13:00:27 <FranciscoD_> #startmeeting NeuroFedora - 2022-10-10
13:00:27 <zodbot> Meeting started Mon Oct 10 13:00:27 2022 UTC.
13:00:27 <zodbot> This meeting is logged and archived in a public location.
13:00:27 <zodbot> The chair is FranciscoD_. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
13:00:27 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:00:27 <zodbot> The meeting name has been set to 'neurofedora_-_2022-10-10'
13:00:32 <FranciscoD_> #meetingname neurofedora
13:00:32 <zodbot> The meeting name has been set to 'neurofedora'
13:00:49 <FranciscoD_> #info Please refer to this wiki page for bot commands: https://fedoraproject.org/wiki/Meeting:Guide#MeetBot_Commands
13:00:56 <FranciscoD_> #info Agenda is published on the blog here: https://neuroblog.fedoraproject.org/2022/10/09/next-open-neurofedora-meeting-10-october-1300-utc.html
13:01:09 <FranciscoD_> #topic Introductions and roll call
13:01:16 <FranciscoD_> we usually wait ~5 minutes here for everyone to join in
13:03:44 <Penguinpee> .hello gui1ty
13:03:45 <zodbot> Penguinpee: gui1ty 'Sandro .' <gui1ty@penguinpee.nl>
13:03:59 <music[m]> .hello music
13:04:00 <zodbot> music[m]: music 'Benjamin Beasley' <code@musicinmybrain.net>
13:05:16 <FranciscoD_> hi music Penguinpee
13:05:27 <FranciscoD_> #chair music Penguinpee
13:05:27 <zodbot> Current chairs: FranciscoD_ Penguinpee music
13:05:52 <Penguinpee> music[m]: Busy weekend? ;)
13:05:57 <FranciscoD_> #topic Tasks from last meeting
13:06:35 <FranciscoD_> #info Minutes from last meeting are here: https://meetbot.fedoraproject.org/fedora-neuro/2022-09-26/neurofedora.2022-09-26-13.00.html
13:06:46 <FranciscoD_> #action FranciscoD_ correct link in blog post
13:06:59 <FranciscoD_> Action items are at the end of the minutes
13:07:23 <FranciscoD_> FranciscoD_ look at python-pyABF build issues -> done with help from releng and music
13:07:39 <FranciscoD_> there was a non-printable character in one of the commits that made createrepo crash etc.
13:08:28 <music[m]> Penguinpee: Sometimes a little time goes a long way…
13:08:29 <FranciscoD_> #info FranciscoD_ look at python-pyABF build issues -> DONE
13:08:45 <Penguinpee> "there was a non-printable character..." <- that's been haunting me in the weekend as well, albeit in a script.
13:09:27 <FranciscoD_> yeh, it wasn't showing in `git log` etc., so I had to do a rebase to just figure out where it was
13:09:40 <FranciscoD_> such tiny unexpected things that make software fail ;)
13:09:58 <FranciscoD_> FranciscoD_ update python-mne: https://bugzilla.redhat.com/show_bug.cgi?id=2115503 -> the current release doesn't work with the new matplotlib, the next one will, so I'll wait for that and then update. I've made a note in the bug
13:10:29 <FranciscoD_> #info FranciscoD_ update python-mne: https://bugzilla.redhat.com/show_bug.cgi?id=2115503 -> WIP: the current release doesn't work with the new matplotlib, the next one will, so I'll wait for that and then update. I've made a note in the bug
13:10:38 * Penguinpee ponders how music[m]'s quote might be an expression of speed
13:12:05 <FranciscoD_> #info FranciscoD_ fix https://bugzilla.redhat.com/show_bug.cgi?id=2126115 -> WIP: It built fine in mock and then failed in koji on i686, so gotta check what's up
13:12:45 <FranciscoD_> a test failing: https://kojipkgs.fedoraproject.org//work/tasks/4724/92844724/build.log
13:13:00 <FranciscoD_> #action FranciscoD_ fix https://bugzilla.redhat.com/show_bug.cgi?id=2126115
13:13:18 <FranciscoD_> should also action the previous one again..
13:13:23 <FranciscoD_> #action FranciscoD_ fix https://bugzilla.redhat.com/show_bug.cgi?id=2115503
13:13:36 <FranciscoD_> #info FranciscoD_ make pynn excludearch s390x -> DONE
13:13:48 <FranciscoD_> #info FranciscoD_ also add excludearch for elephant and efel and epyviewer -> DONE
13:14:51 <FranciscoD_> this is all because pyedflib doesn't support s390x, so everything that depends on it (recursively) needs to excludearch s390x too: https://src.fedoraproject.org/rpms/python-pyedflib/blob/rawhide/f/python-pyedflib.spec#_24
13:16:16 <FranciscoD_> Penguinpee keep an eye on https://bugzilla.redhat.com/show_bug.cgi?id=2113639 and take over bug if we don't hear from MeWjOr in a week
13:16:21 <FranciscoD_> Penguinpee ^
13:16:45 <Penguinpee> Yep. I sent a mail to the mailing list explaining what's going on.
13:16:47 <FranciscoD_> ah, this is the one related to the rdflib packages
13:17:02 <FranciscoD_> I saw your e-mail, let me take a look at it again
13:17:06 <Penguinpee> Indeed.
13:17:36 <FranciscoD_> https://lists.fedoraproject.org/archives/list/neurofedora@lists.fedoraproject.org/message/WMSD5KMHJNTSEUS7SAEXVJT4GV7M32FR/
13:17:48 <Penguinpee> I could/should update the bug with the info.
13:18:40 <Penguinpee> FranciscoD_: You can action it for me again to update the bug.
13:18:46 <FranciscoD_> yeh, a link to the ML thread will do I guess
13:19:01 <FranciscoD_> #action Penguinpee add link to ML explanation e-mail to bug
13:19:21 <FranciscoD_> Penguinpee: is there an issue for upstream to update to v6.0.0?
13:20:04 <Penguinpee> Yes. It's in the mail. One of the dependencies pinned rdflib to 5.0 for that reason.
13:20:55 <FranciscoD_> OK, I see things like this: https://github.com/G-Node/python-odml/issues/417
13:21:03 <FranciscoD_> "The rdflib library is required for conversion of odml to its RDF specific format. Since this library has caused multiple issues in the past and is still causing issues to this date it might be worth looking into moving RDF dependent code from the odml core library into a dedicated sub-library."
13:21:10 <FranciscoD_> sounds like bundling perhaps, but not much we can do
13:21:31 <Penguinpee> It's python-rdflib-jsonld that pinned the version of rdflib to 5.0.0, IIRC.
13:22:03 <FranciscoD_> odml is doing it too now: https://github.com/G-Node/python-odml/blob/v1.5.2/CHANGELOG.md#pinning-rdflib-version-to-500-until-further-notice
13:22:04 <Penguinpee> No, it's python-odml. python-rdflib-jsonld is obsoleted by the update to 6.x
13:22:10 <FranciscoD_> yeh
13:22:27 <FranciscoD_> I don't think there's much we can do here tbh, other than wait for upstream
13:22:36 <FranciscoD_> a path is to fix odml for the new API, but that may be quite a bit of work
13:22:37 <Penguinpee> I put it in the mail and erased it from short term memory.
13:23:05 <Penguinpee> Upstream needs to fix it, I'd say. They are pinning.
13:23:44 <FranciscoD_> Yeh, but that's easier said than done. If rdflib is making frequent major releases with breaking APIs, I can see odml upstream getting a bit fedup XD
13:24:16 <FranciscoD_> https://github.com/RDFLib/rdflib#versions--releases suggests to me that both 6.0.0 and 5.0.0 are in development
13:24:29 <FranciscoD_> or being maintained
13:24:33 <Penguinpee> Upstream: "Due to major breaking changes introduced in the upgrade of rdflib 5.0.0 to 6.0.0, the rdflib version is pinned to 5.0.0 until the breaking code has been fixed."
13:25:08 <Penguinpee> That's from python-odml upstream.
13:25:13 <FranciscoD_> Yeh, but the odml ticket I linked to suggests that this has happened before---and so they're thinking of keeping their own rdf related code instead of relying on rdflib
13:25:42 <Penguinpee> Ah. I see.
13:25:43 <FranciscoD_> If both rdflib 5 and 6 are supported, I wonder if we can have them both in Fedora? 🤔
13:25:53 <FranciscoD_> I expect not---their files will probably conflict etc.
13:26:10 <Penguinpee> We can always ask the maintainers of python-rdflib.
13:26:54 <FranciscoD_> looking at their file lists now
13:27:13 <Penguinpee> May be have them conflicting each other, so you at least get to choose. Not sure how many packages depend on rdflib.
13:28:19 <music[m]> either way you have a conflict on ownership of `%{python3_sitearch}/rdflib` or similar
13:28:29 <FranciscoD_> yeh, music , that's what I was looking at
13:28:33 <music[m]> normally that kind of conflict is not ok except for `-devel` compat packages
13:28:49 <music[m]> https://docs.fedoraproject.org/en-US/packaging-guidelines/Conflicts/#_acceptable_uses_of_conflicts
13:29:11 <music[m]> it might be possible to make a compat package `rdflib5` with everything renamed, and patch to use that
13:29:41 <FranciscoD_> let me quickly look at what depends on rdflib---that'll give us an idea of the number of packages affected by this
13:29:43 <music[m]> or bundle in `odml`… but that’s harder for a C extension that has to be built
13:30:16 <music[m]> wait, actually, rdflib is noarch/pure-Python
13:30:33 <Penguinpee> That would be quite a burden to maintain. AFAIK, it's only odml indirectly depending on rdflib5. How important is odml?
13:30:35 <music[m]> still, yuck
13:31:13 <Penguinpee> Haven't checked what depends on odml.
13:31:35 <music[m]> anyone know what the breaking changes actually are?
13:32:03 <music[m]> https://github.com/RDFLib/rdflib/releases/tag/6.0.0 doesn’t indicate much other than dropped support for old pythons
13:32:14 <FranciscoD_> https://paste.centos.org/view/d0776b26
13:33:43 <Penguinpee> 6.0.0 now includes jsonld, which wath in a compat package before.
13:33:48 <FranciscoD_> their link to 6.0.0 docs is a 404: https://rdflib.readthedocs.io/en/6.0.0/
13:33:53 <Penguinpee> *was
13:34:01 <Penguinpee> https://github.com/RDFLib/rdflib/blob/main/CHANGELOG.md
13:34:18 <Penguinpee> It's quite long. Only skimmed through it.
13:35:46 <FranciscoD_> This is the bit we care about: https://github.com/RDFLib/rdflib/blob/main/CHANGELOG.md#2021-07-20-release-600
13:35:51 <Penguinpee> They dropped support for Python2 and Python < 3.7. JSON-LD now included. Simplification of some functions.
13:36:17 <FranciscoD_> they don't mark API breaks, though
13:36:33 <FranciscoD_> for a major release, ideally, they should list API breaks.
13:36:37 <FranciscoD_> Or have a "porting to 6.x" document or something.
13:36:42 <Penguinpee> The inclusion of JSON-LD is what breaks odml.
13:36:55 <FranciscoD_> Ah, right, why's that?
13:37:32 <FranciscoD_> as in, what was odml using before for json-ld?
13:37:33 <Penguinpee> It's in the mail. It was previously provided by python-rdflib-jsonld.
13:38:10 <FranciscoD_> yeh, but did they just take python-rdflib-jsonld and throw it into rdflib as a sub-module? Would you know
13:38:22 <Penguinpee> That package conflicts with python-rflib >= 6.0
13:38:22 <FranciscoD_> because in that case, all we may need to do is patch imprts
13:38:33 <FranciscoD_> s/imprts/imports/
13:39:04 <FranciscoD_> python-rdflib >6.0.0 should obsolete it, no?
13:39:34 <Penguinpee> Yes, as it's now obsolete for f37 and up, I believe.
13:40:03 <Penguinpee> But odml pinned rdflib to 5.0.0 for a reason, I'd think. Or do you think we can just ignore that?
13:40:54 <FranciscoD_> if the tests etc. pass, we can ignore it. If they don't, we can't :)
13:41:04 <music[m]> Furthermore, if python-rdflib-jsonld conflicts with the version of python-rdflib that is in F37+, it sounds like it should be retired in Rawhide.
13:41:08 <Penguinpee> According to the comments in the spec files maintainers knew this was coming. They prepared for it.
13:41:23 <music[m]> Looks like (only) python-owl_rl still depends on python3-rdflib-jsonld directly.
13:41:30 <Penguinpee> The tests blew up in my simple scratch build.
13:41:55 <FranciscoD_> yeh, and I guess I can run a quick re-build of all rdflib related packages to see if any others blow up with the 6.0.0 version
13:42:02 <FranciscoD_> they may just not have been re-built since the update
13:42:19 <FranciscoD_> which makes me think---should this API change not need to be announced?
13:43:10 <FranciscoD_> I mean, it's python so packages may not need to be re-built in the same way as when a shared library changes soversion, but a backwards incompatible API change should perhaps still be announced so maintainers relying on the package are aware 🤔
13:43:16 <Penguinpee> That's what I thought. But I wanted to discuss this first.
13:44:24 <Penguinpee> They were aware already, going by the comments in the spec. python-rdflib-jsonld had the Conflicts: in there before 6.0 was released (in Fedora).
13:44:35 <music[m]> Yes, https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#_rawhide applies. An update with a breaking API change should have been announced to the `devel` list with a week’s notice.
13:45:49 <FranciscoD_> music: maybe we need to point this out then.
13:46:06 <FranciscoD_> I think in general python package maintainers (myself included sometimes) don't really consider package updates to be "breaking" in the same way as we do shared objects, but that's something that needs changing
13:46:17 <Penguinpee> It's a mixed bag, if you ask me.
13:46:23 <FranciscoD_> yeh
13:46:32 <FranciscoD_> let's decide on what to do here
13:46:35 <FranciscoD_> wait for upstream to fix?
13:46:48 <FranciscoD_> dive into and try to fix the package for 6.0.0 (and send patches upstream)?
13:46:54 <FranciscoD_> other options?
13:48:12 <Penguinpee> I think, seeing the relatively small impact, we could take this to the python-rdflib maintainers directly. I can give it a try making it work with current rdflib
13:48:50 <FranciscoD_> OK, but do be aware that you'll need to dive into the code and understand it etc. to come up with fixes
13:49:04 <FranciscoD_> it can sometimes be quite the undertaking :(
13:49:11 <Penguinpee> We should at least consult odml upstream, asking about their plans regarding rdflib
13:49:16 <FranciscoD_> depending on what the fixes are---but you won't know them without diving in first
13:49:29 <FranciscoD_> let's maybe do that first---speak to odml upstream and ask what their plans are
13:49:39 <FranciscoD_> and maybe the timeline?
13:49:54 <FranciscoD_> if they have plans to fix it in a short period of time, we can just wait for them?
13:50:25 <Penguinpee> Yeah. I'd prefer that. Lots of other things on my plate atm.
13:50:38 <FranciscoD_> sounds good
13:50:52 <Penguinpee> Shall I?
13:51:02 <FranciscoD_> Yes, that'll be great
13:51:19 <FranciscoD_> we can discuss their response in the next meeting and take it from there
13:51:31 <Penguinpee> Action, please! 🎬
13:51:39 <FranciscoD_> #action Penguinpee ask odml upstream what their plans for rdflib 6.0.0 are (preferably with a time line)
13:51:48 <FranciscoD_> there we go, thanks very much for looking into this
13:51:55 <Penguinpee> np
13:51:58 <FranciscoD_> sometimes we end up with these updates that are just time sinks :(
13:52:45 <FranciscoD_> we've used up quite a bit of our time, so I'll do the quick topics first
13:52:59 <FranciscoD_> #topic Open pagure tickets
13:53:03 <FranciscoD_> #info No open pagure tickets
13:53:12 <FranciscoD_> #topic Comp-neuro Fedora ISO status check
13:53:21 <FranciscoD_> #info https://koji.fedoraproject.org/koji/packageinfo?packageID=30691 -> All green, looks good
13:53:38 <FranciscoD_> #topic Open reviews check
13:53:49 <FranciscoD_> #info 6 open reviews at https://bugzilla.redhat.com/show_bug.cgi?id=fedora-neuro -> folks, please take these on and review
13:54:44 <FranciscoD_> #info Please feel free to ask for review swaps on the -devel list too. Great way of working with more package maintainers :)
13:54:45 <FranciscoD_> Penguinpee: I think a lot of these are plotnine related, right? I'll try and review them this week too
13:54:58 <FranciscoD_> #action neuro-sig review open review tickets: https://bugzilla.redhat.com/show_bug.cgi?id=fedora-neuro
13:55:03 <Penguinpee> I have five submissions for plotnine, indeed.
13:55:27 <FranciscoD_> #topic Package health check
13:55:32 <FranciscoD_> I'm afraid we only have 5 minutes left, so we won't be able to do a complete check this week
13:56:25 <davdunc[m> .hi davdunc
13:56:25 <zodbot> davdunc[m: Error: Missing "]".  You may want to quote your arguments with double quotes in order to prevent extra brackets from being evaluated as nested commands.
13:56:43 <FranciscoD_> #info Packages look in good health---a few FTBFS/FTI bugs: folks please work on these and prioritise them, especially if they affect current releases (f36, f37)
13:56:57 <FranciscoD_> #chair davdunc
13:56:57 <zodbot> Current chairs: FranciscoD_ Penguinpee davdunc music
13:56:58 <davdunc[m> .hello davdunc
13:56:59 <FranciscoD_> hi davdunc !
13:56:59 <davdunc[m> thanks.
13:56:59 <zodbot> davdunc[m: davdunc 'David Duncan' <davdunc@amazon.com>
13:57:30 <Penguinpee> davdunc[m: What happened to the closing bracket?
13:57:41 <davdunc[m> :) just wanted to drop in and say that I'm happy to work on the citation ticket amongst other things.
13:57:59 <davdunc[m> Penguinpee: If I could figure it out, I would add it back!
13:58:11 <FranciscoD_> #info Quite a few packages are impacted by python-cached_property being orphaned, but it's already been take up by admawill so we're good
13:58:21 <FranciscoD_> thanks davdunc
13:58:31 <Penguinpee> 🤣
13:58:39 <FranciscoD_> let me get to open floor for 2 minutes XD
13:58:40 <FranciscoD_> #topic Open floor
13:58:56 <FranciscoD_> #info davdunc is referring to this mindshare ticket: https://pagure.io/mindshare/issue/93
13:59:09 <FranciscoD_> adamwill++
13:59:25 <FranciscoD_> re: the pagure ticket---it's for folks to be able to cite Fedora when its used in scientific work
13:59:55 <FranciscoD_> at the moment, we ask folks to cite the posters we presented at CNS for CompNeuro: https://docs.fedoraproject.org/en-US/neurofedora/citations/
14:00:09 <FranciscoD_> but it'll be good to have a citation per release so folks can cite the exact release that they used
14:01:00 <FranciscoD_> OK, that's all we have time for today :)
14:01:24 <FranciscoD_> thanks for coming Penguinpee music davdunc : great to get together and go through all our tasks, as usual :)
14:01:27 <FranciscoD_> #endmeeting