Re: New version 1.40.4-3 of sentry-python uploaded to mentors.debian.net

[Carsten Schoenert]

Hi Eberhard,

Am 25.04.24 um 08:52 schrieb Eberhard Beilharz:

Would someone with the necessary permissions please upload the package?

The previous version of sentry-python was removed from testing because
of some open bugs, and in turn the packages that depend on sentry-python
also got removed.

Someone started to work on a fix and uploaded 1.40.4-2 but never
followed up on the failing autopkg tests that prevented migration.


I've pulled in your MR and uploaded 1.40.4-3.
Thanks for working on sentry-python!

--
Regards
Carsten

Re: Status of sqlalchemy

[Carsten Schoenert]

Hi,

Am 15.04.24 um 11:20 schrieb Thomas Goirand:


The rest of:
...
- wtforms-alchemy


I'll try to have a look at this library.

--
Regards
Carsten

Re: Uscan: watch and changelog

[Carsten Schoenert]

Am 29.03.24 um 17:39 schrieb c.bu...@posteo.jp:

Dear Carsten,

thank for your reply and your patience with me. :)

On 2024-03-29 16:23 Carsten Schoenert  wrote:

You need to use "opts=mode=git, ...", see the man page of uscan.


Are you sure.


Of course I'm sure, I've tested the snippets before posting it on the 
list. Did you test this on your side and have any issues?



For example this watch file do not use "opts="
https://sources.debian.org/src/backintime/1.4.3-1/debian/watch/


You need to ask the person that did probably this creation or 
modification. I can't answering this.



Also some examples on the wikipage about "debian/watch" do not use
"opts=".


You seems to expect that the wiki is all known and answering place. No, 
that is this not. It's by nature always "outdated". But it's a wiki, 
everyone can edit it.



Please be aware that I don't only want to solve one technical problem
with one specific package. I want to understand the whole thing ("big
picture") to improve the documentation.


Well, that's not that complicated for uscan, it does mainly one thing 
(which is done in multiple steps, have a look into the man page), it's 
scanning upstream resources, fetching data and creates an tarball ready 
for importing.



opts="mode=git, \
   
uversionmangle=s/(\d)[_\.\-\+]?((RC|rc|pre|dev|beta|alpha)\.?\d*)$/$1~$2/,
\ dversionmangle=s/\+ds(\.?\d+)?$//" \
https://codeberg.org/buhtz/hyperorg.git \
   refs/tags/v(\d+\S+)


And uscan will find the most recent version matching the regexp.


I see 3 different regex patterns in this line. Why?


I see one that is relevant to your original question. The other two you 
mean are used in other "opts" variables, these variable are also 
explained too in the man page of uscan.


--
Regards
Carsten

Re: Uscan: watch and changelog

[Carsten Schoenert]

Am 29.03.24 um 15:05 schrieb c.bu...@posteo.jp:


I assume I have not yet understood the purpose of the changelog in
context of uscan. What do I miss?

This is "debian/watch":

version=4
# RegEx in Perl dialect
https://codeberg.org/buhtz/hyperorg/archive/v(\d+).(\d+).(\d+).tar.gz

This is a dummy "debian/changelog":

hyperorg (0.0-dev) UNRELEASED; urgency=low

   * Changes made in this version

  -- Maintainer Name   Thu, 01 Jul 2021 12:00:00
  +


You need to use "opts=mode=git, ...", see the man page of uscan.

e.g. like this


$ cat debian/watch
version=4

opts="mode=git, \
  
uversionmangle=s/(\d)[_\.\-\+]?((RC|rc|pre|dev|beta|alpha)\.?\d*)$/$1~$2/, \
  dversionmangle=s/\+ds(\.?\d+)?$//" \
https://codeberg.org/buhtz/hyperorg.git \
  refs/tags/v(\d+\S+)


And uscan will find the most recent version matching the regexp.

$ uscan --verbose --no-download 
uscan info: uscan (version 2.23.7) See uscan(1) for help

uscan info: Scan watch files in .
uscan info: Check debian/watch and debian/changelog in .
uscan info: package="hyperorg" version="0.0-dev" (as seen in debian/changelog)
uscan info: package="hyperorg" version="0.0" (no epoch/revision)
uscan info: ./debian/changelog sets package="hyperorg" version="0.0"
uscan info: Process watch file at: debian/watch
package = hyperorg
version = 0.0
pkg_dir = .
uscan info: opts: mode=git, 
uversionmangle=s/(\d)[_\.\-\+]?((RC|rc|pre|dev|beta|alpha)\.?\d*)$/$1~$2/, 
dversionmangle=s/\+ds(\.?\d+)?$//
uscan info: line: https://codeberg.org/buhtz/hyperorg.git refs/tags/v(\d+\S+)
uscan info: Parsing mode=git
uscan info: Parsing  
uversionmangle=s/(\d)[_\.\-\+]?((RC|rc|pre|dev|beta|alpha)\.?\d*)$/$1~$2/
uscan info: Parsing  dversionmangle=s/\+ds(\.?\d+)?$//
uscan info: line: https://codeberg.org/buhtz/hyperorg.git refs/tags/v(\d+\S+)
uscan info: Last orig.tar.* tarball version (from debian/changelog): 0.0
uscan info: Last orig.tar.* tarball version (dversionmangled): 0.0
uscan info: Execute: git ls-remote https://codeberg.org/buhtz/hyperorg.git
uscan info: Found the following matching refs:
 refs/tags/v0.1.0 (0.1.0)
 HEAD ()
 refs/heads/fix/131subfolders ()
 refs/heads/fix/30_and_70_links ()
 refs/heads/latest ()
 refs/pull/138/head ()
 refs/pull/139/head ()
uscan info: Looking at $base = https://codeberg.org/buhtz/hyperorg.git with
$filepattern = refs/tags/v(\d+\S+) found
$newfile = refs/tags/v0.1.0
$newversion  = 0.1.0
$lastversion = 0.0
uscan info: Upstream URL(+tag) to download is identified as
https://codeberg.org/buhtz/hyperorg.git refs/tags/v0.1.0
uscan info: Filename (filenamemangled) for downloaded file: 
hyperorg-0.1.0.tar.xz
Newest version of hyperorg on remote site is 0.1.0, local version is 0.0
 => Newer package available from:
=> https://codeberg.org/buhtz/hyperorg.git refs/tags/v0.1.0
uscan info: Scan finished


--
Regards
Carsten

Re: Docu: Need help to understand section about package creation

[Carsten Schoenert]

Hello Paul,

Am 29.03.24 um 13:49 schrieb Paul Boddie:

On Friday, 29 March 2024 09:52:14 CET Carsten Schoenert wrote:


Starting with Debian packaging isn't a easy thing and there is *not* the
one way to do it right. And there are for sure hundreds of HowTos out
there. You will need to try a few of them and chose in the end the
workflow that fit's best for you.


The problem with this advice is that for the Debian Python Team, there
probably aren't many ways to "do it right". Instead, as I understand it, there
will be very few ways that people tolerate, as recent discussion on this list
has indicated.


the question in general was not about the right and correct way in the 
DPT, it was about starting from scratch. At least I don't know of a 
right way from scratch that is written down as policy, would also make 
no real sense to me.
Starting Debian packaging isn't easy, but it's going to be more 
complicated if you think there is only one way that's correct. In the 
end DAK needs some files, how you create them is on your own.
The DPT policy doesn't say you need to do packaging a very specif way, 
it stated that git-buildpackage is the tool for organizing the VCS data.


The DPT policy gives you the freedom to do your packaging preparation 
how ever you like, but it is expected you finally upload the data of 
your work into a git tree with a specific layout so others can take your 
work and reproduce a package by using gbp.


gbp is very flexible, so if you like to use sbuild in favor of pbuilder 
e.g. than you can simply do so.


BTW: I posted my way on how I created a new Python package for Debian in 
the German Debian forum extensively and in length last year while DC 
[1]. Because I also know were starters typically struggle with and I was 
in the need to introduce a new Python package as a dependency for 
another package.
I'm unsure if Christian did follow my steps by trying to reproduce the 
package I was working on. I'm thinking he didn't, if he did then I'm 
wondering where he is having problems to prepare his package. Until now 
there is no "I did this and this, ..., I failed."


The feedback on my mini HowTo was quite low. So I wont do such things again.


In the end, I did my usual thing and distilled the documentation's prose down
to a concise workflow to remind me of what I might need to do if I were to
start packaging something else. In fact, I wrote the following for the Moin
2.0 packages and then made use of it for the other package:

git branch -c master upstream
git checkout -b debian/master

git add debian
git commit

git push origin 
gbp buildpackage --git-debian-branch=debian/master \
   --git-upstream-tag='upstream/%(version)s' --git-builder=sbuild


gbp makes all these steps easier I think. Even if you want to do it 
completely manually. Basically I do this


mkdir new-package && cd new-package
git init
# create a file debian/gbp.conf if you want to have it more convenient
gbp import-orig [--verbose] --sign-tags --pristine-tar 
/path/to/tarball-version.tar.{gz,...,xz}

# add required files into debian/
gbp dch -aR
gbp buildpackage --git-ignore-new [--git-builder=what_ever_you_like]
# run lintian, squash issues, prepare autopkgtest, commit changes atomically
# create a patch queue if needed
gbp pq import [--ignore-new]
# work on patches, commit them
gbp qp export
git add debian/patches && git commit
# hack further, finalize the package, create the final changelog entry 
if needed

git commit debian/changlog
gbp buildpackage ...
# upload, wait for the DAK email
gbp tag --sig-tags
git remote add salsa 
gbp push [salsa]

But we will find ten more possible ways to create a new package from 
scratch. :)


...

P.S. The argument made about needing to understand what happens "under the
hood" is something of an indictment of the way technology is developed these
days. A tool that is meant to simplify something should present its own
coherent level of abstraction; deferring to lower-level mechanisms is
something that the Git developers and community like to do, which is why the
usability of Git is the subject of occasional jokes and somewhat more
infrequent attempts to wrap it in more usable interfaces.


A good tool is always helpful, and a good first time user experience is 
also important. But I've seen a lot of people and contributors that were 
completely lost once a errors message was coming up and they did not 
know what to do and were to look. A good developer or engineer is always 
able to help themselves. Means he need to know how things work or at 
least were to look next to solve problems.


[1] https://debianforum.de/forum/viewtopic.php?t=187764

--
Regards
Carsten

Re: Docu: Need help to understand section about package creation

[Carsten Schoenert]

Am 29.03.24 um 08:51 schrieb c.bu...@posteo.jp:

This document is not Python related. The section about Python is empty.
See section 15 at PDF page 65.


This isn't really needed yet, packaging Debian packages is technically 
always the same.
You seems to have a general problem to understand what is the basic 
workflow, what are the steps, what are the various files in the debian/ 
folders are for, what are the constraints and relationships of these 
files and how the low level tools work together. You need to work on 
this first before starting to dive into special handling for different 
languages done by the helper tools.


So Mechtilde pointed correctly to the

New Maintainer Guide:
https://www.debian.org/doc/manuals/maint-guide/

and to the
Developer Reference:
https://www.debian.org/doc/manuals/developers-reference/

Asking meta questions (It's not working, what do I wrong?) isn't 
helpful, ask specific questions and describe what you already did befor 
you encountered the problem.


Starting with Debian packaging isn't a easy thing and there is *not* the 
one way to do it right. And there are for sure hundreds of HowTos out 
there. You will need to try a few of them and chose in the end the 
workflow that fit's best for you.


git-buildpackage is one of the high level tools that can and should 
packaging tasks easier, to use it effective you will need to know what 
it is doing under the hood, means you need to be familiar with the low 
level tools that getting called by gbp.


--
Regards
Carsten

Re: #1066146 RM: flask-basicauth (Re: morph's abandoned packages (list))

[Carsten Schoenert]

Hello Andreas,

Am 18.03.24 um 21:15 schrieb Andreas Tille:

Hi Carsten,

Am Sun, Mar 17, 2024 at 08:18:58AM +0100 schrieb Carsten Schoenert:

The arguments to remove  flask-basicauth looks sensible, can someone confirm ?


looking at the upstream situation for flask-basicauth I see no real issues
to drop and this package from the archive. This horse is long dead for a
long time.


This sentence looks as if would have been created by autocomplete function.
Could you please try to rephrase for better understandability?


well, it's getting harder to maintain upstream source that is simply not 
maintained anymore by the original upstream author or group. 
flask-basicauth is one of these cases. The last action by upstream is 
now 8 years old!


https://github.com/jpvanhal/flask-basicauth

There is no feedback from upstream on bug reports since years. I'm 
writing bug reports in such cases sometimes mainly only to show the 
problems we or I have discovered in a hope that other will post than how 
they solved this issue.


And of course also upstream is not reacting on created PRs. I've given 
up to write new and further PRs in such cases, it's a waste of time.


Doing the needed maintenance for such old repositories is often 
difficult and time consuming, e.g. dealing with old build systems or the 
test setup.
I'm primarily a package maintainer not a person that is having fun to 
update or adjust old trees with a 5th possible solution. It's not 
helpful and wise if every distro is doing the same with lots of energy. 
It's not our responsibility to keep every source package alive in the 
archive if upstream has moved away, at least this is my thinking.


We have more and more the problem to manage big transitions like the 
usual Python major updates, or big frameworks like Sphinx, PyTest, 
Django etc. I've spend a lot of time with rather old and not really 
maintained anymore by upstream packages in the past year.
We can't deal with all the challenges that will need some action all 
other the time. But shipping then outdated or not really useful packages 
within a release is not something we should do. Sometimes it's better to 
drop such packages from the archive and shift time and energy to other 
packages.


And to me flask-basicauth is such a package. It's dead Jim!

--
Regards
Carsten

#1066146 RM: flask-basicauth (Re: morph's abandoned packages (list))

[Carsten Schoenert]

Hi,

Am 16.03.24 um 18:37 schrieb Alexandre Detiste:

Hi,

The arguments to remove  flask-basicauth looks sensible, can someone confirm ?


looking at the upstream situation for flask-basicauth I see no real 
issues to drop and this package from the archive. This horse is long 
dead for a long time.


--
Regards
Carsten

Re: OK to create a new package in "python-team/packages/"

[Carsten Schoenert]

Am 15.03.24 um 08:31 schrieb c.bu...@posteo.jp:


On the long run it is my goal to make the package [1] ready for official
upload. But I suspect this is a long way. So on short view that repo
will be for practicing only. Am I allowed to create such a repo in my
position?


There is no need to start any packaging work within the Salsa group of 
the DPT. You can start any work within your namespace and move the 
package to any other group later if needed and appropriate.


And within your namespace you can e.g. do force pushing if you feel you 
need to, within team space that's a no go.


--
Regards
Carsten

Flask 3.0 - Almost there (Re: Updating Flask to 3.x?)

[Carsten Schoenert]

Hi,

Am 04.02.24 um 13:46 schrieb Carsten Schoenert:


Based on the current situation I plan now to upload Werkzeug und Flask
3.x in about a week to unstable.


the upload of Werkzeug and Flask to unstable did happen on Friday and 
Saturday last week. Things went smooth without hick-ups so far. Thanks 
again all involved Contributors to make this happen!


https://tracker.debian.org/pkg/python-werkzeug
https://tracker.debian.org/pkg/flask

@Hefee
Could you please prepare a upload of onionshare to unstable the next 
days? At this time onionshare in testing will prevent python3-flask from 
migrating to testing.


--
Regards
Carsten

Re: Updating Flask to 3.x?

[Carsten Schoenert]

Hello Hefee, hello list,

Am 24.01.24 um 22:46 schrieb Hefee:


Me as maintainer of onionshare got notice about this discussion here by a
sidechannel. It would have made things a lot easier to me to spot the issue
that onionshare is not ready for flask 3.x, if you had open a bugreport against
onionshare in December.


no worries, at that time at least I was focusing on the rather easier 
things for me to fix and did chose to work on packages which were rather 
easier to fix for me.


Thanks for your time and energy fixing the onionshare package, that 
makes currently one package left that is not ready for Flask 3.0.


The current outstanding package is ironic-inspector which is marked due 
other reason for auto removal from testing on 29th February.


Based on the current situation I plan now to upload Werkzeug und Flask 
3.x in about a week to unstable.


--
Regards
Carsten

Re: Updating Flask to 3.x?

[Carsten Schoenert]

Hi,

Am 26.12.23 um 15:24 schrieb Carsten Schoenert:

I've uploaded first python-werkzeug

https://qa.debian.org/excuses.php?experimental=1=python-werkzeug

and a day later flask with a newer version >= 3.0.0.

https://qa.debian.org/excuses.php?experimental=1=flask

I focused the past days within my free time to fix issues related to
python-werkzeug. Some of the packages a I touched had also impact to the
broken QA packages in the flask package.

So far it looks not that bad, currently there are three packages left
for python-werkzeug.

flask-dance
For this package I wasn't able to fix the broken CI tests, fixing the
broken import which is shown on the QA output is mostly easy, but
afterwards there are some more other broken tests that will require some
help by upstream. Raising a issue within the GitHub issue tracker is
still needed. For now I postponed this, if someone wants to take action
on this please go ahead.

onionshare
open3d
These packages have currently no version in testing for some time. Both
will also require help from upstream I guess.

pytest-httpbin
Should be obsolete soon, I uploaded a newer version to unstable that
will fix the broken tests.

The amount of broken packages due the flask 3.0.0 upload is a bit
greater and I haven't looked much at these packages yet. My guess is
that most of these packages can be "fixed" by preparing uploads with
newer versions.


I wanted to give a update on the current state.

Since my last email about this topic a lot fixes and uploading of 
packages did happen by various people and contributors, thank you all 
for working on the build or test issues!


For now it's look quite good to me. There are currently three packages 
left that showing build or test issues while package build. The details 
can be found on the URLS from my previous email.^^^


python-werkzeug triggers (still) a autopkgtest failure for onionshare.

flask is provoking autopkgtest failure for ironic-inspector[2] and 
bepasty [3].
bepasty is fixed upstream and will get fixed in Debian once the newer 
version (not yet released) will enter Debian.


So we mainly have basically two packages left, I might will find some 
time and look again into onionshare.
ironic-inspector is maintained by the Openstack maintainers and I'm not 
familiar enough to check if a newer version would fix the current test 
issues.



[1] https://ci.debian.net/packages/o/onionshare/unstable/amd64/41943542/
[2] 
https://ci.debian.net/packages/i/ironic-inspector/unstable/amd64/41962520/

[3] https://ci.debian.net/packages/b/bepasty/unstable/amd64/41942909/

--
Regards
Carsten

Re: sentry-python

[Carsten Schoenert]

Hi,

this package was on my list for some time, I picked the recent upstream 
version and prepared a upload yesterday.

Looks good so far, should be migrate to testing in two days.

Am 08.01.24 um 18:43 schrieb Gregor Riepl:

Hi Eberhard,


Is anyone working on updating sentry-python
 to prevent autoremoval
due to #1058422 ?


I did some debugging/testing, because this bug affects our Cura
packages, but I didn't get very far.

The root of the problem is a change in the Python 3.12 logging library:
https://docs.python.org/3/library/logging.html#logrecord-attributes
  > Changed in version 3.12: taskName was added.

The unit tests in Debian's sentry-sdk can't cope with that.

However, it seems like upstream has already done the work to fix Python
3.12 compatibility: https://github.com/getsentry/sentry-python/issues/2480

So, it should suffice to upgrade to at least 1.34.0 (or better yet, the
latest 1.x release).

Regards,
Gregor



--
Regards
Carsten

Re: Updating Flask to 3.x?

[Carsten Schoenert]

Hello Michael, hello list,

Am 18.12.23 um 12:54 schrieb Michael Kesper:

Following a simple list of reverse deps for the resulting binary
packages. Any help, suggestion or useful hint in maintaining this Flask
update is really appreciated!


Feel free to contact me if you need help!


I've uploaded first python-werkzeug

https://qa.debian.org/excuses.php?experimental=1=python-werkzeug

and a day later flask with a newer version >= 3.0.0.

https://qa.debian.org/excuses.php?experimental=1=flask

I focused the past days within my free time to fix issues related to 
python-werkzeug. Some of the packages a I touched had also impact to the 
broken QA packages in the flask package.


So far it looks not that bad, currently there are three packages left 
for python-werkzeug.


flask-dance
For this package I wasn't able to fix the broken CI tests, fixing the 
broken import which is shown on the QA output is mostly easy, but 
afterwards there are some more other broken tests that will require some 
help by upstream. Raising a issue within the GitHub issue tracker is 
still needed. For now I postponed this, if someone wants to take action 
on this please go ahead.


onionshare
open3d
These packages have currently no version in testing for some time. Both 
will also require help from upstream I guess.


pytest-httpbin
Should be obsolete soon, I uploaded a newer version to unstable that 
will fix the broken tests.


The amount of broken packages due the flask 3.0.0 upload is a bit 
greater and I haven't looked much at these packages yet. My guess is 
that most of these packages can be "fixed" by preparing uploads with 
newer versions.


--
Regards
Carsten

Updating Flask to 3.x?

[Carsten Schoenert]

Hi,

the Flask team released Flask and the depending package Werkzeug 3.0.0 
on 2023-09-30.


Since Thomas Goirand did the last update of Flask to 2.2.x nearly one 
year ago in preparation for the Bookworm release I've talked with Thomas 
recently about updating Flask and depending packages again so we can get 
Flask 3.x into the archive.
Thomas pointed out he will not have time to work on Flask 3 and some 
depending packages in the near future.


I usual try to keep an eye on some Flask related packages as we use them 
on my day job. A few of them have now RC issues and are already kicked 
out of testing. Solving these bug reports are now mostly depending on a 
newer Flask version or at least it would be more useful to move over to 
a recent Flask version.


Given we are now short before the X-mas days and I will have some more 
time to look at some packages I'm willing to push things further.


I've started on Flask and werkzeug packages yesterday and basically 
there are no big issues to get these packages updated.
If no objections are raised I intend to upload recent versions of 
python-flask and python-werkzeug to experimental next week.


Once happen we will see through

https://qa.debian.org/excuses.php?experimental=1=python-werkzeug
https://qa.debian.org/excuses.php?experimental=1=flask

which packages would prevent a migration later due build or test failures.

Following a simple list of reverse deps for the resulting binary 
packages. Any help, suggestion or useful hint in maintaining this Flask 
update is really appreciated!


@Thomas
Do you agree on my plan? Or do you have reasons to wait a bit more with 
uploading Flask and Werkzeug to experimental?



$ LANG= apt rdepends python3-flask python3-werkzeug
python3-flask
Reverse Depends:
  Depends: python3-flask-api (>= 0.12.3)
  Depends: mu-editor (>= 1.0.2)
  Depends: python3-etesync-dav
  Depends: voltron
  Depends: supysonic (>= 0.11)
  Recommends: snakemake
  Depends: python3-sahara (>= 2.1.2)
  Depends: recon-ng
  Suggests: python3-livereload
  Depends: python3-flask-sockets
  Depends: python3-flask-seeder (>= 1.0.2)
  Depends: python3-flask-marshmallow
  Depends: python3-python-flask-jwt-extended (>= 2.0)
  Depends: python3-python-flask-jwt-extended (<< 4.0)
  Depends: python3-flask-httpauth
  Depends: python3-flask-cors (>= 0.9)
  Depends: python3-flasgger (>= 0.10)
  Depends: python3-pytest-flask
  Depends: python3-trove (>= 2.2.3)
  Depends: python-openslide-examples
  Depends: openlp
  Depends: onionshare-cli (<< 3.0.0)
  Depends: onionshare-cli (>= 2.0.0)
  Depends: mkchromecast
  Depends: mitmproxy (>= 1.1.1)
  Depends: python3-locust (>= 2.0.0)
  Depends: lektor
  Depends: python3-klaus
  Depends: python3-keystone
  Depends: json-schema-test-suite
  Depends: python3-ironic-inspector (>= 1.1.0)
  Depends: python3-impacket
  Depends: python3-httpbin
  Depends: gftools
  Depends: python3-flaskext.wtf
  Depends: python3-flask-sqlalchemy (>= 2.2)
  Depends: python3-flask-socketio (>= 0.9)
  Depends: python3-flask-session
  Depends: python3-flask-restful (>= 0.8)
  Depends: python3-flask-principal
  Depends: python3-flask-peewee
  Depends: python3-flask-paranoid (>= 0.10)
  Depends: python3-flask-paginate
  Depends: python3-flask-openid (>= 0.10.1)
  Depends: python3-flaskext.multistatic
  Depends: python3-flask-mongoengine (>= 1.1.2)
  Depends: python3-flask-migrate (>= 0.9)
  Depends: python3-flask-mail
  Depends: python3-flask-login (>= 1.0.4)
  Depends: python3-flask-limiter (>= 2)
  Depends: python3-flask-ldapconn (>= 0.12)
  Depends: python3-flask-jwt-simple
  Depends: python3-flask-htmlmin
  Depends: python3-flask-flatpages (>= 0.8)
  Depends: python3-flask-dance (>= 2.0.3)
  Depends: python3-flask-compress
  Depends: python3-flask-caching
  Depends: python3-flask-bcrypt
  Depends: python3-flask-basicauth
  Depends: python3-flask-babelex
  Depends: python3-flask-babel (>= 2.0)
  Depends: python3-cloudkitty (>= 2.0.0)
  Recommends: python-flask-doc
  Suggests: dnstwist
  Depends: python3-designate
  Depends: comitup
  Depends: a2d
  Depends: ceph-iscsi
  Depends: python3-flask-bootstrap
  Depends: python3-biomaj3-user
  Depends: python3-biomaj3-process
  Depends: python3-biomaj3-download
  Depends: python3-biomaj3-daemon
  Depends: bepasty
  Suggests: beets
python3-werkzeug
Reverse Depends:
  Depends: python3-quart (>= 2.2.0~)
  Depends: python3-mediagoblin
  Depends: ceph-mgr-dashboard
  Depends: ceph-mgr
  Depends: python3-vitrage
  Depends: tryton-server
  Depends: tryton-modules-web-shortener
  Depends: tryton-modules-web-shop-vue-storefront
  Depends: tryton-modules-timesheet
  Depends: tryton-modules-marketing-automation
  Depends: tryton-modules-account-payment-stripe
  Depends: tryton-modules-account-payment-braintree
  Depends: python3-pytest-localserver (>= 0.10)
  Depends: python3-pywps
  Depends: python3-python-flask-jwt-extended
  Suggests: python3-django-extensions
  Depends: python3-flask (>= 2.2.2)
  Depends: 

Re: [backintime] I'll package the next release

[Carsten Schoenert]

Hello Christian,

Am 15.09.23 um 13:18 schrieb bu...@posteo.de:

Hello together,

I hope different from the past this announcement will work this time.
Last time I announced the will to package something ("feedparser") but
someone else did it without communication.

Back In Time [1][2] will have a new upstream release [3] in the next
days. I [4] will try to prepare the packaging for Debian this time. The
next Debian release is minimum 2 years away so I have enough time. ;)


the DPT isn't the maintainer of this package, you are aware of this?
Means, I see primarily no work nor action on the side of the DPT that's 
needed to take as the package has a person as Maintainer set.


Do you have talked to the Maintainer and/or Uploader if they are 
interested in help with any packaging work done by you?
Not that you not can do this for yourself, but please be not 
disappointed if the Debian Maintainers refuse your packaging work to merge.


--
Regards
Carsten

Re: [backintime] Switch the maintainer to "Debian Python Team (DPT)"

[Carsten Schoenert]

Hello Christian,

Am 27.07.23 um 21:56 schrieb c.bu...@posteo.jp:

Dear Carsten,

thanks for your feedback, your kind words and your patience with my
frustration. :)

I was thinking about what it is what bothers me here. It is not that
"the work" isn't done or bugs not fixed. It is that there is no
reaction; zero; total silence.


you really should read the Social Contract/DFSG, the Debian policy and 
the Developers reference a few times.


https://www.debian.org/social_contract
https://www.debian.org/doc/debian-policy/
https://www.debian.org/doc/manuals/developers-reference/

There is no rule that any DD or DM *must* do something in Debian, so you 
probably have the wrong expectations.



The current Debian release is fresh. All of you maintainers have done a
lot of extra work in the last weeks to get it done. The next release is
two years in the future. Totally understandable if someone now would
take half or one year off from the maintainers job.

But this needs to be communicated somehow. A simple mail with "I'm on
holiday for the next 6 months" would be OK for me.


There is a private list there such information *can* be given, again, 
there is no rule that I need to do this.
There are options if some other DD believes a package is needing an 
update, that process is called NMU (non maintainer upload). Or if you 
think the other maintainer isn't doing his work in a time able manner, a 
DD can salvage a package.

But these options are only doable by DDs! And that for a reason.


But without any reaction it feels to me that the package is not
important to the maintainer.


This depends heavily from the POV. As written, taking a 6 month off time 
might be an important time span for you, but this isn't true for other 
people.



This is not about a simple bug ticket. I asked seriously in public on
the list if the DPT could take over the package. Especially in this
situation I would expect a reaction. Asking in public is quit
impolite by me. But before I've done this I tried to reach jmw several
times.


Debian isn't working that way! It's all a project of volunteers, that 
why I'm did chose to be part of it. We are not bound to a company and we 
wont this to happen. So we all have no obligation to do something in a 
specific time window.
If you expect this than you should move to Canonical/Ubuntu, thats there 
businesses is made off.


...

Why can't only the maintainer answer this?


You might haven't read all ticket comments or I wasn't able to make my
question clear. The intention of my last comments to that ticket are to
understand how Jonathan worked around the problem while packaging. It
is my learning on the way becoming a Debian packager myself.


The "workaround", if there is one, is visible within the Debian package 
source.


https://salsa.debian.org/jmw/pkg-backintime/-/commits/debian

I don't see any workaround and there is non needed. The bug issue is 
about the not usable upstream test suite that would need to be called 
through d/rules.



As he describes the problem and I as understand, it must be impossible
to build and package backintime for Debian. But as it is obvious it is
somehow possible and I want to know how. I want to learn something
specific about that packaging here.


To quote from the BTS:
---%<---

In 1.2 upstream added a test suite. We should run it during build
(cd common && $(MAKE) test) but it needs to be able to write to the home
directory, which is disabled on Debian auto-builders. Need to find
a solution to that.

--->%---

To me it's clear what the problem is. The test requires a $HOME folder, 
but the build environment doesn't provide something like this.


You nee to dive into the Debian package build process if you want to 
learn the "why". But this list is the wrong place for this.
This list can help if you have specific questions about Python and 
Python packaging (as Mechtilde did mention).





I don't understand what or who is blocking whom here?
Is it that you feel you are blocked with your upstream work by the
maintainer?
[..]
If you only think that the maintainer of backintime should be
switched to the DPT then this is only a wish. And I don't think doing
such a switch is improving the situation for you, still someone needs
to do the work you requesting.


All this is not about work in the meaning of fixing, uploading or
something else. It is just about having a dialog. Without dialog I'm
not able to learn and to take over packaging someday to save your
resources. Not sure if it is against the Debian rules that upstream do
its own Debian packaging.


So you want and need to talk about how the Debian packaging is done? So 
you may be lucky to have some Debian folks around you which can explain 
this in one or more hacking session.


Or you went to Debian Mentors.
https://wiki.debian.org/DebianMentorsFaq
https://mentors.debian.net/
https://lists.debian.org/debian-mentors/

This is the place there a few Debian contributors are willing to answer 
questions 

Re: [backintime] Switch the maintainer to "Debian Python Team (DPT)"

[Carsten Schoenert]

Hello Christian,

Am 23.07.23 um 09:09 schrieb c.bu...@posteo.jp:

Hello,

On 2023-06-12 10:40 Jonathan Carter  wrote:

Adding DPT to at least uploaders and having the package VCS in the
python-team namespace would probably be a good idea, but that's up to
Jonathan Wiltshire.


I have to state that after 5 weeks of waiting there is no reaction from
Jonathan Wiltshire by mail, any bug-ticket (in context of backintime)
and even IRC.


it might be sounds strange to you, but 5 or sometimes also 8 weeks and 
longer isn't a long time within Debian. I know that my answer isn't 
helping you, it's simply quite all of the DMs and DDs are doing their 
work for Debian within their free and spare time and they can decide 
when to work on something.
And Jonathan isn't only active as package maintainer, it's up to him 
what are his priorities and on what he wanted to work on.



There is also this bug ticket where I had specific questions (in August
last year) only the maintainer can answer but got no reaction.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940319


Why can't only the maintainer answer this?
Also the issue is marked correctly as wishlist, typically this indicates 
also that the underlying issue isn't time critical.


If you want to get applied something quickly then make it easy to the 
maintainer to accept the suggested modifications. Means prepare one (or 
more) patches which are easy and save to pick. I can't see anything like 
this within the bug report.


For sure testing and test suites are always a good thing to add, but 
basically they are not needed for the functionality of a package.



How can we proceed further?
IMHO it is blocking the process waiting on someone who do not answer.


I don't understand what or who is blocking whom here?
Is it that you feel you are blocked with your upstream work by the 
maintainer?
Do you like to have more power within the Debian package of your 
upstream work?

Is there a issue in the Debian package that is causing trouble on the users?

If you only think that the maintainer of backintime should be switched 
to the DPT then this is only a wish. And I don't think doing such a 
switch is improving the situation for you, still someone needs to do the 
work you requesting.
The Debian policy is quite clear that a maintainer of a package has more 
or less the full power of the package, that's how Debian is build and 
also working for years.


So far I've not seen any DPT member in the past weeks who would be 
willing to do work on the package backintime. If you want to improve 
this then you are welcome to become a member of the DPT by doing work on 
packages which are in the maintenance of the DPT, but becoming a DM will 
take time and requires to learn and accept the rules of being a DM.


So you want to process further something?
Provide patches, improve packages, enhance documentation, do some kind 
of the work. That's the typical answers to that question.


--
Regards
Carsten

Re: Updating pdm-pep517 and pep517 and renaming to new upstream names?

[Carsten Schoenert]

I've forgotten to add the DD lists...

--
Regards
CarstenBoyuan Yang 
   findpython (U)
   pdm (U)
   pytoolconfig (U)
   rope (U)
   unearth (U)

Carsten Schoenert 
   flask-sqlalchemy (U)
   mkdocs-autorefs (U)
   mkdocstrings (U)
   mkdocstrings-python-handlers (U)
   mkdocstrings-python-legacy (U)
   python-griffe (U)
   pytkdocs (U)

Debian Python Team 
   autoimport
   findpython
   flask-sqlalchemy
   mkdocs-autorefs
   mkdocstrings
   mkdocstrings-python-handlers
   mkdocstrings-python-legacy
   pdm
   python-griffe
   pytkdocs
   pytoolconfig
   rope
   unearth

Edward Betts 
   autoimport (U)

Henning Sprang 
   flask-sqlalchemy (U)

Pablo Mestre Drake 
   rope (U)

Boyuan Yang 
   pdm (U)

Chris Lamb 
   diffoscope (U)

Debian Med Packaging Team 
   sniffles

Debian Python Team 
   check-manifest
   pdm
   poetry-core
   py7zr (U)
   python-build
   python-lsp-server

Emmanuel Arias 
   poetry-core (U)

Holger Levsen 
   diffoscope (U)

Jochen Sprickerhof 
   python-lsp-server (U)

Julian Gilbey 
   python-lsp-server (U)

Mattia Rizzolo 
   diffoscope (U)

Pablo Mestre Drake 
   python-lsp-server (U)

Pranav Ballaney 
   sniffles (U)

Reproducible builds folks 
   diffoscope

Sandro Tosi 
   py7zr

Sergio Durigan Junior 
   check-manifest (U)
   python-build (U)

Updating pdm-pep517 and pep517 and renaming to new upstream names?

[Carsten Schoenert]

Hi,

happy new year to you all!

Not only the Python version in bookworm is moving right now, due some 
side effect around that also the PDM build backend is moving fast.


I was working around the Xmas days on one of the packages I usually take 
care on (python-griffe [1]) to get an new upstream version ready for 
uploading. While doing I noticed that my local work was not building 
successful anymore due a new version of python-packaging which has some 
different structure of folders and files.



Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/pep517/wrappers.py", line 319, in 
_call_hook
raise BackendUnavailable(data.get('traceback', ''))
pep517.wrappers.BackendUnavailable: Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/pep517/in_process/_in_process.py", line 
77, in _build_backend
obj = import_module(mod_path)
  ^^^
  File "/usr/lib/python3.11/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
   
  File "", line 1206, in _gcd_import
  File "", line 1178, in _find_and_load
  File "", line 1149, in _find_and_load_unlocked
  File "", line 690, in _load_unlocked
  File "", line 940, in exec_module
  File "", line 241, in _call_with_frames_removed
  File "/usr/lib/python3/dist-packages/pdm/pep517/api.py", line 10, in 
from pdm.pep517.editable import EditableBuilder
  File "/usr/lib/python3/dist-packages/pdm/pep517/editable.py", line 13, in 

from pdm.pep517.wheel import WheelBuilder
  File "/usr/lib/python3/dist-packages/pdm/pep517/wheel.py", line 24, in 

from pdm.pep517.base import Builder
  File "/usr/lib/python3/dist-packages/pdm/pep517/base.py", line 12, in 
from pdm.pep517.metadata import Metadata
  File "/usr/lib/python3/dist-packages/pdm/pep517/metadata.py", line 20, in 

from pdm.pep517.version import DynamicVersion
  File "/usr/lib/python3/dist-packages/pdm/pep517/version.py", line 10, in 

from pdm.pep517.scm import get_version_from_scm
  File "/usr/lib/python3/dist-packages/pdm/pep517/scm.py", line 17, in 
from packaging.version import LegacyVersion, Version
ImportError: cannot import name 'LegacyVersion' from 'packaging.version' 
(/usr/lib/python3/dist-packages/packaging/version.py)

ERROR Backend 'pdm.pep517.api' is not available.
E: pybuild pybuild:386: build: plugin pyproject failed with: exit code=1: 
python3.11 -m build --skip-dependency-check --no-isolation --wheel --outdir 
/build/python-griffe-0.25.2/.pybuild/cpython3_3.11_griffe


The same build issue can now be found on recent FTBFS issue reports done 
by Lucas archive rebuilds.


While trying to understand what has changed I noticed also that 
src:pdm-pep517 [2] got an upstream update to (Thanks Boyuan Yang for 
packaging it!).

But, pdm-pep517 got also a renaming on the upstream side to pdm-backend [3].

I've done a rather quick and dirty import of the new version on top of 
the existing tree from src:pdm-517 to investigate things further.


After using the updated python3-pdm-pep517 package I see another PDM 
related package that will need an update.



Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/pep517/wrappers.py", line 319, in 
_call_hook
raise BackendUnavailable(data.get('traceback', ''))
pep517.wrappers.BackendUnavailable: Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/pep517/in_process/_in_process.py", line 
77, in _build_backend
obj = import_module(mod_path)
  ^^^
  File "/usr/lib/python3.11/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
   
  File "", line 1206, in _gcd_import
  File "", line 1178, in _find_and_load
  File "", line 1128, in _find_and_load_unlocked
  File "", line 241, in _call_with_frames_removed
  File "", line 1206, in _gcd_import
  File "", line 1178, in _find_and_load
  File "", line 1142, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'pdm.pep517'


The package failing while importing here is python3-pep517 (src:pep517 [4]).

But again as for pdm-pep517, also pep517 is renamed on the upstream side 
to pyproject-hooks [5].


I haven't done yet any local work on updating src:pep517 as I wanted to 
ask here on the list how to handle these two updated and renamed 
upstream projects.


The first one, src:pdm-pep517 seems not that difficult as it's only 
living in unstable and testing and the packages that are using the 
existing package as build dependency is rather small.


The second one, src:pep517 needs an transition to a new source package 
and also to a new binary package to me. And now it can get complicated, 
given we are about 4 weeks away from the first freeze step of the RMs.


What do other think?

I've attached DD 

Re: Request for salsa access

[Carsten Schoenert]

Hello Matthias,

Am 21.11.22 um 16:39 schrieb matthias.geiger1...@tutanota.de:

Dear Maintainers,

I'd like to join the team and get access to maintain python3-fints.
fints is a new package I filed an ITP for (#1024494). In my opinion it 
would be best if it
would be maintained under the python packaging team. I'd only need 
access for this library.


I acknowledge that I read the packaging policy. My salsa username is 
werdahias.

I'm not a DD yet, so I'd need sponsorship for this package.


I'd suggest to first work on your ITP and get more familiar with 
packaging of Debian packages in general. There is no need to first have 
a working access to the DPT group on Salsa. You will have to learn a lot 
things and to me it seems easier to work first within your own namespace 
on Salsa were you can act as you like. It's no problem to move packaging 
trees all over within the GitLab instance on Salsa later.


I did a quick look into the git tree you referenced within your ITP.

The branches for the upstream source and also pristine-tar are missing. 
It's of course somehow possible to get your current work build into a 
deb package, but the typical workflow is a bit different. :-)


You might want have a look at existing packages on Salsa within the DPT 
to get some inspiration how your tree layout should look like.


The DPT uses git-buildpackage for preparing packages, this tool can help 
a lot with the typical steps that are needed to produce the required 
files for a new package upload. But also in your case if you need to 
start a new package from scratch.


https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#id3

I suggest to have again a look into the DPT policy and also into 
existing packages and their git history to see and learn how things work 
together.
This mailing list is probably not the best place to get help on basic 
packaging question, there a better channels available (IRC, mailing list 
debian-mentors), but it *is* the place to ask specific questions about 
Python in Debian or Python packaging in detail.


Feel free to contact me directly for specific questions.

--
Regards
Carsten

Re: python-werkzeug 2.2.2 and flask 2.2.2 transition

[Carsten Schoenert]

Hi,

Am 13.11.22 um 07:18 schrieb Carsten Schoenert:

If there are no objections I will bump the severity of serious for the
remaining three bug reports this week.


currently I've raised the severity for only two remaining bug reports

flask-appbuilder: #1020739
searx-admin: #1020823

I've skipped #1023568 that was open against oninshare, but the main or 
first problem within the autopkgtest run is based on a outdated package 
flask-socketio.
And onionshare is currently not in testing and would not block a 
migration of flask and python-werkzeug.


@Thomas
I'd like to see flask and the required python-werkzeug in unstable soon 
so any outstanding issues after a first upload could get fixed before 
the hard freezes for bookworm will begin.


Do you have a timeline when any uploads of the two packages to unstable 
can happen?


--
Regards
Carsten

Re: python-werkzeug 2.2.2 and flask 2.2.2 transition

[Carsten Schoenert]

Hi,

Am 06.11.22 um 20:31 schrieb Carsten Schoenert:

Hi again,

currently I still see the following packages are left with autopkgtest
issues.

flask-appbuilder: #1020739
onionshare: #1023568
pydevd: #1020795
searx-admin: #1020823

I filed a new issue about the failing autopkgtest against onionshare
minutes ago.


it has shown, that onionshare isn't the problem for the breaking 
autopkgtest but flask-socketio is. The good news is that updating 
flask-socketio will be enough to solve the not working autopkgtest 
mainly. There is a small need to tune one of the remaining onionshare 
test calls.



What about raising the severity for the other packages? Time flies and
it's not that far away the first freeze date will come.


If there are no objections I will bump the severity of serious for the 
remaining three bug reports this week.


--
Regards
Carsten

Re: python-werkzeug 2.2.2 and flask 2.2.2 transition

[Carsten Schoenert]

Hi again,

currently I still see the following packages are left with autopkgtest 
issues.


flask-appbuilder: #1020739
onionshare: #1023568
pydevd: #1020795
searx-admin: #1020823

I filed a new issue about the failing autopkgtest against onionshare 
minutes ago.
What about raising the severity for the other packages? Time flies and 
it's not that far away the first freeze date will come.


Am 20.10.22 um 09:23 schrieb Carsten Schoenert:

Hi,
Am 27.09.22 um 11:52 schrieb Thomas Goirand:

Hi,

I'd like Bookworm to be released with python-werkzeug 2.2.2 and flask
2.2.2 (needed by Sahara).

So I've uploaded both to Experimental, and here's the result:
https://qa.debian.org/excuses.php?experimental=1=python-werkzeug
https://qa.debian.org/excuses.php?experimental=1=flask

So I filled bugs against the relevant packages:
pytest-httpbin: #1020728, #1020796
quart: #1020729
sentry-python: #1020730
flask-appbuilder: #1020739
flask-bcrypt: #1020824
flask-login: #1020794
pydevd: #1020795
python-flask-marshmallow: #1020822
searx-admin: #1020823


I've looked at some of these issues and fixed also some of them, the
following packages are left with build issues against the updated packages.

pytest-httpbin
flask-appbuilder
pydevd
searx-admin



--
Regards
Carsten

Re: build package xrayutilities - wheel and pip with setuptools

[Carsten Schoenert]

Hello Frederic,

Am 31.10.22 um 08:57 schrieb PICCA Frederic-Emmanuel:

I can build the package basically doing these modifications and by
adding the additional B-D package Scott did mention. Simply let
dh_sphinxdoc build the documentation and adding the additional needed
package dependencies.


[your patch]

In your proposition you removed the arch/indep split, is it on purpose ?


yes, building the Sphinx based documentation doesn't need to be done 
that (to me fragile) way. debhelper is smart enough to do the right 
things in the correct order if you tell it to use the sphinxdoc module.


--
Regards
Carsten

Re: build package xrayutilities - wheel and pip with setuptools

[Carsten Schoenert]

Hello Frederic,

please could you provide next time direct links to the VCS/Tracker of 
your package, that prevents time to search for the correct package on my 
or others people side. Also a speaking subject content is helping me to 
decide if I want to spend time on taking a look, you've choose a very 
generic line. :-)


https://tracker.debian.org/pkg/xrayutilities
https://salsa.debian.org/science-team/python-xrayutilities

Am 30.10.22 um 01:08 schrieb picca:

Le 2022-10-30 00:39, Scott Kitterman a écrit :


Adding  pybuild-plugin-pyproject to build-depends should solve it.  It
looks like it is trying to do the new pyproject.toml style build
without all the necessary parts in place.


the package contain a pyproject.toml file and a setup.py one.

the build system in the pyproject file is setuptools.

[build-system]
requires = ["setuptools", "wheel", "numpy"]
build-backend = "setuptools.build_meta"

So I imagine that under the hood it use the setup.py file.


No as you have overwritten the default target by a call that is quite 
similar to the original pybuild call.



now it fails with this error message

adding 'xrayutilities-1.7.3.dist-info/top_level.txt'
adding 'xrayutilities-1.7.3.dist-info/RECORD'
removing build/bdist.linux-x86_64/wheel
* Building wheel...
Successfully built xrayutilities-1.7.3-cp310-cp310-linux_x86_64.whl
I: pybuild plugin_pyproject:118: Unpacking wheel built for python3.10 with 
"installer" module
E: pybuild pybuild:379: build: plugin pyproject failed with: File already exists: 
/<>/.pybuild/cpython3_3.10_xrayutilities/build/xrayutilities/VERSION
dh_auto_build: error: pybuild --build -i python{version} -p 3.10 returned exit 
code 13
make[1]: *** [debian/rules:20: override_dh_auto_build-arch] Error 25


this failure seems to come from the indep part


%:
  dh $@ --buildsystem=pybuild

execute_after_dh_auto_clean:
  rm -rf build

override_dh_auto_build-arch:
  dh_auto_build

override_dh_auto_build-indep: override_dh_auto_build-arch
ifeq (,$(findstring nodoc, $(DEB_BUILD_OPTIONS)))
  dh_auto_build -- -s custom --build-args="env
PYTHONPATH={build_dir} {interpreter} setup.py build_doc"
endif


since I make the indep part depends on the arch one, it build the
package a second time. and this is during this second reconstruction
that
it failes.

it seems that the arch rules does not gard from a second build, and it
is not indepotent...


Yes, the environment isn't the same for the second call, you'd need to 
ensure that the build directory is clean before starting the second run. 
But I don't see why this construct you've build in d/rules is needed 
that way.


I can build the package basically doing these modifications and by 
adding the additional B-D package Scott did mention. Simply let 
dh_sphinxdoc build the documentation and adding the additional needed 
package dependencies.



$ git diff
diff --git a/debian/control b/debian/control
index 4a702ea..1b746a3 100644
--- a/debian/control
+++ b/debian/control
@@ -10,9 +10,9 @@ Section: science
 Priority: optional
 Build-Depends:
  debhelper-compat (= 13),
- dh-python,
  dh-sequence-numpy3,
  dh-sequence-python3,
+ pybuild-plugin-pyproject,
  python3-all-dev,
  python3-h5py,
  python3-lmfit,
diff --git a/debian/rules b/debian/rules
index 54c4cb0..089385d 100755
--- a/debian/rules
+++ b/debian/rules
@@ -4,6 +4,7 @@
 # Uncomment this to turn on verbose mode.
 export DH_VERBOSE=1
 export DEB_BUILD_MAINT_OPTIONS=hardening=+all
+export DEB_HOST_ARCH?=$(shell dpkg-architecture -qDEB_HOST_ARCH)
 
 # copy the tests to the build dir to be able to pass nose

 export PYBUILD_NAME=xrayutilities
@@ -11,18 +12,13 @@ export PYBUILD_BEFORE_TEST=cp -r tests {build_dir}; cp -r 
examples {build_dir};
 export PYBUILD_AFTER_TEST=rm -rf {build_dir}/tests; rm -rf 
{build_dir}/xrayutilities/materials/data; rm -rf {build_dir}/examples
 
 %:

-   dh $@ --buildsystem=pybuild
+   dh $@ --with sphinxdoc --buildsystem=pybuild
 
-execute_after_dh_auto_clean:

-   rm -rf build
-
-override_dh_auto_build-arch:
-   dh_auto_build
-
-override_dh_auto_build-indep: override_dh_auto_build-arch
+override_dh_sphinxdoc:
 ifeq (,$(findstring nodoc, $(DEB_BUILD_OPTIONS)))
-   dh_auto_build -- -s custom --build-args="env PYTHONPATH={build_dir} 
{interpreter} setup.py build_doc"
+   PYTHONPATH=. python3 -m sphinx -b html -N doc/source 
$(CURDIR)/debian/python-xrayutilities-doc/usr/share/doc/python-xrayutilities-doc/html
+   dh_sphinxdoc
 endif
 
-execute_after_dh_installdocs:

-   dh_installdocs -p python-xrayutilities-doc build/sphinx/html
+execute_after_dh_auto_clean:
+   rm -rf build


lintian has some additional remarks any way, I haven't looked further at 
these.


--
Regards
Carsten

Re: python-werkzeug 2.2.2 and flask 2.2.2 transition

[Carsten Schoenert]

Hi,
Am 27.09.22 um 11:52 schrieb Thomas Goirand:

Hi,

I'd like Bookworm to be released with python-werkzeug 2.2.2 and flask
2.2.2 (needed by Sahara).

So I've uploaded both to Experimental, and here's the result:
https://qa.debian.org/excuses.php?experimental=1=python-werkzeug
https://qa.debian.org/excuses.php?experimental=1=flask

So I filled bugs against the relevant packages:
pytest-httpbin: #1020728, #1020796
quart: #1020729
sentry-python: #1020730
flask-appbuilder: #1020739
flask-bcrypt: #1020824
flask-login: #1020794
pydevd: #1020795
python-flask-marshmallow: #1020822
searx-admin: #1020823


I've looked at some of these issues and fixed also some of them, the 
following packages are left with build issues against the updated packages.


pytest-httpbin
flask-appbuilder
pydevd
searx-admin

--
Regards
Carsten

Re: Enabling salsa-ci on all Debian Python Team repos

[Carsten Schoenert]

Hello Emanuele,

Am 21.09.22 um 12:01 schrieb Emanuele Rocca:

Well but that's the whole point of automated testing. There's no *need*
to do it locally if it's already done by Salsa for you. What is already
automated and working pretty well is:

- amd64 build
- i386 build
- source build
- autopkgtest
- blhc
- lintian
- piuparts
- reprotest
- arm64 crossbuild

That's a pretty time consuming list of things to go through for a human!


sure, that's a killer argument that I can't really argue against. But 
that is not the point for me.


For all these checks we already have existing infrastructure, running 
the same also by a pipeline job isn't helping at all if it's not clear 
how to handle the fallout (we already mostly have seen in other places 
too!).


As Sandro and Arnaud have pointed out it's probably mostly a matter of 
the workflow for a package upload. And for me the CI pipeline stuff 
right now doesn't fit really into the package upload workflow that is 
typically used.


Using the CI stuff in your own namespace is perfectly fine and I'm using 
this option from time to time. But I use there also the possibility to 
do heavily force pushing to not blow up the git tree with dozens of 
Fixup commits! In the 'official' git tree this is a no go of course.


Nobody is perfect and even every Python package will have it's own small 
differences in between. As long as we don't have *one* Debian way to 
build packages and a helpful way to deal with breakage in any of the 
test runs it will always be a waste of time an energy to run for all 
packages a CI run at all times!


If the decision is to do this step I will simply need to ignore any 
errors that are not RC.



The only work left to be done on your machine is a binary build to see
if the packages look good, perhaps some specific manual testing [1],
source build and upload. Isn't that better?


I do all package built locally as a all/any build run.
As written above and trying to say, I like atomic git commits that are 
doing things "correct" and by looking at the commit it's clear why this 
commit was done.
I have to "fight" enough on my day job with my colleagues as they do git 
mostly using committing every forward and backward steps with no clean 
up locally finally before pushing their stuff and so I need to spend a 
lot of time to get the changes and their basically meaning. You would 
end up the same in the packages here as people would commit again and 
again to fix up the packages.


I stand on my thinking, it's not helpful to enable a global CI for all 
packages. Doing this from case to case is absolutely fine to me.


Arnaud Ferraris has written about the usage of a CI option in Debian 
Mobile etc.
His writing is affirming me as I see and have the same experience within 
the PureOS ecosystem. People work there the same as I did describe, 
package are prepared in the local namespace and if the CI is running 
there successfully then a push to the team namespace is done.


--
Regards
Carsten

Re: Enabling salsa-ci on all Debian Python Team repos

[Carsten Schoenert]

Hi,

Am 20.09.22 um 16:13 schrieb Emanuele Rocca:

Salsa CI is useful because it automatically performs binary/source builds,
arm64 crossbuilds, and it runs various pretty important tests such as lintian,
piuparts, reproducible build testing, and more. It also runs autopkgtest in
LXC.


quite most of these steps I usually need to do locally before I do any 
upload of packages. So I see no real gain to run any pipeline by 
default, for me this would be just burning energy in CPU cycles just for 
"because we can".


CI/CD makes sense for me within a greater view such as is a version 
upgrade of package A not break other stuff in other packages, like does 
working all packages that now need to use a new version of pytest or 
setuptools, django etc. But that's not ready within the current way the 
default CI pipeline is working (in my POV).


So no, for me it makes currently no sense to enable a CI thingy for ALL 
packages by default!


We have automatic Lintian checks, the buildds itself, and also the 
autopkgtest infrastructure, why double such things, that's waste of 
energy and resources! The packages are not getting better by running 
tests multiple times within the same environment.
And given my experience within other teams and groups, nobody really 
cares about packages that fail in some tests within a CI run. I strongly 
believe it wouldn't be better here.



Sure you can do all this manually on your own, but it's better to live in a
world where the machines work for us rather than the other way around. :-)


I still don't see why this is a benefit.
If you use an CI option within your own namespace is another thing, 
doing so make sense to me to prepare a new version for uploading.


--
Regards
Carsten

Re: RFS: tpm2-pytss

[Carsten Schoenert]

Hello Claudius,

Am 08.09.22 um 13:37 schrieb Claudius Heine:


Related to this, I would like to update the tpm2-pkcs11 package, which
is not part of the DPT, but the new version depends on that package.

Do I need to wait until the tpm2-pytss package is available on unstable
before doing this, or can this be done in parallel?


from a technical side it would be no problem, the buildd's simply 
couldn't build this package due the dep chain.


But I try to avoid such uploads and wait for required depending packages.
First, it helps me to have some better overview of my or team related 
packages. If the package isn't visible here I know there is some work left.
Second, other user who doesn't know all related things might wondering 
why the uploaded new version isn't build. This can be confusing.


And third, in this case here, the upload would be a NMU if the 
maintainer of tpm2-pkcs11 [1] might not react on bug reports or emails.


So, a general suggestion in my eyes is to get always in contact with the 
package maintainers of tpm2-pkcs11, which you have done so far through 
#1011376 [2].
You can prepare and provide an MR on Salsa so the package could be easy 
updated by the original maintainers and write about within the issue 
tracking.



[1] https://tracker.debian.org/pkg/tpm2-pkcs11
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011376

--
Regards
Carsten

Re: RFS: tpm2-pytss

[Carsten Schoenert]

Hello Claudius,

Am 05.09.22 um 14:26 schrieb Claudius Heine:

The link I posted is already in the DPT namespace:

  https://salsa.debian.org/python-team/packages/tpm2-pytss

Since I am no a member of the team, I wanted to move it over, but it
already existed, but was completely empty. So I just pushed my changes
there.


ahh, o.k, I haven't seen this.
I've take now this repo as base for the initial upload, now we need to 
wait for the ftpmaster to process this package.


https://ftp-master.debian.org/new/tpm2-pytss_1.2.0-1.html

--
Regards
Carsten

Re: RFS: tpm2-pytss

[Carsten Schoenert]

Hello Claudius,

Am 01.09.22 um 10:59 schrieb Claudius Heine:

Hi Carsten,

On 2022-09-01 10:56, Carsten Schoenert wrote:

Hello Claudius,

I can take care on this, might take time until the weekend.


Thanks!


you are welcome!

I did go through the source again some days ago and that resulting in a 
new MR for tpm2-pytss which I raised afterwards.


https://salsa.debian.org/cmhe/tpm2-pytss/-/merge_requests/3

I see two options to getting further.
Option 1) would be that you please meld this MR into the current state, 
you than also adjust the changelog subject line with 
s/UNRELEASED/unstable and move the tree over to the DPT so I would just 
need to rebuild the package finally.


Or option 2) could be I create a new repo within the DPT namespace on 
Salsa an do the small adjustments by myself.


I can happily live with any of these options.

--
Regards
Carsten

Re: RFS: tpm2-pytss

[Carsten Schoenert]

Hello Claudius,

I can take care on this, might take time until the weekend.

Am 01.09.22 um 08:47 schrieb Claudius Heine:

Hi,

would someone be willing to sponsor the tpm2-pytss package?

  https://salsa.debian.org/python-team/packages/tpm2-pytss

This package is a dependencies of newer versions of tpm2-pkcs11 (>= 1.8.0).

regards,
Claudius



--
Regards
Carsten

Re: New package for tpm2-pytss

[Carsten Schoenert]

Hi,

Am 25.08.22 um 09:25 schrieb Claudius Heine:


I am not possessive about this package and would like to share
maintainer-ship if possible. For me this is contract work, I am not
doing this for myself, but for a customer, which will continue to use
this and packages around it for rolling out Linux-based Desktop systems
for their employees. So I suspect that this will be used and maintained
in any case, even if not my me personally.


well, if packaging work is covered any payed by the employee or 
costumers than this is great as it also shows it's possible to earn 
money with FOSS.


I just wanted to stress out that it's sometimes better to not start 
packaging work if it's already recognizable that were will no time 
afterwards to do the maintenance work, which is mostly more work than 
the initial packaging. At some point almost every software will get some 
security update which needs to get incorporated into the package and the 
archive. As you work for DENX I'm quite sure what I mean. :-)



Debian already contains the tpm2-pkcs11 package, which in its newest
version (1.8.0) (see #1011376 [1]) will require tpm2-pytss (which this
is about). So I guess sooner or later (if tpm2-pkcs11 is still
maintained), someone will need to create tpm2-pytss as well.

tpm2-pkcs11 1.8.0 is required to fix bugs when used with openssl 3, that
are present in older versions (1.7.0).

My goal here mainly was to help and speed up the upgrade of tpm2-pkcs11
to 1.8.0 by supplying the tpm2-pytss package. Also of course avoiding
low-quality and duplicate work by providing the packages to upstream Debian.


...


Yes, sure. I already started doing that as soon as my salsa account was
approved:

https://salsa.debian.org/cmhe/tpm2-pytss

That should work already, but currently I am just adding salsa-ci
support, and possible fixing some metadata issues.


I've take a look and opened up a MR to address some small things I've 
noted. Your work looks good so far.


https://salsa.debian.org/cmhe/tpm2-pytss/-/merge_requests/2

Feel free to cherry-pick or merge in the modifications.

I haven't looked yet into potential copyright things, if some other 
member would have time to have also a look at this that would be great.


--
Regards
Carsten

Re: New package for tpm2-pytss

[Carsten Schoenert]

Hello Claudius,

Am 24.08.22 um 15:00 schrieb Claudius Heine:

Hi,

I am not a member of the Python team and want to contribute a Debian
package for tpm2-pytss to help resolve #1011358 [1].

I am not sure how to proceed here. Do I need to become a
member/contributor/maintainer of this package or will this package be
collectively maintained by the python team afterwards?


this depends on you and your intentions.
If you want to maintain this package by your own you don't need to 
become a member of the Python Packaging Team. But you will need a 
sponsor for your uploads then.


One big advantage of team maintained package is that not only one 
specific maintaining person (the Maintainer field in d/control) is 
required and to be around. You still can add yourself to the Uploaders 
field anyway.


Maintaining a package costs time and requires technical skills to 
fulfill the Debian packaging policy. Ask yourself if you can ensure you 
will have the required time to do the packaging work, especially if you 
want to maintain the package alone by yourself, but also if you are 
interested in maintaining this package within the DPT.
It's not a good behavior to prepare a package, find a sponsor and then 
the contributor isn't seen anymore afterwards. Other Debian maintainer 
will need to take care on that package then.



I guess I need to be a member to create the repo on salsa. I already
have made an account there (@cmhe).


Yes, if you want to create a repo within the teams namespace.

But you can always create new repos within YOUR own namespace! The repo 
could later easily transferred into the DPT space on Salsa once the 
trees are ready and finished.


I'd suggest to start that way and ask here on the list once you feel 
someone should review your work.
You can e.g. force push to your git tree as often you want to do so or 
feel to need to do. Once the repo is within the DPT force pushing is a 
no-go and is mostly disabled for good reason.



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


If you are interested in showing that you are willing to do further work 
on this issue you should take over the ownership for this issue and also 
do a retitle of the bug report e.g. by using the 'bts' command. This is 
available locally once you have installed the package devscripts and 
have setup a local MTA [1]. I personally use nullmailer for this job


You can then interact with the BTS and set the ownership.


bts owner 1011358 c...@denx.de , retitle 1011358 "ITP: tpm2-pytss -- TPM2 TSS Python 
bindings"


More explanations about controlling the BTS can be found here:

https://www.debian.org/Bugs/server-control

[1] https://wiki.debian.org/msmtp
https://wiki.debian.org/sSMTP
https://wiki.debian.org/nullmailer

--
Regards
Carsten

Re: archive rebuild for pytest from experimental

[Carsten Schoenert]

Hi,

Am 16.06.22 um 10:05 schrieb Julian Gilbey:
...

Great, thanks.  Since the pygments in testing fails on pytest 7.2.1,
and the version in experimental depends on pytest >= 7.0, we'll need
to do the following when we are ready to upload pytest 7.2.1 to
unstable:

* Mark pytest 7.2.1 as Breaks: pygments (<< 2.12.0)


looking at the autopkgtest on the CI pygments is still failing while 
testing with versions from testing. Mostly because I think as pytest < 7 
(from testing) is used. All other versions differences are not critical 
I guess. The following list of used packages are given by the different 
versions between testing and unstable.



testing: python3-lib2to3 all 3.9.12-1
testing: python3-distutils all 3.9.12-1
testing: python3-toml all 0.10.2-1
testing: python3-pytest all 6.2.5-3


unstable:  python3-lib2to3 all 3.10.5-1
unstable:  python3-distutils all 3.10.5-1
unstable:  python3-tomli all 1.2.2-2
unstable:  python3-pytest all 7.1.2-2


Currently python3-pytest hasn't an entry for breaking on pygments like 
Julian was proposing. Maybe I'm still missing something.


--
Regards
Carsten

Re: archive rebuild for pytest from experimental

[Carsten Schoenert]

Hi,

Am 15.06.22 um 21:22 schrieb Louis-Philippe Véronneau:


# Doesn't seem like a pytest regression, but I could be wrong?:
...
* sentry-python 1.4.3-1 (AssertionError: previous item was not torn down 
properly)

# Already fixed in the archive:

* monitoring-plugins-systemd 2.3.1-2


I've updated sentry-python last week to the current upstream version, so 
this package can be count as fixed.


Current pygments requires pytest >= 7.0, I've uploaded 2.12.0 to 
experimental.


--
Regards
Carsten

Re: PDM - Python package manager for Debian

[Carsten Schoenert]

Hi Nick,

Am 03.04.22 um 09:58 schrieb Dominik George:

Hi Carsten,


Or is there a way to get such packages build without a need for PDM to be 
around?


This should really not matter at all when packaging for Debian. The
source tarball should include a setup.cfg or setup.py file (i.e. be a
regular Python sdist), and if not developing on the package, you
should never meet PDM.


yeah, but upstream isn't shipping one or both files, it only ships a 
file pyproject.toml. And switched from Poetry to PDM recently


https://github.com/mkdocstrings/autorefs/commit/85f3920ec153e6aa3c206475977b8666ac340504


If the upstream sdist is not installable without PDM, this is
probably an upstream bug; but my guess is that you chose a Git export
instead of a real sdist as orig.tar.gz.


No, I did pick up the tagged version 0.4.1 as tarball from GitHub as 
usual to start with as I'm aware of this trap.


https://github.com/mkdocstrings/autorefs/tags

I've compared the tarball from GH with the file from PyPi, the sdist on 
PyPi contains even less files than the GH tarball, but also no setup.* 
files.


https://pypi.org/project/mkdocs-autorefs/#files


If helpful I can upload my current WIP scratch status to my namespace on 
Salsa.


So far I've read about PDM the past hours, it's quite new yes, but more 
upstream projects will switch or start with this package management 
system I guess. So somehow the Debian packaging of Python libraries will 
need to deal with this.


--
Regards
Carsten

PDM - Python package manager for Debian

[Carsten Schoenert]

Hi,

while working further on doing packaging on NetBox I've started trying 
to package more upcoming new dependencies.


Namely I was looking into mkdocstrings [1], which is a new dep for the 
next minor version of NetBox (in order to build the documentation).


mkdocstrings comes (of course) with own new package build deps [2] on 
mkdocs-autorefs [3] and mkdocstrings-python-legacy [4].

pymdown-extensions is something Sandro Tosi was already working on.

To get the additional build dependencies packaged first I started on 
mkdocs-autorefs.

While doing this the package build breaks due missing PDM support.


dh binary --with python3 --buildsystem=pybuild
   dh_update_autotools_config -O--buildsystem=pybuild
   dh_autoreconf -O--buildsystem=pybuild
   dh_auto_configure -O--buildsystem=pybuild
   dh_auto_build -O--buildsystem=pybuild
I: pybuild plugin_pyproject:107: Building wheel for python3.9 with "build" 
module
I: pybuild base:237: python3.9 -m build --skip-dependency-check --no-isolation --wheel --outdir /build/mkdocs-autorefs-0.4.1/.pybuild/cpython3_3.9_autorefs 
* Building wheel...


Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/pep517/wrappers.py", line 332, in 
_call_hook
raise BackendUnavailable(data.get('traceback', ''))
pep517.wrappers.BackendUnavailable: Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/pep517/in_process/_in_process.py", line 
89, in _build_backend
obj = import_module(mod_path)
  File "/usr/lib/python3.9/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 1030, in _gcd_import
  File "", line 1007, in _find_and_load
  File "", line 972, in _find_and_load_unlocked
  File "", line 228, in _call_with_frames_removed
  File "", line 1030, in _gcd_import
  File "", line 1007, in _find_and_load
  File "", line 972, in _find_and_load_unlocked
  File "", line 228, in _call_with_frames_removed
  File "", line 1030, in _gcd_import
  File "", line 1007, in _find_and_load
  File "", line 984, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'pdm'

ERROR Backend 'pdm.pep517.api' is not available.
E: pybuild pybuild:367: build: plugin pyproject failed with: exit code=1: python3.9 -m build --skip-dependency-check --no-isolation --wheel --outdir /build/mkdocs-autorefs-0.4.1/.pybuild/cpython3_3.9_autorefs 
I: pybuild plugin_pyproject:107: Building wheel for python3.10 with "build" module
I: pybuild base:237: python3.10 -m build --skip-dependency-check --no-isolation --wheel --outdir /build/mkdocs-autorefs-0.4.1/.pybuild/cpython3_3.10_autorefs 
* Building wheel...


Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/pep517/wrappers.py", line 332, in 
_call_hook
raise BackendUnavailable(data.get('traceback', ''))
pep517.wrappers.BackendUnavailable: Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/pep517/in_process/_in_process.py", line 
89, in _build_backend
obj = import_module(mod_path)
  File "/usr/lib/python3.10/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 1050, in _gcd_import
  File "", line 1027, in _find_and_load
  File "", line 992, in _find_and_load_unlocked
  File "", line 241, in _call_with_frames_removed
  File "", line 1050, in _gcd_import
  File "", line 1027, in _find_and_load
  File "", line 992, in _find_and_load_unlocked
  File "", line 241, in _call_with_frames_removed
  File "", line 1050, in _gcd_import
  File "", line 1027, in _find_and_load
  File "", line 1004, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'pdm'

ERROR Backend 'pdm.pep517.api' is not available.
E: pybuild pybuild:367: build: plugin pyproject failed with: exit code=1: python3.10 -m build --skip-dependency-check --no-isolation --wheel --outdir /build/mkdocs-autorefs-0.4.1/.pybuild/cpython3_3.10_autorefs 
dh_auto_build: error: pybuild --build -i python{version} -p "3.9 3.10" returned exit code 13

make: *** [debian/rules:10: binary] Error 13
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
I: copying local configuration
E: Failed autobuilding of package


I've tried to find out if we have in Debian PDM already included but 
haven't found any Python related packages. But my knowledge about core 
package build backends is really poor. And doing a packaging of such an 
module is for sure to much I could do.


Anyone here on the list who can shad some light about PDM [5] or is 
someone already working on this?
Or is there a way to get such packages build without a need for PDM to 
be around?
Sorry if this is a stupid questions, but I'm really not in the deep 
interns of Python package build systems.



[1] https://github.com/mkdocstrings/mkdocstrings
[2] 
https://github.com/mkdocstrings/mkdocstrings/blob/master/pyproject.toml#L37

[3] https://github.com/mkdocstrings/autorefs

Re: Bug#1006483: ITP: python3-mergedeep -- A deep merge function for Python

[Carsten Schoenert]

Hello Edward,

I've wrote an ITP for the same package shortly before your ITP:

https://bugs.debian.org/1006479

And uploaded to NEW right now.
So you shouldn't need to do any additional work, I'm happy if you want 
to do some co-maintaining and uploading for this package.


Regards
Carsten

Am 26.02.22 um 09:12 schrieb Edward Betts:

Package: wnpp
Severity: wishlist
Owner: Edward Betts 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org

* Package name: python3-mergedeep
   Version : 1.3.4
   Upstream Author : Travis Clarke
* URL : https://github.com/clarketm/mergedeep
* License : MIT
   Programming Lang: Python
   Description : A deep merge function for Python

Includes four merge strategies:

## Replace

When destination and source keys are the same, replace
the destination value with one from source (default).

## Additive

When destination and source values are both the same additive
collection type, extend destination by adding values from source.

Additive collection types include: list, tuple, set, and Counter

## Typesafe replace
When destination and source values are of different types, raise
TypeError. Otherwise, perform a REPLACE merge.

## Typesafe additive

When destination and source values are of different types, raise
TypeError. Otherwise, perform a ADDITIVE merge.


This is a dependency of the datasette tool by Simon Willison.

I plan to maintain this package as part of the python modules team.

Re: Fixing pytest-twisted ^W Updating twisted

[Carsten Schoenert]

Hi again,

Am 24.01.22 um 06:35 schrieb Carsten Schoenert:
...

So I think I can answer my original question by  myself. These two
packages are not relevant and not needed any more. But thanks for your
feedback!


I moved along and worked further on tuning the packaging for twisted.

I'm able to build new binary packages for the latest release of 21.7.0 
and also can run the autopkgtest at the end successful. Again I've 
pushed all to


https://salsa.debian.org/tijuca/twisted

Also the Lintian issues are down to an amount of minimum compared to the 
output for 20.3.0.

https://lintian.debian.org/sources/twisted


$ lintian -IE --pedantic
W: python3-twisted: no-manual-page usr/bin/cftp3
W: python3-twisted: no-manual-page usr/bin/ckeygen3
W: python3-twisted: no-manual-page usr/bin/conch3
W: python3-twisted: no-manual-page ... use --no-tag-display-limit to see all 
(or pipe to a file/program)
W: twisted-doc: privacy-breach-generic 
usr/share/doc/twisted-doc/html/_downloads/c0d415299e6995227a6e3c8a2ed17fe5/slots-attributes-output.html
 [http://example.com/user.png; />] (http://example.com/user.png)
W: python3-twisted: uses-implicit-await-trigger interest (line 1)
W: twisted-doc: zero-byte-file-in-doc-directory 
usr/share/doc/twisted-doc/html/api/extra.css
X: python3-twisted: application-in-library-section python usr/bin/twistd3 
usr/bin/twist3 usr/bin/cftp3 usr/bin/pyhtmlizer3 usr/bin/trial3 usr/bin/conch3 
usr/bin/mailmail3 usr/bin/ckeygen3 usr/bin/tkconch3
X: python3-twisted: library-package-name-for-application usr/bin/twistd3 
usr/bin/twist3 usr/bin/cftp3 usr/bin/pyhtmlizer3 usr/bin/trial3 usr/bin/conch3 
usr/bin/mailmail3 usr/bin/ckeygen3 usr/bin/tkconch3
X: twisted source: debian-watch-does-not-check-gpg-signature
X: twisted-doc: duplicate-files usr/share/doc/twisted-doc/development/index.rst 
usr/share/doc/twisted-doc/html/_sources/core/development/index.rst.txt
X: twisted-doc: duplicate-files 
usr/share/doc/twisted-doc/development/listings/new_module_template.py 
usr/share/doc/twisted-doc/html/_downloads/4ba91eba2b7dc02d171b2b303f7cae54/new_module_template.py
X: twisted-doc: duplicate-files 
usr/share/doc/twisted-doc/development/naming.rst 
usr/share/doc/twisted-doc/html/_sources/core/development/naming.rst.txt
X: twisted-doc: duplicate-files ... use --no-tag-display-limit to see all (or 
pipe to a file/program)
P: twisted-doc: example-unusual-interpreter python 
[usr/share/doc/twisted-doc/examples/courier.py]
P: twisted-doc: example-unusual-interpreter python 
[usr/share/doc/twisted-doc/examples/dbcred.py]
P: twisted-doc: example-unusual-interpreter python 
[usr/share/doc/twisted-doc/examples/echoclient.py]
P: twisted-doc: example-unusual-interpreter ... use --no-tag-display-limit to 
see all (or pipe to a file/program)
P: python3-twisted: executable-in-usr-lib 
usr/lib/python3/dist-packages/twisted/mail/test/pop3testserver.py
P: python3-twisted: executable-in-usr-lib 
usr/lib/python3/dist-packages/twisted/trial/test/scripttest.py
P: twisted-doc: repeated-path-segment finger 
usr/share/doc/twisted-doc/howto/tutorial/listings/finger/finger/
P: twisted source: very-long-line-length-in-source-file NEWS.rst line 196 is 1030 
characters long (>512)
P: twisted source: very-long-line-length-in-source-file docs/core/howto/amp.rst 
line 183 is 535 characters long (>512)
P: twisted source: very-long-line-length-in-source-file docs/core/howto/defer.rst 
line 501 is 702 characters long (>512)
P: twisted source: very-long-line-length-in-source-file ... use 
--no-tag-display-limit to see all (or pipe to a file/program)



The original issue because I was looking into twisted isn't fixed yet, 
the used upstream version hasn't fixed the deprecation warning for 
currentThread().
But a new main upstream version 22.1.0 is in preparation, that will come 
with a merged in PR to fix this.


https://github.com/twisted/twisted/pull/1671

Besides this I think I'm mostly ready to give the current state a try 
and upload the modifications to unstable.


Still I'm happy to hear other minds about updating twisted before going 
further.


--
Regards
Carsten

Re: Fixing pytest-twisted ^W Updating twisted

[Carsten Schoenert]

Hello Gregor,

Am 23.01.22 um 19:01 schrieb Gregor Riepl:



Ignoring the autopkgtest for now Lintian is complaining about empty
binary packages for python3-twisted-{bin,dbg}. Are they needed anymore?
OTOH it's looking not that bad and a lot of the messages should be easy
to fix.



X: python3-twisted: library-package-name-for-application usr/bin/cftp3 
usr/bin/trial3 usr/bin/conch3 usr/bin/pyhtmlizer3 usr/bin/twist3 
usr/bin/mailmail3 usr/bin/twistd3 usr/bin/tkconch3 usr/bin/ckeygen3


Sounds to me like these binaries should go into the python3-twisted-bin
package, and that it shouldn't be empty after all.

Maybe you're missing a python3-twisted-bin.install file?


currently there isn't such an sequencer file. The moving of files was 
done directly within debian/rules.


The currently existing -bin package has some libraries included which 
seems to be used only for some tests.


https://packages.debian.org/bookworm/amd64/python3-twisted-bin/filelist

These SO files are not build anymore and have moved into a new own project.

https://github.com/twisted/cython-test-exception-raiser

So I think I can answer my original question by  myself. These two 
packages are not relevant and not needed any more. But thanks for your 
feedback!


--
Regards
Carsten

Fixing pytest-twisted ^W Updating twisted

[Carsten Schoenert]

Hi,

I've came across through #1001371 which is basically


pytest-twisted: (autopkgtest) needs update for python3.10: E {'warnings': 2} != 
{'warnings': 1}


https://bugs.debian.org/1001371

So far I understand the information from the bug report the real problem 
isn't a broken autopkgtest in pytest-twisted but rather a deprecation 
warning from twisted which turns into an error.


So I've looked into twisted. We currently ship a quite old version and I 
think instead of "just" fixing the current version in unstable/testing 
we should updating twisted to the most recent version in a midterm.


I've already done some work to get this done, but at least the 
autopkgtest is something I haven't got to successful working.


My current WIP can be found here:

https://salsa.debian.org/tijuca/twisted

I created a new branch debian/master on top of the current master branch 
(due to group policy) and I tried to update the patch queue (successful 
I think), a lot of old patches are not needed anymore I'd say.


I also added some new patches later while working on issues to get the 
build at least completed. I do not have a greater experience on the 
twisted framework, so currently I can't say for sure that my current WIP 
is completely right, but it should be nearly by.


Currently the autopkgtest beaks on some version comparing which I can't 
really rate.



twisted.trial.unittest.FailTest: '[dummy, version 1.0.0rc1]' != '[dummy, 
version 1.0.0.rc1]'


The relevant part is visible here:


https://salsa.debian.org/tijuca/twisted/-/jobs/2375834#L504


I tend to disable these tests for now to make progress on more relevant 
parts like updating d/rules to debhelper style. But without some help 
regarding the later required binary packages I wont get done this.


Ignoring the autopkgtest for now Lintian is complaining about empty 
binary packages for python3-twisted-{bin,dbg}. Are they needed anymore?
OTOH it's looking not that bad and a lot of the messages should be easy 
to fix.



$ lintian -IE
W: python3-twisted-bin: empty-binary-package
W: python3-twisted-bin-dbg: empty-binary-package
W: python3-twisted: no-manual-page usr/bin/cftp3
W: python3-twisted: no-manual-page usr/bin/ckeygen3
W: python3-twisted: no-manual-page usr/bin/conch3
W: python3-twisted: no-manual-page ... use --no-tag-display-limit to see all 
(or pipe to a file/program)
W: twisted-doc: privacy-breach-generic 
usr/share/doc/twisted-doc/html/_downloads/c0d415299e6995227a6e3c8a2ed17fe5/slots-attributes-output.html
 [http://example.com/user.png; />] (http://example.com/user.png)
W: python3-twisted: uses-implicit-await-trigger interest (line 1)
W: twisted-doc: zero-byte-file-in-doc-directory 
usr/share/doc/twisted-doc/html/api/extra.css
X: python3-twisted: application-in-library-section python usr/bin/cftp3 
usr/bin/trial3 usr/bin/conch3 usr/bin/pyhtmlizer3 usr/bin/twist3 
usr/bin/mailmail3 usr/bin/twistd3 usr/bin/tkconch3 usr/bin/ckeygen3
I: twisted source: debian-rules-parses-dpkg-parsechangelog (line 8)
I: twisted source: duplicate-long-description python3-twisted 
python3-twisted-bin
I: twisted source: duplicate-short-description python3-twisted 
python3-twisted-bin
X: python3-twisted: library-package-name-for-application usr/bin/cftp3 
usr/bin/trial3 usr/bin/conch3 usr/bin/pyhtmlizer3 usr/bin/twist3 
usr/bin/mailmail3 usr/bin/twistd3 usr/bin/tkconch3 usr/bin/ckeygen3
I: twisted source: no-dh-sequencer
I: twisted source: out-of-date-standards-version 4.5.1 (released 2020-11-17) 
(current is 4.6.0.1)
I: python3-twisted: package-contains-documentation-outside-usr-share-doc 
usr/lib/python3/dist-packages/twisted/internet/iocpreactor/notes.txt
X: python3-twisted-bin: package-contains-no-arch-dependent-files
X: python3-twisted-bin-dbg: package-contains-no-arch-dependent-files
I: twisted source: patch-not-forwarded-upstream 
debian/patches/0012-Skip-test-for-empty-cypher-string-openssl-does-not-t.patch
I: twisted source: patch-not-forwarded-upstream 
debian/patches/Privacy-Don-t-sideload-Google-Analytics.patch
I: twisted source: patch-not-forwarded-upstream 
debian/patches/WIP-Ignore-test_listingModulesAlreadyImport.patch
I: twisted source: patch-not-forwarded-upstream ... use --no-tag-display-limit 
to see all (or pipe to a file/program)
I: twisted source: upstream-metadata-missing-bug-tracking


I'm happy to hear some feedback how to proceed with the twisted framework.
I wanted to "clean" up the patch queue by uniform patch names e.g. and 
extend commit messages, but for now it's better to keep the old patches 
as changes are easier to track by this currently.


--
Regards
Carsten

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

[Carsten Schoenert]

Hi Antonio,

thanks for your quick feedback!

Am 19.09.21 um 21:24 schrieb Antonio Terceiro:


Looking from my side, the tarball from the archive (apt source
python-django-js-asset) and the one generated by pristine-tar are
identical:

4b6a2c8625b8e96bbc4ff1588a27238d7d418b03  
/tmp/python-django-js-asset_1.2.2.orig.tar.gz
4b6a2c8625b8e96bbc4ff1588a27238d7d418b03  
/tmp/archive/python-django-js-asset_1.2.2.orig.tar.gz

 From reading the REJECT email, I think it implies that the .dsc/.changes
you uploaded refer to an orig tarball with 6360 bytes. Do you still have
the exact artifacts that you uploaded?


No, not completely.
But I played around a bit with gbp and pristine-tar too and I was able 
to recreate a tarball which has the same size and the same hashes as the 
*.tar.gz in the archive and the one you've posted by using pristine-tar 
manually.


If I clean out all completely and build the package from scratch by gbp 
I get again a wrong size and of course also different hashes.


Currently I've no real clue why gbp is creating here different results, 
will look again at this once Guido is around, I'm sure he can blame me 
that I'm doing something wrong. :P


I was able to upload 1.2.2-3 successful recently so no big problem any more.

--
Regards
Carsten

Re: Request to join the Python Team

[Carsten Schoenert]

Hello Stefano,

Am 18.05.21 um 13:06 schrieb Stefano Rivera:
> Hi Carsten (2021.05.17_17:04:13_+)
>> I'd like to join the Python team on Salsa.
> 
> Please read
> https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
> 
> Hint: 3rd point about joining the team.

arg, my bad.

Of course I have before the policy and I agree on that.

-- 
Regards
Carsten

Request to join the Python Team

[Carsten Schoenert]

Hi,

I'd like to join the Python team on Salsa.

Recently I've taken over the maintainer ship for flask-sqlalchemy
together with a long time businesses partner I'm working together with
on my day job.

And some more packages are to come I want to work on.

For another Django based project we needed to get
python-django-crispy-forms-foundation packaged. I'm testing currently
the prepared Debian packages on this.

My username on Salsa is tijuca. Thanks!

-- 
Regards
Carsten