Hi everybody, we've scheduled the rpmautospec plugin to be deployed into production for tomorrow, from 14:00 UTC on. This means installing the relevant packages and restarting kojid processes on the builders, which will restart any tasks which are being processed at that time, i.e. expect delays for builds in-flight at the time. We'll announce when the deployment is done. Cheers, Nils -- Nils Philippsen "Those who would give up Essential Liberty to Software Engineer purchase a little Temporary Safety, deserve neither Red Hat Liberty nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: D0C1 1576 CDA6 5B6E BBAE 95B2 7D53 7FCA E9F6 395D

So ... I've now been able to try this out, since exam season is finally over (sigh), and - after one case of "RTFM" - this stuff seems to ... just work. Thanks a lot for working on this feature, it's going to save me *so much time* maintaining Rust packages.

Now that this is in the Koji builders... would this be sufficient to have it enabled for EPEL8 specs as well? - branch and build python-rpmautospec for EPEL8 - add Requires: rpmautospec-rpm-macros to epel-rpm-macros in EPEL8 Given that EPEL8 will be around for a while, it sounds like it would be of benefits if we can keep the same spec between Rawhide and it. e.g. python-TestSlide now uses rpmautospec in the Rawhide branch, and so any update in EPEL8 will have to diverge.

Hi everybody, we've scheduled the rpmautospec plugin to be deployed into production for tomorrow, from 14:00 UTC on. This means installing the relevant packages and restarting kojid processes on the builders, which will restart any tasks which are being processed at that time, i.e. expect delays for builds in-flight at the time. We'll announce when the deployment is done. Cheers, Nils

Il 10/07/21 11:07, Robert-André Mauchin ha scritto: > I haven't followed the dev of this project closely, is there a > guide for packagers to explain how it works and how to integrate it > to our workflow? > > Best regards, > > Robert-André I think it's https://pagure.io/docs/fedora-infra/rpmautospec/

On 6/16/21 6:03 PM, Nils Philippsen wrote: > Hi everybody, > > we've scheduled the rpmautospec plugin to be deployed into production > for tomorrow, from 14:00 UTC on. > > This means installing the relevant packages and restarting kojid > processes on the builders, which will restart any tasks which are being > processed at that time, i.e. expect delays for builds in-flight at the > time. > > We'll announce when the deployment is done. > > Cheers, > Nils > What is the situation wrt new packages? Should we enforce the use of rpmautospec during reviews or is it completely optional?

On 17.07.21 00:59, Miro Hrončok wrote: > On 16. 07. 21 19:58, Robert-André Mauchin wrote: >> On 6/16/21 6:03 PM, Nils Philippsen wrote: >>> Hi everybody, >>> >>> we've scheduled the rpmautospec plugin to be deployed into production >>> for tomorrow, from 14:00 UTC on. >>> >>> This means installing the relevant packages and restarting kojid >>> processes on the builders, which will restart any tasks which are being >>> processed at that time, i.e. expect delays for builds in-flight at the >>> time. >>> >>> We'll announce when the deployment is done. >>> >>> Cheers, >>> Nils >>> >> >> What is the situation wrt new packages? Should we enforce the use of >> rpmautospec during reviews or is it completely optional? > > It is completely optional. > One thing to note: If people *are* using it, then right now fedora-review will complain about a missing dist-tag and rpmlint will warn about macros in the changelog.

Robert-André Mauchin <zebob.m(a)gmail.com&gt; writes: > What is the situation wrt new packages? Should we enforce the use of > rpmautospec during reviews or is it completely optional? I think we should encourage the usage of rpmautospec for new packages, provided that the packager feels comfortable enough to use it. E.g. I wouldn't suggest it for someone's first package. But this shouldn't become a *MUST*, at least not yet.

Otto Urpelainen <oturpe(a)iki.fi&gt; writes: > Dan Čermák kirjoitti 17.7.2021 klo 23.10: >> Robert-André Mauchin <zebob.m(a)gmail.com&gt; writes: >> >>> What is the situation wrt new packages? Should we enforce the use of >>> rpmautospec during reviews or is it completely optional? >> >> I think we should encourage the usage of rpmautospec for new packages, >> provided that the packager feels comfortable enough to use it. E.g. I >> wouldn't suggest it for someone's first package. But this shouldn't >> become a *MUST*, at least not yet. > > I am curious regarding the reasons for not recommending rpmautospec for > new maintainers? It is an automation feature that removes manual steps > from the process. Using it is simpler than doing the same manually. I > think we should offer the simplest possible process for newcomers and > only recommend manual overrides for use cases that automation cannot > handle (yet). Well, I think that a total newcomer is already struggling enough to produce a good spec file for their first package, but now they also need to keep in mind that their changelog is tied to the git history (and can thus not be changed easily anymore). Back when I started packaging, I found a lot of the details quite confusing and was building packages on copr and locally for a few years before I dared to go near koji. At least for me using rpmautospec would've been another one of these confusing details. That's why I would only recommend its usage, until most other build system out there use something comparable and beginners can be expected to know this concept already.

On Mon, 19 Jul 2021, 08:08 Otto Urpelainen, <oturpe(a)iki.fi&gt; wrote: > > However, copr seems to understand rpmautospec. > Not really. The release will always be 1. When a package builds again, end users won't receive the updated version. https://pagure.io/fedora-infra/rpmautospec/issue/199

Dan Čermák kirjoitti 18.7.2021 klo 23.38: > Otto Urpelainen <oturpe(a)iki.fi&gt; writes: > >> Dan Čermák kirjoitti 17.7.2021 klo 23.10: >>> Robert-André Mauchin <zebob.m(a)gmail.com&gt; writes: >>> >>>> What is the situation wrt new packages? Should we enforce the use of >>>> rpmautospec during reviews or is it completely optional? >>> >>> I think we should encourage the usage of rpmautospec for new packages, >>> provided that the packager feels comfortable enough to use it. E.g. I >>> wouldn't suggest it for someone's first package. But this shouldn't >>> become a *MUST*, at least not yet. >> >> I am curious regarding the reasons for not recommending rpmautospec for >> new maintainers? It is an automation feature that removes manual steps >> from the process. Using it is simpler than doing the same manually. I >> think we should offer the simplest possible process for newcomers and >> only recommend manual overrides for use cases that automation cannot >> handle (yet). > > Well, I think that a total newcomer is already struggling enough to > produce a good spec file for their first package, but now they also need > to keep in mind that their changelog is tied to the git history (and can > thus not be changed easily anymore). Back when I started packaging, I > found a lot of the details quite confusing and was building packages on > copr and locally for a few years before I dared to go near koji. At > least for me using rpmautospec would've been another one of these > confusing details. That's why I would only recommend its usage, until > most other build system out there use something comparable and beginners > can be expected to know this concept already. Understood. That makes sense. This is a case of different backgrounds. The only rpm packages I have ever built are Fedora official packages. From that angle, using rpmautospec is just simpler. In your case, it is the other way round.

On 6/16/21 6:03 PM, Nils Philippsen wrote: > Hi everybody, > > we've scheduled the rpmautospec plugin to be deployed into production > for tomorrow, from 14:00 UTC on. > > This means installing the relevant packages and restarting kojid > processes on the builders, which will restart any tasks which are being > processed at that time, i.e. expect delays for builds in-flight at the > time. > > We'll announce when the deployment is done. > > Cheers, > Nils > Maybe I'm doing something wrong but the autochangelog does not seem to work for me: The latest commit I pushed: https://src.fedoraproject.org/rpms/buku/c/dd2d84f9ac02ff6357e239f62e6c4af... The bodhi update does not pick up that last commit and only show the latest entry in the changelog file: https://bodhi.fedoraproject.org/updates/FEDORA-2021-83bf7dfa10 And the bug number is not picked up and thus not closed. Am I doing something wrong somewhere?

Best regards, Robert-André _______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure