Bug 1152155 - Update to 3.14.3
Summary: Update to 3.14.3
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: mingw-gtk3
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kalev Lember
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-10-13 13:50 UTC by David King
Modified: 2014-11-02 07:28 UTC (History)
2 users (show)

Fixed In Version: mingw-atk-2.14.0-1.fc21
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-11-02 07:28:53 UTC


Attachments (Terms of Use)
update to 3.14.2 (14.15 KB, patch)
2014-10-13 13:51 UTC, David King
no flags Details | Diff
refactor autoreconf handling (2.61 KB, patch)
2014-10-13 13:52 UTC, David King
no flags Details | Diff
update to 3.14.3 (14.16 KB, patch)
2014-10-14 08:40 UTC, David King
no flags Details | Diff
updated autoreconf patch (1.71 KB, patch)
2014-10-14 08:41 UTC, David King
no flags Details | Diff

Description David King 2014-10-13 13:50:09 UTC
It would be nice to have the latest GTK+ 3 for MinGW.

Comment 1 David King 2014-10-13 13:51:59 UTC
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.

Comment 2 David King 2014-10-13 13:52:54 UTC
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.

Comment 3 Erik van Pienbroek 2014-10-13 16:36:46 UTC
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.

Comment 4 David King 2014-10-13 16:51:16 UTC
(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?

Comment 5 Kalev Lember 2014-10-13 16:59:16 UTC
I have another question. I see you've switched to 'install -p' in a few places -- what's the benefit of doing that?

Comment 6 David King 2014-10-13 17:05:58 UTC
(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

Comment 7 Kalev Lember 2014-10-13 18:04:16 UTC
(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.

Comment 8 David King 2014-10-13 18:36:58 UTC
(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".

Comment 9 David King 2014-10-14 08:40:19 UTC
Created attachment 946748 [details]
update to 3.14.3

3.14.3 was released yesterday.

Comment 10 David King 2014-10-14 08:41:25 UTC
Created attachment 946749 [details]
updated autoreconf patch

Dropped the preserve timestamps bits.

Comment 11 Kalev Lember 2014-10-14 13:50:34 UTC
Thanks! Pushed both with the minor edit suggested in comment #3.

Comment 12 Fedora Update System 2014-10-17 12:37:51 UTC
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

Comment 13 Fedora Update System 2014-10-17 19:43:44 UTC
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).

Comment 14 Fedora Update System 2014-11-02 07:28:53 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.