Package Details: mingw-w64-giflib 5.1.2-1

Git Clone URL: https://aur.archlinux.org/mingw-w64-giflib.git (read-only)
Package Base: mingw-w64-giflib
Description: A library for reading and writing gif images (mingw-w64)
Upstream URL: http://sourceforge.net/projects/giflib/
Keywords: giflib mingw mingw-w64
Licenses: MIT
Submitter: Schala
Maintainer: Schala
Last Packager: Schala
Votes: 2
Popularity: 0.000000
First Submitted: 2012-11-01 00:39
Last Updated: 2016-01-22 12:49

Latest Comments

Schala commented on 2016-01-24 09:42

I have no idea what's up with the repo right now.

mawe commented on 2016-01-24 06:13

I thought plain 'giflib' is meant to be the corresponding regular package.

Schala commented on 2016-01-24 05:58

I thought I did? I saw lib32-giflib on repo

mawe commented on 2016-01-23 10:12

Why didn't the policy "follow the Arch version" - as it was topic below - apply this time?

ricco19 commented on 2016-01-23 05:05

Newest version broke my program, official repo still using 5.1.1. See bug here: http://sourceforge.net/p/giflib/bugs/80/

ant32 commented on 2015-01-29 21:25

Oh! That's a new idea to me. Till now I've seen us maintainers complaining when it is flaged before offical package is updated. Maybe it's right to flag even if we're not suppose to update it yet. I think it is still best if users wait to flag till the official package is updated (That way we know which packages need attention), but us maintainers should be aware that the user shouldn't be expected to know this policy and when we comment we should kindly tell them next time to wait till the officail package is updated.

mawe commented on 2015-01-29 20:29

I understand, but I rather refered to my act of flagging this package.

ant32 commented on 2015-01-29 15:39

Always try to match the pkgver in your mingw-w64 packages to the pkgver of the corresponding regular packages in the official Arch Linux repos (not the testing repos). This ensures that the cross-compiled software works exactly the same way on Windows without any unexpected bugs. If packages in Arch are out-of-date, there usually is a good reason and you should still follow the Arch version instead of using the most recent upstream release. If the corresponding native package is in the AUR, you need not follow this version policy, as many AUR packages are often orphaned or left unmaintained.
https://wiki.archlinux.org/index.php?title=MinGW_package_guidelines&redirect=no

mawe commented on 2015-01-29 13:14

Where does this policy come from? A package is out-of-date if there is a newer stable release available upstream.

Schala commented on 2015-01-28 23:04

Don't flag out of date until the official repo updates

All comments