[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: disco

Hi Niels,

Thank you for reviewing this package.

On Mon, Oct 11, 2010 at 10:13 PM, Niels Thykier <niels@thykier.net> wrote:
> Hash: SHA256
> On 2010-10-06 20:47, Janos Guljas wrote:
>> Dear mentors,
>> I am looking for a sponsor for my package "disco".
>> * Package name    : disco
>>   Version         : 0.3.1-1
>>   Upstream Author : Ville Tuulos <tuulos@gmail.com>
>> * URL             : http://github.com/tuulos/disco/downloads
>> * License         : GPL-2+
>>   Section         : admin
>> It builds these binary packages:
>> disco-doc  - A distributed computing framework - documentation
>> disco-master - A distributed computing framework - master
>> disco-node - A distributed computing framework - node
>> python-disco - A distributed computing framework - client python module
>> python-discodb - An efficient, immutable, persistent mapping object Disco
>> python-discodex - Distributed indices for Disco
>> [...]
>> Kind regards
>>  Janos Guljas
> Hi
> Thanks for considering to contribute to Debian, your help is much
> appreciated. :)
> While I am not a python/erlang/etc. packager, I did a small review of
> your package. It is quite possible that I missed some issues that a
> second reviewer will find (particularly if said review knows anything
> about packaging python or erlang).
> That aside, here is what I got:
> You got two license files in
>  contrib/discodex/lib/discodex/restapi/
>  master/src/mochiweb/
> which mentions a copyright holders and/or licenses not mentioned in
> d/copyright. Their presence implies that the respective subdirectories
> are copyrighted and licensed as described in those license files (unless
> individual files in those directories state otherwise).

Hm, licensecheck did not pointed them out, and I didn't do manual
check for licences. Thanks, they are in debian/copyright file now.

> Why do disco-master Pre-Depends on python-disco? I see nothing in the
> preinst script that suggests that python-disco must be present before
> disco-master is unpacked.

Python module "disco" is needed for starting python-master.
Python-setuptools on disco python module must be triggered before
running /etc/init.d/disco-master start, which is done after installing
python-disco. Trying to start disco-master before configuring
python-disco package will fail.

> There is a reference in preinst disco-master and disco-nodes to
>  /etc/init.d/disco-node
> but neither of them appears to install that script.

Yes, that was left because upstream packaging is using that. It seems
deprecated, and I'll remove references.

> Is disco-master really an arch:any package? It appears to only contain
> image files, javascript, python scripts and html files?

Hm, yes, you are right. My mistake.

> I am not much of a Python packager, but I suspect you should not be
> getting this warning.
> dpkg-deb: warning: 'debian/$pkg/DEBIAN/control' contains user-defined
> field 'Python-Version'

I believe that this filed is here because of XB-Python-Version under
debian/control. Debian Python Policy requires that filed

> Probably you want X-Python-Version or XS-Python-Version (check the
> Debian Python documentation or with the Python Team).

I'll see with them about that.

> It fails to build from source if Build-Depends-Indep are not satisfied
> when dpkg-buildpackage is invoked with -B:
> [...]
> sphinx-build -b html -d .build/doctrees   . .build/html
> make[2]: sphinx-build: Command not found
> [...]
> This is how auto-builders will build your package. As I recall the
> debian-policy is disagreeing with reality here. I believe there is an
> attempt to make these two agree, but for now your package must be able
> to build without Build-Depends-Indep when dpkg-buildpackage is passed -B.

Are you suggesting to move references from:
Build-Depends-Indep: python-sphinx, libjs-jquery
to Build-Depends?

With that set, cowbuilder --build disco_0.3.1-1.dsc --buildresult .
--binary-arch is building packages fine. But I do not understand the
reason for -B option in autobuild scripts. Do you have some references
that can clarify reason for it. Until now, I tested packages without
--binary-arch build. I see now that this is a requirement.

> Have you contacted (or considered to contact) the python application
> team about team maintaining the package? (See [1] for more info).

Yes, but I am not sure is this belongs to DMPT or PAPT. There are
modules and application packages...

> If you have any questions or comments about the things I mentioned (or
> anything else regarding your package) then feel free to write back.
> ~Niels
> [1] http://wiki.debian.org/Teams/PythonAppsPackagingTeam
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> dYfYnAGYZ6coGVmNVwlz4+SGy+d9JeGRwhHbAhG9pclYo94r3SdD7arTH09BeS+3
> as1ySVEjkxrNmNaz6F58hd9GBCNQQD6AJpn/i0VEHuxwmVr8R8sjfTJdbWiEpMpQ
> 2zwtR3l663C+DpcDwqkwswBrjeMf7RbMFTkx4qgZg/ZkiimpbjdRuuZnpKneuxzM
> HONBMbdtsPOEve+kjNgBtI9qUjpQRW2Lu87GSUa4EtqfPDi5wuyL0zJk1Uc8vKCw
> 5dOR7Bx7zbAHw2PtSg+JncZnwOVXj8KUKjFEOQgflD0pNyDl8yD7zVLgocPkGNAY
> 4UddlmjorGOr0+74oTwuo7P14pR19NEkBiXG2NIwoBHMQHTg5sUqN4uRw9ig+Stw
> 76fJj1nxgXhyhZ0sdTNIYABUk4ArRCNIUA/pJO/0KSaZYbbDpBAL5LSP7d0ot5n8
> AKZU0j59Yvw5P0+ZH00Gkp4hrfwg46DbXQpfUICNfVEoKabjvChCgpLKQw8jikNm
> AQW8YjWRUzpRpTtqKpSTQhkm5yKCn9ekfYwIii9X641QC1torRjR/Ii2UIyDRxNh
> pbzE7NNEr/BXcaBVJjhhQwEwXvn+VcZ37TSzXYZsnVscS5WR+MZiZ0dXQ2CyfRTS
> D3Jg6gVYBkWVzILCfc3C
> =rSvV

Janoš Guljaš

Reply to: