Spec URL: http://marionline.fedorapeople.org/packages/SPECS/akonadi-googledata.spec SRPMS URL: http://marionline.fedorapeople.org/packages/SRPMS/ RPMS: http://marionline.fedorapeople.org/packages/RPMS/ Description: These are the akonadi resources to sync google calendar events and contacts. These package use version 1.2.0 of akonadi-googledata: http://code.google.com/p/libgcal/downloads/detail?name=akonadi-googledata-1.2.0.tar.bz2&can=2&q= I create this rpm from spec file specified in this bugreport: https://bugzilla.redhat.com/show_bug.cgi?id=551274 There is another bug on kde that affect some people: https://bugs.kde.org/show_bug.cgi?id=268643 https://bugs.kde.org/show_bug.cgi?id=264861 I hope somebody can help me to correct spec file if somethings are wrong.
*** Bug 551274 has been marked as a duplicate of this bug. ***
I look spec file of suse distro: https://build.opensuse.org/package/view_file?file=akonadi-googledata.spec&package=akonadi-googledata&project=home%3Acgiboudeaux%3AKDE%3AUnstable&srcmd5=fc115bb37500d8cc8f9d9d02954db6f7 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: https://bugzilla.redhat.com/show_bug.cgi?id=551274#c27 I want to use a new googledata package from svn, like suse distro(maybe newer commit). What do you think?
I'l take it.
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.: https://fedoraproject.org/wiki/Packaging/Guidelines#.25clean https://fedoraproject.org/wiki/Packaging/Guidelines#BuildRoot_tag 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?
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?
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: http://fedoraproject.org/wiki/PackageMaintainers/Join#Create_Your_Review_Request 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!
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.
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.
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 ;)
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? http://marionline.fedorapeople.org/packages/SPECS/akonadi-googledata.spec 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: http://fedoraproject.org/wiki/PackageMaintainers/Join#Install_the_Client_Tools_.28Koji.29
> 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.
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.
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 :)
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.
Hi to all, I update the spec file here: http://marionline.fedorapeople.org/packages/SPECS/akonadi-googledata.spec I use koji so the new packages is here: http://koji.fedoraproject.org/koji/taskinfo?taskID=3118664 http://koji.fedoraproject.org/koji/taskinfo?taskID=3118681 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...
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.
Spec file update! http://marionline.fedorapeople.org/packages/SPECS/akonadi-googledata.spec 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.
Thanks for your work so far, I'll take a look today, and start a formal review.
Thank you Rex. Should I do other things for this package?
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 3. MUST I'd recommend using %{_cmake_kde4} macro, instead of %cmake, see http://fedoraproject.org/wiki/SIGs/KDE#Best_Practices 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 and %defattr(...
1. Change 2. Dropped 3. Change 4. Done 5. Added 6. Removed And I change source to source0. Updated packages here: http://marionline.fedorapeople.org/packages/SPECS/akonadi-googledata.spec http://marionline.fedorapeople.org/packages/ Can you check the new spec and packages? Thank you very much!
close, though only your src.rpm was updated. :) I notice now that your %build section lacks any 'make' directive, and didn't follow the %{cmake_kde4} template I referenced either. Please check that again.
I just update all the files...maybe is a cached problem with the browser? The build section is: %build %{cmake_kde4} Should be: %build %{cmake_kde4} make ?
Sorry, should be: %build %{cmake_kde4} %cmake ?
that works, but I'd prefer something like: %build mkdir -p %{_target_platform} pushd %{_target_platform} %{cmake_kde4} .. popd make %{?_smp_mflags} -C %{_target_platform} %install rm -rf %{buildroot} make install/fast DESTDIR=%{buildroot} -C %{_target_platform} to match the template in http://fedoraproject.org/wiki/SIGs/KDE#Best_Practices
OK, I update all package and spec file: http://marionline.fedorapeople.org/packages/SPECS/akonadi-googledata.spec http://marionline.fedorapeople.org/packages/ Hope now is ok :) :)
Looks like a winner, APPROVED. Let me know your fas username, and I'll sponsor you.
Wow :) thank you Rex, and thank you Dmitrij too :) My fas uesrname is marionline . Thank you very much :)
sponsored, you can now move on to, http://fedoraproject.org/wiki/PackageMaintainers/Join#Add_Package_to_Source_Code_Management_.28SCM.29_system_and_Set_Owner 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.
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 InitialCC:
Git done (by process-git-requests).
FYI, there's now a competing implementation under development: http://progdan.cz/2011/06/akonadi-google-resource-0-2 (but it's probably not ready for production use yet).
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.
collaboration (if possible), for the win, indeed.
akonadi-googledata-1.2.0-4.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/akonadi-googledata-1.2.0-4.fc14
akonadi-googledata-1.2.0-4.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/akonadi-googledata-1.2.0-4.fc15
Ok, I submit the package. Should I close this bug report? Bodhi should do this alone, isn't?
bodhi will close it once it goes to stable updates.
akonadi-googledata-1.2.0-4.fc15 has been pushed to the Fedora 15 stable repository.
akonadi-googledata-1.2.0-4.fc14 has been pushed to the Fedora 14 stable repository.