[Kolab-devel] Debian packages, upstream source patching and quilt

[Richard]

Jeroen,

Op donderdag 14 november 2013 23:21:21 schreef Paul Boddie:
> That said, indeed should patches be in format 3.0 (quilt), but here be 
> dragons. OBS-originated dragons, to be precise. Since I said "OBS", I 
> feel I need not go in to any further detail. Suffice it to say we 
> deliberately set everything to format 1.0, and therefore void the use of 
> debian/patches/ (uch! and yuk!).

Did you share your experience with OBS on the OBS emaillist 
(http://lists.opensuse.org/opensuse-buildservice/)?  

As far as I know the OBS developers are willing to explain OBS and are willing 
to listen to feedback and to act on it when the feedback makes sense.  The OBS 
is an important part of Kolab infrastructure and as such it should fit you 
nicely. 

I think that if you make bug reports / feature requests for the items that you 
want to see improve, it will happen in the end.  I'm thinking of the feedback 
you provided last month:
  http://lists.kolab.org/pipermail/devel/2013-October/014706.html

You once stated that you're a fan of multiple people collaborating to achieve 
similar goals, the same is valid for the OBS folks.  
  
Bring your points about OBS to the OBS emaillist or make them bug reports, so 
the OBS developers can do something about it.  
But who am I to tell you this, you know this better than I would anybody else.

-- 
Richard


Op donderdag 14 november 2013 23:27:10 schreef Paul Boddie:
> Hello,
> 
> I finally managed to get pbuilder to build the Development packages for
> Debian Wheezy using various tricks with hooks and a build dependencies
> directory that I will write up in a blog post that should then appear on
> Planet Kolab. (This can save a lot of time: pbuilder isn't quick itself,
> but OBS can take up to 9 minutes on my system to just set up the build
> environment for a single package.) The packages also appeared to install
> cleanly, and I didn't need to use aptitude to navigate a multitude of
> packaging choices - apt-get was good enough - so things certainly seem to
> be going my way.
> 
> I've previously referred to problems with cmake, but these did not occur
> this time round, although since the build environment was Wheezy and not
> Sid there's a chance that something still needs fixing, but I suppose we'll
> deal with that in the future. I didn't bother with the 389 packages just
> out of curiosity as to whether the stock Debian packages would be
> sufficient, and it looks as if they are, at least to install Kolab.
> 
> When doing the building I found two packages that seemed to need additional
> packages installed before pbuilder would even get started:
> 
> python-icalendar needed python-setuptools, but since I dislike setuptools
> intensely and won't risk it breaking my system (and since I wasn't building
> inside another chroot), I made a patch to replace its use with distutils
> because what setuptools attempts to do when employed most ambitiously isn't
> really attempted here (and generally isn't relevant in a package building
> situation anyway). In other situations I have tended to patch setup.py files
> to remove setuptools dependencies where the upstream developers could have
> easily used good old distutils, and I don't see any significant problems
> doing so here.
> 
> php-http-request2 needs pkg-php-tools, and I just accepted that because I
> don't run any PHP stuff myself. I imagine that the Debian build system is
> clever enough to have this as some kind of "pre-build" dependency.
> 
> (I noticed that in OBS, the build dependencies are maintained in two places
> - the control file and the .dsc file - so removing python-setuptools as a
> build dependency needed to be done in two places, whereas the .dsc would be
> updated to reflect the control file in a pbuilder-based workflow.)
> 
> Doing patches on upstream sources led me to consider how they are delivered.
> I noticed that there were quite a few packages where I got complaints about
> how the patches should be managed using quilt. I don't know whether this is
> fully supported in OBS, but quilt patches typically reside in
> debian/patches and so could be bundled in the debian.tar.gz file that sits
> in each OBS package directory. When building python-icalendar with a
> modified debian.tar.gz containing patches, OBS seemed to apply such
> patches, but amongst the resulting output files there doesn't seem to be a
> special "debian" patch archive like this...
> 
> python-icalendar_3.4-1.debian.tar.gz
> 
> ...but only a file like this:
> 
> python-icalendar_3.4-1.diff.gz
> 
> I'm sure a lot of the above doesn't really matter, but I know that some
> people prefer recent best practices to be observed, so I thought I should
> investigate whether they can indeed be followed. If it doesn't cause
> inconvenience, I can add quilt patch series to the following packages to
> make Debian happy:
> 
> irony, kolab-freebusy, libkolab, libkolabxml, mozilla-ldap-sdk,
> roundcubemail, roundcubemail-plugin-threadingasdefault
> 
> Paul
> _______________________________________________
> devel mailing list
> devel at lists.kolab.org
> https://lists.kolab.org/mailman/listinfo/devel