Re: Respectfully request to join the debian python team

2021-01-21 Thread Stefano Rivera
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

2021-01-21 Thread PerRy
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

2021-01-21 Thread Paul Wise
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

2021-01-21 Thread Paul Wise
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

2021-01-21 Thread Nicholas D Steeves
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/

2021-01-21 Thread Fabrice BAUZAC-STEHLY
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

2021-01-21 Thread Fabrice BAUZAC-STEHLY
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

2021-01-21 Thread Stefano Rivera
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

2021-01-21 Thread Ole Streicher
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

2021-01-21 Thread Ole Streicher
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

2021-01-21 Thread Evangelos Ribeiro Tzaras

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

2021-01-21 Thread Ansgar
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

2021-01-21 Thread Paul Wise
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

2021-01-21 Thread Ole Streicher
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