Summary: | sci-chemistry/platon-20151001 : Reason: Filesize does not match recorded size | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Toralf Förster <toralf> |
Component: | Current packages | Assignee: | Gentoo Chemistry-Related Packages <sci-chemistry> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | Hloupy.Honza, kernelpanic, mgorny, proxy-maint, treecleaner |
Priority: | Normal | Keywords: | PMASKED |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | Pending removal: 2018-02-04 | ||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 640504 | ||
Attachments: |
emerge-history.txt
sci-chemistry:platon-20151001:20161017-235452.log platon-20180118.ebuild |
Description
Toralf Förster
2016-10-18 10:10:30 UTC
Created attachment 450642 [details]
emerge-history.txt
Created attachment 450644 [details]
sci-chemistry:platon-20151001:20161017-235452.log
This bug is somewhat expected into the ebuild; the release policy of platon is rather strange -- no versions, no changelog, no release notes, no previous tarballs (that I am aware of). Still, development seems to be active (latest sources on January, 3) and the software can be useful. Is there something that can be done to avoid the removal? Created attachment 515308 [details]
platon-20180118.ebuild
The platon ebuild with the version number updated.
The package needs a maintainer who wold periodically try refetching it or check the date of the platon.tar.gz file at the download site.
If there were a way to create a platon-999.ebuild that would always fetch the current platon.tar.gz from the download site, not paying attention to its checksum, it might make the maintainers live even easier, because the package usually compiles without problems, and no real changes to its ebuild are apparently needed.
(In reply to Michelangelo Scopelliti from comment #3) > Is there something that can be done to avoid the removal? Probably becoming the maintainer of the ebuild. Perhaps in the science overlay if becoming a main tree maintainer is too complicated. I have access to the overlay, so I may add sci-chemistry/platon there, at least as nobody decides to counter my action; of course as long as it is in package.mask, every user will have to unmask it for themselves. Unfortunately I am not excessively reliable, and being already long time overdue with bumping the version of sci-physics/abinit, the package of my primary repsonsibility in the overlay, I am not likely to care for the sci-chemistry/platon ebuild properly. (In reply to Honza Macháček from comment #5) > (In reply to Michelangelo Scopelliti from comment #3) > > > Is there something that can be done to avoid the removal? > > Probably becoming the maintainer of the ebuild. > > Perhaps in the science overlay if becoming a main tree maintainer is too > complicated. I have access to the overlay, so I may add sci-chemistry/platon > there, at least as nobody decides to counter my action; of course as long as > it is in package.mask, every user will have to unmask it for themselves. > Unfortunately I am not excessively reliable, and being already long time > overdue with bumping the version of sci-physics/abinit, the package of my > primary repsonsibility in the overlay, I am not likely to care for the > sci-chemistry/platon ebuild properly. I think I could adopt the package; what are the step to take? I have to register somewhere? You would need to take a look on: https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers Removed from the tree |