=== cpaelzer__ is now known as cpaelzer === cpaelzer__ is now known as cpaelzer [14:01] o/ [14:02] he [14:03] cpaelzer, jamespage, joining? [14:03] o/ [14:03] yep [14:05] let's start with component mismatches [14:05] https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg [14:05] didrocks: can you do/forward alsa-lib? [14:06] doko: I will forward it [14:06] here [14:06] and I didn't look at the status of ghostscript/fonts, although cpaelzer did [14:06] doko: actually, it’s the kernel team who maintains alsa [14:07] so I guess it should be them filing the MIR [14:07] jamespage: cinder/python-tabulate ? [14:07] (looking at alsa-lib subscriber) [14:07] https://bugs.launchpad.net/ubuntu/+source/fonts-urw-base35/+bug/1862048 was waiting for a subscriber [14:07] Launchpad bug 1862048 in ghostscript (Ubuntu) "[MIR] fonts-urw-base35" [High,New] [14:07] didrocks: you said you can't do so and pinged others [14:07] has this happened? [14:07] yes [14:07] desktop-packages is sub [14:07] sorry all, late to the meeting. [14:08] Then this is ready for promotion @didrocks [14:08] will do after this meeting [14:08] I updated the bug accordingly [14:09] I'll forward apport/terminator to foundations [14:09] there are two more in te new MIR queue [14:09] and doing the licensecheck ones [14:09] https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=NEW&assignee_option=none&field.assignee=&field.subscriber=ubuntu-mir [14:09] telp / amtk - has anyone context on those? [14:10] I don’t but I’ll handle it [14:10] gedit [14:10] them* [14:11] thanks didrocks, IÄll assign you ont he bugs then [14:11] thx [14:11] Lets also look at the recently modified incomplete [14:11] so the open one is cinder/python-tabulate [14:11] whiel I fetch the Link I think Laney wanted to talk about something [14:11] Laney: around? [14:12] incomplete MIRs [14:12] https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.subscriber=ubuntu-mir [14:12] jeepeney was done alst week and needs no further action for now [14:12] this list is long [14:13] they don't auto-expire [14:13] doko: therefore - we only look at the last touched [14:13] although when in Frankfurt on the sprint we could clear out the past if all us want to do so [14:13] should be a quick everyone-nods-and-set-invalid pass [14:13] ec2-instance-connect still is disliked by me and security [14:14] but I know rbalint is working on it [14:14] anyone haveing any other MIRish topic to discuss ? [14:15] nothing here [14:15] jamespage: still here? [14:15] yep [14:16] sorry - multi-tasking never helps == multi-failing [14:16] I think there was one new security MIR added to the queue for joeubuntu's team [14:16] in the last week - masakari [14:17] filed https://bugs.launchpad.net/ubuntu/+source/python-tabulate/+bug/1862773 [14:17] Launchpad bug 1862773 in python-tabulate (Ubuntu) "[MIR] python-tabulate (dependency of cinder)" [High,Incomplete] [14:17] joeubuntu: ^^^ [14:18] masakari is in the backlog on the security team trello so its in the queue [14:18] thanks [14:19] doko: coreycb or I will pickup completion of that MIR for tabulate [14:19] IT's on the list, thanks doko [14:19] ta [14:19] anything else? [14:19] I think we are good [14:19] as I said Laney had some question [14:20] but I don't know which one, only that didrocks and I said plese get to the IRC meeting to talk about it [14:20] didrocks: do you know what it was about? [14:21] I don't at all [14:21] we have our desktop meeting in 10 min, so he should soon be around [14:21] hmm later/next time then [14:21] oh that is good [14:22] Oh FYI I won't be here next week (PTO) [14:22] see you, bye [14:22] cu [14:22] enjoy cpaelzer :) [14:25] doko: just to be clear: I’ll let you handle alsa-lib dep with the kernel team if you don’t mind [14:29] didrocks: to be clear, doing adminstrative work on a MIR doesn't have to be done just be me [14:29] now https://bugs.launchpad.net/ubuntu/+source/alsa-ucm-conf/+bug/1862776 [14:29] Launchpad bug 1862776 in alsa-ucm-conf (Ubuntu) "[MIR] alsa-ucm-conf & alsa-topology-conf (b-d of alsa-lib)" [High,Incomplete] [14:31] I don’t think filing an empty MIR really helps in moving the discussion forward with the people who need to deal with it, but probably material for discussing in Frankfurt [14:32] back here [14:32] is the meeting still going obn? [14:32] it's done [14:33] meh [14:33] but I guess you can write here, people seem still being around [14:33] yep [14:33] it's not on the fridge calendar btw [14:34] yeah ok, so there's a project going on at the minute with some of us @ canonical [14:34] basically the goal is to make the oem enablement tweaks that some hardware requires, and comes with when you buy it with ubuntu pre-loaded, also available if you buy with another OS and install Ubuntu yourself [14:35] essentially requires defining extra packages to install for different hardware [14:35] doko: jamespage: joeubuntu: ^^ highlight to make you come back to the meeting :-) [14:35] we're going to do this by including metapackages on the iso that declare what they're compatibile with, and dynamically installing them [14:35] now "on the iso" implies "in main" [14:35] and "package*s*" implies many [14:36] so I'm coming to you to try to work out an exception for this [14:36] This sounds familiar, did you bring that up on the last engineering sprint already? [14:36] I did write up a draft here: https://wiki.ubuntu.com/MIRTeam/Exceptions/OEM [14:36] yes [14:36] the idea is that packages which fit that draft can go in without MIR [14:36] great, the exception is what I'd have asked for [14:36] * cpaelzer reading ... [14:38] so the real content is in an extra apt archive [14:38] and this is really just abotu the meta-packages to go onto the iso [14:38] that was unclear last time we talked, thanks for adding the link on the wiki page [14:39] more or less, and that part is being considered by the TB [14:39] the meta pkgs themselves are super trivial [14:39] how many of those packages per release do you expect to see during a release life? [14:40] no idea [14:40] that all depends on how many laptops are enabled which is a bit beyond my field of view [14:40] but you could say several [14:41] wondering as well about the burden on the SRU team, but that’s another topic (to see if the mechanism is realistic) [14:41] Laney: I know it was only an idea back then when we talked - but is there any chance to get a linter-script for these rules ont that wiki page? [14:41] anyway, if we expect several, I think we should have an automated checker for them [14:41] the AAs could use that to verify that the package follows the rules before promotions [14:41] exactly :) [14:41] hehe, same thoughts it seems [14:41] explain more [14:41] please [14:41] Laney: I think the definitions on the page are good [14:42] Laney: the next step would be writing and attaching a script of some sort [14:42] I don't really have weeks to spend writing a script [14:42] or days even [14:42] so if that blocks this, it might do so for some time [14:42] well, if we don't have such a thing the AAs will ahve to manually check against the defnitions ont his page [14:43] which can work, but is error prone as we all know [14:43] and it scales wit hthe number of packages that will go this path [14:43] and can consume even more time depending on how many packages we are talking about (which we should know before starting this) [14:43] I guess the OEM team can give some estimation [14:44] Laney: IMHO it will not stall the approval of this approach to not (yet) have this script [14:44] But once the actual "please promote on the base of this" happens [14:44] then having one will make it fast [14:44] and lacking that checker will make it slow and the AAs grumpy [14:45] ok I can put it on the list, but I have to deliver the project itself as a higher priority, hope you understand [14:45] absolutely [14:46] I think it can be seem as a broken record, but I would really like to have at least have a guess estimate of the number of packages we are talking about [14:46] didrocks: can you explain the background behind your request? [14:46] if it's 10, you prefer to review them all manually? [14:46] but 15 not? [14:47] I guess 10 is indeed ok, but if it’s 30, the script should be mandatory before we start such a process [14:47] it's an interesting one [14:47] as AA will likely spend more time and it will be more error-prone [14:48] if you decline this exception then it is the *MIR* team that gets more work [14:48] It's not that hard to have one package as a reference, and then run debdiff against any new ones, though [14:48] I'm interested because it saves me paperwork, but you should be because it saves you MIRs to review [14:48] And that provides a reasonable review base, I'd guess [14:48] that is a simple approach to such a helper script [14:48] good hint juliank [14:48] I’m more thinking about MIR/AA/SRU in general, and not not caring just to deliver but giving the load to others [14:49] I'm saying the difference between declining until I write a script and approving without the script isn't that great [14:49] it's the addition of some paperwork [14:49] but if debdiffing some template is OK, ... [14:49] which will back-pressure all parties to have a script [14:50] or it will never happen because life and next projects… [14:50] "debdiff | filterdiff -p1 -x debian/changelog -x debian/modaliases" should be enough of a script [14:50] yep [14:50] seriously? [14:50] This sounds like a method to just get around MIRs, will the packages that get installed be supported for 10 years? [14:51] it is a method to get around MIRs [14:51] they'll be supported for the life of the release yes [14:51] get around in the sense that doing MIRs will be extremely repetitive [14:52] But the burden of support isn't any lower, shouldn't we do some validation of the packages supportability? [14:52] joeubuntu: the packages will have no "active" content [14:53] joeubuntu: we essentially do the validation on the template [14:53] and then based on that provide a fast path as long as that pattern is matched [14:53] OK, that makes sense. [14:53] Thanks [14:53] Laney: please correct me if your plan changed from what I barely remember from half a year ago :-) [14:54] Laney: maybe the words in the last few messages here could be added to the wiki [14:54] no that's it [14:54] it seems they help to calrify [14:54] so that debdiff thing, that is ok for a script for you? [14:54] I can upload a 'good' template somewhere and then just add that to the page ... [14:54] yeah, if you attach the files needed and how to invoke to the wiki that should be ok [14:55] I think so, just wrap it in an helper for the AA and that’s fine [14:55] a repo somewhere and a link to it from the wiki might be even better than an attachment [14:55] I would really put that in lp:ubuntu-archive-tools [14:55] didrocks: weren't there a aa-helper repository somewhere? [14:55] yes that is what i was looking for [14:55] Laney: would that work for you (not stalling you too much) but giving you what you need? [14:56] I thought you wanted an actual static verifier, but this should be ok if you don't mind [14:57] we are all reasonable people, in a perfect world there would be a super-duper-verifier - but this seems to work [14:57] if it turns out it does not it will slow down the AAs and thereby your packages from promotion [14:57] and all packages will have a very strong testsuite in them :p and and and… :) [14:57] but I think this will be good [14:57] Oh, test suite [14:57] ahah [14:57] Laney: would you ping me once you updated the wiki/repo please? [14:58] It would be nice to have autopkgtest that installs it and run apt update I guess to ensure there's no typos in the .list entry [14:58] we lack the people to "sign-off" on this atm, but I can send a mail to the MIR team then [14:58] cpaelzer: ok, I will do, thanks [14:58] * Laney ignores juliank trying to load more work onto this [14:58] juliank: good suggestion [14:58] lets add it only as a bonus-objective to avoid the anger of Laney [14:59] heh [14:59] if you're being cool you'd do it with autodep8 [14:59] and *that* would be the static verifier [14:59] * Laney runs [14:59] Oh yeah, I should write an autodep8 module for verifying packages which install sources.list entries [14:59] yeah, but nothing ensures you that in the long run, the repo is still valid [15:00] and have needed packages [15:00] but anyway, let’s move on :) [15:00] (or you need regularly running autodep8, which in the end is a jenkins-like solution with reporting and so on…) [15:06] funny thing but juliank is at some point in our lives going to work on something similar to that