Arch Linux User Repository

I incorporated working curl options from script by Dwaddle directly into the PKGBUILD. I have done that in the hackish way, if someone can propose "the right way" to do it, I will appreciate. But for now it works.

@SydMax
What do you think of this solution ?
Downloads the file if remote version is newer or if there is no local archive, rewrites PKGBUILD to reflect local build and builds the package in one step

https://github.com/dwaddle/ZyGrib-downloader/blob/master/zygrib-org.sh

It's not an ideal solution but it does make live a lot easier.

I only have doubts about automatic recalculating the sha256 checksum for a newer version.

Ok, makepkg/PKGBUILD don't work with cookies ;-(. That would mean that we are probably stuck for a while with this solution. Unless we somehow can mirror the file to a location without a cookie or start hacking around in makepkg ourselves.

Both options probably take a while, Maybe we need a better/more elegant script

Thank you for your script. I am aware of this problem, but was not able to come up with any not-so-hack-like solution yet [except to download source file manually]. If anyone have some elegant solution to offer, don't hesitate to share.

makepkg can not download the file. It retrieves the homepage. For downloading the tgz file you need a session cookie. The bash-script below works great but I don't have a clue how to include the functionality in the PKGBUILD file.
<---------SCRIPT ---------------------->
FILE='zyGrib-7.0.0.tgz'
URL="http://www.zygrib.org/"
URL_DOWNLOAD="$URL/getfile.php?file=$FILE"

# -------------------------------------------
# the --next directive requires curl >=7.36.0
# -------------------------------------------
# the first curl request gets the main page and the needed session cookie
# the second request retrieves the file
curl --cookie nada $URL > /dev/null --next --cookie nada -o $FILE $URL_DOWNLOAD
<---- Script ends ------>

Things are a bit complicated now with the new build. Zygrib require qwt 6.0.x, and fails to build against qwt 6.1.x from current [extra]. It can be built against local copy of qwt 6.0.1 provided together with its sources, but there is a bug http://sourceforge.net/p/qwt/bugs/150/ because of which local qwt can not be built if there is already qwt installation in /usr/lib. This bug can not be fixed by qwt devs, it require interaction with repo qwt packager or qmake patching. So for now options are:
1. Rallback to the last qwt 6.0.x arch package and build zygrib against it [you should edit PKGBUILD, comment out zyGrib_Qt_path.patch and uncomment zyGrib_ARCH_0.1.patch which was used in previous zygrib PKGBUILDS]. Bad option, obviously.
2. Temporarily remove qwt (pacman -R -dd qwt), build zygrib (its own qwt 6.0.1 will be used), install qwt back. Nasty workaround, hopefully temporary, but seems to be a bit better than 1.
3. Contact qwt packager to move qwt from /usr/lib to its own directory. This will eliminate need in qwt removing hack. I will do this, but it may take some time to be done. We can also contact qwt developers with a request to fix qwt 6.1.x compatibility. May take a lot of time.
If I missed something or if someone have better idea, please let us know.

Things a bit complicated now with the new build. Zygrib require qwt 6.0.x, and fails to build against qwt 6.1.x from current [extra]. It can be built against local copy of qwt 6.0.1 provided together with its sources, but there is a bug http://sourceforge.net/p/qwt/bugs/150/ because of which local qwt can not be built if there is already qwt installation in /usr/lib. This bug can not be fixed by qwt devs, it require interaction with repo qwt packager or qmake patching. So for now options are:
1. Rallback to the last qwt 6.0.x arch package and build zygrib against it [you should edit PKGBUILD, comment out zyGrib_Qt_path.patch and uncomment zyGrib_ARCH_0.1.patch which was used in previous zygrib PKGBUILDS]. Bad option, obviously.
2. Temporarily remove qwt (pacman -R -dd qwt), build zygrib (its own qwt 6.0.1 will be used), install qwt back. Nasty workaround, hopefully temporary, but seems to be a bit better than 1.
3. Contact qwt packager to move qwt from /usr/lib to its own directory. This will eliminate need in qwt removing hack. I will do this, but it may take some time to be done. We can also contact qwt developers with a request to fix qwt 6.1.x compatibility. May take a lot of time.
If I missed something or if someone have better idea, please let us know.

New version 6.2.3 is available.
Could you update ?

The 6.2.1-1 build seems to fail with following output, see http://pastebin.com/b97ZnbdH

Ok, for some reason developers decided to make a silent update of the source tarball without version increase or any notification.