[opensuse-kde] presentation and a request
Hi! I'm Pedro Lopez-Cabanillas from Barcelona, Spain. I'm an openSUSE user, packager and KDE developer. My build service home project is 'home:plcl'. I'm packaging my own MIDI related applications: KMid2, KMetronome, KMidimon, aseqmm and VMPK. I would like to join the KDE4:Community project, and ask your opinions about that programs, specially about KMid2 because it is the newest one and it is being developed at KDE/playground SVN repository. I think it is stable enough, but maybe it is a better candidate for the KDE4:Playground project? Regards, Pedro -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
On Wednesday 16 December 2009 17:00:02 Pedro Lopez-Cabanillas wrote:
I'm Pedro Lopez-Cabanillas from Barcelona, Spain. I'm an openSUSE user, packager and KDE developer. My build service home project is 'home:plcl'. I'm packaging my own MIDI related applications: KMid2, KMetronome, KMidimon, aseqmm and VMPK.
Hi Pedro, welcome to the team. Since you're packaging your own apps, have you considered also packaging for other distros using the Build Service too? We can help you tweak your specfiles for other distros, or see Lubos' blog [1] If you have seen Frank Karlitschek's latest blog you'll know that you can now automatically export your Build Service results to kde-apps.org to get them a wider user base.
I would like to join the KDE4:Community project, and ask your opinions about that programs, specially about KMid2 because it is the newest one and it is being developed at KDE/playground SVN repository. I think it is stable enough, but maybe it is a better candidate for the KDE4:Playground project?
The rules governing when a package is suitable for Playground and when for Community are not black and white. Generally, if you have made releases of your apps' tarballs then they can go in Community, but if they are still under heavy development they should stay in Playground until they stabilise. A few comments to improve your packages: Package naming - it's conventional to use lower case names for your packages (even the Build Service packages, when the specfile creates lower case rpms) eg kmetronome, kmidimon, if only because your packages will appear with other kde packages in a case-sensitive sort. CamelCase package names are generally a sign of delusions of grandeur, eg NetworkManager. You can rename a package by copying it with osc copypac and then delete the old package. From the rpmlint reports: aseqmm: Only the package containing the shared library needs the library major version as a suffix. I suggest: libaseqmm0 (libaseqmm0.so.0*) libaseqmm-devel (headers) aseqmm (programs, other files like README) aseqmm-debug* kaseq: the "RPMLINT report" in the build log is clear here - tag documentation with %doc in the %files section, and fix your .desktop files or the apps may not show up in the menus where you expect. KMetronome: %kde4_runtime_requires needed HTH Will [1] http://www.kdedevelopers.org/node/3994 [2] http://blog.karlitschek.de/2009/12/opensuse-buildservice-integration.html -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
On Thursday, December 17, 2009, Will Stephenson wrote:
On Wednesday 16 December 2009 17:00:02 Pedro Lopez-Cabanillas wrote:
I'm Pedro Lopez-Cabanillas from Barcelona, Spain. I'm an openSUSE user, packager and KDE developer. My build service home project is 'home:plcl'. I'm packaging my own MIDI related applications: KMid2, KMetronome, KMidimon, aseqmm and VMPK.
Hi Pedro, welcome to the team.
Since you're packaging your own apps, have you considered also packaging for other distros using the Build Service too? We can help you tweak your specfiles for other distros, or see Lubos' blog [1] If you have seen Frank Karlitschek's latest blog you'll know that you can now automatically export your Build Service results to kde-apps.org to get them a wider user base.
Thank you very much for your message and pointers. I would like to create packages for xUbuntu and other distros, but I have only (little) experience in RPM packaging. I will try, though. I'm looking to Lubos' project as a model to learn.
I would like to join the KDE4:Community project, and ask your opinions about that programs, specially about KMid2 because it is the newest one and it is being developed at KDE/playground SVN repository. I think it is stable enough, but maybe it is a better candidate for the KDE4:Playground project?
The rules governing when a package is suitable for Playground and when for Community are not black and white. Generally, if you have made releases of your apps' tarballs then they can go in Community, but if they are still under heavy development they should stay in Playground until they stabilise.
KMid2 heavy development has finished, at least for Linux. I've planned backends for other platforms, and there is still a kpart pending for Konqueror integration, but the program released as 0.1 should be usable enough for most users, I hope. I will release a 0.1.1 update soon, but with very few changes.
A few comments to improve your packages:
Package naming - it's conventional to use lower case names for your packages (even the Build Service packages, when the specfile creates lower case rpms) eg kmetronome, kmidimon, if only because your packages will appear with other kde packages in a case-sensitive sort. CamelCase package names are generally a sign of delusions of grandeur, eg NetworkManager. You can rename a package by copying it with osc copypac and then delete the old package.
I am thinking about creating several sub-projects: * qt4 for my Qt4-only based packages: vmpk and aseqmm * kde for the KDE4 packages: KMid2, KMetronome and KMidimon * kde3 for Kaseq, which is not yet ready for KDE4 migration What do you think? While moving the packages from the old to new locations, they would be properly renamed as well.
From the rpmlint reports:
aseqmm: Only the package containing the shared library needs the library major version as a suffix. I suggest: libaseqmm0 (libaseqmm0.so.0*) libaseqmm-devel (headers) aseqmm (programs, other files like README) aseqmm-debug*
I would like to add a -doc package for the doxygen generated documentation which is not packaged right now. What name would be better? libaseqmm-doc?
kaseq: the "RPMLINT report" in the build log is clear here - tag documentation with %doc in the %files section, and fix your .desktop files or the apps may not show up in the menus where you expect.
This is a KDE3 service executable, with DCOP interface. There are several scripts, which also depend on Kommander. I'm not sure what to do with it. I will fix the spec for now.
KMetronome: %kde4_runtime_requires needed
I will add it, and thanks again for your advice. Regards, Pedro -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
On Thursday 17 December 2009 15:41:58 Pedro Lopez-Cabanillas wrote:
On Thursday, December 17, 2009, Will Stephenson wrote:
On Wednesday 16 December 2009 17:00:02 Pedro Lopez-Cabanillas wrote: Package naming - it's conventional to use lower case names for your packages (even the Build Service packages, when the specfile creates lower case rpms) eg kmetronome, kmidimon, if only because your packages will appear with other kde packages in a case-sensitive sort. CamelCase package names are generally a sign of delusions of grandeur, eg NetworkManager. You can rename a package by copying it with osc copypac and then delete the old package.
I am thinking about creating several sub-projects: * qt4 for my Qt4-only based packages: vmpk and aseqmm * kde for the KDE4 packages: KMid2, KMetronome and KMidimon
Is there a reason why these should be separate? I would combine them and set various KDE4:* repositories eg vanilla 11.2, Factory:Desktop, etc.
* kde3 for Kaseq, which is not yet ready for KDE4 migration
good idea, base on KDE:KDE3 repos.
What do you think? While moving the packages from the old to new locations, they would be properly renamed as well.
From the rpmlint reports:
aseqmm: Only the package containing the shared library needs the library major version as a suffix. I suggest: libaseqmm0 (libaseqmm0.so.0*) libaseqmm-devel (headers) aseqmm (programs, other files like README) aseqmm-debug*
I would like to add a -doc package for the doxygen generated documentation which is not packaged right now. What name would be better? libaseqmm-doc?
libaseqmm-doc if it is specific to the library, otherwise aseqmm-doc cheers Will -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
On Thursday, December 17, 2009, Will Stephenson wrote:
On Thursday 17 December 2009 15:41:58 Pedro Lopez-Cabanillas wrote:
I am thinking about creating several sub-projects: * qt4 for my Qt4-only based packages: vmpk and aseqmm * kde for the KDE4 packages: KMid2, KMetronome and KMidimon
Is there a reason why these should be separate? I would combine them and set various KDE4:* repositories eg vanilla 11.2, Factory:Desktop, etc.
Not really. Indeed, the three KDE4 programs are using aseqmm. Right now they are building a static version of the library, but soon they are going to depend on the shared library. I don't know if it would be possible to build packages on a sub-project depending on a package on a different sub-project? Regards, Pedro -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
On Thursday 17 December 2009 17:21:09 Pedro Lopez-Cabanillas wrote:
Not really. Indeed, the three KDE4 programs are using aseqmm. Right now they are building a static version of the library, but soon they are going to depend on the shared library. I don't know if it would be possible to build packages on a sub-project depending on a package on a different sub-project?
Sure, this is what you are doing when you add a repository to a project; the Buildrequires: for that repository are searched using the packages in that repository. So you could have (not that I think you need this in your case) home:plcl:qt (containing aseqmm) - repo: KDE:KDE4:Factory:Desktop/openSUSE_11.2 home:plcl:kde (containing kmid, kmetronome etc) - repo: home:plcl:qt/KDE:KDE4:Factory:Desktop/openSUSE_11.2 Will -- Will Stephenson, openSUSE Team SUSE LINUX Products GmbH - Nürnberg - AG Nürnberg - HRB 16746 - GF: Markus Rex -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
On Friday, December 18, 2009, Will Stephenson wrote:
On Thursday 17 December 2009 17:21:09 Pedro Lopez-Cabanillas wrote:
Not really. Indeed, the three KDE4 programs are using aseqmm. Right now they are building a static version of the library, but soon they are going to depend on the shared library. I don't know if it would be possible to build packages on a sub-project depending on a package on a different sub-project?
Sure, this is what you are doing when you add a repository to a project; the Buildrequires: for that repository are searched using the packages in that repository.
So you could have (not that I think you need this in your case)
home:plcl:qt (containing aseqmm) - repo: KDE:KDE4:Factory:Desktop/openSUSE_11.2
Thanks. Of course, I see no advantage in separating the sub-projects for Qt4 and KDE4 applications when the Qt4 repository depends on KDE4. So, I've created KDE4 and KDE3 sub-projects, as you suggested. I've tried (and failed) to build vmpk and kaseq for Fedora and Mandriva, following some directions from http://en.opensuse.org/Build_Service/cross_distribution_package_how_to I don't have enough information to even know the name of the required build dependencies. Regards, Pedro -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
participants (2)
-
Pedro Lopez-Cabanillas
-
Will Stephenson