Postings by Kaleb S. KEITHLEY, 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.


systemd question

I need glusterd to start before any _netdev mounts (NFS or glusterfs)
take place.

reading the system.special man page it talks about ...pulling in and order themselves after it.

Would adding a to the glusterd.service be
the right thing to do or is there a better solution? (It already has rpcbind.service)


-devel rpm question

When adding a new sub-package, what's the convention or rule regarding
the associated -devel?

E.g. for glusterfs, with its associated glusterfs-devel; when adding
glusterfs-api containing a new library, should the .so link and header
be in glusterfs-api-devel, or can they be in the glusterfs-devel rpm?

It (obviously) occurs to me that having glusterfs-devel install the .so
link and header file for a library that may not be installed would
probably be frowned upon.

(Yes, I've read
<a href="" title=""></a>)


taking over ownership of glusterfs

Matthias Saou has released ownership so that I can take over.

<a href="" title=""></a> indicates that
I can use the <a href="" title=""></a> to request ownership
changes, but I don't see any way to do this. Am I not looking in the
right place?

It also indicates that I can open an Admin request to make the change.
My google fu is failing me here too. Where do I do that?

In the mean time I've appended a Package Change Request to
<a href="" title=""></a> and set the
fedora-cvs=? flag.

no audit2allow in f18

SELinux Alert Browser tells me to:

grep plugin-containe /var/log/audit/audit.log | audit2allow -M mypol

I have policycoreutils-python installed, but there's no
/usr/bin/audit2allow in it (as there was in F17).

glusterfs rename

What hoops do I have to jump through, approvals, etc., do I need to
respin glusterfs rpms as glusterfs32 (for 3.2.6, and soon 3.2.7), and
the imminent glusterfs-3.3.0, which would be glusterfs33.

I.e. what is currently glusterfs-3.2.6-2.{fc16,fc17,el6} would become
glusterfs32-3.2.6-x.{fc16,fc17,el6}, etc. x would be what, 1? 2?

license in rpm spec file for dual license?

GlusterFS-3.3.0, which is to GA soon, has had (another) license change.
Much of it now under a dual license: GPLv2 or LGPLv3+, with a small
number of pieces still remain under GPLv3+.

What is the correct way to represent this in the spec file?

What are the rules for updating a package?

Red Hat (nee Gluster) is about to release glusterfs-3.2.6. It's a bugfix
release. No API/ABI changes (in theory, I haven't done an exhaustive check.)

In f16 we released 3.2.5. Am I allowed to update it in f16 to 3.2.6?

In f17alpha we also have 3.2.5. Am I allowed to update that at this
point in time or is it too late?



epel 6 fedpkg build or koji scratch builds failing — I'm stumped

I can build glusterfs fine on real RHEL6.1 using rpmbuild, both x86_64
and i686 with `rpmbuild -bb ...` and `rpmbuild -bb --target=i686 ...`

I can also build using mock, both x86_64 and i386, with `mock -r
epel-6-x86_64 --rebuild ...` and mock -r epel-6-i386 --rebuild ...`

In all the above cases I get all the expected RPMs and the build.log
shows no errors.

But when I do a `fedpkg build` or a `koji --scratch ...` in the el6
branch of my fedora-scm tree the builds fall down with an error
compiling a file.

openssh-server in F16ga

IIRC in f16alpha and f16beta with openssh-server installed, sshd was
enabled and run.

I installed f16ga in several vm guests yesterday and even though
openssh-server was installed, it was both not enabled and therefor not
run when the install finished and after a reboot.

It's possible that I forgot that I had to do a systemctl enable sshd and
systemctl run sshd on my f16alpha and f16beta guests, but since I've
only just learned about systemctl I tend to think I would have
remembered needing to do that?

Is not enabling and running sshd intentional?