Created attachment 946397 [details]
update to 3.14.2

This would need 3.14.2 uploading to the lookaside cache, but should otherwise be fine.

Created attachment 946398 [details]
refactor autoreconf handling

This is similar to the handling in gnome-disk-utility, and makes it nicer to add patches which touch the build system.

You beat me to it in updating mingw-gtk3, thanks for helping out :)

In your second patch you've moved the autoreconf instruction from the %prep phase to the %build phase. Is that intentional? All other packages I've seen which use autoreconf call it from the %prep phase.

(In reply to Erik van Pienbroek from comment #3)
> You beat me to it in updating mingw-gtk3, thanks for helping out :)

I use the Fedora MinGW packages for EasyTAG Windows builds, so thanks to you too!

> In your second patch you've moved the autoreconf instruction from the %prep
> phase to the %build phase. Is that intentional? All other packages I've seen
> which use autoreconf call it from the %prep phase.

I was basing the change on what was already in the gnome-disk-utility package:

http://pkgs.fedoraproject.org/cgit/gnome-disk-utility.git/tree/gnome-disk-utility.spec#n50

I do not know which approach is "better", but to me it makes more sense to keep the autoreconf parts together with the configure parts. I could not really tell from https://fedoraproject.org/wiki/How_to_create_an_RPM_package whether autoreconf should belong in %build or %prep, do you know of a better reference?

I have another question. I see you've switched to 'install -p' in a few places -- what's the benefit of doing that?

(In reply to Kalev Lember from comment #5)
> I have another question. I see you've switched to 'install -p' in a few
> places -- what's the benefit of doing that?

It preserves timestamps of files when installing them. It is (very) briefly mentioned in the packaging guidelines as a recommendation: https://fedoraproject.org/wiki/Packaging:Guidelines#Timestamps

(In reply to David King from comment #6)
> It preserves timestamps of files when installing them.

Right, but what's the benefit of preserving the tarball timestamps?

> It is (very) briefly mentioned in the packaging guidelines
> as a recommendation:
> https://fedoraproject.org/wiki/Packaging:Guidelines#Timestamps

I think the packaging guidelines are misguided here and 'install -p' at best only adds unnecessary cruft to the spec file and at worst can be actively harmful when it causes timestamps to go backwards in rpm files.

Consider a typical workflow for creating upstream tarballs. One would check out a tree with git, run 'configure', 'make' and 'make distcheck'. This creates a tarball with the same timestamps that the sources files in the checked out git tree had.

But what happens if all releases aren't done from the same git clone, for example when a module has two maintainers who each use their own local clone? Depending on which clone the tarball is created from, the timestamps are taken from the local checkout, and if the newer release is created from an older clone, the timestamps go backwards.

I would guess that this is also the reason why 'install' (in my opinion, correctly) defaults to not preserving timestamps.

(In reply to Kalev Lember from comment #7)
> Right, but what's the benefit of preserving the tarball timestamps?

It is not mentioned in the guidelines, but I guess that it is useful in the case where the timestamps of distributed files do not change between releases.

> I think the packaging guidelines are misguided here and 'install -p' at best
> only adds unnecessary cruft to the spec file and at worst can be actively
> harmful when it causes timestamps to go backwards in rpm files.
> 
> Consider a typical workflow for creating upstream tarballs. One would check
> out a tree with git, run 'configure', 'make' and 'make distcheck'. This
> creates a tarball with the same timestamps that the sources files in the
> checked out git tree had.
> 
> But what happens if all releases aren't done from the same git clone, for
> example when a module has two maintainers who each use their own local
> clone? Depending on which clone the tarball is created from, the timestamps
> are taken from the local checkout, and if the newer release is created from
> an older clone, the timestamps go backwards.
> 
> I would guess that this is also the reason why 'install' (in my opinion,
> correctly) defaults to not preserving timestamps.

Maybe. I am not really fussed about adding the INSTALL="install -p".

Created attachment 946748 [details]
update to 3.14.3

3.14.3 was released yesterday.

Created attachment 946749 [details]
updated autoreconf patch

Dropped the preserve timestamps bits.

Thanks! Pushed both with the minor edit suggested in comment #3.

mingw-atk-2.14.0-1.fc21,mingw-gdk-pixbuf-2.31.1-1.fc21,mingw-glib2-2.42.0-1.fc21,mingw-glib-networking-2.42.0-1.fc21,mingw-gtk2-2.24.25-1.fc21,mingw-gtk3-3.14.3-1.fc21,mingw-gtksourceview3-3.14.1-1.fc21,mingw-libsoup-2.48.0-1.fc21,mingw-pango-1.36.8-1.fc21,mingw-pixman-0.32.6-1.fc21,mingw-webkitgtk-2.2.8-1.fc21,mingw-webkitgtk3-2.2.8-1.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/mingw-atk-2.14.0-1.fc21,mingw-gdk-pixbuf-2.31.1-1.fc21,mingw-glib2-2.42.0-1.fc21,mingw-glib-networking-2.42.0-1.fc21,mingw-gtk2-2.24.25-1.fc21,mingw-gtk3-3.14.3-1.fc21,mingw-gtksourceview3-3.14.1-1.fc21,mingw-libsoup-2.48.0-1.fc21,mingw-pango-1.36.8-1.fc21,mingw-pixman-0.32.6-1.fc21,mingw-webkitgtk-2.2.8-1.fc21,mingw-webkitgtk3-2.2.8-1.fc21

Package mingw-atk-2.14.0-1.fc21, mingw-gdk-pixbuf-2.31.1-1.fc21, mingw-glib2-2.42.0-1.fc21, mingw-glib-networking-2.42.0-1.fc21, mingw-gtk2-2.24.25-1.fc21, mingw-gtk3-3.14.3-1.fc21, mingw-gtksourceview3-3.14.1-1.fc21, mingw-libsoup-2.48.0-1.fc21, mingw-pango-1.36.8-1.fc21, mingw-pixman-0.32.6-1.fc21, mingw-webkitgtk-2.2.8-1.fc21, mingw-webkitgtk3-2.2.8-1.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing mingw-atk-2.14.0-1.fc21 mingw-gdk-pixbuf-2.31.1-1.fc21 mingw-glib2-2.42.0-1.fc21 mingw-glib-networking-2.42.0-1.fc21 mingw-gtk2-2.24.25-1.fc21 mingw-gtk3-3.14.3-1.fc21 mingw-gtksourceview3-3.14.1-1.fc21 mingw-libsoup-2.48.0-1.fc21 mingw-pango-1.36.8-1.fc21 mingw-pixman-0.32.6-1.fc21 mingw-webkitgtk-2.2.8-1.fc21 mingw-webkitgtk3-2.2.8-1.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-13078/mingw-atk-2.14.0-1.fc21,mingw-gdk-pixbuf-2.31.1-1.fc21,mingw-glib2-2.42.0-1.fc21,mingw-glib-networking-2.42.0-1.fc21,mingw-gtk2-2.24.25-1.fc21,mingw-gtk3-3.14.3-1.fc21,mingw-gtksourceview3-3.14.1-1.fc21,mingw-libsoup-2.48.0-1.fc21,mingw-pango-1.36.8-1.fc21,mingw-pixman-0.32.6-1.fc21,mingw-webkitgtk-2.2.8-1.fc21,mingw-webkitgtk3-2.2.8-1.fc21
then log in and leave karma (feedback).

mingw-atk-2.14.0-1.fc21, mingw-gdk-pixbuf-2.31.1-1.fc21, mingw-glib2-2.42.0-1.fc21, mingw-glib-networking-2.42.0-1.fc21, mingw-gtk2-2.24.25-1.fc21, mingw-gtk3-3.14.3-1.fc21, mingw-gtksourceview3-3.14.1-1.fc21, mingw-libsoup-2.48.0-1.fc21, mingw-pango-1.36.8-1.fc21, mingw-pixman-0.32.6-1.fc21, mingw-webkitgtk-2.2.8-1.fc21, mingw-webkitgtk3-2.2.8-1.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.