Re: Reaching team consensus on usage of py3versions -r and X-Python3-Version in Lintian

2022-01-18 Thread Thomas Goirand

On 1/17/22 18:47, Louis-Philippe Véronneau wrote:

Hey folks,

I'm following up on bug #1001677 [1] on the DPT's list to try to reach
consensus, as I think the Lintian tags that were created to fix this bug
are not recommending the proper thing.

As a TL;DR for those of you who don't want to read the whole BTS thread,
jdg saw that a bunch of packages were using `py3versions -r` in
autopkgtests, and this fails when there's no X-Python3-Version variable
in d/control.

The fix that Lintian now proposes for packages that use `py3versions -r`
in autopkgtests is to set X-Python3-Version.

I think the proper fix would be to ask people to move away from
`py3versions -r` if there is no X-Python3-Version, and use`py3versions
-s` instead.

As such, I think we should ask the Lintian maintainers to:

1. Change the desc for tag declare-requested-python-versions-for-test to

The specified test attempts to query the Python versions
requested by your sources with the command py3versions
--requested but your sources do not actually declare those
versions with the field X-Python3-Version.
.
Please query all supported Python versions with the command
py3versions --supported in your test instead.

2. Change the desc for tag query-requested-python-versions-in-test to

The specified test queries all supported Python versions with
the command py3versions --supported but your sources
request a specific set of versions via the field
X-Python3-Version.
.
Please delete the field X-Python3-Version, as it is not needed.


These changes would push maintainers to use `py3versions -s`, but
wouldn't ask people using `py3versions -r` and X-Python3-Version to make
any changes.

AFAIU, the only valid use of X-Python3-Version would be a package that
fails to build on an older but currently supported version of Python
(let's say 3.9) but builds on the newer version (say 3.10). I think such
use cases are pretty rare though.

Cheers,

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001677



+1 (very much)



Re: Update packages to recent version

2022-01-14 Thread Thomas Goirand

On 1/13/22 21:25, Mechtilde Stehmann wrote:

Hallo,

I intend to package paperless-ng.

Many of its dependencies are packaged in Debian but in an older version. 
You can see the list at 
https://salsa.debian.org/mechtilde/paperless-ng/-/wikis/home


Are there any hints to upload newer versions?

Kind regards


Hi,

If you're looking at the requirements.txt file from upstream to tell 
what version you need in Debian, this is a *very* wrong approach.


What's happening is that your upstream is using the requirements.txt to 
tell pip what version to fetch for paperless-ng testing. This is, in no 
way, some indication of what should be in your package.


For example, the requirements.txt contains:
pytz==2021.1

however, I'd be really surprised if paperless-ng wouldn't work with some 
other version of python3-tz (even an older one).


What's harder then, is to know what is the minimum version of each 
component for your application. However, running internal tests at build 
time may help you to know.


I hope this helps,
Cheers,

Thomas Goirand (zigo)



Re: python-cryptography, Rust, and OpenSSL 3.0

2021-12-01 Thread Thomas Goirand
On 12/1/21 4:05 PM, Andrius Merkys wrote:
> Hi Simon,
> 
> On 2021-12-01 14:31, Simon Chopin wrote:
>> TL;DR: Does it make sense to upload the intermediary upstream version
>> 3.4.8 or rather wait for someone to work on the Rust-based later versions?
> 
> I would say yes. python-cryptography >= v3.4.6 is needed to update
> python-autobahn [1]. Thomas Goirand (in CC) said [2] he is already
> working on python-cryptography, thus it would be best to coordinate
> uploads with him.
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995431
> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994914#19
> 
> Best,
> Andrius
> 

Did ?!? I believe I wrote I was working on python-autobahn, but I have
to admit I completely failed my duty (busy on other stuff, like Ceph and
many other RC bug fixing).

At this point, I believe I must accept NMUs, or at least patches,
otherwise it will take forever...

Cheers,

Thomas Goirand (zigo)



Removal of python-flask-script and flask-assets from unstable/bookworm

2021-11-24 Thread Thomas Goirand
Hi,

flask-assets build-depends on python3-flask-script. python-flask-script
depends on Flask, but isn't compatible with Flask 2.x which is now in
unstable. python-flask-script has no commit or release since 2017.

So both packages are kind of doomed...

Neither python-flask-script or flask-assets have reverse dependencies.

I am therefore hereby proposing the removal of python-flask-script and
flask-assets from unstable/testing, which by the way will allow Flask to
migrate to Bookworm.

Your thoughts?

Cheers,

Thomas Goirand (zigo)



Re: mass bug filling for nose removal (was: Bug#997758: nose: FTBFS: There is a syntax error in your configuration file: invalid syntax (conf.py, line 220))

2021-11-11 Thread Thomas Goirand
On 11/11/21 1:33 PM, Dmitry Shachnev wrote:
> Hi Thomas!
> 
> On Thu, Nov 11, 2021 at 11:04:10AM +0100, Thomas Goirand wrote:
>> On 10/24/21 3:24 PM, Dmitry Shachnev wrote:
>>> If anyone is still using nose (1.x), please port your packages to nose2,
>>> pure unittest or pytest. I am attaching a dd-list and I intend to do a MBF
>>> in a few weeks when I have more time.
>>>
>>> --
>>> Dmitry Shachnev
>>
>> Hi,
>>
>> I wonder if we could do a mass bug filling for this. Your thoughts?
> 
> Yes, this idea was present in my original mail you quoted here :)
> 
> I intend to do it at some point, but I can't yet say when it will happen.

Yes, but your original idea was to kick nose out of Debian before we get
the chance to fix. I believe it'd be nicer to do the MBF even if we keep
nose for a while, which is why I wrote about it again, as I didn't know
what your intention was.

Very good if you still have it in mind then! It'd be very useful to me
at least (as many of the package I contribute may be affected and it's
hard to have a vision of it without the MBF).

Cheers,

Thomas Goirand (zigo)



Re: mass bug filling for nose removal (was: Bug#997758: nose: FTBFS: There is a syntax error in your configuration file: invalid syntax (conf.py, line 220))

2021-11-11 Thread Thomas Goirand
On 10/24/21 3:24 PM, Dmitry Shachnev wrote:
> If anyone is still using nose (1.x), please port your packages to nose2,
> pure unittest or pytest. I am attaching a dd-list and I intend to do a MBF
> in a few weeks when I have more time.
> 
> --
> Dmitry Shachnev

Hi,

I wonder if we could do a mass bug filling for this. Your thoughts?

Cheers,

Thomas Goirand (zigo)

P.S: I'm not volunteering for doing it, just giving the idea...



Re: platform.machine() on salsa i386 build?

2021-10-30 Thread Thomas Goirand
On 10/30/21 8:43 PM, Andrey Rahmatullin wrote:
> On Sat, Oct 30, 2021 at 02:20:40PM +0200, Ole Streicher wrote:
>> I have a package (pyraf) where I need to switch off some tests for i386
>> (but not for other 32-bit platforms). I do this by
>>
>> import platform
>> is_i386 = platform.machine() in ('i386', 'i486', 'i586', 'i686')
> Yup, this is incorrect. This is the same as `uname -m` and so returns the
> kernel architecture.
> If you want to do this purely at the upstream side without checking
> DEB_HOST_ARCH, AFAIK there is no 100% reliable way to do this.

I would also advise to use DEB_HOST_ARCH... Maybe with some fallbacks if
you wish to upstream it?

Cheers,

Thomas Goirand (zigo)



Re: Bug#997758: nose: FTBFS: There is a syntax error in your configuration file: invalid syntax (conf.py, line 220)

2021-10-25 Thread Thomas Goirand
On 10/25/21 8:18 PM, Dmitry Shachnev wrote:
> However, it would be still nice to remove nose at some future point, maybe
> before Bookworm release.

Will do, probably for the next version of OpenStack (last one made me
update 220 packages: that's a good way to review everything).

> I'm impressed by the number of packages you have depending on nose, but if
> they all come from the same upstream, maybe you can convince this upstream
> to not rely on dead software.

I believe most dependencies on Nose could be removed (for example, all
of the OpenStack dashboard stuff...), but just right after a release
isn't the best time to start the work...

Cheers,

Thomas Goirand (zigo)



Re: Bug#997758: nose: FTBFS: There is a syntax error in your configuration file: invalid syntax (conf.py, line 220)

2021-10-24 Thread Thomas Goirand
On 10/24/21 3:24 PM, Dmitry Shachnev wrote:
> Hi all!
> 
> On Sun, Oct 24, 2021 at 01:49:30PM +0200, Lucas Nussbaum wrote:
>> Source: nose
>> Version: 1.3.7-7
>> Severity: serious
>> Justification: FTBFS
>> Tags: bookworm sid ftbfs
>> User: lu...@debian.org
>> Usertags: ftbfs-20211023 ftbfs-bookworm
>>
>> Hi,
>>
>> During a rebuild of all packages in sid, your package failed to build
>> on amd64.
>>
>> [...]
> 
> It happens because setuptools v58.0.0 removed support for 2to3 during builds,
> which nose relied on (because it has a Python 2 codebase).
> 
> Instead of spending time on a proper Python 3 port, I would prefer to simply
> let nose die (it is abandoned since 2016).
> 
> If anyone is still using nose (1.x), please port your packages to nose2,
> pure unittest or pytest. I am attaching a dd-list and I intend to do a MBF
> in a few weeks when I have more time.
> 
> --
> Dmitry Shachnev

Hi,

I'm referenced for 55 packages. Please don't force me to do this right
away, that's too much work. I very much would prefer if we could have a
smoother transition.

Note that it's possible that for many packages mentioned, only removing
the dependency should be enough. Still, that's some work to do... :/

Other alternative would be: help with NMU fixes (or I can add any of you
in the OpenStack team if you need...).

Cheers,

Thomas Goirand (zigo)



Re: python-anyio not building?

2021-10-23 Thread Thomas Goirand
On 10/23/21 1:09 PM, Julien Puydt wrote:
> Hi,
> 
> I don't get why python-anyio is stuck ; I certainly didn't upload it
> without trying to build it, and I just tried again and there was no
> issue :
> https://buildd.debian.org/status/package.php?p=python-anyio
> 
> Does someone have a clue what is happening?
> 
> Cheers,
> 
> J.Puydt
> 

It looks fine to me, is there any issue?

Cheers,

Thomas Goirand (zigo)



Re: .egg-info for entry points during dh_auto_test

2021-10-22 Thread Thomas Goirand
On 10/21/21 8:55 PM, Michael Fladischer wrote:
> Hi,
> 
> I'm working on src:pytest-lazy-fixtures and was trying to get the
> unittests to run but it seems that I have run into a problem that I'm
> not sure on how to fix it in a clean way.
> 
> pytest-lazy-fixtures is a pytest plugin and registers itself through the
> Python entrypoints mechanism. In its unitests, it assumes that this
> registration has already happened but during dh_auto_test there is no
> .egg-info directory available. I could use "python3 setup.py develop -x"
> to generate it, but this registers the package in /usr inside the build
> chroot which I think is not the best solution.
> 
> Is there an other, less intrusive way to register the entrypoint before
> running the tests?
> 
> Thanks,
> Michael
> 

Hi Michael,

I do this in many of my packages (or a variation of this) to solve that
problem:

override_dh_install:
python3 setup.py install --install-layout=deb \
--root=$(CURDIR)/debian/tmp

ifeq (,$(findstring nocheck, $(DEB_BUILD_OPTIONS)))
PYTHONPATH=$(CURDIR)/debian/tmp/usr/lib/python3/dist-packages \
dh_auto_test
endif

dh_install

override_dh_auto_test:
    echo "Do nothing..."

I hope this helps,
Cheers,

Thomas Goirand (zigo)



Re: Why is isal limited to just three archs?

2021-10-16 Thread Thomas Goirand
On 10/16/21 9:09 AM, Nilesh Patra wrote:
> Hi Ondřej,
> 
> I see that isal package is limited to amd64, arm64 and kfreebsd-amd64.
> Is there a particular reason for this? -- Is it possible to extend
> support to other archs?
> 
> Actually, a -med team package fastp has started to depend on
> libisal-dev, and this
> now is limited to the few archs isal supports. So it would be really
> nice if isal
> can build on more archs.
> 
> Please do let me know.
> 
> Nilesh

Hi,

Did you look into the source package? isal is written in assembly
language...

Cheers,

Thomas Goirand (zigo)



Re: writing debian/gbp.conf considered harmful [was: python-django-js-asset_1.2.2-3_source.changes REJECTED]

2021-09-22 Thread Thomas Goirand
On 9/21/21 11:00 PM, Antonio Terceiro wrote:
> However, having it duplicated in every package means we as a team work
> consistently regardless of people's global configuration, and that's one
> less detail people need to get just right to be able to contribute
> effectively.

No. It *ALREADY* works by default, no need to tweak anything on
debian/gbp.conf. Also, as I wrote already, using gbp buildpackage is
*NOT* the only one way of doing things. One can use sbuild without gbp.
What you're proposing is in fact the same as if you were proposing to
add defaults for some text editors in the packaging: that's irrelevant,
and hard to maintain consistently (like Sandro wrote).

> Also, one's global configuration might not apply to all the packages
> they contribute to

It is the case for me: I contribute to both the OpenStack team and the
Python team. Both teams have *very* different workflow (the Python team
is using pristine-tar, I don't like it and that's the main reason why
OpenStack is maintained outside of this team...).

In the OpenStack team, we used to maintain per-package debian/gbp.conf.
I am *very* happy we decided back in Debconf Montreal in 2017 to stop
doing that.

> it's easier for everyone if gbp just does the
> right thing based on per-package configuration than expecting people to
> remember to switch their defaults, or to pass options explicitly.

There's nothing to switch. One just needs to remember to explicitly
generate the tarball with "gbp export-orig", OR (preferred) directly
fetch the orig.tar.{gz,xz} from the Debian archive. If you forget, gbp
complains about it and stops building (that is, as long as you have the
option "no-create-orig = True" in your ~/.gbp.conf).

Cheers,

Thomas Goirand (zigo)



Re: python-django-js-asset_1.2.2-3_source.changes REJECTED

2021-09-20 Thread Thomas Goirand
On 9/20/21 5:14 PM, Sandro Tosi wrote:
>> That's because gbp does not use pristine-tar by default, and
>> debian/gbp.conf was missing `pristine-tar=True`. Just pushed a commit to
>> fix that.
> 
> I dont think this is the right approach: the default options to work
> on DPT packages should be in gbp default config file (or in another,
> global, config file), and not live in each and every package
> debian/gbp.conf file; it is already inconsistently maintained with
> several packages having uncommon settings that will take precedence
> over the default ones.

+1

Plus gbp is just *one* out of *many* tools available. Some people just
prefer to use sbuild only, for example, and that's perfectly fine. IMO
it's up to the person that's using gbp to know what they are doing.

FYI, I've rebuilt regularly packages from the team, I even have
"pristine-tar = False" in my ~/.gbp.conf, and it's all fine...

Cheers,

Thomas Goirand (zigo)



Re: Moving forward with more Python 2 removal, plus upgrading to markupsafe 2.0, jinja2 3.0, werkzeug 2.0 and flask 2.0

2021-09-20 Thread Thomas Goirand
On 9/18/21 3:02 PM, Thomas Goirand wrote:
> Dear Python Team, Dear Piotr,
> 
> As I was packaging Cloudkitty (that is: OpenStack rating of resources,
> typically used in a public cloud) for the next Xena release, I went into
> this chain of dependency:
> 
> cloudkitty: needs flask 2.0
> Flask 2.0: needs werkeug 2.0, jinja2 3.0
> jinja2: needs markupsafe 2.0
> 
> The thing is, markupsafe 2.0 looks like incompatible with Python 2 (when
> I removed Python 2 support in the package, it built fine).
> 
> I currently have updated markupsafe and jinja2 packages in my laptop,
> (which IS removing Python 2 support). I'll soon have updates for the
> other 2 (if I don't hit any blockers).
> 
> During the python BoF of the last Debconf, we decided to go ahead with
> full removal of Python 2, so doing this looks like a move to the right
> direction.
> 
> Is it fine for everyone (including Piotr, who's the only marked uploader
> for these) if I upload these to Experimental right now (which is where I
> am uploading OpenStack Xena), and in Unstable after the 8th of October
> (when OpenStack Xena will be finally released)?
> 
> I'm also aware that the packages I mentioned above are high profile (ie:
> used a lot in Debian), which is why I thought announcing my plan was a
> good idea (also so that Piotr can tell his opinion).
> 
> Also Piotr, can I add myself as uploader for all of these?
> 
> Your thoughts?
> Cheers,
> 
> Thomas Goirand (zigo)
> 
> P.S: I do believe that uploading to Experimental is harmless (when we're
> not in freeze), so I may go ahead before getting a reply, and we can
> decide what to do together.
> 

FYI, I went ahead with the above, and uploaded to Experimental (and also
uploaded Falcon 3.0.1 too...). All went fine, however, I had to disable
a dozen unit tests in werkzeug. Help to fix this would be very much
appreciated.

Cheers,

Thomas Goirand (zigo)



Moving forward with more Python 2 removal, plus upgrading to markupsafe 2.0, jinja2 3.0, werkzeug 2.0 and flask 2.0

2021-09-18 Thread Thomas Goirand
Dear Python Team, Dear Piotr,

As I was packaging Cloudkitty (that is: OpenStack rating of resources,
typically used in a public cloud) for the next Xena release, I went into
this chain of dependency:

cloudkitty: needs flask 2.0
Flask 2.0: needs werkeug 2.0, jinja2 3.0
jinja2: needs markupsafe 2.0

The thing is, markupsafe 2.0 looks like incompatible with Python 2 (when
I removed Python 2 support in the package, it built fine).

I currently have updated markupsafe and jinja2 packages in my laptop,
(which IS removing Python 2 support). I'll soon have updates for the
other 2 (if I don't hit any blockers).

During the python BoF of the last Debconf, we decided to go ahead with
full removal of Python 2, so doing this looks like a move to the right
direction.

Is it fine for everyone (including Piotr, who's the only marked uploader
for these) if I upload these to Experimental right now (which is where I
am uploading OpenStack Xena), and in Unstable after the 8th of October
(when OpenStack Xena will be finally released)?

I'm also aware that the packages I mentioned above are high profile (ie:
used a lot in Debian), which is why I thought announcing my plan was a
good idea (also so that Piotr can tell his opinion).

Also Piotr, can I add myself as uploader for all of these?

Your thoughts?
Cheers,

Thomas Goirand (zigo)

P.S: I do believe that uploading to Experimental is harmless (when we're
not in freeze), so I may go ahead before getting a reply, and we can
decide what to do together.



Re: RFS: colorzero/2.0-1 [ITP] -- Construct, convert, and manipulate colors in a Pythonic manner.

2021-06-19 Thread Thomas Goirand
On 6/19/21 2:03 PM, Peter Green wrote:
> Just done some reviewing/tweaking. I've pushed the following changes to
> the git repo, please
> tell me if you have any objections.
> 
> I added a gpb.conf to make git-buildpackage actually use pristine tar
> and hence result in an orig
> tarball that was consistent with what is already in Ubuntu.
> 
> I found the clean target was not cleaning up the "egg-info" so I added a
> command to do that.

I used to do that, but a few years ago, I switched to (and generalize in
all of my packages) using this:

$ cat debian/source/options
extend-diff-ignore = "^[^/]*[.]egg-info/"

That's a way more simple, as sometimes, upstream ships an egg-info and
building *modifies* it (and then, nightmare starts...).

Just my 2 cents of experience... :)

Thomas Goirand (zigo)



Re: Python BoF at DebConf2021

2021-06-12 Thread Thomas Goirand
On 6/12/21 10:20 PM, Louis-Philippe Véronneau wrote:
> Hey folks,
> 
> The deadline to submit talks for DebConf21 is June 20th and I was
> thinking it would be a good idea to have a Python BoF, as we always do.
> 
> Anyone opposed to the idea?

Thanks, go ahead! :)

Did you also register a BoF for the puppet team?

Thomas



Re: Jupyter team?

2021-05-18 Thread Thomas Goirand
On 5/18/21 10:06 AM, Gordon Ball wrote:
> On Mon, May 17, 2021 at 06:20:19PM +0200, Roland Mas wrote:
>> Hi everyone,
>>
>> I've been contracted by Synchrotron Soleil to work on the packaging of
>> Jupyterhub and its dependencies. This turns out to about 20 Python packages,
>> most of which should probably go under the Debian Python Team umbrella
>> (although some may go into Debian Science). So I hereby request to be added
>> to the python-team group on salsa. My salsa login is "lolando", and I have
>> read and accept the 
>> https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
>> policy.
> 
> Hello
> 
> Good to have more people working on jupyter and related tools. Can you
> say what the extent of your goal here is? Does it just relate to the
> jupyterhub server, spawners, proxy, etc or does your target also include
> some work on the jupyter interfaces/core side?
> 
> I wonder if it is time to have a distinct jupyter packaging team given
> the (perhaps concerningly?) growing size of this software stack [1].

We're talking about 2 dozen of Python packages. Do you really think
that's a lot?

Cheers,

Thomas Goirand (zigo)



Re: Challenges packaging Python for a Linux distro - at Python Language Summit

2021-05-17 Thread Thomas Goirand
umpy and sci-py.

The problem isn't the build system, which is doing things the correct
way. Any "arch: any" package linked against Python *must* be upgraded
together with the interpreter itself when it transition from Unstable to
Testing. That's a fact, and how Debian is designed.

By *policy* Debian doesn't support multiple versions of a library on a
single system. The only thing that is allowed, is to have 2 versions
*during a transition*. What we hope is to have such thing happen (ie: 2
versions of a single library) only in Unstable, though sometimes, this
also migrates to testing, but that's not what we desire.

If you wish Debian to support multiple versions of a library, you should
first attempt to discuss this feature at large with the Debian community
because *by design* (and therefore, written in the stones of the Debian
Policy Manual) that isn't how we want Debian to work, and how the Debian
community wants it to work.

If you wish to have such a feature, then yeah, probably you should go
and use another distribution, because I don't see Debian changing on the
direction you describe anytime soon.

> i can only surmise that they probably don't want to say anything
> because the message being sent to them on summary closure
> of bugreports is that, well, "nobody cares".

I don't think that's right. They just think you are wrong, because you
believe Debian should support multiple versions of a library (here:
Python), when it's not the case *by design*, because we (ie: everyone
contributing to Debian) want Debian to be this way. This isn't specific
to the Python world, this is how Debian *at large* is designed.

> once this is accepted as actually being a problem that needs solving,
> rather than being avoided because "it's not supported, you're on your
> own, not our problem", i am happy to help advise and discuss
> solutions.
> 
> given that this has been ongoing for 10 years now i have been giving
> it some thought for a long, long time.
> 
> however before getting to a discussion of solutions i would prefer
> to see acknowledgement that it is recognised as a problem that
> people actively wish to see fixed.

As I wrote earlier, before discussing if this is a problem or not, you
will need to convince a majority of Debian Developers that having 2
versions of a shared library at the same time on a given Debian system
is something we desire. Good luck doing that, as this is a very strong
feature of Debian. I don't know any Debian Developer that believes this
is something desirable.

> otherwise i will have to wait patiently
> for the next disaster situation to occur, or, sadly, after 20 years of
> using debian, and remaining loyal to it despite maltreatment, i will
> have to find an alternative distro.

There's no maltreatment. Just a misunderstanding from your side of what
Debian does, IMO.

Finding another distro may be one solution indeed.

Doing what Jeremy suggests (ie: running your builds in a chroot, or with
venv, etc.) may work for some times, though I would strongly recommend
the best practices in terms of dependency management, which means:
always try to stay current with all of your dependencies.

> what is stopping me from doing that is the severe financial consequences
> involved and risk to myself and my family due to my income being
> far below average. the downtime that would result is a huge risk,
> plus learning a new distro also compromises my effectiveness which
> also results in further lost income.

Then learn how to reproducibly build chroot and venvs.

> what i am saying is: this is serious - i am effectlvely financially
> trapped and critically dependent on the decisions that you make,
> even though i am not paying you money for the work that you do.

IMO, you've trapped yourself here... but there's exist strategies. :)
I sincerely hope you will find a solution that matches your need,
hopefully by continuing to use Debian.

Cheers,

Thomas Goirand (zigo)



Re: Challenges packaging Python for a Linux distro - at Python Language Summit

2021-05-16 Thread Thomas Goirand
On 5/16/21 1:52 PM, Luke Kenneth Casson Leighton wrote:
>> * One 3.x version at a time. Doesn't line up with cpython's support terms.
> 
> folks, deep breath here: this is much more important than the one line
> summary suggests.
> 
> for some background: i have been using debian since 1996 and python for
> 20+ years, dating back to python 2.0.
> 
> due to the massive amount of accumulated software (several million
> development source code files) i run a rolling debian/testing system,
> *never* do an "apt-get dist-upgrade", *always* simply perform an on-demand
> install of a given package and let apt sort itself out even to the
> point often of
> having some innocuous package end up pulling in a new libc6-dev and
> binutils.

All the horrors that you are painting after this paragraph, are due to
the fact that you aren't doing "apt-get dist-upgrade". I'm having a hard
time understanding why you're both:
- not doing "apt-get dist-upgrade"
- complaining that it's breaking your system

Could you care to explain? This makes absolutely no sense.

By the way, since you're never doing "apt-get dist-upgrade", it means
your system is full of security issues that aren't getting fixed.
Hopefully, the computer system(s) you're talking about isn't connected
to internet, right?

Cheers,

Thomas Goirand (zigo)



Re: Challenges packaging Python for a Linux distro - at Python Language Summit

2021-05-13 Thread Thomas Goirand
On 5/13/21 1:26 AM, Stefano Rivera wrote:
> Hi Thomas (2021.05.12_23:06:45_+)
>> On 5/12/21 11:21 PM, Stefano Rivera wrote:
>>> Matthias Klose gave a presentation at the Python Language Summit on the
>>> Challenges packaging Python for a Linux distro.
>>> [..]
>> This looks great. Is there a video of it somewhere?
> 
> No, there won't be videos published, only blog posts written.
> 
> SR

Matthias, if you read this: you *MUST* make such a presentation at the
next debconf, *PLEASE* !!!

Cheers,

Thomas Goirand (zigo)



Re: Challenges packaging Python for a Linux distro - at Python Language Summit

2021-05-12 Thread Thomas Goirand
On 5/12/21 11:21 PM, Stefano Rivera wrote:
> Matthias Klose gave a presentation at the Python Language Summit on the
> Challenges packaging Python for a Linux distro.
> [..]
This looks great. Is there a video of it somewhere?

Cheers,

Thomas Goirand (zigo)



Re: upstream python concerns, python3-full package for bullseye

2021-02-16 Thread Thomas Goirand
On 2/16/21 5:25 AM, Stefano Rivera wrote:
> Hi debian-python (2021.02.11_18:24:57_+)
>> I have prepared a policy MR for this:
>> https://salsa.debian.org/cpython-team/python3-defaults/-/merge_requests/8
>> It catches up on the current split situation, too.
> 
> We had a discussion on the principle of the change, but nobody has
> responded to the policy wording yet.
> 
> Anyone seconds / objections?
> 
> SR
> 

It's fine, thanks for working on this.

Cheers,

Thomas Goirand (zigo)



Re: upstream python concerns, python3-full package for bullseye

2021-02-13 Thread Thomas Goirand
Hi,

FYI, my concerned are addressed by what Stefano wrote about the full
desc, though I still feel like I need to reply to you.

On 2/12/21 2:08 PM, Julien Palard wrote:
> Hi,
> 
> As far as I understand, the divergence between "Python upstream" and 
> Debian is:
> 
> - It looks like Debian target users consuming software, users just 
> install a package and it works, no venv needed obviously, it always just 
> work, it's fantastic. Users may not even care if the program is written 
> in Python or not at this point.
> 
> - Upstream Python is obviously composed by people writing in Python and 
> know many people who write some Python too: all in need of venv to work.
> 
>> Also, it's a disservice to push our users into the direction of using
>> venv which is very ugly way to use Python in a Debian system
> I do agree, we could even replace Python with software in this sentence.
> 
> And I don't think we're pushing our users to always install things in 
> venvs. Providing venv is not a big signal for Debian users to ask them 
> to use it to install packages (if a signal at all).
> 
> With my "I do write things in Python that may run on non-Debian systems" 
> hat, and "I teach Python" (most of them not using Debian) hat, a venv is 
> helping me in many many ways, it's literally part of my daily routine:
> 
> - It allows me to pin a set of dependencies and sub-dependencies to an 
> exact version (I do use pip-compile, from pip-tools), per project, that 
> I can use in automatic tests (ensuring if tests passes today, they'll 
> pass tomorrow), I can share this set with coworkers and future me ("if 
> it works for me, it works for you"), note my coworkers may not use 
> Debian at all.
> 
> - It allows me to easily replace a dependency with a modified one to 
> test it, or make anyone else test it (for example [1]).
> 
> - It allows me to work on my Debian testing laptop on code aimed to work 
> on Debian stable, or a completly different OS.
> 
> - It allows me to work on various projects with a different set of 
> incompatible dependencies.

Wouldn't it be nicer if all of the dependencies you're talking about
were all playing well together? You're happy with venv and pip because
they address the huge problem that your dependencies are constantly
breaking the world. This needs to stop. Promoting venv and pip isn't
helping toward this goal, and that's what I was trying to say to begin with.

> I still think venv is a very usefull tool

It is. Because it addresses (badly) the brokenness of your dependencies,
as I wrote above.

> P.S.: If you still feel I'm completly wrong to use venv and pip in my
> workflow, I'll be very happy to learn better ways.

You are not. Though in an ideal world, you'd be only describing the list
of dependency you need, and the tooling would either fetch the Debian
package (if available) or through PyPi, and it would always work,
without ever needing to care about versions (here, from your side, with
pinning and version bounds), and without ever needing to isolate things
in a venv/chroot.

Cheers,

Thomas Goirand (zigo)



Re: upstream python concerns, python3-full package for bullseye

2021-02-12 Thread Thomas Goirand
Hi,

Looks like once more I've been not able to express myself clearly enough
in the first message. Hopefully, what's bellow contain *all* of my
thoughts, and that it brings value to this thread.

On 2/12/21 9:30 AM, Raphael Hertzog wrote:
> On Fri, 12 Feb 2021, Thomas Goirand wrote:
>> What I read from Elana, is that *upstream* think we have a problem. But
>> do we really have one? Or are we just being influenced by upstream who
>> is trying to impose a view we don't necessary share?
> 
> Or is it you that is trying to impose your view on those users?
> 
> Let's be clear, I understand what you are saying and I mostly agree
> with your view but Debian is about inclusiveness and about meeting
> the needs of as many people as possible and I believe that implementing
> this python3-full meta-package can only help towards this.

I mostly agree to add a metapackage. I just don't agree with the choice
of package name. It makes our user believe that Python isn't "full"
without it, and they then may install it when they don't need it to
consume whatever is packaged in Debian. Reality is different.

Also, it's a disservice to push our users into the direction of using
venv which is very ugly way to use Python in a Debian system, outside of
just testing something. You then end up with a variety of versions of
things pulled by pip, which are quickly unmanageable. That's why we do
package Python modules, and make sure they work well together
(sometimes, patching them to achieve this goal).

So, by all means, let's create a metapackage, and call it
"python3-addons-that-upstream-thinks-make-python-full" or anything you
like, but not just "python3-without-this-package-python-is-not-full",
misguiding our users to install venv and distutils which they don't need
if they are consuming only Python for things that we package already.

I'm also concerned that this is useful at all. If someone wants to use
venv, 2to3 or setuptools, I believe they will know how to fetch them...

Cheers,

Thomas Goirand (zigo)



Re: upstream python concerns, python3-full package for bullseye

2021-02-12 Thread Thomas Goirand
On 2/12/21 1:42 AM, stefa...@debian.org wrote:
> Hi Thomas (2021.02.12_00:11:07_+)
>> So indeed, it's a good thing to *not* include distutils and venv by
>> default when someone installs python.
> 
> ...
> 
>>> I propose that we add a python3-full* metapackage for
>>>   bullseye. (*We can use a different name, but it must be a name not
>>>   currently in use.)
>>
>> Please do not add distutils, venv and lib2to3 in this python3-full
>> metapackage. IMO that's falling into a design that isn't Debian. This
>> would probably be best in a "python3-dev-full" or something similar, as
>> from the distribution perspective, we see them as developer use only.
>> Don't confuse our users so that they install something they don't need.
> 
> From your arguments above, it doesn't sound like the python3-full solves
> a problem you experience. So, I'm not sure why you'd be using it.

I don't think I would. And to me, Python is already "full"(y supported)
without these. Though at least, adding "dev" in its name shows it's not
for our users.

> If it doesn't include distutils, venv, lib2to3, etc. then it doesn't
> solve any problem we currently have, and we don't need it. The purpose
> is to provide a package that gives you the entire stdlib.
> 
> SR

What I read from Elana, is that *upstream* think we have a problem. But
do we really have one? Or are we just being influenced by upstream who
is trying to impose a view we don't necessary share?

Cheers,

Thomas Goirand (zigo)



Re: upstream python concerns, python3-full package for bullseye

2021-02-11 Thread Thomas Goirand
Hi Elana,

Thanks for bringing this topic in the channel, and speaking with the
Python Steering Council, plus Mathias and Stefano. That's very much
appreciated.

On 2/11/21 7:12 PM, Elana Hashman wrote:
> - When users install Python, it should be easy to install all required
>   modules for what upstream considers core, including venv, distutils,
>   and lib2to3.

I understand that upstream python guys probably think the way to consume
python stuff is through venv, pip, and setuptools. I have a very
different view on this, and probably I'm not alone.

We (Debian people) indeed prefer if our user can enjoy a packaged
versions of things if they are available (and that's not specific to
Python). In such a packaged environment, venv and distutils are useless,
as the distribution is taking care of all what these tools would do
without apt or dpkg. I do prefer my system to *not* have venv support,
for example.

So indeed, it's a good thing to *not* include distutils and venv by
default when someone installs python.

As for lib2to3, is this a joke? Lib2to3 is a complete failure to begin
with. Upstream python developer naively thought everyone would just
switch at once to Python3, but it never happened, which is why things
like six exist (ie: to bring a layer of compatibility between python 2
and 3 during the transition).
Also, since we got rid of Python 2, is this a (naive) call to bring a
library that could convert old code which nobody cared to port in time?
This also will be a failure, IMO. Lib2to3 is just an utility, which has
nothing to do on a standard user computer, unless they really know what
it does and explicitly want to use it (and in that case, it's easy for
them to fetch it).

> I propose that we add a python3-full* metapackage for
>   bullseye. (*We can use a different name, but it must be a name not
>   currently in use.)

Please do not add distutils, venv and lib2to3 in this python3-full
metapackage. IMO that's falling into a design that isn't Debian. This
would probably be best in a "python3-dev-full" or something similar, as
from the distribution perspective, we see them as developer use only.
Don't confuse our users so that they install something they don't need.

Hoping that what I wrote is making sense,
Cheers,

Thomas Goirand (zigo)



Re: Downgrading dnspython back to 1.16.0 to fix Eventlet

2021-02-04 Thread Thomas Goirand
On 2/2/21 7:46 PM, Thomas Goirand wrote:
> Both Eventlet and DNSPython are monkey patching the standard SSL library
> in potentially conflicting ways
After checking, that's *NOT* the case. Though Eventlet is doing
monkey-patching of dnspython, in a possible not-compatible with 2.x.

Anyways, looks like this small patch fixes Eventlet with dnspython 2:

https://github.com/tipabu/eventlet/commit/2f9b7969f9a66a75e72908454246b88bf57fe58a

I've uploaded Debian release 0.26.1-5, and when it reaches the mirrors,
I'll try again to make OpenStack work, and see how it goes. If it fixes
everything, then we're good to go. Otherwise, my questioning about
downgrading dnspython to 1.16.0 still stand. I'll let you know.

Cheers,

Thomas Goirand (zigo)

P.S: Thanks to Tim Burke for this patch



Downgrading dnspython back to 1.16.0 to fix Eventlet

2021-02-02 Thread Thomas Goirand
Hi Scott, Robert,

As you may know, Eventlet is at the hart of OpenStack. Unfortunately,
version 0.26.1 currently in Sid/Testing fails when connecting over SSL,
with a traceback that looks like this:

  File "/usr/lib/python3/dist-packages/urllib3/connection.py", line 392,
in connect
self.ssl_context = create_urllib3_context(
  File "/usr/lib/python3/dist-packages/urllib3/util/ssl_.py", line 303,
in create_urllib3_context
context.options |= options
  File "/usr/lib/python3.9/ssl.py", line 602, in options
super(SSLContext, SSLContext).options.__set__(self, value)
  File "/usr/lib/python3.9/ssl.py", line 602, in options
super(SSLContext, SSLContext).options.__set__(self, value)
  File "/usr/lib/python3.9/ssl.py", line 602, in options
super(SSLContext, SSLContext).options.__set__(self, value)
  [Previous line repeated 458 more times]
RecursionError: maximum recursion depth exceeded (txn:
txad38d097c88545ecbd274-0060127626)

In OpenStack, this happens whenever a service attempts to validate a
Keystone token, meaning whenever any component connects to the OpenStack
API (in most deployments: this is done over SSL). In other words: all of
OpenStack is currently completely broken because of this.

Both Eventlet and DNSPython are monkey patching the standard SSL library
in potentially conflicting ways (for those who don't know: this means
they override the standard Python SSL objects/functions to re-write /
overload them).

This incompatibility is well known upstream. Some has been addressed in
Eventlet, but not all. Currently, Eventlet has:

'dnspython >= 1.15.0, < 2.0.0'

as dependency in upstream setup.py.

So I am currently wondering if we could revert DNSPython in Sid/Testing
to 1.16.0 until this is fixed upstream. That is, unless someone here in
this list knows how to fix Eventlet, but this looks like non-trivial...

Note that Ubuntu has version 2.0.0+really1.16.0-2ubuntu2, as they
understood the above.

Scott, Robert, your thoughts? Do you think it's ok to downgrade
dnspython? Or will it break some other reverse-dependencies? Is there
another way to fix the current situation?

Cheers,

Thomas Goirand (zigo)

P.S: The current reverse-dependency tree is:

Reverse-Recommends
==
* 2ping
* calibre
* dnstwist

Reverse-Depends
===
* ansible
* b4
* dehydrated-hook-ddns-tsig
* designate-tempest-plugin
* dhcpy6d
* dkimpy-milter
* dnsdiag
* dnsrecon
* dnsviz
* fierce
* knockpy
* linkchecker [amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x]
* mailman3
* patator
* python3-aioxmpp
* python3-authheaders
* python3-certbot-dns-rfc2136
* python3-designate
* python3-dkim
* python3-dnsq
* python3-electrum
* python3-email-validator
* python3-etcd
* python3-eventlet
* python3-exchangelib
* python3-formencode
* python3-kdcproxy
* python3-ldapdomaindump
* python3-sleekxmpp
* python3-spf
* recon-ng
* samba [amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x]



Re: gotchas when running tests via pybuild?

2021-01-24 Thread Thomas Goirand
On 1/22/21 6:06 PM, Antonio Terceiro wrote:
> Hi,
> 
> I'm working on python-eventlet, to fix a FTBFS bug and an
> incompatibility with python3.9. I got both fixes ready, but I'm not
> fighting with the fact that the test suite fails randomly. In my
> experiments, the test suite fails ~40% of the time, but *only when run
> during the build* (!!).
> 
> - I added a testsuite run to autopkgtest, and it consistently passes,
>   100% of the time.
> - If I run the same command as pybuild runs manually (python3 -m nose)
>   on a fully patched tree, it passes 100% of the time.
> - Only during the build -- when executed automatically by pybuild -- the
>   test fails ~40% of the time.
> 
> The failures are the typical failures you get when testing concurrency
> code: timeouts, race conditions, etc, and it happens on different tests
> every time. What I don't quite understand yet is why this _only_ happens
> during the Debian package build.
> 
> I already checked that the tests don't use anything else from the source
> tree beyond the tests themselves and the python modules. For example the
> autopkgtest copies tests/, and only it, to a temp directory and runs the
> tests from there; and works every time. So in principle I wouldn't need
> to have an explicit testfiles file.
> 
> Does anybody have an insight on cases like this? Are there any details
> that I'm missing?
> 
> If anyone wants to try it, the git repository is up to date.

Hi,

Eventlet looks broken beyond just the unit tests. I did a deployment of
OpenStack on unstable, and there's lots of issues on absolutely all
daemons. Hopefully, I can fine time to investigate this next week.

Cheers,

Thomas Goirand (zigo)



Re: sponsor uploading python-discogs-client_2.3.5-1

2020-12-15 Thread Thomas Goirand
On 12/14/20 11:43 PM, jojo wrote:
> On 11.12.20 10:03, jojo wrote:
>> Hi,
>> I updated a team-maintained package and am looking for an upload
>> sponsor. This one:
>> https://salsa.debian.org/python-team/packages/python3-discogs-client/-/tree/debian/2.3.5-1.
>> I already uploaded the package to my webserver:
>> https://jojo.peek-a-boo.at/E950513F/python-discogs-client_2.3.5-1.dsc
>>
>> I tried to find a sponsor on the irc channel #debian-python already. I
>> posted it in the channel and have been told to better just add it to
>> the topic of that channel. I didn't do that because I am an irc noob
>> and use the irc bridge on matrix.org to access irc rooms and didn't
>> find a way to do it yet. Just so you know.
> 
> I finally found out how to properly edit the topic via my matrix client
> and just have added python-discogs-client to the RFS list :-)

Uploaded.

Thanks for your contribution to Debian.

Cheers,

Thomas Goirand (zigo)



Re: Should Binaries provided by python-babel have a "python3-" prefix?

2020-11-27 Thread Thomas Goirand
On 11/27/20 1:13 PM, Simon McVittie wrote:
> A good way to decide this is to think about what we would do if we had a
> Python 4 that is incompatible with Python 3 (which I assume will happen
> eventually, although hopefully not for a few years).

It is very likely that you're wrongly guessing. Numerous times, the
Python upstream people wrote that the py2 to py3 transition was a bad
idea, and they will not do the same kind of mistake again, and that
there probably wont be a Python 4 anytime.

Which is why I thought merging the content of python3-babel and
python3-babel-localedata would be a good idea.

Cheers,

Thomas Goirand (zigo)



Re: Should Binaries provided by python-babel have a "python3-" prefix?

2020-11-26 Thread Thomas Goirand
On 11/26/20 1:16 PM, Nilesh Patra wrote:
> Hi,
> 
> Currently src:python-babel provides 3 binaries:
> 
> * python3-babel
> * python-babel-doc
> * python-babel-localedata
> 
> of which python3-babel is the main binary, -babel-doc is for the
> documentation and -babel-localedata is for storing locale data files
> used by python3-babel.
> 
> Should this be renamed to a "python3-" prefix for both binaries? They do
> not contain any actual code though
> 
> BTW this also has a RC bug, and I pushed the fix to salsa. If it needs a
> renaming, it'd be great if someone could upload it to NEW.
> 
> If not, I'll do a source-only-upload.
> Please let me know what you think of this.
> 
> Kind regards
> Nilesh

Hi,

It used to be that we had a python-babel that also needed the data in
python-babel-localedata, which was shared by both the Python 2 and 3
packages. Now, we don't have it anymore. So probably, what could be
done, is move all the files in python3-babel, and get rid of
python-babel-localedata completely.

python-babel-doc is still the correct package name for the doc (unless
the amount of doc is small and could be integrated in python3-babel as
well).

If that's the way to go, then python3-babel needs a Breaks+Replaces:
python-babel-localedata.

Cheers,

Thomas Goirand (zigo)



Re: Joining the team

2020-11-23 Thread Thomas Goirand
On 11/23/20 10:10 PM, Sandro Tosi wrote:
>>> First, an apology: it seems I misremembered being in the team, and uploaded 
>>> to
>>> NEW a bunch of packages with the team in `Uploaders`.
>>
>> Please put the team as Maintainer, and yourself as Uploaders.
> 
> why? that's not a requirement:
> https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#maintainership

Because joining a team, putting packages in them, and enforcing strong
ownership, is not logic at all. I know you like to do this way, but this
shouldn't be what we advise for new comers.

Cheers,

Thomas Goirand (zigo)



Re: Joining the team

2020-11-23 Thread Thomas Goirand
On 11/23/20 2:15 PM, nicoo wrote:
> Hi everyone!
> 
> First, an apology: it seems I misremembered being in the team, and uploaded to
> NEW a bunch of packages with the team in `Uploaders`.

Please put the team as Maintainer, and yourself as Uploaders.

Cheers,

Thomas Goirand (zigo)



Re: [Python-modules-team] Bug#954381: marked as done (python3-kubernetes: New upstream version available)

2020-11-21 Thread Thomas Goirand
On 11/21/20 3:36 AM, Sandro Tosi wrote:
>>* Use git to generate upstream tarball, as the PyPi module doesn't include
>>  the test folder. Using the gen-orig-xz in debian/rules, as using the
>>  repack function of debian/watch doesn't make sense (why downloading a
>>  tarball that would be later on discarded? I'm open to a better solution
>>  which would be uscan compatible though...). Switch d/watch to the github
>>  tag therefore.
> 
> you can track the github project instead of pypi (man uscan has the
> details); this is was i'm doing recently, as most of the time PyPI
> releases dont have all the files we need (tests, or test data, or
> documentation, or a combination of that)

Hi.

Thanks, I know that. However, that's not my problem. The issue is that
uscan --download will download the tarball from github, and I'd like to
replace that by what I'm doing in debian/rules, which is using git and
git submodule, to fetch things using git, and create a tarball. Sure, I
could use a repack script in debian/watch, but then uscan will continue
to first download the archive from github, and *then* only, I can
discard what's been downloaded, and fetch stuff from github with git.

Is there a solution here, so that uscan uses a repack script directly
without attempting to download first?

Cheers,

Thomas Goirand (zigo)



Re: Python 3.9 for bullseye

2020-11-09 Thread Thomas Goirand
On 11/9/20 10:19 AM, Matthias Klose wrote:
> https://bugs.debian.org/973239 src:python-fixtures

Does anyone else than me think it's probably OK to just disable to 2
broken tests?

Cheers,

Thomas Goirand (zigo)



Re: "pytest" command is missing

2020-11-05 Thread Thomas Goirand
On 11/4/20 9:27 PM, Novy, Ondrej wrote:
> Hi,
> 
> Antonio Terceiro píše v St 04. 11. 2020 v 14:01 -0300:
>> Could you ellaborate? Maybe we should have a discussion in the Python
>> team so that we implement consistent practices. For example, `gunicorn`
>> and `pip` now point to their python3 versions, but you are saying that
>> pytest will not do that, what maybe creates more confusion given Debian
>> bullseye will not support any other Python.
> 
> "pytest" in buster now points to python2 version of pytest and
> "pytest-3" points to python3 version. To prevent confusion after upgrade
> I want to keep one stable release with pytest cmd "unoccupied" and keep
> pytest-3.
> 
> Bullseye will support Python2 interpreter so user can keep python-pytest
> package installed from buster.

Moreover, simply invoking "pytest-3" is not enough, one should be using:

for pyvers in $$(py3versions -vr 2>/dev/null) ; do \
python$$pyvers -m pytest ; \
done

otherwise, only the default version of Python3 is tested, and we really
want to test with all available versions (so we get results whenever
we're transitioning to a new Python 3 version).

Cheers,

Thomas Goirand (zigo)



Re: How to watch pypi.org

2020-11-01 Thread Thomas Goirand
On 10/31/20 1:10 PM, Jeremy Stanley wrote:
> On 2020-10-31 12:03:50 +0100 (+0100), Thomas Goirand wrote:
> [...]
>> On 10/31/20 3:07 AM, Jeremy Stanley wrote:
>>> I have to agree, though in the upstream projects with which I'm
>>> involved, those generated files are basically a lossy re-encoding of
>>> metadata from the Git repositories themselves: AUTHORS file
>>> generated from committer headers, ChangeLog files from commit
>>> subjects, version information from tag names, and so on. Some of
>>> this information may be referenced from copyright licenses, so it's
>>> important in those cases for package maintainers to generate it when
>>> making their source packages if not using the sdist tarballs
>>> published by the project.
>>
>> Unfortunately, the FTP masters do not agree with you. I've been told
>> that the OpenStack changelog is a way too big, and it's preferable to
>> not have it in the binary packages.
> 
> PBR started creating much smaller changelogs years ago, after you
> asked ftpmaster. I get that you see no value in changelog files, but
> it seems like it would be worth revisiting.

Probably it'd be worth revisiting indeed, especially by finding a way to
push the logs only in the relevant -doc packages. Maybe by using the
same kind of trick which I want to do with the release notes (see
below), ie storing these files in the debian folder.

However, if I am to put more efforts on stuff like that, my priority
would be first on getting the reno release notes published in the Debian
package. I've been thinking about this for a long time, and haven't
figured out yet what would be the best way, with a reasonable workflow.

>From the Debian perspective, I'd have to:
- generate the release notes from the last version in Debian Stable, up
to what's in Sid. For example, I would include all the OpenStack release
notes for Stein, Train, Ussuri and Victoria in all packages uploaded for
Debian Bullseye, as this would concern anyone upgrading from Buster.
- make it so that release notes would be generated from Git, and maybe
stored in a debian/release-notes folder, so that it wouldn't generate a
diff with the original upstream tag.

The drawback would be that, on each upload of a new Debian revision, the
debian.tar.xz will contain the release notes, which could be of
significant size (especially if they include static objects like CSS,
JS, and all what makes a theme).

If you have any other suggestion concerning how to handle these release
notes, please let me know.

Cheers,

Thomas Goirand (zigo)



Re: How to watch pypi.org

2020-10-31 Thread Thomas Goirand
On 10/30/20 3:18 PM, Fioddor Superconcentrado wrote:
> As I said I'm very new to this and all (python) packages I'm using
> lately use the usual python tools (pipy, setup.py, etc) and my first
> approach has been to stick as close as possible to the upstream
> procedures. But I might very likely be taking a wrong decision. What are
> the reasons to go for git instead of pypi? I see that it is 'more
> upstream' but it seems that everyone else is pointing to pypi as a
> distro-agnostic solution.

Pypi is often thought as a Python module source repository. It is *NOT*.
It is a repository for binaries to be consumed by pip. Therefore, the
tarballs may omit some artifacts, and add some more. For example, it's
preferable that the sources do not include the egg-info folder, or
pre-generated documentation. These must be built from source.

On 10/31/20 3:07 AM, Jeremy Stanley wrote:
> I have to agree, though in the upstream projects with which I'm
> involved, those generated files are basically a lossy re-encoding of
> metadata from the Git repositories themselves: AUTHORS file
> generated from committer headers, ChangeLog files from commit
> subjects, version information from tag names, and so on. Some of
> this information may be referenced from copyright licenses, so it's
> important in those cases for package maintainers to generate it when
> making their source packages if not using the sdist tarballs
> published by the project.

Unfortunately, the FTP masters do not agree with you. I've been told
that the OpenStack changelog is a way too big, and it's preferable to
not have it in the binary packages. Also, there's nothing in the Apache
license that mandates having an AUTHORS list as per what PBR builds. If
we are to care that much in OpenStack, then the license must be changed.

In Debian, quite the opposite, and like it or not (I personally don't
really feel the policy is right, but that's how it is), what Debian
cares is what's in the source code marked with "copyright (c) yeah,
copyright-holder", and this must already be in debian/copyright.

Cheers,

Thomas Goirand (zigo)



Re: Python 3.9 for bullseye

2020-10-26 Thread Thomas Goirand
On 10/18/20 12:13 PM, Matthias Klose wrote:
> Python 3.9 as a supported Python3 version is now in unstable, and all binNMUs
> are done (thanks to Graham for the work).   Bug reports should be all filed 
> for
> all known problems [1], and the current state of the 3.9 addition can be seen 
> at
> [2] (a few of the "bad" are false packages with b-d n python3-all-dev, but not
> building for 3.9, bug reports also filed).
> 
> The major outstanding issue is the pandas stack, all other problems are found 
> in
> leaf packages (leaf in the sense of that no other package for the 3.9 addition
> is blocked).
> 
> Please help fixing the remaining issues!
> 
> Matthias

Hi Matthias,

I don't know if that was on purpose, but you happen to upload Python 3.9
in Unstable the day OpenStack was released. I then rebuilt all of
OpenStack to upload from Experimental to Unstable, and to my surprise,
it went very well (note: all packages in the OpenStack team are running
unit tests at build time on all available Python versions). Only 2
issues happened multiple times:
- base64.{en,de}codestring removal (easy fix: s/string/bytes/)
- Threading.isAlive removal (easy fix too: s/isAlive/is_alive/)

This happened

This is on a set of 200+ packages which I manually rebuilt.

I do expect that there will be more packages with the same issue, so
it'd be nice to have all Python-using packages rebuilt. As Lucas
Nussbaum proposed such a service, should we ask him to do such a massive
rebuilt? Or maybe you have other plans?

Cheers,

Thomas Goirand (zigo)



Re: Newcomers project: DPMT/PAPT pristine-tar verification

2020-10-09 Thread Thomas Goirand
On 10/3/20 9:35 PM, Sandro Tosi wrote:
> attached the dd-list of the packages missing the pristine-tar branch
> (some may have been moved/removed, but these are actual repos in DPT)

For those:

   python-etcd3 (U)
   python-requests-mock (U)
   python-sphinxcontrib.apidoc (U)

they in fact live in the OpenStack team namespace, but I don't have
enough rights to delete the Git repositories. Can someone do it for me
please?

There's 2 more for which I'm listed, I'll see if I can fix.

Cheers,

Thomas Goirand (zigo)



Re: mercurial switch to python3 in debian unstable - July 16th, 2020

2020-07-18 Thread Thomas Goirand
On 7/16/20 9:48 PM, Sandro Tosi wrote:
>> If we dont hear otherwise, we plan to upload the python3 version of
>> mercurial in unstable on or around next Thursday, July 16th.
> 
> mercurial/5.4.1-2 has just been uploaded to unstable, switching it to
> use python3.
> 
> Regards,

Thanks a lot for your work, on this specifically, and on the Python 2
removal in general.

I guess a lot of things are unlocked now. I wonder how we can help
fixing what's remaining. Please do share your thoughts on that.

Cheers,

Thomas Goirand (zigo)



Re: The python command in Debian

2020-07-17 Thread Thomas Goirand
On 7/16/20 6:03 PM, Sandro Tosi wrote:
> it is my opinion that that's what we should do: not ship `python` at
> all and have users/packagers/developers use either python2 or python3
> as needed, and not to reintroduce `python` at a later time.

I agree.

It's trivial for anyone to manually "fix" (or break?!?) a system to have
/usr/bin/python anyway, so let's not ship Debian as already broken. :)

Thomas



Re: joining team / salsa access

2020-07-17 Thread Thomas Goirand
On 7/17/20 8:21 AM, jojo wrote:
> On 16.07.20 15:01, Jojo wrote:
> 
>> Hi,
>>
>> I'd like to join the debian python modules and application teams to be
>> able to push my gbp packing sources to salsa.debian.org.
>>
>> I've read and understood https://wiki.debian.org/Python
>>
>> Packages are:
>>
>> - python3-discogs-client (using pristine tar)
>>   source package name: python-discogs-client
>>   ITP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961714
>>
>> - python3-webdavclient(using pristine tar)
>>   source package name: python-discogs-client
>>   ITP:https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961715
>>
>> - discodos (not using pristine tar)
>>   ITP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960698
>>
>> zigo was helping/mentoring the packaging and is about to do the final
>> reviews and ftp uploads.
>>
>>
> I forgot to mention that I already registered for an account on salsa:
> https://salsa.debian.org/jojo
> 
> all the best
> 
> Jojo

Unless someone opposes quickly, there's no need to wait 75 hours on this
case, as Jojo previously introduced himself in this list. He's been
doing good packaging work so far, and hopefully, his 3 packages will
soon make it to Debian.

Cheers,

Thomas Goirand (zigo)



Re: Request to join Python Modules Team

2020-07-16 Thread Thomas Goirand
On 7/15/20 12:02 PM, Ondrej Novy wrote:
> Hi,
> 
> út 14. 7. 2020 v 23:18 odesílatel Geert Stappers  <mailto:stapp...@debian.org>> napsal:
> 
> And please enlighten me (and us (through the mailinglist))
> what is holding back
>  https://lists.debian.org/debian-python/2020/07/msg00057.html
> 
> 
> huh, this is a bit rude.

I don't agree Geert is being rude. Besides that, I know Geert (from
Debconfs) to be a nice and polite person that isn't rude with others.

Please assume good faith.

Thomas Goirand (zigo)



Re: The python command in Debian

2020-07-14 Thread Thomas Goirand
On 7/9/20 9:31 PM, Ondrej Novy wrote:
> * keep "python" command pointing to python2.7 if I'm upgrading
> buster->bullseye with python2.7 installed. We are going to keep
> python2.7 interpreter for bullseye, so don't break old "python" command
> for third-parties apps/scripts/etc. (install python-is-python2 during
> buster->bullseye upgrade)

Please do break them. They are broken because they expect an interpreter
which we don't support anymore. So they MUST break. Leaving the distro
half-upgraded with the feeling that things are continuing to work is a
horrible design.

During the upgrade to bullseye, please do remove all things Python2,
including the interpreter, unless explicitly requested by the user (if
that's possible). If a user feels like he must install Python2, it must
be a manual decision (maybe after the upgrade and using /usr/local ?).
Otherwise, there's still Buster around for the next 4 years to come...

Cheers,

Thomas Goirand (zigo)



Re: pybuild vs os-pkg-tools [was: Maintaining all of the testing-cabal packages under the OpenStack team]

2020-07-08 Thread Thomas Goirand
On 7/7/20 8:20 AM, Ondrej Novy wrote:
> Hi,
> 
> po 6. 7. 2020 v 11:09 odesílatel Thomas Goirand  <mailto:z...@debian.org>> napsal:
> 
> This isn't about hating or loving pybuild. This is all about being able
> to control how this set of packages are build globally (the whole set of
> packages. 
> 
> 
> so you could wrap these global things around pybuild, right?

There would be no point doing that, as all what pybuild would be doing
(ie: setup.py install and unit testing), I'd be overriding it. The other
(IMO preferred) way would be to contribute to Pybuild to make it does
what's needed for these packages, and in a way so that we can also make
such global change for all OpenStack packages at once.

I've been thinking about it for a while, but my ideas aren't clear
enough to start something (yet).

Cheers,

Thomas Goirand (zigo)



Re: Timing of Python upstream and Debian releases

2020-07-08 Thread Thomas Goirand
On 7/6/20 9:04 PM, Matthias Klose wrote:
> Starting with Python 3.8, Python upstream changed to a time based yearly 
> release
> schedule, targeting the first release of a major Python version (3.x) for
> October of each year.  For the transition to 3.8:
> 
>  - we add 3.8 as supported in November
>  - made 3.8 the default in March
>  - dropped 3.7 in April
> 
> That's a little bit late looking at the Debian release schedule, so a little
> speedup would be needed if we want to target the current Python release for 
> the
> current Debian release.  For 3.8 Ubuntu started to prepare the switch a bit
> earlier, using the results for a better experience in Debian:
> 
>  - added 3.8 in mid October
>  - made 3.8 the default in mid December
> 
> Technically it would be possible to do the defaults change before the Debian
> freeze, however there's usually a tail of follow-up upstream releases required
> to support a new major Python version, unless you opt for actively backporting
> changes in various packages.  Having the confidence, that the switch is 
> feasible
> in another distro certainly helps doing the transition in Debian, however it
> adds a delay.  I don't think it's feasible to do the transition in 
> experimental
> first, or doing a large test rebuild, because it requires keeping the whole
> python stack in sync with testing/unstable.
> 
> So what I'm proposing here is to aim to support 3.9 as early as possible as a
> supported Python3 version, starting with the 3.9 upstream release, and fixing
> stuff on the go.  Then decide in November, if we can do the defaults change to
> 3.9, or if we drop 3.9 again, or ship with two supported Python3 versions.

This looks reasonable, thanks for opening the discussion and doing the
hard work. However, I wouldn't be for shipping 2 supported versions, and
would prefer if we could have only one if possible, as otherwise this
means running unit tests at build time against 2 python versions, which
then takes twice as much build time: that's annoying and useless
(because at the end, only one of these versions will be in use).

Cheers,

Thomas Goirand (zigo)



Re: pybuild vs os-pkg-tools [was: Maintaining all of the testing-cabal packages under the OpenStack team]

2020-07-06 Thread Thomas Goirand
On 6/29/20 8:34 AM, Ondrej Novy wrote:
> for my packages (i'm uploader): no, sorry.
> 
> Reasons:
> 1. I hate openstack-pkg-tools
> 2. I like pybuild
> 3. you hate pybuild and don't want to use it

I thought about this for a long time, thinking if I should leave it
unanswered or not. Finally, I have the opinion I can't let it blank.

You are so focus on nit-picking cosmetic fixes, that you are failing to
see the big picture. The same way Daniel did when he told me that
pybuild is "superior" and that I shouldn't waste my time working on my
own tooling. At least 2 others also asked, so maybe it's time to explain.

This isn't about hating or loving pybuild. This is all about being able
to control how this set of packages are build globally (the whole set of
packages. Let me explain why this is important using 3 examples, and
hopefully you'll get where I am at.

A few OpenStack releases ago, most packages migrated away from
testrepository to stestr. For good, because I believe stestr is better.
Anwyay, that's not the point. The point is, the only thing I had to do
to fix it, was to fix pkgos-dh_auto_test, and in there, check if a
.stestr.conf is present. If it is there, pkgos-dh_auto_test just use stestr.

The same way, some packages need to be installed, with a correct
egg-info and entrypoint, otherwise, unit tests are failing. So I could
change that in openstack-pkg-tools.

A 3rd example from last week: now, when unit tests are failing,
openstack-pkg-tools displays the output of "pip3 freeze", so I can do
report upstream more easily.

Each time, for all of these changes, I had to do a single unique change,
in a single place, without affecting other packages in the archive.

Hoping this explains well enough my choice, so that it makes sense to
everyone.

Cheers,

Thomas Goirand (zigo)



Re: Maintaining all of the testing-cabal packages under the OpenStack team

2020-06-30 Thread Thomas Goirand
On 6/30/20 12:41 AM, Jeremy Stanley wrote:
> On 2020-06-29 23:55:49 +0200 (+0200), Thomas Goirand wrote:
> [...]
>> nodepool from OpenStack,
> 
> Well, *formerly* from OpenStack, these days Nodepool is a component
> of the Zuul project gating system, which is developed by an
> independent project/community (still represented by the OSF):
> 
> https://zuul-ci.org/
> https://opendev.org/zuul/nodepool/
> 
> You could probably run a Nodepool launcher daemon stand-alone
> (without a Zuul scheduler), but it's going to expect to be able to
> service node requests queued in a running Apache Zookeeper instance
> and usually the easiest way to generate those is with Zuul's
> scheduler. You might be better off just trying to run Nodepool along
> with Zuul, maybe even set up a GitLab connection to Salsa:
> 
> https://zuul-ci.org/docs/zuul/reference/drivers/gitlab.html
> 
>> and use instances donated by generous cloud providers (that's not
>> hard to find, really, I'm convinced that all the providers that
>> are donating to the OpenStack are likely to also donate compute
>> time to Debian).
> [...]
> 
> They probably would, I've approached some of them in the past when
> it sounded like the Salsa admins were willing to entertain other
> backend storage options than GCS for GitLab CI/CD artifacts. One of
> those resource donors (VEXXHOST) also has a Managed Zuul offering of
> their own, which they might be willing to hook you up with instead
> if you decide packaging all of Zuul is daunting (it looks like both
> you and hashar from WMF started work on that at various times in
> https://bugs.debian.org/705844 but more recently there are some
> JavaScript deps for its Web dashboard which could get gnarly to
> unwind in a Debian context).

Hi Jeremy,

I gave up a few times, because the reverse dependencies for it were not
aligned with what was in use in Debian at the time, and gave up.

If there's some nasty NPM job behind, then I probably will just skip the
dashboard, and expect deployment to get the dashboard not from packages.
What is included in the dashboard? Things like https://zuul.openstack.org/ ?

Cheers,

Thomas Goirand (zigo)



Re: Maintaining all of the testing-cabal packages under the OpenStack team

2020-06-29 Thread Thomas Goirand
On 6/29/20 7:35 PM, Utkarsh Gupta wrote:
>> Running the script shows that 279 reverse (build?) dependencies are
>> affected by mock. This clearly isn't something one wants to run on a
>> personal computer, and even less a test which one wants to run sequentially.
> 
> Haha, right.
> What we (me and a couple others) do is run this build script on a
> server (via screen) and call it a night :P
> And we get the list of broken packages in the morning!
> 
> But of course, this is not a very "professional" way of doing it.

What we could do, is use nodepool from OpenStack, and use instances
donated by generous cloud providers (that's not hard to find, really,
I'm convinced that all the providers that are donating to the OpenStack
are likely to also donate compute time to Debian). And then we could
launch 150 builds at a time on 150 VMs. Then the time to wait is only
the time of the longest build.

>> Has any thought went into having some kind of runners running on a cloud
>> to run these tests, and maybe plug this into Salsa's CI to run it
>> automatically?
> 
> This seems to be a nice idea!
> I am not sure if someone had the time or energy to do this, but this
> is something we'd definitely love \o/

To get this to happen, we have no other way but using the power of some
kind of cloud / HTC.

>> I'd very much would love to set this up, at least as a first
>> experimentation on a bunch of package of the DPMT.
> 
> Me too!

I shall resume packaging nodepool then...

Cheers,

Thomas Goirand (zigo)



Re: Maintaining all of the testing-cabal packages under the OpenStack team

2020-06-29 Thread Thomas Goirand
On 6/29/20 2:33 PM, Utkarsh Gupta wrote:
> There exists such a thing which I use daily: ruby-team/meta[1].
> The meta/build script is (hopefully and exactly) what we need here!
> 
> It checks all the reverse(-build)-dependencies and lets you know what's
> going to break as soon as you dput.

Hi Utkarsh,

Nice! Thanks a lot for the pointer.

I very much agree with you that the debate has to be emptied from
emotions if possible. My goal has never been to point finger at anyone,
but try to fix a reoccurring situation which I would like to avoid.

Running the script shows that 279 reverse (build?) dependencies are
affected by mock. This clearly isn't something one wants to run on a
personal computer, and even less a test which one wants to run sequentially.

Has any thought went into having some kind of runners running on a cloud
to run these tests, and maybe plug this into Salsa's CI to run it
automatically?

I'd very much would love to set this up, at least as a first
experimentation on a bunch of package of the DPMT.

Your thoughts?

Cheers,

Thomas Goirand (zigo)



Re: Maintaining all of the testing-cabal packages under the OpenStack team

2020-06-29 Thread Thomas Goirand
On 6/29/20 12:58 PM, Scott Kitterman wrote:
> On June 29, 2020 10:12:49 AM UTC, Thomas Goirand  wrote:
>> On 6/29/20 8:34 AM, Ondrej Novy wrote:
>>> nope, this is not true. Using the newest debhelper compat level is
>>> recommended, see man page. There is no reason to __not__ upgrade
>>> debhelper compat level. I will always upgrade debhelper in my
>> packages
>>> to the newest debhelper as soon as possible. Please newer downgrade
>>> debhelper in my packages again without asking.
>>
>> I don't agree this is best practice when backports are to be expected.
> 
> I'm substantially less enthusiastic about bumping compat levels than
> Ondrej, but since debhelper 13 is available in buster-backports,> backporting 
> is unrelated to whether it's a good idea or not.

I'm not maintaining OpenStack through the official backports channel,
because OpenStack users need to have access to all versions of OpenStack
backported to the current Stable. These backports are available through
a debian.net channel (available using extrepo).

Therefore, the debhelper backport is not available in my build
environment unless I explicitly do some work to make this happen (and
Ondrej is aware of that). Just bumping the debhelper version (and
without a good reason to do so) just add some unnecessary work
maintaining the debhelper backport for me. By all means, let's bump to
version 12. But why version 13 if you don't need the added features?
This makes no sense to me.

Cheers,

Thomas Goirand (zigo)



Re: Maintaining all of the testing-cabal packages under the OpenStack team

2020-06-29 Thread Thomas Goirand
On 6/29/20 8:34 AM, Ondrej Novy wrote:
> Ondrej, you once cared for the OpenStack packages. Why are you now
> completely careless?
> 
> 
> because it's really hard to cooperate with you. I already tried to
> explain it to you but you didn't listen.

You're mixing 2 things: working on OpenStack package, and caring not to
break them. I'm just asking for the later.

On 6/29/20 8:34 AM, Ondrej Novy wrote:
> yep, that's how it works. We need to move forward and don't keep old,
> buggy and unmaintained packages in Debian, right?

If I'm getting this right, not only you break things (which is ok, if it
isn't on purpose), but now claim that this is the right thing to do. No,
this is not how Debian works, it never was, and hopefully, never will.

> More over, mock debhelper was upgraded to 13, for no apparent reason
> (yet another "cosmetic fix" that isn't helping?). I'd like to remind
> everyone that, increasing debhelper compat version to a number that
> isn't in stable, without a specific reason (like the need of a specific
> feature that wasn't there before) is just annoying for anyone
> maintaining backports. That's truth even for when debhelper itself is
> backported to oldstable (it's always nicer to be able to build a
> backport without requiring another backport at build time).
> 
> nope, this is not true. Using the newest debhelper compat level is
> recommended, see man page. There is no reason to __not__ upgrade
> debhelper compat level. I will always upgrade debhelper in my packages
> to the newest debhelper as soon as possible. Please newer downgrade
> debhelper in my packages again without asking.

I don't agree this is best practice when backports are to be expected.

Cheers,

Thomas Goirand (zigo)



Re: Maintaining all of the testing-cabal packages under the OpenStack team

2020-06-28 Thread Thomas Goirand
On 6/28/20 7:59 PM, Sandro Tosi wrote:
>> Is anyone from the team opposing to this?
> 
> Yes, i'm against your proposal.
> 
>> If so, please explain the
>> drawbacks if the OpenStack team takes over.
> 
> 1. you're personally attacking Ondrej, who is one of the very few
> members of this team doing team-wide work, and that should be enough
> to reject it
> 2. this is clearly an hostile take-over (even if you frame it as a
> proposal), and that should be enough to reject it
> 3. you propose to only update those packages every 6 months, i dont
> find it appropriate: OS is *just* another software we package for
> Debian; is it complex? sure, but it's not special, and it doesnt
> warrant any special treatment.
> 4. you clearly want to have sole and absolute control of the packages
> in the openstack-team, because what would happen if a os-team member
> will upgrade one of those packages (in good faith) and things will
> break? will they get another "well done! :( " email from you?
> 4.1. You wonder why Ondrey "stopped caring" about OS, if that's the
> case, i could see why
> 5. consolidating packages *into* the DPMT/PAPT gives a lot of
> benefits, f.e. people basically got "free" handling of the py2removal
> process; moving packages out is actually detrimental for the python
> ecosystem (at least that's my opinion).
> 
> Thomas, this is not the first time your temperament and aggressive
> behavior is causing some troubles, please reassess how you interact
> and work with other fellow contributors.

Sandro,

I'm sorry if the tone was inappropriate. It probably was. Though it's
not *that* harsh toward Ondrej. At least, it's really FAR from the
hostile behavior he had toward me last summer during debconf, after I
fixed 40 Django RC bugs (due to Django python2 removal), for which I was
thank with threatens.

What I'm painting of what happened is the reality. Let me explain. In
OpenStack, we have this repository:

https://github.com/openstack/requirements/

in this, you'll see the upper-constraints.txt file. This sets pinning
for the current release of OpenStack, which evolves at the same time as
the project. It's updated often during a cycle of 6 months before a
release, then it is frozen for the release. Right now, the stable/ussuri
branch matches what we have in Sid (so one should be looking at that).
Ondrej used to carefully check for this before doing any upload, as I
mentored him to do so. Now he apparently does not care anymore. Call it
personal attacks if you wish, I still don't think this is right.

When you write that:
> "OS is *just* another software we package for Debian; is it complex?
> sure, but it's not special, and it doesnt warrant any special
> treatment."

I don't agree with you here. Absolutely all of the other distributions
that include OpenStack are making sure that nothing breaks it by
careless uploads of not compatible releases of Python modules. Ubuntu
does it, Red Hat as well. Just in Debian, nobody cares but the
maintainers of OpenStack itself.

In fact, let me expand this further, because that's not the first time
I'm raising this issue: we do not threat Python libraries as candidate
for transitions enough, are countless uploads breaks the world of many.
One very good example would be Django, and in the past we had also
SQLAlchemy (though upstream got better for SQLA, so there's less
problems with that one). So yeah, OpenStack shouldn't have any special
treatment *IF* we care enough not breaking things when we update packages.

It'd be nice if we had a framework to be able to rebuild all reverse
build-dependency when we update a package. But currently, we don't have
such CI. If one volunteers to write it, probably we can find some
compute resources to make it happen. That's probably the way out, and
IMO we should really all think about it.

Now, please read what Jeremy wrote, and understand that these package
are really related to OpenStack. Given the fact that these packages are
tightly coupled with OpenStack, it does make sense.

Also, given how often Debian is released (every 2 years, these days?),
updating packages every 6 months doesn't seem that bad, especially if
you consider the set of packages that I'm talking about. They aren't
updated that often upstream.

Please take a step back and understand what's going on. What I would
like to happen, is making sure that things don't break, and currently,
this isn't the case with this set of packages. And this isn't the first
time. So I'm proposing to take measures to make this stop. If you feel
it's a hostile take over, then ok we shall find another way. But then
What is your proposal so that it doesn't happen anymore then?

Cheers,

Thomas Goirand (zigo)



Maintaining all of the testing-cabal packages under the OpenStack team

2020-06-28 Thread Thomas Goirand
Hi,

Under a single Github account, the below packages are maintained:
- mock
- subunit
- testtools
- fixtures
- funcsigs (deprecated, py2 backport)
- testresources
- traceback2
- testscenarios
- testrepository
- extras
- linecache2

Currently, these packages are maintained by a variety of DDs, and
there's no uniform maintenance of them.

The last upload of mock 4.0.2, by Ondrej, broke *a least*:
- nova (see: #963339)
- cloudkitty (see: #963069)
- congress (see: #963312)
- rally (see: #963381)

All of the 4 packages above were able to build in Bullseye (ie: mock
3.0.5) and FTBFS in Sid (with mock 4.0.2).

Well done! :(

Obviously, these couldn't be tested with Mock 4.x at the time of the
last OpenStack freeze, because Mock 4.x didn't exist. However, OpenStack
regularly increases the dependency versions and tries to stay current,
so no blame to be put on OpenStack upstream, just on mock package
maintenance here.

Ondrej, you once cared for the OpenStack packages. Why are you now
completely careless?

More over, mock debhelper was upgraded to 13, for no apparent reason
(yet another "cosmetic fix" that isn't helping?). I'd like to remind
everyone that, increasing debhelper compat version to a number that
isn't in stable, without a specific reason (like the need of a specific
feature that wasn't there before) is just annoying for anyone
maintaining backports. That's truth even for when debhelper itself is
backported to oldstable (it's always nicer to be able to build a
backport without requiring another backport at build time).

I don't want this to happen again. So I am hereby asking to take over
the maintenance of these packages which aren't in the OpenStack team.
They will be updated regularly, each 6 months, with the rest of
OpenStack, following the upstream global-requirement pace. I'm confident
it's going to work well for me and the OpenStack team, but as well for
the rest of Debian.

Is anyone from the team opposing to this? If so, please explain the
drawbacks if the OpenStack team takes over.

Cheers,

Thomas Goirand (zigo)



Re: DebCond20 @ Home -- Python Team Bof & Sprint ?

2020-06-26 Thread Thomas Goirand
On 6/25/20 3:13 AM, Louis-Philippe Véronneau wrote:
> Hello folks!
> 
> As some of you might have seen, DebConf20 @ Home will be happening end
> of August.
> 
> I was wondering if others would be interested in having a Python Team
> BoF to talk about ongoing work/issues (the Python 2 removals comes to my
> mind but I'm sure there are other discussion-worthy topics).
> 
> If there is interest, I'd be happy to submit something to the DebConf
> Content team.
> 
> Maybe it would also be good to set aside half a day during the conf
> (preferably after the BoF) for a sprint to try and fix things?

+1 to both proposal (ie: BoF + sprint)

Thomas



Re: Help fixing #959558 (case: FTBFS: AttributeError: 'tuple' object has no attribute 'lstrip' with sphinx 2.4)

2020-05-29 Thread Thomas Goirand
On 5/27/20 11:26 AM, Dmitry Shachnev wrote:
> Hi all!
> 
> On Tue, May 26, 2020 at 05:06:16PM -0400, Scott Talbert wrote:
>> On Tue, 26 May 2020, Thomas Goirand wrote:
>>> Hi there!
>>>
>>> Does any of you knows how to fix this bug?
>>> https://bugs.debian.org/959558
>>>
>>> Almost all of OpenStack can removed from Bullseye if not fixed in time,
>>> so I tried to fix, but couldn't.
>>
>> It looks like it's a bug in sphinx.  I tried sphinx 3.0.4 and it seems to
>> work fine.  2.4.4 still has the problem, however.
>>
>> Dmitry, do you plan to update to sphinx 3.0.x soon?
> 
> 3.x won't happen soon, but I will fix this bug in the next Sphinx 2.4 upload.
> 
> --
> Dmitry Shachnev

Hi Dmitry,

I stayed quite about this, though today, I'd like to thanks you a lot
for your prompt action fixing this bug! Much appreciated. :)

Cheers,

Thomas



Help fixing #959558 (case: FTBFS: AttributeError: 'tuple' object has no attribute 'lstrip' with sphinx 2.4)

2020-05-26 Thread Thomas Goirand
Hi there!

Does any of you knows how to fix this bug?
https://bugs.debian.org/959558

Almost all of OpenStack can removed from Bullseye if not fixed in time,
so I tried to fix, but couldn't.

Cheers,

Thomas Goirand (zigo)



Re: packaging DiscoDOS - a cli tool for vinyl DJs

2020-05-19 Thread Thomas Goirand
On 5/18/20 11:24 AM, jojo wrote:
> One private question: What do you use? I remember that back then when I
> found out that Debian stable is pretty oldish I was always using
> testing. My teamleader recently told me that he's actually using
> unstable these days and prefers it over testing. I think if one wants
> halfway modern software there is only two options: Use Ubuntu(ish) or
> use Debian unstable? Right?

I use Debian Stable, and whenever I need something new (which is very
rare), then I do my own backports.

> Thanks so much for all this hints

My pleasure.

> One question: Often I
> read the workflow is to first create a source package and then the
> binary package from it. Is that true for python tools as well?

Yes.

> I mean
> there is no "source/binary" in this sense.

There is. I am not sure I understand...

> And this does not seem to be
> a source package but a regular package I would install as user using
> apt: https://salsa.debian.org/python-team/applications/rename-flac.git

This git is using pristine-tar, just like everything else within the
Python team. The debian/master branch contains the upstream sources plus
the Debian folder. This really is a source package repository.

> I guess I knew the answer already ;-) IMHO it's a shame that Discogs is
> not responsive at all to pull-requests in the last ~1-2 years, I would
> rather prefer if I package the official discogs_client (really
> maintained by discogs.com themselves) but to complete my task, I will
> just package my fork because it just works and has two features that I
> just require.

Best is if you can package upstream code, and add your specific patches
in debian/patches, so that they are well identified.

> Anyway, tell me what you think: First package my fork to get things
> done, then ask discogs.com if they want to be in debian and I would do
> it if they would finally work on some of the pulls that are open for
> almost "years" already.

Hopefully that works. I can't tell though, you'll see!

>> You're talking about joining the list. But what about the Python APP
>> team? Do you intend to join it?
> 
> I think I still don't understand the difference between "being on the
> debian-python list" and joining the "python app packagning team". Please
> elaborate again! Most of all: What exactly would it mean if I "join the
> team".

Joining the list only means your receive messages from it. Joining the
team means you become a member of the Salsa Python APP group. We ask
people to first read our policy about it, and agree with it. Then you
can ask to join. If you're accepted, then you get write access to the
Git directly (and you can create new projects too).

Cheers,

Thomas Goirand (zigo)



Re: Bug#953970: Taking over DPMT (Was: python-boto: autopkgtest failure with Python 3.8 as default)

2020-05-16 Thread Thomas Goirand
On 5/16/20 11:02 AM, Andreas Tille wrote:
> On Mon, May 11, 2020 at 10:20:24PM -0400, Noah Meyerhans wrote:
>> Control: tags -1 + patch
>>
>>> I'll move this package to a cloud-team repository and prepare an upload
>>> to unstable on Monday if nobody beats me to it.
>>
>> https://salsa.debian.org/cloud-team/python-boto/-/merge_requests/1
> 
> Could somebody from the cloud-team please merge and upload?
> I'm not a member of this team and can not do anything here.
> 
> Thanks a lot
> 
> Andreas. 
> 

Merged, built and uploaded.

Cheers,

Thomas Goirand (zigo)



Re: packaging DiscoDOS - a cli tool for vinyl DJs

2020-05-16 Thread Thomas Goirand
On 5/16/20 3:36 AM, Paul Wise wrote:
> Would it be fair to say that your main objection is that Ubuntu has
> much higher popularity than Debian

This is what I regret, indeed. It's been like that for many years, and
the trend isn't reversing. We should ask ourselves why. From my point of
view, I see it as a problem of marketing more than OS content or
technical excellence.

> and so the Ubuntu policy to work
> upstream where possible leads people to come to Debian without
> necessarily caring about the Debian community or users but more about
> Ubuntu users?

We are lucky this happens.

> Personally, I think over the years Ubuntu's Debian involvement has
> been a net positive for Debian

Indeed.

> both in terms of packaging and other
> technical changes and in terms of attracting new contributors, often
> Ubuntu migrants end up contributing to Debian more than Ubuntu. I
> think the same goes for derivatives in general.

That's truth. I am very thankful for Canonical to contribute things like
Grub, Python, MySQL and many other things directly in Debian. It's very
nice that some full time employees can take care of stuff like that.
It's also nice that some components are explicitly worked on to be the
same in both distros. I also like the fact that they push contributors
to work on upstream Debian.

Never the less, I've seen multiple occurrences where some people vaguely
knew what Ubuntu was, but never heard of Debian. Saw others saying wrong
things, like Ubuntu was updating faster (which is wrong, as packages are
updated in Sid first). And many other things of that type. Isn't it
legitimate that I'm asking myself why? Shouldn't the Debian project try
to question its image?

Cheers,

Thomas Goirand (zigo)



Re: Disparaging people's motivation to contribute to Debian was: Re: packaging DiscoDOS - a cli tool for vinyl DJs

2020-05-16 Thread Thomas Goirand
On 5/15/20 10:42 PM, Scott Kitterman wrote:
> On Friday, May 15, 2020 4:36:52 PM EDT Thomas Goirand wrote:
>> On 5/15/20 7:09 PM, Scott Kitterman wrote:
>>> On Friday, May 15, 2020 12:55:48 PM EDT Thomas Goirand wrote:
>>>> On 5/15/20 5:43 PM, jojo wrote:
>>>>> Hi,
>>>>>
>>>>> I'd like to join the list because I think my software is a valuable
>>>>> addition to the debian universe, my ultimate goal would be to bring it
>>>>> into Ubuntu Studio because it is music-related.
>>>>
>>>> I really think it's a shame that people join Debian just because of
>>>> Ubuntu... :(
>>>
>>> Thomas,
>>>
>>> Ask yourself if you are modelling being a member of a welcoming community
>>> here?
>>>
>>> There are lots of examples of people who initially became interested in
>>> Debian via Ubuntu and are good Debian contributors and project members.
>>>
>>> You are free to think whatever you want, but I don't think this kind of
>>> sentiment has any place on Debian lists.
>>>
>>> Scott K
>>
>> This was kind of rhetorical, and it is my believe that if it is the way
>> it is, *we* are at fault, globally in Debian. I'm just not sure how to
>> fix that. I BTW don't agree with you, and IMO, this has some place on
>> the Debian lists. Having Debian (directly) appealing to everyone is very
>> important topic.
>>
>> Of course, Jojo is very much welcome, and I'm sorry that you take it
>> this way. I've pointed at many docs to help, so I very much believe he
>> knows I warmly welcome him.
>>
>> Cheers,
>>
>> Thomas Goirand (zigo)
> 
> If you don't actually think it's a shame he wants to participate in Debian, 
> it 
> might be better not to say so.

I should be more careful with my choice of words.

If I'm not mistaking, in English, "it's a shame" can have 2 meanings.
One is like "shame on you", which isn't what I meant. The other one is
"I regret that", which was what I originally wanted to say.

Does it make more sense now?

Cheers,

Thomas Goirand (zigo)



Re: packaging DiscoDOS - a cli tool for vinyl DJs

2020-05-15 Thread Thomas Goirand
On 5/15/20 7:09 PM, Scott Kitterman wrote:
> On Friday, May 15, 2020 12:55:48 PM EDT Thomas Goirand wrote:
>> On 5/15/20 5:43 PM, jojo wrote:
>>> Hi,
>>>
>>> I'd like to join the list because I think my software is a valuable
>>> addition to the debian universe, my ultimate goal would be to bring it
>>> into Ubuntu Studio because it is music-related.
>>
>> I really think it's a shame that people join Debian just because of
>> Ubuntu... :(
> 
> Thomas,
> 
> Ask yourself if you are modelling being a member of a welcoming community 
> here?
> 
> There are lots of examples of people who initially became interested in 
> Debian 
> via Ubuntu and are good Debian contributors and project members.
> 
> You are free to think whatever you want, but I don't think this kind of 
> sentiment has any place on Debian lists.
> 
> Scott K

This was kind of rhetorical, and it is my believe that if it is the way
it is, *we* are at fault, globally in Debian. I'm just not sure how to
fix that. I BTW don't agree with you, and IMO, this has some place on
the Debian lists. Having Debian (directly) appealing to everyone is very
important topic.

Of course, Jojo is very much welcome, and I'm sorry that you take it
this way. I've pointed at many docs to help, so I very much believe he
knows I warmly welcome him.

Cheers,

Thomas Goirand (zigo)



Re: packaging DiscoDOS - a cli tool for vinyl DJs

2020-05-15 Thread Thomas Goirand
On 5/15/20 5:43 PM, jojo wrote:
> Hi,
> 
> I'd like to join the list because I think my software is a valuable
> addition to the debian universe, my ultimate goal would be to bring it
> into Ubuntu Studio because it is music-related.

I really think it's a shame that people join Debian just because of
Ubuntu... :(

> I already filed a bug report against the wnpp pseudo package but I am
> not quite sure what would be the next step and which packaging guides it
> is best to follow to get started with packaging and finally uploading
> it.

IMO, the best thing to start with is the packaging tutorial:
apt-get install packaging-tutorial

It's nicely written. Then you should read the Debian Policy Manual.
Finally, search and read the python policy (in the wiki?) if your app is
Python based.

> Should my next step be following this tutorial on packaging?
> https://packaging.ubuntu.com/html/packaging-new-software.html

This guide talks about bzr. It's not in use anywhere these days, even
Ubuntu people don't use it anymore. It's also Python 2 only, and
therefore, we removed it from Debian.

IMO, you should install sbuild to start with:
https://wiki.debian.org/sbuild

and then go from the above. Note that I don't think using dh_make is a
good idea. It's IMO nicer to just take another Python app as example.
Look at the team's Git for that.

> Also some other questions arise as my tool has a dependency that I am
> pretty sure is not in debian already. the official discogs_client - a
> python sdk to access discogs.com rest api, and actually I forked and
> extended it. pull-request to official repo is pending:
> https://github.com/JOJ0/discogs_client

Well, if you need it for your app, then it must be packaged in Debian as
well if you intend to depend on it.

> Well enough already, let's discuss stuff when I am on the list :-)

You're talking about joining the list. But what about the Python APP
team? Do you intend to join it?

Thanks for your interest in Debian packaging and your intention to
package your app,
Cheers,

Thomas Goirand (zigo)



Re: Bug#937769: getting python-linecache2/python-traceback2 fixes into testing (FAO traceback2, funcsigs nipype and numba maintainers).

2020-04-22 Thread Thomas Goirand
On 4/22/20 6:23 AM, Valentin Vidić wrote:
> On Tue, Apr 21, 2020 at 11:20:16PM +0200, Thomas Goirand wrote:
>> You can remove all of the python-oslo* from the list. The versions in
>> Experimental, which are the next version of OpenStack, are fixed. In 2
>> weeks of time, I'll upload all what I staged in Experimental to Sid
>> (maybe 150 packages?) and that's going to fix it all.
> 
> Will the new OpenStack version also fix this issue?
> 
> #955116 python-murano-pkg-check: FTBFS with Sphinx 2.4: AttributeError:
> 'Sphinx' object has no attribute 'info'

Hopefully yes. As I understand, the issue is in oslo-sphinx, which is
deprecated. I checked, and the master branch of murano-pkg-check doesn't
use oslo-sphinx (and is therefore fixed). I'm waiting for it to be
released, hopefully this week or the next one.

Cheers,

Thomas Goirand (zigo)



Re: Bug#937769: getting python-linecache2/python-traceback2 fixes into testing (FAO traceback2, funcsigs nipype and numba maintainers).

2020-04-21 Thread Thomas Goirand
On 4/20/20 2:51 PM, peter green wrote:
> On 20/04/2020 08:57, Thomas Goirand wrote:
>>> Option 1: fix all four packages to be python 2 free.
>>>
>>> Option 2: Remove python2 stuff from traceback2, python-funcsigs and
>>> numba. Break the dependencies of nipype in sid.
>>>
>>> Option 3: Remove python2 stuff from traceback2, modify python-funcsigs
>>> so it still builds the python2 package but does not run tests with
>>> python 2.
>> Funcsigs is a backport of the PEP 362 function signature features from
>> Python 3.3's inspect module.
> Thanks for the info.
>> Python 2 has never been removed from this
>> package. Though instead, we shall remove this source package entirely
>> from Debian.
> # Broken Depends:
> nipype: python-nipype
> pytest: pypy-pytest
> python-logfury: python3-logfury
> python-oslo.utils: python3-oslo.utils
> 
> # Broken Build-Depends:
> beaker: python3-funcsigs
> kombu: python3-funcsigs
> nipype: python-funcsigs
> pagure: python3-funcsigs
> pytest: pypy-funcsigs
> python-oslo.log: python3-funcsigs
> python-oslo.utils: python3-funcsigs (>= 0.4)
> ripe-atlas-cousteau: python3-funcsigs

You can remove all of the python-oslo* from the list. The versions in
Experimental, which are the next version of OpenStack, are fixed. In 2
weeks of time, I'll upload all what I staged in Experimental to Sid
(maybe 150 packages?) and that's going to fix it all.

For the others, probably I should start filling bugs...

> If what you say is correct then it sounds like the python3-funcsigs
> revese depedencies could be dealt with fairly easily.
> 
> But that still leaves the question of what to do about the dependency of
> pytest on pypy-funcsigs ? should pypy modules be removed from pytest and
> it's reverse-dependencies in the same way that regular python2 modules
> were? how feasible is that? are pypy-* packages only useful with python2
> pypy or are they also useful with python3 pypy?

I really don't know about pypy. Probably the pypy-pytest should indeed
go away, as the initial plan was to switch to pypy3. Maybe tumbleweed
(Stefano Rivera) would be able to answer. I'm adding him as Cc.

>> Traceback2 *already* has Python 2 support removed in Sid. I uploaded
>> this on the 21st of march, pressured by its potential autoremoval.
> 
> Sorry it seems I got my package names mixed up when writing the list of
> options. I said traceback2 where I meant unittest2.

So, if I'm following correctly, what you seem to propose, is to remove
Python 2 from unittest2. If that's the case, then I agree with such a
plan. I just didn't dare to do it yet.

Though in fact, I already worked on that, but stopped, also because
unittest2 FTBFS when I try building it on my laptop. So I've pushed it
in its normal Git repo [1] under a py2-removal branch. If anyone has
some time available to look at it, that'd be nice (I currently don't...).

Cheers,

Thomas Goirand (zigo)

[1] https://salsa.debian.org/python-team/modules/unittest2/



Re: [felix+deb...@gueux.org: Bug#955862: RFS: sphinx-autoapi/1.2.1-1 [ITP]]

2020-04-21 Thread Thomas Goirand
On 4/21/20 11:12 AM, Félix Sipma wrote:
> dget -x
> https://mentors.debian.net/debian/pool/main/s/sphinx-autoapi/sphinx-autoapi_1.3.0-1.dsc
> && sbuild sphinx-autoapi_1.3.0-1.dsc

Hi Felix,

I believe I was downloading the previous version, 1.2.0-1. Just an
advice for lazy sponsors like myself, just put your .dsc URL on *EVERY*
email follow-up... :)

Uploaded.

Thanks for your patience,
Thanks for your contribution to Debian,
Please be patient with FTP masters work,
Cheers,

Thomas Goirand (zigo)



Re: [felix+deb...@gueux.org: Bug#955862: RFS: sphinx-autoapi/1.2.1-1 [ITP]]

2020-04-20 Thread Thomas Goirand
On 4/20/20 4:35 PM, Félix Sipma wrote:
> I use `dgit sbuild` to build the package, and the other tests are
> actually ran (I just tried again)...

Well, I'm just trying to sponsor what you've uploaded to mentors, and so
far, it didn't work (I just tried). Please try downloading the .dsc with
dget and try yourself.

Cheers,

Thomas Goirand (zigo)



Re: [felix+deb...@gueux.org: Bug#955862: RFS: sphinx-autoapi/1.2.1-1 [ITP]]

2020-04-20 Thread Thomas Goirand
On 4/20/20 2:45 PM, Félix Sipma wrote:
> On 2020-04-20 12:06+0200, Thomas Goirand wrote:
>> I'm not sure, the doc still accounts for half of the package. But let's
>> pretend it's ok.
> 
> We are talking about 80KB for the whole package. If it's not a blocker
> for you I prefer keeping it like that.

Fine, ok.

> 
>> Now, the package contains a test suite. It'd be nice to run it. If you
>> add, as dependency: python3-mock, python3-pytest, then pybuild runs the
>> tests automatically. It needs to be overridden though, to avoid running
>> integration tests which are failing (or these tests must be fixed).
>>
>> Can you do that? Then I'll happily upload...
> 
> I added the dependencies, and disabled the integration tests which
> requires golang and dotnet sphinxcontrib extensions. I don't have the
> energy to package these myself...

Of course! However, when I build the package:

The text files are in build/sphinx/text.
   dh_auto_test -O--buildsystem=pybuild
I: pybuild base:217: cd
/<>/.pybuild/cpython3_3.8_sphinx-autoapi/build; python3.8
-m unittest discover -v

--
Ran 0 tests in 0.000s

So, it's running zero tests now. I'm unsure what you did, but that's not
correct. When it tried myself, a lot of tests ran with success.

> Could you please also give me the upload rights for this package when it
> will enter sid?

I'm sorry, but considering the process and how many mistakes I had to
point at which were easy to spot, I wont take this responsibility. I
however will agree to review subsequent uploads.

Cheers,

Thomas Goirand (zigo)



Re: [felix+deb...@gueux.org: Bug#955862: RFS: sphinx-autoapi/1.2.1-1 [ITP]]

2020-04-20 Thread Thomas Goirand
On 4/20/20 11:13 AM, Félix Sipma wrote:
> On 2020-04-19 21:50+0200, Thomas Goirand wrote:
>> On 4/19/20 5:24 PM, Félix Sipma wrote:
>>> I hope I fixed the issues you found
>>
>> Not really... :(
> 
> Let's try again, then...
> 
>> Now the package is 2.7 MB, out of which the extracted library is only
>> 380 KB. Now, the extracted documentation is 3.5 MB and contains 3 MB of
>> fonts, like fontawesome and lato, which are already part of Debian.
>>
>> If everyone was doing like you, installing a small python app would
>> download gigabytes of packages! :)
>>
>> Please:
>> 1/ Push the docs into a separate package that you could call
>> python-sphinx-autoapi-doc.
>> 2/ Remove the embedded fonts fonts from that -doc package, and create
>> symlinks to the appropriate files in the fonts-font-awesome and
>> fonts-lato package.
>>
>> One little general advice now: use mc (or something similar) to go
>> within the resulting .deb files after you've built them, so you can
>> check its content. If you did that, you would have find the issues I'm
>> describing above.
> 
> For sure, getting a 2.7MB package for this small library is not good. I
> do display the list of the files after I build them, but I admit I
> usually don't look too closely to these, and rely on lintian warnings to
> see if fonts package are incorrectly embedded, if the resulting doc is
> too big and should be put to a separate package, etc. Maybe something
> changed recently on lintian (or in my config, but the warnings were not
> displayed on https://mentors.debian.net/package/sphinx-autoapi either)
> because I do not get the embedded fonts warnings I used to have...
> 
> The resulting package is much smaller, I don't think it justifies
> another -doc package. Do you agree?
> 
> Regards,

I'm not sure, the doc still accounts for half of the package. But let's
pretend it's ok.

Now, the package contains a test suite. It'd be nice to run it. If you
add, as dependency: python3-mock, python3-pytest, then pybuild runs the
tests automatically. It needs to be overridden though, to avoid running
integration tests which are failing (or these tests must be fixed).

Can you do that? Then I'll happily upload...

Cheers,

Thomas Goirand (zigo)



Re: [felix+deb...@gueux.org: Bug#955862: RFS: sphinx-autoapi/1.2.1-1 [ITP]]

2020-04-19 Thread Thomas Goirand
On 4/19/20 5:24 PM, Félix Sipma wrote:
> I hope I fixed the issues you found

Not really... :(

Now the package is 2.7 MB, out of which the extracted library is only
380 KB. Now, the extracted documentation is 3.5 MB and contains 3 MB of
fonts, like fontawesome and lato, which are already part of Debian.

If everyone was doing like you, installing a small python app would
download gigabytes of packages! :)

Please:
1/ Push the docs into a separate package that you could call
python-sphinx-autoapi-doc.
2/ Remove the embedded fonts fonts from that -doc package, and create
symlinks to the appropriate files in the fonts-font-awesome and
fonts-lato package.

One little general advice now: use mc (or something similar) to go
within the resulting .deb files after you've built them, so you can
check its content. If you did that, you would have find the issues I'm
describing above.

Cheers,

Thomas Goirand (zigo)



Re: [felix+deb...@gueux.org: Bug#955862: RFS: sphinx-autoapi/1.2.1-1 [ITP]]

2020-04-19 Thread Thomas Goirand
Hi Felix,

Thanks for working on this. Here's my comments. I'm sorry that there's a
lot to say on what you did... :/

On 4/19/20 11:53 AM, Félix Sipma wrote:
>   dget -x 
> https://mentors.debian.net/debian/pool/main/s/sphinx-autoapi/sphinx-autoapi_1.2.1-1.dsc

Looking at your debian/copyright, I'd strongly suggest releasing the
Debian packaging under the same license. For me that's a blocker for
sponsoring the package (it may be ok for others to sponsor).

You wrote in d/control as if the 2nd line of Description: was the
continuation of the short description. This is not the case. Please
write a proper short description (ie: the first line after
"Description:") and a long description (what goes after that first line)
as *not* the continuation of the first line. It's very much ok to repeat
the short description in the long one. This is also a blocker for me to
sponsor the package.

You're packaging the doc "as-is" without using Sphinx to build it. Any
reason why, or you just don't know how yet? :) I'd suggest looking at
other Python package building a -doc package to fix this. I'd also
suggest packaging the doc in a separate -doc package.

Also, please remove:

[import-orig]
merge-mode = replace

from debian/gbp.conf. This is typically something that goes into
~/.gbp.conf rather than on individual packages.

Can you explain in more details than in debian/rules why you're
overriding override_dh_auto_clean ? What does it try to download, apart
from the build dependencies? Can't you set $clean_source = 0; in your
~/.sbuildrc instead?

I hope this helps,
Cheers,

Thomas Goirand (zigo)



Re: py2removal: drop python-pytest by not running tests for python2 packages

2020-04-13 Thread Thomas Goirand
On 4/13/20 11:22 AM, Dmitry Shachnev wrote:
> On Sun, Apr 12, 2020 at 11:05:13PM -0400, Scott Kitterman wrote:
>> On Sunday, April 12, 2020 9:56:01 PM EDT Sandro Tosi wrote:
>>> Hello,
>>> python-pytest is blocking 18 packages from removal, most of them would
>>> be leaves once python-pytest is gone.
>>>
>>> so i was playing with the idea of tackling python-pytest removal by
>>> updating all its rdeps and not run unittests for the python2 binary
>>> (so dropping pytest and the other b-d* only used for tests).
>>>
>>> I know it's suboptimal (some python2 packages can still see updates
>>> until we're ready to drop them and running tests can still have
>>> value), but i think the cost/benefit ratio points towards removing
>>> python-pytest soon rather than wait.
>>>
>>> There are only 25 packages that would need updating, and most of them
>>> are in DPMT/PAPT.
>>
>> Go for it.
> 
> +1 from me too.

+1

Please publish a list here, so we can share the workload.

Cheers,

Thomas Goirand (zigo)



Re: Automatically removing "badges" pictures from README.rst files

2020-04-09 Thread Thomas Goirand
On 4/9/20 10:05 PM, PICCA Frederic-Emmanuel wrote:
> what about lintian brush ?
> 

What's that?

Thomas



Automatically removing "badges" pictures from README.rst files

2020-04-09 Thread Thomas Goirand
Hi team!

In many OpenStack packages, README.rst files are infected with badges.
For example, nova-client here:

https://opendev.org/openstack/python-novaclient/src/branch/master/README.rst

As I'm a good Debian citizen, I'm removing them from the resulting
sphinx doc, because as Lintian warns, it's a privacy breach, and also
because without internet access, the picture just not render.

The problem is that patching the README.rst files is very time
consuming. The number I had to rebase this type of patches is countless.

Therefore, I was wondering if anyone thought about an automated way to
remove these. Maybe we could have some options for dh_sphinxdoc?

Thoughts anyone?

Cheers,

Thomas Goirand (zigo)



Re: packaging manual for a beginner

2020-04-08 Thread Thomas Goirand
On 4/8/20 11:25 AM, Alex Mestiashvili wrote:
> I can imagine that for a newcomer it is kind of
> complicated to start packaging python software. There must be some easy
> py2deb stuff giving you almost ready debian package,(that's what stdeb
> is doing to some extent), but again the documentation is sparse and
> output of stdeb is sometimes scary :) I know, if you need it, just
> implement it, but may be I am missing some already available tools.

I wrote my own "pkgos-debpypi", though it's mainly aimed at OpenStack
packages (actually, not using pybuild as a result, which is kind of
controversial in itself). Piotr implemented something as well for
creating package to use pybuild, but I can't remember the name.

Cheers,

Thomas Goirand (zigo)



Re: packaging manual for a beginner

2020-04-08 Thread Thomas Goirand
On 4/7/20 8:13 PM, Alex Mestiashvili wrote:
> Hi Debian Python folks,
> 
> Is there a good entry point for a newbie who wants to package a python
> module? I am looking for a tool similar to dh-make-perl. In the past
> I've been using stdeb as far as I remember, but it is somehow painful
> compared to other dh-make-x helpers.
> A link with step-by-step instructions would be also helpful. Sorry but I
> am unable to find Debian documentation suitable for a newcomer.
> 
> Thank you,
> Alex
> 

Hi Alex,

I'd advise you to check the content of the packaging-tutorial package.
It contains nice PDFs under /usr/share/doc/packaging-tutorial/
(translated in multiple languages). This is a very good start, IMO.

When you're done with that one, you may start reading the Debian Policy
Manual, which is probably a lot harder to read.

I hope this helps,
Cheers,

Thomas Goirand (zigo)



Re: Reviving #debian-python-changes channel

2020-04-08 Thread Thomas Goirand
On 4/7/20 8:30 PM, Dmitry Shachnev wrote:
> Hi!
> 
> salsabot is dead for two months now, however we can replace it with KGB
> which is alive.
> 
> I am attaching a script that Lisandro Damián Nicanor Pérez Meyer kindly
> shared with me, he used it to revive the #debian-qt-notifications channel.
> 
> I have already replaced qt-kde-team/qt with python-team/modules.
> 
> Can some admin please run it? (You need to get an API token and put a
> SALSA_TOKEN=... line to ~/.devscripts first.)
> 
> python-team/applications is not affected because it seems to already use KGB.
> 
> --
> Dmitry Shachnev

Hi Dmitry,

Thanks a lot for sharing, I've used this script to reconfigure all of
the OpenStack team's repos so that it logs with KGB in
#debian-openstack-commits. You made me save a lot of time! :)

Cheers,

Thomas Goirand (zigo)



Re: Taking over DPMT (Was: python-boto: autopkgtest failure with Python 3.8 as default)

2020-04-04 Thread Thomas Goirand
On 3/30/20 11:44 AM, Andreas Tille wrote:
> I wonder whether we should take over python-boto into DPMT maintenance
> which would enable commits to Git way more easily. 

I'd very much be in the favor of this, especially considering the
package history.

Cheers,

Thomas Goirand (zigo)



When should I drop python2 support for python-linecache2 & python-traceback2 (therefore, unittest2, mock, sphinx, pytest... and the rest of the Python 2 world if I pull this string until end...)

2020-03-20 Thread Thomas Goirand
Hi,

python-fixture (the binary) is gone, therefore we have #952130 and
#952127. I've been reluctant to remove Py2 support from these, because
unittest2 needs it, and this would break a lot of packages (including,
indirectly, stuff like sphinx, pytest, etc.).

What is it that the team suggests at this point? Should I reintroduce
Py2 support in fixtures, or should we go ahead and do a missive Py2 RM
of what's left in the archive?

We're down to only 366 packages with Py2 in testing. We can either
postpone forever, or just go hardly on it (but there will be inevitable
collaterals...).

Your thoughts?

Cheers,

Thomas Goirand (zigo)



Re: Questions about including tests/ directory into package

2020-03-20 Thread Thomas Goirand
On 3/19/20 7:22 AM, Sao I Kuan wrote:
> Hi,
> 
> I'm newcomer to Debian packaging, and trying to add the autopkgtest
> test script into python-tinyalign[1].
> 
> [1] https://salsa.debian.org/med-team/python-tinyalign
> 
> And now I'm facing a (maybe simple) problem.
> 
> The upstream test files are located in tests/ directory, but seems
> this directory is excluded during packaging.
> I have no idea how to include this tests/ directory.
> 
> 1. Please let me know is there any variable for including the specific
> file/directory.
> 2. Why and when the tests/ directory excluded? I tried to find the
> logic in dh-python [2], but failed.
> 
> [2] https://salsa.debian.org/python-team/tools/dh-python
> 
> 3. Is this a correct approach for including the excluded test materials?
> 
> Always appreciates.
> 
> Sincerely,
> 
> Sao I Kuan
> saoik...@gmail.com

Hi,

Ah... how much I hate python and setuptools for being so liberal and let
every developer design its own thing... we end up with no standard, one
having to read setup.py, know all the internals of setuptools, and this
thread is one more collateral of that. :/

For this specific package, what's being packaged is what's found by
setup.py. In that file, you can see:

packages=find_packages("src"),

Setuptools will only find "tinyalign" under the "src" folder, as a
python module to package, which is why that's the only thing that is
going to be packaged.

IMO, the best approach to this problem is to convince upstream to move
their tests folder into the Python package folder. Best is even to make
upstream get rid of the "src" folder, rename that one "tinyalign" and
put the tests folder in it. In other words, make upstream do:

mv src/tinyalign .
rmdir src
mv tests tinyalign
sed -i 's/packages=.*/packages=["tinyalign"],/' setup.py

Cheers,

Thomas Goirand (zigo)



Re: python-babel

2020-02-11 Thread Thomas Goirand
On 2/11/20 4:45 PM, Sandro Tosi wrote:
>> In such case, could you provide me with the source package, rather than
>> just letting me try with Git? Maybe this is going to work then...
> 
> whatever turns out to be, please ensure the package is buildable from
> the git repo. and matches what's going to be uploaded. We have already
> enough packages with missing pristine-tar deltas, with orig tarballs
> that dont match what's in the upstream+pristine-tar output, let's not
> increase that number.
> 
> Thanks,

Sure, we're on the same page. The purpose is just to diagnose what's
going on, and fix it the Git repo!

Cheers,

Thomas



Re: How to find DD member to perform reviews and uploads

2020-02-11 Thread Thomas Goirand
On 2/11/20 12:12 PM, Ondrej Novy wrote:
> Hi,
> 
> út 11. 2. 2020 v 11:02 odesílatel Adam Cecile  <mailto:acec...@le-vert.net>> napsal:
> 
> Bringing the package into the archive would be doable, if someone get
> legal contacts at LSI and asked for official statement authorizing
> Debian to redistribute their binary. I did this in the past for another
> package but I cannot guarantee any success.
> 
> 
> be careful with this. See DFSG 8 :)

This is irrelevant. We're discussing uploading something into non-free,
and as you know, non-free is not part of Debian, and the DFSG doesn't
apply there.

Cheers,

Thomas Goirand (zigo)



Re: python-babel

2020-02-11 Thread Thomas Goirand
On 2/11/20 11:16 AM, Håvard Flaget Aasen wrote:
> 
>>
>> I tried to build python-babel to sponsor the upload from what's in the
>> Git in the DPMT, and it failed to build for me:
>>
>> # Generate the localedata folder data out of the xml files
>> # downloaded in debian/repack
>> scripts/import_cldr.py common
>> Processing root.xml (Language = root; Territory = 001)
>>
>> root: Unsupported number system "adlm" in 
>>
>> [... lots of lines like this one ...]
> 
> I'm also getting these lines. I tested with the current 2.6.0 which also
> gives the same messages, the build log for 2.6.0 in Ubuntu prints the
> same messages.
> 
> Now for the files actually being processed
> It is 719 in version 2.4.0
> 745 in version 2.6.0 and
> 764 in version 2.8.0
> 
> Not that it is supposed to be this way of course. Though I do believe
> the actual content in the package is correct.
> I can have a look at what we are actually importing in d/repack and see
> if anything has changed from version 2.4.0 to 2.8.0
> 
> 
>>
>> root: Unsupported number system "vaii" in > numberSystem="vaii">
>>
>> Traceback (most recent call last):
>>    File "scripts/import_cldr.py", line 968, in 
>>  main()
>>    File "scripts/import_cldr.py", line 193, in main
>>  dump_json=bool(options.dump_json)
>>    File "scripts/import_cldr.py", line 207, in process_data
>>  _process_local_datas(sup, srcdir, destdir, force=force,
>> dump_json=dump_json)
>>    File "scripts/import_cldr.py", line 435, in _process_local_datas
>>  write_datafile(data_filename, data, dump_json=dump_json)
>>    File "scripts/import_cldr.py", line 167, in write_datafile
>>  with open(path, 'wb') as outfile:
>> IOError: [Errno 2] No such file or directory:
>> '/<>/babel/locale-data/root.dat'
>>
> I can't replicate this. I tried with cowbuilder/pbuilder and sbuild and
> the build completes fine on my systems.
> 
> Håvard


In such case, could you provide me with the source package, rather than
just letting me try with Git? Maybe this is going to work then...

FYI, I'm just using plain sbuild with git-buildpackage.

Cheers,

Thomas Goirand (zigo)



Re: How to find DD member to perform reviews and uploads

2020-02-11 Thread Thomas Goirand
On 2/9/20 3:12 PM, Adam Cecile wrote:
> Hello Debian-Python,
> 
> 
> I have a couple of package ready on Salsa but my RFS sent here remained
> unanswered.
> 
> So I'm asking again for your help again ! Here is a list of package
> waiting for uploads:
> 
> 
> https://salsa.debian.org/python-team/modules/djangorestframework-api-key
> 
> https://salsa.debian.org/python-team/modules/aionotify
> 
> https://salsa.debian.org/python-team/modules/python-fastjsonschema
> 
> https://salsa.debian.org/python-team/modules/python-cassandra-driver
> 
> https://salsa.debian.org/python-team/modules/python-sunrise
> 
> 
> Thanks in advance,
> 
> 
> Regards, Adam.

Hi Adam,

I've built and uploaded python-cassandra-driver. Thanks for your
contribution to Debian. Do you still need sponsoring for the above?

Also, thanks a lot for your work on megacli packaging, it's very useful.
However, I haven't found the matching source packages. Do you also think
it'd be possible to push these into the non-free repository of Debian?
Do you even have some sources from upstream, or only binaries? I very
much need this for my work (we use Dell LSI hardware RAID a lot), and my
colleagues would love to have this through the official channel, rather
than from your unofficial repository. Your thoughts?

Cheers,

Thomas Goirand (zigo)



Re: python-babel

2020-02-11 Thread Thomas Goirand
On 1/10/20 8:50 PM, Håvard Flaget Aasen wrote:
> Hello,
> 
> The python-babel [1] package is currently broken, there isn't any bugs
> reported yet, but after the transit to
> python3.8 it failed the testsuite. New upstream version 2.7.0 and above
> fixes these issues.
> To update the package there is a 'repack' script which i believe is
> broken, I at least did most of the work
> manually. For that reason I haven't dared push it to the official repo
> yet, if anyone have time, it will be nice
> with a second opinion. It's still some work left, but it builds and
> tests fine. The version I updated is currently here [2]
> 
> The script might only require a minor fix but i noticed that the files
> being downloaded already exist
> within Debian. The package unicode-cldr-core [3].
> Is it possible to have this as a build-dependency, have a Files-Excluded
> in d/copyright file and
> drop the repack script altogether? If there still is a reason to change
> the files in the first place.
> If this makes it any easier/better of course.
> 
> I'll appreciate all kinds of feedback.
> 
> 
> Håvard
> 
> 
> [1] https://tracker.debian.org/pkg/python-babel
> [2] https://salsa.debian.org/haava-guest/python-babel
> [3] https://tracker.debian.org/pkg/unicode-cldr-core
> 

Hi,

I tried to build python-babel to sponsor the upload from what's in the
Git in the DPMT, and it failed to build for me:

# Generate the localedata folder data out of the xml files
# downloaded in debian/repack
scripts/import_cldr.py common
Processing root.xml (Language = root; Territory = 001)

root: Unsupported number system "adlm" in 

[... lots of lines like this one ...]

root: Unsupported number system "vaii" in 

Traceback (most recent call last):
  File "scripts/import_cldr.py", line 968, in 
main()
  File "scripts/import_cldr.py", line 193, in main
dump_json=bool(options.dump_json)
  File "scripts/import_cldr.py", line 207, in process_data
_process_local_datas(sup, srcdir, destdir, force=force,
dump_json=dump_json)
  File "scripts/import_cldr.py", line 435, in _process_local_datas
write_datafile(data_filename, data, dump_json=dump_json)
  File "scripts/import_cldr.py", line 167, in write_datafile
with open(path, 'wb') as outfile:
IOError: [Errno 2] No such file or directory:
'/<>/babel/locale-data/root.dat'

Can you fix this?

Cheers,

Thomas Goirand (zigo)



Removing python-xmlbuilder from Debian

2019-12-25 Thread Thomas Goirand
Hi Andreas,

Currently, python-xmlbuilder cannot easily be ported to Py3. When
running its unit tests, here's the result:

  File "/<>/xmlbuilder/test.py", line 135, in test_with6
eq_(str(self.xml), '11')
  File "/<>/xmlbuilder/__init__.py", line 208, in __str__
return hdr + str(self.__stack[0])
TypeError: __str__ returned non-string (type bytes)

Feel free to download the updated package from
http://salsa.debian.org/openstack-team/python/python-xmlbuilder to test
this yourself.

Currently, the only reverse dependency of this package is
python-pbcommand. So we have 2 choices:

1/ Fix python-xmlbuilder
2/ Get python-xmlbuilder and python-pbcommand removed from Debian.

Your thoughts?

Cheers,

Thomas Goirand (zigo)



The package python2.7 is RC?

2019-12-24 Thread Thomas Goirand
Hi,

I've seen that the package python2.7 is now of severity RC because of
the py2 removal process:
https://bugs.debian.org/937569

I wonder, is this a mistake done by the severity script? If so, are
there more mistakes?

Happy Chrismass,

Thomas Goirand (zigo)



Re: RFS: opentracing-python/2.2.0-2 [ITP] -- opentracing interface for Python

2019-11-24 Thread Thomas Goirand
On 11/24/19 10:42 PM, Fabrice BAUZAC-STEHLY wrote:
> Hello Thomas,
> 
> I have tried to fix all the issues you have mentioned in 2.2.0-2:
> 
> dget -x 
> https://mentors.debian.net/debian/pool/main/o/opentracing-python/opentracing-python_2.2.0-2.dsc
> 
> Could you please have a look and/or sponsor the package?
> 
> Thanks a lot!
> 
> Best regards

Well, remove the 2nd entry in debian/changelog: this package has never
been uploaded to Debian, so you are documenting something that never
happened in Debian.

Cheers,

Thomas Goirand (zigo)



Re: RFS: opentracing-python/2.2.0-1 [ITP] -- opentracing interface for Python

2019-11-24 Thread Thomas Goirand
On 11/20/19 10:53 PM, Fabrice BAUZAC-STEHLY wrote:
> Alternatively, one can download the package with dget using this command:
> 
>   dget -x 
> https://mentors.debian.net/debian/pool/main/o/opentracing-python/opentracing-python_2.2.0-1.dsc

Hi,

My review.

d/changelog:


No need to write "[ Fabrice BAUZAC ]". That's for when there's multiple
persons in the changelog.

d/compat:
=
Please get rid of this file, and in d/control write debhelper-compat
(=12) instead (and remove debhelper there).

d/control:
==
Not mandatory, but it'd be nice to run "wrap-and-sort -bastk" to
clean-up build-depends ordering.

d/copyright:

There's no "Files: *" entry there, and it looks like you're listing all
the files of upstream. Please don't do that.

The only blocker I see is about d/copyright, the other things are more
cosmetic changes that I'm suggesting.

Cheers,

Thomas Goirand (zigo)



Re: FYI: Python 3 migration of distributuion

2019-11-13 Thread Thomas Goirand
On 11/13/19 6:11 PM, Charles Cazabon wrote:
> Unfortunately, it's difficult to find the hours to devote to this task.  I
> don't know when, or even if, I could have a beta release ready.
> 
>> If you convert python 2 code for 2.7 style, then we can support both
>> python 2 and 3.
> 
> I'm not very interested in doing this, as it means not using a lot of 3.x
> features, or not using them in the most Pythonic way.  My thought was that
> this project would target at least Python 3.7; anyone who didn't want to run
> 3.7 could still run "legacy" getmail under Python 2.7.
> 
> Charles

Hi Charles,

Please allow me to comment on this.

Converting some Python 2.7 code to Python 3.x is not very hard for
anyone who's a little bit trained to it. Most of the time, we see the
same patterns over and over again. So it would be relatively easy for a
lot of us to help you transition the current code to Python 3.x, without
even the need to understand much about getmail itself. Add to this that
there's automated tools to do the most boring part of it (like sixer,
and someone mentioned another one which I can't remember).

I had a quick look into Getmail's code, and it looks very similar to
what I've seen in other programs. Lots of print statements that needs to
be converted, a bit of except to patch, a few itertools too. The code is
also of quite a manageable size (by that I mean: it's a lot smaller than
lots of other stuff I converted to Py3 in a few hours...).

Some of us are offering such a help, and quickly, if you accept the
patches, you'll be able to have Getmail in a good enough shape so it can
stay in Debian, Ubuntu, Fedora.

On the opposite side, if you attempt to do a huge rework of Getmail
(which is maybe needed, I don't know Getmail enough to be able to tell),
probably nobody else but you will be able to do it, and you wont get
much help. As you wrote it may take some time, and you aren't even able
to predict how much.

So, why don't you just take the offer, get the Python 3.x patches in,
and then *later* do your rework, maybe in a version 6 of Getmail? This
sounds a much more reasonable approach to me.

Note that I'm not at all involved in Getmail or I'm not even a user, I'm
just trying to convince you to do the right move here... on the
direction which I believe will serve your users best, for example have
Getmail stay on the next Ubuntu 20.04 LTS (Debian Bullseye is for in 2
years, so you may have more time for that one...).

Cheers,

Thomas Goirand (zigo)



Re: getmail: Python2 removal in sid/bullseye

2019-11-13 Thread Thomas Goirand
On 11/13/19 3:31 PM, Iustin Pop wrote:
> On 2019-11-13 15:06:54, Thomas Goirand wrote:
>> On 11/12/19 4:37 PM, Osamu Aoki wrote:
>>> The related binary packages are available in 2 binary names (depending on 
>>> release)
>>>  getmail4 (version=4,5) popcon installed ~2000
>>>  getmail  (version=3,5) popcon installed ~1000
>>>
>>> https://qa.debian.org/popcon-graph.php?packages=getmail%20getmail4_installed=on_legend=on_ticks=on_fmt=%25Y-%25m=1
>>>
>>> I think this qualifies for "py2keep".
>>
>> IMO, this qualifies for RM-RoM. getmail is an alternative to fetchmail,
>> which is still available in Debian (and with 4 times the number of
>> installed package in popcon...). So I see no reason to keep getmail
>> then. Maybe tell this to upstream, and they may think another time.
> 
> Uh, no. Functionality-wise, they're quite different. getmail is (AFAIK)
> the only tool that works for gmail with ASPs disabled (i.e. with OAUTH).

Oh ! Thanks for the insight. I didn't know.

> Heck, I'd be very willing to maintain Py3 patches myself, because I need
> this tool.

Then there's no issue anymore? :)

Thomas



Re: getmail: Python2 removal in sid/bullseye

2019-11-13 Thread Thomas Goirand
On 11/12/19 4:37 PM, Osamu Aoki wrote:
> The related binary packages are available in 2 binary names (depending on 
> release)
>  getmail4 (version=4,5) popcon installed ~2000
>  getmail  (version=3,5) popcon installed ~1000
> 
> https://qa.debian.org/popcon-graph.php?packages=getmail%20getmail4_installed=on_legend=on_ticks=on_fmt=%25Y-%25m=1
> 
> I think this qualifies for "py2keep".

IMO, this qualifies for RM-RoM. getmail is an alternative to fetchmail,
which is still available in Debian (and with 4 times the number of
installed package in popcon...). So I see no reason to keep getmail
then. Maybe tell this to upstream, and they may think another time.

Cheers,

Thomas Goirand (zigo)



Re: Policy About Maintainer and Uploaders Fields (was: PAPT: join request)

2019-11-12 Thread Thomas Goirand
On 11/12/19 2:38 AM, Sandro Tosi wrote:
> please also realize not everyone shares the
> same ideas as yours and you should try sometimes to respect those
> people decisions too.

With all due respect, the point that I'm trying to make is that this
policy is only there because what I believe is a minority (which you are
part of) supports it, and which everyone else doesn't like.

I do respect your view, and I'm sorry if voicing my opinion is (again)
going against what's been established for years, just like it did when
we moved from SVN to Git. Though that's how things evolve, hopefully for
the better. Also, it's ok if we don't agree... :)

Cheers,

Thomas Goirand (zigo)



Re: Policy About Maintainer and Uploaders Fields (was: PAPT: join request)

2019-11-11 Thread Thomas Goirand
On 11/11/19 9:17 PM, Scott Kitterman wrote:
> Personally, I've been judicious in putting myself as Maintainer in DPMT and 
> PAPT packages.  If we were to ditch the current policy, my immediate response 
> would be to remove DPMT/PAPT from uploaders and maintain them outside the 
> team.  It's about 1/4 of my DPMT/PAPT packages.
> 
> I suspect I'm not the only one.
> 
> Your proposal is not cost free for the teams.
> 
> Scott K

Hi Scott,

Exactly what difference would it make? Just that your package would
really appear as not team-maintained, which is already the current plain
reality (as the "unwritten policy" tells nobody else but you can touch
the package). So I don't see why anyone in the team would mind.

Cheers,

Thomas Goirand (zigo)



Re: Policy About Maintainer and Uploaders Fields (was: PAPT: join request)

2019-11-11 Thread Thomas Goirand
On 11/11/19 9:21 AM, Fabrice BAUZAC-STEHLY wrote:
> For the record, it looks like this policy comes from the package
> "developers-reference", section "Collaborative maintenance".

Absolutely not. The developers-reference doesn't tell what the Python
team policy is when the Uploaders field contains the team address. It
only tells that it is possible to do that, not what it implies in our team.

Cheers,

Thomas Goirand (zigo)



Re: Policy About Maintainer and Uploaders Fields (was: PAPT: join request)

2019-11-10 Thread Thomas Goirand
On 11/10/19 1:20 AM, Sandro Tosi wrote:
> is there any public trace of these "many voices"?

Just like when we discussed moving away from SVN to Git, we can't know
the exact number unless we have a kind of poll/vote (but we don't
actually *have* to start such poll... I'm just saying it's hard to know
otherwise).

However, I can account for maybe 5 people (it's hard to remember) who
told me (face to face) they hate this policy, and it felt like there was
a broad consensus that it was really against a team spirit, plus it made
little sense to have a package team maintained with strong ownership. I
wouldn't name the persons I have in mind publicly, because they haven't
granted me the permission to do so, and therefore, it wouldn't be nice
to do so.

All of this is just feelings I had during conversations with others, and
of course, cannot be accounted as just plain facts, so just take it as
it is: just a report of the feeling I had when talking with others, that
it looks like I'm far from the only one disliking this policy because of
the above mentioned reasons.

As Louis-Philippe wrote, it's very much ok to delay this conversation,
but sooner or later, it will come back on the table.

Thomas Goirand (zigo)



  1   2   3   4   5   >