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?
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
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
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.
----- 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.
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?
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
desktop@lists.fedoraproject.org