Re: Ask for reviewing

[Hans-Christoph Steiner]

Andrey Rahmatullin:

On Sat, May 28, 2022 at 06:39:56PM +0430, Danial Behzadi wrote:

Hey folks,

I recently uploaded my python app to deb-expo. As this is my first
packaging experience in Debian, I would love to get some feedback on my
packaging to make it better.

Here is my package: https://mentors.debian.net/package/tractor/

You shouldn't make this a native package or keep an upstream changelog in
debian/changelog.


Hey Danial,

Good to see you in Debian also!  Did you intend to make this a native Debian 
package?  That means that the version in Debian is considered the canonical one, 
and the Debian git repo is the canonical source repo.  Based on pypi, it seems 
that framagit is the canonical repo, so it probably makes more sense to convert 
this to a "source package" as Andrey suggested.


.hc

Re: Updating pytest

[Julian Gilbey]

On Tue, Jun 07, 2022 at 03:49:37PM -0400, Sandro Tosi wrote:
> > Sandro: you managed the numpy transition, it seems.  What is involved
> > in something like this?  I would imagine something like:
> >
> > (1) Upload pytest 7.x to experimental
> 
> i took care of this just now, uploading pytest/7.1.2 to experimental
> (and i've messed up the branches on salsa, so i've committed my
> changes to `experimental2`)

Amazing, thanks!  I might have used a version number such as -1~exp1,
but that is fairly immaterial.  And at least I'm not the only one to
mess up things on salsa! ;-)

> > (2) Arrange with Lucas to test build all rdeps against the
> > experimental version of pytest (by which I mean: all packages which
> > require python3-pytest as a (recursive) build-dependency)
> 
> I'll take care of this soon, likely after pytest has been built on a
> buildd host (so will be either later today EST or tomorrow)

Great!

> > (3) File bugs (with patches where possible) against all packages which
> > either FTBFS with the experimental pytest or which fail their
> > autopkgtest suite with the experimental pytest.  Presumably these bugs
> > would have a usertag associated with them so they can be easily
> > monitored.
> 
> that's something usually Lucas can automate, but he'll provided a set
> of failed/successful logs for us to look at.

OK, that's really helpful.

> > (4) After an appropriate time period, prepare NMUs for remaining bugs.
> >
> > (5) Once all bugs are closed, upload to unstable.
> >
> > I could certainly do (1) and help with (3)-(5) if someone else can do
> > (2) and help with (3)-(5).
> >
> > Best wishes,
> >
> >Julian

Best wishes,

   Julian

Re: Ask for reviewing

[دانیال بهزادی]

Hey Hans 😍

I already converted it to a source package and made this RFS:


Stil waiting for a sponsor though…
Danial Behzadi

در چهارشنبه, ژوئن 8 2022 at ۱۰:۰۱:۰۰ +02:00:00, 
Hans-Christoph Steiner  نوشته بود:



Andrey Rahmatullin:

On Sat, May 28, 2022 at 06:39:56PM +0430, Danial Behzadi wrote:

Hey folks,

I recently uploaded my python app to deb-expo. As this is my first
packaging experience in Debian, I would love to get some feedback 
on my

packaging to make it better.

Here is my package: 
You shouldn't make this a native package or keep an upstream 
changelog in

debian/changelog.


Hey Danial,

Good to see you in Debian also!  Did you intend to make this a native 
Debian package?  That means that the version in Debian is considered 
the canonical one, and the Debian git repo is the canonical source 
repo.  Based on pypi, it seems that framagit is the canonical repo, 
so it probably makes more sense to convert this to a "source package" 
as Andrey suggested.


.hc

Re: Updating pytest

[Julian Gilbey]

On Tue, Jun 07, 2022 at 03:49:37PM -0400, Sandro Tosi wrote:
> > Sandro: you managed the numpy transition, it seems.  What is involved
> > in something like this?  I would imagine something like:
> >
> > (1) Upload pytest 7.x to experimental
> 
> i took care of this just now, uploading pytest/7.1.2 to experimental
> (and i've messed up the branches on salsa, so i've committed my
> changes to `experimental2`)

I've just looked at
https://release.debian.org/britney/pseudo-excuses-experimental.html -
it's encouraging that there have only been a handful of failures on
amd64.  There have been a few more on arm64, but they seem mostly
insignificant or transient.  Here are the failing tests:

1. finalcif: it seems like an update to python3-gemmi has broken this
package

2. fpylll: The failures are happening in the current unstable version
as well.

3. glyphslib: The failures are happening in the current unstable
version as well.

4. junitparser: This looks like it might be due to the new version of
pytest.

5. jupyter-client: The arm64 failure looks likely to be transient

6. monitoring-plugins-systemd: This looks like it might be due to the
new version of pytest - it's not finding any tests.

7. nibabel: This is a new warning I haven't seen before: there's a
ResourceWarning about an unclosed file, which is putting a message on
stderr and causing the test to fail.

8. pytest-pylint: This looks like it may be due to the new version of
pytest, but I'm not sure.

9. pytest-twisted: Bizarre; it's failing to find the testdir fixture;
pytest 7.x does not claim to have deprecated this, so something is
weird here.

10. python-ase: not sure why the pytest.warns call raises an error
rather than just a warning.  But this is certainly a pytest 7.x issue.
I'm not sure how best to rewrite the code in these tests; different
calls are now needed in the two cases (pytest.warns(...) in the first
case, warnings.catch_warnings() in the second, perhaps?).

11. python-async-lru: this throws an error to stderr:
 Future exception was never retrieved
 future: 
 ZeroDivisionError
No idea what that's about.

12. python-b2sdk: this fails to select any tests, so presumably a
pytest 7.x issue.

13. python-email-validator: interesting error on arm64, suggesting the
test needs fixing (but not pytest 7.x related)

14. python-etelemetry: looks like it is a pytest 7.x issue (change in
keywords for skipping?)

15. python-httplib2: similar to python-etelemetry

16. python-parameterized: this looks likely to be a pytest 7.x issue;
the meaning of missing_tests has perhaps changed?  Would need to look
at the code more carefully to understand this.

17. python-pytest-subtests: this is a pytest 7.x issue; the package
has been updated upstream

And that's it, so it really doesn't seem too bad.

Best wishes,

   Julian

Re: Updating pytest

[Andrius Merkys]

Hi,

On 2022-06-08 14:47, Julian Gilbey wrote:
> 1. finalcif: it seems like an update to python3-gemmi has broken this
> package

Yes, this is indeed the case with finalcif. Will report and investigate
it soon.

Best,
Andrius

Re: a review of your bumblebee-status package

[Antoine Beaupré]

On 2022-06-07 18:46:37, Ben Westover wrote:
> Hello,
>
> I've read more into versioneer, and it turns out with the way it works 
> you can't simply remove versioneer.py from the source, much less 
> _version.py. Therefore, I'm excluding _version.py in d/copyright, then 
> replacing it with the much smaller PyPI version in d/patches, and not 
> touching versioneer.py at all, since with the way versioneer works it's 
> technically not vendoring.

Got it, thanks for bearing with me here.
-- 
The destiny of Earthseed is to take root among the stars.
- Octavia Butler

Build and run-time triplets

[Julian Gilbey]

I'd like to ask for some help.  I'm working on packaging pydevd, which
builds a private .so library.  Ordinary extensions built using cython
or similar end up being called "foo.cpython-310-x86_64-linux-gnu.so",
but this library, which is not dependent on the Python version, should
presumably be called "bar.x86_64-linux-gnu.so".

Question 1: How do I determine (within Python) the triplet to use when
building the library?

Question 2: How do I determine (within Python) the triplet to use when
loading the library at runtime?

Thanks!

   Julian

archive rebuild for pytest from experimental

[Sandro Tosi]

Hello Lucas,
the Debian Python Team is in the process of updating pytest to a new
upstream release. Given the substantial number of packages depending
on it, we'd like to leverage the mass rebuild infrastructure to build
the reverse dependencies against pytest/7.1.2-1 in experimental.

I've opened a MR for adding the new mode at
https://salsa.debian.org/lucas/collab-qa-tools/-/merge_requests/22 and
you can find attached the package list.

Thanks a lot in advance!

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


pytest.pkglist
Description: Binary data

Re: Build and run-time triplets

[Andrey Rahmatullin]

On Wed, Jun 08, 2022 at 10:43:57PM +0100, Julian Gilbey wrote:
> I'd like to ask for some help.  I'm working on packaging pydevd, which
> builds a private .so library.  Ordinary extensions built using cython
> or similar end up being called "foo.cpython-310-x86_64-linux-gnu.so",
> but this library, which is not dependent on the Python version, should
> presumably be called "bar.x86_64-linux-gnu.so".
If it's just a private library and not a Python module it should be called
bar.so.

> Question 1: How do I determine (within Python) the triplet to use when
> building the library?
You don't.

> Question 2: How do I determine (within Python) the triplet to use when
> loading the library at runtime?
You don't, but also how are you actually loading it?

-- 
WBR, wRAR


signature.asc
Description: PGP signature