[11:52] <lool> Hmm it's not going to be easy to provide d-i images for dove z0 boards using the -z0 udeb: both the dove and dove-z0 udebs use the /boot/vmlinuz name
[11:53] <lool> cjwatson: Do you think we should use a subarch here to workaround this or should we change kernel-wedge/kernel udebs to output /boot/vmlinuz-$flavour ?
[11:53] <ogra> oh, that will be fun once we have imx51 lange kernels (if ever)
[11:53] <cjwatson> gaaaaaaaaah
[11:53] <cjwatson> sorry, I just don't have bandwidth for this
[11:53] <lool> cjwatson: no hurry
[11:54] <lool> cjwatson: let's chat about this post A6
[11:54] <cjwatson> why do you have both dove and dove-z0 in the one image?
[11:54] <cjwatson> if you don't have them in the same image, then surely it doesn't matter
[11:54] <lool> cjwatson: We dont have them in one image
[11:54] <ogra> -z0 is really only a nice to have
[11:54] <lool> cjwatson: however I understand d-i builds flavours for a subarch in a single pass
[11:54] <cjwatson> so why is it a problem? vmlinuz can be one thing in one image and something else in another
[11:54] <lool> and subarches in multiples passes
[11:55] <cjwatson> each image should be built in an entirely separate tree
[11:55] <lool> cjwatson: In both case it's a netboot image
[11:55] <lool> *cases
[11:55] <cjwatson> yes, but ... what I said
[11:55] <lool> So I guess I could add netboot-z0
[11:55] <cjwatson> *one* of the names needs to be different
[11:56] <lool> It's less ugly than a subarch indeed
[11:56] <cjwatson> I don't see why you couldn't just call it dove-z0/netboot though
[11:56] <lool> Ah right that doesn't imply subarch
[11:56] <cjwatson> as in, have a dove-z0 alongside the existing dove
[11:56] <cjwatson> well, it would be a subarch
[11:56] <lool> That's fine too, I thought subdirs where subarches but they are not
[11:56] <cjwatson> but what's wrong with that? it's a different kernel ...
[11:56] <lool> Ah
[11:57] <lool> Well I thought we had x arches with y subarches and z kernel flavours as the data model
[11:57] <cjwatson> the data model is not all that rigid
[11:57] <lool> Ok; I'll either create a subarch or differently named image
[11:58] <lool> thanks
[11:58] <cjwatson> in the case of powerpc, "powerpc64" is considered a subarchitecture at the d-i build system level
[11:58] <cjwatson> even though it's not a subarchitecture in the more general sense
[11:58] <cjwatson> it's just a kernel flavour
[12:22] <lool> cjwatson: Ack; what I looked at when I saw the vmlinuz filename issue was hppa
[12:23] <lool> http://ftp.de.debian.org/debian/dists/unstable/main/installer-hppa/current/images/cdrom/2.6/
[12:23] <cjwatson> I wouldn't recommend using hppa as an example of anything much
[12:23] <lool> It's the only one I found where two kernel flavours were used in the same image build
[12:24] <lool> Looking at subarch versus another image, it seems I could just include the dove.cfg from dove-z0.cfg and add overrides
[12:25] <cjwatson> I'd prefer that you copied the whole dove/ tree instead
[12:25] <cjwatson> and edited
[12:25] <lool> Ok
[12:25] <cjwatson> that's more usual practice
[12:25] <cjwatson> (sane or not)
[12:54] <lool> ./installer-armel/20081029ubuntu61/images/dove-z0/netboot/dove-z0/uImage
[12:54] <lool> ./installer-armel/20081029ubuntu61/images/dove-z0/netboot/dove-z0/uInitrd
[12:54] <lool> ./installer-armel/20081029ubuntu61/images/dove/netboot/dove/uImage
[12:54] <lool> ./installer-armel/20081029ubuntu61/images/dove/netboot/dove/uInitrd
[12:55] <lool> I think I'll use dove/netboot/dove-z0 instead
[12:56] <lool> ah that's not the easy one
[12:56] <lool> Oh well powerpc does the same
[13:34] <CIA-33> ubiquity: mterry * r3454 trunk/ (debian/changelog ubiquity/frontend/kde_ui.py):
[13:34] <CIA-33> ubiquity: kde: Fix crasher when in the advanced partition page by adding a
[13:34] <CIA-33> ubiquity: missing function. LP: #430413
[13:48] <lool> cjwatson: Just pushed d-i dove-z0 netboot images support; not needed in A6 in anyway though
[13:48] <cjwatson> ok, thanks
[15:53] <mterry> cjwatson, evand1, btw, I pushed an unreleased crasher for kde partitioning.  Probably worth pushing before alpha.  Don't know if ya'll planned another push or not
[15:57] <evand1> well, we can always upload, and if someone triggers a livefs rebuild it will get picked up.
[15:58]  * evand1 starts that
[15:58] <cjwatson> well
[15:58] <cjwatson> we need to convert to Upstart as well
[15:59] <cjwatson> I think we should probably wait until that's done since we'll need to upload for it anyway, otherwise the "Install Ubuntu" menu item won't work - bug 430607
[15:59] <cjwatson> I'm part-way into that
[15:59] <evand1> okay
[16:07] <CIA-33> usb-creator: evand * r171 policykit/ (15 files in 7 dirs): Initial commit of PolicyKit support.
[16:07] <evand1> ignore that
[16:07]  * evand1 hacks CIA off his branch configuration
[16:51] <rgreening> oooh-ooo-ooo-oooh  policykit evand1 :)
[16:51] <rgreening> noooooooo
[16:51] <rgreening> heh
[16:52] <evand1> haha, almost ready to go in
[16:52] <evand1> just polishing
[17:31] <CIA-33> ubiquity: cjwatson * r3455 ubiquity/debian/ (oem-config.upstart ubiquity.upstart changelog): Add Upstart jobs for ubiquity and oem-config (LP: #430607).
[17:32] <cjwatson> evand1: anything more before we upload this?
[17:32] <evand1> nope, nothing here
[17:33] <superm1> you don't need to nuke the init scripts themselves first or anything like that?
[17:37] <CIA-33> usb-creator: evand * r201 trunk/ (15 files in 6 dirs): Add PolicyKit support (LP: #273483).
[17:38] <cjwatson> superm1: no
[17:38] <cjwatson> dh_installinit is clever
[17:38] <superm1> cool :)
[18:04] <rgreening> mmmm policykit
[18:04]  * rgreening checksout to test
[18:14] <CIA-33> usb-creator: rgreening * r202 trunk/ (8 files in 5 dirs):
[18:14] <CIA-33> usb-creator: * Bump version in setup.py, kde_about.py, usb-creator-gtk, and man to 0.2.7
[18:14] <CIA-33> usb-creator: * Remove completed TODO items
[18:14] <CIA-33> usb-creator: * Update some message strings fro translations
[18:26] <CIA-33> usb-creator: evand * r203 trunk/debian/control: Drop depends on gksu and kdesudo.
[18:41] <rgreening> yay
[18:41] <rgreening> bu-bye su-su-sudo
[18:42] <rgreening> NCommander: ping
[18:43] <NCommander> rgreening, pong
[18:44] <rgreening> hey NCommander. YOu know of current b0rkage with python, qt, and sip?
[18:44] <rgreening> I can't run any pyqt apps now... ScottK said something about BIC
[18:46] <NCommander> rgreening, I'm not aware of any breakage, but I haven't run any apps recently
[18:47] <rgreening> hmm... NCommander: ImportError: /usr/lib/pymodules/python2.6/PyQt4/QtGui.so: undefined symbol: _Z29qt_set_sequence_auto_mnemonicb
[18:47] <rgreening> any idea?
[18:51] <NCommander> rgreening, rebuild the app thats using it, or bindings if its KDE
[18:51] <NCommander> ABI bumps aren't properly handled w/ pyqt4 ATM
[18:53] <rgreening> oh
[18:53] <rgreening> so, my app is usb-creator-kde, it's all python... so rebuild which package?
[18:53] <rgreening> kdebindings?
[18:53] <NCommander> rgreening, sounds promising, but I'm not 100% sure
[18:54]  * NCommander is feeling horrible ATM
[19:09] <samba> can anyone tell me where casper kicks in among the initrd scripts? I'm looking at a Jaunty Desktop CD, and so far I haven't found anything in the scripts that specifically calls /scripts/casper
[19:10] <cjwatson> samba: we pass boot=casper as a boot parameter
[19:10] <cjwatson> sorry, BOOT=casper
[19:10] <cjwatson> actually, I was right the first time :)
[19:10] <cjwatson> /usr/share/initramfs-tools/init has:
[19:10] <cjwatson> ...
[19:10] <cjwatson>         boot=*)
[19:10] <cjwatson>                 BOOT=${x#boot=}
[19:10] <cjwatson> ...
[19:10] <cjwatson> . /scripts/${BOOT}
[19:10] <samba> oh, right!
[19:10] <samba> (forgot about that one)
[19:10] <samba> thanks
[19:11]  * cjwatson -> away
[20:47] <samba> evand1, you around?
[21:45] <CIA-33> ubiquity: evand * r3456 ubiquity/debian/changelog: releasing version 1.99.20
[22:59] <superm1> cjwatson, evand1, looking at that diff for upstart enabling stuff, isn't that going to unconditionally start ubiquity if it's installed, preventing gdm from starting up?
[22:59] <superm1> there doesn't look to be a check for if ubiquity is actually 1 around those two exec statements
[23:00] <superm1> same thing with oem config
[23:00] <cjwatson> true, I'll fix that
[23:00] <cjwatson> but in a moment because I have another change involving moving those files aroundd
[23:04] <CIA-33> ubiquity: cjwatson * r3457 ubiquity/debian/ (6 files):
[23:04] <CIA-33> ubiquity: Install the init script (under a new, temporary name) as well as the
[23:04] <CIA-33> ubiquity: Upstart job, in order that flavours whose display managers haven't yet
[23:04] <CIA-33> ubiquity: converted to Upstart can still work. Take pains to ensure that only one
[23:04] <CIA-33> ubiquity: of these runs.
[23:05] <CIA-33> ubiquity: cjwatson * r3458 ubiquity/debian/ (changelog ubiquity.ubiquity.upstart):
[23:05] <CIA-33> ubiquity: Fix ubiquity's Upstart job to actually check whether it should run
[23:05] <CIA-33> ubiquity: ubiquity (thanks, Mario Limonciello).
[23:26] <evand1> ah, awesome catch cjwatson
[23:27] <evand1> (on 430724)
[23:27] <cjwatson> can't believe I missed that in the conversion
[23:27] <cjwatson> I was really careful about debdiffing
[23:27] <cjwatson> I'm just testing now to make sure nothing else has exploded
[23:28] <cjwatson> but the upshot is that ubiquity's extensions get installed to /lib/partman/partman/...
[23:32] <xivulon1> slow iso rsync here, is it worth the wait? or are relevant changes going to be in tomorrow?
[23:35] <CIA-33> ubiquity: cjwatson * r3459 ubiquity/ (d-i/update-control debian/changelog debian/control): Build-depend on dh-di 3 to pick up fix affecting manual partitioning.
[23:36] <CIA-33> ubiquity: cjwatson * r3460 ubiquity/ (debian/changelog ubiquity/frontend/base.py): Tolerate LANG not being set yet in get_string (LP: #431048).
[23:37] <cjwatson> well, we're madly fixing stuff ...
[23:37] <cjwatson> I don't know exactly how good or bad the current images are