Bug#1055539: bookworm-pu: package opensc/0.23.0-0.3+deb12u1

[Bastian Germann]

Am 08.11.23 um 02:15 schrieb Bastian Germann:

   [x] attach debdiff against the package in (old)stable


diff -Nru opensc-0.23.0/debian/changelog opensc-0.23.0/debian/changelog
--- opensc-0.23.0/debian/changelog  2023-06-01 20:30:18.0 +
+++ opensc-0.23.0/debian/changelog  2023-11-08 00:26:46.0 +
@@ -1,3 +1,12 @@
+opensc (0.23.0-0.3+deb12u1) bookworm; urgency=medium
+
+  * Team upload
+  * Fix CVE-2023-4535 with two upstream patches (Closes: #1055520)
+  * Fix CVE-2023-40660 with upstream patch (Closes: #1055521)
+  * Fix CVE-2023-40661 with upstream patches (Closes: #1055522)
+
+ -- Bastian Germann   Wed, 08 Nov 2023 01:26:46 +0100
+
 opensc (0.23.0-0.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru opensc-0.23.0/debian/patches/0006-CVE-2023-4535.patch 
opensc-0.23.0/debian/patches/0006-CVE-2023-4535.patch
--- opensc-0.23.0/debian/patches/0006-CVE-2023-4535.patch   1970-01-01 
00:00:00.0 +
+++ opensc-0.23.0/debian/patches/0006-CVE-2023-4535.patch   2023-11-08 
00:26:46.0 +
@@ -0,0 +1,54 @@
+Origin: 
https://github.com/OpenSC/OpenSC/commit/cde2e050ec4f2f1b7db38429aa4e9c0f4656308c
+From: Peter Popovec 
+Date: Wed, 26 Apr 2023 13:22:09 +0200
+Subject: NULL pointer fix
+
+Thanks to the clang analyzer:
+ Null pointer passed to 2nd parameter expecting 'nonnull'
+ [clang-analyzer-core.NonNullParamChecker]
+
+   modified:   src/libopensc/card-myeid.c
+---
+ src/libopensc/card-myeid.c | 15 ++-
+ 1 file changed, 10 insertions(+), 5 deletions(-)
+
+diff --git a/src/libopensc/card-myeid.c b/src/libopensc/card-myeid.c
+index 31dd209f3e..951c179f1b 100644
+--- a/src/libopensc/card-myeid.c
 b/src/libopensc/card-myeid.c
+@@ -1973,6 +1973,9 @@ myeid_enc_dec_sym(struct sc_card *card, const u8 *data, 
size_t datalen,
+   return_len = block_size - pad_byte;
+   }
+   *outlen = return_len;
++  /* application can request buffer size or actual buffer 
size is too small */
++  if (out == NULL)
++  LOG_FUNC_RETURN(ctx, SC_SUCCESS);
+   if (return_len > *outlen)
+   LOG_FUNC_RETURN(ctx, SC_ERROR_BUFFER_TOO_SMALL);
+   memcpy(out, priv->sym_plain_buffer, return_len);
+@@ -2042,10 +2045,11 @@ myeid_enc_dec_sym(struct sc_card *card, const u8 
*data, size_t datalen,
+   priv->sym_crypt_buffer_len = 0;
+   rest_len = 0;
+   }
+-  memcpy(sdata, data, apdu_datalen);
+-  data += apdu_datalen;
+-  datalen -= apdu_datalen;
+-
++  if (data) {
++  memcpy(sdata, data, apdu_datalen);
++  data += apdu_datalen;
++  datalen -= apdu_datalen;
++  }
+   r = sc_transmit_apdu(card, );
+   LOG_TEST_RET(ctx, r, "APDU transmit failed");
+   r = sc_check_sw(card, apdu.sw1, apdu.sw2);
+@@ -2084,7 +2088,8 @@ myeid_enc_dec_sym(struct sc_card *card, const u8 *data, 
size_t datalen,
+   /* save rest of data for next run */
+   priv->sym_crypt_buffer_len = datalen;
+   sc_log(ctx, "rest data len = %zu", datalen);
+-  memcpy(priv->sym_crypt_buffer, data, datalen);
++  if (data)
++  memcpy(priv->sym_crypt_buffer, data, datalen);
+   sc_log(ctx, "return data len = %zu", return_len);
+   *outlen = return_len;
+   return SC_SUCCESS;
diff -Nru opensc-0.23.0/debian/patches/0007-CVE-2023-4535.patch 
opensc-0.23.0/debian/patches/0007-CVE-2023-4535.patch
--- opensc-0.23.0/debian/patches/0007-CVE-2023-4535.patch   1970-01-01 
00:00:00.0 +
+++ opensc-0.23.0/debian/patches/0007-CVE-2023-4535.patch   2023-11-08 
00:26:46.0 +
@@ -0,0 +1,39 @@
+Origin: 
https://github.com/OpenSC/OpenSC/commit/f1993dc4e0b33050b8f72a3558ee88b24c4063b2
+From: Peter Popovec 
+Date: Tue, 27 Jun 2023 09:50:42 +0200
+Subject: myeid: fixed CID 380538  Out-of-bounds read (OVERRUN)
+
+also fixes output buffer size checking
+---
+ src/libopensc/card-myeid.c | 10 ++
+ 1 file changed, 6 insertions(+), 4 deletions(-)
+
+diff --git a/src/libopensc/card-myeid.c b/src/libopensc/card-myeid.c
+index 4ee4246840..50e78ff1d8 100644
+--- a/src/libopensc/card-myeid.c
 b/src/libopensc/card-myeid.c
+@@ -1986,18 +1986,20 @@ myeid_enc_dec_sym(struct sc_card *card, const u8 
*data, size_t datalen,
+   sc_log(ctx, "Found padding byte %02x", 
pad_byte);
+   if (pad_byte == 0 || pad_byte > block_size)
+   LOG_FUNC_RETURN(ctx, 
SC_ERROR_WRONG_PADDING);
+-  sdata = priv->sym_plain_buffer + block_size - 
pad_byte;
++  sdata = priv->sym_plain_buffer + block_size;
+

Processed: bookworm-pu: package opensc/0.23.0-0.3+deb12u1

[Debian Bug Tracking System]

Processing control commands:

> affects -1 + src:opensc
Bug #1055539 [release.debian.org] bookworm-pu: package opensc/0.23.0-0.3+deb12u1
Added indication that 1055539 affects src:opensc

-- 
1055539: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055539
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1055539: bookworm-pu: package opensc/0.23.0-0.3+deb12u1

[Bastian Germann]

Package: release.debian.org
Control: affects -1 + src:opensc
X-Debbugs-Cc: ope...@packages.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: bookworm
Severity: normal

[ Reason ]
opensc in bookworm is vulnerable for CVE-2023-4535, CVE-2023-40660, 
CVE-2023-40661.

[ Impact ]
User can be attacked via the CVE vectors.

[ Tests ]
No automated tests. I have not exploited the CVEs.

[ Risks ]
I have left out two patches of CVE-2023-40661 because they change code that is not yet available in 
the bookworm release. There might be side effects of not applying them


[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

NEW changes in oldstable-new

[Debian FTP Masters]

Processing changes file: open-vm-tools_11.2.5-2+deb11u3_source.changes
  ACCEPT
Processing changes file: open-vm-tools_11.2.5-2+deb11u3_amd64-buildd.changes
  ACCEPT
Processing changes file: open-vm-tools_11.2.5-2+deb11u3_i386-buildd.changes
  ACCEPT
Processing changes file: openjdk-17_17.0.9+9-1~deb11u1_source.changes
  ACCEPT
Processing changes file: openjdk-17_17.0.9+9-1~deb11u1_all-buildd.changes
  ACCEPT
Processing changes file: openjdk-17_17.0.9+9-1~deb11u1_amd64-buildd.changes
  ACCEPT
Processing changes file: openjdk-17_17.0.9+9-1~deb11u1_arm64-buildd.changes
  ACCEPT
Processing changes file: openjdk-17_17.0.9+9-1~deb11u1_armel-buildd.changes
  ACCEPT
Processing changes file: openjdk-17_17.0.9+9-1~deb11u1_armhf-buildd.changes
  ACCEPT
Processing changes file: openjdk-17_17.0.9+9-1~deb11u1_i386-buildd.changes
  ACCEPT
Processing changes file: openjdk-17_17.0.9+9-1~deb11u1_mips64el-buildd.changes
  ACCEPT
Processing changes file: openjdk-17_17.0.9+9-1~deb11u1_mipsel-buildd.changes
  ACCEPT
Processing changes file: openjdk-17_17.0.9+9-1~deb11u1_ppc64el-buildd.changes
  ACCEPT
Processing changes file: openjdk-17_17.0.9+9-1~deb11u1_s390x-buildd.changes
  ACCEPT
Processing changes file: pmix_4.0.0-4.1+deb11u1_source.changes
  ACCEPT
Processing changes file: pmix_4.0.0-4.1+deb11u1_amd64-buildd.changes
  ACCEPT
Processing changes file: pmix_4.0.0-4.1+deb11u1_arm64-buildd.changes
  ACCEPT
Processing changes file: pmix_4.0.0-4.1+deb11u1_armel-buildd.changes
  ACCEPT
Processing changes file: pmix_4.0.0-4.1+deb11u1_armhf-buildd.changes
  ACCEPT
Processing changes file: pmix_4.0.0-4.1+deb11u1_i386-buildd.changes
  ACCEPT
Processing changes file: pmix_4.0.0-4.1+deb11u1_mips64el-buildd.changes
  ACCEPT
Processing changes file: pmix_4.0.0-4.1+deb11u1_mipsel-buildd.changes
  ACCEPT
Processing changes file: pmix_4.0.0-4.1+deb11u1_ppc64el-buildd.changes
  ACCEPT
Processing changes file: pmix_4.0.0-4.1+deb11u1_s390x-buildd.changes
  ACCEPT
Processing changes file: request-tracker4_4.4.4+dfsg-2+deb11u3_source.changes
  ACCEPT
Processing changes file: 
request-tracker4_4.4.4+dfsg-2+deb11u3_all-buildd.changes
  ACCEPT
Processing changes file: trafficserver_8.1.9+ds-1~deb11u1_source.changes
  ACCEPT
Processing changes file: trafficserver_8.1.9+ds-1~deb11u1_amd64-buildd.changes
  ACCEPT
Processing changes file: trafficserver_8.1.9+ds-1~deb11u1_arm64-buildd.changes
  ACCEPT
Processing changes file: trafficserver_8.1.9+ds-1~deb11u1_armhf-buildd.changes
  ACCEPT
Processing changes file: trafficserver_8.1.9+ds-1~deb11u1_i386-buildd.changes
  ACCEPT
Processing changes file: 
trafficserver_8.1.9+ds-1~deb11u1_mips64el-buildd.changes
  ACCEPT
Processing changes file: trafficserver_8.1.9+ds-1~deb11u1_mipsel-buildd.changes
  ACCEPT
Processing changes file: trafficserver_8.1.9+ds-1~deb11u1_ppc64el-buildd.changes
  ACCEPT

NEW changes in stable-new

[Debian FTP Masters]

Processing changes file: trafficserver_9.2.3+ds-1+deb12u1_source.changes
  ACCEPT
Processing changes file: trafficserver_9.2.3+ds-1+deb12u1_amd64-buildd.changes
  ACCEPT
Processing changes file: trafficserver_9.2.3+ds-1+deb12u1_arm64-buildd.changes
  ACCEPT

Re: rust-grep-regex REMOVED from testing

[Paul Gevers]

Hi,

On 07-11-2023 16:54, Peter Green wrote:

  Previous version: 0.1.11-1
  Current version:  (not in testing)
  Hint: 
    # 2023-11-04
    # blocks lots of packages from migrating
    # 1053431


Assuming your goal was to allow rust-regex and friends to
migrate to testing, you will also want to set removal
hints for rust-matchers and rust-loom.


Thanks, that was indeed my intent. But after several iterations (and dak 
not being able to help me find the set) I gave up at it looked like it 
would be solved around 16 November 2023. So, this message was useful.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1054657: transition: r-bioc-biocgenerics

[Andreas Tille]

Hi Dirk,

Am Tue, Nov 07, 2023 at 12:28:22PM -0600 schrieb Dirk Eddelbuettel:
> 
> "Kinda. Sorta. Not fully." I have written related code doing most of this
> during the many attempt for 'turning CRAN into .deb packages'.
> ...

Sounds like another idea how this problem can be turned into code
(alternatively we could re-use some code from dh-r or rewrite in
Python to parse previously downloaded DESCRIPTION files).  But all
final code needs time and testing ... which I'd like to avoid (but
for sure working code contributions are welcome).
 
> 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.

Thanks a lot for your ideas anyway
 Andreas. 

-- 
http://fam-tille.de

NEW changes in oldstable-new

[Debian FTP Masters]

Processing changes file: firefox-esr_102.15.1esr-1~deb11u1_source.changes
  ACCEPT
Processing changes file: firefox-esr_102.15.1esr-1~deb11u1_all-buildd.changes
  ACCEPT
Processing changes file: firefox-esr_102.15.1esr-1~deb11u1_amd64-buildd.changes
  ACCEPT
Processing changes file: firefox-esr_102.15.1esr-1~deb11u1_arm64-buildd.changes
  ACCEPT
Processing changes file: firefox-esr_102.15.1esr-1~deb11u1_armhf-buildd.changes
  ACCEPT
Processing changes file: firefox-esr_102.15.1esr-1~deb11u1_i386-buildd.changes
  ACCEPT
Processing changes file: 
firefox-esr_102.15.1esr-1~deb11u1_ppc64el-buildd.changes
  ACCEPT
Processing changes file: firefox-esr_102.15.1esr-1~deb11u1_s390x-buildd.changes
  ACCEPT
Processing changes file: firefox-esr_115.3.0esr-1~deb11u1_source.changes
  ACCEPT
Processing changes file: firefox-esr_115.3.0esr-1~deb11u1_all-buildd.changes
  ACCEPT
Processing changes file: firefox-esr_115.3.0esr-1~deb11u1_amd64-buildd.changes
  ACCEPT
Processing changes file: firefox-esr_115.3.0esr-1~deb11u1_arm64-buildd.changes
  ACCEPT
Processing changes file: firefox-esr_115.3.0esr-1~deb11u1_armhf-buildd.changes
  ACCEPT
Processing changes file: firefox-esr_115.3.0esr-1~deb11u1_i386-buildd.changes
  ACCEPT
Processing changes file: firefox-esr_115.3.0esr-1~deb11u1_ppc64el-buildd.changes
  ACCEPT
Processing changes file: firefox-esr_115.3.0esr-1~deb11u1_s390x-buildd.changes
  ACCEPT
Processing changes file: firefox-esr_115.3.1esr-1~deb11u1_source.changes
  ACCEPT
Processing changes file: firefox-esr_115.3.1esr-1~deb11u1_all-buildd.changes
  ACCEPT
Processing changes file: firefox-esr_115.3.1esr-1~deb11u1_amd64-buildd.changes
  ACCEPT
Processing changes file: firefox-esr_115.3.1esr-1~deb11u1_arm64-buildd.changes
  ACCEPT
Processing changes file: firefox-esr_115.3.1esr-1~deb11u1_armhf-buildd.changes
  ACCEPT
Processing changes file: firefox-esr_115.3.1esr-1~deb11u1_i386-buildd.changes
  ACCEPT
Processing changes file: firefox-esr_115.3.1esr-1~deb11u1_ppc64el-buildd.changes
  ACCEPT
Processing changes file: firefox-esr_115.3.1esr-1~deb11u1_s390x-buildd.changes
  ACCEPT
Processing changes file: firefox-esr_115.4.0esr-1~deb11u1_source.changes
  ACCEPT
Processing changes file: firefox-esr_115.4.0esr-1~deb11u1_all-buildd.changes
  ACCEPT
Processing changes file: firefox-esr_115.4.0esr-1~deb11u1_amd64-buildd.changes
  ACCEPT
Processing changes file: firefox-esr_115.4.0esr-1~deb11u1_arm64-buildd.changes
  ACCEPT
Processing changes file: firefox-esr_115.4.0esr-1~deb11u1_armhf-buildd.changes
  ACCEPT
Processing changes file: firefox-esr_115.4.0esr-1~deb11u1_i386-buildd.changes
  ACCEPT
Processing changes file: firefox-esr_115.4.0esr-1~deb11u1_ppc64el-buildd.changes
  ACCEPT
Processing changes file: firefox-esr_115.4.0esr-1~deb11u1_s390x-buildd.changes
  ACCEPT

NEW changes in oldstable-new

[Debian FTP Masters]

Processing changes file: chromium_118.0.5993.70-1~deb11u1_source.changes
  ACCEPT
Processing changes file: chromium_118.0.5993.70-1~deb11u1_all-buildd.changes
  ACCEPT
Processing changes file: chromium_118.0.5993.70-1~deb11u1_amd64-buildd.changes
  ACCEPT
Processing changes file: chromium_118.0.5993.70-1~deb11u1_arm64-buildd.changes
  ACCEPT
Processing changes file: chromium_118.0.5993.70-1~deb11u1_ppc64el-buildd.changes
  ACCEPT
Processing changes file: chromium_118.0.5993.117-1~deb11u1_source.changes
  ACCEPT
Processing changes file: chromium_118.0.5993.117-1~deb11u1_all-buildd.changes
  ACCEPT
Processing changes file: chromium_118.0.5993.117-1~deb11u1_amd64-buildd.changes
  ACCEPT
Processing changes file: chromium_118.0.5993.117-1~deb11u1_arm64-buildd.changes
  ACCEPT
Processing changes file: chromium_118.0.5993.117-1~deb11u1_i386-buildd.changes
  ACCEPT
Processing changes file: 
chromium_118.0.5993.117-1~deb11u1_ppc64el-buildd.changes
  ACCEPT
Processing changes file: chromium_119.0.6045.105-1~deb11u1_source.changes
  ACCEPT
Processing changes file: chromium_119.0.6045.105-1~deb11u1_all-buildd.changes
  ACCEPT
Processing changes file: chromium_119.0.6045.105-1~deb11u1_amd64-buildd.changes
  ACCEPT
Processing changes file: chromium_119.0.6045.105-1~deb11u1_arm64-buildd.changes
  ACCEPT
Processing changes file: chromium_119.0.6045.105-1~deb11u1_armhf-buildd.changes
  ACCEPT
Processing changes file: chromium_119.0.6045.105-1~deb11u1_i386-buildd.changes
  ACCEPT
Processing changes file: 
chromium_119.0.6045.105-1~deb11u1_ppc64el-buildd.changes
  ACCEPT

Bug#1054657: transition: r-bioc-biocgenerics

[Dirk Eddelbuettel]

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

[Andreas Tille]

Hi Sebastian,

Am Tue, Nov 07, 2023 at 03:12:39PM +0100 schrieb Sebastian Ramacher:
> > Charles and I tried to explain in different ways: We do not have simple
> > means to answer this question.
> 
> Picking a random r-bioc-* package:
> https://salsa.debian.org/r-pkg-team/r-bioc-aroma.light/-/blob/master/DESCRIPTION
> has an "Imports" field. Those are mapped to dependencies in the package.
> So I presume that when importing those packages into the packaging
> repository, changes to this field can be identified and checked. I would
> excpect this information to be enough to identify any currently missing
> packages.

Well, I'm one of the authors of dh-r.  I know where to find the
dependencies since we are parsing this file.  We even go further:  When
trying to build an R package and find a missing dependency this will be
nearly ready packaged automatically.  This is NOT the problem.  The
point is that this workflow is completely automated.  Parsing 170
DESCRIPTION files of not yet packaged versions is not automated and thus
quite some manual work.  And I would really like to hear better reasons
why you want us to do this manual work in addition to something which is
done automatically.
 
> > But I had a different question;  What
> > exactly is the problem of a transition taking about 1 month due to some
> > delay by waiting for packages in new?
> >  
> > I somehow have the feeling that this transition is currently delayed by
> > some bug-mail / tagging ping-pong which is demotivating for both sides.
> > You make a request to some volunteers to do some extra work that was not
> > requested before and we volunteers explained that it is really hard
> > work.  I think it is fair to ask for the reasons you want us to do some
> > work which is definitely hard to do and for us painful and unproductive.
> 
> We should have requested this information for all transitions in the
> past. We did not and thus had the same problems for the last couple of
> transitions including missing packages and a significant number of
> autopkgtest regressions.

The autopkgtest regressions are not caused due to missing new packages.
They are mostly due to issues on some architectures.  We can stop those
by restricting Bioconductor packages to those tested by upstream by
loosing the advantages Debian provides to the community.  In fact
dealing with the regressions has taken us usually longer than the
missing packages.  I'm not proud on it that it takes so long to deal
with the regressions but cutting from our time constraints even more
will not help at all.
 
> The r-bioc-* transition is special in the sense that it requires all
> involved packages to be ready to migrate at the same time. This is where
> delays become an issue. It essentially blocks all other transitions that
> could potentially overlap (e.g., auto-hdf5) from being started or
> progressing.

We can wait until auto-hdf5 transition is done.
 
> All of that binds resources on our side to track down the remaining bits
> and pieces to make everything migrate at the same time. This is usually
> not an issue with a typical shared library transition. Hence we are
> asking you to identify possible NEW packages that will be required to
> complete the transition.

You did not yet answered the question I asked twice whether we can find
a compromise by simply removing packages with missing new dependencies
from testing.  I consider this a compromise which I would really love to
discuss honestly.

I try to repeat:  Please trust me that finding those packages is not as
simple as picking a random DESCRIPTION.  We need time for it, time were
other packages (RC bugs, autopkgtest regressions etc. are suffering).
I'm not yet convinced that we should do this extra work for a couple of
days win.  If you insist on your position I will escalate the issue to
the technical committee.

Kind regards
   Andreas.

-- 
http://fam-tille.de

re: rust-grep-regex REMOVED from testing

[Peter Green]

  Previous version: 0.1.11-1
  Current version:  (not in testing)
  Hint: 
# 2023-11-04
# blocks lots of packages from migrating
# 1053431


Assuming your goal was to allow rust-regex and friends to
migrate to testing, you will also want to set removal
hints for rust-matchers and rust-loom.

Bug#1055022: bullseye-pu: package distro-info-data/0.51+deb11u5

[Stefano Rivera]

Hi David (2023.11.03_18:59:13_+0200)
> Short version:
> Would you consider modifying this bullseye-pu for
> distro-info-data/0.51+deb11u5 into a bullseye-pu for a
> distro-info-data/0.59~deb11u1 instead?

That may make more sense in the future. But in the past, it wasn't
really an option, and consistency is useful.

We have had some format changes in the last few years that have made new
versions not as backportable as one would have hoped. And data changes
that broke test suites in other packages.

Both of these were addressed in the most recent round of updates. So,
the data should be fully backportable right now (provided sufficient
Breaks).

> I recently independently discovered Debian bug #711238[2] with
> devscripts and I would would like to see it fixed in unstable and
> my desired fix of adding to it a Build-Depends on
> ```
> distro-info-data (>= 0.58~) 
> ```

I don't really see the point in bumping Build-Depends like that. You
aren't requiring any format change or anything like that, just a version
that has the *current* stable (or development, not sure of the specifics
of that bug) versions.

We ensure that distro-info-data is kept up to date in all supported
releases.

Probably devscripts should become a little more tolerant about outdated
data?

Stefano

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

Bug#1054657: transition: r-bioc-biocgenerics

[Sebastian Ramacher]

On 2023-11-07 14:38:13 +0100, Andreas Tille wrote:
> Hi Sebastian,
> 
> Am Tue, Nov 07, 2023 at 10:53:00AM +0100 schrieb Sebastian Ramacher:
> > Control: tags -1 moreinfo
> 
> I admit I'm not really happy about the bug ping-pong.
>  
> > > I just finished inspecting by eye the homepage of each of the 69 new
> > > Bioconductor packages.  None of them declare a reverse-dependency to
> > > an existing Bioc package that we ship in Debian.
> > 
> > We do not care about new reverse dependencies.
> 
> Seems there is some misunderstanding.  Charles has inspected pacckages
> *outside* Debian whether they might be pulled by new versions of
> packages *inside* Debian.  These would be candidates for new packages.
> 
> > We care about new
> > dependencies of packages currently in the archive. So what's the status
> > of new the dependencies?
> 
> Charles and I tried to explain in different ways: We do not have simple
> means to answer this question.

Picking a random r-bioc-* package:
https://salsa.debian.org/r-pkg-team/r-bioc-aroma.light/-/blob/master/DESCRIPTION
has an "Imports" field. Those are mapped to dependencies in the package.
So I presume that when importing those packages into the packaging
repository, changes to this field can be identified and checked. I would
excpect this information to be enough to identify any currently missing
packages.

> But I had a different question;  What
> exactly is the problem of a transition taking about 1 month due to some
> delay by waiting for packages in new?
>  
> I somehow have the feeling that this transition is currently delayed by
> some bug-mail / tagging ping-pong which is demotivating for both sides.
> You make a request to some volunteers to do some extra work that was not
> requested before and we volunteers explained that it is really hard
> work.  I think it is fair to ask for the reasons you want us to do some
> work which is definitely hard to do and for us painful and unproductive.

We should have requested this information for all transitions in the
past. We did not and thus had the same problems for the last couple of
transitions including missing packages and a significant number of
autopkgtest regressions.

The r-bioc-* transition is special in the sense that it requires all
involved packages to be ready to migrate at the same time. This is where
delays become an issue. It essentially blocks all other transitions that
could potentially overlap (e.g., auto-hdf5) from being started or
progressing.

All of that binds resources on our side to track down the remaining bits
and pieces to make everything migrate at the same time. This is usually
not an issue with a typical shared library transition. Hence we are
asking you to identify possible NEW packages that will be required to
complete the transition.

Cheers
-- 
Sebastian Ramacher

Bug#1054657: transition: r-bioc-biocgenerics

[Andreas Tille]

Hi Dirk,

Am Tue, Nov 07, 2023 at 07:40:38AM -0600 schrieb Dirk Eddelbuettel:
> 
> 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
> 
> As you brought r2u up, allow me to add my perspective. I have done so before
> ...

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?

This would be really helpful
Andreas.

-- 
http://fam-tille.de

Bug#1054657: transition: r-bioc-biocgenerics

[Dirk Eddelbuettel]

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#1054657: transition: r-bioc-biocgenerics

[Andreas Tille]

Hi Sebastian,

Am Tue, Nov 07, 2023 at 10:53:00AM +0100 schrieb Sebastian Ramacher:
> Control: tags -1 moreinfo

I admit I'm not really happy about the bug ping-pong.
 
> > I just finished inspecting by eye the homepage of each of the 69 new
> > Bioconductor packages.  None of them declare a reverse-dependency to
> > an existing Bioc package that we ship in Debian.
> 
> We do not care about new reverse dependencies.

Seems there is some misunderstanding.  Charles has inspected pacckages
*outside* Debian whether they might be pulled by new versions of
packages *inside* Debian.  These would be candidates for new packages.

> We care about new
> dependencies of packages currently in the archive. So what's the status
> of new the dependencies?

Charles and I tried to explain in different ways: We do not have simple
means to answer this question.  But I had a different question;  What
exactly is the problem of a transition taking about 1 month due to some
delay by waiting for packages in new?
 
I somehow have the feeling that this transition is currently delayed by
some bug-mail / tagging ping-pong which is demotivating for both sides.
You make a request to some volunteers to do some extra work that was not
requested before and we volunteers explained that it is really hard
work.  I think it is fair to ask for the reasons you want us to do some
work which is definitely hard to do and for us painful and unproductive.

I have also no answer yet to some compromise to simply remove those
packages from testing that need new dependencies.  By doing so at least
to my naive understanding the transition should not create any blocker.

Kind regards
Andreas.

-- 
http://fam-tille.de

Bug#1054657: transition: r-bioc-biocgenerics

[Charles Plessy]

Le Tue, Nov 07, 2023 at 10:53:00AM +0100, Sebastian Ramacher a écrit :
> 
> We do not care about new reverse dependencies.

Hi Sebastian,

I am sorry that the information that I sent appears to have wasted your
time.  I still think that it does have some relevance, but I probably
did not explain my thougts well, and I worry that you have no appetite
for reading a longer version.

By the way, I work in a multicultural environment where most people are
not native speakers of English and we take great care of not hurting
each other in our oral and written communications.  Nobody would ever
start an answer like you did, and I feel like saying that I am not used
any more to that kind of communication.  Hence the unease that you can
probably feel from my reply.

> We care about new dependencies of packages currently in the archive.
> So what's the status of new the dependencies?

The tools available to us to answer your question are quite inexistant.
Until now we would just wait for the release team's green light to
ensure that we do not disturb other transitions.  The previous one was
more painful than usual, but in our experience it is quite rare.  I wish
you would trust our word instead of requiring quantitative evidence.

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

Still, that is quite an extensive amount of work, only to ensure that
the risk of asking the FTP team to fast-track a package is lowered to a
minimum.  We have done such requests in the past, and the response was
usually cheerful so unless you received complains form the FTP team, may
I suggest that you might be worrying too much?  And again, we are not
under the impression that this transition will be as demanding as the
past one.

Please let me I ask again for your kind understanding and allow us to do
the transition despite not being able to tell you if and how much the
transition will require the processing of packages through the NEW
queue.

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://fediscience.org/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Processed: Re: Bug#1054657: transition: r-bioc-biocgenerics

[Debian Bug Tracking System]

Processing control commands:

> tags -1 moreinfo
Bug #1054657 [release.debian.org] transition: r-bioc-biocgenerics
Added tag(s) moreinfo.

-- 
1054657: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054657
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1054657: transition: r-bioc-biocgenerics

[Sebastian Ramacher]

Control: tags -1 moreinfo

Hi Charles

On 2023-11-03 09:56:13 +0900, Charles Plessy wrote:
> > Am Wed, Nov 01, 2023 at 09:02:10AM -0100 schrieb Graham Inggs:
> > > Again, we are not asking for the entire transition to happen in
> > > experimental.  We are only asking for the NEW packages, so that NEW
> > > processing happens before the transition, and not during.
> 
> Le Wed, Nov 01, 2023 at 11:28:38AM +0100, Andreas Tille a écrit :
> > Understood this item now - but I'm lacking any clue how to find out
> > what new packages are needed.
> 
> Hi Graham and Andreas,
> 
> I just finished inspecting by eye the homepage of each of the 69 new
> Bioconductor packages.  None of them declare a reverse-dependency to
> an existing Bioc package that we ship in Debian.

We do not care about new reverse dependencies. We care about new
dependencies of packages currently in the archive. So what's the status
of new the dependencies?

Cheers
-- 
Sebastian Ramacher

Bug#1055487: nmu: openstructure_2.6.0~rc-1~exp spglib_2.1.0-1~exp

[Andrius Merkys]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

Hello,

I want to request binNMU on amd64 for packages recently accepted to 
experimental.


  nmu openstructure_2.6.0~rc-1~exp . amd64 . experimental . -m "Rebuild 
on buildd"

  nmu spglib_2.1.0-1~exp . amd64 . experimental . -m "Rebuild on buildd"

Thanks,
Andrius