Contacting Release team with invitation to DebConf talk and specific questions to team members
Hi, while I contacted the release team previously[0] there was no response so far. I tried to establish this first contact since I consider the release team of really high relevance. Meanwhile I have added some more information to my contact mails including advertising a DebConf event (see below). I also added some question and tried to keep every team member in CC. I'd be really happy if you would find some time to answer my questions at the end of this mail (preferably in public on the list but private answers are fine as well. I'd like to officially contact all our teams to learn about potential issues that might affect your work. I would love to learn how you organise / share your workload. If you do some regular meetings - be it on IRC, video conference or whatever I'm interested in joining one of your next meetings. Like previous DPLs, I'm open to any inquiries or requests for assistance. I personally prefer public discussion whenever possible, as they can benefit a wider audience. You can find a list of contact options at the bottom of my page on people.d.o[1]. I prefer being offline when I'm away from my keyboard, so I don't carry a phone. In urgent situations, I can provide the number of my dumb phone, though it may not always be within reach. Feel free to ping me via email if I don't respond promptly to ensure I address your concerns. Please let me know whether I can do something for you. I'm fine joining your IRC channel if needed but please invite me in case I should be informed about some urgent discussion there since I normally do not lurk on this channel. I'd also like to inform you that I've registered a BoF for DebConf24 in Busan with the following description: This BoF is an attempt to gather as much as possible teams inside Debian to exchange experiences, discuss workflows inside teams, share their ways to attract newcomers etc. Each participant team should prepare a short description of their work and what team roles (“openings”) they have for new contributors. Even for delegated teams (membership is less fluid), it would be good to present the team, explain what it takes to be a team member, and what steps people usually go to end up being invited to participate. Some other teams can easily absorb contributions from salsa MRs, and at some point people get commit access. Anyway, the point is that we work on the idea that the pathway to become a team member becomes more clear from an outsider point-of-view. I'm sure not everybody will be able to travel this distance but it would be great if you would at least consider joining that BoF remotely. I'll care for a somehow TimeZone aware scheduling - if needed we'll organise two BoFs to match all time zones. I'm also aware that we have pretty different teams and it might make sense to do some infrastructure related BoF with your team and other teams that are caring for Debian infrastructure. I have some specific questions to the FIXME team. - Do you feel good when doing your work in FIXME team? - Do you consider the workload of your team equally shared amongst its members? - Do you have some strategy to gather new contributors for your team? - Can you give some individual estimation how many hours per week you are working on your tasks in youre team? Does this fit the amount of time you can really afford for this task? - Since the release team is an appointed team please let me know if I need to send out a new appointment. - Can I do anything for you? Kind regards and thanks a lot for your work Andreas. [0] https://lists.debian.org/debian-release/2024/05/msg00114.html [1] https://people.debian.org/~tille/ -- https://fam-tille.de signature.asc Description: PGP signature
Bug#1070723: bullseye-pu: package bart/0.6.00-3+deb11u1
Am Wed, May 08, 2024 at 01:18:44AM +0200 schrieb Santiago Vila: > Package: release.debian.org > Severity: normal > Tags: bullseye > User: release.debian@packages.debian.org > Usertags: pu > X-Debbugs-Cc: b...@packages.debian.org, sanv...@debian.org > Control: affects -1 + src:bart > > [ Reason ] > This upload fixes Bug #1026061 FTBFS randomly in bullseye. Thanks a lot Santiago for your great QA work Andreas. -- https://fam-tille.de
Contacting Release team
Hi, as promised I'd like to contact all teams inside Debian which I like to do today to the release team. Currently I don't have any urgent questions for your team. More general I would love to learn how you organise / share your workload. Do you have some regular team meatings? If yes I'd love to join one of the next ones. Like previous DPLs, I'm open to any inquiries or requests for assistance. I personally prefer public discussions whenever possible, as they can benefit a wider audience. You can find a list of contact options at the bottom of my page on people.d.o[1]. I prefer being offline when I'm away from my keyboard, so I don't carry a phone. In urgent situations, I can provide the number of my dumb phone, though it may not always be within reach. Feel free to ping me if I don't respond promptly to ensure I address your concerns. Please let me know whether I can do something for you. I'm fine joining your IRC channel if needed but please invite me in case I should be informed about some urgent discussion there since I normally do not lurk on this channel. Hopefully see you in Busan - at least one member of your team if possible Andreas. [1] https://people.debian.org/~tille/ -- https://fam-tille.de signature.asc Description: PGP signature
Re: Status of the t64 transition
Hi Sebastian, thank you for your work on t64 transition. Am Thu, Apr 18, 2024 at 09:22:02PM +0200 schrieb Sebastian Ramacher: I've spotted these Debian Med packages. > gentle > jellyfish > quorum > sbmltoolbox No idea how we can help here. Please let us know if we can do something. > anfo We like to fix gcc-12 issues (#1012893) in anfo but so far nobody managed to do so since it seems to be quite complex. If we are blocking progress with this package its probably a sign that it should be removed from Debian. > blasr We try to work on #1067374. > freebayes Upstream is working on bug #1067271. > vg This package is in a bad state in any case and we are aware of this. However, could you explain in how far is this affecting t64 transition since 32bit architectures are excluded? > If you maintain any of the packages above, please check their status and > help get them fixed. Any help in filing bugs, fixing packages, > requesting removals, etc. is appreciated so that we can look into > unblocking the whole stack and migrate it to testing. I fixed two packages of Debian Python Team and pinged about some packages in Debian Science Team. Kind regards Andreas. -- https://fam-tille.de
Bug#1054657: Transition ready? (Was: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics))
Hi Graham, Am Sun, Dec 17, 2023 at 02:11:47PM -0100 schrieb Graham Inggs: > There are some packages that have still not migrated since the > previous r-api-bioc-3.17 transition in July 2023. > > Links to their tracker pages, which should tell you what is needed, follow: > > https://tracker.debian.org/pkg/r-bioc-cner Fixed. > https://tracker.debian.org/pkg/r-bioc-dada2 > https://tracker.debian.org/pkg/r-bioc-edaseq > https://tracker.debian.org/pkg/r-bioc-ioniser Due to shortread. > https://tracker.debian.org/pkg/r-bioc-megadepth d/tests/control has Architecture: !s390x Why is it considered failing on s390x anyway? > https://tracker.debian.org/pkg/r-bioc-scater While this is an Architecture:all package it Depends from r-bioc-densvis which exists only on amd64 and arm64 due to the Build-Depends: r-bioc-basiklisk. Thus tests on other architectures are failing since r-bioc-densvis is not installable. What solution do you suggest in this case? > https://tracker.debian.org/pkg/r-bioc-shortread Fixed. > https://tracker.debian.org/pkg/r-bioc-tcgabiolinks Reported upstream ( https://github.com/BioinformaticsFMRP/TCGAbiolinks/issues/612 ) > https://tracker.debian.org/pkg/r-bioc-tfbstools Due to cner which is fixed. > As a bonus, here's another, not related to the transition, but from a > similar time: > https://tracker.debian.org/pkg/r-cran-dials Forgot source-only upload - done. Thanks a lot for the links Andreas. -- http://fam-tille.de
Bug#1054657: Transition ready? (Was: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics))
Hi Paul, Am Wed, Dec 13, 2023 at 09:56:14PM +0100 schrieb Paul Gevers: > > > Not built on buildd: arch all binaries uploaded by tille, a new > > > source-only upload is needed to allow migration > > > > I do not understand this line. What exact package needs a source-only > > upload? > > You uploaded binaries together with the source. Because this is an arch:all > binary we can't binNMU in a meaningful way and we don't accept uploader > built binaries in testing anymore. Currently the only way to solve this is > by doing a source-only (so, no binaries) upload (of r-bioc-biocgenerics). This must have been by pure accident since I never do so except for packages targeting new. I did a source-only upload for r-bioc-biocgenerics. > > Please let me know if I > > can do something to fix the situation, but for the moment I have no idea > > what to do. > > Patches for britney2 please ;). I'm using this chance to thank you for all your work in the release team and patchinbg britney2 at least to the current state. > I'll try to do some manual triggering of tests tonight/tomorrow, but after a > quick glance, that might be too much to handle manually. > > Paul > > [1] https://tracker.debian.org/pkg/r-bioc-biocgenerics > [tracker] https://tracker.debian.org/teams/r-pkg-team/ the piece below > Packages with test failures: if it goes from passing in testing to fail in > unstable there is potentially a problem This tracker page was new to me and is extremely helpful! Thanks to whoever this thanks deserves. Very helpful also for other teams I'm working in. > [excuses] https://release.debian.org/britney/update_excuses.html > [yaml] https://release.debian.org/britney/excuses.yaml.gz Well, it also points to several pandoc related issues which I can't do anything about. > [britney2] > https://salsa.debian.org/release-team/britney2/-/blob/master/britney2/policies/autopkgtest.py#L622 > until line 743 Please let me know when I (realistically) can do more than just that source-only upload mentioned above. Kind regards Andreas. -- http://fam-tille.de
Bug#1054657: Transition ready? (Was: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics))
Hi Graham, Am Wed, Dec 13, 2023 at 12:13:54PM -0100 schrieb Graham Inggs: > I've added removal hints for r-bioc-dss and r-bioc-demixt. Please > file an RC bug for r-bioc-dss to prevent it from migrating straight > back (r-bioc-demixt already has #1058278). Done for r-bioc-dss. > One problem I see at [1]: > > Not built on buildd: arch all binaries uploaded by tille, a new > source-only upload is needed to allow migration I do not understand this line. What exact package needs a source-only upload? > Remember, all r-bioc-* packages need to migrate together, so all of > your uploads need to be ready before r-bioc-biocgenerics can migrate. > I checked only the first few "Migrates after" links from [1], and > found at least these packages still show autopkgtest regressions > [2][3][4][5][6]. Thank you for these links. Could you please explain how I can obtain these myself? Is there any page I could look at for some kind of summary? Now to these links: > > [1] https://tracker.debian.org/pkg/r-bioc-biocgenerics OK, no idea what source-only upload is needed (see above). > [2] https://tracker.debian.org/pkg/r-bioc-beachmat This shows: autopkgtest for r-bioc-biocsingular/1.16.0+ds-1: amd64: Regression or new test... but that version of r-bioc-biocsingular is in testing and bound to fail. Version 1.18.0+ds matches to BioC API 3.18. Autopkgtest in Salsa CI works as expected. When looking in debci (https://ci.debian.net/packages/r/r-bioc-biocsingular/unstable/amd64/40579344/) the test suite error is caused by pandoc. > [3] https://tracker.debian.org/pkg/r-bioc-biobase Same here: autopkgtest for r-bioc-degreport/1.36.0+dfsg-1: amd64: Regression or new test... we have r-bioc-degreport 1.38.3+dfsg-1 in unstable matching BioC API 3.18. Failures with any former version is bound to fail. Similarly: autopkgtest for r-bioc-multiassayexperiment/1.26.0+dfsg-1: amd64: Regression or new test... version in testing not unstable > [4] https://tracker.debian.org/pkg/r-bioc-biocbaseutils See above autopkgtest for r-bioc-multiassayexperiment/1.26.0+dfsg-1: amd64: Regression or new test... > [5] https://tracker.debian.org/pkg/r-bioc-biocio > [6] https://tracker.debian.org/pkg/r-bioc-biostrings Same problem as above autopkgtest for r-bioc-bsgenome/1.68.0-1: amd64: Regression or new test... in both cases. I admit I have no idea what to do. If the migration issues are caused by running tests against versions in testing which can't pass something is broken. As you wrote above > Remember, all r-bioc-* packages need to migrate together, ... yes, that's why running debci tests is not needed - at least as far as I understood the purpose of a transition. Please let me know if I can do something to fix the situation, but for the moment I have no idea what to do. Sorry if I'm a bit slow to catch on. Kind regards Andreas. -- http://fam-tille.de
Bug#1054657: Transition ready? (Was: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics))
Hi, as you might have noticed the upstream source for r-bioc-dss and r-bioc-demixt are missing and upstream did not answered two mails about this. Since the transition looks clean for me so far[1] after I fixed two autopkgtest issues yesterday I (naively) think we could remove r-bioc-dss and r-bioc-demixt from testing and all other packages can migrate to finish the transition from r-bioc perspective. I'm wondering what I can do in some cases that are caused by the pandoc issue like shortread[2] which should be solved in principle. I'm worried about issues in r-rcan-rmarkdown[3] and r-cran-flextable[4] which are caused by pandoc errors on ppc64el architecture *only*. That's really strange and might mean that pandoc on this architecture is broken? Regarding pandoc I've just uploaded a fix for pypandoc (fixing bugs #1057946 and #1058153) I have neither any clue nor any time to check nbconvert. Kind regards Andreas. [1] https://tracker.debian.org/pkg/r-bioc-biocgenerics [2] https://tracker.debian.org/pkg/r-bioc-shortread [3] https://ci.debian.net/packages/r/r-cran-rmarkdown/testing/ppc64el/40945637/ [4] https://ci.debian.net/packages/r/r-cran-flextable/testing/ppc64el/40945625/ -- http://fam-tille.de
Bug#1054657: Source archive of DSS missing
Hi, could someone please have a look at the source download? Thank you Andreas. Am Fri, Dec 08, 2023 at 04:04:27PM +0100 schrieb Andreas Tille: > Hi, > > when looking at > > https://bioconductor.org/packages/release/bioc/html/DSS.html > > and following the link "Source Archive" at bottom of the page linking > to > https://bioconductor.org/packages/3.18/bioc/src/contrib/Archive/DSS/ > > I can only see > >Page Not Found >The page you were looking for was not found. > > I'm trying to upgrade the Debian package of DSS to its latest version > and would need the source tarball which can be usually downloaded from > the "Source Archive" link. > > Kind regards > Andreas. > > -- > http://fam-tille.de -- http://fam-tille.de
Bug#1054657: Source download of DeMixT broken
Hi again, could someone please have a look at the source download? Thank you Andreas. Am Fri, Dec 08, 2023 at 04:01:17PM +0100 schrieb Andreas Tille: > Hi, > > when looking at > > https://bioconductor.org/packages/release/bioc/html/DeMixT.html > > and following the link "Source Archive" at bottom of the page linking > to > https://bioconductor.org/packages/3.18/bioc/src/contrib/Archive/DeMixT/ > > I can only see > >Page Not Found >The page you were looking for was not found. > > I'm trying to upgrade the Debian package of DeMixT to its latest version > and would need the source tarball which can be usually downloaded from > the "Source Archive" link. > > Kind regards > Andreas. > > -- > http://fam-tille.de -- http://fam-tille.de
Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)
Am Mon, Dec 11, 2023 at 01:36:38PM +0100 schrieb Sebastian Ramacher: > > OK, but what is your suggestion? Reverting and have broken tests due to > > the pandoc issue? > > pandoc is fixed in unstable. Really? Salsa CI[1] says: pandoc : Depends: pandoc-data (>= 3.0.1+ds) but 3.0.1-3 is to be installed I uploaded anyway and hope this will be cured somehow. Kind regards Andreas. [1] https://salsa.debian.org/r-pkg-team/r-cran-rmarkdown/-/jobs/5026534 -- http://fam-tille.de
Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)
Hi Sebastian, Am Mon, Dec 11, 2023 at 11:29:24AM +0100 schrieb Sebastian Ramacher: > > > I found a workaround; demote pandoc from a Depends to a Recommends in > > > the r-cran-rmarkdown package. It seems that pandoc is not used for > > > building, at least for r-bioc-biovizbase, -degnorm, -ioniser, scrnaseq > > > and -tximeta, which I tried. > > > > Thanks for the patch - applied and uploaded. > > This change broke autopkgtests of reverse dependencies. OK, but what is your suggestion? Reverting and have broken tests due to the pandoc issue? Kind regards Andreas. -- http://fam-tille.de
Bug#1054657: Source archive of DSS missing
Hi, when looking at https://bioconductor.org/packages/release/bioc/html/DSS.html and following the link "Source Archive" at bottom of the page linking to https://bioconductor.org/packages/3.18/bioc/src/contrib/Archive/DSS/ I can only see Page Not Found The page you were looking for was not found. I'm trying to upgrade the Debian package of DSS to its latest version and would need the source tarball which can be usually downloaded from the "Source Archive" link. Kind regards Andreas. -- http://fam-tille.de
Bug#1054657: Source download of DeMixT broken
Hi, when looking at https://bioconductor.org/packages/release/bioc/html/DeMixT.html and following the link "Source Archive" at bottom of the page linking to https://bioconductor.org/packages/3.18/bioc/src/contrib/Archive/DeMixT/ I can only see Page Not Found The page you were looking for was not found. I'm trying to upgrade the Debian package of DeMixT to its latest version and would need the source tarball which can be usually downloaded from the "Source Archive" link. Kind regards Andreas. -- http://fam-tille.de
Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)
Am Thu, Dec 07, 2023 at 04:09:28PM +0100 schrieb Andreas Tille: > I'll take this > occurence as a reason to fail with an error in dh-r to avoid such cases > in future. Done in https://salsa.debian.org/r-pkg-team/dh-r/-/commit/e4c348832b3d99ba7bc8f7670085b9b21323f7b6 The check could be even more strict but should be sufficient for those practical cases that occured in the past. Thanks for Graham for spotting the issue Andreas. -- http://fam-tille.de
Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)
Hi Graham, Am Thu, Dec 07, 2023 at 01:37:02PM -0100 schrieb Graham Inggs: > On Sun, 3 Dec 2023 at 07:21, Andreas Tille wrote: > > I have no idea how to work around this. > > I found a workaround; demote pandoc from a Depends to a Recommends in > the r-cran-rmarkdown package. It seems that pandoc is not used for > building, at least for r-bioc-biovizbase, -degnorm, -ioniser, scrnaseq > and -tximeta, which I tried. Thanks for the patch - applied and uploaded. > Do you know why r-bioc-metagenomeseq is considered neither good nor > bad in the tracker? Argh, upstream has messed up DESCRIPTION/git_branch which we trust to detect r-bioc-api. This is fixed[1] and uploaded. I'll take this occurence as a reason to fail with an error in dh-r to avoid such cases in future. > Also, why do r-bioc-netsam and r-bioc-org.hs.eg.db not even appear on > the tracker? I was always wondering about this but I have no clue. r-bioc-go.db is the third example in this row. I was updating these in past transitions manually which is IMHO no big harm - but I simply don't understand. Kind regards Andreas. [1] https://salsa.debian.org/r-pkg-team/r-bioc-metagenomeseq/-/blob/master/debian/patches/fix_git_branch.patch -- http://fam-tille.de
Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)
Hi Adrian, Am Sun, Dec 03, 2023 at 11:15:49PM +0200 schrieb Adrian Bunk: > > And it also means that r-bioc-biocgenerics is now blocked on the haskell > > transition. Lovely. Good thing that pandoc is supposed to be the last piece > > in that several months long transition. > > It's only blocked by the pandoc part of the Haskell transition, > it shouldn't be blocked by the other remaining parts of the > transition or by getting the transition into testing. Is there any chance to upload a working pandoc to unstable? Nearly all r-* package tests I tried in upgrades are broken and I'd like to know when it makes sense again to touch those packages. Kind regards Andreas. -- http://fam-tille.de
Bug#1054657: Removed in Bioconductor 3.18: NanoStringQCPro
Hi Steffen, you are listed as Uploader of r-bioc-nanostringqcpro. This package was removed by Bioconductor in release 3.18. Please decide what to do with this package and act accodingly. Kind regards Andreas. -- http://fam-tille.de
Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)
Hi, Am Sun, Dec 03, 2023 at 09:51:38PM +0100 schrieb Paul Gevers: > > And it also means that r-bioc-biocgenerics is now blocked on the haskell > transition. Lovely. Good thing that pandoc is supposed to be the last piece > in that several months long transition. ... which on the other hand shows, that new packages have never been the main blocker in r-bioc-* transitions (even if I confirm I'm happy that you convinced us to get rid of this reason). Kind regards Andreas. -- http://fam-tille.de
Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)
Hi, Charles Plessy and I uploaded r-bioc-* packages until level 11. Unfortunately building of some packages seems to be blocked for A: some pandoc dependency reason pandoc depends on missing: - pandoc-data:amd64 (< 2.17.1.1-3.~) https://buildd.debian.org/status/package.php?p=r-bioc-biovizbase B: for non-obvious reasons https://buildd.debian.org/status/package.php?p=r-bioc-ioniser https://buildd.debian.org/status/package.php?p=r-bioc-scrnaseq https://buildd.debian.org/status/package.php?p=r-bioc-tximeta I have no idea how to work around this. Kind regards Andreas. -- http://fam-tille.de
Bug#1054657: Transition issue for r-cran-rstanarm (Was: Bug#1055922: rmatrix: ABI change in Matrix 1.6-2)
Hi Graham, Am Tue, Nov 28, 2023 at 09:29:41AM -0100 schrieb Graham Inggs: > > for tests that run successfully on all architectures where they are > > triggered (as in, where at least some of the binaries build by the > > source are installable). As the failure isn't a regression, the > > migration isn't blocked, though. > > I noticed this today, and added an age hint for r-cran-seurat so it > should migrate soon. Thanks a lot for this. > On Mon, 27 Nov 2023 at 23:22, Charles Plessy wrote: > > would it be possible to have an estimation about when we can expect to > > start the Bioconductor transition ? > > We recently announced that britney now considers mips64el to be an > out-of-sync architecture [1]. We are finding other systems; e.g. UDD > and BTS, also need changes to accommodate this. We hope to have this > resolved and for you to be able to start your transition within the > next few days. We don't want to start a big transition and have it > blocked on missing builds or installability issues on mips64el. Perfectly understandable. > On Sun, 26 Nov 2023 at 15:20, Andreas Tille wrote: > > I've asked ftpmaster for removal (see bug #1056913) of some architecture > > builds for r-cran-rstan which is preventing the migration of this > > package. > > It seems the armel build was retried by someone and it succeeded [2]. > Fixing the riscv64 build (where it built previously) would be nice, as > riscv64 is aiming to be a release architecture for trixie, but I do > not see that being a blocker for this transition. I confirm having all achitectures building would be great, specifically all 64bit architectures which are potentially used architectures, thought. As a general statement I'm personally lacking knowledge and time to resolve issues like this but try to inform upstream at least. Actually risc64 is not affected by #1056913 which seems to have resolved now for all architectures except mips64el which is to be expected. Thus I will close the said bug. > > There is another issue for r-cran-rstan which affects a regression > > for r-cran-projpred for ppc64el architecture[1] which boils down to: > > ... > > It seems something on this architecture is broken I can't do anything > > about. Could you provide help here? > > It looks like this was also retried and succeeded [3]. Looks good. So if I understood correctly we are now rather waiting for some infrastructure issues to start the transition and we should simply sit-n-wait for the green light, right? Kind regards Andreas. > [1] https://lists.debian.org/debian-devel-announce/2023/11/msg5.html > [2] https://buildd.debian.org/status/package.php?p=r-cran-rstanarm > [3] https://ci.debian.net/packages/r/r-cran-projpred/testing/ppc64el/ > > -- http://fam-tille.de
Bug#1054657: transition: r-bioc-biocgenerics
Am Tue, Nov 28, 2023 at 09:22:18AM +0900 schrieb Charles Plessy: > would it be possible to have an estimation about when we can expect to > start the Bioconductor transition ? I am contributing to Debian mostly > on my work time and it would be super useful for me to have this > information in order to better integrate it in my planning. See my other mail about the current delay. Probably we both missed the "and" in the condition to remove the moreinfo tag[1] > Regarding my unavailable dates: it is Dec 2nd to 11th, and 23rd to Jan > 8th. > > The next Bioconductor release has not been announced but will probably > take place in April or May 2024. As time passes I am starting to wonder > if we should just skip the current one... I do not think we should skip any release since we might face unexpected effects from that skip. Release team has spotted the unexpected new packages as blocker - fine, we seem to have dealt with this. If now real life of lack of developer time will come in as an alternative blocker and the transition will take longer than usual this is probably nothing we can fix technically. Kind regards Andreas. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054657#189 -- http://fam-tille.de
Bug#1054657: Transition issue for r-cran-rstanarm (Was: Bug#1055922: rmatrix: ABI change in Matrix 1.6-2)
Hi again, Am Sun, Nov 26, 2023 at 05:20:27PM +0100 schrieb Andreas Tille: > > > The remaining regressions seen are caused by unrelated uploads of > > > r-cran-seurat/r-cran-seuratobject on 2023-11-01 and > > r-cran-seuratobject 5.0.1-1 has migrated to testing today. > r-cran-seurat had not passed waiting time. I have no idea why r-cran-seurat is not profiting from reduced waiting time for the transition. > > > r-cran-rstan/r-cran-rstanarm on 2023-10-27 which have not yet > > > migrated. > > I've asked ftpmaster for removal (see bug #1056913) of some architecture > builds for r-cran-rstan which is preventing the migration of this > package. > > There is another issue for r-cran-rstan which affects a regression > for r-cran-projpred for ppc64el architecture[1] which boils down to: > > 53s Unpacking pandoc (2.17.1.1-3) ... > 54s dpkg-deb: error: subprocess was killed by signal (Killed) > 54s dpkg: error processing archive > /tmp/apt-dpkg-install-geka0F/120-pandoc_2.17.1.1-3_ppc64el.deb (--unpack): > 54s cannot copy extracted data for './usr/bin/pandoc' to > '/usr/bin/pandoc.dpkg-new': unexpected end of file or stream > ... > 71s Errors were encountered while processing: > 71s /tmp/apt-dpkg-install-geka0F/120-pandoc_2.17.1.1-3_ppc64el.deb > 72s E: Sub-process /usr/bin/dpkg returned an error code (1) It seems this is solved now. Currently r-cran-rstan seems to wait only for r-cran-quickjsr (which I uploaded yesterday unfortunately but this should be done tomorrow so even before the unexpectedly long waiting period for r-cran-seurat will end). Kind regards Andreas. > [1] > https://ci.debian.net/data/autopkgtest/testing/ppc64el/r/r-cran-projpred/40151666/log.gz -- http://fam-tille.de
Bug#1054657: Transition issue for r-cran-rstanarm (Was: Bug#1055922: rmatrix: ABI change in Matrix 1.6-2)
Hi Graham, Am Fri, Nov 24, 2023 at 10:20:38PM +0100 schrieb Andreas Tille: > > Closing now because there's nothing to be done in rmatrix. > > > > The remaining regressions seen are caused by unrelated uploads of > > r-cran-seurat/r-cran-seuratobject on 2023-11-01 and r-cran-seuratobject 5.0.1-1 has migrated to testing today. r-cran-seurat had not passed waiting time. > > r-cran-rstan/r-cran-rstanarm on 2023-10-27 which have not yet > > migrated. I've asked ftpmaster for removal (see bug #1056913) of some architecture builds for r-cran-rstan which is preventing the migration of this package. There is another issue for r-cran-rstan which affects a regression for r-cran-projpred for ppc64el architecture[1] which boils down to: 53s Unpacking pandoc (2.17.1.1-3) ... 54s dpkg-deb: error: subprocess was killed by signal (Killed) 54s dpkg: error processing archive /tmp/apt-dpkg-install-geka0F/120-pandoc_2.17.1.1-3_ppc64el.deb (--unpack): 54s cannot copy extracted data for './usr/bin/pandoc' to '/usr/bin/pandoc.dpkg-new': unexpected end of file or stream ... 71s Errors were encountered while processing: 71s /tmp/apt-dpkg-install-geka0F/120-pandoc_2.17.1.1-3_ppc64el.deb 72s E: Sub-process /usr/bin/dpkg returned an error code (1) It seems something on this architecture is broken I can't do anything about. Could you provide help here? Kind regards Andreas. [1] https://ci.debian.net/data/autopkgtest/testing/ppc64el/r/r-cran-projpred/40151666/log.gz -- http://fam-tille.de
Bug#1054657: transition: r-bioc-biocgenerics
Hi Paul, Am Fri, Nov 24, 2023 at 11:17:34AM +0100 schrieb Paul Gevers: > On Wed, 22 Nov 2023 20:46:17 +0100 Andreas Tille wrote: > > Control: tags -1 - moreinfo > > > > r-bioc-sparsearray is accepted in unstable. > > Well, Graham wrote "remove the 'moreinfo' tag once SparseArray has cleared > NEW, and rmatrix has migrated." > ^^^ > Note the "and". Ahhh, yes, I ignored this unfortunately. > We're currently handling that, but rmatrix was blocked by r-cran-seurat, > which, IIUC, is in that state because you updated r-cran-seuratobject three > weeks ago. I admit two uploads of r-cran-seuratobject I assumed I would have pushed where caught by some weak network. That was fixed earlier today and I also fixed r-cran-seurat which needed a stricter versioned Depends than declared by upstream. > We're still waiting for the migration of rmatrix to succeed. I also was able to fix r-cran-rstanarm right now (hopefully). I'll be offlineish until Sunday afternoon - so hopefully all will go smoothly. Thanks a lot for your patience and have fun in Cambridge Andreas. -- http://fam-tille.de
Bug#1054657: transition: r-bioc-biocgenerics
Control: tags -1 - moreinfo r-bioc-sparsearray is accepted in unstable. Kind regards Andreas. -- http://fam-tille.de
Re: Matrix update triggering need for four rebuilds
Am Fri, Nov 17, 2023 at 10:12:02AM -0600 schrieb Dirk Eddelbuettel: > Leaving > >r-cran-irlba >r-cran-openmx > > for you (unless you got to it already). To make it pretty clear: I will not simply rebuild these packages before we have a promising solution for the future. If you do not agree with this you can either * Ask for Bin-NMU which should be sufficient * Do a team upload Kind regards Andreas. -- http://fam-tille.de
Re: Matrix update triggering need for four rebuilds
Am Tue, Nov 14, 2023 at 04:49:01PM -0600 schrieb Dirk Eddelbuettel: > > On 14 November 2023 at 16:17, Dirk Eddelbuettel wrote: > | > | On 14 November 2023 at 11:06, Andreas Tille wrote: > | | Am Mon, Nov 13, 2023 at 07:23:06AM -0600 schrieb Dirk Eddelbuettel: > | | > 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 > | | > | | Uploaded yesterday since I realised the need. > | > | Thank you! > > I misread that, I think. So you updated TMB. Good. One done, three to go. Yes, that is what I intended to express. > irlba is widely used, OpenMx is big and I think MatrixModels also pops up. > If you could do a sweep over those I would appreciate it. I'll happily update these as soon as possible. However, I'd like to know what might be some sensible means to catch this quickly in future. For r-cran-tmb the strict version checking in d/rules (which is not the best thing to do according to the release team) was raising some signal. I'd like to clarify first, whether there will be some better solution via some r-matrix-api before I upload those other packages. Kind regards Andreas. -- http://fam-tille.de
Re: Matrix update triggering need for four rebuilds
Hi Dirk, Am Mon, Nov 13, 2023 at 07:23:06AM -0600 schrieb Dirk Eddelbuettel: > Most of these are not in Debian but I think we need binary rebuilds of > >irlba because of headers >OpenMx because of headers, a new upstream 2.21.10 is out too >TMB because of headers Uploaded yesterday since I realised the need. >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. In principle upgrading four packages at request is cheap. However, I have the feeling that we are technically more safe if we would introduce some r-tmb-api which would technically raise a signal for tmb dependencies. I've "hacked" some workaround into r-cran-tmb since I was motivated by the github issue discussing the relation to Matrix[1] to fix a very specifix Matrix version. I've put the release team in CC since they were involved into the according discussion. I consider it necessary to make those dependencies technically transparent and some according API seems to be the usual way to do this. > 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. May be its interesting to hear the opinion of the said CRAN maintainers whether they consider the suggested means as appropriate to deal with this issue. Kind regards Andreas. [1] https://github.com/kaskr/adcomp/issues/387 -- http://fam-tille.de
Bug#1054657: transition: r-bioc-biocgenerics
Am Fri, Nov 10, 2023 at 11:26:21PM +0100 schrieb Andreas Tille: > > What about a compromise. We start the transition, r-bioc-s4arrays is in > ... Thanks to the hint from Charles I found that SparseArray is not new in Bioconductor and we can build the previous version with the current packages in unstable which I did and uploaded to new. Kind regards Andreas. -- http://fam-tille.de
Bug#1054657: r-bioc-sparsearray_1.0.12+dfsg-1_amd64.changes is NEW
Hi ftpmasters, we want to start the transition from Bioconductor version 3.17 to 3.18. The release team asked us to make sure there will be no packages missing in Debian that needs to pass new queue first to maintain some smooth transition. Thus I uploaded the only missing package r-bioc-sparsearray. If your time permits it would be great to give this package some preference to enable us starting the transition. Kind regards Andreas. Am Mon, Nov 13, 2023 at 09:07:37AM + schrieb Debian FTP Masters: > binary:r-bioc-sparsearray is NEW. > binary:r-bioc-sparsearray is NEW. > source:r-bioc-sparsearray is NEW. > > Your package has been put into the NEW queue, which requires manual action > from the ftpteam to process. The upload was otherwise valid (it had a good > OpenPGP signature and file hashes are valid), so please be patient. > > Packages are routinely processed through to the archive, and do feel > free to browse the NEW queue[1]. > > If there is an issue with the upload, you will receive an email from a > member of the ftpteam. > > If you have any questions, you may reply to this email. > > [1]: https://ftp-master.debian.org/new.html > or https://ftp-master.debian.org/backports-new.html for *-backports > > ___ > R-pkg-team mailing list > r-pkg-t...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/r-pkg-team > -- http://fam-tille.de
Bug#1054657: transition: r-bioc-biocgenerics
Hi Paul, Am Fri, Nov 10, 2023 at 08:39:18PM +0100 schrieb Paul Gevers: > On 10-11-2023 11:56, Andreas Tille wrote: > > The only new dependency we need is SparseArray. However, we cannot > > upload the package to new since it needs r-bioc-s4arrays (>= 1.1.6) for > > building it. In other words: We need to start the transition before we > > can package SparseArray. > > You're totally free use experimental for that to get SparseArray through > NEW. I assume you don't need 100% of the transition, but only a (hopefully > tiny) bit. So you could upload the newer version of r-bioc-biocgenerics and > reverse depending packages up to where you need it to build SparseArray. > ... What about a compromise. We start the transition, r-bioc-s4arrays is in level 3 and given that ftpmaster might accept the new package in 3-5 days when we ping kindly it will be available before we are in the last level. I'd like to remind that quite some delays are caused by autopkgtest errors on rarely used architectures. My experience of past transitions tells me that a single new package in the beginning will not have some measurable effect on the total length of the transition. Kind regards and thanks for your work as release team Andreas. -- http://fam-tille.de
Bug#1054657: transition: r-bioc-biocgenerics
Control: tags -1 - moreinfo Hi, Am Fri, Nov 10, 2023 at 05:43:43PM +0900 schrieb Charles Plessy: > Hi Paul and everybody, I admit Paul's mail was convincing enough to dive deeper into this. I also need to admit that hacking together some scripts doing the job was less effort than I expected, finally. Sorry for sounding stubborn in the beginning. > We will complete the checks and package the new dependencies and submit > the to NEW next week The only new dependency we need is SparseArray. However, we cannot upload the package to new since it needs r-bioc-s4arrays (>= 1.1.6) for building it. In other words: We need to start the transition before we can package SparseArray. Kind regards Andreas. -- http://fam-tille.de
Bug#1054657: transition: r-bioc-biocgenerics
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
Bug#1054657: transition: r-bioc-biocgenerics
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
Bug#1054657: transition: r-bioc-biocgenerics
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
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
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
Bug#1054657: transition: r-bioc-biocgenerics
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
Bug#1054657: transition: r-bioc-biocgenerics
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 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
Bug#1054657: transition: r-bioc-biocgenerics
Hi Graham, Am Sat, Oct 28, 2023 at 04:55:24PM + 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
Bug#1054657: transition: r-bioc-biocgenerics
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
Bug#1054657: transition: r-bioc-biocgenerics
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 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";
Bug#1050223: RM: r-cran-rgdal/1.6-7+dfsg-1
Control: tags -1 - moreinfo Am Tue, Aug 22, 2023 at 06:43:46PM +0200 schrieb Paul Gevers: > > Hi Andreas, > > rgdal will run out of upstream support soon. Since the package created > > failures with newer upstream versions of other packages (see bug > > #1049438) it should be removed from testing. > > Two questions/remarks: > 1) why only testing, doesn't it make more sense to remove it from unstable > (hint: reassign to ftp.debian.org) If you only need it from testing, > reopening 1049438 is a reasonably fast way to achieve that. I guess I need some time to verify all dependencies and may be we even find a fix. But this needs time I do not have currently. It does not make sense to me to stop testing migration of other r-cran-* packages just because a candidate for removal makes some tests fail. > 2) as you mentioned in 1049438, the reverse (test) depends should be fixed > first. Please remove the moreinfo tag once that has happened. Closing this was a mistake and I've re-opened it. Regarding the testing removal of r-cran-rgdal. This bug would do this automatically. However, as long as the package is in testing it creates noise of testing removal announcements which does not really help. Thus my request for removal from testing. Sorry for the mess I've created by closing this bug Andreas. -- http://fam-tille.de
Bug#1050223: RM: r-cran-rgdal/1.6-7+dfsg-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm X-Debbugs-Cc: r-cran-rg...@packages.debian.org, 1049...@bugs.debian.org Control: affects -1 + src:r-cran-rgdal Hi, as per upstream https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1049438#31 rgdal will run out of upstream support soon. Since the package created failures with newer upstream versions of other packages (see bug #1049438) it should be removed from testing. Kind regards Andreas.
Bug#1040498: Should we consider the transition ready (Was: Bug#1040498: transition: r-bioc-biocgenerics)
Hi Graham, Am Wed, Aug 16, 2023 at 09:23:00PM + schrieb Graham Inggs: > tracker.d.o. is having some issues (see #1043546), but you can still > access up-to-date excuses here: > https://qa.debian.org/excuses.php?package=r-bioc-biocgenerics > > The current blocker I see is: > Implicit dependency: r-bioc-biocgenerics r-bioc-decoupler (not considered) I've fixed r-bioc-decoupler manually to remove this blocker quickly (instead of working around invalid version specifications by detecting these in dh-r) Do you see any other blocker? Kind regards Andreas. -- http://fam-tille.de
Bug#1040498: Should we consider the transition ready (Was: Bug#1040498: transition: r-bioc-biocgenerics)
Hi, the last new precondition was accepted so all r-bioc-* packages are uploaded and built meanwhile. The only not-transitioned package is r-bioc-bitseq where I filed a removal bug for[1]. So we have at least all r-bioc-* packages in their current version. [1] https://bugs.debian.org/1049359 Am Tue, Aug 01, 2023 at 01:06:41PM + schrieb Graham Inggs: > Hi Andreas > > You should check on the package tracker pages for all the r-bioc-* > uploads and make sure they are ready to migrate along with > r-bioc-biocgenerics, e.g. r-bioc-cummerbund [1]. > > r-bioc-biocversion appears to break the autopkgtest of > r-cran-biocmanager/1.30.21.1+dfsg-1 in testing. We now have 1.30.22+dfsg-2 in unstable which passes its tests. Do we need to do some further action? > At least the following packages are failing their own autopkgtests in > unstable (list not complete): > r-bioc-cummerbund > r-bioc-decoupler > r-bioc-monocle > r-bioc-scran > r-bioc-singler Most of those packages have autopkgtests marked as Failed (not a regression) Am I correct that we do not need to take any action regarding the transition? The only exception in this list (as far as I can see) is https://tracker.debian.org/pkg/r-bioc-scran I'm about to verify the possibly rounding error for i386 which might be fixed by relaxing the boundaries or ignoring this single test. I'm wondering about the issue with ppc64el where the log[2] says: 43s Broken autopkgtest-satdep:ppc64el Depends on r-bioc-scrnaseq:ppc64el < none @un H > 43s Considering r-bioc-scrnaseq:ppc64el 2 as a solution to autopkgtest-satdep:ppc64el -2 43s Removing autopkgtest-satdep:ppc64el rather than change r-bioc-scrnaseq:ppc64el > r-bioc-dupradar has regressed from passing to neutral, apparently due > to the use of 'skip-not-installable'. Please don't use this > restriction on all the autopkgtests in a package, otherwise there are > no tests which are not superficial, and regressions can migrate to > testing. Could you please be more verbose about this hint (may be suggesting a patch that implements your suggestion since I'm afraid I do not understand this correctly) Do you see any further blockers? Kind regards Andreas. [2] https://ci.debian.net/data/autopkgtest/testing/ppc64el/r/r-bioc-scran/36185915/log.gz -- http://fam-tille.de
Bug#1040498: Should we consider the transition ready (Was: Bug#1040498: transition: r-bioc-biocgenerics)
Hi Paul, Am Sat, Jul 29, 2023 at 07:44:32PM +0200 schrieb Paul Gevers: > > Well, I didn't check everything yet (hint is at [1]) Thanks for the hint - this was the point I wanted to make with my mail. > but at least the > autopkgtest regression in r-bioc-rhdf5filters (see [2] to find that in > unstable it fails too) should really be solved.. Thanks to Nilesh for fixing it. > For several of the other > packages, you see that the right versioned (test) dependencies aren't > declared, so the test pass in unstable, but fails to pull in the right > dependencies when tested in the migration scenario. I enhanced dh-r to inject the versioned Depends declared by upstream as long as these are packaged. That's no guarantee that our tests will work but hopefully a first step to enhance the situation. > Also, but that's more my > fault than yours, there are a bunch of packages in testing that fail their > tests there because their *test* dependencies aren't in testing. Those > should be pulled in by the migration scenario, but I hope none of the three > packages mentioned above are needed for other tests, because then the tests > will keep failing until NEW is cleared. > > > If you agree it might make sense to not touch r-bioc-* packages to let > > the testing migration happen. > > Well, any fix for triggered autopkgtest failure due to the lack of the right > constraints (versioned (test) dependencies and/or breaks) might actually > help speed up the process, because it will need less hand-holding. I'm just hoping for the team since I'm busy with real life and will be absolutely offline from tomorrow noon for at least 24 hours. > PS: I'm not seeing the uploads of r-bioc-isoformswitchanalyzer and > r-bioc-scater yet IT can't be uploaded since the new version will not build due to the missing dependencies that need to clear new. I see no sense in rebuilding the old versions since they do not fit the bioconductor version of all other r-bioc-* packages. I intended to express with my mail that those packages are not and can not be uploaded. Kind regards Andreas. > [1] https://people.debian.org/~elbrus/ci/regressions.html (grey is only in > unstable) > [2] https://ci.debian.net/packages/r/r-bioc-rhdf5filters/ -- http://fam-tille.de
Bug#1040498: Should we consider the transition ready (Was: Bug#1040498: transition: r-bioc-biocgenerics)
Hi, all r-bioc-* packages except r-bioc-bitseq which is not maintained upstream and should probably be removed (as in the last transition) and r-bioc-scater r-bioc-deseq r-bioc-isoformswitchanalyzer are uploaded. The latter three have new dependencies which are uploaded to new. Since all four exceptions are in sid only we could consider the transition done and the majority of r-bioc-* packages can migrate to testing. We can wait for new processing for those three remaining packages which does not really affect all other r-bioc-* packages. If you agree it might make sense to not touch r-bioc-* packages to let the testing migration happen. Kind regards Andreas. -- http://fam-tille.de
Bug#1040498: Please give preference to this package (Was: r-bioc-densvis_1.10.2+dfsg-1_amd64.changes is NEW)
Hi ftpmasters, this package is needed to complete the Transitions r-api-bioc-3.17[1] since it is a new dependency of package r-bioc-scater. Thanks a lot in advance for processing this package quickly Andreas. [1] https://release.debian.org/transitions/html/r-api-bioc-3.17.html Am Thu, Jul 27, 2023 at 07:52:54AM + schrieb Debian FTP Masters: > binary:r-bioc-densvis is NEW. > binary:r-bioc-densvis is NEW. > source:r-bioc-densvis is NEW. > > Your package has been put into the NEW queue, which requires manual action > from the ftpteam to process. The upload was otherwise valid (it had a good > OpenPGP signature and file hashes are valid), so please be patient. > > Packages are routinely processed through to the archive, and do feel > free to browse the NEW queue[1]. > > If there is an issue with the upload, you will receive an email from a > member of the ftpteam. > > If you have any questions, you may reply to this email. > > [1]: https://ftp-master.debian.org/new.html > or https://ftp-master.debian.org/backports-new.html for *-backports > > ___ > R-pkg-team mailing list > r-pkg-t...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/r-pkg-team > -- http://fam-tille.de
Bug#1040498: Transition blocked by new package
Control: block -1 by 1042368 -- http://fam-tille.de
Bug#1040498: transition: r-bioc-biocgenerics - blocked by new package r-bioc-s4arrays
Control: block -1 by 1041598 Hi, it has turned out that there is a new dependency for the new version of package r-bioc-delayedarray. The new package r-bioc-s4arrays is uploaded to new but I record the ITP bug here as a blocker to record that issue. Usually ftpmaster is helpful and quick in such situations. Kind regards Andreas. -- http://fam-tille.de
Bug#1040498: Help for Bioconductor transition needed: using Debian packaged libraries in r-bioc-rhdf5filters
Hi, I've just pushed r-bioc-rhdf5filters to salsa[1]. We are replacing code copies of several compression related libs by the Debian equivalents. Seems upstream added zstd and thus I added libzstd-dev to Build-Depends and tried to fix the according patch. But it went more complex. The issues are occuring when trying to build src/blosc where upstream provides in src/blosc/lib three versioned code copies src/blosc/lib/blosc-1.20.1 src/blosc/lib/lz4-1.9.4 src/blosc/lib/snappy-1.1.1 My first means was (not commited yet) diff --git a/debian/control b/debian/control index 1a28bdb..76b3258 100644 --- a/debian/control +++ b/debian/control @@ -15,6 +15,8 @@ Build-Depends: debhelper-compat (= 13), libbz2-dev, libblosc-dev, libhdf5-dev, + liblz4-dev, + libsnappy-dev, libzstd-dev Testsuite: autopkgtest-pkg-r but further patching attempts did no good here. The plain build log of the package in Salsa does not say much since the actual build error of R is suppressed. You can see the real issue behind the failures when you do R CMD INSTALL -l `pwd`/debian/r-bioc-rhdf5filters/usr/lib/R/site-library . For the moment I try to checkout other packages of the transition. It would help if someone could have a look here. Kind regards Andreas. [1] https://salsa.debian.org/r-pkg-team/r-bioc-rhdf5filters -- http://fam-tille.de
Bug#1040498: Fwd: Bug#1040498: transition: r-bioc-biocgenerics
Additional hint: The transition tracker is here https://release.debian.org/transitions/html/r-api-bioc-3.17.html and I have just uploaded r-bioc-biocgenerics_0.46.0-1 with Provides: r-api-bioc-3.17 (Now I need some break for some hours ;-) - I'm back from 85km cycling tour.) Kind regards Andreas. Am Mon, Jul 17, 2023 at 04:08:53PM +0200 schrieb Andreas Tille: > Hi, > > the BioC transition can be started now. I'm kind of offline-ish for a > couple of hours today and a bit tired. May be I'll start tomorrow. For > those who do not want to wait feel free to start with the first levels. > > We should coordinate at > >https://matrix.to/#/#debian-med:matrix.org > > to avoid race conditions. > > Kind regards > Andreas. > > - Weitergeleitete Nachricht von Paul Gevers - > > Date: Mon, 17 Jul 2023 09:13:55 +0200 > From: Paul Gevers > To: Andreas Tille , 1040...@bugs.debian.org > Subject: Re: Bug#1040498: transition: r-bioc-biocgenerics > > Control: tags -1 confirmed > > Hi Andreas, > > On 06-07-2023 20:55, Andreas Tille wrote: > > BioConductor has released version 3.17 when we were in Freeze. Once we > > have settled the r-base graphics API transition I would like to start the > > BioConductor transition bumping r-api-bioc-3.16 to r-api-bioc-3.17. > > Please go ahead. > > Paul > > > > > - Ende weitergeleitete Nachricht - > > -- > http://fam-tille.de -- http://fam-tille.de
Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)
Am Sat, Jul 08, 2023 at 10:35:17PM +0200 schrieb Paul Gevers: > Indeed, I think the pattern is that if we test in testing, with r-cran from > unstable and r-cran-tibble from testing it fails, but with r-cran from > unstable and r-cran-tibble from unstable, it works. > > I'm working my through the list and the ppc64el ci workers have a bit of > backlog; we're getting somewhere, but I'm think I'm still also seeing > different failure modes than the graphics engine, tibble and dplyr. I admit the only chance I personally see to clarify this question is to open an issue at the tibble git repository[1]. May be we also need something like an r-cran-tibble-api? Kind regards Andreas. [1] https://github.com/tidyverse/tibble -- http://fam-tille.de
Bug#1040001: adds unnecessarily strict versioned Depends on r-base-core
Control: reopen -1 Thanks for watching me, Bas. Am Fri, Jul 07, 2023 at 05:09:31PM +0200 schrieb Sebastiaan Couwenberg: > It seems that dh-r (20230707) should have closed #1040515 instead of the > transition bug report (#1040001). -- http://fam-tille.de
Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing (Was: Bug#1040001: transition: r-base)
Am Fri, Jul 07, 2023 at 12:52:49AM +0530 schrieb Nilesh Patra: > > Andreas, if you remember, the code pointed out by Sébastien is > the exact same reason we had to t-p-u r-cran-shiny during freeze, See > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035428#15 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035428#40 > > https://tracker.debian.org/news/1431956/accepted-r-cran-shiny-174dfsg-2deb12u1-source-into-testing-proposed-updates/ Nilesh, you somehow work like my "external memory". I just answered the issue and IMHO Sébastian is correct but this line has a long history ... Kind regards Andreas. -- http://fam-tille.de
Bug#1040001: To strict version restrictions injected by dh-r (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)
Hi Sébastien,
Am Thu, Jul 06, 2023 at 09:13:46PM +0200 schrieb Sébastien Villemot:
> > I'm not sure so please explain in more detail. dh-r was designed to put
> > the lowest restriction regarding the versions. I remember some
> > discussion some time ago that Dirk thought we should put stronger
> > restrictions (and he is sometimes adding version restrictions manually
> > that are not helpful for backporting). If I will be sure I understand
> > your point exactly I can check the code and the relevant discussion.
> > (Feel free to file a bug report about this and we can discuss it there
> > if you think this makes more sense.)
>
> It comes from this line:
> https://salsa.debian.org/r-pkg-team/dh-r/-/blob/master/dh/R.pm#L272
>
> More precisely the “r-base-core (>= $rbase_version)” part, which
> imposes an unnecessarily tight restriction on the r-base-core version.
Got it, thanks for the explanation. This restriction existed since the
early stage of dh-r development
https://salsa.debian.org/r-pkg-team/dh-r/-/commit/22fd80b9#L174
by Gordon Ball (in CC but not really active in R pkg team any more) at
2016-09-04 12:28:57 +0200 . I'm guessing this restriction was obtained
from the cdbs helper that existed before the dh support was created by
Gordon and he simply took over what existed there. The according line
in the initial commit of dh-r is
say $svs "R:Depends=r-base-core (>= $rversion), $rapiversion";
which supports my thesis. So I went back in history and found the
discussion of bug #704805 where several people were finally able to
convince Dirk that r-api is a good idea.
In r-base changelog we find:
r-base (3.2.0-3) unstable; urgency=low
* debian/control: The r-base-core package now 'Provides: r-api-3' which
can be used to have r-cran-* depend on a particular API vintage.
(Closes: #704805)
* debiab/r-cran.mk: Have the build-time API vintage encoded as a Depends
(with thanks to Julian Gilbey, Charles Plessy, and others for the patch)
* debian/control: Set Standards-Version: to current version
-- Dirk Eddelbuettel Mon, 11 May 2015 06:08:12 -0500
which contains the change in /usr/share/R/debian/r-cran.mk
@@ -96,7 +98,7 @@
dh_installdirs $(debRdir)
##
## support ${R:Depends} via debian/${package}.substvars
- echo "R:Depends=r-base-core (>= ${rversion})" >>
debian/$(package).substvars
+ echo "R:Depends=r-base-core (>= ${rversion}), ${rapiversion}"
>> debian/$(package).substvars
##
## call R to install the sources we're looking at
## use this inside xvfb-run if this wrapper is installed
between this file from r-base (3.2.0-2)
So this seems a historic leftover to me probably since Dirk has the
opinion that this version restriction is needed.
I'd consider it sensible if you open a bug against dh-r where we can
document the change you are suggesting.
Kind regards
Andreas.
--
http://fam-tille.de
Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)
Hi,
Am Thu, Jul 06, 2023 at 08:28:45PM +0200 schrieb Paul Gevers:
> On 06-07-2023 19:08, Paul Gevers wrote:
> > Yes, we'll take care of that where it looks sane to do so (examples of
> > that are r-cran-epi); I'll manually schedule the "combined" tests, such
> > that they disappear from the excuses if they then pass.
>
> I'm seeing in several tests where things seem to work when r-cran-tibble
> from unstable is involved and fail if the version from unstable is used;
Are you sure there is no typo in your sentence? At least I fail to
understand. I assume the latter "unstable" should be "testing", right?
> e.g. here: https://ci.debian.net/packages/r/r-cran-rsample/testing/amd64/
I can only say that tibble is used by a lot of packages directly as
dependency (69 in my locally stored repositories - may be some more).
In addition there are further dependencies of higher order.
> Is there something special about r-cran-tibble? It didn't grow a dependency
> on r-graphics-engine according to
> https://buildd.debian.org/status/fetch.php?pkg=r-cran-tibble=amd64=3.2.1%2Bdfsg-2=1688629916=0
> so it doesn't seem to be involved in that part of the discussion.
I confirm it shouldn't be involved into the r-graphics-engine issue.
May be there is some other "hidden" transition needed which is connected
to some interface of tibble? Dirk, can you shed some light into this?
Kind regards
Andreas.
--
http://fam-tille.de
Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing (Was: Bug#1040001: transition: r-base)
Hi Paul, Am Thu, Jul 06, 2023 at 07:08:04PM +0200 schrieb Paul Gevers: > Yes, we'll take care of that where it looks sane to do so (examples of that > are r-cran-epi); I'll manually schedule the "combined" tests, such that they > disappear from the excuses if they then pass. OK. Thanks a lot for this service. Do you think the remaining serious tests are blockers? Should these be closed manually? > > Alternatively it would probably OK to remove all > > RC buggy r-bioc-* packages from testing since we need to upload new > > versions of these packages anyway in the pending BioC transition (I'll > > file an according bug report soon). > > If you're OK to temporarily remove r-bioc-*, than I think it's the fastest > and easiest way out, albeit not the prettiest. For sure it is not pretty, but since once week I'm fighting to non-pretty things and I'm really happy about fast and easy solutions. ;-) I have just filed a transition bug for r-bioc-* where we can discuss issues belonging to this transition. > Please all involved, hold any uploads in the r-* world until we get r-base > migrated unless it's needed (and we acked it). OK, I'll refrain from any upload of r-* packages (I'll answer your other mail about r-cran-tibble separately). > Paul > > PS: in a private discussion I had today, we noticed that r-* packages often > (always?) have a dependency on r-base-core with a lower limited version > equal to the r-base-core that was used during the build. With the > appropriate API in Provides of r-base-core, this should no longer be > necessary and ease migrations in the future. Could you please give some example to make sure I understand correctly? > We should probably file a bug > against dh-r (I guess) to fix that dependency. Or did we conclude that > wrong? I'm not sure so please explain in more detail. dh-r was designed to put the lowest restriction regarding the versions. I remember some discussion some time ago that Dirk thought we should put stronger restrictions (and he is sometimes adding version restrictions manually that are not helpful for backporting). If I will be sure I understand your point exactly I can check the code and the relevant discussion. (Feel free to file a bug report about this and we can discuss it there if you think this makes more sense.) Kind regards Andreas. -- http://fam-tille.de
Bug#1040498: transition: r-bioc-biocgenerics
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: r-bioc-biocgener...@packages.debian.org, debia...@bugs.debian.org Control: affects -1 + src:r-bioc-biocgenerics Hi, BioConductor has released version 3.17 when we were in Freeze. Once we have settled the r-base graphics API transition I would like to start the BioConductor transition bumping r-api-bioc-3.16 to r-api-bioc-3.17. As we discussed in bug #1040001 it is fine in principle to remove all r-bioc-* packages from testing to smoothen the r-base migration. These will be soonish replaced by the new set of packages belonging to BioConductor 3.17. Kind regards and thanks a lot for your work as release team Andreas. Ben file: title = "r-bioc-biocgenerics"; is_affected = .depends ~ "r-bioc-biocgenerics" | .depends ~ "r-bioc-biocgenerics"; is_good = .depends ~ "r-bioc-biocgenerics"; is_bad = .depends ~ "r-bioc-biocgenerics";
Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing (Was: Bug#1040001: transition: r-base)
Hi again, Am Thu, Jul 06, 2023 at 09:56:31AM +0200 schrieb Andreas Tille: > > I've now re-uploaded all 6 packages that are known to be affected by the > graphics ABI change (and verified that it is set properly). I'll > continue now closing the open bugs. After rebuilding quite some packages with autopkgtest failure with r-base (4.3.1-1) it came to my mind (probably to late) that since we do not have any real transition those uploads will probably not help very much since these are not generated with dependencies that are conflicting with the versions in testing and thus the autopkgtests running against packages in testing will keep on failing. Is there any chance to fix this via hinting by release team or should I rather add some "artificial" versioned Depends just to enable the whole set of r-cran-* packages to testing. I'm also wondering whether I should upload the old r-bioc-* packages to finally get the full R stack fit for testing before I'll start the next BioC transition. Alternatively it would probably OK to remove all RC buggy r-bioc-* packages from testing since we need to upload new versions of these packages anyway in the pending BioC transition (I'll file an according bug report soon). Kind regards Andreas. -- http://fam-tille.de
Bug#1040001: transition: r-base
Hi, Am Wed, Jul 05, 2023 at 04:07:12PM + schrieb Graham Inggs: > I don't think it's possible to set up a tracker for this first > "transition", as no packages currently depend on r-graphics-engine-*. Right, this makes perfectly sense. > Please wait until r-base and dh-r are built and in the installed state > on all architectures. I've now re-uploaded all 6 packages that are known to be affected by the graphics ABI change (and verified that it is set properly). I'll continue now closing the open bugs. Kind regards Andreas. PS: @Dirk I do not mind much whether I'm mentioned in changelogs for patches[1] but if you might happen to blame me about doing things wrong again please keep in mind that I sometimes do things right. Thank you. [1] https://metadata.ftp-master.debian.org/changelogs//main/r/r-base/r-base_4.3.1-2_changelog -- http://fam-tille.de
Bug#1040001: transition: r-base
Hi, the just uploaded r-base 4.3.1-2 implements r-graphics-engine-* which is respected by dh-r 20230705 (also just uploaded). It would be great if you could setup transition tracker. Am I understanding things correctly that I can now start uploading those r-cran-* packages featuring bugs autopkgtest failure with r-base (4.3.1-1) even if the tracker is not yet setup? Kind regards Andreas. -- http://fam-tille.de
Bug#1040001: Add block by
Control: block -1 by 1040038
Bug#1040001: transition: r-base
Hi Paul, Am Sun, Jul 02, 2023 at 10:54:03AM +0800 schrieb Paul Wise: > $ objdump -T debian/*/usr/lib/R/site-library/*/libs/*.so | grep > R_GE_checkVersionOrDie > DF *UND* Base > R_GE_checkVersionOrDie Thanks for the hint. Its implemented as suggested as per https://salsa.debian.org/r-pkg-team/dh-r/-/commit/7ad36007e575a4ec28c673ad1eae57e93ad5189e I would love to merge this with master and release a new dh-r once r-base exports the graphics ABI. Kind regards Andreas. -- http://fam-tille.de
Bug#1040001: transition: r-base
Hi Graham, Am Mon, Jul 03, 2023 at 05:24:19PM + schrieb Graham Inggs: > On Sun, 2 Jul 2023 at 19:57, Andreas Tille wrote: > > 45 > > > > serious bugs that are all caused by the non-transition while we should > > have done one. That's pretty annoying for the people who need to do the > > work (in this case basically me). > > IMHO, those autopkgtests regression bugs are useful. At least > #1039651 (in r-cran-gnm) and #1039653 (in r-cran-irkernel) appear > unrelated to the R_GE_version issue. Thank you for your uploads with fixes. > In addition, r-cran-bookdown [1] appears to break r-cran-flextable's > autopkgtests and r-cran-checkmate [2] fails its own autopkgtests on > armel, armhf and i386. These do not have bugs filed yet. I can imagine that there might be further bugs that are not filed yet. But that's not my point. I think if we would do a proper transition we can solve those issues caused by R_GE_version in one rush. All remaining things can be done manually if needed. I really wish we could make any progress in this direction. Kind regards Andreas. > [1] https://tracker.debian.org/pkg/r-cran-bookdown > [2] https://tracker.debian.org/pkg/r-cran-checkmate -- http://fam-tille.de
Bug#1040001: transition: r-base
Hi Paul,
Am Sat, Jul 01, 2023 at 05:21:16PM +0200 schrieb Paul Gevers:
> > So per upstream ("R Core" for short), this is clearly on the package
> > side. There is no ABI/API incompatibility: R offers graphics functions new
> > functionality, to use it one needs a rebuild _if a package decides to stop
> > and die on mismatch_.
I'd like to point out that "one needs a rebuild" is something else if
one installs a CRAN package manually or if we upload a Debian package.
A Debian package has to "survive" a set of tests (and here we
continuously disagree but right now in this actual case it has proven to
be necessary) and pass a migration procedure in a dependency tree of
packages which is just more complex than "just rebuild".
> > I so filed three bug reports last weekend against three such packages
... and I told you that this list of three packages was incomplete. By
chance I had rebuild two other packages that needed the rebuild and some
autopkgtest I was running uncovered that vdiffr simply slipped through
your attention. That's perfectly human - and since its human I'm in
favour of a technical solution which avoids such manual digging inside
the package pool.
Besides this such technical things to my experience these issues always
go with some well known pattern of "social friction" which is
demotivating for all sides. I'd like to reduce these friction points
to a minimum if there is some technical solution.
> > requesting a simple rebuild as that is in fact all it takes. (And
> > missed one that was added.) These were quickly rebuilt.
>
> While this may be true, in Debian we require that such packages express this
> relation. I understand that that's what we achieve with the proposal of
> Andreas. "Just rebuilding" is often the wrong solution (in Debian) if it
> doesn't express the relation properly.
Fully ACK.
> > So let me know what you think. If the release team thinks we must rebuild
> > across 1100 r-* packages (of which likely 400-500 are Architecture: any)
> > then I will of course work with you.
>
> I recognize that at this moment we might not need it to straighten things
> out, because of all the new version uploads, but I believe it's the right
> solution for the future, as this seems to be a recurring topic.
IMHO its not a solved case. The R pkg team is creating a list of packages
that are not up to date and a list of bugs which you can see in the second
table of [1]. This page lists
$ grep serious outdated_r-packages.txt | grep -c 4.3.1
45
serious bugs that are all caused by the non-transition while we should
have done one. That's pretty annoying for the people who need to do the
work (in this case basically me).
I would really welcome if we do it the right way even now, specifically
since there is a patch for bug #1040038 that implements a solution that
should help for now and in future.
Kind regards
Andreas.
[1]
https://salsa.debian.org/r-pkg-team/maintenance-utilities/-/blob/master/outdated_r-packages.txt
--
http://fam-tille.de
Bug#1040001: transition: r-base
Hi again, just a status update: Am Sat, Jul 01, 2023 at 01:45:11PM +0200 schrieb Andreas Tille: > > I think my piece is ready. We just need to decide about a proper name > of the virtual package. I'll inject this into my proof of concept > change of dh-r. Than Dirk needs to upload another r-base package > containing the r-graphics-api-VERSION. This should not be a hard thing > to do - Dirk just stayed silent about this change since we are > discussing it. I've filed Bug#1040038 with the patch for r-graphics-api and updated branch r-api-graphic branch of dh-r[1] to match the suggested patch immediately once uploaded. Kind regards Andreas. [1] https://salsa.debian.org/r-pkg-team/dh-r/-/tree/r-api-graphic?ref_type=heads -- http://fam-tille.de
Bug#1040001: transition: r-base
Hi Paul, Am Sat, Jul 01, 2023 at 07:48:16AM +0200 schrieb Paul Gevers: > Anytime is good to ask for a transition, particularly when the transition is > already ongoing. :-) > I don't think it should surprise anyone that we prefer it to be done right. > Our preference is for option 1. Thanks for confirming. > However, if you can't get the pieces for > that option in place in a reasonable time (say, a week or two, take some > time to try), I think my piece is ready. We just need to decide about a proper name of the virtual package. I'll inject this into my proof of concept change of dh-r. Than Dirk needs to upload another r-base package containing the r-graphics-api-VERSION. This should not be a hard thing to do - Dirk just stayed silent about this change since we are discussing it. > then we prefer to get *this* transition out of the way by > means of option 2. I personally think that we are in a good situation in the beginning of the release cycle to do things right, which means option 1. But it depends from the r-base maintainer to cooperate here. > I don't think it's in anybodies interest to waste time on > option 3. ACK. I told Bas so who had spent quite some time to file bugs against lots of r-cran-* packages which are all a consequence of the not-yet-transition. > > Sorry that this transition bug is that complex. I would have loved if > > it would went more coordinated but unfortunately that's not in my hands > > and I simply try to reassemble the pieces. > > Thanks for communicating with us, much appreciated. Its always a pleasure to communicate with you. ;-) > I'll try to set a placeholder transition tracker up soon; for now, by lack > of something better, will reflect option 2. We can update that once we have > the pieces for option 1. Thanks a lot Andreas. -- http://fam-tille.de
Bug#1040001: transition: r-base
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: r-b...@packages.debian.org, debia...@lists.debian.org Control: affects -1 + src:r-base Hi, I'm not sure that we are in the right status to ask for a transition bug since the affected package was just uploaded some time ago by its maintainer who did not considered a proper transition. This was discussed on debia...@lists.debian.org in several postings - I try to point you to the most relevant ones https://lists.debian.org/debian-r/2023/06/msg00011.html as a response to >30 bugs against single packages all affecting the r-base migration due to (to be expected) autopkgtest errors in testing. You can basically get this list of now all RC buggy packages from the tracker page or r-base[1] https://lists.debian.org/debian-r/2023/06/msg00017.html suggests r-graphics-api-* after r-base maintainer confirmed "they cheated _a little_ and changes the graphics API" (probably meaning ABI not API) https://lists.debian.org/debian-r/2023/06/msg00016.html Reference to the docs https://lists.debian.org/debian-r/2023/06/msg00025.html In the end of this mail three options are listed which I simply repeat here for your comfort: 1. implement the r-graphics-api-* This might be a bit complex since for the moment I do not know any means how to detect the packages that need this dependency (and how we can implement this into dh-update-R) So this might become technically complex in the first case 2. Just do a full r-api transition This would work but affects more packages than strictly necessary. My gut feeling says we will be able to finish this earlier than 1. despite technically not perfect 3. Blindly ignore the fact that we need a transition and follow the hackish workaround by using random versioned Depends as suggested by Nilesh for r-cran-epi. https://lists.debian.org/debian-r/2023/06/msg00027.html Confirmation for option 1. While I would love to hear the opinion of the release team what kind of transition (1. or 2.) should be prefered (if this is possible now at all since the affected package r-base 4.3.1 is in the archive since some time and also the most urgent packages are rebuild manually) or whether we need to fight manually through this mess (option 3.) I confirm that I agree with Johannes Ranke to prefer option 1. and do it "right" to be safe for the next time. To support this idea I just commited some proof of concept change to dh-r which would support injecting a virtual package in case r-base would define it. This requires confirmation of the r-base maintainer. Sorry that this transition bug is that complex. I would have loved if it would went more coordinated but unfortunately that's not in my hands and I simply try to reassemble the pieces. Kind regards Andreas. [1] https://tracker.debian.org/pkg/r-base [2] https://salsa.debian.org/r-pkg-team/dh-r/-/commit/f79e2573a59c1ff01c526a7dcf15b7f85263cc29 Ben file: title = "r-base"; is_affected = ; is_good = ; is_bad = ;
Seems we need a transition for r-base instead of lots of single bugs against single packages (Was: Bug#1039645: r-cran-epi: autopkgtest failure with r-base (4.3.1-1))
Hi Bas, (this is just an example bug out of a lot you filed) Am Wed, Jun 28, 2023 at 08:11:05AM +0200 schrieb Bas Couwenberg: > 189s DLL requires the use of native symbols I wonder, whether all those bugs against single r-* packages are sensible. As far as I can see we simply need a transition for this r-base upgrade. Am I missing something? Kind regards Andreas. -- http://fam-tille.de
Bug#1028132: now ready
Am Tue, Jun 27, 2023 at 06:31:28AM +0200 schrieb Rene Engelhard: > > Andreas, you can upload r-cran-hunspell. Uploaded. Thanks a lot for the ping Andreas. -- http://fam-tille.de
Bug#1036753: unblock: debian-science/1.14.5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: debian-scie...@packages.debian.org, debian-scie...@lists.debian.org Control: affects -1 + src:debian-science Please unblock package debian-science [ Reason ] This is the usual update of the Blends metapackages short before the release to reflect removals inside the freeze process. Well, admittedly its not the "usual" one. I intended to get version 1.14.4 featuring lots of changes into testing before the freeze and failed. Its simply my fault and I should have done this earlier - I'm very sorry about this. The consequence is a diff to the version in testing (1.14.3) which is *way* larger than usually acceptable and I can perfectly understand if you might reject this unblock request due to this large diff which is not readable any more. The consequence would be some inconsistencies inside the metapackages which might have a non-optimal user experience. [ Impact ] Some packages recommended inside the metapackages are removed from bookworm. Due to my late upload of 1.14.4 which contained a lot of updates regarding packages created by Debian Science users would miss quite some packages that are not mentioned in the dependencies of the metapackages. [ Tests ] Unfortunately there are no tests for the metapackages. However, they are automatically created and thus checked against the package pool and thus it is sensible to expect that the packages are fine. [ Risks ] There is no real code inside the metapackages so the packages are extremely trivial and all are leaf packages so no other package is depending from them and thus they can not break any other package. [ Checklist ] [*] all changes are documented in the d/changelog [*] I reviewed all changes and I approve them [*] attach debdiff against the package in testing [ Other info ] I promise to deliver smaller diffs for the next release cycle. unblock debian-science/1.14.5 debian-science_1.14.3-1.14.5.debdiff.gz Description: application/gzip
Bug#1036227: bookworm-pu: package r-cran-shiny/1.7.4+dfsg-3~deb12u1
Hi Paul, Am Tue, May 23, 2023 at 01:52:38PM +0200 schrieb Paul Gevers: > Control: tags -1 confirmed Thanks. > On 17-05-2023 19:48, Andreas Tille wrote: > > I'd like to announce an upload to testing-proposed-updates > > You confused me here. I don't see traces of the upload yet, so I assume this > is a pre-approval. Yes, I was asking for pre-approval (sorry for the confusing wording). > > Thus an upload to testing-proposed-updates > > seems an appropriate solution for this and this bug report is > > about asking you for confirmation about this solution. > > Ack. For the future ideally this would be fixed by dh-r being less strict in > what it injects. I think the injection is sensible in principle to prevent any r-cran package that is build against r-base with a higher version than in testing to migrate to testing to early. Its just the accidental upload of a higher version which creates the problem. > > I propose to upload the following change to t-p-u: > > Please, always generate your debdiff comparing to what is currently in > testing. I'll do - just wanted to wait for confirmation of the versioning scheme to create the final diff. It is attached now. > However, I personally prefer the automatic > syncing of testing to unstable that we get if you use 1.7.4+dfsg-3+deb12u1 > (mind the version being *higher* than testing) or even 1.7.4+dfsg-4. But ACK > with whatever reasonable version number you choose. Hope this fits the easy route now. Kind regards and thanks for working in the release team Andreas. [1] https://lists.debian.org/debian-release/2023/05/msg00623.html -- http://fam-tille.de diff -Nru r-cran-shiny-1.7.4+dfsg/debian/changelog r-cran-shiny-1.7.4+dfsg/debian/changelog --- r-cran-shiny-1.7.4+dfsg/debian/changelog2023-02-21 20:34:31.0 +0100 +++ r-cran-shiny-1.7.4+dfsg/debian/changelog2023-05-17 07:56:25.0 +0200 @@ -1,3 +1,12 @@ +r-cran-shiny (1.7.4+dfsg-2+deb12u1) bookworm; urgency=medium + + * Upload to testing-proposed-updates "bookworm" due to the fact that +there was an accidental upload of a new version of r-base to unstable + * Fix link for normalize.css +Closes: #1035428 + + -- Andreas Tille Wed, 17 May 2023 07:56:25 +0200 + r-cran-shiny (1.7.4+dfsg-2) unstable; urgency=medium * closure-compiler fails - simply symlinking uncompressed JS diff -Nru r-cran-shiny-1.7.4+dfsg/debian/links r-cran-shiny-1.7.4+dfsg/debian/links --- r-cran-shiny-1.7.4+dfsg/debian/links2023-02-21 20:34:31.0 +0100 +++ r-cran-shiny-1.7.4+dfsg/debian/links2023-05-17 07:56:25.0 +0200 @@ -37,5 +37,5 @@ usr/share/javascript/bootstrap/files/js/locales usr/lib/R/site-library/shiny/www/shared/datepicker/js/locales usr/share/javascript/bootstrap/files/less/datepicker.less usr/lib/R/site-library/shiny/www/shared/datepicker/less/datepicker.less # usr/share/javascript/selectize.js/selectize.min.js usr/lib/R/site-library/shiny/www/shared/selectize/js/selectize.min.js -usr/lib/nodejs/normalize.css/normalize.css usr/lib/R/site-library/shiny/www/shared/ionrangeslider/css/normalize.css +usr/share/javascript/normalize.css/normalize.css usr/lib/R/site-library/shiny/www/shared/ionrangeslider/css/normalize.css usr/share/nodejs/html5shiv/dist/html5shiv.min.js usr/lib/R/site-library/shiny/www/shared/bootstrap/shim/html5shiv.min.js
Bug#1036557: unblock: debian-med/3.8.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: debian-...@packages.debian.org, debian-...@lists.debian.org Control: affects -1 + src:debian-med Please unblock package debian-med [ Reason ] This is the final update of the Debian Med metapackages after some changes in the package pool. Since some packages were removed from testing this had to be reflected in the dependencies of the metapackages Updating Blends metapackages in the final phase of a release cyclus to adapt to those changes is the usual thing we do in the release process. [ Impact ] The metapackages would recommend packages that are not available in the future stable release. [ Tests ] There is no test but the automatic generation of the dependencies was done as usual and has shown to be reliable in the past. The resulting changes make perfectly sense. [ Risks ] There is not even code and its a leaf package anyway. [ 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 testing [ Other info ] unblock debian-med/3.8.1 debian-med_3.8.1-3.8.debdiff.gz Description: application/gzip
Bug#1036227: bookworm-pu: package r-cran-shiny/1.7.4+dfsg-3~deb12u1
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: r-cran-sh...@packages.debian.org, 1035...@bugs.debian.org, debia...@lists.debian.org Control: affects -1 + src:r-cran-shiny I'd like to announce an upload to testing-proposed-updates [ Reason ] As discussed on the mailing list debian-release@l.d.o[1] the accidental upload of r-base prevents r-cran-shiny from migrating to testing since it has some failing tests due to the r-base version conflict. Thus an upload to testing-proposed-updates seems an appropriate solution for this and this bug report is about asking you for confirmation about this solution. [ Impact ] R-cran-shiny has an RC bug and is in danger to be not released with bookworm. It has quite some dependencies that would be affected. [ Tests ] There is just a fixed symlink in the upload to fix the RC bug. All tests are passing as usual. [ Risks ] The change to the package is minimal. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [ ] attach debdiff against the package in (old)stable --> will be attached once uploaded [x] the issue is verified as fixed in unstable [ Changes ] I propose to upload the following change to t-p-u: $ git diff HEAD^ diff --git a/debian/changelog b/debian/changelog index 21d12c3..a2b6c26 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +r-cran-shiny (1.7.4+dfsg-3~deb12u1) bookworm; urgency=medium + + * Upload to testing-proposed-updates "bookworm" due to the fact that +there was an accidental upload of a new version of r-base to unstable + + -- Andreas Tille Wed, 17 May 2023 07:56:25 +0200 + r-cran-shiny (1.7.4+dfsg-3) unstable; urgency=medium Nilesh Patra suggested to use version 1.7.4+dfsg-2+deb12u1 but I personally regard my version suggestion more logical (long explanation given in [2]). [ Other info ] Please confirm that I should upload to t-p-u (and raise your opinion about the most sensible version in your eyes). Kind regards and thanks for working as release team Andreas. [1] https://lists.debian.org/debian-release/2023/05/msg00623.html
Re: Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)
Am Wed, May 17, 2023 at 02:07:22PM +0530 schrieb Nilesh Patra: > On Wed, May 17, 2023 at 08:58:58AM +0200, Andreas Tille wrote: > > I hope I was following developers reference about t-p-u[6] correctly > > and pushed > > I've choosen the version 1.7.4+dfsg-3~deb12u1 to match > > the requirement that the version is lower than in unstable > > I guess this should be alright. But as per devref, you may want to choose > "1.7.4+dfsg-2+deb12u1". This was my first consideration. However, the changes simply fit to 1.7.4+dfsg-3 and by using the '~' separator the "smaller version than in unstable" is fulfilled as well. I don't mind much actually - just to explain my choice. > > I wonder whether dput is working with target distribution bookworm since > > lintian throws an error. > > It probably should. There's a d/ch entry I found for argon2 package > here[7] in case that helps you. Thanks for confirming. > > Release team is in CC - do you think I should > > file a bug right now or just after an upload? > > devref says "Ask for authorization for uploading from the release > managers." > > So I suppose it makes sense to file a bug before you upload and ping > them back again once you upload as per Yepp, I'll do so and will ask what they consider the more sensible version number. > "After uploading and successful build on all platforms, contact the > release team at debian-release@lists.debian.org and ask them to approve > your upload." Will do so. Kind regards Andreas. > > > > > [1] > > > > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-thematic/33619891/log.gz > > > > > [2] > > > > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treescape/33619892/log.gz > > > > > [3] > > > > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treespace/33619893/log.gz > > > > > [4] > > > > > https://tracker.debian.org/news/1429562/accepted-r-base-430-1-source-into-unstable/ > > > > [5] https://wiki.debian.org/TestingProposedUpdates > > [6] > > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#t-p-u > [7] > https://tracker.debian.org/news/1429925/accepted-argon2-020171227-03deb12u1-source-into-testing-proposed-updates/ > > -- > Best, > Nilesh -- http://fam-tille.de
Re: Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)
Hi again, Am Tue, May 16, 2023 at 07:49:55PM +0530 schrieb Nilesh Patra: > On Tue, May 16, 2023 at 07:25:15PM +0530, Nilesh Patra wrote: > > I personally prefer "1" over 2 as it is less noise (and effort). > > On second thoughts, I think sending it via testing-proposed-updates > would be a better thing to do, as this case perfectly fits the problem. I hope I was following developers reference about t-p-u[6] correctly and pushed $ git diff HEAD^ diff --git a/debian/changelog b/debian/changelog index 21d12c3..a2b6c26 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +r-cran-shiny (1.7.4+dfsg-3~deb12u1) bookworm; urgency=medium + + * Upload to testing-proposed-updates "bookworm" due to the fact that +there was an accidental upload of a new version of r-base to unstable + + -- Andreas Tille Wed, 17 May 2023 07:56:25 +0200 + r-cran-shiny (1.7.4+dfsg-3) unstable; urgency=medium * Fix link for normalize.css to git. I've choosen the version 1.7.4+dfsg-3~deb12u1 to match the requirement that the version is lower than in unstable $ if dpkg --compare-versions 1.7.4+dfsg-3 gt 1.7.4+dfsg-3~deb12u1 ; then echo "OK" ; else echo "hmmm" ; fi OK I wonder whether dput is working with target distribution bookworm since lintian throws an error. Release team is in CC - do you think I should file a bug right now or just after an upload? Kind regards Andreas. > > > [1] > > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-thematic/33619891/log.gz > > > [2] > > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treescape/33619892/log.gz > > > [3] > > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treespace/33619893/log.gz > > > [4] > > > https://tracker.debian.org/news/1429562/accepted-r-base-430-1-source-into-unstable/ > > [5] https://wiki.debian.org/TestingProposedUpdates [6] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#t-p-u -- http://fam-tille.de
Re: Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)
Am Tue, May 16, 2023 at 07:49:55PM +0530 schrieb Nilesh Patra: > On Tue, May 16, 2023 at 07:25:15PM +0530, Nilesh Patra wrote: > > I personally prefer "1" over 2 as it is less noise (and effort). > > On second thoughts, I think sending it via testing-proposed-updates > would be a better thing to do, as this case perfectly fits the problem. Seems to be an appropriate solution - given we should stick to smallest changes in packaging if possible. > It's be same effort in both cases (one upload + filing a bug with release > team). Since I will not manage to do so in the next 16 hours I'd be happy if someone might beat me in doing so. Otherwise I can catch up tomorrow. Thanks a lot for your hint Andreas. > > Let me know what you think. > > > > [1] > > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-thematic/33619891/log.gz > > > [2] > > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treescape/33619892/log.gz > > > [3] > > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treespace/33619893/log.gz > > > [4] > > > https://tracker.debian.org/news/1429562/accepted-r-base-430-1-source-into-unstable/ > > [5] https://wiki.debian.org/TestingProposedUpdates > > -- > Best, > Nilesh -- http://fam-tille.de
Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)
Hi, when fixing bug #1035428 I realised test suite issues with r-cran-thematic [1] -> Error in `svglite_(filename, bg, width, height, pointsize, standalone, always_valid)`: Graphics API version mismatch r-cran-treescape [2] r-cran-treespace [3] -> error is given if lambda is outside of [0,1] --- `medTree(trees, -1)` did not throw an error. As far as I can guess at least the first type of error (Graphics API version mismatch) is caused by the fact that a new upstream version of r-base (4.3.0-1) was uploaded to unstable (changelog[4] says to experimental so it seems by accident). I wonder what might be the most sensible strategy to fix this. Since an epoch is considered ugly I've seen some kind of 4.3.0+really+4.2.2.20221110 version number. However, in case of R it might not be the best idea to use this kind of fake version in a stable release. Kind regards Andreas. [1] https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-thematic/33619891/log.gz [2] https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treescape/33619892/log.gz [3] https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treespace/33619893/log.gz [4] https://tracker.debian.org/news/1429562/accepted-r-base-430-1-source-into-unstable/ -- http://fam-tille.de
Bug#1034288: RM: igdiscover/0.11-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm X-Debbugs-Cc: igdisco...@packages.debian.org, 1032...@bugs.debian.org, steffen_moel...@gmx.de Control: affects -1 + src:igdiscover According to bug #1032975 the package is non-functional and should not be released with bookworm. My last response to the bug report has refreshed the autoremoval timer which is not needed. Please remove the package from testing to clean up the release status. Thanks a lot for your work on the Debian release Andreas.
Bug#1033687: unblock: debian-pan/0.4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: debian-...@packages.debian.org, debian-pan-maintain...@alioth-lists.debian.net, pi...@debian.org Control: affects -1 + src:debian-pan Please unblock package debian-pan (Please provide enough (but not too much) information to help the release team to judge the request efficiently. E.g. by filling in the sections below.) [ Reason ] Debian PAN is a set of metapackages that was unfortunately out of focus before the freeze. It reflects the current state of the archive of the dependant packages and thus should show up in bookworm. [ Impact ] Users would get an old-fashioned package dependency status with the old version of debian-pan. [ Tests ] Unfortunately we do not have any means to test Blends metapackages. [ Risks ] The code is trivial - actually there is no real code inside these packages, just dependencies from other packages. [ Checklist ] [x] all changes are documented in the d/changelog of the 0.4~exp package which contained new metapackages and thus needed to pass new [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing I admit the debdiff is way longer than usually acceptable in unblock requests. It contains lots of changes that were assembled over a long time in Git. However, these changes were needed to make the package sensible at all. I admit it contains also spelling fixes, well - its finally about user experience when reading the descriptions [ Other info ] It might happen (as for all other Blends metapackages) that some additional version needs to be unblocked. This is in case some dependency will be removed in the freeze process. However, in this case the changes will be really minimal. Kind regards and thanks a lot for working on the Debian release Andreas. unblock debian-pan/0.4 diff -Nru debian-pan-0.3/config/control debian-pan-0.4/config/control --- debian-pan-0.3/config/control 2021-02-28 14:43:03.0 +0100 +++ debian-pan-0.4/config/control 2023-03-06 12:01:06.0 +0100 @@ -7,4 +7,19 @@ . These are the pan related metapackages in the PAN Blend project: . - * pan-something do something # FIXME + pan-coherent-diffraction: coherent diffraction software + pan-control-systems:control systems + pan-control-systems-dev: control system development packages + pan-data-reduction-frameworks: data reduction frameworks + pan-data-reduction-frameworks-dev: data reduction frameworks dev + pan-diffraction:diffraction software suit + pan-grazing-incidence: grazing incidence X-ray photon and neutron diffraction + pan-imaging:imaging software + pan-machine-learning: machine learning software + pan-modelling: modeling software + pan-mx: macro molecular diffraction + pan-powder: powder diffraction + pan-small-angle-scattering: small angle scattering + pan-spectroscopy: X-Rays and Neutron spectroscopy + pan-tomography: photons and neutrons (PAN) Blend tomography + pan-xas:EXAFS and XANES diff -Nru debian-pan-0.3/debian/changelog debian-pan-0.4/debian/changelog --- debian-pan-0.3/debian/changelog 2021-02-28 14:43:03.0 +0100 +++ debian-pan-0.4/debian/changelog 2023-03-06 12:01:06.0 +0100 @@ -1,3 +1,109 @@ +debian-pan (0.4) unstable; urgency=medium + + * Team upload. + * Spelling issues + * Fix description of data-reduction-frameworks-dev + + -- Andreas Tille Mon, 06 Mar 2023 12:01:06 +0100 + +debian-pan (0.4~exp) experimental; urgency=medium + + * Team upload. + + [ Picca Frédéric-Emmanuel ] + * updated the task. + + [ Andreas Tille ] + * Fix debian/copyright + * Standards-Version: 4.6.2 + + * start of automatic changelog entry * + + * Changes in metapackage dependencies + -pan-coherent-diffraction +added: + Recommends: facet-analyser, python3-moviepy + -pan-data-reduction-frameworks +added: + Recommends: python3-descartes, python3-periodictable, looktxt, + python3-pweave, python3-tables, python3-leather, + python-ipywidgets-doc, python3-sklearn, python3-mplcursors, + python-sklearn-doc, labplot, python3-bcolz, pandoc, + python3-dask, vitables, python-agate-doc, python3-skimage, + h5utils, hdf-compass, hdf5-tools, grads, python3-agate, + python3-opencv, python3-h5netcdf, view3dscene, python3-joypy, + python3-mpltoolkits.basemap, python3-xraydb, + python-tables-doc, python3-traitlets, python3-numpy-groupies, + python3-colorcet, libxrl-dev, libxrl11, python3-mpi4py, lz4, + python3-netcdf4, python3-gmplot, admesh, bitshuffle, xpython, + bcolz-doc, python3-zarr, zstd
Re: Upload of new upstream version before fix has migrated to testing (Was: Re: Bug#1032120: tiledb: uses atomic operations, but is not linked to libatomic)
[Release team in CC] Am Wed, Mar 15, 2023 at 08:45:21AM +0530 schrieb Nilesh Patra: > I am removing myself from the uploaders field/maintenance of tiledb-py. Feel > free to update it once tiledb is ready for migration. The repository > lives at python team namespace. I admit I'm strongly in favour of following release policy properly instead of putting work on other DDs who need to check rdepends. I became aware of this bug since genomicsdb received a testing removal warning. Thus I insist that the correct fix for this violation of the freeze policy is to upload 2.15.0-2+really_2.14.1 (or at your preference using an epoch) as I wrote before in this bug log[1]) @Dirk, I would be happy if you could simply say sorry guys for creating this noise and follow freeze policy. Kind regards Andreas. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032120#37 -- http://fam-tille.de
Re: Bug#1032545: r-cran-qpdf: FTBFS in testing: QPDF.hh:1569:36: error: ‘std::string_view’ has not been declared
Am Thu, Mar 09, 2023 at 10:08:02PM +0100 schrieb Sebastian Ramacher: > > What do you think? > > std::string_view was introduced in C++17, but r-cran-qpdf is building > with C++11. Have you tried bumping the C++ version? Ahhh, right. Thanks a lot for the hint. Just uploaded a fix. I guess I need to file an unblock request for the just uploaded r-cran-qpdf 1.3.0+dfsg-2? Kind regards Andreas. -- http://fam-tille.de
Re: Bug#1032545: r-cran-qpdf: FTBFS in testing: QPDF.hh:1569:36: error: ‘std::string_view’ has not been declared
Hi, Am Wed, Mar 08, 2023 at 09:30:38PM +0100 schrieb Lucas Nussbaum: > > /usr/include/qpdf/QPDF.hh:1569:36: error: ‘std::string_view’ has not been > > declared > > 1569 | void linearizationWarning(std::string_view); > > |^~~ > > In file included from bindings.cpp:3: > > /usr/include/qpdf/QPDFWriter.hh:557:27: error: ‘std::string_view’ has not > > been declared > > 557 | void writeString(std::string_view str); > > | ^~~ > > /usr/include/qpdf/QPDFWriter.hh:559:30: error: ‘std::string_view’ has not > > been declared > > 559 | void writeStringQDF(std::string_view str); > > | ^~~ > > /usr/include/qpdf/QPDFWriter.hh:560:32: error: ‘std::string_view’ has not > > been declared > > 560 | void writeStringNoQDF(std::string_view str); > > |^~~ > > make[1]: *** [/usr/lib/R/etc/Makeconf:178: bindings.o] Error 1 This error occures due to the upgrade of qpdf from 11.2.0 to 11.3.0. r-cran-qpdf ships with a code copy of 11.2.0 which was removed in favour of dynamic linking. The only way I see to fix this bug while keeping the same r-cran-qpdf version is to keep the original upstream tarball and link against the code copy. What do you think? Kind regards Andreas. -- http://fam-tille.de
Chain of Dependencies prevents closing RC bugs
Hi, to fix #1030884 python-cogent: FTBFS (ImportError: cannot import name 'float' from 'numpy') and let it migrate to testing it needs to wait for #950598 python3-jupyter-sphinx: package relies on unavailable `ipywidgets.embed` module which in turn needs #896460 Please package ipywidgets 7 which needs another not yet packaged precondition. Since I do not think that #896460 will be closed any time soon the only realistic solution to let python-cogent migrate will probably be to make it independent from python3-jupyter-sphinx by skipping features in its docs or simply do not generate the doc at all as long as its precondition will not be in testing. Do you think that's correct? Kind regards Andreas. -- http://fam-tille.de
Re: Bug#1022571: transition: pandas 1.3 -> 1.5
Hi Graham, Am Wed, Jan 25, 2023 at 02:28:37PM +0200 schrieb Graham Inggs: > On Wed, 25 Jan 2023 at 11:43, Andreas Tille wrote: > > I was motivated for this patch by Diane's statement on the Debian Med > > matrix channel that dask and dask.distributed are interconnected. If > > the autopkgtest on Salsa CI[4] would have passed I would have uploaded. > > We will temporarily remove dask.distributed from testing, which should > unblock dask and pandas. Thanks a lot! > No uploads please, until dask and pandas have migrated. Yep Andreas. -- http://fam-tille.de
Re: Bug#1022571: transition: pandas 1.3 -> 1.5
Hi Graham Am Tue, Jan 24, 2023 at 12:50:41PM +0200 schrieb Graham Inggs: > > On Tue, 24 Jan 2023 at 00:16, Rebecca N. Palmer > wrote: > > The remaining autopkgtest failures blocking pandas are: > > - dipy/amd64 and snakemake/i386 look like random flakiness: please retry > > them. (I think DMs can't use the self-service interface.) Or for dipy, > > see #1029533 for a possible fix. > > These have cleared up. > > > - python-xarray/i386 looks like xarray not pandas: see #1004869. > > Sometimes britney is too greedy and pins too many packages from > unstable. I managed to find the right combination [1] and got the > test to pass without python-xarray. Thanks a lot. > > - dask and dask.distributed have to go together, with or before pandas. > > There's nothing in the currently uploaded packages that specifies > this, although I do see a commit on salsa [2]. I was motivated for this patch by Diane's statement on the Debian Med matrix channel that dask and dask.distributed are interconnected. If the autopkgtest on Salsa CI[4] would have passed I would have uploaded. Unfortunately I have no idea how to deal with those PytestUnraisableExceptionWarnings raised in this test and thus I did not upload. > I tried running dask.distributed's autopkgtest with dask and itself > from unstable [3], but no luck. Diane, could you please comment on this or at least throw some ENOTIME error to let others know. Thanks a lot for you contribution in any case Andreas. > [1] https://ci.debian.net/packages/p/python-xarray/testing/i386/ > [2] > https://salsa.debian.org/python-team/packages/dask.distributed/-/commit/9df3fe1a0ea7538f742ebb162379e3cd50b388e6 > [3] https://ci.debian.net/packages/d/dask.distributed/testing/amd64/ [4] https://salsa.debian.org/python-team/packages/dask.distributed/-/jobs/3834919 -- http://fam-tille.de
Re: Python 3.11 for bookworm?
Am Tue, Jan 17, 2023 at 01:04:50AM +0100 schrieb Thomas Goirand: > > > #1023965 [src:pandas] pandas FTBFS with Python 3.11 as supported > > > version > > > #1024031 [src:numba] numba FTBFS with Python 3.11 as supported version > > I saw the above 2 were fixed. Fixed in the sense that there was an upload closing the bug. If you look at https://tracker.debian.org/pkg/pandas https://tracker.debian.org/pkg/numba you see multiple blockers for a testing migration. So the problem for the release persists. I have confirmations of upstream of several rdepends of these packages that they do not support 3.11 since these two packages do not officially support Python 3.11 yet (the Debian packages are coming with several patches - just one example of an answer from upstream for python-cogent[1]) > > I'd like to add > > > >#1027851 [src:pytorch] FTBFS with Python 3.11 as default version > > > > also with lots of rdepends. > > So we're back with one single bug. I remember seeing something similar in > another package ... (scratching my head...). The latest version of the > upstream code has some modifications to this broken Stream.cpp, have you > tried to apply them? No, I have not dealt with torch. I just know that this package is in the very competent hands of Mo Zhou who will know what to do. > Do you have more to share? It's harder to help if you don't ask for it. > IMO, feel free to give a full list of problematic packages in this list, so > others may help. As I said above the packages above are far from testing. If someone could lend helping hands to let these packages migrate this would be really helpful. > > I did not received any response to my "small" list. What does this > > mean for the transition to 3.11 process? > > As much as I know, we're moving toward having Python 3.11 only in Bookworm. > I'm not the person driving it though, and I am not in the best position to > make such choice, but I support it (as I would prefer having the nice > enhancements of Python 3.11 rather than lagging behind). Hopefully, I wont > regret it and wont find more failures in "my" packages. I understand the advantages of Python 3.11 and I'm not against releasing Bookworm with it. I'm against overlong freezing periods which I see as the consequence of pushing Python 3.11 while sticking to the current freeze shedule. If we would decide that Python 3.11 is really important I would consider shifting the testing period by one or two months. We have just seen that every full rebuild of the archive as Lucas recently did creates quite some new RC bugs that are related to the Python version bump and I expect more of these at the next rebuild. > > > You mean you are fixing Python 3.10 manually in some packages diverging > > > what will be default Python? > > > > Any answer to this question? > > All of my packages hopefully always test with all available versions, and > most run autopkgtest. So I was warned early of Py 3.11 failures. They are > all fixed, as much as I know (no opened RC bug remaining...). And no, > forcing Python 3.10 is *NOT* an option, one must fix failures in Python > 3.11. Since you said above that we want to release with 3.11 only this becomes clear. Luckily the teams where I'm working in have also quite good autopkgtest coverage so I'm positive about sensible warnings. > > I keep on thinking that the timing is unfortunate and that it > > will spoil the whole release process. > > I'm sad to read this. Hopefully, this is truth only for some of the packages > you care, and the vast majority of the packages are fine? I'm unfortunately > not in a good position to tell (I didn't run any survey of broken > packages...). We are just a couple of people who are fighting hard through scientific packages with a complex depency tree. Some of them (like numba) take ages to build even on amd64 (salsa CI is set to 6h here) and thus take quite some time to fix. As I said above I'm not against Python 3.11 per see. I'm simply afraid that this decision will delay the release process and IMHO it makes sense to shift the schedule if we decide that Python 3.11 is something we want. Kind regards Andreas. [1] https://github.com/cogent3/cogent3/issues/1263 -- http://fam-tille.de
Re: Python 3.11 for bookworm?
Am Sat, Jan 07, 2023 at 09:05:21AM +0100 schrieb Andreas Tille: > Hi Thomas, > > Am Thu, Jan 05, 2023 at 01:57:43PM +0100 schrieb Thomas Goirand: > > > > This has since already been discussed here: the final decision was to "at > > least try 3.11", which is exactly what we're doing. > > I admit I was not at site and may be I missunderstood what was finally > decided. From my perspective this "at least try" is that we are > actually trying by having 3.11 as additional supported version which has > triggered quite some work. We are approaching the Transition and > Toolchain Freeze in 5 days[1]. Given that switching default Python is a > transition I wonder how you can assume that this is the right time to > suggest this. I would not have been that astonished if you would have > done so say at first December last year. But now its absolutely clear > that a migration (with the "option" to revert which will cause extra > work) will pour sand into the gears of the release process. How will we decide whether the "at least try 3.11" is success or fail? Did we defined anything I might have missed in terms of number of packages that need to pass or number of packages we shoule not loose? > > FYI, I'm down with only 2 major bugs (I don't mind much if the other 3 RC > > bugs push the 3 affected packages away from the release, it's just a "would > > be nice" thing ATM): > > That's a nice situation for the field you are working in. > > > > If I would create a list mine whould be way longer. > > > > Please share it in this list! > >#1023965 [src:pandas] pandas FTBFS with Python 3.11 as supported version >#1024031 [src:numba] numba FTBFS with Python 3.11 as supported version I'd like to add #1027851 [src:pytorch] FTBFS with Python 3.11 as default version also with lots of rdepends. > These packages have a sufficient amount of rdepends and usually trigger > lots of other autopkgtest failures in other packages which will keep > them out of testing for quite some time. We could need all helping > hands to fix these ... all noise that will happen afterwards will keep > the relevant teams busy enough. I did not received any response to my "small" list. What does this mean for the transition to 3.11 process? > > > We are constantly beaten by removal from testing warnings > > > even with Python3.11 as an option and sometimes we simply need to remove > > > that option as a temporary means for bookworm. > > > > Same over here. It's finally looking good for me after 2 months of heavy > > efforts. > > You mean you are fixing Python 3.10 manually in some packages diverging > what will be default Python? Any answer to this question? > > > No better solution but better timing which means after bookworm release. > > > > I've read *many* people saying it would be disappointing for them to see > > their package removed because of Python 3.11. Well, please consider that it > > would also be very disappointing to *not* have Python 3.11 for those who > > managed constantly fix issues for it. > > I can understand that we can never satisfy the needs of everybody. My > main problem is the extremely unfortunate timing that is happening now. > > > The timing was exactly what was discussed during Debconf: it's very annoying > > that this year, upstream Python release was one month late... we're only > > trying to deal with it. > > I do not remember that the scchedule was discussed. > >* Add 3.11 as a supported Python3 version > > was done in python3-defaults (3.10.6-2) at Fri, 11 Nov 2022 11:10:31 > +0200. At 12. December Graham suggested on the behalf of the release > team[2] to switch to 3.11. If we would have acted upon this at that > very time I would have considered this quite dense but the last chance > to consider this in line with the "lets try" attempt discussed at > DebConf. > > Bug #1026825: python3.11 as default filed right before (21.12.) a series > of holidays in the region of the world where lots of developers will > typically reduce their activity which is closely followed by the first > freeze step is IMHO something else. Since I realised that the transition > was started[3] our discussion is a bit useless. I just want to explain > the motivation why I sounded "astonished" since you said that you do > not understood astonishment since we are following the suggested plan. I keep on thinking that the timing is unfortunate and that it will spoil the whole release process. Kind regards Andreas. > > [1] https://release.debian.org/testing/freeze_policy.html > [2] https://lists.debian.org/debian-python/2022/12/msg00074.html > [3] https://release.debian.org/transitions/html/python3.11-default.html > > -- > http://fam-tille.de > > -- http://fam-tille.de
Re: transition: pandas 1.3 -> 1.5
Am Mon, Jan 09, 2023 at 01:44:40PM +0200 schrieb Graham Inggs: > Hi Rebecca > > On Fri, 6 Jan 2023 at 10:30, Rebecca N. Palmer > wrote: > > Should this go ahead before the freeze? I think yes if the new dask > > works, but am open to disagreement. > > Please go ahead. With numpy 1:1.24.1-2 built on all release > architectures, now is a good time. Fine for me. Thanks a lot for working on pandas Andreas. -- http://fam-tille.de
Re: Python 3.11 for bookworm?
Hi Thomas, Am Thu, Jan 05, 2023 at 01:57:43PM +0100 schrieb Thomas Goirand: > > This has since already been discussed here: the final decision was to "at > least try 3.11", which is exactly what we're doing. I admit I was not at site and may be I missunderstood what was finally decided. From my perspective this "at least try" is that we are actually trying by having 3.11 as additional supported version which has triggered quite some work. We are approaching the Transition and Toolchain Freeze in 5 days[1]. Given that switching default Python is a transition I wonder how you can assume that this is the right time to suggest this. I would not have been that astonished if you would have done so say at first December last year. But now its absolutely clear that a migration (with the "option" to revert which will cause extra work) will pour sand into the gears of the release process. > FYI, I'm down with only 2 major bugs (I don't mind much if the other 3 RC > bugs push the 3 affected packages away from the release, it's just a "would > be nice" thing ATM): That's a nice situation for the field you are working in. > > If I would create a list mine whould be way longer. > > Please share it in this list! #1023965 [src:pandas] pandas FTBFS with Python 3.11 as supported version #1024031 [src:numba] numba FTBFS with Python 3.11 as supported version These packages have a sufficient amount of rdepends and usually trigger lots of other autopkgtest failures in other packages which will keep them out of testing for quite some time. We could need all helping hands to fix these ... all noise that will happen afterwards will keep the relevant teams busy enough. > > We are constantly beaten by removal from testing warnings > > even with Python3.11 as an option and sometimes we simply need to remove > > that option as a temporary means for bookworm. > > Same over here. It's finally looking good for me after 2 months of heavy > efforts. You mean you are fixing Python 3.10 manually in some packages diverging what will be default Python? > > No better solution but better timing which means after bookworm release. > > I've read *many* people saying it would be disappointing for them to see > their package removed because of Python 3.11. Well, please consider that it > would also be very disappointing to *not* have Python 3.11 for those who > managed constantly fix issues for it. I can understand that we can never satisfy the needs of everybody. My main problem is the extremely unfortunate timing that is happening now. > The timing was exactly what was discussed during Debconf: it's very annoying > that this year, upstream Python release was one month late... we're only > trying to deal with it. I do not remember that the scchedule was discussed. * Add 3.11 as a supported Python3 version was done in python3-defaults (3.10.6-2) at Fri, 11 Nov 2022 11:10:31 +0200. At 12. December Graham suggested on the behalf of the release team[2] to switch to 3.11. If we would have acted upon this at that very time I would have considered this quite dense but the last chance to consider this in line with the "lets try" attempt discussed at DebConf. Bug #1026825: python3.11 as default filed right before (21.12.) a series of holidays in the region of the world where lots of developers will typically reduce their activity which is closely followed by the first freeze step is IMHO something else. Since I realised that the transition was started[3] our discussion is a bit useless. I just want to explain the motivation why I sounded "astonished" since you said that you do not understood astonishment since we are following the suggested plan. Kind regards Andreas. [1] https://release.debian.org/testing/freeze_policy.html [2] https://lists.debian.org/debian-python/2022/12/msg00074.html [3] https://release.debian.org/transitions/html/python3.11-default.html -- http://fam-tille.de
Bug#1023731: BioC Packages are now clean (one exception with RC bug filed) (Was: Bug#1023731: Any idea why debci picks old versions)
Am Thu, Dec 08, 2022 at 06:08:04PM +0100 schrieb Sebastian Ramacher: > It did. Closing. Thanks a lot Andreas. -- http://fam-tille.de
Bug#1023731: BioC Packages are now clean (one exception with RC bug filed) (Was: Bug#1023731: Any idea why debci picks old versions)
Am Sun, Dec 04, 2022 at 12:22:53PM +0100 schrieb Sebastian Ramacher: > No, it's not. If you check the logs from r-bioc-htsfilter for example > (https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-bioc-htsfilter/28944996/log.gz), > you see that some packages have actual regressions: The log has Get:1 http://deb.debian.org/debian testing/main r-bioc-htsfilter 1.36.0+dfsg-1 (dsc) [2,244 B] which is BioC 3.15. In unstable is r-bioc-htsfilter 1.38.0+dfsg-2 which belongs to Bioc 3.15 > Removing autopkgtest-satdep (0) ... > autopkgtest [19:15:37]: test run-unit-test: [--- > cp: cannot stat '/usr/share/doc/r-bioc-htsfilter/tests/*': No such file or > directory This line is in the test of the *old* package and was fixed in 1.38.0+dfsg-2. I can't do anything about this, sorry. > > If this might help and is easily to realise removing all r-bioc-* > > packages from testing could enable the migration of the packages in > > unstable. > > I've done that now. Thanks. This will hopefully solve that situation. Kind regards Andreas. -- http://fam-tille.de
Bug#1023731: BioC Packages are now clean (one exception with RC bug filed) (Was: Bug#1023731: Any idea why debci picks old versions)
Am Sat, Dec 03, 2022 at 10:53:58PM +0100 schrieb Sebastian Ramacher: > And there are many more. r-bioc-biocparallel is another one. This smells > like many insufficient dependencies. Sorry, this all seems to be the same britney failure Paul was reporting. The tests are all against the versions in testing which makes no sense at all. These tests are not fixable since the old versions of BioC 3.15 are bound to fail with packages from 3.16. If this might help and is easily to realise removing all r-bioc-* packages from testing could enable the migration of the packages in unstable. Kind regards Andreas. -- http://fam-tille.de
Bug#1023731: BioC Packages are now clean (one exception with RC bug filed) (Was: Bug#1023731: Any idea why debci picks old versions)
Hi Paul, Am Sat, Dec 03, 2022 at 09:34:09PM +0100 schrieb Paul Gevers: > On 29-11-2022 10:26, Andreas Tille wrote: > > Now there is only one remaining one which is a real > > problem which I have reported upstream (see bug #1025045). If > > r-bioc-structuralvariantannotation would be removed from testing I > > do not see any blocker for the transition any more. > > I removed r-bioc-structuralvariantannotation Thanks a lot. > but the transition is blocked > on an autopkgtest regressions caused by r-bioc-iranges. This is also a false positive since for sure the test against r-bioc-fishpond 2.2.0+ds-2 fails since this belongs to BioConductor 3.15. Kind regards Andreas. -- http://fam-tille.de
Bug#1023731: BioC Packages are now clean (one exception with RC bug filed) (Was: Bug#1023731: Any idea why debci picks old versions)
Hi again, Am Mon, Nov 28, 2022 at 09:32:13PM +0100 schrieb Andreas Tille: > So you want to say, the fact that the current debci results that are > listed on the r-bioc-biocgenerics page are based on packages that are > replaced in unstable and the current packages that are fixed are not > listed with recent debci results, is due to a bug in britney? > > Thanks for the manual triggers, hope this will help here This has definitely helped to clean-up the debci related excuses from false positives. Now there is only one remaining one which is a real problem which I have reported upstream (see bug #1025045). If r-bioc-structuralvariantannotation would be removed from testing I do not see any blocker for the transition any more. The good news is that ftpmaster accepted all preconditions right in time, so I was able to upload all missings this morning. IMHO this is a good sign for me, that the current strategy "do the transition right in unstable and see what new preconditions are needed when doing so" is not really a blocker in the current case. Please let me know if you think this is not the case. Kind regards Andreas. -- http://fam-tille.de
Bug#1023731: Any idea why debci picks old versions (Was: Bug#1023731: BioC Transition blocked by new dependencies)
Hi Paul, Am Mon, Nov 28, 2022 at 08:23:12PM +0100 schrieb Paul Gevers: > > I'm constantly checking the tracker page of r-bioc-biocgenerics[1] to > > follow the transition status. I realised that debci picks old, not yet > > fixed package versions like: > > > >r-bioc-biocfilecache/2.4.0+dfsg-1 while 2.4.0+dfsg-2 is in unstable > >r-bioc-biocsingular/1.12.0+ds-1 while 1.14.0+ds-2 is in unstable > >(I've just uploaded fixed r-bioc-bluster - lets see what will be picked) > >r-bioc-edaseq/2.30.0+dfsg-1 while 2.32.0+dfsg-2 is in unstable > > It's not debci that picks them, but rather britney (our migration software) > that doesn't know from the information it uses that r-bioc-biocgenerics from > unstable makes r-bioc-biocfilecache from testing uninstallable. I haven't > checked but I suspect that this transition is declared via Provides and this > *might* mean that britney doesn't handle Provides ideally for this use case. > > > I wonder when debci will be run with the latest versions in unstable > > that are fixing the build issues. > > *Probably* when bugs in britney regarding this use of Provides are fixed. > For now, I'll schedule some tests manually with the Release Team > credentials. So you want to say, the fact that the current debci results that are listed on the r-bioc-biocgenerics page are based on packages that are replaced in unstable and the current packages that are fixed are not listed with recent debci results, is due to a bug in britney? Thanks for the manual triggers, hope this will help here Andreas. -- http://fam-tille.de
Bug#1023731: Any idea why debci picks old versions (Was: Bug#1023731: BioC Transition blocked by new dependencies)
Hi, I'm constantly checking the tracker page of r-bioc-biocgenerics[1] to follow the transition status. I realised that debci picks old, not yet fixed package versions like: r-bioc-biocfilecache/2.4.0+dfsg-1 while 2.4.0+dfsg-2 is in unstable r-bioc-biocsingular/1.12.0+ds-1 while 1.14.0+ds-2 is in unstable (I've just uploaded fixed r-bioc-bluster - lets see what will be picked) r-bioc-edaseq/2.30.0+dfsg-1 while 2.32.0+dfsg-2 is in unstable I wonder when debci will be run with the latest versions in unstable that are fixing the build issues. Kind regards Andreas. PS: First round of new predependencies was done. I've fixed the remaining reasons for rejects. [1] https://tracker.debian.org/pkg/r-bioc-biocgenerics -- http://fam-tille.de
