Join Python Applications Packaging Team
I'd like to join the PAPT to work on the python based 'alot' application. I would be taking over from the previous maintainer who is no longer actively using debian. I'm a DM and I've worked on packaging for 3 other C based projects previously. My alioth username is jljusten-guest. I have read http://python-apps.alioth.debian.org/policy.html and I accept it. But, I do have a question. I had planed to develop the 'alot' package in git, but it appears that the python-apps project uses svn still. Is it required that all python-apps packages use svn? I have uploaded a new version of the 'alot' package to mentors.debian.net, and I think josch agreed to sponsor the package. Thanks, -Jordan signature.asc Description: signature
Join Python Applications Packaging Team
Hi, I'm already member of DPMT and I want to join PAPT. I read http://python-apps.alioth.debian.org/policy.html and i accept it. I would like to work on update of pyflakes, which i need for new flake8 package. Thanks. -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
Re: How to split modules in multiple deb packages
Hi Ioannes, > why would you want to do that? > i mean: what harm comes from shipping the rpi.py file on non-rpi systems? Because only the rpi module requires gpiozero module to work properly, but I cannot put a dependency on gpiozero for the whole package. > is that file exposed to the user or is it just internally used? Exposed to the user. > is the system failing gracefully if it is there but not really usable, > because you are missing hardware? (if so, there is no need to split). Yes, it raises ImportError if the user tries to use a class that needs gpiozero. > is the system failing gracefully if it is missing on systems that would > normally use it? (if not, then splitting could actually be harmful). Yes, same as above. But the user can complain that he/she installed a package that requires gpiozero without having pyhton3-gpiozero in the required list... Bye Simone
Re: How to split modules in multiple deb packages
[Simone Rossetto, 2017-02-21]
> > ("mypackage" is module name which will be shipped in python3-mypackage
> > binary package and "rpi" or "rpi-daemon" is binary package shipping the
> > daemon)
> > [...]
> > if it's one file only (without private modules) you can install directly
> > into /usr/bin/
>
> The file rpi.py is a module of mypackage, not the binary of the
> daemon. The binary will be installed in its own package that requires
> python3-mypackage.
in that case I think shipping rpi.py with other modules in
python3-mypackage with all required dependencies in Recommends or even
Suggests (and Depends of the binary package with the daemon) sounds fine
--
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl www.griffith.cc www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: How to split modules in multiple deb packages
Hi Piotr,
> ("mypackage" is module name which will be shipped in python3-mypackage
> binary package and "rpi" or "rpi-daemon" is binary package shipping the
> daemon)
> [...]
> if it's one file only (without private modules) you can install directly
> into /usr/bin/
The file rpi.py is a module of mypackage, not the binary of the
daemon. The binary will be installed in its own package that requires
python3-mypackage.
Bye
Simone
Re: How to split modules in multiple deb packages
On 2017-02-18 09:16, Simone Rossetto wrote: > One of the module is specific for Raspberry Pi, it adds some > functionalities, but > the daemon itself doesn't require a Pi hardware and can still do its job > without that module even on a Pi. What I want to do is to split the modules > in two deb packages, one with all the modules except rpi.py and one with only > rpi.py (setting the appropriate dependencies, i.e. python3-gpiozero, etc). > > How can I do that? why would you want to do that? i mean: what harm comes from shipping the rpi.py file on non-rpi systems? is that file exposed to the user or is it just internally used? is the system failing gracefully if it is there but not really usable, because you are missing hardware? (if so, there is no need to split). is the system failing gracefully if it is missing on systems that would normally use it? (if not, then splitting could actually be harmful). also, Debian has no notion of "packages only for the Raspberry", as there is no architecture specific to the RPi (only). So most likely you will end up with a package called "mypackage-rpi" that can be installed on any old s390x cpu, creating even more confusion. fgamsdr IOhannes
Re: How to split modules in multiple deb packages
[Simone Rossetto, 2017-02-18]
> Hello everybody, I'm packaging a daemon that I've developed in python3 and I
> need to split the core modules in two deb packages, but I don't now how to do
> that.
>
> One of the module is specific for Raspberry Pi, it adds some
> functionalities, but
> the daemon itself doesn't require a Pi hardware and can still do its job
> without that module even on a Pi. What I want to do is to split the modules
> in two deb packages, one with all the modules except rpi.py and one with only
> rpi.py (setting the appropriate dependencies, i.e. python3-gpiozero, etc).
>
> How can I do that?
you can use this in debian/rules:
("mypackage" is module name which will be shipped in python3-mypackage
binary package and "rpi" or "rpi-daemon" is binary package shipping the daemon)
export PYBUILD_NAME=mypackage
override_dh_auto_install:
dh_auto_install
mv debian/python3-mypackage/usr/bin/rpi debian/rpi-daemon/usr/bin/
(add "/usr/bin/" to debian/rpi-daemon.dirs)
> I can exclude rpi.py module from main package and create a
> python3-mypackage.rpi.install
please don't use "python3-" prefix for packages that do not install
files in /usr/lib/python3/dist-packages/
> file installing rpi.py in /usr/lib/python3/mypackage but I don't think it is
> the right way of doing that.
if it's one file only (without private modules) you can install directly
into /usr/bin/
--
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl www.griffith.cc www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Pending broken links
Hi, > I have noticed that the automatically generated links sent to the BTS on > git changes that close bugs are broken. > > e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855510#10 has the > following link: > > http://git.debian.org/?p=python-modules/packages/slimit.git;a=commitdiff;h=d20c791 > True. For some reason, the redirect to gitweb on anonscm seems to be broken. This works correctly: http://git.debian.org/?p=python-modules/packages/slimit.git → https://anonscm.debian.org/gitweb/?p=python-modules/packages/slimit.git This doesn't and redirects to cgit instead, cutting off the commit id: http://git.debian.org/?p=python-modules/packages/slimit.git;a=commitdiff;h=d20c791 → https://anonscm.debian.org/cgit/python-modules/packages/slimit.git/diff/?id= But… > Which generates the following error: > > 404 - No such project …following the above observation, it throws Bad object name instead here. -nik -- PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296 Dominik George · Hundeshagenstr. 26 · 53225 Bonn Mobile: +49-1520-1981389 · https://www.dominik-george.de/ Teckids e.V. · FrOSCon e.V. Fellowship of the FSFE · Piratenpartei Deutschland Opencaching Deutschland e.V. · Debian Maintainer LPIC-3 Linux Enterprise Professional (Security) signature.asc Description: PGP signature
