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.
ably insane; none of them has worked.
The new web interface worked, once I figured out what the correct inputs
were.
On 08/25/2015 06:38 AM, Kaleb KEITHLEY wrote:
I must have missed some announcement?
Submitting from an up to date f22 box I get:
% fedpkg update
/usr/lib/python2.7/site-packag
libntirpc. It's currently bundled in nfs-ganesha with a bundling
exception through Fedora 23, but it's ready now.
https://bugzilla.redhat.com/show_bug.cgi?id=1204898
Thanks,
--
Kaleb
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
F
On Thu, May 28, 2020 at 4:46 AM Jonathan Wakely
wrote:
> I'm starting the rebuilds for Boost 1.73.0 and packages that depend on
> it, using the f33-boost side tag.
>
>
Is this still in progress? I don't see that ceph-15.2.2 has been rebuilt
nor is it being rebuilt now. Should I build the new rele
Is the rebuild in the side tag something that's still in progress?
I sent Jonathan an email asking, but didn't get a reply.
I've built a new release of ceph (ceph-15.2.3) in the f33-boost side tag
but if this is something that's on hold I'll need to build it for f33.
Thanks
On Thu, May 28, 2020
On Tue, Jun 2, 2020 at 10:25 AM Jonathan Wakely
wrote:
> ...
> ceph was not in my list, because it isn't returned by the first query
> shown at https://fedoraproject.org/wiki/Changes/F33Boost173#Dependencies
>
> Does it actually depend on any libboost_*.so libraries, or just use
> the header-only
On Tue, Jun 2, 2020 at 10:48 AM Tomasz Torcz wrote:
> > Hmm, I do see this in ceph.spec:
> >
> > BuildRequires:boost-devel
> > BuildRequires:boost-random
> >
> > But the repoquery doesn't say it needs them.
>
> Thats interesting, as boost is in RPM requires.
> For example ceph-c
On Tue, Jun 2, 2020 at 10:58 AM Jonathan Wakely
wrote:
>
> >Up to now it hasn't.
> >
> >I've been waiting to get boost > 1.71 so that it can be built with the
> >system boost instead of its bundled copy.
> >
> >If the side tag build is going to be going on for a while then I'm going
> to
> >rebui
Whatever name is picked: devel, main, rawhide, next, etc., how about
setting the default branch.
E.g. `git symbolic-ref HEAD refs/heads/rawhide`
This way when someone clones the repo they don't need to know or remember
which name Fedora is using as the mainline development branch.
On Wed, Jul
On 2020-07-17 I built ceph-15.2.4-5 (and ceph-15.2.4-6 --target=f33-java11)
with cmake-3.18.0-1.fc33 and the build(s) were successful.
Today, with cmake-3.18.0-2.fc33 (which I guess is a respin of cmake-
3.18.0-1.fc33.1, a.k.a. 3.18.0-1.1) my scratch builds are failing with:
...
+ make -j5
On Mon, Jul 20, 2020 at 1:48 PM Neal Gompa wrote:
>
>
> Your spec file is a complete mess, so I have not yet touched it to fix it.
>
Not _my_ spec file. Is this another episode of whinging about %ifdef SUSE,
then I suggest you direct your comments at
https://github.com/ceph/ceph/blob/master/ceph
About a week ago I did a scratch build of one of my packages that includes
and it built successfully.
Today I did another scratch build and it broke with:
...
Making all in src
CC fuse-helpers.lo
CC fuse-resolve.lo
CC fuse-bridge.lo
CC misc.lo
In file included from fuse
A scratch build on koji if that wasn't apparent.
- Original Message -
From: "Kaleb Keithley"
To: "Development discussions related to Fedora"
Sent: Thursday, May 31, 2012 1:38:32 PM
Subject: sys/sysctl.h and bits/sysctl.h in rawhide/f18?
About a week ago I d
How do I do this? (The package is hekafs.)
I have retired the package in f18.
I have removed the f18 tag from all the fc18 builds.
Bit the rawhide build is still pulling the fc17 version of the package.
There are no dependencies on it.
I have googled for it, but my google fu is not good with t
>
> How do I do this? (The package is hekafs.)
>
> I have retired the package in f18.
>
> I have removed the f18 tag from all the fc18 builds.
>
> But the rawhide build is still pulling the fc17 version of the package.
>
> There are no dependencies on it.
And FWIW, the latest glusterfs rpm Obso
Hi,
The gluster community has been trying to get its
glusterfs-openstack-swift package reviewed since August (2013).
See https://bugzilla.redhat.com/show_bug.cgi?id=1003089
I realize that reviewers are often unpaid volunteers working on their
own time. On the flip side, the package owner, who
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)
From: "Ric Wheeler"
>
> Friday is a normal work day for most people (although some people will take
> it
> off to get a longer weekend :))
You know it's a Red Hat paid holiday, right?
--
Kaleb
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listi
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
network-online.target and order themselves after it.
Would adding a Before=network-online.target to the glusterd.service be
the right thing to
On 07/23/2013 03:44 PM, Richard W.M. Jones wrote:
Not sure if glusterfs could be split into client and server parts
and/or if that would help (only a "client" bit is needed).
glusterfs already exists in client (glusterfs and/or glusterfs-api and
associated -devel rpms) and server (glusterfs-s
On 07/23/2013 04:41 PM, Richard W.M. Jones wrote:
On Tue, Jul 23, 2013 at 03:49:37PM +0530, Kaleb KEITHLEY wrote:
On 07/23/2013 03:44 PM, Richard W.M. Jones wrote:
Not sure if glusterfs could be split into client and server parts
and/or if that would help (only a "client" bit
On 07/23/2013 05:20 PM, Richard W.M. Jones wrote:
On Tue, Jul 23, 2013 at 12:45:59PM +0100, Daniel P. Berrange wrote:
On Tue, Jul 23, 2013 at 03:49:37PM +0530, Kaleb KEITHLEY wrote:
On 07/23/2013 03:44 PM, Richard W.M. Jones wrote:
Not sure if glusterfs could be split into client and server
On 07/23/2013 05:34 PM, Matthew Miller wrote:
On Tue, Jul 23, 2013 at 05:27:20PM +0530, Kaleb KEITHLEY wrote:
$ rpm -ql glusterfs-api
/usr/lib64/glusterfs/3.4.0beta4/xlator/mount/api.so
/usr/lib64/libgfapi.so.0
/usr/lib64/libgfapi.so.0.0.0
Even if libgfapi (from glusterfs-api) is used instead
On 07/24/2013 12:29 AM, Peter Robinson wrote:
Can't you split the translators into a glusterfs-common (or something)
The glusterfs RPM already is the glusterfs-common RPM that you want.
If you look, you'll see that the other things in the glusterfs RPM
really aren't that big; moving the tr
On 08/15/2013 11:32 AM, Reindl Harald wrote:
Am 15.08.2013 17:17, schrieb Ralf Corsepius:
On 08/15/2013 04:36 PM, Paul Wouters wrote:
On Thu, 15 Aug 2013, Reindl Harald wrote:
Am 15.08.2013 15:40, schrieb Paul Wouters:
We can't tell people to re-install from scratch every 6 months.
What we
On 10/01/2013 01:10 PM, Niels de Vos wrote:
On Sat, Sep 14, 2013 at 09:55:38PM +0200, Hans de Goede wrote:
Hi All,
I'm very happy to announce the second release (r2) of my Fedora 19 ARM
remix images for Allwinner A10, A10s, A13 and A20 based devices. This
release is based on the official Fedora
On 05/14/2013 08:15 AM, build...@fedoraproject.org wrote:
glusterfs has broken dependencies in the F-19 tree:
On x86_64:
glusterfs-ufo-3.4.0-0.4.beta1.fc19.noarch requires
openstack-swift-proxy = 0:1.8.0
glusterfs-ufo-3.4.0-0.4.beta1.fc19.noarch requires
openstack-swift-object =
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,
--
Kaleb
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,
--
Kaleb
--
devel maili
On 03/13/2013 12:17 PM, Stef Walter wrote:
On 03/12/2013 08:17 PM, Till Maas wrote:
On Tue, Mar 12, 2013 at 12:47:07AM -0400, Digimer wrote:
On 03/12/2013 12:41 AM, Charles Zeitler wrote:
i don't like giving up control over my machine (partitioning),
so i won't be upgrading to Fedora 18.
i'll
On 10/23/2013 11:09 AM, Miroslav Suchý wrote:
On 10/23/2013 04:25 PM, Simo Sorce wrote:
If glusterfs feels people need to run the bricks and the main daemons
separately then they should probably split service files and have a
dependency to bring one up when the other comes up, yet still be allow
On 10/23/2013 11:57 AM, Michael Cronenworth wrote:
Perhaps I need to file the bug against the glusterfsd unit file?
Yes, you should certainly do that.
--
Kaleb
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct:
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 fin
Take, for example, https://github.com/nfs-ganesha/nfs-ganesha/releases,
where there's a button for "Source code (tar.gz)" pointing at
https://github.com/nfs-ganesha/nfs-ganesha/archive/V2.0.0.tar.gz
Note V2.0.0.tar.gz versus nfs-ganesha-2.0.0.tar.gz.
If I click on that link the downloaded fi
On 01/21/2014 12:39 PM, Richard Shaw wrote:
On Tue, Jan 21, 2014 at 11:25 AM, Alec Leamas mailto:leamas.a...@gmail.com>> wrote:
Actually, the GL are pretty clear here: the source should be
referenced using the full commit, nothing else. There is some
reasoning why. The tag should got
I pushed glusterfs-3.7.9-1.fc23 to stable four days ago. It has +4 karma.
It's still pending. Is it stuck? Can someone please give it a kick?
Thanks
--
Kaleb
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
On 04/05/2016 08:55 AM, Peter Robinson wrote:
> On Tue, Apr 5, 2016 at 1:51 PM, Kaleb KEITHLEY wrote:
>>
>> I pushed glusterfs-3.7.9-1.fc23 to stable four days ago. It has +4 karma.
>>
>> It's still pending. Is it stuck? Can someone please give it a kick?
>
On 04/07/2016 06:45 AM, Peter Robinson wrote:
I pushed glusterfs-3.7.9-1.fc23 to stable four days ago. It has +4 karma.
It's still pending. Is it stuck? Can someone please give it a kick?
>>>
>>> All the updates are already in process of being kicked by me, should
>>> hopefully be m
Hi,
Trying to build latest nfs-ganesha––
Yesterday (for me, 02:00 UTC, 24 Jan) I was getting (on both a fedpkg build and
koji scratch builds):
DEBUG util.py:435: Error: package pkgconf-pkg-config-1.2.0-1.fc26.ppc64le
conflicts with pkgconfig < 1:0.29.1-2 provided by
pkgconfig-1:0.29.1-1.fc
for f26
>
> On Tue, Jan 24, 2017 at 11:07 AM, Kaleb Keithley wrote:
> > Hi,
> >
> > Trying to build latest nfs-ganesha––
> >
> > Yesterday (for me, 02:00 UTC, 24 Jan) I was getting (on both a fedpkg build
> > and koji scratch builds):
> >DEB
Now five. ppc64le this time.
On Tue, Mar 24, 2020 at 7:10 AM Kaleb Keithley wrote:
>
>
>
> Hi,
>
> I've had four ceph builds die in the last 12ish hours. One of them was a
> scratch build on x86_64; the others were regular builds, one on ppc64le,
> and the other tw
On Tue, Mar 24, 2020 at 1:13 PM Kevin Fenzi wrote:
> On Tue, Mar 24, 2020 at 09:28:35AM -0400, Kaleb Keithley wrote:
> > Now five. ppc64le this time.
>
> I've cleaned these up now.
>
> Mostly it was due to the upgrade on the builders this weekend pulling in
&g
In rawhide the ceph ceph-test subpackage is deriving a Requires: for
$subject, and even with gmock and gtest installed the requires is not
satisfied.
And the gtest and gmock rpms (somehow) do not provide them. (Is this a bug
in the gtest and gmock rpms?)
(They do provide libgtest.so.1.10.0 libgmo
On Wed, May 20, 2020 at 8:52 AM Neal Gompa wrote:
> On Wed, May 20, 2020 at 8:39 AM Kaleb Keithley
> wrote:
> >
> > In rawhide the ceph ceph-test subpackage is deriving a Requires: for
> $subject, and even with gmock and gtest installed the requires is not
> satisfied.
&
Hi,
three different builds of ceph have failed in the last 15 min. for lack of
space to untar the source.
Would someone check them out please?
thanks
--
Kaleb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to dev
My bad. Only one. The second failed because the first had not finished on
the other arches, despite canceling it.
The third is actually x86_64 and failed for a different reason.
On Tue, May 26, 2020 at 11:54 AM Kaleb Keithley wrote:
> Hi,
>
> three different builds of ceph have fail
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
--
Kaleb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedo
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.
https://kojipkgs.fedoraproject.org//work/tasks/7359/38917359/build.log
thanks
--
Kaleb
___
dev
On Mon, Nov 11, 2019 at 1:39 PM Kevin Fenzi wrote:
> On Mon, Nov 11, 2019 at 01:10:07PM -0500, Kaleb Keithley wrote:
> > 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 toda
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
o
Yet Another Ceph Build Stuck in Pending Testing
https://bodhi.fedoraproject.org/updates/FEDORA-2019-623fb9419e
Would someone please give it a kick.
Thanks
--
Kaleb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email t
On Thu, Jul 25, 2019 at 1:11 PM Kevin Fenzi wrote:
> On 7/25/19 3:48 AM, Kaleb Keithley wrote:
> > Yet Another Ceph Build Stuck in Pending Testing
> >
> > https://bodhi.fedoraproject.org/updates/FEDORA-2019-623fb9419e
> >
> > Would someone please give it a kic
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?
On Fri, Jul 19, 2019 at 2:12 PM Miro Hrončok wrote:
>
> ktdre...@ktdreyer.com ktdreyer
> https://bugzilla.redhat.com/show_bug.cgi?id=1731540
> https://bugzilla.redhat.com/show_bug.cgi?id=1706223
Use kdre...@redhat.com instead.
He is currently on paternity leave and may not be responding to wor
On Fri, Jul 26, 2019 at 1:31 PM Kevin Fenzi wrote:
> On 7/25/19 11:05 AM, Kaleb Keithley wrote:
> > hmmm. from the root.log
> >
> > DEBUG util.py:585: BUILDSTDERR: Error:
> > DEBUG util.py:585: BUILDSTDERR: Problem: conflicting requests
> > DEBUG util.
On Wed, Jul 31, 2019 at 3:43 PM Kevin Fenzi wrote:
> On 7/31/19 12:01 PM, Kaleb Keithley wrote:
>
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1733602
> >
> > One of the suggestions there is to "drop the arch." I.e. i686.
> >
> > If th
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
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
On Mon, Aug 5, 2019 at 11:29 AM Peter Robinson wrote:
> On Mon, Aug 5, 2019 at 3:44 PM Kaleb Keithley wrote:
> >
> >
> > There is a proposal[1] in upstream GlusterFS to drop 32-bit arches.
> >
> > The original proposal was to drop 32-bit with GlusterFS-7. Glu
On Mon, Aug 5, 2019 at 9:57 AM Miro Hrončok wrote:
> On 05. 08. 19 15:36, Kaleb Keithley wrote:
> > 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
> > i
On Mon, Aug 5, 2019 at 6:17 PM Kevin Kofler wrote:
> >
> > Please feel free though to add your thoughts to the issue.
> >
> > [1] https://github.com/gluster/glusterfs/issues/702
>
> The upstream issue actually says they want to keep building 32-bit in
> their
> CI, so it should compile just fine,
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 gen
On Thu, Aug 15, 2019 at 10:21 AM Alexander Bokovoy
wrote:
> On to, 15 elo 2019, Kaleb Keithley wrote:
> >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 wi
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 pyth
Never mind, false alarm. Waiting for coffee to kick in.
On Mon, Aug 19, 2019 at 8:49 AM Kaleb Keithley wrote:
>
> 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-unversion
On Wed, Aug 21, 2019 at 1:23 PM Miro Hrončok wrote:
> On 15. 08. 19 0:18, Miro Hrončok wrote:
> > Hello, in order to deliver Python 3.8, we are running a coordinated
> rebuild in a
> > side tag.
> >
>
> The side tag was merged. Build in regular rawhide now. Thanks.
>
/me wonders why my `dnf upda
`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:31201
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 th
https://bodhi.fedoraproject.org/updates/FEDORA-2019-6f5be50fd9
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,
--
Kaleb
___
devel mailing list --
Someone with privs please kick it. Thanks
https://bodhi.fedoraproject.org/updates/FEDORA-2019-995f3ae953
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
On Thu, Sep 19, 2019 at 2:18 PM Kevin Fenzi wrote:
> On 9/19/19 5:26 AM, Kaleb Keithley wrote:
> > Someone with privs please kick it. Thanks
> >
> > https://bodhi.fedoraproject.org/updates/FEDORA-2019-995f3ae953
>
> Done. Do note that you can do this too, just unta
On Thu, Sep 19, 2019 at 7:33 PM Kaleb Keithley wrote:
> On Thu, Sep 19, 2019 at 2:18 PM Kevin Fenzi wrote:
>
>> On 9/19/19 5:26 AM, Kaleb Keithley wrote:
>> > Someone with privs please kick it. Thanks
>> >
>> > https://bodhi.fedoraproject.org/updates/FED
On Fri, Sep 20, 2019 at 11:41 AM Kevin Fenzi wrote:
> On 9/20/19 6:07 AM, Kaleb Keithley wrote:
> > On Thu, Sep 19, 2019 at 7:33 PM Kaleb Keithley
> wrote:
> >
> >> On Thu, Sep 19, 2019 at 2:18 PM Kevin Fenzi wrote:
> >>
> >>> On 9/19/19 5:26 AM,
And for https://bodhi.fedoraproject.org/updates/FEDORA-2019-6f79c53e44
I don't have permission to untag and retag the f30-signing-pending tag.
Many thanks for your help.
On Sun, Sep 22, 2019 at 4:02 PM Kevin Fenzi wrote:
> On Fri, Sep 20, 2019 at 12:12:58PM -0400, Kaleb Keithl
related to bodhi having gone down?
Can someone kick it please?
Thanks
--
Kaleb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproj
One (the only) thing I've noticed so far about gcc-10 is that (sloppily)
defined variables in header files that lack an extern qualifier and that
don't have an explicit defn in a .c file are no longer 'common' or .comm
but are now .global .bss and cause link errors due to duplicate definitions.
Th
And now it's just "pending".
On Thu, Jan 2, 2020 at 7:40 PM Kevin Fenzi wrote:
> On Thu, Jan 02, 2020 at 09:14:30AM -0500, Kaleb Keithley wrote:
> > related to bodhi having gone down?
> >
> > Can someone kick it please?
>
> I would if I cou
https://koji.fedoraproject.org/koji/taskinfo?taskID=40326373
Is it a transient problem or something that needs to be fixed?
thanks
--
Kaleb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedor
On Tue, Jan 21, 2020 at 7:36 AM Miro Hrončok wrote:
>
... glusterfs...
>
>
glusterfs and nfs-ganesha are already fixed upstream. They'll be fixed in
their next minor release before it becomes necessary, or I will respin with
patches sooner.
--
Kaleb
___
Coming in Ceph-15 (octopus)
From: LGPL-2.1 and CC-BY-SA-3.0 and GPL-2.0 and BSL-1.0 and BSD-3-Clause
and MIT
To: LGPL-2.1 and LGPL-3.0 and CC-BY-SA-3.0 and GPL-2.0 and BSL-1.0 and
BSD-3-Clause and MIT
Note: I'm tentatively planning on landing ceph-15 in rawhide after f32
branch.
--
Kaleb
_
On Mon, Feb 3, 2020 at 11:35 PM Daniel P. Berrangé
wrote:
> On Mon, Feb 03, 2020 at 11:26:46PM +0530, Kaleb Keithley wrote:
> > Coming in Ceph-15 (octopus)
> >
> > From: LGPL-2.1 and CC-BY-SA-3.0 and GPL-2.0 and BSL-1.0 and BSD-3-Clause
> > and MIT
> > To: L
On Mon, Feb 3, 2020 at 11:35 PM Daniel P. Berrangé
wrote:
> On Mon, Feb 03, 2020 at 11:26:46PM +0530, Kaleb Keithley wrote:
> > Coming in Ceph-15 (octopus)
> >
> > From: LGPL-2.1 and CC-BY-SA-3.0 and GPL-2.0 and BSL-1.0 and BSD-3-Clause
> > and MIT
> > To: L
On Tue, Feb 4, 2020 at 3:45 PM Miro Hrončok wrote:
>
> Iff the above is correct, the license field should say:
>
> (LGPL-2.1 or LGPL-3.0) and CC-BY-SA-3.0 and GPL-2.0 and BSL-1.0 and
> BSD-3-Clause
> and MIT
>
>
> (If we ignore that those are probably SPDX license identifiers and not
> what
> Fed
several of my `koji --scratch --arch-overide=s390x ...` builds have failed
with error; reading package header (after the rebuildSRPM)
Latest is https://koji.fedoraproject.org/koji/taskinfo?taskID=41622496
(guess I could reopen my s390x disk full ticket. Or open a new one.)
--
Kaleb
___
On Tue, Feb 18, 2020 at 9:59 PM Kevin Fenzi wrote:
> On Tue, Feb 18, 2020 at 04:41:42PM -0800, Kevin Fenzi wrote:
> > On Tue, Feb 18, 2020 at 02:05:07PM -0500, Kaleb Keithley wrote:
> > > several of my `koji --scratch --arch-overide=s390x ...` builds have
> failed
>
st FYI. (I can provide the tasks, if you're unable to find them
easily in koji.)
On Tue, Feb 18, 2020 at 2:05 PM Kaleb Keithley wrote:
>
> several of my `koji --scratch --arch-overide=s390x ...` builds have
> failed with error; reading package header (after the rebuildS
https://bodhi.fedoraproject.org/updates/FEDORA-2019-1c53f1a6c8
https://bodhi.fedoraproject.org/updates/FEDORA-2019-6a2e72916a
Would someone please give them a kick?
Thanks
--
Kaleb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe
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
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 ep
On Mon, Mar 11, 2019 at 8:22 AM Neal Gompa wrote:
> Heck, the spec file
> that is in Fedora is basically an openSUSE spec with Fedora
> conditionals in it.
>
The ceph.spec file in Fedora is based on the upstream ceph.spec.in file;
not on anything in/from openSUSE.
The upstream ceph.spec.in fil
On Mon, Mar 11, 2019 at 7:35 AM Daniel P. Berrangé
wrote:
> The ability to have multiple different builds of the same software which
> users can choose between, sounds alot like the use case for modularity.
> Abusing Epoch to try to address this kind of situation feels like a pretty
> undesirable
On Tue, Feb 19, 2019 at 3:18 AM Kevin Fenzi wrote:
> On 2/18/19 12:56 PM, Kaleb Keithley wrote:
> > https://bodhi.fedoraproject.org/updates/FEDORA-2019-1c53f1a6c8
> > https://bodhi.fedoraproject.org/updates/FEDORA-2019-6a2e72916a
> >
> > Would someone please give them
ceph-12.2.12 for f28 and f29.
Happens every time.
Someone please give them a kick.
Thanks.
--
Kaleb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: ht
Two more are stuck again.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-3b8418
https://bodhi.fedoraproject.org/updates/FEDORA-2019-399f5bd105
On Fri, Mar 22, 2019 at 3:08 PM Kevin Fenzi wrote:
> On 3/21/19 5:45 PM, Kaleb Keithley wrote:
> > On Tue, Feb 19, 2019 at 3:18 AM Ke
Hi,
https://bodhi.fedoraproject.org/updates/FEDORA-2019-60ba61b5ab
Why does this happen every time?
Would someone please kick it? Thanks
--
Kaleb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@list
Thanks for opening the ticket, but the update is still stuck, now going on
nine days.
Would someone with the necessary privs please kick it.
Thanks
On Mon, Jun 3, 2019 at 1:52 PM Randy Barlow
wrote:
> On Sun, 2019-06-02 at 18:03 -0400, Kaleb Keithley wrote:
> &
On Thu, Feb 9, 2023 at 12:02 PM Kaleb Keithley wrote:
>
> On Tue, Nov 29, 2022 at 10:54 AM Kaleb Keithley
> wrote:
>
>> Hi,
>>
>> Apache Arrow 10.0.0 has been released.
>>
>> At present nobody is using libarrow except Ceph. (Which I am the
>> main
Hi,
ceph-18 RC will likely be tagged in the next week or two, according to my
sources.
(Note: wrt rhbz#2193399, the submoduled/bundled boost that's currently in
ceph-18 is newer than the version in ceph-17 (quincy) and does support
kXXH3 cksum. Ceph, even ceph-18, hasn't caught up to boost-1.81,
Hi,
I don't see a specific epel working group list on lists.fpo.
I'd like to update rocksdb to a newer version for consumption by ceph.
(Ceph currently bundles rocksdb-7.9.2 IIRC for when the distribution's
version is too old.)
AFAIK, AFAICT, ceph is the only consumer of rocksdb in EPEL (or in F
Hi,
Apache ORC 1.9.0 has been released.
I believe it is the case that only libarrow (Apache Arrow) and by
extension, ceph consume liborc, and I am the maintainer of both libarrow
and ceph. (My repoqueries don't show anything using liborc or liborc-devel.)
I will be rebasing liborc to 1.9.0 short
1 - 100 of 178 matches
Mail list logo
