DevHeads.net

Postings by Kaleb S. KEITHLEY

are the ppc64le builders low on memory?

Last week I built ceph 14.2.4-2 and it built fine on both fc31 and rawhide.

I fixed a typo for a Requires: and the ppc64le builds today are getting
killed.

<a href="https://kojipkgs.fedoraproject.org//work/tasks/7359/38917359/build.log" title="https://kojipkgs.fedoraproject.org//work/tasks/7359/38917359/build.log">https://kojipkgs.fedoraproject.org//work/tasks/7359/38917359/build.log</a>

thanks

SONAME bump for libntirpc coming soon in f32/rawhide

I don't believe anything except nfs-ganesha uses libntirpc, but on the
off-chance that there is—

libntirpc will bump from 1.8 to 3.0

YACBSIPT, rawhide ceph build stuck in bodhi, again

Someone with privs please kick it. Thanks

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

is this update stuck? Ceph-14.2.3-1.fc32

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

Two other ceph updatest submitted around the same time moved to testing
okay.

If it is stuck, can someone with appropriate privs please kick it.

Thanks,

python38-3.8.0~b3-1.fc30 on my f30 machine? how?

Also python36, python35, and python34.

I'm 100% confident that I never explicitly installed these.

Having python38 broke my devel setup due to there being no Cython in
/usr/lib64/python3.8/site-packages/... I don't know how long it was
broken. Very annoying to discover this.

How do I prevent this from happening again? (Yes, I know I can put
explicit excludes in my /etc/yum.repos.d/fedora-updates.repo file.) Seems
like I shouldn't need to and that it shouldn't have happened in the first
place.

f32/rawhide, nothing provides module(platform:f31)

`dnf update` on my f32/rawhide machine is giving me:

Problem 1: conflicting requests
- nothing provides module(platform:f31) needed by module
bat:latest:3120190714171319:22d7e2a5-0.x86_64
Problem 2: conflicting requests
- nothing provides module(platform:f31) needed by module
exa:latest:3120190721165838:22d7e2a5-0.x86_64
Problem 3: conflicting requests
- nothing provides module(platform:f31) needed by module
libgit2:0.28:3120190714114509:f636be4b-0.x86_64
Problem 4: conflicting requests
- nothing provides module(platform:f31) needed by module
silver:rolling:3120190728135623:22d7e2a

ambiguous python in f29+ builds,

All the python files in one of my packages (nfs-ganesha) have
#!/usr/bin/python[23] shebangs.

The nfs-ganesha.spec does _not_ have python-unversioned-command as a
BuildRequires:

I do not have python-unversioned-command installed on my f30 box.

AIUI, setup.py alters the shebangs to match the python that's in the path
when it runs.

When I build (rpmbuild or mock) on my f30 box, the shebangs are left
unchanged.

Yet the packages built in koji all have their python shebangs changed to
/usr/bin/python (by setup.py.) The build.logs show
that python-unversioned-command is not installed.

when will bodhi (updates) recognize fc31/f31 updates

I've tried to submit a build on f31 to testing, using both the cli and via
the web site, and both are failing

On the web site I get a popup with: Builds : Cannot find release associated
with build: nfs-ganesha-2.8.2-5.fc31, tags: ['f31']

fedpkg update gets: Could not execute update: Could not generate update
request: Cannot find release associated with build:
nfs-ganesha-2.8.2-5.fc31, tags: ['f31']

Thanks

Fedora 32 System-Wide Change: glusterfs dropping 32-bit arches

There is a proposal[1] in upstream GlusterFS to drop 32-bit arches.

The original proposal was to drop 32-bit with GlusterFS-7. GlusterFS-7 will
land in Fedora 31/rawhide soon. More than likely though it will not be
official until GlusterFS-8, which will probably land, accordingly, after
Fedora 31 GA in Fedora 32/rawhide.

[1] <a href="https://github.com/gluster/glusterfs/issues/702" title="https://github.com/gluster/glusterfs/issues/702">https://github.com/gluster/glusterfs/issues/702</a>

mass rebuild, glusterfs build failed

hmmm. from the root.log

DEBUG util.py:585: BUILDSTDERR: Error:
DEBUG util.py:585: BUILDSTDERR: Problem: conflicting requests
DEBUG util.py:585: BUILDSTDERR: - nothing provides kernel >= 4.18.0
needed by firewalld-0.6.4-1.fc31.noarch

how to deal with this? Wait for a new firewalld package?

YACBSIPT

Yet Another Ceph Build Stuck in Pending Testing

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

Would someone please give it a kick.

Thanks

are the ppc64le builders healthy?

I built the latest ceph-14 (14.2.2) on rawhide successfully two days ago.

Two different builds on f30 built or are building fine on x86_64, i686, and
aarch64, but failed with different errors on ppc64le at different places in
the build. One looks like it ran out of space in the file system. The
other may have been OOM killed (?).

<a href="https://kojipkgs.fedoraproject.org//work/tasks/2448/36422448/build.log" title="https://kojipkgs.fedoraproject.org//work/tasks/2448/36422448/build.log">https://kojipkgs.fedoraproject.org//work/tasks/2448/36422448/build.log</a>

<a href="https://kojipkgs.fedoraproject.org//work/tasks/4819/36444819/build.log" title="https://kojipkgs.fedoraproject.org//work/tasks/4819/36444819/build.log">https://kojipkgs.fedoraproject.org//work/tasks/4819/36444819/build.log</a>

Thanks,

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