Re: Releasing package updates in multiple Fedora releases
Hi, A little late for the party , I decide publish my helper_scripts on a github repo, maybe all this will be supersede by Packit https://github.com/sergiomb2/herlper_scripts Usage : fedpkg clone foo-package cd foo-packge ~/bin/update_from_bugzilla.sh id_bug stage_number echo "stage 0: rpmdev-bumpspec" echo "stage 1: scratch-build" echo "stage 2: rfpkg new-sources && fedpkg ci -c && git show" echo "stage 3: fedpkg push && fedpkg build on rawhide" echo "stage 4: build all branches" echo "stage 5: bodhi updates all branches" On Mon, 2023-06-19 at 13:58 +0200, Sandro wrote: > On 19-06-2023 12:51, Miroslav Suchý wrote: > > > Sounds like these tools are worth mentioning in the docs, seeing > > > how > > > many people face the same challenge. > > > > We (I am part of Packit team) plan to do more noise about it later. > > Especially this feature - we have finished it in January and asked > > few > > people to try it. We have done several rounds of fix-and-try- > > again. > > Today, we have one outstanding issue "manually re-trigger event" > > and I > > believe that once implemented, it will be ready for wide audience. > > If > > you are brave and ready for bleeding edge, you can try it now. > > I didn't realize Packit is still very new. So new, it's still warm, > like > the blood dripping off its edge... ;) > > I'll certainly try it out and provide feedback should I have any. > Thanks, Miro! > > -- Sandro > ___ > 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 > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Sérgio M. B. ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Releasing package updates in multiple Fedora releases
On Tue, 2023-06-20 at 21:01 -0600, Orion Poplawski wrote: > > You're addition of git pull is a good thing. It's based on unfortunate experience. :D Using ; not && (as some others suggested) is bad, though, I'll have to change that (would save me some panicked ctrl-c'ing). I'm just somehow used to using ; in handcrafted loops so I do it automatically... -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Releasing package updates in multiple Fedora releases
On 6/18/23 04:28, Adam Williamson wrote:
On Sun, 2023-06-18 at 09:16 +, Mattia Verga via devel wrote:
For the 99% of packages I maintain I usually perform the same workflow
when updating them:
1. Update spec and source in Rawhide
2. commit and push
3. fedpkg build
4. fedpkg switch-branch f*
5. git merge rawhide
6. push and fedpkg build
And repeat 4-5-6 for every f*/epel* branches where I want to push the
update.
This is quite boring and time wasting... is there a more efficient way
to use my packaging time? Do you think fedpkg can be enhanced to have a
single command which makes 4-5-6 to all specified branches?
I have this in my command history:
for i in f37 f38 rawhide; do fedpkg switch-branch $i; git pull; git merge
rawhide; fedpkg push; fedpkg build --nowait; done
Similar:
In my .bashrc:
fpbr() { for rel in $*; do fedpkg switch-branch $rel; git merge rawhide
&& git push && fedpkg build --nowait; done; }
You're addition of git pull is a good thing.
--
Orion Poplawski
he/him/his - surely the least important thing about me
IT Systems Manager 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
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Releasing package updates in multiple Fedora releases
On 19-06-2023 12:51, Miroslav Suchý wrote: Sounds like these tools are worth mentioning in the docs, seeing how many people face the same challenge. We (I am part of Packit team) plan to do more noise about it later. Especially this feature - we have finished it in January and asked few people to try it. We have done several rounds of fix-and-try-again. Today, we have one outstanding issue "manually re-trigger event" and I believe that once implemented, it will be ready for wide audience. If you are brave and ready for bleeding edge, you can try it now. I didn't realize Packit is still very new. So new, it's still warm, like the blood dripping off its edge... ;) I'll certainly try it out and provide feedback should I have any. Thanks, Miro! -- Sandro ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Releasing package updates in multiple Fedora releases
On Mon, Jun 19, 2023 13:02:45 +0200, Vít Ondruch wrote: > > Dne 19. 06. 23 v 11:55 Ankur Sinha napsal(a): > > > > > We're discussing a different topic now. > > > Sorry but we don't. The thread started with: "For the 99% of packages I > maintain I usually perform the same workflow > when updating them". I don't see that percentage could be in line with the > update policy. > It really depends on what these packages are (and had I assumed that was hyperbole anyway). It sure wouldn't apply to 99% of my (or the neuro-sig) packages, but would to quite a few. To re-iterate: everyone should remember to check what impact their package builds/updates have on other packages before building/pushing (even for rawhide). > > The thread was "these steps are > > repetitive, how do folks automate them", and we're now discussing > > "maintainers should remember to check the impact of update before > > pushing them". > > > Being maintainer of ~200 packages, I certainly don't suffer the > repetitiveness, because there is rarely need to update the stable releases, > following the update policy. Again, it really depends on your packages. You maintain lots of core libraries where API/ABI bumps etc. do not/should not be pushed to stable releases. For the neuro-sig, we do have quite a few python packages that have frequent minor/patch releases and we do push these as updates to stable branches also after doing impact checks. So, I do use my script for these. -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Releasing package updates in multiple Fedora releases
Dne 19. 06. 23 v 11:55 Ankur Sinha napsal(a): On Mon, Jun 19, 2023 11:22:35 +0200, Vít Ondruch wrote: Right, not pushing to all branches is in line with official guidelines: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases It's more nuanced than "don't push updates to all branches" though: ".. we should avoid major updates of packages within a stable release. Updates should aim to fix bugs, and not introduce features, particularly when those features would materially affect the user or developer experience. The update rate for any given release should drop off over time, approaching zero near release end-of-life; since updates are primarily bugfixes, fewer and fewer should be needed over time." So minor/patch version updates, especially for things like Python packages that have frequent minor/patch releases is perfectly fine. Especially I don't like my packages being FTBFS due to other packagers pushing their updates everywhere. If there was at least included mass-prebuild step in the initial list to ensure there is no breakage in dependent packages. This is part of the "vetting the update before pushing" step. We have tools that package maintainers can/should use to see what packages depend on a particular one before updating it (fedrq is one I believe, but folks have their own dnf based scripts/commands). I've also filed an RFE to the-new-hotness to add dependency information to the "new package version is available" bug report some time ago, which would help ensure maintainers are aware of the update's impact: https://github.com/fedora-infra/the-new-hotness/issues/545 We're discussing a different topic now. Sorry but we don't. The thread started with: "For the 99% of packages I maintain I usually perform the same workflow when updating them". I don't see that percentage could be in line with the update policy. The thread was "these steps are repetitive, how do folks automate them", and we're now discussing "maintainers should remember to check the impact of update before pushing them". Being maintainer of ~200 packages, I certainly don't suffer the repetitiveness, because there is rarely need to update the stable releases, following the update policy. Vít OpenPGP_signature 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Releasing package updates in multiple Fedora releases
Dne 19. 06. 23 v 11:30 Sandro napsal(a): 2) Even better is Packit https://packit.dev/ You have many ways to use it. My favorite way is to use pull-from-upstream https://packit.dev/posts/pull-from-upstream/ You just make sure you have record in https://release-monitoring.org/ and then put .packit.yaml in Fedora's dist-git. And when upstream has a new release you will receive a pull request to src.fedoraproject.org for all configure branches. And when it merges it (can) build in Koji and submit Bodhi update for you. With Packit you can use full automation or only some steps. And combine it as you like it. If you do not like triggereing by release monitoring, you can initiate it from command line. It is up to you. Sounds like these tools are worth mentioning in the docs, seeing how many people face the same challenge. We (I am part of Packit team) plan to do more noise about it later. Especially this feature - we have finished it in January and asked few people to try it. We have done several rounds of fix-and-try-again. Today, we have one outstanding issue "manually re-trigger event" and I believe that once implemented, it will be ready for wide audience. If you are brave and ready for bleeding edge, you can try it now. -- Miroslav Suchy, RHCA Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Releasing package updates in multiple Fedora releases
On Mon, Jun 19, 2023 08:28:23 +0200, Vitaly Zaitsev via devel wrote: > On 18/06/2023 17:42, Ankur Sinha wrote: > > I threw all the commands into a script with some optional arguments: > > Maybe this script can be added to fedora-packager? Sure, if folks find it useful enough. In the meantime, I added bits to run `fedrq` before each branch is worked upon to inform the user what packages would be affected: https://github.com/sanjayankur31/100_dotfiles/blob/main/bin/fedpkg-sync-build-all-branches.sh#L30 -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Releasing package updates in multiple Fedora releases
On Mon, Jun 19, 2023 11:22:35 +0200, Vít Ondruch wrote: > Right, not pushing to all branches is in line with official guidelines: > > https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases It's more nuanced than "don't push updates to all branches" though: ".. we should avoid major updates of packages within a stable release. Updates should aim to fix bugs, and not introduce features, particularly when those features would materially affect the user or developer experience. The update rate for any given release should drop off over time, approaching zero near release end-of-life; since updates are primarily bugfixes, fewer and fewer should be needed over time." So minor/patch version updates, especially for things like Python packages that have frequent minor/patch releases is perfectly fine. > Especially I don't like my packages being FTBFS due to other packagers > pushing their updates everywhere. If there was at least included > mass-prebuild step in the initial list to ensure there is no breakage in > dependent packages. This is part of the "vetting the update before pushing" step. We have tools that package maintainers can/should use to see what packages depend on a particular one before updating it (fedrq is one I believe, but folks have their own dnf based scripts/commands). I've also filed an RFE to the-new-hotness to add dependency information to the "new package version is available" bug report some time ago, which would help ensure maintainers are aware of the update's impact: https://github.com/fedora-infra/the-new-hotness/issues/545 We're discussing a different topic now. The thread was "these steps are repetitive, how do folks automate them", and we're now discussing "maintainers should remember to check the impact of update before pushing them". -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Releasing package updates in multiple Fedora releases
On 19-06-2023 11:04, Miroslav Suchý wrote: Dne 18. 06. 23 v 11:16 Mattia Verga via devel napsal(a): This is quite boring and time wasting... is there a more efficient way to use my packaging time? Do you think fedpkg can be enhanced to have a single command which makes 4-5-6 to all specified branches? I know several ways: 1) Tito https://github.com/rpm-software-management/tito This requires upstream modification. Namely .tito/releasers.conf https://github.com/rpm-software-management/tito/blob/master/.tito/releasers.conf Then you can (e.g. in the Tito git repo itself) run: tito release fedora or tito release copr and it will build the package in Fedora's Koji for all configured versions. Or in Copr. As you configure it. 2) Even better is Packit https://packit.dev/ You have many ways to use it. My favorite way is to use pull-from-upstream https://packit.dev/posts/pull-from-upstream/ You just make sure you have record in https://release-monitoring.org/ and then put .packit.yaml in Fedora's dist-git. And when upstream has a new release you will receive a pull request to src.fedoraproject.org for all configure branches. And when it merges it (can) build in Koji and submit Bodhi update for you. With Packit you can use full automation or only some steps. And combine it as you like it. If you do not like triggereing by release monitoring, you can initiate it from command line. It is up to you. Sounds like these tools are worth mentioning in the docs, seeing how many people face the same challenge. -- Sandro ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Releasing package updates in multiple Fedora releases
On Mon, Jun 19, 2023 11:04:16 +0200, Miroslav Suchý wrote: > > 2) Even better is Packit > > https://packit.dev/ > > You have many ways to use it. My favorite way is to use pull-from-upstream > > https://packit.dev/posts/pull-from-upstream/ > > You just make sure you have record in https://release-monitoring.org/ and > then put .packit.yaml in Fedora's dist-git. And when upstream has a new > release you will receive a pull request to src.fedoraproject.org for all > configure branches. And when it merges it (can) build in Koji and submit > Bodhi update for you. > > With Packit you can use full automation or only some steps. And combine it > as you like it. If you do not like triggereing by release monitoring, you > can initiate it from command line. It is up to you. > This is awesome! I've been meaning to try Packit for a while now. Will try it asap. -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Releasing package updates in multiple Fedora releases
Right, not pushing to all branches is in line with official guidelines: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases Especially I don't like my packages being FTBFS due to other packagers pushing their updates everywhere. If there was at least included mass-prebuild step in the initial list to ensure there is no breakage in dependent packages. Vít Dne 19. 06. 23 v 9:22 Richard W.M. Jones napsal(a): On Sun, Jun 18, 2023 at 09:16:28AM +, Mattia Verga via devel wrote: For the 99% of packages I maintain I usually perform the same workflow when updating them: 1. Update spec and source in Rawhide 2. commit and push 3. fedpkg build 4. fedpkg switch-branch f* 5. git merge rawhide 6. push and fedpkg build And repeat 4-5-6 for every f*/epel* branches where I want to push the update. This is quite boring and time wasting... is there a more efficient way to use my packaging time? Do you think fedpkg can be enhanced to have a single command which makes 4-5-6 to all specified branches? So one alternative is *not* to push the change to all branches. Unless it's really necessary, such as fixing an essential bug, I tend to leave older Fedora branches on a stable release, to reduce churn for users. eg: $ cd fedora/libnbd $ for f in f* rawhide ; do (cd $f && fedpkg verrel); done Using libnbd.spec libnbd-1.0.2-1.fc29 Using libnbd.spec libnbd-1.2.2-1.fc30 Using libnbd.spec libnbd-1.4.1-1.fc31 Using libnbd.spec libnbd-1.6.2-1.fc32 Using libnbd.spec libnbd-1.6.5-1.fc33 Using libnbd.spec libnbd-1.8.6-1.fc34 Using libnbd.spec libnbd-1.10.5-1.fc35 Using libnbd.spec libnbd-1.12.7-1.fc36 Using libnbd.spec libnbd-1.14.2-1.fc37 Using libnbd.spec libnbd-1.16.1-1.fc38 Using libnbd.spec libnbd-1.16.1-2.fc39 (Also note 'fedpkg clone -B' option to use a separate subdirectory for each branch, much more intuitive IMHO.) Rich. OpenPGP_signature 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Releasing package updates in multiple Fedora releases
On Mon, Jun 19, 2023 08:46:47 -, Michael J Gruber wrote: > > On Sun, Jun 18, 2023 at 09:16:28AM +, Mattia Verga via devel wrote: > > > > So one alternative is *not* to push the change to all branches. > > > > Unless it's really necessary, such as fixing an essential bug, I tend > > to leave older Fedora branches on a stable release, to reduce churn > > Exactly. Blindly pushing to all active releases is never a good idea. > Now, I'm not saying people here do that, but those shortcuts make it > too easy to do it in a rash ... > > In particular: Most proposals do it in the wrong order (old to new) > and some without error catching. You may end up with newer builds in > older releases - without an update yet, granted, but still. I think folks here on the list understand that each update needs to be vetted. Once it has been vetted and we know it can go to rawhide + other releases, it's nice to be able to do it quickly and move on to other packages. So shortcuts + automation is always welcome in cases where we know it's doing the right thing. -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Releasing package updates in multiple Fedora releases
On Mon, Jun 19, 2023 at 08:46:47AM -, Michael J Gruber wrote:
> > On Sun, Jun 18, 2023 at 09:16:28AM +, Mattia Verga via devel wrote:
> > (Also note 'fedpkg clone -B' option to use a separate subdirectory for
> > each branch, much more intuitive IMHO.)
>
> That creates a bunch of unrelated git repos. Maybe we should teach
> fedpkg to use current git's method for that, which is
> worktrees. That way you share not only the object store ("one fetch
> rules them all") but also config such as remote definitions (for
> forks) etc. The main worktree could be a main/rawhide checkout.
I actually thought it worked like this but I checked now and you're
right that it is creating multiple git repos. In practice it's not a
huge problem, but worktrees would be better.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
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
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Releasing package updates in multiple Fedora releases
Dne 18. 06. 23 v 11:16 Mattia Verga via devel napsal(a): This is quite boring and time wasting... is there a more efficient way to use my packaging time? Do you think fedpkg can be enhanced to have a single command which makes 4-5-6 to all specified branches? I know several ways: 1) Tito https://github.com/rpm-software-management/tito This requires upstream modification. Namely .tito/releasers.conf https://github.com/rpm-software-management/tito/blob/master/.tito/releasers.conf Then you can (e.g. in the Tito git repo itself) run: tito release fedora or tito release copr and it will build the package in Fedora's Koji for all configured versions. Or in Copr. As you configure it. 2) Even better is Packit https://packit.dev/ You have many ways to use it. My favorite way is to use pull-from-upstream https://packit.dev/posts/pull-from-upstream/ You just make sure you have record in https://release-monitoring.org/ and then put .packit.yaml in Fedora's dist-git. And when upstream has a new release you will receive a pull request to src.fedoraproject.org for all configure branches. And when it merges it (can) build in Koji and submit Bodhi update for you. With Packit you can use full automation or only some steps. And combine it as you like it. If you do not like triggereing by release monitoring, you can initiate it from command line. It is up to you. Miroslav -- Miroslav Suchy, RHCA Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Releasing package updates in multiple Fedora releases
> On Sun, Jun 18, 2023 at 09:16:28AM +, Mattia Verga via devel wrote:
>
> So one alternative is *not* to push the change to all branches.
>
> Unless it's really necessary, such as fixing an essential bug, I tend
> to leave older Fedora branches on a stable release, to reduce churn
Exactly. Blindly pushing to all active releases is never a good idea. Now, I'm
not saying people here do that, but those shortcuts make it too easy to do it
in a rash ...
In particular: Most proposals do it in the wrong order (old to new) and some
without error catching. You may end up with newer builds in older releases -
without an update yet, granted, but still.
> ...
>
> (Also note 'fedpkg clone -B' option to use a separate subdirectory for
> each branch, much more intuitive IMHO.)
That creates a bunch of unrelated git repos. Maybe we should teach fedpkg to
use current git's method for that, which is worktrees. That way you share not
only the object store ("one fetch rules them all") but also config such as
remote definitions (for forks) etc. The main worktree could be a main/rawhide
checkout.
Michael
___
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
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Releasing package updates in multiple Fedora releases
On Sun, Jun 18, 2023 at 09:16:28AM +, Mattia Verga via devel wrote: > For the 99% of packages I maintain I usually perform the same workflow > when updating them: > > 1. Update spec and source in Rawhide > 2. commit and push > 3. fedpkg build > 4. fedpkg switch-branch f* > 5. git merge rawhide > 6. push and fedpkg build > > And repeat 4-5-6 for every f*/epel* branches where I want to push the > update. > > This is quite boring and time wasting... is there a more efficient way > to use my packaging time? Do you think fedpkg can be enhanced to have a > single command which makes 4-5-6 to all specified branches? So one alternative is *not* to push the change to all branches. Unless it's really necessary, such as fixing an essential bug, I tend to leave older Fedora branches on a stable release, to reduce churn for users. eg: $ cd fedora/libnbd $ for f in f* rawhide ; do (cd $f && fedpkg verrel); done Using libnbd.spec libnbd-1.0.2-1.fc29 Using libnbd.spec libnbd-1.2.2-1.fc30 Using libnbd.spec libnbd-1.4.1-1.fc31 Using libnbd.spec libnbd-1.6.2-1.fc32 Using libnbd.spec libnbd-1.6.5-1.fc33 Using libnbd.spec libnbd-1.8.6-1.fc34 Using libnbd.spec libnbd-1.10.5-1.fc35 Using libnbd.spec libnbd-1.12.7-1.fc36 Using libnbd.spec libnbd-1.14.2-1.fc37 Using libnbd.spec libnbd-1.16.1-1.fc38 Using libnbd.spec libnbd-1.16.1-2.fc39 (Also note 'fedpkg clone -B' option to use a separate subdirectory for each branch, much more intuitive IMHO.) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com nbdkit - Flexible, fast NBD server with plugins https://gitlab.com/nbdkit/nbdkit ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Releasing package updates in multiple Fedora releases
On 19/06/2023 08:36, Mattia Verga via devel wrote:
I only need to find how to pass branch names to the alias, instead of
hardcoding them. From a quick search I need to create a function in
.bashrc rather than an alias.
Add to ~/.bashrc:
function fpr {
for i in f$(rpm -E %fedora) f$(($(rpm -E %fedora) - 1)) rawhide; do
fedpkg switch-branch $i
if [[ "$i" != "rawhide" ]]; then
git merge rawhide
fi
fedpkg push
fedpkg build --nowait
done
}
Usage:
cd ~/foo-bar
fpr
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.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
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Releasing package updates in multiple Fedora releases
Il 19/06/23 08:26, Vitaly Zaitsev via devel ha scritto: > On 18/06/2023 14:51, Sandro wrote: >> Aren't you missing the 'git push' (or 'fedpkg push')? IIRC, your 'fpb' >> alias would fail since no changes have been pushed to dist-git for koji >> to base a build on. > Good catch. Thanks: > > alias fpm="fedpkg switch-branch f38 && git merge rawhide && fedpkg > switch-branch f37 && git merge rawhide && fedpkg switch-branch rawhide > && git push" > > -- > Sincerely, > Vitaly Zaitsev (vit...@easycoding.org) Nice, thanks. I only need to find how to pass branch names to the alias, instead of hardcoding them. From a quick search I need to create a function in .bashrc rather than an alias. Mattia ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Releasing package updates in multiple Fedora releases
On 18/06/2023 17:42, Ankur Sinha wrote: I threw all the commands into a script with some optional arguments: Maybe this script can be added to fedora-packager? -- Sincerely, Vitaly Zaitsev (vit...@easycoding.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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Releasing package updates in multiple Fedora releases
On 18/06/2023 14:51, Sandro wrote: Aren't you missing the 'git push' (or 'fedpkg push')? IIRC, your 'fpb' alias would fail since no changes have been pushed to dist-git for koji to base a build on. Good catch. Thanks: alias fpm="fedpkg switch-branch f38 && git merge rawhide && fedpkg switch-branch f37 && git merge rawhide && fedpkg switch-branch rawhide && git push" -- Sincerely, Vitaly Zaitsev (vit...@easycoding.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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Releasing package updates in multiple Fedora releases
On Sun, Jun 18, 2023 at 5:17 AM Mattia Verga via devel wrote: > > For the 99% of packages I maintain I usually perform the same workflow > when updating them: > > 1. Update spec and source in Rawhide > 2. commit and push > 3. fedpkg build > 4. fedpkg switch-branch f* > 5. git merge rawhide > 6. push and fedpkg build > > And repeat 4-5-6 for every f*/epel* branches where I want to push the > update. > With fbrnch, you can run `fbrnch parallel --all-fedora`, which will do steps 2.5 (i.e., the push part) through 6 for all Fedora branches (in parallel), and wait for all builds to finish, then produce updates for all of them except rawhide. > This is quite boring and time wasting... is there a more efficient way > to use my packaging time? Do you think fedpkg can be enhanced to have a > single command which makes 4-5-6 to all specified branches? > > Mattia > ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Releasing package updates in multiple Fedora releases
On Sun, Jun 18, 2023 14:51:01 +0200, Sandro wrote: > On 18-06-2023 14:16, Vitaly Zaitsev via devel wrote: > > On 18/06/2023 11:16, Mattia Verga via devel wrote: > > > This is quite boring and time wasting... is there a more efficient way > > > to use my packaging time? Do you think fedpkg can be enhanced to have a > > > single command which makes 4-5-6 to all specified branches? I threw all the commands into a script with some optional arguments: https://github.com/sanjayankur31/100_dotfiles/blob/main/bin/fedpkg-sync-build-all-branches.sh I did think that a fedpkg subcommand would would be very useful, but I haven't found the cycles to look into it. -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Releasing package updates in multiple Fedora releases
On 18-06-2023 14:16, Vitaly Zaitsev via devel wrote: On 18/06/2023 11:16, Mattia Verga via devel wrote: This is quite boring and time wasting... is there a more efficient way to use my packaging time? Do you think fedpkg can be enhanced to have a single command which makes 4-5-6 to all specified branches? Add to your ~/.bashrc the following: alias fpm="fedpkg switch-branch f38 && git merge rawhide && fedpkg switch-branch f37 && git merge rawhide && fedpkg switch-branch rawhide" alias fpb="fedpkg switch-branch rawhide && fedpkg build --nowait && fedpkg switch-branch f38 && fedpkg build --nowait && fedpkg switch-branch f37 && fedpkg build --nowait && fedpkg switch-branch rawhide" Aren't you missing the 'git push' (or 'fedpkg push')? IIRC, your 'fpb' alias would fail since no changes have been pushed to dist-git for koji to base a build on. Usage: cd ~/foo-bar fpm fpb ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Releasing package updates in multiple Fedora releases
On 18/06/2023 11:16, Mattia Verga via devel wrote: This is quite boring and time wasting... is there a more efficient way to use my packaging time? Do you think fedpkg can be enhanced to have a single command which makes 4-5-6 to all specified branches? Add to your ~/.bashrc the following: alias fpm="fedpkg switch-branch f38 && git merge rawhide && fedpkg switch-branch f37 && git merge rawhide && fedpkg switch-branch rawhide" alias fpb="fedpkg switch-branch rawhide && fedpkg build --nowait && fedpkg switch-branch f38 && fedpkg build --nowait && fedpkg switch-branch f37 && fedpkg build --nowait && fedpkg switch-branch rawhide" Usage: cd ~/foo-bar fpm fpb -- Sincerely, Vitaly Zaitsev (vit...@easycoding.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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Releasing package updates in multiple Fedora releases
On Sun, 2023-06-18 at 09:16 +, Mattia Verga via devel wrote: > For the 99% of packages I maintain I usually perform the same workflow > when updating them: > > 1. Update spec and source in Rawhide > 2. commit and push > 3. fedpkg build > 4. fedpkg switch-branch f* > 5. git merge rawhide > 6. push and fedpkg build > > And repeat 4-5-6 for every f*/epel* branches where I want to push the > update. > > This is quite boring and time wasting... is there a more efficient way > to use my packaging time? Do you think fedpkg can be enhanced to have a > single command which makes 4-5-6 to all specified branches? I have this in my command history: for i in f37 f38 rawhide; do fedpkg switch-branch $i; git pull; git merge rawhide; fedpkg push; fedpkg build --nowait; done -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Releasing package updates in multiple Fedora releases
On 18-06-2023 11:16, Mattia Verga via devel wrote: And repeat 4-5-6 for every f*/epel* branches where I want to push the update. That drill sounds familiar. ;) If you look at he output of 'fedpkg build --help', there seems to be an option to submit koji builds for multiple targets at once. I think I may have tinkered with it once. But I didn't get it to work and fell back to looping through all branches manually. However, if that works, it would at least simplify the build step and updates could be submitted in Bodhi. Other than that, there's only scripting and/or submitting an RFE for fedpkg. -- Sandro ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Releasing package updates in multiple Fedora releases
For the 99% of packages I maintain I usually perform the same workflow when updating them: 1. Update spec and source in Rawhide 2. commit and push 3. fedpkg build 4. fedpkg switch-branch f* 5. git merge rawhide 6. push and fedpkg build And repeat 4-5-6 for every f*/epel* branches where I want to push the update. This is quite boring and time wasting... is there a more efficient way to use my packaging time? Do you think fedpkg can be enhanced to have a single command which makes 4-5-6 to all specified branches? Mattia ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
