Bug#892505: transition: openexr
Hi! On 2018-03-11 at 00:33 (+0100), Emilio Pozuelo Monfort wrote: > Good, that means this can be a 'smooth' transition, i.e. the new library > package > can migrate while keeping the old one in testing at the same time, so the two > packages that fail to build are not really blockers (they are in order to > finish > the transition, but they are not in order to move the rest of the packages to > testing). Thus please go ahead. Uploaded. Thanks. -- Matteo F. Vescovi || Debian Developer GnuPG KeyID: 4096R/0x8062398983B2CF7A signature.asc Description: PGP signature
Bug#892505: transition: openexr
Hi! On 2018-03-11 at 00:33 (+0100), Emilio Pozuelo Monfort wrote: [...] > Good, that means this can be a 'smooth' transition, i.e. the new library > package > can migrate while keeping the old one in testing at the same time, so the two > packages that fail to build are not really blockers (they are in order to > finish > the transition, but they are not in order to move the rest of the packages to > testing). Thus please go ahead. As a final test, wrt vips, noticing that it was ftbfs on experimental but doing great on unstable, I compiled it on unstable using -3 revision of libopenexr23 and -dev and it builds fine. So no need to open a bug report on that. I'll upload the unstable revision asap. Thanks again for your time and patience. Cheers. -- Matteo F. Vescovi || Debian Developer GnuPG KeyID: 4096R/0x8062398983B2CF7A signature.asc Description: PGP signature
Bug#892505: transition: openexr
Control: tags -1 confirmed On 10/03/18 20:20, Matteo F. Vescovi wrote: > Hi! > > On 2018-03-10 at 16:35 (+0100), Emilio Pozuelo Monfort wrote: > > [...] > >>> while vips on some weird missing dependencies where openexr is not >>> involved, it seems. >> >> Can you file a bug for this? > > Gonna do it asap. > >> BTW I see in your changelog: >> >> openexr (2.2.1-2) experimental; urgency=medium >> >> * debian/: SONAME bump 22 -> 23 >> * debian/control: add Breaks and Replaces for library replacement >> >> So IIUC, you upgraded 2.2.1-1, which bumped the SONAME, without bumping the >> binary package name. Then you uploaded 2.2.1-2 with updated package name for >> the >> bumped SONAME. However since both libopenexr22_2.2.1-1 and >> libopenexr23_2.2.1-2 >> ship libopenexr.so.23, you had to add some Breaks/Replaces. But you added: >> >> Package: libopenexr23 >> Version: 2.2.1-2 >> Replaces: libopenexr22 (<< 2.2.1-2) >> Breaks: libopenexr22 (<< 2.2.1-2) >> >> That's unnecessarily broad, as it breaks against libopenexr22_2.2.0-11.1 >> that we >> have in testing, when it shouldn't. That will cause pain during the >> transition. >> Can you instead update the Breaks/Replaces to something like >> >> libopenexr22 (= 2.2.1-1) >> >> or >> >> libopenexr22 (>= 2.2.1) >> >> That should still conflict against the bad versions but not against the good >> ones. >> >> Basically if you can install libopenexr22/testing with libopenexr23, then >> we're >> good to go. > > That's what I've done now: I've just uploaded -3 revision that fixes the > Breaks/Replaces with the first option you provided. And I've tested the > co-installability of libopenexr22 from testing and libopenexr23 from > experimental. Good, that means this can be a 'smooth' transition, i.e. the new library package can migrate while keeping the old one in testing at the same time, so the two packages that fail to build are not really blockers (they are in order to finish the transition, but they are not in order to move the rest of the packages to testing). Thus please go ahead. Cheers, Emilio
Processed: Re: Bug#892505: transition: openexr
Processing control commands: > tags -1 confirmed Bug #892505 [release.debian.org] transition: openexr Added tag(s) confirmed. -- 892505: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892505 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#892505: transition: openexr
Hi! On 2018-03-10 at 16:35 (+0100), Emilio Pozuelo Monfort wrote: [...] >> while vips on some weird missing dependencies where openexr is not >> involved, it seems. > > Can you file a bug for this? Gonna do it asap. > BTW I see in your changelog: > > openexr (2.2.1-2) experimental; urgency=medium > > * debian/: SONAME bump 22 -> 23 > * debian/control: add Breaks and Replaces for library replacement > > So IIUC, you upgraded 2.2.1-1, which bumped the SONAME, without bumping the > binary package name. Then you uploaded 2.2.1-2 with updated package name for > the > bumped SONAME. However since both libopenexr22_2.2.1-1 and > libopenexr23_2.2.1-2 > ship libopenexr.so.23, you had to add some Breaks/Replaces. But you added: > > Package: libopenexr23 > Version: 2.2.1-2 > Replaces: libopenexr22 (<< 2.2.1-2) > Breaks: libopenexr22 (<< 2.2.1-2) > > That's unnecessarily broad, as it breaks against libopenexr22_2.2.0-11.1 that > we > have in testing, when it shouldn't. That will cause pain during the > transition. > Can you instead update the Breaks/Replaces to something like > > libopenexr22 (= 2.2.1-1) > > or > > libopenexr22 (>= 2.2.1) > > That should still conflict against the bad versions but not against the good > ones. > > Basically if you can install libopenexr22/testing with libopenexr23, then > we're > good to go. That's what I've done now: I've just uploaded -3 revision that fixes the Breaks/Replaces with the first option you provided. And I've tested the co-installability of libopenexr22 from testing and libopenexr23 from experimental. Cheers. -- Matteo F. Vescovi || Debian Developer GnuPG KeyID: 4096R/0x8062398983B2CF7A signature.asc Description: PGP signature
Bug#892505: transition: openexr
On 10/03/18 16:05, Matteo F. Vescovi wrote: > Hi Emilio! > > On 2018-03-10 at 10:27 (+0100), Emilio Pozuelo Monfort wrote: > > [...] > >>> ### Dependency level 3 ### >>> * gmic_1.7.9+zart-4 => FTBFS (not openexr related) >>> * gst-plugins-bad1.0_1.8.3-1 => FTBFS (not openexr related) >> >> unstable has gst-plugins-bad1.0 1.12.4-2. >> Did you really check with 1.8.3-1? > > Gosh, reverse-depends from ubuntu-dev-tools package brought that version > in my list, no idea why. Anyway, I've checked gst-plugins-bad1.0 > 1.12.4-2 and: > > * gst-plugins-bad1.0 1.12.4-2 => OK Ok, good. > >> Can you also check the other packages that failed to build (gmic and >> vips)? > > Unfortunately, both were built on the right versions and they fail; gmic > with: > > = = = = = = = >8 = = = = = = > dh_install: Cannot find (any matches for) "etc/bash_completion.d/gmic" > (tried in ., debian/tmp) > > dh_install: gmic missing files: etc/bash_completion.d/gmic > dh_install: missing files, aborting > = = = = = = = >8 = = = = = = That's #892123. > while vips on some weird missing dependencies where openexr is not > involved, it seems. Can you file a bug for this? BTW I see in your changelog: openexr (2.2.1-2) experimental; urgency=medium * debian/: SONAME bump 22 -> 23 * debian/control: add Breaks and Replaces for library replacement So IIUC, you upgraded 2.2.1-1, which bumped the SONAME, without bumping the binary package name. Then you uploaded 2.2.1-2 with updated package name for the bumped SONAME. However since both libopenexr22_2.2.1-1 and libopenexr23_2.2.1-2 ship libopenexr.so.23, you had to add some Breaks/Replaces. But you added: Package: libopenexr23 Version: 2.2.1-2 Replaces: libopenexr22 (<< 2.2.1-2) Breaks: libopenexr22 (<< 2.2.1-2) That's unnecessarily broad, as it breaks against libopenexr22_2.2.0-11.1 that we have in testing, when it shouldn't. That will cause pain during the transition. Can you instead update the Breaks/Replaces to something like libopenexr22 (= 2.2.1-1) or libopenexr22 (>= 2.2.1) That should still conflict against the bad versions but not against the good ones. Basically if you can install libopenexr22/testing with libopenexr23, then we're good to go. Cheers, Emilio
Bug#892505: transition: openexr
Hi Emilio! On 2018-03-10 at 10:27 (+0100), Emilio Pozuelo Monfort wrote: [...] >> ### Dependency level 3 ### >> * gmic_1.7.9+zart-4 => FTBFS (not openexr related) >> * gst-plugins-bad1.0_1.8.3-1 => FTBFS (not openexr related) > > unstable has gst-plugins-bad1.0 1.12.4-2. > Did you really check with 1.8.3-1? Gosh, reverse-depends from ubuntu-dev-tools package brought that version in my list, no idea why. Anyway, I've checked gst-plugins-bad1.0 1.12.4-2 and: * gst-plugins-bad1.0 1.12.4-2 => OK > Can you also check the other packages that failed to build (gmic and > vips)? Unfortunately, both were built on the right versions and they fail; gmic with: = = = = = = = >8 = = = = = = dh_install: Cannot find (any matches for) "etc/bash_completion.d/gmic" (tried in ., debian/tmp) dh_install: gmic missing files: etc/bash_completion.d/gmic dh_install: missing files, aborting = = = = = = = >8 = = = = = = while vips on some weird missing dependencies where openexr is not involved, it seems. Hope this helps. Cheers. -- Matteo F. Vescovi || Debian Developer GnuPG KeyID: 4096R/0x8062398983B2CF7A signature.asc Description: PGP signature
Bug#892505: transition: openexr
On 09/03/18 21:43, Matteo F. Vescovi wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-CC: pkg-phototools-de...@lists.alioth.debian.org, ma...@debian.org > > Dear Release Team, > > I'm filing this bug for a new transition of openexr package. > > On March 8, 2018 a fixed testing-purpose package (2.2.1-2) has been > uploaded to experimental. > > So, following the auto-openexr checklist[1], here is the list of source > packages depending on openexr and the results of the test builds > (honoring the dependency levels as reported in the checklist, as > relevant for the correct order): > > ### Dependency level 2 ### > * aqsis_1.8.2-8 => OK > * darktable_2.4.0-1 => OK > * exactimage_1.0.1-1 => OK > * freeimage_3.17.0+ds1-5 => OK > * gegl_0.3.28-2 => OK > * imagemagick_8:6.9.9.34+dfsg-3 => OK > * kde-runtime_4:17.08.3-1 => OK > * kimageformats_5.42.0-2 => OK > * kio-extras_4:17.08.3-2 => OK > * krita_1:3.3.3+dfsg-1 => OK > * libvigraimpex_1.10.0+git20160211.167be93+dfsg-5 => OK > * luminance-hdr_2.5.1+dfsg-3 => OK > * mia_2.4.6-2 => OK > * nvidia-texture-tools_2.0.8-1+dfsg-8.1 => OK > * opencv_3.2.0+dfsg-4 => OK > * openexr-viewers_1.0.1-6 => OK > * openvdb_5.0.0-1 => OK > * povray_1:3.7.0.4-2 => OK > > ### Dependency level 3 ### > * gmic_1.7.9+zart-4 => FTBFS (not openexr related) > * gst-plugins-bad1.0_1.8.3-1 => FTBFS (not openexr related) unstable has gst-plugins-bad1.0 1.12.4-2. Did you really check with 1.8.3-1? Can you also check the other packages that failed to build (gmic and vips)? Cheers, Emilio > * hugin_2018.0.0+dfsg-1 => OK > * k3d_0.8.0.6-6 => OK > * openimageio_1.8.9~dfsg0-1 => OK > * pfstools_2.1.0-3 => OK > * synfig_1.0.2-1 => OK > * vips_8.4.5-1 => FTBFS (not openexr related) > > ### Dependency level 4 ### > blender_2.79+dfsg0-3 => OK > > Thanks for your time and patience. > > mfv
Bug#892505: transition: openexr
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-CC: pkg-phototools-de...@lists.alioth.debian.org, ma...@debian.org Dear Release Team, I'm filing this bug for a new transition of openexr package. On March 8, 2018 a fixed testing-purpose package (2.2.1-2) has been uploaded to experimental. So, following the auto-openexr checklist[1], here is the list of source packages depending on openexr and the results of the test builds (honoring the dependency levels as reported in the checklist, as relevant for the correct order): ### Dependency level 2 ### * aqsis_1.8.2-8 => OK * darktable_2.4.0-1 => OK * exactimage_1.0.1-1 => OK * freeimage_3.17.0+ds1-5 => OK * gegl_0.3.28-2 => OK * imagemagick_8:6.9.9.34+dfsg-3 => OK * kde-runtime_4:17.08.3-1 => OK * kimageformats_5.42.0-2 => OK * kio-extras_4:17.08.3-2 => OK * krita_1:3.3.3+dfsg-1 => OK * libvigraimpex_1.10.0+git20160211.167be93+dfsg-5 => OK * luminance-hdr_2.5.1+dfsg-3 => OK * mia_2.4.6-2 => OK * nvidia-texture-tools_2.0.8-1+dfsg-8.1 => OK * opencv_3.2.0+dfsg-4 => OK * openexr-viewers_1.0.1-6 => OK * openvdb_5.0.0-1 => OK * povray_1:3.7.0.4-2 => OK ### Dependency level 3 ### * gmic_1.7.9+zart-4 => FTBFS (not openexr related) * gst-plugins-bad1.0_1.8.3-1 => FTBFS (not openexr related) * hugin_2018.0.0+dfsg-1 => OK * k3d_0.8.0.6-6 => OK * openimageio_1.8.9~dfsg0-1 => OK * pfstools_2.1.0-3 => OK * synfig_1.0.2-1 => OK * vips_8.4.5-1 => FTBFS (not openexr related) ### Dependency level 4 ### blender_2.79+dfsg0-3 => OK Thanks for your time and patience. mfv [1] https://release.debian.org/transitions/html/auto-openexr.html Ben file: title = "openexr"; is_affected = .depends ~ "libopenexr22" | .depends ~ "libopenexr23"; is_good = .depends ~ "libopenexr23"; is_bad = .depends ~ "libopenexr22"; -- System Information: Debian Release: buster/sid APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.15.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- Matteo F. Vescovi signature.asc Description: PGP signature
