DevHeads.net

Postings by Kaleb S. KEITHLEY

Another ceph build stuck in pending testing, four days

Hi,

<a href="https://bodhi.fedoraproject.org/updates/FEDORA-2019-60ba61b5ab" title="https://bodhi.fedoraproject.org/updates/FEDORA-2019-60ba61b5ab">https://bodhi.fedoraproject.org/updates/FEDORA-2019-60ba61b5ab</a>

Why does this happen every time?

Would someone please kick it? Thanks

ceph packages submitted to testing four days ago still haven't been pushed

ceph-12.2.12 for f28 and f29.

Happens every time.

Someone please give them a kick.

Thanks.

On not bumping the epoch in ceph-14, f30 and f31/rawhide

The epoch was inadvertently bumped (not by me) when ceph was rebased to
14.x in f30/rawhide.

I reset it to 1 in subsequent builds. Now adamwill is running builds with
it bumped to 2 again.

I would prefer that it not be bumped. Ceph has their own builds (for Fedora
even I think) where they have epoch=2. I see this as a feature that lets
someone install Ceph's epoch=2 packages on a system and not risk
inadvertently updating with the Fedora Ceph packages.

Is there really no other way to get rid of the one or two "bad builds"
where epoch=2 and keep shipping epoch=1 in Fedora?

Are the s390x builders healthy?

I'm trying to build Ceph again for f31 after the branching.

It built before the branching, eight days ago.

The x86_64[1] part of number two below got further than either of the two
examples below before I killed it. I'm guessing it would have finished
successfully if I had let it. I have another running now to confirm.

But I'm getting strange errors on s390x.

One, e.g.

two Ceph updates for f28, f29, stuck in pending testing for six days

<a href="https://bodhi.fedoraproject.org/updates/FEDORA-2019-1c53f1a6c8" title="https://bodhi.fedoraproject.org/updates/FEDORA-2019-1c53f1a6c8">https://bodhi.fedoraproject.org/updates/FEDORA-2019-1c53f1a6c8</a>
<a href="https://bodhi.fedoraproject.org/updates/FEDORA-2019-6a2e72916a" title="https://bodhi.fedoraproject.org/updates/FEDORA-2019-6a2e72916a">https://bodhi.fedoraproject.org/updates/FEDORA-2019-6a2e72916a</a>

Would someone please give them a kick?

Thanks

two builds stuck in pending testing for nine days

f28: <a href="https://bodhi.fedoraproject.org/updates/FEDORA-2018-e6538e58ce" title="https://bodhi.fedoraproject.org/updates/FEDORA-2018-e6538e58ce">https://bodhi.fedoraproject.org/updates/FEDORA-2018-e6538e58ce</a>

and

f29: <a href="https://bodhi.fedoraproject.org/updates/FEDORA-2018-175284c10b" title="https://bodhi.fedoraproject.org/updates/FEDORA-2018-175284c10b">https://bodhi.fedoraproject.org/updates/FEDORA-2018-175284c10b</a>

Is there a reason they haven't moved to testing state?

Thanks

Ceph-14.x.x, dropping 32-bit archs

Ceph 14.x.x (Nautilus) will no longer be built on i686 and armv7hl archs
starting in fedora-30/rawhide.

The upstream project doesn't support it. The armv7hl builders don't have
enough memory (or address space) to build some components.

And the other active maintainer (branto) and I don't have cycles to
devote to keeping it building on 32-bit archs.

(FWIW, currently ceph-12.2.9 (luminous) is in rawhide, f29, and f28 and
it has packages for i686 and armv7hl for people who want to run ceph on
32-bit archs.)

enabling KCM in the Fedora kernels

Hi,

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.

Thanks,

build failed on s390x, other archs building okay

Is this a spurious failure or ???

...
Task info: <a href="https://koji.fedoraproject.org/koji/taskinfo?taskID=28564187" title="https://koji.fedoraproject.org/koji/taskinfo?taskID=28564187">https://koji.fedoraproject.org/koji/taskinfo?taskID=28564187</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/daemon.py", line 1244, in
runTask\n response = (handler.run(),)\n File
"/usr/lib/python2.7/site-packages/koji/tasks.py", 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/util.py", 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="https://release-monitoring.org/project/267/" title="https://release-monitoring.org/project/267/">https://release-monitoring.org/project/267/</a>

But the Homepage: in the above and the Source: in the .spec would seem
to be saying that <a href="http://download.ceph.com/tarballs/" title="http://download.ceph.com/tarballs/">http://download.ceph.com/tarballs/</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?

Thanks,

'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

Thanks

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
knowledge.

E.g.——

%cat /etc/sysconfig/network-scripts/ifcfg-ens3
...
BOOTPROTO=none
...
IPADDR=192.168.122.26
...

But it's getting 192.168.122.169 (from dhcp?)

Thanks

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

E.g.:
...
On x86_64:
nfs-ganesha-2.6.0-0.4rc5.fc28.x86_64 requires
libntirpc.so.1.6(NTIRPC_1.6.0)(64bit)
...

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
build?

glusterfs in Fedora Modular 27?

I've been contacted by Fedora QE about this, and have bz
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1518150" title="https://bugzilla.redhat.com/show_bug.cgi?id=1518150">https://bugzilla.redhat.com/show_bug.cgi?id=1518150</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

sysconf(_SC_IOV_MAX);

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
this:

...
DEBUG util.py:439: No matching package to install: 'libibverbs-devel'
DEBUG util.py:439: No matching package to install: 'librdmacm-devel >=
1.0.15'
...

Thanks,

librpm.so.7, 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 util.py:439: Error: nothing provides librpm.so.7()(64bit) needed
by deltarpm-3.6-22.fc27.x86_64
DEBUG util.py:439: (try to add '--allowerasing' to command line to
replace conflicting packages)
...

the scratch build had rpm-4.13.0.1-41.fc27 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/ceph_dencoder.cc.o] 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.

Thanks,

[1] <a href="https://kojipkgs.fedoraproject.org//work/tasks/1128/20631128/build.log" title="https://kojipkgs.fedoraproject.org//work/tasks/1128/20631128/build.log">https://kojipkgs.fedoraproject.org//work/tasks/1128/20631128/build.log</a>

fedpkg update is failing

TL;DNR
<a href="https://paste.fedoraproject.org/paste/PyG9sLWVgPpVKqAXPYp6K15M1UNdIGYhyRLivL9gydE=/" title="https://paste.fedoraproject.org/paste/PyG9sLWVgPpVKqAXPYp6K15M1UNdIGYhyRLivL9gydE=/">https://paste.fedoraproject.org/paste/PyG9sLWVgPpVKqAXPYp6K15M1UNdIGYhyR...</a>

Reader's Digest version: Could not execute update: Could not generate
update request: Command 'bodhi --bodhi-url
<a href="https://bodhi.fedoraproject.org/" title="https://bodhi.fedoraproject.org/">https://bodhi.fedoraproject.org/</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?

Thanks,

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

Hi,

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

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

and

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

Thanks,

rawhide vs koji f26 builds

Hi,

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

<a href="https://koji.fedoraproject.org/koji/getfile?taskID=16059122&amp;name=build.log&amp;offset=-4000" title="https://koji.fedoraproject.org/koji/getfile?taskID=16059122&amp;name=build.log&amp;offset=-4000">https://koji.fedoraproject.org/koji/getfile?taskID=16059122&amp;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?

Thanks,

nfs-ganesha -stable request stalled

Hi,

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.

Thanks,

autoconf test for deprecated readdir_r

Hi,

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

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

Thanks,

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

Hi,

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/cli.py:169: 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="https://admin.fedoraproject.org/updates/save" title="https://admin.fedoraproject.org/updates/save">https://admin.fedoraproject.org/updates/save</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
2015-04-21.

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

Thanks,

over-riding an autodep for a sharedlib?

the samba.spec has:

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

The samba-vfs-glusterfs has these Requires (rpm -q --requires
samba-vfs-gluster)
glusterfs-api >= 3.4.0.16
glusterfs >= 3.4.0.16
...
libgfapi.so.0()(64bit)
...

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