[06:25] <tai271828> hi, I noted desktop current download url is outdated. It provides the link to download xenial-desktop-amd64.iso (timestamp Mar. 3rd) instead of the one with timestamp Mar. 16  http://cdimage.ubuntu.com/ubuntu/daily-live/20160316/
[11:29] <ginggs> Anyone from ubuntu-archive able to look at removing wine1.6 please? LP: #1558480
[11:29] <ubot5> Launchpad bug 1558480 in wine1.6 (Ubuntu) "remove wine1.6 package" [Undecided,Confirmed] https://launchpad.net/bugs/1558480
=== s8321414_ is now known as s8321414
[13:00] <Odd_Bloke> Could someone accept ^, pretty please?
[13:20] <apw> Odd_Bloke, your previous build also threw a 'make: py3versions: Command not found' is that resolved in this one ?
[13:21] <Odd_Bloke> apw: It is not; let me address that.
[13:23] <apw> Odd_Bloke, also you seemed to have some extraneous change in d/control though just whitespace
[13:25] <infinity> Removing whitespace from control is a good thing.
[13:25] <Odd_Bloke> apw: That whitespace was added in ...~12.04.1, so I was just cleaning it up; is that a problem?  (First time actually uploading a package myself, so apologies if I'm beeing a noob :p)
[13:25] <apw> Odd_Bloke, no that sounds good then
[15:14] <rbasak> ^^ src:mysql-5.7, FFe bug 1528583. There will be new binaries too (s/5.6/5.7/ and a libmysqlclient soname bump)
[15:14] <ubot5> bug 1528583 in mysql-5.6 (Ubuntu) "[FFe] Please update to MySQL 5.7 series" [Wishlist,In progress] https://launchpad.net/bugs/1528583
[15:26] <rbasak> infinity: ^^ if you don't mind please.
[15:32] <infinity> rbasak: Oh fun, a libmysql transition too?
[15:33] <infinity> rbasak: Are you taking ownership of the transition, or hoping someone from Foundations takes pity on you and does it?
[15:34] <infinity> rbasak: (please answer the former)
[16:13] <andyrock> Laney Trevinho https://bugs.launchpad.net/unity/+bug/676457
[16:13] <ubot5> Launchpad bug 676457 in unity (Ubuntu Xenial) "[FFe] Launcher - Add 'launching' state to launcher icons" [Medium,In progress]
[16:14] <Laney> yes I keep having other things to do, sorry
[16:14] <Laney> It would be good if someone else on the release team would look
[16:28] <rbasak> infinity: I'll take care of it.
[16:28] <rbasak> infinity: I did point it out in the bug. I thought that's what you were acking.
[16:28] <infinity> rbasak: I must have missed that bit.
[16:30] <rbasak> The ABI bump is mainly because they cleaned up symbols that shouldn't have been exported in the first place.
[16:30] <rbasak> No API-level changes are intended.
[16:34] <infinity> rbasak: So just a mess of rebuilds, hopefully.
[16:35] <infinity> rbasak: I'll try to get to the new source sometime today, so we can attempt to get the rebuild madness done over the weekend.
[16:38] <rbasak> infinity: yes. OK, thanks!
[16:44] <rbasak> infinity: BTW, you'll probably notice https://anonscm.debian.org/cgit/pkg-mysql/mysql-5.7.git/commit/?h=rbasak&id=32cf55d6aaed56b65a68cd07364e1bbd5d1dc3a6
[16:44] <rbasak> I'm not sure what to do about that, although upstream (who provided it) pointed out that it's like that in libboost-dev also.
[16:45] <rbasak> I figured that we're not making it any worse. Perhaps a bug against libboost-dev would be appropriate. Not that it's their problem since we're duplicating the headers, but might as well fix it the same way.
[16:45] <infinity> xnox: WTF, mate, why is boost's copyright empty? :P
[16:46] <xnox> Hahahaha =)
[16:46] <xnox> infinity, did i do the last upload as well?! =)
[16:47] <rbasak> infinity: oh and https://anonscm.debian.org/cgit/pkg-mysql/mysql-5.7.git/log/?h=ubuntu/devel might be helpful to you generally if you want to follow packaging changes, as it's a ridiculously big diff otherwise.
[16:47] <infinity> rbasak: Oh, it's a bit more complicated than that.
[16:47] <infinity> Files: *
[16:47] <infinity> Copyright:
[16:47] <infinity> License: Boost
[16:47] <infinity>  This software is a collection of libraries from the Boost.org site.
[16:47] <infinity>  Most of the libraries use the Boost Software License 1.0, which
[16:47] <infinity>  reads as follows.
[16:47] <infinity> ...
[16:47] <rbasak> "Most"
[16:47] <infinity> rbasak: Yes, and then specific ones are listed later.
[16:48] <infinity> rbasak: So, yeah, it might be nice if the license was actually checked properly and specified for whatever's bundled.
[16:49] <infinity> rbasak: (Alternately, stop bundling and use the system boost?  But I'm guessing theirs is forked somehow)
[16:49] <rbasak> I suspect that upstream's taking just a subset and so they may say that the current file is accurate, but I'll check.
[16:49] <rbasak> They want to lock the version of Boost IIRC, and it's only the headers they need.
[16:50] <rbasak> (for the lifetime of 5.7)
[16:50] <rbasak> I think we discussed this?
[16:50] <rbasak> I checked with someone, anyway.
[16:50] <Skuggen> rbasak: o/
[16:50] <rbasak> Skuggen: infinity was asking about debian/copyright for Boost.
[16:52] <Skuggen> Yeah?
[16:52] <rbasak> Skuggen: http://paste.ubuntu.com/15408607/
[16:52] <rbasak> Skuggen: line 43
[16:53] <Skuggen> Yeah
[16:54] <Skuggen> We bundle boost because 5.7 requires 1.59. System version all over is 1.58
[16:54] <Skuggen> But also because we want to lock it down in case future updates causes issues
[16:54] <rbasak> Right
[16:54] <Skuggen> The copyright field is empty because there are a huge number of contributors to boos
[16:54] <Skuggen> boost*
[16:55] <rbasak> But separate from that infinity was querying the licensing.
[16:55] <rbasak> Anyway
[16:55] <rbasak> Skuggen (upstream) will do what infinity requests. So I'm just trying to get out of the middle :)
[16:56] <rbasak> BTW, we want to upload the same thing to Debian experimental. If that's relevant.
[16:56] <rbasak> Debian ftpmasters will have a view on this too.
[16:56] <Skuggen> Yeah, I left it empty on the assumption that since it's empty in libboost, that's ok
[16:59] <infinity> Skuggen: "Copyright" is empty in libboost, but the license isn't.
[17:00] <Skuggen> Wait, is the license empty?
[17:00] <Skuggen> It shouldn't be
[17:00] <Skuggen> Ah, the license text
[17:01] <infinity> Skuggen: Yeah, it's only valid to have empty license text if the license is shipped in common-licenses.
[17:01] <infinity> Which boost isn't.
[17:01]  * rbasak thinks he sees a license text.
[17:01] <rbasak> What am I missing?
[17:01] <rbasak> https://anonscm.debian.org/cgit/pkg-mysql/mysql-5.7.git/commit/?h=rbasak&id=32cf55d6aaed56b65a68cd07364e1bbd5d1dc3a6
[17:01] <rbasak> Short name Boost, full text at the bottom.
[17:01] <rbasak> Unless of course it's wrong.
[17:06] <infinity> rbasak: Oh!
[17:06] <Skuggen> rbasak, infinity: I'm looking at the copyright file for libboost
[17:06] <infinity> rbasak: I should learn to scroll.
[17:06] <infinity> Skuggen: So, uhm.  Nevermind.
[17:06] <Skuggen> It has a couple of exceptions from the default boost license, but only for files we don't bundle
[17:06] <Skuggen> Ah :D
[18:22] <superm1> can someone release fwupdate from unapproved again?  also why does it keep getting put there?
[18:40] <slangasek> superm1: because there's a signed efi binary artifact, which requires archive admin oversight
[18:40] <superm1> ah gotcha
[18:41] <superm1> so grub and shim go through the same thing then each time
[18:41] <slangasek> yes
[18:44] <superm1> related question - how is the signed fwupdate EFI binary going to be installed in xenial?  should this be something that happens from installer like happens with grub or should it be seeded and part of the livefs to start?
[18:46] <slangasek> superm1: I think the expectation is that it would be seeded; I saw something about that in an MIR bug, but it seems only fwupdate was seeded so far, not fwupdate-signed
[19:00] <superm1> OK, i'll make some relevant seed changes for that
[19:44] <cyphermox> yes, things will need fwupdate-signed too now, possibly should depend on that rather than fwupdate
[19:44] <cyphermox> superm1: that means perhaps it would be good to add a package that depends on the right fwupdate-$arch-signed per-arch
[19:44] <cyphermox> so one can just depends on fwupdate-signed
[19:46] <cyphermox> hrm, or Provides ;)
[19:46] <superm1> cyphermox: yeah i was about to  say that sounds like Provides would be better
[19:47] <superm1> although it's not clear to me that UpdateCapsule is really useful anywhere but amd64
[19:47] <cyphermox> anyway, something prettier than having seeds depend on different named packages on different architectures, if it's avoidable
[19:47] <superm1> at least I haven't heard of anything using that on arm yet
[19:47] <cyphermox> superm1: in theory EFI is EFI; even if no arm boards don't have it, they eventually will
[19:47] <cyphermox> I suppose we can burn that bridge when we get there ;)
[19:48] <superm1> that's true, if the binary is building may as well get it all packaged up nicely
[19:52] <cyphermox> hrm, it's really not that easy
[19:52] <superm1> cyphermox: i don't see any raw uefi archives for any of the arm builds on the archive, something special needed for them?
[19:53] <cyphermox> we shouldn't install fwupdate-signed on non-EFI amd64.
[19:53] <superm1> oh no ESP, that's true
[19:53] <cyphermox> uefi for arm: I don't know
[19:53] <superm1> makes me think that it should actually get installed by grub-installer
[19:54] <cyphermox> I lied, I know
[19:54] <cyphermox> http://ports.ubuntu.com/dists/xenial/main/uefi/
[19:55] <superm1> oh not published in archive.*, ports.* ok..
[19:55] <cyphermox> superm1: I'm not sure grub-installer is the right place for it
[19:55] <cyphermox> I mean, fwupdate is not grub.
[19:58] <superm1> you won't actually know if it's an EFI system until you get to install time, so i'd think you either need it seeded in the image and pull it out if you're not an EFI system or don't seed it in the image but add it at install time
[19:59] <cyphermox> of course
[19:59] <cyphermox> but you maybe want to have lilo or $random_other_bootloader to boot in EFI and still use fwupdate, even if it's not something we officially support in ubuntu.
[20:00] <cyphermox> grub-installer is probably the easiest, immediately obvious place one could add fwupdate-signed; but it's probably not the best
[20:01] <superm1> does d-i give an option to use other bootloaders?  if not, then someone would have to install with grub, install some other bootloader and remove grub still
[20:01] <cyphermox> d-i have other $bootloader-installer(s)
[20:01] <cyphermox> s/have/has/
[20:02] <superm1> oh.  i guess you could argue if someone is wandering down that path with something other than grub they probably don't want the signed fwupdate anyway though
[20:02] <superm1> because they'd have to worry about signing the other bootloader themselves
[20:02] <superm1> and then at that point they'll have to sign their own fwupdate anyway
[20:04] <cyphermox> maybe what we really want for this is some kind of 'fwupdate-installer', that runs iif you're in efi *and* you have some ESRT
[20:06] <cyphermox> (at least, for d-i. desktop would probably best have the package installed on the image, and removed if !(efi && esrt)
[20:08] <superm1> once the MIR is done for fwupd and FFE is done for gnome-software i'd expect that fwupdate is going to end up on systems whether you have efi or not and ESRT or not
[20:09] <superm1> the other interesting thing is it's possible to turn on ESRT for some systems that have it off already, so that's not the right toggle to look at  (https://github.com/rhinstaller/fwupdate/commit/3b08a1622e92c3a9c42f6773214dc3f41f13484b)
[20:09] <cyphermox> yeah, we should fix that. that's up to ubiquity to figure out whether you're on efi or not
[20:09] <cyphermox> I could live with the toggle being just "are we in EFI"
[20:12] <infinity> cyphermox: Isn't that how we already choose to keep grub-signed/linux-signed?
[20:12] <infinity> cyphermox: We don't require you to be in SB mode, for instance (I hope).
[20:13] <cyphermox> infinity: moo?
[20:13] <infinity> Since that would explode if you were in setup mode for install and then rebooted and enabled SB.
[20:13] <infinity> Moo!
[20:13] <infinity> cyphermox: Refering to 'I could live with the toggle being just "are we in EFI"'
[20:13] <superm1> ok if that's the approach to go with, the way to go about this i'm thinking is add a Provides: fwupdate-signed, seed it so ends up in the pool on install media and then somewhere in ubiquity (plugininstall.py?) mark fwupdate-signed for installation if you're in EFI
[20:14] <cyphermox> infinity: oh, right. but in the case of SB, we know it can be toggled, and we still do check for EFI
[20:15] <cyphermox> infinity: I didn't remember you could toggle firmware updates
[20:15] <infinity> Does fwupdate{,-signed} somehow do bad things if your firmware isn't in the right mode or doesn't provide the right interface?
[20:15] <superm1> no it doesn't
[20:15] <cyphermox> it just won't do anything
[20:15] <infinity> If it's just dead code, then I say we just install for all EFI and be done with it.
[20:16] <cyphermox> infinity: the question is more "do we want to install fwupdate-signed in grub-installer", and my initial reaction was "probably not, there ought to be another way"
[20:16] <cyphermox> the install for all efi part is easy enough in ubiquity if it's already on the image, and just a little bit more complicated for straight d-i installs
[20:16] <infinity> cyphermox: Its own installer package might be better for d-i flexibility reasons indeed.
[20:17] <infinity> It would be trivial.
[20:17] <cyphermox> right
[20:18] <cyphermox> well I can cook one later, when I'm done with the upgrade things. or superm1 if you want to play with d-i ;)
[20:20] <infinity> Anyhow, for the desktop case, you can just seed it to -live and worry about the removal bit.
[20:20] <infinity> And that seems entirely doable for beta.
[20:20] <infinity> d-i would be a nice bonus, though.
[20:21] <cyphermox> yep
[20:21] <cyphermox> the removal part is in scripts/install.py and scripts/plugininstall.py in ubiquity
[20:39] <superm1> cyphermox: okay i uploaded fwupdate-signed 1.8 which should do packages all the others archs uefi packages now too and work with a Provides fwupdate-signed.  once AA clears fwupdate* that from the queues (unapproved and NEW) i'll seed that in -live
[20:47] <cyphermox> cool
[21:52] <lamont> who is my favorite AA today?  please NEW bind9, kthx
[21:54] <infinity> lamont: Do you have a favourite?
[21:54] <lamont> you know you're always my favorite
[21:55] <lamont> we had to add libisccfg-exportNNN
[21:55] <lamont> and udeb
[21:56] <lamont> and once _that_ lands, then I'll upload isc-dhcp, and we can have a party
[21:59] <infinity> lamont: Waiting on armhf to be done.
[21:59] <lamont> doh.
[21:59] <infinity> lamont: I assume you tested all of this somehow?
[22:00] <lamont> lets go with "yes"
[22:00]  * teward raises an eyebrow
[22:00] <lamont> meanwhile, I'll confirm the CVE fixes
[22:01] <lamont> infinity: your conditions are acceptable :/
[22:03] <lamont> infinity: give me about 15 min and I will have reconfirmed that
[22:25] <lamont> infinity: reconfirmed. it's all been tested and retested
[22:31] <lamont> infinity: and all pending publication
[22:31] <lamont> and e'rything
[22:31] <infinity> lamont: Ta.
[22:33]  * lamont fiddles rome untiul he can upload isc-dhcp
[22:46] <lamont> isc-dhcp uploaded
[22:46] <lamont> infinity: ta
[22:47] <infinity> lamont: I feel like you may have jumped the gun on that upload...
[22:47] <infinity> lamont: Unless it'll appropriately dep-wait.
[22:49] <infinity> Which I don't think it will...
[22:50] <infinity> Oh.  It will, because libbind-export-dev isn't in xenial.  Check.
[22:53] <lamont> infinity: and it showed as published... not pending.
[22:53] <lamont> but yeah, sihg
[22:56] <infinity> lamont: LP lies.
[22:57] <infinity> lamont: But the dep-wait works, so we're good.  I was about to cancel them all in a panic.
[22:58] <lamont> worst case would have been a build1, but yeah
[22:59] <lamont> I will remember that it lies
[22:59] <infinity> lamont: rmadison is your friend in this case.
[22:59] <slangasek> tumbleweed: hi, do you still maintain https://code.launchpad.net/~stefanor/+junk/reverse-deps -> http://qa.ubuntuwire.org/rdepends ? I have a feature request
[23:00] <infinity> lamont: LP records it as "published" when it starts smacking it on disk on ftpmaster, which is long before dists is updated.
[23:17] <tumbleweed> slangasek: put it this way, nobody else does :)
[23:17] <slangasek> heh
[23:17] <tumbleweed> so, if it's a simple feature request, sure
[23:17] <tumbleweed> otherwise, patches welcome
[23:17] <slangasek> tumbleweed: but how can I submit patches it's a junk branch!
[23:17] <slangasek> tumbleweed: the request is that it would be really nice if the reverse-depends command showed when there were alternative deps
[23:17] <tumbleweed> yeah
[23:18] <tumbleweed> so, it doesn't track whether a dep is alternate or not
[23:18] <tumbleweed> this probably means a protocol change
[23:18] <slangasek> I was figuring it could be shoved into the depends field
[23:19] <slangasek> i.e. instead of "Dependency": "openjdk-7-jre-headless", it could just say "Dependency": "openjdk-7-jre-headless | default-jre" - no protocol change
[23:23] <tumbleweed> hrm, that'd work