fedora-infrastructure

#6593 Bugzilla default assignee wrong for mock
Closed: Fixed Opened by tmz.

Closed: Fixed
Reopen Issue

A bug was filed against the mock package today and it was assigned to me by default. I tried to edit the assignee and checked the "Reset Assignee to default for component" box, which confirmed that I was the default assignee.

I'm not a maintainer of mock. But I have forked the repo in the past. I don't know if this bug is in the bugzilla sync script or elsewhere, where a pagure query to src.fpo isn't setting forks=false.

(Perhaps a better default in pagure would be forks=false and then fixing any queries which actually want to include forks?)

The same thing has happened for me, too--but for tomcat and policycoreutils. And I just raised bug 1528329 against Bugzilla reporting the problem.

0001-distgit-ignore-forks-when-syncing-pagure-to-bugzilla.patch may be the proper fix, but I am not at all familiar with the pagure-sync-bugzilla.py script, so it needs a closer look from someone who does.

And looks like Dusty Mabe now maintains Anaconda: https://bugzilla.redhat.com/show_bug.cgi?id=1528215#c4

Thanks Dusty! ;-)

And looks like Dusty Mabe now maintains Anaconda: https://bugzilla.redhat.com/show_bug.cgi?id=1528215#c4
Thanks Dusty! ;-)

haha - sweet. I'll just go ahead and slip all those changes I wanted in now :)

Seen several other cases like this - systemd bug getting assigned to Frederic Lepied and an selinux-policy bug to someone equally inappropriate (I forget who).

This was fixed in the script yesterday, unfortunately the script was broken by re-adding the 'tests' namespace and hasn't yet run since then.

We should get it sorted out today, sorry for the troubles...

ok, Should be all fixed up now. Sorry for the problem...

Metadata Update from @kevin:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.