Hi,
it seems that there is a major breakage in the current master branch.
Jeff already send an email about this yesterday [1], but it seems that
things have not settled down yet.
In order to prevent (more) confusion, automated regression tests have
been disabled for now. Patches that have been
On 04/02/2015 12:27 AM, Raghavendra Talur wrote:
On Wed, Apr 1, 2015 at 10:34 PM, Justin Clift jus...@gluster.org
mailto:jus...@gluster.org wrote:
On 1 Apr 2015, at 10:57, Emmanuel Dreyfus m...@netbsd.org
mailto:m...@netbsd.org wrote:
Hi
crypt.t was recently broken
On Thu, Apr 02, 2015 at 01:58:39PM +0530, Raghavendra Bhat wrote:
On Thursday 02 April 2015 01:00 PM, Pranith Kumar Karampuri wrote:
On 04/02/2015 12:27 AM, Raghavendra Talur wrote:
On Wed, Apr 1, 2015 at 10:34 PM, Justin Clift jus...@gluster.org
mailto:jus...@gluster.org wrote:
On Thursday 02 April 2015 01:00 PM, Pranith Kumar Karampuri wrote:
On 04/02/2015 12:27 AM, Raghavendra Talur wrote:
On Wed, Apr 1, 2015 at 10:34 PM, Justin Clift jus...@gluster.org
mailto:jus...@gluster.org wrote:
On 1 Apr 2015, at 10:57, Emmanuel Dreyfus m...@netbsd.org
On 12 Feb 2015, at 08:54, Mohammed Rafi K C rkavu...@redhat.com wrote:
On 02/12/2015 08:32 AM, Rudra Siva wrote:
Rafi,
I'm preparing the Phi RDMA patch for submission
If you can send a patch to support iWARP, that will be a great addition
to gluster rdma.
Clearing out older email... did
On 31 Mar 2015, at 08:15, Niels de Vos nde...@redhat.com wrote:
On Tue, Mar 31, 2015 at 12:20:19PM +0530, Kaushal M wrote:
IMHO, doing hardening and security should be left the individual
distributions and the package maintainers. Generally, each distribution has
it's own policies with regards
On 04/02/2015 01:28 PM, Niels de Vos wrote:
Hi,
it seems that there is a major breakage in the current master branch.
Jeff already send an email about this yesterday [1], but it seems that
things have not settled down yet.
In order to prevent (more) confusion, automated regression tests have
Hi all,
Since GlusterFs version 3.6.0 gluster volume replace-brick VOLNAME
SOURCE-BRICK NEW-BRICK {start [force]|pause|abort|status|commit } command
have deprecated. Only gluster volume replace-brick VOLNAME SOURCE-BRICK
NEW-BRICK commit force command supported.
for bug
Hi,
Sorry for the top-post. Just to Amplify a but if what Niels has already
said——
Yes, in Fedora, the glusterfs.spec file has a line
%global _hardened_build 1
at the top. This enables PIE and RELRO in Fedora and EPEL builds.
This line exists in the glusterfs.spec.in file in the Gluster
On 04/02/2015 08:22 AM, Kaleb KEITHLEY wrote:
Hi,
Sorry for the top-post. Just to Amplify a but if what Niels...
Just to Amplify a bit of what Niels
(Naughty fingers.)
--
Kaleb
___
Gluster-devel mailing list
On 2 Apr 2015, at 12:10, Vijay Bellur vbel...@redhat.com wrote:
On 04/02/2015 06:27 AM, Jeff Darcy wrote:
My recommendations:
(1) Apply the -Wno-error=cpp and -Wno-error=maybe-uninitialized
changes wherever they need to be applied so that they're
effective during
On Thu, Apr 02, 2015 at 01:21:57PM +0100, Justin Clift wrote:
On 31 Mar 2015, at 08:15, Niels de Vos nde...@redhat.com wrote:
On Tue, Mar 31, 2015 at 12:20:19PM +0530, Kaushal M wrote:
IMHO, doing hardening and security should be left the individual
distributions and the package
On 2 Apr 2015, at 01:57, Jeff Darcy jda...@redhat.com wrote:
As many of you have undoubtedly noticed, we're now in a situation where
*all* regression builds are now failing, with something like this:
-
cc1: warnings being treated as errors
On 2 Apr 2015, at 12:10, Vijay Bellur vbel...@redhat.com wrote:
On 04/02/2015 06:27 AM, Jeff Darcy wrote:
My recommendations:
(1) Apply the -Wno-error=cpp and -Wno-error=maybe-uninitialized
changes wherever they need to be applied so that they're
effective during
On 2 Apr 2015, at 01:57, Jeff Darcy jda...@redhat.com wrote:
snip
(1) Apply the -Wno-error=cpp and -Wno-error=maybe-uninitialized
changes wherever they need to be applied so that they're
effective during normal regression builds
The git repo which holds our CentOS build
I've got responses from couple of folks, would also love hear from others.
~Atin
On 03/31/2015 11:49 AM, Atin Mukherjee wrote:
Folks,
There are some projects which uses compiler/glibc features to strengthen
the security claims. Popular distros suggest to harden daemon with
RELRO/PIE flags.
Also, everyone please rebase your patches so that they get the fix and
regression can be triggered on them again.
~kaushal
On Thu, Apr 2, 2015 at 3:42 PM, Vijay Bellur vbel...@redhat.com wrote:
On 04/02/2015 01:28 PM, Niels de Vos wrote:
Hi,
it seems that there is a major breakage in the
On 04/02/2015 06:27 AM, Jeff Darcy wrote:
My recommendations:
(1) Apply the -Wno-error=cpp and -Wno-error=maybe-uninitialized
changes wherever they need to be applied so that they're
effective during normal regression builds
Thanks, Jeff.
Justin - would it be
On 2 Apr 2015, at 05:18, Emmanuel Dreyfus m...@netbsd.org wrote:
Hi
I am now convinced the solution to our multiple regression problem is to
introduce more Gluster Build System users: one for CentOS regression,
another one for NetBSD regression (and one for each smoke test, as
exaplained
I think, crypt xlator should do a mem_put of local after doing STACK_UNWIND
like other xlators which also use mem_get for local (such as AFR). I am
suspecting crypt not doing mem_put might be the reason for the bug
mentioned.
My understanding was that mem_put should be called automatically
On 1 Apr 2015, at 19:47, Jeff Darcy jda...@redhat.com wrote:
When doing an initial burn in test (regression run on master head
of GlusterFS git), it coredumped on the new slave23.cloud.gluster.org VM.
(yeah, I'm reusing VM names)
On 03/31/2015 12:45 PM, Niels de Vos wrote:
On Tue, Mar 31, 2015 at 12:20:19PM +0530, Kaushal M wrote:
IMHO, doing hardening and security should be left the individual
distributions and the package maintainers. Generally, each distribution has
it's own policies with regards to hardening and
On 04/02/2015 07:27 PM, Raghavendra Bhat wrote:
On Thursday 02 April 2015 05:50 PM, Jeff Darcy wrote:
I think, crypt xlator should do a mem_put of local after doing
STACK_UNWIND
like other xlators which also use mem_get for local (such as AFR). I am
suspecting crypt not doing mem_put might be
Hi all,
Thank you for your thoughts. force should be present in command, i will keep
it to commit force.
replace brick command will be gluster volume replace-brick VOLNAME
SOURCE-BRICK NEW-BRICK commit force
Regards
Gaurav
- Original Message -
From: Raghavendra Talur
On 2 Apr 2015, at 14:42, Jeff Darcy jda...@redhat.com wrote:
Is it ok to put slave23.cloud.gluster.org into general rotation, so it
runs regression jobs along with the rest?
Sounds OK to me. Do we have a place to store the core tarball, just in
case we decide we need to go back to it some
The regression builds seem to be running again at the moment without
removing -Werror. So I'm not sure if this needs adjusting any more?
Yeah, I'm not sure why either. Maybe a difference in compiler versions?
In any case, if it's working now, I'd say let's not mess with it. I can
add the
On 2 Apr 2015, at 14:08, Niels de Vos nde...@redhat.com wrote:
On Thu, Apr 02, 2015 at 01:21:57PM +0100, Justin Clift wrote:
On 31 Mar 2015, at 08:15, Niels de Vos nde...@redhat.com wrote:
On Tue, Mar 31, 2015 at 12:20:19PM +0530, Kaushal M wrote:
IMHO, doing hardening and security should be
Is it ok to put slave23.cloud.gluster.org into general rotation, so it
runs regression jobs along with the rest?
Sounds OK to me. Do we have a place to store the core tarball, just in
case we decide we need to go back to it some day?
___
On Thursday 02 April 2015 05:50 PM, Jeff Darcy wrote:
I think, crypt xlator should do a mem_put of local after doing STACK_UNWIND
like other xlators which also use mem_get for local (such as AFR). I am
suspecting crypt not doing mem_put might be the reason for the bug
mentioned.
My
29 matches
Mail list logo
