Bug 902549 - Various tracker packaging fixes/improvements
Various tracker packaging fixes/improvements
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: tracker (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Deji Akingunola
Fedora Extras Quality Assurance
: Patch
: 877783 896707 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-01-21 17:29 EST by Ville Skyttä
Modified: 2013-12-19 18:18 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-21 11:24:03 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Various packaging fixes/improvements (5.17 KB, patch)
2013-01-21 17:29 EST, Ville Skyttä
no flags Details | Diff

  None (edit)
Description Ville Skyttä 2013-01-21 17:29:42 EST
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.
Comment 1 Ville Skyttä 2013-01-21 17:30:38 EST
*** Bug 896707 has been marked as a duplicate of this bug. ***
Comment 2 Deji Akingunola 2013-02-21 11:24:03 EST
Thanks for the patch. Bug fixed in rawhide (and F18 & F17).
Comment 3 Ville Skyttä 2013-02-21 14:10:19 EST
*** Bug 877783 has been marked as a duplicate of this bug. ***
Comment 4 Debarshi Ray 2013-12-18 11:06:17 EST
(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.
Comment 5 Ville Skyttä 2013-12-18 16:24:52 EST
(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.
Comment 6 Debarshi Ray 2013-12-19 12:23:36 EST
(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.
Comment 7 Ville Skyttä 2013-12-19 18:18:17 EST
(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).

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