new bcfg2 dep python-profiler is non-free

[dclark]

r5389 added a .deb packaging dep on python-profiler based on a dep in bcfg2-server code.

python-profiler is not free software:

Ubuntu

As shown at ​http://packages.ubuntu.com/search?keywords=python-profiler python-profiler is in multiverse, which is not enabled in default ubuntu installs, and is described like this:

"multiverse" component

The "multiverse" component contains software that is "not free", which means the licensing requirements of this software do not meet the Ubuntu "main" Component Licence Policy.

The onus is on you to verify your rights to use this software and comply with the licensing terms of the copyright holder.

This software is not supported and usually cannot be fixed or updated. Use it at your own risk.

Debian

As shown at ​http://packages.debian.org/search?keywords=python-profiler python-profiler is in non-free

The free packages go into main; the non-free ones into non-free, and the free ones which depend on non-free ones into contrib.

Discussion

I'm not going to comment on legal / ethical / moral issues at the moment, but from a sys admin annoyance POV this means that users running Debian and Ubuntu are unable to install bcfg2-server in a default configuration, and users of distributions like Trisquel and gNewSense that do not distribute any nonfree software will be completely unable to install it.

Relevant external discssion looks like:

• profile.py has non-free license ​http://lists.debian.org/debian-legal/2005/02/msg00103.html
• profile.py has non-free license - ​http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=293932

The best overall writeup of the problem seems to be at ​http://bugs.gnewsense.org/Bugs/00345

It looks like there is a project to replace with a freedom-respecting version at: ​http://savannah.nongnu.org/projects/pyprof

It's marked as beta, last updated 22 Aug 2006. In a 2008 thread the author recommends against using it.

There is a more recent project at: ​http://sourceforge.net/projects/pyprof/develop (​code) that includes threading support, but is marked as being alpha.

The most recent useful answer looks like in ​http://www.mail-archive.com/[email protected]/msg04552.html

> the python-profile is in non-free, so what free tool do you use for
> profiling your python programs? There is cProfile in python2.5, which
> seems to be free, but for showing
> the result I need pstat, which is again non-free. Is there a DFSG free
> way to profile python programs?

I use lsprofcalltree, which fires up KCacheGrind to visualize the
results of profiling from cProfile (aka lsprof).

It looks like there are some details on how to do this at ​http://wiki.sugarlabs.org/go/Development_Team/Performance

[dclark]

r5507 is a workaround for the .deb packaging side of the problem

[dclark]

Based on ​http://docs.python.org/library/profile.html in python 2.5 and later you can just use the new cProfile as a drop-in replacement for profile; cProfile just comes with python 2.5 and later.

It looks like ​http://www.gnome.org/~johan/lsprofcalltree.py can be used as a replacement for pstats.

So a possible next step would be to do the drop-in replacement of profile with cProfile and then replace this code in ./src/sbin/bcfg2-info

stats = pstats.Stats(trace)
stats.sort_stats('cumulative', 'calls', 'time')
stats.print_stats(200)

with something like:

stats = lsprofcalltree.KCacheGrind(trace)
data = open('/tmp/bcfg2.kgrind', 'w+')
stats.output(data)
data.close()

and then prompt the user to use ​KCachegrind to view the profiling data.

[somekool <…>]

can this be backported to 2.4

will the requirement on python 2.4 be preserved for bcfg2-server?

[desai]

I just make the profiling stuff optional in 1.0, so that the python-profiler switch from depends to recommends is correct.

In 1.0.1, we can make the system either use python-profiler or cProfile, which will retain backwards compatibility.

[solj]

Retargetting for 1.1.0 as per desai's request:

13:41 <desai> so for 767 13:41 <desai> that isn't a 1.0.1 thing 13:41 <desai> since that will change up prereqs and the like

[desai]

I think that having profiling as an optional feature is where we will be for the forseeable future; this smells a bit like python ssl circa 2005.