Re: Fixing upstream branch after tagging

[Andrius Merkys]

Hi Guðjón,

On 2022-12-05 08:24, Guðjón Guðjónsson wrote:

I am working on eric and I made a mistake while updating the git repository.

Some paths have changed so files were not excluded correctly and now 
upstream and pristine-tar contain jquery*.js files.


How can I remove the files after having tagged?
I read that the pristine-tar branch should be removed [1]. Is that correct?


I would suggest repacking the source package [2] (see starting from 
"Copyright"). Branches 'upstream' and 'pristine-tar' should not be 
modified manually.


1) https://go-team.pages.debian.net/workflow-changes.html 



[2] https://wiki.debian.org/Repacking#Copyright

Hope this helps,
Andrius

Fixing upstream branch after tagging

[Guðjón Guðjónsson]

Hi list

I am working on eric and I made a mistake while updating the git repository.

Some paths have changed so files were not excluded correctly and now
upstream and pristine-tar contain jquery*.js files.

How can I remove the files after having tagged?
I read that the pristine-tar branch should be removed [1]. Is that correct?

Regards
Gudjon

1) https://go-team.pages.debian.net/workflow-changes.html

Bug#1025456: RM: flask-oidc -- RoM; inactive upstream; never migrated to testing

[Sergio Durigan Junior]

Package: ftp.debian.org
Severity: normal

Hello,

I would like to request the removal of flask-oidc from unstable.  The
package is currently FTBFSing, and while it would be possible to patch
it and make it build successfully again, I don't think it's worth the
trouble: the package has never migrated to testing, and upstream has
been inactive for 2 years now (the latest upstream release happened more
than 5 years ago).

This package is maintained with the Debian Python team, but I was the
one who added it to Debian and there has been no other person interested
in it ever since.

--8<---cut here---start->8---
$ apt rdepends python3-flask-oidc
python3-flask-oidc
Reverse Depends:
--8<---cut here---end--->8---

Thank you,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Re: Request to join the team

[Stefano Rivera]

Hi Malik (2022.12.04_17:03:05_+)
> I would like to join the team to help maintaining packages and adopt 
> easyprocess [1]

Welcome to the team, added you.

SR

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

Request to join the team

[Malik Mlitat]

Hello DPT,

I would like to join the team to help maintaining packages and adopt 
easyprocess [1]

I have prepared the easyprocess upgrade and started MRs [2] and would like to 
request a sponsor to merge these changes into the team repository.


I read and accepted the team policy[2] and my salsa username is MalikMlitat.


[1]https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888078
[2]https://salsa.debian.org/python-team/packages/easyprocess
[3]https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst  




Regards,

Malik Mlitat

Re: Different behavior of package with pyproject.toml

[Ole Streicher]

Scott Kitterman  writes:
> On December 4, 2022 3:42:15 PM UTC, Ole Streicher  wrote:
>>So I would suspect that it is already the build does something wrong
>>here. Which package is that? pybuild-plugin-pyproject?
>
>
> python3-installer


Thank you, I filed a bug.

Best

Ole

Re: Different behavior of package with pyproject.toml

[Scott Kitterman]

On December 4, 2022 3:42:15 PM UTC, Ole Streicher  wrote:
>Hi Scott,
>
>thanks for the hint.
>
>Scott Kitterman  writes:
>> My first guess is that in some circumstances setuptools is doing the 
>> installing 
>> and in others it's the dh-python pyproject plugin (using the installer 
>> module).  Looking at the build log on buildd.d.o, I can see that build is 
>> using the plugin/installer.
>>
>> I think it would be useful to stop the build right before the install step 
>> starts [1], manually unpack the wheel (it's a zip file) and see if it has 
>> all 
>> the files in it.  If it does, then plugin/build is doing the right thing and 
>> it's an issue with either the plugin or the installer module.
>
>I couldn't manage this; however when looking into the log, I see
>
>-8<-
>  dh_auto_build -O--buildsystem=pybuild
>I: pybuild plugin_pyproject:107: Building wheel for python3.11 with "build" 
>module
>I: pybuild base:240: python3.11 -m build --skip-dependency-check 
>--no-isolation --wheel --outdir 
>/builds/debian-astro-team/asdf-astropy/debian/output/source_dir/.pybuild/cpython3_3.11
> 
>/usr/lib/python3/dist-packages/setuptools/config/pyprojecttoml.py:108: 
>_BetaConfiguration: Support for `[tool.setuptools]` in `pyproject.toml` is 
>still *beta*.
>  warnings.warn(msg, _BetaConfiguration)
>running bdist_wheel
>running build
>running build_py
>creating build
>creating build/lib
>creating build/lib/asdf_astropy
>copying asdf_astropy/_version.py -> build/lib/asdf_astropy
>[... no asdf_astropy/io files here ...]
>* Building wheel...
>Successfully built asdf_astropy-0.3.0-py3-none-any.whl
>I: pybuild plugin_pyproject:118: Unpacking wheel built for python3.11 with 
>"installer" module
>-8<-
>
>So I would suspect that it is already the build does something wrong
>here. Which package is that? pybuild-plugin-pyproject?


python3-installer

Scott K

Re: Different behavior of package with pyproject.toml

[Ole Streicher]

Hi Scott,

thanks for the hint.

Scott Kitterman  writes:
> My first guess is that in some circumstances setuptools is doing the 
> installing 
> and in others it's the dh-python pyproject plugin (using the installer 
> module).  Looking at the build log on buildd.d.o, I can see that build is 
> using the plugin/installer.
>
> I think it would be useful to stop the build right before the install step 
> starts [1], manually unpack the wheel (it's a zip file) and see if it has all 
> the files in it.  If it does, then plugin/build is doing the right thing and 
> it's an issue with either the plugin or the installer module.

I couldn't manage this; however when looking into the log, I see

-8<-
  dh_auto_build -O--buildsystem=pybuild
I: pybuild plugin_pyproject:107: Building wheel for python3.11 with "build" 
module
I: pybuild base:240: python3.11 -m build --skip-dependency-check --no-isolation 
--wheel --outdir 
/builds/debian-astro-team/asdf-astropy/debian/output/source_dir/.pybuild/cpython3_3.11
 
/usr/lib/python3/dist-packages/setuptools/config/pyprojecttoml.py:108: 
_BetaConfiguration: Support for `[tool.setuptools]` in `pyproject.toml` is 
still *beta*.
  warnings.warn(msg, _BetaConfiguration)
running bdist_wheel
running build
running build_py
creating build
creating build/lib
creating build/lib/asdf_astropy
copying asdf_astropy/_version.py -> build/lib/asdf_astropy
[... no asdf_astropy/io files here ...]
* Building wheel...
Successfully built asdf_astropy-0.3.0-py3-none-any.whl
I: pybuild plugin_pyproject:118: Unpacking wheel built for python3.11 with 
"installer" module
-8<-

So I would suspect that it is already the build does something wrong
here. Which package is that? pybuild-plugin-pyproject?

Best

Ole

Re: request for review: python-pyglfw

[Étienne Mollier]

Hi Timo,

Timo Röhling, on 2022-12-04:
> * Étienne Mollier  [2022-12-04 12:46]:
> > I'm a DD, but since this is my first DPT package, I wouldn't be
> > against having a second pair of eyeballs having a look at the
> > python-pyglfw package I produced this morning[1].  The packaging
> > in itself was super smooth, I just wanted to make sure I didn't
> > miss team specific bits; I had the policy and guide under the
> > eyes while packaging, but one never knows.
> > 
> > [1]: https://salsa.debian.org/python-team/packages/python-pyglfw
> - You forgot to push the upstream and pristine-tar branches, the
>   upstream/2.5.5+dfsg tag, and you should set
>   "debian-branch = debian/master" in d/gbp.conf

Ack, these look like an oversight of mine.  These should be
fixed now.  Sorry for the mess.

> - I think the package can be arch:all, as the package will be
>   identical an all architectures, with all architecture-specific
>   bits hidden behind the ctypes indirection.

Ack, I did some further testing, and it seems to be fine to move
to arch all, unless I missed a bit.

> - The "Build-Depends: libglfw3 " seems unnecessary, because
>   AFAICT, there is no test suite in the package at all.

If I remove it, the test scanner seems to catch something which
in turn fails to load the module:

I: pybuild base:240: cd /<>/.pybuild/cpython3_3.11/build; 
python3.11 -m unittest discover -v 
glfw (unittest.loader._FailedTest.glfw) ... ERROR

==
ERROR: glfw (unittest.loader._FailedTest.glfw)
--
ImportError: Failed to import test module: glfw
Traceback (most recent call last):
  File "/usr/lib/python3.11/unittest/loader.py", line 440, in 
_find_test_path
package = self._get_module_from_name(name)
  
  File "/usr/lib/python3.11/unittest/loader.py", line 350, in 
_get_module_from_name
__import__(name)
  File 
"/<>/.pybuild/cpython3_3.11/build/glfw/__init__.py", line 43, in 

raise ImportError("Failed to load GLFW3 shared library.")
ImportError: Failed to load GLFW3 shared library.

In doubt, I'll keep the test dependency for now.  For some
reason, I still witness this error in spite of the library
installed on riscv64, but arm64 build went alright; there might
be something wrong with the dependency.

> - There is no "Testsuite: autopkgtest-pkg-python" in d/control. I'm
>   really not sure if this is an issue, because I usually have more
>   intrusive tests and seldomly rely on the default one. Besides, you
>   did add a config in d/tests, which may also suffice? I really
>   don't know, but wanted to mention it just in case.

I forcefully run it when running sbuild, so I tend to forget to
append it.  I have a more in-depth test in preparation, but it's
commented out due to #1025312.  Anyway, I added the necessary
statement to d/control, shouldn't hurt.

> - I've never set LC_ALL in d/rules. Is there a particular reason
>   why it is necessary?

That's a safety precaution for reproducible builds, when some
artifacts are locale dependent.  This may not be 100% necessary
in the present case, but I tend to keep it around just in case.

> - Personally, I prefer having dh-sequence-python3 in Build-Depends,
>   so I don't have to add --with python3 in d/rules.

I was not aware of that (or just overheard it exists), I give it
a try.  Thanks!

> Everything else looks good to me, with the caveat that I did not
> actually test-build the package, because of the missing pushes.
> 
> Oh, and welcome to the team, nice to have you here!

Thanks for your time and the warm welcome!  :)

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.


signature.asc
Description: PGP signature

Re: request for review: python-pyglfw

[Timo Röhling]

Hi Étienne,

* Étienne Mollier  [2022-12-04 12:46]:

I'm a DD, but since this is my first DPT package, I wouldn't be
against having a second pair of eyeballs having a look at the
python-pyglfw package I produced this morning[1].  The packaging
in itself was super smooth, I just wanted to make sure I didn't
miss team specific bits; I had the policy and guide under the
eyes while packaging, but one never knows.

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

- You forgot to push the upstream and pristine-tar branches, the
  upstream/2.5.5+dfsg tag, and you should set
  "debian-branch = debian/master" in d/gbp.conf

- I think the package can be arch:all, as the package will be
  identical an all architectures, with all architecture-specific
  bits hidden behind the ctypes indirection.

- The "Build-Depends: libglfw3 " seems unnecessary, because
  AFAICT, there is no test suite in the package at all.

- There is no "Testsuite: autopkgtest-pkg-python" in d/control. I'm
  really not sure if this is an issue, because I usually have more
  intrusive tests and seldomly rely on the default one. Besides, you
  did add a config in d/tests, which may also suffice? I really
  don't know, but wanted to mention it just in case.

- I've never set LC_ALL in d/rules. Is there a particular reason
  why it is necessary?

- Personally, I prefer having dh-sequence-python3 in Build-Depends,
  so I don't have to add --with python3 in d/rules.

Everything else looks good to me, with the caveat that I did not
actually test-build the package, because of the missing pushes.

Oh, and welcome to the team, nice to have you here!


Cheers
Timo


--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

request for review: python-pyglfw

[Étienne Mollier]

Hi,

I'm a DD, but since this is my first DPT package, I wouldn't be
against having a second pair of eyeballs having a look at the
python-pyglfw package I produced this morning[1].  The packaging
in itself was super smooth, I just wanted to make sure I didn't
miss team specific bits; I had the policy and guide under the
eyes while packaging, but one never knows.

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

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.
On air: The Tangent - The World We Drive Through


signature.asc
Description: PGP signature