Re: [backintime] Switch the maintainer to "Debian Python Team (DPT)"
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. 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 How can we proceed further? IMHO it is blocking the process waiting on someone who do not answer. Kind Christian Buhtz
Re: [backintime] Switch the maintainer to "Debian Python Team (DPT)"
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
Aw: Should cocotb & pyuvm be under Electronics or Python team ?
Hello,
Thank you for your work!
I suggest to direct to electronics about everthing that is tailored for the
electronics and only have non-electronic-specific dependencies with the Python
repository.
Best,
Steffen
> Gesendet: Sonntag, 23. Juli 2023 um 01:51 Uhr
> Von: "أحمد المحمودي"
> An: debian-python@lists.debian.org,
> pkg-electronics-de...@alioth-lists.debian.net
> Betreff: Should cocotb & pyuvm be under Electronics or Python team ?
>
> Hello,
>
> I am currently working on packages for cocotb & pyuvm, both are Python
> packages, that are used for verification (simulation) of VHDL/*Verilog
> models, ie. their scope is electronics. Do I am wondering whether to
> package them under Electeonics team or Python team.
>
> Also, I've set the Section source control field to 'electronics', yet
> lintian complained that since the binary package names are
> python3-{cocotb/pyuvm}, then the section should be 'python'. Should I
> ignore/override that ? Or should I modifybthe Section field to
> 'python' ?
>
> Thanks
>
>
> --
> أحمد المحمودي (Ahmed El-Mahmoudy)
> Digital design engineer
> GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
> GPG Fingerprints:
> 6E2E E4BB 72E2 F417 D066 6ABF 7B30 B496 A7EF 5761
> 8206 A196 2084 7E6D 0DF8 B176 BC19 6A94 EDDD A1B7
>
Re: Bug#1041633: cmake: FindPython.cmake returns /usr/local/lib/python3.11/dist-packages for Python_SITEARCH
Control: reassign -1 qgis 3.28.8+dfsg-1
Control: retitle -1 qgis: needs DEB_PYTHON_INSTALL_LAYOUT=deb to build
Hi Bas,
* Sebastiaan Couwenberg [2023-07-21 17:17]:
Changes between bookworm and sid:
cmake 3.25.1:
``Python_SITELIB``
Third-party platform independent installation directory.
Information returned by
``distutils.sysconfig.get_python_lib(plat_specific=False,standard_lib=False)``
or else ``sysconfig.get_path('purelib')``.
``Python_SITEARCH``
Third-party platform dependent installation directory.
Information returned by
``distutils.sysconfig.get_python_lib(plat_specific=True,standard_lib=False)``
or else ``sysconfig.get_path('platlib')``.
cmake 3.27.0:
``Python_SITELIB``
Third-party platform independent installation directory.
Information returned by ``sysconfig.get_path('purelib')``.
``Python_SITEARCH``
Third-party platform dependent installation directory.
Information returned by ``sysconfig.get_path('platlib')``.
On bookworm distutils is still used which returns:
>>> distutils.sysconfig.get_python_lib(
plat_specific=False,
standard_lib=False,
)
'/usr/lib/python3/dist-packages'
On sid sysconfig is used which results:
>>> sysconfig.get_path('platlib')
'/usr/local/lib/python3.11/dist-packages'
To get the right path for the Debian python3 interpreter,
you need to add 'deb_system':
>>> sysconfig.get_path('platlib', 'deb_system')
'/usr/lib/python3/dist-packages'
After a bit of discussion in #d-python, I believe that
CMake actually behaves as intended now, and the previous behavior was
unintended.
The default use-case is a local user build, not a package build, and
the default SITELIB reflects that.
It is the package maintainer's responsibility to set
DEB_PYTHON_INSTALL_LAYOUT=deb in d/rules, either implicitly through
the use of pybuild, or explicitly with "export
DEB_PYTHON_INSTALL_LAYOUT", as you already did in Salsa.
Cheers
Timo
--
⢀⣴⠾⠻⢶⣦⠀ ╭╮
⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │
⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄ ╰╯
signature.asc
Description: PGP signature
Bug#1041778: python3.11: 'posix_local' scheme conflicts with 'base' and 'platbase' prefix overrides
Package: python3.11
Version: 3.11.4-1
Severity: normal
X-Debbugs-Cc: debian-python@lists.debian.org
Control: found -1 3.11.2-6
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Dear maintainer,
the 'posix_local' scheme will unexpectedly insert "/local"s into path
names if the 'base' prefix is changed to something other than '/usr':
>>> import sysconfig
>>> sysconfig.get_path('purelib')
'/usr/local/lib/python3.11/dist-packages'
>>> sysconfig.get_path('purelib', vars={'base': '/opt/mystuff'})
'/opt/mystuff/local/lib/python3.11/dist-packages'
>>> sysconfig.get_path('purelib', vars={'base': './'})
'local/lib/python3.11/dist-packages'
>>> sysconfig.get_path('purelib', vars={'base': '/usr/local'})
'/usr/local/local/lib/python3.11/dist-packages'
As code like the above is actually being used "in the wild" to create
FHS-like directory structures in locations other than /usr, we should
consider if and how we manage the implied expectation behind that code.
As far as I understand the rationale behind the 'posix_local' scheme, it
is supposed to prevent local installations into the dpkg-managed
/usr/lib, for the reasons given in PEP-668. To that end, the scheme is
arguably slightly "overpowered", as it does more than just divert
'purelib' and 'platlib' from /usr/lib.
We could make sysconfig.get_path() and sysconfig.get_paths() check if
'base' or 'platbase' are overridden to something other than '/usr'
before applying the 'posix_local' scheme for 'purelib' and 'platlib',
respectively. This would certainly help minimize the impact of the
Debian-specific posix_local scheme. Technically, it means that the
posix_local scheme can no longer be expressed as a simple dict, but as
far as I see it, this is just a current implementation detail and
nothing promised by the sysconfig API.
So while it is possible that we would violate other expectations about the
behavior of get_path() along the way, I believe we would make the
Debianized version of Python more compatible with other platforms and
behave less surprisingly in the common use case, which I consider a Good
Thing.
Feel free to rebut (or second) my reasoning. :)
Cheers
Timo
-BEGIN PGP SIGNATURE-
iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmS9PJgACgkQ+C8H+466
LVlrvQv/S8NjYecZVDu1ARN/DiYg5qCVdWQjpTzWhm+VSBLJ/fkcjyYNLWB+/ott
H9DA0bTMsDTKn1G+VZ238Wb8Nm9Hwhx+aVQRENGKh6LR9JLDZT8RzpTQrp/4e9gM
KPYaS5KcLi3vpy+9eiu0V0zFTBv5sPLy91bipQ9Cbh6it69Cv7QhUBGNkVz6ckLN
5YWqlK56z2nu2tvaedS/1LrxB7zy6axo1RPLZKKkbk12rTCaeVBSetBnYos978eu
4puSqgKdYKAskvOFo0XCKDR9msBLdKm1V907mkzVfRoh3wWX00gMz9/BplPPnkHB
tavi3fqdwkunvq+a1zAn2YKX15JH31vzuTKfIB+XPVgsRuAV9y7y8X/CrMYpy7zX
RGRTq8Ycg8BRRMyxIwv/TDJqpXjF6iiL5Qbt/ju7gy/pyDVyqi6VS7BNxhJhprlJ
Xk8ctWYj1495hf7O0Hrn1U0q31AW8s9dGJ6ilF+VqAsDqrmsm4vp2dmURHC+0jGn
KXOiI8T1
=TwPy
-END PGP SIGNATURE-
Re: Should cocotb & pyuvm be under Electronics or Python team ?
Hi Ahmed,
2023-07-23 02:04 CEST, أحمد المحمودي:
> I am currently working on packages for cocotb [1] & pyuvm [2], both
> are Python packages, that are used for verification (simulation) of
> VHDL/*Verilog models, ie. their scope is electronics. Do I am
> wondering whether to package them under Electeonics team or Python
> team.
For choosing the team, it depends on which expertise you want the team
which holds the package to have. For pure Python software, I would say
that the expertise of the Debian Python Team is more useful.
> Also, I've set the Section source control field to 'electronics', yet
> lintian complained that since the binary package names are
> python3-{cocotb/pyuvm}, then the section should be 'python'. Should I
> ignore/override that ? Or should I modifybthe Section field to
> 'python' ?
>From my quick look at cocotb’s documentation [3], it seems to ship at
least one binary in $PATH named `cocotb-config`. Here is how it could be
packaged:
- `cocotb` srcpkg in `electronics` section;
- `python3-cocotb` binpkg in `python` section, containing the library;
- `cocotb` binpkg in `electronics` section, Depends on `python3-cocotb`
and contains the executables.
Same advice would apply for pyuvm, which I did not look at.
> [1] ITP: https://bugs.debian.org/1041288
> [2] ITP: https://bugs.debian.org/1041285
[3] https://docs.cocotb.org/en/stable/quickstart.html
