15:33 <doko> #startmeeting Weekly Main Inclusion Requests status
15:33 <meetingology> Meeting started at 15:33:59 UTC.  The chair is doko.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
15:33 <meetingology> Available commands: action, commands, idea, info, link, nick
15:34 <doko> #topic Review of previous action items
15:34 <doko> I don't have a list ...
15:35 <didrocks> I have handled my 2 of last week list, I don’t remember the rest for others
15:35 <doko> did so for my action as well. ok, let's skip this
15:35 <sarnold> /lastlog action doesn't look like it's got anything from these meetings
15:35 <doko> #topic current component mismatches
15:36 <doko> #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
15:36 <doko> needrestart not yet addressed by foundations
15:37 <doko> https://bugs.launchpad.net/ubuntu/+source/libbackuppc-xs-perl/+bug/1910262 is in progress, and needs security review
15:37 <ubottu> Launchpad bug 1910262 in libbackuppc-xs-perl (Ubuntu) "[MIR] libbackuppc-xs-perl" [Undecided,In progress]
15:37 <sarnold> iniparser feels new to me
15:38 <doko> ok, I'll take that
15:38 <doko> mozc/abseil is still unresolved
15:38 <doko> who is pkg-ime?
15:39 <didrocks> an empty MIR for abseil is opened, but missed the tag to be listed
15:39 <doko> didrocks: #1908502 is incomplete
15:39 <didrocks> seb128 will do the MIR AFAIK
15:40 <ddstreet> for usrmerge, I approved it and put into in-progress; but since it's already seeded, should i just move it directly to fix-committed?
15:40 <didrocks> doko: dunno about this one, we didn’t talk about libtiff5 last week, I can chase
15:41 <doko> ddstreet: ok, I'll promote that after the meeting
15:41 <ddstreet> thanks
15:41 <doko> #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg
15:42 <doko> nothing new
15:42 <doko> #topic New MIRs
15:42 <doko> #link https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=NEW&assignee_option=none&field.assignee=&field.subscriber=ubuntu-mir
15:43 <didrocks> door bell
15:43 <doko> I don't any new ones
15:43 <sarnold> :)
15:43 <doko> #topic Incomplete bugs / questions
15:43 <doko> #link 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
15:44 <GunnarHj> Maybe that's where my item comes in.
15:44 <GunnarHj> This is about the opencc MIR at bug #1909665. We were asked to add a symbols file for libopencc1.1, but since it's written in C++ doing so proved to be harder than I first realized. I was invited by didrocks to talk about it here.
15:44 <GunnarHj> So I guess my questions are:
15:44 <GunnarHj> 1. Should a symbols file be a requirement for including a C++ library in Ubuntu's main?
15:44 <GunnarHj> 2. Even if it normally is, is there room for an exception in case of a non-core library with a specific target user group? (libopencc1.1 facilitates conversion between simplified and traditional Chinese.)
15:44 <ubottu> bug 1909665 in opencc (Ubuntu) "[MIR] ibus-libpinyin dependencies" [Undecided,Incomplete] https://launchpad.net/bugs/1909665
15:45 <doko> #topic Any other business?
15:45 <doko> the formal answer is: yes ;p
15:46 <GunnarHj> doko: To which of the questions?
15:46 <doko> to 1
15:46 <GunnarHj> Ok. Room for exception in a non-core package?
15:47 <doko> I know it's a pain, however we don't have yet anything better
15:47 <doko> we really should use abigail instead of symbols files for c++ symbols
15:48 <GunnarHj> We haven't given up yet, but had a discussion at https://salsa.debian.org/debian/opencc/-/merge_requests/1, and the principal maintainer suggested that I ask.
15:48 <doko> I'm not aware of any exceptions. I would tend to no-exception for now. any opinions=?
15:49 <doko> looks like -3 has symbols files ...
15:50 <sarnold> I don't understand the purpose of the symbols files well enough to have strong opinions; if they're part of some automated way to find abi breakage, then I'd guess they're more important with c++ than c, no?
15:51 <doko> yes, finding ABI breakage. I don't see a difference for c and c++. but with c++, it's harder to see what makes up the ABI
15:52 <doko> there are a lot of smbols for template instantiations, which vary for optimization levels, archs, endienness and 32/64 bit
15:52 <sarnold> oh wow
15:53 <seb128> hey there
15:53 <sarnold> hey seb128
15:54 <doko> abipkgdiff <lib1.deb> <lib2.deb> is usually very helpful
15:54 <seb128> is the MIR meeting over yet?
15:54 <sarnold> seb128: no, we're right now discussing adding symbols to opencc
15:54 <sarnold> :https://launchpad.net/bugs/1909665 and https://salsa.debian.org/debian/opencc/-/merge_requests/1
15:54 <ubottu> Launchpad bug 1909665 in opencc (Ubuntu) "[MIR] ibus-libpinyin dependencies" [Undecided,Incomplete]
15:54 <GunnarHj> I learned that the hard way. Created a symbols file and got opencc uploaded, but the build failed in all archs but two.
15:55 <doko> GunnarHj: https://qt-kde-team.pages.debian.net/symbolfiles.html
15:55 <GunnarHj> doko: Right, I was told that pkg-kde-tools may help.
15:56 <doko> so could you give it a try first?
15:56 <GunnarHj> doko: Sure, as I said we haven't given up.
15:56 <doko> thanks
15:57 <doko> anything else?
15:57 <GunnarHj> Thanks for considering it.
15:57 <sarnold> thanks GunnarHj
15:57 <sarnold> doko: nothing from me
15:57 <doko> seb128: ?
15:57 <seb128> would that be the right place to discuss removing the 'subscribe an owning team before the MIR is approved' requirement ?
15:58 <seb128> we got desktop subscribed to flatpak as part of bug #1812456
15:58 <ubottu> bug 1812456 in flatpak (Ubuntu) "[MIR] libflatpak0" [Medium,New] https://launchpad.net/bugs/1812456
15:58 <seb128> but now flatpak rls tagged bugs show up on our report despite the MIR not being approved nor moving since septembre
15:58 <seb128> which is suboptimal
15:59 <doko> hmm, who would then be supposed to care about this?  maybe we should delay that to next week when more people are here
16:00 <seb128> I would suggest the team should be subscribed once the promotion is approved
16:00 <seb128> get approved, subscribe, promote
16:00 <seb128> seems a more logical order to me
16:02 <doko> what's the current state? wait for security review
16:02 <seb128> yes
16:02 <sarnold> I can see the frustration with no progress on the package, but seeing bugs filed while its being processed feels like a useful thing to me
16:02 <doko> let's wait for next week when Christian is here
16:02 <doko> and james
16:03 <seb128> k, I will join again next week, thanks
16:03 <seb128> sarnold, well, it's just that the MIR might be rejected or meanwhile there is no reason we should be on the hook to support a package which isn't in main
16:19 <doko> oops, I think I forgot to close the meeting
16:19 <doko> #endmeeting