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)
Le jeudi 06 juillet 2023 à 22:09 +0200, Andreas Tille a écrit : > 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. […] > I'd consider it sensible if you open a bug against dh-r where we can > document the change you are suggesting. Done in #1040515. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1040505: bookworm-pu: package rime-cantonese/0.0~git20230209.e0295fa-2~deb12u1
Package: release.debian.org Control: affects -1 + src:rime-cantonese X-Debbugs-Cc: rime-canton...@packages.debian.org f...@debian.org User: release.debian@packages.debian.org Usertags: pu Tags: bookworm X-Debbugs-Cc: by...@debian.org Severity: normal [ Reason ] This upload adds a missing file (word frequency file) to the installation of binary package rime-data-jyut6ping3 to fix https://bugs.debian.org/1037022 . [ Impact ] If the update is not approved, the rime-cantonese input method will not show word candidates according to the frequency, which makes it very difficult to use. [ Tests ] Manually tested by myself and the original bug submitter. [ Risks ] Minimal. Only a new file appears in the new binary package. [ Checklist ] [X] *all* changes are documented in the d/changelog [X] I reviewed all changes and I approve them [X] attach debdiff against the package in (old)stable [X] the issue is verified as fixed in unstable [ Changes ] Full debdiff pasted below. diff -Nru rime-cantonese-0.0~git20230209.e0295fa/debian/changelog rime-cantonese-0.0~git20230209.e0295fa/debian/changelog --- rime-cantonese-0.0~git20230209.e0295fa/debian/changelog 2023-02-09 12:49:08.0 -0500 +++ rime-cantonese-0.0~git20230209.e0295fa/debian/changelog 2023-07-06 16:35:12.0 -0400 @@ -1,3 +1,18 @@ +rime-cantonese (0.0~git20230209.e0295fa-2~deb12u1) bookworm; urgency=medium + + * Upload fix to Debian Bookworm. + + -- Boyuan Yang Thu, 06 Jul 2023 16:35:12 -0400 + +rime-cantonese (0.0~git20230209.e0295fa-2) unstable; urgency=medium + + * Team upload. + * Install new /usr/share/rime-data/essay-cantonese.txt vocabulary file +so that the words and characters are sorted by their frequency +for a smooth Cantonese typing experience like before. (Closes: #1037022) + + -- Anthony Fok Thu, 01 Jun 2023 14:32:16 -0600 + rime-cantonese (0.0~git20230209.e0295fa-1) unstable; urgency=medium * New upstream snapshot. diff -Nru rime-cantonese-0.0~git20230209.e0295fa/debian/rime-data-jyut6ping3.install rime-cantonese-0.0~git20230209.e0295fa/debian/rime-data-jyut6ping3.install --- rime-cantonese-0.0~git20230209.e0295fa/debian/rime-data-jyut6ping3.install 2022-11-05 15:57:28.0 -0400 +++ rime-cantonese-0.0~git20230209.e0295fa/debian/rime-data-jyut6ping3.install 2023-07-06 16:34:31.0 -0400 @@ -2,3 +2,4 @@ jyut6ping3*.yaml usr/share/rime-data/ opencc usr/share/rime-data/ symbols_cantonese.yaml /usr/share/rime-data/ +essay-cantonese.txt /usr/share/rime-data/ -- Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part
Processed: bookworm-pu: package rime-cantonese/0.0~git20230209.e0295fa-2~deb12u1
Processing control commands: > affects -1 + src:rime-cantonese Bug #1040505 [release.debian.org] bookworm-pu: package rime-cantonese/0.0~git20230209.e0295fa-2~deb12u1 Added indication that 1040505 affects src:rime-cantonese -- 1040505: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040505 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: bookworm-pu: package rime-luna-pinyin/0.0~git20230204.79aeae2-3~deb12u1
Processing control commands: > affects -1 + src:rime-luna-pinyin Bug #1040502 [release.debian.org] bookworm-pu: package rime-luna-pinyin/0.0~git20230204.79aeae2-3~deb12u1 Added indication that 1040502 affects src:rime-luna-pinyin -- 1040502: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040502 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1040502: bookworm-pu: package rime-luna-pinyin/0.0~git20230204.79aeae2-3~deb12u1
Package: release.debian.org Control: affects -1 + src:rime-luna-pinyin X-Debbugs-Cc: rime-luna-pin...@packages.debian.org eni...@petalmail.com User: release.debian@packages.debian.org Usertags: pu Tags: bookworm X-Debbugs-Cc: by...@debian.org Severity: normal [ Reason ] Fix input method deployment error and bug in customizing input method as reported in https://bugs.debian.org/1040403 . It is caused by missing installation of pinyin.yaml from upstream source code to binary package according to the upstream bug report at https://github.com/rime/home/issues/1326 . [ Impact ] If the update is not approved, the user will not be able to customize rime-luna-pinyin input method, and error message will occur every time on startup. [ Tests ] Manual testing by myself and the original bug submitter. [ Risks ] Minimal risk. Difference between fixed package and problematic package is only the missing pinyin.yaml file. [ Checklist ] [X] *all* changes are documented in the d/changelog [X] I reviewed all changes and I approve them [X] attach debdiff against the package in (old)stable [X] the issue is verified as fixed in unstable [ Changes ] Full debdiff pasted here. diff -Nru rime-luna-pinyin-0.0~git20230204.79aeae2/debian/changelog rime-luna-pinyin-0.0~git20230204.79aeae2/debian/changelog --- rime-luna-pinyin-0.0~git20230204.79aeae2/debian/changelog 2023-02-20 20:39:19.0 -0500 +++ rime-luna-pinyin-0.0~git20230204.79aeae2/debian/changelog 2023-07-06 16:21:47.0 -0400 @@ -1,3 +1,16 @@ +rime-luna-pinyin (0.0~git20230204.79aeae2-3~deb12u1) bookworm; urgency=medium + + * Upload to Debian Bookworm. + + -- Boyuan Yang Thu, 06 Jul 2023 16:21:47 -0400 + +rime-luna-pinyin (0.0~git20230204.79aeae2-3) unstable; urgency=medium + + * debian/rime-data-luna-pinyin.install: Also install missing +pinyin schema data. (Closes: #1040403) + + -- Boyuan Yang Thu, 06 Jul 2023 11:46:15 -0400 + rime-luna-pinyin (0.0~git20230204.79aeae2-2) unstable; urgency=medium * debian/rime-data-luna-pinyin.install: Also install missing diff -Nru rime-luna-pinyin-0.0~git20230204.79aeae2/debian/rime-data-luna-pinyin.install rime-luna-pinyin-0.0~git20230204.79aeae2/debian/rime-data-luna-pinyin.install --- rime-luna-pinyin-0.0~git20230204.79aeae2/debian/rime-data-luna-pinyin.install 2023-02-20 20:39:12.0 -0500 +++ rime-luna-pinyin-0.0~git20230204.79aeae2/debian/rime-data-luna-pinyin.install 2023-07-06 11:51:03.0 -0400 @@ -1,2 +1,3 @@ build/luna* usr/share/rime-data/build/ *luna*.yaml usr/share/rime-data +pinyin.yaml usr/share/rime-data -- Best Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part
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: Seeking advise how to proceed with the transition / move R stack to testing (Was: Bug#1040001: transition: r-base)
On Thu, Jul 06, 2023 at 02:24:57PM -0500, Dirk Eddelbuettel wrote: > [...] I understood some of it (not completely, possibly because of lack of background with R extensions), but thanks a lot for taking the time to explain it to me! > So if tibble does this now, it should only affect tibble itself -- unless of > course a dependent package calls directly into the native code of tibble > (possible, but rare). I found some code in vctrs which do some tibble specific stuff, like https://sources.debian.org/src/r-cran-vctrs/0.6.3-1/src/type-tibble.c/ But I don't think there are calls for native code anywhere. No idea where this comes from, then. > | Since you are building with R from unstable and tibble from testing > | (built with an older R), it chokes and works when both are new. > > Not sure I agree. That should still work. Quick check in Docker (using the > r-base image I maintain) shows it does: > > root@f39da83dba5a:/# dpkg -l r-base-core r-cran-tibble | tail -2 Very weird. That means you're unable to repro the failure in https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-rsample/35451568/log.gz Right? Would you have an idea on the github dplyr issue then? The log seems to be the same as we see in the CI https://github.com/tidyverse/dplyr/issues/6793 > It's simpy that testing has an older one and (esp in the tidyverse) things > change quickly and packages want to be in consistent cohort. But AFAICS, in both the scenarios (with and without failure) it is essentially running with the same version of tidyverse, so ideally pulling tibble from unstable and mixing it with an older tidyverse should break, right? (It's the opposite here and I'm quite confused). > | This attribute has got something to do with R extensions' entry > | points / dll compatibilty, but I simply do not have enough background > | with r-core to comment beyond this point, I'm afraid. > > Hope the above helped a little. Yes, thanks again. Best, Nilesh signature.asc Description: PGP signature
Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing (Was: Bug#1040001: transition: r-base)
On 7 July 2023 at 00:33, Nilesh Patra wrote:
| I think we are hitting this issue here:
https://github.com/tidyverse/dplyr/issues/6793
| The comment says "Looks like some package in the stack sets
R_forceSymbols(dll, TRUE)" and that package is tibble
|
| | $ grep -rnw R_forceSymbols
| | src/init.c:19: R_forceSymbols(dll, TRUE);
That mechanism should not spill from one package to the next.
What we have here is that (R) packages with compiled code can (optionally)
declare in NAMESPACE whether or not 'symbols' (ie the entrypoints for the
compiled code) should be a registered symbol (to R), or (as they used to be)
strings. That is then used in the first argument to .Call() as in eg
.Call(myfunc) as opposed to .Call("myfunc"). It has small efficiency
gains. Most packages do that now.
Now, another (less frequently-used) option is in the intialization file run
at package to also say R_forceSymbols in which case the second ("string")
form is no longer allowed. Few packages do that.
So if tibble does this now, it should only affect tibble itself -- unless of
course a dependent package calls directly into the native code of tibble
(possible, but rare).
So I sum in should not spill. I could be wrong but if there were general
spillage it would affect all R use of compiled packages and it very clearly
does not. So in short, this force symbol resolution should only affect the
symbols from the one shared (per-package) library it is set for.
| Since you are building with R from unstable and tibble from testing
| (built with an older R), it chokes and works when both are new.
Not sure I agree. That should still work. Quick check in Docker (using the
r-base image I maintain) shows it does:
root@f39da83dba5a:/# dpkg -l r-base-core r-cran-tibble | tail -2
ii r-base-core4.3.1-2 amd64GNU R core of statistical
computation and graphics system
ii r-cran-tibble 3.1.8+dfsg-1 amd64GNU R Simple Data Frames
root@f39da83dba5a:/# Rscript -e 'library(tibble); print(as_tibble(mtcars))'
# A tibble: 32 × 11
mpg cyl disphp dratwt qsecvsam gear carb
1 21 6 160110 3.9 2.62 16.5 0 1 4 4
2 21 6 160110 3.9 2.88 17.0 0 1 4 4
3 22.8 4 108 93 3.85 2.32 18.6 1 1 4 1
4 21.4 6 258110 3.08 3.22 19.4 1 0 3 1
5 18.7 8 360175 3.15 3.44 17.0 0 0 3 2
6 18.1 6 225105 2.76 3.46 20.2 1 0 3 1
7 14.3 8 360245 3.21 3.57 15.8 0 0 3 4
8 24.4 4 147.62 3.69 3.19 20 1 0 4 2
9 22.8 4 141.95 3.92 3.15 22.9 1 0 4 2
10 19.2 6 168. 123 3.92 3.44 18.3 1 0 4 4
# … with 22 more rows
root@f39da83dba5a:/#
It's simpy that testing has an older one and (esp in the tidyverse) things
change quickly and packages want to be in consistent cohort.
| This attribute has got something to do with R extensions' entry
| points / dll compatibilty, but I simply do not have enough background
| with r-core to comment beyond this point, I'm afraid.
Hope the above helped a little.
Dirk
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing (Was: Bug#1040001: transition: r-base)
On Thu, Jul 06, 2023 at 09:13:46PM +0200, Sébastien Villemot wrote: > > 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. 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/ Best, Nilesh signature.asc Description: PGP signature
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&arch=amd64&ver=3.2.1%2Bdfsg-2&stamp=1688629916&raw=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)
Le jeudi 06 juillet 2023 à 21:02 +0200, Andreas Tille a écrit : > Am Thu, Jul 06, 2023 at 07:08:04PM +0200 schrieb Paul Gevers: > > 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.) 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. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing (Was: Bug#1040001: transition: r-base)
Hi Paul, On Thu, Jul 06, 2023 at 08:28:45PM +0200, Paul Gevers wrote: > 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; > e.g. here: https://ci.debian.net/packages/r/r-cran-rsample/testing/amd64/ > > 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&arch=amd64&ver=3.2.1%2Bdfsg-2&stamp=1688629916&raw=0 > so it doesn't seem to be involved in that part of the discussion. I think we are hitting this issue here: https://github.com/tidyverse/dplyr/issues/6793 The comment says "Looks like some package in the stack sets R_forceSymbols(dll, TRUE)" and that package is tibble | $ grep -rnw R_forceSymbols | src/init.c:19: R_forceSymbols(dll, TRUE); Since you are building with R from unstable and tibble from testing (built with an older R), it chokes and works when both are new. This attribute has got something to do with R extensions' entry points / dll compatibilty, but I simply do not have enough background with r-core to comment beyond this point, I'm afraid. Best, Nilesh signature.asc Description: PGP signature
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
Processed: transition: r-bioc-biocgenerics
Processing control commands: > affects -1 + src:r-bioc-biocgenerics Bug #1040498 [release.debian.org] transition: r-bioc-biocgenerics Added indication that 1040498 affects src:r-bioc-biocgenerics -- 1040498: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040498 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
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, 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; e.g. here: https://ci.debian.net/packages/r/r-cran-rsample/testing/amd64/ 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&arch=amd64&ver=3.2.1%2Bdfsg-2&stamp=1688629916&raw=0 so it doesn't seem to be involved in that part of the discussion. Paul OpenPGP_signature Description: OpenPGP digital signature
Processed: Re: Bug#1039860: bullseye-pu: package nvidia-graphics-drivers-tesla-470/470.199.02-1~deb11u1
Processing control commands: > tags -1 + confirmed Bug #1039861 [release.debian.org] bookworm-pu: package nvidia-graphics-drivers-tesla-470/470.199.02-1~deb12u1 Added tag(s) confirmed. -- 1039861: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039861 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#1039860: bullseye-pu: package nvidia-graphics-drivers-tesla-470/470.199.02-1~deb11u1
Processing control commands: > tags -1 + confirmed Bug #1039860 [release.debian.org] bullseye-pu: package nvidia-graphics-drivers-tesla-470/470.199.02-1~deb11u1 Added tag(s) confirmed. -- 1039860: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039860 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1039860: bullseye-pu: package nvidia-graphics-drivers-tesla-470/470.199.02-1~deb11u1
Control: tags -1 + confirmed On Thu, 2023-06-29 at 00:29 +0200, Andreas Beckmann wrote: > Package: release.debian.org > Severity: normal > Tags: bullseye > User: release.debian@packages.debian.org > Usertags: pu > Control: clone -1 -2 > Control: retitle -2 bookworm-pu: package nvidia-graphics-drivers- > tesla-470/470.199.02-1~deb12u1 > Control: tag -2 = bookworm > Control: usertag -2 pu > fwiw, setting usertags via Control: doesn't work; fixed separately. > [ Reason ] > Let's update nvidia-graphics-drivers-tesla-470 in bookworm/bullseye > to a new upstream release fixing some CVEs. > Please go ahead. Regards, Adam
Processed: Re: Bug#1040142: bookworm-pu: package aide/0.18.3-1+deb12u2
Processing control commands: > tags -1 + confirmed Bug #1040142 [release.debian.org] bookworm-pu: package aide/0.18.3-1+deb12u2 Added tag(s) confirmed. -- 1040142: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040142 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1040142: bookworm-pu: package aide/0.18.3-1+deb12u2
Control: tags -1 + confirmed On Sat, 2023-07-01 at 16:03 +0200, Marc Haber wrote: > This update augments 0.18.3-1+deb12u1 which has already been accepted > for bookworm-pu last week. It fixes #1039936, an important bug that > is a > regression from bullseye and affects directory processing when using > equals rules. > > [ Impact ] > Without this bug fixes, equals rules concerning directories are > incorrectly processed, which differs from the way that bullseye's > aide > handled this case and also differs from the way operation is > documented. > Debian's default configuration doesn't use equals rules and is > therefore > not affected, but local configurations might be. > Please go ahead. Regards, Adam
Processed: Re: Bug#1040139: bookworm-pu: package exim4/4.96-15
Processing control commands: > tags -1 + confirmed Bug #1040139 [release.debian.org] bookworm-pu: package exim4/4.96-15 Added tag(s) confirmed. -- 1040139: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040139 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1040139: bookworm-pu: package exim4/4.96-15
Control: tags -1 + confirmed
On Sun, 2023-07-02 at 15:11 +0200, Andreas Metzler wrote:
> I would like to get most of the changes from 4.96-16
> (unstable/testing)
> into bookworm:
>* 75_42-Fix-run-arg-parsing.patch (From upstream GIT master,
> backported by
> Bryce Harrington for Ubuntu): Fix argument parsing for ${run }
> expansion.
> Previously, when an argument included a close-brace character
> (eg. it
> itself used an expansion) an error occurred. Closes: #1025420
>* 75_68-Fix-srs_encode-.-for-mod-1024-day-zero.patch from upstream
> GIT
> master: Fix ${srs_encode ..}. Previously it would give a bad
> result for
> one day every 1024 days.
>
> The former is something has already popped up a couple of times on
> the
> upstream user support mailing list.
>
Please go ahead.
Regards,
Adam
Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing (Was: Bug#1040001: transition: r-base)
Hi Andreas, On 06-07-2023 16:44, Andreas Tille wrote: Am Thu, Jul 06, 2023 at 09:56:31AM +0200 schrieb Andreas Tille: 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. 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. 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. Please all involved, hold any uploads in the r-* world until we get r-base migrated unless it's needed (and we acked it). 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. We should probably file a bug against dh-r (I guess) to fix that dependency. Or did we conclude that wrong? OpenPGP_signature Description: OpenPGP digital signature
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
NEW changes in stable-new
Processing changes file: mediawiki_1.39.4-1~deb12u1_source.changes ACCEPT Processing changes file: mediawiki_1.39.4-1~deb12u1_all-buildd.changes ACCEPT
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
