Re: Respectfully request to join the debian python team
Hi PerRy (2021.01.22_00:48:18_+) > thanks for the advice, I'll definitely take a look into patching and > orphaned packages. As far as mentoring how would I go about doing that? > finding one that is. I'd say post upload requests to the debian-mentors lists, or patches to bugs. There's a freeze coming up soon, so RC bugs are especially valuable to fix. I'm afraid this path often isn't easy. It's definitely one of Debian's weaker areas, but with good work and persistence you should be able to get some uploads done. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Respectfully request to join the debian python team
Hi Stefano, thanks for the advice, I'll definitely take a look into patching and orphaned packages. As far as mentoring how would I go about doing that? finding one that is. On Thu, Jan 21, 2021 at 12:15 PM Stefano Rivera wrote: > Hi PerRy (2021.01.21_07:39:50_+) > > I wanted to request to join the debian python team. In a previous email, > I > > shared that I have been using debian for a while now and at this point in > > time I want to contribute back to the project. One of my skills is > writing > > scripts in python, and I want to utilize and build upon this skill in > > contributing back to debian. > > Aside from a password reset, I'd recommend getting started by > contributing patches through the bug tracking system, or adopting some > orphaned packages, and getting some experience maintaining them. Ideally > finding some mentors to help you out, along the way. > > We don't generally give people who are brand new to contributing to the > project commit access to hundreds of packages. > > SR > > -- > Stefano Rivera > http://tumbleweed.org.za/ > +1 415 683 3272 > > -- *Perry Ryan Cruz Aganad*
Re: Generic Python packages which don’t work on all architectures
On Thu, Jan 21, 2021 at 11:30 PM Paul Wise wrote: > there is probably some coverage of arch:all packages on debci, not > sure if it tests them on multiple arches though. FTR, #debci says arch:all packages get tested on all debci arches. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Generic Python packages which don’t work on all architectures
On Thu, Jan 21, 2021 at 3:42 PM Ole Streicher wrote: > But this is also the case for all packages which implicitly depend on > other packages which are not available on some architectures. This is true, but it doesn't make for a good user experience. > Generally, arch:all packages depend on a lot of architecture dependent > packages, and unless one resolves the whole dependency chain, there is > no way to check whether a package is actually installable. The buildds have installability checking for build-deps (IIRC using dose), so some sort of QA service could be doing these sort of checks more cheaply than installing arch:all packages outside of amd64. Also unfortunately piuparts.d.o doesn't yet support multiple arches, but there is probably some coverage of arch:all packages on debci, not sure if it tests them on multiple arches though. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Questions around the python-policy document
Hi Fabrice, Fabrice BAUZAC-STEHLY writes: > Hello Debian-Python, > > I have a few questions regarding the Python Policy: > https://www.debian.org/doc/packaging-manuals/python-policy/ > > - Is there a Debian package for reading it offline? (apparently not) > > - Who maintains this document: is it the Policy team, the Python team? > > - Where is the source code? I could not find it on salsa... > apt-file search python-policy Then identify the package it comes from and "debcheckout" that package. Other answers can be found there :-) Regards, Nicholas signature.asc Description: PGP signature
Re: Status of https://debian-python.readthedocs.io/en/latest/
Barry Warsaw writes: >> On Dec 25, 2020, at 12:52, Sandro Tosi wrote: >> >> it looks like Barry (correct me if i'm wrong) set up >> https://debian-python.readthedocs.io/en/latest/ but it has not been >> updated in a while. >> >> Do we know what's the status of this website, if we want to continue >> to maintain it, or instead we should just consolidate onto >> https://www.debian.org/doc/packaging-manuals/python-policy/ ? > That RTD project has been failing for years. It looks like I’m the > only maintainer for that project. I’m happy to add others or transfer > it to someone else. I don’t think RTD supports maintainer teams. > Just let me know what y’all want to do! The RTD website [1] indicates that the "project home" is [2] but [2] leads to a 404 Page Not Found. Where are the sources? If RTD cannot be a long-term host for this doc (because it does not support maintainer teams), maybe we can convert it to a documentation package, similar to debmake-doc? [1] https://debian-python.readthedocs.io/en/latest/README.html [2] https://gitlab.com/debian-python/dpdp -- Fabrice Bauzac-Stehly PGP 01EEACF8244E9C14B551C5256ADA5F189BD322B6 old PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D
Questions around the python-policy document
Hello Debian-Python, I have a few questions regarding the Python Policy: https://www.debian.org/doc/packaging-manuals/python-policy/ - Is there a Debian package for reading it offline? (apparently not) - Who maintains this document: is it the Policy team, the Python team? - Where is the source code? I could not find it on salsa... - Is it meant to be normative and relatively small like the Debian Policy, or is it allowed to contain tutorials, tips, best practices, examples and recommendations like the debmake manual? - Would it need some help, are there bugs or needs for improvements? Thanks in advance! Best regards -- Fabrice Bauzac-Stehly PGP 01EEACF8244E9C14B551C5256ADA5F189BD322B6 old PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D
Re: Respectfully request to join the debian python team
Hi PerRy (2021.01.21_07:39:50_+) > I wanted to request to join the debian python team. In a previous email, I > shared that I have been using debian for a while now and at this point in > time I want to contribute back to the project. One of my skills is writing > scripts in python, and I want to utilize and build upon this skill in > contributing back to debian. Aside from a password reset, I'd recommend getting started by contributing patches through the bug tracking system, or adopting some orphaned packages, and getting some experience maintaining them. Ideally finding some mentors to help you out, along the way. We don't generally give people who are brand new to contributing to the project commit access to hundreds of packages. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Generic Python packages which don’t work on all architectures
Paul Wise writes: > On Thu, Jan 21, 2021 at 1:12 PM Ole Streicher wrote: > >> This would be a quite flexible and extendible approach to have packages >> installable only where they work. > > There is precedent for this sort of thing in the isa-support source > package, which fails installation when your CPU doesn't support > particular ISA extensions like SSE or NEON. > > It is a reasonable workaround for now, but the packages using the > pseudo-packages would still be available, causing confusion when > people try to install them. But this is also the case for all packages which implicitly depend on other packages which are not available on some architectures. This is not very rare: * Python arch:all packages may depend on arch:* Python packages which are not available everywhere * Packages written in an interpreted language are arch:all, but depend on the interpreter and can only installed on archs where the interpreter exists (like gnudatalanguage or iraf from my portfolio) Generally, arch:all packages depend on a lot of architecture dependent packages, and unless one resolves the whole dependency chain, there is no way to check whether a package is actually installable. > It would be better to just not have them available where they aren't > going to work. I also wonder how multi-arch stuff would interact with > the pseudo-packages idea. IMO this is a problem that already exists there and is not solved. Imagine the following constellation: * I have a python3-foo package with arch:all. * this depends on python3-foo-obj that exists only for i386. Now I have a x86_64 machine that gets i386 added. On this machine, I could install python3-foo (since the dependency is resolvable), but 'import foo' with the x86_64 interpreter would fail. Best regards Ole
Re: Generic Python packages which don’t work on all architectures
Ansgar writes: > On Thu, 2021-01-21 at 13:46 +0100, Ole Streicher wrote: >> I am still wondering why we don't have just empty some pseudo- > packages that are available only on specific architectures >> (or groups of them, like linux, or little endian, or 64 bit or so). > > To solve which problem? For example, the problem that a certain package is working properly only on big endian systems. Or on Linux. Currently, there is (as discussed here) no way to tell that an arch:all package is not working on a 32-bit system. And for architecture dependent builds, one needs to specify every single architecture where it is supposed to build. How do you currently otherwise would specify "all little endian systems" as build dependency? > Packages being installable don't mean that they can do anything useful > as they might, for example, require special hardware. We don't have a > way to express "requires device ${X}" on a package level. Special hardware is another topic, which is surely not solved here (and not solvable at all in general, since hardware today may be hot-pluggable, and the hardware configuration at install time does not need to be the configuration at run time). However, the proposal to have architecture (group) specific empty packages would already solve some of the problems if this is limited to architecture specification. Best regards Ole
Re: Respectfully request to join the debian python team
Hi, On 1/21/21 8:39 AM, PerRy wrote: My name is Perry, I wanted to request to join the debian python team. In a previous email, I shared that I have been using debian for a while now and at this point in time I want to contribute back to the project. One of my skills is writing scripts in python, and I want to utilize and build upon this skill in contributing back to debian. I have read, understand, and accept the debian python team policy. Salsa Login: username - bpm10 pw - You should really not share your password like that (this is a public mailing list after all). Furthermore I would advice changing this (and similar passwords) in all services where you use it. -- */ */Perry Ryan Cruz Aganad/* /*
Re: Generic Python packages which don’t work on all architectures
On Thu, 2021-01-21 at 13:46 +0100, Ole Streicher wrote: > I am still wondering why we don't have just empty some pseudo- packages that are available only on specific architectures > (or groups of them, like linux, or little endian, or 64 bit or so). To solve which problem? Packages being installable don't mean that they can do anything useful as they might, for example, require special hardware. We don't have a way to express "requires device ${X}" on a package level. Ansgar
Re: Generic Python packages which don’t work on all architectures
On Thu, Jan 21, 2021 at 1:12 PM Ole Streicher wrote: > This would be a quite flexible and extendible approach to have packages > installable only where they work. There is precedent for this sort of thing in the isa-support source package, which fails installation when your CPU doesn't support particular ISA extensions like SSE or NEON. It is a reasonable workaround for now, but the packages using the pseudo-packages would still be available, causing confusion when people try to install them. It would be better to just not have them available where they aren't going to work. I also wonder how multi-arch stuff would interact with the pseudo-packages idea. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Generic Python packages which don’t work on all architectures
Paul Wise writes: > This is what I eventually chose for iotop. At the time I wanted dpkg > and dak to support something like Architecture: linux-all, which would > build arch: all packages, but only put them in the Packages files for > the Linux architectures. > > I am now thinking that a more generic solution than Architecture: > linux-all is needed, in order to cover your case as well. Perhaps > something like Available-Architecures or Runtime-Architectures or > Architecture-all-Architectures: or similar. I am still wondering why we don't have just empty some pseudo-packages that are available only on specific architectures (or groups of them, like linux, or little endian, or 64 bit or so). If a package works (or builds) only on a specific arch (or an arch with specific properties), it can be set dependent (or built-dependent) on that. This would be a quite flexible and extendible approach to have packages installable only where they work. Best regards Ole