Bug#1072648: src:survival: fails to migrate to testing for too long: triggers autopkgtest issues in r-cran-popepi which needs an update
On 6 June 2024 at 08:22, Johannes Ranke wrote: | Am Mittwoch, 5. Juni 2024, 22:27:09 CEST schrieb Dirk Eddelbuettel: | > On 5 June 2024 at 21:55, Paul Gevers wrote: | > | Source: survival | > | Version: 3.5-8-1 | > | Severity: serious | > | Control: close -1 3.6-4-1 | > | Tags: sid trixie | > | User: release.debian@packages.debian.org | > | Usertags: out-of-sync | > | | > | Dear maintainer(s), | > | | > | The Release Team considers packages that are out-of-sync between testing | > | and unstable for more than 30 days as having a Release Critical bug in | > | testing [1]. Your package src:survival has been trying to migrate for 40 | > | days [2]. Hence, I am filing this bug. The version in unstable triggers | > | autopkgtest failure in r-cran-popepi. | > | | > | If a package is out of sync between unstable and testing for a longer | > | period, this usually means that bugs in the package in testing cannot be | > | fixed via unstable. Additionally, blocked packages can have impact on | > | other packages, which makes preparing for the release more difficult. | > | Finally, it often exposes issues with the package and/or | > | its (reverse-)dependencies. We expect maintainers to fix issues that | > | hamper the migration of their package in a timely manner. | > | | > | This bug will trigger auto-removal when appropriate. As with all new | > | bugs, there will be at least 30 days before the package is auto-removed. | > | | > | I have immediately closed this bug with the version in unstable, so if | > | that version or a later version migrates, this bug will no longer affect | > | testing. I have also tagged this bug to only affect sid and trixie, so | > | it doesn't affect (old-)stable. | > | | > | If you believe your package is unable to migrate to testing due to | > | issues beyond your control, don't hesitate to contact the Release Team. | > | > It is beyond my control that package r-cran-popepi descides to run | > autopkgtests that than hijack and blackmail this package of mine. | > | > Maybe the maintainers of r-cran-popepi should look at their package tracker | > and eg attempt to update to a _current_ version? That's how things work at | > CRAN. | | A look at the ChangeLog of popEpi confirms that that package just needs an | update: | | News for version 0.4.12 | Unit tests | No changes in the package itself — fixed a unit test that used the output of | survival::summmary.survfit which had improved slightly in 3.6-4. | | Should we reassign the bug to r-cran-popepi? See #1072661 It would be nice if a package tracker should display not only 'this package is behind' (which it does, and which seems to get ignored) but also 'this package is involved in an autopkgtest failure of one of its reverse depends'. survival is just a victim of its success: popEpi uses it, the maintainers sleep and what is likely a routine update (possibly even initiated by CRAN with a nudge) gets ignored here -- but we have massive amounts of manual labour and headaches as a result. I am not a fan of this rather imperfect setup. :-/ Dirk | Johannes | | > I am really tired of this here in Debian. If the package gets autoremoved, | > so be it. The blame will rest with the so-called maintainer team for these | > R package that are effectively taking down maintained packages of mine. | > | > Dirk | > | > | Paul | > | | > | [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html | > | [2] https://qa.debian.org/excuses.php?package=survival | > | | > | x[DELETED ATTACHMENT OpenPGP_signature.asc, application/pgp-signature] | -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1072661: r-cran-popepi: Please update to current version
Source: r-cran-popepi Version: 0.4.11+dfsg-1 This package is holding CRAN package 'survival' (aka r-cran-survival, a package listed as part of the 'recommended' set by R Core and hence in r-recommended) back from migrating and is now threatening removal. See #1072648 for details. And that is of course ridiculous. The package has been in Debian for 20 years and is in perfect standing. As it is at CRAN. Consider: - package survival is in _perfect_ condition at CRAN, see https://cloud.r-project.org/web/checks/check_results_survival.html - package popEpi is in _perfect_ condition at CRAN, see https://cloud.r-project.org/web/checks/check_results_popEpi.html - But it is at version 0.4.12 (one release ahead) and its changelog / news https://cloud.r-project.org/web/packages/popEpi/news/news.html says News for version 0.4.12 Unit tests No changes in the package itself — fixed a unit test that used the output of survival::summmary.survfit which had improved slightly in 3.6-4. suggesting that you may get your autopkgtest failure fixed for free if you update. Please consider doing so, and the sooner the better. I remain underimpressed by autopkgtest scatter for healthly packages (where current, ie CRAN) that are left behind upstream. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1072650: src:quantlib-swig: fails to migrate to testing for too long: FTBFS on armel, armhf, i386 and riscv64
On 5 June 2024 at 21:57, Paul Gevers wrote: | Source: quantlib-swig | Version: 1.33-1 | Severity: serious | Control: close -1 1.34-1 | Tags: sid trixie ftbfs | User: release.debian@packages.debian.org | Usertags: out-of-sync | | Dear maintainer(s), | | The Release Team considers packages that are out-of-sync between testing | and unstable for more than 30 days as having a Release Critical bug in | testing [1]. Your package src:quantlib-swig has been trying to migrate | for 40 days [2]. Hence, I am filing this bug. The version in unstable | failed to build on armel, armhf, i386 and riscv64. | | If a package is out of sync between unstable and testing for a longer | period, this usually means that bugs in the package in testing cannot be | fixed via unstable. Additionally, blocked packages can have impact on | other packages, which makes preparing for the release more difficult. | Finally, it often exposes issues with the package and/or | its (reverse-)dependencies. We expect maintainers to fix issues that | hamper the migration of their package in a timely manner. | | This bug will trigger auto-removal when appropriate. As with all new | bugs, there will be at least 30 days before the package is auto-removed. | | I have immediately closed this bug with the version in unstable, so if | that version or a later version migrates, this bug will no longer affect | testing. I have also tagged this bug to only affect sid and trixie, so | it doesn't affect (old-)stable. | | If you believe your package is unable to migrate to testing due to | issues beyond your control, don't hesitate to contact the Release Team. I have seen this, and I am torn. Maybe it is just best to let quantlib-swig die and keep keep just quantlib (the C++ library). Dirk | Paul | | [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html | [2] https://qa.debian.org/excuses.php?package=quantlib-swig | | x[DELETED ATTACHMENT OpenPGP_signature.asc, application/pgp-signature] -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1072648: src:survival: fails to migrate to testing for too long: triggers autopkgtest issues
On 5 June 2024 at 21:55, Paul Gevers wrote: | Source: survival | Version: 3.5-8-1 | Severity: serious | Control: close -1 3.6-4-1 | Tags: sid trixie | User: release.debian@packages.debian.org | Usertags: out-of-sync | | Dear maintainer(s), | | The Release Team considers packages that are out-of-sync between testing | and unstable for more than 30 days as having a Release Critical bug in | testing [1]. Your package src:survival has been trying to migrate for 40 | days [2]. Hence, I am filing this bug. The version in unstable triggers | autopkgtest failure in r-cran-popepi. | | If a package is out of sync between unstable and testing for a longer | period, this usually means that bugs in the package in testing cannot be | fixed via unstable. Additionally, blocked packages can have impact on | other packages, which makes preparing for the release more difficult. | Finally, it often exposes issues with the package and/or | its (reverse-)dependencies. We expect maintainers to fix issues that | hamper the migration of their package in a timely manner. | | This bug will trigger auto-removal when appropriate. As with all new | bugs, there will be at least 30 days before the package is auto-removed. | | I have immediately closed this bug with the version in unstable, so if | that version or a later version migrates, this bug will no longer affect | testing. I have also tagged this bug to only affect sid and trixie, so | it doesn't affect (old-)stable. | | If you believe your package is unable to migrate to testing due to | issues beyond your control, don't hesitate to contact the Release Team. It is beyond my control that package r-cran-popepi descides to run autopkgtests that than hijack and blackmail this package of mine. Maybe the maintainers of r-cran-popepi should look at their package tracker and eg attempt to update to a _current_ version? That's how things work at CRAN. I am really tired of this here in Debian. If the package gets autoremoved, so be it. The blame will rest with the so-called maintainer team for these R package that are effectively taking down maintained packages of mine. Dirk | Paul | | [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html | [2] https://qa.debian.org/excuses.php?package=survival | | x[DELETED ATTACHMENT OpenPGP_signature.asc, application/pgp-signature] -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1072322: r-cran-gdata: CVE-2023-7101 due to unpatched ParseExcel/Utility.pm
Mark, On 31 May 2024 at 22:33, Voorhies, Mark wrote: | Package: r-cran-gdata | Version: 2.18.0.1-1 | Severity: normal | | Dear Maintainer, | | I believe r-cran-gdata 2.18.0.1-1 in Debian 12 is vulnerable to CVE-2023-7101 | due to shipping a copy of Utility.pm from Spreadsheet::ParseExcel that uses | string eval for conditional formatting. | C.f. this patch: | https://github.com/jmcnamara/spreadsheet-parseexcel/commit/bd3159277e745468e2c553417b35d5d7dc7405bc | referenced from the Debian CVE page: | https://security-tracker.debian.org/tracker/CVE-2023-7101 | | This vulnerability is patched in the version of Utility.pm in libspreadsheet-parseexcel-perl | and the vulnerability does not exist in r-cran-gdata as of 3.0.0-1 (currently in testing and unstable) | due to the affected perl modules being dropped from the upstream code. | | I don't know if there are any actual code paths in gdata's use of Spreadsheet::ParseExcel that | would trigger the vulnerability. | | So, this _is_ fixed in the Debian gdata package as of testing, but I'm reporting it in case the | CVE should prompt a security patch for stable. Package maintainer here: There is actually little I can do (and as you state, we are in the green for the current package). We generally inject new amd updated package in 'unstable', if they behave they migrate to 'testing' and every two or so years a release is cut. If you think this needs the attention of the release or security you should probably try to contact them. Cheers, Dirk | Thank you for your time, | | Mark | | -- System Information: | Debian Release: 12.5 | APT prefers stable-updates | APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') | Architecture: amd64 (x86_64) | | Kernel: Linux 6.1.0-21-amd64 (SMP w/4 CPU threads; PREEMPT) | Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set | Shell: /bin/sh linked to /usr/bin/dash | Init: systemd (via /run/systemd/system) | LSM: AppArmor: enabled | | Versions of packages r-cran-gdata depends on: | ii r-base-core [r-api-4.0] 4.2.2.20221110-2 | ii r-cran-gtools3.9.4-1 | | r-cran-gdata recommends no packages. | | r-cran-gdata suggests no packages. | | -- no debconf information -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1072198: xfce4-pulseaudio-plugin: [pipewire] Plugin terminates with signal SIGABRT during Xfce-user logout
;. For help, type "help". Type "apropos word" to search for commands related to "word". warning: Can't open file /memfd:pulseaudio (deleted) during file-backed mapping note processing [New LWP 3609] [New LWP 3619] [New LWP 3617] [New LWP 3618] [New LWP 3641] Core was generated by `/usr/lib/x86_64-linux-gnu/xfce4/panel/wrapper-2.0 /usr/lib/x86_64-linux-gnu/xfc'. Program terminated with signal SIGABRT, Aborted. #0 0x7f1358307b1c in ?? () [Current thread is 1 (LWP 3609)] (gdb) backtrace #0 0x7f1358307b1c in ?? () #1 0x559d0b14bbe0 in ?? () #2 0xe18a9f147313d100 in ?? () #3 0x0006 in ?? () #4 0x7f135737da80 in ?? () #5 0x7f13585abd60 in ?? () #6 0x7f13585f9ff0 in ?? () #7 0x7ffe2e2a5ab0 in ?? () #8 0x7f13582b94e2 in ?? () #9 0x7f1358453b50 in ?? () #10 0x7f13582a24ed in ?? () #11 0x0020 in ?? () #12 0x559d0b276f50 in ?? () #13 0x0094 in ?? () #14 0x7f13584e5e45 in ?? () #15 0x559d0030 in ?? () #16 0x7ffe in ?? () #17 0x7ffe2e2a5a30 in ?? () #18 0xe18a9f147313d100 in ?? () #19 0x in ?? () (gdb) q *** ** Also in the `/home/user/.xsession-errors` are something, but I'm not sure if it related to the issue: ** *** /home/user/.xsession-errors *** ** GLib-GObject:ERROR:../../../gobject/gtypemodule.c:119:g_type_module_finalize: assertion failed: (module->type_infos == NULL) Bail out! GLib-GObject:ERROR:../../../gobject/gtypemodule.c:119:g_type_module_finalize: assertion failed: (module->type_infos == NULL) ** GLib-GObject:ERROR:../../../gobject/gtypemodule.c:119:g_type_module_finalize: assertion failed: (module->type_infos == NULL) ** GLib-GObject:ERROR:../../../gobject/gtypemodule.c:119:g_type_module_finalize: assertion failed: (module->type_infos == NULL) Bail out! GLib-GObject:ERROR:../../../gobject/gtypemodule.c:119:g_type_module_finalize: assertion failed: (module->type_infos == NULL) Bail out! GLib-GObject:ERROR:../../../gobject/gtypemodule.c:119:g_type_module_finalize: assertion failed: (module->type_infos == NULL) (xfce4-panel:3421): Gtk-CRITICAL **: 07:07:03.957: gtk_main_quit: assertion 'main_loops != NULL' failed ** GLib-GObject:ERROR:../../../gobject/gtypemodule.c:119:g_type_module_finalize: assertion failed: (module->type_infos == NULL) Bail out! GLib-GObject:ERROR:../../../gobject/gtypemodule.c:119:g_type_module_finalize: assertion failed: (module->type_infos == NULL) ** GLib-GObject:ERROR:../../../gobject/gtypemodule.c:119:g_type_module_finalize: assertion failed: (module->type_infos == NULL) Bail out! GLib-GObject:ERROR:../../../gobject/gtypemodule.c:119:g_type_module_finalize: assertion failed: (module->type_infos == NULL) Error executing command as another user: Not authorized This incident has been reported. X connection to :0.0 broken (explicit kill or server shutdown). *** ** What resenting is, that a core dump is written on every logout. Hopefully there are enough information to that issue. Btw., I am using `lightdm` as display manager. Best regards, Dirk Lehmann -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.7.12-amd64 (SMP w/20 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xfce4-pulseaudio-plugin depends on: ii libc62.38-11 ii libcairo21.18.0-3+b1 ii libexo-2-0 4.18.0-1+b2 ii libgdk-pixbuf-2.0-0 2.42.12+dfsg-1 ii libglib2.0-0t64 2.80.2-2 ii libgtk-3-0t643.24.41-4 ii libkeybinder-3.0-0 0.3.2-1.1+b2 ii libnotify4 0.8.3-1+b1 ii libpulse-mainloop-glib0 16.1+dfsg1-5 ii libpulse016.1+dfsg1-5 ii libwnck-3-0 43.0-3+b1 ii libxfce4panel-2.0-4 4.18.4-1+b1 ii libxfce4ui-2-0 4.18.4-1+b1 ii libxfce4util74.18.1-2+b1 ii libxfconf-0-34.18.1-1+b2 Versions of packages xfce4-pulseaudio-plugin recommends: ii pavucontrol 5.0-2+b3 ii pipewire-pulse 1.0.7-1 xfce4-pulseaudio-plugin suggests no packages. -- no debconf information
Bug#1072036: release.debian.org: Transition for gsl-2.8 / libgsl28
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition GNU GSL 2.8 was released a few days ago, and I uploaded a new version to experimental was has now cleared NEW. I checked my email folder, and the last time this happened (gsl 2.7, early 2021) we attempted an automatic transition but some things got in the way it seems. Help from Graham (CC'ed) was invaluable then, I am easy either way: a formal or automatic transition works for me, so please advise as to what you preferred course of action is. The package has a fair number of reverse dependencies but rebuilds "should" work cleanly. Tentative ben file below. - title = "gsl 2.8 transition"; is_affected = .depends ~ /libgsl-dev/; is_good = .depends ~ "libgsl28"; is_bad = .depends ~ "libgsl27"; - Let me know if I can help otherwise. Cheers, Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1071362: rpy2: FTBFS: rpy2/tests/rinterface/test_embedded_r.py s.......Fatal Python error: Segmentation fault
We are still having the open issue of rpy2 now segfaulting on the embedding tests which reproduces on my plain vanilla amd64 setup -- so I commented that test out too. Laurent: Any idea why R 4.4.0 and rpy2 do not get along on embedding? Cheers, Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1071940: r-cran-matrix: why depend on r-base instead of r-base-core?
On 26 May 2024 at 11:41, Jörg-Volker Peetz wrote: | Package: r-cran-matrix | Version: 1.7-0-2 | Severity: wishlist | | Dear Dirk Eddelbuettel, | | shouldn't this package depend on r-base-core instead of r-base? | The description of r-base says it "eases the transition from the | pre-1.5.0 package setup" and "once installed, it can be safely removed". This is already fixed in my sources following, I think, an earlier hint by Graham in private email. The current change is also because of the R 4.4.0 release of Matrix 1.7.0; this is not a super-strong dependence but CRAN and the Matrix team decided to have 1.7.0 released after R 4.4.0, and we tagged a small number of packages needing a rebuild with this version of Matrix as they consumed the C API via the headers. The 1.5.0 transition has long been taken care of. As this is now an open bug I will just plug it. Thanks for the report. | Thanks for your work on the R packages. My pleasure! And thanks so much for the kind words. Cheers, Dirk | Regards, | Jörg. -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1071362: rpy2: FTBFS: rpy2/tests/rinterface/test_embedded_r.py s.......Fatal Python error: Segmentation fault
On 25 May 2024 at 12:35, Bo YU wrote: | Hi, | On Sat, May 18, 2024 at 06:41:53AM -0500, Dirk Eddelbuettel wrote: | > | >On 17 May 2024 at 23:05, Santiago Vila wrote: | >| Dirk Eddelbuettel wrote: | >| > Is there a chance this could be spurious? | >| | >| Unlikely because it also happens here: | >| | >| https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/rpy2.html | > | >Ok, I will get in touch with Laurent. | | hmm, the failure will not happen on riscv64 real hardware when I am | trying to get below diff file. Thanks for working through this, and a good idea to piggy-back on the existing test skipping for mips64! The only thing that is a little troubling the overall skip of the 'datetime from timestamp' test but we probably added that one for a reason too... I think I will apply this. Many thanks! Dirk | -- | Regards, | -- |Bo YU | | x[DELETED ATTACHMENT rpy2_fix_ftbfs_riscv64.debdiff, plain text] | x[DELETED ATTACHMENT signature.asc, application/pgp-signature] -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1071868: ITP: python3-wgconfig -- parsing and writing WireGuard configuration files (comment preserving)
Package: wnpp Severity: wishlist Owner: Dirk Henrici X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python3-wgconfig Version : 1.0.2 Upstream Contact: Dirk Henrici * URL : https://github.com/towalink/wgconfig * License : AGPL Programming Lang: Python Description : parsing and writing WireGuard configuration files (comment preserving) WireGuard config files are ini-style. Since all "Peer" sections have the same name, these files cannot be parsed and modified by most libraries handling configuration files. Most existing libraries are not able to preserve or even add comments when modifying a config file. "wgconfig" was created to work with WireGuard configuration files and to preserve comments. Additional information: Used as dependency in other projects, even in corporate environment. Has more than 30 stars on Github. Having it packaged for Debian instead of just PyPi would thus be nice. wgconfig is just a small Python module. However, the capability to preserve comments when writing WireGuard configuration files is quite unique. Package would fit to the PythonTeam. Alternatively, a sponsor is needed. wgconfig exists since 2020 and appears quite stable. Very low rate of updates expected so that maintenance should be low effort. Personally, I'd like to use this to get to know Debian processes and tools and to help the community.
Bug#1071535: car: Please remove r-cran-maptools from (Build-)Depends
On 20 May 2024 at 19:12, Andreas Tille wrote: | Source: car | Version: 3.1-2-2 | Severity: normal | | Hi, | | car mentions r-cran-maptools in (Build-)Depends which is not backed up | by the DESCRIPTION file. Since maptools is removed from CRAN I'd like Yes, we fail to build if 'added' depends are missing, it doesn't work the same way the other direction. Thanks for the heads-up, now corrected in my sources. Maybe also take care of data.table and its i386 test? Else 'car' will be gone anyway via autoremoval. Thanks, Dirk | to remove it from Debian. So it would be great if you could drop the | unneeded dependency. If you might consider using | | dh-update-R | | the Dependencies are auto-updated for you. | | Kind regards | Andreas. | | | -- System Information: | Debian Release: trixie/sid | APT prefers testing | APT policy: (501, 'testing'), (50, 'buildd-unstable'), (50, 'unstable'), (5, 'experimental') | Architecture: amd64 (x86_64) | | Kernel: Linux 6.7.12-amd64 (SMP w/8 CPU threads; PREEMPT) | Kernel taint flags: TAINT_WARN | Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set | Shell: /bin/sh linked to /usr/bin/dash | Init: systemd (via /run/systemd/system) | LSM: AppArmor: enabled -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1071362: rpy2 segfaults in tests under Debian bulk rebuild
On 18 May 2024 at 07:59, Dirk Eddelbuettel wrote: | | Hi Laurent, | | We a build issue in Debian found via bulk rebuilds. Which everything current | in 'unstable', rpy2 (version 3.5.16) segfaults in a test when embedding. | | Details are at https://bugs.debian.org/1071362 | | If you kee 1071...@bugs.debian.org in the email headers replies will get | appended there. Let me know if I can help in any way. And simplest to reply-all to this now that the forwarding has been registered. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1071380: RM: r-cran-randomfields -- ROM; Package removed from CRAN
Appears to be a duplicate of 1071379, maybe check if your script meant to remove another one. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1071362: rpy2: FTBFS: rpy2/tests/rinterface/test_embedded_r.py s.......Fatal Python error: Segmentation fault
On 17 May 2024 at 23:05, Santiago Vila wrote: | Dirk Eddelbuettel wrote: | > Is there a chance this could be spurious? | | Unlikely because it also happens here: | | https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/rpy2.html Ok, I will get in touch with Laurent. Dirk | Thanks. -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1071362: rpy2: FTBFS: rpy2/tests/rinterface/test_embedded_r.py s.......Fatal Python error: Segmentation fault
Is there a chance this could be spurious? The R API is reasonably stable, including the part for embedding R (and I am upstream for a small project doing that from C++). rpy2 is also mature and stable. So could this be a one-off? Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1070840: r-cran-ff: autopkgtest regression with r-base 4.4.0
On 10 May 2024 at 06:28, Dirk Eddelbuettel wrote:
|
| On 10 May 2024 at 10:54, Graham Inggs wrote:
| | Source: r-cran-ff
| | Version: 4.0.12+ds-1
| | Severity: serious
| | X-Debbugs-Cc: Dirk Eddelbuettel
| | User: debian...@lists.debian.org
| | Usertags: regression
| |
| | Hi Maintainer
| |
| | r-cran-ff's autopkgtest regresses when tested with r-base 4.4.0 [1].
| | I've copied what I hope is the relevant part of the log below.
|
| FYI, I am not the maintainer of r-cran-ff.
|
| The package is perfectly clean at CRAN on all hardware-os combinations,
| including amd64 so maybe the maintainer needs to turn this test off:
|
|https://cloud.r-project.org/web/checks/check_results_ff.html
Also, for what it is worth, installing r-cran-ff and its one dependency in a
container along with r-cran-testthat and its twenty (ick!), and then running
'bash run-unit-test' leads to no issue:
[ FAIL 0 | WARN 52 | SKIP 0 | PASS 966 ]
Maybe something for the package maintainer to consider.
Dirk
|
| Dirk
|
| | Regards
| | Graham
| |
| |
| | [1] https://ci.debian.net/packages/r/r-cran-ff/testing/amd64/
| |
| |
| | 42s ══ Failed tests
| |
| | 42s ── Failure ('test-zero_lengths.R:34:3'): file size is correct when
| | creating ff integer from scratch ──
| | 42s file.exists(f1) is not TRUE
| | 42s
| | 42s `actual`: FALSE
| | 42s `expected`: TRUE
| | 42s
| | 42s [ FAIL 1 | WARN 52 | SKIP 0 | PASS 965 ]
| | 42s Error: Test failures
| | 42s Execution halted
|
| --
| dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
|
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1070842: r-bioc-mutationalpatterns: autopkgtest regression with r-base 4.4.0
On 10 May 2024 at 11:01, Graham Inggs wrote:
| Source: r-bioc-mutationalpatterns
| Version: 3.12.0+dfsg-1
| Severity: serious
| X-Debbugs-Cc: Dirk Eddelbuettel
| User: debian...@lists.debian.org
| Usertags: regression
|
| Hi Maintainer
|
| r-bioc-mutationalpatterns' autopkgtest regresses when tested with r-base 4.4.0
| [1]. I've copied what I hope is the relevant part of the log below.
FYI, I am not the maintainer of r-bioc-mutationalpatterns.
As you likely know, BioConductor aligns its releases with R releases and is
now at release 3.19 (matching R 4.4.0) for which this package is now at
version 3.14.0.
I suggest the maintainer look into upgrading BioConductor to 3.19.
Dirk
|
| Regards
| Graham
|
|
| [1] https://ci.debian.net/packages/r/r-bioc-mutationalpatterns/testing/amd64/
|
|
| 125s > test_check("MutationalPatterns")
| 172s [ FAIL 3 | WARN 275 | SKIP 0 | PASS 280 ]
| 172s
| 172s ══ Failed tests
|
| 172s ── Error ('test-fit_to_signatures_bootstrapped.R:12:3'): Output
| has correct class ──
| 172s Error in `FUN(X[[i]], ...)`: isEmpty() is not defined for objects
| of class NULL
| 172s Backtrace:
| 172s ▆
| 172s 1. ├─MutationalPatterns::fit_to_signatures_bootstrapped(...) at
| test-fit_to_signatures_bootstrapped.R:12:3
| 172s 2. │ └─MutationalPatterns::fit_to_signatures_strict(...)
| 172s 3. │ └─MutationalPatterns:::.strict_refit_backwards_selection_sample(...)
| 172s 4. │ └─MutationalPatterns:::.plot_sim_decay(...)
| 172s 5. │ ├─sims[!S4Vectors::isEmpty(sims)] %>% unlist()
| 172s 6. │ ├─S4Vectors::isEmpty(sims)
| 172s 7. │ └─S4Vectors::isEmpty(sims)
| 172s 8. │ └─base::vapply(x, isEmpty, logical(1L))
| 172s 9. │ ├─S4Vectors (local) FUN(X[[i]], ...)
| 172s 10. │ └─S4Vectors (local) FUN(X[[i]], ...)
| 172s 11. └─base::unlist(.)
| 172s ── Error ('test-fit_to_signatures_bootstrapped.R:31:3'): Output
| is equal to expected ──
| 172s Error in `FUN(X[[i]], ...)`: isEmpty() is not defined for objects
| of class NULL
| 172s Backtrace:
| 172s ▆
| 172s 1. ├─MutationalPatterns::fit_to_signatures_bootstrapped(...) at
| test-fit_to_signatures_bootstrapped.R:31:3
| 172s 2. │ └─MutationalPatterns::fit_to_signatures_strict(...)
| 172s 3. │ └─MutationalPatterns:::.strict_refit_backwards_selection_sample(...)
| 172s 4. │ └─MutationalPatterns:::.plot_sim_decay(...)
| 172s 5. │ ├─sims[!S4Vectors::isEmpty(sims)] %>% unlist()
| 172s 6. │ ├─S4Vectors::isEmpty(sims)
| 172s 7. │ └─S4Vectors::isEmpty(sims)
| 172s 8. │ └─base::vapply(x, isEmpty, logical(1L))
| 172s 9. │ ├─S4Vectors (local) FUN(X[[i]], ...)
| 172s 10. │ └─S4Vectors (local) FUN(X[[i]], ...)
| 172s 11. └─base::unlist(.)
| 172s ── Error ('test-fit_to_signatures_strict.R:11:1'): (code run
| outside of `test_that()`) ──
| 172s Error in `FUN(X[[i]], ...)`: isEmpty() is not defined for objects
| of class NULL
| 172s Backtrace:
| 172s ▆
| 172s 1. ├─MutationalPatterns::fit_to_signatures_strict(...) at
| test-fit_to_signatures_strict.R:11:1
| 172s 2. │ └─MutationalPatterns:::.strict_refit_backwards_selection_sample(...)
| 172s 3. │ └─MutationalPatterns:::.plot_sim_decay(...)
| 172s 4. │ ├─sims[!S4Vectors::isEmpty(sims)] %>% unlist()
| 172s 5. │ ├─S4Vectors::isEmpty(sims)
| 172s 6. │ └─S4Vectors::isEmpty(sims)
| 172s 7. │ └─base::vapply(x, isEmpty, logical(1L))
| 172s 8. │ ├─S4Vectors (local) FUN(X[[i]], ...)
| 172s 9. │ └─S4Vectors (local) FUN(X[[i]], ...)
| 172s 10. └─base::unlist(.)
| 172s
| 172s [ FAIL 3 | WARN 275 | SKIP 0 | PASS 280 ]
| 173s Error: Test failures
| 173s Execution halted
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1070843: r-bioc-s4vectors: autopkgtest regression with r-base 4.4.0
On 10 May 2024 at 11:04, Graham Inggs wrote:
| Source: r-bioc-s4vectors
| Version: 0.40.2+dfsg-1
| Severity: serious
| X-Debbugs-Cc: Dirk Eddelbuettel
| User: debian...@lists.debian.org
| Usertags: regression
|
| Hi Maintainer
|
| r-bioc-s4vectors' autopkgtest regresses when tested with r-base 4.4.0
| [1]. I've copied what I hope is the relevant part of the log below.
FYI, I am not the maintainer of r-bioc-s4vectors.
As you likely know, BioConductor aligns its releases with R releases and is
now at release 3.19 (matching R 4.4.0) for which this package is now at
version 0.42.0.
I suggest the maintainer look into upgrading BioConductor to 3.19.
Dirk
|
| Regards
| Graham
|
|
| [1] https://ci.debian.net/packages/r/r-bioc-s4vectors/testing/amd64/
|
|
| 125s > S4Vectors:::.test()
| 129s Timing stopped at: 0.009 0 0.009
| 129s Error in var(x) : is.atomic(y) is not TRUE
| 129s In addition: Warning messages:
| 129s 1: In combineUniqueCols(X, Y, Z, use.names = FALSE) :
| 129s different values in multiple instances of column 'dup', ignoring this
| 129s column in DFrame 2
| 129s 2: In combineUniqueCols(X, Y, Z) :
| 129s different values for shared rows in multiple instances of column 'dup',
| 129s ignoring this column in DFrame 2
| 129s 3: In combineUniqueCols(x, y2) :
| 129s different values for shared rows in multiple instances of column 'X',
| 129s ignoring this column in DFrame 2
| 130s Loading required package: GenomeInfoDb
| 132s
| 132s
| 132s RUNIT TEST PROTOCOL -- Thu May 9 22:12:10 2024
| 132s ***
| 132s Number of test functions: 74
| 132s Number of errors: 1
| 132s Number of failures: 0
| 132s
| 132s
| 132s 1 Test Suite :
| 132s S4Vectors RUnit Tests - 74 test functions, 1 error, 0 failures
| 132s ERROR in test_Rle_numerical: Error in var(x) : is.atomic(y) is not TRUE
| 132s
| 132s Test files with failing tests
| 132s
| 132s test_Rle-utils.R
| 132s test_Rle_numerical
| 132s
| 132s
| 132s Error in BiocGenerics:::testPackage("S4Vectors") :
| 132s unit tests failed for package S4Vectors
| 132s Calls: ->
| 132s Execution halted
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1070841: r-bioc-iranges: autopkgtest regression with r-base 4.4.0
On 10 May 2024 at 10:58, Graham Inggs wrote: | Source: r-bioc-iranges | Version: 2.36.0-1 | Severity: serious | X-Debbugs-Cc: Dirk Eddelbuettel | User: debian...@lists.debian.org | Usertags: regression | | Hi Maintainer | | r-bioc-iranges' autopkgtest regresses when tested with r-base 4.4.0 | [1]. I've copied what I hope is the relevant part of the log below. FYI, I am not the maintainer of r-bioc-iranges. As you likely know, BioConductor aligns releases with R releases at is now at release 3.19 for which this package is at version 2.38.0. I suggest the maintainer look into upgrading BioConductor to 3.19. Dirk | | Regards | Graham | | | [1] https://ci.debian.net/packages/r/r-bioc-iranges/testing/amd64/ | | | 194s *** | 194s Number of test functions: 98 | 194s Number of errors: 1 | 194s Number of failures: 0 | 194s | 194s | 194s 1 Test Suite : | 194s IRanges RUnit Tests - 98 test functions, 1 error, 0 failures | 194s ERROR in test_AtomicList_numerical: Error in FUN(X[[i]], ...) : | is.atomic(y) is not TRUE | 194s | 194s Test files with failing tests | 194s | 194s test_AtomicList-utils.R | 194s test_AtomicList_numerical | 194s | 194s | 194s Warning messages: | 194s 1: In recycleListElements(e1, en) : | 194s Some element lengths are not multiples of their corresponding | element length in e1 | 194s 2: In x + y : | 194s longer object length is not a multiple of shorter object length | 194s 3: In recycleListElements(e1, en) : | 194s Some element lengths are not multiples of their corresponding | element length in e1 | 194s 4: In x + y : | 194s longer object length is not a multiple of shorter object length | 194s Execution halted -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1070840: r-cran-ff: autopkgtest regression with r-base 4.4.0
On 10 May 2024 at 10:54, Graham Inggs wrote:
| Source: r-cran-ff
| Version: 4.0.12+ds-1
| Severity: serious
| X-Debbugs-Cc: Dirk Eddelbuettel
| User: debian...@lists.debian.org
| Usertags: regression
|
| Hi Maintainer
|
| r-cran-ff's autopkgtest regresses when tested with r-base 4.4.0 [1].
| I've copied what I hope is the relevant part of the log below.
FYI, I am not the maintainer of r-cran-ff.
The package is perfectly clean at CRAN on all hardware-os combinations,
including amd64 so maybe the maintainer needs to turn this test off:
https://cloud.r-project.org/web/checks/check_results_ff.html
Dirk
| Regards
| Graham
|
|
| [1] https://ci.debian.net/packages/r/r-cran-ff/testing/amd64/
|
|
| 42s ══ Failed tests
|
| 42s ── Failure ('test-zero_lengths.R:34:3'): file size is correct when
| creating ff integer from scratch ──
| 42s file.exists(f1) is not TRUE
| 42s
| 42s `actual`: FALSE
| 42s `expected`: TRUE
| 42s
| 42s [ FAIL 1 | WARN 52 | SKIP 0 | PASS 965 ]
| 42s Error: Test failures
| 42s Execution halted
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1070240: r-cran-tmb: Please rebuild under updated Matrix package
Package: r-cran-tmb
Version: 1.9.11-1
Severity: important
CRAN package Matrix had a new release 1.7.0 bringing in a new
SuiteSparse API which requires a rebuild if (and only if) the
Matrix headers are used. Your package is one of those that do,
and therefore needs a rebuild.
This was reasonably well circulated earlier (by upstream in [1],
and I followed up on debian-devel) but it was then decided to tie
this 1.7-0 release to the R 4.4.0 release last week.
To recap we can look at the total dependencies of Matrix at CRAN (1300+)
and the ones using the headers via LinkingTo (15) in R via
> db <- tools::CRAN_package_db()
> matrixrevdep <- tools::package_dependencies("Matrix", reverse=TRUE,
db=db)[[1]]
> length(matrixrevdep)# the vector 'matrixrevdep' list all
[1] 1349
> tools::package_dependencies("Matrix", which = "LinkingTo", reverse =
TRUE)[[1L]]
[1] "ahMLE" "bayesWatch" "cplm"
"GeneralizedWendland"
[5] "geostatsp" "hibayes" "irlba" "lme4"
[9] "mcmcsae" "OpenMx" "PRIMME"
"PUlasso"
[13] "robustlmm" "spGARCH" "TMB"
>
But among these 15 affected only five are in Debian:
irlbar-cran-irlba
lme4 r-cran-lme4
OpenMx r-cran-openmx
TMB r-cran-tmb
bcSeqr-bioc-bcseq
and lme4 is my package, and I already rebuilt it.
You should see a message about 'Matrix API 1, needs 2' in case of
a mismatch, if you rebuild then the `library(...)` call in R will
be quiet as usual.
All it takes is a rebuild: for r-cran-lme4 I just adjusted (Build-)
Depends for r-cran-matrix to r-cran-matrix (>= 1.7-0) (and I also
adjusted r-base-dev to depend on 4.4.0 or greater, but that is both
optional, and implied via Matrix).
It would be terrific if you could update the package in the next
few days. If you are unable I could do a binary-only NMU -- just
let me know.
Many thanks, Dirk
[1] https://stat.ethz.ch/pipermail/r-package-devel/2024q1/010463.html
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1070239: r-cran-openmx: Please rebuild under updated Matrix package
Package: r-cran-openmx
Version: 2.21.11+dfsg-3
Severity: important
CRAN package Matrix had a new release 1.7.0 bringing in a new
SuiteSparse API which requires a rebuild if (and only if) the
Matrix headers are used. Your package is one of those that do,
and therefore needs a rebuild.
This was reasonably well circulated earlier (by upstream in [1],
and I followed up on debian-devel) but it was then decided to tie
this 1.7-0 release to the R 4.4.0 release last week.
To recap we can look at the total dependencies of Matrix at CRAN (1300+)
and the ones using the headers via LinkingTo (15) in R via
> db <- tools::CRAN_package_db()
> matrixrevdep <- tools::package_dependencies("Matrix", reverse=TRUE,
db=db)[[1]]
> length(matrixrevdep)# the vector 'matrixrevdep' list all
[1] 1349
> tools::package_dependencies("Matrix", which = "LinkingTo", reverse =
TRUE)[[1L]]
[1] "ahMLE" "bayesWatch" "cplm"
"GeneralizedWendland"
[5] "geostatsp" "hibayes" "irlba" "lme4"
[9] "mcmcsae" "OpenMx" "PRIMME"
"PUlasso"
[13] "robustlmm" "spGARCH" "TMB"
>
But among these 15 affected only five are in Debian:
irlbar-cran-irlba
lme4 r-cran-lme4
OpenMx r-cran-openmx
TMP r-cran-tmp
bcSeqr-bioc-bcseq
and lme4 is my package, and I already rebuilt it.
You should see a message about 'Matrix API 1, needs 2' in case of
a mismatch, if you rebuild then the `library(...)` call in R will
be quiet as usual.
All it takes is a rebuild: for r-cran-lme4 I just adjusted (Build-)
Depends for r-cran-matrix to r-cran-matrix (>= 1.7-0) (and I also
adjusted r-base-dev to depend on 4.4.0 or greater, but that is both
optional, and implied via Matrix).
It would be terrific if you could update the package in the next
few days. If you are unable I could do a binary-only NMU -- just
let me know.
Many thanks, Dirk
[1] https://stat.ethz.ch/pipermail/r-package-devel/2024q1/010463.html
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1070238: r-cran-irlba: Please rebuild under updated Matrix package
Package: r-cran-irlba
Version: 2.3.5.1-3
Severity: important
CRAN package Matrix had a new release 1.7.0 bringing in a new
SuiteSparse API which requires a rebuild if (and only if) the
Matrix headers are used. Your package is one of those that do,
and therefore needs a rebuild.
This was reasonably well circulated earlier (by upstream in [1],
and I followed up on debian-devel) but it was then decided to tie
this 1.7-0 release to the R 4.4.0 release last week.
To recap we can look at the total dependencies of Matrix at CRAN (1300+)
and the ones using the headers via LinkingTo (15) in R via
> db <- tools::CRAN_package_db()
> matrixrevdep <- tools::package_dependencies("Matrix", reverse=TRUE,
db=db)[[1]]
> length(matrixrevdep)# the vector 'matrixrevdep' list all
[1] 1349
> tools::package_dependencies("Matrix", which = "LinkingTo", reverse =
TRUE)[[1L]]
[1] "ahMLE" "bayesWatch" "cplm"
"GeneralizedWendland"
[5] "geostatsp" "hibayes" "irlba" "lme4"
[9] "mcmcsae" "OpenMx" "PRIMME"
"PUlasso"
[13] "robustlmm" "spGARCH" "TMB"
>
But among these 15 affected only five are in Debian:
irlbar-cran-irlba
lme4 r-cran-lme4
OpenMx r-cran-openmx
TMP r-cran-tmp
bcSeqr-bioc-bcseq
and lme4 is my package, and I already rebuilt it.
You should see a message about 'Matrix API 1, needs 2' in case of
a mismatch, if you rebuild then the `library(...)` call in R will
be quiet as usual.
All it takes is a rebuild: for r-cran-lme4 I just adjusted (Build-)
Depends for r-cran-matrix to r-cran-matrix (>= 1.7-0) (and I also
adjusted r-base-dev to depend on 4.4.0 or greater, but that is both
optional, and implied via Matrix).
It would be terrific if you could update the package in the next
few days. If you are unable I could do a binary-only NMU -- just
let me know.
Many thanks, Dirk
[1] https://stat.ethz.ch/pipermail/r-package-devel/2024q1/010463.html
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1070009: r-cran-data.table: Update to current upstream
The file 'issue_563_fread.txt' appears to be an input to data.table::fread() for a test on encodings, glancing at the context. I can run 'R CMD check --as-cran data.table_1.15.4.tar.gz' just fine [1] here without any failing tests (and I have no locale or anything set). It's not my package but if I were you the natural step would be a combination of pausing the offending tests and filing an upstream issue notifying upstream that you had to do so. It is now a pretty active team so you may get some help from them. Dirk [1] I also have a local R env.vars set to report timing issues at lower thresholds than CRAN itself (to be aware for the packages I (co-)author so I get a bit more line noise: ## ... earlier lines omitted, this is on x86_64 with Ubuntu 23.10 ## * checking tests ... Running ‘autoprint.R’ Running R code in ‘autoprint.R’ had CPU time 4.2 times elapsed time Comparing ‘autoprint.Rout’ to ‘autoprint.Rout.save’ ... OK Running ‘froll.R’ [9s/9s] Running ‘knitr.R’ Running R code in ‘knitr.R’ had CPU time 3.7 times elapsed time Comparing ‘knitr.Rout’ to ‘knitr.Rout.save’ ... OK Running ‘main.R’ [30s/25s] Running ‘nafill.R’ Running R code in ‘nafill.R’ had CPU time 3.2 times elapsed time Running ‘other.R’ Running ‘programming.R’ Running R code in ‘programming.R’ had CPU time 2.5 times elapsed time Running ‘types.R’ Running R code in ‘types.R’ had CPU time 4.4 times elapsed time [47s/35s] NOTE * checking for unstated dependencies in vignettes ... OK * checking package vignettes ... OK * checking re-building of vignette outputs ... [76s/20s] OK * checking PDF version of manual ... [5s/4s] OK * checking HTML version of manual ... [2s/2s] OK * checking for non-standard things in the check directory ... OK * checking for detritus in the temp directory ... OK * DONE Status: 1 NOTE See ‘/tmp/r/data.table.Rcheck/00check.log’ for details. edd@rob:/tmp/r$ -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1070009: r-cran-data.table: Update to current upstream
The package is pristine at CRAN https://cran.r-project.org/web/checks/check_results_data.table.html (apart from some new warnings several packages now get about interal R API headers, nothing to do with tests) Maybe you can sort this with upstream -- data.table is effectively holding up r-base (and has been for months since the R 4.3.3 release) which is not exactly ideal. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1070009: r-cran-data.table: Update to current upstream
Package: r-cran-data.table Version: 1.14.10+dfsg-1 Severity: normal data.table had a release 1.15.0 in January -- the first new one in three years! -- and two follow-ups since bringing it 1.15.4 at CRAN. Please update the Debian package to the current upstream version. This should likely reduce some autopkgtest noise too in both data.table itself and some of the packages depending on it. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1069882: testing: MISSING ARCHS on debian mirrors: amd64 arm64 i386 mips64el ppc64el riscv64 s390x
26.04.2024 19:52:12 Andreas Beckmann : > On 26/04/2024 18.54, Dirk Lehmann wrote: >> Yes, thanks that works, I used >> $> apt-get install libgnutls-dane0t64 > > Does dist-upgrade work again now? > Yes, now it works fine with libgnutls30t64 3.8.5-2 :) ... But can this issue occur in the future, when someone upgrade from the current Debian stable 'Bookworm' to the next stable 'Trixie'? Testing users should assume that such issues occur. But a Debian stable upgrade should be run fluent.
Bug#1069882: testing: MISSING ARCHS on debian mirrors: amd64 arm64 i386 mips64el ppc64el riscv64 s390x
26.04.2024 17:51:42 Andreas Beckmann : > On 26/04/2024 16.51, Dirk Lehmann wrote: >> The following packages have unmet dependencies: >> libgnutls-dane0 : Depends: libgnutls30 (= 3.8.3-1) >> E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused >> by held packages. > > Do you have any packages on "hold" (apt-mark showhold)? > > What does > > apt-cache policy gnutls-bin > > report? > If that reports something older than > > Candidate: 3.8.5-2 > > your mirror is not up-to-date. > > Otherwise upgrading to that package > > Package: gnutls-bin > Version: 3.8.5-2 > ... > Depends: libc6 (>= 2.34), libgnutls-dane0t64 (>= 3.7.0), libgnutls30t64 (>= > 3.8.4-0+private+1), libtasn1-6 (>= 4.14) > ... > No, I am currently don't have `gnutls-bin` installed. Just `gnutls-bin` and the sources are versioned to 3.8.5-2. In sid and testing the binary packages `libgnutls30` and `libgnutls-dane0` are consistent versioned to 3.8.3-1 here. Can you confirm that the binaries of the libs are versioned to `3.8.5-2` on your side? > should replace libgnutls-dane0, libgnutls30 with their t64 successors. > Yes, thanks that works, I used ``` $> apt-get install libgnutls-dane0t64 ```
Bug#1069882: Acknowledgement (testing: MISSING ARCHS on debian mirrors: amd64 arm64 i386 mips64el ppc64el riscv64 s390x)
Okay doing the following that fix current testing installations: ``` apt-get install libgnutls-dane0t64 Reading package lists... Done Building dependency tree... Done The following additional packages will be installed: libgnutls30t64 libhogweed6t64 libnettle8t64 Suggested packages: dns-root-data gnutls-bin The following packages will be REMOVED: libgnutls-dane0 libgnutls30 libhogweed6 libnettle8 The following NEW packages will be installed: libgnutls-dane0t64 libgnutls30t64 libhogweed6t64 libnettle8t64 0 upgraded, 4 newly installed, 4 to remove and 93 not upgraded. Need to get 2,495 kB of archives. After this operation, 48.1 kB of additional disk space will be used. Do you want to continue? [Y/n] y Get:1 https://deb.debian.org/debian testing/main amd64 libnettle8t64 amd64 3.9.1-2.2 [296 kB] Get:2 https://deb.debian.org/debian testing/main amd64 libhogweed6t64 amd64 3.9.1-2.2 [328 kB] Get:3 https://deb.debian.org/debian testing/main amd64 libgnutls-dane0t64 amd64 3.8.5-2 [435 kB] Get:4 https://deb.debian.org/debian testing/main amd64 libgnutls30t64 amd64 3.8.5-2 [1,437 kB] Fetched 2,495 kB in 2s (1,577 kB/s) dpkg: libhogweed6:amd64: dependency problems, but removing anyway as you requested: qemu-system-x86 depends on libhogweed6. qemu-system-common depends on libhogweed6. librtmp1:amd64 depends on libhogweed6. libgnutls30:amd64 depends on libhogweed6 (>= 3.6). (Reading database ... 237486 files and directories currently installed.) Removing libhogweed6:amd64 (3.9.1-2+b1) ... dpkg: libnettle8:amd64: dependency problems, but removing anyway as you requested: wget depends on libnettle8. qemu-system-x86 depends on libnettle8. qemu-system-common depends on libnettle8. libsrt1.5-gnutls:amd64 depends on libnettle8. librtmp1:amd64 depends on libnettle8. libgnutls30:amd64 depends on libnettle8 (>= 3.9~). libcurl3-gnutls:amd64 depends on libnettle8. libarchive13:amd64 depends on libnettle8. Removing libnettle8:amd64 (3.9.1-2+b1) ... Selecting previously unselected package libnettle8t64:amd64. (Reading database ... 237470 files and directories currently installed.) Preparing to unpack .../libnettle8t64_3.9.1-2.2_amd64.deb ... Unpacking libnettle8t64:amd64 (3.9.1-2.2) ... Selecting previously unselected package libhogweed6t64:amd64. Preparing to unpack .../libhogweed6t64_3.9.1-2.2_amd64.deb ... Unpacking libhogweed6t64:amd64 (3.9.1-2.2) ... dpkg: libgnutls-dane0:amd64: dependency problems, but removing anyway as you requested: exim4-daemon-light depends on libgnutls-dane0 (>= 3.7.0). (Reading database ... 237486 files and directories currently installed.) Removing libgnutls-dane0:amd64 (3.8.3-1) ... Selecting previously unselected package libgnutls-dane0t64:amd64. (Reading database ... 237480 files and directories currently installed.) Preparing to unpack .../libgnutls-dane0t64_3.8.5-2_amd64.deb ... Unpacking libgnutls-dane0t64:amd64 (3.8.5-2) ... dpkg: libgnutls30:amd64: dependency problems, but removing anyway as you requested: xfce4-mailwatch-plugin depends on libgnutls30 (>= 3.8.1). wget depends on libgnutls30 (>= 3.8.1). sane-airscan depends on libgnutls30 (>= 3.7.5). qemu-system-x86 depends on libgnutls30 (>= 3.8.2). qemu-system-common depends on libgnutls30 (>= 3.8.2). ntfs-3g depends on libgnutls30 (>= 3.7.2). network-manager depends on libgnutls30 (>= 3.7.2). lynx depends on libgnutls30 (>= 3.8.2). libvte-2.91-0:amd64 depends on libgnutls30 (>= 3.7.2). libsrt1.5-gnutls:amd64 depends on libgnutls30 (>= 3.7.0). librtmp1:amd64 depends on libgnutls30 (>= 3.6.14). libqpdf29:amd64 depends on libgnutls30 (>= 3.8.2). libnm0:amd64 depends on libgnutls30 (>= 3.7.2). libldap-2.5-0:amd64 depends on libgnutls30 (>= 3.8.2). libcurl3-gnutls:amd64 depends on libgnutls30 (>= 3.8.2). libcups2:amd64 depends on libgnutls30 (>= 3.8.1). libcamera0.2:amd64 depends on libgnutls30 (>= 3.7.3). libavformat60:amd64 depends on libgnutls30 (>= 3.8.1). glib-networking:amd64 depends on libgnutls30 (>= 3.8.1). exim4-daemon-light depends on libgnutls30 (>= 3.8.2). emacs-gtk depends on libgnutls30 (>= 3.8.2). dirmngr depends on libgnutls30 (>= 3.8.1). apt depends on libgnutls30 (>= 3.8.1). (Reading database ... 237487 files and directories currently installed.) Removing libgnutls30:amd64 (3.8.3-1) ... Selecting previously unselected package libgnutls30t64:amd64. (Reading database ... 237459 files and directories currently installed.) Preparing to unpack .../libgnutls30t64_3.8.5-2_amd64.deb ... Unpacking libgnutls30t64:amd64 (3.8.5-2) ... Setting up libnettle8t64:amd64 (3.9.1-2.2) ... Setting up libhogweed6t64:amd64 (3.9.1-2.2) ... Setting up libgnutls30t64:amd64 (3.8.5-2) ... Setting up libgnutls-dane0t64:amd64 (3.8.5-2) ... Processing triggers for libc-bin (2.37-18) ... ``` A Meta-package would be a better solution. I am out of here. Sorry for my excitement in the last reply, Dirk. On 4/26/24 1
Bug#1069882: testing: MISSING ARCHS on debian mirrors: amd64 arm64 i386 mips64el ppc64el riscv64 s390x
On 4/26/24 15:51, Andreas Beckmann wrote: Control: reassign -1 src:gnutls28 3.8.3-1 Control: severity -1 normal Control: tag -1 moreinfo On Fri, 26 Apr 2024 12:41:45 +0200 Dirk Lehmann wrote: Package: libgnutls30 Version: 3.8.3-1 since yesterday the .deb files for the architectures * amd64 arm64 i386 mips64el ppc64el riscv64 s390x on the Debian Apt mirrors are not listed/available anymore: since they have been superseded by libgnutls30t64 for the 64-bit time_t transition. In a minimal up-to-date testing chroot: # apt-get install exim4-daemon-light Reading package lists... Done Building dependency tree... Done Reading state information... Done The following additional packages will be installed: cron cron-daemon-common dmsetup exim4-base exim4-config libapparmor1 libargon2-1 libcryptsetup12 libdevmapper1.02.1 libevent-2.1-7t64 libfdisk1 libgnutls-dane0t64 libidn12 libjson-c5 libkmod2 libsystemd-shared libunbound8 netbase systemd systemd-dev Suggested packages: anacron logrotate checksecurity supercat bat exim4-doc-html | exim4-doc-info eximon4 file mail-reader spf-tools-perl swaks dns-root-data systemd-container systemd-homed systemd-userdbd systemd-boot systemd-resolved libfido2-1 libip4tc2 libqrencode4 libtss2-esys-3.0.2-0 libtss2-mu-4.0.1-0 libtss2-rc0 libtss2-tcti-device0 polkitd Recommended packages: bsd-mailx | mailx psmisc default-dbus-system-bus | dbus-system-bus systemd-timesyncd | time-daemon The following NEW packages will be installed: cron cron-daemon-common dmsetup exim4-base exim4-config exim4-daemon-light libapparmor1 libargon2-1 libcryptsetup12 libdevmapper1.02.1 libevent-2.1-7t64 libfdisk1 libgnutls-dane0t64 libidn12 libjson-c5 libkmod2 libsystemd-shared libunbound8 netbase systemd systemd-dev 0 upgraded, 21 newly installed, 0 to remove and 0 not upgraded. Need to get 86.0 kB/9704 kB of archives. After this operation, 27.8 MB of additional disk space will be used. Do you want to continue? [Y/n] which looks fine, therefore downgrading the severity. The t64 transition has started migrating packages to testing a few days ago, so maybe you experienced the failure at an unfortunate moment. My current Apt output ! You have broken the whole Debian testing distribution! ``` $> apt-get dist-upgrade Reading package lists... Done Building dependency tree... Done Calculating upgrade... Error! Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libgnutls-dane0 : Depends: libgnutls30 (= 3.8.3-1) E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages. ``` Best regards, Dirk.
Bug#1069882: testing: MISSING ARCHS on debian mirrors: amd64 arm64 i386 mips64el ppc64el riscv64 s390x
Package: libgnutls30 Version: 3.8.3-1 Severity: critical Justification: breaks unrelated software Dear Maintainer, since yesterday the .deb files for the architectures * amd64 arm64 i386 mips64el ppc64el riscv64 s390x on the Debian Apt mirrors are not listed/available anymore: * MISSING: testing libgnutls30 3.8.3-1 * MISSING: testing libgnutls-dane0 3.8.3-1 At yesterday I guess that's an security issue and will be available via `testing-security` in some hours. But currently it seems not be resolved. The CRITICAL IMPACT of this issue is that `exim4-daemon-light` is depending on `libgnutls-dane0`. And `reportbug` is depending on `exim4`. Since exim4 is the default MTA in Debian it is currently not possible to report bugs anymore in testing, as I am currently doing! Please fix fast. Maybe possible to just "held back" libgnutls30 and libgnutls-dane0? Best regards, Dirk =) -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.6.15-amd64 (SMP w/20 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libgnutls30 depends on: ii libc6 2.37-18 ii libgmp10 2:6.3.0+dfsg-2+b1 ii libhogweed63.9.1-2+b1 ii libidn2-0 2.3.7-2 ii libnettle8 3.9.1-2+b1 ii libp11-kit00.25.3-4 ii libtasn1-6 4.19.0-3+b2 ii libunistring5 1.2-1 libgnutls30 recommends no packages. Versions of packages libgnutls30 suggests: pn gnutls-bin -- no debconf information
Bug#1069842: rjava: FTBFS: /usr/bin/ld: cannot find -ldeflate: No such file or directory
reassign 1069842 r-base thanks On 25 April 2024 at 18:27, Santiago Vila wrote: | Package: src:rjava | Version: 1.0-11-1 | Severity: serious | Tags: ftbfs | | Dear maintainer: | | During a rebuild of all packages in unstable, your package failed to build: Thanks for this. It is caused by the just released R 4.4.0 which now uses libdeflate, gets it somehow already via its Build-Depends but then does not implicitly pass it on via its virtual (child) package r-base-dev and its depends. (Both have a list of lib*-dev compression packages.) I will make a r-base 4.4.0-2 either today or tomorrow to correct this and have r-base-dev explicitly list libdeflate-dev. Dirk | | | [...] | debian/rules build | dh build --buildsystem R | dh_update_autotools_config -O--buildsystem=R | cp: warning: behavior of -n is non-portable and may change in future; use --update=none instead | cp: warning: behavior of -n is non-portable and may change in future; use --update=none instead | dh_autoreconf -O--buildsystem=R | dh_auto_configure -O--buildsystem=R | dh_auto_build -O--buildsystem=R | dh_auto_test -O--buildsystem=R | create-stamp debian/debhelper-build-stamp | fakeroot debian/rules binary | dh binary --buildsystem R | dh_testroot -O--buildsystem=R | dh_prep -O--buildsystem=R | dh_auto_install --destdir=debian/r-cran-rjava/ -O--buildsystem=R | I: R Package: rJava Version: 1.0-11 | I: Building using R version 4.4.0-1 | I: R API version: r-api-4.0 | I: Using built-time from d/changelog: Fri, 26 Jan 2024 11:10:09 -0600 | mkdir -p /<>/debian/r-cran-rjava/usr/lib/R/site-library | R CMD INSTALL -l /<>/debian/r-cran-rjava/usr/lib/R/site-library --clean . "--built-timestamp='Fri, 26 Jan 2024 11:10:09 -0600'" | * installing *source* package ‘rJava’ ... | files ‘configure’, ‘jri/tools/config.guess’, ‘jri/tools/config.sub’, ‘src/config.h.in’ have the wrong MD5 checksums | ** using staged installation | checking for gcc... gcc | checking whether the C compiler works... yes | checking for C compiler default output file name... a.out | checking for suffix of executables... | checking whether we are cross compiling... no | checking for suffix of object files... o | checking whether the compiler supports GNU C... yes | checking whether gcc accepts -g... yes | checking for gcc option to enable C11 features... none needed | checking for sys/wait.h that is POSIX.1 compatible... yes | checking for stdio.h... yes | checking for stdlib.h... yes | checking for string.h... yes | checking for inttypes.h... yes | checking for stdint.h... yes | checking for strings.h... yes | checking for sys/stat.h... yes | checking for sys/types.h... yes | checking for unistd.h... yes | checking for string.h... (cached) yes | checking for sys/time.h... yes | checking for unistd.h... (cached) yes | checking for an ANSI C-conforming const... yes | configure: checking whether gcc supports static inline... | yes | checking whether setjmp.h is POSIX.1 compatible... yes | checking for gcc options needed to detect all undeclared functions... none needed | checking whether sigsetjmp is declared... yes | checking whether siglongjmp is declared... yes | checking Java support in R... present: | interpreter : '/usr/lib/jvm/default-java/bin/java' | archiver: '/usr/lib/jvm/default-java/bin/jar' | compiler: '/usr/lib/jvm/default-java/bin/javac' | header prep.: '' | cpp flags : '-I/usr/lib/jvm/default-java/include -I/usr/lib/jvm/default-java/include/linux' | java libs : '-L/usr/lib/jvm/default-java/lib/server -ljvm' | checking whether Java run-time works... yes | checking whether -Xrs is supported... yes | checking whether -Xrs will be used... yes | checking whether JVM will be loaded dynamically... no | checking whether JNI programs can be compiled... yes | checking whether JNI programs run... yes | checking JNI data types... ok | checking whether JRI should be compiled (autodetect)... yes | checking whether debugging output should be enabled... no | checking whether memory profiling is desired... no | checking whether threads support is requested... no | checking whether callbacks support is requested... no | checking whether JNI cache support is requested... no | checking whether headless init is enabled... no | checking whether JRI is requested... yes | configure: creating ./config.status | config.status: creating src/Makevars | config.status: creating R/zzz.R | config.status: creating src/config.h | === configuring in jri (/<>/jri) | configure: running /bin/bash ./configure --disable-option-checking '--prefix=/usr/local' 'CC=gcc' 'CFLAGS=-g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection' 'LDFLAGS=-Wl,-z,relro' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2' --cache-fi
Bug#970021: Seeking a small group to package Apache Arrow (was: Bug#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics)
On 9 April 2024 at 18:45, Jose Manuel Abuin Mosquera wrote: | If possible, I would like to contribute. At work we use the Go and | Python implementations, also, in the short term, we will start using the | Rust one. Similar for us, and we have seen plenty of build headaches across pypi or conda ... (Hence my earlier hint about nanoarrow. No linking, uses the C API of two void pointers.) | Just to point out, the Rust version has its own native implementation, | here: https://github.com/apache/arrow-rs . And IIRC there is an independent Arrow implementation (in Rust) used by polars making it two possible ITPs: vanilla Arrow from Apache and Arrow from polars. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1068117: dieharder: dab_monobit2 crashes with ntuple > 17
On 8 April 2024 at 18:21, Lucas Thode wrote: | Apologies for the confusion, I didn't realize the patch in question was a new | addition. Just confirmed that it errors out instead of segfaulting or hanging. Thanks for confirming! Dirk | On Sat, Apr 6, 2024 at 5:32 PM Dirk Eddelbuettel wrote: | | | Hi Lucas, | | As Milan suggested, please sure you are current. If in doubt, park you | current checkout and start from | | git checkout https://github.com/eddelbuettel/dieharder.git | | where you should see today's commit from merging PR 24. | | edd@rob:~/git/dieharder(master)$ git ls | head | * 3442896 - (HEAD -> master, origin/master, origin/HEAD) Merge pull | request #24 from mbroz/dab-monobit2-ntup (10 hours ago) | |\ | | * d928cbf - Avoid overflow in DAB Monobit2 test. (10 hours ago) | | |/ | * 2d4763a - Merge pull request #22 from mbroz/master (6 weeks ago) | | |\ | | * 67989b4 - Do not report file input rewind if nothing was read | repeatedly. (6 weeks ago) | |/ | * c987a15 - Fix segfault for wrongly specified test on commandline. (# | 21) (9 weeks ago) | * a186d90 - Merge pull request #20 from mbroz/warning-fixes (2 months | ago) | edd@rob:~/git/dieharder(master)$ | | Do not rely on the Debian package, it has not been updated yet. | | Cheers, Dirk | | -- | dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org | | -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1068117: dieharder: dab_monobit2 crashes with ntuple > 17
Hi Lucas, As Milan suggested, please sure you are current. If in doubt, park you current checkout and start from git checkout https://github.com/eddelbuettel/dieharder.git where you should see today's commit from merging PR 24. edd@rob:~/git/dieharder(master)$ git ls | head * 3442896 - (HEAD -> master, origin/master, origin/HEAD) Merge pull request #24 from mbroz/dab-monobit2-ntup (10 hours ago) |\ | * d928cbf - Avoid overflow in DAB Monobit2 test. (10 hours ago) |/ * 2d4763a - Merge pull request #22 from mbroz/master (6 weeks ago) |\ | * 67989b4 - Do not report file input rewind if nothing was read repeatedly. (6 weeks ago) |/ * c987a15 - Fix segfault for wrongly specified test on commandline. (#21) (9 weeks ago) * a186d90 - Merge pull request #20 from mbroz/warning-fixes (2 months ago) edd@rob:~/git/dieharder(master)$ Do not rely on the Debian package, it has not been updated yet. Cheers, Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1068117: dieharder: dab_monobit2 crashes with ntuple > 17
Hi Lucas, On 30 March 2024 at 22:47, Lucas Thode wrote: | Package: dieharder | Version: 3.31.1.4-1.1 | Severity: normal | X-Debbugs-Cc: thode...@gmail.com | | Dear Maintainer, | | `dieharder -d 209 -n $nvalue` crashes for $nvalue>17: | | $ dieharder -d 209 | #=# | #dieharder version 3.31.1 Copyright 2003 Robert G. Brown # | #=# |rng_name|rands/second| Seed | | mt19937| 1.55e+08 |2819069712| | #=# | test_name |ntup| tsamples |psamples| p-value |Assessment | #=# | dab_monobit2| 12| 6500| 1|0.40510331| PASSED | $ dieharder -d 209 -n 12 | #=# | #dieharder version 3.31.1 Copyright 2003 Robert G. Brown # | #=# |rng_name|rands/second| Seed | | mt19937| 2.54e+08 | 152376536| | #=# | test_name |ntup| tsamples |psamples| p-value |Assessment | #=# | dab_monobit2| 12| 6500| 1|0.10580971| PASSED | $ dieharder -d 209 -n 17 | #=# | #dieharder version 3.31.1 Copyright 2003 Robert G. Brown # | #=# |rng_name|rands/second| Seed | | mt19937| 2.29e+08 |2998370165| | #=# | test_name |ntup| tsamples |psamples| p-value |Assessment | #=# | dab_monobit2| 17| 6500| 1|1.| FAILED | $ dieharder -d 209 -n 18 | *** stack smashing detected ***: terminated | Aborted | $ dieharder -d 209 -n 27 | *** stack smashing detected ***: terminated | Aborted | $ dieharder -d 209 -n 28 | Segmentation fault | | P.S. There are more issues with this test not liking non-standard n values, as | can be seen from it failing miserably on mt19937 with -n 17, but the crash is | the most glaring problem. Good stuff. dieharder is a little 'dormant' upstream and via my maintenance of the Debian package I have somewhat inherited upstream. Can you take a look please if this was take care of already at the (somewhat active) shadow repo of mine at https://github.com/eddelbuettel/dieharder I will also CC Milan who has been very attentive with a few other fixes, and may have seen this one too. We are trying to get hold of Robert but no luck yet. Cheers, Dirk PS Apologies also for replying late. I usually get to bug reports within a day but it's a teaching term plus being busy at my 'real job' puts some stress on my response times. :-/ I think I reply quicker to GH issues as I am on GH all day anyway... | -- System Information: | Debian Release: trixie/sid | APT prefers testing | APT policy: (500, 'testing') | Architecture: amd64 (x86_64) | Foreign Architectures: i386 | | Kernel: Linux 6.3.0-1-amd64 (SMP w/12 CPU threads; PREEMPT) | Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set | Shell: /bin/sh linked to /usr/bin/dash | Init: systemd (via /run/systemd/system) | LSM: AppArmor: enabled | | Versions of packages dieharder depends on: | ii libc6 2.37-15 | ii libdieharder3t64 3.31.1.4-1.1 | ii libgsl27 2.7.1+dfsg-6+b1 | | dieharder recommends no packages. | | dieharder suggests no packages. | | -- no debconf information -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#970021: Seeking a small group to package Apache Arrow (was: Bug#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics)
Julian, Arrow is a complicated and large package. We use it at work (where there is a fair amount of Python, also to Conda etc) and do have issues with more complex builds especially because it is 'data infrastructure' and can come in from different parts. I would recommend against packaging at old one -- we also have seen issues with different (py)arrow version biting. Have you seen https://github.com/apache/arrow-nanoarrow ? It works via the C API to Arrow which interchanges data via two void* to the the two structs for arrow array and schema -- and avoids linkage issue. (In user space the pyarrow or R arrow packages can still be used also interfacing via these.) I have been using it for R package bindings for some time and we plan to expand that (again, at work) -- as do others. It is already use by duckdb, by the Arrow 'ADBC' interfaces (which are generic in the ODBC/JDBC sense but for Arrow, and also by a python interface to snowflake. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1034732: Use GitHub nightlies? [was:Keep out of testing]
The GPAC project recommends using its nightly builds from GitHub. Would it be possible to pick a known good 2.3DEV build that fixes other outstanding CVEs (eg, commits from Oct 2023) with a maintenance strategy based on picking a newer known good nightly build to fix issues? GPAC seems to offer some capabilities that aren't matched by fffmpeg, even, or weren't when I last checked. /df -- London UK
Bug#1067218: gretl: please make the build reproducible
Hi Chris, On 20 March 2024 at 11:05, Chris Lamb wrote: | Source: gretl | Version: 2023c-2.1 | Severity: wishlist | Tags: patch | User: reproducible-bui...@lists.alioth.debian.org | Usertags: timestamps | X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org | | Hi, | | Whilst working on the Reproducible Builds effort [0], we noticed that | gretl could not be built reproducibly. | | This is because the PDF documentation embeds the current date via TeX's | \today (etc.). A patch is attached that uses FORCE_SOURCE_DATE to request | that TeX sources the current date from SOURCE_DATE_EPOCH instead of the | system clock. With pleasure! Thanks for the patch. gretl_2023c-3 is now building, should be up 'shortly'. Dirk | [0] https://reproducible-builds.org/ | | | Regards, | | -- | ,''`. | : :' : Chris Lamb | `. `'` la...@debian.org / chris-lamb.co.uk |`- | x[DELETED ATTACHMENT gretl.diff.txt, plain text] -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1066950: elpa-org: elpa-org is outdated – emacs version is newer
Package: elpa-org Version: 9.6.10+dfsg-1-c42-bpo-1 Severity: important X-Debbugs-Cc: none, H.-Dirk Schmitt The in bug #1033400 reported version problem is repeated again with the emacs version 1.29 in bookworm-backports and trixie. This emacs package includes org-mode 9.6.15, but the elpa-org package is still the outdated 9.6.10 or 9.5.2 package. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (600, 'stable-updates'), (600, 'stable-security'), (600, 'stable'), (500, 'oldstable-security'), (99, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-0.deb12.4-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE:de:en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages elpa-org depends on: ii dh-elpa-helper 2.0.16 ii elpa-htmlize1.56-1 ii emacsen-common 3.0.5 Versions of packages elpa-org recommends: ii elpa-org-drill 2.7.0+20200412+dfsg1-2 ii emacs 1:29.2+1-2~bpo12+1 ii emacs-gtk [emacs] 1:29.2+1-2~bpo12+1 Versions of packages elpa-org suggests: ii ditaa 0.10+ds1-1.2 ii elpa-org-contrib 0.4+git20220927.1.6422b26-1 ii org-mode-doc 9.5.2-1 ii texinfo6.8-6+b1 ii texlive-fonts-recommended 2022.20230122-3 ii texlive-latex-extra2022.20230122-4 pn xprintidle -- no debconf information -- --- H.-Dirk_Schmitt Dipl.Math. eMail:dirk.schm...@computer42.org pgp: http://www.computer42.org/~dirk/OpenPGP-fingerprint.html
Bug#1066403: R packages failing to build with missing -ltirpc are actually an issue in r-base
On 13 March 2024 at 19:06, Aurelien Jarno wrote: | control: reassign 1066403 r-base-dev | control: reassign 1066452 r-base-dev | control: reassign 1066455 r-base-dev | control: reassign 1066456 r-base-dev | control: forcemerge 1066403 1066452 1066455 1066456 | control: affects 1066403 rjava | control: affects 1066403 rapache | control: affects 1066403 littler | control: affects 1066403 rpy2 | control: retitle 1066403 r-base-dev: missing dependency on libtirpc-dev | | Hi Dirk, | | There are 4 r-base packages failing to build in the latest archive | rebuild: | | #1066403 rjava: FTBFS: ld: cannot find -ltirpc: No such file or directory | #1066452 rapache: FTBFS: ld: cannot find -ltirpc: No such file or directory | #1066455 littler: FTBFS: ld: cannot find -ltirpc: No such file or directory | #1066456 rpy2: FTBFS: ld: cannot find -ltirpc: No such file or directory | | Investigating, it appears that the issue is actually at the r-base | level. They try to link with -ltirpc because R tell them to do so: | | $ R CMD config --ldflags | -Wl,--export-dynamic -fopenmp -Wl,-z,relro -L/usr/lib/R/lib -lR -lpcre2-8 -llzma -lbz2 -lz -ltirpc -lrt -ldl -lm -licuuc -licui18n | | Therefore it seems that r-base-dev is missing a dependency on | libtirpc-dev. Sorry for not having noticed that when filling #1065216. I should have noticed that too when I prepared 4.3.3-2 from your #1065216: r-base (4.3.3-2) unstable; urgency=medium * debian/control: Add libtirpc-dev to Build-Depends to fix build issue from side effects of t64 transition (Closes: #1065216) -- Dirk Eddelbuettel Mon, 04 Mar 2024 08:54:45 -0600 I will take care of it in -3. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1065216: r-base: recent libc6-dev change causes the xdr feature to be dropped
On 1 March 2024 at 23:36, Aurelien Jarno wrote: | Source: r-base | Version: 4.3.3-1 | Severity: serious | Tags: ftbfs | Justification: fails to build from source (but built successfully in the past) | User: debian-gl...@lists.debian.org | Usertags: libtirpc-dev | | Dear maintainer, | | Starting with glibc 2.31, support for NIS (libnsl library) has been | moved to a separate libnsl2 package. In order to allow a smooth | transition, a libnsl-dev, which depends on libtirpc-dev, has been added | to the libc6-dev package. | | The libnsl-dev dependency has been temporarily dropped in the 2.37-15.1 | NMU, as part of the 64-bit time_t transition. This causes the xdr | feature of r-base to be dropped, I am not sure it is something to care | about. | | Therefore please either: | - Add libtirpc-dev as build dependency I'll do that. We don't have that much little vs big endian out there anymore but it is a feature that was long supported so it should remain supported. Dirk | - Disable the xdr feature support explicitly so that it does not depend | on the packages installed on the system. | | Regards | Aurelien -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1063320: gretl: NMU diff for 64-bit time_t transition
On 29 February 2024 at 00:20, Steve Langasek wrote: | Dear maintainer, | | Please find attached a final version of this patch for the time_t | transition. This patch is being uploaded to unstable. | | Note that this adds a versioned build-dependency on dpkg-dev, to guard | against accidental backports with a wrong ABI. Thanks a lot for managing this well. I replaced the earlier patch with this one and force-pushed over the previous commit. The repo is current. Really appreciate the handling of the 64-bit time_t issue by all. Cheers, Dirk | Thanks! | | | -- System Information: | Debian Release: trixie/sid | APT prefers unstable | APT policy: (500, 'unstable') | Architecture: amd64 (x86_64) | | Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT) | Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE | Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set | Shell: /bin/sh linked to /usr/bin/dash | Init: systemd (via /run/systemd/system) | x[DELETED ATTACHMENT nmu_gretl.debdiff, plain text] -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1062364: dieharder: NMU diff for 64-bit time_t transition
On 28 February 2024 at 21:28, mwhud...@fastmail.fm wrote: | Dear maintainer, | | Please find attached a final version of this patch for the time_t | transition. This patch is being uploaded to unstable. | | Note that this adds a versioned build-dependency on dpkg-dev, to guard | against accidental backports with a wrong ABI. Thanks a lot for managing this well. I replaced the earlier patch with this one and force-pushed over the previous commit. The repo is current. Really appreciate the handling of the 64-bit time_t issue by all. Cheers, Dirk | Thanks! | | | -- System Information: | Debian Release: trixie/sid | APT prefers unstable | APT policy: (500, 'unstable'), (1, 'experimental') | Architecture: amd64 (x86_64) | | Kernel: Linux 6.5.0-21-generic (SMP w/16 CPU threads; PREEMPT) | Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE | Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set | Shell: /bin/sh linked to /usr/bin/dash | Init: systemd (via /run/systemd/system) | x[DELETED ATTACHMENT nmu_dieharder.debdiff, plain text] -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1063864: src:mediawiki2latex: fails to migrate to testing for too long: not installable on armel, mips64el and s390x
HI Georges, Thanks a lot. I think all we have to do now is to wait for 5 days. Yours Dirk On 16.02.24 08:48, Georges Khaznadar wrote: Dirk Hünniger a écrit : chromium-sandbox [!armel !mips64el !s390x], Done. Best regards, Georges.
Bug#1063864: src:mediawiki2latex: fails to migrate to testing for too long: not installable on armel, mips64el and s390x
Hi Georges, I forgot to metion that that the line 52 (chromium-sandbox) should be change in the same manner as line 51. So it should look like: chromium-sandbox [!armel !mips64el !s390x], Yours Dirk On 15.02.24 16:03, Paul Gevers wrote: Hi, On 15-02-2024 15:56, Dirk Hünniger wrote: So could you Paul please post some information on how to do that. Maybe an example. See [1] after the first example. Replace [2] with chromium [!armel !mips64el !s390x], Paul [1] https://www.debian.org/doc/debian-policy/ch-relationships.html [2] https://sources.debian.org/src/mediawiki2latex/8.7-2/debian/control/#L51
Bug#1063864: src:mediawiki2latex: fails to migrate to testing for too long: not installable on armel, mips64el and s390x
Hi Paul, Georges thanks a lot Paul for explanation on the syntax. Georges, could you please follow the instruction given below. Yours Dirk On 15.02.24 16:03, Paul Gevers wrote: Hi, On 15-02-2024 15:56, Dirk Hünniger wrote: So could you Paul please post some information on how to do that. Maybe an example. See [1] after the first example. Replace [2] with chromium [!armel !mips64el !s390x], Paul [1] https://www.debian.org/doc/debian-policy/ch-relationships.html [2] https://sources.debian.org/src/mediawiki2latex/8.7-2/debian/control/#L51
Bug#1063864: src:mediawiki2latex: fails to migrate to testing for too long: not installable on armel, mips64el and s390x
Hi, If I have the choice, I would go for the second solution. So tell the system to build on all architectures and remove the runtime dependency to chromium on s390x armel and mips64el . I think mediawiki2latex can still be used in a practical way even if chromium is not available. For many years mediawiki2latex was used without any option to use chromium any way. I am not sure if Georges knows the syntax to add such an architecture qualified depends on chromium. I didn't find any out in a quick internet search. So could you Paul please post some information on how to do that. Maybe an example. Yours Dirk On 15.02.24 15:33, Paul Gevers wrote: Hi, On 15-02-2024 08:40, Dirk Hünniger wrote: So it still wants to build on s390x armel and mips64el. Possibly its not possible to drop support for an architecture that once was supported. This is not the solution *I* had in mind. I was thinking about just adding an architecture qualified depends on chromium, not only build on the non-chromium architectures. If you want to continue the current route, instead of hardcoding the architectures, I would add a *build*-depends on chromium to prevent building on architectures where it's not available. Then the package automatically builds on those once chromium becomes available. Once an architecture builds successfully, it requires actions from ftp-master to remove the binaries. So, $(reportbug ftp.debian.org) if the architectures are fully unsupported. So possible we need to tell the system that it can still build on all architectures, but the the dependency to chromium is only needed on all architectures but s390x armel and mips64el That's what I had in mind indeed. Paul
Bug#1063864: src:mediawiki2latex: fails to migrate to testing for too long: not installable on armel, mips64el and s390x
HI Georges, Paul, thank you for uploading the package. Unfortunately the system still says https://qa.debian.org/excuses.php?package=mediawiki2latex * Issues preventing migration: o missing build on armel <https://buildd.debian.org/status/logs.php?suite=sid=armel=mediawiki2latex=8.7-2> o missing build on mips64el <https://buildd.debian.org/status/logs.php?suite=sid=mips64el=mediawiki2latex=8.7-2> o missing build on s390x <https://buildd.debian.org/status/logs.php?suite=sid=s390x=mediawiki2latex=8.7-2> o arch:armel not built yet, autopkgtest delayed there o arch:s390x not built yet, autopkgtest delayed there o Too young, only 0 of 5 days old So it still wants to build on s390x armel and mips64el. Possibly its not possible to drop support for an architecture that once was supported. So possible we need to tell the system that it can still build on all architectures, but the the dependency to chromium is only needed on all architectures but s390x armel and mips64el Yours Dirk On 14.02.24 17:01, Dirk Hünniger wrote: Hi, Ok. So if I understood correctly all that has to be done is to add an architecture qualifier. And the person who has can do it is Georges. So I herewith ask him to do so. Yours Dirk On 14.02.24 16:58, Paul Gevers wrote: Hi, On 14-02-2024 16:53, Dirk Hünniger wrote: If it helps to change the dependency to chromium and chromium-sandbox from Depends to Recommends I would like to ask Georges to do so. If you think the Depends is best, make it conditional on the architecture, because ideally also Recommends can be installed (so would benefit from the architecture qualifier). Paul
Bug#1063864: src:mediawiki2latex: fails to migrate to testing for too long: not installable on armel, mips64el and s390x
Hi, Ok. So if I understood correctly all that has to be done is to add an architecture qualifier. And the person who has can do it is Georges. So I herewith ask him to do so. Yours Dirk On 14.02.24 16:58, Paul Gevers wrote: Hi, On 14-02-2024 16:53, Dirk Hünniger wrote: If it helps to change the dependency to chromium and chromium-sandbox from Depends to Recommends I would like to ask Georges to do so. If you think the Depends is best, make it conditional on the architecture, because ideally also Recommends can be installed (so would benefit from the architecture qualifier). Paul
Bug#1063864: src:mediawiki2latex: fails to migrate to testing for too long: not installable on armel, mips64el and s390x
Hi Paul, thank you for the explanation. So the dependency on chromium is the problem on these architectures. Chromium is used to render tables in tables to pdf if command line option -a is given. Otherwise Chromium is not used. If it helps to change the dependency to chromium and chromium-sandbox from Depends to Recommends I would like to ask Georges to do so. Yours Dirk On 14.02.24 16:47, Paul Gevers wrote: Hi, On 14-02-2024 14:27, Georges Khaznadar wrote: At the same time, https://buildd.debian.org/status/package.php?p=mediawiki2latex says that the package could be installed, I understand the confusing but the word "installed" on buildd.d.o means something else than that you can install the binaries. It means that the packages were incorporated (installed) into the archive. so its runtime dependencies are correct, on architectures: amd64, arm64, armel, armhf, i386, mips64el, ppc64el, riscv64, s390x, alpha, hurd-i386, ia64, ppc64, sparc64. Maybe you can try to install the binaries in a clean environment (I've done so, pasted below). Paul root@autopkgtest-lxc-vtalsf:/tmp/autopkgtest-lxc.c47fu43n/downtmp/build.Nel/src# apt install mediawiki2latex Reading package lists... Done Building dependency tree... Done Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: mediawiki2latex : Depends: chromium but it is not installable Depends: chromium-sandbox but it is not installable Recommends: calibre but it is not going to be installed Recommends: latex2rtf but it is not going to be installed Recommends: libreoffice but it is not going to be installed E: Unable to correct problems, you have held broken packages.
Bug#1063864: src:mediawiki2latex: fails to migrate to testing for too long: not installable on armel, mips64el and s390x
Hi Georges, I think its a good idea to wait for 24 hours. I am not sure if I will be available during the next few weeks. So just take the decisions you consider useful and don't bother about me. Yours Dirk On 14.02.24 14:27, Georges Khaznadar wrote: Hello Paul, Dirk, Dirk Hünniger a écrit : https://qa.debian.org/excuses.php?package=mediawiki2latex says: Issues preventing migration: * mediawiki2latex/armel has unsatisfiable dependency * mediawiki2latex/mips64el has unsatisfiable dependency * mediawiki2latex/s390x has unsatisfiable dependency At the same time, https://buildd.debian.org/status/package.php?p=mediawiki2latex says that the package could be installed, so its runtime dependencies are correct, on architectures: amd64, arm64, armel, armhf, i386, mips64el, ppc64el, riscv64, s390x, alpha, hurd-i386, ia64, ppc64, sparc64. I have no precise idea about this misbehavior, unfortunately. However the excuses page tells that the package is 5 days old (needing 5 days), maybe we should wait 24 hours longer ? If the migrations keeps failing, I can make some trivial change and make another source upload. Best regards, Georges.
Bug#1063864: src:mediawiki2latex: fails to migrate to testing for too long: not installable on armel, mips64el and s390x
Hi Paul, Georges, This site https://qa.debian.org/excuses.php?package=mediawiki2latex says: Issues preventing migration: * mediawiki2latex/armel has unsatisfiable dependency * mediawiki2latex/mips64el has unsatisfiable dependency * mediawiki2latex/s390x has unsatisfiable dependency So I think its a problem in the packages I depend on and thus cannot fix myself. What is even more strange is that this site https://buildd.debian.org/status/package.php?p=mediawiki2latex says that is it installed on armel misp64el and s390x. Happy to hear about you explanations. Yours Dirk On 13.02.24 20:08, Paul Gevers wrote: Source: mediawiki2latex Version: 8.0-1 Severity: serious Control: close -1 8.7-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:mediawiki2latex has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version can't be installed on armel, mips64el and s390x while the package builds on those architectures. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=mediawiki2latex
Bug#1063320: gretl: NMU diff for 64-bit time_t transition
On 6 February 2024 at 06:43, Steve Langasek wrote: | Source: gretl | Version: 2023c-2 | Severity: serious | Tags: patch pending sid trixie | Justification: library ABI skew on upgrade | User: debian-...@lists.debian.org | Usertags: time-t | | NOTICE: these changes must not be uploaded to unstable yet! | | Dear maintainer, | | As part of the 64-bit time_t transition required to support 32-bit | architectures in 2038 and beyond | (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified | gretl as a source package shipping runtime libraries whose ABI | either is affected by the change in size of time_t, or could not be | analyzed via abi-compliance-checker (and therefore to be on the safe | side we assume is affected). | | To ensure that inconsistent combinations of libraries with their | reverse-dependencies are never installed together, it is necessary to | have a library transition, which is most easily done by renaming the | runtime library package. | | Since turning on 64-bit time_t is being handled centrally through a change | to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is | important that libraries affected by this ABI change all be uploaded close | together in time. Therefore I have prepared a 0-day NMU for gretl | which will initially be uploaded to experimental if possible, then to | unstable after packages have cleared binary NEW. | | Please find the patch for this NMU attached. | | If you have any concerns about this patch, please reach out ASAP. Although | this package will be uploaded to experimental immediately, there will be a | period of several days before we begin uploads to unstable; so if information | becomes available that your package should not be included in the transition, | there is time for us to amend the planned uploads. Thanks, Steve. I applied the patch to my repo and committed to salsa. Gretl updates infrequently enough so that a transition to unstable is very likely to happen before a new upstream. Cheers, Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1063047: Unable to run R CMD Rserve
Appears to work based on a quick check in Docker: root@8d41067e72ce:/work# dpkg -i r-cran-rserve_1.8-13-2_amd64.deb Selecting previously unselected package r-cran-rserve. (Reading database ... 17542 files and directories currently installed.) Preparing to unpack r-cran-rserve_1.8-13-2_amd64.deb ... Unpacking r-cran-rserve (1.8-13-2) ... Setting up r-cran-rserve (1.8-13-2) ... root@8d41067e72ce:/work# R CMD Rserve --help Usage: R CMD Rserve [] Options: --help this help screen --version prints Rserve version (also passed to R) --RS-port listen on the specified TCP port --RS-socket use specified local (unix) socket instead of TCP/IP. --RS-workdir use specified working directory root for connections. --RS-encoding set default server string encoding to . --RS-conf load additional config file. --RS-settings dumps current settings of the Rserve --RS-source source the specified file on startup. --RS-enable-control enable control commands --RS-enable-remote enable remote connections --RS-pidfile store the pid of the Rserve process in --RS-set = set configuration option as if it was read from a configuration file All other options are passed to the R engine. root@8d41067e72ce:/work# Thanks again for the heads-up! Best, Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1063047: Unable to run R CMD Rserve
On 4 February 2024 at 18:12, Jerome Charaoui wrote: | Package: r-cran-rserve | Version: 1.8-13-1 | Severity: important | | Hello, | | Running the command "R CMD Rserve" doesn't work because of missing | symlinks in the package. The error message shown is: | | /usr/lib/R/bin/Rcmd: 64: exec: Rserve: not found Uh-oh. Not good. | This problem was previously reported as #744759, but has been | reintroduced (I think) when the package was migrated to debhelper. | | Migrating the DEB_DH_LINK_ARGS variable to a proper target should be | sufficient to resolve this. I have those, see [1] but they may also only work with cdbs which dh-r and debhelper-compat replaced. I will see about an explicit target to correct this. Thanks a bunch for catching this. And good to know someone uses Rserve, it is a nifty little (underappreciated, I find) tool! Dirk [1] https://sources.debian.org/src/rserve/1.8-13-1/debian/rules/ -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1060101: Boost 1.81 removal
On 14 January 2024 at 06:49, Dirk Eddelbuettel wrote: | | FYI two days before you filed #1060101 I actually happened to have updated | r-cran-bh to 1.84.0 (upstream, which is me, went to the 1.84.0 version | released in December as Boost releases every four months) using 1.83: | |r-cran-bh (1.84.0-1) unstable; urgency=medium | | * debian/control: Update Depends back to libboost-dev which will ensure |use of Boost 1.83 matching the just-updated BH package at CRAN which |is now at Boost 1.84 (released in December) which should be close |enough for our needs; a versioned name is no longer needed as the |default is now 1.83.0-2+b2 | | * debian/control: Set Build-Depends: to current R version | * debian/control: Switch to virtual debhelper-compat (= 13) | | -- Dirk Eddelbuettel Wed, 10 Jan 2024 07:20:09 -0600 | | So this should sort itself out by itself in a matter of days. r-cran-bh is | healthy: | |https://tracker.debian.org/pkg/r-cran-bh And it did, as expected. So no issues from r-cran-bh. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1060101: Boost 1.81 removal
FYI two days before you filed #1060101 I actually happened to have updated r-cran-bh to 1.84.0 (upstream, which is me, went to the 1.84.0 version released in December as Boost releases every four months) using 1.83: r-cran-bh (1.84.0-1) unstable; urgency=medium * debian/control: Update Depends back to libboost-dev which will ensure use of Boost 1.83 matching the just-updated BH package at CRAN which is now at Boost 1.84 (released in December) which should be close enough for our needs; a versioned name is no longer needed as the default is now 1.83.0-2+b2 * debian/control: Set Build-Depends: to current R version * debian/control: Switch to virtual debhelper-compat (= 13) -- Dirk Eddelbuettel Wed, 10 Jan 2024 07:20:09 -0600 So this should sort itself out by itself in a matter of days. r-cran-bh is healthy: https://tracker.debian.org/pkg/r-cran-bh Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1059875: RM: rJava [i386] -- RoM: FTBFS as i386 builds no longer maintained upstream
( Resending to now correctly-typed package r-cran-rcdklibs -- Dirk ) On 11 January 2024 at 07:09, Dirk Eddelbuettel wrote: | | Package: ftp.debian.org | Severity: normal | | The rJava package (source package 'rjava', binary package r-cran-rjava) no | longer builds on i386 as most of the world, including R and its CRAN network, | have moved on from i386. | | So I am requesting the removal of the i386 builds from testing so that the | package can migrate; it works and tests fine everywhere else. | | Four packages are listed as reverse depends (see below). I will have to | presumably 'climb the tree' and request removal of each of these and will | likely dues so in due course. For now, I am CCing the packages in question, | as well as the initial bug report #1059875. | | Dirk | | | $ ssh mirror.ftp-master.debian.org "dak rm -Rn rjava" | Will remove the following packages from unstable: | | r-cran-rjava | 1.0-6-1+b1 | i386 | r-cran-rjava | 1.0-10-1 | amd64, arm64, armel, armhf, mips64el, ppc64el, riscv64, s390x | rjava |1.0-6-1 | source | rjava | 1.0-10-1 | source | | Maintainer: Dirk Eddelbuettel | | --- Reason --- | | -- | | Checking reverse dependencies... | # Broken Depends: | libgoby-java: goby-java | r-cran-rcdk: r-cran-rcdk | r-cran-rcdklibs: r-cran-rcdklibs | | # Broken Build-Depends: | beast-mcmc: r-cran-rjava | libgoby-java: r-cran-rjava | r-cran-rcdk: r-cran-rjava | r-cran-rcdklibs: r-cran-rjava | | Dependency problem found. | | $ | | | -- | dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1060441: RM: rJava [i386] -- RoM: FTBFS as i386 builds no longer maintained upstream
Package: ftp.debian.org Severity: normal The rJava package (source package 'rjava', binary package r-cran-rjava) no longer builds on i386 as most of the world, including R and its CRAN network, have moved on from i386. So I am requesting the removal of the i386 builds from testing so that the package can migrate; it works and tests fine everywhere else. Four packages are listed as reverse depends (see below). I will have to presumably 'climb the tree' and request removal of each of these and will likely dues so in due course. For now, I am CCing the packages in question, as well as the initial bug report #1059875. Dirk $ ssh mirror.ftp-master.debian.org "dak rm -Rn rjava" Will remove the following packages from unstable: r-cran-rjava | 1.0-6-1+b1 | i386 r-cran-rjava | 1.0-10-1 | amd64, arm64, armel, armhf, mips64el, ppc64el, riscv64, s390x rjava |1.0-6-1 | source rjava | 1.0-10-1 | source Maintainer: Dirk Eddelbuettel --- Reason --- -- Checking reverse dependencies... # Broken Depends: libgoby-java: goby-java r-cran-rcdk: r-cran-rcdk r-cran-rcdklibs: r-cran-rcdklibs # Broken Build-Depends: beast-mcmc: r-cran-rjava libgoby-java: r-cran-rjava r-cran-rcdk: r-cran-rjava r-cran-rcdklibs: r-cran-rjava Dependency problem found. $ -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1060162: sssd_ad: Dynamic DNS updates fail with NOTZONE for PTR records if interface has multiple IPv6 adresses
Package: sssd-ad Version: 2.8.2-4 Severity: normal Tags: upstream ipv6 X-Debbugs-Cc: dirk.heinri...@altum.de If a network interface has multiple IPv6 addresses (here: a public one and one on the fd00 network), dynamic DNS updates fail with a NOTZONE error when updating the PTR records, although there's a zone for each of the networks configured in the DNS (Samba AD) server. The reason is that the commands to update the records are sent at the same time, like this (according to the log file): update delete .in-addr.arpa. in PTR update add .in-addr.arpa. 3600 in PTR . send update delete .ip6.arpa. in PTR update add .ip6.arpa. 3600 in PTR . update delete .ip6.arpa. in PTR update add .ip6.arpa. 3600 in PTR . send which I can also reproduce by copy/pasting the same commands into an nsupdate session. The problem can easily be solved by adding another send command, like so: update delete .in-addr.arpa. in PTR update add .in-addr.arpa. 3600 in PTR . send update delete .ip6.arpa. in PTR update add .ip6.arpa. 3600 in PTR . send update delete .ip6.arpa. in PTR update add .ip6.arpa. 3600 in PTR . send The problem has been solved upstream already (see https://github.com/SSSD/sssd/issues/7110) and released with version 2.9.3. Please backport the fix to 2.8.2 included in Bookworm. -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-17-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages sssd-ad depends on: ii libc6 2.36-9+deb12u3 ii libdhash1 0.6.2-1 ii libini-config50.6.2-1 ii libldap-2.5-0 2.5.13+dfsg-5 ii libldb2 2:2.6.2+samba4.17.12+dfsg-0+deb12u1 ii libpopt0 1.19+dfsg-1 ii libsasl2-22.1.28+dfsg-10 ii libsmbclient 2:4.17.12+dfsg-0+deb12u1 ii libsss-idmap0 2.8.2-4 ii libtalloc22.4.0-f2 ii libtevent00.14.1-1 ii samba-libs2:4.17.12+dfsg-0+deb12u1 ii sssd-ad-common2.8.2-4 ii sssd-common 2.8.2-4 ii sssd-krb5-common 2.8.2-4 sssd-ad recommends no packages. Versions of packages sssd-ad suggests: ii adcli 0.9.1-2 -- no debconf information
Bug#1059875: src:rjava: fails to migrate to testing for too long: FTBFS on i386
(Adrian: Added you to CCs per suggestion of Paul.) Hi Paul, On 2 January 2024 at 21:00, Paul Gevers wrote: | Hi Dirk, | | On 02-01-2024 20:42, Dirk Eddelbuettel wrote: | > | The Release Team considers packages that are out-of-sync between testing | > | and unstable for more than 30 days as having a Release Critical bug in | > | > I noticed that too over the last few weeks as I tend to keep an eye on my | > aggregation at https://qa.debian.org/developer.php?login=e...@debian.org | | Nice. I wish every DD did that. | | > | This bug will trigger auto-removal when appropriate. As with all new | > | bugs, there will be at least 30 days before the package is auto-removed. | > | > Sure. Though that might be harsh / might affect other packages. | | They will be notified of the autoremoval automatically and can help you | fix the situation. If there's work in progress, you can delay the | autoremoval by pinging this bug, that resets the timer. | | > We may want to consider exempting i386 as a build arch if that is possible. | | Well, if you really can't support i386 anymore (we expect from DD to | support as many architectures as is *reasonably* possible), you should | arrange for the removal of the i386 package, including all reverse i386 | dependencies. It would be good to coordinate this with your reverse | dependencies (at least inform them). In the end removal happens by | filing appropriate RM bugs against the ftp.debian.org pseudo package. Ok. I can do that. I just look at 'rdepends' for r-cran-rjava and it is only five packages. That seems fair. | > | If you believe your package is unable to migrate to testing due to | > | issues beyond your control, don't hesitate to contact the Release Team. | > | > :wave: | | FTBFS of your own package is what I consider to be in your control (this | text is part of the template I use). Either you fix the issue, or you | decide to no long support i386 with your package, but you'll need to | coordinate with your reverse dependencies. The removal happens by | ftp-master once you file the appropriate bugs. | | > This is an R package, and R no longer releases on i386 meaning upstream may | > not have checked / may not be receptive. See eg [1] for the CRAN state of the | > package. No i386 there. | > | > I am not sure what else to do besides simply saying 'no longer builds on i386'. | | Maybe contact i386 porters for help creating a patch? (We have one: | Adrian Bunk). Good idea. Have CC'ed Adrian to see if he wants to jump in. | Having said all that, most of our upstreams don't support (for some | value of support) all the architectures that we support. Still we expect | from DD to put in *reasonable* effort to support their packages on our | architectures. So, the call to drop an architecture from the supported | list is yours to make as a maintainer. It is not easy to strike the right balance, ie for m68k we 'hang on' for a long time as we had motivated maintainers / porters / developers. Not sure we had users :) For i386 we have been patient too. The hardware has been EOL for some time and most projects have ceased explicit support. That is a fair sign. If someone wants to help, I am happy to play along. But if not, I think for a 'somewhat marginal leaf-alike' dependency such as rJava aka r-cran-rjava removing i386 support is defensible. We only support approx 1k out 20k CRAN packages so users are accustomed to having to go elsewhere anyway. I packaged rJava nearly 20 years ago because it is a 'difficult' package for many users and our integration helps. I still maintain it for the same reason, even if Java is also way more marginal within R now. So for i386 the end may be coming. Cheers, Dirk | Paul | x[DELETED ATTACHMENT OpenPGP_signature.asc, application/pgp-signature] -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1059875: src:rjava: fails to migrate to testing for too long: FTBFS on i386
On 2 January 2024 at 20:07, Paul Gevers wrote: | Source: rjava | Version: 1.0-6-1 | Severity: serious | Control: close -1 1.0-10-1 | Tags: sid trixie ftbfs | User: release.debian@packages.debian.org | Usertags: out-of-sync | | Dear maintainer(s), | | The Release Team considers packages that are out-of-sync between testing | and unstable for more than 30 days as having a Release Critical bug in I noticed that too over the last few weeks as I tend to keep an eye on my aggregation at https://qa.debian.org/developer.php?login=e...@debian.org | testing [1]. Your package src:rjava has been trying to migrate for 31 | days [2]. Hence, I am filing this bug. The version in unstable failed to | build on i386. | | If a package is out of sync between unstable and testing for a longer | period, this usually means that bugs in the package in testing cannot be | fixed via unstable. Additionally, blocked packages can have impact on | other packages, which makes preparing for the release more difficult. | Finally, it often exposes issues with the package and/or | its (reverse-)dependencies. We expect maintainers to fix issues that | hamper the migration of their package in a timely manner. | | This bug will trigger auto-removal when appropriate. As with all new | bugs, there will be at least 30 days before the package is auto-removed. Sure. Though that might be harsh / might affect other packages. We may want to consider exempting i386 as a build arch if that is possible. | I have immediately closed this bug with the version in unstable, so if | that version or a later version migrates, this bug will no longer affect | testing. I have also tagged this bug to only affect sid and trixie, so | it doesn't affect (old-)stable. | | If you believe your package is unable to migrate to testing due to | issues beyond your control, don't hesitate to contact the Release Team. :wave: This is an R package, and R no longer releases on i386 meaning upstream may not have checked / may not be receptive. See eg [1] for the CRAN state of the package. No i386 there. I am not sure what else to do besides simply saying 'no longer builds on i386'. Dirk [1] https://cran.r-project.org/web/checks/check_results_rJava.html | Paul | | [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html | [2] https://qa.debian.org/excuses.php?package=rjava | | x[DELETED ATTACHMENT OpenPGP_signature.asc, application/pgp-signature] -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)
On 9 December 2023 at 01:06, Charles Plessy wrote:
| I do not know for r-bioc-netsam, but for r-bioc-org.hs.eg.db and similar
| packages, it is because it is an "annotation package" made of data and
| therefore not managed the same way as the other Bioconductor packages.
|
| This is why it DESCRIPTION file does not mention its Bioconductor Git
| branch. This is also why its version number matches the Bioconductor
| release number. Also, its homepage resolves to
|
https://bioconductor.org/packages/release/data/annotation/html/org.Hs.eg.db.html
| while for regular packages there is no data/annotation/html in the URL.
|
| I think that it does not have to depend on the bioc api pseudo-package.
When r2u builds all of CRAN plus the ~ 200 BioC that are implied plus ~ 200
more that either in Debian or high on BioC's own 'karma' list, I query all
four repositories as one must. That is basically what the BioC installer
helpers always did for twenty-some years. My code (quicker for me to find)
is
## cf contrib.url(BiocManager::repositories())
## [1] "https://bioconductor.org/packages/3.14/bioc/src/contrib;
## [2]
"https://bioconductor.org/packages/3.14/data/annotation/src/contrib;
## [3]
"https://bioconductor.org/packages/3.14/data/experiment/src/contrib;
biocrepo <- paste0("https://bioconductor.org/packages/;,
.getConfig("bioc_version"), "/bioc")
apBIOC <- data.table(ap="Bioc",
as.data.frame(available.packages(repos=biocrepo)))
biocdataannrepo <- paste0("https://bioconductor.org/packages/;,
.getConfig("bioc_version"), "/data/annotation")
apBIOCdataann <- data.table(ap="Bioc",
as.data.frame(available.packages(repos=biocdataannrepo)))
apBIOC <- merge(apBIOC, apBIOCdataann, all=TRUE)
biocdataexprepo <- paste0("https://bioconductor.org/packages/;,
.getConfig("bioc_version"), "/data/experiment")
apBIOCdataexp <- data.table(ap="Bioc",
as.data.frame(available.packages(repos=biocdataexprepo)))
apBIOC <- merge(apBIOC, apBIOCdataexp, all=TRUE)
Ah, and younger Dirk left a message for current Dirk that this does indeed
show it too:
> contrib.url(BiocManager::repositories())
'getOption("repos")' replaces Bioconductor standard repositories, see
'help("repositories", package = "BiocManager")' for details.
Replacement repositories:
CRAN: https://cloud.r-project.org
[1] "https://bioconductor.org/packages/3.18/bioc/src/contrib;
[2] "https://bioconductor.org/packages/3.18/data/annotation/src/contrib;
[3] "https://bioconductor.org/packages/3.18/data/experiment/src/contrib;
[4] "https://bioconductor.org/packages/3.18/workflows/src/contrib;
[5] "https://bioconductor.org/packages/3.18/books/src/contrib;
[6] "https://cloud.r-project.org/src/contrib;
>
And when I bulk-updated the BioC packages for my 20.04 and 22.04 build in
r2u, I did notice that some of the 'non-R-package packages' in annotations
and experiment did not update. One could always ask BioC which of these are
/ are not considered release dependent. Their slack is open and pretty
friendly, I hang there too.
Cheers, Dirk
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1055922: rmatrix: ABI change in Matrix 1.6-2
Hi Graham On 30 November 2023 at 07:54, Graham Inggs wrote: | Hi Dirk | | On Thu, 30 Nov 2023 at 00:51, Dirk Eddelbuettel wrote: | > Ping squared. | > | > If I don't hear from you I may just close this. I believe this (non-, to me) | > issue has been taken care of. If you think I am wrong please let me know. | | I closed it on 2023-11-24 [1]. Where do you see it still open? My bad: I don't. I just didn't see an explicit ack. (General bts acks are filtered away by procmail to a different folder). So my bad and sorry for wasting your time. I see you track it at Ubuntu too so all good. r2u, which dominates of course all r-(cran,bioc)-* packages for use on jammy had it long covered. Cheers, Dirk | | [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055922#118 -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1055922: rmatrix: ABI change in Matrix 1.6-2
On 27 November 2023 at 08:27, Dirk Eddelbuettel wrote: | | Graham, | | Quick ping to ask where we are we on this? Matrix is in testing so can this | be closed? Ping squared. If I don't hear from you I may just close this. I believe this (non-, to me) issue has been taken care of. If you think I am wrong please let me know. Dirk | Cheers, Dirk | | -- | dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1055922: rmatrix: ABI change in Matrix 1.6-2
Graham, Quick ping to ask where we are we on this? Matrix is in testing so can this be closed? Cheers, Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1055926: rodbc: [L10N,DE] rodbc_1.3-21-1_R-de: german translation
On 26 November 2023 at 15:09, Christoph Brinkhaus wrote: | Am Tue, Nov 14, 2023 at 02:46:18PM +0100 schrieb Christoph Brinkhaus: | > Am Tue, Nov 14, 2023 at 07:04:23AM -0600 schrieb Dirk Eddelbuettel: | > > | > > On 14 November 2023 at 12:30, Christoph Brinkhaus wrote: | > > | Source: rodbc | > > | Version: 1.3-21-1 | > > | Severity: wishlist | > > | | > > | Dear Maintainer, | > > | | > > | please find attached the po file with the german translation. | > > | It is an update to the current po template. | > > | Please consider to apply it to the package. | > > | > > Should that not go to the upstream package, possibly via the R Translations | > > project (where AFAIK German po files are handled by Detlef Steuer) ? | > > | > > https://translation.r-project.org/ | > | > I will mail Detlef and add you cc. | | The po file has been accepted and updated upstream. Yes, thanks, I know -- I run a cronjob scanning CRAN for new packages and updates every hour: https://dirk.eddelbuettel.com/cranberries/ (also eg on Mastodon as @CRANberriesFeed) but this being a travel weekend in the US I was gone a few days. I just updated the package. Thanks for contributing the translations, much appreciated (even if I emigrated 'von daheim' a few years before I got into Debian (and R) in the nineties. Mit besten Grüssen, Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1055922: rmatrix: ABI change in Matrix 1.6-2
Hi Graham, On 20 November 2023 at 12:13, Graham Inggs wrote: | On Sun, 19 Nov 2023 at 14:59, Dirk Eddelbuettel wrote: | > So it contains a patch by Mikael which had been applied _permitting Matrix | > 1.6-2_ to get to CRAN. So for this particular pair it was the other way around. | | Great, thanks for clearing that up. | | > So I leave this in your hands. If you think that after all this needs a | > transtion, I may shrug but will of course help. | | Well, we are doing a transition (for some value of), just not a | "rebuild everything" transition like we must do for C libraries, but a | "rebuild only affected things" like we do for Python and other | interpreted languages. | | On Sun, 19 Nov 2023 at 17:28, Dirk Eddelbuettel wrote: | > Done in lme4 1.1-35.1-3. | | Thanks. I see now r-cran-lme4 now has a: | Depends: r-cran-matrix (>= 1.6-2) | ...however this is not correct, because dpkg considers r-cran-matrix | 1.6-1.1-1 in testing to meet that requirement, and the tests still | fail with that version. | | $ dpkg --compare-versions 1.6-1.1-1 ge 1.6-2 && echo True | True | | Please change that to: | Depends: r-cran-matrix (>= 1.6-2-1) | ... and re-upload, because dpkg considers 1.6-2 to be upstream version | 1.6 and Debian revision 2, whereas we need upstream version 1.6-2 and | Debian revision 1. | | $ dpkg --compare-versions 1.6-1.1-1 ge 1.6-2-1 && echo True | Dang. Fell into a well-known hole there. Will fix ASAP. Had in the back of my mind some notion of 'cannot express Debian build number' but that is clearly wrong. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1055922: rmatrix: ABI change in Matrix 1.6-2
On 19 November 2023 at 09:59, Dirk Eddelbuettel wrote: | On 19 November 2023 at 13:49, Graham Inggs wrote: | | We don't believe only touching debian/changelog, or a binNMU, is | | sufficient. We were surprised that your r-cran-lme4 upload did not at | | least include: | | Depends: r-cran-matrix (>= 1.6-2-1) | | Without that relationship, r-cran-lme4 could migrate to testing and be | | installed on users' systems without the corresponding version of | | r-cran-matrix. It is no surprise that the excuses page for lme4 [4] | | is all red, because that is exactly what is being tested. More on | | this to come in my next email. | | I can add that, and probably should have. And I agree with the sentiment in | your other mail that a transition is overkill here. Done in lme4 1.1-35.1-3. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1055922: rmatrix: ABI change in Matrix 1.6-2
Hi Graham,
On 19 November 2023 at 13:49, Graham Inggs wrote:
| On Tue, 14 Nov 2023 at 12:42, Dirk Eddelbuettel wrote:
| > Doesn't 'normal' do that?
|
| No, only serious and above are considered RC [1] and also for migration.
|
| This week, Paul Gevers and I spent some time discussing ways to move
| this transition forward.
|
| Referring back to some of your previous emails below.
|
| On Tue, 14 Nov 2023 at 12:01, Dirk Eddelbuettel wrote:
| > We need to address the packages needing a rebuild. Mine (r-cran-lme4,
| > r-cran-rcppeigen). have been taken care of.
|
| We see the upload of lme4 1.1-35.1-2 on 2023-11-14 [2], and the
| changelog mentions a rebuild, but the upload of r-cran-rcppeigen
| 0.3.3.9.4-1 on 2023-11-03 [3] happened before the upload of matrix
| 1.6-2-1. Does r-cran-rcppeigen still require a rebuild?
I am upstream for RcppEigen.
And the upstream NEWS has
\item The interface to package \pkg{Matrix} has been updated and
simplified thanks to an excllent patch by Mikael Jagan.
\item The new upload is coordinated with packages \pkg{lme4} and
\pkg{OpenMx}.
So it contains a patch by Mikael which had been applied _permitting Matrix
1.6-2_ to get to CRAN. So for this particular pair it was the other way around.
And I acted accordingly as Debian maintainer for a package for which I am
upstream.
| On Mon, 13 Nov 2023 at 12:23, Dirk Eddelbuettel wrote:
| > I would appreciate it if someone could tickle rebuilds. To me a quick
| > informal touch of debian/changelog would do; if someone thinks this needs a
| > formal transition go for it.
|
| We don't believe only touching debian/changelog, or a binNMU, is
| sufficient. We were surprised that your r-cran-lme4 upload did not at
| least include:
| Depends: r-cran-matrix (>= 1.6-2-1)
| Without that relationship, r-cran-lme4 could migrate to testing and be
| installed on users' systems without the corresponding version of
| r-cran-matrix. It is no surprise that the excuses page for lme4 [4]
| is all red, because that is exactly what is being tested. More on
| this to come in my next email.
I can add that, and probably should have. And I agree with the sentiment in
your other mail that a transition is overkill here.
Matrix has 1304 reverse dependencies at CRAN [1], Mikael (in the two emails
he wrote at my urging) identified 14 packages that needed a rebuild because
they use Matrix header files (R packages can build against headers in another
package, this is more specialised use), and another 3 that had cached S4 (the
more complicated OO model in R) function signature.
So 17 out of 1304 is not exactly a general breakage. I think I found 6 out of
the 17 as being in Debian. I had dealt with three myself and then sent email to
initiate
simple rebuilds. But that went nowhere.
So I leave this in your hands. If you think that after all this needs a
transtion, I may shrug but will of course help.
And please dDon't get wrong: I am considering this to be an open problem
upstream. The R Core team, the CRAN team, and others are discussing, but the
CRAN system does not quite have our mechanisms even to push binary
rebuilds. So this is an ongoing and open issue.
Dirk
[1] See the R snippet:
> db <- tools::CRAN_package_db()
> length(tools::package_dependencies("Matrix", reverse=TRUE, db=db)$Matrix)
[1] 1304
>
so 1304 are found right now at CRAN, and 17/1304 is about 1.3%. We seem
to have 6 identified out of about 138 (per apt-cache rdepends ...)
which is a little higher at 4.3% which is normal as 'heavier' packages
are more likely to be packaged. But net-net it is still only one out
over twenty packages around Matrix.
|
| Regards
| Graham
|
|
| [1] https://www.debian.org/Bugs/Developer#severities
| [2]
https://tracker.debian.org/news/1478501/accepted-lme4-11-351-2-source-into-unstable/
| [3]
https://tracker.debian.org/news/1475888/accepted-r-cran-rcppeigen-03394-1-source-into-unstable/
| [4] https://qa.debian.org/excuses.php?package=lme4
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1055922: rmatrix: ABI change in Matrix 1.6-2
I will not engage any more with debian-r. But this is now at the BTS so a clarification may be in order. This started as I had sent an email as a heads-up to fellow maintainers (via that mostly pointless list) informing them that their packages would exhibit a bug following a bug in package Matrix. Now, net-net all I got out of this is a 'severity: serious' bug against my own package, and a beyond-stupid situation (sadly also not a first time) where the affected maintainer now acts like a three-year and refuses to update his known-broken packages. And I repeact that it was upstream (for Matrix) who asked (publically, on a R list) for a rebuild. Going forward, I will simply not send such courtesy emails. Life is too short. I will let just those follow maintainers continue to waste the time of the release managers by trying random combination of packages and then acting surprised that breakage happens. CRAN is well known to work exceedingly well at '@HEAD' (occasional bugs among what are now over 20k packages notwithstanding). But some people refuse to understand or acknowledge that and enjoy fighting fight pointless fights. We can all choose our own adventure, but that particular one is of no interest to me. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1055922: rmatrix: ABI change in Matrix 1.6-2
On 14 November 2023 at 07:42, Dirk Eddelbuettel wrote: | | On 14 November 2023 at 12:26, Graham Inggs wrote: | | Hi Dirk | | | | On Tue, 14 Nov 2023 at 12:01, Dirk Eddelbuettel wrote: | | > Well that seems to be a) the wrong severity and b) the wrong package. | | | | Both are correct. We do not want rmatrix to migrate and break | | packages in testing. | | Doesn't 'normal' do that? I always get the shivers when I see 'serious' as I | fear that my package is at the risk of removal (which we of course Matrix | can't be 'really' given its systemic status from its "recommended" status | within R and very widespread use). | | | However, in this case, I only set the severity to match reality; | | rmatrix is already blocked from migrating due to the autopkgtest | | regressions. | | | | > We need to address the packages needing a rebuild. Mine (r-cran-lme4, | | > r-cran-rcppeigen). have been taken care of. | | | | Agreed, and rmatrix may need some new Breaks to allow the affected | | packages to migrate together. | | The issue is actually hugely problematic for CRAN and R Core, and there are | some discussions but no solutions. They do not have (formal) notions like | binary rebuild for parts where they distribute binaries, and no means of | reaching binary redistributors such as us. Oh well. At least it doesn't | happen often. | | Anyway. Now that you made it a bug I let you drive this. Upstream just made | an unrelated bugfix Matrix 1.6-3 which I just sent to unstable. There are two known failures left which the maintainer(s) do not want to fix. As I have fixed my dependents of package Matrix, I continue to find it unfair that I am being to an open bug requiring fixes via builds in other packages that are not mine. So I guess this bug will stay open 'forever' or until those packages get normal routine updates. Dirk | | Dirk | | -- | dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1055922: rmatrix: ABI change in Matrix 1.6-2
On 14 November 2023 at 12:26, Graham Inggs wrote: | Hi Dirk | | On Tue, 14 Nov 2023 at 12:01, Dirk Eddelbuettel wrote: | > Well that seems to be a) the wrong severity and b) the wrong package. | | Both are correct. We do not want rmatrix to migrate and break | packages in testing. Doesn't 'normal' do that? I always get the shivers when I see 'serious' as I fear that my package is at the risk of removal (which we of course Matrix can't be 'really' given its systemic status from its "recommended" status within R and very widespread use). | However, in this case, I only set the severity to match reality; | rmatrix is already blocked from migrating due to the autopkgtest | regressions. | | > We need to address the packages needing a rebuild. Mine (r-cran-lme4, | > r-cran-rcppeigen). have been taken care of. | | Agreed, and rmatrix may need some new Breaks to allow the affected | packages to migrate together. The issue is actually hugely problematic for CRAN and R Core, and there are some discussions but no solutions. They do not have (formal) notions like binary rebuild for parts where they distribute binaries, and no means of reaching binary redistributors such as us. Oh well. At least it doesn't happen often. Anyway. Now that you made it a bug I let you drive this. Upstream just made an unrelated bugfix Matrix 1.6-3 which I just sent to unstable. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1055926: rodbc: [L10N,DE] rodbc_1.3-21-1_R-de: german translation
On 14 November 2023 at 12:30, Christoph Brinkhaus wrote: | Source: rodbc | Version: 1.3-21-1 | Severity: wishlist | | Dear Maintainer, | | please find attached the po file with the german translation. | It is an update to the current po template. | Please consider to apply it to the package. Should that not go to the upstream package, possibly via the R Translations project (where AFAIK German po files are handled by Detlef Steuer) ? https://translation.r-project.org/ Dirk | Thank you very much! | | Kind regards, | Christoph Brinkhaus | | -- System Information: | Debian Release: 12.2 | APT prefers stable-updates | APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') | Architecture: amd64 (x86_64) | | Kernel: Linux 6.1.0-13-amd64 (SMP w/4 CPU threads; PREEMPT) | Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE | Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set | Shell: /bin/sh linked to /usr/bin/dash | Init: systemd (via /run/systemd/system) | LSM: AppArmor: enabled | x[DELETED ATTACHMENT rodbc_1.3-21-1_R-de.po, plain text] -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1055922: rmatrix: ABI change in Matrix 1.6-2
On 14 November 2023 at 09:15, Graham Inggs wrote: | Source: rmatrix | Version: 1.6-2-1 | Severity: serious | X-Debbugs-Cc: debia...@lists.debian.org | | Hi Dirk | | I'm opening this bug as a place for discussion and to track the | affected packages. It can be closed once rmatrix and its | reverse-dependencies are ready to migrate. Well that seems to be a) the wrong severity and b) the wrong package. We need to address the packages needing a rebuild. Mine (r-cran-lme4, r-cran-rcppeigen). have been taken care of. Dirk | I've copied your email to the debian-r mailing list [1] below. | | Regards | Graham | | | [1] https://lists.debian.org/debian-r/2023/11/msg00033.html | | | Package Matrix is having a new and energetic maintainer/contributor in Mikael | Jagan who is tidying up a few loose corners (and inter alia sent me a patch | to RcppEigen that resulted in a coordinated CRAN update of RcppEigen, lme4, | and OpenMx). | | Mikael also identified two sets of packages needed a rebuild in messages to | the r-package-devel list (the more-or-less official place in the R Project to | ask / discuss package changes, it is a decent to be on) following private | mails between him and me. See | | https://stat.ethz.ch/pipermail/r-package-devel/2023q4/010051.html | https://stat.ethz.ch/pipermail/r-package-devel/2023q4/010054.html | | The first concerns packages using a LinkingTo: Matrix and building against | Matrix _headers_. The second concerns caching of S4 signatures (which bit us | at work because of SeuratObject [not in Debian] and how I got onto this). | | Most of these are not in Debian but I think we need binary rebuilds of | |irlbabecause of headers |OpenMx because of headers, a new upstream 2.21.10 is out too |TMB because of headers |MatrixModels because of S4 caching | | I would appreciate it if someone could tickle rebuilds. To me a quick | informal touch of debian/changelog would do; if someone thinks this needs a | formal transition go for it. | | The R Core team and the CRAN maintainers are aware of the implicit problem | with signalling the need for binary rebuilds. They are discussing this, but | do not have an answer. Historically, CRAN has informally rebuilt its binaries | for windows and macOS, but that of course does not help binary distributors | such as us, other Linux distros, Conda, r2u, ... at all. -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1054657: transition: r-bioc-biocgenerics
On 7 November 2023 at 14:58, Andreas Tille wrote:
| Do you see any way to answer the question that is discussed in this
| thread by r2u how to know whether new Bioconductor packages might have
| new dependencies not yet packaged for Debian?
"Kinda. Sorta. Not fully." I have written related code doing most of this
during the many attempt for 'turning CRAN into .deb packages'.
I.e. when I recompile BioC packages in r2u as I did this weekend I start from
all BioC packages I have already built within r2u (same for you here for a
'within Debian' check), use available.packages() etc to get the package
database (in the R sense) and use that to map out dependencies. In my case I
sort strip off CRAN (already built) and base R packages to get a count of
'pure BioC depends'. I then sort and first build all of these with a
dependency count of zero, refresh the index so that these become available,
then all with a count of one and so. (Max count this weekend was 41.)
The one step I did not do (as I didn't need it) was to check 'is package X
already available'. When it wasn't I just built it :) But you can do all that
from either shell into apt-cache, or R via my RcppAPT package, or via
python-apt and friends.
My code is in R with use of data.table for the mangling so it is somewhat
'internal'. It is based on R's own 'tools::package_dependencies()'. There
must also be suitable code in R itself which I never pulled out because R can
run a package's reverse dependencies. But anyway here is a minimal sketch
using R and its data.table package.
> AP <- suppressMessages( data.table(available.packages(repos =
> BiocManager::repositories())) )
> AP[, lcpkg := tolower(Package)]
> basePkgs <- c("base", "class", "codetools", "datasets", "graphics", "grid",
> "lattice",
+ "Matrix", "mgcv", "nnet", "rpart", "splines", "stats4", "tcltk",
"translations",
+ "boot", "cluster", "compiler", "foreign", "grDevices", "KernSmooth", "MASS",
+ "methods", "nlme", "parallel", "spatial", "stats", "survival", "tools",
"utils")
> cranPkgs <- AP[Repository=="https://cloud.r-project.org/src/contrib;, Package]
> biocPkgs <- AP[Repository!="https://cloud.r-project.org/src/contrib;, Package]
>
> pkg <- "SingleCellExperiment"
> deps <- tools::package_dependencies(pkg, AP, recursive=TRUE)[[1]]
> nAll <- length(deps)
> nBase <- length(intersect(deps, basePkgs))
> nCran <- length(intersect(deps, cranPkgs))
> nBioc <- length(intersect(deps, biocPkgs))
>
> intersect(deps, biocPkgs)
[1] "SummarizedExperiment" "S4Vectors""BiocGenerics"
"GenomicRanges"
[5] "DelayedArray" "MatrixGenerics" "IRanges"
"S4Arrays"
[9] "GenomeInfoDb" "XVector" "Biobase"
"GenomeInfoDbData"
[13] "zlibbioc"
>
So for all packages you are interested in (here I look just at
'SingleCellExperiment') you construct the BioC (or maybe CRAN and BioC)
dependencies, and then create an aggregate list of the unique
combination. Those are the packages you need and apt-cache and related will
tell you if they exist.
Dirk
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1054657: transition: r-bioc-biocgenerics
On 7 November 2023 at 22:01, Charles Plessy wrote: | One possible direction would be to leverage the work done by Dirk and | others in r2u, where the Bioc transition is over, and for each package | in Debian, look if the r2u equivalent has a dependency not in Debian. | | https://fediscience.org/@eddelbuettel@mastodon.social/111359074099802189 Thanks for the endorsement, Charles. As you brought r2u up, allow me to add my perspective. I have done so before without changing anyone's mind but once every few years I get to howl at these windmills. So I have been maintaining CRAN packages in Debian for 20 years [1], and I said for twenty years that we can trust CRAN. I meant that then, I mean it now. Ditto for BioConductor. Doubling all our testing up, and also throwing spanners into our own wheels via the autopkgtests, is (to me) a waste of our (limited !!) volunteer time. We *do* add value to CRAN (and BioConductor) because we build on much more exotic platforms than they do. But testing _again_ on core platforms like x86_64 is (to me) simply does not seem all that efficient. My r2u [2] is a case in point. As of last Friday, I had ~ 270 BioConductor packages in it (that is for Ubuntu LTS release 20.04 and 22.04, and of course in addition to the 22k CRAN packages each already has). I then rebuilt those 270 first for 'focal' (20.04) and then 'jammy' (22.04) on my machine [3] and uploaded them. After that, I realized I could and should check against BioConductor's own 'popularity context' [4,5] and ensured I had the top 200+ packages. And I also ran a `setdiff()` against the package 'testing' knew. So I added from both these source on the weekend. So r2u is now at 391 or so BioConductor packages, all at 3.18, for both 20.04 and 22.04. And 22.2k for CRAN. This does provide the obvious existence proof that yes, right after a BioConductor release their stuff of course works: they have AFAIK paid staff to ensure this. r2u has been running for a little over 1 1/2 years. It has shipped over 10 million packages (and I luckily have access to a well-connected mirror on the U of Illinois campus as I teach there part-time). It had a download spike in October (from a European research center, I have access to download logs) fetching 3+ million in two days (!!). It now sees a daily (!!) download from a 'well known US west coast tech giant' taking in about 5200 packages _each day_ from what looks like a cron job. It serves about 1000 unique IPs each day. There is clear demand for this. So if we wanted to do something useful, we should extend r2u to Debian. I have limited 'personal' bandwidth and hardware but if someone wanted to join we could make some hay here. People trust apt. The technology is there and works as we all know. It might be worth discussing how we can offer the 19.9k packages on CRAN [6] and all/most of BioConductor. We may want to do that in a to-be-determined form outside the distro as the ftpmasters (whose work I so appreciate, so let me say a big thanks here) cannot possibly 'manually' check 20+k thousand packages. But as I said on the outset: We *can* trust CRAN and BioConductor and take advantage and leverage their work which (among many other things) contains the same authorship, copyright, IP, ... tests we do. Thanks for listening for my sermon. I will now be quiet again and concentrate on these (in aggregate coming up on) 45k packages. I do appreciate everything that everybody does here -- we are after all a bunch of committed volunteers. Cheers, Dirk [1] The very first one we had was IIRC my r-cran-rodbc as ODBC headers always baffled users; and still do [2] See https://eddelbuettel.github.io/r2u [3] For BioConductor I cannot (?) use pre-made binaries as I do for (most of) CRAN via R-style binaries from p3m.dev which I turn into proper .deb files. [4] They call it somethings else, and 'score' downloads by unique IP over a rolling (12 months if I recall) window [5] See https://bioconductor.org/packages/stats/bioc/bioc_pkg_scores.tab [6] CRAN purges reasonably aggressively which is how r2u is now at 22.2k while CRAN is at 19.9k. -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1051901: 1.2.10 breaks ability to play audio using i386 binaries on amd64 host
Am Mo, 23. Okt 2023 um 18:31:26 -0400 schrieb Stefan Monnier: I'd go so far to think that this is not constrained to i386 binaries on amd64 hosts. `aplay /dev/zero` segfaults on a plain i386 host with asound 1.2.10. Downgrading to 1.2.9 helps. Is this the same as https://github.com/alsa-project/alsa-lib/issues/352 ? Seems to be the case. Sound is working again with the patches applied. Thanks, Dirk
Bug#1054921: [Quantlib-dev] Build error for quantlib-swig on mips64el
On 30 October 2023 at 12:23, Luigi Ballabio wrote: | Hello Dirk, unfortunately I have no idea what can cause this — do you think it | possible that the size of the wrappers crossed some threshold and relocations | started to occur that weren't there before? Adrian (CC'ed) supplied a merge request / pull request tweaking the compilation settings per architecture in the (meta-Makefile) debian/rules. It now builds again with optimization which I had forced off (for mips* architectures and per an earlier suggestion by Adrian also for mips64el). "These days" the compilers should be fast enough to cope. It is a bloody large file generated by Swig so we may need to wiggle settings once more on another architecture. We'll see. But first off, my thanks to Adrian for the suggested fix. Building here now and should get uploaded soon. Builders page is https://buildd.debian.org/status/package.php?p=quantlib-swig and the 1.32-2 build should appear there "soon". Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1054921: Build error for quantlib-swig on mips64el
The Debian package fails to build now on mipsel, a log is at [1]. The gist seems to be a relocation error: g++ -shared -Wl,-O1 -Wl,-Bsymbolic-functions -O0 -g0 -mxgot --param ggc-min-expand=20 -DBOOST_NO_AUTO_PTR build/temp.linux-mips64-cpython-311/QuantLib/quantlib_wrap.o -L/usr/lib/mips64el-linux-gnuabi64 -L/usr/lib -lQuantLib -o build/lib.linux-mips64-cpython-311/QuantLib/_QuantLib.cpython-311-mips64el-linux-gnuabi64.so -fopenmp build/temp.linux-mips64-cpython-311/QuantLib/quantlib_wrap.o: in function `virtual thunk to QuantLib::HimalayaOption::arguments::~arguments()': quantlib_wrap.cpp:(.text._ZN8QuantLib14HimalayaOption9argumentsD1Ev[_ZN8QuantLib14HimalayaOption9argumentsD1Ev]+0x104): relocation truncated to fit: R_MIPS_GOT_PAGE against `.text._ZN8QuantLib14HimalayaOption9argumentsD1Ev' Luigi, and idea if that is a known swig-on-mips64el issue and if we can addres it with particular flag? As the Debian bug report at [2] states, "this used to work" and I didn't change anything for the 1.32 pair of quantlib and quantlib-swig. For quantlib-swig, and for a few years now, I set some exotic compiler flags: ifneq "$(findstring $(cpu), mipsel mips mips64el)" "" compilerflags = -O0 -g0 -mxgot --param ggc-min-expand=20 -DBOOST_NO_AUTO_PTR endif but that mostly came from trying to keep the build with time or ram limits. Any hints would be most welcome. Cheers, Dirk [1] https://buildd.debian.org/status/fetch.php?pkg=quantlib-swig=mips64el=1.32-1=1698321785=0 [2] https://bugs.debian.org/1054921, also in CC for this email -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1054921: quantlib-swig: FTBFS on mips64el
the output | collect2: error: ld returned 1 exit status Looks like toolchain issue -- Swig maybe? Dirk | Cheers | -- | Sebastian Ramacher -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1054657: transition: r-bioc-biocgenerics
On 27 October 2023 at 16:43, Andreas Tille wrote: | Am Fri, Oct 27, 2023 at 09:19:22AM -0500 schrieb Dirk Eddelbuettel: | > | > | BioConductor has just released version 3.17. Since the next r-base | > | > Typo: 3.18 | | Yes. Thanks for pointing this out. | | > | release is pending on 2023-10-31 we do not think it is a good idea to | > | start the transition before but it might make sense to open this bug | > | > These two events are basically unrelated. (BioC releases twice a year, and | > the April release comes usually right after an R release. Those may warrant | > staging. October releases do not. It uses R 4.3.*. Note the wildcard.) | > | > | right now. (No idea whether we will see a proper r-api transition but | > | > R does not change APIs on _minor_ releases such as 4.3.2 next week. | | Thank you for this information. Since we will "loose" just about one | week I think waiting for r-base 4.3.2 makes sense anyway. It might | even last some days until release team might have setup the transition | tracker. Let me stress again that it is not relevant. You need R 4.3.0 or R 4.3.1 which havce existed for months inside the distro. Nothing in the release notes will suggest R 4.3.2 and none of those packages will change between use with either R 4.3.1 and R 4.3.2. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1054657: transition: r-bioc-biocgenerics
On 27 October 2023 at 16:00, Andreas Tille wrote: | Package: release.debian.org | Severity: normal | User: release.debian@packages.debian.org | Usertags: transition | X-Debbugs-Cc: r-bioc-biocgener...@packages.debian.org, debia...@lists.debian.org | Control: affects -1 + src:r-bioc-biocgenerics | | Hi, | | BioConductor has just released version 3.17. Since the next r-base Typo: 3.18 | release is pending on 2023-10-31 we do not think it is a good idea to | start the transition before but it might make sense to open this bug These two events are basically unrelated. (BioC releases twice a year, and the April release comes usually right after an R release. Those may warrant staging. October releases do not. It uses R 4.3.*. Note the wildcard.) | right now. (No idea whether we will see a proper r-api transition but R does not change APIs on _minor_ releases such as 4.3.2 next week. Dirk | building everything against the new r-base sounds like less hassle | than doing r-api-bioc transition right now.) | The BioConductor transition will bump the virtual package | r-api-bioc-3.17 to r-api-bioc-3.18. | | BTW, I'm aware that a couple of r-bioc-* packages did not yet migrated | to testing due to some autopkgtest issues on some architectures. We | decided that it makes sense to do the transition first and approach | upstream about their latest release in case those issues might remain. | | Kind regards and thanks a lot for your work as release team | Andreas. | | Ben file: | | title = "r-bioc-biocgenerics"; | is_affected = .depends ~ "r-api-bioc-3.17" | .depends ~ "r-api-bioc-3.18"; | is_good = .depends ~ "r-api-bioc-3.18"; | is_bad = .depends ~ "r-api-bioc-3.17"; | -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1037439: Unlikely to be a bug in r-base
On 16 October 2023 at 11:41, Andreas Beckmann wrote:
| On 05/10/2023 17.05, Dirk Eddelbuettel wrote:
| >
| > Andreas,
| >
| > This looks like an error:
| >
| > > reassign 1037439 src:r-base
| > Bug #1037439 {Done: Dirk Eddelbuettel }
[r-cran-rstan] r-cran-rstan/armhf FTBFS with r-cran-bh 1.74, works with boost
1.81
| > Bug reassigned from package 'r-cran-rstan' to 'src:r-base'.
| > No longer marked as found in versions r-cran-rstan/2.21.8-1 and
r-cran-bh.
| >
| > r-base-core cannot possibly be the cause. What we have here is that
|
| This bug was marked as fixed (IIRC by a boost version bump) by some
| version in (src:)r-base while it was reportted against another (source)
| package. As this prevents bug archival (the BTS considers the bug not
| yet fixed in the originally reported package), I reassigned the bug to
| make the BTS happy.
Ahhh -- perfect, and sorry about possibly having created that confusion from
the r-base side.
There ~is~ was still something [else] wrong because a package ~has~ had a
hickup with Boost on one arch which then bubbles up to a current autoremmove
for six or seven packages of mine. [Just checked: Looks like that is taken
care of too so all good!
Thanks again, and cheers from Italy during a brief vacation.
Dirk
|
| Andreas
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1037439: Unlikely to be a bug in r-base
Andreas,
This looks like an error:
> reassign 1037439 src:r-base
Bug #1037439 {Done: Dirk Eddelbuettel } [r-cran-rstan]
r-cran-rstan/armhf FTBFS with r-cran-bh 1.74, works with boost 1.81
Bug reassigned from package 'r-cran-rstan' to 'src:r-base'.
No longer marked as found in versions r-cran-rstan/2.21.8-1 and r-cran-bh.
r-base-core cannot possibly be the cause. What we have here is that
- R packages can use (C++ upstream library) Boost (from boost.org)
- (ie not be confused with a CRAN package called boost)
- I happen to be upstream for CRAN package BH
- Which I update annually in December, so CRAN is now at 1.81
- Because BH is big we once decided to _not_ double it up in Debian
- So we have r-cran-bh essentially as a virtual package depending on
libboost-all-dev
In June, we put a hard version constraint into r-cran-bh to enfore 1.81 or
later:
r-cran-bh (1.81.0-1) unstable; urgency=medium
* debian/control: Update Build-Depends to libboost1.81-dev to ensure use
of Boost 1.81 (needed eg by rstan) which is not yet the default Boost
in Debian, but available. Note to re-set this to libboost-dev once it
is default. Thanks to Steve Langasek for the idea. (Closes: #1037439)
* debian/control: Set Build-Depends: to current R version
* debian/control: Set Standards-Version: to current version
* debian/control: Switch to virtual debhelper-compat (= 12)
-- Dirk Eddelbuettel Tue, 13 Jun 2023 07:10:09 -0500
Steve may have suggsted that at the time for Ubuntu build issues. So is this
now in Debian unstable/testing? IIRC there was a migration.
Thanks for any pointer, Dirk
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1052655: gsl: CVE-2020-35357
Hi Salvatore, Looks like we emailed concurrently :) (or concurrently enough for my batched mail setup). On 26 September 2023 at 14:19, Salvatore Bonaccorso wrote: | Hi Dirk, | | On Tue, Sep 26, 2023 at 06:54:31AM -0500, Dirk Eddelbuettel wrote: | > | > On 25 September 2023 at 20:58, Salvatore Bonaccorso wrote: | > | Source: gsl | > | Version: 2.7.1+dfsg-5 | > | > | Severity: important | > | Tags: security upstream | > | Forwarded: https://savannah.gnu.org/bugs/?59624 | > | X-Debbugs-Cc: car...@debian.org, Debian Security Team | > | Control: found -1 2.6+dfsg-2 | > | | > | Hi, | > | | > | The following vulnerability was published for gsl. | > | | > | CVE-2020-35357[0]: | > | | A buffer overflow can occur when calculating the quantile value | > | | using the Statistics Library of GSL (GNU Scientific Library), | > | | versions 2.5 and 2.6. Processing a maliciously crafted input data | > | > | > I presume this is still true? Is the '2020' in the CVE for the year this is from? | | I did check the source and unless I did a mistake in checking then yes | the issue is unfixed up to 2.7.1+dfsg-5 yet, and [2] applies. I found (thanks to your diligent links) the better upstream fix that will be in 2.8 and used that. | > [ I see now at [0] that is spreads 2.6 and 2.7. Out of curiousity, who did | > the fix for buster (security) and when ? ] | | For buster: https://tracker.debian.org/news/1465169/accepted-gsl-25dfsg-6deb10u1-source-into-oldoldstable/ Ack. And that was only days ago so I wasn't asleep at the wheel here. | > | | for gsl_stats_quantile_from_sorted_data of the library may lead to | > | | unexpected application termination or arbitrary code execution. | > | | > | | > | If you fix the vulnerability please also make sure to include the | > | CVE (Common Vulnerabilities & Exposures) id in your changelog entry. | > | > I'll try. I think this is only the second CVE case in my nearly 30 years in Debian. | | Thanks. Note the issue does not really warrant a DSA, I had two goals Agreed. | with filling the bug: make you aware of the CVE assignment so the | issue can be fixed first in unstable and the fix land in trixie. For | bookworm and bullseye if you have spare cycles the fix might land in a | point release (there is one upcoming, but the window for uploads | closing the upcoming weekend). I am a bit on the fence as to whether it is needed but I suppose the change in -6 would apply 'as is'. | > So the debian/changelog entry needs to contain the string 'CVE-2020-35357' -- correct? | | Yes that is good. Perfect. I used that. Cheers, Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1052655: gsl: CVE-2020-35357
Fix made, built, uploaded and committed to the package's salsa repo. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1052655: gsl: CVE-2020-35357
On 25 September 2023 at 20:58, Salvatore Bonaccorso wrote: | Source: gsl | Version: 2.7.1+dfsg-5 | Severity: important | Tags: security upstream | Forwarded: https://savannah.gnu.org/bugs/?59624 | X-Debbugs-Cc: car...@debian.org, Debian Security Team | Control: found -1 2.6+dfsg-2 | | Hi, | | The following vulnerability was published for gsl. | | CVE-2020-35357[0]: | | A buffer overflow can occur when calculating the quantile value | | using the Statistics Library of GSL (GNU Scientific Library), | | versions 2.5 and 2.6. Processing a maliciously crafted input data I presume this is still true? Is the '2020' in the CVE for the year this is from? [ I see now at [0] that is spreads 2.6 and 2.7. Out of curiousity, who did the fix for buster (security) and when ? ] | | for gsl_stats_quantile_from_sorted_data of the library may lead to | | unexpected application termination or arbitrary code execution. | | | If you fix the vulnerability please also make sure to include the | CVE (Common Vulnerabilities & Exposures) id in your changelog entry. I'll try. I think this is only the second CVE case in my nearly 30 years in Debian. So the debian/changelog entry needs to contain the string 'CVE-2020-35357' -- correct? Dirk | For further information see: | | [0] https://security-tracker.debian.org/tracker/CVE-2020-35357 | https://www.cve.org/CVERecord?id=CVE-2020-35357 | [1] https://savannah.gnu.org/bugs/?59624 | [2] https://git.savannah.gnu.org/cgit/gsl.git/commit/?id=989a193268b963aa1047814f7f1402084fb7d859 | | Regards, | Salvatore -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1051901: 1.2.10 breaks ability to play audio using i386 binaries on amd64 host
Hi Antoine, Am Do, 14. Sep 2023 um 02:11:25 +0200 schrieb Antoine Le Gonidec: I think the problem might actually be related to trying to play sounds using any i386 binary (so the i386 libasound.so.2) on an amd64 host. I'd go so far to think that this is not constrained to i386 binaries on amd64 hosts. `aplay /dev/zero` segfaults on a plain i386 host with asound 1.2.10. Downgrading to 1.2.9 helps. ,[ dmesg ]- | [135665.812694] aplay[25480]: segfault at 10b ip b7efda1a sp bfd11860 error 4 in libasound.so.2.0.0[b7e8a000+a4000] likely on CPU 0 (core 0, socket 0) | [135665.812732] Code: 55 57 56 53 e8 17 f7 f8 ff 81 c3 7b 69 09 00 83 ec 0c 8b 6c 24 20 8b 74 24 24 8b 85 08 01 00 00 8b 50 20 85 d2 74 11 8b 40 1c <8b> 80 08 01 00 00 85 c0 0f 84 88 00 00 00 8d 7e 04 89 f1 31 c0 c7 ` Best regards, Dirk
Bug#1052291: ITP: r-cran-writexl -- GNU R package for export Excel xlsx format
Package: wnpp Owner: Dirk Eddelbuettel Severity: wishlist * Package name: r-cran-writexl Version : 1.4.2 Upstream Author : Jeroen Ooms * URL or Web page : https://cran.r-project.org/package=writexl * License : BSD-2 Description : GNU R package to write xlsx file This zero-dependency export helper package is now a dependency of package rio (aka r-cran-rio) which has been in Debian since May 2018. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1034356: gnome-shell: Frozen UI and massive log flodding
Am Samstag, dem 09.09.2023 um 23:38 +0100 schrieb Simon McVittie: > On Sun, 27 Aug 2023 at 10:56:20 +0200, H.-Dirk Schmitt wrote: > > Am Sonntag, dem 20.08.2023 um 12:17 +0100 schrieb Simon McVittie: > > > Please could you try installing the libgjs0g from here: > > > <https://people.debian.org/~smcv/12.2/pool/main/g/gjs/> > > > and then do whatever is necessary to reproduce the issue? > > > > I have installed the update on my machine and will distribute the > > update to other maintained machines. > > > > I don't know a simple reproduction of the problem. Sometimes it > > appears > > shortly after login – sometimes it take days. > > You've now been testing this for about 2 weeks. Have you seen this > bug's > symptoms again? No – no UI freeze has been occurred after update was installed. Also the log message hasn't appeared any more. Thanks, H.-Dirk Schmitt
Bug#1050955: rpy2: please make the build reproducible
On 31 August 2023 at 11:37, Chris Lamb wrote: | Source: rpy2 | Version: 3.5.13-5 | Severity: normal | Tags: patch | User: reproducible-bui...@lists.alioth.debian.org | Usertags: timestamps | X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org | | Hi, | | Whilst working on the Reproducible Builds effort [0], we noticed that | rpy2 could not be built reproducibly. | | This is because the testsuite generates a Rplots.pdf file which | contains a build timestamp. This file is then installed directly into | /usr/lib/python3/dist-packages — hence the increased severity of this | bug. | | Patch attached. Will do -- and really appreciate the patch! [ R tends to always use Rplots.pdf as a fallback when plot() (or alike) are called but not device can be opened. That can be on purpose -- testing / comparison happens on plots too -- but it can be accidental. In that wrapping in xvfb is good. ] I will wait a day or two as we tried hard to get rpy2 into testing. I added it already to debian/rules and debian/changelog. Dirk | [0] https://reproducible-builds.org/ | | | Regards, | | -- | ,''`. | : :' : Chris Lamb | `. `'` la...@debian.org / chris-lamb.co.uk |`- | x[DELETED ATTACHMENT rpy2.diff.txt, plain text] -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1050432: rpy2: FTBFS on mips64el
On 27 August 2023 at 18:44, YunQiang Su wrote: | Maybe there is something wrong with ffi. (In fact the complex support of mips | was added by me. ;) Hah. | I am looking for a way to use debug to debug the extensions. | If you have any documents, can you point it to me. I can help you with R, I think here the issue is more on the Python side. But to the best of my knowledge, the applications languages generally just call into the C library 'and assume things work'. But maybe here we need another compile-time / link-time option to turn ffi on? Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1034356: gnome-shell: Frozen UI and massive log flodding
Am Sonntag, dem 20.08.2023 um 12:17 +0100 schrieb Simon McVittie: > Control: tags -1 + moreinfo > > On Thu, 17 Aug 2023 at 09:58:42 +0100, Simon McVittie wrote: > > The key change in gjs seems to be the second commit of > > <https://gitlab.gnome.org/GNOME/gjs/-/merge_requests/832> so I'll > > try to > > build a package with that change for testing. > > Please could you try installing the libgjs0g from here: > <https://people.debian.org/~smcv/12.2/pool/main/g/gjs/> > and then do whatever is necessary to reproduce the issue? I have installed the update on my machine and will distribute the update to other maintained machines. I don't know a simple reproduction of the problem. Sometimes it appears shortly after login – sometimes it take days. Best regards and thanks, H.-Dirk Schmitt
Bug#1050432: rpy2: FTBFS on mips64el
On 27 August 2023 at 14:09, YunQiang Su wrote: | Dirk Eddelbuettel 于2023年8月27日周日 00:15写道： | > | > | > Hi all, | > | > As the test failures for complex valued variables appeared to be systemic on | > the 'mips64el' platform, I buckled down, taught myself some Python ==:-) and | > conditioned the number of failing tests away via | > | > @pytest.mark.skipif(platform.machine() == 'mips64' and sys.byteorder == 'little', | > reason="Complex tests fails for 'mips64el'.") | > | > Maybe the porters team can shed some light on why we needed it, and if this | > worked (the autobuilders will tell us soon enough) I can pass the patch on to | > Laurent for a possible inclusion upstream. | > | | Sorry for the late reply. I can work on it. Appreciate that! (While my fix corrected the build, it is a stop-gap as it avoids the issue. A real fix would be good.) | Do you knwo any way to run a single testcase? Can you start from the unit tests I conditioned out? Each of those has simple expression with a complex in it. Those should be executable directly in the Python interpreter. You probably need all the build-deps (python, R, rpy2, numpy, ...) installed. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1050432: rpy2: FTBFS on mips64el
Hi all, As the test failures for complex valued variables appeared to be systemic on the 'mips64el' platform, I buckled down, taught myself some Python ==:-) and conditioned the number of failing tests away via @pytest.mark.skipif(platform.machine() == 'mips64' and sys.byteorder == 'little', reason="Complex tests fails for 'mips64el'.") Maybe the porters team can shed some light on why we needed it, and if this worked (the autobuilders will tell us soon enough) I can pass the patch on to Laurent for a possible inclusion upstream. Cheers, Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1050432: rpy2: FTBFS on mips64el
Paul, Thanks for the hint. I was aware and had been meaning to bring this up with Laurent (upstream, now CCed). Laurent: I should have access to a 'porterbox' running mips64el if you have an idea about what may be going on here / have a branch to test. Paul: While I have you here, and as all those failures are on _complex_, is there a known issue with mips64el or a specific compiler switch that may be needed? rpy2 is fairly widely used but also 'glue' around other Python libraries, are any others affected? Dirk On 24 August 2023 at 16:59, Paul Gevers wrote: | Source: rpy2 | Version: 3.5.13-1 | Severity: serious | Tags: ftbfs | Justification: FTBFS | | Dear maintainer, | | Since the upload version 3.5.13-1, rpy2 has been failing to build on | mips64el, which is blocking migration to testing. | | https://buildd.debian.org/status/logs.php?pkg=rpy2=mips64el | | === short test summary info | FAILED rpy2/tests/rinterface/test_na.py::test_R_to_NAComplex - assert False | FAILED rpy2/tests/rinterface/test_vector_complex.py::test_init_from_seqr - as... | FAILED rpy2/tests/rinterface/test_vector_complex.py::test_getitem - assert (-... | FAILED rpy2/tests/rinterface/test_vector_complex.py::test_setitem - assert (-... | FAILED rpy2/tests/rinterface/test_vector_complex.py::test_getslice - assert (... | FAILED rpy2/tests/rinterface/test_vector_complex.py::test_getslice_negative | FAILED rpy2/tests/rinterface/test_vector_complex.py::test_setslice - assert (... | FAILED rpy2/tests/rinterface/test_vector_complex.py::test_setslice_negative | FAILED rpy2/tests/rinterface/test_vector_complex.py::test_index - ValueError:... | FAILED rpy2/tests/robjects/test_conversion_numpy.py::TestNumpyConversions::test_vector_complex | | Paul | | -- System Information: Debian Release: trixie/sid APT prefers testing | APT policy: (990, 'testing') Architecture: amd64 (x86_64) | | Kernel: Linux 6.4.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) | Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en | Shell: /bin/sh linked to /usr/bin/dash | Init: systemd (via /run/systemd/system) | LSM: AppArmor: enabled -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1049438: r-cran-rgdal: autopkgtest needs update for new version of r-cran-sp
On 18 August 2023 at 13:58, Andreas Tille wrote:
| Control: tags -1 upstream
| Control: forwarded -1 Roger Bivand
|
| Hi Roger,
|
| the CI tests in Debian uncovered some conflict between recent rgdal and
| version 2.0 of sp. As you either can see in the bug report that was
| filed[1] or in a recent CI build log[2] it fails with
|
| In CRS("+init=epsg:4326") :> sp.tr <- spTransform(sp, CRS("+init=epsg:3857"))
| sf required for evolution_status==2L
| Error in spTransform(sp, CRS("+init=epsg:3857")) :
| source crs creation failed: Invalid PROJ string syntax
| Calls: spTransform -> spTransform
|
| It would be great if you could adapt rgdal to the latest version of sp.
Possibly related to a *planned* and *announced* phaseout.
See the DESCRIPTION file entry Description upstream
[...] Please note that 'rgdal' will be retired during October 2023,
plan transition to sf/stars/'terra' functions using 'GDAL' and 'PROJ'
at your earliest convenience (see
<https://r-spatial.org/r/2023/05/15/evolution4.html> and earlier blogs
for guidance).
Erlier posts are
https://r-spatial.org/r/2022/04/12/evolution.html
https://r-spatial.org/r/2022/12/14/evolution2.html
https://r-spatial.org/r/2023/04/10/evolution3.html
This is exemplary for guidance from an upstream project.
Dirk
|
| Kind regards
| Andreas.
|
|
| [1] https://bugs.debian.org/1049438
| [2] https://salsa.debian.org/r-pkg-team/r-cran-rgdal/-/jobs/4562837#L790
|
| --
| http://fam-tille.de
|
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
