Heads up: openjpeg2-2.5.0 and gdal-3.5.0 coming to rawhide

[Sandro Mani]

Hi

I'll build openjpeg2-2.5.0 and gdal-3.5.0 for rawhide in the side tag 
f37-build-side-53899. I've switched gdal to the new cmake based build, 
and at the same time merged the mingw package with the native one. I'll 
rebuild affected packages as listed below.

Thanks
Sandro

---

lizams
bes
blender
cloudcompare
compat-ffmpeg4
darktable
dcm2niix
eccodes
efl
engauge-digitizer
ffmpeg
freeimage
gazebo
gdal
gdcm
geeqie
ghostscript
gimp
GMT
gpac
grass
gstreamer1-plugins-bad-free
ImageMagick
liblas
librasterlite2
mapnik
mapserver
merkaartor
mingw-freeimage
mingw-gstreamer1-plugins-bad-free
mingw-opencv
mingw-poppler
mtpaint
mupdf
ncl
opencv
OpenImageIO
OpenSceneGraph
openslide
osgearth
paraview
PDAL
poppler
postgis
python-fiona
python-pillow
python-PyMuPDF
python-rasterio
qgis
qmapshack
qsstv
R-rgdal
saga
vfrnav
vips
vtk
webkit2gtk3
zathura-pdf-mupdf

[Sandro Mani]

Hi

I've now merged the side tag. Remarks:

- opencv failed to build due to noarch -doc subpackage building 
differently on different arches. This caused by the intel_va sample only 
being included on x86 arches. I've made the -doc subpackge arched to 
solve this.
- python-PyMuPDF test fail due to a corrupted double-linked list 
assertion. I've disabled the test for now, and will investigate further.
- python-fiona test fail due to a segmentation fault. I've disabled the 
test for now, and will investigate further.
- gazebo fails to build due to "cannot convert 'ALCdevice*' to 
'ALCdevice_struct*' in assignment", which looks like an openal-soft-1.21 
incompatibility. Possibly updating gazebo from the currently packaged 
v10.1.0 to current upstream version 11.10.2 might help.

Sandro

On 20.05.22 22:42, Sandro Mani wrote:
>  Hi
>
>  I'll build openjpeg2-2.5.0 and gdal-3.5.0 for rawhide in the side tag 
>  f37-build-side-53899. I've switched gdal to the new cmake based build, 
>  and at the same time merged the mingw package with the native one. 
>  I'll rebuild affected packages as listed below.
>
>  Thanks
>  Sandro
>
>  ---
>
>  lizams
>  bes
>  blender
>  cloudcompare
>  compat-ffmpeg4
>  darktable
>  dcm2niix
>  eccodes
>  efl
>  engauge-digitizer
>  ffmpeg
>  freeimage
>  gazebo
>  gdal
>  gdcm
>  geeqie
>  ghostscript
>  gimp
>  GMT
>  gpac
>  grass
>  gstreamer1-plugins-bad-free
>  ImageMagick
>  liblas
>  librasterlite2
>  mapnik
>  mapserver
>  merkaartor
>  mingw-freeimage
>  mingw-gstreamer1-plugins-bad-free
>  mingw-opencv
>  mingw-poppler
>  mtpaint
>  mupdf
>  ncl
>  opencv
>  OpenImageIO
>  OpenSceneGraph
>  openslide
>  osgearth
>  paraview
>  PDAL
>  poppler
>  postgis
>  python-fiona
>  python-pillow
>  python-PyMuPDF
>  python-rasterio
>  qgis
>  qmapshack
>  qsstv
>  R-rgdal
>  saga
>  vfrnav
>  vips
>  vtk
>  webkit2gtk3
>  zathura-pdf-mupdf
>

[Mamoru TASAKA]

Sandro Mani wrote on 2022/05/23 3:39:
>  Hi
>  
>  - gazebo fails to build due to "cannot convert 'ALCdevice*' to
> 'ALCdevice_struct*' in assignment", which looks like an openal-soft-1.21
> incompatibility. Possibly updating gazebo from the currently packaged v10.1.0 to current
> upstream version 11.10.2 might help. 
Fixed by backporting upstream patch:
https://src.fedoraproject.org/rpms/gazebo/c/9b045b25a1c310648bc3158cadc4d...

Regards,
Mamoru

[Michael J Gruber]

Hi

>  I've now merged the side tag. Remarks: 
...
>  - python-PyMuPDF test fail due to a corrupted double-linked list 
>  assertion. I've disabled the test for now, and will investigate further.
>  - python-fiona test fail due to a segmentation fault. I've disabled the 
>  test for now, and will investigate further. 
Has there been any progress in the investigation?

That corrupted double-linked list in the test suite occurs only on rawhide and only since
some larger side-tags merged. Disabling the test suite permanently is not a god thing if
we think about the py3.11 rebuild, for example, as well as the upcoming update for mupdf
1.20.0.

That issue has some Heisenbug flavor, by the way, and typically shows up on 50% of the
archs only (but not with a reliable pattern). It does not show up on f36.

Since we cannot work with f37 chroot from before the side-tag merge any more, I tried with
F36 in copr and adding (rebuilding) F37 package versions from the side-tag one-by-one to
narrow down the issue: https://copr.fedorainfracloud.org/coprs/mjg/PyMuPDF-corruption/
(The f37 fails are the expected ones)

Unfortunately, python-pillow didn't build on s390x (neither on F37 nor F36), and I
don't want to exclude even more arches in the testing ground.

Have you faired better?

[Sandro Mani]

On 20.06.22 12:11, Michael J Gruber wrote:
>  Hi
>
> > I've now merged the side tag. Remarks:
>  ...
> > - python-PyMuPDF test fail due to a corrupted double-linked list
> > assertion. I've disabled the test for now, and will investigate further.
> > - python-fiona test fail due to a segmentation fault. I've disabled the
> > test for now, and will investigate further.
>  Has there been any progress in the investigation?
>
>  That corrupted double-linked list in the test suite occurs only on rawhide and only since
> some larger side-tags merged. Disabling the test suite permanently is not a god thing if
> we think about the py3.11 rebuild, for example, as well as the upcoming update for mupdf
> 1.20.0.
>
>  That issue has some Heisenbug flavor, by the way, and typically shows up on 50% of the
> archs only (but not with a reliable pattern). It does not show up on f36.
>
>  Since we cannot work with f37 chroot from before the side-tag merge any more, I tried
> with F36 in copr and adding (rebuilding) F37 package versions from the side-tag one-by-one
> to narrow down the issue: https://copr.fedorainfracloud.org/coprs/mjg/PyMuPDF-corruption/
> (The f37 fails are the expected ones)
>
>  Unfortunately, python-pillow didn't build on s390x (neither on F37 nor F36), and I
> don't want to exclude even more arches in the testing ground.
>
>  Have you faired better? 
Unfortunately not. I had looked into it and despite a
rawhide koji i686 
build pretty reliably failing, I was not able to reproduce the issue 
locally in a i686 rawhide chroot. I've looked into it again now and the 
behavior so far is still the same...