DevHeads.net

Postings by Sandro Mani

Non-responsive maintainer: Lubomir Rintel (lkundrak)

Hi

Does anyone know how to contact Lubomir Rintel (lkundrak)? He is
obviously still active since his last koji build is as recent as last
Sunday the 11th, but he isn't answering to this ticket [1] and I also
had no luck e-mailing him directly.

Thanks

Sandro

[1] <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1531289" title="https://bugzilla.redhat.com/show_bug.cgi?id=1531289">https://bugzilla.redhat.com/show_bug.cgi?id=1531289</a>

HEADS UP: upcoming giflib-5.1.4 update in rawhide

Hi

Per GifLib5 change [1] I plan to start updating to giflib-5.1.4 tomorrow
evening. I'll start by building giflib-5.1.4 and then follow with the
transition package compat-giflib-4-1.6, which will provide the old
giflib-4.x dependency during the transition to giflib-5.x.

Review request: compat-giflib

Hi

For the giflib-5.x update (see [1]) I need compat-giflib reviewed [2].

Happy to review in exchange.

Thanks
Sandro

[1] <a href="https://fedoraproject.org/wiki/Changes/GifLib5" title="https://fedoraproject.org/wiki/Changes/GifLib5">https://fedoraproject.org/wiki/Changes/GifLib5</a>
[2] <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1541516" title="https://bugzilla.redhat.com/show_bug.cgi?id=1541516">https://bugzilla.redhat.com/show_bug.cgi?id=1541516</a>

Help required: bootstrap-build of java-1.8.0-openjdk for giflib-5.x update

Hi

I've proposed a change to update to giflib-5.x for F28+ [1] (which is an
incompatible update from the current giflib-4.x). I did some initial
testing in this COPR repo [1], and have hit a problem with
java-1.8.0-openjdk, which has a BR on itself (java-1.8.0-openjdk-devel),
resulting in it wanting to pull in also giflib-4 (since the current
build is compiled against giflib-4), and hence leading to a conflict
when installing the build dependencies. So I'd need to do a bootstrap
build of java-1.8.0-openjdk without giflib support.

openjpeg-1.x removal

Hi

I've had a look at what still requires openjpeg-1.x, and there are just
a handful of packages which can be ported with relatively small effort
to openjpeg2.

scotch: packaging a version with 64bit integers

Hi

I've received a request to package a version of scotch with 64bit
integers (as opposed to 32bit). I suppose the details are less
important, the bottom line is

scotch 32bit: typedef int32_t SCOTCH_Num;

scotch 64bit: typedef int64_t SCOTCH_Num;

where SCOTCH_Num affects the public ABI and is used by third parties
which use scotch.

Upstream allows selecting the integer size at compile-time (i.e. passing
-DINTSIZE64 for int64_t).

Intent to retire eigen2

Hi

eigen2 has long since been EOL, was actually already retired once in
Fedora, but brought back alive to keep avogadro building (which didn't
build against eigen3 >= 3.3). Avogadro has since received proper
upstream eigen3 support, and the Fedora package has switched to using
eigen3. There are no other users of eigen2, so I plan to retire it the
coming weekend unless someone objects.

Thanks
Sandro

Review requests: mingw-qt5-qtserialport, mingw-qt5-qtcharts, mingw-twaindsm

Hi

Another bunch of mingw packages:

* mingw-qt5-qtserialport:
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1526479" title="https://bugzilla.redhat.com/show_bug.cgi?id=1526479">https://bugzilla.redhat.com/show_bug.cgi?id=1526479</a>

* mingw-qt5-qtcharts: <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1526480" title="https://bugzilla.redhat.com/show_bug.cgi?id=1526480">https://bugzilla.redhat.com/show_bug.cgi?id=1526480</a>

* mingw-twaindsm: <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1526481" title="https://bugzilla.redhat.com/show_bug.cgi?id=1526481">https://bugzilla.redhat.com/show_bug.cgi?id=1526481</a>

Should be pretty straight forward. Happy to review in exchange.

Sandro

Review requests: enchant2, mingw-enchant2

Hi

I've posted reviews for enchant2 and mingw-enchant2:

- enchant2: <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1525706" title="https://bugzilla.redhat.com/show_bug.cgi?id=1525706">https://bugzilla.redhat.com/show_bug.cgi?id=1525706</a>

- mingw-enchant2: <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1525707" title="https://bugzilla.redhat.com/show_bug.cgi?id=1525707">https://bugzilla.redhat.com/show_bug.cgi?id=1525707</a>

These are parallel-installable to the enchant-1.x packages.

Happy to review in exhange.

Sandro

Review requests: mingw-vulkan, mingw-uriparser, mingw-libkml, mingw-djvulibre

Hi

I've got four mingw packages up for review:

- mingw-vulkan: <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1507606" title="https://bugzilla.redhat.com/show_bug.cgi?id=1507606">https://bugzilla.redhat.com/show_bug.cgi?id=1507606</a>

- mingw-uriparser: <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1507604" title="https://bugzilla.redhat.com/show_bug.cgi?id=1507604">https://bugzilla.redhat.com/show_bug.cgi?id=1507604</a>

- mingw-libkml: <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1507605" title="https://bugzilla.redhat.com/show_bug.cgi?id=1507605">https://bugzilla.redhat.com/show_bug.cgi?id=1507605</a>

- mingw-djvulibre: <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1507603" title="https://bugzilla.redhat.com/show_bug.cgi?id=1507603">https://bugzilla.redhat.com/show_bug.cgi?id=1507603</a>

Happy to review in exchange.

Sandro

BuildError: src.fedoraproject.org:/git/rpms/mingw-gdal is not in the list of allowed SCMs

Hi

Any ideas about this one?

$ fedpkg build
Building mingw-gdal-2.2.2-3.fc28 for rawhide
Created task: 22673795
Task info: <a href="https://koji.fedoraproject.org/koji/taskinfo?taskID=22673795" title="https://koji.fedoraproject.org/koji/taskinfo?taskID=22673795">https://koji.fedoraproject.org/koji/taskinfo?taskID=22673795</a>
Watching tasks (this may be safely interrupted)...
22673795 build (rawhide,
/git/rpms/mingw-gdal:41a1d0cf030714b5728c02968c6309260ee935ce): open
(buildvm-armv7-13.arm.fedoraproject.org)
  22673796 buildSRPMFromSCM
(/git/rpms/mingw-gdal:41a1d0cf030714b5728c02968c6309260ee935ce): free
22673795 build (rawhide,
/git/rpms/mingw-gdal:41a1d0cf030714b5728c02968c6309260ee935ce): open
(buildvm-armv7-13.arm.fedorapr

koji: Get all completed builds since a specific date?

Hi

Is there a way to query koji for all completed builds since a specific date?

Thanks
Sandro

Build weirdness

Hi

I've got another weird situation: I wanted to get pjproject building
again, rebased and added necessary patches, did the scratch build, and
all looked good [1]. So I went ahead and committed the result, fired off
the build, but to my surprise that build failed while applying the
patches [2].

Mysterious build, perhaps tagged to wrong release?

Hi

I've got an odd situation with mingw-qt5-qtbase on f26: in git, I have
version 5.7.1, however there is a mingw-qt5-qtbase-5.8.0-3.fc26 in koji
[2] which I cannot understand where it came from, considering also that
other 5.7.1-x versions have been built since. I'm now in the situation
where I cannot push an update [3] to stable since

"Cannot submit mingw-qt5-qtbase ('0', '5.7.1', '5.fc26') to stable since
it is older than ('0', '5.8.0', '3.fc26')"

The update was however successfully pushed to testing a couple of days ago.

Any idea what's going on?

mingw-find-debuginfo.sh: objcopy strip-unneeded vs strip-debug?

Hi

I'm investigating why gdb returns so unreliable backtraces for mingw
binaries without debuginfos, and noticed a big improvement if I change
strip-unneeded to strip-debug in mingw-find-debuginfo.sh. Currently,
mingw-find-debuginfo.sh does the following:

mingw-objcopy --only-keep-debug "$binary" "$binary.debug"
mingw-objcopy --add-gnu-debuglink=$(basename "$binary.debug")
--strip-unneeded "$binary"

For a trivial test application (see bottom of email), with
strip-unneeded and no debug symbols, gdb reports:

#0 0x000000000040157d in ?? ()
#1 0x00000000004015b5 in ??

alglib soname bump

Hi

I'm updating to alglib-3.12.0 in rawhide and F27, I'll rebuild the
following dependent packages:

gmsh-3.0.4-1.fc27.src.rpm
qmapshack-1.9.0-1.fc27.src.rpm

Sandro

Review requests: perl-Regexp-Pattern, perl-Regexp-Pattern-License

Hi

I needs these simple perl packages reviewed to fix broken dependencies
introduced in licensecheck-3.0.31 (the reason it actually built
successfully was that licensecheck-3.0.30 actually provided
perl(Regexp::Pattern::License), fact which I missed, but now 3.0.31
can't be installed since it needs 3.0.30 to satisfy the dependencies...):

<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1482893" title="https://bugzilla.redhat.com/show_bug.cgi?id=1482893">https://bugzilla.redhat.com/show_bug.cgi?id=1482893</a>

<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1482894" title="https://bugzilla.redhat.com/show_bug.cgi?id=1482894">https://bugzilla.redhat.com/show_bug.cgi?id=1482894</a>

Happy to review in exchange.

Sandro

openjpeg-2.2.0

Hi

openjpeg-2.2.0 was just release, carrying a large number of security
fixes. I'd also like to update it for F25 and F26, since it is ABI and
API compatible with 2.1.x, there is however the problem that openjpeg2
installs its headers under /usr/include/openjpeg-$major.$minor, so this
would mean that the location of headers changes, potentially leading to
compilation failures in the unlikely event users have hardcoded the path
to said headers (instead of using the pkgconfig file).

Debuginfo/debugsource: mingw package with mixed host and target debuginfos

Hi

mingw-qt5-qtbase and mingw-qt5-qttools are currently FTBFS [1] due to
errors like

error: Could not open %files file /builddir/build/BUILD/qtbase-opensource-src-5.9.1/debugsourcefiles.list: No such file or directory
Duplicate build-ids /builddir/build/BUILDROOT/mingw-qt5-qtbase-5.9.1-4.fc27.x86_64/usr/i686-w64-mingw32/lib/libQt5Bootstrap.so.5.9.1 and /builddir/build/BUILDROOT/mingw-qt5-qtbase-5.9.1-4.fc27.x86_64/usr/x86_64-w64-mingw32/lib/libQt5Bootstrap.so.5.9.1
Duplicate build-ids /builddir/build/BUILDROOT/mingw-qt5-qtbase-5.9.1-4.fc27.x86_64/usr/i686-w64-mingw32/lib/libQt5Boo

Review swap: qbs - Cross platform build tool

Hi

Upstream notified me that the way qbs is currently packaged (as part of
qt-creator) is wrong, and that it should live in a separate package with
the correct version (instead of using the qt-creator version). The
review request for the split-off qbs package is here:

<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1475483" title="https://bugzilla.redhat.com/show_bug.cgi?id=1475483">https://bugzilla.redhat.com/show_bug.cgi?id=1475483</a>

Happy to review in exchange.

Thanks
Sandro

Review request: mingw-pcre2 - MinGW Windows pcre2 library

Hi

I need mingw-pcre2 to update mingw-qt5-* to 5.9.0. Review request is here:

<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1461368" title="https://bugzilla.redhat.com/show_bug.cgi?id=1461368">https://bugzilla.redhat.com/show_bug.cgi?id=1461368</a>

Happy to review in exchange.

Thanks
Sandro

Updates not getting pushed to stable

Hi,

I've got a couple of updates which are stuck waiting to get pushed to
stable:

<a href="https://bodhi.fedoraproject.org/updates/FEDORA-2017-e46ec0bbe8" title="https://bodhi.fedoraproject.org/updates/FEDORA-2017-e46ec0bbe8">https://bodhi.fedoraproject.org/updates/FEDORA-2017-e46ec0bbe8</a>
<a href="https://bodhi.fedoraproject.org/updates/FEDORA-2017-19c1569283" title="https://bodhi.fedoraproject.org/updates/FEDORA-2017-19c1569283">https://bodhi.fedoraproject.org/updates/FEDORA-2017-19c1569283</a>
<a href="https://bodhi.fedoraproject.org/updates/FEDORA-2017-192daab41c" title="https://bodhi.fedoraproject.org/updates/FEDORA-2017-192daab41c">https://bodhi.fedoraproject.org/updates/FEDORA-2017-192daab41c</a>

The last two I tried unpushing and repushing to see whether it would
unlock them, so far that does not seem to be the case.

Looks like they are isolated cases, various updates before and after
that have been successfully pushed to stable.

Anyone with a magic wand to get those updates to stable or ideas what's
wrong?

Koji build failure: OverflowError: long int exceeds XML-RPC limits

Hi

I've tried a couple of times to build mingw-qt5-qtquick1 [1], but the
task consistently fails after the actual build succeded [2], seemingly
when moving the rpms or tagging the build, with the following message:

Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/koji/daemon.py", line 1160, in
runTask
response = (handler.run(),)
File "/usr/lib/python2.7/site-packages/koji/tasks.py", line 158, in run
return koji.util.call_with_argcheck(self.handler, self.params,
self.opts)
File "/usr/lib/python2.7/site-packages/koji/util.py", line 156, in
call

Package with spec name != packagename.spec

Hi

I just came across a package (mingw-qt5-qtquickcontrols) whose specfile
isn't named <packagename>.spec (in this case, mingw-qtquickcontrols.spec
instead of mingw-qt5-qtquickcontrols.spec).

As I understand it this is against the guildelines? (Shouldn't the build
actually fail?)

Can I just fix it by renaming the spec file or do I need to take other
precautions?

Thanks
Sandro

ActionNotAllowed: policy violation (build_from_srpm)

Hi

Anyone an idea what's going on here?

$ fedpkg build
Building mingw-eigen3-3.3.3-1.fc26 for rawhide
Created task: 17994713
Task info: <a href="https://koji.fedoraproject.org/koji/taskinfo?taskID=17994713" title="https://koji.fedoraproject.org/koji/taskinfo?taskID=17994713">https://koji.fedoraproject.org/koji/taskinfo?taskID=17994713</a>
Watching tasks (this may be safely interrupted)...
17994713 build (rawhide,
/git/rpms/mingw-eigen3:e85524ace76e2d184ef7be04a8b9db7752099dbf): free
17994713 build (rawhide,
/git/rpms/mingw-eigen3:e85524ace76e2d184ef7be04a8b9db7752099dbf): free
-> open (buildhw-04.phx2.fedoraproject.org)
17994713 build (rawhide,
/git/rpms/mingw-eigen3:e85524ace76e2d184ef7be04a8b9db7752099dbf): open
(buildhw-04.p

BuildRequire debuginfo for debugging?

Hi

I'm trying to gather a good stacktrace of a qbs crash on
aarch64/ppc64/ppc64le and I managed to collect something by prepending

gdb -batch -ex "run" -ex "bt full" --args

to the qbs calls.

Dependency rebuild order

Hi

Wondering if someone has some neat script which outputs the rebuild
order of a set of packages, say after a library these depend on bumped
its soname.

Thanks
Sandro

HEADS UP: libwebp-0.6.0 soname bumps

Hi

I'm about to fire off the libwebp and mingw-libwebp 0.6.0 updates, which
include soname bumps.

I'm rebuilding all of the dependent packages:

darktable-2.2.2-1.fc26.src.rpm
efl-1.18.4-2.fc26.src.rpm
freeimage-3.17.0-8.fc26.src.rpm
gd-2.2.4-1.fc26.src.rpm
gdal-2.1.2-6.fc26.src.rpm
gegl03-0.3.10-1.fc26.src.rpm
gnuplot-5.0.5-1.fc26.src.rpm
grads-2.0.2-20.fc26.src.rpm
GraphicsMagick-1.3.25-2.fc26.src.rpm
gstreamer1-plugins-bad-free-1.11.1-1.fc26.src.rpm
gthumb-3.4.4.1-2.fc26.src.rpm
guacamole-server-0.9.9-2.fc26.src.rpm
ImageMagick-6.9.3.0-3.fc25.src.rpm
kde-runtime-16.12.1-1.fc26.src.rpm
le

Updates in testing for EOL releases stuck forever in Bodhi?

Hi

Just wondering: is there any way to get rid of the entries of updates
stuck in testing for EOL releases in
bodhi.fedoraproject.org/updates/?user=<user>&status=testing ?

Thanks
Sandro

Orphaning python-sphinx-theme-better

Hi

I've orphaned python-sphinx-theme-better. It was briefly used by
python-pillow for its documentation in the past, but that's not the case
anymore and python-sphinx-theme-better hasn't seen any activity upstream
since 2013.