Postings by Kaleb S. KEITHLEY

enabling KCM in the Fedora kernels


How would one go about requesting this be enabled by default?

Upstream NFS-Ganesha devs have been playing with it a bit and got a
modest performance boost.

It's conceivable that GlusterFS could utilize it too.


build failed on s390x, other archs building okay

Is this a spurious failure or ???

Task info: <a href="" title=""></a>
buildArch (glusterfs-4.1.2-1.fc29.1.src.rpm, s390x): free -> FAILED:
Fault: <Fault 1: 'Traceback (most recent call last):\n File
"/usr/lib/python2.7/site-packages/koji/", line 1244, in
runTask\n response = (,)\n File
"/usr/lib/python2.7/site-packages/koji/", line 307, in run\n
return koji.util.call_with_argcheck(self.handler, self.params,
self.opts)\n File "/usr/lib/python2.7/site-packages/koji/", line
209, in call_with_argcheck\n retu

release-monitoring is telling me it has noticed (new) ceph-13.0.x

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

But the Homepage: in the above and the Source: in the .spec would seem
to be saying that <a href="" title=""></a> is where
the-new-hotness is looking.

And there is no ceph-13.x.y tar at that location (yet).

It's a maze of twisty passages. Or maybe at's a twisty maze of passages.
How do I find where release-monitoring is actually looking?


'endless' stream of "greenwave is a GO on glusterfs-4.0.0-2...." emails

I've rec'd about 30 of these in the last hour or so, fedora-28,
fedora-27, fedora-26, and fedora-28-modular.

Would someone please make them stop


f28 and rawhide ignoring static ip settings

Did I miss something?

Both machines were dnf system-upgraded from f27. Static IP settings were
set at f27 install time and worked before the respective upgrades.

f28 was working correctly until a couple of days ago to the best of my


%cat /etc/sysconfig/network-scripts/ifcfg-ens3

But it's getting (from dhcp?)


why do I keep getting Broken dependencies: nfs-ganesha emails

On x86_64:
nfs-ganesha-2.6.0-0.4rc5.fc28.x86_64 requires

I have long since built the GA packages: nfs-ganesha-2.6.0-1 in f28 and
even nfs-ganesha-2.6.0-2 because I didn't notice that this was whining
about -0.4rc5.

Is something stuck somewhere that it is complaining about this obsolete

glusterfs in Fedora Modular 27?

I've been contacted by Fedora QE about this, and have bz
<a href="" title=""></a>

I haven't followed (can't follow) Fedora closely enough to know what's
needed here. Apparently none of my co-maintainers have either. ;-)

glusterfs packages are built for f27.

Reading through -devel it kinda looks like there was a branch created. A
branch that I should be doing builds on. But I have no branch in the
glusterfs dist-git other than the usual f26, f27, master that I could do
a build on.

Would someone hit me with a cluebat please?

sysconf(_SC_IOV_MAX) returns -1 in f27 and f28/rawhide (glibc-2.26-8)

perusing the glibc source and headers it seems to come down to the
#undef __IOV_MAX
line in bits/uio_lim.h.

The Changelog (2017-06-14) speaks rather obliquely to the issue, but I
can't quite figure out if


now returning -1 (errno = 0) is an unintentional side effect of the
changes or not. (I don't follow glibc development to know what the
history is behind this change.) In f26, glibc-2.25-10 it returns 1024.
Off hand I don't see any way that glibc could be built now to make the
call return anything but -1.

Anyone know more of the story?

rdma -devel packages missing (?) on f27/armv7hl, builds failing

I've built glusterfs previously on F27 with these same Build-Requires.
Same package & same .spec build on F28 and F26.

While trying to build a new version for the last 24 hours I keep hitting

DEBUG No matching package to install: 'libibverbs-devel'
DEBUG No matching package to install: 'librdmacm-devel >=

Thanks,, deltarpm-3.6.{21,22} and building ceph on rawhide

After a successful scratch build[1] on fc27/i686 of ceph-2.1.2-2 to test
a fix for a 32-bit issue I immediately fired off a full fedpkg build,
which failed thusly [2]:

DEBUG Error: nothing provides needed
by deltarpm-3.6-22.fc27.x86_64
DEBUG (try to add '--allowerasing' to command line to
replace conflicting packages)

the scratch build had rpm- and deltarpm-3.6-21.fc27

The fedpkg builds got rpm-4.13.90-0.git14002.1.fc27 and
deltarpm-3.6-22.fc27 (x86_64 at least, I didn't look at the others)

Did I just catch thin

armv7hl builds running out of memory

trying to build ceph-12 on f27 armv7hl.

It builds on everything x86_64, aarch64, s390x, and i686 (w/o java), but
on armv7hl the build fails, reporting out of memory.

[100%] Built target ceph-osd
cc1plus: out of memory allocating 11284160 bytes after a total of
58859520 bytes
make[2]: *** [src/CMakeFiles/ceph-dencoder.dir/build.make:64:
src/CMakeFiles/ceph-dencoder.dir/test/encoding/] Error 1
make[1]: *** [CMakeFiles/Makefile2:1626:
src/CMakeFiles/ceph-dencoder.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

full log at
<a href="https://kojipkgs.fedoraproject" title="https://kojipkgs.fedoraproject">https://kojipkgs.fedoraproject</a>.

Do I need to do a Self Contained Change to update Ceph to Ceph 12 in fedora-27?

The current version is quite old (10.2.7) and I believe that may have
been built before f27/rawhide was updated to gcc-7.

10.2.8, 10.2.9, and 11.x.y do not build due to internal compiler errors.

12.1.1 does build at this time [1].

I am the package owner.


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

fedpkg update is failing

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

Reader's Digest version: Could not execute update: Could not generate
update request: Command 'bodhi --bodhi-url
<a href="" title=""></a> --new --release f26 --file
bodhi.template libntirpc-1.4.4-1.fc26 --username kkeithle' returned
non-zero exit status 255

This is on up to date f25.

I am authenticated with kinit <a href="mailto: ... at FEDORAPROJECT dot ORG"> ... at FEDORAPROJECT dot ORG</a>

Any ideas?


Is there something wrong with the Koji builders?

I've done two builds for rawhide this morning.

On the first the armv7hl and ppc64le builds failed because the source
tar file could not be unpacked.

On the second the aarch64 build failed because the source tar file could
not be unpacked.

All the other arches built successfully.

two package reviews


I have two packages up for review that could use some attention please:

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


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


rawhide vs koji f26 builds


I have a glusterfs-3.7.16 scratch build that's failing in koji f26 builds

<a href=";name=build.log&amp;offset=-4000" title=";name=build.log&amp;offset=-4000">;name=build.l...</a>

Yesterday (11 October) I downloaded and installed the current rawhide
and built — successfully — from the same src.rpm that's failing in koji.

I tried again today and the koji f26 build is still failing.

The koji f26 build of the previous release of glusterfs (3.7.15,
containing the same code) built fine approx five weeks ago.

What's the recommend action here, just wait a few days? Or something else?


nfs-ganesha -stable request stalled


Would someone please give the nfs-ganesha-2.4.0-0.8dev21.fc24 a kick?

I've had two other updates pushed to -stable since, and they've gone
through. Been waiting ~4 days now.

Status page says the update is locked and can't be modified, but I don't
know why.


autoconf test for deprecated readdir_r


Does anyone have a good/working autoconf test for checking for
deprecated readdir_r (for Fedora 25) ?

I'm not having much luck. (Have tried AC_COMPILE_IFELSE, among other

Alternatively it would be nice if there was a some kind of feature test
define in dirent.h.


three questions: f24 branch, python3 default, where to put /etc/rsyslog.d/gluster.conf.example


1) usually after the branch I build new packages for rawhide (i.e.
$branch+1). But atm in the master branch, a `fedpkg build` gives me

Could not execute build: Package glusterfs-3.7.8-1.fc24 has already
been built

Am I just too early?

can't submit updates for f22?

I must have missed some announcement?

Submitting from an up to date f22 box I get:

% fedpkg update
/usr/lib/python2.7/site-packages/fedpkg/ DeprecationWarning:
Commands._hash_file is deprecated and will be removed eventually.
Please use Commands.lookasidecache.hash_file instead.
hash = self.cmd._hash_file('bodhi.template', 'sha1')
Creating a new update for glusterfs-3.6.5-1.fc22
Password for kkeithle:
Creating a new update for glusterfs-3.6.5-1.fc22
ServerError(<a href="" title=""></a>, 404, Not Found)
Traceback (most recent call last):
File "/usr

something wrong with f22 fedpkg builds on i686 of nfs-ganesha?

I previously did a fedpkg build of nfs-ganesha-2.2.0-1 for f22 on

Review, or review swap?

libntirpc. It's currently bundled in nfs-ganesha with a bundling
exception through Fedora 23, but it's ready now.

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


over-riding an autodep for a sharedlib?

the samba.spec has:

%package vfs-glusterfs
Requires: glusterfs-api >=
Requires: glusterfs >=

The samba-vfs-glusterfs has these Requires (rpm -q --requires
glusterfs-api >=
glusterfs >=

Coming soon the libgfapi shlib will get bumped to for
various reasons I won't go into.

.spec file Source0 magic for github release source tarballs?

Take, for example, <a href="" title=""></a>,
where there's a button for "Source code (tar.gz)" pointing at
<a href="" title=""></a>

Note V2.0.0.tar.gz versus nfs-ganesha-2.0.0.tar.gz.

If I click on that link the downloaded file is named
nfs-ganesha-2.0.0.tar.gz by virtue of the Content-Disposition http header.

Likewise if I use `curl -L ...` the downloaded file is named

But for my nfs-ganesha.spec file, if I use the github link shown above,
I have to load a file V2.0.0.tar.gz into the look-asi

package foo is blocked for tag dist-6E-epel-testing-candidate

I unretired the el6 branch and took ownership for a package I maintain.

Now I'm getting the $subject build error when I do a fedpkg build.
Scratch builds are successful.

Is there some built-in delay between unretiring before I can do builds
or is there another step I've missed (and don't find any mention of.)


review swap — nfs-ganesha

nfs-ganesha is a user-mode NFS v4 server. GlusterFS will use nfs-ganesha
for it's NFSv4 implementation.

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

how to withdraw glusterfs from epel?

Before too much longer I will need to withdraw the glusterfs.
(glusterfs-3.2.7 fwiw, very out of date, this version is a Requires for
another package, HekaFS.)

Withdrawal becomes necessary when RHEL starts to ship a subset of the
glusterfs packages.

But instead of withdrawing it, what if I were to alter it to simply
install /etc/yum.repos.d/community-glusterfs.repo file?

BUG 1003089 - Review Request: glusterfs-openstack-swift

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

This is a/the stand-alone replacement RPM for the glusterfs-ufo
subpackage and the fix for the broken deps in glusterfs in f20 and rawhide.

I personally would like to get this wrapped up so that glusterfs doesn't
have broken deps in f20 final.


f20 systemd rpm isn't signed!


I have just tried to do a `yum --releasever=20 distro-sync` (of an f19
box) and it aborts with the error that the systemd rpm isn't signed.

(Yes, I know I can use --nogpgcheck to get around the problem.)

promoting to package co-maintainers?


On 7 Aug I opened a trac ticket to request that two colleagues be
promoted to the packager group so that I can grant them the commit ACL
for the glusterfs package. They both work full time on GlusterFS.

I have not heard anything in response to the trac ticket and I'm curious
about what the normal amount of time is for action a ticket like this.