| === ppisati_afktmux is now known as ppisati | ||
| didrocks | kirkland: FYI, I uploaded a powernap fix for the upstart override ^ | 07:33 |
|---|---|---|
| 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:22 |
| sil2100 | The agreenment was that every binary package addition/rename (I think) needs approval from the archive admins | 11:23 |
| 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:25 |
| * 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:26 |
| 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/ | 11:27 |
| === doko_ is now known as doko | ||
| kirkland | didrocks: thanks! | 15:08 |
| kirkland | didrocks: I'm still having some some systemd problems with dotdee, which isn't installing | 15:08 |
| === bjf is now known as b_j_f | ||
| 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:41 |
| bdmurray | arges: I don't see anything obvious for either issue | 17:46 |
| arges | bdmurray: hmm... should I just manually comment to verify? | 17:47 |
| bdmurray | arges: all the other SRU bugs are getting updated right? | 17:47 |
| arges | bdmurray: yea others ones are working fine so far | 17:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| arges | dannf: yea so adding the L-B-F was the only obvious thing I saw | 17:59 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:14 |
| 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:15 |
| infinity | ScottK: Or, I could put my foot down, which I'm doing. | 18:18 |
| ScottK | I like that option better. | 18:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| infinity | Anyhow, commented on the bug, we'll see where it goes. | 18:26 |
| infinity | Riddell: Erm. Since when does KDE own the generic-looking /usr/share/doc/HTML namespace? | 18:42 |
| infinity | Riddell: That looks entirely wrong. | 18:43 |
| Riddell | infinity: that's the upstream default in kde frameworks 5, it's been agreed with debian to use that | 18:46 |
| 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:47 |
| 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:49 |
| infinity | I don't suppose you can s/common/kdelibs5-data/ and have it still work? | 18:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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. :/ | 18:54 |
| infinity | mdeslaur: You sure seem to be enjoying tiff this week. | 19:16 |
| mdeslaur | infinity: *&*("?" PoS | 19:17 |
| infinity | mdeslaur: But how do you really feel? | 19:17 |
| mdeslaur | irc needs emoji | 19:17 |
| * mdeslaur makes all the neckbears cringe | 19:18 | |
| mdeslaur | neckbeards | 19:18 |
| === sturmflut__ is now known as sturmflut | ||
| 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:57 |
| 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 | 19:58 |
| dannf | arges: can you reject the utopic ones too? | 20:01 |
| arges | dannf: done | 20:01 |
| dannf | ta | 20:01 |
| arges | dannf: all set? I'll re-review those packages then | 20:35 |
| dannf | arges: yeap, thx | 20:35 |
| === b_j_f is now known as bjf | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!