=== bladernr_afk is now known as bladernr_ === jibel_ is now known as jibel === bladernr_ is now known as bladernr_afk [12:38] pitti: looks like the software-center maverick-proposed SRU is now verified as well, when could that land in -updates? I ask mainly for the ISD team they need this fix for the payments stuff [13:09] mvo: released [13:11] \o/ === kenvandine is now known as kenvandine_afk === bladernr_afk is now known as bladernr_ === kenvandine_afk is now known as kenvandine === bladernr_ is now known as bladernr_afk === davmor2_ is now known as davmor2 === Ursinha is now known as Ursinha-lunch [17:05] Why does http://reports.qa.ubuntu.com/reports/kernel-bugs/reports/rls-mgr-p-tracking-bugs.html show "O release" in the "Found" column for bug 897714, which was reported on a Precise image, is tagged precise, and has no mention of oneiric anywhere? [17:05] Launchpad bug 897714 in ubiquity (Ubuntu Precise) (and 1 other project) "oem-config-remove-gtk crashed with SystemExit in _on_failure(): 1 (affects: 1) (heat: 10)" [High,Triaged] https://launchpad.net/bugs/897714 [17:40] cjwatson, I'll dig into it a bit this afternoon and see if I can figure it out with bjf. === Ursinha-lunch is now known as Ursinha [18:44] just pushed a new edubuntu-meta, this should replace edubuntu-fonts in the process, so I'd appreciate it if an archive admin can approve the new binary package (edubuntu-fonts) and remove the old one (both binary and source) from the archive [18:46] the new binary should be accepted automatically [18:47] could you file a bug for removal of the old source, and subscribe ~ubuntu-archive? [18:51] sure [20:28] skaet, rtg just pushed a new version of linux-firmware (1.64). it fixes an issue where netboot installs are failing (and its blocking boot speed testing) [20:29] skaet, we'll just need to make sure its been built before we respin the ISOs [20:29] skaet, by we I mean, I'm asking that they get respun :) [20:30] patrickmw, I was wondering.... the daily images will be kicking off by the cron job in the next couple of hours. Any reason we can't wait for those? [20:30] :) [20:31] patrickmw: netboot != isos; what's the issue that was being fixed, exactly? [20:31] skaet, can we be more exact on how long? teams are waiting for boot speed test results on those systems. [20:31] slangasek, ah ok. bad wording [20:32] well, not just bad wording - if this is actually about netbooting, you need a different fix, unrelated to the ISOs :) [20:32] "Add all rtl_nic firmware files to nic-firmware" [20:32] patrickmw: you're pxe booting, right? [20:33] slangasek, yes. but I'm using the daily image as my mirror [20:34] patrickmw: that's not the issue - you need a fix so that the firmware is *in* the image you're pxe booting [20:34] nic-firmware is part of the pxe image, and you need to have the right version in it [20:34] so what we need here is a respin of the debian-installer package [20:34] slangasek, let me get rtg involved. he can explain it better than I [20:36] * slangasek waves to tgardner [20:36] patrickmw, yo [20:36] tgardner, hey [20:36] slangasek, I added all of the rtl_nic file this time. [20:37] tgardner: yep, thanks :) so I was just saying to patrickmw that what we need in order to get the nic-firmware where it's useful to him is a respin of the debian-installer package [20:37] which I'll address as soon as I see that linux-firmware 1.64 is published [20:37] slangasek, ok, but it'll take a few minutes for the fresh upload to propagate. [20:37] indeed [20:38] it will in fact take an hour from now [20:39] none of this requires changes to the ISO build schedule though; the only copy of nic-firmware that matters for the netboot case is the one in the pxe image itself, and that's all debian-installer [20:39] right, a turn of the publisher crank [20:41] * skaet nods [20:57] slangasek, we don't use netboot, we use the ISO and extract the kernel/initrd for the pxe setup via cobbler [20:58] pgraner: from which ISO? [20:58] slangasek, the daily [20:59] the daily alternate, desktop, or server? [20:59] slangasek, alternate [20:59] patrickmw, correct me if I'm wrong [21:00] pgraner: ok... that initrd is still generated via debian-installer, so the d-i respin is still needed [21:00] given that we publish pxe images for the installer in the archive, maybe it would be better to use those? Shortens the dependency chain [21:03] slangasek, ok didn't realize those were there [21:04] http://archive.ubuntu.com/ubuntu/dists/precise/main/installer-i386/current/images/netboot/ [21:04] (or installer-amd64) [21:05] slangasek, how often to those get regenerated ? [21:09] slangasek, pgraner: I didn't either. I can try using those and make sure we get the desired result. The important that is that we install the package versions that would be on the ISO and not just latest version (althought that will be the case at times.) [21:10] thats a good reason for the ISO 'cause the archive image may skew wrt the ISO [21:11] tgardner: they get regenerated whenever the debian-installer package is uploaded - so each time you guys upload an ABI-changing kernel that triggers a d-i upload, plus on-demand respins (like this one) [21:12] patrickmw, Use the PXE images that slangasek referenced above then point the installer at the daily ISO [21:13] tgardner: the initrd image that's included on the ISO *also* comes from the archive; so unless you have a reason to test a specific older ISO that no longer has matching kernel bits in the archive, I think using the current pxe image would be easiest [21:13] slangasek, but the reason he's using the ISO is to chart boot speed. there may not be an ABI bump for multiple kernel versions, but the daily ISO will pick up the new kernel every day. [21:14] tgardner: not relevant - he's not charting the speed of the installer booting [21:14] but he is charting the speed of the kernel on the ISO [21:14] tgardner, we boot, install, reboot, reboot & chart, copy results [21:14] pxe boot the installer, do an automated install - which pulls the current kernel from the archive (which in this case is the ISO), boot that, chart [21:15] the only case where skew between the pxe-booted kernel and the kernel on the ISO can *possibly* hurt is if the pxe image itself doesn't have the drivers needed in order to find the hardware you're installing to [21:17] so if there's been a kernel ABI update, d-i is respun, and the ISO is not yet respun, it'll fail because it can't find the disk drivers [21:18] I think the easy answer there is to wait until the ISO is respun to match d-i, though? [21:18] I guess I don't see the advantage. He's gotta have the ISO anyways, why not just build the netboot from it. that way we _know_ there is no skew. [21:19] it's no skin off my nose if he does [21:19] it just makes a longer dependency chain when something needs fixing in the boot sequence [21:20] yeah, its not really my problem either :) I'll let patrickmw deal with it. [21:20] slangasek, tgardner, personally I don't care, but I need this working [21:21] pgraner, you should have it as soon as the publisher has run and the ISO is respun. couple of hours ? [21:22] pgraner, skaet: looks like linux-firmware is published [21:22] tgardner, I know I was saying that in frustration [21:23] tgardner: it's "published", not published; it has to be visible on the mirror before I pull the trigger on debian-installer [21:25] * skaet nods [21:53] debian-installer uploaded [23:23] regarding the discussion earlier, it indeed sounds like it makes absolutely no sense to use the image on the ISO. It means you have to wait longer for fixes for no benefit [23:51] Regarding ben: I think it'll make future merging easier if we keep configs and code separate [23:53] fine by me [23:53] I'm setting up a project and a vcs import of collab-maint/ben.git now [23:59] hope to finish the merge tomorrow, at which point I'll need help re-cronning [23:59] ok [23:59] bonsoir