Search Criteria
Package Details: scitopdf 0.7.2-1
Package Actions
Git Clone URL: | https://aur.archlinux.org/scitopdf.git (read-only, click to copy) |
---|---|
Package Base: | scitopdf |
Description: | Script to quickly fetch scientific papers from Sci-Hub or Libgen. |
Upstream URL: | https://github.com/dougy147/scitopdf.git |
Licenses: | GPL3 |
Conflicts: | scitopdf-git |
Provides: | scitopdf |
Submitter: | dougy147 |
Maintainer: | dougy147 |
Last Packager: | dougy147 |
Votes: | 2 |
Popularity: | 0.000000 |
First Submitted: | 2022-06-16 10:28 (UTC) |
Last Updated: | 2024-09-05 08:24 (UTC) |
Latest Comments
dougy147 commented on 2024-09-06 07:34 (UTC)
Thanks for your feedback @m040601, This is an interesting option for both users and servers. I opened an issue on the GitHub repo about it, feel free to track that there!
m040601 commented on 2024-09-04 16:09 (UTC) (edited on 2024-09-04 16:21 (UTC) by m040601)
Thanks for the continuing work and improvements.
Just some feedback for you. This tool is really gold. I use it for academic articles in both the humanities and tech/science. It it sooooo usefull to get very old papers out of print.
I am actually using "scitopdf-git".
It has been working flawlessly. No dns problems, no blocks. Always finds a way.
This option is "brutal"
Since I discovered it, I've been using and abusing it with simple lines of URLs or DOIs in plain text files.
Sometimes I push it to hard and overload it with too many downloads at the same time.
Some sci-hub servers seem then to impose some kind of restriction. They seem to limit my speed if I do too many consecutive downloads in a very short time. Especially if my internet connection is "too fast".
But if I pause a bit, stop, wait and resume it later, it works again.
That is of course not a problem of scitopdf, but a (well intentioned) restriction of the server.
This got me thinking.
Maybe there could be an extra optional flag to use with the "-l --list" flag ?
Something to self limit yourself or pause a bit between requests ?
Like, for example:
That is. If doing multiple consecutive requests, wait and pause xyz seconds/minutes between them.
What do you think ?
dougy147 commented on 2023-11-09 13:45 (UTC) (edited on 2024-03-13 09:55 (UTC) by dougy147)
@m040601, @Antiz
First of, thanks for your insightful remarks. I hope your efforts to guide me towards compliance regarding the AUR guidelines are fruitful. Here is what I did:
Corrected this and set PREFIX to
/usr
in PKGBUILD. As stated here: "All Arch Linux packages should use the /usr directory."As the script is stable, I created a release on GitHub (v0.6.5). PKGBUILD points towards the latest release tag and will not be updated everytime a minor change is made.
The pkgver() function has been added to PKGBUILD and will follow the last annotated tag in the development repository.
LICENSE has been correctly renamed in the GitHub repository. Thanks for noticing that!
I don't find any doc about this, is there something wrong with the man page?
Also note that this package is now conflicting with
scitopdf-git
to avoid potential troubles on users end.Finally, I am not against removing this repository if judged needed. Otherwise, if there are any other changes to be done, I will pursue efforts to guidelines compliance.
Again, thank you for time spent inspecting that package.
Antiz commented on 2023-09-19 13:26 (UTC) (edited on 2023-09-19 13:29 (UTC) by Antiz)
@m040601, dougy147:
True
This software is licensed under the GPL3 license so it does not need to copy the license locally as the said license is already provided by the [licenses package(https://wiki.archlinux.org/title/PKGBUILD#license). See https://wiki.archlinux.org/title/PKGBUILD#license
That would have been true if that package had a proper "pkgver()" function, but it does not. See: https://wiki.archlinux.org/title/VCS_package_guidelines#The_pkgver()_function
Despite being maintained by the developer of the software itself, this package does not respect the packaging guidelines and is a duplicate one (since this package seems to have been uploaded on the AUR first), which is not allowed.
As explained in this comment, I don't see the point working on making this package compliant with the package guidelines to replace the current scitopdf-git package when the latter is already properly packaged. I advice making a merge-request from this package to the scitopdf-git package and ask the current maintainer of it to add you (dougy147) as a co-maintainer if you want to collaborate on maintaining it.
m040601 commented on 2023-09-19 11:53 (UTC) (edited on 2023-09-19 12:01 (UTC) by m040601)
You dont need to keep changing the "pkgver" for this PKGBUILD,when you do some development on github. You dont have to come here on AUR and update the PKGBUILD yourself.
5 to 6, 7 to 8 etc
It's useless. Because you have neither "versions" nor "releases" on github.
https://wiki.archlinux.org/title/VCS_package_guidelines
This PKGBUILD uses git to pull from master.
It automatically makes sure the user as the latest software on his PC as you have made changes on github.
Because it is a "-git" type of PKGBUILD it doesnt care about "versions" or what you do on github. If it detects that you have done something on the master repo on github, it automaticaly asks the AUR user to update. And uses git clone to pull those latest commits.
https://wiki.archlinux.org/title/Arch_package_guidelines
https://wiki.archlinux.org/title/PKGBUILD
https://wiki.archlinux.org/title/Creating_packages
m040601 commented on 2023-09-19 11:00 (UTC) (edited on 2023-09-19 11:01 (UTC) by m040601)
@dougy147
You are still missing the LICENSE which you have on the repo and should end up in
And eventually the README and future docs. That is if the man page does not contain everything neeeded and is not up to date.
m040601 commented on 2023-09-19 10:46 (UTC) (edited on 2023-09-19 11:03 (UTC) by m040601)
This PKGBUILD should be actually called "scitopdf-git" and not "scitopdf" according to the AUR guidelines, https://wiki.archlinux.org/title/Arch_package_guidelines#Package_naming
Its source is not a release xxx-number.tar.gz that gets pulled from github. As there are no releases on github.
It just uses git clone to build the package.
Unfortunately someone else also made a "scitopdf-git" PKGBUILD and took that name, https://aur.archlinux.org/packages/scitopdf-git.
It's useless and confusing to end users to have duplictated PKGBUILDs on the AUR doing the same thing exactly.
I left a message there, asking the maintainer to consider deleting the PKGBUILD ( 1995parham ) "scitopdf-git" .
So that this one (dougy147) can use that name and be renamed to "scitopdf".
It seems to be the wise thing do to since dougy147 is both the developer of the tool and maintains the PKGBUILD.
dougy147 commented on 2022-06-21 08:58 (UTC)
Insightful remarks, proper release will come soon
m040601 commented on 2022-06-19 22:51 (UTC) (edited on 2022-06-19 23:09 (UTC) by m040601)
Interesting tool. And thanks for creating it and coming here to work on this PKGBUILD. The way you have it right now, this is the end result,
$ pacman -Ql scitopdf
"/usr/local".
This is wrong according the Arch PKGBUILD guide lines. You should not be using "/usr/local" in Archlinux.
You are probably doing this mistake, because you are blindly following what the Makefile, https://github.com/dougy147/scitopdf/blob/master/Makefile in the original repo contains.
That Makefile is a generic file for a generic Linux installation. AUR PKGBUILD's are specific to Archlinux. You are supposed to study that Makefile and understand what is needed to be done, for the Archlinux PKGBBUILD. not blindly copy it.
See how another Arch users does it, https://aur.archlinux.org/packages/scitopdf-git, and correct yours. You could actually coordinate with him. No need for two different maintainers for the same tool.
You also named your PKGBUILD "0.3.r124.729695f-1", which to me seems that your intention is simply pull whatever the lastest commits you have on github. In that case, it should be called "XXX-git" . There is no need for that, as there is already the other "scitopdf-git".
If you want a more stable PKGBUILD on Archlinux, maybe you could wait a little longer, until you have polished it more, and are certain of no big bugs. Than do a proper "release" on github. Something like "version "1.0". And then start with a "pkgver=1.0" or "1.1", etc in AUR. Not version 0.3345345XXXXXX.
Only than, does it make sense to have a "stable" version of "scitopdf" in AUR. One that "pulls" from the releases, not the latest git commmits.