13:00:50 <FranciscoD_> #startmeeting neurofedora 2020-10-24
13:00:50 <zodbot> Meeting started Mon Oct 24 13:00:50 2022 UTC.
13:00:50 <zodbot> This meeting is logged and archived in a public location.
13:00:50 <zodbot> The chair is FranciscoD_. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
13:00:50 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:00:50 <zodbot> The meeting name has been set to 'neurofedora_2020-10-24'
13:01:03 <FranciscoD_> #meetingname NeuroFedora
13:01:03 <zodbot> The meeting name has been set to 'neurofedora'
13:01:32 <FranciscoD_> #info Bot commands: https://fedoraproject.org/wiki/Meeting:Guide#MeetBot_Commands
13:01:33 <FranciscoD_> #info Agenda: https://neuroblog.fedoraproject.org/2022/10/21/next-open-neurofedora-meeting-24-october-1300-utc.html
13:01:48 <FranciscoD_> #topic Introductions and roll call
13:01:50 <FranciscoD_> we'll wait at this topic for 5 minutes, to give everyone a chance to join in
13:02:33 <Penguinpee> .hello gui1ty
13:02:34 <zodbot> Penguinpee: gui1ty 'Sandro .' <gui1ty@penguinpee.nl>
13:03:08 <FranciscoD_> #chair Penguinpee
13:03:08 <zodbot> Current chairs: FranciscoD_ Penguinpee
13:03:32 <FranciscoD_> #chair music
13:03:32 <zodbot> Current chairs: FranciscoD_ Penguinpee music
13:03:36 <music[m]> .hello music
13:03:36 <FranciscoD_> .hello ankursinha
13:03:37 <zodbot> music[m]: music 'Benjamin Beasley' <code@musicinmybrain.net>
13:03:40 <zodbot> FranciscoD_: ankursinha 'Ankur Sinha' <sanjay.ankur@gmail.com>
13:05:41 <FranciscoD_> #topic Tasks from last meeting
13:06:20 <FranciscoD_> #info Last meeting logs: https://meetbot.fedoraproject.org/fedora-neuro/2022-10-10/neurofedora.2022-10-10-13.00.html
13:06:32 <FranciscoD_> #info FranciscoD_ correct link in blog post -> DONE
13:07:08 <FranciscoD_> #info FranciscoD_ fix https://bugzilla.redhat.com/show_bug.cgi?id=2126115 -> DONE
13:07:30 <FranciscoD_> #info FranciscoD_ fix https://bugzilla.redhat.com/show_bug.cgi?id=2115503 -> DONE
13:08:14 <FranciscoD_> (although 1.2.1 came out in the meantime already: https://bugzilla.redhat.com/show_bug.cgi?id=2136474)
13:08:32 <FranciscoD_> #action FranciscoD_ update python-mne to 1.2.1 : https://bugzilla.redhat.com/show_bug.cgi?id=2136474
13:08:33 <FranciscoD_> Penguinpee add link to ML explanation e-mail to bug
13:09:13 <FranciscoD_> Penguinpee: I think this was about the rdflib update etc.
13:09:23 <Penguinpee> Yes. It's done.
13:09:38 <FranciscoD_> there's another action item here about speaking to odml upstream too:
13:09:38 <FranciscoD_> Penguinpee ask odml upstream what their plans for rdflib 6.0.0 are (preferably with a time line)
13:09:39 <FranciscoD_> any progress on these Penguinpee , anything we can do to help?
13:10:28 <Penguinpee> I spoke to them. They have plans implementing rdflib 6.x in the next two month (rough estimate).
13:10:41 <Penguinpee> https://github.com/G-Node/python-odml/issues/417#issuecomment-1280406820
13:10:43 <FranciscoD_> I just found it too: https://github.com/G-Node/python-odml/issues/417#issuecomment-1278789807
13:11:25 <FranciscoD_> ETA is around 2 months, says upstream
13:11:45 <FranciscoD_> +1
13:11:46 <FranciscoD_> should we just wait for them?
13:11:46 <FranciscoD_> #info Penguinpee ask odml upstream what their plans for rdflib 6.0.0 are (preferably with a time line) -> DONE
13:11:57 <FranciscoD_> #info odml upstream have plans implementing rdflib 6.x in the next two month (rough estimate).
13:12:00 <Penguinpee> I think it's not worth introducing an rdflib5 compat package. So, wait, yes.
13:12:45 <Penguinpee> AFAIK odml is the only package depending specifically on rdflib 5.x
13:13:46 <FranciscoD_> Yeh, i agree.
13:14:32 <FranciscoD_> Yeh---although, I'm not sure if the others have been rebuilt etc. to test if they do actually work with rdflib 6.x
13:15:00 <FranciscoD_> I think we discussed in the last meeting that this change should've been announced to the lists since it's a major API change etc. Ideally these need the maintainers to test build all deps to see what the effect of the API change is and so on
13:15:38 <Penguinpee> True. You can action that for me.
13:16:23 <FranciscoD_> music: what do you think? happy to wait for upstream to fix?
13:17:45 <FranciscoD_> the API change announcement? The rdflib maintainers should be doing it
13:18:14 <FranciscoD_> in accordance with FESCo policies: second bullet point here: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#_rawhide
13:18:57 <FranciscoD_> it didn't happen this time, but not much to be done about it now
13:18:58 <FranciscoD_> #agreed +2/-0 wait for upstream to fix odml for rdflib 6.x
13:19:06 <FranciscoD_> OK, those were the action items
13:19:23 <FranciscoD_> #topic Open Pagure tickets
13:19:24 <FranciscoD_> we do have a ticket this time!
13:19:41 <FranciscoD_> #info Tickets to be discussed at meetings should be tagged "next meeting": https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open&tags=S%3A+Next+meeting
13:19:51 <Penguinpee> FranciscoD_: I meant inquiring about not sending it. Reminding them to do it in the future.
13:19:54 <FranciscoD_> We have the one ticket this time: https://pagure.io/neuro-sig/NeuroFedora/issue/533 : Issue #533: Have all neuro-sig packages added to Zuul?
13:20:11 <FranciscoD_> what do folks think about this?
13:21:01 <FranciscoD_> From the looks of it, we'll have to manually generate the list etc. and open a PR. This is unlike Koschei where they have a script that automatically adds any neuro-sig packages to Koschei
13:21:02 <FranciscoD_> Penguinpee: Ah, right, yeh, I can action that to you
13:21:45 <FranciscoD_> #action Penguinpee inquire with rdflib maintainers about API change notification e-mail (as per FESCo guidelines)
13:22:11 <Penguinpee> I just scrolled through the Zuul info. Haven't found time earlier. Looks helpful. We could do a small test with a handful of packages first. Getting acquainted.
13:22:29 <FranciscoD_> back to the Zuul thing----we do have a list of our packages already, so it's certainly doable. I can probably use a vim macro to add the necessary lines etc. and open the PR
13:22:30 <FranciscoD_> do folks think it's worth doing?
13:23:03 <Penguinpee> music[m]: How's your Zuul experience?
13:24:03 <Penguinpee> I think it's worth at least doing a test run with it.
13:24:03 <FranciscoD_> It's very similar to the standard CI that src.fp.o runs, but it runs plenty of extra checks
13:24:04 <FranciscoD_> these are listed here: https://fedoraproject.org/wiki/Zuul-based-ci#Attach_packaging_jobs_for_a_distgit_repository_on_src.fedoraproject.org
13:24:49 <FranciscoD_> so it's not too big a change, and only applies to PRs as I understand it
13:25:06 <Penguinpee> So, that can be chosen per package?
13:25:20 <FranciscoD_> let me check the config, I think we probably already have some packages with Zuul set up---because they're also maintained by others
13:25:49 <Penguinpee> Would/Could that also apply to hotness builds?
13:27:15 <FranciscoD_> I don't think it applies to upstream release monitoring builds. It's limited to src.fp.o PRs, and hotness doesn't open those
13:28:01 <FranciscoD_> It doesn't feel like something we should definitely do, so maybe we can add a few now and then, and maybe encourage that all new packages be added?
13:28:48 <Penguinpee> That would be possible. I could add my packages from the plotnine stack for starters.
13:29:27 <Penguinpee> Some of them are rather actively maintained with frequent updates and changes.
13:30:16 <FranciscoD_> +1, let's do that
13:30:26 <Penguinpee> +1
13:30:53 <FranciscoD_> #agreed Gradually add neuro-sig packages to Zuul, and encourage maintainers to add all new packages to Zuul from now on
13:31:26 <FranciscoD_> all tickets done
13:31:26 <FranciscoD_> #topic Package health check
13:31:50 <FranciscoD_> #info Neuro-sig packager dashboard is here:  https://packager-dashboard.fedoraproject.org/dashboard?groups=neuro-sig
13:32:45 <Penguinpee> Link in the mail was ?user=neuro-sig
13:33:05 <Penguinpee> That doesn't work obviously.
13:34:30 <FranciscoD_> #info We prioritise FTBFS/FTI bugs, then other bugs and updates, and then anything else
13:34:35 <FranciscoD_> Ah, I need to correct the e-mail template too then
13:34:43 <FranciscoD_> #action FranciscoD_ correct dashboard link in e-mail
13:35:00 <FranciscoD_> yeh, it used to, and then they made a release where the URL format changed so it broke
13:35:47 <Penguinpee> I see. On to the FTBFS/FTI...
13:36:32 <FranciscoD_> #info we've got a few FTBFS bugs, but quite a few of them have fixes in -testing, so they should be fixed once the F37 freeze is over and these updates hit stable
13:37:10 <music[m]> Sorry, I greeted everyone and then ran off.
13:37:36 <Penguinpee> Anything that still needs looking into? It's not quite clear on the board.
13:38:05 <FranciscoD_> no worries, we've just been going through the agenda :)
13:38:16 <Penguinpee> music[m]: how rude (jar jar binks style)
13:39:12 <FranciscoD_> pybids is one that's been around for a while. New version needs new packages, so I'm working on those.
13:40:39 <music[m]> My experience with Zuul is mostly positive. It’s helpful when reviewing PR’s, because it checks some things that otherwise might not be checked outside of a package review, and it stands a chance of catching some FTI-type issues ahead of time. But there are also a noticeable number of noisy or false positive findings.
13:40:56 <Penguinpee> What's the difference between a Koschei FTBFS and a regular (Koji?) one?
13:41:52 <music[m]> Since by default you can still merge a PR that Zuul doesn’t like, I think it’s generally helpful. I haven’t been motivated enough to get around to adding all of my packages to it.
13:41:57 <Penguinpee> Thanks for the info music[m]. I might have some use for using Zuul on a non-related package. Big upgrade, old neglected package.
13:42:58 <music[m]> Koschei does scratch builds. So it can detect FTBFS before someone tries to rebuild the package.
13:42:58 <Penguinpee> Sounds more like a case by case decision and especially useful for group maintenance and/or big upgrades / volatile packages.
13:43:08 <FranciscoD_> +1
13:44:16 <Penguinpee> What's the basis for Koschei to do a scratch build? Something in the dependency chain that was rebuild?
13:45:15 <music[m]> Like foo BuildRequires bar 1.x, someone updates bar to 2.0, foo is now FTBFS but nothing breaks until a mass rebuild or a foo update. Koschei indicates the problem as soon as it gets around to test-rebuilding foo, and the UI shows which dependencies were updated since the last successful rebuild.
13:45:59 <FranciscoD_> they're all just extra tools to help us maintain the packages regularly, rather than for us to run around fixing lots of broken packages when the mass rebuild happens
13:46:26 <music[m]> I think that’s right, plus a priority queue to allocate limited resources (so there might not be a scratch build for every dependency change).
13:46:44 <FranciscoD_> Yeh, from the wiki page: https://fedoraproject.org/wiki/Koschei  "tracks package dependency changes in Fedora Rawhide and rebuilds packages whose dependencies change too much."
13:47:00 <music[m]> Here’s an example of Koschei detecting a problem: https://koschei.fedoraproject.org/package/asv
13:48:00 <music[m]> That showed up on my dashboard, so I filed https://bugzilla.redhat.com/show_bug.cgi?id=2137127 and https://src.fedoraproject.org/rpms/asv/pull-request/2. Otherwise it would have been noticed at the next upstream update or mass rebuild.
13:48:57 <FranciscoD_> +1
13:49:02 <Penguinpee> Thanks. I get the picture. Need to make use of it.
13:49:07 <Penguinpee> music++
13:49:07 <zodbot> Penguinpee: Karma for music changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
13:49:22 <music[m]> Here’s an example of a PR on a Zuul-enabled package: https://src.fedoraproject.org/rpms/python-hatchling/pull-request/25
13:50:17 <FranciscoD_> lots of extra checks there, no harm having the info
13:50:52 <FranciscoD_> so yeh, let's try and enable them for new packages, and wen gradually add our ~300 packages to zuul as we go too
13:50:52 <music[m]> I agree. Most of the time, if Zuul is unhappy, I learn something useful from it.
13:51:04 <FranciscoD_> I'll do a mass addition at some point perhaps, after the python-sig PR has been merged
13:51:38 <FranciscoD_> #topic Open package reviews
13:51:51 <Penguinpee> Definitely useful. Especially for packages a lot of other packages depend on. Same wrt Koschei.
13:51:59 <FranciscoD_> #info Please see the neuro-sig review tracker bug here: https://bugzilla.redhat.com/show_bug.cgi?id=fedora-neuro
13:52:07 <FranciscoD_> Penguinpee: I saw the review swap e-mails etc---are all your reviews doe?
13:52:07 <FranciscoD_> *done?
13:52:46 <FranciscoD_> yeh, looks like it
13:53:29 <Penguinpee> Yeah, now have to wait for the dependencies to land in stable before pushing.
13:53:32 <FranciscoD_> I have a very trivial review for python-setup-meta if someone has 5 minutes to do that :)
13:53:32 <FranciscoD_> https://bugzilla.redhat.com/show_bug.cgi?id=2136778
13:54:39 <Penguinpee> How urgent? I probably manage this week, but not today.
13:54:44 <FranciscoD_> the dep chain is pybids -> formulaic -> interface-meta -> setup-meta
13:54:44 <FranciscoD_> so I've got another two to go before we can update pybids, and fix its FTBFS
13:56:01 <FranciscoD_> Penguinpee: for rawhide, that should happen very qucikly. For others, you can use side tags or build root overrides
13:56:02 <FranciscoD_> and then push all the deps in one update
13:56:22 <FranciscoD_> setup-meta isn't too urgent, I'll e-mail out for review swaps when i have a few more collected
13:56:47 <FranciscoD_> Penguinpee: https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#multiple_packages
13:57:55 <FranciscoD_> ^ one doesn't have to wait for deps to hit stable, one can use side tags and build root overrides. My understanding is that side tags are preferred nowadays
13:58:27 <Penguinpee> Rawhide is done. Except for plotnine. Will get this out this week. I will look into the side tags / overrides to speed things up. It should all be available by the time f37 is released.
13:58:58 <FranciscoD_> the python-pyABF review is still open. That update got unpushed because it broke createrpo, but we'd fixed that. I'll check to see if we pushed another update etc. and close that ticket
13:59:18 <FranciscoD_> #action FranciscoD_ check python-pyABF update and close review ticket
13:59:19 <FranciscoD_> that's all for our reviews
13:59:45 <FranciscoD_> #topic CompNeuro image generation check
14:00:02 <FranciscoD_> #info https://koji.fedoraproject.org/koji/packageinfo?packageID=30691
14:00:11 <Penguinpee> ⏰
14:00:28 <FranciscoD_> #info rawhide build failed recently, but it isn't a neuro-sig issue. Something broken in the workstation packages, so the build will be fixed when that is
14:01:21 <Penguinpee> Do we (neuro-sig) get mails when the compose fails or would that be an option?
14:01:25 <FranciscoD_> #info Tickets for failed builds are filed here, if anyone wants to subscribe to the repo etc: https://stg.pagure.io/releng/failed-composes/issues
14:01:56 <FranciscoD_> We've hit the hour mark, so let's stop here today
14:01:56 <FranciscoD_> next meeting again in 2 weeks, same time
14:02:01 <FranciscoD_> #info Next meeting in 2 weeks, same time
14:02:01 <FranciscoD_> #endmeeting