Bug 711058 - Review Request: akonadi-googledata - Google contacts and calendar akonadi resource
Summary: Review Request: akonadi-googledata - Google contacts and calendar akonadi res...
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: Unspecified
OS: Linux
Target Milestone: ---
Assignee: Rex Dieter
QA Contact: Fedora Extras Quality Assurance
: 551274 (view as bug list)
Depends On:
Blocks: kde-reviews
TreeView+ depends on / blocked
Reported: 2011-06-06 12:22 UTC by Mario Santagiuliana
Modified: 2011-06-24 17:58 UTC (History)
10 users (show)

Fixed In Version: akonadi-googledata-1.2.0-4.fc14
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-06-14 19:01:48 UTC
Type: ---
rdieter: fedora-review+
gwync: fedora-cvs+

Attachments (Terms of Use)

Description Mario Santagiuliana 2011-06-06 12:22:34 UTC
Spec URL:

Description: These are the akonadi resources to sync google calendar events and
contacts. These package use version 1.2.0 of akonadi-googledata:

I create this rpm from spec file specified in this bugreport:

There is another bug on kde that affect some people:

I hope somebody can help me to correct spec file if somethings are wrong.

Comment 1 Nicola Soranzo 2011-06-06 12:35:43 UTC
*** Bug 551274 has been marked as a duplicate of this bug. ***

Comment 2 Mario Santagiuliana 2011-06-06 16:37:09 UTC
I look spec file of suse distro:

They don't use the stable release package but code from svn.
My package resolve some problems but I can't view my calender in kontact (I can create events and view them online but after a refresh I lost them in my kontact view).

I want to update my spec file to respect this comment:

I want to use a new googledata package from svn, like suse distro(maybe newer commit). What do you think?

Comment 3 Dmitrij S. Kryzhevich 2011-06-07 03:45:41 UTC
I'l take it.

Comment 4 Dmitrij S. Kryzhevich 2011-06-07 04:28:56 UTC
1) Drop akonadi Requires as it will be added automaticaly.
2) License is LGPLv2 and any later but no only LGPLv2.
3) If you NOT plan this package will be in EPEl you may be would like to drop BuildRoot tag, buildroot cleaning as first string at %install section, %clean section. See, i.e.:
4) Packages must not own files or directories already owned by other packages. See https://fedoraproject.org/wiki/Packaging/Guidelines#FileAndDirectoryOwnership
%{_kde4_datadir}/akonadi is owned by akonadi package.

Svn. There are to ways you could move, and both are acceptable. First: make patches (or patch if there is one problem) resolving mentioned problems only and include them (or it) into package with release sources. Second: prepare prerelease package with sources from snv. Sure, you need to comfirm it works. See https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Package_Version

Hope you are sponsored already?

Comment 5 Dmitrij S. Kryzhevich 2011-06-07 04:32:12 UTC
And as for notsyncing, may there is a solution http://websvn.kde.org/trunk/extragear/pim/googledata/calendar/gcalresource.cpp?r1=1211814&r2=1211813&pathrev=1211814 that could be applied to release sources?

Comment 6 Mario Santagiuliana 2011-06-07 10:17:47 UTC
Hi Dmitrij,
today I will correct the spec file. I think the better solution is to create a pre-release package from svn version.
Last night I start to understand how to do that on my local system and test it. For now akonadi google resource seems to work better than old stable release.

> Hope you are sponsored already?
No...I don't start the process to become a package mantainer, sorry...
I am in this step:
I need to join the ML devel and inform the upstream developer of thi rpm package. (Today I have some problem with my hosting, I can't use email for a bit).

In response to comment 5: revision 1211814 should be included in the last commit of trunk. I review the code to be sure of this patch!

Thank you for your help!

Comment 7 Dmitrij S. Kryzhevich 2011-06-07 12:15:31 UTC
As you not sponsored, I dropped assigment (I cant be a sponsor), but I'm still here.

(In reply to comment #6)
> Hi Dmitrij,
> today I will correct the spec file. I think the better solution is to create a
> pre-release package from svn version.

Test it with current akonadi version. May be there realy is better to just apply only one patch? But it is all your choice.

> Last night I start to understand how to do that on my local system and test it.

May be you will be interested in utility called "mock".

> I need to join the ML devel and inform the upstream developer of thi rpm
> package.

Upstream information is usfull only after review request is completed or near it.

Comment 8 Rex Dieter 2011-06-07 14:29:58 UTC
wrt to snapshotting or not, I'd recommend using the release tarball for pkg review purposes, and postpone adding patches or using snapshots until after this is fully reviewed and imported into git.

Regardless, I'd be happy to finish reviewing this and be your sponsor.

Comment 9 Mario Santagiuliana 2011-06-07 15:42:09 UTC
Thank you Rex and than you Dmitrij,
I will create the new rpm with spec file fix. I will subscribe the ML and follow the steps to become the package mantainer.

I will create new version of this package from svn trunk and I will post new things here ok?

P.S. thanks Dmitrij, I created the packages for other architecture using mock ;)

Comment 10 Mario Santagiuliana 2011-06-07 20:33:05 UTC
Hi to all,
In response to comment 4:
1) Done;
2) Done;
3) Remove, I use just Fedora, I can't looking for EPEL. But it needed to leave DESTDIR in make install to compile without error;
4) Remove %{_kde4_datadir}/akonadi but I don't understand...How can I understand which files are owner by other rpm files?

Then, generally, how can I undestand where the files of a packages will be placed?
How can I be secure to include all the files installed by a package and don't lost them? And, expecially, don't include file owned by other rpm?

Now, can you check if spec file is correct?

I update all package in my fedorapeople area. I use the last official release of akonadi-googledata, 1.2.0 in respect of Rex comment.

I subscribe devel-announce list and package-review list.

Thank you :)

P.S. to create the package I use mock. I don't use kojij like explain here:

Comment 11 Dmitrij S. Kryzhevich 2011-06-08 03:41:18 UTC
> 3) Remove, I use just Fedora, I can't looking for EPEL. But it needed to leave
> DESTDIR in make install to compile without error;

buildroot var will be generated automaticaly, you not need to specify it manually. That what I meant. DESTDIR still is required with the reference to %{buildroot}

> 4) Remove %{_kde4_datadir}/akonadi but I don't understand...How can I
> understand which files are owner by other rpm files?

Just look at what your package creates, apply common scence, remember that all installed FILES must be described in %files section as well as package's own DIRs. Beside, "yum provides \*/<path>/<to>/<file or dir>" (to query repo) or "rpm -qf /<path>/<to>/<file or dir>" (if package is installed on your system) could give you an answer. In last case path could be relevant.
Note: why "\*/<path>" but not "<path>". Just because yum with "provides" option wants a pattern but not exact string.

> P.S. to create the package I use mock. I don't use kojij like explain here:
> http://fedoraproject.org/wiki/PackageMaintainers/Join#Install_the_Client_Tools_.28Koji.29

You will use koji :) Testing on local machine - mock, including final result into Fedora repo - koji.

One thing with %files section. You not need another %files entry to just add filelist akonadi_gcal_resource.lang.
And in Requires section boost is mentioned. As I undestand, it is not required to be explicitly mentioned either.

Comment 12 Dmitrij S. Kryzhevich 2011-06-08 03:45:49 UTC
Hm. Looks like I have twice give a wgong sugestion that boost is not requires in Requires section. It is required. akonadi-googledata test it is installed.

Comment 13 Mario Santagiuliana 2011-06-08 08:36:53 UTC
To reply in order:
- Ok, I will leave DESTDIR in make install, it is necessary.
- Ok...I hope to do insert all the files! I check them and I think the %files section is correct.
- Ok, I report the %files -f [...] in one string.
- Boost is required, it is also specified in README file.

I try to use koji now :)

Comment 14 Dmitrij S. Kryzhevich 2011-06-08 09:20:52 UTC
Boos is not required as source to build akonadi-googledata, but it is testted to be installed as requirements for akonadi itself. I don't know - why. Ok, boost is required.

Comment 15 Mario Santagiuliana 2011-06-08 09:26:25 UTC
Hi to all, I update the spec file here:

I use koji so the new packages is here:

On my fedorapeople account there are the old packages. Should I update or
remove them?

Boost is not require to build but it is require to execute akonadi-googledata...

Comment 16 Dmitrij S. Kryzhevich 2011-06-08 10:00:47 UTC
1) BuildRoot still defined.
2) Only one source: Source0 -> Source.
3) Mark all changes with spec file into %changelog section. Evry changes. With release tag update. 

Boost. Yes, but akonadi already requires boost. Dependency chain: boost -> akonadi -> akonadi-googledata.

Koji will be *required* as a step to include package into repo, after review will be completed. You can use it for testing and providing additional information and... whatever you need. You can to not use it either, providing spec and srpm files somewhere else, ie fedorapeople. Note: anyway, you still need to place spec file somwhere else but koji.

Comment 17 Mario Santagiuliana 2011-06-08 11:44:03 UTC
Spec file update!

1) Now should be ok, isn't?
2) Change.
3) Ok, i will update the spec file.
4) Remove Boost from require package.

Update all files in my fedorapeople directory. I don't use koji now, I will use it later when the akonadi-googledata packages is ok.

Comment 18 Rex Dieter 2011-06-08 12:46:34 UTC
Thanks for your work so far, I'll take a look today, and start a formal review.

Comment 19 Mario Santagiuliana 2011-06-10 11:45:10 UTC
Thank you Rex. Should I do other things for this package?

Comment 20 Rex Dieter 2011-06-10 12:56:41 UTC
I'm going to be a little more picky than usual, since this is your first package.

comments:  MUST => required fixes before I'll approve, SHOULD => items I'd like to see addressed, but not required if you'd rather not for whatever reason.

Naming: ok 

Sources: ok
483bb82d4492ff20edb64d3d4edc02eb  akonadi-googledata-1.2.0.tar.bz2
thought I would still recommend calling it Source0, even if it's the only one.

Scriptlets: n/a, ok

$ rpmlint *.rp x86_64/*.rpm
^C^C^C^C[rdieter1@math-110 akonadi-googledata]$ rpmlint *.rpm x86_64/*.rpm
akonadi-googledata.src: W: spelling-error %description -l en_US kde -> ked, de, ode
akonadi-googledata.src: W: spelling-error %description -l en_US google -> Google, goggle, googly
akonadi-googledata.src: W: spelling-error %description -l en_US joe -> Joe, hoe, jor
akonadi-googledata.src: W: invalid-license LGPL v2.1
akonadi-googledata.src: W: invalid-license later
akonadi-googledata.src: W: invalid-url Source0: http://libgcal.googlecode.com/files/akonadi-googledata-1.2.0.tar.bz2 HTTP Error 404: Not Found
akonadi-googledata.x86_64: W: spelling-error %description -l en_US kde -> ked, de, ode
akonadi-googledata.x86_64: W: spelling-error %description -l en_US google -> Google, goggle, googly
akonadi-googledata.x86_64: W: spelling-error %description -l en_US joe -> Joe, hoe, jor
akonadi-googledata.x86_64: W: invalid-license LGPL v2.1
akonadi-googledata.x86_64: W: invalid-license later
akonadi-googledata.x86_64: W: no-manual-page-for-binary akonadi_gcal_resource
akonadi-googledata.x86_64: W: no-manual-page-for-binary akonadi_googledata_resource
akonadi-googledata-debuginfo.x86_64: W: invalid-license LGPL v2.1
akonadi-googledata-debuginfo.x86_64: W: invalid-license later
3 packages and 0 specfiles checked; 0 errors, 15 warnings.

most of these are harmless, I'll address license below.

1. MUST:  licensing: not ok, should use
License: LGPLv2+
per http://fedoraproject.org/wiki/Licensing#Software_License_List

2. SHOULD drop useless definition of...  %global kde4_version

I'd recommend using %{_cmake_kde4} macro, instead of %cmake, see  
for an example/template.

4.  SHOULD (getting really picky, this is mostly cosmetic, but...), I personally prefer to put build deps 1 per line like:
BuildRequires: akonadi-devel
BuildRequires: gettext
which makes reading pkg diffs later easier to parse when items are added/removed

5.  SHOULD  even though boost-devel is already pulled in via indirect dependencies (kdepimlibs-devel), this package does explicitly check-for and use it directly, so I'd recommend adding
BuildRequires: boost-devel

6.  SHOULD drop more items that are deprecated (ie, not needed) with recent fedora/rpm releases including:
Group: tag

Comment 21 Mario Santagiuliana 2011-06-10 14:46:17 UTC
1. Change

2. Dropped

3. Change

4. Done

5. Added

6. Removed

And I change source to source0.

Updated packages here:

Can you check the new spec and packages?

Thank you very much!

Comment 22 Rex Dieter 2011-06-10 14:58:26 UTC
close, though only your src.rpm was updated.  :)

I notice now that your
section lacks any 'make' directive, and didn't follow the %{cmake_kde4} template I referenced either.  Please check that again.

Comment 23 Mario Santagiuliana 2011-06-10 15:08:42 UTC
I just update all the files...maybe is a cached problem with the browser?

The build section is:

Should be:


Comment 24 Mario Santagiuliana 2011-06-10 15:12:01 UTC
Sorry, should be:



Comment 25 Rex Dieter 2011-06-10 15:32:53 UTC
that works, but I'd prefer something like:

mkdir -p %{_target_platform}
pushd %{_target_platform}
%{cmake_kde4} ..

make %{?_smp_mflags} -C %{_target_platform}

rm -rf %{buildroot}
make install/fast DESTDIR=%{buildroot} -C %{_target_platform}

to match the template in

Comment 26 Mario Santagiuliana 2011-06-10 16:43:22 UTC
OK, I update all package and spec file:

Hope now is ok :) :)

Comment 27 Rex Dieter 2011-06-13 18:07:23 UTC
Looks like a winner, APPROVED.

Let me know your fas username, and I'll sponsor you.

Comment 28 Mario Santagiuliana 2011-06-13 18:23:15 UTC
Wow :)
thank you Rex, and thank you Dmitrij too :)

My fas uesrname is marionline .

Thank you very much :)

Comment 29 Rex Dieter 2011-06-13 19:26:47 UTC
sponsored, you can now move on to,


and the following steps.

Feel free to stop by on freenode irc, #fedora-kde (or #fedora-devel) channels if you have any questions, or just want to chat.

Comment 30 Mario Santagiuliana 2011-06-14 09:57:10 UTC
New Package SCM Request
Package Name: akonadi-googledata
Short Description: These are the akonadi resources to sync google calendar events and contacts
Owners: marionline
Branches: f14 f15

Comment 31 Gwyn Ciesla 2011-06-14 13:06:05 UTC
Git done (by process-git-requests).

Comment 32 Kevin Kofler 2011-06-14 14:54:52 UTC
FYI, there's now a competing implementation under development:
(but it's probably not ready for production use yet).

Comment 33 Mario Santagiuliana 2011-06-14 16:25:27 UTC
I never seen this package before, I'm writing to him to undestand if is possible to merge the two projects. I think that would be the best solution for users and for the developers. I think that two-three developers on one common projects is best than three developers on three different projects, isn't?

Thank you for your reply, I will push akonadi-googledata in scm.

Comment 34 Rex Dieter 2011-06-14 16:40:34 UTC
collaboration (if possible), for the win, indeed.

Comment 35 Fedora Update System 2011-06-14 18:40:06 UTC
akonadi-googledata-1.2.0-4.fc14 has been submitted as an update for Fedora 14.

Comment 36 Fedora Update System 2011-06-14 18:41:29 UTC
akonadi-googledata-1.2.0-4.fc15 has been submitted as an update for Fedora 15.

Comment 37 Mario Santagiuliana 2011-06-14 18:47:04 UTC
Ok, I submit the package.
Should I close this bug report? Bodhi should do this alone, isn't?

Comment 38 Rex Dieter 2011-06-14 19:12:58 UTC
bodhi will close it once it goes to stable updates.

Comment 39 Fedora Update System 2011-06-24 17:58:07 UTC
akonadi-googledata-1.2.0-4.fc15 has been pushed to the Fedora 15 stable repository.

Comment 40 Fedora Update System 2011-06-24 17:58:36 UTC
akonadi-googledata-1.2.0-4.fc14 has been pushed to the Fedora 14 stable repository.

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