Mailinglist Archive: opensuse-buildservice (153 mails)

< Previous Next >
Re: [opensuse-buildservice] bogofilter-sqlite (was Re: new package based on the existing one)

On November 29, 2014 6:49:21 AM EST, Gour <gour@xxxxxxxxxxxx> wrote:
On Sat, 29 Nov 2014 08:52:33 +0100
Johannes Kastl <mail@xxxxxxxxxx> wrote:

Thank you all for the help.

If you want to modify a package (e.g. do a version update) and want
get these changes into the repository/project where the package is
from, then branch is your friend.

Otherwise, as the others said, osc copypac creates a completely
independent package, that has the same state and history as the
package you copy from.

I want(ed) to create new package bogofilter-sqlite which is based on
bogofilter but uses Sqlite3 database as storage back-end instead of
default 'db' one.

I did as advised and here is the package which works for me - I'm using
it with Claws-mail with its bogofilter plugin.

Result is here:

=> "Opensuse-factory" is no longer the preferred testing repo name. Drop it
and add opensuse-tumbleweed. (Only announced a couple weeks ago, so most
projects still use opensuse-factory, including mine, but you might as well
start off with the new nomenclature).

=> On the WebUI near the build results you will find rpmlint results.

The first 2 complaints you should fix before moving on.

- change *.changes and *.spec to be named after the new package name.

mv ... ...
osc ar
osc commit

- do you really need to include "install" in the doc set?

Fyi: just because the old package has rpmlint errors doesn't mean your new
package should duplicate them.

First I was changing spec file and submitting via web, then I did build
package locally and commit.

I try to do a local build of everything before I commit. I only locally build
for opensuse-factory (I mean opensuse-tumbleweed) typically, then I commit
working changes to OBS to verify the other distros I care about build correctly.

Please, advice/correct me!!

No need to tell, but I'd like that bogofilter ends up in openSUSE since
I was using the same package in FreeBSD
(, in Arch Linux
( as well in
Debian Sid ( from
where did I migrate to SUSE.

Opensuse is a do-apoly - those that do decide.

If you are willing to do the packaging work and commit to maintaining a package
for the lifecycle of a release, then there are only 3 hurdles to overcome:

- technical: does the packaging meet the opensuse guidelines? Does the package
itself work?

- legal: is the licensing either open source? If not, can a legal right to
distribute be arranged? Also, is the package legal to distribute under both US
and German law. German law prohibits pure hacking tools, so somethings legal
in most countries are not allowed in opensuse. An example is metasploit; it
would be a difficult sell to the release team to include it in factory, but it
is legally distributed in the US.

- security - some packages require a security review. I don't know when this
is required/not required but I've got a package going through a security review
now (my first). It won't be submitted to factory until that is complete. <>. Probably needed because
it reaches out to Google during setup.


Sent from my Android phone with K-9 Mail. Please excuse my brevity.
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-buildservice+owner@xxxxxxxxxxxx

< Previous Next >