Hello, all:
On rawhide (f37) jasper is updated from 2.0.33-2 to 3.0.0-1, which causes unannounced soname bump from libjasper.so.4 to libjasper.so.6.
What is strange here is that the committer seems aware of this change: https://src.fedoraproject.org/rpms/jasper/c/13f23ce40bfeafccd96ecc8872f965e6...
Affected packages: $ dnf --quiet repoquery --repo=koji-37 --qf '%{sourcerpm}' --whatrequires "libjasper.so.4()(64bit)" | cat -n 1 DevIL-1.7.8-38.fc36.src.rpm 2 GraphicsMagick-1.3.36-6.fc36.src.rpm 3 LibRaw-0.20.2-5.fc36.src.rpm 4 OpenSceneGraph-3.6.5-2.fc36.src.rpm 5 dcraw-9.28.0-13.fc36.src.rpm 6 digikam-7.5.0-2.fc36.src.rpm 7 eccodes-2.24.0-2.fc36.src.rpm 8 gdal-3.4.1-4.fc36.src.rpm 9 gegl04-0.4.34-2.fc36.src.rpm 10 grads-2.0.2-39.fc36.src.rpm 11 grib_api-1.27.0-13.fc36.src.rpm 12 kdelibs-4.14.38-31.fc37.src.rpm 13 kdelibs3-3.5.10-114.fc36.src.rpm 14 libicns-0.8.1-23.fc36.src.rpm 15 ncl-6.6.2-25.fc36.src.rpm 16 netpbm-10.97.00-2.fc36.src.rpm 17 qt5-qtimageformats-5.15.2-5.fc36.src.rpm 18 qt6-qtimageformats-6.2.3-1.fc36.src.rpm 19 wgrib2-2.0.8-9.fc36.src.rpm
jasper-3.0.0-1.fc37 was build just one hours ago, so maybe untagging this build is better.
Regards, Mamoru
On 11. 02. 22 15:20, Mamoru TASAKA wrote:
Hello, all:
On rawhide (f37) jasper is updated from 2.0.33-2 to 3.0.0-1, which causes unannounced soname bump from libjasper.so.4 to libjasper.so.6.
What is strange here is that the committer seems aware of this change: https://src.fedoraproject.org/rpms/jasper/c/13f23ce40bfeafccd96ecc8872f965e6...
Affected packages: $ dnf --quiet repoquery --repo=koji-37 --qf '%{sourcerpm}' --whatrequires "libjasper.so.4()(64bit)" | cat -n 1 DevIL-1.7.8-38.fc36.src.rpm 2 GraphicsMagick-1.3.36-6.fc36.src.rpm 3 LibRaw-0.20.2-5.fc36.src.rpm 4 OpenSceneGraph-3.6.5-2.fc36.src.rpm 5 dcraw-9.28.0-13.fc36.src.rpm 6 digikam-7.5.0-2.fc36.src.rpm 7 eccodes-2.24.0-2.fc36.src.rpm 8 gdal-3.4.1-4.fc36.src.rpm 9 gegl04-0.4.34-2.fc36.src.rpm 10 grads-2.0.2-39.fc36.src.rpm 11 grib_api-1.27.0-13.fc36.src.rpm 12 kdelibs-4.14.38-31.fc37.src.rpm 13 kdelibs3-3.5.10-114.fc36.src.rpm 14 libicns-0.8.1-23.fc36.src.rpm 15 ncl-6.6.2-25.fc36.src.rpm 16 netpbm-10.97.00-2.fc36.src.rpm 17 qt5-qtimageformats-5.15.2-5.fc36.src.rpm 18 qt6-qtimageformats-6.2.3-1.fc36.src.rpm 19 wgrib2-2.0.8-9.fc36.src.rpm
jasper-3.0.0-1.fc37 was build just one hours ago, so maybe untagging this build is better.
It was actually announced:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
But for reasons I don't understand, it was pushed to rawhide without using a side tag and without doing rebuilds :(
I agree that untagging this is the best option now, it breaks hundreds of packages both on runtime and buildtime.
Miro Hrončok wrote on 2022/02/11 23:29:
On 11. 02. 22 15:20, Mamoru TASAKA wrote:
Hello, all:
On rawhide (f37) jasper is updated from 2.0.33-2 to 3.0.0-1, which causes unannounced soname bump from libjasper.so.4 to libjasper.so.6.
What is strange here is that the committer seems aware of this change: https://src.fedoraproject.org/rpms/jasper/c/13f23ce40bfeafccd96ecc8872f965e6...
Affected packages: $ dnf --quiet repoquery --repo=koji-37 --qf '%{sourcerpm}' --whatrequires "libjasper.so.4()(64bit)" | cat -n 1 DevIL-1.7.8-38.fc36.src.rpm 2 GraphicsMagick-1.3.36-6.fc36.src.rpm 3 LibRaw-0.20.2-5.fc36.src.rpm 4 OpenSceneGraph-3.6.5-2.fc36.src.rpm 5 dcraw-9.28.0-13.fc36.src.rpm 6 digikam-7.5.0-2.fc36.src.rpm 7 eccodes-2.24.0-2.fc36.src.rpm 8 gdal-3.4.1-4.fc36.src.rpm 9 gegl04-0.4.34-2.fc36.src.rpm 10 grads-2.0.2-39.fc36.src.rpm 11 grib_api-1.27.0-13.fc36.src.rpm 12 kdelibs-4.14.38-31.fc37.src.rpm 13 kdelibs3-3.5.10-114.fc36.src.rpm 14 libicns-0.8.1-23.fc36.src.rpm 15 ncl-6.6.2-25.fc36.src.rpm 16 netpbm-10.97.00-2.fc36.src.rpm 17 qt5-qtimageformats-5.15.2-5.fc36.src.rpm 18 qt6-qtimageformats-6.2.3-1.fc36.src.rpm 19 wgrib2-2.0.8-9.fc36.src.rpm
jasper-3.0.0-1.fc37 was build just one hours ago, so maybe untagging this build is better.
It was actually announced:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
But for reasons I don't understand, it was pushed to rawhide without using a side tag and without doing rebuilds :(
I agree that untagging this is the best option now, it breaks hundreds of packages both on runtime and buildtime.
Requested untagging https://pagure.io/fedora-infrastructure/issue/10552
Regards, Mamoru
./find_unblocked_orphans.py --max_deps 1 --skip-orphans jasper
Depending on: jasper (30), DevIL (maintained by: jwrdegoede) DevIL-1.7.8-38.fc36.i686 requires libjasper.so.4 DevIL-1.7.8-38.fc36.src requires jasper-devel = 2.0.33-2.fc36 DevIL-1.7.8-38.fc36.x86_64 requires libjasper.so.4()(64bit) DevIL-ILUT-1.7.8-38.fc36.i686 requires libjasper.so.4 DevIL-ILUT-1.7.8-38.fc36.x86_64 requires libjasper.so.4()(64bit)
GraphicsMagick (maintained by: ixs, rdieter) GraphicsMagick-1.3.36-6.fc36.i686 requires libjasper.so.4 GraphicsMagick-1.3.36-6.fc36.src requires jasper-devel = 2.0.33-2.fc36 GraphicsMagick-1.3.36-6.fc36.x86_64 requires libjasper.so.4()(64bit)
ImageMagick (maintained by: kalev, luya, remi, sergiomb, troycurtisjr) ImageMagick-1:6.9.12.37-1.fc36.src requires pkgconfig(jasper) = 2.0.33
LibRaw (maintained by: dchen, hobbes1069, limb) LibRaw-0.20.2-5.fc36.i686 requires libjasper.so.4 LibRaw-0.20.2-5.fc36.src requires pkgconfig(jasper) = 2.0.33 LibRaw-0.20.2-5.fc36.x86_64 requires libjasper.so.4()(64bit)
OpenImageIO (maintained by: hobbes1069) OpenImageIO-2.3.12.0-1.fc36.src requires jasper-devel = 2.0.33-2.fc36
OpenSceneGraph (maintained by: smani) OpenSceneGraph-3.6.5-2.fc36.src requires jasper-devel = 2.0.33-2.fc36 OpenSceneGraph-libs-3.6.5-2.fc36.i686 requires libjasper.so.4 OpenSceneGraph-libs-3.6.5-2.fc36.x86_64 requires libjasper.so.4()(64bit)
darktable (maintained by: asn, germano, kalev, madko) darktable-3.8.0-7.fc36.src requires libjasper-devel = 2.0.33-2.fc36
dcraw (maintained by: jridky, nphilipp) dcraw-9.28.0-13.fc36.src requires jasper-devel = 2.0.33-2.fc36 dcraw-9.28.0-13.fc36.x86_64 requires libjasper.so.4()(64bit)
digikam (maintained by: dvratil, kde-sig, kwizart, nucleo, rdieter, than, tuxbrewr, vjancik) digikam-7.5.0-2.fc36.src requires pkgconfig(jasper) = 2.0.33 digikam-libs-7.5.0-2.fc36.i686 requires libjasper.so.4 digikam-libs-7.5.0-2.fc36.x86_64 requires libjasper.so.4()(64bit)
eccodes (maintained by: jdekloe) eccodes-2.24.0-2.fc36.src requires jasper-devel = 2.0.33-2.fc36 eccodes-2.24.0-2.fc36.x86_64 requires libjasper.so.4()(64bit) eccodes-devel-2.24.0-2.fc36.x86_64 requires jasper-devel(x86-64) = 2.0.33-2.fc36
g2clib (maintained by: jdekloe, orion, scitech_sig) g2clib-1.6.3-3.fc36.src requires jasper-devel = 2.0.33-2.fc36 g2clib-devel-1.6.3-3.fc36.i686 requires jasper-devel(x86-32) = 2.0.33- 2.fc36 g2clib-devel-1.6.3-3.fc36.x86_64 requires jasper-devel(x86-64) = 2.0.33-2.fc36
gdal (maintained by: alexlan, devrim, jmlich, neteler, oliver, orion, pali, praiskup, smani, volter) gdal-3.4.1-4.fc36.src requires jasper-devel = 2.0.33-2.fc36 gdal-java-3.4.1-4.fc36.x86_64 requires libjasper.so.4()(64bit) gdal-libs-3.4.1-4.fc36.i686 requires libjasper.so.4 gdal-libs-3.4.1-4.fc36.x86_64 requires libjasper.so.4()(64bit)
gegl04 (maintained by: jridky, nphilipp) gegl04-0.4.34-2.fc36.i686 requires libjasper.so.4 gegl04-0.4.34-2.fc36.src requires pkgconfig(jasper) = 2.0.33 gegl04-0.4.34-2.fc36.x86_64 requires libjasper.so.4()(64bit)
gimp (maintained by: jridky, nphilipp, zdohnal) gimp-2:2.10.30-1.fc36.1.src requires jasper-devel = 2.0.33-2.fc36
grads (maintained by: deji) grads-2.0.2-39.fc36.x86_64 requires libjasper.so.4()(64bit)
grib_api (maintained by: jdekloe, orion) grib_api-1.27.0-13.fc36.i686 requires libjasper.so.4 grib_api-1.27.0-13.fc36.src requires jasper-devel = 2.0.33-2.fc36 grib_api-1.27.0-13.fc36.x86_64 requires libjasper.so.4()(64bit) grib_api-devel-1.27.0-13.fc36.i686 requires jasper-devel(x86-32) = 2.0.33-2.fc36 grib_api-devel-1.27.0-13.fc36.x86_64 requires jasper-devel(x86-64) = 2.0.33-2.fc36
gstreamer1-plugins-bad-free (maintained by: swt2c, uraeus, wtaymans) gstreamer1-plugins-bad-free-1.20.0-1.fc36.src requires jasper-devel = 2.0.33-2.fc36
kdelibs (maintained by: dvratil, jgrulich, jreznik, kde-sig, kkofler, rdieter, than) kdelibs-6:4.14.38-30.fc36.i686 requires libjasper.so.4 kdelibs-6:4.14.38-30.fc36.src requires pkgconfig(jasper) = 2.0.33 kdelibs-6:4.14.38-30.fc36.x86_64 requires libjasper.so.4()(64bit)
kdelibs3 (maintained by: jreznik, kkofler, rdieter, than) kdelibs3-3.5.10-114.fc36.i686 requires libjasper.so.4 kdelibs3-3.5.10-114.fc36.src requires jasper-devel = 2.0.33-2.fc36 kdelibs3-3.5.10-114.fc36.x86_64 requires libjasper.so.4()(64bit)
kf5-kimageformats (maintained by: dvratil, jgrulich, kde-sig, rdieter, than) kf5-kimageformats-5.90.0-2.fc36.src requires jasper-devel = 2.0.33- 2.fc36
kopete (maintained by: jreznik, kde-sig, nucleo, rdieter, than) kopete-21.12.2-1.fc36.src requires pkgconfig(jasper) = 2.0.33
libicns (maintained by: hobbes1069, musuruan, xavierb) libicns-0.8.1-23.fc36.i686 requires libjasper.so.4 libicns-0.8.1-23.fc36.src requires jasper-devel = 2.0.33-2.fc36 libicns-0.8.1-23.fc36.x86_64 requires libjasper.so.4()(64bit)
ncl (maintained by: orion, scitech_sig) ncl-6.6.2-25.fc36.x86_64 requires libjasper.so.4()(64bit)
netpbm (maintained by: jridky, phracek) netpbm-10.97.00-2.fc36.src requires jasper-devel = 2.0.33-2.fc36 netpbm-progs-10.97.00-2.fc36.x86_64 requires libjasper.so.4()(64bit)
opencv (maintained by: hguemar, hhorak, jkucera, jmlich, jridky, kwizart, sergiomb, vjancik) opencv-4.5.5-2.fc36.src requires jasper-devel = 2.0.33-2.fc36
qt5-qtimageformats (maintained by: jgrulich, kde-sig, rdieter, than) qt5-qtimageformats-5.15.2-5.fc36.i686 requires libjasper.so.4 qt5-qtimageformats-5.15.2-5.fc36.src requires jasper-devel = 2.0.33- 2.fc36 qt5-qtimageformats-5.15.2-5.fc36.x86_64 requires libjasper.so.4()(64bit)
qt6-qtimageformats (maintained by: jgrulich, kde-sig) qt6-qtimageformats-6.2.3-1.fc36.i686 requires libjasper.so.4 qt6-qtimageformats-6.2.3-1.fc36.src requires jasper-devel = 2.0.33- 2.fc36 qt6-qtimageformats-6.2.3-1.fc36.x86_64 requires libjasper.so.4()(64bit)
saga (maintained by: volter) saga-7.6.1-10.fc36.src requires jasper-devel = 2.0.33-2.fc36
ufraw (maintained by: nphilipp, sergiomb) ufraw-0.23-0.13.20210425.fc36.src requires jasper-devel = 2.0.33-2.fc36
wgrib2 (maintained by: orion, scitech_sig) wgrib2-2.0.8-9.fc36.x86_64 requires libjasper.so.4()(64bit)
On Fri, 2022-02-11 at 23:41 +0900, Mamoru TASAKA wrote:
Miro Hrončok wrote on 2022/02/11 23:29:
On 11. 02. 22 15:20, Mamoru TASAKA wrote:
Hello, all:
On rawhide (f37) jasper is updated from 2.0.33-2 to 3.0.0-1, which causes unannounced soname bump from libjasper.so.4 to libjasper.so.6.
What is strange here is that the committer seems aware of this change: https://src.fedoraproject.org/rpms/jasper/c/13f23ce40bfeafccd96ecc8872f965e6...
Affected packages: $ dnf --quiet repoquery --repo=koji-37 --qf '%{sourcerpm}' -- whatrequires "libjasper.so.4()(64bit)" | cat -n 1 DevIL-1.7.8-38.fc36.src.rpm 2 GraphicsMagick-1.3.36-6.fc36.src.rpm 3 LibRaw-0.20.2-5.fc36.src.rpm 4 OpenSceneGraph-3.6.5-2.fc36.src.rpm 5 dcraw-9.28.0-13.fc36.src.rpm 6 digikam-7.5.0-2.fc36.src.rpm 7 eccodes-2.24.0-2.fc36.src.rpm 8 gdal-3.4.1-4.fc36.src.rpm 9 gegl04-0.4.34-2.fc36.src.rpm 10 grads-2.0.2-39.fc36.src.rpm 11 grib_api-1.27.0-13.fc36.src.rpm 12 kdelibs-4.14.38-31.fc37.src.rpm 13 kdelibs3-3.5.10-114.fc36.src.rpm 14 libicns-0.8.1-23.fc36.src.rpm 15 ncl-6.6.2-25.fc36.src.rpm 16 netpbm-10.97.00-2.fc36.src.rpm 17 qt5-qtimageformats-5.15.2-5.fc36.src.rpm 18 qt6-qtimageformats-6.2.3-1.fc36.src.rpm 19 wgrib2-2.0.8-9.fc36.src.rpm
jasper-3.0.0-1.fc37 was build just one hours ago, so maybe untagging this build is better.
It was actually announced:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
But for reasons I don't understand, it was pushed to rawhide without using a side tag and without doing rebuilds :(
I agree that untagging this is the best option now, it breaks hundreds of packages both on runtime and buildtime.
Requested untagging https://pagure.io/fedora-infrastructure/issue/10552
Regards, Mamoru _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Mamoru TASAKA wrote on 2022/02/11 23:41:
Miro Hrončok wrote on 2022/02/11 23:29:
On 11. 02. 22 15:20, Mamoru TASAKA wrote:
Hello, all:
On rawhide (f37) jasper is updated from 2.0.33-2 to 3.0.0-1, which causes unannounced soname bump from libjasper.so.4 to libjasper.so.6.
What is strange here is that the committer seems aware of this change: https://src.fedoraproject.org/rpms/jasper/c/13f23ce40bfeafccd96ecc8872f965e6...
Affected packages: $ dnf --quiet repoquery --repo=koji-37 --qf '%{sourcerpm}' --whatrequires "libjasper.so.4()(64bit)" | cat -n 1 DevIL-1.7.8-38.fc36.src.rpm 2 GraphicsMagick-1.3.36-6.fc36.src.rpm 3 LibRaw-0.20.2-5.fc36.src.rpm 4 OpenSceneGraph-3.6.5-2.fc36.src.rpm 5 dcraw-9.28.0-13.fc36.src.rpm 6 digikam-7.5.0-2.fc36.src.rpm 7 eccodes-2.24.0-2.fc36.src.rpm 8 gdal-3.4.1-4.fc36.src.rpm 9 gegl04-0.4.34-2.fc36.src.rpm 10 grads-2.0.2-39.fc36.src.rpm 11 grib_api-1.27.0-13.fc36.src.rpm 12 kdelibs-4.14.38-31.fc37.src.rpm 13 kdelibs3-3.5.10-114.fc36.src.rpm 14 libicns-0.8.1-23.fc36.src.rpm 15 ncl-6.6.2-25.fc36.src.rpm 16 netpbm-10.97.00-2.fc36.src.rpm 17 qt5-qtimageformats-5.15.2-5.fc36.src.rpm 18 qt6-qtimageformats-6.2.3-1.fc36.src.rpm 19 wgrib2-2.0.8-9.fc36.src.rpm
jasper-3.0.0-1.fc37 was build just one hours ago, so maybe untagging this build is better.
It was actually announced:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
But for reasons I don't understand, it was pushed to rawhide without using a side tag and without doing rebuilds :(
I agree that untagging this is the best option now, it breaks hundreds of packages both on runtime and buildtime.
Requested untagging https://pagure.io/fedora-infrastructure/issue/10552
Regards, Mamoru
Just note that I am going to bed now. Mamoru
Miro Hrončok wrote:
It was actually announced:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
But for reasons I don't understand, it was pushed to rawhide without using a side tag and without doing rebuilds :(
I agree that untagging this is the best option now, it breaks hundreds of packages both on runtime and buildtime.
As a comaintainer of at least 2 of the affected packages (kdelibs3 and kdelibs 4), I must say I do not really understand why this is such a big deal. 18 packages would have needed to be rebuilt in Rawhide. "Hundreds of packages" is just with transitive dependencies that do not all need to be rebuilt. The untagging just makes us lose time because we can not rebuild the packages directly in Rawhide now.
The fact that we got automatically filed FTI bugs within hours is also absurd. It would be easiest to just have a provenpackager rebuild the packages and not bother the maintainers at all (nor untag the package). Filing a bug makes sense only if an FTI persists for more than a week at the very least. Transient breakage in Rawhide is perfectly normal.
We have always worked that way in Rawhide: if a soname got bumped, just rebuild the reverse dependencies and move on. It worked without any issues. So I do not see why this is suddenly no longer allowed.
Kevin Kofler
On Fri, Feb 11, 2022 at 09:45:53PM +0100, Kevin Kofler via devel wrote:
Miro Hrončok wrote:
It was actually announced:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
But for reasons I don't understand, it was pushed to rawhide without using a side tag and without doing rebuilds :(
I agree that untagging this is the best option now, it breaks hundreds of packages both on runtime and buildtime.
As a comaintainer of at least 2 of the affected packages (kdelibs3 and kdelibs 4), I must say I do not really understand why this is such a big deal. 18 packages would have needed to be rebuilt in Rawhide. "Hundreds of packages" is just with transitive dependencies that do not all need to be rebuilt. The untagging just makes us lose time because we can not rebuild the packages directly in Rawhide now.
As a release engineer trying to get a rawhide compose, I do find this a big deal. (Another f37 compose just failed because of this issue).
The fact that we got automatically filed FTI bugs within hours is also absurd. It would be easiest to just have a provenpackager rebuild the packages and not bother the maintainers at all (nor untag the package). Filing a bug makes sense only if an FTI persists for more than a week at the very least. Transient breakage in Rawhide is perfectly normal.
no. It means that this should be done in a side tag and merged when it's ready / everything(or most everything) is rebuilt.
We have always worked that way in Rawhide: if a soname got bumped, just rebuild the reverse dependencies and move on. It worked without any issues. So I do not see why this is suddenly no longer allowed.
Long ago we worked that way. Back when there were few packages and few maintainers. Now we don't and shouldn't. We should use side tags and merge things only when ready. Keeping rawhide working helps everyone who is trying to use it to integrate their changes. Dumping breakage into rawhide and expecting others to clean it up makes it harder for almost everyone.
kevin
Kevin Fenzi wrote:
As a release engineer trying to get a rawhide compose, I do find this a big deal. (Another f37 compose just failed because of this issue).
Well, as I already pointed out more than once, the real issue there is that the Rawhide compose fails due to a broken dependency. This used not to be the case. If a deliverable fails to compose, then it will be missing for one day (or ideally, just keep the last one that built on the mirrors!). If it is release-blocking, it needs to be fixed before the release. Not sooner. This is how things used to work in the past (without the "or ideally" part, that is just my improvement suggestion that was never implemented) and it is why we were able to work much better with broken dependencies in Rawhide back then than now.
Long ago we worked that way. Back when there were few packages and few maintainers.
The number of packages increases constantly, but the order of magnitude was not that different. What really made the difference was that the composes did not fail. Instead, they would succeed and we would automatically get a list of broken dependencies sent to the devel list (and then provenpackagers like Alex Lancaster and me tried to mass-fix them, and IMHO did a very good job at it, until, in lieu of a "thank you", we were told not to because it "masks the issue of unmaintained packages"… that was the point at which broken dependencies started to accumulate, creating the demand for gating).
Keeping rawhide working helps everyone who is trying to use it to integrate their changes.
The requirement to keep Rawhide working prevents using it to integrate anything non-trivial, forcing everything into side tags (which then moves the conflicts to the point where the side tags get merged, which can cause a big mess if they happen to overlap too much).
Dumping breakage into rawhide and expecting others to clean it up makes it harder for almost everyone.
"Others" (including me) were quite happy to clean it up until we were explicitly told to stop!
Kevin Kofler
Hi,
first of all, I would like to apologize for the mess I've caused by the jasper .so name bump in Rawhide. I entirely forgot the side-tag option and had the old mindset of having rawhide as a "sandbox for new features". I wrote to Miro already as I am not part of the proven packager group to assist me with the update - specifically with package rebuild.
On the other hand, I have to partially agree with Kevin Koffler in the way that making library upgrade in the rawhide from a regular maintainer point of view is still quite painful and from discussion with my colleagues it seems that I am not the only one who feels it that way.
Mostly, simple rebuild of dependent packages is all that is needed, but to achieve it, I have to either communicate with all other maintainers (where their number might be quite huge and not all of them are able to react in meningul timeframe - agree it's not applicable with handful of dependent packages, where it is easy to get it done) or bother some proven packager to do the rebuilds on my behalf (which is something I don't like, as the workload is transferred to someone, who has enough of his/her own tasks already).
It would be awesome to have some bot available for all Fedora maintainers, which would have proven packagers rights and it's only function would be -> bump spec file and build (e.g. in specific side-tag). In that way, for most library updates this would be the easiest way, how to get them into Fedora and bother other maintainers/proven packagers as little as possible.
Best regards
Josef Ridky Senior Software Engineer Core Services Team Red Hat Czech, s.r.o.
On Sat, Feb 12, 2022 at 8:13 PM Kevin Kofler via devel < devel@lists.fedoraproject.org> wrote:
Kevin Fenzi wrote:
As a release engineer trying to get a rawhide compose, I do find this a big deal. (Another f37 compose just failed because of this issue).
Well, as I already pointed out more than once, the real issue there is that the Rawhide compose fails due to a broken dependency. This used not to be the case. If a deliverable fails to compose, then it will be missing for one day (or ideally, just keep the last one that built on the mirrors!). If it is release-blocking, it needs to be fixed before the release. Not sooner. This is how things used to work in the past (without the "or ideally" part, that is just my improvement suggestion that was never implemented) and it is why we were able to work much better with broken dependencies in Rawhide back then than now.
Long ago we worked that way. Back when there were few packages and few maintainers.
The number of packages increases constantly, but the order of magnitude was not that different. What really made the difference was that the composes did not fail. Instead, they would succeed and we would automatically get a list of broken dependencies sent to the devel list (and then provenpackagers like Alex Lancaster and me tried to mass-fix them, and IMHO did a very good job at it, until, in lieu of a "thank you", we were told not to because it "masks the issue of unmaintained packages"… that was the point at which broken dependencies started to accumulate, creating the demand for gating).
Keeping rawhide working helps everyone who is trying to use it to integrate their changes.
The requirement to keep Rawhide working prevents using it to integrate anything non-trivial, forcing everything into side tags (which then moves the conflicts to the point where the side tags get merged, which can cause a big mess if they happen to overlap too much).
Dumping breakage into rawhide and expecting others to clean it up makes
it
harder for almost everyone.
"Others" (including me) were quite happy to clean it up until we were explicitly told to stop!
Kevin Kofler
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 13. 02. 22 13:32, Josef Řídký wrote:
Hi,
first of all, I would like to apologize for the mess I've caused by the jasper .so name bump in Rawhide. I entirely forgot the side-tag option and had the old mindset of having rawhide as a "sandbox for new features". I wrote to Miro already as I am not part of the proven packager group to assist me with the update - specifically with package rebuild.
On the other hand, I have to partially agree with Kevin Koffler in the way that making library upgrade in the rawhide from a regular maintainer point of view is still quite painful and from discussion with my colleagues it seems that I am not the only one who feels it that way.
Mostly, simple rebuild of dependent packages is all that is needed, but to achieve it, I have to either communicate with all other maintainers (where their number might be quite huge and not all of them are able to react in meningul timeframe - agree it's not applicable with handful of dependent packages, where it is easy to get it done) or bother some proven packager to do the rebuilds on my behalf (which is something I don't like, as the workload is transferred to someone, who has enough of his/her own tasks already).
It would be awesome to have some bot available for all Fedora maintainers, which would have proven packagers rights and it's only function would be -> bump spec file and build (e.g. in specific side-tag). In that way, for most library updates this would be the easiest way, how to get them into Fedora and bother other maintainers/proven packagers as little as possible.
Considering most of the dependent packages failed to rebuild in this case, I am not sure how a robot would be supposed to deal with this :(
Successful rebuilds (jasper+5):
https://koji.fedoraproject.org/koji/builds?inherited=0&tagID=50649&o...
Still in progress: gdal (already succeeded on some architectures)
Failed twice (13): LibRaw OpenSceneGraph digikam eccodes gegl04 grads grib_api kdelibs kdelibs3 ncl qt5-qtimageformats qt6-qtimageformats wgrib2
If somebody wants to help, build in f37-build-side-50649 please.
On Sun, Feb 13 2022 at 02:26:46 PM +0100, Miro Hrončok mhroncok@redhat.com wrote:
Considering most of the dependent packages failed to rebuild in this case, I am not sure how a robot would be supposed to deal with this :(
If the bot can handle everything that doesn't require manual intervention, that's still a good improvement over the status quo.
Michael
On Sun, Feb 13, 2022 at 09:43:38AM -0600, Michael Catanzaro wrote:
On Sun, Feb 13 2022 at 02:26:46 PM +0100, Miro Hrončok mhroncok@redhat.com wrote:
Considering most of the dependent packages failed to rebuild in this case, I am not sure how a robot would be supposed to deal with this :(
If the bot can handle everything that doesn't require manual intervention, that's still a good improvement over the status quo.
A bot would be nice, but I think we're unlikely to get this in the near future. I think it would be useful to start with a helper script to: - identify all dependent packages that need to be rebuild - if possible figure out build dependencies (i.e. the cases where we know that some package will fail to build until some other package in the set has been rebuilt), - suggest a build order - start builds in a side tag
Then you could ask a proven packager to just run the rebuild command, even if you don't have the privileges yourself.
If we ever want to write a bot for this, this script will be a good starting point…
Zbyszek
Here is a proof-of-concept one-liner (split up a bit for readability purposes):
```fish #!/usr/bin/fish
function get_dependent_pkgs dnf -q repoquery --repo=koji --qf='%{sourcerpm}' --whatrequires $argv[1] end
function parse_names get_dependent_pkgs | rev | cut -d/ -f1 | cut -d- -f3- | rev end
# https://src.fedoraproject.org/rpms/fbrnch function topo_sort_and_sidetag_build fbrnch parallel --sidetag rawhide (parse_names) end ```
May an actual proven packager or infrastructure people adapt the three lines above in a workable program.
Thanks, I wasn't aware that fbrnch is so smart.
On Sun, Feb 13, 2022 at 08:09:12PM -0000, E.N. virgo wrote:
Here is a proof-of-concept one-liner (split up a bit for readability purposes):
#!/usr/bin/fish function get_dependent_pkgs dnf -q repoquery --repo=koji --qf='%{sourcerpm}' --whatrequires $argv[1] end function parse_names get_dependent_pkgs | rev | cut -d/ -f1 | cut -d- -f3- | rev
get_dependent_pkgs | sed -r 's/-[0-9].*//'
(the first dash followed by a digit is the start of the version part in the rpm package name.)
end
# https://src.fedoraproject.org/rpms/fbrnch function topo_sort_and_sidetag_build fbrnch parallel --sidetag rawhide (parse_names) end
Thanks, Zbyszek
On Sun, Feb 13, 2022 at 05:46:49PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
On Sun, Feb 13, 2022 at 09:43:38AM -0600, Michael Catanzaro wrote:
On Sun, Feb 13 2022 at 02:26:46 PM +0100, Miro Hrončok mhroncok@redhat.com wrote:
Considering most of the dependent packages failed to rebuild in this case, I am not sure how a robot would be supposed to deal with this :(
If the bot can handle everything that doesn't require manual intervention, that's still a good improvement over the status quo.
A bot would be nice, but I think we're unlikely to get this in the near future. I think it would be useful to start with a helper script to:
- identify all dependent packages that need to be rebuild
- if possible figure out build dependencies (i.e. the cases where we know that some package will fail to build until some other package in the set has been rebuilt),
- suggest a build order
- start builds in a side tag
Then you could ask a proven packager to just run the rebuild command, even if you don't have the privileges yourself.
If we ever want to write a bot for this, this script will be a good starting point…
+100 to improving tooling here. It would be nice if we could get it into fedora-packager too so it's in a easy to find place and many people could contribute to it.
So, most/much of what you list above (or perhaps the part before it) is/was handled by the stewardship-sig's review-pr.py. I think that might be a good place to start. Then you get:
* All dependent packages id'ed and built against pr in copr * Can see what packages fail to build in copr
We could perhaps enhance it to get a build order and run so it makes a sidetag, merges the pr and does the builds?
kevin
On 2/13/22 15:29, Kevin Fenzi wrote:
On Sun, Feb 13, 2022 at 05:46:49PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
On Sun, Feb 13, 2022 at 09:43:38AM -0600, Michael Catanzaro wrote:
On Sun, Feb 13 2022 at 02:26:46 PM +0100, Miro Hrončok mhroncok@redhat.com wrote:
Considering most of the dependent packages failed to rebuild in this case, I am not sure how a robot would be supposed to deal with this :(
If the bot can handle everything that doesn't require manual intervention, that's still a good improvement over the status quo.
A bot would be nice, but I think we're unlikely to get this in the near future. I think it would be useful to start with a helper script to:
- identify all dependent packages that need to be rebuild
- if possible figure out build dependencies (i.e. the cases where we know that some package will fail to build until some other package in the set has been rebuilt),
- suggest a build order
- start builds in a side tag
Then you could ask a proven packager to just run the rebuild command, even if you don't have the privileges yourself.
If we ever want to write a bot for this, this script will be a good starting point…
+100 to improving tooling here. It would be nice if we could get it into fedora-packager too so it's in a easy to find place and many people could contribute to it.
A bot could also allow the use of dynamic linking for libraries and languages that do not have a stable ABI. Haskell, Rust, and OCaml come to mind, as do C++ template libraries when the template part changes. There is simply no way I know of to have a stable ABI in Rust or Haskell, so being able to automatically rebuild reverse dependencies when needed is the only realistic way for them to use dynamic linking at all.
In C++ one often gets away without the rebuild, but this is a violation of the One Definition Rule and is undefined behavior. Furthermore, any bug fixes in template code or inline functions will not propagate to users of the library until the users are rebuilt.
On Sun, Feb 13, 2022 at 11:47 AM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Sun, Feb 13, 2022 at 09:43:38AM -0600, Michael Catanzaro wrote:
On Sun, Feb 13 2022 at 02:26:46 PM +0100, Miro Hrončok mhroncok@redhat.com wrote:
Considering most of the dependent packages failed to rebuild in this case, I am not sure how a robot would be supposed to deal with this :(
If the bot can handle everything that doesn't require manual intervention, that's still a good improvement over the status quo.
A bot would be nice, but I think we're unlikely to get this in the near future. I think it would be useful to start with a helper script to:
- identify all dependent packages that need to be rebuild
- if possible figure out build dependencies (i.e. the cases where we know that some package will fail to build until some other package in the set has been rebuilt),
- suggest a build order
- start builds in a side tag
Then you could ask a proven packager to just run the rebuild command, even if you don't have the privileges yourself.
If we ever want to write a bot for this, this script will be a good starting point…
I used to be motivated to write such a bot, but after the rpmautospec thing, I'm not going to bother. I wanted rpmautospec to handle rebuilds without commits/changelog bumps, because then we could trigger rebuilds more simply (dependency drift? rebuild in side-tag then merge once all rebuilds are done). Now it would require interacting with Git and changelog bumps.
Essentially, this is the model that is used in openSUSE and it's quite a bit less stressful.
On Sun, Feb 13, 2022 at 04:27:36PM -0500, Neal Gompa wrote:
I used to be motivated to write such a bot, but after the rpmautospec thing, I'm not going to bother. I wanted rpmautospec to handle rebuilds without commits/changelog bumps, because then we could trigger rebuilds more simply (dependency drift? rebuild in side-tag then merge once all rebuilds are done). Now it would require interacting with Git and changelog bumps.
Essentially, this is the model that is used in openSUSE and it's quite a bit less stressful.
I think you're mixing up two things here. We *do* want to record the fact that the rebuild happened. It should be visible in the changelog, possibly with some explanatory text and a link to a bug number, and the new build should have a release bump. The way that we cause all those things to happen in Fedora is by commiting to dist-git. With rpmautospec this commit might be empty, but it still needs to exist.
The bot for rebuilds would need two privileges: for dist-git and for koji. And it was the same before rpmautospec and now. And I think it's good that rpmautospec deals with changelog/release number generation at the level of a single package, and doesn't try to handle additional disto-wide jobs.
Zbyszek
On Mon, Feb 14, 2022 at 3:31 AM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Sun, Feb 13, 2022 at 04:27:36PM -0500, Neal Gompa wrote:
I used to be motivated to write such a bot, but after the rpmautospec thing, I'm not going to bother. I wanted rpmautospec to handle rebuilds without commits/changelog bumps, because then we could trigger rebuilds more simply (dependency drift? rebuild in side-tag then merge once all rebuilds are done). Now it would require interacting with Git and changelog bumps.
Essentially, this is the model that is used in openSUSE and it's quite a bit less stressful.
I think you're mixing up two things here. We *do* want to record the fact that the rebuild happened. It should be visible in the changelog, possibly with some explanatory text and a link to a bug number, and the new build should have a release bump. The way that we cause all those things to happen in Fedora is by commiting to dist-git. With rpmautospec this commit might be empty, but it still needs to exist.
Why? Why does that even *matter*? In ordinary circumstances, there would be *zero* information to provide anyway. A rebuild should happen with *no* effort on *anyone's* part. The churn is *already* recorded by Koji separately in its own metadata.
The bot for rebuilds would need two privileges: for dist-git and for koji. And it was the same before rpmautospec and now. And I think it's good that rpmautospec deals with changelog/release number generation at the level of a single package, and doesn't try to handle additional disto-wide jobs.
Touching Dist-Git is hugely problematic. It creates races between contributors, collaborators, pull requests, etc. The fact that we have to do that for rebuilds basically forces manual involvement for all rebuilds.
-- 真実はいつも一つ!/ Always, there's only one truth!
Your points about why touching dist-git for rebuilds can be problematic are correct, I think. However, I don’t see an easy way around the fact that a release bump is required to produce a new build that obsoletes the previous build, and that interaction with dist-git is required to make this happen—in classic spec files because the release number is hard-coded and must be updated along with the changelog, and in rpmautospec spec files because the release and changelog are computed based on dist-git history, and the presence of a new commit is the only way to communicate the need to bump the release. Maybe I’m missing something.
On Mon, Feb 14, 2022, at 10:32 AM, Neal Gompa wrote:
On Mon, Feb 14, 2022 at 3:31 AM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Sun, Feb 13, 2022 at 04:27:36PM -0500, Neal Gompa wrote:
I used to be motivated to write such a bot, but after the rpmautospec thing, I'm not going to bother. I wanted rpmautospec to handle rebuilds without commits/changelog bumps, because then we could trigger rebuilds more simply (dependency drift? rebuild in side-tag then merge once all rebuilds are done). Now it would require interacting with Git and changelog bumps.
Essentially, this is the model that is used in openSUSE and it's quite a bit less stressful.
I think you're mixing up two things here. We *do* want to record the fact that the rebuild happened. It should be visible in the changelog, possibly with some explanatory text and a link to a bug number, and the new build should have a release bump. The way that we cause all those things to happen in Fedora is by commiting to dist-git. With rpmautospec this commit might be empty, but it still needs to exist.
Why? Why does that even *matter*? In ordinary circumstances, there would be *zero* information to provide anyway. A rebuild should happen with *no* effort on *anyone's* part. The churn is *already* recorded by Koji separately in its own metadata.
The bot for rebuilds would need two privileges: for dist-git and for koji. And it was the same before rpmautospec and now. And I think it's good that rpmautospec deals with changelog/release number generation at the level of a single package, and doesn't try to handle additional disto-wide jobs.
Touching Dist-Git is hugely problematic. It creates races between contributors, collaborators, pull requests, etc. The fact that we have to do that for rebuilds basically forces manual involvement for all rebuilds.
-- 真実はいつも一つ!/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Mon, Feb 14, 2022 at 10:32:40AM -0500, Neal Gompa wrote:
On Mon, Feb 14, 2022 at 3:31 AM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Sun, Feb 13, 2022 at 04:27:36PM -0500, Neal Gompa wrote:
I used to be motivated to write such a bot, but after the rpmautospec thing, I'm not going to bother. I wanted rpmautospec to handle rebuilds without commits/changelog bumps, because then we could trigger rebuilds more simply (dependency drift? rebuild in side-tag then merge once all rebuilds are done). Now it would require interacting with Git and changelog bumps.
Essentially, this is the model that is used in openSUSE and it's quite a bit less stressful.
I think you're mixing up two things here. We *do* want to record the fact that the rebuild happened. It should be visible in the changelog, possibly with some explanatory text and a link to a bug number, and the new build should have a release bump. The way that we cause all those things to happen in Fedora is by commiting to dist-git. With rpmautospec this commit might be empty, but it still needs to exist.
Why? Why does that even *matter*?
It matters! The fact that the rebuild happened (and why) is very important. Obviously we expect the rebuild to require a different SONAME. So the new package is uninstallable on a system from a few days ago, and the old package is uninstallable on updates systems. So it should be clear that (despite having the same sources) this binary package very much *not the same*.
In ordinary circumstances, there would be *zero* information to provide anyway. A rebuild should happen with *no* effort on *anyone's* part. The churn is *already* recorded by Koji separately in its own metadata.
It may be well be recorded in koji, but we don't interact with packages through koji. Users do not and should not directly query koji for information about packages.
I agree that we should reduce the effort. But reducing effort != hiding information about the rebuild.
The bot for rebuilds would need two privileges: for dist-git and for koji. And it was the same before rpmautospec and now. And I think it's good that rpmautospec deals with changelog/release number generation at the level of a single package, and doesn't try to handle additional disto-wide jobs.
Touching Dist-Git is hugely problematic. It creates races between contributors, collaborators, pull requests, etc. The fact that we have to do that for rebuilds basically forces manual involvement for all rebuilds.
Is this really a problem? If you do "git commit --allow-empty -m 'Rebuild for …' && git push --atomic && fedpkg build" (or some programmatic equivalent), there is a window, but it is very small.
Let's say that somebody adds some patches in the meantime. This can happen at three points: before git push, before fedpkg build, or after fedpkg build.
If they do so before you did the push, your push fails, they win the race completely, and you can reconsider what to do. If they do this after you started the build, you have won the race and there is no issue. If they do a merge between the push and "fedpkg build", however unlikely this may be, you end up with a rebuild that includes the merged pull request and the commit for rebuild. I think this is still OK. It is also quite unlikely: a push from a local clone would fail because the remote would not be ff, and merging in the pagure web UI would fail because pagure will ask you to refresh the page first.
So I think in practice you end up with either side winning the race completely and the other side getting an error that they need to rebase. In case of empty commits there is no conflict possible, so the rebase always trivially succeeds.
Zbyszek
On 2/13/22 06:26, Miro Hrončok wrote:
Still in progress: gdal (already succeeded on some architectures)
Failed twice (13): LibRaw OpenSceneGraph digikam eccodes gegl04 grads grib_api kdelibs kdelibs3 ncl qt5-qtimageformats qt6-qtimageformats wgrib2
If somebody wants to help, build in f37-build-side-50649 please.
Some of these are due to the need to rebuild g2clib (which is a static library). I've submitted that:
https://koji.fedoraproject.org/koji/taskinfo?taskID=82783644
On 13. 02. 22 21:19, Orion Poplawski wrote:
On 2/13/22 06:26, Miro Hrončok wrote:
Still in progress: gdal (already succeeded on some architectures)
Failed twice (13): LibRaw OpenSceneGraph digikam eccodes gegl04 grads grib_api kdelibs kdelibs3 ncl qt5-qtimageformats qt6-qtimageformats wgrib2
If somebody wants to help, build in f37-build-side-50649 please.
Some of these are due to the need to rebuild g2clib (which is a static library). I've submitted that:
https://koji.fedoraproject.org/koji/taskinfo?taskID=82783644
I've waited for g2clib-1.6.3-4.fc37 and submitted everything again.
They all failed except for ncl which i still building:
https://koji.fedoraproject.org/koji/taskinfo?taskID=82783944
On 13. 02. 22 21:40, Miro Hrončok wrote:
On 13. 02. 22 21:19, Orion Poplawski wrote:
On 2/13/22 06:26, Miro Hrončok wrote:
Still in progress: gdal (already succeeded on some architectures)
Failed twice (13): LibRaw OpenSceneGraph digikam eccodes gegl04 grads grib_api kdelibs kdelibs3 ncl qt5-qtimageformats qt6-qtimageformats wgrib2
If somebody wants to help, build in f37-build-side-50649 please.
Some of these are due to the need to rebuild g2clib (which is a static library). I've submitted that:
https://koji.fedoraproject.org/koji/taskinfo?taskID=82783644
I've waited for g2clib-1.6.3-4.fc37 and submitted everything again.
They all failed except for ncl which i still building:
https://koji.fedoraproject.org/koji/taskinfo?taskID=82783944
And... it failed as well.
On 2/13/22 13:40, Miro Hrončok wrote:
On 13. 02. 22 21:19, Orion Poplawski wrote:
On 2/13/22 06:26, Miro Hrončok wrote:
Still in progress: gdal (already succeeded on some architectures)
Failed twice (13): LibRaw OpenSceneGraph digikam eccodes gegl04 grads grib_api kdelibs kdelibs3 ncl qt5-qtimageformats qt6-qtimageformats wgrib2
If somebody wants to help, build in f37-build-side-50649 please.
Some of these are due to the need to rebuild g2clib (which is a static library). I've submitted that:
https://koji.fedoraproject.org/koji/taskinfo?taskID=82783644
I've waited for g2clib-1.6.3-4.fc37 and submitted everything again.
They all failed except for ncl which i still building:
https://koji.fedoraproject.org/koji/taskinfo?taskID=82783944
I think we're going to need a jasper2 compat library. At least I don't have time to port stuff and a number of these are mostly dead upstream.
On 2/13/22 13:19, devel@lists.fedoraproject.org wrote:
On 2/13/22 06:26, Miro Hrončok wrote:
Still in progress: gdal (already succeeded on some architectures)
Failed twice (13): LibRaw OpenSceneGraph digikam eccodes gegl04 grads grib_api kdelibs kdelibs3 ncl qt5-qtimageformats qt6-qtimageformats wgrib2
If somebody wants to help, build in f37-build-side-50649 please.
Some of these are due to the need to rebuild g2clib (which is a static library). I've submitted that:
https://koji.fedoraproject.org/koji/taskinfo?taskID=82783644
Or not. I'll see what I can figure out.
On 2/13/22 13:51, devel@lists.fedoraproject.org wrote:
On 2/13/22 13:19, devel@lists.fedoraproject.org wrote:
On 2/13/22 06:26, Miro Hrončok wrote:
Still in progress: gdal (already succeeded on some architectures)
Failed twice (13): LibRaw OpenSceneGraph digikam eccodes gegl04 grads grib_api kdelibs kdelibs3 ncl qt5-qtimageformats qt6-qtimageformats wgrib2
If somebody wants to help, build in f37-build-side-50649 please.
Some of these are due to the need to rebuild g2clib (which is a static library). I've submitted that:
https://koji.fedoraproject.org/koji/taskinfo?taskID=82783644
Or not. I'll see what I can figure out.
Looks like some of these are using internal functions that are no longer exported. Still poking around at how to fix since I'm not familiar with jasper's API.
Hi,
eccodes will need to be adapted upstream. I filed an issue there and they will try to fix this a.s.a.p. Untill then, if needed, I could remove use of libjasper since it is an optional feature.
grib_api is no longer maintained upstream, so not much can be done there.
Jos.
On 2/13/22 21:51, Orion Poplawski wrote:
On 2/13/22 13:19, devel@lists.fedoraproject.org wrote:
On 2/13/22 06:26, Miro Hrončok wrote:
Still in progress: gdal (already succeeded on some architectures)
Failed twice (13): LibRaw OpenSceneGraph digikam eccodes gegl04 grads grib_api kdelibs kdelibs3 ncl qt5-qtimageformats qt6-qtimageformats wgrib2
If somebody wants to help, build in f37-build-side-50649 please.
Some of these are due to the need to rebuild g2clib (which is a static library). I've submitted that:
https://koji.fedoraproject.org/koji/taskinfo?taskID=82783644
Or not. I'll see what I can figure out.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Jos de Kloe wrote on 2022/02/14 15:56:
Hi,
eccodes will need to be adapted upstream. I filed an issue there and they will try to fix this a.s.a.p. Untill then, if needed, I could remove use of libjasper since it is an optional feature.
For now, I've pushed: https://src.fedoraproject.org/rpms/eccodes/c/a086e5e7b27c579a9fd0afbc4b7be1a...
scratch build was okay: https://koji.fedoraproject.org/koji/taskinfo?taskID=82812510
Now doing real build.
Mamoru
grib_api is no longer maintained upstream, so not much can be done there.
Jos.
On 2/13/22 21:51, Orion Poplawski wrote:
On 2/13/22 13:19, devel@lists.fedoraproject.org wrote:
On 2/13/22 06:26, Miro Hrončok wrote:
Still in progress: gdal (already succeeded on some architectures)
Failed twice (13): LibRaw OpenSceneGraph digikam eccodes gegl04 grads grib_api kdelibs kdelibs3 ncl qt5-qtimageformats qt6-qtimageformats wgrib2
If somebody wants to help, build in f37-build-side-50649 please.
Some of these are due to the need to rebuild g2clib (which is a static library). I've submitted that:
https://koji.fedoraproject.org/koji/taskinfo?taskID=82783644
Or not. I'll see what I can figure out.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Miro Hrončok wrote:
kdelibs kdelibs3
So they both hit this error:
/usr/include/jasper/jas_log.h:122:46: error: expected primary-expression before 'int' 122 | static inline jas_logtype_t jas_logtype_init(int class, int priority) | ^~~ /usr/include/jasper/jas_log.h:122:57: error: expected primary-expression before 'int' 122 | static inline jas_logtype_t jas_logtype_init(int class, int priority) | ^~~ /usr/include/jasper/jas_log.h:122:69: error: expression list treated as compound expression in initializer [-fpermissive] 122 | static inline jas_logtype_t jas_logtype_init(int class, int priority) | ^
which appears to be due to something defining jas_logtype_init both as a macro and as an inline function. The macro makes the inline definition fail to parse.
The kdelibs 4 build in addition also chokes on incompatible function pointer types:
/builddir/build/BUILD/kdelibs-4.14.38/kimgio/jp2.cpp:151:9: error: invalid conversion from 'int (*)(jas_stream_obj_t*, char*, unsigned int)' {aka 'int (*) (void*, char*, unsigned int)'} to 'ssize_t (*)(jas_stream_obj_t*, char*, size_t)' {aka 'long int (*)(void*, char*, long unsigned int)'} [-fpermissive] 151 | qiodevice_read, | ^~~~~~~~~~~~~~ | | | int (*)(jas_stream_obj_t*, char*, unsigned int) {aka int (*)(void*, char*, unsigned int)} /builddir/build/BUILD/kdelibs-4.14.38/kimgio/jp2.cpp:152:9: error: invalid conversion from 'int (*)(jas_stream_obj_t*, const char*, unsigned int)' {aka 'int (*)(void*, const char*, unsigned int)'} to 'ssize_t (*)(jas_stream_obj_t*, const char*, size_t)' {aka 'long int (*)(void*, const char*, long unsigned int)'} [-fpermissive] 152 | qiodevice_write, | ^~~~~~~~~~~~~~~ | | | int (*)(jas_stream_obj_t*, const char*, unsigned int) {aka int (*)(void*, const char*, unsigned int)}
Kevin Kofler
Kevin Kofler via devel wrote:
Miro Hrončok wrote:
kdelibs kdelibs3
So they both hit this error:
/usr/include/jasper/jas_log.h:122:46: error: expected primary-expression before 'int' 122 | static inline jas_logtype_t jas_logtype_init(int class, int priority) | ^~~ /usr/include/jasper/jas_log.h:122:57: error: expected primary-expression before 'int' 122 | static inline jas_logtype_t jas_logtype_init(int class, int priority) | ^~~ /usr/include/jasper/jas_log.h:122:69: error: expression list treated as compound expression in initializer [-fpermissive] 122 | static inline jas_logtype_t jas_logtype_init(int class, int priority) |
^
which appears to be due to something defining jas_logtype_init both as a macro and as an inline function. The macro makes the inline definition fail to parse.
Since Qt 5, the code has moved to Qt and is now in qt5-qtimageformats and qt6-imageformats. And in fact, qt6-imageformats hits the same error. qt5-qtimageformats, which builds using QMake rather than CMake, fails to detect the new Japer entirely, possibly because it tries to build a test file against it and fails with the same error. That would have to be investigated more closely.
Kevin Kofler
Miro Hrončok wrote on 2022/02/13 22:26:
On 13. 02. 22 13:32, Josef Řídký wrote:
Hi,
first of all, I would like to apologize for the mess I've caused by the jasper .so name bump in Rawhide. I entirely forgot the side-tag option and had the old mindset of having rawhide as a "sandbox for new features". I wrote to Miro already as I am not part of the proven packager group to assist me with the update - specifically with package rebuild.
On the other hand, I have to partially agree with Kevin Koffler in the way that making library upgrade in the rawhide from a regular maintainer point of view is still quite painful and from discussion with my colleagues it seems that I am not the only one who feels it that way.
Mostly, simple rebuild of dependent packages is all that is needed, but to achieve it, I have to either communicate with all other maintainers (where their number might be quite huge and not all of them are able to react in meningul timeframe - agree it's not applicable with handful of dependent packages, where it is easy to get it done) or bother some proven packager to do the rebuilds on my behalf (which is something I don't like, as the workload is transferred to someone, who has enough of his/her own tasks already).
It would be awesome to have some bot available for all Fedora maintainers, which would have proven packagers rights and it's only function would be -> bump spec file and build (e.g. in specific side-tag). In that way, for most library updates this would be the easiest way, how to get them into Fedora and bother other maintainers/proven packagers as little as possible.
Considering most of the dependent packages failed to rebuild in this case, I am not sure how a robot would be supposed to deal with this :(
Successful rebuilds (jasper+5):
https://koji.fedoraproject.org/koji/builds?inherited=0&tagID=50649&o...
Still in progress: gdal (already succeeded on some architectures)
Failed twice (13): LibRaw OpenSceneGraph digikam eccodes gegl04 grads grib_api kdelibs kdelibs3 ncl qt5-qtimageformats qt6-qtimageformats wgrib2
If somebody wants to help, build in f37-build-side-50649 please.
A One issue as Kevin pointed out should be fixed in https://src.fedoraproject.org/rpms/jasper/c/810e315ae32ec99e569361e680308fd1...
LibRaw, gegl04, OpenSceneGraph, digikam was okay with the above change.
kdelibs3 also seems to be okay with above, but ppc64le build only failed: https://koji.fedoraproject.org/koji/taskinfo?taskID=82799185 Looking at build.log , it looks like parallel make issue.
B Other issue like missing symbol on jpc_encode / jpc_decode is that now jasper 3 hides these internal decoder / encoder symbols: https://github.com/jasper-software/jasper/commit/5fe57ac5829ec31396e7eaab59a...
(While I am testing now) I believe that the usage image=jpc_decode(jpcstream,opts); can simply replaced with image=jas_image_decode (jpcstream, -1, 0);
and ier=jpc_encode(&image,jpcstream,opts); can be fmt = jas_image_strtofmt("jpc"); ier=jas_image_encode(&image,jpcstream,fmt,opts);
Now I am trying to fix g2clib -> grads chain dependency first.
Regards, Mamoru
Mamoru TASAKA wrote on 2022/02/14 17:47:
Miro Hrončok wrote on 2022/02/13 22:26:
On 13. 02. 22 13:32, Josef Řídký wrote:
Hi,
first of all, I would like to apologize for the mess I've caused by the jasper .so name bump in Rawhide. I entirely forgot the side-tag option and had the old mindset of having rawhide as a "sandbox for new features". I wrote to Miro already as I am not part of the proven packager group to assist me with the update - specifically with package rebuild.
On the other hand, I have to partially agree with Kevin Koffler in the way that making library upgrade in the rawhide from a regular maintainer point of view is still quite painful and from discussion with my colleagues it seems that I am not the only one who feels it that way.
Mostly, simple rebuild of dependent packages is all that is needed, but to achieve it, I have to either communicate with all other maintainers (where their number might be quite huge and not all of them are able to react in meningul timeframe - agree it's not applicable with handful of dependent packages, where it is easy to get it done) or bother some proven packager to do the rebuilds on my behalf (which is something I don't like, as the workload is transferred to someone, who has enough of his/her own tasks already).
It would be awesome to have some bot available for all Fedora maintainers, which would have proven packagers rights and it's only function would be -> bump spec file and build (e.g. in specific side-tag). In that way, for most library updates this would be the easiest way, how to get them into Fedora and bother other maintainers/proven packagers as little as possible.
Considering most of the dependent packages failed to rebuild in this case, I am not sure how a robot would be supposed to deal with this :(
Successful rebuilds (jasper+5):
https://koji.fedoraproject.org/koji/builds?inherited=0&tagID=50649&o...
Still in progress: gdal (already succeeded on some architectures)
Failed twice (13): LibRaw OpenSceneGraph digikam eccodes gegl04 grads grib_api kdelibs kdelibs3 ncl qt5-qtimageformats qt6-qtimageformats wgrib2
If somebody wants to help, build in f37-build-side-50649 please.
A One issue as Kevin pointed out should be fixed in https://src.fedoraproject.org/rpms/jasper/c/810e315ae32ec99e569361e680308fd1...
LibRaw, gegl04, OpenSceneGraph, digikam was okay with the above change.
kdelibs3 also seems to be okay with above, but ppc64le build only failed: https://koji.fedoraproject.org/koji/taskinfo?taskID=82799185 Looking at build.log , it looks like parallel make issue.
B Other issue like missing symbol on jpc_encode / jpc_decode is that now jasper 3 hides these internal decoder / encoder symbols: https://github.com/jasper-software/jasper/commit/5fe57ac5829ec31396e7eaab59a...
(While I am testing now) I believe that the usage image=jpc_decode(jpcstream,opts); can simply replaced with image=jas_image_decode (jpcstream, -1, 0);
and ier=jpc_encode(&image,jpcstream,opts); can be fmt = jas_image_strtofmt("jpc"); ier=jas_image_encode(&image,jpcstream,fmt,opts);
Now I am trying to fix g2clib -> grads chain dependency first.
Unfortunately eccodes testsuite now fails with the above changes ( calling jas_stream_memopen() just aborts, gdb shows like below (*)) and it seems now calling jasper function like jas_stream_memopen() now always have to call some initialization functions like:
jas_conf_clear(); jas_conf_set_max_mem_usage(jas_get_total_mem_size()); jas_init_library(); jas_init_thread();
beforehand, and after that some shutdown functions have to be called:
jas_cleanup_thread(); jas_cleanup_library();
(and thanks to eccodes testsuite for pointing this out). With the above additional changes, eccodes test suite now all passes (on x86_64, I verified only on this arch for now)
So simple rebuilding seems not enough and it seems all jasper consumers may have to adjust internal code to jasper 3...
Is it okay for me to commit these changes? I really appreciate it if jasper maintainer confirms the above changes. Or we should investigat jasper changes more carefully?
Regards, Mamoru
(*) For example, one of eccodes testsuite aborts like:
Program received signal SIGABRT, Aborted. 0x00007ffff7b8cedc in __pthread_kill_implementation () from /lib64/libc.so.6 Missing separate debuginfos, use: dnf debuginfo-install glibc-2.35-2.fc37.x86_64 libgomp-12.0.1-0.7.fc37.x86_64 libjpeg-turbo-2.1.2-2.fc36.x86_64 libpng-1.6.37-12.fc36.x86_64 openjpeg2-2.4.0-5.fc36.x86_64 zlib-1.2.11-31.fc36.x86_64 (gdb) bt #0 0x00007ffff7b8cedc in __pthread_kill_implementation () from /lib64/libc.so.6 #1 0x00007ffff7b3ca36 in raise () from /lib64/libc.so.6 #2 0x00007ffff7b2682f in abort () from /lib64/libc.so.6 #3 0x00007ffff7b2675b in __assert_fail_base.cold () from /lib64/libc.so.6 #4 0x00007ffff7b35596 in __assert_fail () from /lib64/libc.so.6 #5 0x00007ffff79d0209 in jas_get_ctx_internal () at /usr/src/debug/jasper-3.0.0-4.fc37.x86_64/src/libjasper/base/jas_init.c:919 #6 0x00007ffff79d5fdd in jas_get_ctx_internal () at /usr/src/debug/jasper-3.0.0-4.fc37.x86_64/src/libjasper/base/jas_init.c:919 #7 jas_get_ctx () at /usr/src/debug/jasper-3.0.0-4.fc37.x86_64/src/libjasper/include/jasper/jas_init.h:407 #8 jas_get_debug_level () at /usr/src/debug/jasper-3.0.0-4.fc37.x86_64/src/libjasper/include/jasper/jas_init.h:432 #9 jas_stream_memopen ( buf=buf@entry=0x55555583fd80 "\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373\034\373"..., bufsize=bufsize@entry=130320) at /usr/src/debug/jasper-3.0.0-4.fc37.x86_64/src/libjasper/base/jas_stream.c:208 #10 0x00007ffff7e413b9 in grib_jasper_encode (c=0x7ffff7fb0a60 <default_grib_context>, helper=helper@entry=0x7ffffffed2b0) at /builddir/build/BUILD/eccodes-2.24.0-Source/src/grib_jasper_encoding.c:175 #11 0x00007ffff7e43fda in pack_double (a=0x555555811640, cval=0x7ffff714b010, len=0x7ffffffed360) at /builddir/build/BUILD/eccodes-2.24.0-Source/src/grib_accessor_class_data_jpeg2000_packing.c:527 #12 0x00007ffff7e8831c in _grib_set_double_array_internal (h=h@entry=0x555555813b10, a=a@entry=0x555555811640, val=val@entry=0x7ffff714b010, buffer_len=<optimized out>, encoded_length=encoded_length@entry=0x7ffffffed3c0, check=check@entry=0) at /builddir/build/BUILD/eccodes-2.24.0-Source/src/grib_value.c:660 #13 0x00007ffff7e8844b in _grib_set_double_array (h=h@entry=0x555555813b10, name=name@entry=0x555555813470 "codedValues", val=val@entry=0x7ffff714b010, length=<optimized out>, check=check@entry=0) at /builddir/build/BUILD/eccodes-2.24.0-Source/src/grib_value.c:696 #14 0x00007ffff7e88501 in grib_set_double_array_internal (h=0x555555813b10, name=0x555555813470 "codedValues", val=0x7ffff714b010, length=<optimized out>) at /builddir/build/BUILD/eccodes-2.24.0-Source/src/grib_value.c:719 #15 0x00007ffff7e3e604 in pack_double (a=0x55555581d970, val=0x7ffff714b010, len=0x7ffffffed4b8) at /builddir/build/BUILD/eccodes-2.24.0-Source/src/grib_accessor_class_data_apply_bitmap.c:322 #16 0x00007ffff7e565d2 in grib_init_accessor_from_handle (loader=0x7ffffffed9a0, ga=0x55555581d970, default_value=<optimized out>) at /builddir/build/BUILD/eccodes-2.24.0-Source/src/grib_loader_from_handle.c:225 #17 0x00007ffff7e0246b in create_accessor (p=0x5555558105e0, act=<optimized out>, h=0x7ffffffed9a0) at /builddir/build/BUILD/eccodes-2.24.0-Source/src/action_class_template.c:179 #18 0x00007ffff7e01b78 in notify_change (act=0x5555557fe890, notified=0x5555557fdf50, changed=<optimized out>) at /builddir/build/BUILD/eccodes-2.24.0-Source/src/action_class_section.c:177 #19 0x00007ffff7e87c78 in grib_dependency_notify_change (observed=observed@entry=0x5555557eafe0) at /builddir/build/BUILD/eccodes-2.24.0-Source/src/grib_dependency.c:134 #20 0x00007ffff7e88018 in grib_set_long (h=<optimized out>, name=0x5555557d71a0 "dataRepresentationTemplateNumber", val=<optimized out>) at /builddir/build/BUILD/eccodes-2.24.0-Source/src/grib_value.c:111 #21 0x00007ffff7e8c9b3 in grib_set_values (h=0x555555682200, args=<optimized out>, count=1) at /builddir/build/BUILD/eccodes-2.24.0-Source/src/grib_value.c:1664 #22 0x00007ffff7e111c0 in grib_concept_apply (a=<optimized out>, name=<optimized out>) at /builddir/build/BUILD/eccodes-2.24.0-Source/src/grib_accessor_class_concept.c:415 #23 0x00007ffff7e88a1b in grib_set_string (h=<optimized out>, name=0x555555679ec0 "packingType", val=0x555555679ee0 "grid_jpeg", length=0x7fffffffe080) at /builddir/build/BUILD/eccodes-2.24.0-Source/src/grib_value.c:424 #24 0x00007ffff7e8cb20 in grib_set_values (h=h@entry=0x555555682200, args=args@entry=0x555555568060 <global_options+32832>, count=count@entry=1) at /builddir/build/BUILD/eccodes-2.24.0-Source/src/grib_value.c:1678 #25 0x000055555555b625 in grib_tool_new_handle_action (h=0x555555682200, options=0x555555560020 <global_options>) at /builddir/build/BUILD/eccodes-2.24.0-Source/tools/grib_set.c:129 #26 0x0000555555558dfa in grib_tool_without_orderby (options=0x555555560020 <global_options>) at /builddir/build/BUILD/eccodes-2.24.0-Source/tools/grib_tools.c:409 #27 grib_tool (argv=<optimized out>, argc=<optimized out>) at /builddir/build/BUILD/eccodes-2.24.0-Source/tools/grib_tools.c:197 #28 main (argc=<optimized out>, argv=<optimized out>) at /builddir/build/BUILD/eccodes-2.24.0-Source/tools/grib_set.c:60
Mamoru TASAKA wrote:
kdelibs3 also seems to be okay with above, but ppc64le build only failed: https://koji.fedoraproject.org/koji/taskinfo?taskID=82799185 Looking at build.log , it looks like parallel make issue.
Yes, try just resubmitting the build, hopefully it will not hit the race condition again.
Kevin Kofler
Miro Hrončok wrote on 2022/02/13 22:26:
On 13. 02. 22 13:32, Josef Řídký wrote:
Hi,
first of all, I would like to apologize for the mess I've caused by the jasper .so name bump in Rawhide. I entirely forgot the side-tag option and had the old mindset of having rawhide as a "sandbox for new features". I wrote to Miro already as I am not part of the proven packager group to assist me with the update - specifically with package rebuild.
On the other hand, I have to partially agree with Kevin Koffler in the way that making library upgrade in the rawhide from a regular maintainer point of view is still quite painful and from discussion with my colleagues it seems that I am not the only one who feels it that way.
Mostly, simple rebuild of dependent packages is all that is needed, but to achieve it, I have to either communicate with all other maintainers (where their number might be quite huge and not all of them are able to react in meningul timeframe - agree it's not applicable with handful of dependent packages, where it is easy to get it done) or bother some proven packager to do the rebuilds on my behalf (which is something I don't like, as the workload is transferred to someone, who has enough of his/her own tasks already).
It would be awesome to have some bot available for all Fedora maintainers, which would have proven packagers rights and it's only function would be -> bump spec file and build (e.g. in specific side-tag). In that way, for most library updates this would be the easiest way, how to get them into Fedora and bother other maintainers/proven packagers as little as possible.
Considering most of the dependent packages failed to rebuild in this case, I am not sure how a robot would be supposed to deal with this :(
Successful rebuilds (jasper+5):
https://koji.fedoraproject.org/koji/builds?inherited=0&tagID=50649&o...
Still in progress: gdal (already succeeded on some architectures)
Failed twice (13): LibRaw
- fixed by jasper header fix
OpenSceneGraph
- fixed by jasper header fix
digikam
- fixed by jasper header fix
eccodes
- fixed by replacing jpc_encode with jas_image_encode and other similar change
gegl04
- fixed by jasper header fix
grads
- fixed by g2clib side fix similar to eccodes
grib_api
- uses same code as eccodes, fixed likewise
kdelibs
- fixed by similar ways with eccodes + jas_stream_ops_t API change fix (perhaps) now building... https://koji.fedoraproject.org/koji/taskinfo?taskID=82817310
kdelibs3
- fixed by jasper header fix
ncl
- fixed by g2clib side
qt5-qtimageformats
- fixed by jasper header fix
qt6-qtimageformats
- fixed by jasper header fix
wgrib2
- fixed by similar way with eccodes
If somebody wants to help, build in f37-build-side-50649 please.
I am going to bed. Good night.
Regards, Mamoru
On 14. 02. 22 18:14, Mamoru TASAKA wrote:
Miro Hrončok wrote on 2022/02/13 22:26:
On 13. 02. 22 13:32, Josef Řídký wrote:
Hi,
first of all, I would like to apologize for the mess I've caused by the jasper .so name bump in Rawhide. I entirely forgot the side-tag option and had the old mindset of having rawhide as a "sandbox for new features". I wrote to Miro already as I am not part of the proven packager group to assist me with the update - specifically with package rebuild.
On the other hand, I have to partially agree with Kevin Koffler in the way that making library upgrade in the rawhide from a regular maintainer point of view is still quite painful and from discussion with my colleagues it seems that I am not the only one who feels it that way.
Mostly, simple rebuild of dependent packages is all that is needed, but to achieve it, I have to either communicate with all other maintainers (where their number might be quite huge and not all of them are able to react in meningul timeframe - agree it's not applicable with handful of dependent packages, where it is easy to get it done) or bother some proven packager to do the rebuilds on my behalf (which is something I don't like, as the workload is transferred to someone, who has enough of his/her own tasks already).
It would be awesome to have some bot available for all Fedora maintainers, which would have proven packagers rights and it's only function would be -> bump spec file and build (e.g. in specific side-tag). In that way, for most library updates this would be the easiest way, how to get them into Fedora and bother other maintainers/proven packagers as little as possible.
Considering most of the dependent packages failed to rebuild in this case, I am not sure how a robot would be supposed to deal with this :(
Successful rebuilds (jasper+5):
https://koji.fedoraproject.org/koji/builds?inherited=0&tagID=50649&o...
Still in progress: gdal (already succeeded on some architectures)
Failed twice (13): LibRaw
- fixed by jasper header fix
OpenSceneGraph
- fixed by jasper header fix
digikam
- fixed by jasper header fix
eccodes
- fixed by replacing jpc_encode with jas_image_encode and other similar change
gegl04
- fixed by jasper header fix
grads
- fixed by g2clib side fix similar to eccodes
grib_api
- uses same code as eccodes, fixed likewise
kdelibs
- fixed by similar ways with eccodes + jas_stream_ops_t API change fix (perhaps) now building... https://koji.fedoraproject.org/koji/taskinfo?taskID=82817310
kdelibs3
- fixed by jasper header fix
ncl
- fixed by g2clib side
qt5-qtimageformats
- fixed by jasper header fix
qt6-qtimageformats
- fixed by jasper header fix
wgrib2
- fixed by similar way with eccodes
If somebody wants to help, build in f37-build-side-50649 please.
I am going to bed. Good night.
Thank you so much!
https://bodhi.fedoraproject.org/updates/FEDORA-2022-0c298e65e6
On 2/15/22 02:42, Miro Hrončok wrote:
On 14. 02. 22 18:14, Mamoru TASAKA wrote:
Miro Hrončok wrote on 2022/02/13 22:26:
On 13. 02. 22 13:32, Josef Řídký wrote:
Hi,
first of all, I would like to apologize for the mess I've caused by the jasper .so name bump in Rawhide. I entirely forgot the side-tag option and had the old mindset of having rawhide as a "sandbox for new features". I wrote to Miro already as I am not part of the proven packager group to assist me with the update - specifically with package rebuild.
On the other hand, I have to partially agree with Kevin Koffler in the way that making library upgrade in the rawhide from a regular maintainer point of view is still quite painful and from discussion with my colleagues it seems that I am not the only one who feels it that way.
Mostly, simple rebuild of dependent packages is all that is needed, but to achieve it, I have to either communicate with all other maintainers (where their number might be quite huge and not all of them are able to react in meningul timeframe - agree it's not applicable with handful of dependent packages, where it is easy to get it done) or bother some proven packager to do the rebuilds on my behalf (which is something I don't like, as the workload is transferred to someone, who has enough of his/her own tasks already).
It would be awesome to have some bot available for all Fedora maintainers, which would have proven packagers rights and it's only function would be -> bump spec file and build (e.g. in specific side-tag). In that way, for most library updates this would be the easiest way, how to get them into Fedora and bother other maintainers/proven packagers as little as possible.
Considering most of the dependent packages failed to rebuild in this case, I am not sure how a robot would be supposed to deal with this :(
Successful rebuilds (jasper+5):
https://koji.fedoraproject.org/koji/builds?inherited=0&tagID=50649&o...
Still in progress: gdal (already succeeded on some architectures)
Failed twice (13): LibRaw
- fixed by jasper header fix
OpenSceneGraph
- fixed by jasper header fix
digikam
- fixed by jasper header fix
eccodes
- fixed by replacing jpc_encode with jas_image_encode and other similar change
gegl04
- fixed by jasper header fix
grads
- fixed by g2clib side fix similar to eccodes
grib_api
- uses same code as eccodes, fixed likewise
kdelibs
- fixed by similar ways with eccodes + jas_stream_ops_t API change fix (perhaps) now building... https://koji.fedoraproject.org/koji/taskinfo?taskID=82817310
kdelibs3
- fixed by jasper header fix
ncl
- fixed by g2clib side
qt5-qtimageformats
- fixed by jasper header fix
qt6-qtimageformats
- fixed by jasper header fix
wgrib2
- fixed by similar way with eccodes
If somebody wants to help, build in f37-build-side-50649 please.
I am going to bed. Good night.
Thank you so much!
https://bodhi.fedoraproject.org/updates/FEDORA-2022-0c298e65e6
Indeed, +100!
I think this will be my last reply on the topic...I think people know my view and Kevin's here (but if other folks have more questions, happy to answer them).
On Sat, Feb 12, 2022 at 08:09:34PM +0100, Kevin Kofler via devel wrote:
Kevin Fenzi wrote:
As a release engineer trying to get a rawhide compose, I do find this a big deal. (Another f37 compose just failed because of this issue).
Well, as I already pointed out more than once, the real issue there is that the Rawhide compose fails due to a broken dependency. This used not to be the case. If a deliverable fails to compose, then it will be missing for one day (or ideally, just keep the last one that built on the mirrors!). If it is release-blocking, it needs to be fixed before the release. Not sooner.
But thats way too late. Say you are working on a change, you get it all landed, and... someone breaks deps that causes images to not compose. You can't wait until release to get that fixed and see that it breaks a bunch of your work that you now need to fix.
This is how things used to work in the past (without the "or ideally" part, that is just my improvement suggestion that was never implemented) and it is why we were able to work much better with broken dependencies in Rawhide back then than now.
I disagree. I think rawhide is _more_ usefull now that it's at least Alpha quality all the time instead of broken for long periods.
Long ago we worked that way. Back when there were few packages and few maintainers.
The number of packages increases constantly, but the order of magnitude was not that different. What really made the difference was that the composes did not fail. Instead, they would succeed and we would automatically get a list of broken dependencies sent to the devel list (and then provenpackagers like Alex Lancaster and me tried to mass-fix them, and IMHO did a very good job at it, until, in lieu of a "thank you", we were told not to because it "masks the issue of unmaintained packages"… that was the point at which broken dependencies started to accumulate, creating the demand for gating).
I recall things differently. :) I fixed many a broken dep in the day too... but it's much more effective for everyone to not have them in the first place and it doesn't even require that much more work. Making a side tag takes 10 seconds. Sure, you may have to wait until deps are all sorted before merging, but that saves everyone a vast amount of time.
Perhaps you and Alex would be willing to volenteer to help maintainers finish up builds in side tags when asked? I know a number of times people mention on list that they would like help with builds in sidetags.
kevin
On 11. 02. 22 21:45, Kevin Kofler via devel wrote:
Miro Hrončok wrote:
It was actually announced:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
But for reasons I don't understand, it was pushed to rawhide without using a side tag and without doing rebuilds :(
I agree that untagging this is the best option now, it breaks hundreds of packages both on runtime and buildtime.
As a comaintainer of at least 2 of the affected packages (kdelibs3 and kdelibs 4), I must say I do not really understand why this is such a big deal. 18 packages would have needed to be rebuilt in Rawhide. "Hundreds of packages" is just with transitive dependencies that do not all need to be rebuilt. The untagging just makes us lose time because we can not rebuild the packages directly in Rawhide now.
The fact that we got automatically filed FTI bugs within hours is also absurd. It would be easiest to just have a provenpackager rebuild the packages and not bother the maintainers at all (nor untag the package). Filing a bug makes sense only if an FTI persists for more than a week at the very least. Transient breakage in Rawhide is perfectly normal.
We have always worked that way in Rawhide: if a soname got bumped, just rebuild the reverse dependencies and move on. It worked without any issues. So I do not see why this is suddenly no longer allowed.
I think Kevin Fenzi summarized it all, I just feel I need to add two things.
1) Not that long ago something like this happened, and I decided to go ahead and be the provenpackager that rebuilds all the packages. Half of them did not rebuild succesfully. So sure, a provenpackager can "just go ahead and deal with it" but it not always works as expected.
2) If the maintainer who updated this package was around, we could have tagged the build into a side tag and finish the rebuild there within minutes/hours. But they were not around. I've cc'ed them on all rebuild and received no reply. I believe untagging this and waiting for them is the best course of action. There is no reason to ship this immediately. It can wait and be done properly.
On 2/11/22 21:45, Kevin Kofler via devel wrote:
Miro Hrončok wrote:
It was actually announced:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
But for reasons I don't understand, it was pushed to rawhide without using a side tag and without doing rebuilds :(
I agree that untagging this is the best option now, it breaks hundreds of packages both on runtime and buildtime.
As a comaintainer of at least 2 of the affected packages (kdelibs3 and kdelibs 4), I must say I do not really understand why this is such a big deal. 18 packages would have needed to be rebuilt in Rawhide. "Hundreds of packages" is just with transitive dependencies that do not all need to be rebuilt. The untagging just makes us lose time because we can not rebuild the packages directly in Rawhide now.
The fact that we got automatically filed FTI bugs within hours is also absurd. It would be easiest to just have a provenpackager rebuild the packages and not bother the maintainers at all (nor untag the package). Filing a bug makes sense only if an FTI persists for more than a week at the very least. Transient breakage in Rawhide is perfectly normal.
We have always worked that way in Rawhide: if a soname got bumped, just rebuild the reverse dependencies and move on. It worked without any issues. So I do not see why this is suddenly no longer allowed.
Hi, Let me chime in as a maintainer of "just a transitive dependency" that was affected by the change. I've been working on Fedora for around a year now and can't tell anything about the old consensus but I want to share my thoughts on the current experience.
I've been preparing a bigger update of two widely-used Python libraries - Pygments and Sphinx - for the last three weeks. As thousands of packages depend on them, I did my best to establish potential impact (Copr FTW!), worked to resolve the spotted issues and finally it was good to go. But Rawhide was broken for my builds and I only could wait for it to be resolved. Things happen and I certainly don't want to blame anyone. I just think we could do better and not settle with this state as a normal one.
For each such update I prepare there are dozens of broken for unrelated reasons packages - it's already shadowing the real impact of my change on the others and in an ideal world I'd prefer to solve it all *before* the change I introduce lands in Rawhide. When even my tested package fails to build, it sums up to some nontrivial time. Every effort to make Rawhide a bit more stable for maintainers of those "middle-impact" packages will be welcome.
Cheers, Karolina