HPC/mvapich4
SHA256
6
0
Fork 1
forked from pool/mvapich4
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Re-download tarball to match the Source: reference in the spec file #4

Closed
dimstar wants to merge 1 commits from (deleted):main into main
pull from: (deleted):main
merge into: HPC:main
Conversation 8 Commits 1 Files Changed 1 +2 -2
dimstar commented 2025-11-10 10:42:29 +01:00
First-time contributor
Copy Link
No description provided.
dimstar added 1 commit 2025-11-10 10:42:30 +01:00
Re-download tarball to match the Source: reference in the spec file 0db88d9405
dimstar commented 2025-11-10 10:43:15 +01:00
Author
First-time contributor
Copy Link

should fix the bot detected error:


Source URLs are not valid. Try `osc service runall download_files`. mvapich-4.1.tar.gz /home/go/co/1316655/mvapich4/mvapich-4.1.tar.gz differ: byte 5, line 1 ERROR: download_files is configured to fail when the upstream file is different than the committed file... this is the case!

from https://build.opensuse.org/requests/1316655

should fix the bot detected error: ``` Source URLs are not valid. Try `osc service runall download_files`. mvapich-4.1.tar.gz /home/go/co/1316655/mvapich4/mvapich-4.1.tar.gz differ: byte 5, line 1 ERROR: download_files is configured to fail when the upstream file is different than the committed file... this is the case! ``` from https://build.opensuse.org/requests/1316655
NMorey requested review from NMorey 2025-11-10 14:49:52 +01:00
NMorey commented 2025-11-10 14:51:52 +01:00
Owner
Copy Link

(Weird. I would have expected the bots to spawn a similar PR to HPC/_ObsPrj to check the build status)
This PR does not work. Upstream applied one of my patch before generating a new tarball with the exact same release id....
So I have to drop that patch as well to fix the build.

(Weird. I would have expected the bots to spawn a similar PR to HPC/_ObsPrj to check the build status) This PR does not work. Upstream applied one of my patch before generating a new tarball with the exact same release id.... So I have to drop that patch as well to fix the build.
dimstar commented 2025-11-10 14:55:22 +01:00
Author
First-time contributor
Copy Link

Respinning tarballs upstream without changing the version ID is bad. But glad you caught the issue

Respinning tarballs upstream without changing the version ID is bad. But glad you caught the issue
dimstar closed this pull request 2025-11-10 14:55:22 +01:00
NMorey commented 2025-11-10 15:02:04 +01:00
Owner
Copy Link

I've pinged them about it. It was well intended but may create a whole lot of issues !
As a contributor to a whole lot of project under this new workflow, do you never get auto PR on the top project like this ?
HPC/_ObsPrj#19

I've pinged them about it. It was well intended but may create a whole lot of issues ! As a contributor to a whole lot of project under this new workflow, do you never get auto PR on the top project like this ? https://src.opensuse.org/HPC/_ObsPrj/pulls/19
dimstar commented 2025-11-10 15:05:03 +01:00
Author
First-time contributor
Copy Link

As Factory did not yet switch to the git workflow (not-yet fully tested/approved staging workflow) I'm not entirely sure.

But yes, as far as I understand, this should have also given you a PR to the project to actually bump to the new revision upon accept; probably I did something unexpectedly wrong :(

As Factory did not yet switch to the git workflow (not-yet fully tested/approved staging workflow) I'm not entirely sure. But yes, as far as I understand, this should have also given you a PR to the project to actually bump to the new revision upon accept; probably I did something unexpectedly wrong :(
NMorey commented 2025-11-10 15:10:47 +01:00
Owner
Copy Link

IIUC there are 2 ways PR are handled:

  • Either the package one (like this one) is merged manually and some bot will automatically update the submodule in the associated _ObsPrj (without going through a PR) like this commit: f01d8973de
  • Or you get an automated PR in _ObsPrj which should trigger the whole acceptance when a project maintainer has review it AND the build was succesfull.

My PR did not get one either. I'm guessing there's something broken somewhere.

IIUC there are 2 ways PR are handled: - Either the package one (like this one) is merged manually and some bot will automatically update the submodule in the associated _ObsPrj (without going through a PR) like this commit: https://src.opensuse.org/HPC/_ObsPrj/commit/f01d8973de3ee2d651f254a58a6268c62d5483824083521977beb050c0eaca3f - Or you get an automated PR in _ObsPrj which should trigger the whole acceptance when a project maintainer has review it AND the build was succesfull. My PR did not get one either. I'm guessing there's something broken somewhere.
NMorey commented 2025-11-10 18:07:03 +01:00
Owner
Copy Link

Reopening for some testing

Reopening for some testing
NMorey reopened this pull request 2025-11-10 18:07:03 +01:00
NMorey requested changes 2025-11-10 18:07:39 +01:00
NMorey left a comment
Owner
Copy Link

Denying to test the workflow :)

Denying to test the workflow :)
NMorey closed this pull request 2025-11-10 18:08:00 +01:00

Pull request closed

This pull request cannot be reopened because the branch was deleted.
Sign in to join this conversation.
Reviewers
No Reviewers
NMorey
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
NMorey adamm_super autogits-devel dstoecker eeich mslacken
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: HPC/mvapich4#4
Delete Branch "(deleted):main"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?