Hi, On Thu, Feb 1, 2018 at 5:20 PM, Michael Kogan wrote:

I am wondering, what about PKGBUILDs whose source is hosted at Launchpad or Sourceforge? Those are quite common hosters, are there plans to add them? Thanks!

I see the following difficulties with Launchpad or Sourceforge (as a infrequent user I might be wrong): - Sometimes, more than one software/package is released within a project, such as [1] - The files are listed in chronological order, but there's no clear concept of the latest release Since only few of my packages are hosted there, extracting version from there is not high priority for me. However, if you came up with a PR or a way to reliably determine the latest release, I'd happily include that. Simon [1] https://sourceforge.net/projects/sevenzip/files/

Hi, On Thu, Feb 1, 2018 at 5:44 PM, Eli Schwartz via aur-general wrote:

This looks quite cool!

Thanks :)

1) How does this handle PKGBUILDs that, say, have their homepage on github, but do not tag releases there -- because :( :( :( -- and instead push releases to PyPI or npmjs or something?

This should work: unless a version can be determined from the upstream URL, the first source URL is used for a second attempt. I haven't tested the described situation, though.

2) It looks like your AUR package is downloading a source tarball, then completely ignoring it by using go get and downloading the bleeding-edge master. I'm not really sure how this crazy language handles packaging :p but I think *maybe* you should be cloning git+https://github.com/simon04/$pkgname.git#tag=v$pkgver and symlinking "$srcdir/$pkgname" --> "$srcdir/src/github.com/simon04/aur-out-of-date/"

You're right. I hopefully fixed that in aur-out-of-date 0.6.0-2 Simon

On 02/01/2018 02:56 PM, Michael Kogan wrote:

Unfortunately, I don't know Go and in general have too little programming skills and experience to propose any code modifications. But I have an idea: What about introducing some variables which the package maintainers would put into their PKGBUILD and which are then parsed by aur-out-of-date? The variables might be commented out in order to not interfere with whatever happens when makepkg is run. Something like

# aur-out-of-date-check-url = https://sourceforge.net/projects/sevenzip/files/7-Zip/

for the above example. There could be sane defaults defined for such problematic hosters and only if they fail the user-defined values put into the PKGBUILD by its maintainer would be used. Also this would require some documentation to tell the maintainers which variables are necessary and how to give them the desired values.

Just an idea, I don't know if it makes much sense. Well, lots of people already do this, via urlwatch or pkgbuild-urlwatch. I think the idea was supposed to be, finding a way to do this without introducing complex tricks that need to be manually added to the PKGBUILD and then fragilely parsed.

-- Eli Schwartz Bug Wrangler and Trusted User

On 02/01/2018 11:08 AM, Simon Legner via aur-general wrote:

Hi aur-general,

as a maintainer of fifty-something AUR packages I found it difficult to keep track of new upstream versions. I would subscribe to various RSS feeds to keep track of some.

Recently, I sat down and wrote a tool "aur-out-of-date" which, given a username or a list of packages, checks upstream for newer versions. It does so by inspecting the upstream URL and/or source URL, and calling a suitable API (github.com, registry.npmjs.org, pypi.python.org, cpan.org for now) to determine the latest released version. Out-of-date packages are output in red color on the command line.

Give it a try: https://github.com/simon04/aur-out-of-date https://aur.archlinux.org/packages/aur-out-of-date/

I'm happy to hear you feedback :) Simon

Awesome project. I made myself a similar one, a bash script that checks GitHub API for new versions and updates the PKGBUILD. I was planning on making something bigger with ruby, so it would be easily extensible for non-regular cases (custom download pages etc.). So I'm testing it at the moment. Looks cool. First of all please modify the name of the source in AUR. Some people use common source directories and that causes conflicts. Secondly I think the program is too verbose. It would be better readable displaying only brief information like: "[OUT-OF-DATE] [$pkgname] Flagged: 1.0.0 -> 1.0.1" or something like that. An option to ignore [UNKNOWN] packages would be great too. I might be wrong, but it seems to go crazy with metapackages. I don't know Go, but I'll try to patch if anything else comes to my mind. Eli Schwartz via aur-general writes:

1) How does this handle PKGBUILDs that, say, have their homepage on github, but do not tag releases there -- because :( :( :( -- and instead push releases to PyPI or npmjs or something?

Imho such cases should be always reported upstream as that is a very bad practice. Marcin Wieczorek