=== ppisati_afktmux is now known as ppisati
[07:33] <didrocks> kirkland: FYI, I uploaded a powernap fix for the upstart override ^
[11:22] <sil2100> Hello! I would need an archive admin +1'ing a version bump of media-hub packages
[11:22] <sil2100> https://ci-train.ubuntu.com/job/ubuntu-landing-023-2-publish/lastSuccessfulBuild/artifact/media-hub_packaging_changes.diff/*view*/ <- here is the CI Train packaging diff
[11:22] <sil2100> It basically renames libmedia-hub-common2, libmedia-hub-client2 to libmedia-hub-common3, libmedia-hub-client3
[11:23] <sil2100> The agreenment was that every binary package addition/rename (I think) needs approval from the archive admins
[11:25] <ogra_> sil2100, i'd ACK it ... but thats from my team :)
[11:25] <ogra_> looks totally sane though
[11:25] <cjwatson> ogra_: but you aren't in ~ubuntu-archive
[11:25] <ogra_> oops
[11:25] <ogra_> yeah
[11:25] <cjwatson> sil2100: diff looks OK but I prefer to check the actual generated binaries; doing that now
[11:26]  * ogra_ totally missed the channel :)
[11:26] <cjwatson> and yes, any package whose name wasn't previously in the archive requires approval, not inclined to change that.  hopefully we'll get the LP bug fixed soon that gives you a backdoor here
[11:27] <sil2100> :)
[11:27] <sil2100> cjwatson: thanks!
[11:27]  * sil2100 waits for the final ACK
[11:27] <cjwatson> sil2100: looks fine, go ahead
[11:27] <sil2100> Thanks again o/
=== doko_ is now known as doko
[15:08] <kirkland> didrocks: thanks!
[15:08] <kirkland> didrocks: I'm still having some some systemd problems with dotdee, which isn't installing
=== bjf is now known as b_j_f
[17:41] <arges> bdmurray: infinity: hey I just accepted this into -proposed: https://launchpad.net/ubuntu/+source/grub-installer/1.78ubuntu23.1 for bug 1435663, but for some reason rmadison isn't showing it in -proposed, nor did sru-review update the bug appropriately. What got screwed up?
[17:41] <ubot93> bug 1435663 in partman-efi (Ubuntu Utopic) "arm64/efi support" [Undecided,In progress] https://launchpad.net/bugs/1435663
[17:46] <bdmurray> arges: I don't see anything obvious for either issue
[17:47] <arges> bdmurray: hmm... should I just manually comment to verify?
[17:47] <bdmurray> arges: all the other SRU bugs are getting updated right?
[17:48] <arges> bdmurray: yea others ones are working fine so far
[17:49] <bdmurray> arges: did the tab open for bug 1435663 when you were reviewing it?
[17:49] <ubot93> bug 1435663 in partman-efi (Ubuntu Utopic) "arm64/efi support" [Undecided,In progress] https://launchpad.net/bugs/1435663
[17:49] <infinity> arges: The rmadison thing is a lack of patience.  No idea about the bug comment.
[17:50] <arges> bdmurray: no the tab did not open, but I already had the bug open due to the previous package and the bug comment looked well formed
[17:50] <arges> infinity: ack. I'll wait it out a bit
[17:51] <infinity> arges: If you look at https://launchpad.net/ubuntu/+source/grub-installer/1.78ubuntu23.1/+publishinghistory it's pending.
[17:51] <arges> ah didnt know about +publishinghistory that's pretty useuful
[17:51] <bdmurray> arges: ah, then for some the .changes file is mising Launchpad-Bugs-Fixed
[17:51] <bdmurray> s/some/some reason/
[17:51] <infinity> arges: It's linked from the page you linked to us. :P
[17:52] <infinity> arges: Directly above the builds, where you'd expect to see which pockets/releases it's in.
[17:52] <arges> 'View Publishing History' cool
[17:52] <bdmurray> https://launchpadlibrarian.net/201141747/grub-installer_1.78ubuntu23.1_source.changes
[17:52] <arges> and there it is in rmadison
[17:52] <bdmurray> ^- No L-B-F
[17:53] <arges> bdmurray: ok in the cases where there isn't a bugs-fixed should it be re-uploaded with that corrected?
[17:53] <infinity> Tell dannf to stop preparing his uploads on a Debian system. :P
[17:54] <bdmurray> arges: I think so, a fair number of things look for that
[17:54] <arges> ok i'll ask for a re-upload of those packages with proper LBF, and ask they be done in a proper Ubuntu schroot for that release etc
[17:55] <arges> bdmurray: infinity thanks guys
[17:55] <dannf> arges: infinity: ah - didn't know that broke things, sorry
[17:55] <infinity> arges: I'm not sure a reupload is worth it now that they're accepted.
[17:55] <arges> infinity: i think some of the other packages in that bug may have the same issue, need to check it
[17:55] <dannf> arges: all of them probably do - that's where i sign things
[17:56] <infinity> arges: Yeah, for the ones already in the archive, a no-op upload isn't worth the effort just to make some computers happier.  Humans can sort out if the bugs don't auto-close, etc.
[17:56] <arges> infinity: makes sense
[17:56] <infinity> dannf: genchanges on Ubuntu, scp to Debian and sign?
[17:57] <arges> dannf: libdebian-installer for trusty/utopic needs to be re-done
[17:57] <dannf> infinity: yeah, easy to do, just not something i knew was better
[17:57] <infinity> We don't actually carry changes to dpkg-genchanges, I'm wondering what this keys off of.
[17:57] <infinity> Probably dpkg-vendor.
[17:57] <arges> dannf: partman-auto for trusty/utopic too
[17:58] <arges> dannf: and partman-efi for trusty/utopic
[17:58] <infinity> Oh, in fact, LP-B-F only happens in Dpkg/Vendor/Ubuntu.pm
[17:58] <infinity> So, that explains that.
[17:58] <arges> dannf: i'll hold off on that for a bit and look at it after lunch
[17:58] <infinity> dannf: Yeah, do all your source package building on Ubuntu. :)
[17:58] <dannf> arges: is the "re-done" for L-B-F or something else?
[17:59] <arges> dannf: yea so adding the L-B-F was the only obvious thing I saw
[18:10] <arges> infinity: bdmurray : the other thing to ask (while you're here) is there some sort of MAAS Macro release Exception discussion I missed? looks like andreas wants to slam 1.7 into utopic/trusty
[18:11] <infinity> arges: There's a discussion ongoing, but no formal exception yet, so that one will be reviewed as a normal SRU.
[18:11] <arges> bug 1438428 <- seems really risky with all the changes (people will have to re-import images etc)
[18:11] <ubot93> bug 1438428 in maas (Ubuntu Utopic) "[SRU] New upstream Release 1.7.2" [Undecided,New] https://launchpad.net/bugs/1438428
[18:12] <ScottK> Since when did really risky stop Maas?
[18:12] <infinity> arges: Or, rather, we'll review the 1.7->1.7.2 in utopic as a normal SRU, then verify that the backport to trusty looks vaguely sane, then they'll dilver a ton of testing to prove said sanity.
[18:14] <infinity> arges: Not happy about the "users will have to do manual things to upgrade" bit, though. :/
[18:14] <arges> Ok I'll skip it for now since there is ongoing discussion
[18:15] <ScottK> infinity: Isn't that normally a show stopper?
[18:15] <infinity> ScottK: It should be, yes.  I'll bring it up with them in said ongoing discussion.
[18:15] <ScottK> I sometimes feel like we might as well change the SRU rules to "Meh, whatever".
[18:18] <infinity> ScottK: Or, I could put my foot down, which I'm doing.
[18:18] <ScottK> I like that option better.
[18:19] <infinity> ScottK: The "new maas upstream versions in LTSes" was sabdfled, but only on the condition that the maas team met a set of requirements laid out by the TB and SRU people.  That's not happening here.
[18:20] <ScottK> I don't suppose there's anything that can be done to align their development schedule to the distro development schedule.
[18:20] <ScottK> It'd be nice to have one release without last minute Maas related flails.
[18:20] <ScottK> (i.e. plan on delivering the features before feature freeze)
[18:21] <arges> infinity: if it does break imported images etc, could we request a debconf prompt be added to let the user know how their system will break?
[18:22] <arges> or is that pretty pointless
[18:22] <infinity> ScottK: To be fair, their changes in vivid have been pretty sane, and not massive feature work.  It's the SRUing it back to trusty bit that's problematic.
[18:22] <ScottK> OK.
[18:23] <infinity> arges: If there's literally no other way out of it, angry user prompts might help.  But that's hardly the ideal.
[18:23] <ScottK> I thought I recalled seeing a standing FFe request from them.
[18:23] <arges> yea
[18:23] <infinity> arges: You'd think people familiar with the old and new data models could migrate from A to B for the user.
[18:23] <ScottK> arges: That's an abuse of debconf.  It's not a notification system.
[18:23] <infinity> NEWS.Debian is the right place for that, but it's still wrong.
[18:26] <infinity> Anyhow, commented on the bug, we'll see where it goes.
[18:42] <infinity> Riddell: Erm.  Since when does KDE own the generic-looking /usr/share/doc/HTML namespace?
[18:43] <infinity> Riddell: That looks entirely wrong.
[18:46] <Riddell> infinity: that's the upstream default in kde frameworks 5, it's been agreed with debian to use that
[18:47] <infinity> Riddell: ... seriously?
[18:47] <infinity> usr/share/doc/HTML/en/common/2.png <-- That's pretty horrible namespace pollution that isn't obviously tied to a package or a set of packages.
[18:49] <Riddell> that becomes /usr/share/doc/HTML/en/kdoctools5-common/ in frameworks, kde4libs will go away one day but in the mean time we should be compatible with it
[18:50] <infinity> I don't suppose you can s/common/kdelibs5-data/ and have it still work?
[18:51] <infinity> If you've checked that no other packages in the world overlap, and it's going to go away Very Soon, I guess it's not world ending, but it's pretty gross.
[18:51] <Riddell> not without risking breakage
[18:52] <Riddell> the next step is to upload 300 odd kdelibs4 apps to move the docs I'm afraid
[18:52] <infinity> And not to package namespaces?
[18:53] <infinity> I note that everything in the archive currently using that namespace uses /usr/share/doc/HTML/$lang/$package, which is fine.  All except for kdelibs.
[18:53] <Riddell> it will yes
[18:54] <infinity> Okay, yeah, apt-file shows me all the old stuff is namespaced fine, assuming they just remove the "kde" from their path.
[18:54] <infinity> The common thing bugs me, but there's no overlap, so I'll get over it. :/
[19:16] <infinity> mdeslaur: You sure seem to be enjoying tiff this week.
[19:17] <mdeslaur> infinity: *&*("?" PoS
[19:17] <infinity> mdeslaur: But how do you really feel?
[19:17] <mdeslaur> irc needs emoji
[19:18]  * mdeslaur makes all the neckbears cringe
[19:18] <mdeslaur> neckbeards
=== sturmflut__ is now known as sturmflut
[19:57] <dannf> arges: so for l-d-i, partman-auto & partman-efi - did you want to reject those and have me reupload them?
[19:57] <arges> dannf: yea me reject
[19:58] <dannf> ok - will reupload proper source packages once i get the reject notifications
[19:58] <dannf> that way i can hopefully do one d-i build against proposed to verify the whole stack instead of franken-builds to verify the individual components
[19:58] <arges> dannf: ok rejected on my end
[19:58] <dannf> thx
[20:01] <dannf> arges: can you reject the utopic ones too?
[20:01] <arges> dannf: done
[20:01] <dannf> ta
[20:35] <arges> dannf: all set? I'll re-review those packages then
[20:35] <dannf> arges: yeap, thx
=== b_j_f is now known as bjf