Re: I want to join the DPT

[Bo YU]

Hi all,

On Thu, Mar 17, 2022 at 10:44 PM Sandro Tosi  wrote:

> > Sorry again. I recheck the #1007025 [0], it should be RFP tag.
> > This is my misspelt in the first request email.
> > So I think I can go to to work it :-)
>
> OMG you're right! i guess morning coffee hadnt kicked in when first
> replying. I would still contact anarcat before starting any work,
> because they may already have started the packaging effort and you two
> can collaborate. It's also possible nothing was done and so you can
> start from scratch.
>
I am a newbie for Debian develop and noticed the RFP [0]. So, hi Antoine,
Have you started to work on this? If not, I think I can finish it with
DPT's help:-).
If yes, please let us know(As I said, I am a newbie and do not know what
this is polite
to ask the reporter directly. No offense).
Thank you all,
Bo


> if you need help, you can let this mailing list know, or if you're
> comfortable using IRC, you can ask questions in #debian-python on the
> OFTC network
>
> Thanks,
> --
>
[0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007025

> Sandro "morph" Tosi
> My website: http://sandrotosi.me/
> Me at Debian: http://wiki.debian.org/SandroTosi
> Twitter: https://twitter.com/sandrotosi
>

Re: Bug#1007025: I want to join the DPT

[Bo YU]

On Fri, Mar 18, 2022 at 9:30 PM Antoine Beaupré  wrote:

> On 2022-03-18 16:45:25, Bo YU wrote:
> > Hi all,
> >
> > On Thu, Mar 17, 2022 at 10:44 PM Sandro Tosi  wrote:
> >
> >> > Sorry again. I recheck the #1007025 [0], it should be RFP tag.
> >> > This is my misspelt in the first request email.
> >> > So I think I can go to to work it :-)
> >>
> >> OMG you're right! i guess morning coffee hadnt kicked in when first
> >> replying. I would still contact anarcat before starting any work,
> >> because they may already have started the packaging effort and you two
> >> can collaborate. It's also possible nothing was done and so you can
> >> start from scratch.
> >>
> > I am a newbie for Debian develop and noticed the RFP [0]. So, hi Antoine,
> > Have you started to work on this? If not, I think I can finish it with
> > DPT's help:-).
>
> Hi!
>
> I'm happy to see anyone pick up this work. I don't have the context for
> that thread, but I did (deliberately) file the bug as an RFP (Request
> For Package). If I would be working on it, I would have changed its
> status to ITP (Intent To Package). So while it's nice to hear from you,
> you don't actually need my approval to go ahead and package this. :)
>
> (I file a lot of RFPs, mostly to keep track of packages missing from
> Debian. But sometimes I do start working on them and I *do* make sure to
> change the bug status accordingly.)
>
> > If yes, please let us know(As I said, I am a newbie and do not know what
> > this is polite
> > to ask the reporter directly. No offense).
>
> No offense taken whatsoever. Also: I didn't receive that email at all, I
> had to be told by a friend about your response (and I don't know how
> they found it!) because you didn't CC me...
>
Oops, my bad. I forget to cc you indeed :-(.

>
> By default, the BTS doesn't include the original submitter when you only
> write to the bug report...
>
Thank you all. I have changed the RFP to ITP for the bug. I can't wait to
start the adventure. :-)
BR,
Bo

> a.
>
> --
> From the age of uniformity, from the age of solitude, from the age of
> Big Brother, from the age of doublethink - greetings!
> - Winston Smith, 1984
>

Re: I want to join the DPT

[Bo YU]

On Sun, Mar 27, 2022 at 7:11 AM Stefano Rivera  wrote:

> Hi vimer (2022.03.17_14:34:11_+)
> > I have read the policy [1] and accept it.
> > In fact, in my native language, the follow is the same as accept.
> > Whataway, I accept the policy now.
>
> Added, welcome.
>
Thank you. I am get to work already:-)

>
> SR
>
> --
> Stefano Rivera
>   http://tumbleweed.org.za/
>   +1 415 683 3272
>

RFS: git-multimail/1.5.0-1 [ITP] -- git-multimail is a tool for sending notification emails on pushes

[Bo YU]

From: Bo YU 
To: sub...@bugs.debian.org
Subject: RFS: git-multimail/1.5.0-1 [ITP] -- git-multimail is a tool
for sending notification emails on pushes

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "git-multimail":

 * Package name: git-multimail
   Version : 1.5.0-1
   Upstream Author : Matthieu Moy 
 * URL : https://github.com/git-multimail/git-multimail
 * License : GPL-2.0+, GPL-2.0
 * Vcs : https://salsa.debian.org/python-team/packages/git-multimail
   Section : python

The source builds the following binary packages:

  python3-git-multimail - git-multimail is a tool for sending
notification emails on pushes

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/git-multimail/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/g/git-multimail/git-multimail_1.5.0-1.dsc

Changes for the initial release:

 git-multimail (1.5.0-1) unstable; urgency=medium
 .
   * Initial release of git-multimail to Debian. (Closes: #1007025)
 .
   * Start from upstream's packaging. With some refreshing:
 .
 -- Add myself as Maintainer.

Regards,
-- 
  Bo YU

RFS: git-multimail/1.5.0-1 [ITP] -- git-multimail is a tool for sending notification emails on pushes

[Bo YU]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,
Sorry, due to previous email mismatch pseudo-header, the debian
tracker system does not deal with the bug report,so send again.
I am looking for a sponsor for my package "git-multimail":

 * Package name: git-multimail
   Version : 1.5.0-1
   Upstream Author : Matthieu Moy 
 * URL : https://github.com/git-multimail/git-multimail
 * License : GPL-2.0+, GPL-2.0
 * Vcs : https://salsa.debian.org/python-team/packages/git-multimail
   Section : python

The source builds the following binary packages:

  python3-git-multimail - git-multimail is a tool for sending
notification emails on pushes

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/git-multimail/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/g/git-multimail/git-multimail_1.5.0-1.dsc

Changes for the initial release:

 git-multimail (1.5.0-1) unstable; urgency=medium
 .
   * Initial release of git-multimail to Debian. (Closes: #1007025)
 .
   * Start from upstream's packaging. With some refreshing:
 .
 -- Add myself as Maintainer.

Regards,
-- 
  Bo YU

RFS: git-multimail/1.6.0-1 [ITP] -- git-multimail is a tool for sending notification emails on pushes

[Bo YU]

Dear mentors,

I am looking for a sponsor for my package "git-multimail":

 * Package name: git-multimail
   Version : 1.6.0-1
   Upstream Author : Matthieu Moy 
 * URL : https://github.com/git-multimail/git-multimail
 * License : GPL-2, GPL-2+
 * Vcs : https://salsa.debian.org/python-team/packages/git-multimail
   Section : python

The source builds the following binary packages:

  python3-git-multimail - git-multimail is a tool for sending notification 
emails on pushes

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/git-multimail/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/g/git-multimail/git-multimail_1.6.0-1.dsc

Changes for the initial release:

 git-multimail (1.6.0-1) unstable; urgency=medium
 .
   * Initial release of git-multimail to Debian. (Closes: #1007025)

-

Now I have to flag FLAKY on upstream's test case becasue most of them
will fail, see https://github.com/git-multimail/git-multimail/issues/221 
pep8 have been renamed pycodestyle but its case did not switch it.


Another thing is that jcfp helped me to review some months ago, it was
1.5.0, but recently upstream release 1.6.0 tag. 1.5.0 codebase has
been existed in salsa and i import-orig 1.6.0 based on 1.5.0. so you
will see an odd thing in d/changelog file maybe.


--
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Re: git-multimail 1.6.0 package review

[Bo YU]

Hi,
On Thu, Sep 15, 2022 at 05:32:33PM +0100, Antoine Beaupré wrote:

Hi!

I've done a quick review of the 1.6.0 package on salsa as of commit
d5bd184a1cf73b752f80dea46d8080493a5e663b.

It looks like there's some leftover stuff in debian/copyright, i would
remove this:

modified   debian/copyright
@@ -2,8 +2,6 @@ Format: 
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: git-multimail
Upstream-Contact: Matthieu Moy 
Source: https://github.com/git-multimail/git-multimail
-#
-# Please double check copyright with the licensecheck(1) command.

Files: *
Copyright: 2014-2022, Matthieu Moy 


Ok, removed comment here.



Also, I didn't quite follow the work on the test cases, but why did you
replace pep8 by pycodestyle in the patch in debian/patches? The patch
itself doesn't actually explain the *why* (it explains the "what" but we
typically want more than this...)


This time i add dep3 header for the patch. It should be noted that
despite this patch, it is still not helpful for upstream test cases.
I have forwarded this for upstream:
https://github.com/git-multimail/git-multimail/issues/221#issuecomment-1245009306
(To avoid bring noisy for upstream, i just recorded it in a issue)



It seems like you have README.rst both in debian/rules and
debian/docs. Either one of those should be sufficient, and you should
remove the other. Same with the launcher in
python3-git-multimail.install vs debian/rules.


There should be no duplicate file. I have droped they.


I'm also surprised we need that launcher at all. Normally, the
`setup.py` wrapper has a scripts= stanza which should install the
upstream one, why do we do it differently?


yeah. The reason why I use launcher here is bacause that @jcfp helped
me to review it in the previous time:

```
the (large) git_multimail.py file is installed twice, both as a
public module under /usr/lib/python3 and as a script in /usr/bin;
the latter could be replaced by a tiny launcher (take a look at the
nfoview package if you need inspiration; your launcher would be even
shorter because it doesn't need the sys.path manipulation)
```
I am not sure if I understand jcfp's meaning correctly and I refer to
nfoview:
https://salsa.debian.org/python-team/packages/nfoview/-/blob/debian/master/debian/launcher/nfoview

The issue is that I installed git_multimail.py twice in fact it should
be under /usr/lib/python3 only as jcfp said. So i remove it in /usr/bin
by hand.

Now I have removed the launcher for git-multimail and it should work:)


I would also name the binary package `git-multimail` instead of
`python3-git-multimail`, since we don't really care that much that the
thing is written in python, since it's not a library.


Got it. I mixed python module and library here.

(I paste and copy another mail in here:)


Finally, one fundamental issue with this package is that, as you
correctly identified, it's unmaintained upstream. If we do ship it in
Debian, maybe we'd want to keep it out of stable until that is settled?


Ok. I think so also. Fortunately, maintainer of upstream has a little
response, but that's all.


I think that's what I have for now. I haven't double-checked the
upstream branch to see if it matches the upstream repo I have here, but
that would be my next step before uploading... just a formality to make
sure everything matches up.

Thanks for working on this package!


Thanks. This is the first package made by me with you all help.

The new version for git-multimail is here:
https://mentors.debian.net/package/git-multimail/

Thanks again for your encouragement.:)

--
The greatest crimes in the world are not committed by people breaking
the rules but by people following the rules. It's people who follow
orders that drop bombs and massacre villages.
   - Banksy




--
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Re: Bug#1007025: git-multimail 1.6.0 package review

[Bo YU]

Hi,
On Tue, Sep 20, 2022 at 10:56:05AM -0400, Antoine Beaupré wrote:

https://github.com/git-multimail/git-multimail/issues/221#issuecomment-1245009306
(To avoid bring noisy for upstream, i just recorded it in a issue)


I don't think pull requests are noisy... you should probably just submit
this as a PR upstream.


Ok, got it. Will do.
Sometime I mentioned the patch in the issue, the maintainer of upstream will
pick it into if he think that is valuable.


[...]


nfoview:
https://salsa.debian.org/python-team/packages/nfoview/-/blob/debian/master/debian/launcher/nfoview

The issue is that I installed git_multimail.py twice in fact it should
be under /usr/lib/python3 only as jcfp said. So i remove it in /usr/bin
by hand.

Now I have removed the launcher for git-multimail and it should work:)


Hm. This is weird. Why would you *not* want git-multimail under
/usr/bin? I understand the that git_multimail.py *module* should be in
/usr/lib/, but you should *also* have a launcher in /usr/bin/

I think, therefore, this is incorrect:

+override_dh_python3:
+   dh_python3
+   rm -f debian/git-multimail/usr/bin/git_multimail.py
+

First off, don't use `-f` there: we *do* want to fail if the file
doesn't exist, so that we can remove the override.


yeah, right.


Second, this looks wrong: `git-multimail` (the launcher) should be the
thing that's installed under /usr/bin, not `git_multimail.py` (the
module). If the module ends up in /usr/bin, then it's probably a bug
upstream that should be filed.

Could you clarify what happens with the package right now?


The issue is that, it really seems like a bug here.

First, I install git-multimail manual:

```
sudo python setup.py install

# log is below
...
creating /usr/local/lib/python3.10/dist-packages/git_multimail-1.5.0-py3.10.egg
Extracting git_multimail-1.5.0-py3.10.egg to 
/usr/local/lib/python3.10/dist-packages
Adding git-multimail 1.5.0 to easy-install.pth file
Installing git_multimail.py script to /usr/local/bin
...

vimer@dev:~/build/rfs/git-multimail$ which git_multimail.py
/usr/local/bin/git_multimail.py
```

It looks like you said. The git_multimail.py is placed in
/usr/local/bin/git_multimail.py (if from debian package, it will be
placed into /usr/bin/)

The content of git-multimail.deb is:

```
  This package provides the Python 3 modules and the git-multimail script.

drwxr-xr-x root/root 0 2022-09-14 09:11 ./
drwxr-xr-x root/root 0 2022-09-14 09:11 ./usr/
drwxr-xr-x root/root 0 2022-09-14 09:11 ./usr/bin/
-rwxr-xr-x root/root161143 2022-09-14 09:11 ./usr/bin/git_multimail.py
drwxr-xr-x root/root 0 2022-09-14 09:11 ./usr/lib/
drwxr-xr-x root/root 0 2022-09-14 09:11 ./usr/lib/python3/
drwxr-xr-x root/root 0 2022-09-14 09:11 ./usr/lib/python3/dist-packages/
drwxr-xr-x root/root 0 2022-09-14 09:11 
./usr/lib/python3/dist-packages/git_multimail-1.6.0.egg-info/
-rw-r--r-- root/root 35851 2022-09-14 09:11 
./usr/lib/python3/dist-packages/git_multimail-1.6.0.egg-info/PKG-INFO
-rw-r--r-- root/root 1 2022-09-14 09:11 
./usr/lib/python3/dist-packages/git_multimail-1.6.0.egg-info/dependency_links.txt
-rw-r--r-- root/root14 2022-09-14 09:11 
./usr/lib/python3/dist-packages/git_multimail-1.6.0.egg-info/top_level.txt
-rw-r--r-- root/root161147 2022-07-21 07:30 
./usr/lib/python3/dist-packages/git_multimail.py
drwxr-xr-x root/root 0 2022-09-14 09:11 ./usr/share/
drwxr-xr-x root/root 0 2022-09-14 09:11 ./usr/share/doc/
drwxr-xr-x root/root 0 2022-09-14 09:11 ./usr/share/doc/git-multimail/
-rw-r--r-- root/root 11317 2022-07-21 07:30 
./usr/share/doc/git-multimail/README.rst.gz
-rw-r--r-- root/root   210 2022-09-14 09:11 
./usr/share/doc/git-multimail/changelog.Debian.gz
-rw-r--r-- root/root  1755 2022-09-14 09:11 
./usr/share/doc/git-multimail/copyright
```
I think the people found the issue also:
https://github.com/git-multimail/git-multimail/issues/221#issuecomment-1252529169

Certainly, lintian will give a kindly warning:
W: git-multimail: script-with-language-extension [usr/bin/git_multimail.py]

If I understand correctly, this is a bug as you said.
The workround is still to use launcher file in d/ as in previous commit?

Many thanks for your time to help me review it again :)

--
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Re: Bug#1007025: git-multimail 1.6.0 package review

[Bo YU]

Hi,
On Thu, Sep 22, 2022 at 02:12:07PM -0400, Antoine Beaupré wrote:

On 2022-09-22 19:43:24, Jeroen Ploemen wrote:

On Thu, 22 Sep 2022 12:35:12 -0400
Antoine Beaupré  wrote:


I think the simplest solution is not to rewrite the launcher, but to
rename it. So in debian/rules, you would simply do:

override_dh_auto_install:
dh_auto_install
mv debian/git-multimail/usr/bin/git_multimail.py
debian/git-multimail/usr/bin/git-multimail


Antoine, IIRC the git_multimail.py file upstream installs into
/usr/bin is not a launcher but a full copy of the module as installed
into /usr/lib/python3. The code in that file auto-detects whether
it's run as a program.


Oh. I misunderstood that, sorry.


Sorry, maybe my words misled you also here.




That resulted in two copies of that sizeable file in the package I
reviewed back in June. Hence my suggestion - quoted in an earlier
message by Bo - to replace the copy in /usr/bin with a tiny launcher,
reducing the installed size of the package by almost half.


Sure, that completely makes sense then, sorry.


Ok, I have re-enabled the launcher and other issues fixed for git-multimail
as your and jcfp's suggestions.

Thanks all and please let me know if any issues.

--
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Re: Bug#1007025: git-multimail 1.6.0 package review

[Bo YU]

Hi

On Sat, Sep 24, 2022 at 3:34 PM Bo YU  wrote:
>
> Hi,
> On Thu, Sep 22, 2022 at 02:12:07PM -0400, Antoine Beaupré wrote:
> >On 2022-09-22 19:43:24, Jeroen Ploemen wrote:
> >> On Thu, 22 Sep 2022 12:35:12 -0400
> >> Antoine Beaupré  wrote:
> >>
> >>> I think the simplest solution is not to rewrite the launcher, but to
> >>> rename it. So in debian/rules, you would simply do:
> >>>
> >>> override_dh_auto_install:
> >>> dh_auto_install
> >>> mv debian/git-multimail/usr/bin/git_multimail.py
> >>> debian/git-multimail/usr/bin/git-multimail
> >>
> >> Antoine, IIRC the git_multimail.py file upstream installs into
> >> /usr/bin is not a launcher but a full copy of the module as installed
> >> into /usr/lib/python3. The code in that file auto-detects whether
> >> it's run as a program.
> >
> >Oh. I misunderstood that, sorry.
>
[...]
>
> Thanks all and please let me know if any issues.

I have sent the PR and whcih was merged:
https://github.com/git-multimail/git-multimail/pull/224

The latest version git-multimail debian package is here:
https://mentors.debian.net/package/git-multimail/

Thanks again.:)

>
> --
> Regards,
> --
>Bo YU
>

how to fix TypeError: expected string or bytes-like object ?

[Bo YU]

hi,
(maybe this is off topic on this list)
When I want to run sphinx cmd on my pc, I got the error:
```
vimer@dev:~/build/rfs/packages/test_dir$ cat /tmp/sphinx-err-etgbo9tg.log
# Sphinx version: 4.5.0
# Python version: 3.10.7 (CPython)
# Docutils version: 0.17.1 release
# Jinja2 version: 3.0.3
# Last messages:

# Loaded extensions:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/sphinx/cmd/build.py", line 272,
in build_main
app = Sphinx(args.sourcedir, args.confdir, args.outputdir,
  File "/usr/lib/python3/dist-packages/sphinx/application.py", line
220, in __init__
self.preload_builder(buildername)
  File "/usr/lib/python3/dist-packages/sphinx/application.py", line
297, in preload_builder
self.registry.preload_builder(self, name)
  File "/usr/lib/python3/dist-packages/sphinx/registry.py", line 142,
in preload_builder
builder_entry_points = entry_points(group='sphinx.builders')
  File "/usr/lib/python3/dist-packages/importlib_metadata/__init__.py",
line 1047, in entry_points
return SelectableGroups.load(eps).select(**params)
  File "/usr/lib/python3/dist-packages/importlib_metadata/__init__.py",
line 477, in load
ordered = sorted(eps, key=by_group)
  File "/usr/lib/python3/dist-packages/importlib_metadata/__init__.py",
line 1044, in 
eps = itertools.chain.from_iterable(
  File "/usr/lib/python3/dist-packages/importlib_metadata/_itertools.py",
line 16, in unique_everseen
k = key(element)
  File "/usr/lib/python3/dist-packages/importlib_metadata/__init__.py",
line 961, in _normalized_name
or super()._normalized_name
  File "/usr/lib/python3/dist-packages/importlib_metadata/__init__.py",
line 628, in _normalized_name
return Prepared.normalize(self.name)
  File "/usr/lib/python3/dist-packages/importlib_metadata/__init__.py",
line 883, in normalize
return re.sub(r"[-_.]+", "-", name).lower().replace('-', '_')
  File "/usr/lib/python3.10/re.py", line 209, in sub
return _compile(pattern, flags).sub(repl, string, count)
TypeError: expected string or bytes-like object
```
The problem may be in importlib_metadata here, but I am not sure how to fix it.
I remembered I do `python setup.py build/install` something ago.
Any help is welcome!

BR,
Bo

Re: how to fix TypeError: expected string or bytes-like object ?

[Bo YU]

Hi,
On Wed, Oct 05, 2022 at 01:33:53PM +0300, Felix Yan wrote:

On 10/5/22 12:47, Bo YU wrote:

hi,
(maybe this is off topic on this list)
When I want to run sphinx cmd on my pc, I got the error:
```

[...]

line 883, in normalize
return re.sub(r"[-_.]+", "-", name).lower().replace('-', '_')
  File "/usr/lib/python3.10/re.py", line 209, in sub
return _compile(pattern, flags).sub(repl, string, count)
TypeError: expected string or bytes-like object
```


Looks like this: https://github.com/sphinx-doc/sphinx/issues/10339


I noticed it also but I did not remember use sphinx with rinohtype
extension.


Are you using the rinohtype extension too?


The fact is that I am packaging the sphinxcontrib-ditaa[0] and I want to
test it via pip3:

```
vimer@dev:~/build/rfs/packages/test_dir$ sudo pip3 install  sphinxcontrib-ditaa
Collecting sphinxcontrib-ditaa
  Using cached sphinxcontrib-ditaa-1.0.1.tar.gz (7.5 kB)
  Preparing metadata (setup.py) ... error
  error: subprocess-exited-with-error

  × python setup.py egg_info did not run successfully.
  │ exit code: 1
  ╰─> [30 lines of output]
  Traceback (most recent call last):
File "", line 2, in 
File "", line 34, in 
File 
"/tmp/pip-install-c2wygkxs/sphinxcontrib-ditaa_10e1c64028af47e59b8fc5bf20b6901c/setup.py",
 line 8, in 
  setup(
File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 86, 
in setup
  _install_setup_requires(attrs)
File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 75, 
in _install_setup_requires
  dist = MinimalDistribution(attrs)
File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 57, 
in __init__
  super().__init__(filtered)
File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 474, in 
__init__
  for ep in metadata.entry_points(group='distutils.setup_keywords'):
File "/usr/lib/python3.10/importlib/metadata/__init__.py", line 1009, 
in entry_points
  return SelectableGroups.load(eps).select(**params)
File "/usr/lib/python3.10/importlib/metadata/__init__.py", line 459, in 
load
  ordered = sorted(eps, key=by_group)
File "/usr/lib/python3.10/importlib/metadata/__init__.py", line 1006, in 

  eps = itertools.chain.from_iterable(
File "/usr/lib/python3.10/importlib/metadata/_itertools.py", line 16, 
in unique_everseen
  k = key(element)
File "/usr/lib/python3.10/importlib/metadata/__init__.py", line 941, in 
_normalized_name
  return self._name_from_stem(stem) or super()._normalized_name
File "/usr/lib/python3.10/importlib/metadata/__init__.py", line 622, in 
_normalized_name
  return Prepared.normalize(self.name)
File "/usr/lib/python3.10/importlib/metadata/__init__.py", line 871, in 
normalize
  return re.sub(r"[-_.]+", "-", name).lower().replace('-', '_')
File "/usr/lib/python3.10/re.py", line 209, in sub
  return _compile(pattern, flags).sub(repl, string, count)
  TypeError: expected string or bytes-like object
  [end of output]

  note: This error originates from a subprocess, and is likely not a problem 
with pip.
error: metadata-generation-failed

× Encountered error while generating package metadata.
╰─> See above for output.

```

So I think the issue maybe not raised from sphinx extension, but it could be 
worse than that.

Thanks for help:)
[0]: https://pypi.org/project/sphinxcontrib-ditaa/


--
Regards,
Felix Yan






--
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Re: how to fix TypeError: expected string or bytes-like object ?

[Bo YU]

Hi,
On Wed, Oct 05, 2022 at 02:28:56PM +0300, Felix Yan wrote:

On 10/5/22 14:02, Bo YU wrote:

```
vimer@dev:~/build/rfs/packages/test_dir$ sudo pip3 install  
sphinxcontrib-ditaa

Collecting sphinxcontrib-ditaa
  Using cached sphinxcontrib-ditaa-1.0.1.tar.gz (7.5 kB)
  Preparing metadata (setup.py) ... error
  error: subprocess-exited-with-error


[...]

  return self._name_from_stem(stem) or super()._normalized_name
    File "/usr/lib/python3.10/importlib/metadata/__init__.py", 
line 622, in _normalized_name

  return Prepared.normalize(self.name)
    File "/usr/lib/python3.10/importlib/metadata/__init__.py", 
line 871, in normalize

  return re.sub(r"[-_.]+", "-", name).lower().replace('-', '_')
    File "/usr/lib/python3.10/re.py", line 209, in sub
  return _compile(pattern, flags).sub(repl, string, count)
  TypeError: expected string or bytes-like object
  [end of output]

  note: This error originates from a subprocess, and is likely not 
a problem with pip.

error: metadata-generation-failed

× Encountered error while generating package metadata.
╰─> See above for output.

```


You are right. The traceback is indeed different but more similar to 
this one, probably: https://github.com/pypa/setuptools/issues/3273


I have tried to make an empty .dist-info dir and got the very similar 
result to yours.


The following command may help to locate the actual offending package:

strace -eopenat python -c "from importlib.metadata import 
entry_points; print(entry_points(group='sphinx.builders'))"




Great! It works.

I deleted the package that was installed by setup.py with above command
hint. Everythng is well now.

Many thanks~

--
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

RFS: tkcalendar/1.6.1-1 [ITP] -- Calendar widget for Tkinter

[Bo YU]

I am looking for a sponsor for my package "tkcalendar":

 * Package name     : tkcalendar
   Version          : 1.6.1-1
   Upstream contact : Juliette Monsel 
 * URL              : https://github.com/j4321/tkcalendar
 * License          : GPL-3.0+
 * Vcs              : https://salsa.debian.org/python-team/packages/tkcalendar
   Section          : python

The source builds the following binary packages:

  tkcalendar - Calendar widget for Tkinter

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/tkcalendar/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/t/tkcalendar/tkcalendar_1.6.1-1.dsc

Changes for the initial release:

 tkcalendar (1.6.1-1) unstable; urgency=low
 .
   * Initial release. Closes: #1021073

-
The main issue is below:

I change Architecture: all -> any field on d/control, because if it was all,
then will get warning:
```
dh_auto_test: warning: "You asked that all arch in(dep) packages be built, 
but there are none of that type" 
```

and then skip the test suite. This is very odd but I have no idea how to fix it.

The package is depended on by pygubu.

--
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Re: Review of Debian package lazy-loader

[Bo YU]

Hi,
On Fri, Oct 21, 2022 at 11:58:38PM -0400, Louis-Philippe Véronneau wrote:

Hello,

This is my review of the lazy-loader package you asked the Debian 
Python Team to sponsor in the Debian archive.


1. In d/control, I'm not sure to understand why the binary package is 
marked as "Multi-Arch: foreign", as this package isn't arch dependent?


The binary package is arch dependent as it was marked as "Architecture: all"
I think. There is more knowledge for me to here:
https://wiki.debian.org/MultiArch/Hints#set_Multi-Arch:_foreign

Fixed it.






[...]
You should instead run the upstream test suite as autopkgtests: they 
are much more meaningful.


Have a look at this example:

https://salsa.debian.org/python-team/packages/metalfinder/-/tree/debian/master/debian/tests



Ok, The package now is updated according to the all above review comments.

6. In d/changelog, you marked your entry as "unstable", whereas it 
should be UNRELEASED. Please re-read the DPT's policy with regards to 
this.


Ok, this is different entry with previous package that has been
sponsored by others DD. But I think 'UNRELEASED' entry is right:)


7. Although I have not listed them here, pretty much all of the 
lintian tags raised are relevant errors that you should fix.


Yeah, I run lintian the package this time and it got nothing from my
chroot build. The only error from mentor is:
```
Package uploaded for the UNRELEASED distribution

I think it should be ok this time.



--

You're 90% there!

I've removed your package from the sponsor queue for now, but feel 
free to re-add it when you feel like you've dealt with my review. I'll 
be happy to sponsor it then.


Thanks you very much! I have updated it from your valueable review.
Please let me know if there is any issues.

--
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Re: Bug#1022526: python-ssdeep: FTBFS: distutils.errors.DistutilsClassError: command class must subclass Command

[Bo YU]

Hi,
On Sat, Nov 19, 2022 at 02:06:04AM +0200, Adrian Bunk wrote:

Control: tags -1 fixed-upstream

On Sun, Nov 13, 2022 at 10:04:04AM +0200, Stefano Rivera wrote:

Hi Helmut (2022.11.04_11:36:41_+0200)
> And no, updating it to 3.4 does not fix the ftbfs.

Updating it to 3.4.1 might. It includes this commit:
https://github.com/DinoTools/python-ssdeep/commit/fce02106c07ff56a84097dec0df02fb00ef69dc7
which moves the setuptools import above the first distutils import,
which should resolve this issue.


I can confirm that 3.4.1 does fix the build
(but I am reluctant to update it myself).


Is it ok to update for me?
I have built it based on 3.4.1:
https://salsa.debian.org/python-team/packages/python-ssdeep/-/tree/debian/main/

One question:
If I put the packahe under Debian Python team, should to change
maintainer to DPT from QA team?

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


--
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Help to package xdoctest

[Bo YU]

Hi,

I am packaging the xdoctest to meet ubelt's[0] B-D.

Now I think it has a good shape in packaging[1], but I am not sure
about below warning:

```
W: python3-xdoctest: no-manual-page [usr/bin/xdoctest]
P: xdoctest source: very-long-line-length-in-source-file 563 > 512
[dev/outline.md:11]
X: python3-xdoctest: application-in-library-section python [usr/bin/xdoctest]
X: xdoctest source: debian-watch-does-not-check-openpgp-signature [debian/watch]
X: python3-xdoctest: library-package-name-for-application [usr/bin/xdoctest]

```
First, the executable program is placed in the /usr/bin directory, right?
In my understanding, Python modules should be put in
/usr/lib/python3/dist-packages/xdoctest. But it is ok for program
entry in /usr/bin also.

If so, I should add manpage for it.

Please help me to confirm it, TIA.

BR,
Bo

[0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026966
[1]: https://salsa.debian.org/python-team/packages/xdoctest/-/tree/debian/main/

Re: review for pygubu/0.27-1

[Bo YU]

Hi,

First sorry for the late reply.

On Sat, Dec 10, 2022 at 6:17 PM Jeroen Ploemen  wrote:
>
> hi Bo,
>
> my comments for the pygubu package up for sponsorship in the Python
> team:
>
> * changelog: only a single entry is needed for an initial debian
>   release.
>
> * copyright:
>   + please remove the copyright statement at the start of the MIT
> license paragraph so that it contains only the license terms;
>   + tests/support.py appears to be based on [1] (i.e. from upstream
> python, license info at [2])?
>
> * control:
>   + do you need python3-tk for any other purpose than running tests?
> If not, mark as !nocheck;
>   + "Description: Debian packaging for pygubu": you want to describe
> pygubu itself here, not that it's packaged for Debian - every
> package in the distribution is, after all.
>

It is easy to fix these above issues.

> * rules: the script at development/runtests.sh simply calls "python3
>   -m unittest" on the tests dir for the default python3 only, which
>   is not what you want. Consider letting pybuild (+pytest?) handle
>   things directly, for example by changing the override to something
>   like PYBUILD_SYSTEM=custom PYBUILD_TEST_ARGS="xvfb-run -a
>   {interpreter} -m pytest -v tests" dh_auto_test.

Right, I *just* use custom testing scripts to test cases when
building. But I am stuck in
when I use PYBUILD_* something. I searched some code as example:

```
override_dh_auto_test:
HOME=/tmp xvfb-run -a dh_auto_test  \
 -- --system=custom --test-args="cd tests; {interpreter}
-m unittest -v"
```
But it works. (I should keep exploring the way you recommend).

>
> * tests: you don't want to hardcode dependencies on an autopkgtest
>   that should be pulled in by the binary package.
Here I do not understand clearly when modifying it, I know you mean I should
put some dependencies for autopkgtest in binary packages' B-D,but which packages
should be put there[0]?

```
Depends: @, python3-all, tkcalendar, python3-tk, xvfb, xauth
```
Could you help me to understand it again?:)

> There's a debian/.gitlab-ci.yml file but the CI isn't enabled in the
> repository settings on salsa.
Ok. I know how to turn on the CI button.
>
> The binary package seems to be missing dependencies on tk, pil
> (conditional import at src/pygubu/stockimage.py:124), as well as a
> large number of tk-related modules used by the plugins (tkcalendar,
> awesometkinter, customtkinter, tkintertable, tkintermapview, tksheet;
> most of these don't seem to be packaged yet).
>
Yeah, I think you are right. But I thought if autopkgtest is ok, the
functions testing
should be ok. I suspect that my understanding about autopkgtest this time.

> Have you done any functional testing on a (reasonably clean) debian
> testing or unstable install?

I will do that. If it was you said[1], there are many works need to do.:)

BR,
Bo
>
[0]: 
https://salsa.debian.org/python-team/packages/pygubu/-/blob/debian/main/debian/control#L22
[1]: https://salsa.debian.org/python-team/packages/pygubu

Re: Help to package xdoctest

[Bo YU]

Hi,

On Mon, Dec 26, 2022 at 3:01 PM Bo YU  wrote:
>
> Hi,
>
> I am packaging the xdoctest to meet ubelt's[0] B-D.
>
> Now I think it has a good shape in packaging[1], but I am not sure
> about below warning:
>
> ```
> W: python3-xdoctest: no-manual-page [usr/bin/xdoctest]
> P: xdoctest source: very-long-line-length-in-source-file 563 > 512
> [dev/outline.md:11]
> X: python3-xdoctest: application-in-library-section python [usr/bin/xdoctest]
> X: xdoctest source: debian-watch-does-not-check-openpgp-signature 
> [debian/watch]
> X: python3-xdoctest: library-package-name-for-application [usr/bin/xdoctest]
>
> ```
...
>
> If so, I should add manpage for it.

Today I try to add -doc package to meet lintian's check, this should
also basic requirement
for Python packages including docs dir. But again I ran into the
problem with the dependency[0] to use
sphinx to generate html, especially since it needs ubelt, the xdoctest
package itself to meet its dependencies.
So what is the better way to solve the issue?

BR,
Bo

[0]: 
https://salsa.debian.org/python-team/packages/xdoctest/-/blob/debian/main/docs/requirements.txt
>
> Please help me to confirm it, TIA.
>
> BR,
> Bo
>
> [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026966
> [1]: 
> https://salsa.debian.org/python-team/packages/xdoctest/-/tree/debian/main/

Re: review for lazy-loader/0.3-1

[Bo YU]

Hi!

On Tue, Aug 8, 2023 at 1:24 AM Jeroen Ploemen  wrote:
>
> Hi,
>
> I took a look at lazy-loader, up for sponsorship in the Python Team:
>
> * copyright: years outdated;
> * control: long description would benefit from some more details
>   explaining what lazy loader is and does, e.g. a summary of [1];
> * control: standards-version is slightly out-of-date;
> * watch: upstream uses signed tags for releases, please add the
>   upstream key in the packaging and make uscan verify the signature.
>   Since the watch file already uses git mode, you might only have to
>   add the pgpmode=gittag option once the upstream key is in place for
>   verification to work.
>
> Please re-add the package to the channel topic on IRC once the above
> issues have been fixed.
>
Thanks for uploading it.  All issues should be fixed except d/conftrol
to improve
description and thanks with your help here. In addition to pabs help
me to find upstream
key file here and thanks too.:)

BR,
Bo
>
> [1]https://scientific-python.org/specs/spec-0001/ standards-version

RFS: filecheck

[Bo YU]

Hi team!

Due to rfs bot maybe not work on debian-python irc, So I am seeking help
to review/upload my new python package:

https://salsa.debian.org/python-team/packages/filecheck

TIA.

BR,
Bo

Re: RFS: filecheck

[Bo YU]

Hi！

Thanks for reviewing my package!


On Tue, Oct 10, 2023 at 3:51 AM Emmanuel Arias  wrote:
>
> On Mon, Oct 09, 2023 at 02:46:36PM -0300, Emmanuel Arias wrote:
> > Hi!
> >
> > On Sat, Oct 07, 2023 at 09:34:43PM +0800, Bo YU wrote:
> > > Hi team!
> > >
> > > Due to rfs bot maybe not work on debian-python irc, So I am seeking help
> > > to review/upload my new python package:
> > >
> > > https://salsa.debian.org/python-team/packages/filecheck
> > >
> > > TIA.
> > To avoid duplicated work from another team member, I mention here, I'm
> > going to review this package.
> >
> > Cheers,
> > Emmanuel
>
> Hi!,
>
> Me again.
>
> I leave you some comments regarding to FileCheck
>
> * Binary package suggests install the docs package, but is not in
>   d/control.
Done. Here the ideal situation should be a docs package on there, but if we use
sphinx-build to build its doc, there is one guzzle_sphinx_theme does
not in Debian.
So I package its manpage to binary package.

> * Package should depends on python3-poetry-core instead of python3-poetry
Done.

> * d/copyright: upstream does not specify a range of date 2019-2023, only in
>   docs/conf.py the copyright says 2019.
Yeah, although there are only one file flaged its date on 2019, but
how to judge the
whole project copyright date range? I just follow its the first commit:

https://github.com/mull-project/FileCheck.py/commits/main?after=195aa1527a2572b4697ae0d5c604f0baceba805c+419&branch=main&qualified_name=refs%2Fheads%2Fmain

Not sure this is right.

> * The package synopsis should not finished with a period. Please remove it.
Sorry, I am not very clear about here. Do you mean here:
https://salsa.debian.org/python-team/packages/filecheck/-/blob/debian/main/debian/control#L30
If yes, I think the synopsis solution should be more robust here.
Because it saves more space than
specially descriptions.

please let me know if there is not true.

> * The binary package should not be python3-filecheck?
You hint me here. So I spilted the origin package into python3 library
package and
its binary tool binary. this should be working.

I have updated the package on salsa:
https://salsa.debian.org/python-team/packages/filecheck

Thanks again for reviewing the package!

BR,
Bo
>
> Cheers,
> Emmanuel
> > >
> > > BR,
> > > Bo
> > >
>
>

Re: RFS: filecheck

[Bo YU]

Hi!

On Sat, Oct 14, 2023 at 5:27 AM Emmanuel Arias  wrote:
>
> Hi!
>
> On Thu, Oct 12, 2023 at 05:03:45PM +0800, Bo YU wrote:
> > Hi！
> >
> > Thanks for reviewing my package!
> >
> >
> > On Tue, Oct 10, 2023 at 3:51 AM Emmanuel Arias  wrote:
> > >
> > > On Mon, Oct 09, 2023 at 02:46:36PM -0300, Emmanuel Arias wrote:
> > > > Hi!
> > > >
> > > > On Sat, Oct 07, 2023 at 09:34:43PM +0800, Bo YU wrote:
> > > > > Hi team!
> > > > >
> > > > > Due to rfs bot maybe not work on debian-python irc, So I am seeking 
> > > > > help
> > > > > to review/upload my new python package:
> > > > >
> > > > > https://salsa.debian.org/python-team/packages/filecheck
> > > > >
> > > > > TIA.
> > > > To avoid duplicated work from another team member, I mention here, I'm
> > > > going to review this package.
> > > >
> > > > Cheers,
> > > > Emmanuel
> > >
> > > Hi!,
> > >
> > > Me again.
> > >
> > > I leave you some comments regarding to FileCheck
> > >
> > > * Binary package suggests install the docs package, but is not in
> > >   d/control.
> > Done. Here the ideal situation should be a docs package on there, but if we 
> > use
> > sphinx-build to build its doc, there is one guzzle_sphinx_theme does
> > not in Debian.
> > So I package its manpage to binary package.
>
> OK.
>
> >
> > > * Package should depends on python3-poetry-core instead of python3-poetry
> > Done.
> >
> > > * d/copyright: upstream does not specify a range of date 2019-2023, only 
> > > in
> > >   docs/conf.py the copyright says 2019.
> > Yeah, although there are only one file flaged its date on 2019, but
> > how to judge the
> > whole project copyright date range? I just follow its the first commit:
> >
> > https://github.com/mull-project/FileCheck.py/commits/main?after=195aa1527a2572b4697ae0d5c604f0baceba805c+419&branch=main&qualified_name=refs%2Fheads%2Fmain
> >
> > Not sure this is right.
>
> I'd just use 2019, not a range.

Ok, done.
>
> >
> > > * The package synopsis should not finished with a period. Please remove 
> > > it.
> > Sorry, I am not very clear about here. Do you mean here:
> > https://salsa.debian.org/python-team/packages/filecheck/-/blob/debian/main/debian/control#L30
> > If yes, I think the synopsis solution should be more robust here.
> > Because it saves more space than
> > specially descriptions.
> >
> > please let me know if there is not true.
>
> Sorry, perhaps I was not clear, I mean remove the period at the end of
> line 20 [0].

Okay, done. :)
>
> >
> > > * The binary package should not be python3-filecheck?
> > You hint me here. So I spilted the origin package into python3 library
> > package and
> > its binary tool binary. this should be working.
> >
> > I have updated the package on salsa:
> > https://salsa.debian.org/python-team/packages/filecheck
> >
> > Thanks again for reviewing the package!
> >
> > BR,
> > Bo
> > >
> > > Cheers,
> > > Emmanuel
> > > > >
> > > > > BR,
> > > > > Bo
> > > > >
> > >
> > >
>
> The rest looks good to me.

Thanks.
I updated the package here:
https://salsa.debian.org/python-team/packages/filecheck/-/tree/debian/main/debian

Thanks,
BR,
Bo
>
> [0] 
> https://salsa.debian.org/python-team/packages/filecheck/-/blob/debian/main/debian/control#L20

help to fix ftbfs issue #1052815 for python-sparse

[Bo YU]

Hi,

I am looking at the issue and trying to fix it.

If upgrading to 0.14.0[0] directly does not fix the issue and it is in
complicated situation. So below I will explain what I do.

First to fix #1052815[1], wo need to adjust pybuild with custom way:
```
PYBUILD_SYSTEM=custom \
PYBUILD_TEST_ARGS="{interpreter} -m pytest -v" \
```
Okay, it works. But unfortunately, the test cases failed.

```
-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
=== short test summary info 
FAILED sparse/tests/test_coo_numba.py::TestBasic::test_roundtrip - numba.core...
FAILED sparse/tests/test_coo_numba.py::TestBasic::test_roundtrip_constant - n...
FAILED sparse/tests/test_coo_numba.py::TestBasic::test_unpack_attrs - numba.c...
FAILED sparse/tests/test_coo_numba.py::TestBasic::test_repack_attrs - numba.c...
FAILED 
sparse/tests/test_dot.py::test_tensordot[coo-gcxs-a_shape1-b_shape1-axes1]
FAILED 
sparse/tests/test_dot.py::test_tensordot[coo-gcxs-a_shape3-b_shape3-axes3]
FAILED 
sparse/tests/test_dot.py::test_tensordot[coo-gcxs-a_shape7-b_shape7-axes7]
FAILED sparse/tests/test_dot.py::test_tensordot[coo-gcxs-a_shape9-b_shape9-0]
FAILED 
sparse/tests/test_dot.py::test_tensordot[gcxs-coo-a_shape1-b_shape1-axes1]
 9 failed, 5402 passed, 36 xfailed, 49 xpassed, 3729 warnings in 44.59s 

```

The upstream has reported the bug[2] then I applied the workaround in
issue 8993[3], but it still got some cases failed:
```
=== short test summary info 
FAILED sparse/tests/test_coo_numba.py::TestBasic::test_roundtrip - numba.core...
FAILED sparse/tests/test_coo_numba.py::TestBasic::test_roundtrip_constant - n...
FAILED sparse/tests/test_coo_numba.py::TestBasic::test_unpack_attrs - numba.c...
FAILED sparse/tests/test_coo_numba.py::TestBasic::test_repack_attrs - numba.c...
```

It seems the bug was raised by numba and fixed in 0.57 but not sure
why it fails on Debian here.

But maybe I am wrong to get the conclusion above because from upstream
issue 393[4], the problem maybe
due to entry points of sparse. But I have no idea how to fix the issue
properly. For example, If I install
python3-hyperspy[5] to run tests and it will pass. I suspect
python-sparse was installed properly when installing
python3-hyperspy which depend on python-sparse and installing
python3-hyperspy should not to as workaround at all.

So what is properly way to fix the issue? TIA.

BR,
Bo

[0]: https://tracker.debian.org/pkg/python-sparse
[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052815
[2]: https://github.com/pydata/sparse/issues/594
[3]: https://github.com/numba/numba/issues/8993
[4]: https://github.com/pydata/sparse/issues/393
[5]: 
https://salsa.debian.org/python-team/packages/python-sparse/-/pipelines/595732

Re: help to fix ftbfs issue #1052815 for python-sparse

[Bo YU]

On Sun, Oct 29, 2023 at 1:25 AM Bo YU  wrote:
>
> Hi,
>
> I am looking at the issue and trying to fix it.
>
> If upgrading to 0.14.0[0] directly does not fix the issue and it is in
> complicated situation. So below I will explain what I do.
>
> First to fix #1052815[1], wo need to adjust pybuild with custom way:
> ```
> PYBUILD_SYSTEM=custom \
> PYBUILD_TEST_ARGS="{interpreter} -m pytest -v" \
> ```
> Okay, it works. But unfortunately, the test cases failed.
>
> ```
> -- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
> === short test summary info 
> 
> FAILED sparse/tests/test_coo_numba.py::TestBasic::test_roundtrip - 
> numba.core...
> FAILED sparse/tests/test_coo_numba.py::TestBasic::test_roundtrip_constant - 
> n...
> FAILED sparse/tests/test_coo_numba.py::TestBasic::test_unpack_attrs - 
> numba.c...
> FAILED sparse/tests/test_coo_numba.py::TestBasic::test_repack_attrs - 
> numba.c...
> FAILED 
> sparse/tests/test_dot.py::test_tensordot[coo-gcxs-a_shape1-b_shape1-axes1]
> FAILED 
> sparse/tests/test_dot.py::test_tensordot[coo-gcxs-a_shape3-b_shape3-axes3]
> FAILED 
> sparse/tests/test_dot.py::test_tensordot[coo-gcxs-a_shape7-b_shape7-axes7]
> FAILED sparse/tests/test_dot.py::test_tensordot[coo-gcxs-a_shape9-b_shape9-0]
> FAILED 
> sparse/tests/test_dot.py::test_tensordot[gcxs-coo-a_shape1-b_shape1-axes1]
>  9 failed, 5402 passed, 36 xfailed, 49 xpassed, 3729 warnings in 44.59s 
> 
>
> ```
>
> The upstream has reported the bug[2] then I applied the workaround in
> issue 8993[3], but it still got some cases failed:
> ```
> === short test summary info 
> 
> FAILED sparse/tests/test_coo_numba.py::TestBasic::test_roundtrip - 
> numba.core...
> FAILED sparse/tests/test_coo_numba.py::TestBasic::test_roundtrip_constant - 
> n...
> FAILED sparse/tests/test_coo_numba.py::TestBasic::test_unpack_attrs - 
> numba.c...
> FAILED sparse/tests/test_coo_numba.py::TestBasic::test_repack_attrs - 
> numba.c...
> ```
>
> It seems the bug was raised by numba and fixed in 0.57 but not sure
> why it fails on Debian here.
>
> But maybe I am wrong to get the conclusion above because from upstream
> issue 393[4], the problem maybe
> due to entry points of sparse. But I have no idea how to fix the issue
> properly. For example, If I install
> python3-hyperspy[5] to run tests and it will pass. I suspect
> python-sparse was installed properly when installing
> python3-hyperspy which depend on python-sparse and installing
> python3-hyperspy should not to as workaround at all.

Now the issue should be fixed by changing the order in which tests are executed,
which was put after installing. The only trouble is still one test
case failed on i386
even applied upstream workaround[0]. I have reported this to upstream also[1]

[0]: https://github.com/pydata/sparse/pull/486
[1]: https://github.com/pydata/sparse/issues/490

BR,
Bo

Re: review for riscemu/2.2.5-1

[Bo YU]

Hi!

Sorry for the late reply.

On Thu, Nov 09, 2023 at 11:31:29AM +0100, Jeroen Ploemen wrote:

hi Bo,

I took a look at the riscemu package, put up for sponsorship in the
Python team. Some (mostly minor) issues came up:

* copyright:
 + upstream years are incorrect (license file, sources have 2021-2022
   resp. 2023).
 + leftover boilerplate comments.
 + empty line (dot) at the start of the license paragraph.


Done.



* control:
 + no need to mention -doc/-examples pkgs in the long description,
   that's what a suggested dependency is for.
 + tiny (< 10kB) examples package is probably best merged into the
   documentation package.


Okay, I have merged examples into -doc package.



* rules:
 + weird comment at the top of the file (leftover TODO?).
 + variables for doc and example dirs defined but not used?
 + documentation dir /usr/share/doc/riscemu-doc/; did you mean
   /usr/share/doc/riscemu/?


Yeah, I think it should be later too.



* d/riscemu-examples.install used for examples; these should be
 handled by dh_installexamples instead.


Thanks, done.



* lintian hit: W: riscemu: no-manual-page [usr/bin/riscemu].


At first I thought there is no manual for the binary because I searched
a lot online. In fact if you `--help` you can get basic manual for it.
Fixed it.

Please let me know if there is any issue:
https://salsa.debian.org/python-team/packages/riscemu

Thanks for your reviewing it.

BR,
Bo

--
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Re: Maintenance of python-resolvelib and python-commentjson

[Bo YU]

Hi!

On Sat, Mar 16, 2024 at 1:18 AM Scott Kitterman  wrote:
>
> On Friday, March 15, 2024 10:55:34 AM EDT Stefano Rivera wrote:
> > Hi Scott (2024.03.15_13:31:40_+)
> >
> > > I originally packaged python-resolvelib for pip and python-commentjson so
> > > we could run python-resolvelib's tests.  Pip is no longer using the
> > > packaged version.  It's currently used by pdm and ansible-core.
> >
> > However pip does still use resolvelib (albeit vendored). I make an
> > effort to keep all pip's vendored dependencies in Debian so that we are
> > familiar with them and track their security issues.
> >
> > So, I'll add myself as an uploader of resolvelib.
>
> Thanks.  I've removed myself.  Commentjson is required for the resolvelib
> tests (and nothing else).  Do you want to do that one too?
Would you mind me to take it? I would like to add myself as one of the
uploaders before Stefano answers this.

BR,
Bo

>
> Scott K

Re: morph's abandoned packages (list)

[Bo YU]

hi!

On Sat, Mar 30, 2024 at 8:20 AM Thomas Goirand  wrote:
>
> On 3/29/24 21:18, Timo Röhling wrote:
> > Hi Thomas,
> >
> > * Thomas Goirand  [2024-03-17 23:09]:
> >> Anyone is welcome to join, it's just that I'm using git tag workflow,
> >> so it doesn't fit in the DPT, but that's the only thing.
> > I am not familiar with that workflow and could not find any
> > documentation. Can you give me a quick overview what I should do
> > differently from the "regular" DPT workflow?
> >
> > Cheers
> > Timo
>
> I'm not using pristine-tar, or gbp import-orig, and don't use upstream
> tarballs, but git only. Everything is done in a single (debian) branch.
Just share the workflow of DPT I always follow[0]:
```
$ uscan   # Download your package's upstream original tarball
$ tar -xvf srcpkgname_1.0.orig.tar.gz
$ cd srcpkgname_1.0
$ git init
$ git checkout -b upstream
$ git add .
$ git commit -m "import srcpkgname_1.0.orig.tar.gz"
$ git tag -s upstream/1.0
$ pristine-tar commit ../srcpkgname_1.0.orig.tar.gz upstream
$ git checkout -b debian/master
```
And upgrade upstream release[1]. These should be enough.
If given team maintenance, I would like to suggest to follow this.

[0]: https://wiki.debian.org/Python/GitPackaging#Creating_a_new_package
[1]: https://wiki.debian.org/Python/GitPackaging#New_upstream_release

> The only thing that needs to be done, is to push upstream tags to the
> Debian repository. The git history contains all upstream commits then,
> because the workflow is to merge upstream tag.
>
> To upgrade to a newer upstream tag, simply do:
>
> ./debian/rules fetch-upstream-remote
> git merge -X theirs 
> dch --newversion  -m "New upstream release."
>
> Then simply generate the upstream tarball from the git tag:
> ./debian/rules gen-orig-xz
>
> The fetch-upstream-remote and gen-orig-xz are from the
> openstack-pkg-tools package, though I heard others in Debian have
> standardized on something else. But who cares what wrapper one is using,
> really. The point is to fetch upstream tags, merge them, and use "git
> archive" to generate an orig tarball before building and uploading to
> Debian.
>
> If the upstream release was already uploaded to Debian, best is to
> download it instead of generating it, as (like with pristine-tar)
> regenerating it may (in some cases) lead to a different checksum.
>
TIL also, thanks.

BR,
Bo
> Cheers,
>
> Thomas Goirand (zigo)
>

Re: blhc failing due to non-verbose build

[Bo YU]

Hi,

On Fri, Dec 6, 2024 at 10:01 AM Soren Stoutner  wrote:
>
...
> # Append the CPPFLAGS to the standard CFLAGS and CXXFLAGS variables, which is
> how CMake likes it.   Hardening#Notes_for_packages_using_CMake>
> CFLAGS += $(CPPFLAGS)
> CXXFLAGS += $(CPPFLAGS)
>
> https://salsa.debian.org/python-team/packages/pyinstaller/-/blob/debian/
> master/debian/rules?ref_type=heads
>
> Does anyone know how to convince it to populate the logs with the full flags
> used to compile the binaries?

I would like to suggest you to look at the code:
https://sources.debian.org/src/structure-synth/1.5.0-7.1/debian/rules/#L6
or
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1075694#56

Even if it doesn't work, we can get inspiration on how to append extra
flags during the configure phase.

Hope this helps.

BR,
Bo
>
> --
> Soren Stoutner
> so...@debian.org

Bug#1092770: ITP: python-crypt-r -- A copy of the crypt module that was removed in Python 3.13

[Bo YU]

Package: wnpp
Severity: wishlist
Owner: Bo YU 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org
Control: block 1092349 by -1

* Package name: python-crypt-r
  Version : 3.13.1
  Upstream Contact: Miro Hrončok 
* URL : https://github.com/fedora-python/crypt_r
* License : Python-2.1.1
  Programming Lang: Python
  Description : A copy of the crypt module that was removed in Python 3.13

 The crypt_r module is a renamed copy of the crypt module as it was present in
 Python 3.12 before it was removed.
 .
 See PEP 594 for details of the removal.
 .
 Unlike crypt, this library always exposes the crypt_r(3) function, not
 crypt(3). This module implements an interface to the crypt_r(3) routine,
 which is a one-way hash function based upon a modified DES algorithm; see
 the Unix man page for further details. Possible uses include storing hashed
 passwords so you can check passwords without storing the actual password, or
 attempting to crack Unix passwords with a dictionary.
 
I will maintain it under DPT umbrella.

-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Please help to remove python project on python-team/packages

[Bo YU]

Hi,

Please help remove this invalid project[0] that I accidentally
introduced by pressing the enter key when I want to create a new
project.

Thanks for your time and help.

BR,
Bo

[0]: https://salsa.debian.org/python-team/packages/python