python-psutil already has an exception.

Are the pygobject3 maintainers aware of this exception request?

@mattrose ?

I don't think so. I haven't consulted with them. Should I? Looking over the list of other python2 exceptions I don't think any other projects have such a requirement

Should I?

It would be a good thing, yes.

Looking over the list of other python2 exceptions I don't think any other projects have such a requirement

They all do.

Sorry, I meant a requirement for gobject, not a requirement to consult :), sorry for the miscommunication

Oh, now I understand, sorry. Sugar does have that requirement, but no communication happened with pygobject3 either, as far as i can tell from the ticket: https://pagure.io/fesco/issue/2267

What is the best way to get in touch with the maintainer? Is the last committer in the changelog a good place to start? That would be klember@redhat.com

https://src.fedoraproject.org/rpms/pygobject3 lists 3 maintainers: @walters @johnp and @nacho.

You can e-mail them at pygobject3-maintainers@fedoraproject.org

In reality, however, @kalev indeed seems to be maintaining the package instead.

pygobject upstream is planning to drop python2 support in Fedora 33 timeframe (https://mail.gnome.org/archives/distributor-list/2019-October/msg00002.html). I intend to follow upstream there and drop pygobject python2 support in Fedora as well then.

For Fedora 32, I am fine with keeping pygobject python2 support alive.

That's good news. I'm still attacking the twin avenues of trying to get upstream to release a version of terminator that is compatible with python3, and developing a patch set to have the last release tarball work with python3. Apparently Debian maintains a patch set that does this.

If python2-gobject and python2-psutil are supported for Fedora 32 this gives me more opportunity to get this properly done

https://sources.debian.org/patches/terminator/1.91-4/python3.diff/
is the patch in question.

Maybe we could apply the same patch in Fedora and forgo the python2 exception? The patch is large, but it seems to be just a removal of a file and some automatic fixes generated with 2to3.

While I haven't looked at that patch in depth, having run a basic 2to3 run of the terminator code and gotten the result to run, it introduces a lot of regressions, that we would have to deal with as fedora bug reports.

As a last resort we could do something like this, but I'd rather go for an extension to give us time to do a proper job of it, rather than rushing this and causing ourselves more headaches down the line.

I'm going to do some more work on incorporating bugfixes from the launchpad bug in question this weekend or next, and try and get something in, but if I'm not comfortable that the resulting code won't result in a flood of bug reports, then I'd rather have the exception.

@mattrose did you get a chance to try this over the weekend?

@mattrose ?

@mattrose ?

Sorry, I haven't had the spare cycles necessary to look at all the patches and coerce them into something that I'm comfortable won't generate a bunch of problems. I basically need a couple of spare hours on a week-end to do this, and I just haven't had that. Hopefully this Sunday?

Amazingly enough, I did have time to get a patch in order today. I'm just gonna check with my co-maintainer before I submit an update. Has F32 branched yet, or can I just throw it in Rawhide and trust that the new version will be picked up by F32.

f32 doesn't branch until 2020-02-11 ( https://fedorapeople.org/groups/schedule/f-32/f-32-key-tasks.html ), so yeah, landing in rawhide now will mean it will be in f32.

All checked in. We can close this as I don't need the exception anymore. Can I close https://bugzilla.redhat.com/show_bug.cgi?id=1737872 as well?