Bug#971415: transition: ocaml
Hi On 2020-11-02 19:18:45 +0100, Paul Gevers wrote: > HI Stéphane, > > On 02-11-2020 16:56, Stéphane Glondu wrote: > >> autopkgtest for ocaml-cairo2/0.6.1+dfsg-5: amd64: Regression ♻ (reference > >> ♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), > >> i386: Regression ♻ (reference ♻), ppc64el: Regression ♻ (reference ♻) > > > > However, I don't understand why it complains about > > ocaml-cairo2/0.6.1+dfsg-5 whereas version 0.6.1+dfsg-6 is fixed. Does > > something need to be done? > > Your symptoms describe a missing *versioned* Depends/Breaks or test > dependency. The migration software tries run tests with the minimum > changes. So, if nothing makes sure that the version from unstable is > needed, it will run with as much packages as possible from testing. What > we see in the logs is that it installs the test suite from testing. > Then, the test dependencies are installed and apt-get reports that it > can't install the required packages. It then falls back to enable > everything from unstable and then installation is possible. > > Do you confirm that the issue is only in the test? I think we can ignore > this issue then (or better, trigger the test manually with ocaml-cairo2 > from unstable. With the description above, do you understand why the > relations in the packages don't teach our migration software what to do? The test fails because it tries to build the examples contained in the source package. The version in testing, 0.6.1+dfsg-5, fails to build with ocaml 4.11.1, so that's expected. The issue was fixed in 0.6.1+dfsg-6. Since Depends and Breaks do not affect source packages, I don't think this is fixable in any of the involved packages other than by fixing the FTFBS bug. I think this issue can be ignored and I will add a hint. Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#971415: transition: ocaml
HI Stéphane, On 02-11-2020 16:56, Stéphane Glondu wrote: >> autopkgtest for ocaml-cairo2/0.6.1+dfsg-5: amd64: Regression ♻ (reference >> ♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), >> i386: Regression ♻ (reference ♻), ppc64el: Regression ♻ (reference ♻) > > However, I don't understand why it complains about > ocaml-cairo2/0.6.1+dfsg-5 whereas version 0.6.1+dfsg-6 is fixed. Does > something need to be done? Your symptoms describe a missing *versioned* Depends/Breaks or test dependency. The migration software tries run tests with the minimum changes. So, if nothing makes sure that the version from unstable is needed, it will run with as much packages as possible from testing. What we see in the logs is that it installs the test suite from testing. Then, the test dependencies are installed and apt-get reports that it can't install the required packages. It then falls back to enable everything from unstable and then installation is possible. Do you confirm that the issue is only in the test? I think we can ignore this issue then (or better, trigger the test manually with ocaml-cairo2 from unstable. With the description above, do you understand why the relations in the packages don't teach our migration software what to do? Paul signature.asc Description: OpenPGP digital signature
Bug#971415: transition: ocaml
Le 16/10/2020 à 11:31, Stéphane Glondu a écrit :
> I have scheduled all binNMUs and uploaded the necessary packages, and
> most of packages have been built now.
>
> IMHO, the major blocker for now are llvm-toolchain-{9,10} which FTBFS on
> ppc64el. The other issues concern packages that are not in testing, or
> can be removed from testing.
llvm has been fixed. Everything seems in place to complete this
transition, except for this autopkgtest failure (according to
tracker.debian.org):
> autopkgtest for ocaml-cairo2/0.6.1+dfsg-5: amd64: Regression ♻ (reference ♻),
> arm64: Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386:
> Regression ♻ (reference ♻), ppc64el: Regression ♻ (reference ♻)
However, I don't understand why it complains about
ocaml-cairo2/0.6.1+dfsg-5 whereas version 0.6.1+dfsg-6 is fixed. Does
something need to be done?
Cheers,
--
Stéphane
Bug#971415: transition: ocaml
On 2020-10-16 11:31:45 +0200, Stéphane Glondu wrote:
> Le 12/10/2020 à 09:57, Sebastian Ramacher a écrit :
> I tried to install all corresponding opam packages in a 4.11.1 switch,
> and the breakage is minimal.
> >>>
> >>> Have bugs been filed for the these issues or are you taking care of
> >>> that?
> >>
> >> I will take care of filing bugs and/or fixing issues. And as usual, I
> >> will also take care of binNMUs.
> >
> > Great, please go ahead.
>
> I have scheduled all binNMUs and uploaded the necessary packages, and
> most of packages have been built now.
>
> IMHO, the major blocker for now are llvm-toolchain-{9,10} which FTBFS on
> ppc64el. The other issues concern packages that are not in testing, or
> can be removed from testing.
libguestfs has been fixed and llvm-toolchain-{9,10} are the only
blockers left.
Sylvestre, Gianfranco, could you please take a loog at the
llvm-toolchain build failures on ppc64el?
Cheers
--
Sebastian Ramacher
signature.asc
Description: PGP signature
Bug#971415: transition: ocaml
On 2020-10-17 13:02:14 -0500, Brett Gilio wrote: > Sebastian Ramacher writes: > > > > > Except for sks, they were fixed by rerunning them with the correct > > binNMUs. sks, however, looks like a real issue introduced by the switch > > to 4.11.1 > > > > I checked buildd for this transition on SKS and it seems to be completed > successfully? > https://buildd.debian.org/status/fetch.php?pkg=sks=armhf=1.1.6%2Bgit20200620.9e9d504-1%2Bb1=1602666464=0 It built fine, but the autopkgtests of the binary package built with ocaml 4.11.1 fails: https://ci.debian.net/data/autopkgtest/testing/amd64/s/sks/7566217/log.gz The failure is not restricted to armhf, but affects all architectures. The other architectures weren't marked as regressions since the binNMUs migrated already and now also the reference tests in testing fail. Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#971415: transition: ocaml
Sebastian Ramacher writes: > > Except for sks, they were fixed by rerunning them with the correct > binNMUs. sks, however, looks like a real issue introduced by the switch > to 4.11.1 > I checked buildd for this transition on SKS and it seems to be completed successfully? https://buildd.debian.org/status/fetch.php?pkg=sks=armhf=1.1.6%2Bgit20200620.9e9d504-1%2Bb1=1602666464=0 I am not understanding something here, surely. -- Brett M. Gilio bre...@gnu.org https://brettgilio.com/ E82A C026 95D6 FF02 43CA 1E5C F6C5 2DD1 BA27 CB87
Bug#971415: transition: ocaml
Hi On 2020-10-16 14:16:47 -0500, Brett Gilio wrote: > Sebastian Ramacher writes: > > > autopkgtest for cudf/0.9-1: amd64: Pass, arm64: Pass, armhf: Regression ♻ > > (reference ♻), i386: Pass > > autopkgtest for dose3/5.0.1-15: amd64: Pass, arm64: Pass, armhf: Test in > > progress, i386: Pass > > autopkgtest for mcl/1:14-137+ds-9: amd64: Pass, arm64: Pass, armhf: > > Regression ♻ (reference ♻), i386: Pass > > autopkgtest for morbig/0.10.4-4: amd64: Pass, arm64: Pass, armhf: > > Regression ♻ (reference ♻), i386: Not a regression > > autopkgtest for morsmall/0.3.0-3: amd64: Pass, arm64: Pass, armhf: > > Regression ♻ (reference ♻), i386: Pass > > autopkgtest for ocaml-visitors/20200210-2: armhf: Regression ♻ (reference ♻) > > autopkgtest for ppx-deriving-yojson/3.5.3-1: amd64: Pass, arm64: Pass, > > armhf: Regression ♻ (reference ♻), i386: Pass > > autopkgtest for sks/1.1.6+git20200620.9e9d504-1: amd64: Pass, arm64: Pass, > > armhf: Regression ♻ (reference ♻), i386: Pass > > autopkgtest for why3/1.3.3-1: amd64: Pass, arm64: Pass, armhf: Test in > > progress, i386: Pass > > > > Hi, new OCaml team member. Are these regressions introduced on the > 4.11.x switch? Thanks! Except for sks, they were fixed by rerunning them with the correct binNMUs. sks, however, looks like a real issue introduced by the switch to 4.11.1 Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#971415: transition: ocaml
Sebastian Ramacher writes: > autopkgtest for cudf/0.9-1: amd64: Pass, arm64: Pass, armhf: Regression ♻ > (reference ♻), i386: Pass > autopkgtest for dose3/5.0.1-15: amd64: Pass, arm64: Pass, armhf: Test in > progress, i386: Pass > autopkgtest for mcl/1:14-137+ds-9: amd64: Pass, arm64: Pass, armhf: > Regression ♻ (reference ♻), i386: Pass > autopkgtest for morbig/0.10.4-4: amd64: Pass, arm64: Pass, armhf: Regression > ♻ (reference ♻), i386: Not a regression > autopkgtest for morsmall/0.3.0-3: amd64: Pass, arm64: Pass, armhf: Regression > ♻ (reference ♻), i386: Pass > autopkgtest for ocaml-visitors/20200210-2: armhf: Regression ♻ (reference ♻) > autopkgtest for ppx-deriving-yojson/3.5.3-1: amd64: Pass, arm64: Pass, armhf: > Regression ♻ (reference ♻), i386: Pass > autopkgtest for sks/1.1.6+git20200620.9e9d504-1: amd64: Pass, arm64: Pass, > armhf: Regression ♻ (reference ♻), i386: Pass > autopkgtest for why3/1.3.3-1: amd64: Pass, arm64: Pass, armhf: Test in > progress, i386: Pass > Hi, new OCaml team member. Are these regressions introduced on the 4.11.x switch? Thanks! -- Brett M. Gilio bre...@gnu.org https://brettgilio.com/ E82A C026 95D6 FF02 43CA 1E5C F6C5 2DD1 BA27 CB87
Bug#971415: transition: ocaml
On 2020-10-16 11:31:45, Stéphane Glondu wrote:
> Le 12/10/2020 à 09:57, Sebastian Ramacher a écrit :
> I tried to install all corresponding opam packages in a 4.11.1 switch,
> and the breakage is minimal.
> >>>
> >>> Have bugs been filed for the these issues or are you taking care of
> >>> that?
> >>
> >> I will take care of filing bugs and/or fixing issues. And as usual, I
> >> will also take care of binNMUs.
> >
> > Great, please go ahead.
>
> I have scheduled all binNMUs and uploaded the necessary packages, and
> most of packages have been built now.
>
> IMHO, the major blocker for now are llvm-toolchain-{9,10} which FTBFS on
> ppc64el. The other issues concern packages that are not in testing, or
> can be removed from testing.
I have added removal hints for those that can be removed.
Besides llvm-toolchain, there are also some autopkgtest regressions on
armhf:
autopkgtest for cudf/0.9-1: amd64: Pass, arm64: Pass, armhf: Regression ♻
(reference ♻), i386: Pass
autopkgtest for dose3/5.0.1-15: amd64: Pass, arm64: Pass, armhf: Test in
progress, i386: Pass
autopkgtest for mcl/1:14-137+ds-9: amd64: Pass, arm64: Pass, armhf: Regression
♻ (reference ♻), i386: Pass
autopkgtest for morbig/0.10.4-4: amd64: Pass, arm64: Pass, armhf: Regression ♻
(reference ♻), i386: Not a regression
autopkgtest for morsmall/0.3.0-3: amd64: Pass, arm64: Pass, armhf: Regression ♻
(reference ♻), i386: Pass
autopkgtest for ocaml-visitors/20200210-2: armhf: Regression ♻ (reference ♻)
autopkgtest for ppx-deriving-yojson/3.5.3-1: amd64: Pass, arm64: Pass, armhf:
Regression ♻ (reference ♻), i386: Pass
autopkgtest for sks/1.1.6+git20200620.9e9d504-1: amd64: Pass, arm64: Pass,
armhf: Regression ♻ (reference ♻), i386: Pass
autopkgtest for why3/1.3.3-1: amd64: Pass, arm64: Pass, armhf: Test in
progress, i386: Pass
Not sure about sks. The others look like they have been run before
some of the binNMUs were available, so I have rescheduled them.
> I've gathered relevant bug reports there:
>
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ocaml-4.11.1-transition;users=debian-oc...@lists.debian.org
Thanks!
Cheers
--
Sebastian Ramacher
Bug#971415: transition: ocaml
Le 12/10/2020 à 09:57, Sebastian Ramacher a écrit :
I tried to install all corresponding opam packages in a 4.11.1 switch,
and the breakage is minimal.
>>>
>>> Have bugs been filed for the these issues or are you taking care of
>>> that?
>>
>> I will take care of filing bugs and/or fixing issues. And as usual, I
>> will also take care of binNMUs.
>
> Great, please go ahead.
I have scheduled all binNMUs and uploaded the necessary packages, and
most of packages have been built now.
IMHO, the major blocker for now are llvm-toolchain-{9,10} which FTBFS on
ppc64el. The other issues concern packages that are not in testing, or
can be removed from testing.
I've gathered relevant bug reports there:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ocaml-4.11.1-transition;users=debian-oc...@lists.debian.org
Cheers,
--
Stéphane
Bug#971415: transition: ocaml
Control: tags -1 + confirmed On 2020-10-12 09:50:08, Stéphane Glondu wrote: > Le 10/10/2020 à 17:58, Sebastian Ramacher a écrit : > >> I tried to install all corresponding opam packages in a 4.11.1 switch, > >> and the breakage is minimal. > > > > Have bugs been filed for the these issues or are you taking care of > > that? > > I will take care of filing bugs and/or fixing issues. And as usual, I > will also take care of binNMUs. Great, please go ahead. Cheers > > > Cheers, > > -- > Stéphane > -- Sebastian Ramacher
Processed: Re: Bug#971415: transition: ocaml
Processing control commands: > tags -1 + confirmed Bug #971415 [release.debian.org] transition: ocaml Added tag(s) confirmed. -- 971415: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971415 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#971415: transition: ocaml
Le 10/10/2020 à 17:58, Sebastian Ramacher a écrit : >> I tried to install all corresponding opam packages in a 4.11.1 switch, >> and the breakage is minimal. > > Have bugs been filed for the these issues or are you taking care of > that? I will take care of filing bugs and/or fixing issues. And as usual, I will also take care of binNMUs. Cheers, -- Stéphane
Bug#971415: transition: ocaml
Hi Stéphane On 2020-09-30 09:12:20 +0200, Stéphane Glondu wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: debian-ocaml-ma...@lists.debian.org > > Dear Release Team, > > I've updated ocaml to 4.11.1 and uploaded to experimental. It builds on > all release architectures, and most of ports as well (fixes for > hurd-i386 are pending, and it's still not built on kfreebsd-*). > > The main change as far as Debian is concerned is the split of the > graphics library, which I packaged (as ocaml-graphics) and has been > accepted. > > I tried to install all corresponding opam packages in a 4.11.1 switch, > and the breakage is minimal. Have bugs been filed for the these issues or are you taking care of that? Best > > Therefore, I think we can proceed to updating OCaml in unstable. > > > Cheers, > > -- > Stéphane > > Ben file: > > title = "ocaml"; > is_affected = .depends ~ "ocaml.*4\.08\.1" | .depends ~ "ocaml.*4\.11\.1"; > is_good = .depends ~ "ocaml.*4\.11\.1"; > is_bad = .depends ~ "ocaml.*4\.08\.1"; > > > -- System Information: > Debian Release: bullseye/sid > APT prefers testing > APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU threads) > Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#971415: transition: ocaml
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: debian-ocaml-ma...@lists.debian.org Dear Release Team, I've updated ocaml to 4.11.1 and uploaded to experimental. It builds on all release architectures, and most of ports as well (fixes for hurd-i386 are pending, and it's still not built on kfreebsd-*). The main change as far as Debian is concerned is the split of the graphics library, which I packaged (as ocaml-graphics) and has been accepted. I tried to install all corresponding opam packages in a 4.11.1 switch, and the breakage is minimal. Therefore, I think we can proceed to updating OCaml in unstable. Cheers, -- Stéphane Ben file: title = "ocaml"; is_affected = .depends ~ "ocaml.*4\.08\.1" | .depends ~ "ocaml.*4\.11\.1"; is_good = .depends ~ "ocaml.*4\.11\.1"; is_bad = .depends ~ "ocaml.*4\.08\.1"; -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU threads) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
