[09:12] infinity, Yo [09:15] infinity, When the Baseline drops? [09:15] Yes, I am continuing to troll infinity with song titles. [13:29] https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1553176 <-- I wonder if that's worthy of an SRU in trusty (prolly) [13:29] Launchpad bug 1553176 in bind9 (Ubuntu) "BIND ignores nanoseconds field in timestamps, fails to load newer versions of zones on reload" [High,Confirmed] [13:30] only affects instances where the DNS is updated more than once per second... [13:38] lamont: seems reasonable if MAAS wants it. [13:39] fact [13:39] I'll get back to you on that... [14:23] mythbuntu and edubuntu will release in 16.04 LTS, right? [14:23] * xnox is editing the release notes. [14:25] * smb just read "eating" instead of "editing" ... and he already had lunch... [14:28] they are about as useful for eating :) [14:43] Hi, i have a FFe for LP: #1549763 to sync a new (to xenial) package from debian, provided I find an archive admin to review it. Should I subscribe ubuntu-archive to the bug, or do I sync the package? [14:43] Launchpad bug 1549763 in trilinos (Ubuntu) "FFe: Sync trilinos 12.4.2-2 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/1549763 [16:05] ginggs, ^ [16:20] infinity, Base Things? [17:07] xnox: thanks! [20:43] cjwatson: on -signed packages, is there a way for the archive to make a distinction if the efi binaries changed from one version to another and not require a new -signed package with every upload if the efi binaries are identical? [20:44] eg an upload for 0.5-1 is there, -signed gets uploaded and they both move out of proposed. 0.5-2 gets uploaded but fixes something unrelated to EFI binaries that 0.5-1 made, so not have to upload -signed package again [20:48] superm1: It has nothing to do with the archive; the -signed packages have tight dependencies. In order to loosen the dependencies, the -signed packages would have to be clairvoyant, I think. [20:49] yeah i suppose that makes sense when I give it more thought :/ [20:49] superm1: There is one possibility I can think of: instead of depending on a tight version, we could hash the EFI binaries (somehow) and use the hash to compute a Provides field; the -signed packages could then depend on that. [20:49] superm1: Implementation is left as an exercise for the reader. :-) [20:52] cjwatson: Ah I like that idea. does anything do any filtering of custom Provides that I'd need to worry about if I tried to come up with something? [20:55] ah, I like that idea [20:55] superm1: one thing comes up to mind though, infinity wanted to sync the code to download the signed binaries across all the -signed packages [20:56] IIRC the right source was the linux-signed package, and others should use the same scripts [20:56] cyphermox: like have one -signed source package that generates all the -signed packages at once? [20:56] no [20:56] but at least use the same version of the scripts across all packages, some do things others don't [20:57] (not that there is very much to do really) [20:57] oh i see [20:57] I'd really discuss this with infinity again, perhaps between the three of us we can come up with something solid [20:58] (or maybe I just misunderstood completely ;) [20:59] superm1: did you need a new build of some signed package now? otherwise would you have time for a hangout on monday or something? [20:59] superm1: No, this is based on the approach that Haskell and Ocaml use so I know it works in theory. [21:02] cyphermox: i just uploaded fwupdate-signed so that it could transition as part of the MIR that was just approved for fwupdate*. i'm traveling the next 2 weeks in an opposing timezone in a country that hates google, probably wouldn't be able to hop on a hangout easily during that time, sorry [21:02] ok [21:02] well, IRC is just as fine though :) [21:03] Yeah. ping me at some point when you guys chat and if i'm around i'll comment, otherwise i'll look at what you guys decide upon and make any appropriate changes for fwupdate-signed to match what you do for grub, shim and linux -signed [21:03] ok [21:04] I really like the hashing idea, I'll run a few tests with shim here [21:26] The hash dep could work indeed, assuming reproducible builds. [21:27] Though, to be fair, the "reupload -signed" bit isn't exactly onerous for anything other than shim, which needs a turnaround step with Microsoft. And that one's done by hand, so we could as easily be checking the hash ourselves there. [21:27] shim's the unique snowflake because of that. [21:29] The bigger concern isn't slow migration in the devel series, it's the inevitable bollocksing of SRUs until we get britney driving that process end-to-end. [21:29] cjwatson: We really need to sit down and see how close we are to being able to do that. [21:30] cjwatson: Possibly less you and more pitti, since the blocker is/was probably too many adt failures to deal with.