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#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#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#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-file=/dev/null --srcdir=. | checking
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#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#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#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#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#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
On 28 October 2023 at 22:53, Sebastian Ramacher wrote: | Source: quantlib-swig | Version: 1.32-1 | Severity: serious | Tags: ftbfs | Justification: fails to build from source (but built successfully in the past) | X-Debbugs-Cc: sramac...@debian.org | | https://buildd.debian.org/status/fetch.php?pkg=quantlib-swig=mips64el=1.32-1=1698321785=0 | | 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' | build/temp.linux-mips64-cpython-311/QuantLib/quantlib_wrap.o: in function `non-virtual thunk to QuantLib::HimalayaOption::results::~results()': | quantlib_wrap.cpp:(.text._ZN8QuantLib14HimalayaOption7resultsD1Ev[_ZN8QuantLib14HimalayaOption7resultsD1Ev]+0xf0): relocation truncated to fit: R_MIPS_GOT_PAGE against `.text._ZN8QuantLib14HimalayaOption7resultsD1Ev' | build/temp.linux-mips64-cpython-311/QuantLib/quantlib_wrap.o: in function `virtual thunk to QuantLib::HimalayaOption::results::~results()': | quantlib_wrap.cpp:(.text._ZN8QuantLib14HimalayaOption7resultsD1Ev[_ZN8QuantLib14HimalayaOption7resultsD1Ev]+0x118): relocation truncated to fit: R_MIPS_GOT_PAGE against `.text._ZN8QuantLib14HimalayaOption7resultsD1Ev' | build/temp.linux-mips64-cpython-311/QuantLib/quantlib_wrap.o: in function `non-virtual thunk to QuantLib::HimalayaOption::results::~results()': | quantlib_wrap.cpp:(.text._ZN8QuantLib14HimalayaOption7resultsD0Ev[_ZN8QuantLib14HimalayaOption7resultsD0Ev]+0x8c): relocation truncated to fit: R_MIPS_GOT_PAGE against `.text._ZN8QuantLib14HimalayaOption7resultsD0Ev' | build/temp.linux-mips64-cpython-311/QuantLib/quantlib_wrap.o: in function `virtual thunk to QuantLib::HimalayaOption::results::~results()': | quantlib_wrap.cpp:(.text._ZN8QuantLib14HimalayaOption7resultsD0Ev[_ZN8QuantLib14HimalayaOption7resultsD0Ev]+0xb4): relocation truncated to fit: R_MIPS_GOT_PAGE against `.text._ZN8QuantLib14HimalayaOption7resultsD0Ev' | build/temp.linux-mips64-cpython-311/QuantLib/quantlib_wrap.o: in function `non-virtual thunk to QuantLib::GenericEngine::~GenericEngine()': | quantlib_wrap.cpp:(.text._ZN8QuantLib13GenericEngineINS_14HimalayaOption9argumentsENS1_7resultsEED2Ev[_ZN8QuantLib13GenericEngineINS_14HimalayaOption9argumentsENS1_7resultsEED5Ev]+0x110): relocation truncated to fit: R_MIPS_GOT_PAGE against `.text._ZN8QuantLib13GenericEngineINS_14HimalayaOption9argumentsENS1_7resultsEED2Ev' | build/temp.linux-mips64-cpython-311/QuantLib/quantlib_wrap.o: in function `non-virtual thunk to QuantLib::GenericEngine::~GenericEngine()': | quantlib_wrap.cpp:(.text._ZN8QuantLib13GenericEngineINS_14HimalayaOption9argumentsENS1_7resultsEED0Ev[_ZN8QuantLib13GenericEngineINS_14HimalayaOption9argumentsENS1_7resultsEED5Ev]+0x8c): relocation truncated to fit: R_MIPS_GOT_PAGE against `.text._ZN8QuantLib13GenericEngineINS_14HimalayaOption9argumentsENS1_7resultsEED0Ev' | build/temp.linux-mips64-cpython-311/QuantLib/quantlib_wrap.o: in function `non-virtual thunk to QuantLib::HimalayaOption::engine::~engine()': | quantlib_wrap.cpp:(.text._ZN8QuantLib14HimalayaOption6engineD2Ev[_ZN8QuantLib14HimalayaOption6engineD5Ev]+0xa4): relocation truncated to fit: R_MIPS_GOT_PAGE against `.text._ZN8QuantLib14HimalayaOption6engineD2Ev' | build/temp.linux-mips64-cpython-311/QuantLib/quantlib_wrap.o: in function `non-virtual thunk to QuantLib::HimalayaOption::engine::~engine()': | quantlib_wrap.cpp:(.text._ZN8QuantLib14HimalayaOption6engineD0Ev[_ZN8QuantLib14HimalayaOption6engineD5Ev]+0x8c): relocation truncated to fit: R_MIPS_GOT_PAGE against `.text._ZN8QuantLib14HimalayaOption6engineD0Ev' | build/temp.linux-mips64-cpython-311/QuantLib/quantlib_wrap.o: in function `virtual thunk to QuantLib::CliquetOption::arguments::~arguments()': | quantlib_wrap.cpp:(.text._ZN8QuantLib13CliquetOption9argumentsD1Ev[_ZN8QuantLib13CliquetOption9argumentsD1Ev]+0x104): relocation truncated to fit: R_MIPS_GOT_PAGE against `.text._ZN8QuantLib13CliquetOption9argumentsD1Ev' | build/temp.linux-mips64-cpython-311/QuantLib/quantlib_wrap.o: in function `non-virtual thunk to QuantLib::GenericEngine::~GenericEngine()': | quantlib_wrap.cpp:(.text._ZN8QuantLib13GenericEngineINS_13CliquetOption9argumentsENS_14OneAssetOption7resultsEED2Ev[_ZN8QuantLib13GenericEngineINS_13CliquetOption9argumentsENS_14OneAssetOption7resultsEED5Ev]+0x110): additional relocation overflows omitted from the
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#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#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#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
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
Bug#1041556: What is the architecture name in R what we call armel/armhf
On 17 August 2023 at 07:24, Graham Inggs wrote: | On Thu, 17 Aug 2023 at 05:52, Andreas Tille wrote: | > I tried to skip two tests in r-cran-checkmate with this patch[1] | > which is based on | > | > arch <- R.version$arch | > identical(arch, "i386") || identical(arch, "i686") || identical(arch, "armel") || identical(arch, "armhf") | | Stack Overflow suggested to check .Machine$sizeof.pointer | which will return the pointer size in bytes, | so 8 on 64-bit and 4 on 32-bit architectures. Seconded to detect 'word size'. Closest to an R-provided 'is it 32bit' ? The failed logs for armhf and armel also clearly show that the value from R.version$arch is 'arm', see https://ci.debian.net/data/autopkgtest/testing/armel/r/r-cran-checkmate/36601942/log.gz and its displayed text: 68s R version 4.3.1 (2023-06-16) -- "Beagle Scouts" 68s Copyright (C) 2023 The R Foundation for Statistical Computing 68s Platform: arm-unknown-linux-gnueabi (32-bit) ^^^ That is the value returned from R.version$arch. 'arm', not 'armel' or 'armhf'. For completeness, the armhf run https://ci.debian.net/data/autopkgtest/testing/armhf/r/r-cran-checkmate/36588004/log.gz has 56s R version 4.3.1 (2023-06-16) -- "Beagle Scouts" 56s Copyright (C) 2023 The R Foundation for Statistical Computing 56s Platform: arm-unknown-linux-gnueabihf (32-bit) R.version$platform has the full triplet, ie 'x86_64-pc-linux-gnu' for me here. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1044299: ggobi: Fails to build source after successful build
On 13 August 2023 at 18:56, Lucas Nussbaum wrote:
| Source: ggobi
| Version: 2.1.11-2
| Severity: minor
| Tags: trixie sid ftbfs
| User: lu...@debian.org
| Usertags: ftbfs-sab-20230813 ftbfs-source-after-build
| User: debian...@lists.debian.org
| Usertags: qa-doublebuild
|
| Hi,
|
| This package fails to build a source package after a successful build
| (dpkg-buildpackage ; dpkg-buildpackage -S).
|
| This is probably a clear violation of Debian Policy section 4.9 (clean
target),
| but this is filed as severity:minor for now, because a discussion on
| debian-devel showed that we might want to revisit the requirement of a working
| 'clean' target.
It may be time to retire the package. Upstream is pretty much dead, research
work in the area move 'to the browser' as opposed to cross-platform GUI
binaries with all their challengess.
I have to think this over. Removal may be best.
Dirk
| More information about this class of issues, included common problems and
| solutions, is available at
| https://wiki.debian.org/qa.debian.org/FTBFS/SourceAfterBuild
|
| Relevant part of the build log:
| > cd /<> && runuser -u user42 -- dpkg-buildpackage
--sanitize-env -us -uc -rfakeroot -S
| >
--
| >
| > dpkg-buildpackage: info: source package ggobi
| > dpkg-buildpackage: info: source version 2.1.11-2
| > dpkg-buildpackage: info: source distribution unstable
| > dpkg-buildpackage: info: source changed by Dirk Eddelbuettel
| > dpkg-source --before-build .
| > fakeroot debian/rules clean
| > dh_testdir
| > dh_testroot
| > dh_autoreconf_clean
| > rm -f build-stamp configure-stamp install-stamp
| > [ ! -f Makefile ] || /usr/bin/make distclean
| > make[1]: Entering directory '/<>'
| > CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/bash
'/<>/config/missing' aclocal-1.16
| > /bin/bash: /<>/config/missing: No such file or directory
| > make[1]: *** [Makefile:500: aclocal.m4] Error 127
| > make[1]: Leaving directory '/<>'
| > make: *** [debian/rules:82: clean1] Error 2
| > dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned
exit status 2
| >
| > E: Command 'cd /<> && runuser -u user42 -- dpkg-buildpackage
--sanitize-env -us -uc -rfakeroot -S' failed to run.
|
|
| The full build log is available from:
| http://qa-logs.debian.net/2023/08/13/ggobi_2.1.11-2_unstable.log
|
| If you reassign this bug to another package, please mark it as 'affects'-ing
| this package. See https://www.debian.org/Bugs/server-control#affects
|
| If you fail to reproduce this, please provide a build log and diff it with
mine
| so that we can identify if something relevant changed in the meantime.
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1028111: r-cran-clock: autopkgtest failure on 32bit
The 'bug fix' applied to the _previous_ version of CRAN package clock, namely
a somewhat 'wild' sed patching of a single ie
# Ignore single test for i386 architecture. This is a workaround for bug
#1024828 of r-cran-igraph
if [ "$hostarch" = "i386" -o "$hostarch" = "armel" -o "$hostarch" = "armhf" ] ;
then
sed -i -e '152d' -e '151d' testthat/test-posixt.R
fi
now creates a syntax error on these very architectures (as the upstream file
presumably changed). Here is the corresponding part of one of the logs
(armel at
https://ci.debian.net/data/autopkgtest/testing/armel/r/r-cran-clock/36601943/log.gz)
80s > library(testthat)
80s > library(clock)
80s >
80s > test_check("clock")
132s Error in parse(con, n = -1, srcfile = srcfile, encoding = "UTF-8") :
132s test-posixt.R:1372:0: unexpected end of input
132s 1370: })
132s 1371: })
132s ^
132s Calls: test_check ... doTryCatch -> lapply -> FUN -> source_file -> parse
132s Execution halted
133s autopkgtest [08:19:23]: test run-unit-test: ---]
133s autopkgtest [08:19:23]: test run-unit-test: - - - - - - - - - - results -
- - - - - - - - -
133s run-unit-testFAIL non-zero exit status 1
Obviously if we ambush upstream code and corrupt then tests we impose will
fail.
This has fairly large repurcussions across other packages include some of mine.
If nobody else steps up I plan to address this by no longer 'hot-fix
patching' (and thereby corrupting) test-posixt.R but (at least for now)
simply skipping tests of test-posixt.t. The regular maintainers may find
time to investigate what parts of the test file work for armel, armhf, i386.
Dirk
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1042889: vm breakage with Emacs 29
On 2 August 2023 at 14:41, Ian Jackson wrote:
| Dirk Eddelbuettel writes ("Re: vm breakage with Emacs 29"):
| > On 2 August 2023 at 13:17, Ian Jackson wrote:
| > | Hi. Since you were helpful with #1039105 "Fails to start with Emacs
| > | 28" I thought I would draw your attention to #1042889
| > | "vm: autopkgtest fails against Emacs 29.1" [0]
| > |
| > | I won't have time to look at this until next week, probably. Any help
| > | or background research would be greatly appreciated. We need to fix
| > | this to avoid vm getting autoremoved.
| > |
| > | I did have a quick look at the test log [1] and the failure looks
| > | genuine. I suggest we do any further diagnosis in the bug.
| >
| > The band-aid I found and submitted for #1039105 (ie per Fedora's tracker,
| > "just do not byte compile") seems apt here, no? I still do not really read
| > (or, for that matter, write) elisp but it seems to complain about byte code.
| >
| > So I would try two things:
| > - turn off elisp byte compilation as in #1039105
|
| The patch from #1039105 is still in the package.
Ok.
| Do we need to add to a list of files in it, or something, do you
That was my hunch.
| think ? Maybe it would be best to disable byte compilation
| completely.
Yes given the previous bug report and fix ensuring no byte-compilation takes
place for vm may be best. At least until someone (upstream? another dev?)
understand why it breaks vm.
Dirk
|
| One thing that would be useful would be for someone to try out emacs
| and vm in a sid chroot; that would confirm that this isn't a spurious
| test failure (or confirm that it is).
|
| Thanks,
| Ian.
|
| --
| Ian JacksonThese opinions are my own.
|
| Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
| that is a private address which bypasses my fierce spamfilter.
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1038405: Bug#1037439: r-cran-rstan/armhf FTBFS with r-cran-bh 1.74
On 31 July 2023 at 23:13, Adrian Bunk wrote: | On Mon, Jun 19, 2023 at 04:37:22PM +0300, Adrian Bunk wrote: | > On Tue, Jun 13, 2023 at 03:30:18PM -0500, Dirk Eddelbuettel wrote: | > > | > > On 13 June 2023 at 13:15, Steve Langasek wrote: | > > | Control: reassign -1 r-cran-rstan r-cran-bh | > > | Control: found -1 r-cran-rstan/2.21.8-1 | > > | | > > | Unfortunately, at least in Ubuntu it appears the r-cran-rstan build still | > > | exhausts the 32-bit memory space even with boost 1.81. | > > | | > > | https://launchpad.net/ubuntu/+source/r-cran-rstan/2.21.8-1/+build/26010118 | > > | > > :-/ | > > | > > Not sure that it is fair to point at BH / Boost though. Anyway. | > > | > > CRAN no longer checks / compiles 32 bit so upstream may not care, but they | > > are a good team (if busy). You could ping Ben, he is at | > >Benjamin K Goodrich | > >... | > | > The patch below to r-base fixes the build of r-cran-rstan/i386 for me. | > | > This will reduce debug info in the R ecosystem on 32bit to what is | > required for backtraces, but I assume realistically R on 32bit is | > anyway only sparsely used these days. | > | > > Dirk | > | > cu | > Adrian | > | > --- debian/rules.old2023-06-18 19:45:14.437261923 + | > +++ debian/rules2023-06-18 19:51:30.097179612 + | > @@ -90,6 +90,11 @@ | > export DEB_CFLAGS_MAINT_APPEND = -ffloat-store | > endif | > | > +## fewer debug info on 32bit to workaround 2-4 GB address space limitation | > +ifeq ($(DEB_HOST_ARCH_BITS), 32) | > +export DEB_CFLAGS_MAINT_APPEND += -g1 | > +endif | > + | >... | | These two entries ended up in the opposite order in the upload, and the | -ffloat-store one did not have a += making the -g1 change a nop on i386. | | Please apply also the patch below. | | cu | Adrian | | --- debian/rules.old 2023-07-26 07:56:06.872438302 + | +++ debian/rules 2023-07-26 07:56:27.340457680 + | @@ -92,7 +92,7 @@ | | ## Adrian Bunk 20 Jan 2023 workaround excess precision of x87 | ifneq (,$(filter $(DEB_HOST_ARCH), i386)) | -export DEB_CFLAGS_MAINT_APPEND = -ffloat-store | +export DEB_CFLAGS_MAINT_APPEND += -ffloat-store | endif | | ## edd 31 Mar 2014 Flim! Thanks for catching that, that's what I get for manually patching. Will fix now. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1042040: quantlib-swig: FTBFS: QuantLib/quantlib_wrap.cpp:9493:19: error: ‘LexicographicalView’ in namespace ‘QuantLib’ does not name a template type
On 25 July 2023 at 23:05, Lucas Nussbaum wrote:
| Source: quantlib-swig
| Version: 1.30-2
| Severity: serious
| Justification: FTBFS
| Tags: trixie sid ftbfs
|
| Hi,
|
| During a rebuild of all packages in sid, your package failed to build
| on amd64.
I'll get on this -- it is lagging behind the quantlib package and these
usually go in sync. 1.31, and then 1.31.1, came out last week.
I will make sure quantlib-swig catches up, that will make the error go away.
Thanks, Dirk
|
| Relevant part (hopefully):
| > g++ -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g
-fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -O0
-g0 -Wall -Wno-strict-aliasing -DBOOST_NO_AUTO_PTR -Wdate-time
-D_FORTIFY_SOURCE=2 -fPIC -DNDEBUG -I/usr/include/python3.11 -I/usr/include -c
QuantLib/quantlib_wrap.cpp -o
build/temp.linux-x86_64-3.11/QuantLib/quantlib_wrap.o -fopenmp -Wno-unused -O0
-g0 -Wall -Wno-strict-aliasing -DBOOST_NO_AUTO_PTR
| > QuantLib/quantlib_wrap.cpp:9493:19: error: ‘LexicographicalView’ in
namespace ‘QuantLib’ does not name a template type
| > 9493 | typedef QuantLib::LexicographicalView
| > | ^~~
| > QuantLib/quantlib_wrap.cpp:9495:19: error: ‘LexicographicalView’ in
namespace ‘QuantLib’ does not name a template type
| > 9495 | typedef QuantLib::LexicographicalView::y_iterator
| > | ^~~
| > QuantLib/quantlib_wrap.cpp:9498:62: error:
‘DefaultLexicographicalViewColumn’ was not declared in this scope; did you mean
‘SWIGTYPE_p_DefaultLexicographicalViewColumn’?
| > 9498 | SWIGINTERN Real
DefaultLexicographicalViewColumn___getitem__(DefaultLexicographicalViewColumn
*self,Size i){
| > |
^~~~
| > |
SWIGTYPE_p_DefaultLexicographicalViewColumn
| > QuantLib/quantlib_wrap.cpp:9498:96: error: ‘self’ was not declared in this
scope
| > 9498 | SWIGINTERN Real
DefaultLexicographicalViewColumn___getitem__(DefaultLexicographicalViewColumn
*self,Size i){
| > |
^~~~
| > QuantLib/quantlib_wrap.cpp:9498:106: error: expected primary-expression
before ‘i’
| > 9498 | SWIGINTERN Real
DefaultLexicographicalViewColumn___getitem__(DefaultLexicographicalViewColumn
*self,Size i){
| > |
^
| > QuantLib/quantlib_wrap.cpp:9498:107: error: expression list treated as
compound expression in initializer [-fpermissive]
| > 9498 | SWIGINTERN Real
DefaultLexicographicalViewColumn___getitem__(DefaultLexicographicalViewColumn
*self,Size i){
| > |
^
| > QuantLib/quantlib_wrap.cpp:9501:17: error: variable or field
‘DefaultLexicographicalViewColumn___setitem__’ declared void
| > 9501 | SWIGINTERN void
DefaultLexicographicalViewColumn___setitem__(DefaultLexicographicalViewColumn
*self,Size i,Real x){
| > | ^~~~
| > QuantLib/quantlib_wrap.cpp:9501:62: error:
‘DefaultLexicographicalViewColumn’ was not declared in this scope; did you mean
‘SWIGTYPE_p_DefaultLexicographicalViewColumn’?
| > 9501 | SWIGINTERN void
DefaultLexicographicalViewColumn___setitem__(DefaultLexicographicalViewColumn
*self,Size i,Real x){
| > |
^~~~
| > |
SWIGTYPE_p_DefaultLexicographicalViewColumn
| > QuantLib/quantlib_wrap.cpp:9501:96: error: ‘self’ was not declared in this
scope
| > 9501 | SWIGINTERN void
DefaultLexicographicalViewColumn___setitem__(DefaultLexicographicalViewColumn
*self,Size i,Real x){
| > |
^~~~
| > QuantLib/quantlib_wrap.cpp:9501:106: error: expected primary-expression
before ‘i’
| > 9501 | SWIGINTERN void
DefaultLexicographicalViewColumn___setitem__(DefaultLexicographicalViewColumn
*self,Size i,Real x){
| > |
^
| > QuantLib/quantlib_wrap.cpp:9501:113: error: expected primary-expression
before ‘x’
| > 9501 | SWIGINTERN void
DefaultLexicographicalViewColumn___setitem__(DefaultLexicographicalViewColumn
*self,Size i,Real x){
| > |
^
| > QuantLib/quantlib_wrap.cpp:9504:12: error: ‘DefaultLexicographicalView’
does not name a type; did you mean ‘SWIGTYPE_p_DefaultLexicographicalView’?
| >
Bug#1041835: gretl: installs empty directory /usr/lib/pkgconfig
On 24 July 2023 at 06:47, Helmut Grohne wrote: | Source: gretl | Version: 2023b-1 | Severity: important | Tags: patch | | gretl contains an empty directory /usr/lib/pkgconfig. Due to having | implemented the /usr-merge using directory aliasing, this directory is | prone to loss. Are we sure this is 'important'? | Looking into gretl, it becomes evident that this directory is not | needed. It is an artifact of splitting files to different binary | packages. As such, the directory can be deleted without loss of | functionality. What does not exist, cannot be lost, problem solved. I'm | attaching a patch for your convenience. edd@rob:/var/cache/pbuilder/result$ for f in *2023b*deb; do echo $f; dpkg -c $f | grep config; done gretl_2023b-1_amd64.deb drwxr-xr-x root/root 0 2023-07-23 09:34 ./usr/lib/pkgconfig/ gretl-common_2023b-1_all.deb gretl-data_2023b-1_all.deb gretl-dbgsym_2023b-1_amd64.deb gretl-doc_2023b-1_all.deb libgretl1_2023b-1_amd64.deb libgretl1-dbgsym_2023b-1_amd64.deb libgretl1-dev_2023b-1_amd64.deb drwxr-xr-x root/root 0 2023-07-23 09:34 ./usr/lib/pkgconfig/ -rw-r--r-- root/root 317 2023-07-23 09:34 ./usr/lib/pkgconfig/gretl.pc edd@rob:/var/cache/pbuilder/result$ Looks like it is alive and well in libgretl1-dev where it should be. But I agree with the 'find and rmdir'. Per 'git blame' we had the lintian override since 2007 (!!) but yes, with the /usr rearrangement it may make sense to clean this up. Dirk | Helmut | x[DELETED ATTACHMENT gretl_2023b-1.1.debdiff, plain text] -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1041738: src:lme4: fails to migrate to testing for too long: causes timeout in autopkgtests on i386
On 23 July 2023 at 11:03, Dirk Eddelbuettel wrote: | Note that the mlmRev authors / maintainers are the same as / a subset of the | lme4 authors. They may have an idea. | | https://cran.r-project.org/package=mlmRev I just ran `R CMD check mlmRev_*tar.gz` on my amd64 (under Ubuntu 23.04), it ran fine but also took a moment. In parallel I am also running it in a i386 Docker container for Debian unstable and that seems slow esp on the second file tests/lmerTest.R So if it were me I'd just skip that test file on i386 and move on. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1041738: src:lme4: fails to migrate to testing for too long: causes timeout in autopkgtests on i386
On 23 July 2023 at 15:07, Graham Inggs wrote: | Hi | | On Sun, 23 Jul 2023 at 13:11, Nilesh Patra wrote: | > How do you conclude that? | > The versions of affected packages are same in unstable and testing. They | > fail in i386 with a newer version of lme4. | | For what it's worth, r-cran-afex[1] and r-cran-mertools[2] **are** | passing in unstable. Ah. So maybe I did look at that... | So perhaps whatever package fixed this condition has been uploaded, but not | yet migrated. | | Yet r-cran-mlmrev[3] still seems to have the timeout issue in unstable. Note that the mlmRev authors / maintainers are the same as / a subset of the lme4 authors. They may have an idea. https://cran.r-project.org/package=mlmRev Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1041738: src:lme4: fails to migrate to testing for too long: causes timeout in autopkgtests on i386
On 23 July 2023 at 18:42, Nilesh Patra wrote: | On Sun, 23 Jul 2023 07:15:09 -0500 Dirk Eddelbuettel wrote | > Is this is not an example of a release manager override? The affectect | > packages all work together in unstable and could migrate. | | How do you conclude that? | The versions of affected packages are same in unstable and testing. They | fail in i386 with a newer version of lme4. Sorry, my fault. I was wrong here so thanks for the correction. I looked at the bottom of one of those logs, saw a PASS and missed the FAIL preceding it. Still, it is a self-imposed problem by Debian. At some point we managed to let go of m68k too. But if you all think we are better auto-removing lme4 over i386 fails _of packages using it_ as opposed to fails in itself then I cannot stop you. That does not mean I concur with the decision. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1041738: src:lme4: fails to migrate to testing for too long: causes timeout in autopkgtests on i386
Paul, Is this is not an example of a release manager override? The affectect packages all work together in unstable and could migrate. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1041738: src:lme4: fails to migrate to testing for too long: causes timeout in autopkgtests on i386
On 22 July 2023 at 21:45, Paul Gevers wrote: | Source: lme4 | Version: 1.1-31-1 | Severity: serious | Control: close -1 1.1-34-1 | X-Debbugs-CC: debia...@lists.debian.org | 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:lme4 has been trying to migrate for 32 | days [2]. Hence, I am filing this bug. | | The version in unstable causes 3 autopkgtest failures when tested in | testing, all on i386. The failures are due to autopkgtest timeout after | 2:47 h, while normally these tests run in minutes, so this suggests the | tests hang. In unstable, r-cran-afex and r-cran-mertools pass (so this | is probably a (set of) package(s) in unstable that also needs to migrate | together with lme4), but r-cran-mlmrev also times out in unstable. | | 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. The lme4 package is in fine standing at CRAN https://cloud.r-project.org/web/checks/check_results_lme4.html and build everywhere on Debian (see this and other links) https://cloud.r-project.org/web/checks/check_results_lme4.html If three other packages (that I have nothing to do with) fail in _their autopkgtests_ may I suggest you talk to the maintainers of _those packages_? lme4 is _core_ package, written and maintained by current and former R Core members. It is one of the most widely used and watched packages around. This is most likely an issue of shooting the messenger as the root cause with be with those other packages. It could be an issue as simple as CRAN (and upstream) no longer checking on i386 though it usually does not fail there. Dirk | Paul | | [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html | [2] https://qa.debian.org/excuses.php?package=lme4 | x[DELETED ATTACHMENT OpenPGP_signature, application/pgp-signature] -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)
Graham, On 13 July 2023 at 18:59, Graham Inggs wrote: | I believe the attached patch should do the trick. It's basically | Paul's list from message #210, plus r-cran-interval and | r-cran-maldiquant. I've also used a << relationship against the | versions in unstable, and appended a tilde at the end. I believe this | will work better for derivatives and make backports easier. Almost done building, will upload shortly. Thanks, Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)
Hi Graham, On 13 July 2023 at 11:14, Graham Inggs wrote: | On Wed, 12 Jul 2023 at 19:07, Dirk Eddelbuettel wrote: | > On 12 July 2023 at 19:47, Paul Gevers wrote: | > | Yes, you only need to carry the Breaks until in the next release. So | > | every Breaks that's present in the r-base package in bookworm can be | > | removed from the r-base package in unstable. | > | > Good point and much less ugly then :) | | I'll prepare a patch dropping the old and adding the new Breaks. Sounds good, and thanks for the assist! I should be able to provide a pretty quick turn-around. Onwards! Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)
Hi Paul, On 12 July 2023 at 19:47, Paul Gevers wrote: | On 12-07-2023 16:02, Dirk Eddelbuettel wrote: | > I can add the Breaks as a 'best of the worse alternative'. And, I presume, I | > can remove the existing four-year breaks? [1] | | Yes, you only need to carry the Breaks until in the next release. So | every Breaks that's present in the r-base package in bookworm can be | removed from the r-base package in unstable. Good point and much less ugly then :) Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)
Hi Paul, On 11 July 2023 at 20:36, Paul Gevers wrote: | On 11-07-2023 02:43, Dirk Eddelbuettel wrote: | I'm totally on board for technical excellence, although I think we have | different things in mind when we say that. | | In Debian, with more QA than we ever had before, we're finding a class | of issues that often went unnoticed years ago. One of these things is Of course I am not against testing auto-upgrades. I imagine nobody is. What I am not happy about is that we fell into a hole we would not need to be in, ideally. Please hear me out on this: - R has an annual release cycle at the end of April - During that cycle the 'next' release (in VCS) is referred to as r-devel. - CRAN checks all packages at all uploads, as well as periodically, against r-devel. - When a change is needed because something would break once r-devel becomes 'r-release' they contact the package author and request the change, this is a hard requirement and non-compliant package are thrown off CRAN. No - breakage allowed! - What I showed with maldiquant was that its upstream made the change in March still well before the R 4.3.0 release requiring it - So we could have (we had the freeze, more below) had the package which would have passed both 'r-release' then and 'r-devel then' (which is 'r-release now') and everything would pass. Even under our tests. That is an ideal I would really like us to move towards with the CRAN packages in Debian. As CRAN makes it so easy for us to 'always build / build @HEAD' we really should take the fullest advantage of it. So I typically roll up my packages the day or week of a CRAN change. (And maintain 2 x 21k binaries off CRAN in r2u, but that is a different story.) As it happens, not everybody does, sometimes we have freezes, and other things happen. Also the number of CRAN packages increases of course and the net-net of that is that we then have to spend precious manual time picking up the pieces. Clearly not ideal, but better than having installation bugs. | that partial upgrades can leave you in a bad state. So more and more we | see that packages "have to" add Breaks to tell apt that when you want to | upgrade package X, you also have to upgrade package Y if you happen to | have that installed. As package Y can not tell that, package X has to | add the Breaks on the broken version of Y. As an example, see the list | of Breaks in libc6 [1]. While partial upgrades aren't officially Thanks for that. An impressively long list! | supported, we rely on them nevertheless (even if only for QA (piuparts, | autopkgtest)), and as a Release Team member I consider that class of | fixes technical excellence: ensuring as best as we can that the user | that upgrades a package keeps a working system. Yes. | While a rebuild of everything combined with bumping the "api" would | achieve that, I'm much more in favor of targeted Breaks, like we have | been discussing here. It's typically more work, but it's more correct. Fully agreed. | For the future, with the recent change in dh-r, r-base will be much less | impacted by this "problem" as the new uploads of reverse dependencies | can migrate *before* r-base, and hence this class of issues will I don't think so. The recent change helps with the (approximately a handful or two CRAN packages) setting the graphics engine check (out of a total of maybe 1300 CRAN/BioC packages at Debian leaving the many others unaffected). | disappear once that happens (autopkgtest failures are retried after a | day). So unless somebody investigates the issues in time, the retry will We will get the same breakage next time will CRAN assumes (and ensures !!) everything is current at HEAD, we usually have slippage for various reasons so in practice I fear ... here we are and remain. | pass after the migration and the issue will no longer block r-base. I | can live with that, but I find it a shame nevertheless. Yep. We should aim to have 'less shame, more technical excellence'. | So, what do you say: technical excellence and you add the Breaks? Or we | let this slip in? I prefer the former, I can live with the latter. I can add the Breaks as a 'best of the worse alternative'. And, I presume, I can remove the existing four-year breaks? [1] Cheers, Dirk [1] edd@rob:~/deb/r-base(master)$ git blame debian/control | grep -A24 Breaks 52de7d776d (Dirk Eddelbuettel 2019-08-08 19:11:55 -0500 55) Breaks: r-bioc-graph (<< 1.62.0-1~), 52de7d776d (Dirk Eddelbuettel 2019-08-08 19:11:55 -0500 56) r-cran-bbmle (<< 1.0.20-5~), 52de7d776d (Dirk Eddelbuettel 2019-08-08 19:11:55 -0500 57) r-cran-biocmanager (<< 1.30.4+dfsg-2~), 52de7d776d (Dirk Eddelbuettel 2019-08-08 19:11:55 -0500 58) r-cran-caret (<< 6.0-84-2~), 52de7d776d (Dirk Eddelbuettel 2019-08-08 19:11:55 -0500 59) r-cran-cmprsk (<< 2.2-8-1~), 52de7d776d (Dirk Eddelbuettel 2
Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)
On 10 July 2023 at 19:43, Dirk Eddelbuettel wrote: | Someone simply didn't update our Debian package, so it lacks this change and | fingers point at r-base when the fault, if there is one, is to let our | package slip behind a compilation and code standard established at CRAN for | the R 4.3.0 relese in April. | | I still have hopes that we can let technical excellence rule and not require | blunt instruments such as forced recompilation. | | Because with slips like this, even forcing recompilation of over 1000+ | sources packages times 10+ architectures (for binary-any) will not help | against stale code, and hence mismatched expectations in the language engine | (r-base) and its client packages. I should have double-checked. 1.22.1-1 is in unstable, so that is good, and hence works with R 4.3.[01]. So what tripped me up is the (known, and expected, if "you know") failure in the (hence not all that informative) autopkgtest of trying R 4.3.1 with the outdated maldiquant 1.22 (not 1.22.1). I am not versed well-enough in the mechanics of release details. If the only way to get r-base into testing consists of having a Breaks for r-cran-maldiquant (<< 1.22.1) then I guess that is what we need to do. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)
Paul, Here is a case in point from looking at the current excluses list (which is by now indeed a little shorter). One package that jumps out is r-cran-maldiquant. We are at version 1.22, with Debian build 1.22-1. But one second at the CRAN site and the page for the package shows that it is upstream at 1.22.1, since March, with a sole entry in NEWS being CHANGES IN MALDIquant VERSION 1.22.1 [2023-03-20]: -- * Use symbols instead of names in `.Call` for faster lookup of C functions. So there it is. Someone simply didn't update our Debian package, so it lacks this change and fingers point at r-base when the fault, if there is one, is to let our package slip behind a compilation and code standard established at CRAN for the R 4.3.0 relese in April. I still have hopes that we can let technical excellence rule and not require blunt instruments such as forced recompilation. Because with slips like this, even forcing recompilation of over 1000+ sources packages times 10+ architectures (for binary-any) will not help against stale code, and hence mismatched expectations in the language engine (r-base) and its client packages. Best, Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)
Hi Paul,
On 9 July 2023 at 20:11, Paul Gevers wrote:
| On 09-07-2023 18:41, Dirk Eddelbuettel wrote:
| > On 9 July 2023 at 17:40, Paul Gevers wrote:
| > | Did we already discuss that r-cran-ps also seems to be impacted by the
| > | r-base change of the symbols thingy, as can be seen in r-cran-xopen [1].
| >
| > Correct me if I am wrong but the "symbols thingy" was not a change in R
4.2.*
| > to R 4.3.*. It was a change by some packages opting into different behavior.
|
| I don't understand this then. For several packages we're seeing failures
| in testing even if we only use r-base from unstable and everything else
| from testing to run the test. They pass with a rebuild r-cran-fnn and/or
| a rebuild and updated r-cran-ps, and/or r-cran-tibble. (Sorry, in my
| previous message I think I added r-cran-dplyr by mistake, misremembered).
It would be useful to break this down into concrete reproducible examples.
| > | 33s 10. ps:::not_null(.Call("psll_connections", p))
| >
| > Tis would be a bug in r-cran-ps and I think a Breaks may be warranted.
|
| Ok, let's remember this.
|
| > Given
| > that ps always had 'native symbols', maybe testthat changed?
|
| But I think (I would need to check for the autopkgtest fallback) in none
| of the tests, the version of testthat in testing changed between passing
| and failing tests. Would testthat embed something during the build of
| the binaries (from the name, I would assume not)?
I don't think it would do anything _explicit_.
I think what we are seeing is simply 'fragility from some packages with
larger tails'. If you install 'testthat' (presumably just to run tests) you
end up with with 30+ packages loaded (without considering Suggests:). It is
similar with other 'tidyverse' packages (dplyr, tibble, vctrs, ...) are all
part of that.
| > | Same for r-cran-fnn, which impacts r-cran-uwof [2].
I just looked at FNN, it is very narrow package at its core, it gets a bit of
tail via the Suggests of chemometrics.
| > | I think what we should do is add a versioned Breaks in r-base on
| > | , r-cran-ps, r-cran-tibble,
| > | r-cran-dplyr, r-cran-fnn. I think that's the right thing to do for
| >
| > I think it would be best to work out to corresponding package pairings and
| > apply the Breaks to them. If we can.
|
| Sure, lets add the Breaks to the place where it belongs.
|
| > For spacetime and stars I suspect (based on past experience) possible
| > interaction from the underlying graphics libraries.
|
| Good to hear, didn't check yet, but will shortly (geospatial).
It's a complex block. spacetime is one of the older ones using 'sp' (and then
'raster' via Suggests), 'stars' is newer using 'sf'. Sometimes these prefer /
work better with a consistent rebuild.
| > If I am not mistaken all of these were already in the Excuses list before we
| > made addition of the r-graphics-engine-* tag (which was taken care of for R
| > 4.3.* already, having it may help if another change happens like that).
|
| Sure, I'd hope the r-graphics-engine-* Provides only reduced issue, so
| I'm currently considering them to be different. But I might be proven
| wrong easily.
I don't think it had a net effect this. The
|
| > Unfortunately I find
| > the reports a little hard to read and am hence not very efficient at
| > pinpointing underlying causes. Above you pointed eg at [2] for uwot, I see
no
| > error in there :-/
|
| Well, that log has two tests. The first second one passes, the first one
| has:
| 51s > library(testthat)
| 51s > library(uwot)
| 51s Loading required package: Matrix
| 53s >
| 53s > test_check("uwot")
| 53s Error in FNN::get.knn(X, k) : DLL requires the use of native symbols
| 53s Calls: test_check ... eval -> create_data -> find_nn -> FNN_nn ->
|
| 53s Execution halted
But uwot itself does not force symbols:
https://github.com/jlmelville/uwot/blob/master/src/RcppExports.cpp#L228-L231
and I mentioned, using just those two lines in common. So the forceSymbols
comes from somewhere else.
Ok, I rechecked. R 4.3.0 has this
* Attempting to use a character string naming a foreign function
entry point in a foreign function call in a package will now
signal an error if the packages has called R_forceSymbols to
specify that symbols must be used.
It used to _ignore_ the combinatation of calling R_forceSymbols _and_ use of
non-symbols / quoted identifiers. Now it errors: if you have R_forceSymbols
each .Call() will require symbols (not strings).
So this is where R 4.3.[01] will possibly break with some older packages.
But the fix is simple because when R 4.3.0 came out all packages at CRAN
complied. We need to have current packages that correspond to the R 4.3.0
standard.
(If one were super picky one could call this an ABI/API change and reason for
forcing _all_ packa
Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)
On 9 July 2023 at 11:41, Dirk Eddelbuettel wrote: | For spacetime and stars I suspect (based on past experience) possible | interaction from the underlying graphics libraries. Absent-minded typing error: "geospatial", of course. Not "graphics". Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)
Paul,
On 9 July 2023 at 17:40, Paul Gevers wrote:
| Did we already discuss that r-cran-ps also seems to be impacted by the
| r-base change of the symbols thingy, as can be seen in r-cran-xopen [1].
Correct me if I am wrong but the "symbols thingy" was not a change in R 4.2.*
to R 4.3.*. It was a change by some packages opting into different behavior.
| In unstable r-cran-xopen works. If I take r-cran-ps, r-cran-xopen and
| r-base from unstable and test in testing, r-cran-xopen works. If I only
| take r-base and r-cran-ps from unstable and test in testing,
| r-cran-xopen works. Can somebody with R understanding confirm?
|
| 33s Error in `not_null(.Call("psll_connections", p))`: DLL requires
| the use of native symbols
| 33s Backtrace:
| 33s 1. testthat::test_that(...)
| 33sat test.R:4:0
| 33s 2. testthat:::test_code(desc, code, env = parent.frame(),
| reporter = reporter)
| 33s 3. reporter$start_test(context = reporter$.context, test = test)
| 33s 4. testthat:::o_apply(self$reporters, "start_test", context, test)
| 33s 5. base::lapply(objects, f)
| 33s 6. testthat (local) FUN(X[[i]], ...)
| 33s 7. x$start_test(...)
| 33s 8. ps::ps_connections(ps_handle())
| 33s 9. ps:::psl_connections(p)
| 33s 10. ps:::not_null(.Call("psll_connections", p))
Tis would be a bug in r-cran-ps and I think a Breaks may be warranted. We
are apparently between version 1.7.2 and 1.7.5 of package (r-cran-)ps but I
see no smoking gun in https://github.com/r-lib/ps/blob/main/NEWS.md that
would have caused this.
Looking further, `git blame` indicates that the package had
`registation=TRUE` for five years / all its existence, see line 2 here
https://github.com/r-lib/ps/blame/357f9c01f5db95b67ce9e230282391bc835afca4/R/ps.R
It also used 'forceSymbols' for the same five years (lines 99 to 101 here
https://github.com/r-lib/ps/blame/357f9c01f5db95b67ce9e230282391bc835afca4/src/init.c
So I think the issue here may not be coming from ps. I has not changed how it
refers to its symbols. Same R API, same usage.
As the last entry here is into the (unexported) ps:::not_null we can look
into it. It just indexes with map_lgl which is a local function (from R/utils)
and calls psll_connection, a local compiled function in the package. Given
that ps always had 'native symbols', maybe testthat changed?
However, it does not force symbols :-/ Lines 20 and 21 use the two required
initialization but not the optional symbol forcing that eg ps has.
https://github.com/r-lib/testthat/blob/main/src/init.c
So I got nothing here. Cause is unclear to me.
| Same for r-cran-fnn, which impacts r-cran-uwof [2].
|
| I think what we should do is add a versioned Breaks in r-base on
| , r-cran-ps, r-cran-tibble,
| r-cran-dplyr, r-cran-fnn. I think that's the right thing to do for
I think it would be best to work out to corresponding package pairings and
apply the Breaks to them. If we can.
| bookworm to trixie upgrades (and current trixie to trixie with the new
| r-base). Has anyone see other packages throwing that "DLL requires the
| use of native symbols" error? I spotted the ones below [3, 4, 5, 6], but
| I haven't identified which package brings in the issue. I first thought
| it would be from the package itself, but for some (r-cran-spacetime and
| r-cran-stars) their versions in unstable fail their own testsuite in
For spacetime and stars I suspect (based on past experience) possible
interaction from the underlying graphics libraries.
| testing. Would it hint at the same problem for the packages, or just for
| their tests? I suspect the former, then they should also need to be
| added to the Breaks list.
|
| Paul
|
| [1]
|
https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-xopen/35575366/log.gz
| [2]
|
https://ci.debian.net/data/autopkgtest/testing/i386/r/r-cran-uwot/35590669/log.gz
| [3]
|
https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-intervals/35575046/log.gz
| [4]
|
https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-maldiquant/35575320/log.gz
| [5]
|
https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-spacetime/35575371/log.gz
| [6]
|
https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-stars/35583884/log.gz
If I am not mistaken all of these were already in the Excuses list before we
made addition of the r-graphics-engine-* tag (which was taken care of for R
4.3.* already, having it may help if another change happens like that).
So it short, the vast majority of R packages is now fine. A persistent
subset is not under the testing regime of autopkgtest. Unfortunately I find
the reports a little hard to read and am hence not very efficient at
pinpointing underlying causes. Above you pointed eg at [2] for uwot, I see no
error in there :-/
Obviously, I too want my package r-base in testing and I will help. But I
feel that pinning a large Breaks list on it seems a little inefficient /
unfair if
Bug#1039721: r-base: 4.3 causes many autopkgtests to fail
Thanks for closing it. I think in due course as you will see there a) new tag does not help today (we already took care of the six packages needing a rebuild because of the graphics engine constant changing) and b) what is likely being the exact same sets of packages having issue with each other as week ago, and the r-base 4.3.1-2 change does not affect them as these are internal issue to the respective packages c) hence there never a mass bug cause to be had. So it was always a nothingburger, and I suspect the ongoing round two of the transition will boil down to what I said at the outset: the packages with woes (beside what the graphics engine change that we covered the standard way) will be dealt with by their maintainer. We'll see how it goes. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing (Was: Bug#1040001: transition: r-base)
On 7 July 2023 at 00:33, Nilesh Patra wrote:
| I think we are hitting this issue here:
https://github.com/tidyverse/dplyr/issues/6793
| The comment says "Looks like some package in the stack sets
R_forceSymbols(dll, TRUE)" and that package is tibble
|
| | $ grep -rnw R_forceSymbols
| | src/init.c:19: R_forceSymbols(dll, TRUE);
That mechanism should not spill from one package to the next.
What we have here is that (R) packages with compiled code can (optionally)
declare in NAMESPACE whether or not 'symbols' (ie the entrypoints for the
compiled code) should be a registered symbol (to R), or (as they used to be)
strings. That is then used in the first argument to .Call() as in eg
.Call(myfunc) as opposed to .Call("myfunc"). It has small efficiency
gains. Most packages do that now.
Now, another (less frequently-used) option is in the intialization file run
at package to also say R_forceSymbols in which case the second ("string")
form is no longer allowed. Few packages do that.
So if tibble does this now, it should only affect tibble itself -- unless of
course a dependent package calls directly into the native code of tibble
(possible, but rare).
So I sum in should not spill. I could be wrong but if there were general
spillage it would affect all R use of compiled packages and it very clearly
does not. So in short, this force symbol resolution should only affect the
symbols from the one shared (per-package) library it is set for.
| Since you are building with R from unstable and tibble from testing
| (built with an older R), it chokes and works when both are new.
Not sure I agree. That should still work. Quick check in Docker (using the
r-base image I maintain) shows it does:
root@f39da83dba5a:/# dpkg -l r-base-core r-cran-tibble | tail -2
ii r-base-core4.3.1-2 amd64GNU R core of statistical
computation and graphics system
ii r-cran-tibble 3.1.8+dfsg-1 amd64GNU R Simple Data Frames
root@f39da83dba5a:/# Rscript -e 'library(tibble); print(as_tibble(mtcars))'
# A tibble: 32 × 11
mpg cyl disphp dratwt qsecvsam gear carb
1 21 6 160110 3.9 2.62 16.5 0 1 4 4
2 21 6 160110 3.9 2.88 17.0 0 1 4 4
3 22.8 4 108 93 3.85 2.32 18.6 1 1 4 1
4 21.4 6 258110 3.08 3.22 19.4 1 0 3 1
5 18.7 8 360175 3.15 3.44 17.0 0 0 3 2
6 18.1 6 225105 2.76 3.46 20.2 1 0 3 1
7 14.3 8 360245 3.21 3.57 15.8 0 0 3 4
8 24.4 4 147.62 3.69 3.19 20 1 0 4 2
9 22.8 4 141.95 3.92 3.15 22.9 1 0 4 2
10 19.2 6 168. 123 3.92 3.44 18.3 1 0 4 4
# … with 22 more rows
root@f39da83dba5a:/#
It's simpy that testing has an older one and (esp in the tidyverse) things
change quickly and packages want to be in consistent cohort.
| This attribute has got something to do with R extensions' entry
| points / dll compatibilty, but I simply do not have enough background
| with r-core to comment beyond this point, I'm afraid.
Hope the above helped a little.
Dirk
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1040001: transition: r-base
Paul, Graham, r-base 4.3.1-2 is now on its way. You will have to update / tweak the ben file as there is no 'r-api-4.3' tag as there is no such thing API change upstream in R itself. Filing the bug reports against the handful of packages testing the graphics engine version was the right thing to do, and their simple rebuilds now shows https://qa.debian.org/excuses.php?package=r-base has no remaining graphics bugs. This demonstrates clearly that we do not "need" a graphics api. But as I get nowhere making this argument I relented and now provide r-graphics-engine-* from r-base-core. Packages have not used it yet, of course, so the transition cannot depend on it. This of cannot resolve the remaining problems at the excuses page. It would be nice if the maintainers of the packages experiencing the breakage were looking into them. I suspect relatively simple inter-package issues. The newest BioConductor release does as always use the most recent and preceding R release, so we probably need consistent builds of BioConductor release 3.16 using the R 4.3.* version that came out just before it. And likely similar with geo-spatial stack which of then refers consistent builds of its underlying library (gdal, geos, ...) Cheers, Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1039721: r-base: 4.3 causes many autopkgtests to fail
Control: severity -1 normal I am changing this back because a) there is no general bug in R 4.3.1, and there newer was there were a few packages requiring an update to the new graphics engine version (as the packages choose to call R_GE_checkVersionOrDie, it is coming from their side, not the R package imposing/causing a break) filing bug reports against the affected package resolved the issue as expected, if you look at https://qa.debian.org/excuses.php?package=r-base there is not a single graphics related issue but I can argue this issue til I am blue in the face and not get anywhere so the R package now provides r-graphics-engine-* b) note that the remaining autopkgtest breaks have nothing to do with the graphics engine version, and the change I was asked to make (and which I accomodated) will not help however, the error is not with R just like the one you posted in your bug report was not: Error in `vectbl_assign(x[[j]], i, recycled_value[[j]])`: DLL requires the use of native symbols this is almost surely intra-package and needs to be resolved by those package For both reasons the bug report should be closed but I am now only dialing it down to 'normal'. r-base is a bystander here, and the messenger that is being shot at. We of course do use R 4.3.* just fine with 21,000 r-cran-* binary packages in r2u. If one keeps the package current with CRAN all is well. It is not my fault if some other maintainers claim they (and I paraphrase, but it is all in the BTS) "have too many packages to keep them current". That is an issue for which filing bugs again r-base does not, and cannot, help. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1040341: r-base: please drop libpcre3-dev dependencies
On 4 July 2023 at 16:00, Graham Inggs wrote: | Source: r-base | Version: 4.3.1-1 | Tags: patch | | Hi Maintainer | | r-base has a build-dependency, and r-base-dev has a dependency, on the | ancient libpcre3-dev package. I believe these are no longer required | since the dependencies on the (confusingly) newer libpcre2-dev are | already present, and a test rebuild of r-base with libpcre3-dev | dropped still shows the following lines in its build log: | | checking for pcre2.h... yes | checking for pcre2_compile_8 in -lpcre2-8... yes | checking if PCRE2 has Unicode support... yes | checking whether PCRE support suffices... yes | | The maintainer of both PCRE packages is trying to get rid of pcre3 | during the trixie development cycle [1]. Please consider applying the | attached patch in a future upload of r-base. Happy to help. That was always very confusing. Updated my debian/control. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1040038: r-base-core: Please provide r-graphics-api-*
On 1 July 2023 at 15:26, Graham Inggs wrote:
| Your patch has 'rgraphicsapiversion' and 'r-graphics-api-4.3'.
|
| Upstream [1] refer to it as follows:
|
| The graphics engine version, R_GE_version, has been bumped to 16
| and so packages that provide graphics devices should be
| reinstalled.
Also see the nice compact history at
https://sources.debian.org/src/r-base/4.3.1-1/src/include/R_ext/GraphicsEngine.h/
showing that versions 13 _and_ 14 seem to have come during the 4.1.* cycle.
There is also a nice Rcpp functionality we can use as it can evaluate C/C++
expression and asking for the value of a #define is one:
> Rcpp::evalCpp("R_GE_version")
[1] 16
>
> getRversion()
[1] ‘4.3.1’
>
Dirk
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
