[Freeswitch-users] Debian packaging - some questions

Tue Mar 12 18:50:54 MSK 2013

The problem is currently the changelogs are not updated on a regular basis,
we could use some help in the area. If they were updated routinely it
wouldn¹t really be out of day in the tarballs

On 3/12/13 8:45 AM, "Steven Ayre" <steveayre at gmail.com> wrote:

> Debian's policy is to keep the changelog entries pretty short. Debian
> changelogs are frequently just lots of 'Updated upstream version' entries,
> 'Closes bug' entries when there's a Debian bug that's patched because it's not
> fixed upstream yet, and packaging change notes. 'git log' or 'Docs/changelog'
> would be too verbose. The correct thing to do according to Debian policy would
> be to have a short 'Updated upstream version' entry and ship the
> docs/ChangeLog file so a more complete history can be found in the doc folder.
> 
> freeswitch/build/next-release.txt is pretty good at generating a version for
> Git versions, and I'd say sufficient.
> 
> The issue for me is specifically when tarball releases are rolled. I believe
> there's a script that's run to generate them? Could that update the
> debian/changelog file too? Submitting ChangeLog entries against a tarball
> won't work unless the developers are willing to recreate the tarball. If it
> only gets committed to Git then it's not going to make it into a tarball until
> the next release, at which point it'll be out of date.
> 
> -Steve
> 
> 
> 
> 
> On 12 March 2013 14:37, Ken Rice <krice at freeswitch.org> wrote:
>> There are 2 change logs already that can be used to update debian/changelog
>> 
>> 1. git log  (yes I know not really a changelog but it can be derived from
>> there) 
>> 2. docs/ChangeLog this is the main changelog. Its not always 100% up to date
>> but its there
>> 
>> If you wish to contribute patches to the ChangeLog please do so they are
>> welcomed the main committers don¹t always have time to update these things...
>> 
>> One of the biggest things the project as a whole needs is dedicated
>> documenters that will help with these things.
>> 
>> K
>> 
>> 
>> 
>> On 3/12/13 7:15 AM, "Steven Ayre" <steveayre at gmail.com
>> <http://steveayre@gmail.com> > wrote:
>> 
>>> Another big problem you're likely to get is that pbuilder expects
>>> debian/changelog to be kept updated. That's not practical for the number of
>>> commits Git gets, hence generating a new entry from next-release.txt + the
>>> date.
>>> 
>>> IMO the release tarballs should get the debian/changelog updated for version
>>> releases - there is a Jira on
>>> that: http://jira.freeswitch.org/browse/FS-4778
>>> 
>>> -Steve
>>> 
>>> 
>>> 
>>> 
>>> On 12 March 2013 12:59, Steven Ayre <steveayre at gmail.com
>>> <http://steveayre@gmail.com> > wrote:
>>>>> The second problem is that the build resulted in nearly 100 different
>>>>> *.deb files This also poses somewhat of an annoyance in automated
>>>>> deployment environments, for example saltstack, where the configuration
>>>>> would have to list each individual FreeSWITCH module. It also feels very
>>>>> untidy. I understand that certain packages (such as libfreeswitch,
>>>>> libfreeswitch-dev, freeswitch-server etc) should be separated. But having
>>>>> a package for each module, the only use I could think of for this, would
>>>>> be if the Debian package compiles absolutely every module possible, and is
>>>>> then linked dynamically, rather than compiled static. This means
>>>>> enabling/disabling modules would be a matter of simply adding/removing a
>>>>> package. However I'm not entirely convinced if this is what it is doing..
>>>>> when compiling absolutely every package possible, FreeSWITCH will usually
>>>>> fail to compile, due to collision etc.
>>>> 
>>>> That's exactly what it's trying to do. It attempts to build every package,
>>>> allowing you to install only what you need.
>>>> 
>>>> Modules are created as .so packages that are loaded dynamically when
>>>> FreeSWICH loads the module. They're all linked against the shared
>>>> libfreeswitch library which provides the core API. Modules such as
>>>> mod_sofia link statically against that library (so libsofia is in
>>>> mod_sofia.so not freeswitch itself). Any system libraries used may be
>>>> linked by the module dynamically (libjpeg by mod_spandsp etc).
>>>> 
>>>> If you want to limit the modules built create a debian/modules.conf file
>>>> and list them in there (same format as modules.conf). The
>>>> debian/bootstrap.sh script reads that file and generates the packaging from
>>>> that.
>>>> 
>>>> 
>>>>> 2) Are there any reasons to not be using pbuilder?
>>>> 
>>>> The debian/bootstrap.sh is probably the primary reason it doesn't play well
>>>> with pbuilder - debian tools will often assume the packaging is usable
>>>> without any bootstrap step.
>>>> 
>>>> The bootstrap is necessary for two reasons: 1) it allows the module build
>>>> list to be customised by the builder 2) it makes that list manageable by
>>>> automating the package generation.
>>>> 
>>>> 
>>>> -Steve
>>>> 
>>>> 
>>>> 
>>>> On 12 March 2013 12:44, Cal Leeming [Simplicity Media Ltd]
>>>> <cal.leeming at simplicitymedialtd.co.uk
>>>> <http://cal.leeming@simplicitymedialtd.co.uk> > wrote:
>>>>> Hey,
>>>>> 
>>>>> So today I went to go and create a Debian package for FreeSWITCH using the
>>>>> existing packaging structure;
>>>>> 
>>>>> https://github.com/traviscross/freeswitch/blob/master/debian/
>>>>> http://wiki.freeswitch.org/wiki/Debian_packages_buildscript
>>>>> 
>>>>> The first problem is that neither the helper or the debian/ dir have been
>>>>> configured for compatibility with pbuilder, which makes it untidy/non-sane
>>>>> to place this onto an automated production build system (it also impacts
>>>>> security slightly due to untrusted external code being ran outside of a
>>>>> chroot - but that's possibly an entirely different debate).
>>>>> 
>>>>> The second problem is that the build resulted in nearly 100 different
>>>>> *.deb files This also poses somewhat of an annoyance in automated
>>>>> deployment environments, for example saltstack, where the configuration
>>>>> would have to list each individual FreeSWITCH module. It also feels very
>>>>> untidy. I understand that certain packages (such as libfreeswitch,
>>>>> libfreeswitch-dev, freeswitch-server etc) should be separated. But having
>>>>> a package for each module, the only use I could think of for this, would
>>>>> be if the Debian package compiles absolutely every module possible, and is
>>>>> then linked dynamically, rather than compiled static. This means
>>>>> enabling/disabling modules would be a matter of simply adding/removing a
>>>>> package. However I'm not entirely convinced if this is what it is doing..
>>>>> when compiling absolutely every package possible, FreeSWITCH will usually
>>>>> fail to compile, due to collision etc.
>>>>> 
>>>>> So I have a couple of questions;
>>>>> 
>>>>> 1) Why are the modules separated into individual files? 
>>>>> 
>>>>> 2) Are there any reasons to not be using pbuilder?
>>>>> 
>>>>> I have also CC'd Travis Cross who appears to a major contributor on the
>>>>> Debian packaging code.
>>>>> 
>>>>> Thanks
>>>>> 
>>>>> Cal
>>>>> 
>>>>> _________________________________________________________________________
>>>>> Professional FreeSWITCH Consulting Services:
>>>>> consulting at freeswitch.org <http://consulting@freeswitch.org>
>>>>> http://www.freeswitchsolutions.com
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> Official FreeSWITCH Sites
>>>>> http://www.freeswitch.org
>>>>> http://wiki.freeswitch.org
>>>>> http://www.cluecon.com
>>>>> 
>>>>> FreeSWITCH-users mailing list
>>>>> FreeSWITCH-users at lists.freeswitch.org
>>>>> <http://FreeSWITCH-users@lists.freeswitch.org>
>>>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>>>> http://www.freeswitch.org
>>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> _________________________________________________________________________
>>> Professional FreeSWITCH Consulting Services:
>>> consulting at freeswitch.org <http://consulting@freeswitch.org>
>>> http://www.freeswitchsolutions.com
>>> 
>>> 
>>> 
>>> 
>>> Official FreeSWITCH Sites
>>> http://www.freeswitch.org
>>> http://wiki.freeswitch.org
>>> http://www.cluecon.com
>>> 
>>> FreeSWITCH-users mailing list
>>> FreeSWITCH-users at lists.freeswitch.org
>>> <http://FreeSWITCH-users@lists.freeswitch.org>
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>> http://www.freeswitch.org

-- 
Ken
http://www.FreeSWITCH.org
http://www.ClueCon.com
http://www.OSTAG.org
irc.freenode.net #freeswitch

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20130312/1a50713a/attachment-0001.html 