~ sudo dnf install fedpkg
Updating and loading repositories:
Repositories loaded.
Failed to resolve the transaction:
Problem: problem with installed package
- package python3-gcsfs-2022.11.0-2.fc38.noarch requires python3.11dist(requests), but none of the providers can be installed
- cannot install both python3-requests-2.28.2-2.fc39.noarch and python3-requests-2.28.2-4.fc39.noarch
- package bodhi-client-7.2.0-2.fc39.noarch requires (python3.12dist(requests) < 3~~ with python3.12dist(requests) >= 2.27), but none of the providers can be installed
- package fedpkg-1.44-5.fc39.noarch requires python3-bodhi-client, but none of the providers can be installed
- package fedpkg-1.44-5.fc39.noarch requires python3.12dist(bodhi-client), but none of the providers can be installed
- conflicting requests
Nothing on your side. The latest version in the repositories is currently broken because it did not correctly build for python 3.12. So, you need to wait for the new version of the package to be built and pushed to the repositories. For that the pull request needs to be merged.
This is why using rawhide for development is not a good idea, usually around mass-rebuilds when packages may be broken for a while. It takes time to figure out the complete dependency chain to see what packages are broken, and then packages need to be fixed one by one.
Yes, but you need to understand the target audience for rawhide as noted here:
Unfortunately, it is not meant for users that are not well versed with how the package maintenance system works. I’ve been a Fedora contributor for quite a while, and I only use rawhide to test rawhide, never to do work.
Here are the usual steps:
first one checks to see what bugs are open for the package: Bug List (you can get here from the Fedora packages app, or from src.fp.o)
As you see there, there are bugs opened for a number of things: FTI and FTBFS ; and that a new version is available.
Then we check if the bug has been responded to by the maintainer. If we can help, we check Overview - rpms/python-gcsfs - src.fedoraproject.org to see if a fix or a pull request has been made, if not, we can help by providing one if possible.
Yes is yes. So, for users to grow into contributors, the pipeline on how to get updated versions of their package themselves should be clear regardless of it is rawhide or not. Do you agree?
Thanks for clarifying the workflow. From the UX point of view, the workflow is attuned to manual mentoring rather than for funneling the growth of contributors :
knowing to check for bugs to check for new versions, instead of checking directly what new version is
digging for the links and manually clicking through web pages, instead of having relevant info right in the terminal (dnf --explain or dnf --dig could be the interface for that)
FTI, FTBFS and - common abbreviations, but I don’t know/remember what a FTI is
checking if there is a response to FTI, FTBS and to version bug by manually clicking 3 pages and scrolling them down
clicking through unfamiliar src.fedoraproject.org forge to locate PRs
And all that is even before the PR to bump the package version is filled (which was my original question - how to make changes to make that PR).
So my question is basically - how to do it manually what fedpkg is supposed to do?
By the way, I removed python3-gcsfs package. I have no idea why it was installed in the first place. But there even more similar problems that keep dnf install fedpkg from running.
fedpkg does many things. rpmdev-bumpspec bumps the package version for you, but you can just edit the spec file in the editor of your choice. fedpkg push/clone etc. are basically git commands. fedpkg update is basically bodhi update.
But really @ankursinha has given you good advice and pointers. Maybe try it out that way!
In a way yes, but packages are maintained by individuals (or teams that co-maintain them). It is not expected that users, or indeed other package maintainers, update all the packages they use—it is just not scalable. So we look after “our” packages and we work with each other to keep other packages that we may rely on in shape.
OK, so say you check directly to see that a new version is available. For one software this works. I maintain 300 packages—how do I manually check that new versions are available for each of these 300 packages upstream?
The solution is to use release-monitoring.org. Instead of a human having to manually check for new versions, this tool does it for us, and to notify the human package maintainer, it files a bug. So, now, whenever a new version is available for any of my ~300 packages, I get a bug and the corresponding e-mail notification.
I think that’s a pretty good system.
You did not get this because you are not the package maintainer of this particular package. If you go to src.fp.o and “watch” the package, I think you will also get all bug notifications. So if this package is important to you, that is the way to go.
The packages application is intended to solve this—it is the one stop location for all information on packages. It works for both users and package maintainers.
Requiring people to use the terminal for everything is sort of not a good goal—it may be your preference, but lots of people would rather not have to learn another dnf command to get information about a package.
Each team/project/pipeline has its own jargon. It takes time to learn it. it is just not always possible to explain each thing in detail each time. I can’t say what the best way to solve this is—my solution is to bookmark the package maintainer documentation and the corresponding FESCo documentation. When I don’t know something, I know where to look:
(this also applies to my dayjob in science—one cannot remember everything, but one can know where to look/refer when required)
If you watch the package, you’ll get all of these update in your e-mail.
It’s unfamiliar to you, but very familiar to me (and other package maintainers).
Again, different teams use different tools. One must learn the tools to be able to work. It’s like saying I want to contribute to a software project but it uses git/GitHub and I’m not familiar with either so they should also use this other version control tool and web forge that I’m already familiar with.
That’s not how it works. We learn the tools needed to do the task, and while people can improve tools to make them better, they cannot support every individual’s workflow/technical skill level to improve access.
A pull request, like on GitHub, requires you to fork the repository, make a change, make a commit, and open the pull request. This workflow is the same whether on src.fp.o or on GitHub/Gitlab/bitbucket/… if you have specific questions
There are certain things that one can do without fedpkg (like modify the spec and run a local mock build by using mock directly), but other things that one cannot because fedpkg implements the necessary functionality to work with the koji etc. API—which one needs to build packages. (One may be able to use the koji client tool directly, but I’ve never used that to do anything other than cancel or monitor builds, so I cannot say)
In this particular scenario, if you want to “solve” the issue, you need to help package maintainers fix the whole dependency tree—because it’s not a bug in fedpkg, it’s issues in building the various dependencies.
So, for users to grow into contributors, the pipeline on how to get updated versions of their package themselves should be clear regardless of it is