Learn more about these different git repos.
Other Git URLs
There is package rubygem-connection_pool, where although the review was finished [1], the package was never imported neither built. Later, somebody wanted to use rubygem-connection_pool, so there was other review [2]. This was approved (while unnoticed, there is rubygem-connection_pool already in Fedora) and repository rubygem-connection-pool was requested (please note the dash instead of underscore in the repository name). From there, there are coming builds of rubygem-connection_pool here [3]. Somebody later noticed and retired the rubygem-connection-pool package [4], but really, I am not sure this was the best possible action. There are several concerns:
For (1) and (2), I hope you can check your tooling and avoid these situations in the future.
For (3) neither one of the current maintainers is really active. I haven't hear about @anujmore for past 4 years. I've heard about @axilleas, but I believe he is busy with other stuff. @ilgrad might still be interested in this package. I can also take the package over, since it is dependency of Ruby on Rails.
This has been fixed.
Metadata Update from @syeghiay: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Would you mind providing more details about the fix? The rubygem-connection_pool is still available in Fedora while the repo is still empty.
@mohanboddu , please provide more info on fix.
Metadata Update from @vondruch: - Issue status updated to: Open (was: Closed)
Technically, rubygem-connection-pool is retired and rubygem-connection_pool has never been imported and built. If you wish to maintain it, I suggest following the nonrepsonsive maintainer procedure on rubygem-connection_pool maintainers.
@churchyard You are trying to solve just consequences, but ignores the fact, that the package should have been retired together with the repository. So there should not be rubygem-connection_pool in Fedora ATM.
I see, rubygem-connection_pool 2.2.0-2.fc24 is still in the repo (source rubygem-connection_pool-2.2.0-2.fc24).
I guess the cause is that we allow to build rubygem-connection_pool source package from rubygem-connection-pool repository. rubygem-connection-pool is bloxcked in koji, but rubygem-connection_pool is not.
i.e. it seems that if I take any of my retired packages and I push a custom kernel.spec in it, I will be able to build kernel from a retired package scm.
Metadata Update from @syeghiay: - Issue assigned to mohanboddu
I will be very unhappy, if my packages get broken because this is not fixed in more than two years:
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/thread/V7TGJH4XV6EZ7NO62MFWLGH7EQCU2CD2/
The procedure would simply run "fedpkg retire" in the rubygem-connection_pool repo. That would remove the rubygem-connection_pool from the repo. If you need rubygem-connection_pool in the repo, please file a bugzilla for rubygem-connection_pool to be imported an built. If you plan to maintain it yourself, the retirement actually allows you to do it without talking to the maintainer - you will simply unretire it.
How can I help? Should I push what was in rubygem-connection-pool to rubygem-connection_pool as a provenpackager?
Note that I will not help you with a permanent fix, but I would very much like to help with the symptoms, as suggested half a year ago.
I can fix the symptoms myself, but I don't want to change anything until there is permanent fix to prevent issues like this in the future. This was already closed with "This has been fixed." message without any fix or explanation, so once you resolve the symptoms nobody will care.
OK, so there are two things to fix:
What if we open a more general issue about the cause and solve this specific one before it breaks things?
Looking at this, I understand your frustration, but not fixing the symptoms is clearly not helping anything here. You are afraid that when you do it, nobody will care, while apparently, that is the case already.
Releng, how can we prioritize this?
On top all of this, the "fix of symptoms" also requires unresponsive policy for both, @anujmore and @axilleas. That is other reason I have not touched the repository :blush:
:wave: sorry if I caused this mess :/ As @vondruch stated, I'm no longer active in packaging.
@axilleas SInce I have your attention, would you mind to orphan your packages? Or should I open FeSCo ticket referring to your previous comment to have your packages orphaned?
@vondruch done! I orphaned those that had only me as a maintainer, and gave the others to the existing co-maintainers.
That means rubygem-connection_pool is not orphaned :(
Ah crap... I didn't think of this :/ I wasn't the admin maintainer, so I just removed myself.
In that case you were not able to orphan it, so don't worry.
@axilleas Thx a lot.
I started unresponsive policy calling out @anujmore here:
https://bugzilla.redhat.com/show_bug.cgi?id=1780077 https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/TKUTVFREP55FRARHKFS2S7FEVP22HC6E/
Metadata Update from @cverna: - Assignee reset
So... if I understand right here:
Is tracked under https://pagure.io/releng/issue/8601 (ie, packages that don't create a src.rpm fail before we get any message about them failing)
is fedscm-admin should check that repo name == package name, but in this case they did match the subject of the bug. It also matched the first and other comments, but not what was imported. So, should this perhaps be in fedpkg import to check the spec name against the repo name? but this was never imported, so fedpkg can't check it... Can you expand on what you think releng can do here?
happy to try and move this forward, but not sure what their is to do here?
is fedscm-admin should check that repo name == package name, but in this case they did match the subject of the bug. It also matched the first and other comments, but not what was imported.
Not sure what would help. Maybe if scratch build was mandatory part and base for fedscm-admin?
So, should this perhaps be in fedpkg import to check the spec name against the repo name? but this was never imported, so fedpkg can't check it... Can you expand on what you think releng can do here?
There were two packages, rubygem-connection_pool and rubygem-connection-pool. The later was imported with the wrong package name. Therefore if fedpkg import did more checks, that situation could be prevented.
fedpkg import
ok, so sounds like we could close this in favor of a fedpkg issue to do more checks on imports?
Would you like to file the fedpkg issue, or would you like me to?
I'd appreciate if you filed the issue. I don't think I see enough into all the internals.
Related fedpkg issue: https://pagure.io/fedpkg/issue/529
Metadata Update from @patrikp: - Issue close_status updated to: upstream - Issue status updated to: Closed (was: Open)
Commit 13623dbf relates to this ticket
Login to comment on this ticket.