On Sun, Jan 10, 2010 at 12:06:11AM -0700, Kevin Fenzi wrote: > rjones:BADURL:expat-2.0.1.tar.gz:mingw32-expat > rjones:BADURL:mingwrt-3.15.2-mingw32-src.tar.gz:mingw32-runtime > rjones:BADURL:PDCurses-3.4.tar.gz:mingw32-pdcurses > rjones:BADURL:w32api-3.13-mingw32-src.tar.gz:mingw32-w32api > rjones:BADURL:watchdog-5.5.tar.gz:watchdog Sourceforge seems to have changed the format of their download URLs once again. The source url for the first one is: http://download.sourceforge.net/expat/expat-%{version}.tar.gz which corresponds with the advice given here (and obviously this worked previously). https://fedoraproject.org/wiki/Packaging:SourceURL But the above link no longer works, and the new URL is this: http://downloads.sourceforge.net/project/expat/expat/2.0.1/expat-2.0.1.tar.gz What's the current thinking on SF URLs? Perhaps we should have an RPM macro/feature to hide this hideousness? > rjones:BADURL:camlimages-3.0.1.tar.gz:ocaml-camlimages Fixed by rebasing to new upstream version 3.0.2. > rjones:BADURL:coccinelle-0.1.10.tgz:coccinelle Fixed by rebasing to new upstream version 0.2.0rc1. > rjones:BADURL:freetype-2.3.8.tar.bz2:mingw32-freetype > rjones:BADURL:freetype-doc-2.3.8.tar.bz2:mingw32-freetype Upstream moved. Fixed by rebasing to 2.3.11. > rjones:BADURL:libpng-1.2.40.tar.bz2:mingw32-libpng Annoyingly tricky to fix. Anyone in fedora-mingw SIG want to help? > rjones:BADURL:ocaml-autoconf-1.1.tar.gz:ocaml-autoconf This seems OK to me, but it's an HTTPS URL with a self-signed certificate, and I seem to remember those caused problems for spectool in the past. > rjones:BADURL:ocamlp3l-2.03.tgz:ocaml-p3l Fixed. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
