[17:13] <infinity> xnox: Naughty.
[17:14] <xnox> infinity: =)
[17:15] <xnox> infinity: yeah, i think I'll move firmware install from post-base-install.d to pre-pkgsel.d/01* such that it's almost first thing after kernel is installed.
[17:16] <xnox> infinity: and most importantly before update-initramfs is done.
[17:16] <infinity> Indeed.  The timing is critical.
[17:17] <infinity> (Well, there's no reason you can't trigger another in-target update-initramfs -u)
[17:17] <infinity> SUcks to slow down the install with multiple calls, but it's not world-ending either.
[17:17] <xnox> infinity: i just think that some of drivers, might just be drivers with no other postinst scripts et al.
[17:18] <xnox> infinity: and as this bug shows, all other driver disks never used proper dependencies.
[17:18] <xnox> =/
[17:21] <xnox> infinity: should drivers generally depend on "linux-image-3.x.y-WW-generic" ?
[17:21] <infinity> Well, dkms driver disks don't need to depend on a kernel (would be wrong if they did), but still better to shuffle them all to this later spot.
[17:22] <infinity> This new and icky case is because they're shipping pre-compiled .ko files.
[17:22] <xnox> infinity: true. I wonder if moving this will break any existing driver disks, as I'll be pushing this to precise I'm guessing.
[17:22] <xnox> infinity: e.g. like Dell disks (which is where this feature originally came from)
[17:23] <infinity> I don't see why it would break a dkms disk, but shouldn't be too hard to test.
[17:23] <infinity> It just means the dkms trigger will have to happen from the driver install instead of from the kernel's postinst.
[17:23] <xnox> infinity: true.
[17:24] <infinity> Which should be true anyway, or their driver's don't work when you apt-get install them.
[17:24] <infinity> But worth checking.
[17:24] <infinity> s/driver's/drivers/
[17:24] <infinity> Wow, I'm typing in internet grammar.  I need to wake up.
[17:25] <xnox> infinity: try to install twice? or will we find bugs =)
[17:25] <xnox> i think it ignores errors at the moment.
[17:27] <xnox> superm1: are there any Dell Driver Injection Disks available publicly? e.g. for testing. I am working on a solution for bug #1216043
[17:27] <ubot2`> Launchpad bug 1216043 in hw-detect (Ubuntu Saucy) "driver-inject-disk: in target debs are installed before kernel has been" [High,Confirmed] https://launchpad.net/bugs/1216043
[17:27] <xnox> superm1: and well see discussion above ^
[17:28] <xnox> and I would not want to break existing driver disks.
[17:34] <superm1> xnox: AFAIK it hasn't actually been used yet.  it was added in anticipation of a factory preinstalled ubuntu server image, but thus far the machines have been certified but not preinstalled and there has been no other work put towards it
[17:35] <superm1> but to your discussion, i don't think it's appropriate that the debs included should depend on specific kernel versions
[17:35] <superm1> it's asking for breakage with every respin of an alternate ISO that includes an updated kernel
[17:36] <xnox> superm1: ok. thanks for the info.
[17:36] <superm1> kentb-out: was just discussing with me plans on how to get it into deployment though, so if you make changes make sure you tie off with him
[17:37] <xnox> ack.
=== kentb-out is now known as kentb
[17:39] <infinity> superm1: dkms disks obviously shouldn't depend on kernel versions.  This other messed up use-case (pre-built .ko files) has to, but that shouldn't concern you guys, cause you're doing it right. :)
[17:40]  * arges reads
[17:42] <superm1> prebuilt ko's without a way to rebuild is asking for trouble for sure
[17:46] <infinity> superm1: We've told this partner the same thing, yes. :P
[17:46] <infinity> superm1: But providing them a mechanism to ask for said trouble is still helpful, even if we disagree with their method. :)
[17:47] <infinity> (And it should just be a matter of doing the driver install a tiny bit later (after a kernel is already installed in-target) and then making sure that doens't blow up dkms disks)
[17:47] <superm1> that's unfortunate that it probably will get used by another partner before we ever got to use it in production
[17:47] <infinity> superm1: And if you guys aren't yet using dkms disks in production, this is perfect, as we can just test new disks going forward, not worry about breaking old ones.
[17:47] <superm1> yep
[18:03] <xnox> arges: see proposed branch and check if that works for you https://bugs.launchpad.net/ubuntu/+source/hw-detect/+bug/1216043
[18:03] <ubot2`> Launchpad bug 1216043 in hw-detect (Ubuntu Saucy) "driver-inject-disk: in target debs are installed before kernel has been" [High,Confirmed]
[18:04] <xnox> arges: I'm off to gym and EOD/EOW, but will pop back on IRC later.
[18:07] <infinity> xnox: Your MP is full of >>><<< merge conflict markers. :P
[18:08] <xnox> infinity: excellent.
[18:09] <xnox> infinity: so you click search, find a branch, click on it, lp adds it to the target branch field, but does not move the radio button from default focus!
[18:10] <infinity> xnox: Oh, so the MP was a mistake? :)
[18:10] <infinity> That explains a lot.
[18:10] <xnox> infinity: well, target branch =)
[18:10] <xnox> infinity: https://code.launchpad.net/~xnox/hw-detect/fix-firmware-order/+merge/181886
[18:10] <xnox> fixed.
[18:14] <infinity> xnox: Ahh, that's much more readable.  Uselessly so, since I need the source to figure out what the file you moved is. :)
[18:14]  * infinity looks.
[18:15] <infinity> # copy any loose firmware files to /target (incl. subdirs)
[18:15] <infinity> SRSLY?
[18:15] <infinity> Who wrote this?
[18:17] <infinity> I really, really, really wish I hadn't read that script.
[18:20] <infinity> xnox: Hrm, after I've approved it, I now wonder if the above scary bit is a problem with reordering.
[18:20] <infinity> xnox: Since it could be overwriting firmware from linux-firmware (presumably, it ran before linux-firmware was installed before you moved it)
[18:21] <infinity> Honestly, I wonder who thought that was a good idea AT ALL.  Copying random firmware from the installer to the target system just seems scary.
[18:26] <superm1> 50-install-firmware wasn't written as part of the driver injection disk stuff, i thought that part came from debian from earlier
[18:26] <infinity> Indeed, you just leveraged it, since it already copies debs around and installs them.
[18:26] <infinity> In fact...
[18:26] <infinity> Hrm.
[18:27] <infinity> xnox: It might be better to put 50-install-firmware back where it came from.
[18:27] <infinity> xnox: And do a new XX-driver-disk in hw-detect.pre-pkgsel.d that uses a different /tmp directory.
[18:28] <infinity> xnox: And mangle driver-injection-disk.sh to use that instead of overloading /tmp/firmware
[18:30] <superm1> also the driver injection stuff did make it up to debian, so make sure that whatever you change you commit (or get someone to sponsor) up there too to be consistent
[18:30] <infinity> xnox and I both have commit to d-i in Debian.
[18:31] <superm1> great :)
[19:13] <xnox> infinity: I rarely question d-i =) colin will be back on monday and I can see if that bit can be improved.
[19:28] <infinity> xnox: Fundamentally, I think it's just wrong to leverage the firmware thing to install things that aren't firmware.  Using another tmpdir and a different hook for driver disks feels cleaner.
[19:28] <infinity> xnox: And should be generally non-contentious.  I'd commit that upstream today, if it looked clean.
[19:44] <xnox> I have tea to drink with cheesecake though =)
[19:44] <xnox> will do that, but not today.