Hi all,
Following my messages on the "The Death of Java Packages" thread on this list(1), Ankur Shina suggested to me to give a go at being a package maintainer and let the mailing list know how it goes.
I hope this to be a constructive and helful way to help get more people onboard.
My first step was to go to "Collection maintaners"(2) and check the "Preparation". Most steps was already done (bugzilla account, fedora account, join mailing list, ...) so the next step was to find some software, to get a view of what is needed right now.
I pointed my browser to the orphaned packages that need new maintainers(3) page, as it seems the most appropriate for the task, and it gave me some guidelines and a link to the "Lists of Orphan and Retired Packages"(4) where I found a 500 response.
I have informed the webmaster at fedoraproject.org email address of the issue.
Meanwhile I went for other preparation steps as I was asked to join some mailing lists, devel (already on it), package-announces, devel- announce, package-review, packaging. At the lists suscription page (5) I was asked to log in, tried with fedora account, but that did not worked, so I guess the hyperkitty account is not linked to the fedora account system. , AnywayI put my email address in the suscribe form and joined the mailing lists.
Then I went to read again the guidelines (6). It's a 68 sections document, so seems a bit daunting. I went to the "Naming Guidelines" section and it was a 141,600 words page.
I am sure an abridged version for newcomers would be really helpful.
It going to take a while to go through that document.
Then I went to the package review status page (7) to get a look at the review proccess and I found a bit shocking the first package from review seems to be lurking around since 2015 and the guy still did not found an sponsor. May be I did not understood what was going, but that alone would be enought to demotivate many folk around. If you think it's going to be 6 years to get sponsored and submit a package, is somewhat easy to back down being a packager at Fedora.
So, that was so far my first couple of hours as a wannabe package maintainer.Not that bad, but somewhat rough.
Now I am going to setup a build system, and go ahead with the package review status page to learn a bit more about the review proccess, but going through the documentation will most likely eat most of my time those days.
If you find this thread useful, I will continue to describe my journey., otherwise please let me know and I will keep it to myself.
By the way not on https://fedoraproject.org/wiki/Join nor at https://whatcanidoforfedora.org/ there exists a packager role. I guess this is on purpose, but it doesn't helps to recruit people.
Thanks for your time.
(1) h ttps://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/4EHBACT4I263R4QF75HB3DUJWWANGHAS/ (2) https://fedoraproject.org/wiki/Join_the_package_collection_maintainers (3) https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers (4) https://src.fedoraproject.org/user/orphan (5) https://lists.fedoraproject.org/ (6) https://docs.fedoraproject.org/en-US/packaging-guidelines/ (7) https://fedoraproject.org/PackageReviewStatus/reviewable.html
On 8/18/21 6:32 PM, Iago Rubio wrote:
I pointed my browser to the orphaned packages that need new maintainers(3) page, as it seems the most appropriate for the task, and it gave me some guidelines and a link to the "Lists of Orphan and Retired Packages"(4) where I found a 500 response.
I have informed the webmaster at fedoraproject.org email address of the issue.
I think ppl now can go to https://packager-dashboard.fedoraproject.org/user/orphan to see orphaned packages.
Then I went to read again the guidelines (6). It's a 68 sections document, so seems a bit daunting. I went to the "Naming Guidelines" section and it was a 141,600 words page.
I am sure an abridged version for newcomers would be really helpful.
It going to take a while to go through that document.
You don't need to understand all of them at once, but you may need to skim the guidelines.
"Don't worry too much about it though---once you've done a few packages and a few reviews, you know where to find the info."
e.g. Referencing source -> https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/ , etc.
On Wed, 2021-08-18 at 20:15 +0700, Didik Supriadi wrote:
On 8/18/21 6:32 PM, Iago Rubio wrote:
I pointed my browser to the orphaned packages that need new maintainers(3) page, as it seems the most appropriate for the task, and it gave me some guidelines and a link to the "Lists of Orphan and Retired Packages"(4) where I found a 500 response.
I have informed the webmaster at fedoraproject.org email address of the issue.
I think ppl now can go to https://packager-dashboard.fedoraproject.org/user/orphan to see orphaned packages.
Thanks for the info !! Fixed it on the Wiki.
On Wed, 2021-08-18 at 20:15 +0700, Didik Supriadi wrote:
I think ppl now can go to https://packager-dashboard.fedoraproject.org/user/orphan to see orphaned packages.
Thanks for the pointer. Fixed it on the Wiki.
On Wed, Aug 18, 2021 at 08:15:36PM +0700, Didik Supriadi wrote:
On 8/18/21 6:32 PM, Iago Rubio wrote:
I pointed my browser to the orphaned packages that need new maintainers(3) page, as it seems the most appropriate for the task, and it gave me some guidelines and a link to the "Lists of Orphan and Retired Packages"(4) where I found a 500 response.
I have informed the webmaster at fedoraproject.org email address of the issue.
I think ppl now can go to https://packager-dashboard.fedoraproject.org/user/orphan to see orphaned packages.
IMHO, we should not point people to this list.
Sometimes packages are orphaned simply because the maintainer doesn't have time for them or the like and they would be easy to pick up. But also pretty often upstream is inactive or there's other problems that make the package difficult for a newcomer. I think it might be better to suggest pacakging something the user users thats not packaged, or looking for more simple requests on the wishlist?
kevin
On Wed, 2021-08-18 at 08:56 -0700, Kevin Fenzi wrote:
On Wed, Aug 18, 2021 at 08:15:36PM +0700, Didik Supriadi wrote:
I think ppl now can go to https://packager-dashboard.fedoraproject.org/user/orphan to see orphaned packages.
IMHO, we should not point people to this list.y
Then I messed it up by editing the Wiki.
Should I revert the Wiki to the non-working orphans page ?
I think it might be better to suggest pacakging something the user users thats not packaged, or looking for more simple requests on the wishlist?
I checked out the wishlist and the first entry is the orphans page, that leads to the link I edited to the packager dashboard orphans.
So I am now a bit confused on what should be the path to look for a new package.
It seems there is no consensus on this issue.
Right now, I was aiming for rarian.
It was orphaned a week ago, but the packager dashboard shows many dependencies that will be in trouble in a month:
- dia - etherape - gconf-editor - glade2 - gnome-search-tool - gnome-translate - grhino - gtk-v4l - mail-notification - pioneers - qalculate-gtk - stardict - ucview - viking - xiphos - xiphos
There is an email by Mukundan Ragavan on the list stating it was going to be orphaned because notning depends on it on rawhide.
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
He used this repoquery to check it out:
# dnf repoquery --releasever rawhide --whatrequires librarian* Last metadata expiration check: 0:02:50 ago on Wed 11 Aug 2021 06:03:30 PM EDT. rarian-compat-0:0.8.1-27.fc34.x86_64 rarian-devel-0:0.8.1-27.fc34.i686 rarian-devel-0:0.8.1-27.fc34.x86_64
But my results for the "rairian" package differ:
[iago@rawhide]$ dnf repoquery --releasever rawhide --whatrequires "rarian*" Last metadata expiration check: 0:00:26 ago on Thu 19 Aug 2021 10:34:56 PM CEST. alleyoop-0:0.9.8-18.fc35.x86_64 etherape-0:0.9.18-8.fc35.x86_64 gnome-translate-0:0.99-39.fc35.x86_64 grhino-0:0.16.1-13.fc35.x86_64 mail-notification-0:5.4-100.git.9ae8768.fc35.x86_64 pioneers-0:15.6-3.fc35.x86_64 rarian-compat-0:0.8.1-27.fc34.x86_64 rarian-devel-0:0.8.1-27.fc34.i686 rarian-devel-0:0.8.1-27.fc34.x86_64 ucview-0:0.33-21.fc35.i686 ucview-0:0.33-21.fc35.x86_64
It seems most packages requires rarian-compat as - I guess - most used it as a replacement for scrollkeeper.
alleyoop -> rarian-compat -> rarian etherape -> rarian-compat -> rarian gnome-translate -> rarian-compat -> rarian grhino -> rarian-compat -> rarian mail-notification -> rarian-compat -> rarian pioneers -> rarian-compat -> rarian ucview -> rarian-compat -> rarian
The other problem stated by Mukundan was: "Last upstream release was in 2008 and this is currently FTBFS on rawhide/F35".
Indeed the package doesn't build, but it's a combination of ancient autotools & libtool and rpath rpm checks failing.
I got it building on rawhide by fiddling with the sources and now I can get a working rpm.
I have to put all the commands and patches on the spec file, but it don't looks like it's going to be a huge problem.
Most Makefile.am files need to be touch, but the changes are minimal.
Should I go fot it or I'd rather search for other package on the wish list ?
Thanks in advance.
On Thu, Aug 19, 2021 at 11:03:27PM +0200, Iago Rubio wrote:
On Wed, 2021-08-18 at 08:56 -0700, Kevin Fenzi wrote:
On Wed, Aug 18, 2021 at 08:15:36PM +0700, Didik Supriadi wrote:
I think ppl now can go to https://packager-dashboard.fedoraproject.org/user/orphan to see orphaned packages.
IMHO, we should not point people to this list.y
Then I messed it up by editing the Wiki.
Should I revert the Wiki to the non-working orphans page ?
No, I don't know that we have any kind of consensus on this, that was just my opinion.
I think it might be better to suggest pacakging something the user users thats not packaged, or looking for more simple requests on the wishlist?
I checked out the wishlist and the first entry is the orphans page, that leads to the link I edited to the packager dashboard orphans.
So I am now a bit confused on what should be the path to look for a new package.
It seems there is no consensus on this issue.
Yeah. I think both the wishlist and the orphans list are probibly bad. Ideally we would have a small list of things that are somewhat easy looking to package for new folks who are looking for something. I am not sure who would be willing to maintain such a list though. ;(
Right now, I was aiming for rarian.
It was orphaned a week ago, but the packager dashboard shows many dependencies that will be in trouble in a month:
- dia
- etherape
- gconf-editor
- glade2
- gnome-search-tool
- gnome-translate
- grhino
- gtk-v4l
- mail-notification
- pioneers
- qalculate-gtk
- stardict
- ucview
- viking
- xiphos
- xiphos
There is an email by Mukundan Ragavan on the list stating it was going to be orphaned because notning depends on it on rawhide.
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
He used this repoquery to check it out:
# dnf repoquery --releasever rawhide --whatrequires librarian* Last metadata expiration check: 0:02:50 ago on Wed 11 Aug 2021 06:03:30 PM EDT. rarian-compat-0:0.8.1-27.fc34.x86_64 rarian-devel-0:0.8.1-27.fc34.i686 rarian-devel-0:0.8.1-27.fc34.x86_64
But my results for the "rairian" package differ:
[iago@rawhide]$ dnf repoquery --releasever rawhide --whatrequires "rarian*" Last metadata expiration check: 0:00:26 ago on Thu 19 Aug 2021 10:34:56 PM CEST. alleyoop-0:0.9.8-18.fc35.x86_64 etherape-0:0.9.18-8.fc35.x86_64 gnome-translate-0:0.99-39.fc35.x86_64 grhino-0:0.16.1-13.fc35.x86_64 mail-notification-0:5.4-100.git.9ae8768.fc35.x86_64 pioneers-0:15.6-3.fc35.x86_64 rarian-compat-0:0.8.1-27.fc34.x86_64 rarian-devel-0:0.8.1-27.fc34.i686 rarian-devel-0:0.8.1-27.fc34.x86_64 ucview-0:0.33-21.fc35.i686 ucview-0:0.33-21.fc35.x86_64
It seems most packages requires rarian-compat as - I guess - most used it as a replacement for scrollkeeper.
alleyoop -> rarian-compat -> rarian etherape -> rarian-compat -> rarian gnome-translate -> rarian-compat -> rarian grhino -> rarian-compat -> rarian mail-notification -> rarian-compat -> rarian pioneers -> rarian-compat -> rarian ucview -> rarian-compat -> rarian
The other problem stated by Mukundan was: "Last upstream release was in 2008 and this is currently FTBFS on rawhide/F35".
Indeed the package doesn't build, but it's a combination of ancient autotools & libtool and rpath rpm checks failing.
I got it building on rawhide by fiddling with the sources and now I can get a working rpm.
I have to put all the commands and patches on the spec file, but it don't looks like it's going to be a huge problem.
Most Makefile.am files need to be touch, but the changes are minimal.
Should I go fot it or I'd rather search for other package on the wish list ?
That sounds fine to me to revive it. You might mail Mukundan directly about it. He may be willing to sponsor you and help out...
kevin
On 8/20/21 9:32 PM, Kevin Fenzi wrote:
On Thu, Aug 19, 2021 at 11:03:27PM +0200, Iago Rubio wrote:
Right now, I was aiming for rarian.
It was orphaned a week ago, but the packager dashboard shows many dependencies that will be in trouble in a month:
- dia
- etherape
- gconf-editor
- glade2
- gnome-search-tool
- gnome-translate
- grhino
- gtk-v4l
- mail-notification
- pioneers
- qalculate-gtk
- stardict
- ucview
- viking
- xiphos
- xiphos
There is an email by Mukundan Ragavan on the list stating it was going to be orphaned because notning depends on it on rawhide.
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
He used this repoquery to check it out:
# dnf repoquery --releasever rawhide --whatrequires librarian* Last metadata expiration check: 0:02:50 ago on Wed 11 Aug 2021 06:03:30 PM EDT. rarian-compat-0:0.8.1-27.fc34.x86_64 rarian-devel-0:0.8.1-27.fc34.i686 rarian-devel-0:0.8.1-27.fc34.x86_64
But my results for the "rairian" package differ:
[iago@rawhide]$ dnf repoquery --releasever rawhide --whatrequires "rarian*" Last metadata expiration check: 0:00:26 ago on Thu 19 Aug 2021 10:34:56 PM CEST. alleyoop-0:0.9.8-18.fc35.x86_64 etherape-0:0.9.18-8.fc35.x86_64 gnome-translate-0:0.99-39.fc35.x86_64 grhino-0:0.16.1-13.fc35.x86_64 mail-notification-0:5.4-100.git.9ae8768.fc35.x86_64 pioneers-0:15.6-3.fc35.x86_64 rarian-compat-0:0.8.1-27.fc34.x86_64 rarian-devel-0:0.8.1-27.fc34.i686 rarian-devel-0:0.8.1-27.fc34.x86_64 ucview-0:0.33-21.fc35.i686 ucview-0:0.33-21.fc35.x86_64
It seems most packages requires rarian-compat as - I guess - most used it as a replacement for scrollkeeper.
alleyoop -> rarian-compat -> rarian etherape -> rarian-compat -> rarian gnome-translate -> rarian-compat -> rarian grhino -> rarian-compat -> rarian mail-notification -> rarian-compat -> rarian pioneers -> rarian-compat -> rarian ucview -> rarian-compat -> rarian
The other problem stated by Mukundan was: "Last upstream release was in 2008 and this is currently FTBFS on rawhide/F35".
Indeed the package doesn't build, but it's a combination of ancient autotools & libtool and rpath rpm checks failing.
I got it building on rawhide by fiddling with the sources and now I can get a working rpm.
I have to put all the commands and patches on the spec file, but it don't looks like it's going to be a huge problem.
Most Makefile.am files need to be touch, but the changes are minimal.
Should I go fot it or I'd rather search for other package on the wish list ?
That sounds fine to me to revive it. You might mail Mukundan directly about it. He may be willing to sponsor you and help out...
I would offer a different opinion here.
I am not sure it's worth keeping rarian alive at this point: any app that's maintained upstream has by now been migrated away from scrollkeeper (rarian-compat) and I think removing rarian from the distro would be a good nudge to remove all the rest of the obsolete packages that still depend on it.
It's awesome that you are looking for ways to work on Fedora, but I would rather let rarian go at this point.
On Fri, 2021-08-20 at 23:29 +0200, Kalev Lember wrote:
On 8/20/21 9:32 PM, Kevin Fenzi wrote:
On Thu, Aug 19, 2021 at 11:03:27PM +0200, Iago Rubio wrote:
Right now, I was aiming for rarian. ... Should I go fot it or I'd rather search for other package on the wish list ?
That sounds fine to me to revive it. You might mail Mukundan directly about it. He may be willing to sponsor you and help out...
I would offer a different opinion here.
I am not sure it's worth keeping rarian alive at this point: any app that's maintained upstream has by now been migrated away from scrollkeeper (rarian-compat) and I think removing rarian from the distro would be a good nudge to remove all the rest of the obsolete packages that still depend on it.
It's awesome that you are looking for ways to work on Fedora, but I would rather let rarian go at this point.
It's ok for me, no problem at all.
I got it right now on Copr, already building - but on ELN but will make a separate email about this - so I can let it there once a give it a last cleanup.
https://copr.fedorainfracloud.org/coprs/iago/rarian/
If it's better to completelly get rid on it, no problem as well, will remove it from there.
For me it was a nice learning exercise.
Kevin Fenzi kirjoitti 20.8.2021 klo 22.32:
On Thu, Aug 19, 2021 at 11:03:27PM +0200, Iago Rubio wrote:
On Wed, 2021-08-18 at 08:56 -0700, Kevin Fenzi wrote:
On Wed, Aug 18, 2021 at 08:15:36PM +0700, Didik Supriadi wrote:
I think ppl now can go to https://packager-dashboard.fedoraproject.org/user/orphan to see orphaned packages.
IMHO, we should not point people to this list.y
Then I messed it up by editing the Wiki.
Should I revert the Wiki to the non-working orphans page ?
No, I don't know that we have any kind of consensus on this, that was just my opinion.
Sure, there are dragons in the orphaned packages list. But the wiki page with that link also has the appropriate warning:
Claiming Ownership of a Retired Package
If you really want to maintain a retired package, you need to be aware that if upstream is dead, fixing release critical bugs, etc becomes your responsibility. This is to ensure the high quality and standards of packaging remain for Fedora package collection. There may be additional issues with retired packages. If possible, consult with the former maintainer for more information.
There are also ideal candidates for helping out, useful and almost functional packages orphaned simply because the previous maintainer does not need them anymore or like that.
This could be further improved by more structured listing of possible paths into joining packages, adopting an orphaned package being one of them. The sensible safety checks could be described there.
<rant> For some time already, I have all of the package maintainer docs already rewritten and improved at package-maintainer-docs [1], with the intent to keep improving them. They remain unpublished because, despite my pleas, the main docs page maintainers keep ignoring two oneliner pull requests to publish them [2,3].
For cases like this., Fedora would need something like the Nonreponsive Package Maintainer Process for non-package repositories too. </rant>
[1]: https://pagure.io/fedora-docs/package-maintainer-docs [2]: https://pagure.io/fedora-docs/docs-fp-o/pull-request/171 [3]: https://pagure.io/fedora-docs/pages/pull-request/14#request_diff
<snip>
<rant> For some time already, I have all of the package maintainer docs already rewritten and improved at package-maintainer-docs [1], with the intent to keep improving them. They remain unpublished because, despite my pleas, the main docs page maintainers keep ignoring two oneliner pull requests to publish them [2,3].
For cases like this., Fedora would need something like the Nonreponsive Package Maintainer Process for non-package repositories too.
</rant>
Thanks for working on these.
I've tagged @pbokoc and @bcotton there who may have the necessary permissions (and know-how) to merge the PRs.
I don't think having a non-responsive maintainer policy works quite as well for such repos. We need to encourage more folks to join the docs team to help out so there is enough human-power there (something we have to do for all teams/SIGs in Fedora in general).
Ankur Sinha kirjoitti 21.8.2021 klo 11.56:
<snip>
<rant> For some time already, I have all of the package maintainer docs already rewritten and improved at package-maintainer-docs [1], with the intent to keep improving them. They remain unpublished because, despite my pleas, the main docs page maintainers keep ignoring two oneliner pull requests to publish them [2,3].
For cases like this., Fedora would need something like the Nonreponsive Package Maintainer Process for non-package repositories too.
</rant>
Thanks for working on these.
I've tagged @pbokoc and @bcotton there who may have the necessary permissions (and know-how) to merge the PRs.
Thanks!
I don't think having a non-responsive maintainer policy works quite as well for such repos.
Sure, the cases are different. What I meant is that for packaging related issues there is a standard way to escalate issues, defined in that policy, and just following that path will get the issue eventually resolved. For issues not related to packaging, it is not what is the appropriate next step if nothing you tried before helped.
We need to encourage more folks to join the docs team to help out so there is enough human-power there (something we have to do for all teams/SIGs in Fedora in general).
Certainly, having things running in such a way that pull requests are processed fast is better than having policies to handle cases where they are not!
On Fri, 2021-08-20 at 12:32 -0700, Kevin Fenzi wrote:
On Thu, Aug 19, 2021 at 11:03:27PM +0200, Iago Rubio wrote:
I checked out the wishlist and the first entry is the orphans page, that leads to the link I edited to the packager dashboard orphans.
So I am now a bit confused on what should be the path to look for a new package.
It seems there is no consensus on this issue.
Yeah. I think both the wishlist and the orphans list are probibly bad. Ideally we would have a small list of things that are somewhat easy looking to package for new folks who are looking for something. I am not sure who would be willing to maintain such a list though. ;(
I guess - from what I am finding now - that something like a step by step tutorial and/or examples to slowly get into Fedora packaging would be a great idea in the long run.
The main problem I am finding is the infrastructure, the tooling, the guidelines are all huge.
The tooling is very nice, but have many different ways to tackle the same problem for a new packager - in this case get a working package.
Copr, fedpkg, fedora-review, koji ... to get deep into it there is a huge learning curve, but it's not really required to get an initial package going.
A slimmed down version of the doc - that's really great but dense - with just one tool at a time - build with fedpkg locally, using it as a git replacement, using it to upload a new source tarbal, ... - instead of interleaving all the tooling and explaining how the whole ecosystem works at the same time, would help.
This is a case where the forset is what don't let you see the trees.
Anyway I think most people need to understand that to get approved as a packager, will give you some "superpowers" - git access, koji access, etc ... - so packagers need to be properly vetted. Many people wants to find a way of droping a spec, and just have the package automagically apear on the repos ... and that just won't happen.
That is why many people feels like they are encouraged to join and submit a package, and they end up hitting a wall when they see it's not that easy, because they have to demostrate they can manage and are trustworthy for the new "powers" that come with the packager status.
It could be that for "newbies" such as me, a intermediate status - say co-packager, or package helper - would help to prove our worthiness regarding to achieve the packager status.
Packagers could post "looking for 'prospect'" messages, where they get people to help them to get the job done, meanwhile they don't get ready to be packagers.
But well, I'm starting to digress, sorry.
One way to ease to find "easy" packages, may be just put it down in the "Orphaning package" email would help. Just Trivial/Easy/Hard/Complex package, so who comes down the chain will know what he is facing.
If a fixed format could be agreed, they even can get "distilled" from the email in some sort of database.
Just a dumb idea I guess, but that won't put that much burden on the packager.
Right now, I was aiming for rarian. ... Should I go fot it or I'd rather search for other package on the wish list ?
That sounds fine to me to revive it. You might mail Mukundan directly about it. He may be willing to sponsor you and help out...
Great idea, Thanks.
Will do it.
Iago Rubio kirjoitti 20.8.2021 klo 0.03:
[iago@rawhide]$ dnf repoquery --releasever rawhide --whatrequires "rarian*" Last metadata expiration check: 0:00:26 ago on Thu 19 Aug 2021 10:34:56 PM CEST. alleyoop-0:0.9.8-18.fc35.x86_64 etherape-0:0.9.18-8.fc35.x86_64 gnome-translate-0:0.99-39.fc35.x86_64 grhino-0:0.16.1-13.fc35.x86_64 mail-notification-0:5.4-100.git.9ae8768.fc35.x86_64 pioneers-0:15.6-3.fc35.x86_64 rarian-compat-0:0.8.1-27.fc34.x86_64 rarian-devel-0:0.8.1-27.fc34.i686 rarian-devel-0:0.8.1-27.fc34.x86_64 ucview-0:0.33-21.fc35.i686 ucview-0:0.33-21.fc35.x86_64
If you use 'dnf repoquery --whatrequires' to find packages dependees, it is a good idea to to check also the source repositories, so you will not miss packages that only depend at build time:
$ sudo dnf --enablerepo='*source' repoquery --whatrequires 'rarian*' Last metadata expiration check: 0:00:18 ago on Sat Aug 21 10:26:20 2021. alleyoop-0:0.9.8-18.fc35.x86_64 bless-0:0.6.3-3.fc35.src dia-1:0.97.3-18.fc35.src etherape-0:0.9.18-8.fc35.src etherape-0:0.9.18-8.fc35.x86_64 florence-0:0.6.3-15.fc35.src gconf-editor-0:3.0.1-23.fc35.src glade2-0:2.12.2-35.fc35.src gnome-search-tool-0:3.6.0-20.fc35.src gnome-translate-0:0.99-39.fc35.src gnome-translate-0:0.99-39.fc35.x86_64 grhino-0:0.16.1-13.fc35.src grhino-0:0.16.1-13.fc35.x86_64 gtk-v4l-0:0.4-22.fc35.src ignuit-0:2.24.3-10.fc35.src mail-notification-0:5.4-100.git.9ae8768.fc35.src mail-notification-0:5.4-100.git.9ae8768.fc35.x86_64 mdbtools-0:0.9.3-2.fc35.src moserial-0:3.0.16-2.fc35.src pioneers-0:15.6-3.fc35.src pioneers-0:15.6-3.fc35.x86_64 qalculate-gtk-0:3.20.1-1.fc35.src quarry-0:0.2.0-31.fc35.src rarian-compat-0:0.8.1-27.fc34.x86_64 rarian-devel-0:0.8.1-27.fc34.i686 rarian-devel-0:0.8.1-27.fc34.x86_64 stardict-0:3.0.6-17.fc35.src ucview-0:0.33-21.fc35.i686 ucview-0:0.33-21.fc35.x86_64 viking-0:1.8-7.fc36.src xiphos-0:4.2.1-11.fc35.src
See how there are some .src rpms that were missed by your query?
Depending on what you are trying to do, using --recursive as well may be a good idea.
Otto
Great tío thank you
En 21 ago. 2021 9:30, en 9:30, Otto Urpelainen oturpe@iki.fi escribió:
Iago Rubio kirjoitti 20.8.2021 klo 0.03:
[iago@rawhide]$ dnf repoquery --releasever rawhide --whatrequires "rarian*" Last metadata expiration check: 0:00:26 ago on Thu 19 Aug 2021
10:34:56
PM CEST. alleyoop-0:0.9.8-18.fc35.x86_64 etherape-0:0.9.18-8.fc35.x86_64 gnome-translate-0:0.99-39.fc35.x86_64 grhino-0:0.16.1-13.fc35.x86_64 mail-notification-0:5.4-100.git.9ae8768.fc35.x86_64 pioneers-0:15.6-3.fc35.x86_64 rarian-compat-0:0.8.1-27.fc34.x86_64 rarian-devel-0:0.8.1-27.fc34.i686 rarian-devel-0:0.8.1-27.fc34.x86_64 ucview-0:0.33-21.fc35.i686 ucview-0:0.33-21.fc35.x86_64
If you use 'dnf repoquery --whatrequires' to find packages dependees, it is a good idea to to check also the source repositories, so you will not miss packages that only depend at build time:
$ sudo dnf --enablerepo='*source' repoquery --whatrequires 'rarian*' Last metadata expiration check: 0:00:18 ago on Sat Aug 21 10:26:20 2021. alleyoop-0:0.9.8-18.fc35.x86_64 bless-0:0.6.3-3.fc35.src dia-1:0.97.3-18.fc35.src etherape-0:0.9.18-8.fc35.src etherape-0:0.9.18-8.fc35.x86_64 florence-0:0.6.3-15.fc35.src gconf-editor-0:3.0.1-23.fc35.src glade2-0:2.12.2-35.fc35.src gnome-search-tool-0:3.6.0-20.fc35.src gnome-translate-0:0.99-39.fc35.src gnome-translate-0:0.99-39.fc35.x86_64 grhino-0:0.16.1-13.fc35.src grhino-0:0.16.1-13.fc35.x86_64 gtk-v4l-0:0.4-22.fc35.src ignuit-0:2.24.3-10.fc35.src mail-notification-0:5.4-100.git.9ae8768.fc35.src mail-notification-0:5.4-100.git.9ae8768.fc35.x86_64 mdbtools-0:0.9.3-2.fc35.src moserial-0:3.0.16-2.fc35.src pioneers-0:15.6-3.fc35.src pioneers-0:15.6-3.fc35.x86_64 qalculate-gtk-0:3.20.1-1.fc35.src quarry-0:0.2.0-31.fc35.src rarian-compat-0:0.8.1-27.fc34.x86_64 rarian-devel-0:0.8.1-27.fc34.i686 rarian-devel-0:0.8.1-27.fc34.x86_64 stardict-0:3.0.6-17.fc35.src ucview-0:0.33-21.fc35.i686 ucview-0:0.33-21.fc35.x86_64 viking-0:1.8-7.fc36.src xiphos-0:4.2.1-11.fc35.src
See how there are some .src rpms that were missed by your query?
Depending on what you are trying to do, using --recursive as well may be a good idea.
Otto _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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 on the list, report it: https://pagure.io/fedora-infrastructure
Dne 18. 08. 21 v 15:15 Didik Supriadi napsal(a):
On 8/18/21 6:32 PM, Iago Rubio wrote:
I pointed my browser to the orphaned packages that need new maintainers(3) page, as it seems the most appropriate for the task, and it gave me some guidelines and a link to the "Lists of Orphan and Retired Packages"(4) where I found a 500 response.
I have informed the webmaster at fedoraproject.org email address of the issue.
I think ppl now can go to https://packager-dashboard.fedoraproject.org/user/orphan to see orphaned packages.
Then I went to read again the guidelines (6). It's a 68 sections document, so seems a bit daunting. I went to the "Naming Guidelines" section and it was a 141,600 words page.
I am sure an abridged version for newcomers would be really helpful.
It going to take a while to go through that document.
You don't need to understand all of them at once, but you may need to skim the guidelines.
Ironically, I find the Review guidelines [1] more practical for start, because they list the basics what should be done during package review. The packaging guidelines are useful source if the package gets more complex.
Vít
[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/
"Don't worry too much about it though---once you've done a few packages and a few reviews, you know where to find the info."
e.g. Referencing source -> https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/ , etc.
Iago Rubio kirjoitti 18.8.2021 klo 14.32:
Hi all,
Following my messages on the "The Death of Java Packages" thread on this list(1), Ankur Shina suggested to me to give a go at being a package maintainer and let the mailing list know how it goes.
I hope this to be a constructive and helful way to help get more people onboard.
Thank you for taking the time to report you experiences! Long time Fedora contributors have already learned all the common pitfalls and learned to avoid them, so it is really useful to get the newcomers perspective, especially when it is written as clearly as you do here. Please keep posting.
I pointed my browser to the orphaned packages that need new maintainers(3) page, as it seems the most appropriate for the task, and it gave me some guidelines and a link to the "Lists of Orphan and Retired Packages"(4) where I found a 500 response.
I have informed the webmaster at fedoraproject.org email address of the issue.
Reporting this kind of issues is certainly the right thing to do. There are many issues, large and small, in Fedora tooling. Filing issues is the first step to get things fixed.
I am not sure if you got or will get a response to your email. In this case, the problem seems to be in Pagure engine that powers src.fedoraproject.org, so I filed a bug there [1].
[1]: https://pagure.io/pagure/issue/5209
Meanwhile I went for other preparation steps as I was asked to join some mailing lists, devel (already on it), package-announces, devel- announce, package-review, packaging. At the lists suscription page (5) I was asked to log in, tried with fedora account, but that did not worked, so I guess the hyperkitty account is not linked to the fedora account system. , AnywayI put my email address in the suscribe form and joined the mailing lists.
At least for me, the login screen at lists.fedoraproject.org has a button (the first and largest one) saying "Fedora", which does the right thing.
I am not sure what is the use of the other options, including creating a separate account for that service only. Maybe it is just that some component that was used to make Fedora login possible gave those others for free.
Anyhow, as you just discovered, lists.fedoraproject.org can be very well used without ever logging in. Actually, I did it for the first time while writing this post.
Then I went to the package review status page (7) to get a look at the review proccess and I found a bit shocking the first package from review seems to be lurking around since 2015 and the guy still did not found an sponsor. May be I did not understood what was going, but that alone would be enought to demotivate many folk around. If you think it's going to be 6 years to get sponsored and submit a package, is somewhat easy to back down being a packager at Fedora.
If you had looked there half a year ago, you would have seen one from 2008. Unfortunately, reviews sometimes get stalled because either the reviewee or reviewer drops the ball for whatever reason. There is automation to detect and close these automatically, but if they are in a Bugzilla state that is no picked up, they can stay there indefinitely.
I have been going through those manually and closing them if they really are dead. Some were even completed after years of silence. I have reached November 2016 already. The 'giza' review request you mention still has some activity going on, that is why it has not been closed. It is a sad story if you read through the comments, not a typical package review issue at all, all kinds of trouble just stacking on top of each other. Let us just hope that the remaining issues get resolved.
I have hard time believing that anybody would not get sponsored if they just follow the instructions on doing the informal package reviews and then file an issue at package-sponsors issue tracker [2], explaining what they have done.
What I have not been able to understand is why Fedora has two parallel processes for getting sponsored, the FE-NEEDSPONSOR flag and the package-sponsors issue tracker. I have a feeling that the former is just a relic and Fedora would be better off by just instructing aspiring packager group members to file a properly filled ticket in the latter. But I am not a packager sponsor myself, so I do not really know how this appears from that side.
[2]: https://pagure.io/packager-sponsors/issues
By the way not on https://fedoraproject.org/wiki/Join nor at https://whatcanidoforfedora.org/ there exists a packager role. I guess this is on purpose, but it doesn't helps to recruit people.
I am not really familiar with these pages, but at the former, packager seems to be a sub role of "OS Developer" and the latter actually has it [3]. Not sure why these two use different categorization, perhaps they are from different periods or made by different people?
On Wed, Aug 18, 2021 at 11:53:49PM +0300, Otto Urpelainen wrote:
Iago Rubio kirjoitti 18.8.2021 klo 14.32:
Hi all,
Following my messages on the "The Death of Java Packages" thread on this list(1), Ankur Shina suggested to me to give a go at being a package maintainer and let the mailing list know how it goes.
I hope this to be a constructive and helful way to help get more people onboard.
Thank you for taking the time to report you experiences! Long time Fedora contributors have already learned all the common pitfalls and learned to avoid them, so it is really useful to get the newcomers perspective, especially when it is written as clearly as you do here. Please keep posting.
Agreed. :) Good to get feedback...
I pointed my browser to the orphaned packages that need new maintainers(3) page, as it seems the most appropriate for the task, and it gave me some guidelines and a link to the "Lists of Orphan and Retired Packages"(4) where I found a 500 response.
I have informed the webmaster at fedoraproject.org email address of the issue.
Reporting this kind of issues is certainly the right thing to do. There are many issues, large and small, in Fedora tooling. Filing issues is the first step to get things fixed.
I am not sure if you got or will get a response to your email. In this case,
Yeah, so webmaster@fedoraproject.org goes to the websites mailing list. However, I don't see your post there. Did you get a bounce or rejection email?
the problem seems to be in Pagure engine that powers src.fedoraproject.org, so I filed a bug there [1].
Yeah, the problem is due to it trying to gather all of them over all releases and it just is too many to gather in a timely manner.
Meanwhile I went for other preparation steps as I was asked to join some mailing lists, devel (already on it), package-announces, devel- announce, package-review, packaging. At the lists suscription page (5) I was asked to log in, tried with fedora account, but that did not worked, so I guess the hyperkitty account is not linked to the fedora account system. , AnywayI put my email address in the suscribe form and joined the mailing lists.
At least for me, the login screen at lists.fedoraproject.org has a button (the first and largest one) saying "Fedora", which does the right thing.
I am not sure what is the use of the other options, including creating a separate account for that service only. Maybe it is just that some component that was used to make Fedora login possible gave those others for free.
We should remove the login/password there. It was only added for persona users who couldn't login via persona after mozilla retired it.
Anyhow, as you just discovered, lists.fedoraproject.org can be very well used without ever logging in. Actually, I did it for the first time while writing this post.
Then I went to the package review status page (7) to get a look at the review proccess and I found a bit shocking the first package from review seems to be lurking around since 2015 and the guy still did not found an sponsor. May be I did not understood what was going, but that alone would be enought to demotivate many folk around. If you think it's going to be 6 years to get sponsored and submit a package, is somewhat easy to back down being a packager at Fedora.
If you had looked there half a year ago, you would have seen one from 2008. Unfortunately, reviews sometimes get stalled because either the reviewee or reviewer drops the ball for whatever reason. There is automation to detect and close these automatically, but if they are in a Bugzilla state that is no picked up, they can stay there indefinitely.
I have been going through those manually and closing them if they really are dead. Some were even completed after years of silence. I have reached November 2016 already. The 'giza' review request you mention still has some activity going on, that is why it has not been closed. It is a sad story if you read through the comments, not a typical package review issue at all, all kinds of trouble just stacking on top of each other. Let us just hope that the remaining issues get resolved.
I have hard time believing that anybody would not get sponsored if they just follow the instructions on doing the informal package reviews and then file an issue at package-sponsors issue tracker [2], explaining what they have done.
What I have not been able to understand is why Fedora has two parallel processes for getting sponsored, the FE-NEEDSPONSOR flag and the package-sponsors issue tracker. I have a feeling that the former is just a relic and Fedora would be better off by just instructing aspiring packager group members to file a properly filled ticket in the latter. But I am not a packager sponsor myself, so I do not really know how this appears from that side.
Yeah, that process could be revamped for sure. In theory sponsors go and look at the FE-NEEDSPONSOR blocker and sponsor folks from it as their time permits. The issue tracker is for people following the 'become a co-maintainer of existing package' flow.
By the way not on https://fedoraproject.org/wiki/Join nor at https://whatcanidoforfedora.org/ there exists a packager role. I guess this is on purpose, but it doesn't helps to recruit people.
I am not really familiar with these pages, but at the former, packager seems to be a sub role of "OS Developer" and the latter actually has it [3]. Not sure why these two use different categorization, perhaps they are from different periods or made by different people?
There is also: https://docs.fedoraproject.org/en-US/fesco/Package_maintainer_responsibiliti...
kevin
On Thu, 2021-08-19 at 13:07 -0700, Kevin Fenzi wrote:
On Wed, Aug 18, 2021 at 11:53:49PM +0300, Otto Urpelainen wrote: Yeah, so webmaster@fedoraproject.org goes to the websites mailing list. However, I don't see your post there. Did you get a bounce or rejection email?
Nope, and from the mail server logs it seems it went through.
Aug 18 09:57:53 iagorubio postfix/smtp[10659]: 5F50E3FB24: to=< webmaster@fedoraproject.org>, relay=mx1.redhat.com[209.132.183.28]:25, delay=9.6, delays=0.5/0.02/1.3/7.8, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 2C3F3309B174)
May be it got caught as spam? It was just a one liner " https://src.fedoraproject.org/user/orphan is returning an error 500".
Am 18.08.2021 um 13:32 schrieb Iago Rubio iago@iagorubio.com:
Hi all,
Following my messages on the "The Death of Java Packages" thread on this list(1), Ankur Shina suggested to me to give a go at being a package maintainer and let the mailing list know how it goes.
If you find this thread useful, I will continue to describe my journey., otherwise please let me know and I will keep it to myself.
Please, go on reporting your „journey“ and experiences. Many of those are typical for the current Fedora universe and there are initiatives to address and the issues and improve the situation. So, your report is very helpful.
-
Ankur Sinha -
Didik Supriadi -
Iago Rubio -
Kalev Lember -
Kevin Fenzi -
Otto Urpelainen -
Peter Boy -
Vít Ondruch