Postings by Pavel Raiskup

copr builders moved to F31, with more builders

Hey all,

Jakub recently finished movement of copr builders from Fedora 30 to Fedora
F31. At this moment we are not aware of any serious issues related to
this change, but please let us know if you noticed anything.

With a great help of fedora infra (Kevin) we were able to add a new set of
builders for x86_64 architecture, so the build queue processing should be
faster now. Also, the new machines should be a bit faster (while we still
keep the old machines), so please be prepared that the x86_64 builder set
is not that homogeneous as before.

epel-8-{x86_64,ppc64le,aarch64} chroots enabled in copr

CentOS 8 repositories are now available, so @msuchy released new
`mock-core-configs` (see updates-testing), and so we were allowed to enable
epel-8 chroots in Copr! Feel free to build against them.

Note that it doesn't make sense to support `rhelbeta-8-*` chroots anymore,
so we plan to disable them after in 14 days. Please stop using them.

Also note that so far 'dnf copr enable <user>/<project>' command executed
on RHEL 8 box actually enabled the `rhelbeta-8-$basearch` repository.

copr's ppc64le builders fail to start

Hi all,

for some reason (not yet known, tracked in fedora infra [1]) ppc64le
builders fail to spawn, and what is even worse this issue also affects x86
builders. So because of this, we temporarily disabled ppc64le
architecture in copr.

Copr builders moved to Fedora 30, added AARCH64 support

Hello, fyi,

Fedora Copr builders were recently upgraded to Fedora 30 (from F28).

The major change is that `yum` package is not working ideally on F30
anymore, and soon (on F31) there will be no `yum` at all [1].

Mock (which is used on builders) though uses /usr/bin/yum-deprecated (yum)
by default for epel* chroots installation usually (on Fedora host), even
though it may use /usr/bin/yum symlink to /usr/bin/dnf as a fallback.

The major difference from mock perspective (and why yum-deprecated is
actually preferred, when available) is that dnf might calculate the
install transactions a littl

How to avoid re-generating Pagure API keys all the time?

From time to time I have to submit a ticket with 'fedpkg request-repo' or
'fedpkg request-branch', and I have feeling that I have to regenerate the API
key very often (since 2018-02-17 I have 5th key already?!).

How do you work-around this requirement to re-generate the key all the

Intent to split 'postgresql.spec' into 'libpq.spec' and 'libecpg.spec'

Hi all,

ad [1] tracker - it's a good time to warn about this (rather
non-intrusive, I believe) change in PostgreSQL packaging in Fedora,
expected to happen in F30.

We'd like to provide alternative versions of PostgreSQL servers in
Fedora's modular repo, but still - it is very much desirable to have only
one version of in Fedora (and build all the PostgreSQL server
versions against that one client library).

So we plan to cut soname into separate specfile, dedicated package
(and ditto for*, and friends).

From packaging POV (of ~120 packages that depend on eithe

follow Fedora branching by default?

Hi, there was an idea to turn on the "Follow Fedora branching" feature in Copr
by default (for newly created copr projects).

Plan to orphan 'plv8' package -- V8 Engine for PostgreSQL

Fedora's v8/v8-devel were updated (F28) and the environment is now
incompatible with F28's (already built) plv8.

Honestly, I plan to orphan the package because v8 environment is probably
only supposed to be bundled, and I'm not ready to take the responsibility
for bundling that huge thing...

config.sub ppc64p7 optimization

Hi all,

I have 'perl -pi -e "s/ppc64-\*/ppc64-\* \| ppc64p7-\*/" config.sub' hack in
%prep in some of my packages; without reference to any bug nor upstream
issue. My plan is to drop that hacks - especially in automake.spec which
transitively poisons all 'make dist' tarballs generated on Fedora boxes. The
proper way to do this is IMO:

- propose config.sub change upstream (gnuconfig)

- if any downstream fix is still needed, we should fix 'config.sub' in
redhat-rpm-config - that way any package using %configure automatically
replaces config.sub with fedora friendly version.

systemd in non-privileged container

Hi all,

just wanted to let you know about trivial experiment [1] with systemd in
container. Non-privileged systemd can now pretty fine run in docker
container (tested on Fedora 27 box).

Could we support this under fedora-kickstarts, or as a layered image?

[1] <a href="" title=""></a>


SELinux Policy Modules Packaging Draft

Hi all, any plan to ratify the Draft? [1]

I'm thinking whether it is good time already to add '*-selinux' subpackage
to generally selinux-covered services (by selinux-policy-targeted), like
e.g. 'httpd' or 'postgresql-server'.

Any experiences?

[1] <a href="" title=""></a>


libarchive 3.3.1 into Rawhide

JFYI, there's no soname bump, no ABI removed (only private symbols) - so no rush
is expected; I'm building the package into Rawhide right now:

<a href="" title=""></a>


$ abipkgdiff /tmp/result-old/libarchive-3.2.2-3.fc27.x86_64.rpm \
/tmp/result-new/libarchive-3.3.1-1.fc27.x86_64.rpm \
--debug-info-pkg1 /tmp/result-old/libarchive-debuginfo-3.2.2-3.fc27.x86_64.rpm \
--debug-info-pkg2 /tmp/result-new/libarchive-debuginfo-3.3.1-1.fc27.x86_64.rpm
================ changes of ''===============

Package 'xdelta' was relicensed from GPLv2 to ASL 2.0

SSIA, per release notes on <a href="" title=""></a>


Ongoing zlib 1.2.11 rebase in Rawhide

Hi all,

I'll build new zlib in Rawhide very soon, testing packages are in [1] and the
commits are in [2]. Abipkgdiff output is in related bug report [3].

There's no soname bump, and it seems to be clean update. So no mass rebulid or
breakage is expected, but let's keep you informed. Any review is welcome.

Koji builders' specs

Hi all,

where is documented what system/hw is used on (primary) Koji builders?
I'm interested in memory, storage, filesystem, host operating system, guest
operating system (if those are VMs), etc.

The only thing I was able to find is version of mock in the log output.

FWIW, I'd like to reproduce hang in gnulib's test-lock [1] test case.
Unless I'm able to reproduce that somehow, I'll disable the test for the time
being (done in 'coreutils' and I guess elsewhere, too).

[1] <a href="" title=""></a>


gettext: 'msghack' moved to 'msghack' sub-papackage

Hi all,

JFYI, for <a href="" title=""></a> purpose, we're moving
'/bin/msghack' script into 'msghack' package (and most probably, it is going to
be dropped in future). In case anybody used '/bin/msghack' for anything, we'd
like to hear from you (adding explicit (Build)Requires is fine too).


repoquery to get the complete set of dependencies

Consider we have package 'foo-libs' that provides set of libraries.

How do I get all dependant packages (for batch rebuild of dependencies after
package update)? Something which takes soft dependencies into account, too.

Some packages might depend on 'foo-libs' explicitly, some depend on soname
(implicitly), some depend on particular file within package (say

Is there facility within 'dnf repoquery' that gives ultimate answer?

Making package critical path, some batch update now?

I keep informed via fedora notifications that some of the packges I
maintain are hired into critical-path team... Some of those changes make
sense to me :) but for example 'less' package sounds like a mistake.

Is there a database/git which can I read now?

Copr && Rawhide -- no "rolling updates" workflow

<a href="" title=""></a>

Seems like the `fedora-rawhide-x86_64` chroot is not going to exist from
now, which is IMO unnecessary change ... but what could be other than
those "obvious" consequences for both Copr repo maintainers and users?
Does this sound like acceptable change?


PostgreSQL 9.6.0 rebase

Hi all,

there's new PostgreSQL version 9.6.0 out and we plan to build this into
Fedora Rawhide within few moments (a bit of testing remains now).

This action requires re-buliding of packages that provide binary
PostgreSQL modules, basically this is about:

$ dnf repoquery --disablerepo='*' --enablerepo hell \
--whatrequires 'postgresql-server(:MODULE*'

Hacks for multilib unclean C headers

Just wanted to ping here about one packaging helper [1], which is stuck in
some (possibly infinite/priority) queue without any review.

In database packages we have that multilib hack for a very long time,
mostly C&P'ed among various spec files. Having this in redhat-rpm-config
could make that more solid, maintained at one place.

[1] <a href="" title=""></a>
[2] <a href="" title=""></a>

It is probably possible to package this separately, so I'm ready to have a
special package for database purposes.

libarchive-3.2.0 into rawhide

Hi, this is just headsup that I'll rebase the libarchive in Rawhide today.
This should not cause breakage, no SONAME bump -- there's only one private
symbol missing (renamed, detected by abipkgdiff).

So, if there are issues, please open a bug.

Thanks, Pavel

ping: rebase to xz-5.2.0 release + xz-compat-libs removal

Hello list,

upstream (Lasse Collin), _thanks a lot_ BTW, was able to cut new xz
(stable) release 5.2.0. I rather write here to inform you about upcoming
rebase in Fedora Rawhide (tomorrow or day after) as there is quite a few
dependant packages..

There shouldn't be a need to rebuild huge amount of packages as the soname
was not bumped and the API upgrade is clean.

making the testsuite installable

Hello all.

My issue with current testsuite solution:

The testsuite requires 'root' account. Thats needed because successful run
requires PostgreSQL properly configured and running. This is hardly
achievable during package build because (e.g. in Fedora) we build packages
under non-privileged user.

Running git testsuite against distributed psqlodbc is not comfortable so
I doubt users run the testsuite. Running the testsuite automatically is
not trivial.

It would be really nice to have the testsuite installed with 'make

upcoming libtool rebase (2.4.2 ~> 2.4.3)

Libtool upstream was able to cut the new release!

I'll rebase the Rawhide package probably by the end of the next week or
so, if there are no objections.

Upstream maintainer calls this update fearless :) and that it needs a bit
of luck [1] (asking for possible downstream cooperation); however after
cutting F21 from rawhide we have probably good time for this rebase (the
update should be more like bugfix anyway).

There are some known incompatibilities; see the official announcement [2].
There is also scratch build for testing [3].

[1] <a href="" title=""></a>

Failing tests on Fedora

Hello, I started with running the testsuite recently, thanks a lot for its

There are currently 8 fails on my system (Fedora 20 x86_64), I didn't look
at all the errors carefully yet as I found in `git show a5e2002a` note
about expected failures — iirc, there is not specified what tests are
expected to fail.

Could we add one additional "EXP_FAIL" state for the testsuite to make
that clear? Or at least have a list of expected failures somewhere?
(Also instructions how to run single test would be useful in README.txt).

Attached files (regression.out, regression.diffs).

Static analysis fix request

* Attached fix for overrun. This is imo worth fixing.

* Attached added gcc & Coverity warnings (added between 9.2.1 and 9.3.1)


psqlodbc - dos line-ending in generated source tarballs

Just wanted to warn about ${SUBJECT}. I was told that the line ending in
the psqlodbc tarball [1] caused problems with some SunCC compiler (that
needed dos2unix recoding; I don't know details though, CCing original

I haven't seen this problem in git-repository; this seems to be
one-release problem - but still I am reporting upstream because it would
be worth avoiding for the next releases :).

[1] <a href="" title=""></a>

Thanks, Pavel

Problems with linking against PostgreSQL 8.4

Hi, I tried to build the latest git version of postgresql odbc driver and
(even if the build seems to be complete) there is a linkage problem:

$ ldd -r ./.libs/ > /dev/null
undefined symbol: PQconnectdbParams (./.libs/

I see that the symbol was added to PostgreSQL project in ~2010 and it
seems to be a problem. Should I expect that newer drivers are able to be
run against older (still supported by PostgreSQL community) PostgreSQL
server, namely 8.4.13?

If that ^^ is a problem, could you please fix that?

Silence GCC warnings, fix build

* Add mylog.h into dependand sources.
* convert.c (mylog): Retype sprintf() parameters.
* specific.c (getCommonDefaults): Don't check array for NULL.
* psqlodbc.c (copy_globals): Initialize the 'to' structure
diff --git a/ b/
index dfd36ab..f9820a4 100644
--- a/
+++ b/
@@ -32,7 +32,7 @@ psqlodbca_la_SOURCES = \
descriptor.h dlg_specific.h enviro