15:03:42 <ignatenkobrain> #startmeeting FESCO (2020-05-11)
15:03:42 <zodbot> Meeting started Mon May 11 15:03:42 2020 UTC.
15:03:42 <zodbot> This meeting is logged and archived in a public location.
15:03:42 <zodbot> The chair is ignatenkobrain. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:03:42 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:03:42 <zodbot> The meeting name has been set to 'fesco_(2020-05-11)'
15:03:44 <zbyszek> .hello2
15:03:46 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
15:03:49 <dcantrell> .hello2
15:03:49 <mhroncok> hey
15:03:50 <ignatenkobrain> #meetingname fesco
15:03:50 <zodbot> The meeting name has been set to 'fesco'
15:03:50 <zodbot> dcantrell: dcantrell 'David Cantrell' <dcantrell@redhat.com>
15:03:58 <ignatenkobrain> #chair nirik, ignatenkobrain, decathorpe, zbyszek, bookwar, sgallagh, contyk, mhroncok, dcantrell
15:03:58 <zodbot> Current chairs: bookwar contyk dcantrell decathorpe ignatenkobrain mhroncok nirik sgallagh zbyszek
15:04:07 <ignatenkobrain> #topic init process
15:04:08 <bcotton> .hello2
15:04:09 <sgallagh> .hello2
15:04:09 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
15:04:12 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
15:04:13 <bookwar1> .hello2
15:04:14 <zodbot> bookwar1: Sorry, but you don't exist
15:04:15 <ignatenkobrain> I sent a reminder on #fedora-devel and then got disturbed at home
15:04:15 <nirik> morning
15:04:21 <ignatenkobrain> sorry for delay :)
15:04:24 <decathorpe> .hello2
15:04:26 <zodbot> decathorpe: decathorpe 'Fabio Valentini' <decathorpe@gmail.com>
15:04:29 <bookwar> .hello2
15:04:29 <zodbot> bookwar: bookwar 'Aleksandra Fedorova' <alpha@bookwar.info>
15:04:30 <contyk> .hello psabata
15:04:32 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
15:04:34 <sgallagh> I've been disturbed for a long time. I understand
15:05:08 <ignatenkobrain> I think I see everyone here
15:05:20 <ignatenkobrain> so let's start
15:05:24 <ignatenkobrain> #topic #2372 F33 Self-contained Change: Network Time Security
15:05:26 <ignatenkobrain> .fesco 2372
15:05:27 <zodbot> ignatenkobrain: Issue #2372: F33 Self-contained Change: Network Time Security - fesco - Pagure.io - https://pagure.io/fesco/issue/2372
15:06:00 <sgallagh> I can be +1 now.
15:06:11 * dcantrell reading again quickly
15:06:35 * mhroncok was +1 in the ticket
15:06:43 <dcantrell> yeah, still +1 for me
15:06:47 <zbyszek> Most people voted.
15:06:53 <nirik> +1 (althought has anaconda team signed up to do the changes there or ?)
15:06:59 <bookwar> +1
15:07:01 <contyk> +1
15:07:01 <zbyszek> We're at like 6.75 days on this one.
15:07:30 <sgallagh> Well, we have +6 right here, so that's approved.
15:07:41 <zbyszek> nirik: my understanding is that the anaconda part is postponed too.
15:07:53 <zbyszek> But indeed, that wasn't clarified really.
15:07:57 <nirik> hum, I still see it on the change page?
15:08:45 <ignatenkobrain> I see that too, so I think I will reach to the change owner to clarify that, otherwise I think we are good
15:09:00 <zbyszek> It says "Proposal owners" will do this (under "scope").
15:09:02 <ignatenkobrain> so I guess let's wait for dcantrell and have +9,0,-0?
15:09:37 <dcantrell> I said I was +1
15:09:55 <dcantrell> there, added it again to the ticket
15:10:02 <sgallagh> I think we are +9 now
15:10:07 <dcantrell> (sorry)
15:10:14 <ignatenkobrain> #action ignatenkobrain to contact change owners and clarify anaconda part of the change.
15:10:17 <ignatenkobrain> #agree APPROVED (+9, ±0, -0)
15:10:20 <ignatenkobrain> #topic #2381 F33 System-Wide Change: systemd-resolved
15:10:24 <ignatenkobrain> .fesco 2381
15:10:25 <zodbot> ignatenkobrain: Issue #2381: F33 System-Wide Change: systemd-resolved - fesco - Pagure.io - https://pagure.io/fesco/issue/2381
15:11:00 <nirik> did we see more discussion on list?
15:11:28 <sgallagh> No
15:11:31 <ignatenkobrain> no, I think there was no discussion so I was hoping that RH Security Team will put something or sgallagh but that did not happen
15:11:41 <sgallagh> Sorry, my week was out of control
15:11:57 <sgallagh> Anyway, with Michael's last message, I can be 0 I suppose
15:12:05 <nirik> so shall we punt this another week for that discussion?
15:12:28 <sgallagh> zbyszek: I'd prefer if you would coordinate any nsswitch.conf changes with me and/or sbose though.
15:13:34 <ignatenkobrain> nirik: if you know what you wait for, then probably. in this case, I think it is waiting for nothing
15:13:55 <ignatenkobrain> btw, I was running the proposed configuration for some time and did not notice any regressions
15:13:57 <sgallagh> Yeah, I'm the only one hesitating here, so just vote it in and I'll reserve the right to say I Told You So later :)
15:14:08 <nirik> well, I was thinking there was going to be some input from the security folks?
15:14:15 <dcantrell> I'm also counting myself as a 0 here
15:14:25 <nirik> and sgallagh was going to bring up the nsswitch.conf changes and see if there was a better way to do them?
15:14:32 <zbyszek> sgallagh: sorry, I dropped of the net for a second.
15:14:46 <sgallagh> I don't think we need to hold it up for that. I can work with them on the implementation
15:14:54 <nirik> I'm running it here too... the dnssec support doesn't work with dnf's key verify is the only thing I have noticed.
15:14:54 <zbyszek> sgallagh: changes to nsswitch.conf will most likely be in authselect profiles.
15:15:04 <ignatenkobrain> Proposal: Approve change, zbyszek to make sure coordinating nsswitch changes with sgallagh or sbose
15:15:18 <zbyszek> sgallagh: is is enough if I cc you on any PR or ticket so that you can review it?
15:15:27 <sgallagh> Yeah, that'll work
15:16:01 <ignatenkobrain> +1 from me
15:16:28 <nirik> +1
15:17:01 <ignatenkobrain> mhroncok: contyk bookwar decathorpe vote?
15:17:03 <mhroncok> +0 (I wasn't able to dedicate time to get the details here, sorry)
15:17:06 <ignatenkobrain> zbyszek: I suppose you are +1 here :)
15:17:23 <mhroncok> zbyszek is 0
15:17:28 <contyk> Abstain, I guess.
15:17:28 <decathorpe> I've been +1 over a week :)
15:17:30 <zbyszek> ignatenkobrain: no, I'm not voting on my own ticket ;)
15:17:54 <ignatenkobrain> ok, bookwar ?
15:17:58 <dcantrell> added my vote to the ticket
15:18:03 <bookwar> I'll set my +1, but i assume that if the security implications will be found during testing, we will go back to revisit
15:18:24 <zbyszek> bookwar: well, sure.
15:18:40 <ignatenkobrain> #agree APPROVED (+4, ±5, -0)
15:18:48 <ignatenkobrain> #topic Next week's chair
15:18:49 <zbyszek> In the sense that if security issues are found, I hope we'll fix them immediately.
15:18:56 <zbyszek> But in the worst case...
15:19:05 <ignatenkobrain> I can take next week if nobody else wants
15:19:17 <sgallagh> Hmm, that's actually never happened before; I'm not sure our policy covers (+5, 5, -0)
15:19:26 <sgallagh> err, +4
15:19:39 <bookwar> "Because Fedora is not prepared to handle  an influx of DNSSEC-related bug reports, we will disable this feature  altogether."
15:19:42 <mhroncok> ignatenkobrain: wait
15:19:50 <mhroncok> "A majority of the committee (that is, five out of nine) is required to pass a proposal in a meeting."
15:19:59 <mhroncok> APPROVED (+4, ±5, -0) is not a thing
15:20:12 <ignatenkobrain> oh
15:20:15 <ignatenkobrain> #undo
15:20:15 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7f4719e51410>
15:20:17 <ignatenkobrain> #undo
15:20:18 <zbyszek> Oh, for heavens' sake.
15:20:24 <mhroncok> +1
15:20:33 <mhroncok> you have it, and if this backfires, it's on me
15:20:40 <bookwar> people with 0, do you need more time?
15:20:42 <zbyszek> mhroncok: thanks mhroncok
15:20:49 <bookwar> last chance to say it
15:20:51 <ignatenkobrain> #agree APPROVED (+5, ±4, -0)
15:20:53 <sgallagh> I'll give it a +1 as well, since zbyszek said he'd coordinate with me
15:20:56 <ignatenkobrain> :)
15:20:57 <decathorpe> mhroncok: we could've just let it sit in the ticket for a few days and it would have been approved :)
15:21:02 <ignatenkobrain> okaay
15:21:03 <ignatenkobrain> #undo
15:21:05 <mhroncok> decathorpe: I know
15:21:14 <zbyszek> thanks sgallagh
15:21:23 <ignatenkobrain> #agree APPROVED (+6, ±3, -0)
15:21:25 <mhroncok> decathorpe: I just want to make sure we follow our rules
15:21:27 <ignatenkobrain> #topic Next week's chair
15:21:46 <zbyszek> mhroncok: yeah, thanks for catching that.
15:21:52 <sgallagh> I can do it next week, but I'll be away the week after
15:22:02 <dcantrell> I'll take meeting chair if no one else wants to
15:22:03 <ignatenkobrain> mhroncok++
15:22:03 <zodbot> ignatenkobrain: Karma for churchyard changed to 6 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:22:13 <sgallagh> Either way is fine with me
15:22:18 <ignatenkobrain> sgallagh: was first
15:22:24 <ignatenkobrain> #action sgallagh will chair next meeting
15:22:31 <ignatenkobrain> #topic Open Floor
15:22:42 <ignatenkobrain> anybody has anything for open floor?
15:22:48 <dcantrell> yes
15:23:06 <sgallagh> Proposal: Revise the voting rules to state that "0 (abstain) votes reduce the number of positive votes required to pass a measure"
15:23:07 <dcantrell> not necessarily fesco, but what is next for the ticket I opened requesting 'sponsor' on my FAS account
15:23:20 <ignatenkobrain> sgallagh: hey! I was just typing this!
15:23:20 <dcantrell> I know some of you may have seen that ticket or commented on it
15:23:28 * nirik can give his typical DC move update. Can wait until others are done.
15:23:35 <mhroncok> sgallagh: I don't like such proposal to be just proposed on a meeting and voted on
15:23:46 <bookwar> sgallagh: -1
15:23:50 <nirik> mhroncok: +1
15:24:03 <sgallagh> mhroncok: Well, it's a meeting where we actually have all 9 members, so I figured it was reasonable
15:24:14 <sgallagh> Plus, I think rule changes require unanimity?
15:24:16 <mhroncok> sgallagh: no commuity invovement
15:24:16 <zbyszek> I think this needs to be reworded, because we want to subtract from total too.
15:24:18 <bookwar> if half of the fesco says 0 - this shouldn't be approved, but rather discussed in more details, i think
15:24:19 <dcantrell> sgallagh: wait, so you want to reduce the passing requirement to be the majority of only those voting?
15:24:34 <dcantrell> bookwar: agreed
15:24:47 <sgallagh> dcantrell: No, only those *not abstaining*. It's differnet.
15:24:47 <ignatenkobrain> bookwar: in that case somebody should say -1, no?
15:25:45 <nirik> dcantrell: that should be approved in a few hours... it has to wait 7 days for votes, and I think it's up later this morning?
15:25:54 <ignatenkobrain> sgallagh: so I guess for you proposal - open a ticket and let's discuss it as usual.
15:25:58 <dcantrell> nirik: noted, thanks for the update
15:26:01 <sgallagh> Very well
15:26:19 <sgallagh> #action sgallagh to open a ticket to discuss abstention policy
15:26:28 <bookwar> i have a topic on gcc10
15:26:31 <zbyszek> Yes, I think people should either say "+1", or "-1" or "I need more time for discussion" or "0, I don't have an opinion because ...", and in that last case, this shouldn't block a ticket.
15:26:56 <ignatenkobrain> zbyszek++
15:26:56 <zodbot> ignatenkobrain: Karma for zbyszek changed to 3 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:26:57 <mhroncok> zbyszek: I kinda agree, but let's have this discussion on devel?
15:27:02 <zbyszek> mhroncok: sure
15:27:23 <dcantrell> zbyszek: the - and + could be more formalized on 0 votes.  -0 == need more time/discussion, +0 == no opinion
15:27:28 <bookwar> zbyszek: if half of the fesco couldn't find time to get the opinion - we are doing something wrong, imho
15:27:35 <sgallagh> dcantrell: -1
15:27:56 <zbyszek> dcantrell: I prefer to spell it out.
15:28:02 <ignatenkobrain> bookwar: is gcc10 broken entirely? :)
15:28:03 <dcantrell> yeah that's fine too
15:28:19 <sgallagh> I'll write up some ideas and we can work it through on the list.
15:28:32 <zbyszek> sgallagh++
15:28:32 <zodbot> zbyszek: Karma for sgallagh changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:29:04 <mhroncok> sgallagh: thanks
15:29:10 <nirik> dc move status: RDU - communishift is still down, hopefully we can get some traction to get the cabling and network changes we need done this week, hard to estimate however. IAD2: we have "found" all the machines that are new/were shipped. We have a number of virthosts installed and we have a few vm's up. This week will be getting external ips sorted out, firewall/nat rules, getting everything re-installed that needs it, and hopefully bringing up a
15:29:10 <nirik> proxy or two and out auth stack (which means an openshift 3.11 cluster).
15:31:02 <bookwar> nirik: i've sent you e-mail on the requirements for fedora ci jenkins, which supposed to replace taskotron. We can discuss there. I currently don't undertsand if we should just sit and wait, or we can have some other options
15:31:29 <nirik> I can look... I just got up before the meeting, so I haven't processed mail yet
15:31:34 <bookwar> sure
15:32:50 <zbyszek> dcantrell also had something...
15:33:00 <nirik> I'll also try and find out more about this weeks schedule when I can from networking/dcops
15:33:01 <dcantrell> already mentioned, it was just my ticket question that nirik answered
15:33:21 <bcotton> nirik: is https://status.fedoraproject.org/CY2020-inframove.html being updated as the schedule changes or is it diverging?
15:33:47 <nirik> that was more for the actual moving of services.
15:33:52 <ignatenkobrain> bookwar: do you want to talk about something related to gcc10? you've mentioned this some lines above
15:34:15 <nirik> https://hackmd.io/Eqsf5wFoQRGYhAVwSKJvIA is our running planning/tasks (but might be too detailed)
15:34:27 <bookwar> ignatenkobrain: let's answer dcantrell's question is possible, and then enter the flame )
15:34:47 <ignatenkobrain> ah, if it will be flame - I'll mentioned one thing
15:34:54 <ignatenkobrain> I have created script which to some extent automates and enforces FTI policy - https://pagure.io/releng/pull-request/9443
15:34:57 <ignatenkobrain> it is not perfect, but is quite good at setting needinfos and opening/closing bugs…
15:35:19 <ignatenkobrain> s/mentioned/mention/
15:35:50 <bcotton> nirik: ack. i'll try to parse that to update f33-infra schedule and run it by you
15:36:14 <nirik> bcotton: sure.
15:36:24 <nirik> ignatenkobrain: cool.
15:37:19 <zbyszek> ignatenkobrain: should this be schedule to run periodically from some infra job?
15:37:55 <ignatenkobrain> zbyszek: well, I guess once I add FTBFS support there and it is merged, that would be something what would be nice
15:38:37 <mhroncok> ignatenkobrain: just make sure to stop / repalce the current cron job for ftbfs
15:38:39 <nirik> while you are at it, add the security ones. :)
15:38:43 <mhroncok> :)
15:38:57 <zbyszek> I was just thinking exactly that ;)
15:39:02 <nirik> but really, great work...
15:40:24 <ignatenkobrain> so, let's move to bookwar topic?
15:41:03 <bookwar> so, approved gcc10 pre-release version for Fedora 32 caused major failures in many projects (ex things like rabbitmq, freecad) These projects are not in the workstation default, but having crashing `systemctl rabbitmq-server start` command is not nice
15:41:21 <bookwar> afaik updated gcc10 was merged last week
15:42:16 <bookwar> so, 1) do we need mass rebuild? 2) do we need a retrospective on the gcc10 change ? 3) should we extend release criteria to cover some more packages and by which criteria?
15:42:28 <sgallagh> It's also causing some build-time issues, as there are a bunch of packages that use poor version-detection
15:42:30 <mhroncok> hard questions
15:42:47 <sgallagh> e.g. comparing the first digit
15:43:03 <mhroncok> I have plenty of feedback on 2), but it's an mprovement, this time we at least had a change proposal before the update happened
15:43:37 <bookwar> mhroncok: let's try the retrospective then?
15:43:39 <ignatenkobrain> 1) do we know how much things are broken because of that? does rebuild fixes problem?
15:43:58 <ignatenkobrain> bookwar: 2) we can, though I am not sure what we would discuss there.
15:44:14 <zbyszek> bookwar: re 1: I don't think so. The ABI is not changed, so a mass rebuild will most likely only cause problems.
15:44:35 <nirik> is there a tracker for these issues?
15:44:39 <bookwar> the problem is that packages with broken gcc were built successfully, but they failed randomly when running
15:44:42 <mhroncok> the problem with such changes is that you don't really have any leverage unless the change has landed. -- for example an ignored "your package doesn't build" bug may have consequences, but an ignored "we plan to upgrade gcc and your package won't build" but has none
15:44:43 <zbyszek> A mass rebuild on the side, to see if there are build issues, would be useful. But it shouldn't be merged into rawhid.e
15:45:16 <bookwar> zbyszek: so this is exactly the issue - we check only if we can build packages
15:45:22 <bookwar> but they started to fail on run
15:45:22 <mhroncok> I also think that mass rebuilding *everything* on F32 is more dangerous than helpful
15:45:23 <zbyszek> bookwar: how is that even possible? Are there no tests in those packages?
15:45:38 <mhroncok> hehe
15:45:43 <ignatenkobrain> bookwar: I know that fweimer has some database which he uses to find what needs to be rebuilt if some glibc thing breaks
15:45:57 <bookwar> zbyszek: if you wanted to say - gating, i am with you on that :)
15:46:06 <ignatenkobrain> probably GCC folks can do similar thing?
15:46:13 <ignatenkobrain> Unfortunately I don't know more details to say anything here
15:46:13 <nirik> is this affecting both 32 and rawhide? or just the version in 32?
15:46:55 <dcantrell> I don't see any mention of crash details, just that "things are crashing".  suggesting things like mass rebuilds or whatever is just throwing darts at the wall and hoping something works.  is there any analysis as to what's actually crashing?  it'd make determining a course of action easier
15:47:04 <zbyszek> Does anyone have the bug numbers handy?
15:48:58 <bookwar> https://bodhi.fedoraproject.org/updates/FEDORA-2020-2c6c85202d this is the update, which has upstream fixes
15:49:37 <bookwar> this is the exampel bug https://bugzilla.redhat.com/show_bug.cgi?id=1827357
15:50:00 <bookwar> the issue i hit was rabbitmq-server[13887]: *** stack smashing detected ***: terminated
15:50:42 <bookwar> we don't have to decide here really, and mass rebuild is probably too large of an action anyway
15:50:56 <ignatenkobrain> bookwar: but after upgrading gcc, the problem is gone, right? so there is no rebuild of rabbitmq was needed.
15:51:00 <mhroncok> we should deal with the problems on case by case basis, mass rebuild is too dangerous
15:51:02 <bookwar> but i was wondering which measures we should consider to prevent this
15:51:13 <mhroncok> bookwar: have more tests
15:51:14 <bookwar> ignatenkobrain: if you rebuild everything - yes
15:51:39 <dcantrell> bookwar: the issue seen in rabbitmq-server would suggest it needs fixing since SSP caught something.  it's not always 100% perfect, but it's reasonable
15:51:44 <bookwar> mhroncok: that was my default answer :) the other part was - don't update gcc to pre-release version maybe ?
15:52:06 <bookwar> dcantrell: no, that's already resolved issue, and it was on gcc side
15:52:18 <sgallagh> Wait, did upgrading libgcc solve the problem?
15:52:26 <sgallagh> Or did it require a rebuild with 10.1.1?
15:52:35 <mhroncok> bookwar: we cannot eat the cake and have it
15:52:41 <ignatenkobrain> bookwar: in that case, nobody in this world will ever properly test gcc 🙂 if we don't use pre-release GCC for our packages
15:52:48 <mhroncok> that
15:52:55 <dcantrell> bookwar: I'm also seeing the gcc changes page the very first thing mentioned is fixing an C++ ABI compatibility issue.  That likely is affecting things right now
15:53:01 <sgallagh> bookwar: Yeah, Fedora is pretty much the only way GCC gets tested
15:53:16 <sgallagh> Not carrying pre-releases just moves the fixes to post-release.
15:53:24 <nirik> https://bodhi.fedoraproject.org/updates/FEDORA-2020-073c252157
15:53:36 <nirik> (ie, rabbitmq-server was rebuilt with the fixed gcc)
15:53:40 <zbyszek> bookwar: some failure will always slip through. I don't think we need to change the process on the basis on the few bugs that slip through.
15:54:00 <mhroncok> looks like the rabbit thing is not really severe, if people are not superkarming it up
15:54:03 <zbyszek> It would be great to catch "service crashes at start" much earlier though.
15:54:21 <decathorpe> I don't know, it just seems to me that GCC 10 / fedora 32 was worse than other releases in that regard :/
15:54:29 <bookwar> zbyszek: it is not "some" this time, people in the community literally switching to clang for some projects now
15:54:34 <dcantrell> we should create an even rawer rawhide  :)
15:54:49 <ignatenkobrain> really-raw-rawhide
15:54:50 <decathorpe> dcantrell: cowskin?
15:55:10 <bookwar> i think it was due to the fact that packages were compiling, rather then failing in mass rebuild, and it let more errors through our process
15:55:12 <dcantrell> there you go.  get your gcc snapshots and hourly kernels and everything
15:55:13 <mhroncok> bookwar: what people? where is the mob with pitchforks?
15:55:28 <bookwar> previously we got more build failures, which we were able to catch
15:55:43 <zbyszek> bookwar: dunno, for me the gcc10 transition was easier than the gcc9 transition.
15:55:57 <zbyszek> (In the sense of upstream work in various projects.)
15:56:16 <nirik> would this have been caught by a gating test that did 'program --help' and confirmed it exited 0?
15:56:23 <ignatenkobrain> anyway, I think the real solution here would be to run tests of whole distro after libgcc update, and in more generic words, on a dependency change - run tests of a component and report results to the one who made an update
15:56:24 <bookwar> zbyszek: that's what i think happened, we got errors hidden under seemingly nice package rebuilds
15:56:29 * sgallagh needs to drop in three minutes
15:56:49 <zbyszek> ignatenkobrain: yes please
15:56:53 <sgallagh> nirik: Probably, yes
15:56:58 <bookwar> nirik: yes, this what makes me think about covering mass rebuilds with additional testing
15:57:09 <ignatenkobrain> bookwar: how hard would it be to implement?
15:57:20 <ignatenkobrain> I mean my idea
15:57:27 <bookwar> currently i think mass rebuilds are excluded from gating
15:57:42 <sgallagh> They are, because the load is enormous
15:57:45 <nirik> yeah... they are.
15:57:58 <mhroncok> sgallagh: thanks for the fesco voting email
15:58:05 <sgallagh> Any time
15:58:05 <decathorpe> I don't think bodhi can handle 25000 package side tag update :)
15:58:10 <bookwar> ignatenkobrain: your idea is the revdeps pipeline, we will set it up once we get jenkins running :)
15:58:16 <ignatenkobrain> bookwar: but if I update foo (which bar depends on), will gating tests run on bar?
15:58:22 <dcantrell> I think rather than everything with a libgcc update, there be a short list of packages we test with it (_somehow_) and over time we just grow that list as necessary
15:58:48 <bookwar> so we probably need to include adamw in this conversation
15:59:02 <dcantrell> he'd have a good idea of where to start with that
15:59:04 <mhroncok> I'd pretty much prefer to have this async
15:59:05 <nirik> we could possibly run eventhing thru gating, but it might take a while.
15:59:15 <ignatenkobrain> mhroncok: +1
15:59:18 <sgallagh> OK, I have to drop. Thanks, folks.
15:59:19 <mhroncok> nirik: I would be -1 for that
15:59:24 <bookwar> let me actually take an action on this
15:59:34 <nirik> mhroncok: oh? why? due to the time?
15:59:43 <mhroncok> nirik: I don't want for example a python 3.9 rebuild of 3000 packages be gated on a valgrind check in one of them
15:59:48 <bookwar> i need to talk with Fedora QA on how can we cover this cases better
16:00:35 <nirik> mhroncok: well, I was thinking just the mass rebuild... and not to file it as some gigantic update, but to send each package in in a stream... like it would if everyone just rebuilt their packages
16:00:46 <mhroncok> nirik: the gating land is hic sunt leones
16:01:06 <ignatenkobrain> #action bookwar to discuss with Fedora QA how to cover runtime testing better
16:01:07 <mhroncok> nirik: oh, I misunderstood
16:01:12 * nirik can only parse that based on context. :)
16:01:38 <ignatenkobrain> so, anything else to discuss?
16:01:41 <mhroncok> the only way to handle runtime testing better is to... have some runtime tests
16:01:46 <mhroncok> no tests? no handling it better
16:02:01 <ignatenkobrain> mhroncok: well, even you have them - something should trigger them :)
16:02:14 <bookwar> i meant mass-rebuild case, not runtime test in general :)
16:02:41 <zbyszek> Also, packages should have a 'foo --test >/dev/null || exit 1' in %check.
16:02:53 <zbyszek> Not hard to implement, but really helps with many many stupid bugs.
16:03:30 <bookwar> zbyszek: yes, maybe the answer to any gcc10 complains is just go and submit the check like this
16:03:38 <zbyszek> In particular writing to stderr from --help.
16:03:39 <bookwar> i should do it for reabbitmq right now..
16:03:59 <mhroncok> :)
16:04:42 <ignatenkobrain> so, I'll close meeting in 10 if nobody has anythign else to discuss
16:04:43 <bookwar> so, thank you all for the discussion :)
16:04:56 <mhroncok> ignatenkobrain: 10 seconds?
16:05:03 <decathorpe> ignatenkobrain++ for filing FTI bugs again
16:05:04 <smooge> years
16:05:10 <mhroncok> smooge++
16:05:10 <zodbot> mhroncok: Karma for smooge changed to 10 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:05:21 * nirik wonders if we could make it generic... for everything in _bindir and _sbindir ... run --help
16:05:39 <mhroncok> nirik: if only that would actually work :D
16:05:41 <ignatenkobrain> #endmeeting