I request an adopter for the rpy2 package. The package description is: This Debian package provides RPy2, a very simple yet robust Python interface to the GNU R Programming Language. It can manage different types of R objects, and can execute arbitrary R functions, including graphic functions. Rpy2 is a rewrite and extension of the older RPy interface. The package just got rewritten upstream (and arrived on pypi as rpy2-3.6.0) with two new sub-packages in rpy2 namespace, so it needs some work. And while I do (some, light) Pythob programming, I do not real other Python packaging so the minor rewrite or checkup it needs would be best provided by someone else. I am happy to look after it in the meantime, but my attempt at packaging it went nowhere right. Sources are on salsa (https://salsa.debian.org/edd/rpy2) and generally in good shape. Feel free to ping me by email if you have question. Cheers, Dirk
I'm planning to work on this, possibly in debian-science. Do you have any existing work on 3.6, and if so where? (Salsa looks like you don't.)
Hi Rebecca, Was just visiting open tabs and saw you had replied to my RFA -- thanks so much! I never got that reply via email and was unaware. I only have crappy uncommitted work for rpy2 3.6 here. I sort of had it on the todo-list ever since Laurent upstream switched to a new model with three (sub)packages and had poked around about how to do this and even posted to debian-python for advice. I even have a tab open to salsa and package python-deadlib which may be the closest model. I fear the start may have to be to start creating a new 'super' tarball as Laurent has the two sub-packages individually at PyPi. Let me know if I can help. I know my bits of R, but much less about Python packaging. Best, Dirk
Hi Rebecca, On 8 June 2025 at 07:48, Dirk Eddelbuettel wrote: | Was just visiting open tabs and saw you had replied to my RFA -- thanks so | much! I never got that reply via email and was unaware. | | I only have crappy uncommitted work for rpy2 3.6 here. I sort of had it on | the todo-list ever since Laurent upstream switched to a new model with three | (sub)packages and had poked around about how to do this and even posted to | debian-python for advice. I even have a tab open to salsa and package | python-deadlib which may be the closest model. | | I fear the start may have to be to start creating a new 'super' tarball as | Laurent has the two sub-packages individually at PyPi. | | Let me know if I can help. I know my bits of R, but much less about Python | packaging. If I can help, please don't hesitate and let me know -- in case you started on this and are stuck on something. Best, Dirk
On 22 June 2025 at 15:15, Dirk Eddelbuettel wrote: | On 8 June 2025 at 07:48, Dirk Eddelbuettel wrote: | | Was just visiting open tabs and saw you had replied to my RFA -- thanks so | | much! I never got that reply via email and was unaware. | | | | I only have crappy uncommitted work for rpy2 3.6 here. I sort of had it on | | the todo-list ever since Laurent upstream switched to a new model with three | | (sub)packages and had poked around about how to do this and even posted to | | debian-python for advice. I even have a tab open to salsa and package | | python-deadlib which may be the closest model. | | | | I fear the start may have to be to start creating a new 'super' tarball as | | Laurent has the two sub-packages individually at PyPi. | | | | Let me know if I can help. I know my bits of R, but much less about Python | | packaging. | | If I can help, please don't hesitate and let me know -- in case you started | on this and are stuck on something. rpy2 upstream is now at 3.6.2. Do you still plan to give this some spare cycles, now that "trixie" is released? Dirk
I've now started looking at this. (As the main issue is that it's an outdated upstream version, we wouldn't have been allowed to fix it under freeze.) > I'm planning to work on this, possibly in debian-science. Is the science team an appropriate place for this package, and if so, what is the process for moving the repository from https://salsa.debian.org/edd/rpy2 to https://salsa.debian.org/science-team/rpy2 ? The GitLab documentation for moving repositories https://salsa.debian.org/help/user/project/import/_index.md#migrate-from-gitlab-to-gitlab-by-using-direct-transfer seems to be mostly about moving between servers, not moving between teams on the same server. The question of how many packages rpy2 3.6 is is complicated: - Still one upstream git repository (https://github.com/rpy2/rpy2). - Now 3 PyPI packages (both source and binary): rpy2 (which is near-empty), rpy2-rinterface, rpy2-robjects. - Still one Python package containing two submodules, rpy2.rinterface and rpy2.robjects. (The existence of these submodules is not new, only the fact that they are now separate PyPI packages.) Hence, the natural options are: (1) Keep this as one source package and one binary package, point d/watch to upstream git, call pybuild 3 times using the -d option https://sources.debian.org/src/dh-python/6.20250414/pybuild.rst/#L179 Or, (2) split it into 3 source and 3 binary packages (Debian uses the import names https://www.debian.org/doc/packaging-manuals/python-policy/#module-package-names so the new ones would be named python3-rpy2.rinterface, python3-rpy2.robjects), keep pointing d/watch to PyPi (2) allows a smaller install size for uses that only need rpy2.rinterface, which is one of upstream's stated reasons for the split (https://github.com/rpy2/rpy2/issues/1130), but codesearch suggests that Debian doesn't currently have any packages that would have such a dependency. I intend to try (1) first, but mostly because it doesn't require going through NEW; I am open to discussion of which we actually want.
On 12 August 2025 at 13:36, Rebecca N. Palmer wrote: | I've now started looking at this. (As the main issue is that it's an | outdated upstream version, we wouldn't have been allowed to fix it under | freeze.) | | > I'm planning to work on this, possibly in debian-science. | | Is the science team an appropriate place for this package, and if so, If that is what you prefer, sure. | what is the process for moving the repository from | https://salsa.debian.org/edd/rpy2 to | https://salsa.debian.org/science-team/rpy2 ? The GitLab documentation | for moving repositories | https://salsa.debian.org/help/user/project/import/_index.md#migrate-from-gitlab-to-gitlab-by-using-direct-transfer | seems to be mostly about moving between servers, not moving between | teams on the same server. I don't know. | The question of how many packages rpy2 3.6 is is complicated: | - Still one upstream git repository (https://github.com/rpy2/rpy2). | - Now 3 PyPI packages (both source and binary): rpy2 (which is | near-empty), rpy2-rinterface, rpy2-robjects. | - Still one Python package containing two submodules, rpy2.rinterface | and rpy2.robjects. (The existence of these submodules is not new, only | the fact that they are now separate PyPI packages.) | | Hence, the natural options are: | (1) Keep this as one source package and one binary package, point | d/watch to upstream git, call pybuild 3 times using the -d option | https://sources.debian.org/src/dh-python/6.20250414/pybuild.rst/#L179 | Or, (2) split it into 3 source and 3 binary packages (Debian uses the | import names | https://www.debian.org/doc/packaging-manuals/python-policy/#module-package-names | so the new ones would be named python3-rpy2.rinterface, | python3-rpy2.robjects), keep pointing d/watch to PyPi | | (2) allows a smaller install size for uses that only need | rpy2.rinterface, which is one of upstream's stated reasons for the split | (https://github.com/rpy2/rpy2/issues/1130), but codesearch suggests that | Debian doesn't currently have any packages that would have such a | dependency. | | I intend to try (1) first, but mostly because it doesn't require going | through NEW; I am open to discussion of which we actually want. Agreed. Happy to help. I am traveling this week so I may not get it before early next week. But more than happy to assist with a Python packaging rejig as this is a useful package that has been in Debian for a while. Dirk
Dirk Eddelbuettel <edd@debian.org> writes: See https://docs.gitlab.com/user/project/working_with_projects/#transfer-a-project . AIUI, you'll need to request access at https://salsa.debian.org/science-team (and have it granted) before you can proceed. Alternatively, you can contact salsa-admin@debian.org. Thanks!
On 17 August 2025 at 00:04, Aaron M. Ucko wrote: | Dirk Eddelbuettel <edd@debian.org> writes: | | > On 12 August 2025 at 13:36, Rebecca N. Palmer wrote: | > | what is the process for moving the repository from | > | > I don't know. | | See https://docs.gitlab.com/user/project/working_with_projects/#transfer-a-project . | AIUI, you'll need to request access at https://salsa.debian.org/science-team | (and have it granted) before you can proceed. I appear to be a member of two other salsa groups but not this (though I have been on the list handle as long as it existed). And I do not see where I can apply. So if a I kind person who could 'pull me in' would do so, I would appreciate it. I can then transfer the rpy2 repo out to debian-science. Cheers, Dirk | Alternatively, you can contact salsa-admin@debian.org. | | > Agreed. Happy to help. | | Thanks! | | -- | Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) | http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?amu@monk.mit.edu
Thanks. The equivalent Salsa documentation page doesn't have that section (it does have https://salsa.debian.org/help/user/project/working_with_projects.md#rename-a-repository but that might not work between groups). Hence, I don't know whether that procedure will actually work on Salsa. However, given that Salsa definitely has *a* move process (I frequently get notifications that something has been moved into debian (i.e. all-DDs collab-maint) or python-team), it's probably worth trying it.
On 18 August 2025 at 13:57, Rebecca N. Palmer wrote: | Thanks. | | On 17 August 2025 at 00:04, Aaron M. Ucko wrote: | > | See https://docs.gitlab.com/user/project/working_with_projects/#transfer-a-project . | | The equivalent Salsa documentation page doesn't have that section (it | does have | https://salsa.debian.org/help/user/project/working_with_projects.md#rename-a-repository | but that might not work between groups). | | Hence, I don't know whether that procedure will actually work on Salsa. | However, given that Salsa definitely has *a* move process (I frequently | get notifications that something has been moved into debian (i.e. | all-DDs collab-maint) or python-team), it's probably worth trying it. Agreed, of course, and I already tried. But when I (as owner of project 'rpy2') try this I only have options debian-perl and debian-r which appear to be the only other (large) maintainer groups I joined. So someone needs to put me into debian-science, or tell me which button to click to request to join. I did not find one when I tried. Which is why I asked in my preceding message. We're all on the same page but I need an assist here. Dirk
Hi Rebecca, Thanks for all the updates to rpy2. Do you think it is ready for unstable after its initial stay in experimental? Cheers, Dirk
We believe that the bug you reported is fixed in the latest version of
rpy2, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 1106545@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Rebecca N. Palmer <rebecca_palmer@zoho.com> (supplier of updated rpy2 package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sat, 16 Aug 2025 16:04:12 +0100
Source: rpy2
Architecture: source
Version: 3.6.2-1
Distribution: experimental
Urgency: medium
Maintainer: Debian Science Team <debian-science-maintainers@lists.alioth.debian.org>
Changed-By: Rebecca N. Palmer <rebecca_palmer@zoho.com>
Closes: 1047971 1106545 1111088
Changes:
rpy2 (3.6.2-1) experimental; urgency=medium
.
* New upstream release.
- Adapt packaging to continue including rpy2.rinterface/robjects.
- While upstream is now a namespace package, this is not.
- Upload to experimental, as this is a risky change.
* Change of maintainer and Vcs-* URL. (Closes: #1106545)
* Rewrite d/copyright, as it was incorrect. (Closes: #1111088)
* Remove obsolete items; do not Suggest non-existent docs package.
* Add Build-Depends to run more of the tests.
* Enable Salsa CI.
* Add autopkgtest.
* Clean up after build. (Closes: #1047971)
* Tests: avoid GMT+/-X timezones, as they fail tzlocal, and
set locale as some tests expect error messages to be in English.
* Enable bindnow security hardening.
Checksums-Sha1:
a51fdc966341fc13a5270d6941419a64f7b4cac3 2422 rpy2_3.6.2-1.dsc
a0da31239991c69c4746a6d7fff2bcf10044d428 1192188 rpy2_3.6.2.orig.tar.xz
b13727f353ca1624f02d977c972b6601258cf5f2 9996 rpy2_3.6.2-1.debian.tar.xz
6782dcf96c7f675f94d78e0fec88e9cd8b0defab 6054 rpy2_3.6.2-1_source.buildinfo
Checksums-Sha256:
a8f6a705150081232b4d799bdc14d5288d09a2df5651f479cd0c9854e8b77d2b 2422 rpy2_3.6.2-1.dsc
6bb08e50e6dd5a834cd4db2c67cfd413c591210ef0be7e988ad739a0e4424fd4 1192188 rpy2_3.6.2.orig.tar.xz
2f225c93bb7e230278259334e5111d78fcdc186c0a6e91484e771534b6cfb9fc 9996 rpy2_3.6.2-1.debian.tar.xz
773674a61a9febab8b827e710d44dfcc69900814ee864841591cddd6e67d93a1 6054 rpy2_3.6.2-1_source.buildinfo
Files:
3afbf18740b8cc3516b21e2ebd8bccab 2422 python optional rpy2_3.6.2-1.dsc
da1856cdd2485d2b7876e1296d2eb991 1192188 python optional rpy2_3.6.2.orig.tar.xz
b54d79ce99f91c220dcafa7b3dfb7f59 9996 python optional rpy2_3.6.2-1.debian.tar.xz
f9aa1f8ad4fb860a37cac433b939e54f 6054 python optional rpy2_3.6.2-1_source.buildinfo
-----BEGIN PGP SIGNATURE-----
iQJMBAEBCgA2FiEEZ8sxEAXE7b4yF1MI3uUNDVZ+omYFAmixv8cYHHJlYmVjY2Ff
cGFsbWVyQHpvaG8uY29tAAoJEN7lDQ1WfqJmbwIP/0lje1ePlVKJzF6NLO0QdlXb
4bXMelCbxucw/qQzdd2CCb25fI3yBDt4Vn9u1VgDvITL6DTdAiLN8AOcscHphW5T
KMgIvpniv6bgjtYBqC+v0fq9crzrd13m5Xrr8cceDUYMxQxaOFpioEGb+3PZM4X9
6R3HK1GS1jXVbow+BbdkgqCeuiWDrR+UuOvQy0+JRne14iuvjASc3jEkdmZi7KJG
Q+JYUwlwc+RPD92awqEQ1iry3ftwWzl0yClf+vs/3sqCcObFoYH86HtAKLJKyp98
5u5XehXN2gFVHY/ixi7qc4gmTFCdARSk2bBX0DgFEdlAxLu4EcdDS6e0rqUkCiYf
Ephq5oYlceuPEjreWxJFaWCtxr/aHXhUAiBx8aLqje5buB+LBwudWtX4sAxTvc1G
UM6OvnKfm1m1Fw0CMgwKcETj4Bv+1DbL8pWyavRyzAU9vpkdMQfzIvVCL75qxW7d
urQJ4gHn7Kx+vVsmSYVa4HNpaRc4kX6JSdQ/GHrk/oxEdyFoekazfkjuHbTFlNxY
ki/TQVn+hyUAnBM2ES4VJVAXzoAxl+94s+8D/hcvM1LUrcL15CR/KOt1jR8hgnqp
k8IHdbwWxTPyuCRQlndhBb7uVlIoikFVM5x58FsZDU0Oa7hZMRngVRCaGM/EuTNR
u7FmU3j9FTYfyjwM5vMX
=rR29
-----END PGP SIGNATURE-----