Unannounced soname bump: tracker

[Adam Williamson]

Sigh. Yes, another of these.

On 2013-12-18, tracker was bumped to 0.7.0:

http://koji.fedoraproject.org/koji/buildinfo?buildID=485698

the sonames of libtracker-extract, libtracker-miner and
libtracker-sparql were bumped to 0.18.so.0 (from 0.16.so.0) without
announcement, and without all dependent packages being successfully
rebuilt. At least the following still depend on the old sparql library:

bijiben-0:3.11.1-1.fc21.x86_64
brasero-0:3.11.3-1.fc21.x86_64
grilo-plugins-0:0.2.9-2.fc21.x86_64
media-explorer-0:0.4.4-5.fc21.x86_64
rygel-tracker-0:0.21.1-1.fc21.x86_64

I'll see if I can get any of them rebuilt.

What does it take for people to handle soname bumps properly?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Debarshi Ray]

On Fri, Dec 27, 2013 at 05:50:18PM -0800, Adam Williamson wrote:
>  Sigh. Yes, another of these.
>  
>  On 2013-12-18, tracker was bumped to 0.7.0:
>  
>  http://koji.fedoraproject.org/koji/buildinfo?buildID=485698
>  
>  the sonames of libtracker-extract, libtracker-miner and
>  libtracker-sparql were bumped to 0.18.so.0 (from 0.16.so.0) without
>  announcement, and without all dependent packages being successfully
>  rebuilt. At least the following still depend on the old sparql library: 
The thing with Tracker is that they bump the bump the soname and their
pkgconfig file version somewhat gratuitously every six months.

I built a new tracker because some applications (eg., gnome-photos)
specifically want the features in the 0.17/0.18 series.

I thought I had rebuilt all the affected packages, but obviously I
missed some.

>  bijiben-0:3.11.1-1.fc21.x86_64
>  brasero-0:3.11.3-1.fc21.x86_64 
I thought the round of builds for 3.11.3 would take care of these two, but
it looks like bijiben was not built by mclazy and brasero got built before
the new tracker hit the trees. :-/

>  grilo-plugins-0:0.2.9-2.fc21.x86_64
>  media-explorer-0:0.4.4-5.fc21.x86_64 
These two need new upstream releases, but the patches are already in
Git.

>  What does it take for people to handle soname bumps properly? 
Barring media-explorer, everything else is part of the GNOME stack so
chances of other spins being broken by this was low.

My assumption was that sooner or later this would be sorted by the
GNOME builds during the 3.11.x cycle. Given that the Fedora and GNOME
schedules are quite a bit out of sync these days, I was hoping for
some transient rawhide breakage during the Christmas break to go
largely unnoticed. I mean if this is the only thing broken in Rawhide
at the moment, then I would be more than happy. :)

Anyway. Thanks for taking care of this, and sorry for the trouble.

Cheers,
Debarshi

-- 
Wearing non-prescription glasses and embracing obscurity doesn't
necessarily make you a hipster.  -- Anonymous

[Peter Robinson]

> > http://koji.fedoraproject.org/koji/buildinfo?buildID=485698
> >
> > the sonames of libtracker-extract, libtracker-miner and
> > libtracker-sparql were bumped to 0.18.so.0 (from 0.16.so.0) without
> > announcement, and without all dependent packages being successfully
> > rebuilt. At least the following still depend on the old sparql library:
>
>  The thing with Tracker is that they bump the bump the soname and their
>  pkgconfig file version somewhat gratuitously every six months.
>
>  I built a new tracker because some applications (eg., gnome-photos)
>  specifically want the features in the 0.17/0.18 series.
>
>  I thought I had rebuilt all the affected packages, but obviously I
>  missed some.
>
> > bijiben-0:3.11.1-1.fc21.x86_64
> > brasero-0:3.11.3-1.fc21.x86_64
>
>  I thought the round of builds for 3.11.3 would take care of these two, but
>  it looks like bijiben was not built by mclazy and brasero got built before
>  the new tracker hit the trees. :-/
>
> > grilo-plugins-0:0.2.9-2.fc21.x86_64
> > media-explorer-0:0.4.4-5.fc21.x86_64
>
>  These two need new upstream releases, but the patches are already in
>  Git.
>
> > What does it take for people to handle soname bumps properly?
>
>  Barring media-explorer, everything else is part of the GNOME stack so
>  chances of other spins being broken by this was low.
>
>  My assumption was that sooner or later this would be sorted by the
>  GNOME builds during the 3.11.x cycle. Given that the Fedora and GNOME
>  schedules are quite a bit out of sync these days, I was hoping for
>  some transient rawhide breakage during the Christmas break to go
>  largely unnoticed. I mean if this is the only thing broken in Rawhide
>  at the moment, then I would be more than happy. :) 
Ultimately the rule of thumb is if it's a soname bump you need to
rebuild all the packages that are dependent on it when you push the
build. Relying on the possibility that some time in the future there
maybe a new release of something is not good enough as there are
people that use rawhide constantly and you're unnecessarily causing
pain for them and extra work for others to cleanup the mess. If the
soname is bumped you need to rebuild all the dependent packages no
matter what even if tomorrow or next week there will be new releases.

Peter

[Adam Williamson]

On Sat, 2013-12-28 at 12:21 +0000, Debarshi Ray wrote:
>  On Fri, Dec 27, 2013 at 05:50:18PM -0800, Adam Williamson wrote:
>  > Sigh. Yes, another of these.
>  > 
>  > On 2013-12-18, tracker was bumped to 0.7.0:
>  > 
>  > http://koji.fedoraproject.org/koji/buildinfo?buildID=485698
>  > 
>  > the sonames of libtracker-extract, libtracker-miner and
>  > libtracker-sparql were bumped to 0.18.so.0 (from 0.16.so.0) without
>  > announcement, and without all dependent packages being successfully
>  > rebuilt. At least the following still depend on the old sparql library:
>  
>  The thing with Tracker is that they bump the bump the soname and their
>  pkgconfig file version somewhat gratuitously every six months. 
That sucks, sure. I suggest you get 'em to stop doing that. But as long
as they're doing it...if you bump tracker in Fedora you get to take the
bullet.

>  I built a new tracker because some applications (eg., gnome-photos)
>  specifically want the features in the 0.17/0.18 series.
>  
>  I thought I had rebuilt all the affected packages, but obviously I
>  missed some.
>  
>  > bijiben-0:3.11.1-1.fc21.x86_64
>  > brasero-0:3.11.3-1.fc21.x86_64
>  
>  I thought the round of builds for 3.11.3 would take care of these two, but
>  it looks like bijiben was not built by mclazy and brasero got built before
>  the new tracker hit the trees. :-/
>  
>  > grilo-plugins-0:0.2.9-2.fc21.x86_64
>  > media-explorer-0:0.4.4-5.fc21.x86_64
>  
>  These two need new upstream releases, but the patches are already in
>  Git. 
Then fix 'em. You can't really just leave Rawhide broken for a week.
Well, obviously you *can*, but you really shouldn't.

I did it for you, it took me a couple of hours. If the monkey can do it
in two hours...

>  > What does it take for people to handle soname bumps properly?
>  
>  Barring media-explorer, everything else is part of the GNOME stack so
>  chances of other spins being broken by this was low. 
GNOME is quite an important spin, however. This being broken means
everyone running GNOME on Rawhide gets incomplete updates, and we don't
get nightly GNOME lives. We have been trying to keep Rawhide from
getting broken like this too often for the last few years...

Plus it wasn't just happening on its own; the state of Rawhide when
everyone else bogged off for Christmas was that it was suffering from
this, the borkage in libevdev, the gnome-bluetooth soname bump / library
drop (which affects other desktops), the lack of a
gsettings-desktop-schemas build *and* two SELinux bugs, and that's just
what I noticed because it directly affects me. Cue comedy scenes of the
monkey trying to keep the damn show on the road.

>  My assumption was that sooner or later this would be sorted by the
>  GNOME builds during the 3.11.x cycle. Given that the Fedora and GNOME
>  schedules are quite a bit out of sync these days, I was hoping for
>  some transient rawhide breakage during the Christmas break to go
>  largely unnoticed. 
No, that's not going to happen. People do run Rawhide and we want them
to. It's really not acceptable to break Rawhide, know you're breaking
it, and just go 'meh'. It's going to break sometimes, I recognize that,
but that doesn't mean you can just go around whacking it with hammers
with wilful abandon. There is a duty to at least do the *best you can*
not to break it.

>   I mean if this is the only thing broken in Rawhide
>  at the moment, then I would be more than happy. :) 
Well, I'm not.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Bastien Nocera]

----- Original Message -----
<snip>
>  Plus it wasn't just happening on its own; the state of Rawhide
> when
>  everyone else bogged off for Christmas was that it was suffering from
>  this, the borkage in libevdev, the gnome-bluetooth soname bump / library
>  drop (which affects other desktops), 
library drop? I removed a private shim that gnome-shell used. It was only ever
meant to be used by gnome-shell, or at least internal to gnome-bluetooth.

I'm not sure how the soname bump would affect other desktops either.

[Adam Williamson]

On Mon, 2014-01-06 at 05:52 -0500, Bastien Nocera wrote:
>  ----- Original Message -----
>  <snip>
>  > Plus it wasn't just happening on its own; the state of Rawhide when
>  > everyone else bogged off for Christmas was that it was suffering from
>  > this, the borkage in libevdev, the gnome-bluetooth soname bump / library
>  > drop (which affects other desktops),
>  
>  library drop? I removed a private shim that gnome-shell used. It was only ever
>  meant to be used by gnome-shell, or at least internal to gnome-bluetooth.
>  
>  I'm not sure how the soname bump would affect other desktops either. 
Didn't libgnome-bluetooth-applet go away?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Bastien Nocera]

One hiding in a private directory: /usr/lib64/gnome-bluetooth/ that gnome-shell
explicitely adds to its path. It has no headers and is only usable through introspection.

----- Original Message -----
>  On Mon, 2014-01-06 at 05:52 -0500, Bastien Nocera wrote:
>  > ----- Original Message -----
>  > <snip>
>  > > Plus it wasn't just happening on its own; the state of Rawhide when
>  > > everyone else bogged off for Christmas was that it was suffering from
>  > > this, the borkage in libevdev, the gnome-bluetooth soname bump / library
>  > > drop (which affects other desktops),
>  > 
>  > library drop? I removed a private shim that gnome-shell used. It was only
>  > ever
>  > meant to be used by gnome-shell, or at least internal to gnome-bluetooth.
>  > 
>  > I'm not sure how the soname bump would affect other desktops either.
>  
>  Didn't libgnome-bluetooth-applet go away?
>  --
>  Adam Williamson
>  Fedora QA Community Monkey
>  IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
>  http://www.happyassassin.net
>  
>  --
>  desktop mailing list
>  desktop(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/desktop