After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 743934 - FTBFS after EDS commit 884fb8d8
FTBFS after EDS commit 884fb8d8
Status: RESOLVED FIXED
Product: folks
Classification: Platform
Component: general
git master
Other Linux
: Normal normal
: Unset
Assigned To: folks-maint
folks-maint
Depends on:
Blocks:
 
 
Reported: 2015-02-03 14:33 UTC by Vadim Rutkovsky
Modified: 2015-02-16 12:21 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
proposed patch (2.48 KB, patch)
2015-02-03 16:56 UTC, Milan Crha
needs-work Details | Review
proposed patch ][ (2.93 KB, patch)
2015-02-03 17:10 UTC, Milan Crha
accepted-commit_now Details | Review
follow-up patch as suggested above (832 bytes, patch)
2015-02-04 07:44 UTC, Milan Crha
accepted-commit_now Details | Review
eds: Update to new EDS address book timeout API (4.62 KB, patch)
2015-02-04 08:29 UTC, Philip Withnall
committed Details | Review
build: Drop outdated BlueZ conditional dependency checks (1.33 KB, patch)
2015-02-04 08:29 UTC, Philip Withnall
committed Details | Review

Comment 1 Vadim Rutkovsky 2015-02-03 14:34:18 UTC
Please revert https://git.gnome.org/browse/gnome-continuous/commit/?id=63b44ca69ebd77f44bac297a78c9b2bcafd610e7 after the issue is fixed
Comment 2 Philip Withnall 2015-02-03 14:38:38 UTC
I’m not really sure this should be fixed in folks: it’s an API break in EDS which has been put in place without a deprecation path. If folks changes to use the new parameter in e_book_client_connect(), we will have to bump our EDS dependency to master, which will cause all sorts of distribution problems.

Milan, why was this change made in EDS without deprecating the old API and introducing the new one in parallel?
Comment 3 Milan Crha 2015-02-03 16:56:32 UTC
Created attachment 296045 [details] [review]
proposed patch

I suggest to use 1 second timeout for the connected state. If the backend in already connected, then it'll mean no problem, the same as when it is not connected, the book will be opened in an offline mode, at least till the credentials are provided by any client. As the Folks is a library, and cannot provide credentials on its own due to no UI, it is a sane default. The backend will claim issues when any operation which requires fully connected state would happen, thus it's a safe default. also, users with stored credentials will not notice any issue. The reason to use 1 second timeout for the connected state is to have also updated internal properties.
Comment 4 Philip Withnall 2015-02-03 17:00:32 UTC
Review of attachment 296045 [details] [review]:

folks’ EDS dependency in configure.ac needs bumping, but I would actually prefer it to compile conditionally, passing in the new parameter iff compiling with the latest version of EDS, and omitting it otherwise.

Other than that, I agree with your reasoning.
Comment 5 Milan Crha 2015-02-03 17:10:40 UTC
Created attachment 296047 [details] [review]
proposed patch ][

You are right, I missed that change.
Comment 6 Philip Withnall 2015-02-03 17:14:20 UTC
Review of attachment 296047 [details] [review]:

++

::: configure.ac
@@ +264,3 @@
 TRACKER_SPARQL_REQUIRED=0.15.2
+EBOOK_REQUIRED=3.13.90
+EBOOK_REQUIRED_FOR_BLUEZ=3.13.90

Can you please do a second commit which drops all the EBOOK_REQUIRED_FOR_BLUEZ machinery, since that version is now the same as EBOOK_REQUIRED?

But you can commit this one first.
Comment 7 Milan Crha 2015-02-04 07:44:09 UTC
Created attachment 296070 [details] [review]
follow-up patch as suggested above
Comment 8 Philip Withnall 2015-02-04 08:28:58 UTC
Review of attachment 296070 [details] [review]:

++

I’ll push both.
Comment 9 Philip Withnall 2015-02-04 08:29:43 UTC
Created attachment 296074 [details] [review]
eds: Update to new EDS address book timeout API

Add a timeout parameter to handle the new EDS authentication process.
This means that folks no longer triggers authentication dialogues from
EDS, which will prevent them popping up unexpectedly (particularly from
GNOME Shell). However, it does mean that external processes using folks
which _do_ want to display authentication dialogues should manually
create an ECredentialsPrompter and use that to display the dialogues.

This bumps the EDS dependency to 3.13.90 unconditionally.
Comment 10 Philip Withnall 2015-02-04 08:29:46 UTC
Created attachment 296075 [details] [review]
build: Drop outdated BlueZ conditional dependency checks

Since our overall EDS dependency is now higher than that needed for the
BlueZ backend, we can drop the conditional EDS version checks which
could previously disable building the BlueZ backend.
Comment 11 Philip Withnall 2015-02-04 08:30:44 UTC
All pushed, thanks Milan.

Attachment 296074 [details] pushed as baa67c2 - eds: Update to new EDS address book timeout API
Attachment 296075 [details] pushed as ef70ba9 - build: Drop outdated BlueZ conditional dependency checks
Comment 12 David King 2015-02-14 15:34:00 UTC
This was released with folks 0.11.0, but there has not been a corresponding evolution-data-server release (3.11.90). This means that 0.11.0 failed to build for Rawhide: http://koji.fedoraproject.org/koji/buildinfo?buildID=611058

Can there be an evolution-data-server release (maybe for Monday, which is for the 3.15.90 release), or is it possible to back out these changes and put out a folks 0.11.1?
Comment 13 David King 2015-02-16 12:21:14 UTC
I see that there has now been an evolution-data-server 3.11.90 release. Thanks!