fedpkg

#231 Cloning from "container/foo", "modules/foo" or "tests/foo" should not create [bz] or [sendmail] config
Closed: Fixed by onosek. Opened by tibbs.

Closed: Fixed
Reopen Issue

Again, I'm not sure if this is supposed to be supported, but you can do things like:

fedpkg clone container/httpd
fedpkg clone modules/bind
fedpkg clone tests/shell

In each case, the repository is checked out as appropriate, but the git config is filled in with information that isn't quite correct.

For containers, default-product should be "Fedora Container Images". For modules it's "Fedora Modules". For tests... the [bz] stanza probably shouldn't be there at all.

For containers, the mail address appears to take the form container-foo-owner@fedoraproject.org. For modules it's module-foo-owner@fedoraproject.org (which means that package owner aliases can conflict with these for extra fun). Tests don't get owner aliases.

@tibbs Hi, is there any document for this git config I can reference? Thanks.

I honestly don't know. I'm not sure why those entries get set, or what might use them. All I know is that the values which are set currently aren't correct. I looked in bugzilla to find the correct components to use, and I asked @nirik about the owner aliases.

Edit: I realize that the title is quite wrong; I had entered it before I realized that it's only things in the "tests" namespace which won't have a bugzilla component or owner email alias set up.
Edited by tibbs

@tibbs Could you point out where to get the correct components in Bugzilla? I don't know about that.

I just went to bugzilla.redhat.com, clicked 'Search', picked 'Fedora' and looked at the Product list.

(The [bz] section is used by git-bz.)

Commit 6ee8b537 fixes this issue

Commit ebba627d relates to this ticket

Metadata Update from @onosek:
- Issue set to the milestone: 1.38
Metadata
None
None
None
None
None
Related Pull Requests
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.