=== ubuntulog [i=ubuntulo@trider-g7.fabbione.net]  has joined #ubuntu-installer
=== Topic for #ubuntu-installer: Development of d-i and ubiquity in Ubuntu | http://wiki.ubuntu.com/InstallerDevelopment
=== Topic (#ubuntu-installer): set by cjwatson at Fri Jan  5 15:12:40 2007
=== #ubuntu-installer  [freenode-info]  please register your nickname...don't forget to auto-identify! http://freenode.net/faq.shtml#nicksetup
=== cjwatson_ [n=cjwatson@82-69-40-219.dsl.in-addr.zen.co.uk]  has joined #ubuntu-installer
=== cjwatson1 [n=cjwatson@82-69-40-219.dsl.in-addr.zen.co.uk]  has joined #ubuntu-installer
=== Starting logfile irclogs/ubuntu-installer.log
=== ubuntulog [i=ubuntulo@ubuntu/bot/ubuntulog]  has joined #ubuntu-installer
=== Topic for #ubuntu-installer: Development of d-i and ubiquity in Ubuntu | http://wiki.ubuntu.com/InstallerDevelopment
=== Topic (#ubuntu-installer): set by cjwatson at Fri Jan  5 15:12:40 2007
=== blackskad [n=blackska@d54C4A53D.access.telenet.be]  has joined #ubuntu-installer
[09:43] <CIA-26> oem-config: cjwatson * r300 oem-config/ (d-i/manifest debian/changelog): * Automatic update of included source packages: console-setup 1.16ubuntu4.
[10:03] <CIA-26> oem-config: cjwatson * r301 oem-config/debian/changelog: releasing version 1.16
[11:00] <cjwatson> evand: hw-detect 1.53ubuntu1 uploaded
[11:00] <cjwatson> evand: could you push your bzr branches for base-installer and main-menu?
[01:24] <CIA-26> ubiquity: cjwatson * r2109 ubiquity/ (87 files in 5 dirs): (log message trimmed)
[01:24] <CIA-26> ubiquity: * If oem-config/enable is true, then:
[01:24] <CIA-26> ubiquity:  - Adjust title bar to indicate that Ubiquity is running in OEM mode.
[01:24] <CIA-26> ubiquity:  - Hardcode the user's full name to "OEM Configuration (temporary user)",
[01:24] <CIA-26> ubiquity:  the username to "oem", and the UID to 29999.
[01:24] <CIA-26> ubiquity:  - Install the appropriate oem-config-FRONTEND package on the target
[01:24] <CIA-26> ubiquity:  system.
[01:29] <CIA-26> ubiquity: cjwatson * r2110 ubiquity/ubiquity/frontend/ (gtk_ui.py kde_ui.py noninteractive.py): use new BaseFrontend.debconf_communicator method
[01:46] <CIA-26> oem-config: cjwatson * r302 oem-config/ (11 files in 6 dirs):
[01:46] <CIA-26> oem-config: * Move .glade and .ui files to a new top-level gui directory in the source
[01:46] <CIA-26> oem-config:  package, and install them under /usr/share/oem-config/glade and
[01:46] <CIA-26> oem-config:  /usr/share/oem-config/qt respectively.
[01:48] <CIA-26> oem-config: cjwatson * r303 oem-config/ (configure configure.ac): bump to 1.17
[01:53] <CIA-26> oem-config: cjwatson * r304 oem-config/lib/ (8 files in 3 dirs): PEP-8 import spacing
[01:56] <CIA-26> oem-config: cjwatson * r305 oem-config/ (8 files in 3 dirs):
[01:56] <CIA-26> oem-config: * Rename gtk-ui to gtk_ui and kde-ui to kde_ui, to make it easier to
[01:56] <CIA-26> oem-config:  subclass them.
[02:28] <CIA-26> ubiquity: cjwatson * r2111 ubiquity/ubiquity/frontend/gtk_ui.py: whitespace
[02:31] <CIA-26> oem-config: cjwatson * r306 oem-config/ (8 files in 3 dirs):
[02:31] <CIA-26> oem-config: * Break up the glade file into multiple pieces to make updates to single
[02:31] <CIA-26> oem-config:  pages a lot easier (port of work done in ubiquity by Mario Limonciello).
[02:38] <CIA-26> oem-config: cjwatson * r307 oem-config/ (4 files in 3 dirs):
[02:38] <CIA-26> oem-config: * Drop into pdb.post_mortem on non-SyntaxError exceptions if the --pdb
[02:38] <CIA-26> oem-config:  option is given and oem-config is running from a terminal.
[02:41] <CIA-26> oem-config: cjwatson * r308 oem-config/ (debian/changelog gui/glade/step_language.glade):
[02:41] <CIA-26> oem-config: * Fix title of language page: "Choose language and location" no longer
[02:41] <CIA-26> oem-config:  makes sense now that the location is computed from the timezone.
[02:45] <CIA-26> oem-config: cjwatson * r309 oem-config/gui/glade/ (4 files): expand -i
[02:56] <CIA-26> oem-config: cjwatson * r310 oem-config/gui/glade/ (4 files): load/save in glade-3 3.3.1-0ubuntu1
[03:00] <CIA-26> ubiquity: cjwatson * r2112 ubiquity/gui/glade/ (stepLanguage.glade stepReady.glade): load/save in glade-3 3.3.1-0ubuntu1
[03:01] <evand> cjwatson: Thanks! http://people.ubuntu.com/~evand/bzr/
[03:05] <CIA-26> oem-config: cjwatson * r311 oem-config/ (5 files in 2 dirs): * Minor UI tweaks to sync up with ubiquity.
[03:53] <evand> cjwatson: Are you OK with me merging the mythbuntu stuff to the ~ubuntu-installer branch?
[03:54] <cjwatson> go ahead
[03:55] <evand> thanks
=== superm1 [n=superm1@ubuntu/member/superm1]  has joined #ubuntu-installer
[04:06] <cjwatson> evand: base-installer uploaded; minor point, you forgot -v1.79ubuntu1 when building
[04:06] <evand> whoops
[04:06] <evand> thanks
[04:09] <evand> superm1: pushing the merge shortly.  Just checking to make sure everything works ok in VMWare.
[04:09] <superm1> great evand
[04:09] <superm1> my worry with it was the stuff in the d-i/source folder if thats okay to have as is (since the rest is populated dynamically)
[04:10] <cjwatson> d-i/source isn't in bzrr
[04:10] <cjwatson> bzr
[04:10] <cjwatson> so it doesn't matter ...
[04:11] <superm1> cjwatson, well there was maybe 4 scripts or so in my branch for the mythbuntu specific stuff
[04:11] <superm1> that I made sure were added in the last commit of mine
[04:12] <evand> there's nothing in d-i/source in your branch
[04:12] <evand> but as cjwatson says, d-i/source isn't versioned
[04:12] <cjwatson> ubiquity-local scripts should live in scripts/
[04:13] <evand> and I just hit it in the build
[04:13] <superm1> evand, are you sure you pulled the latest revision of my branch?  There should be a few things in there
[04:13] <evand> positive
[04:14] <evand> at any rate, as cjwatson says
[04:14] <evand> they shouldn't be in there
[04:14] <evand> that gets rm -rf'ed in a maintainer-clean anyway
[04:14] <superm1> okay then i'll have to move them over
[04:14] <superm1> thats good to know
[04:14] <evand> thanks
[04:14] <cjwatson> superm1: codebrowse.launchpad.net agrees
[04:23] <cjwatson> evand: I'm going to rebuild the main-menu upload, since you included .bzr in the tarball, which I'd prefer not to be there
[04:23] <cjwatson> the actual diff looks ok
[04:24] <evand> hrm, not sure how I missed that one
[04:24] <evand> ok, thanks
[04:26] <superm1> evand, okay i pushed moving all the scripts to the scripts/ directory in the branch.  Its in rev 2111 of my branch
[04:27] <cjwatson>  files removed:  d-i/source/
[04:27] <cjwatson> please don't do that
[04:27] <cjwatson> the directory is revision-controlled, just not its contents ...
[04:28] <cjwatson> (sorry I was unclear earlier)
[04:28] <superm1> ah, when i was doing bzr add it started putting things inside of it into my commit so i took it off
[04:28] <superm1> er k then i'll resolve that
[04:29] <cjwatson> um, I wonder how to resolve it in a way that doesn't result in confusion on later merges
[04:29] <superm1> can i revert changes on a merge?
[04:30] <cjwatson> you could try 'bzr merge -r2111..2110 d-i/source'
[04:31] <cjwatson> the correct result should be that the directory is restored with the same id (as shown by 'bzr ls --show-ids')
[04:32] <superm1> so i then move the contents of source back into it? (They were moved source.moved)
[04:32] <cjwatson> the contents don't matter; you can restore them with 'debian/rules update; bzr revert debian/changelog' anyway
[04:32] <superm1> oh right.
[04:32] <cjwatson> or actually 'debian/rules update-local'
[04:36] <superm1> okay 2112 should have the directory re-added with that id again
[04:37] <CIA-26> ubiquity: cjwatson * r2113 ubiquity/ (d-i/get-sources debian/changelog):
[04:37] <CIA-26> ubiquity: * Add a warning in d-i/source/README about modifying files in this
[04:37] <CIA-26> ubiquity:  directory.
[04:37] <evand> ok
[04:39] <CIA-26> oem-config: cjwatson * r312 oem-config/ (d-i/get-sources debian/changelog):
[04:39] <CIA-26> oem-config: * Add a warning in d-i/source/README about modifying files in this
[04:39] <CIA-26> oem-config:  directory.
[04:41] <cjwatson> evand: hmm, main-menu is confusing. looks like you maybe merged one revision more than the bzr log claims
[04:42] <cjwatson> I'll upload it anyway, should be fine, just a bit weird
[04:42] <cjwatson> I think also joeyh uploaded it without waiting for all the i18n machinery to grind
[04:42] <evand> hrm
[04:43] <cjwatson> there are bots that trawl d-i svn and update all the po and pot files from master versions
[04:43] <evand> neat
[04:44] <cjwatson> uploaded
[04:44] <evand> thanks
=== GaryvdM [n=chatzill@mtngprs5.mtn.co.za]  has joined #ubuntu-installer
[05:19] <GaryvdM> Please will someone help me. I have installed PostgreSQL on my kubuntu edgy box, but when I try run pg_ctl, it says Command not found. Where would pg_ctl normaly be installed on the fs, or how I can find out?
[05:19] <evand> GaryvdM: This is not a support channel.  Please /join #ubuntu
[05:19] <GaryvdM> ok - sorry
[05:19] <evand> No worries :)
[05:33] <evand> superm1_: what was your reason for the changes to ubiquity-frontend-gtk.install and ubiquity.install.any?
=== GaryvdM [n=chatzill@mtngprs5.mtn.co.za]  has left #ubuntu-installer [] 
[05:34] <evand> they strike me as unnecessary, but perhaps I'm missing the obvious
=== blackskad [n=blackska@d54C4A53D.access.telenet.be]  has joined #ubuntu-installer
[06:02] <cjwatson> hmm, partman-loop might not be as hard to write as I thought; I had been misremembering the order in which mount.d scripts are rrun
[06:02] <cjwatson> run
=== superm1 [i=malimonc@ubuntu/member/superm1]  has joined #ubuntu-installer
[06:25] <superm1> evand, they were because the * would automatically add some of my files
[06:25] <superm1> into ubiquity-frontend-gtk
[06:25] <superm1> which would be undesirable
[06:27] <evand> gotcha, thanks
[09:27] <CIA-26> ubiquity: evand * r2114 ubiquity/ (32 files in 7 dirs): * Merge in mythbuntu alpha 2 changes.
[09:29] <evand> I made some minor changes here and there.  I moved the mythbuntu scripts into a subdirectory.  I changed the wording on the copyright ever so slightly (so please look and let me know if you take issue with that)
[09:29] <evand> oh and as I myself learned, you want to revert d-i/manifest and the changes to changelog when you build unless you're building the release.
[09:32] <evand> I walked through the interface and everything looks like it's still working.
=== cjwatson_ [n=cjwatson@82-69-40-219.dsl.in-addr.zen.co.uk]  has joined #ubuntu-installer
[10:07] <CIA-26> oem-config: cjwatson * r313 oem-config/ (debian/changelog finish-install.d/07oem-config-user): * Fix desktop file installation harder.
[10:14] <superm1> great evand thanks. i'll merge them back to my branch when I get home later and make sure everything is still working right
[10:14] <superm1> and looks good
[10:15] <superm1> is there anything that will need to be done to make sure translators can translate our UI elements?
[10:15] <superm1> other than have them in the templates file?
[10:19] <evand> superm1: debian/ubiquity.templates
[10:20] <superm1> evand, but since the templates for the mythbuntu ui are in a sep. template file, will that matter?
[10:20] <superm1> or will it be submitted just the same
[10:20] <cjwatson_> it needs to go in debian/po/POTFILES.in
[10:20] <superm1> ah okay
[10:20] <superm1> well i'm going to scrub to make sure i have all the right ones that need translation first
[10:20] <cjwatson> (and then run debconf-updatepo and commit)
[10:20] <superm1> before adding there then
[10:23] <cjwatson> superm1: hmm, I don't like that summary template, it's massive overkill
[10:23] <cjwatson> not to mention crazy indenting
[10:23] <superm1> by overkill you mean too much is presented?
[10:23] <cjwatson> I think translators will have a lot of trouble with that, and it should be cut down
[10:23] <cjwatson> yes
[10:23] <superm1> alright I can pull out a lot of the details then
[10:24] <cjwatson> people will only read a few lines of summary - and it will actually push partitioning information off the screen, which is a lot more important than your mythtv theme!
[10:24] <cjwatson> it also displays passwords which is a big no-no
[10:24] <superm1> ah i see
[10:25] <superm1> i'll clean that up then tonight
[10:25] <cjwatson> there are some places where you have _Description: lines wrapped
[10:25] <cjwatson> technically the format is actually:
[10:25] <cjwatson> _Description: DESCRIPTION
[10:25] <cjwatson>  EXTENDED_DESCRIPTION
[10:25] <cjwatson> so wrapping from the first line pushes it into a different field - looking at the cases in question I would suggest just putting them on a very long single line
[10:25] <superm1> how are you supposed to present a multiline description then?
[10:25] <superm1> with \n's in the field?
[10:26] <cjwatson> debconf will wrap it for you
[10:26] <cjwatson> hardcoded newlines are ignored unless you really try hard anyway ...
[10:26] <cjwatson> actually, it might even be better to do this:
[10:26] <cjwatson> _Description:
[10:26] <superm1> but if its going to override somewhere in the glade that is already multiline
[10:26] <cjwatson>  some text that is
[10:26] <cjwatson>  wrapped
[10:27] <cjwatson> superm1: none of the text I'm talking about benefits from carefully positioned \n characters
[10:27] <superm1> i see
[10:28] <cjwatson> want me to just commit what I mean?
[10:28] <cjwatson> I don't seem to be explaining it very well
[10:28] <superm1> sure that might be best :)
[10:29] <cjwatson> you realise that putting a newline in a <property name="label"> doesn't actually result in a newline in the final display, right?
[10:30] <superm1> I had thought it did..... there were several cases that when editing within glade-3 that i'd just hit enter and start another line in the label text field
[10:30] <cjwatson> or perhaps another explanation
[10:30] <cjwatson> _Description: An RSS feed news reader plugin for MythTV that keeps you up-to-date on your
[10:30] <cjwatson>  favorite news topics.
[10:30] <cjwatson> this results in the following in the debconf database:
[10:30] <cjwatson> Description: An RSS feed news reader plugin for MythTV that keeps you up-to-date on your
[10:30] <cjwatson> Extended_description: favorite news topics.
[10:30] <superm1> ah and that will completely break it
[10:30] <superm1> i see
[10:30] <cjwatson> and results in "An RSS feed news reader plugin for MythTV that keeps you up-to-date on your" and "favorite news topics." being separate translatable chunks
[10:31] <cjwatson> superm1: oh, well if it does then it isn't what you want :)
[10:31] <cjwatson> you don't want to hardcode newlines in the glade file - you have no idea how wide the screen is
[10:31] <superm1> then what is the most appropriate way to do it in glade?
[10:32] <superm1> just keep things short ;)?
[10:32] <cjwatson> don't press Enter
[10:32] <cjwatson> set the line-wrap property and gtk will wrap stuff for you
[10:32] <superm1> how does it know how wide i'm going to allow then?
[10:33] <cjwatson> you don't do the allowing, gtk does :)
[10:34] <superm1> I think i'll need to toy with it a bit then, because when I was doing really long lines the first time around, the GUI window would expand to get wider
[10:34] <cjwatson> you probably forgot to turn line-wrap on for that widget
[10:34] <superm1> probably then
[10:34] <cjwatson> or else you had it in single-line mode (there are two related properties there)
[10:34] <CIA-26> ubiquity: cjwatson * r2115 ubiquity/debian/ubiquity-frontend-mythbuntu.templates: fix incorrect description wrapping
[10:35] <cjwatson> gtk doesn't line-wrap optimally (it tends to use much less than the full width) but I expect that will be fixed eventually and it's better for us to live with that than employ dubious workarounds
[10:35] <superm1> is the full width then determined by the 'alignment' widgets?
[10:36] <superm1> i saw those in use in a lot of your pages, but wasn't sure when was appropriate to be using them
[10:39] <cjwatson> not really; we use GtkAlignments to control things like indentation and spacing
[10:39] <superm1> oh ok
[10:39] <cjwatson> you can wrap an alignment around any non-top-level widget to say "give this a left margin of 12 pixels"
[10:39] <cjwatson> which is good for fine details of page layout
[10:39] <cjwatson> hmm, I notice mythbuntu-setup does xhost +$HOSTNAME but then goes on to use xauth. Do you really need both? Just xauth would be bette
[10:39] <cjwatson> r
[10:40] <superm1> because the hostname is updated
[10:40] <superm1> to the new one chosen during install
[10:40] <superm1> originally it was just done via xauth
[10:41] <superm1> but I realized that mysql was getting messed up because the wrong hostname was being used
[10:41] <superm1> (not the one that is post install)
[10:41] <cjwatson> that would break xhost, not xauth, wouldn't it?
[10:42] <cjwatson> I'm just puzzled by why you turn on two different X authentication mechanisms
[10:42] <superm1> well xhost was the one that i added later
[10:42] <superm1> it was not necessary
[10:42] <superm1> until i realized that
[10:42] <cjwatson> would be better to call apt-install on the packages you want than the manifest-mythbuntu trick
[10:43] <superm1> apt-install for removal?
[10:44] <superm1> the manifest mythbuntu trick calculates removals, additions are done via the same mechanism as the language pack install
[10:44] <cjwatson> no, I mean it would be better to invert it and state what you want to keep using apt-install
[10:44] <cjwatson> then you wouldn't have to override that whole method from scripts/install.py
[10:44] <superm1> oh that's an interesting way to think about it
[10:44] <superm1> didn't consider that as a possibility even
[10:45] <cjwatson> that's the usual way :-)
[10:45] <superm1> i was feeling intuitive with my regex magic :)
[10:46] <superm1> indeed though, the less methods that need to be overriden, the better
[10:49] <CIA-26> ubiquity: cjwatson * r2116 ubiquity/ubiquity/components/mythbuntu_services.py: no need to import both os and os.path
[10:50] <cjwatson> +from ubiquity.misc import *
[10:50] <cjwatson> +
[10:50] <cjwatson> +from ubiquity import misc
=== cjwatson blinks
[10:51] <CIA-26> ubiquity: cjwatson * r2117 ubiquity/ubiquity/frontend/mythbuntu_ui.py: python doesn't need trailing semicolons
[10:52] <superm1> ah the things that i easily overlook... thanks for catching these
[10:54] <cjwatson> not a problem
[10:55] <CIA-26> ubiquity: cjwatson * r2118 ubiquity/bin/ubiquity-wrapper: slightly more idiomatic
[10:57] <CIA-26> ubiquity: cjwatson * r2119 ubiquity/debian/ubiquity-frontend-mythbuntu.postinst: unnecessary postinst
[10:58] <CIA-26> ubiquity: cjwatson * r2120 ubiquity/ubiquity/components/ (mythbuntu_install.py mythbuntu_summary.py summary.py): avoid some duplication
[10:59] <superm1> that postinst was necessary I had thought, it registers all the things in the templates file
[10:59] <superm1> with debconf
[10:59] <superm1> within the #DEBHELPER# tag
[11:01] <cjwatson> superm1: whoops, you're quite right
[11:01] <cjwatson> I'll revert that
[11:01] <CIA-26> ubiquity: cjwatson * r2121 ubiquity/ubiquity/frontend/mythbuntu_ui.py: tidy up imports
[11:02] <superm1> and in 2120, will the default /usr/share/ubiquity/install.py be called before getting to updating prep[0] ?
[11:02] <superm1> or will that work appropriately
[11:03] <cjwatson> phone
[11:03] <CIA-26> ubiquity: cjwatson * r2122 ubiquity/ (debian/changelog gui/glade/stepUserInfo.glade):
[11:03] <CIA-26> ubiquity: * GTK frontend:
[11:03] <CIA-26> ubiquity:  - Fix full-name error reason widget, and make the error reasons
[11:03] <CIA-26> ubiquity:  selectable.
[11:04] <CIA-26> ubiquity: cjwatson * r2123 ubiquity/debian/ubiquity-frontend-mythbuntu.postinst: revert r2119, I was too wrong for words
[11:05] <superm1> and in 2121, don't the debconf imports still need to happen?  so that things like debconf_progress_start() can be called
[11:17] <cjwatson> superm1: 2120> the only change I could see in mythbuntu_install's prepare method was that you returned a slightly different list
[11:18] <superm1> i'll double check it later this evening then
[11:18] <cjwatson> superm1: so that's easily done, just call the superclass' prepare method, modify the list you get back, and return that
[11:18] <superm1> make sure it works as expected still
[11:18] <cjwatson> sure, definitely
[11:18] <cjwatson> superm1: 2121> python imports are very simple: they do some initialisation (often none) and bind names
[11:18] <cjwatson> superm1: well-behaved python modules tend to do no initialisation you actually care about
[11:19] <cjwatson> superm1: so, to a good first approximation, you only need to import something if you use something from its namespace
[11:19] <cjwatson> superm1: those names weren't used, so I deleted the imports
[11:19] <superm1> i see
[11:19] <cjwatson> (and I happened to know that DebconfCommunicator definitely wasn't needed any more)
[11:19] <superm1> okay makes sense :)
[11:20] <cjwatson> debconf_progress_start is implemented in a different file, which imports everything it needs itself to do so
[11:22] <CIA-26> ubiquity: cjwatson * r2124 ubiquity/ubiquity/frontend/mythbuntu_ui.py: come to think of it, we don't need to import gtk.glade either