18:00:14 <spwhitton> #startmeeting
18:00:14 <MeetBot> Meeting started Wed May 12 18:00:14 2021 UTC.  The chair is spwhitton. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:14 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:00:30 <spwhitton> #topic Review of previous meeting AIs
18:00:37 <marga> No roll call?
18:00:37 <spwhitton> #topic Roll Call
18:00:38 <spwhitton> whoops
18:00:40 <Myon> Christoph Berg
18:00:41 <spwhitton> Sean Whitton
18:00:43 <marga> Margarita Manterola
18:00:45 <ehashman> Elana Hashman
18:00:47 <bremner> David Bremner
18:01:03 <gwolf> Gunnar wolf
18:01:03 <ntyni> Niko Tyni
18:01:45 <spwhitton> smcv: around?
18:04:03 <smcv> Simon McVittie
18:04:16 <spwhitton> alright :)
18:04:19 <spwhitton> #topic Review of previous meeting AIs
18:04:32 <spwhitton> smcv wrote his draft -- thak you for that
18:04:35 <spwhitton> does anyone else have any comments on it?
18:04:50 <marga> http://meetbot.debian.net/debian-ctte/2021/debian-ctte.2021-04-14-17.57.html for the previous meeting notes
18:04:52 <spwhitton> smcv: did you see my brief comment on IRC?
18:04:57 <smcv> I did
18:05:05 <smcv> I'll try to do a quick update
18:05:16 <bremner> I had a quick look, it seemed OK to me
18:05:42 <Myon> +1
18:05:50 <gwolf> +1
18:06:19 <marga> It looks ok, except for a with vs without being swapped, was that what you commented spwhitton ?
18:06:31 <spwhitton> marga: ah no mine was something else
18:06:52 <marga> Or maybe, I'm just reading it too fast and confused by the grammar.
18:07:05 <smcv> marga: sorry, where do you think it's either wrong or confusing?
18:07:14 <ehashman> I did not do my action item :x
18:07:53 <ntyni> re treated as bugs upstream, and fixed: the valgrind maintainer said on the bug that while he did fix them, that
18:08:07 <ntyni> he considered those fixed more as a workaround
18:08:20 <ntyni> but I guess there's not much difference
18:08:26 <ntyni> apart from that it works for me
18:08:26 <marga> smcv, " for large packages _this_ can mean ", my initial read of the text pointed the "this" to the wrong thing.
18:09:04 <marga> smcv, maybe just saying "not compressing symbols" instead of "this"?
18:09:15 <smcv> yeah I'm fixing that to be clearer
18:10:30 <marga> Yeah, apart from that, it seems fine to me.
18:10:48 <marga> I also didn't do my AI
18:11:03 <spwhitton> marga, ehashman: would you like to be reactioned or shall we rethink the assignments?
18:11:22 <marga> I think I'd like one last chance
18:11:34 <marga> If I don't do it for next meeting, then yes, let's re-think.
18:11:44 <spwhitton> you can have more than one chance :)  just wanted to give the option.
18:11:51 <spwhitton> #action marga to work on proposal #3 and share some ideas next meeting
18:12:24 <gwolf> marga: Fortunately we have been having a couple of calm months here :-)
18:12:30 <ehashman> spwhitton: yeah you can reaction me
18:12:57 <spwhitton> #action ehashman to work on proposal #1 some more and report back to next meeting
18:13:00 <spwhitton> nice
18:13:01 <smcv> let's have a new #topic for 976462 if people are ready?
18:13:12 <spwhitton> #topic #976462 - Should dbgsym files be compressed via objcopy --compress-debug-section or not?
18:13:37 <smcv> so I've done a couple of fixes for what spwhitton and marga raised
18:13:45 <smcv> I hope that reads OK to everyone
18:14:17 <spwhitton> it's fine with me.  any last comments?
18:14:37 <bremner> can haz diff?
18:14:54 <spwhitton> bremner: the two deb.li links above
18:14:55 <gwolf> bremner: the notice just sent by KGB-2
18:15:08 <smcv> re what ntyni said just now, do we want to rephrase, or even reconsider our decision, based on the valgrind maintainer's unhappiness with compressed debug symbols?
18:15:10 <bremner> uh, I think I ignore that bot, once sec
18:15:39 <gwolf> https://deb.li/3Ipy0 and https://deb.li/MocA
18:16:07 <bremner> ta. I managed to unhide those lines.
18:16:20 <spwhitton> smcv: I think when I read his message my thought was that it was only slightly less vague a worry than the general "tooling might have issues" thing.
18:16:21 <ntyni> the unhappiness was expressed in the last message of #976462 fwiw
18:16:46 <Myon> I think unhappyness just means the tools need further fixing and compressing is the correct choice
18:16:55 <smcv> looking again at the referenced bugs, it seems Mark Wielaard is unhappy with how dh_strip and dh_dwz interact
18:17:16 <spwhitton> It sounds like bright ideas and improvements in valgrind might be the sort of thing that gives an actual reason to stop compressing, but that it doesn't *yet* do so.
18:17:31 <spwhitton> As there isn't a consensus on how these different things ideally interact.
18:17:35 <smcv> and thinks it's wrong that we apply dwz (deduplication) before stripping
18:18:15 <Myon> also that mail isn't new (Mar 23), we were looking at it already last time
18:18:40 <smcv> if that is indeed wrong, then that does somewhat invalidate our reasoning about "well compression might make dwz more awkward, but it seems to work OK and doesn't seem to be burdensome for the debhelper maintainer"
18:19:06 <smcv> sorry, this is new to me at least, I had not looked at the valgrind bugs in detail
18:19:31 <bremner> usually we complain that people call the ctte too late, but this feels to early, before concrete bugs / problems have been identified
18:19:37 <spwhitton> smcv: I mean, do we know why dwz is done first?
18:19:47 <smcv> the easy answer is
18:19:54 <smcv> because dh_strip applies compression
18:20:05 <smcv> and dwz doesn't support acting on compressed dbgsym
18:20:53 <smcv> there might be other reasons, I don't know
18:22:08 <smcv> dwz always seemed to me like something that just appeared in our toolchain without a clear problem statement
18:22:10 <spwhitton> right.  I think that your draft is still correct with emphasis on the "with the information available"
18:22:16 <Myon> does anyone here think not compressing is the way to go? Otherwise we could close it, even if there's questions open
18:22:44 <smcv> I mean, I'm sure dwz does something useful
18:23:09 <smcv> deduplication of similar debug symbols when multiple binaries statically link common code, I think?
18:23:34 <smcv> but it's not obvious to me what that useful thing is, or how it changes the big-picture view of dbgsym
18:24:14 <spwhitton> smcv: do you think ctte needs to get to the bottom of that in order to issue a decision on this bug?  it is not obvious to me why.
18:25:00 <gwolf> We are not going to issue a MUST, but a SHOULD. And the decision can be revised later on
18:25:03 <smcv> I think compressing debug symbols is probably still the right thing to do, even if the sequence of events has to change in order to have strip/dwz/future ELF magic all join up correctly
18:25:19 <smcv> I only raised this because I don't want to be misrepresenting consensus
18:25:28 <gwolf> Yes. It takes quite a bit of work to find the problematic cases... Which might, of course, exist
18:25:36 <spwhitton> smcv: cool -- you mean ctte's consensus?
18:25:38 <gwolf> but we are not going to forbid to act differently on them if ever needed.
18:25:56 <smcv> spwhitton: mostly yes
18:26:22 <spwhitton> smcv: okay.  well, I think I see why you might be concerned about that, but I don't think the current text has that problem, in fact.
18:26:42 <smcv> are people happy with the wording around the valgrind bugs or does anyone want to adjust it?
18:26:54 <Myon> since we don't have anyone (in the project, elsewhere) really arguing for not compressing, and everyone seems to agree that disk space is somewhat a problem, I think we can get an answer out now with the information we have
18:26:56 <smcv> looking at you ntyni since you pointed this out
18:27:23 <ntyni> I'm ok with the wording
18:27:48 <gwolf> I agree with the wording..
18:28:12 <spwhitton> alright, smcv can I action you to close the bug?
18:29:06 <smcv> will do. I assume we don't need a vote because we're saying this unanimously
18:29:18 <spwhitton> right, yes, there hasn't been any disagreement at any point, I believe
18:29:26 <spwhitton> #action smcv to close bug with his latest draft
18:29:39 <spwhitton> smcv: thank you for all your effort on this one
18:29:41 <ntyni> thanks smcv
18:29:41 <spwhitton> and others for reviewing.
18:30:00 <spwhitton> #topic Moving forward with our reimagining the TC tasks
18:30:20 <spwhitton> has anyone had any thoughts on this, or shall we just wait until next time when marga and ehashman can report back
18:30:37 <bremner> I have zero thoughts
18:30:41 <Myon> same
18:32:01 <ntyni> +0
18:32:05 * gwolf cannot help much right now :-(
18:32:20 <Myon> (brb)
18:32:30 <spwhitton> #topic Any other business
18:32:43 <spwhitton> does anyone have anything under this alternative heading? :)
18:33:19 <bremner> not unless marga or ehashman want to take the last chance to bail on their action items
18:34:09 <spwhitton> heh
18:34:14 <ntyni> we might want to do something about https://www.debian.org/devel/tech-ctte , the list of decisions looks a bit neglected
18:34:33 <bremner> do I have to use CVS or something aweful?
18:34:37 <spwhitton> no it's git now
18:34:43 <ehashman> haha
18:34:48 <bremner> damn.
18:34:52 <spwhitton> has the TC traditionally updated that page or the web team?
18:34:53 <ehashman> sorry I'm a bit in and out
18:35:13 <ehashman> I've been underwater with a bunch of things, I just need to sit down and write it down :)
18:35:42 <bremner> spwhitton: I want to say web team, now that you mention it
18:35:45 <spwhitton> hmm, someone has updated it to have phil under the former members
18:36:01 <spwhitton> but not, for example, any other appointments since 2015
18:36:03 <ntyni> might be me, I've been doing some of that at least
18:36:30 <gwolf> Yes, seems to be from the web team -- and there are many decisions not reflected there
18:37:02 <spwhitton> do we think it's important to keep it up to date?
18:37:15 <gwolf> starting with member inclusions (which, as they are voted on, _are_ a formal decision). None of us current members is mentioned :-]
18:37:35 <spwhitton> not a single one of us?!  that's great.
18:37:50 <gwolf> spwhitton: Good point. I don't see much value in having a huge list of nontechnical decisions
18:37:53 <bremner> spwhitton: kept up to date, or replaced with a link to something more dynamic?
18:37:57 <gwolf> maybe the _technical_ ones are more worthy
18:38:25 <spwhitton> bremner: the closest thing would be a BTS search of closed bugs inc. archivec
18:38:28 <spwhitton> but maybe that is fine?
18:38:58 <marga> There were tags, set up by Don for better archiving the bugs
18:39:12 <marga> But nobody has taken care of adding said tags in the past 5-ish years
18:39:15 <gwolf> Or a link to salsa/debian/tech-ctte/resolved-issues...
18:39:28 <spwhitton> gwolf: that's not complete though right?
18:40:00 <gwolf> probably not, but it seems more mantainable -- and if we make a point of drafting resolutions in Git, it _will_ be
18:40:04 <spwhitton> one option is to keep the current page and update whenever someone feels like doing so, but add a note saying "this list of often out of date and is mainly for historical interest; see [bts link] for the official records of discussions"
18:40:11 <gwolf> (maybe some appendix of the TC reimagining ;-) )
18:40:19 <smcv> if the BTS is the single source of truth, which IMO it is, then it seems like the 90% solution is ... yeah what spwhitton said while I was typing this
18:40:20 <spwhitton> it is quite interesting to read if you're interested in debian history
18:40:39 <spwhitton> I could ask the web team to add a notice and link of that nature if others like my solution
18:40:41 <ntyni> yeah I think there's some value in having that list even as incomplete
18:40:56 <bremner> list + link sounds good to me
18:41:03 <gwolf> right
18:41:10 <marga> +1
18:41:48 <spwhitton> #action spwhitton to submit webmaster team bug/patch to clarify the status of the lists of old decisions
18:41:53 <spwhitton> okay then, I think we are done
18:41:55 <spwhitton> #endmeeting