Created attachment 684698 [details] Various packaging fixes/improvements - Build with XPS support, fix building with GNOME keyring support. - Be explicit about unicode=libunistring and disabling Qt. - Description spelling fixes. - Fix bogus %changelog dates. unicode=libunistring is needed for reproducible builds if libicu-devel happens to be installed, and disable-qt ditto in case qt-devel is. Let me know if you'd like me to commit and build this for devel.
*** Bug 896707 has been marked as a duplicate of this bug. ***
Thanks for the patch. Bug fixed in rawhide (and F18 & F17).
*** Bug 877783 has been marked as a duplicate of this bug. ***
(In reply to Ville Skyttä from comment #0) > - Be explicit about unicode=libunistring and disabling Qt. This is wrong. See: https://bugzilla.gnome.org/show_bug.cgi?id=666749 We want to build against libicu, not libunistring. Upstream has changed the defaults to prefer libicu if nothing is explicitly specified.
(In reply to Debarshi Ray from comment #4) > (In reply to Ville Skyttä from comment #0) > > - Be explicit about unicode=libunistring and disabling Qt. > > This is wrong. Nope, the patch just made the build reproducible by being explicit about the unicode lib choice which was earlier implicit based on what happened to be in the build root and this somewhat fragile, that's definitely the right thing to do. Note: no comment whether the unicode lib should be libunistring or libicu, but the build needs to be reproducible.
(In reply to Ville Skyttä from comment #5) > (In reply to Debarshi Ray from comment #4) > > (In reply to Ville Skyttä from comment #0) > > > - Be explicit about unicode=libunistring and disabling Qt. > > > > This is wrong. > > Nope, the patch just made the build reproducible by being explicit And in trying to do so it caused a major regression in released & stable versions of Fedora. A regression that was earlier marked as a blocker for an upstream GNOME release. > about the > unicode lib choice which was earlier implicit based on what happened to be > in the build root and this somewhat fragile, It might well have been implicit, but it was doing the right thing in Koji because of the defaults in the upstream buildsystem. > that's definitely the right > thing to do. The correct fix would have been to remove the BR on libunistring-devel, since that is unused, and explicitly specify libicu. But specifying libunistring there a regression was introduced. Please refrain from doing such fly-by commits in stable branches of Fedora. Note, that I have fixed this in master. I will unbreak F20 and F19 after further testing.
(In reply to Debarshi Ray from comment #6) > (In reply to Ville Skyttä from comment #5) > > (In reply to Debarshi Ray from comment #4) > > > (In reply to Ville Skyttä from comment #0) > > > > - Be explicit about unicode=libunistring and disabling Qt. > > > > > > This is wrong. > > > > Nope, the patch just made the build reproducible by being explicit > > And in trying to do so it caused a major regression in released & stable > versions of Fedora. No it didn't. And it didn't "try to do so", it _did_ make explicit what it said it would. > It might well have been implicit, but it was doing the right thing in Koji > because of the defaults in the upstream buildsystem. No it wasn't. There was no build dep on libicu-devel so the package never built with libicu in clean buildroots, including the Fedora build system, no matter what the upstream defaults were. On the other hand if libicu-devel happened to be installed such as on some developer boxes, it built with libicu despite the obvious intent to build with libunistring, witnessed by the presence of BR libunistring-devel (and no BR on libicu-devel). Don't believe me? Check out revision b5bed63758766c2e8cca8a88b64291b5e285e55f (the one before my patch was merged) from git and notice that there's no libicu-devel build dep, but there is one for libunistring-devel. Still not convinced? See http://koji.fedoraproject.org/koji/rpminfo?rpmID=3662395 (the last koji build available before my changes went in) and note that it was built with libunistring, not libicu. > The correct fix would have been to remove the BR on libunistring-devel, > since that is unused, and explicitly specify libicu. Could very well be. But that's something entirely different than what my patch tried to do and did so comparing would be apples vs oranges. > Please refrain from doing such fly-by commits in stable branches of Fedora. Please do more homework before throwing accusations like this. My patch didn't cause the regression you claim it did, and I didn't commit anything *anywhere*, I submitted a patch in Bugzilla, which the package's owner applied (see comment 2 and git rev c9f8e13cac0c9b53dfe032cb10acdaebda24aaf2).