Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1172960 > unrolled thread

Bug#1054657: transition: r-bioc-biocgenerics

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1054657: transition: r-bioc-biocgenerics Andreas Tille <tille@debian.org> - 2023-10-27 16:10 +0200
    Bug#1054657: transition: r-bioc-biocgenerics Dirk Eddelbuettel <edd@debian.org> - 2023-10-27 16:30 +0200
      Bug#1054657: transition: r-bioc-biocgenerics Andreas Tille <andreas@an3as.eu> - 2023-10-27 16:50 +0200
        Bug#1054657: transition: r-bioc-biocgenerics Dirk Eddelbuettel <edd@debian.org> - 2023-10-27 18:40 +0200
    Bug#1054657: transition: r-bioc-biocgenerics Graham Inggs <ginggs@debian.org> - 2023-10-28 19:00 +0200
      Bug#1054657: transition: r-bioc-biocgenerics Andreas Tille <tille@debian.org> - 2023-10-29 06:40 +0100
        Bug#1054657: transition: r-bioc-biocgenerics Graham Inggs <ginggs@debian.org> - 2023-10-29 17:10 +0100
          Bug#1054657: transition: r-bioc-biocgenerics Andreas Tille <tille@debian.org> - 2023-10-29 18:10 +0100
            Bug#1054657: transition: r-bioc-biocgenerics Graham Inggs <ginggs@debian.org> - 2023-11-01 11:10 +0100
              Bug#1054657: transition: r-bioc-biocgenerics Andreas Tille <tille@debian.org> - 2023-11-01 11:40 +0100
                Bug#1054657: transition: r-bioc-biocgenerics Charles Plessy <plessy@debian.org> - 2023-11-03 02:10 +0100
                  Bug#1054657: transition: r-bioc-biocgenerics Andreas Tille <tille@debian.org> - 2023-11-07 06:50 +0100
                  Bug#1054657: transition: r-bioc-biocgenerics Sebastian Ramacher <sramacher@debian.org> - 2023-11-07 11:00 +0100
                    Bug#1054657: transition: r-bioc-biocgenerics Charles Plessy <plessy@debian.org> - 2023-11-07 14:10 +0100
                      Bug#1054657: transition: r-bioc-biocgenerics Dirk Eddelbuettel <edd@debian.org> - 2023-11-07 14:50 +0100
                        Bug#1054657: transition: r-bioc-biocgenerics Andreas Tille <tille@debian.org> - 2023-11-07 15:10 +0100
                          Bug#1054657: transition: r-bioc-biocgenerics Dirk Eddelbuettel <edd@debian.org> - 2023-11-07 19:40 +0100
                            Bug#1054657: transition: r-bioc-biocgenerics Andreas Tille <tille@debian.org> - 2023-11-07 21:10 +0100
                    Bug#1054657: transition: r-bioc-biocgenerics Andreas Tille <tille@debian.org> - 2023-11-07 14:40 +0100
                      Bug#1054657: transition: r-bioc-biocgenerics Sebastian Ramacher <sramacher@debian.org> - 2023-11-07 15:20 +0100
                        Bug#1054657: transition: r-bioc-biocgenerics Andreas Tille <tille@debian.org> - 2023-11-07 18:10 +0100
          Bug#1054657: transition: r-bioc-biocgenerics Charles Plessy <plessy@debian.org> - 2023-11-01 08:40 +0100
    Bug#1054657: transition: r-bioc-biocgenerics Charles Plessy <plessy@debian.org> - 2023-11-09 15:10 +0100
      Bug#1054657: transition: r-bioc-biocgenerics Charles Plessy <plessy@debian.org> - 2023-11-10 09:50 +0100
        Bug#1054657: transition: r-bioc-biocgenerics Andreas Tille <tille@debian.org> - 2023-11-10 12:10 +0100
        Bug#1054657: transition: r-bioc-biocgenerics Sebastian Ramacher <sramacher@debian.org> - 2023-11-10 23:40 +0100
          Bug#1054657: transition: r-bioc-biocgenerics Charles Plessy <plessy@debian.org> - 2023-11-11 01:50 +0100
    Bug#1054657: transition: r-bioc-biocgenerics Andreas Tille <tille@debian.org> - 2023-11-10 23:40 +0100
      Bug#1054657: transition: r-bioc-biocgenerics Andreas Tille <tille@debian.org> - 2023-11-13 11:20 +0100
        Bug#1054657: transition: r-bioc-biocgenerics Graham Inggs <ginggs@debian.org> - 2023-11-19 16:40 +0100
        Bug#1054657: transition: r-bioc-biocgenerics Andreas Tille <andreas@an3as.eu> - 2023-11-22 21:00 +0100
          Bug#1054657: transition: r-bioc-biocgenerics Charles Plessy <plessy@debian.org> - 2023-11-28 01:30 +0100
            Bug#1054657: transition: r-bioc-biocgenerics Andreas Tille <tille@debian.org> - 2023-11-28 10:30 +0100
    Bug#1054657: r-bioc-sparsearray_1.0.12+dfsg-1_amd64.changes is NEW Andreas Tille <andreas@an3as.eu> - 2023-11-13 10:30 +0100
    Bug#1054657: transition: r-bioc-biocgenerics Andreas Tille <tille@debian.org> - 2023-11-24 22:30 +0100
    Bug#1054657: Transition issue for r-cran-rstanarm (Was: Bug#1055922: rmatrix: ABI change in Matrix 1.6-2) Andreas Tille <andreas@an3as.eu> - 2023-11-26 17:30 +0100
      Bug#1054657: Transition issue for r-cran-rstanarm (Was: Bug#1055922: rmatrix: ABI change in Matrix 1.6-2) Andreas Tille <andreas@an3as.eu> - 2023-11-28 10:20 +0100
    Bug#1054657: Transition issue for r-cran-rstanarm (Was: Bug#1055922: rmatrix: ABI change in Matrix 1.6-2) Graham Inggs <ginggs@debian.org> - 2023-11-28 11:40 +0100
      Bug#1054657: Transition issue for r-cran-rstanarm (Was: Bug#1055922: rmatrix: ABI change in Matrix 1.6-2) Andreas Tille <tille@debian.org> - 2023-11-28 16:00 +0100
        Bug#1054657: Transition issue for r-cran-rstanarm (Was: Bug#1055922: rmatrix: ABI change in Matrix 1.6-2) Graham Inggs <ginggs@debian.org> - 2023-11-29 14:40 +0100
    Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics) Andreas Tille <andreas@an3as.eu> - 2023-12-03 09:30 +0100
      Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics) Graham Inggs <ginggs@debian.org> - 2023-12-03 11:50 +0100
        Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics) Adrian Bunk <bunk@debian.org> - 2023-12-03 22:20 +0100
          Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics) Sebastian Ramacher <sramacher@debian.org> - 2023-12-05 15:50 +0100
      Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics) Graham Inggs <ginggs@debian.org> - 2023-12-07 15:40 +0100
        Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics) Andreas Tille <tille@debian.org> - 2023-12-07 16:20 +0100
          Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics) Andreas Tille <tille@debian.org> - 2023-12-07 16:40 +0100
          Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics) Adrian Bunk <bunk@debian.org> - 2023-12-07 19:40 +0100
          Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics) Sebastian Ramacher <sramacher@debian.org> - 2023-12-11 11:40 +0100
            Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics) Andreas Tille <tille@debian.org> - 2023-12-11 13:40 +0100
              Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics) Sebastian Ramacher <sramacher@debian.org> - 2023-12-11 13:40 +0100
                Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics) Andreas Tille <tille@debian.org> - 2023-12-11 17:10 +0100
                  Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics) Sebastian Ramacher <sramacher@debian.org> - 2023-12-11 18:00 +0100
        Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics) Charles Plessy <plessy@debian.org> - 2023-12-08 17:10 +0100
          Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics) Dirk Eddelbuettel <edd@debian.org> - 2023-12-08 17:40 +0100
      Bug#1054657: Transition ready? (Was: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)) Andreas Tille <andreas@an3as.eu> - 2023-12-13 11:50 +0100
        Bug#1054657: Transition ready? (Was: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)) Adrian Bunk <bunk@debian.org> - 2023-12-13 13:30 +0100
        Bug#1054657: Transition ready? (Was: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)) Graham Inggs <ginggs@debian.org> - 2023-12-13 14:20 +0100
          Bug#1054657: Transition ready? (Was: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)) Andreas Tille <tille@debian.org> - 2023-12-13 17:10 +0100
    Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics) Adrian Bunk <bunk@debian.org> - 2023-12-03 22:20 +0100
      Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics) Andreas Tille <tille@debian.org> - 2023-12-05 14:40 +0100
    Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics) Andreas Tille <tille@debian.org> - 2023-12-04 06:40 +0100
    Bug#1054657: Source download of DeMixT broken Andreas Tille <andreas@an3as.eu> - 2023-12-08 16:10 +0100
      Bug#1054657: Source download of DeMixT broken Andreas Tille <andreas@fam-tille.de> - 2023-12-12 15:10 +0100
    Bug#1054657: Source archive of DSS missing Andreas Tille <andreas@fam-tille.de> - 2023-12-08 16:10 +0100
      Bug#1054657: Source archive of DSS missing Andreas Tille <andreas@fam-tille.de> - 2023-12-12 15:20 +0100
    Bug#1054657: Transition ready? (Was: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)) Andreas Tille <tille@debian.org> - 2023-12-14 09:10 +0100
    Bug#1054657: Transition ready? (Was: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)) Graham Inggs <ginggs@debian.org> - 2023-12-17 16:20 +0100
      Bug#1054657: Transition ready? (Was: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)) Andreas Tille <tille@debian.org> - 2023-12-18 10:20 +0100

Page 1 of 4  [1] 2 3 4  Next page →

#1172960 — Bug#1054657: transition: r-bioc-biocgenerics

Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: transition
X-Debbugs-Cc: r-bioc-biocgenerics@packages.debian.org, debian-r@lists.debian.org
Control: affects -1 + src:r-bioc-biocgenerics

Hi,

BioConductor has just released version 3.17.  Since the next r-base
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
right now.  (No idea whether we will see a proper r-api transition but
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";

[toc] | [next] | [standalone]

#1172962

On 27 October 2023 at 16:00, Andreas Tille wrote:
| Package: release.debian.org
| Severity: normal
| User: release.debian.org@packages.debian.org
| Usertags: transition
| X-Debbugs-Cc: r-bioc-biocgenerics@packages.debian.org, debian-r@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 | edd@debian.org

[toc] | [prev] | [next] | [standalone]

#1172964

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.
 
Kind regards
    Andreas.

-- 
http://fam-tille.de

[toc] | [prev] | [next] | [standalone]

#1172977

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 | edd@debian.org

[toc] | [prev] | [next] | [standalone]

#1173158

Control: tags -1 + moreinfo

Hi Andreas

On Fri, 27 Oct 2023 at 14:03, Andreas Tille <tille@debian.org> wrote:
> 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.

Please remove the 'moreinfo' tag once all NEW packages needed for this
transition have been uploaded to experimental and have passed through
NEW review.

> 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";

I modified the tracker used for the previous transition and the output
can be viewed here:
https://release.debian.org/transitions/html/r-api-bioc-3.18.html
Please let me know if that doesn't look correct.

Regards
Graham

[toc] | [prev] | [next] | [standalone]

#1173197

Hi Graham,

Am Sat, Oct 28, 2023 at 04:55:24PM +0000 schrieb Graham Inggs:
> 
> Please remove the 'moreinfo' tag once all NEW packages needed for this
> transition have been uploaded to experimental and have passed through
> NEW review.

Can you confirm that packages uploaded to experimental can be moved in
one rush from experimental to unstable without extra uploads?  Do you
have this process in mind after the moreinfo tag is removed? 

Kind regards
     Andreas.

-- 
http://fam-tille.de

[toc] | [prev] | [next] | [standalone]

#1173257

Hi Andreas

On Sun, 29 Oct 2023 at 04:33, Andreas Tille <tille@debian.org> wrote:
> Can you confirm that packages uploaded to experimental can be moved in
> one rush from experimental to unstable without extra uploads?

I don't think this has ever been possible.  The packages would need to
be uploaded again to unstable, presumably at the appropriate
dependency level in the transition.

Seeing these packages would be NEW, even if they were initially
uploaded directly to unstable, they would likely still require
source-only uploads for migration anyway.

> Do you
> have this process in mind after the moreinfo tag is removed?

No, after the NEW packages have cleared NEW and the moreinfo tag is
removed, we'll consider a slot for the transition.  We would like to
avoid stalling the transition with multiple packages going through
NEW, and putting pressure on FTP Masters by telling them a package is
needed for a transition is not nice either.

Regards
Graham

[toc] | [prev] | [next] | [standalone]

#1173260

Hi Graham,

Am Sun, Oct 29, 2023 at 02:57:01PM -0100 schrieb Graham Inggs:
> Hi Andreas
> 
> On Sun, 29 Oct 2023 at 04:33, Andreas Tille <tille@debian.org> wrote:
> > Can you confirm that packages uploaded to experimental can be moved in
> > one rush from experimental to unstable without extra uploads?
> 
> I don't think this has ever been possible.  The packages would need to
> be uploaded again to unstable, presumably at the appropriate
> dependency level in the transition.

Sorry, my question was probably confusing.  I was not talking about the
new packages.  I was talking about the 170 r-bioc-* packages.  If I
upload these to experimental, will it be necessary to upload these to
unstable again or can these be moved to unstable in one rush.  Also
interesting in this connection:  Will the tracker display the levels
of packages uploaded to experimental?
 
> Seeing these packages would be NEW, even if they were initially
> uploaded directly to unstable, they would likely still require
> source-only uploads for migration anyway.

I'm comfortable with doing source-only uploads of packages that have
passed NEW.  I'm not comfortable with uploading 170 packages twice -
once to experimmental and once again to unstable.  Given that all
this work has mainly ended up on my shoulders I would prefer to
upload directly to unstable and simply bear with the waiting time
in NEW.

> > Do you
> > have this process in mind after the moreinfo tag is removed?
> 
> No, after the NEW packages have cleared NEW and the moreinfo tag is
> removed, we'll consider a slot for the transition. 

But you just mentioned the tracker in your previous mail[1].

> We would like to
> avoid stalling the transition with multiple packages going through
> NEW, and putting pressure on FTP Masters by telling them a package is
> needed for a transition is not nice either.

I admit I personally see the bigger drawback on spending my time twice
on 170 packages than waiting for new packages.  Please explain (again)
the real drawback of a transition that was delayed due to waiting for
new packages in total by estimated (not verified) by about two weeks.

Kind regards
   Andreas.

[1] https://release.debian.org/transitions/html/r-api-bioc-3.18.html

-- 
http://fam-tille.de

[toc] | [prev] | [next] | [standalone]

#1173476

HI Andreas

On Sun, 29 Oct 2023 at 16:06, Andreas Tille <tille@debian.org> wrote:
> Sorry, my question was probably confusing.  I was not talking about the
> new packages.  I was talking about the 170 r-bioc-* packages.  If I
> upload these to experimental, will it be necessary to upload these to
> unstable again or can these be moved to unstable in one rush.  Also
> interesting in this connection:  Will the tracker display the levels
> of packages uploaded to experimental?

I still don't think this has ever been possible.

> I'm comfortable with doing source-only uploads of packages that have
> passed NEW.  I'm not comfortable with uploading 170 packages twice -
> once to experimmental and once again to unstable.  Given that all
> this work has mainly ended up on my shoulders I would prefer to
> upload directly to unstable and simply bear with the waiting time
> in NEW.

Why do you want to upload 170 packages to experimental?  We are only
asking that the NEW packages involved be uploaded to experimental and
clear NEW review before we start the transition.

> But you just mentioned the tracker in your previous mail[1].

The tracker is visible [0], but is still in the 'Some planned
transitions' section along with many others.

> I admit I personally see the bigger drawback on spending my time twice
> on 170 packages than waiting for new packages.  Please explain (again)
> the real drawback of a transition that was delayed due to waiting for
> new packages in total by estimated (not verified) by about two weeks.

From what I saw in the last transition, r-bioc-biocgenerics was
uploaded on 2023-07-17, and the last package (I think) to clear NEW
was r-bioc-pfamanalyzer, which was accepted on 2023-08-15, almost one
month after the transition started.

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.

Regards
Graham


[0] https://release.debian.org/transitions/

[toc] | [prev] | [next] | [standalone]

#1173478

Hi Graham,

Am Wed, Nov 01, 2023 at 09:02:10AM -0100 schrieb Graham Inggs:
> > Sorry, my question was probably confusing.  I was not talking about the
> > new packages.  I was talking about the 170 r-bioc-* packages.  If I
> > upload these to experimental, will it be necessary to upload these to
> > unstable again or can these be moved to unstable in one rush.  Also
> > interesting in this connection:  Will the tracker display the levels
> > of packages uploaded to experimental?
> 
> I still don't think this has ever been possible.

Thanks for the clarification.  In the last transition someone stated
this might be possible.
 
> > I'm comfortable with doing source-only uploads of packages that have
> > passed NEW.  I'm not comfortable with uploading 170 packages twice -
> > once to experimmental and once again to unstable.  Given that all
> > this work has mainly ended up on my shoulders I would prefer to
> > upload directly to unstable and simply bear with the waiting time
> > in NEW.
> 
> Why do you want to upload 170 packages to experimental?  We are only
> asking that the NEW packages involved be uploaded to experimental and
> clear NEW review before we start the transition.

The point is that we simply have no better means to know what new
packages might be required.  We simply learn about new requirements by
building the new version of the r-bioc-* packages == in the process of
the transition.  Thus someone suggested to do the transition completely
inside experimental.  If there is no chance to move packages from
experimental to unstable without a fresh upload (which I doubted myself
- thanks for confirming) its in fact no option to build everything
in experimental first.
 
> > But you just mentioned the tracker in your previous mail[1].
> 
> The tracker is visible [0], but is still in the 'Some planned
> transitions' section along with many others.

Ahhh, OK.
 
> > I admit I personally see the bigger drawback on spending my time twice
> > on 170 packages than waiting for new packages.  Please explain (again)
> > the real drawback of a transition that was delayed due to waiting for
> > new packages in total by estimated (not verified) by about two weeks.
> 
> >From what I saw in the last transition, r-bioc-biocgenerics was
> uploaded on 2023-07-17, and the last package (I think) to clear NEW
> was r-bioc-pfamanalyzer, which was accepted on 2023-08-15, almost one
> month after the transition started.

Maybe it has lasted for one month.  I admit I personally see no drawback
in this time frame but possibly I'm to less involved of the work of the
release team to understand this.  If it is a real problem I might
imagine to remove those (few, mostly not more than 5-10) leaf packages
that really need those new dependencies from testing so the majority of
the packages can migrate?  I honestly try to understand this issue since
for the moment our only strategy to upgrade to new BioConductor is to
simply build the tree of dependencies and see what is happening.

> 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.

Understood this item now - but I'm lacking any clue how to find out
what new packages are needed.

Kind regards and thanks a lot for your patience

     Andreas.

> [0] https://release.debian.org/transitions/

-- 
http://fam-tille.de

[toc] | [prev] | [next] | [standalone]

#1173668

> 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.  Therefore, I do not
expect that this transition will require NEW processing.

https://bioconductor.org/news/bioc_3_18_release/

Graham, please let us know when we can start uploading.

Have a nice day,

Charles

-- 
Charles Plessy                         Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team         http://www.debian.org/devel/debian-med
Tooting from home                  https://framapiaf.org/@charles_plessy
- You  do not have  my permission  to use  this email  to train  an AI -

[toc] | [prev] | [next] | [standalone]

#1174102

Control: tags -1 - moreinfo

Removing moreinfo tag since according to the investigation of Charles
gave some data points that we do not expect any new Bioconductor
packages (while we did not checked for any new CRAN packages.)

If this is not sufficient please be so kind to explain the problem of a
one month lasting transition.  I would estimate it takes also about one
month for a single developer to check the full dependency tree.

Kind regards
    Andreas.

Am Fri, Nov 03, 2023 at 09:56:13AM +0900 schrieb Charles Plessy:
> > 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.  Therefore, I do not
> expect that this transition will require NEW processing.
> 
> https://bioconductor.org/news/bioc_3_18_release/
> 
> Graham, please let us know when we can start uploading.
> 
> Have a nice day,
> 
> Charles
> 
> -- 
> Charles Plessy                         Nagahama, Yomitan, Okinawa, Japan
> Debian Med packaging team         http://www.debian.org/devel/debian-med
> Tooting from home                  https://framapiaf.org/@charles_plessy
> - You  do not have  my permission  to use  this email  to train  an AI -
> 
> 

-- 
http://fam-tille.de

[toc] | [prev] | [next] | [standalone]

#1174114

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

[toc] | [prev] | [next] | [standalone]

#1174145

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

[toc] | [prev] | [next] | [standalone]

#1174148

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 | edd@debian.org

[toc] | [prev] | [next] | [standalone]

#1174150

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

[toc] | [prev] | [next] | [standalone]

#1174180

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 | edd@debian.org

[toc] | [prev] | [next] | [standalone]

#1174196

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

[toc] | [prev] | [next] | [standalone]

#1174147

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

[toc] | [prev] | [next] | [standalone]

#1174151

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | linux.debian.bugs.dist

csiph-web