two builds stuck in pending testing for nine days

f28: https://bodhi.fedoraproject.org/updates/FEDORA-2018-e6538e58ce and f29: https://bodhi.fedoraproject.org/updates/FEDORA-2018-175284c10b Is there a reason they haven't moved to testing state? Thanks -- Kaleb ___ devel mailing list --

Re: [HEADS UP] Ceph-14.x.x, dropping 32-bit archs

On 12/6/18 7:04 AM, Kaleb S. KEITHLEY wrote: > >> And the other active maintainer (branto) and I don't have cycles to >> devote to keeping (any part of) it building on 32-bit archs. > > But people can always send patches. ;-) If someone else would like to take over as

Re: [HEADS UP] Ceph-14.x.x, dropping 32-bit archs

On 12/5/18 9:50 PM, Peter Robinson wrote: > Kaleb, > > Firstly the title is misleading as there was no heads up, a heads up > is notice before you actually push the change, not when you do the > change. I suggest you take this up with branto. He's the one who built it without 32-bit archs

Re: [HEADS UP] Ceph-14.x.x, dropping 32-bit archs

On 12/5/18 8:34 AM, Dan Horák wrote: > On Wed, 5 Dec 2018 14:23:49 +0100 > Marcin Juszkiewicz wrote: > >> W dniu 05.12.2018 o 14:14, Kaleb S. KEITHLEY pisze: >> >>> Ceph 14.x.x (Nautilus) will no longer be built on i686 and armv7hl >>> archs starting in

[HEADS UP] 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

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, -- Kaleb ___ devel mailing

build failed on s390x, other archs building okay

Is this a spurious failure or ??? ... Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=28564187 ... buildArch (glusterfs-4.1.2-1.fc29.1.src.rpm, s390x): free -> FAILED: Fault: thanks, -- Kaleb ___ devel mailing list --

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

according to https://release-monitoring.org/project/267/ But the Homepage: in the above and the Source: in the .spec would seem to be saying that http://download.ceph.com/tarballs/ 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

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

On 03/21/2018 04:45 PM, Kevin Fenzi wrote: > On 03/20/2018 11:02 AM, Kaleb S. KEITHLEY wrote: >> >> 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

'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 -- Kaleb ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to

Re: f28 and rawhide ignoring static ip settings

On 03/15/2018 01:23 PM, Tomasz Torcz ️ wrote: > On Thu, Mar 15, 2018 at 01:13:09PM -0400, Kaleb S. KEITHLEY wrote: >> >> Did I miss something? >> >> Both machines were dnf system-upgraded from f27. Static IP settings were >> set at f27 install time and work

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

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

Re: LizardFS NFS Ganesha integration with no shared library available

On 01/18/2018 01:16 PM, Kaleb S. KEITHLEY wrote: > On 01/18/2018 03:23 AM, Jonathan Dieter wrote: >> (This is meant for the Fedora devel mailing list, but I've cc'd the >> nfs-ganesha mailing list in the hopes that they might see something I'm >> missing) >> >> T

Re: LizardFS NFS Ganesha integration with no shared library available

On 01/18/2018 03:23 AM, Jonathan Dieter wrote: > (This is meant for the Fedora devel mailing list, but I've cc'd the > nfs-ganesha mailing list in the hopes that they might see something I'm > missing) > > The latest release of the LizardFS distributed filesystem includes a > FSAL for NFS

Re: LizardFS NFS Ganesha integration with no shared library available

On 01/18/2018 03:23 AM, Jonathan Dieter wrote: > (This is meant for the Fedora devel mailing list, but I've cc'd the > nfs-ganesha mailing list in the hopes that they might see something I'm > missing) > > The latest release of the LizardFS distributed filesystem includes a > FSAL for NFS

glusterfs in Fedora Modular 27?

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

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

[EPEL-devel] retiring Ceph in EPEL-7

see https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-a4e3aae817 The package build I made with a README.deprecated has reached 14+ days in testing in bodhi. There was a single comment by anonymous to the effect that RHEL7 has ceph-94.5 with a -1 karma vote which appears to have not been

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

, Kaleb S. KEITHLEY <kkeit...@redhat.com> wrote: 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 matchi

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

[EPEL-devel] Re: update Ceph to 12.1.1 in epel7 ?

On 08/01/2017 01:05 PM, Stephen John Smoogen wrote: I will bring this up at the meeting tomorrow, but I believe that the plan would be something like the following: 1. "Update" the current package with README.deprecated explaining why the package is being removed from the repository and

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

[EPEL-devel] recent builds of glusterfs in epel-7

I've noticed that puiterwijk and kevin have done builds recently of glusterfs. It's unclear to me why anyone would do that. I don't mind really, but I want remind everyone that glusterfs was retired from EPEL when RHEL started to ship glusterfs client-side RPMs. The correct place to get el7

[EPEL-devel] Re: update Ceph to 12.1.1 in epel7 ?

On 08/01/2017 01:05 PM, Stephen John Smoogen wrote: On 1 August 2017 at 12:32, Jeffrey Ollie > wrote: Building 12.1.1 for EPEL7 would be VERY bad IMNSHO. 0.80.7 _is_ seriously out of date, but: [snip] I will bring this up at the meeting

[EPEL-devel] Re: update Ceph to 12.1.1 in epel7 ?

On 08/01/2017 01:05 PM, Stephen John Smoogen wrote: I will bring this up at the meeting tomorrow, but I believe that the plan would be something like the following: 1. "Update" the current package with README.deprecated explaining why the package is being removed from the repository and

[EPEL-devel] update Ceph to 12.1.1 in epel7 ?

The last version of Ceph that was built in epel7 was 0.80.7, back in December, 2016. That's pretty seriously out of date. Is anyone going to have any heartache if I build 12.1.1 for epel7? -- Kaleb ___ epel-devel mailing list --

ppc64le build failure, does it look familiar?

More ceph-12.1.1 This has built successfully previously, including the recent mass rebuild. Today the other associated builds have either finished or passed this point, but on the ppc64le build today I got this: ... Executing command: ['bash', '--login', '-c', '/usr/bin/rpmbuild -bb --target

Re: armv7hl builds running out of memory

On 07/26/2017 06:25 PM, Al Stone wrote: I've been experimenting in a slightly different environment (RHEL vs Fedora) but have been seeing oddly similar results. The use or not of the "-pipe" in GCC didn't seem to help. If I forced the make in the %build step to be just "make" (aka, "make

Re: armv7hl builds running out of memory

On 07/26/2017 08:22 AM, Björn 'besser82' Esser wrote: It looks like the whole parallelized make-process is hitting the 4 Gbytes limit per process / task on 32 Bit arches… Have you tried this? %build export CFLAGS="echo %{optflags} | sed -e 's!-pipe!!g'" export CXXFLAGS="$CFLAGS" …

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]: ***

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]

Re: Rawhide: where for art thou? (why no rawhide composes recently)

You keep using that word — where for [sic] — I do not think it means what you think it means. (As inconceivable as it may seem.) -- Kaleb ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to

[EPEL-devel] retiring nfs-ganesha and libntirpc from EPEL

Hi, I'm considering $subject. 1) the nfs-ganesha pkgs in EPEL are mildly crippled due to missing glusterfs -devel and ceph -devel packages in RHEL or EPEL. (The gluster -devel packages are not in the RHEL base channel, and probably won't ever be.) And they haven't been updated in a long time.

fedpkg update is failing

TL;DNR https://paste.fedoraproject.org/paste/PyG9sLWVgPpVKqAXPYp6K15M1UNdIGYhyRLivL9gydE=/ Reader's Digest version: Could not execute update: Could not generate update request: Command 'bodhi --bodhi-url https://bodhi.fedoraproject.org/ --new --release f26 --file bodhi.template

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

two package reviews

Hi, I have two packages up for review that could use some attention please: https://bugzilla.redhat.com/show_bug.cgi?id=1411875 and https://bugzilla.redhat.com/show_bug.cgi?id=1411947 Thanks, -- Kaleb ___ devel mailing list --

Re: rawhide vs koji f26 builds

On 10/12/2016 08:58 AM, Kalev Lember wrote: On 10/12/2016 02:47 PM, Kaleb S. KEITHLEY wrote: Hi, I have a glusterfs-3.7.16 scratch build that's failing in koji f26 builds https://koji.fedoraproject.org/koji/getfile?taskID=16059122=build.log=-4000 Yesterday (11 October) I downloaded

Re: rawhide vs koji f26 builds

On 10/12/2016 08:49 AM, Peter Robinson wrote: On Wed, Oct 12, 2016 at 1:47 PM, Kaleb S. KEITHLEY <kkeit...@redhat.com> wrote: Hi, I have a glusterfs-3.7.16 scratch build that's failing in koji f26 builds https://koji.fedoraproject.org/koji/getfile?taskID=16059122=build.log=-4000 C

rawhide vs koji f26 builds

Hi, I have a glusterfs-3.7.16 scratch build that's failing in koji f26 builds https://koji.fedoraproject.org/koji/getfile?taskID=16059122=build.log=-4000 Yesterday (11 October) I downloaded and installed the current rawhide and built — successfully — from the same src.rpm that's failing in

enable ABRT reports for glusterfs

Hi, My search engine fu is failing atm. I get ABRT reports from notificati...@fedoraproject.org for another package (nfs-ganesha) that I'm the maintainer for. I'd like to enable ABRT reports for glusterfs. But I can't seem to find where to do that. Or maybe glusterfs never crashes! Thanks,

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

On 02/24/2016 10:46 AM, Orion Poplawski wrote: > On 02/24/2016 07:17 AM, Kaleb S. KEITHLEY wrote: >> 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 >> >&g

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

On 02/24/2016 09:45 AM, Stephen Gallagher wrote: > On 02/24/2016 09:30 AM, Peter Robinson wrote: >>> 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

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? Or is there something missing that's preventing

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

On 09/16/2015 01:19 PM, Jason L Tibbitts III wrote: >> "AT" == Alexander Todorov writes: > > AT> offending packages. You can find links to the script and execution > AT> log here: > AT> http://atodorov.org/blog/2015/09/16/4000-bugs-in-fedora-checksec-failures/ > > BTW

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. [1] I've added a %license, bumped the Release, and added a changelog. fedpkg builds for rawhide are okay, as are the x86_64 builds for f22, but i686 builds are failing, Apparently with (from [2] root.log and

Re: Broken dependencies: vdsm

Posting to -devel because I can't post to vdsm-owner or virt-maintenance. On 09/15/2014 09:57 AM, Balamurugan Arumugam wrote: [Adding Dan] - Original Message - From: Kaleb S. KEITHLEY kkeit...@redhat.com To: Lalatendu Mohanty lmoha...@redhat.com, build...@fedoraproject.org, vdsm-ow

Re: Broken dependencies: vdsm

Posting to -devel because I can't post to vdsm-owner or virt-maintenance. On 09/15/2014 10:09 AM, Kaleb S. KEITHLEY wrote: gluster server. AFAIK it's a mistake for vdsm to have these as dependencies. Correcting myself. glusterfs-cli is okay, and should, AFAIK, be in RHEL6, although I'm

Re: Incorrect order of /usr/bin and /usr/sbin in path

On 05/05/2014 10:28 AM, Adam Jackson wrote: On Sun, 2014-05-04 at 18:59 +0200, Reindl Harald wrote: however, the semantics of /usr/sbin is to contain superuser binaries which should not be overriden because a binary with the same name exists in /usr/bin My memory is that the s was more for

Re: Incorrect order of /usr/bin and /usr/sbin in path

On 05/05/2014 10:43 AM, Lennart Poettering wrote: /usr/sbin is an invention of Linux. Strange that you would claim this. Here's a list of what's in /usr/sbin on NetBSD 1.0 (and there's no overlap between what's in /usr/sbin and any other subdir.) drwxr-xr-x root/wheel 0

review swap — nfs-ganesha

nfs-ganesha is a user-mode NFS v4 server. GlusterFS will use nfs-ganesha for it's NFSv4 implementation. https://bugzilla.redhat.com/show_bug.cgi?id=1026337 -- Kaleb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of

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

Re: how to withdraw glusterfs from epel?

On 10/18/2013 09:55 AM, Paul Howarth wrote: On 18/10/13 13:38, Kaleb S. KEITHLEY wrote: 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

Re: how to withdraw glusterfs from epel?

On 10/18/2013 10:54 AM, Steve Gordon wrote: Would it be against the guidelines to move to packaging it (the software itself, not a repo file) in Fedora/EPEL as glusterfs-community? I'm sure it is against the guidelines. Under any name it'd still be shipping a set of RPMs that conflict

BUG 1003089 - Review Request: glusterfs-openstack-swift

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

f20 systemd rpm isn't signed!

FYI, 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.) -- Kaleb -- devel mailing list devel@lists.fedoraproject.org

Fwd: promoting to package co-maintainers?

Flock is over. How about some action on my ticket? Or reject the ticket and tell me why! Original Message Subject: promoting to package co-maintainers? Date: Mon, 12 Aug 2013 08:31:13 -0400 From: Kaleb S. KEITHLEY kkeit...@redhat.com To: Development discussions related

promoting to package co-maintainers?

Hi 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

Re: promoting to package co-maintainers?

On 08/12/2013 09:46 AM, Mathieu Bridon wrote: Hi, On Monday, August 12, 2013 08:31 AM, Kaleb S. KEITHLEY wrote: 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

Re: systemd network-online.target question

On 07/16/2013 11:24 AM, Lennart Poettering wrote: On Tue, 16.07.13 11:12, Kaleb KEITHLEY (kkeit...@redhat.com) wrote: 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

Re: systemd network-online.target question

On 07/17/2013 07:47 AM, Kaleb S. KEITHLEY wrote: But a user who tried that says the local nfs mount(s) in his /etc/fstab still failed. I tried it as well with an f19 guest vm and got the same results, namely that the nfs mount(s) failed to mount at boot. Answering my own question. I did some

-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

taking over ownership of glusterfs

Matthias Saou has released ownership so that I can take over. http://fedoraproject.org/wiki/Package_SCM_admin_requests indicates that I can use the https://admin.fedoraproject.org/pkgdb to request ownership changes, but I don't see any way to do this. Am I not looking in the right place? It

Re: taking over ownership of glusterfs

On 01/18/2013 09:10 AM, Jon Ciesla wrote: On Fri, Jan 18, 2013 at 7:45 AM, Kaleb S. KEITHLEY kkeit...@redhat.com mailto:kkeit...@redhat.com wrote: Matthias Saou has released ownership so that I can take over. http://fedoraproject.org/wiki/__Package_SCM_admin_requests http

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). -- Kaleb -- devel mailing list devel@lists.fedoraproject.org

Re: sys/sysctl.h and bits/sysctl.h in rawhide/f18?

On 05/31/2012 02:00 PM, Jim Meyering wrote: Kaleb Keithley wrote: About a week ago I did a scratch build of one of my packages that includessys/sysctl.h and it built successfully. Today I did another scratch build and it broke with: ... Making all in src CC fuse-helpers.lo CC

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

Re: glusterfs rename

On 05/30/2012 12:44 PM, Richard W.M. Jones wrote: To be honest it's a pain in the neck to deal with such packages, and unless there's an overwhelming need, I can't recommend it. Does any user really need to parallel install both versions of glusterfs? No, and in fact that would not work.

Re: glusterfs rename

On 05/30/2012 01:08 PM, Kaleb S. KEITHLEY wrote: On 05/30/2012 12:44 PM, Richard W.M. Jones wrote: To be honest it's a pain in the neck to deal with such packages, and unless there's an overwhelming need, I can't recommend it. Does any user really need to parallel install both versions

Re: glusterfs rename

On 05/30/2012 01:25 PM, Peter Robinson wrote: And FWIW, doing nothing doesn't resolve the glusterfs in EPEL versus glusterfs in the RHS Channel issue. That's a different story entirely, and why would you want gluster in EPEL when it's already in RHEL? What's the difference? This has been

Re: glusterfs rename

On 05/30/2012 01:34 PM, Kaleb S. KEITHLEY wrote: On 05/30/2012 01:25 PM, Peter Robinson wrote: And FWIW, doing nothing doesn't resolve the glusterfs in EPEL versus glusterfs in the RHS Channel issue. That's a different story entirely, and why would you want gluster in EPEL when it's

Re: glusterfs rename

On 05/30/2012 02:23 PM, Peter Robinson wrote: Yes, for the Fedora side of things I think gluster 3.2 is the best strategy with a fedorapeople repo of 3.3 if it's considered worthwhile for those that wish to play. For gluster 3.3 I suggest a feature page for F-18 / rawhide. Is it feasible for the

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? -- Kaleb -- devel mailing list

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

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

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

On 11/23/2011 10:08 AM, Orion Poplawski wrote: On 11/23/2011 07:57 AM, Kaleb S. KEITHLEY wrote: I can build glusterfs fine on real RHEL6.1 using rpmbuild, both x86_64 and i686 with `rpmbuild -bb ...` and `rpmbuild -bb --target=i686 ...` respectively. I can also build using mock, both x86_64

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

Re: openssh-server in F16ga

On 11/09/2011 11:15 AM, Jóhann B. Guðmundsson wrote: On 11/09/2011 04:07 PM, Kaleb S. KEITHLEY wrote: 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

Re: F17 heads up: gnome-shell for everyone!

Tell us again where to find that gnome shell for dummies doc? I tried to give it a fair trial, but I found it so non-intuitive/counter-intuitive that I gave up after an hour and switched to Forced Fallback Mode. -- devel mailing list devel@lists.fedoraproject.org

convert init.d to systemd, how to determine which python is installed

HekaFS runs a daemon from init. It's a Bottle (python-based) http server. In order to work on, e.g. RHEL6 in addition to Fedora, the old init script has: ... vercmd=from distutils.sysconfig import get_python_lib; print get_python_lib() py_dir=$(python -c ${vercmd}) exe=${py_dir}/hekafsd.py ...

converting init.d to systemd, koji (scratch) builds fail

I looked at other spec files with systemd .system files. The relevant part of my spec file is: ... %files server ... %if 0%{?fedora} 17 # Legacy init %{_sysconfdir}/init.d/glusterd %{_sysconfdir}/init.d/glusterfsd %else %{_unitdir}/glusterd.service %{_unitdir}/glusterfsd.service %endif ... and

glusterfs and hekafs release number for f16 and rawhide; systemd switch-over

Up to now the glusterfs and hekafs versions and releases have been the same for f16 and rawhide, i.e.: glusterfs-3.2.4-1.x86_64.fc16.rpm, glusterfs-3.2.4-1.x86_64.fc17.rpm, hekafs-0.7-16.x86_64.fc16.rpm, and hekafs-0.7-16.x86_64.fc17.rpm. I did that because the source, thus far, is exactly

Re: GNOME 3 - font point sizes now scaled?

On 10/04/2011 09:36 AM, Jason D. Clinton wrote: On Tue, Oct 4, 2011 at 04:01, Camilo Mesiascam...@mesias.co.uk wrote: On Mon, Oct 3, 2011 at 5:22 PM, Ralf Corsepiusrc040...@freenet.de wrote: The XP I occasionally can not avoid to use, in its system control menus has controls to switch

yum update btrfs-progs failing on F16alpha

I've got an F16alpha kvm guest installed from scratch a few days ago. Today I tried a `yum update` (with --disablerepo=updates-testing) which failed. By trial and error I determined that it is btrfs-progs, trying to update from 0.19-13.fc15 to 0.19-16.fc15, that fails with: warning:

Re: rawhide report: 20110823 changes

On 08/23/2011 08:40 AM, Rawhide Report wrote: Compose started at Tue Aug 23 08:15:54 UTC 2011 Broken deps for x86_64 -- ... cloudfs-0.7-6.fc17.x86_64 requires glusterfs = 0:3.2.1 ... How do I get cloudfs out of rawhide/f17?

Re: Attention: F16 packages needing rebuilds due to the trailing slash bug of rpm-4.9.1

On 08/17/2011 05:51 AM, Panu Matilainen wrote: Hi all, Due to the brown paperbag bug of rpm-4.9.1 causing unwanted trailing slashes on directories (with various nasty side-effects), the following packages in F16 require rebuilding. The sooner the better to stop spreading the damage but at

questions about adding glusterfs and hekafs to comps-f16.xml

metaglusterfs is a clustering file system consisting of a management daemon and one or more instances of servers for each 'brick' in the cluster. hekafs is an add-on for glusterfs that adds cloud attributes such as multi-tenancy, encryption, and authentication./meta I suppose the first

review swap

Already approved once. Just need a quick re-review of the rename and the added Obsoletes: Original Message Subject: package re-review needed — CloudFS name change to HekaFS Date: Mon, 08 Aug 2011 10:40:20 -0400 From: Kaleb S. KEITHLEY kkeit...@redhat.com To: devel

package re-review needed — CloudFS name change to HekaFS

Re-review needed after package name change and added Obsoletes: Will swap a review. bz: https://bugzilla.redhat.com/show_bug.cgi?id=675050 Spec URL: http://cloudfs.org/dist/0.7/hekafs.spec SRPM URL: http://cloudfs.org/dist/0.7/hekafs-0.7-7.fc15.src.rpm Thanks, -- -- devel mailing list