Re: Release rpkg-1.66 and fedpkg-1.44

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 13. 03. 23 21:53, Otto Liljalaakso wrote:
Miro Hrončok kirjoitti 9.3.2023 klo 13.17:
On 09. 03. 23 10:05, Otto Liljalaakso wrote:
Miro Hrončok kirjoitti 8.3.2023 klo 17.29:

However, maybe it does not work as I expected?

[python-setuptools (bundles %)]$ fedpkg prep
Not downloading already downloaded setuptools-65.5.1.tar.gz
Could not execute prep: Could not find the release/dist from branch name bundles
Please specify with --release

Right, it looks like you interpreted "outside of an established dist-git repository" to cover the case where you do have a Git repository, but are in a local branch with a custom name. Unfortunately, currently only the case where there is no Git repository at all is covered.

Mea culpa. I assumed that's the case because I don't use fedpkg outside of git much.

I presume that in your example you intend to eventually create a pull request. Fedpkg should have a great support for that as well, but a bit (just a bit) more work is needed to cover that case. I suppose that it would be enough to, instead of printing the error you saw, fall back to using the same default mechanism that is used for the no-Git case. I will take a look at some point — unless somebody beats me to it, of course.

I took a look at this, and making '--release rawhide' for unknown branches is very easy [1]. I did not create a pull request yet, because I am a bit unsure if this is a good idea. My assumption is still that the vast majority of unknown branches are created for Rawhide pull requests. But for the ones that are for some other purpose, the default behavior changes from asking to be explicit with --release, to doing the wrong thing.

There would be log output notifying about defaulting to 'rawhide', and the --release parameter could still be used to select the correct release. So maybe convenience for the majority case weighs more than some risk for the minority case?

I think so.

This can even be improved to make f38-foo default to f38 etc. That way, I would hardly ever need to use --release except for cases where I want to test-build foo on both rawhide and f38.

If you worry about the risks, I suppose fedpkg build (without --scratch) might abort without --release when the branch is not "proper". All the other use cases i could think of should be safe.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux