[Bug 1806435] perl-Net-Whois-Raw-2.99027 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1806435 Emmanuel Seyman changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Net-Whois-Raw-2.99.027 ||-1.fc33 Resolution|--- |RAWHIDE Doc Type|--- |If docs needed, set a value Last Closed||2020-03-01 07:41:30 --- Comment #2 from Emmanuel Seyman --- Built for rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=1472405 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org
[Bug 1793917] perl-Test-mysqld-1.0012-4.fc32 FTBFS: DBI connect('dbname=mysql;mysql_socket=/tmp/B_Fm_kLtjo/tmp/mysql.sock;user=root','',...) failed: Access denied for user 'root'@'localhost' at /build
https://bugzilla.redhat.com/show_bug.cgi?id=1793917 --- Comment #3 from Fedora Release Engineering --- Dear Maintainer, your package has not been built successfully in 32. Action is required from you. If you can fix your package to build, perform a build in koji, and either create an update in bodhi, or close this bug without creating an update, if updating is not appropriate [1]. If you are working on a fix, set the status to ASSIGNED to acknowledge this. Following the latest policy for such packages [2], your package will be orphaned if this bug remains in NEW state more than 8 weeks. A week before the mass branching of Fedora 33 according to the schedule [3], any packages not successfully rebuilt at least on Fedora 31 will be retired regardless of the status of this bug. [1] https://fedoraproject.org/wiki/Updates_Policy [2] https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ [3] https://fedoraproject.org/wiki/Releases/33/Schedule -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org
[Bug 1799856] perl-Syntax-Highlight-Perl6: FTBFS in Fedora rawhide/f32
https://bugzilla.redhat.com/show_bug.cgi?id=1799856 --- Comment #6 from Fedora Release Engineering --- Dear Maintainer, your package has not been built successfully in 32. Action is required from you. If you can fix your package to build, perform a build in koji, and either create an update in bodhi, or close this bug without creating an update, if updating is not appropriate [1]. If you are working on a fix, set the status to ASSIGNED to acknowledge this. Following the latest policy for such packages [2], your package will be orphaned if this bug remains in NEW state more than 8 weeks. A week before the mass branching of Fedora 33 according to the schedule [3], any packages not successfully rebuilt at least on Fedora 31 will be retired regardless of the status of this bug. [1] https://fedoraproject.org/wiki/Updates_Policy [2] https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ [3] https://fedoraproject.org/wiki/Releases/33/Schedule -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org
[389-devel] 389 DS nightly 2020-03-01 - 95% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2020/03/01/report-389-ds-base-1.4.3.3-20200301gitd9e02aa.fc31.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@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/389-devel@lists.fedoraproject.org
[Bug 1808774] New: perl-List-AllUtils-0.16 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1808774 Bug ID: 1808774 Summary: perl-List-AllUtils-0.16 is available Product: Fedora Version: rawhide Status: NEW Component: perl-List-AllUtils Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 0.16 Current version/release in rawhide: 0.15-5.fc32 URL: http://search.cpan.org/dist/List-AllUtils/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/3031/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org
Re: Forge discussion: FSF project effect?
On Sat, Feb 29, 2020 at 8:42 PM Adam Williamson wrote: > > Hey folks! > > So, I caught an interesting story on LWN today: > > https://lwn.net/Articles/813254/ > > it appears the FSF is planning to run a forge and contribute to > whatever project they use, and Pagure is currently their leading > contender: > > https://libreplanet.org/wiki/Fsf_2019_forge_evaluation > > "Pagure (seems most likely, its our current focus)" > > were we aware of this? Is it feeding into the forge evaluation at all? > Given that resource constraints seem to be a significant factor, > presumably having some resources contributed by FSF would be rather > useful... I'm not sure if anyone beyond myself, Pierre-Yves, and Julen actually knew this was going on prior to now. :) But yes, I was aware of this, as Andrew Engelbrecht from the FSF reached out to us asking about how to handle spam[1] for their evaluation back in December. Since then, I've been helping them with their evaluation of Pagure as the FSF's new forge. They had briefly mentioned this in their November bulletin to supporters, too[2]. Up until a few days ago, they had been super low-key about it. My current guess is that it'll launch at LibrePlanet[3] this year, or at least everything will be finalized for a launch shortly after. As far as I know, it might not be feeding into the evaluation at all, though it would be nice if it did help the case for Pagure for Fedora's forge. The FSF's current plan to deploy Pagure has also triggered interest by others who prefer a fully "free as in freedom" platform. It also led to Pagure finally landing in Debian[4] (and thus, Ubuntu[5]). I'm aware of at least three Linux distributions that are considering Pagure now, one of which is considering a migration from GitLab to Pagure. I'm also aware of at least one commercial entity evaluating it for a preferred integration for a product, due specifically to the design of Pagure being quite amenable to their needs. I really haven't broadly discussed this because I didn't feel like anyone here would have cared at this point in time, but this is something that I've been doing for a lot of Fedora's infrastructure software to try to bootstrap communities around them. It seems nobody has really tried before, which is quite unfortunate. We should hopefully start seeing the fruits of that work sooner rather than later. [1]: https://lists.pagure.io/archives/list/pagure-de...@lists.pagure.io/thread/H2LCKVG6DDMLBCKPQMDKZO75OUCJVNVC/ [2]: https://www.fsf.org/bulletin/2019/fall/the-path-to-a-free-internet [3]: https://libreplanet.org/2020/ [4]: https://packages.debian.org/sid/pagure [5]: https://packages.ubuntu.com/focal/pagure -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: Ideas and proposal for removing changelog and release fields from spec file
On Sat, 29 Feb 2020 at 22:42, Nicolas Mailhot via devel
wrote:
>
> Le samedi 29 février 2020 à 20:57 +0100, clime a écrit :
> > On Sat, 29 Feb 2020 at 16:24, Nicolas Mailhot via devel
> > wrote:
> > > Le samedi 29 février 2020 à 15:12 +0100, clime a écrit :
> > > > On Sat, 29 Feb 2020 at 14:47, Nicolas Mailhot via devel
> > > > wrote:
> > > > > Le samedi 29 février 2020 à 14:28 +0100, clime a écrit :
> > > > > > Does ENVR without %{dist} means something with respect to the
> > > > > > content
> > > > > > from
> > > > > > which the package was built or with respect to features that
> > > > > > it
> > > > > > offers for the given distribution version?
> > > > >
> > > > > You need to evaluate evr with a neutral dist value to decide to
> > > > > bump or
> > > > > not the auto-dynamic part of release or not. Because the whole
> > > > > point of
> > > > > the auto-dynamic part of release would be to track rebuilds
> > > > > from
> > > > > the
> > > > > same spec, all othert parts of EVR being equal
> > > > >
> > > > > Changelog-side and package build side you need the full EVR
> > > > > without
> > > > > neutralization
> > > >
> > > > Thank you very much Nicolas but you reacted to a question which
> > > > was
> > > > actually unrelated to your proposal. That particular question
> > > > about
> > > > the meaning of ENVR when you strip the distribution tag (i.e.
> > > > .fc32
> > > > or
> > > > .el7) was intended to be generic, i.e. i want to know how if
> > > > e.g.
> > > > python3-alembic-1.1.0-1 has any meaning alone without, for
> > > > example,
> > > > .fc31 appended to it (or if it should have any meaning which is
> > > > e.g.
> > > > not respected these days).
> > >
> > > And I answered you. From a changelog POW you need the full dist
> > > because
> > > the exact same stripped/neutralized Release may (and does) exist
> > > today
> > > in different branches, pointing to different spec states.
> >
> > Can you give an example of such package?
> >
> > I mean, of course, technically it is possible and not forbidden
> > anywhere in the guidelines as far as I know. But...
>
> That’s pretty much inevitable when you hit release-specific problems
> that require pushing release-specific changes or patches in one or
> several branches. No matter what clever numbering conventions you try
> to invent, things are eventually going to collide.
>
> %{dist} is not here just to prettify things. Branching is real
> branching. syncing branches is a packager optimization. It’s not
> possible in all cases. The only hard requirement is to keep evr lower
> in older branches, syncing is optional and not done when it’s just a
> lot of pain for little win.
>
> You can say “start from the -devel evr, add .number when adding a
> patch”. That only gets you as far as the first patch. What if f33 state
> needs patching one way in f32 and another in f31 (ignoring el7 and el8
> for now)? Your convention already hit its limits. And it’s just the
> first patch step.
If I wanted to be super-clean, I would simply do a minor bump for f32
and f31 on top of the f33 patch. Minor bumps do not give users any
false impressions because they are placed after the dist tag.
>
> The usual packager reaction in that case is either add spaguetti dist
> ifdefs in their spec, or just give up on syncing (I definitely prefer
> the second strategy). After all, no harm done if the branches de-sync,
> as long as cross-release upgrade pathes work.
>
> > If I, as a user, see e.g. python3-alembic-1.1.0-13 in f31 and then I
> > will see python3-alembic-1.1.0-13 in f32 (this time with .fc32
> > disttag), I am going to assume nothing has changed for that package.
>
> And you’ll be wrong, because we do branch. I we could have avoided
> branching, we’d have avoided it. Branching brings quite a lot of
> complexity. However we do branch because releases overlap but are not
> technically equal.
We still should take into account user's intuitive expectations and
the way numbers are layed out in the Release string that raises those
expectations.
Yes, we always work in a context of a certain distribution branch so
it's very inconvenient to assign to a certain number meaning that
should somehow cross boundaries of that particular branch. Maybe the
way dist-git branches are layed out (per distribution version) is not
totally perfect for everything though and we should be aware of that.
>
> What we *can* do is make fedpkg merge master work to avoid packager
> work when the branches can be synced (or re-synced). And fedpkg merge
> master should work with my proposal (as long as the older branch has
> not already autobumped further than master, but a packager that allows
> that already broke the upgrade path, and earned manual clean-up work).
>
> > If we do these build-counter, commit-counter (without the leading
> > "pivot" number) approaches, then it would imho really be better to
> > have python3-alembic-1.1.0-fc31.13 and python3-alembic-1.1.0-fc32.13
> > which is quite a
Forge discussion: FSF project effect?
Hey folks! So, I caught an interesting story on LWN today: https://lwn.net/Articles/813254/ it appears the FSF is planning to run a forge and contribute to whatever project they use, and Pagure is currently their leading contender: https://libreplanet.org/wiki/Fsf_2019_forge_evaluation "Pagure (seems most likely, its our current focus)" were we aware of this? Is it feeding into the forge evaluation at all? Given that resource constraints seem to be a significant factor, presumably having some resources contributed by FSF would be rather useful... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: Ideas and proposal for removing changelog and release fields from spec file
On Sat, 29 Feb 2020 at 21:50, Nicolas Mailhot via devel
wrote:
>
> Le samedi 29 février 2020 à 20:30 +0100, clime a écrit :
> >
> > What about fedpkg local and fedpkg verrel then?
>
> Putting %{dynrel} reconciliation in the rpmbuild -bs stage using
> detached file state means that fedpkg local (or checking out git state
> and building in mock or copr or OBS or via plain rpmbuild -bs) will
> give you the same result as launching fedpkg build.
Well, I believe it doesn't. You run:
1) fedpkg local -> produces -1.0-1.fc32 (1 in release because
you haven't built that package before)
2) fedpkg build
3) vim .spec and do some change in %description
4) fedpkg commit -m "description improvement"
5) fedpkg local -> produces -1.0-1.fc32
6) fedpkg push -> error because build system pushed meanwhile
7) fedpkg pull --rebase (to quickly fix the error)
8) fedpkg build -> builds -1.0-2.fc32
To get the correct NVR for the package being built by `fedpkg local`
you need to wait for some external process to finish first so that you
can pull the new state. Only then you get correct value again.
> Which is exactly
> what you want to make QA and testing workflows work. Those don’t live
> exclusively in koji.
>
> And because only production builds get committed back the packager can
> change his mind and stage a few more changes before doing the
> production build, without polluting the changelog builds that were
> never pushed to users.
That's a good thing, definitely.
>
> For fedpkg verrel you'll probably want to output a last (saved in
> detached file) and next line (probably factorizable by externalizing
> the dynrel bump logic in a separate command). That’s more honest
> anyway, next may happen or not, when you launch fedpkg verrel, it’s
> mere potential (the next commit may bump version and invalidate your
> future build).
There is the same problem as above with `fedpkg local`, the command
won't be giving you correct values at all times.
>
> > As for changelog, generally with build system commiting back to
> > dist-git, there is a problem that I can be concurrently pushing
> > changes while the build system tries to push its changes and build
> > system is not human so it will not know how to resolve such
> > situation.
>
> I understand, but that’s the consequence of automating changelog. Right
> now the reconciliation is done by the human packager (you can get in a
> similar situation by working on a change at the time a mass rebuild
> runs).
It doesn't need to be the consequence of "automating changelog". It's
only a consequence in certain implementations. If the changelog is
derived purely from the git state, there aren't these problems
anymore. The mass rebuilds are easier to handle than your case because
with mass rebuilds, you always put the the new changelog record "on
top" of other changelogs records. I.e. when you cannot push from build
system (while peforming a mass rebuild), you can simply pull and try
to do the same thing as before. But in your proposal it's not that
easy (unless you do the locking or failing in that case as you
described below) because you would need modify/insert into "middle" of
the changelog at the right place.
>
> > Do you have a solution for situation when I launch a build and then I
> > do another change, commit, and push (the changes to changelog can be
> > quite arbitrary here)?
>
> You can set a lock at fedpkg build time, and forbid fedpkg commit in
> that branch till the lock is released (fedpkg build in the branch
> succeeded or not). The packager can still git commit things, as long as
> he does not touch the detached changelog file. Only fedpkg commit syncs
> git state with detached changelog state.
The fact that "git commit" is different from "fedpkg commit" is not
very convenient imho but could be probably get used to. But you
generally don't except commit actions to change the repository content
under your hands before actually committing. The locking mechanism you
describe can be easily work-arounded by cloning the package repo again
and doing your stuff. The only way to avoid it would be to implement
locking server side. Either way it's not the best user experience.
>
> An alternate simpler strategy would be to mark the fedpkg build as
> failure in koji if sync-back failed. That would work too. The build
> system need not be ultra smart, just robust WRT human behaviour.
I think not being able to work with dist-git while something is
building its content is a throughput limitation and doesn't bring the
best UX.
>
> (If the packager deliberately messes with the detached changelog while
> a production build for the same branch is ongoing he deserves a build
> failure – the changelog state is undefined till the build ends, so he’s
> doing changes on quicksand. If he tried that today he’d probably have
> to rewrite his changelog if the build failed)
>
> > I think, this is not a decision of rpm upstream but an infrastructure
> > thing or a mock thing.
>
> mock and rpm
[rpms/perl-Acme-Damn] PR #1: Spec file cleanups: Use make_build and make_install macros
eseyman merged a pull-request against the project: `perl-Acme-Damn` that you are following. Merged pull-request: `` Spec file cleanups: Use make_build and make_install macros `` https://src.fedoraproject.org/rpms/perl-Acme-Damn/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-eac9cef8cf hiredis-0.13.3-13.el8 9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-3483348dc1 proftpd-1.3.6c-1.el8 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-47a203cb95 openfortivpn-1.12.0-1.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing clamav-0.102.2-3.el8 vapoursynth-48-6.el8 zsh-syntax-highlighting-0.7.1-1.el8 Details about builds: clamav-0.102.2-3.el8 (FEDORA-EPEL-2020-3b652ce497) End-user tools for the Clam Antivirus scanner Update Information: Add missingok to clamav-update logrotate file, ChangeLog: * Sat Feb 29 2020 Orion Poplawski - 0.102.2-3 - Add missingok to clamav-update.logrotate (bz#1807701) References: [ 1 ] Bug #1807701 - daily clamav-update logrotate error https://bugzilla.redhat.com/show_bug.cgi?id=1807701 vapoursynth-48-6.el8 (FEDORA-EPEL-2020-cb2d3ef940) Video processing framework with simplicity in mind Update Information: New package. ChangeLog: * Sat Feb 29 2020 Simone Caronni - 48-6 - Make it exclusive for i686/x86_64. - Fix build on RHEL/CentOS 8. * Tue Feb 25 2020 Artem Polishchuk - 48-5 - Add tests - Cosmetic spec file improvements * Thu Feb 20 2020 Simone Caronni - 48-4 - More review fixes. - Use upstream patch for Python 3.8. * Fri Feb 7 2020 Simone Caronni - 48-3 - Review fixes. * Sun Jan 26 2020 Simone Caronni - 48-2 - Move script library into main library package. - Fix build with Python 3.8. * Thu Jan 16 2020 Simone Caronni - 48-1 - First build. References: [ 1 ] Bug #1791588 - Review Request: vapoursynth - A video processing framework with simplicity in mind https://bugzilla.redhat.com/show_bug.cgi?id=1791588 zsh-syntax-highlighting-0.7.1-1.el8 (FEDORA-EPEL-2020-7edbd1ef8a) Fish shell like syntax highlighting for Zsh Update Information: Update to 0.7.1 ChangeLog: * Sat Feb 29 2020 Michael Kuhn - 0.7.1-1 - Update to 0.7.1 * Fri Jan 31 2020 Fedora Release Engineering - 0.6.0-6 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild References: [ 1 ] Bug #1790134 - zsh-syntax-highlighting-0.7.1 is available https://bugzilla.redhat.com/show_bug.cgi?id=1790134 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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/epel-devel@lists.fedoraproject.org
Re: Ideas and proposal for removing changelog and release fields from spec file
Le samedi 29 février 2020 à 20:57 +0100, clime a écrit :
> On Sat, 29 Feb 2020 at 16:24, Nicolas Mailhot via devel
> wrote:
> > Le samedi 29 février 2020 à 15:12 +0100, clime a écrit :
> > > On Sat, 29 Feb 2020 at 14:47, Nicolas Mailhot via devel
> > > wrote:
> > > > Le samedi 29 février 2020 à 14:28 +0100, clime a écrit :
> > > > > Does ENVR without %{dist} means something with respect to the
> > > > > content
> > > > > from
> > > > > which the package was built or with respect to features that
> > > > > it
> > > > > offers for the given distribution version?
> > > >
> > > > You need to evaluate evr with a neutral dist value to decide to
> > > > bump or
> > > > not the auto-dynamic part of release or not. Because the whole
> > > > point of
> > > > the auto-dynamic part of release would be to track rebuilds
> > > > from
> > > > the
> > > > same spec, all othert parts of EVR being equal
> > > >
> > > > Changelog-side and package build side you need the full EVR
> > > > without
> > > > neutralization
> > >
> > > Thank you very much Nicolas but you reacted to a question which
> > > was
> > > actually unrelated to your proposal. That particular question
> > > about
> > > the meaning of ENVR when you strip the distribution tag (i.e.
> > > .fc32
> > > or
> > > .el7) was intended to be generic, i.e. i want to know how if
> > > e.g.
> > > python3-alembic-1.1.0-1 has any meaning alone without, for
> > > example,
> > > .fc31 appended to it (or if it should have any meaning which is
> > > e.g.
> > > not respected these days).
> >
> > And I answered you. From a changelog POW you need the full dist
> > because
> > the exact same stripped/neutralized Release may (and does) exist
> > today
> > in different branches, pointing to different spec states.
>
> Can you give an example of such package?
>
> I mean, of course, technically it is possible and not forbidden
> anywhere in the guidelines as far as I know. But...
That’s pretty much inevitable when you hit release-specific problems
that require pushing release-specific changes or patches in one or
several branches. No matter what clever numbering conventions you try
to invent, things are eventually going to collide.
%{dist} is not here just to prettify things. Branching is real
branching. syncing branches is a packager optimization. It’s not
possible in all cases. The only hard requirement is to keep evr lower
in older branches, syncing is optional and not done when it’s just a
lot of pain for little win.
You can say “start from the -devel evr, add .number when adding a
patch”. That only gets you as far as the first patch. What if f33 state
needs patching one way in f32 and another in f31 (ignoring el7 and el8
for now)? Your convention already hit its limits. And it’s just the
first patch step.
The usual packager reaction in that case is either add spaguetti dist
ifdefs in their spec, or just give up on syncing (I definitely prefer
the second strategy). After all, no harm done if the branches de-sync,
as long as cross-release upgrade pathes work.
> If I, as a user, see e.g. python3-alembic-1.1.0-13 in f31 and then I
> will see python3-alembic-1.1.0-13 in f32 (this time with .fc32
> disttag), I am going to assume nothing has changed for that package.
And you’ll be wrong, because we do branch. I we could have avoided
branching, we’d have avoided it. Branching brings quite a lot of
complexity. However we do branch because releases overlap but are not
technically equal.
What we *can* do is make fedpkg merge master work to avoid packager
work when the branches can be synced (or re-synced). And fedpkg merge
master should work with my proposal (as long as the older branch has
not already autobumped further than master, but a packager that allows
that already broke the upgrade path, and earned manual clean-up work).
> If we do these build-counter, commit-counter (without the leading
> "pivot" number) approaches, then it would imho really be better to
> have python3-alembic-1.1.0-fc31.13 and python3-alembic-1.1.0-fc32.13
> which is quite a huge change.
The system provides a %{dynrel} counter. The packager can stick it
before or after %{dist} (or not use it at all), the mecanism will work
the same (obviously, without autobumping if the packager does not use
%{dynrel} in his release string).
%{dynrel} is sufficient to handle autobumping. If you try to own the
whole release string, you’ll hit all kinds of complexity (starting with
pre/post release, then the ruby thing, etc)
%{dist} (especially taking %{distprefix} into account, but even without
it) does not sort well. elx/fcx does not sort. Third part packages may
use a sort-able dist or not. if you want evr to work, you put the
relevant part of r before dist, and keep it only as last resort to
distinguish between synced fedora branches.
Regards,
--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
[Bug 1802968] EPEL8 Build
https://bugzilla.redhat.com/show_bug.cgi?id=1802968 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-Term-ReadLine-Gnu-1.36 ||-7.el8 Resolution|--- |ERRATA Last Closed||2020-02-29 21:39:21 --- Comment #4 from Fedora Update System --- perl-Term-ReadLine-Gnu-1.36-7.el8 has been pushed to the Fedora EPEL 8 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org
Re: Ideas and proposal for removing changelog and release fields from spec file
Le samedi 29 février 2020 à 20:30 +0100, clime a écrit :
>
> What about fedpkg local and fedpkg verrel then?
Putting %{dynrel} reconciliation in the rpmbuild -bs stage using
detached file state means that fedpkg local (or checking out git state
and building in mock or copr or OBS or via plain rpmbuild -bs) will
give you the same result as launching fedpkg build. Which is exactly
what you want to make QA and testing workflows work. Those don’t live
exclusively in koji.
And because only production builds get committed back the packager can
change his mind and stage a few more changes before doing the
production build, without polluting the changelog builds that were
never pushed to users.
For fedpkg verrel you'll probably want to output a last (saved in
detached file) and next line (probably factorizable by externalizing
the dynrel bump logic in a separate command). That’s more honest
anyway, next may happen or not, when you launch fedpkg verrel, it’s
mere potential (the next commit may bump version and invalidate your
future build).
> As for changelog, generally with build system commiting back to
> dist-git, there is a problem that I can be concurrently pushing
> changes while the build system tries to push its changes and build
> system is not human so it will not know how to resolve such
> situation.
I understand, but that’s the consequence of automating changelog. Right
now the reconciliation is done by the human packager (you can get in a
similar situation by working on a change at the time a mass rebuild
runs).
> Do you have a solution for situation when I launch a build and then I
> do another change, commit, and push (the changes to changelog can be
> quite arbitrary here)?
You can set a lock at fedpkg build time, and forbid fedpkg commit in
that branch till the lock is released (fedpkg build in the branch
succeeded or not). The packager can still git commit things, as long as
he does not touch the detached changelog file. Only fedpkg commit syncs
git state with detached changelog state.
An alternate simpler strategy would be to mark the fedpkg build as
failure in koji if sync-back failed. That would work too. The build
system need not be ultra smart, just robust WRT human behaviour.
(If the packager deliberately messes with the detached changelog while
a production build for the same branch is ongoing he deserves a build
failure – the changelog state is undefined till the build ends, so he’s
doing changes on quicksand. If he tried that today he’d probably have
to rewrite his changelog if the build failed)
> I think, this is not a decision of rpm upstream but an infrastructure
> thing or a mock thing.
mock and rpm upstreams excel when they work together. My premise is
that they are better qualified than us to do rpm/buildsys boundary fine
tuning.
Populating changelog from git and syncing back to fedora git are
fedpkg/koji responsability, because Fedora git is Fedora specific
infra. Handling release autobumping and build recording belongs to the
lower layers, however. They’re the same with or without Fedora git,
they belong to lower levels.
> I think your proposal wouldn't quite work for copr because it has no
> access to those repositories (which especially for src.fp.o is good
> in your proposal, otherwise copr would be modifying src.fp.o repos).
copr does not need write access to Fedora git, its builds do not
participate to the production build lineage as long as no one re-
imports them in koji (which should be a deliberate fedpkg command, not
something driven by copr itself).
copr only needs access to its own private git to remember its own last
successful build, if people want it to autobump from last successful
state. (maybe they don’t). srpm import in copr will overwrite copr
state with the state the new srpm contains, which is fine too.
Putting state in detached srpm source files has the following super-
duper property. You can import the srpm or scm checkout between
systems, and they’ll just pick up from the point the previous system
left things, without needing a full scm import. So you do not need to
deal with incompatible scms (or lack of scm).
> So if someone wanted to have a build counter in the release, yes,
> this could be an implementation although it would be much easier to
> simply catch the information from copr's database where this info is
> stored
It is simpler from the buildsys POW, but it ties state in a specific
git and buildsystem. So it will break cross-buildsys workflows.
Cross-buildsys workflows are critical for the project success because
they enable sharing work with other distros, and allow packagers to
make the best of a palette of build systems (each with its own
constrains and limitiations). Fun fact: I noticed today than one of my
old Fedora packages was rebuilt by others for AIX. This kind of cross-
pollination is one of the strengths of the rpm ecosystem. Don’t break
it by making out packages depend on Fedora git or buildsys state.
> in
[Bug 1808744] New: perl-CPAN-Perl-Releases-5.20200229 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1808744 Bug ID: 1808744 Summary: perl-CPAN-Perl-Releases-5.20200229 is available Product: Fedora Version: rawhide Status: NEW Component: perl-CPAN-Perl-Releases Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: iarn...@gmail.com, jples...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 5.20200229 Current version/release in rawhide: 5.20200220-1.fc33 URL: http://search.cpan.org/dist/CPAN-Perl-Releases/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/5881/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org
Re: Ideas and proposal for removing changelog and release fields from spec file
On Sat, 29 Feb 2020 at 16:24, Nicolas Mailhot via devel
wrote:
>
> Le samedi 29 février 2020 à 15:12 +0100, clime a écrit :
> > On Sat, 29 Feb 2020 at 14:47, Nicolas Mailhot via devel
> > wrote:
> > > Le samedi 29 février 2020 à 14:28 +0100, clime a écrit :
> > > > Does ENVR without %{dist} means something with respect to the
> > > > content
> > > > from
> > > > which the package was built or with respect to features that it
> > > > offers for the given distribution version?
> > >
> > > You need to evaluate evr with a neutral dist value to decide to
> > > bump or
> > > not the auto-dynamic part of release or not. Because the whole
> > > point of
> > > the auto-dynamic part of release would be to track rebuilds from
> > > the
> > > same spec, all othert parts of EVR being equal
> > >
> > > Changelog-side and package build side you need the full EVR without
> > > neutralization
> >
> > Thank you very much Nicolas but you reacted to a question which was
> > actually unrelated to your proposal. That particular question about
> > the meaning of ENVR when you strip the distribution tag (i.e. .fc32
> > or
> > .el7) was intended to be generic, i.e. i want to know how if e.g.
> > python3-alembic-1.1.0-1 has any meaning alone without, for example,
> > .fc31 appended to it (or if it should have any meaning which is e.g.
> > not respected these days).
>
> And I answered you. From a changelog POW you need the full dist because
> the exact same stripped/neutralized Release may (and does) exist today
> in different branches, pointing to different spec states.
Can you give an example of such package?
I mean, of course, technically it is possible and not forbidden
anywhere in the guidelines as far as I know. But...
If I, as a user, see e.g. python3-alembic-1.1.0-13 in f31 and then I
will see python3-alembic-1.1.0-13 in f32 (this time with .fc32
disttag), I am going to assume nothing has changed for that package. I
think that is the intuitive user's expectation here. By providing the
same NVR (except for disttag) into the new Fedora release, as user had
installed before, I can tell to the user: "Nothing has changed for you
here". I mean, that's how I would interpret it.
If that stripped NVR suddenly starts depending on build count for the
given branch, I will start getting quite random numbers where some
package in the new Fedora release looks like "nothing has changed"
(according to its stripped NVR) but in fact a lot have changed. The
similar problem is with bumping by commit count too.
If we do these build-counter, commit-counter (without the leading
"pivot" number) approaches, then it would imho really be better to
have python3-alembic-1.1.0-fc31.13 and python3-alembic-1.1.0-fc32.13
which is quite a huge change.
>
> From a dynamic release POW dist is irrelevant to compute the next bump
> point and needs stripping. All that matters is that the result evrs
> differently, ignoring dist. Keeping branches synchronized or not is a
> packager decision (choosing to desync requires specific upgrade path
> care, but it is a valid use case today).
>
> And yes that info oriented my proposal. Any other proposal will have to
> take it into account too.
>
> Regards,
>
> --
> Nicolas Mailhot
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Re: Ideas and proposal for removing changelog and release fields from spec file
On Sat, 29 Feb 2020 at 16:12, Nicolas Mailhot via devel
wrote:
>
> Le samedi 29 février 2020 à 13:49 +0100, clime a écrit :
> > On Sat, 29 Feb 2020 at 10:15, Nicolas Mailhot via devel
> > wrote:
> > > Hi,
> > >
> > > Anyway, here is what I would personnaly consider a robust,
> > > inclusive,
> > > and future-proof design:
> >
> > I will need to ask some questions to really understand it.
> >
> > > — a %{use_dynstate} rpm variable enables dynamic changelog/release
> > > behaviour
> > > — probably initialy set to false distro-wide, to let volunteers
> > > test
> > > the thing by setting it to true iin their specs,
> > > — then to true (opt-out), when kinks have been fixed, and
> > > FPC/FESCO
> > > greenlights general availability
> > >
> > > – when activated, last changelog, evr and %{dynrel} state are saved
> > > in one or several detached files
> >
> > You mean the last changelog, evr, and %{dynrel} are stored once
> > %{use_dynstate} is set and and after one invokes fedpkg commit?
> > I think there should be some explicit action (e.g. the commit) to
> > generate the files after I set the %{use_dynstate} value to true in
> > the spec file.
>
> Once a spec sets %{use_dynstate} to true changelog, last computed
> changelog, ev, neutralized-r, and %{dynrel} are taken from detached
> files. neutralized-r is the evaluation of Release with %{dist} set to a
> neutral value (for example “-”).
>
> State is stored in files included in the srpm to be able to import to
> and from Fedora git (pretty much a hard requirement if tooling is to be
> kept Fedora-git neutral, which is itself a hard requirement to be able
> to interact with packaging work existing outside Fedora git).
>
> You need the last computed ev and neutralized-r to decide whether
> %{dynrel} can be kept, needs bumping, or should be reset to 1.
>
> I don’t trust mixed mode, KISS, changelog is detached or not, don’t try
> to have it both ways, here lies madness and confusion.
>
> > How is %{dynrel} computed here at this stage
>
> Nothing is computed at this stage.
>
> Detached changelog state, is a commit property (except for build date).
> It is computed at fedpkg commit time:
> – if detached changelog data is absent
>→ move in-spec changelog data to the detached file if data exists,
>→ otherwise init detached data to nothing
> – after the first fedpkg commit with %{use_dynstate} set to true, the
>detached changelog file exists and the in-spec changelog has been
>removed.
> – others have detailed possible fedpkg commit strategies to stuff
>changelog with new info
>
> %{dynrel} and build changelog info are a build property. They are
> computed at build time:
> – if computed ev ≠ last saved ev or last %{dynrel} is undefined
>→ reset %{dynrel} to 1
> – otherwise if computed neutralized-r = last neutralized-r
>→ bump %{dynrel}
> – otherwise, do nothing, something already took care of things
> – save the new computed ev, computed neutralized-r and dynrel to the
>detached files
> – add a build line with the full evr (and full dist) to detached
>changelog
> – at build time, there is no relationship with magic git state or
>magic buildsys info, the srpms are 100% autonomous as before. The
>detached changelog has already been populated manually or by distro
>automation or manual processes when it reaches build stage and a new
>build is recorded (with a new dynrel value, if necessary).
>
> > Is the intention here that with each new build of the same package,
> > the value of %{dynrel} is bumped and committed back?
>
> It is bumped (or reseted to 1) whenever comparison with last saved
> state shows a bump or reset is needed.
>
> Build-time state changes need to be commited back, of course (otherwise
> the produced srpm needs to be re-imported manually)
>
> > That means the evr file read from the repository needs to contain
> > somehow outdated values at this point (when srpm is being built in
> > build system), otherwise %{dynrel} would be always bumped?
>
> Final dynrel state is not computed before a build, yes. The build will
> decide if it needs to bump dynrel, or can reset it to 1. I had
> forgotten to document the reset, sorry.
>
> There is no need to compute a new dynrel before actual build, the
> packager may yet change ev or r.
>
> > > – a build line is added to the detached changelog, using the
> > > current
> > > date and full evr (without %{dist} neutralization)
> > > — that probably requires defining a rpm variable to track whom
> > > the
> > > build is attributed to
> > > – it can default to "Anonymous coward" or whatever if not
> > > explicitely
> > > set
> >
> > I think today's changelogs do not contain name of the person who
> > built the pacakge
>
> Today’s changelog mixes who made spec changes and who built the result.
> That what confuses you. Confusion is anthetical with automation. This
> proposal clearly documents that changelog can change at build time
> (fedpkg build)
[Bug 1808730] perl-DateTime-1.52 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1808730 --- Comment #2 from Upstream Release Monitoring --- the-new-hotness/release-monitoring.org's scratch build of perl-DateTime-1.52-1.fc30.src.rpm for rawhide completed http://koji.fedoraproject.org/koji/taskinfo?taskID=42040100 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org
[Bug 1808731] New: perl-DateTime-Format-Strptime-1.77 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1808731 Bug ID: 1808731 Summary: perl-DateTime-Format-Strptime-1.77 is available Product: Fedora Version: rawhide Status: NEW Component: perl-DateTime-Format-Strptime Keywords: FutureFeature, Triaged Assignee: p...@city-fan.org Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: p...@city-fan.org, perl-devel@lists.fedoraproject.org, st...@silug.org Target Milestone: --- Classification: Fedora Latest upstream release: 1.77 Current version/release in rawhide: 1.76-4.fc32 URL: http://search.cpan.org/dist/DateTime-Format-Strptime/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/7088/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org
[Bug 1808730] perl-DateTime-1.52 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1808730 --- Comment #1 from Upstream Release Monitoring --- Created attachment 129 --> https://bugzilla.redhat.com/attachment.cgi?id=129=edit [patch] Update to 1.52 (#1808730) -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org
[Bug 1808730] New: perl-DateTime-1.52 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1808730 Bug ID: 1808730 Summary: perl-DateTime-1.52 is available Product: Fedora Version: rawhide Status: NEW Component: perl-DateTime Keywords: FutureFeature, Triaged Assignee: p...@city-fan.org Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: iarn...@gmail.com, p...@city-fan.org, perl-devel@lists.fedoraproject.org, st...@silug.org, trem...@tremble.org.uk Target Milestone: --- Classification: Fedora Latest upstream release: 1.52 Current version/release in rawhide: 1.51-5.fc32 URL: http://search.cpan.org/dist/DateTime/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/2787/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org
Package reviews
Hi all. I have two new packages ready for the review: https://bugzilla.redhat.com/show_bug.cgi?id=1808573 https://bugzilla.redhat.com/show_bug.cgi?id=1808571 I'm available to review other packages in return. -- --- Antonio Trande Fedora Project mailto 'sagitter at fedoraproject dot org' GPG key: 0x7B30EE04E576AA84 GPG key server: https://keys.openpgp.org/ signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: Ideas and proposal for removing changelog and release fields from spec file
On 2/27/20 12:08 AM, Dan Čermák wrote: For the changelog: yes please, generate it from the commit log! They are more or less the same for all my packages and I'm getting tired of copy pasting the same text into %changelog and git commit. Do you know about fedpkg commit --clog ? -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: Ideas and proposal for removing changelog and release fields from spec file
Le samedi 29 février 2020 à 16:11 +0100, Nicolas Mailhot a écrit : > > Build-time state changes need to be commited back, of course > (otherwise the produced srpm needs to be re-imported manually) Probably, only on *successful* production build however. We don’t need to record failed or scratch builds in our package changelogs Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: Ideas and proposal for removing changelog and release fields from spec file
Le samedi 29 février 2020 à 15:12 +0100, clime a écrit :
> On Sat, 29 Feb 2020 at 14:47, Nicolas Mailhot via devel
> wrote:
> > Le samedi 29 février 2020 à 14:28 +0100, clime a écrit :
> > > Does ENVR without %{dist} means something with respect to the
> > > content
> > > from
> > > which the package was built or with respect to features that it
> > > offers for the given distribution version?
> >
> > You need to evaluate evr with a neutral dist value to decide to
> > bump or
> > not the auto-dynamic part of release or not. Because the whole
> > point of
> > the auto-dynamic part of release would be to track rebuilds from
> > the
> > same spec, all othert parts of EVR being equal
> >
> > Changelog-side and package build side you need the full EVR without
> > neutralization
>
> Thank you very much Nicolas but you reacted to a question which was
> actually unrelated to your proposal. That particular question about
> the meaning of ENVR when you strip the distribution tag (i.e. .fc32
> or
> .el7) was intended to be generic, i.e. i want to know how if e.g.
> python3-alembic-1.1.0-1 has any meaning alone without, for example,
> .fc31 appended to it (or if it should have any meaning which is e.g.
> not respected these days).
And I answered you. From a changelog POW you need the full dist because
the exact same stripped/neutralized Release may (and does) exist today
in different branches, pointing to different spec states.
From a dynamic release POW dist is irrelevant to compute the next bump
point and needs stripping. All that matters is that the result evrs
differently, ignoring dist. Keeping branches synchronized or not is a
packager decision (choosing to desync requires specific upgrade path
care, but it is a valid use case today).
And yes that info oriented my proposal. Any other proposal will have to
take it into account too.
Regards,
--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Re: Ideas and proposal for removing changelog and release fields from spec file
Le samedi 29 février 2020 à 13:49 +0100, clime a écrit :
> On Sat, 29 Feb 2020 at 10:15, Nicolas Mailhot via devel
> wrote:
> > Hi,
> >
> > Anyway, here is what I would personnaly consider a robust,
> > inclusive,
> > and future-proof design:
>
> I will need to ask some questions to really understand it.
>
> > — a %{use_dynstate} rpm variable enables dynamic changelog/release
> > behaviour
> > — probably initialy set to false distro-wide, to let volunteers
> > test
> > the thing by setting it to true iin their specs,
> > — then to true (opt-out), when kinks have been fixed, and
> > FPC/FESCO
> > greenlights general availability
> >
> > – when activated, last changelog, evr and %{dynrel} state are saved
> > in one or several detached files
>
> You mean the last changelog, evr, and %{dynrel} are stored once
> %{use_dynstate} is set and and after one invokes fedpkg commit?
> I think there should be some explicit action (e.g. the commit) to
> generate the files after I set the %{use_dynstate} value to true in
> the spec file.
Once a spec sets %{use_dynstate} to true changelog, last computed
changelog, ev, neutralized-r, and %{dynrel} are taken from detached
files. neutralized-r is the evaluation of Release with %{dist} set to a
neutral value (for example “-”).
State is stored in files included in the srpm to be able to import to
and from Fedora git (pretty much a hard requirement if tooling is to be
kept Fedora-git neutral, which is itself a hard requirement to be able
to interact with packaging work existing outside Fedora git).
You need the last computed ev and neutralized-r to decide whether
%{dynrel} can be kept, needs bumping, or should be reset to 1.
I don’t trust mixed mode, KISS, changelog is detached or not, don’t try
to have it both ways, here lies madness and confusion.
> How is %{dynrel} computed here at this stage
Nothing is computed at this stage.
Detached changelog state, is a commit property (except for build date).
It is computed at fedpkg commit time:
– if detached changelog data is absent
→ move in-spec changelog data to the detached file if data exists,
→ otherwise init detached data to nothing
– after the first fedpkg commit with %{use_dynstate} set to true, the
detached changelog file exists and the in-spec changelog has been
removed.
– others have detailed possible fedpkg commit strategies to stuff
changelog with new info
%{dynrel} and build changelog info are a build property. They are
computed at build time:
– if computed ev ≠ last saved ev or last %{dynrel} is undefined
→ reset %{dynrel} to 1
– otherwise if computed neutralized-r = last neutralized-r
→ bump %{dynrel}
– otherwise, do nothing, something already took care of things
– save the new computed ev, computed neutralized-r and dynrel to the
detached files
– add a build line with the full evr (and full dist) to detached
changelog
– at build time, there is no relationship with magic git state or
magic buildsys info, the srpms are 100% autonomous as before. The
detached changelog has already been populated manually or by distro
automation or manual processes when it reaches build stage and a new
build is recorded (with a new dynrel value, if necessary).
> Is the intention here that with each new build of the same package,
> the value of %{dynrel} is bumped and committed back?
It is bumped (or reseted to 1) whenever comparison with last saved
state shows a bump or reset is needed.
Build-time state changes need to be commited back, of course (otherwise
the produced srpm needs to be re-imported manually)
> That means the evr file read from the repository needs to contain
> somehow outdated values at this point (when srpm is being built in
> build system), otherwise %{dynrel} would be always bumped?
Final dynrel state is not computed before a build, yes. The build will
decide if it needs to bump dynrel, or can reset it to 1. I had
forgotten to document the reset, sorry.
There is no need to compute a new dynrel before actual build, the
packager may yet change ev or r.
> > – a build line is added to the detached changelog, using the
> > current
> > date and full evr (without %{dist} neutralization)
> > — that probably requires defining a rpm variable to track whom
> > the
> > build is attributed to
> > – it can default to "Anonymous coward" or whatever if not
> > explicitely
> > set
>
> I think today's changelogs do not contain name of the person who
> built the pacakge
Today’s changelog mixes who made spec changes and who built the result.
That what confuses you. Confusion is anthetical with automation. This
proposal clearly documents that changelog can change at build time
(fedpkg build) and between builds (fedpkg commit).
From a package consumer POW, the only attribution and timestamp that
matters is who build the final package and when, because the builder is
taking the responsability of pushing a result to users.
A clean changelog is:
%changelog
*
Fedora 32 compose report: 20200229.n.0 changes
OLD: Fedora-32-20200228.n.0 NEW: Fedora-32-20200229.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 1 Dropped packages:0 Upgraded packages: 0 Downgraded packages: 0 Size of added packages: 1.09 MiB Size of dropped packages:0 B Size of upgraded packages: 0 B Size of downgraded packages: 0 B Size change of upgraded packages: 0 B Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = Package: rust-zram-generator-0.1.2-2.fc32 Summary: Systemd unit generator for zram devices RPMs:zram-generator Size:1.09 MiB = DROPPED PACKAGES = = UPGRADED PACKAGES = = DOWNGRADED PACKAGES = ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Fedora-32-20200229.n.0 compose check report
No missing expected images. Failed openQA tests: 21/171 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-32-20200228.n.0): ID: 529891 Test: x86_64 Workstation-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/529891 ID: 529940 Test: x86_64 universal install_sata URL: https://openqa.fedoraproject.org/tests/529940 Old failures (same test failed in Fedora-32-20200228.n.0): ID: 529867 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/529867 ID: 529869 Test: x86_64 Server-dvd-iso install_updates_nfs URL: https://openqa.fedoraproject.org/tests/529869 ID: 529917 Test: x86_64 KDE-live-iso desktop_background URL: https://openqa.fedoraproject.org/tests/529917 ID: 529924 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/529924 ID: 529933 Test: x86_64 Silverblue-dvd_ostree-iso desktop_background URL: https://openqa.fedoraproject.org/tests/529933 ID: 529947 Test: x86_64 universal install_simple_encrypted@uefi URL: https://openqa.fedoraproject.org/tests/529947 ID: 529950 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/529950 ID: 529952 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/529952 ID: 529953 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/529953 ID: 529962 Test: x86_64 universal install_software_raid URL: https://openqa.fedoraproject.org/tests/529962 ID: 529963 Test: x86_64 universal install_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/529963 ID: 529970 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/529970 ID: 529975 Test: x86_64 universal install_blivet_software_raid URL: https://openqa.fedoraproject.org/tests/529975 ID: 529978 Test: x86_64 universal install_blivet_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/529978 ID: 529991 Test: x86_64 universal install_simple_encrypted URL: https://openqa.fedoraproject.org/tests/529991 ID: 530003 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/530003 ID: 530010 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/530010 ID: 530011 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/530011 ID: 530016 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/530016 ID: 530017 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/530017 Soft failed openQA tests: 13/171 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-32-20200228.n.0): ID: 529846 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/529846 Old soft failures (same test soft failed in Fedora-32-20200228.n.0): ID: 529845 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/529845 ID: 529848 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/529848 ID: 529850 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/529850 ID: 529853 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/529853 ID: 529854 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/529854 ID: 529874 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/529874 ID: 529937 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/529937 ID: 529946 Test: x86_64 universal install_serial_console URL: https://openqa.fedoraproject.org/tests/529946 ID: 529964 Test: x86_64 universal install_anaconda_text URL: https://openqa.fedoraproject.org/tests/529964 ID: 52 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/52 ID: 530002 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/530002 ID: 530009 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/530009 Passed openQA tests: 121/171 (x86_64) New passes (same test not passed in Fedora-32-20200228.n.0): ID: 529910 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/529910 ID: 530004 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/530004 Skipped non-gating openQA tests: 17 of 173 Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: 1 services(s) added since
Re: Ideas and proposal for removing changelog and release fields from spec file
On Sat, 29 Feb 2020 at 14:47, Nicolas Mailhot via devel
wrote:
>
> Le samedi 29 février 2020 à 14:28 +0100, clime a écrit :
> >
> > Does ENVR without %{dist} means something with respect to the content
> > from
> > which the package was built or with respect to features that it
> > offers for the given distribution version?
>
> You need to evaluate evr with a neutral dist value to decide to bump or
> not the auto-dynamic part of release or not. Because the whole point of
> the auto-dynamic part of release would be to track rebuilds from the
> same spec, all othert parts of EVR being equal
>
> Changelog-side and package build side you need the full EVR without
> neutralization
Thank you very much Nicolas but you reacted to a question which was
actually unrelated to your proposal. That particular question about
the meaning of ENVR when you strip the distribution tag (i.e. .fc32 or
.el7) was intended to be generic, i.e. i want to know how if e.g.
python3-alembic-1.1.0-1 has any meaning alone without, for example,
.fc31 appended to it (or if it should have any meaning which is e.g.
not respected these days).
I posted a separate set of questions to understand your proposal which
is very interesting by the way but the description was a bit fuzzy at
some points so I needed more explanation. If you could rather react
there, it would be awesome.
Thank you again
clime
>
>
> --
> Nicolas Mailhot
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Re: Ideas and proposal for removing changelog and release fields from spec file
Le samedi 29 février 2020 à 14:28 +0100, clime a écrit :
>
> Does ENVR without %{dist} means something with respect to the content
> from
> which the package was built or with respect to features that it
> offers for the given distribution version?
You need to evaluate evr with a neutral dist value to decide to bump or
not the auto-dynamic part of release or not. Because the whole point of
the auto-dynamic part of release would be to track rebuilds from the
same spec, all othert parts of EVR being equal
Changelog-side and package build side you need the full EVR without
neutralization
--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Re: Ideas and proposal for removing changelog and release fields from spec file
On Thu, 27 Feb 2020 at 18:07, Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Tue, Feb 25, 2020 at 05:42:11PM +0100, Miro Hrončok wrote:
> > On 25. 02. 20 9:50, Pierre-Yves Chibon wrote:
> > >Upgrade path may be problematic if you update Fn to a version in less
> > >commit
> > >than the update for Fn-1 (ie: you update F32 to 1.0 in 1 commit and update
> > >F31
> > >to 1.0 in 2 commits, suddenly you have F32 with 1.0-1 and F31 with 1.0-2).
> >
> > I don't consider that an issue. It's not super elegant, but since we
> > do distro-sync on upgrades, it shuld be fine.
>
> Hmm, I don't do distro-sync and in general I think upgrade path is
> something that should be preserved.
>
> What about doing --.?
This is a very good point really. Either it should have been always like that or
we will lose something by removing that number just after the last dash.
I.e. what's the definition of Release number (the number just after
the last dash).
Does it have a definition? I was looking for it in packaging
guidelines but couldn't
find it.
Does ENVR without %{dist} means something with respect to the content from
which the package was built or with respect to features that it offers
for the given
distribution version?
Thank you
clime
> This means that upgrade path not affected by the number of commits or
> builds in the older release.
>
> The numbers in different branches cannot
> be meaningfully compared. Those numbers only make sense in the context
> of a specific branch, so they should be ordered after .
>
> Zbyszek
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Re: Ideas and proposal for removing changelog and release fields from spec file
On Sat, 29 Feb 2020 at 10:15, Nicolas Mailhot via devel
wrote:
>
> Hi,
>
> Anyway, here is what I would personnaly consider a robust, inclusive,
> and future-proof design:
I will need to ask some questions to really understand it.
>
> — a %{use_dynstate} rpm variable enables dynamic changelog/release
> behaviour
> — probably initialy set to false distro-wide, to let volunteers test
> the thing by setting it to true iin their specs,
> — then to true (opt-out), when kinks have been fixed, and FPC/FESCO
> greenlights general availability
>
> – when activated, last changelog, evr and %{dynrel} state are saved in
> one or several detached files
You mean the last changelog, evr, and %{dynrel} are stored once
%{use_dynstate} is set and and after one invokes fedpkg commit?
I think there should be some explicit action (e.g. the commit) to generate
the files after I set the %{use_dynstate} value to true in the spec file.
How is %{dynrel} computed here at this stage - does it have something
to do with the number of commits from the latest version change or
similar?
> — evr computed using a fixed neutral %{dist} value (for example “-”
> since it’s forbidden in %{dist})
>
> – those files are given standard rpm variable names and added to
> Sources:
> – manual packager Source900: %{dynstate} or whatever
> – rpm later updated to allow source file declarations via macros at
> to eliminate boilerplate (I need this in forge and go packages)
> – or the detached files are set in stone as separate Tags with a
> default value overridable via the %{dynstate} variable in a new rpm
> version
>
> – the packager adds %{dynrel} wherever he sees fit in his Release
> string
>
> – at fedpkg commit time changelog state is updated with info taken from
> fedora git state, *without* evr and build date
> – that’s Fedora-specific integration, exact commit/tag syntax to mark
> things to inject or ignore TBD Fedora-side
> – fedpkg commit sets a tag in git to mark anything older can now be
> ignored for changelog generation purposes
> – detached changelog state remains packager-editable, like the in-
> spec changelog today. That allows pruning useless no longer relevant
> stuff and fixing grammar errors
>
> — at rpmbuild -bs stage
> – evr is computed using the same neutral %{dist} value as before, and
> the saved %{dynrel} value
> – if it is equal to the previously saved evr %{dynrel} is bumped and
> saved in the detached file
Is the intention here that with each new build of the same package,
the value of %{dynrel} is bumped and committed back?
Only if other parts of release (other from %{dist} and %{dynrel}) or version or
release have changed, nothing is done? That means the evr file read from the
repository needs to contain somehow outdated values at this point (when srpm
is being built in build system), otherwise %{dynrel} would be always bumped?
> – a build line is added to the detached changelog, using the current
> date and full evr (without %{dist} neutralization)
> — that probably requires defining a rpm variable to track whom the
> build is attributed to
> – it can default to "Anonymous coward" or whatever if not explicitely
> set
I think today's changelogs do not contain name of the person who
built the pacakge (unless it is a mass rebuild), do you think something
like this is needed? Usually a person responsible for release of the
package (for the given "evr") is mentioned in the changelog record.
> – Koji, OBS and Copr can set it to whoever asked them to build the
> package
> – the result constitutes the new srpm (either first or second level
> srpm as upstream rpm sees fit)
You mean there would be different kinds of built srpms? Or otherwise
i don't under why upstream rpm (i understand it as
https://github.com/rpm-software-management/rpm)
should be involved here. What is meant by the "levels"?
> – that’s generic non Fedora-specific behaviour that work as well in
> rpmbuild -bs, mock, copr, koji, OBS, whatever, with or without Fedora
> git presence
> – Koji/copr need to commit the new dynamic dynrel/changelog state to
> git (a build-striggered state change is commited by the build system)
For copr, it is not possible, because it has read-only access to git
repositories being built.
> And yes that requires some work rpm-side. That is necessary to maintain
> the rpm decentralized design and keep srpms independent from anyone’s
> git state. Personnaly, I don’t see the point of pretending we can move
> our infra forward without ever touching rpm.
I think there are good examples where some things can be done without
rpm changes - e.g. the simple-koji-ci to do automatic scratch builds
on a new commit.
> The cardinal sin of
> Modularity was attempting to create an overlay over existing rpm/dnf
> behaviour, without changing this behaviour when it needed improving.
>
> Contrat that with dynamic buildrequires or weak deps that slotted into
> our workflows with hardly any ripple. Though
Re: Tox automation in packaging macros
On 28. 02. 20 23:49, Miro Hrončok wrote:
A follow-up observation, btw: can we exclude things from
pyproject_buildrequires ? (whether that's done at the level of the
dynamic build generation process itself, or within the pyproject
macro/tool I don't care - but I couldn't find any docs indicating it's
possible at either level so far).
You can patch/sed/etc. upstream metadata in %prep. The original idea is that if
upstream metadata is wrong, it should be fixed in upstream, not in spec.
I use setuptools-git for most of my projects. So in pyproject.toml I'm
putting this:
requires = ["setuptools>=40.6.0", "setuptools-git", "wheel"]
because setuptools-git is needed *to produce the source distribution*,
thus it is a 'requires' so far as PEP-517/518 are concerned. However,
it's not a BuildRequires for a Fedora package, because a Fedora package
build *starts* from the source distribution. It doesn't need to produce
one.
I see the problem, but I don't see a nice solution.
What about this?
%generate_buildrequires
%{pyproject_buildrequires -t} | grep -v setuptools-git
https://src.fedoraproject.org/rpms/pyproject-rpm-macros/pull-request/35
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Fedora-Cloud-31-20200229.0 compose check report
No missing expected images. Passed openQA tests: 1/1 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: Ideas and proposal for removing changelog and release fields from spec file
Hi,
Anyway, here is what I would personnaly consider a robust, inclusive,
and future-proof design:
— a %{use_dynstate} rpm variable enables dynamic changelog/release
behaviour
— probably initialy set to false distro-wide, to let volunteers test
the thing by setting it to true iin their specs,
— then to true (opt-out), when kinks have been fixed, and FPC/FESCO
greenlights general availability
– when activated, last changelog, evr and %{dynrel} state are saved in
one or several detached files
— evr computed using a fixed neutral %{dist} value (for example “-”
since it’s forbidden in %{dist})
– those files are given standard rpm variable names and added to
Sources:
– manual packager Source900: %{dynstate} or whatever
– rpm later updated to allow source file declarations via macros at
to eliminate boilerplate (I need this in forge and go packages)
– or the detached files are set in stone as separate Tags with a
default value overridable via the %{dynstate} variable in a new rpm
version
– the packager adds %{dynrel} wherever he sees fit in his Release
string
– at fedpkg commit time changelog state is updated with info taken from
fedora git state, *without* evr and build date
– that’s Fedora-specific integration, exact commit/tag syntax to mark
things to inject or ignore TBD Fedora-side
– fedpkg commit sets a tag in git to mark anything older can now be
ignored for changelog generation purposes
– detached changelog state remains packager-editable, like the in-
spec changelog today. That allows pruning useless no longer relevant
stuff and fixing grammar errors
— at rpmbuild -bs stage
– evr is computed using the same neutral %{dist} value as before, and
the saved %{dynrel} value
– if it is equal to the previously saved evr %{dynrel} is bumped and
saved in the detached file
– a build line is added to the detached changelog, using the current
date and full evr (without %{dist} neutralization)
— that probably requires defining a rpm variable to track whom the
build is attributed to
– it can default to "Anonymous coward" or whatever if not explicitely
set
– Koji, OBS and Copr can set it to whoever asked them to build the
package
– the result constitutes the new srpm (either first or second level
srpm as upstream rpm sees fit)
– that’s generic non Fedora-specific behaviour that work as well in
rpmbuild -bs, mock, copr, koji, OBS, whatever, with or without Fedora
git presence
– Koji/copr need to commit the new dynamic dynrel/changelog state to
git (a build-striggered state change is commited by the build system)
And yes that requires some work rpm-side. That is necessary to maintain
the rpm decentralized design and keep srpms independent from anyone’s
git state. Personnaly, I don’t see the point of pretending we can move
our infra forward without ever touching rpm. The cardinal sin of
Modularity was attempting to create an overlay over existing rpm/dnf
behaviour, without changing this behaviour when it needed improving.
Contrat that with dynamic buildrequires or weak deps that slotted into
our workflows with hardly any ripple. Though they were major feature
changes. But, they were done with rpm upstream, instead of trying to
bypass it.
Regards,
--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
