[03:45] <superm1> re: the debian/rules update-local command.  What am I supposed to do when newer versions are available on the repos, but old ones are in the manifest?
[03:46] <superm1> I don't want to update the manifest myself do I?
[03:54] <evand> you just don't want to commit changes to the manifest unless you're preparing a release.
[03:55] <superm1> oh i see
[03:55] <superm1> well i guess i can just let it update the manifest, and before i commit back, then revert that manifest file
[03:55] <evand> so don't worry about what debian/rules update does until you're ready to commit, at which point bzr revert d-i/manifest and delete the entry out of the changelog
[03:55] <evand> that's what I do
[03:56] <superm1> thats manageable
[03:56] <superm1> earlier cjwatson was talking about how the width of the labels is automatically determined when you go into word wrap mode
[03:56] <superm1> is there any way to let it "determine" that it can be wider?
[04:17] <evand> I'm not sure I understand what you're asking.  GTK uses box packing rather than absolute positioning and sizing.  So a widget will expand to any space you stuff it into.
[04:18] <superm1> alright, well now that i'm looking i cant even run the gui to test for sure
[04:18] <evand> problem?
[04:18] <superm1> it looks like something broke with both gtk_ui
[04:18] <superm1> and mythbuntu_ui
[04:18] <superm1> related to oem_config_title
[04:19] <evand> I recall seeing such errors, but they didn't crash the UI for me
[04:19] <evand> I'll have a look a little later tonight
[04:19] <superm1> its possible my merge is a bit messed up too, i tried to merge all the changes commited today back into my branch
[04:19] <superm1> with bzr merge
[04:19] <superm1> but it seems to be the wrong way to do it
[04:19] <superm1> perhaps i was supposed to do bzr pull
[04:20] <evand> why do you say that?
[04:20] <superm1> well because when i tried to commit my changes, it automatically listed all of cjwatson's changes as other items that were in the commit
[04:20] <evand> pull will pull any changes from the original location you branched from, so you want to merge back, afaik.
[04:20] <evand> right
[04:20] <superm1> that's how its supposed to work then?
[04:20] <evand> I believe so
[04:21] <evand> that's how I've approached it and I don't recall any complaints from cjwatson in future merges
[04:21] <superm1> what happens to all the revision numbers then?
[04:21] <superm1> how do they stay in sync?
[04:21] <superm1> between all these branches
[04:23] <evand> I'm a little fuzzy on how that exactly works, and haven't been curious enough yet to investigate it.  The bzr website probably has documentation on that though.
[04:24] <superm1> yea i've been trying to follow it, and actually talked to jam this weekend when he was talking at ubuntu-chicago (CoDLUG)
[04:24] <superm1> but didn't ask enough :)
[04:24] <evand> heh
[04:33] <superm1> cjwatson, haha.  I just noticed in one of your revisions the "# Add a warning to budding hackers."
[04:48] <superm1> evand, well from what i gather the revision number is only relevant to the branch your working on.  so several branches might have different revision numbering schemes, but it doesnt matter in the end because you merge the other branches in
[04:49] <evand> indeed, I'm just hazy on where the start number comes from.  I think it's revision+1 of the branch point.
[10:10] <cjwatson> superm1: it's entirely possible my oem_config_title change was broken
[11:46] <CIA-26> oem-config: cjwatson * r314 oem-config/ (4 files in 4 dirs):
[11:46] <CIA-26> oem-config: * Update user page layout to match ubiquity, including filling in a
[11:46] <CIA-26> oem-config:  suggested username automatically, displaying error messages inline, and
[11:46] <CIA-26> oem-config:  showing a warning message in debugging mode.
[12:17] <CIA-26> oem-config: cjwatson * r315 oem-config/ (3 files in 3 dirs): * Set up autologin for the oem user via gdm/kdm.
[12:31] <CIA-26> oem-config: cjwatson * r316 oem-config/ (4 files in 3 dirs): * Disable the hwdb-client notification for the created user.
[02:54] <CIA-26> ubiquity: cjwatson * r2125 ubiquity/ (88 files in 7 dirs):
[02:54] <CIA-26> ubiquity: - Ask for a unique identifier for this batch of installations, and save
[02:54] <CIA-26> ubiquity:  that in /var/log/installer/oem-id on the installed system.
[03:03] <CIA-26> oem-config: cjwatson * r317 oem-config/ (debian/changelog oem-config):
[03:03] <CIA-26> oem-config: * Add a facility to run hook scripts from /usr/lib/oem-config/post-install
[03:03] <CIA-26> oem-config:  just before exiting. Hook scripts are run noninteractively, although
[03:03] <CIA-26> oem-config:  they can talk to debconf for database queries and the like if they need
[03:03] <CIA-26> oem-config:  to.
[03:05] <CIA-26> oem-config: cjwatson * r318 oem-config/debian/changelog: reorganise changelog slightly
[03:07] <CIA-26> oem-config: cjwatson * r319 oem-config/debian/changelog: clarify
[03:31] <CIA-26> oem-config: cjwatson * r320 oem-config/debian/changelog: releasing version 1.17
[03:53] <superm1> evand, i'll merge nack in the other revisions and see
[06:51] <superm1> cjwatson, i've been trying to poke around, where is the artwork for the isolinux splash for { ,k,ed,x}ubuntu packaged?  pitti had said he though gfxboot-theme-ubuntu, but it doesn't appear so.
[06:54] <cjwatson> superm1: http://people.ubuntu.com/~cjwatson/bzr/debian-cd/ubuntu/
[06:54] <cjwatson> not exactly easy to find, I admit ...
[10:34] <superm1> cjwatson, is this how the CD are entirely built, via these scripts?
[10:35] <superm1> and yes not easy to find :)