[Kolab-devel] Announcing some blog posts for building packages for Debian on OBS

Paul Boddie paul at boddie.org.uk
Mon Oct 28 20:23:44 CET 2013


On Monday 28. October 2013 16.43.12 Torsten Grote wrote:
> 
> While playing with the Debian packages, I also found other issues which I
> reported here:
> 
>    
> https://issues.kolab.org/buglist.cgi?list_id=4126&query_format=advanced&bu
> g_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=packaging%20
> -%20apt%20-%20debian&product=Kolab%20Server

There are certainly a lot of issues there. :-)

> There's now also a tracker bug for issues that still need to be resolved
> before Kolab 3.1 can be officially released for Debian:
> 
>     https://issues.kolab.org/show_bug.cgi?id=728
> 
> The instructions are really easy and work well. If you want to use Kolab on
> Debian, please consider trying them out and contribute back. I see that
> some people already started to:
> 
>    
> https://obs.kolabsys.com/project/show?project=home%3Abillnogo%3Abranches%3
> AKolab%3ADevelopment

I was wondering which project we should be targeting. I see there are "3.1" 
and "Development" projects, and when I tried to build the "Development" 
packages myself there seemed to be some kind of fundamental (non-packaging-
related) build issue, whereas the "3.1" packages didn't exhibit the same 
problems.

If we're fine-tuning the packaging is it best to target "3.1" in order to not 
have to deal with two different variables at the same time, or should it be 
safe to target the "Development" stuff? Also, where do the "Updates" come into 
this?

> When do you? ;)

Actually, I just stumbled across a problem with libkolabxml when building it 
in Debian sid, so I suppose I should figure out how this gets submitted back. 
Another thing I wondered about was the way upstream code patches are 
performed: the Debian tools complain that quilt is the way to apply such 
patches, and I should probably dust off any notes or memories about using 
quilt, but then I also wondered whether the upstream (non-packaging-related) 
code should be "good to go" and not needing to be patched.

Any thoughts on these matters?

Paul


More information about the devel mailing list