DevHeads.net

Postings by Pavel Raiskup

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="https://github.com/praiskup/systemd-container" title="https://github.com/praiskup/systemd-container">https://github.com/praiskup/systemd-container</a>

Pavel

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="https://fedoraproject.org/w/index.php?title=Talk:SELinux_Policy_Modules_Packaging_Draft" title="https://fedoraproject.org/w/index.php?title=Talk:SELinux_Policy_Modules_Packaging_Draft">https://fedoraproject.org/w/index.php?title=Talk:SELinux_Policy_Modules_...</a>

Thanks,
Pavel

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="https://koji.fedoraproject.org/koji/taskinfo?taskID=19065513" title="https://koji.fedoraproject.org/koji/taskinfo?taskID=19065513">https://koji.fedoraproject.org/koji/taskinfo?taskID=19065513</a>

Pavel

$ 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 'libarchive.so.13.2.2'===============

Package 'xdelta' was relicensed from GPLv2 to ASL 2.0

SSIA, per release notes on <a href="http://xdelta.org/" title="http://xdelta.org/">http://xdelta.org/</a>

Pavel

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="https://koji.fedoraproject.org/koji/taskinfo?taskID=16970779" title="https://koji.fedoraproject.org/koji/taskinfo?taskID=16970779">https://koji.fedoraproject.org/koji/taskinfo?taskID=16970779</a>

Thanks,
Pavel

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

Hi all,

JFYI, for <a href="https://bugzilla.redhat.com/1405433" title="https://bugzilla.redhat.com/1405433">https://bugzilla.redhat.com/1405433</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).

Pavel

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
/usr/libexec/libfoohelper).

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="https://bugzilla.redhat.com/show_bug.cgi?id=1381790" title="https://bugzilla.redhat.com/show_bug.cgi?id=1381790">https://bugzilla.redhat.com/show_bug.cgi?id=1381790</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?

Pavel

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 \
--repofrompath=hell,http://ftp.fi.muni.cz/pub/linux/fedora/linux/development/rawhide/Everything/x86_64/os/
--whatrequires 'postgresql-server(:MODULE*'
orafce-0:3.3.0-1.fc26.x86_64
pg-semver-0:0.5.0-5.fc24.x86_64
pgRouting-0:2.2.3-4.fc26.x86_64
pg_journal-0:0.2.0-12.fc25.x

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="https://bugzilla.redhat.com/show_bug.cgi?id=1286193" title="https://bugzilla.redhat.com/show_bug.cgi?id=1286193">https://bugzilla.redhat.com/show_bug.cgi?id=1286193</a>
[2] <a href="https://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks" title="https://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks">https://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks</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
install'.

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="http://osdir.com/ml/libtool-gnu/2014-10/msg00011.html" title="http://osdir.com/ml/libtool-gnu/2014-10/msg00011.html">http://osdir.com/ml/libtool-gnu/2014-10/msg00011.html</a>
[

Failing tests on Fedora

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

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)

Pavel

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
reporter).

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="http://ftp.postgresql.org/pub/odbc/versions/src/psqlodbc-09.02.0100.tar.gz" title="http://ftp.postgresql.org/pub/odbc/versions/src/psqlodbc-09.02.0100.tar.gz">http://ftp.postgresql.org/pub/odbc/versions/src/psqlodbc-09.02.0100.tar.gz</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/psqlodbcw.so > /dev/null
undefined symbol: PQconnectdbParams (./.libs/psqlodbcw.so)

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

* Makefile.am: 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
completely.
diff --git a/Makefile.am b/Makefile.am
index dfd36ab..f9820a4 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -32,7 +32,7 @@ psqlodbca_la_SOURCES = \
descriptor.h dlg_specific.h enviro

use inet_pton() instead of inet_addr() for ipv4/6

Hi, our regular package checking discovered that in postgresql-odbc is
using inet_addr() call (which is not ipv6 compliant). I tried to look at
it and it was used just for parsing of ipv4 addresses. It is not a big
deal (the worst thing what can happen is that ipv6 addresses will cost a
little bit more time to be resolved).

Better solution would be imo to use inet_pton() call for both ipv4 and
ipv6 address families. Patch is attached, any comment is welcome!

Pavel

Is the linking with -lodbc necessary? (--with-odbc)

Hello all!

Long story short: Is there a need to link psqlodbcw.so plugin against
libodbc.so?

Rebase of automake-1.13.4 to automake 1.14

Hello all, I would like to inform you that I plan to realize ${Subject}
during Thursday & Friday (#976973), if there are no objections.

Even if it does not seem to be, it is just a minor version update, see
NEWS file in tarball (new versioning scheme).

To sum actual changes up for distro POV: no obvious change which may break
building packages was done, _yet_, but some new warnings (related to future
breakage in automake 2.0) were added, so please don't ignore them.

Testing package:
<a href="http://koji.fedoraproject.org/koji/taskinfo?taskID=6040826" title="http://koji.fedoraproject.org/koji/taskinfo?taskID=6040826">http://koji.fedoraproject.org/koji/taskinfo?taskID=6040826</a>

Pavel

Retiring packages automake1{4,7} _heads up_

Same as automake15 & automake16 are, I would like to make automake{14,17}
retired. I'll do so probably during the next week, if there are no
objections (and once the already filled bugs against dependant packages
gets resolved).

Pavel