This bug is related to https://bugs.webkit.org/show_bug.cgi?id=28070 It looks like the soup version code tests in config are not correct for the latest soup version with keyring support. However some simple ifdefs make the code base work with common earlier versions. A patch is attached.
Forgot the patch? In any case the required version was bumped to 2.27.91.
So... there's been data loss in bugzilla. Last comment went like: (Jan said) (In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #1) > > > Forgot the patch? In any case the required version was bumped to 2.27.91. > > > > Did you also rev the glib version ? Thats why I submitted a patch since you > > need a newer glib also. > > Well, the glib requirement is implicitly updated when we update the libsoup > one, since you can't have libsoup installed otherwise. We don't usually rely on implicit dependencies like these, or relying on package managers to work out our minimum requirements. -- IMHO there's nothing wrong with it, since it's impossible that you'll go through configure with an old configure. But I'm also fine with bumping the requirements, does not seem like a big deal to me. -- (Jan says) > Enough on this just it would be nice if all the version checks where reliable. > Depending on secondary dependencies in support libraries to get the versions > correct after you already checked is not a good idea. I think we really have to be realistic with our requirements. Depending on latest libsoup AND glib but leaving GTK behind is just a mess. I rather have the dependencies in sync across the glib/gtk stack. -- I think we are being perfectly realistic. Upgrading GTK+ is a pain for some people (embedders), and I don't see how needlessly updating our GTK+ requirement improves the situation in any way, or how it is a mess currently. In any case, I don't even think the reporter was complaining about this, just about relying on other libraries for our actual requirements.
(In reply to comment #2) > So... there's been data loss in bugzilla. Last comment went like: > > (Jan said) > > (In reply to comment #5) > > (In reply to comment #4) > > > (In reply to comment #1) > > > > Forgot the patch? In any case the required version was bumped to 2.27.91. > > > > > > Did you also rev the glib version ? Thats why I submitted a patch since you > > > need a newer glib also. > > > > Well, the glib requirement is implicitly updated when we update the libsoup > > one, since you can't have libsoup installed otherwise. > > We don't usually rely on implicit dependencies like these, or relying on > package managers to work out our minimum requirements. > > -- > > IMHO there's nothing wrong with it, since it's impossible that you'll go > through configure with an old configure. But I'm also fine with bumping the > requirements, does not seem like a big deal to me. > > -- > > (Jan says) > > > Enough on this just it would be nice if all the version checks where reliable. > > Depending on secondary dependencies in support libraries to get the versions > > correct after you already checked is not a good idea. > > I think we really have to be realistic with our requirements. Depending on > latest libsoup AND glib but leaving GTK behind is just a mess. I rather have > the dependencies in sync across the glib/gtk stack. > > -- > > I think we are being perfectly realistic. Upgrading GTK+ is a pain for some > people (embedders), and I don't see how needlessly updating our GTK+ > requirement improves the situation in any way, or how it is a mess currently. > In any case, I don't even think the reporter was complaining about this, just > about relying on other libraries for our actual requirements. buzilla seems to have bugged out. I'd say the solution is for someone with a good build of the head to post a print out of ldd showing all the versions linked given this I should be able to come up with a decent patch focusing on core libraries glib gtk cairo libsoup etc. Other ones like gstreamer are also and issue. I can of course figure it out after the fact doing a bit of forensic version guessing but a simple ldd output would help a lot.
I understand that this bug is now obsolete, please reopen if it's not the case.