Offer to help with packaging

[Pablo Mestre]

Hello,

My name is Pablo Mestre and since last year I started the training
process to learn how to package for Debian with the sponsorship of Otto
Kekäläinen.

I currently maintain colortest-python[1], collaborate with
rdiff-backup[2] and I try to pack mystiq[3].

Now, I would like to know if there is any orphan package or that you are
needing help in which you can collaborate as a starter packer?

Regards,

Pablo


[1] https://salsa.debian.org/python-team/applications/colortest-python

[2] https://salsa.debian.org/python-team/applications/rdiff-backup

[3]https://salsa.debian.org/debian/mystiq

Re: Offer to help with packaging

[Pablo Mestre]

Ok..
I will take a look

:)


El 6/28/20 a las 11:04 AM, PICCA Frederic-Emmanuel escribió:
> What about helping 
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946035
>
>
> python-language-server
>
> is the only one missing now.
>
> cheers

RE:Offer to help with packaging

[PICCA Frederic-Emmanuel]

What about helping 

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946035


python-language-server

is the only one missing now.

cheers

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

[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: Offer to help with packaging

[Otto Kekäläinen]

Hello!

I just wanted to chip in that I have been mentoring Pablo and he is
very committed and has already worked with several packages and is
proficient in using git, Salsa MR, Salsa CI etc workflow.

If you have some newcomer friendly or intermediate level tasks, please
get in touch with Pablo!

-- 
- Otto

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

[Jeremy Stanley]

On 2020-06-28 16:48:02 +0200 (+0200), Thomas Goirand wrote:
[...]
> 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.

While I don't agree with Thomas's harsh tone in the bits of the
message I snipped (please Thomas, I'm sure everyone's trying their
best, there's no need to attack a fellow contributor personally over
technical issues), I did want to point out that the proposal makes
some sense. The Testing Cabal folk were heavily involved in
OpenStack and influential in shaping its quality assurance efforts;
so OpenStack relies much more heavily on these libraries than other
ecosystems of similar size, and OpenStack community members, present
and past, continue to collaborate upstream on their development.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

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

[Sandro Tosi]

> 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 "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

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

[Scott Kitterman]

On Sunday, June 28, 2020 1:59:08 PM EDT Sandro Tosi wrote:
> 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).

Definitely this.

Scott K

signature.asc
Description: This is a digitally signed message part.

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

[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)

Bug#962505: Update Pygments package

[Kelly Brazil]

Any chance we can get the Pygments package updated? 
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962505 
)

There are some new API values my app, jc, is using 
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962239 
) so packaging for jc 
is blocked by this.

Thanks,
Kelly

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

[Emmanuel Arias]

On Fri, Jun 26, 2020 at 7:08 AM Thomas Goirand  wrote:

> 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)


+1 :) \O/

>


> Thomas
>
>

Asking for help Poetry

[Emmanuel Arias]

Hi,

I'm working on poetry packaging, I created on salsa de repository [0].

Note that there are many packages that are not in Debian like cachy, cleo,
etc.

I RFS python-cachy [1] and now I'm working on cleo, which depends on clikit
that is not on Debian (if I search correctly).

Bastian Venthur note me that pienv, pip have vendors folder with the
dependencies
but looking on poetry that _vendor folder is empty.

So, looking for I more experienced opinion, do you think that we would try
convince
to upstream to make available vendors on the release (if that is necessary)
or
we need to package all the missing dependencies?


[0] https://salsa.debian.org/python-team/applications/poetry
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956819

Many thanks for your help

Cheers,
Arias Emmanuel
@eamanu
yaerobi.com

Re: Asking for help Poetry

[Scott Kitterman]

On June 29, 2020 3:08:53 AM UTC, Emmanuel Arias  wrote:
>Hi,
>
>I'm working on poetry packaging, I created on salsa de repository [0].
>
>Note that there are many packages that are not in Debian like cachy,
>cleo,
>etc.
>
>I RFS python-cachy [1] and now I'm working on cleo, which depends on
>clikit
>that is not on Debian (if I search correctly).
>
>Bastian Venthur note me that pienv, pip have vendors folder with the
>dependencies
>but looking on poetry that _vendor folder is empty.
>
>So, looking for I more experienced opinion, do you think that we would
>try
>convince
>to upstream to make available vendors on the release (if that is
>necessary)
>or
>we need to package all the missing dependencies?

Definitely they should be packaged.

At least for pip none of the vendored libs are used in Debian's package.  
Fortunately upstream supports use of system libs with only minor patching.

Scott K

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

[Ondrej Novy]

Hi,

ne 28. 6. 2020 v 16:48 odesílatel Thomas Goirand  napsal:

> 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.
>

which is perfectly fine, that's how Debian works.

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! :(
>

yep, that's how it works. We need to move forward and don't keep old, buggy
and unmaintained packages in Debian, right?

You should add autopkgtest to prevent this. Failed autopkgtest will block
migration. Or we should start using full transitions, which is a bad idea
imho.

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.


> 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 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.
>

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

-- 
Best regards
 Ondřej Nový