two builds stuck in pending testing for nine days

[Kaleb S. KEITHLEY]

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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Kaleb S. KEITHLEY]

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 maintainer, I'm happy to give
it up.

LMK.

--

Kaleb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Kaleb S. KEITHLEY]

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 without any warning. I only found out about it when
I got build notices from koji (or pagure or whatever.)

You would have preferred no notice at all?

>> 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.)
> 
> As others have asked in the thread can we possibly build client only?

We?

Since the above seems to have been unclear:

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

--

Kaleb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Kaleb S. KEITHLEY]

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 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.
>>
>> BTW - how much memory is needed to build Ceph 14?

More — apparently — than the armv7hl builders have. :-) branto may know.

> have you tried building with reduced debuginfo, eg. -g1 or even -g0?

branto told me that he has tried all the different optimization levels.

> I wonder how much broken deps it will cause.

Don't know. Hence this heads up warning.

-- 

Kaleb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Kaleb S. KEITHLEY]

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

-- 

Kaleb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

enabling KCM in the Fedora kernels

[Kaleb S. KEITHLEY]

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 list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JSO5CKPO2GIDS77WLWHVVMRX7MJ5424S/

build failed on s390x, other archs building okay

[Kaleb S. KEITHLEY]

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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/O2BNTIJT3KVZIZN4UO2JKSPXFOSTV6LI/

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

[Kaleb S. KEITHLEY]

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 twisty passages. Or maybe at's a twisty maze of passages.
How do I find where release-monitoring is actually looking?

Thanks,

-- 

Kaleb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Kaleb S. KEITHLEY]

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
> 
> You can do so.

I think you misunderstood what I was asking.

I'm fine with getting _one_ notification. Or maybe even five.

But I have probably 50 in my inbox after all was said and done. All from
one build.


> 
> Go to:
> 
> https://apps.fedoraproject.org/notifications
> 
> login and select email
> 
> There should be a ruleset on the right called:
> "Events on packages I own"
> 
> Click on it to edit it.
> 
> On the right now there should be a long list of possible messages, one
> of them is "Greenwave decisions"
> 
> Click on "Greenwave decisions" and then "add this rule"
> 
> Now there should be a "Greenwave decisions" rule on the left in your
> ruleset.
> 
> Under that is a "!Negate" button. Click on that to make the rule be a
> negation rule instead of a matching rule.
> 
> Now you should no longer get any greenwave emails.
> 
> Sorry this is so confusing an interface. It really needs a re-write with
> input from some design folks, but we just haven't had the cycles to do
> so yet.
> 
> kevin
> 
> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Kaleb S. KEITHLEY]

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 devel-le...@lists.fedoraproject.org

Re: f28 and rawhide ignoring static ip settings

[Kaleb S. KEITHLEY]

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 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
>> ...
>> IPADDR=192.168.122.26
>>
>> But it's getting 192.168.122.169 (from dhcp?)
> 
>   Could you double check if your interface is still called 'ens3'?
> There's a bug in latest systemd which breaks interface naming:
> https://github.com/systemd/systemd/issues/8446

It's not. Now it's enp0s3.

And renaming /etc/sysconfig/network-scripts/ifcfg-ens3 to ifcfg-enp0s3
doesn't do anything.

Thanks

--

Kaleb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

f28 and rawhide ignoring static ip settings

[Kaleb S. KEITHLEY]

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

--

Kaleb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Kaleb S. KEITHLEY]

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?

--

Kaleb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: LizardFS NFS Ganesha integration with no shared library available

[Kaleb S. KEITHLEY]

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)
>>
>> The latest release of the LizardFS distributed filesystem includes a
>> FSAL for NFS Ganesha, allowing you to mount a LizardFS filesystem using
>> NFS (or pNFS, if you prefer).
> 
> The LizardFS FSAL is GPLv3.  NFS-Ganesha is LGPLv3+.
> 
> From a Fedora packaging standpoint is it acceptable to build a GPLv3
> plug-in for an otherwise LGPLv3+ binary?
> 
> If the licenses were reversed, I'd be reasonably confident that that
> combination is okay.
> 
> What sayeth our "I'm not a lawyer but I play one on Fedora Devel mailing
> list" legal beagles?

And yes, I've already sent a query to a Real Lawyer™

-- 

Kaleb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: LizardFS NFS Ganesha integration with no shared library available

[Kaleb S. KEITHLEY]

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 Ganesha, allowing you to mount a LizardFS filesystem using
> NFS (or pNFS, if you prefer).

The LizardFS FSAL is GPLv3.  NFS-Ganesha is LGPLv3+.

From a Fedora packaging standpoint is it acceptable to build a GPLv3
plug-in for an otherwise LGPLv3+ binary?

If the licenses were reversed, I'd be reasonably confident that that
combination is okay.

What sayeth our "I'm not a lawyer but I play one on Fedora Devel mailing
list" legal beagles?

Thanks

-- 

Kaleb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: LizardFS NFS Ganesha integration with no shared library available

[Kaleb S. KEITHLEY]

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 Ganesha, allowing you to mount a LizardFS filesystem using
> NFS (or pNFS, if you prefer).
> 
> Unfortunately, NFS Ganesha doesn't provide a library to build the
> LizardFS FSAL against, so LizardFS upstream downloads the complete NFS
> Ganesha source and builds against that.
> 
> As far as I can see, all the other FSAL's are maintained and built in
> NFS Ganesha.
> 
> What is the best way for me to include NFS Ganesha support in LizardFS?
>1. Include the latest Fedora NFS Ganesha source and add a hard requires
>   to that version in the LizardFS NFS subpackage.
>2. Convince the LizardFS developers to try to move their FSAL into NFS
>   Ganesha? (LizardFS has just added a client library and doesn't have
>   a server library, so this will probably take some work)

That would be the path of least resistance. And the one I would suggest
and highly recommend. If they've already written a FSAL it should be
easy to add it to the nfs-ganesha source.

Depending on the license of course.


>3. Convince the NFS Ganesha developers to create a library that you can
>   compile FSAL's against?  (The last thread I saw in the NFS Ganesha
>   devel list on this subject was six years old)

That would be a non-trivial amount of work with little benefit to the
current FSAL developers.

It's not an unreasonable request, per se, but we have other, higher
priorities.

>4. ???
> 
> Any advice would be great, as I'd love to get this feature into
> Fedora's release of LizardFS.

Do you have a contact for someone at LizardFS?  I looked at their web
site and nothing popped out at me.

-- 

Kaleb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

glusterfs in Fedora Modular 27?

[Kaleb S. KEITHLEY]

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 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? Was I supposed to request a
-module branch in dist-git?

Thanks,

--

Kaleb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

sysconf(_SC_IOV_MAX) returns -1 in f27 and f28/rawhide (glibc-2.26-8)

[Kaleb S. KEITHLEY]

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? Or want to venture a guess?

Thanks

--

Kaleb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] retiring Ceph in EPEL-7

[Kaleb S. KEITHLEY]

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 registered
in the overall karma somehow. (Last version shipped in epel was 0.80.7.)

What's the next step?

Do I push it to stable and then retire it as soon as it gets pushed?

Just retire it now?

Something else?

Thanks,

-- 

Kaleb
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

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

[Kaleb S. KEITHLEY]

switching to rdma-core-devel also fails.

because according to 
https://koji.fedoraproject.org/koji/buildinfo?buildID=953605 there are 
no armv7hl rpms built.


Probably due to the
  # 32-bit arm is missing required arch-specific memory barriers,
  ExcludeArch: %{arm}
in its .spec file

Which seems odd considering we've had IB/RDMA on armv7hl thus far. But 
if that's really the case then the solution is clear.


Also rdma-core hasn't been built for f28 yet!




On 08/22/2017 07:12 AM, Vít Ondruch wrote:



Dne 22.8.2017 v 12:48 Peter Robinson napsal(a):

On Tue, Aug 22, 2017 at 11:36 AM, 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 matching package to install: 'libibverbs-devel'
DEBUG util.py:439:  No matching package to install: 'librdmacm-devel >=
1.0.15'

For some reason the owner in f27 tag was switched to releng and then
has been blocked:

Sat Aug 19 03:43:40 2017 package list entry for librdmacm in
module-package-list updated by pkgdb
 owner.name: dledford -> releng
Sat Aug 19 06:20:14 2017 librdmacm-1.1.0-4.fc26 untagged from f27 by releng
Sat Aug 19 06:20:14 2017 librdmacm-1.1.0-6.fc27 untagged from f27 by releng
Sat Aug 19 06:20:31 2017 package list entry for librdmacm in f27
updated by releng
 blocked: False -> True

Sat Aug 19 06:20:17 2017 libibverbs-1.2.1-4.fc26 untagged from f27 by releng
Sat Aug 19 06:20:17 2017 libibverbs-1.2.1-6.fc27 untagged from f27 by releng
Sat Aug 19 06:20:31 2017 package list entry for libibverbs in f27
updated by releng
 blocked: False -> True

I'm not sure why that is because it wasn't blocked for f28 because
both of those packages look to be replaced by rdma-core looking at one
of the commit logs

https://src.fedoraproject.org/rpms/libibverbs/c/bd306d2c33fadaf21dafb1351730a0c59052aed1?branch=master

It looks like the maintainer or the person that retired those packages
hasn't added the proper retires/provides into the rdma-core* packages
to ensure the upgrade path is smooth.


See the other thread:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/WJHXQ3G6H7UMVERDCMUXBYDJTFABTGW3/

V.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Kaleb S. KEITHLEY]

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,

--

Kaleb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Kaleb S. KEITHLEY]

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 what a user needs 
to do to get newer versions. A /usr/share/docs/ceph/upstream-ceph.repo 
may also be useful. [Putting in a Summary that the package is deprecated 
may also be useful.]



Update the package with a README.deprecated?

IOW add a README.deprecated file in dist-git, add it to the %doc in 
ceph.spec, and build+update version 0.80.7 (the current epel7 version) 
of the package.


If that's the case, consider this as the announcement that this is going 
to happen shortly.




2. Announce on epel-devel and epel-announce this is going to happen.
2. push the update out to users.
3. orphan the package in EPEL
4. remove it after a month after the update went to stable.

We also need to look at coming up with tools and a process to better 
look at packages we have in the repository so we don't make both the 
maintainer (aka Kaleb) and the users lifes miserable.


Does the above sound reasonable ?


--
Stephen J Smoogen.



___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

librpm.so.7, deltarpm-3.6.{21,22} and building ceph on rawhide

[Kaleb S. KEITHLEY]

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 things in an temporarily inconsistent state? I only 
noticed the warning that rpm-4.14 is coming soon.


Thanks,

--

Kaleb

[1] https://kojipkgs.fedoraproject.org//work/tasks/1690/21151690/root.log
[2] https://kojipkgs.fedoraproject.org//work/tasks/3722/21153722/root.log
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Kaleb S. KEITHLEY]

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 rpms for RHEL and CentOS is from the CentOS
Storage SIG.

If I failed somehow to fully retire glusterfs from EPEL, please let me
know so that I can clean up any remaining bits that I missed the first
time around.

Regards,

-- 

Kaleb
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

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

[Kaleb S. KEITHLEY]

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 tomorrow, but I believe that the 
plan would be something like the following:




And what was the decision?





1. "Update" the current package with README.deprecated explaining why 
the package is being removed from the repository and what a user needs 
to do to get newer versions. A /usr/share/docs/ceph/upstream-ceph.repo 
may also be useful. [Putting in a Summary that the package is deprecated 
may also be useful.]

2. Announce on epel-devel and epel-announce this is going to happen.
2. push the update out to users.
3. orphan the package in EPEL
4. remove it after a month after the update went to stable.

We also need to look at coming up with tools and a process to better 
look at packages we have in the repository so we don't make both the 
maintainer (aka Kaleb) and the users lifes miserable.


Does the above sound reasonable ?


--
Stephen J Smoogen.



___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

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

[Kaleb S. KEITHLEY]

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 what a user needs 
to do to get newer versions. A /usr/share/docs/ceph/upstream-ceph.repo 
may also be useful. [Putting in a Summary that the package is deprecated 
may also be useful.]

2. Announce on epel-devel and epel-announce this is going to happen.
2. push the update out to users.
3. orphan the package in EPEL
4. remove it after a month after the update went to stable.

We also need to look at coming up with tools and a process to better 
look at packages we have in the repository so we don't make both the 
maintainer (aka Kaleb) and the users lifes miserable.


Does the above sound reasonable ?



Yes. That would be wonderful IMO.

--

Kaleb
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

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

[Kaleb S. KEITHLEY]

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 -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

ppc64le build failure, does it look familiar?

[Kaleb S. KEITHLEY]

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 ppc64le --nodeps /builddir/build/SPECS/ceph.spec'] with env
{'SHELL': '/bin/bash', 'PROMPT_COMMAND': 'printf
"\\033]0;\\007"', 'HOME': '/builddir', 'HOSTNAME': 'mock',
'PS1': ' \\s-\\v\\$ ', 'LANG': 'en_US.UTF-8', 'TERM':
'vt100', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin'} and shell False
/usr/bin/lua: error loading module 'posix.ctype' from file
'/usr/lib64/lua/5.3/posix.so':
/lib64/librt.so.1: expected localentry:0 `pthread_attr_setdetachstate'
stack traceback:
[C]: in ?
[C]: in function 'require'
/usr/share/lua/5.3/posix/init.lua:29: in main chunk
[C]: in function 'require'
/usr/share/lmod/lmod/libexec/addto:64: in main chunk
[C]: in ?
/usr/bin/lua: error loading module 'posix.ctype' from file
'/usr/lib64/lua/5.3/posix.so':
/lib64/librt.so.1: expected localentry:0 `pthread_attr_setdetachstate'
stack traceback:
[C]: in ?
[C]: in function 'require'
/usr/share/lua/5.3/posix/init.lua:29: in main chunk
[C]: in function 'require'
/usr/share/lmod/lmod/libexec/addto:64: in main chunk
[C]: in ?
/usr/bin/lua: error loading module 'posix.ctype' from file
'/usr/lib64/lua/5.3/posix.so':
/lib64/librt.so.1: expected localentry:0 `pthread_attr_setdetachstate'
stack traceback:
[C]: in ?
[C]: in function 'require'
/usr/share/lua/5.3/posix/init.lua:29: in main chunk
[C]: in function 'require'
/usr/share/lmod/lmod/libexec/addto:64: in main chunk
[C]: in ?
/usr/bin/ps: error while loading shared libraries: /lib64/librt.so.1:
expected localentry:0 `pthread_attr_setdetachstate'
/usr/bin/basename: missing operand
Try '/usr/bin/basename --help' for more information.
Building target platforms: ppc64le
...

Full build log at
https://kojipkgs.fedoraproject.org//work/tasks/6424/20856424/build.log

Look familiar to anyone?

Thanks,

-- 

Kaleb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: armv7hl builds running out of memory

[Kaleb S. KEITHLEY]

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 -j1"), I could always get a build to 
work, albeit slowly.

It turns out there is a typo in the spec file; look for the string "WTIH_BABELTRACE" -- that should be 
"WITH_BABELTRACE".  In the environment I'm using, "make -j32" is the default state.  If I leave the 
typo alone and do not change the "make -j32", I can pretty consistently get the ceph build to fail; the 
failure moves around a bit but generally seems to hang around with where the babeltrace headers are being used 
(somewhere in RBD code, usually).  If I fix the typo -- and change nothing else -- the build succeeds.

Would you mind trying this one change -- fixing the typo *only* -- and see if 
you get the same results?


If by same result you mean the build still fails, then yes. I get the 
same result.


It's still running out of memory. Not the same way as the prior builds 
though.


...
[100%] Building CXX object src/rgw/CMakeFiles/radosgw.dir/rgw_main.cc.o
/usr/include/c++/7/bits/stl_map.h: In static member function 'static 
void 
pg_missing_set::generate_test_instances(std::__cxx11::list&) 
[with bool TrackChanges = false]':
/usr/include/c++/7/bits/stl_map.h:493:4: note: parameter passing for 
argument of type 'std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::const_iterator {aka 
std::_Rb_tree_const_iterator}' changed in GCC 7.1

__i = _M_t._M_emplace_hint_unique(__i, std::piecewise_construct,
^~~
virtual memory exhausted: Operation not permitted
...
make: *** [Makefile:141: all] Error 2
RPM build errors:
error: Bad exit status from /var/tmp/rpm-tmp.RgosXb (%build)
Bad exit status from /var/tmp/rpm-tmp.RgosXb (%build)
Child return code was: 1
...

See https://koji.fedoraproject.org/koji/taskinfo?taskID=20797264 for 
full logs.


--

Kaleb


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: armv7hl builds running out of memory

[Kaleb S. KEITHLEY]

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"
…

Sometimes piping from cpp to gcc to as to ld takes too much memory on 32 
Bit arches…


Unfortunately that didn't help.

FWIW the actual edits to the ceph.spec that I used (since ceph uses 
cmake and other factors):


...
export RPM_OPT_FLAGS=`echo $RPM_OPT_FLAGS | sed -e 's/i386/i486/' -e 
's/-pipe//g'`


export CPPFLAGS="$java_inc"
export CFLAGS="$RPM_OPT_FLAGS"
export CXXFLAGS="$RPM_OPT_FLAGS"
export LDFLAGS=`echo $LDFLAGS | sed -e 's/-pipe//g'`
...

--

Kaleb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

armv7hl builds running out of memory

[Kaleb S. KEITHLEY]

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
https://kojipkgs.fedoraproject.org//work/tasks/4038/20724038/build.log

Is there any way to bump up swap on the builders? Or any trick to get
more memory or run on a particular machine that has more memory?

Thanks


-- 

Kaleb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Do I need to do a Self Contained Change to update Ceph to Ceph 12 in fedora-27?

[Kaleb S. KEITHLEY]

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] https://kojipkgs.fedoraproject.org//work/tasks/1128/20631128/build.log
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Kaleb S. KEITHLEY]

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 devel-le...@lists.fedoraproject.org

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

[Kaleb S. KEITHLEY]

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.

2) Uncrippled nfs-ganesha packages with GlusterFS (and Ceph too, if I'm
not mistaken) are distributed from the CentOS Storage SIG.

nfs-ganesha is the only consumer of libntirpc.

If nobody objects I will begin the process of retiring them in a few days.

Thanks,

-- 

Kaleb
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

fedpkg update is failing

[Kaleb S. KEITHLEY]

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 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 kkeit...@fedoraproject.org

Any ideas?

Thanks,

--

Kaleb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Is there something wrong with the Koji builders?

[Kaleb S. KEITHLEY]

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

two package reviews

[Kaleb S. KEITHLEY]

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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: rawhide vs koji f26 builds

[Kaleb S. KEITHLEY]

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


From the log:

keys.c:121:11: error: storage size of 'hctx' isn't known
  HMAC_CTX hctx;
   ^~~~

Probably needs patching for openssl 1.1 that just landed in rawhide.



Sure, but I just installed a rawhide box from 
Fedora-Server-netinst-x86_64-Rawhide-20161010.n.0.iso and it still has 
openssl-1.0.2j-1.fc26.x86_64 and a `dnf update openssl` is not giving me 
anything newer.


I guess I can go get 
Fedora-Server-netinst-x86_64-Rawhide-20161011.n.0.iso or install the 
rpms from http://koji.fedoraproject.org/koji/buildinfo?buildID=809049.


--

Kaleb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: rawhide vs koji f26 builds

[Kaleb S. KEITHLEY]

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


Can you reference the root task, can''t get that from the link above
so it's hard to tell all the details with just a snippet.




http://koji.fedoraproject.org/koji/taskinfo?taskID=16059121





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,

--

Kaleb



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

rawhide vs koji f26 builds

[Kaleb S. KEITHLEY]

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

--

Kaleb



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

enable ABRT reports for glusterfs

[Kaleb S. KEITHLEY]

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,

-- 

Kaleb
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Kaleb S. KEITHLEY]

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
>>
>> 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
>> builds for f25.
> 
> Did you do a git pull to bring down the new f24 branch?  I think that is what
> fedpkg keys off of.
> 

Yes. I'm not a git expert by any means, but I do know that much. ;-)

-- 

Kaleb
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Kaleb S. KEITHLEY]

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 glusterfs-3.7.8-1.fc24 has already
>>> been built
>>>
>>> Am I just too early? Or is there something missing that's preventing
>>> builds for f25.
>>
>> The branching is ongoing, there was infrastructure issues last night
>> so it's taken a bit longer than planned.
>>
>>> 2) Despite several articles out in the wild claiming that {F22,F23,F24}
>>> will switch to Python3 as the default, [1] would seem to indicate that
>>> the only thing we're going to see is 1) the update of Python3 from 3.4
>>> to 3.5, and 2) Python3 system-python and system-python-libs will be
>>> split out; however the default python will remain Python2.
>>>
>>> Is that correct?
>>
>> Not really, py3 is the default by means of being the only python
>> shipped in a number of Fedora deliverables but there's also some that
>> can't move directly to pure python3 yet due to other issues (like
>> ansible only bein py2 at the moment). So it's a "it depends" answer.
> 
> 
> To supplement this, it's the default in the sense that packagers are
> expected to ship python3 packages if they are supported upstream and if
> the package includes the same binary executable name for py2 and py3,
> only the py3 package should ship it.

I guess I don't really grok what that means. And/or I didn't frame my
question very well.

I installed a fresh rawhide Fedora/Server two days ago.

It has both python-2.7.11-4.fc24.x86_64 and python3-3.5.1-4.fc24.x86_64.
 /usr/bin/python is a symlink to python2.

Under what circumstances will /usr/bin/python be Python3?

Thanks

-- 

Kaleb
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Kaleb S. KEITHLEY]

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
builds for f25.


2) Despite several articles out in the wild claiming that {F22,F23,F24}
will switch to Python3 as the default, [1] would seem to indicate that
the only thing we're going to see is 1) the update of Python3 from 3.4
to 3.5, and 2) Python3 system-python and system-python-libs will be
split out; however the default python will remain Python2.

Is that correct?


3) The Fedora and upstream glusterfs.spec file package example rsyslog
config files for some distributions. (Although since Fedora hasn't used
rsyslog by default since F20 or so, these aren't actually installed on
recent Fedora releases.) The packaging guidelines don't appear to say
anything on the topic. Absent anything in the packaging guidelines, is
there a consensus for where they should be installed on systems that do
use rsyslog, e.g. EPEL/EL6?

In /etc/rsyslog.d/glusterfs.conf.example? Or somewhere else, e.g.
/usr/share/doc/glusterfs/rsyslog.d/glusterfs.conf.example?


[1] https://fedoraproject.org/wiki/Releases/24/ChangeSet

Thanks,

-- 

Kaleb
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Kaleb S. KEITHLEY]

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 to see if any packages you own are on the list, you can do:
> 
> wget 
> https://raw.githubusercontent.com/atodorov/fedora-scripts/master/checksec.log
> for i in $(pkgdb-cli list --user tibbs --nameonly); do grep "^$i.*rpm$" 
> checksec.log|uniq; done
> 

GlusterFS packages have seven "No canary found" [1]. I get the same
results with gcc-5.1.1 on f22.

However GlusterFS _is_ built with '%global _hardened_build 1' and I have
confirmed that all its sources are compiled with -fstack-protector-strong.

As I read the gcc man page for -fstack-protector,
-fstack-protector-strong, and -fstack-protector-all, it's clear that
with just -fstack-protector-strong it's entirely plausible that these
DSOs would not have the call to __stack_chk_fail, i.e. the canary.

If I compile them with -fstack-protector-all then the resulting .o and
.so files _do_ have the call to __stack_chk_fail.

Off hand I'd say that checksec's test for the canary is wanting.

The glusterfs packages need to be excluded. Or change _hardened_build to
use -fstack-protector-all.


[1] excerpted from
https://raw.githubusercontent.com/atodorov/fedora-scripts/master/checksec.log

...
--
glusterfs-3.7.4-2.fc24.src.rpm
/mnt/fedora/Packages/g/glusterfs-api-3.7.4-2.fc24.x86_64.rpm
RELRO   STACK CANARY  NXPIE RPATH
   RUNPATH  FILE
Full RELRO  No canary found   NX enabledDSO No RPATH
  No RUNPATH   ./usr/lib64/glusterfs/3.7.4/xlator/mount/api.so



--
glusterfs-3.7.4-2.fc24.src.rpm
/mnt/fedora/Packages/g/glusterfs-client-xlators-3.7.4-2.fc24.x86_64.rpm
RELRO   STACK CANARY  NXPIE RPATH
   RUNPATH  FILE
Full RELRO  No canary found   NX enabledDSO No RPATH
  No RUNPATH   ./usr/lib64/glusterfs/3.7.4/xlator/features/ganesha.so



--
glusterfs-3.7.4-2.fc24.src.rpm
/mnt/fedora/Packages/g/glusterfs-extra-xlators-3.7.4-2.fc24.x86_64.rpm
RELRO   STACK CANARY  NXPIE RPATH
   RUNPATH  FILE
Full RELRO  No canary found   NX enabledDSO No RPATH
  No RUNPATH   ./usr/lib64/glusterfs/3.7.4/xlator/encryption/rot-13.so
Full RELRO  No canary found   NX enabledDSO No RPATH
  No RUNPATH   ./usr/lib64/glusterfs/3.7.4/xlator/features/prot_dht.so
Full RELRO  No canary found   NX enabledDSO No RPATH
  No RUNPATH   ./usr/lib64/glusterfs/3.7.4/xlator/features/prot_server.so
Full RELRO  No canary found   NX enabledDSO No RPATH
  No RUNPATH   ./usr/lib64/glusterfs/3.7.4/xlator/features/quiesce.so
Full RELRO  No canary found   NX enabledDSO No RPATH
  No RUNPATH
./usr/lib64/glusterfs/3.7.4/xlator/testing/features/template.so


...


-- 

Kaleb
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

something wrong with f22 fedpkg builds on i686 of nfs-ganesha?

[Kaleb S. KEITHLEY]

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 similar error in mock_output.log)

...
DEBUG util.py:388:  error: db5 error(-30969) from dbenv-open: BDB0091 
DB_VERSION_MISMATCH: Database environment version mismatch

DEBUG util.py:388:  error: cannot open Packages index using db5 -  (-30969)
DEBUG util.py:388:  error: cannot open Packages database in /var/lib/rpm
DEBUG util.py:388:  error: db5 error(-30969) from dbenv-open: BDB0091 
DB_VERSION_MISMATCH: Database environment version mismatch

DEBUG util.py:388:  error: cannot open Packages index using db5 -  (-30969)
DEBUG util.py:388:  error: cannot open Packages database in /var/lib/rpm
...

Thoughts?

[1] https://koji.fedoraproject.org/koji/buildinfo?buildID=629814
[2] http://koji.fedoraproject.org/koji/taskinfo?taskID=9754950

--

Kaleb
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Broken dependencies: vdsm

[Kaleb S. KEITHLEY]

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...@fedoraproject.org
Cc: glusterfs-ow...@fedoraproject.org
Sent: Monday, September 15, 2014 4:54:50 PM
Subject: Re: Broken dependencies: vdsm

On 09/15/2014 04:39 AM, Lalatendu Mohanty wrote:

On 09/14/2014 09:58 AM, build...@fedoraproject.org wrote:

vdsm has broken dependencies in the epel-6 tree:
 vdsm-4.16.4-0.el6.ppc64 requires glusterfs-rdma
 vdsm-4.16.4-0.el6.ppc64 requires glusterfs-fuse
 vdsm-4.16.4-0.el6.ppc64 requires glusterfs-cli
 vdsm-4.16.4-0.el6.ppc64 requires glusterfs-api
 vdsm-4.16.4-0.el6.ppc64 requires glusterfs = 0:3.4.2
 vdsm-4.16.4-0.el6.ppc64 requires fence-agents
On x86_64:
 vdsm-gluster-4.16.4-0.el6.noarch requires glusterfs-server
On ppc64:
 vdsm-gluster-4.16.4-0.el6.noarch requires glusterfs-server


Just to add, Glusterfs (Server and Client) bits are not available in
EPEL because GlusterFS RPMs (client RPMs) are available in RHEL base
channel. Not sure how to fox this issue.


To expand on Lala's comment, everything above _except_ glusterfs-cli and
glusterfs-server are in RHEL.

No part of glusterfs is in EPEL.

Why does vdsm now require glusterfs-cli and glusterfs-server? It didn't
use to AFAIK.




gluster storage domain in vdsm uses glusterfs-cli for mounting gluster volume.


Huh? The glusterfs-cli RPM has /usr/sbin/gluster and its manpage. That's it.

That's not the command used to mount a gluster volume.

A simple `mount -t glusterfs $server:$volname $mntpoint` is all it 
takes. (Assuming you have glusterfs and glusterfs-fuse RPMs installed.)


glusterfs-server and glusterfs-cli and for people to set up and manage a 
gluster server. AFAIK it's a mistake for vdsm to have these as dependencies.




 But I am not sure about glusterfs-server dependency.

Dan, could you help us resolving the requirement of glusterfs-server package 
dependency for vdsm?

Regards,
Bala



--

Kaleb
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Broken dependencies: vdsm

[Kaleb S. KEITHLEY]

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 not seeing that it is.


glusterfs-server is not in RHEL6, and won't ever be in RHEL6, and AFAIK 
it's a mistake for vdsm to have it as a dependency.


--

Kaleb
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Kaleb S. KEITHLEY]

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 static not superuser.
There's some conceptual overlap, static binaries being there to recover
even if your shared libraries are hosed which is normally a superuser
kind of operation, but.


My recollection is that the s in /sbin and /usr/sbin was more system 
level management. Things an admin would need but would not usually be 
needed by an ordinary user.


Binaries in /bin and /sbin would have been statically linked to aid in 
recovering a system in single-user mode when /usr might not be mounted, 
in the days when disks were so small that /usr might often be a separate 
disk.


--

Kaleb
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Kaleb S. KEITHLEY]

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 1994-10-19 15:16 ./usr/sbin
-r-xr-xr-x bin/bin16384 1994-10-19 15:15 ./usr/sbin/ac
-r-xr-xr-x bin/bin12288 1994-10-19 15:15 ./usr/sbin/accton
-r-xr-xr-x bin/bin81920 1994-10-19 15:15 ./usr/sbin/amd
-r-xr-xr-x bin/bin20480 1994-10-19 15:15 ./usr/sbin/amq
-r-xr-xr-x bin/bin16384 1994-10-19 15:15 ./usr/sbin/arp
-r-xr-xr-x bin/bin20480 1994-10-19 15:16 ./usr/sbin/bad144
-r-xr-xr-x bin/bin40960 1994-10-19 15:15 ./usr/sbin/bootpd
-r-xr-xr-x bin/bin32768 1994-10-19 15:15 ./usr/sbin/bootpef
-r-xr-xr-x bin/bin20480 1994-10-19 15:15 ./usr/sbin/bootpgw
-r-xr-xr-x bin/bin20480 1994-10-19 15:15 ./usr/sbin/bootptest
-r-xr-xr-x bin/bin20480 1994-10-19 15:16 ./usr/sbin/chat
hr-xr-xr-x bin/bin0 1994-10-19 15:15 ./usr/sbin/chown link 
to ./usr/bin/chgrp

-r-xr-xr-x bin/bin12288 1994-10-19 15:15 ./usr/sbin/chroot
-r-xr-xr-x bin/bin32768 1994-10-19 15:15 ./usr/sbin/cron
-r-xr-xr-x bin/bin12288 1994-10-19 15:15 ./usr/sbin/dev_mkdb
-r-xr-xr-x bin/bin16384 1994-10-19 15:15 ./usr/sbin/diskpart
-r-xr-xr-x bin/bin20480 1994-10-19 15:15 ./usr/sbin/edquota
-r-xr-xr-x bin/bin40960 1994-10-19 15:15 ./usr/sbin/fsinfo
-r-xr-xr-x bin/bin16384 1994-10-19 15:15 ./usr/sbin/gettable
-r-xr-xr-x bin/bin24576 1994-10-19 15:15 ./usr/sbin/htable
-r-xr-xr-x bin/bin24576 1994-10-19 15:15 ./usr/sbin/inetd
-r-xr-sr-x bin/kmem   16384 1994-10-19 15:15 ./usr/sbin/iostat
-r-xr-xr-x bin/bin20480 1994-10-19 15:15 ./usr/sbin/kvm_mkdb
-r-xr-sr-x bin/daemon 28672 1994-10-19 15:15 ./usr/sbin/lpc
-r-xr-xr-x bin/bin45056 1994-10-19 15:15 ./usr/sbin/lpd
-r-xr-xr-x bin/bin12288 1994-10-19 15:15 ./usr/sbin/lptest
-r-xr-xr-x bin/bin16384 1994-10-19 15:16 ./usr/sbin/mailstats
-r-xr-xr-x bin/bin16384 1994-10-19 15:16 ./usr/sbin/makemap
-r-xr-xr-x bin/bin28672 1994-10-19 15:16 ./usr/sbin/map-mbone
-r-xr-xr-x bin/bin16384 1994-10-19 15:15 ./usr/sbin/mk-amd-map
-r-xr-xr-x bin/bin24576 1994-10-19 15:16 ./usr/sbin/mrinfo
-r-xr-xr-x bin/bin36864 1994-10-19 15:16 ./usr/sbin/mrouted
-r-xr-xr-x bin/bin28672 1994-10-19 15:16 ./usr/sbin/mtree
-r-xr-xr-x bin/bin81920 1994-10-19 15:16 ./usr/sbin/named
-r-xr-xr-x bin/bin   93 1994-10-19 15:16 ./usr/sbin/named.reload
-r-xr-xr-x bin/bin  136 1994-10-19 15:16 ./usr/sbin/named.restart
-r-xr-xr-x bin/bin53248 1994-10-19 15:16 ./usr/sbin/nslookup
-r-xr-xr-x bin/bin12288 1994-10-19 15:16 ./usr/sbin/nsquery
-r-xr-xr-x bin/bin16384 1994-10-19 15:16 ./usr/sbin/nstest
-r-xr-xr-x bin/bin20480 1994-10-19 15:16 ./usr/sbin/pac
-r-xr-xr-x bin/bin16384 1994-10-19 15:16 ./usr/sbin/portmap
-r-sr-xr-x root/bin   65536 1994-10-19 15:16 ./usr/sbin/pppd
-r-xr-sr-x bin/kmem   16384 1994-10-19 15:16 ./usr/sbin/pppstats
-r-xr-xr-x bin/bin12288 1994-10-19 15:16 ./usr/sbin/praliases
-r-xr-sr-x bin/kmem   24576 1994-10-19 15:16 ./usr/sbin/pstat
-r-xr-xr-x bin/bin16384 1994-10-19 15:16 ./usr/sbin/pwd_mkdb
-r-xr-xr-x bin/bin16384 1994-10-19 15:16 ./usr/sbin/quot
-r-xr-xr-x bin/bin16384 1994-10-19 15:16 ./usr/sbin/quotaoff
hr-xr-xr-x bin/bin0 1994-10-19 15:16 ./usr/sbin/quotaon link 
to ./usr/sbin/quotaoff

-r-xr-xr-x bin/bin20480 1994-10-19 15:16 ./usr/sbin/rarpd
-r-xr-xr-x bin/bin24576 1994-10-19 15:16 ./usr/sbin/rbootd
-r-xr-xr-x bin/bin12288 1994-10-19 15:16 ./usr/sbin/rdate
-r-xr-xr-x bin/bin16384 1994-10-19 15:16 ./usr/sbin/repquota
-r-xr-xr-x bin/bin16384 1994-10-19 15:16 ./usr/sbin/rmt
-r-xr-xr-x bin/bin20480 1994-10-19 15:16 ./usr/sbin/rpc.bootparamd
-r-xr-xr-x bin/bin16384 1994-10-19 15:16 ./usr/sbin/rwhod
-r-xr-xr-x bin/bin24576 1994-10-19 15:16 ./usr/sbin/sa
hr-sr-xr-x root/bin   0 1994-10-19 15:16 ./usr/sbin/sendmail 
link to ./usr/bin/mailq

-r-sr-xr-x root/bin   16384 1994-10-19 15:16 ./usr/sbin/sliplogin
-r-xr-sr-x bin/kmem   16384 1994-10-19 15:16 ./usr/sbin/slstats
-r-xr-xr-x bin/bin16384 1994-10-19 15:16 ./usr/sbin/spray
-r-xr-xr-x bin/bin20480 1994-10-19 15:16 ./usr/sbin/sysctl
-r-xr-xr-x bin/bin24576 1994-10-19 15:16 ./usr/sbin/syslogd
-r-xr-xr-x bin/bin   126976 1994-10-19 15:16 ./usr/sbin/tcpdump
-r-xr-xr-x bin/bin45056 1994-10-19 15:16 ./usr/sbin/timed
-r-sr-xr-x root/bin   24576 1994-10-19 15:16 ./usr/sbin/timedc
-r-sr-xr-x root/bin   20480 1994-10-19 15:16 ./usr/sbin/traceroute
-r-xr-sr-x bin/kmem   16384 1994-10-19 15:16 ./usr/sbin/trpt
-r-xr-sr-x 

review swap — nfs-ganesha

[Kaleb S. KEITHLEY]

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 Conduct: http://fedoraproject.org/code-of-conduct

how to withdraw glusterfs from epel?

[Kaleb S. KEITHLEY]

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? This repo file 
would point to YUM repo(s) on download.gluster.org.


Would that conform to the Fedora policy wrt not shipping packages that 
conflict with packages in RHEL.


If this is acceptable, I could do this sooner and not wait for the 
packages to appear in RHEL. (Well, I just withdraw glusterfs from EPEL 
now, for that matter, I very much doubt many people are using 
HekaFS+glusterfs, but that's beside the point.)


Thoughts?

--

Kaleb
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: how to withdraw glusterfs from epel?

[Kaleb S. KEITHLEY]

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 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? This repo file
would point to YUM repo(s) on download.gluster.org.

Would that conform to the Fedora policy wrt not shipping packages that
conflict with packages in RHEL.


It would be against the policy of not shipping repo files for non-Fedora
repos:

https://fedoraproject.org/wiki/Packaging:Guidelines#Configuration_of_Package_Managers


Okay, I'm okay with that. How about instead of a /etc/yum.repos.d/ file 
if it's a /usr/share/doc/glusterfs.README containing instructions for 
how to use the community GlusterFS yum repo?


--

Kaleb
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: how to withdraw glusterfs from epel?

[Kaleb S. KEITHLEY]

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 with RPMs in the RHEL base channel 
— or will be soon.


And just to be clear, it's already been made clear that a repo file is 
not acceptable.


Now I'm asking if I can morph the packaging (for EPEL) from several 
glusterfs-*.RPMs to a single glusterfs-community-doc (or something 
similar) RPM containing a README. This is instead of completely 
withdrawing community glusterfs from EPEL.


--

Kaleb
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

BUG 1003089 - Review Request: glusterfs-openstack-swift

[Kaleb S. KEITHLEY]

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


Thanks,

--

Kaleb KEITHLEY

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

f20 systemd rpm isn't signed!

[Kaleb S. KEITHLEY]

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
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Fwd: promoting to package co-maintainers?

[Kaleb S. KEITHLEY]

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 to Fedora 
devel@lists.fedoraproject.org


Hi

On 7 Aug I opened a trac ticket (as per 
https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#Become_a_co-maintainer) 
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.


Thanks,

--

Kaleb


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

promoting to package co-maintainers?

[Kaleb S. KEITHLEY]

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 the normal amount of time is for action a ticket like this.


Thanks,

--

Kaleb
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: promoting to package co-maintainers?

[Kaleb S. KEITHLEY]

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 full time on GlusterFS.


Just to be sure, do you mean you tried following this procedure?
https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#Become_a_co-maintainer



Yes, that's how I knew to open a trac ticket.




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.


Some people might be busy at Flock. ;)


that's a fair point

--

Kaleb
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: systemd network-online.target question

[Kaleb S. KEITHLEY]

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 order themselves after it.

Would adding a Before=network-online.target to the glusterd.service
be the right thing to do or is there a better solution?  (It already
has After=network.target rpcbind.service)


All network mounts configured in fstab will pull in
network-online.target, and are ordered after it.


Yes (and that's what the man page says, so I knew that.)



If you want your service to start on *all* boots, regardless whether
there is any remote fs configured in fstab or not -- but if there's a
remote fs configured then before that, then only use
Before=network-online.target in your [Unit] section. (And use
WantedBy=multi-user.target in [Install] as you would for any other
normal service).


That's what I want. Start on all boots regardless, and before any 
remote fs in fstab. I.e. before attempting to mount any local nfs 
mount in fstab.


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.


=== /usr/lib/systemd/system/glusterd.service ===
[Unit]
Description=GlusterFS an clustered file-system server
Wants=glusterfsd.service
After=network.target rpcbind.service
Before=network-online.target

[Service]
Type=forking
PIDFile=/run/glusterd.pid
LimitNOFILE=65536
ExecStart=/usr/sbin/glusterd -p /run/glusterd.pid

[Install]
WantedBy=multi-user.target
=== /usr/lib/systemd/system/glusterd.service ===


 /etc/fstab ===
#
# /etc/fstab
# Created by anaconda on Mon Jul  8 12:45:13 2013
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/fedora-root /   ext4defaults1 1
UUID=16a22380-99d1-4c17-81d2-6e1f9b03343d /boot   ext4 
  defaults1 2

/dev/mapper/fedora-swap swapswapdefaults0 0

localhost:volX /mnt nfs _netdev 0 0
 /etc/fstab ===
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd network-online.target question

[Kaleb S. KEITHLEY]

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 experimenting and found that if I 
use defaults or defaults,_netdev for the local nfs mount then it does 
work. (Or has all three times I've tried it. Not a statistically valid 
sample size.)


I'm waiting to see what the user says.





=== /usr/lib/systemd/system/glusterd.service ===
[Unit]
Description=GlusterFS an clustered file-system server
Wants=glusterfsd.service
After=network.target rpcbind.service
Before=network-online.target

[Service]
Type=forking
PIDFile=/run/glusterd.pid
LimitNOFILE=65536
ExecStart=/usr/sbin/glusterd -p /run/glusterd.pid

[Install]
WantedBy=multi-user.target
=== /usr/lib/systemd/system/glusterd.service ===


 /etc/fstab ===
#
# /etc/fstab
# Created by anaconda on Mon Jul  8 12:45:13 2013
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/fedora-root /   ext4defaults1 1
UUID=16a22380-99d1-4c17-81d2-6e1f9b03343d /boot   ext4
defaults1 2
/dev/mapper/fedora-swap swapswapdefaults0 0

localhost:volX /mntnfs_netdev0 0
 /etc/fstab ===



--

Kaleb
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

-devel rpm question

[Kaleb S. KEITHLEY]

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 
http://fedoraproject.org/wiki/Packaging:Guidelines#Devel_Packages)


Thanks

--

Kaleb
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

taking over ownership of glusterfs

[Kaleb S. KEITHLEY]

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 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 
https://bugzilla.redhat.com/show_bug.cgi?id=399301 and set the 
fedora-cvs=? flag. Maybe that'll work, maybe it won't.


--

Kaleb
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: taking over ownership of glusterfs

[Kaleb S. KEITHLEY]

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://fedoraproject.org/wiki/Package_SCM_admin_requests indicates
that I can use the https://admin.fedoraproject.__org/pkgdb
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 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
https://bugzilla.redhat.com/__show_bug.cgi?id=399301
https://bugzilla.redhat.com/show_bug.cgi?id=399301 and set the
fedora-cvs=? flag. Maybe that'll work, maybe it won't.

It won't.  Log into pkgdb with your FAS login, find the package and
click Take Ownership.


Yes, I am signed in. There is no 'Take Ownership' link or button. 
Perhaps because Matthias somehow hasn't actually relinquished ownership?


--

Kaleb
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

no audit2allow in f18

[Kaleb S. KEITHLEY]

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
https://admin.fedoraproject.org/mailman/listinfo/devel

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

[Kaleb S. KEITHLEY]

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 fuse-resolve.lo
   CC fuse-bridge.lo
   CC misc.lo
In file included from fuse-helpers.c:24:0:
/usr/include/sys/sysctl.h:63:25: fatal error: bits/sysctl.h: No such
file or directory
compilation terminated.
...


I noticed that today and reported it:

 http://bugzilla.redhat.com/827040


I note that a new build of glibc, including glibc-headers occurred late 
yesterday (2012-05-31), but the fix was not included.


Is there an ETA for when this will be fixed? I'm probably not the only 
one that this is affecting.


Thanks,

--

Kaleb
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

glusterfs rename

[Kaleb S. KEITHLEY]

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? Does it 
matter?


And of course then respin HekaFS rpms with the dependency changed to the 
new name.


This would serve two purposes: a) resolves the glusterfs in EPEL and RHS 
Channel debate, b) lets us ship glusterfs33 in f16, f17, and f18 along 
with glusterfs32+HekaFS, since we don't (currently) plan to update 
HekaFS for glusterfs33. HekaFS features will be added to later releases 
of glusterfs33.


Any hoops? Or can I just go ahead and do this?

--

Kaleb
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: glusterfs rename

[Kaleb S. KEITHLEY]

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. (And it's not the problem we're 
trying to solve.)


If glusterfs-3.2.x + HekaFS is installed, we essentially want to avoid 
ever updating to glusterfs-3.3.x because HekaFS is not compatible with it.


One way I can solve this is to never ship glusterfs-3.3.x on f16 and f17 
(and EPEL el6).


I'd be perfectly happy saying we will never ship glusterfs-3.3.x on f16 
and f17, but the reality is that there probably are people who want it.


Along the same lines, I'd be happy saying we will not ship HekaFS in f18 
once glusterfs-3.3.x is out, but there are probably people who want 
glusterfs-3.2.x, with or without HekaFS.


And FWIW, doing nothing doesn't resolve the glusterfs in EPEL versus 
glusterfs in the RHS Channel issue.


--

Kaleb
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: glusterfs rename

[Kaleb S. KEITHLEY]

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 of glusterfs?


No, and in fact that would not work. (And it's not the problem we're
trying to solve.)

If glusterfs-3.2.x + HekaFS is installed, we essentially want to avoid
ever updating to glusterfs-3.3.x because HekaFS is not compatible with it.


And HekaFS aside, I could also make the case that we don't want people 
to blindly update from glusterfs-3.2.x to glusterfs-3.3.x.


Another option I'd be willing to consider is leaving glusterfs-3.2.x 
alone, i.e., as glusterfs-3.2.x-y.fc16, but release glusterfs-3.3.x as 
glusterfs33, i.e. glusterfs33-3.3.x-1.fc16.


--

Kaleb
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: glusterfs rename

[Kaleb S. KEITHLEY]

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 beaten to death already. It's not in RHEL. It's in the RHS 
Channel for RHSA. Some client-side bits will eventually be released in 
RHEL7.


And there are more users of EPEL than just RHEL.

And since it's already in EPEL, and has been for a couple of years, as 
glusterfs I'd say the burden is on the RHEL packagers to pick a name 
that doesn't conflict with what's in EPEL. Unless the name gets changed 
before then.


--

Kaleb
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: glusterfs rename

[Kaleb S. KEITHLEY]

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 already in RHEL? What's the difference?



This has been beaten to death already. It's not in RHEL. It's in the RHS
Channel for RHSA. Some client-side bits will eventually be released in
RHEL7.


Just to be clear, it's been extensively discussed on an epel list 
@redhat. Sorry for for the omission.


As for the RHS Channel and RHSA, suffice it to say, it's not RHEL. 
That's the key point.


There seems to be some small consensus that not shipping glusterfs-3.3.x 
on f16 and f17 is the correct strategy, and I'm happy with that. And if 
everyone else is happy with that then no rename is necessary.


--

Kaleb
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: glusterfs rename

[Kaleb S. KEITHLEY]

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 missing hekafs features to
be merged into the 3.3 release train by October when F-18 is due to be
released?


I was under the impression that glusterfs would be automatically carried 
forward from f17 into f18, as it apparently was from f16 into f17.


F18 builds (of 3.2.6) are already available in koji. Until now I haven't 
heard that a feature page is needed for 3.2.x (or 3.3.x) to be included 
in f18. (But how to deprecate HekaFS on f18 once the glusterfs-3.3.0 
build is available.)


The features that are in HekaFS (in f16 and f17) will get merged into 
glusterfs-3.3.1+, as I indicated previously, but I won't promise how 
many of them will be there when f18 ships. We certainly hope that all of 
them will be, but we aren't making any promises.




For the EPEL side possibly it might be worth going the glusterfs32
naming route and keep it simple and move it forward.

Peter



--

Kaleb
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

license in rpm spec file for dual license?

[Kaleb S. KEITHLEY]

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
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

What are the rules for updating a package?

[Kaleb S. KEITHLEY]

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?


Thanks,

—

Kaleb
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

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

[Kaleb S. KEITHLEY]

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

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 y.tab.c file. Suffice it to say it builds for f16 and 
rawhide just fine using the exact same sources and spec file.

Build logs aren't particularly helpful and since they succeed in mock 
and rpmbuild I can't debug the build issue locally. Obviously there's a 
compile error of the y.tab.c file, but I can't see why it doesn't work 
in koji when it does work everywhere else.

Perhaps there's some extra fedpkg flag I should be using for epel builds?

--

K



-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

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

[Kaleb S. KEITHLEY]

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 and i386, with `mock -r
 epel-6-x86_64 --rebuild ...` and mock -r epel-6-i386 --rebuild ...`
 respectively.

 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 y.tab.c file. Suffice it to say it builds for f16 and
 rawhide just fine using the exact same sources and spec file.

 Build logs aren't particularly helpful and since they succeed in mock
 and rpmbuild I can't debug the build issue locally. Obviously there's a
 compile error of the y.tab.c file, but I can't see why it doesn't work
 in koji when it does work everywhere else.

 Perhaps there's some extra fedpkg flag I should be using for epel builds?

 Perhaps try without parallel make?

Yes, that makes it work.

Thanks for the tip.

Regards,

--

K


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

openssh-server in F16ga

[Kaleb S. KEITHLEY]

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?

--

K

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: openssh-server in F16ga

[Kaleb S. KEITHLEY]

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


 It's enabled if installed of DVD  not if installed from live CD/USB.

 I did a fresh install yesterday of the GA DVD and sshd was up and
 running after install.

So it's intentional? I installed f16alpha and F16beta from live CD ISOs 
too, not that I believe that means much for f16ga.

Seems surprising (to me) that it'd be installed, and the port open in 
the firewall, but not enabled.

--

K

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

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

[Kaleb S. KEITHLEY]

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
https://admin.fedoraproject.org/mailman/listinfo/devel

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

[Kaleb S. KEITHLEY]

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

I'd kinda like to preserve that in some fashion in the new systemd 
service file. Not to run on RHEL6 obviously, but to be future-proof 
against the day when python2.8 or python3.x ships in F17 or later or 
RHEL7, e.g.

I read the various systemd.{unit,service,exec} man pages and also tried 
to find the conversion guide that was mentioned here a while back. 
Didn't see anything that looked suitable. Did I overlook something?

Thanks,

--

K

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

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

[Kaleb S. KEITHLEY]

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 the koji build is failing with:
...
Processing files: glusterfs-server-3.2.4-2.fc17.x86_64
error: File must begin with /: %{_unitdir}/glusterd.service
error: File must begin with /: %{_unitdir}/glusterfsd.service
...
RPM build errors:
 File must begin with /: %{_unitdir}/glusterd.service
 File must begin with /: %{_unitdir}/glusterfsd.service
Child returncode was: 1
EXCEPTION: Command failed. See logs for output.
...

rpmbuild -bb specfile works on my f15 machine. Not sure I would expect 
a mock build to work any better than a koji scratch build. Adding a 
leading / is wrong (and a koji scratch build confirms it.)

Why is this puking on this? It didn't puke when it only had the init.d 
files!

Thanks for any insight.

--

K
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

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

[Kaleb S. KEITHLEY]

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 the same for both 
f16 and rawhide. In f16 and rawhide both glusterfs and hekafs used sysv 
init.d scripts.

Now for rawhide I'm going to switch to systemd. I know I can't switch to 
systemd for f16, so the question is, what scheme should I used for the 
release numbering?

One thought I had was to 'leapfrog' increment the release numbers. I 
already have: glusterfs-3.2.4-1.x86_64.fc16.rpm and 
glusterfs-3.2.4-1.x86_64.fc17.rpm. Then for the systemd version then I'd 
go to glusterfs-3.2.4-2.x86_64.fc17.rpm. And if I need to respin 
glusterfs I'd use glusterfs-3.2.4-3.x86_64.fc16.rpm and 
glusterfs-3.2.4-4.x86_64.fc17.rpm.

I.e:
   f16  rawhide
current   3.2.4-1.fc16 [i] 3.2.4-1.fc17 [i]
new... 3.2.4-2.fc17 [s]
   3.2.4-3.fc16 [i] 3.2.4-4.fc17 [s]

([i] means init.d, [s] means systemd)

Alternatively I could just add a character to the first release using 
sytsemd for rawhide, e.g. 's'. Then I'd have the existing 
glusterfs-3.2.4-1.x86_64.fc16.rpm and glusterfs-3.2.4-1.x86_64.fc17.rpm, 
and glusterfs-3.2.4-1s.x86_64.fc17.rpm for the new systemd version. And 
for a respin then I'd just use systemd going forward for rawhide, and 
I'd use glusterfs-3.2.4-2.x86_64.fc16.rpm and 
glusterfs-3.2.4-2.x86_64.fc17.rpm.

I.e:
   f16  rawhide
current   3.2.4-1.fc16 [i] 3.2.4-1.fc17 [i]
new... 3.2.4-1s.fc17 [s]
   3.2.4-2.fc16 [i] 3.2.4-2.fc17 [s]

Whichever I go with I'd do the same thing for hekafs.

Thoughts?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: GNOME 3 - font point sizes now scaled?

[Kaleb S. KEITHLEY]

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 between normal, big very big fonts and
 expert/advanced controls one can specify fonts sizes for many details
 of the DE in pnts.

 Wouldn't the sane solution to be to honour the fallible DPI detection,
 with an expert tweak available to rescue those who have unusual
 hardware (or preferences)? I can't see the justification for the
 present override.

 No. It wouldn't.

Not exactly the most compelling of arguments. ;-)

Grovelling around in the F15 xorg-server sources and reviewing the Xorg 
log file on my F15 box, I see, with _modern hardware_ at least, that we 
do have the monitor geometry available from DDC or EDIC, and obviously 
it is trivial to compute the actual, correct DPI for each screen.

Obviously in a multi-screen set-up using Xinerama this has the potential 
to be a Hard Problem if the monitors differ greatly in their DPI.

If the major resistance is over what to do with older hardware that 
doesn't have this data available, then yes, punt; use a hard-coded 
default. Likewise, if the two monitors really differ greatly, then punt.

Beyond that I'd say this violates POLA if the data is available and the 
xserver doesn't honor and correctly report it.

And it wouldn't be so hard to to add something like -dpi:0, -dpi:1, 
-dpi:2 command line options to specify per-screen dpi. I kinda thought I 
did that a long, long time ago, but maybe I only thought about doing it 
and never actually got around to it.

My 2¢ worth.

--

Kaleb

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

yum update btrfs-progs failing on F16alpha

[Kaleb S. KEITHLEY]

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: rpmts_HdrFromFdno: Header V3 RSA/SHA256 Signature, key ID 
069c8460: NOKEY
   Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-x86_64


   The GPG keys listed for the Fedora 16 - x86_64 repository are 
already installed but they are not correct for this package.
   Check that the correct key URLs are configured for this repository.

The maintainer doesn't know why the keys is bad. (I've also asked him 
why there isn't an fc16 rpm, just fc15 and fc17 in koji. Do we care that 
there are not fc16 builds?)

How did it get a bad key? Do we even care if the newer version goes out 
in the beta? FWIW I forced it by installing the RPM with `rpm -i --force`.

--

Kaleb
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide report: 20110823 changes

[Kaleb S. KEITHLEY]

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?

I've retired the package. It's a dead.package in fedora-scm. It's 
obsoleted by hekafs.

What else do I need to do.

--

Kaleb
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

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

[Kaleb S. KEITHLEY]

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 any rate, before F16 final:
 ...
 cloudfs-0.7-4.fc16.src.rpm

I'm not really sure what's being asked for here.

cloudfs was obsoleted and removed from Fedora SCM two days before this 
email, so I'm not sure it's warranted, or even possible to rebuild it; 
not without jumping though a lot of hoops.

There were later builds of later releases for f16.

And FYI, it was renamed/replaced by hekafs, and there is a recent build 
for f16.

--

Kaleb
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

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

[Kaleb S. KEITHLEY]

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 question is do we want to add them? My strawman 
answer is yes.

The next question is which group? Clustering, along with heartbeat, 
pacemaker, etc.? Or Clustering's parent group, Servers, i.e. along with 
clustering itself, smb-server, etc.? Or Filesystems, with btrfs-progs, 
e2fsprogs, xfsprogs, etc.? Or perhaps in a new group of its own?

Thoughts?

--

Kaleb

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

review swap

[Kaleb S. KEITHLEY]

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@lists.fedoraproject.org

Re-review needed after package name change and added Obsoletes:

bz: https://bugzilla.redhat.com/show_bug.cgi?id=675050

Spec URL: http://hekafs.org/dist/0.7/hekafs.spec
SRPM URL: http://hekafs.org/dist/0.7/hekafs-0.7-7.fc15.src.rpm

Thanks,

--
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

package re-review needed — CloudFS name change to HekaFS

[Kaleb S. KEITHLEY]

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
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel