Spec URL: http://symetrix.com/~bjohnson/projects/fedora/conduit.spec SRPM URL: http://symetrix.com/~bjohnson/projects/fedora/conduit-0.3.0-1.src.rpm Description: Conduit is a synchronization solution for GNOME which allows the user to take their emails, files, bookmarks, and any other type of personal information and synchronize that data with another computer, an online service, or even another electronic device. Conduit manages the synchronization and conversion of data into other formats. For example, conduit allows you to; * Synchronize your tomboy notes to a file on a remote computer * Synchronize your emails to your mobile phone * Synchronize your bookmarks to delicious, gmail, or even your own webserver * and many more... Any combination you can imagine, Conduit will take care of the conversion and synchronization.
I'll start the review in the mean time package pygoocanvas (bug # 233342) will be imported.
Starting review...
it seem that pygoocanvas isn't included yet in branch, to check mock build. i'll re-try this night or tommorrow.
You can grab the buildsys rpms here: http://buildsys.fedoraproject.org/plague-results/fedora-6-extras/pygoocanvas/0.6.0-2.fc6/ or for F7 here: http://koji.fedoraproject.org/koji/buildinfo?buildID=6421 I'm leaving town May 12 and will not be able to do any updates until May 21 so take your time.
okay, i'll check this out. ;-)
Well, OK - Mock : Built on FC6 en F-7 (i386 and x86_64) OK - Package meets naming and packaging guidelines OK - Spec file matches base package name. OK - Spec has consistant macro usage. OK - Meets Packaging Guidelines. OK - License field in spec matches OK - License is GPL OK - License match extras packaging policy licenses allowed OK - License file is included in package OK - Spec in American English OK - Spec is legible. OK - Sources SHOULD match upstream md5sum: c9ce0b7b4519597b5f480b20c42e04c9 conduit-0.3.0.tar.gz OK - Package has correct buildroot. OK - BuildRequires isn't redundant. OK - %build and %install stages is correct and work. OK - Package has %defattr and permissions on files is good. OK - Package has a correct %clean section. OK - Package is code or permissible content. OK - Packages %doc files don't affect runtime. OK - Package has no duplicate files in %files. OK - Package doesn't own any directories other packages own. OK - Changelog section is correct. OK - Should function as described. OK - Should package latest version ------------------------------------------------ Rpmlint output: ------------------------------------------------ OK - silent on srpm NO - not silent on rpm package E: agistudio zero-length /usr/share/agistudio/template/snddir this error is harmless but need to be fix as the file is h=just a template and contains nothing, it can be remove from pakcage. * From source0 tag you should set %{name}-%{version}.tar.gz instead of static basename and version. to improve future update.
(In reply to comment #6) > ------------------------------------------------ > Rpmlint output: > ------------------------------------------------ > OK - silent on srpm > NO - not silent on rpm package > > E: agistudio zero-length /usr/share/agistudio/template/snddir I think you have the wrong package here :) > * From source0 tag > > you should set %{name}-%{version}.tar.gz instead of static basename and version. > to improve future update. Ok, easy enough. Spec URL: http://symetrix.com/~bjohnson/projects/fedora/conduit.spec SRPM URL: http://symetrix.com/~bjohnson/projects/fedora/conduit-0.3.0-3.src.rpm * Thu May 24 2007 Bernard Johnson <bjohnson> - 0.3.0-3 - change source0 url to use %%name and %%version macros * Sun May 06 2007 Bernard Johnson <bjohnson> - 0.3.0-2 - change gmail icon from internet-mail (tango icon) to email (bluecurve icon) so it will display
Hi, just an outsiders comment on something you may want to consider when imported, I think that the summary should be something like "A synchronization solution for GNOME" My rational is, instead of seeing: Name : conduit Summary : Conduit is a synchronization solution for GNOME on an rpm -qi I'd see: Name : conduit Summary : A synchronization solution for GNOME Essentially it's just redundancy in words, but (surprisingly) makes it easier to read.
NOTE: python-elementtree is NO for F-7+ https://www.redhat.com/archives/fedora-devel-list/2006-December/msg00250.html https://www.redhat.com/archives/fedora-devel-list/2006-December/msg00279.html
(in reply to comment #9) hi Mamoru, could you be more explicit, cause for now, the only reason for why it isn't included is just because the version 1.2.6-5 requires python-abi-2.4 which is not included/released yet. note that many of other package (such as alacarte) require python-abi-2.4 and hasn't been remove from repository.
(In reply to comment #10) Perhaps I don't understand what you want to say, however for F-7 and FCC-devel, there is no pythoon-elementtree rpm and no package provides python-elementtree. cElementTree.so module in python-elementtree has been renamed to _elementtree.so module in python rpm (F7 python is 2.5) and to use _elementtree, some code change will be perhaps needed for conduit. ------------------------------------------ [tasaka1@localhost ~]$ rpm -qf /usr/lib/python2.5/lib-dynload/_elementtree.so python-2.5-12.fc7 ------------------------------------------
(In reply to comment #8) > I think that the summary should be something like "A synchronization solution > for GNOME" Noted to be fixed for next release. (In reply to comment #11) > Perhaps I don't understand what you want to say, > however for F-7 and FCC-devel, there is no pythoon-elementtree > rpm and no package provides python-elementtree. If I understand the thread you pointed to, I should be able to: %if 0%{?fedora} && "%fedora" < "7" Requires: python-elementtree %endif > cElementTree.so module in python-elementtree has been > renamed to _elementtree.so module in python rpm > (F7 python is 2.5) and to use _elementtree, some code change > will be perhaps needed for conduit. I had a short conversation with the developers and they indicated that it was developed with 2.5 in mind: <Jc2k> [0x100] yes, we are developing on Feisty which has python 2,5 as default. <Jc2k> elementtree is identical on both 2.4 and 2.5, but the include is from a different area - so we have try except clauses to pull in the correct version <Jc2k> any changes have not impacted us, tho feisty devs indicated that all we needed to change was the include.
I have not checked in detail, however this seems to work on python 2.5 when I drop Requires: python-elementtree (on FC-devel, almost equal to F-7)
(In reply to comment #12) > %if 0%{?fedora} && "%fedora" < "7" > Requires: python-elementtree > %endif I'm not sure if this is the best way to do it. I think you may want to consider building your cases around the dist macro in the buildsystem. Or you can forgo the use of if statements altogether if you are willing to maintain different specfiles for different branches. You can first submit the necessary specfile that works for F-7 and development without the elementree requires and making sure the python requirement is versioned such that python >= 2.5. Once past review you build agaimst development, then against F-7 using this submitted specfile. Then after the development and F-7 packages are built, you can put a modified spec in the FC-6 and older branches which requires python 2.4 and python-element tree. -jef
(In reply to comment #14) > (In reply to comment #12) > > %if 0%{?fedora} && "%fedora" < "7" > > Requires: python-elementtree > > %endif > > I'm not sure if this is the best way to do it. +1 > Once past review you build agaimst development, then against F-7 using this > submitted specfile. Then after the development and F-7 packages are built, you > can put a modified spec in the FC-6 and older branches which requires python 2.4 > and python-element tree. I think this, it's a better approach but... note that some user work with python-2.5 on fc-6 maybe think about setting up obsolete packages action (?)
Avoid using an obsoletes. Obsoletes should really only be used if the package name changes are if the package is re-divided into subpackages. If people recompile python2.5 for themselves then its their responsibility to make sure all the python modules they use will continue to work in their non-fedora packaged python install. If people pull python2.5 from f7 or development, then they should pull updates for the python based software as well to ensure that the python2.4 to python2.5 transition works for everything. As a maintainer you should be concerned with making sure the update paths for the rpm packages from fedora release to fedora release work. Well thoughtout use a the dist macro in the release field may help keep the update paths in order even if the spec files are divergent. -jef
(In reply to comment #14) > (In reply to comment #12) > > %if 0%{?fedora} && "%fedora" < "7" > > Requires: python-elementtree > > %endif > > I'm not sure if this is the best way to do it. > > I think you may want to consider building your cases around the dist macro in > the buildsystem. Can you explain further how this is better handled by dist macros? Are you talking about using something like: %{?fc6: Requires: python-elementtree} > Or you can forgo the use of if statements altogether if you are willing to > maintain different specfiles for different branches. You can first submit the > necessary specfile that works for F-7 and development without the elementree > requires and making sure the python requirement is versioned such that python >= > 2.5. When at all possible, I'd rather maintain the same spec file across multiple branches, especially when those changes are small and can be easy conditionalized.
Spec URL: http://symetrix.com/~bjohnson/projects/fedora/conduit.spec SRPM URL: http://symetrix.com/~bjohnson/projects/fedora/conduit-0.3.1-1.fc7.src.rpm * Fri Jun 08 2007 Bernard Johnson <bjohnson> - 0.3.1-1 - v 0.3.1 - use disttag macros to require python-elementtree when required - tidy summary to be easier to read - remove icon substitution, no longer needed - remove fixup of Categories in .desktop file
Additionnal review : OK - fixed python-elementree (no)required package OK - Rebuild in mock for this updated release (x86_64) [FC-6 and F-7] NO - Desktop files need fix. == issue == Category "Application" should be remove from desktop file categories. Just use --remove-category flag to do so.
Spec URL: http://symetrix.com/~bjohnson/projects/fedora/conduit.spec SRPM URL: http://symetrix.com/~bjohnson/projects/fedora/conduit-0.3.1-2.fc7.src.rpm * Mon Jun 11 2007 Bernard Johnson <bjohnson> - 0.3.1-2 - remove Application from desktop file category
Additional fix has been done. Successfully rebuilt in mock with no rpmlint errors. ============== ** APPROVED ** ==============
New Package CVS Request ======================= Package Name: conduit Short Description: A synchronization solution for GNOME Owners: bjohnson Branches: FC-6 F-7 InitialCC:
Ooops, forgot the flag. New Package CVS Request ======================= Package Name: conduit Short Description: A synchronization solution for GNOME Owners: bjohnson Branches: FC-6 F-7 InitialCC:
cvs done.
Thanks for the review.
Package Change Request ====================== Package Name: conduit Updated Fedora CC: john.carr.uk
We can't currently add arbitrary email addresses to bugzilla. :( If they have a fedora-account system account linked to that email address we can add them by their fedora account name. Please feel free to reset the fedora-cvs flag if they have a fedora account system account we can add.