Bug 1890701 - fedpkg chain-build does not recognize --skip-nvr-check
Summary: fedpkg chain-build does not recognize --skip-nvr-check
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: fedpkg
Version: 33
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Ondřej Nosek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-10-22 18:18 UTC by Miro Hrončok
Modified: 2020-12-13 02:35 UTC (History)
7 users (show)

Fixed In Version: fedpkg-1.40-1.fc33 fedpkg-1.40-1.fc32
Clone Of:
Environment:
Last Closed: 2020-12-07 01:20:02 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Miro Hrončok 2020-10-22 18:18:49 UTC
See this interaction with fedpkg:

[python3.9 (master)]$ fedpkg chain-build --target=eln python-pip
Could not execute chainbuild: Package python3.9-3.9.0-1.fc34 has already been built
Note: You can skip this check with --skip-nvr-check. See help for more info.

[python3.9 (master)]$ fedpkg chain-build --target=eln python-pip --skip-nvr-check
fedpkg: error: unrecognized arguments: --skip-nvr-check


It doesn't matter where I put the switch (after fedpkg, after chain-build, at the end), it is unrecognized. I've checked and it is not mentioned in help either:

$ fedpkg chain-build --help
...
optional arguments:
  -h, --help            show this help message and exit
  --arches [ARCHES ...]
                        Build for specific arches
  --md5                 Use md5 checksums (for older rpm hosts)
  --nowait              Don't wait on build
  --target TARGET       Define build target to build into
  --background          Run the build at a low priority
  --fail-fast           Fail the build immediately if any arch fails
  --skip-remote-rules-validation
                        Don't check if there's a valid gating.yaml file in the repo, where you can define additional policies for Greenwave gating.

------------------

I think this is a bug. Especially when the failed command recommends the switch.


$ rpm -q fedpkg 
fedpkg-1.39-1.fc33.noarch

$ rpm -q rpkg-common 
rpkg-common-1.61-1.fc33.noarch

Comment 1 Ondřej Nosek 2020-11-11 11:27:42 UTC
I looked at this issue.
I found, that when chain-build is run with multiple packages (last package is always the one from active repo), only the last package is checked (nvr, unpushed changes). For other packages, only URL is sent to koji. To check all of them would require cloning them and would make this change complex and would make build operation longer as well.
I think that chain build is not so widely used. What is your typical usage for it? Does nvr_checking has its purpose?
1) I can add the skip option to the chain-build parser to disable checking for the LAST package.
2) I can keep it as it is, just modify the message suggesting --skip-nvr-check option not to confuse user.
3) I can disable check by default for chain-build. Maybe it is better not to perform checking as chain-build is probably used by more advanced users and they know what they do.

@Miro, do you have some suggestion?

Comment 2 Miro Hrončok 2020-11-11 14:17:23 UTC
> I think that chain build is not so widely used. What is your typical usage for it? Does nvr_checking has its purpose?

I use it when I need to, well... chain build things. E.g. in side tags. The typical usage is like shown in the example above, except without eln. nvr_checking is good to let me know I need to do git pull when I forget to do it.


> 1) I can add the skip option to the chain-build parser to disable checking for the LAST package.

That seems like the proper fix to me.


2) I can keep it as it is, just modify the message suggesting --skip-nvr-check option not to confuse user.

That doesn't really work. Especially with eln, disabling nvr check is often the only way to build.



3) I can disable check by default for chain-build. Maybe it is better not to perform checking as chain-build is probably used by more advanced users and they know what they do.

That would fix the problem at hand, but I think 1) is better.

Comment 3 Ondřej Nosek 2020-11-11 16:05:00 UTC
OK, 1) can be seen here:
https://pagure.io/rpkg/pull-request/528

Comment 4 Ondřej Nosek 2020-12-02 01:35:23 UTC
Going to be released in rpkg-1.62-1

Comment 5 Fedora Update System 2020-12-04 22:26:32 UTC
FEDORA-2020-3c9702ca4d has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-3c9702ca4d

Comment 6 Fedora Update System 2020-12-04 23:36:11 UTC
FEDORA-2020-36f82ae84e has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-36f82ae84e

Comment 7 Fedora Update System 2020-12-05 01:59:52 UTC
FEDORA-2020-3c9702ca4d has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-3c9702ca4d`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-3c9702ca4d

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 8 Fedora Update System 2020-12-05 02:08:26 UTC
FEDORA-2020-36f82ae84e has been pushed to the Fedora 32 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-36f82ae84e`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-36f82ae84e

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 9 Fedora Update System 2020-12-07 01:20:02 UTC
FEDORA-2020-3c9702ca4d has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 10 Fedora Update System 2020-12-13 02:35:24 UTC
FEDORA-2020-36f82ae84e has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.