On 2022-Nov-09, Michael Paquier wrote:
> I got to look at that, now that the minor releases have been tagged,
> and the change has no conflicts down to 9.3. 9.2 needed a slight
> tweak, though, but it seemed fine as well. (Tested the build on all
> branches.) So done all the way down, sticking
On Fri, Nov 04, 2022 at 08:49:24AM +0900, Michael Paquier wrote:
> In line of ad96696, seems like that it would make sense to do the same
> here even if the bar is lower. sepgsql has not changed in years, so I
> suspect few conflicts. Alvaro, if you want to take care of that,
> that's fine by me.
On Thu, Nov 03, 2022 at 07:01:20PM -0400, Tom Lane wrote:
> Alvaro Herrera writes:
>> FWIW I just had a CI job fail the "warnings" test because of lacking
>> this patch in the back branches :-) What do you think about
>> back-patching this to at least 11?
>
> No objection to back-patching from m
Alvaro Herrera writes:
> On 2020-Aug-14, Michael Paquier wrote:
>> On Thu, Aug 13, 2020 at 08:47:28PM -0400, Tom Lane wrote:
>>> Should we back-patch that? Usually I figure that people might want
>>> to build back PG branches on newer platforms at some point, so that
>>> it's useful to apply port
On 2020-Aug-14, Michael Paquier wrote:
> On Thu, Aug 13, 2020 at 08:47:28PM -0400, Tom Lane wrote:
> > Should we back-patch that? Usually I figure that people might want
> > to build back PG branches on newer platforms at some point, so that
> > it's useful to apply portability fixes across-the-b
On Thu, Aug 13, 2020 at 08:47:28PM -0400, Tom Lane wrote:
> Should we back-patch that? Usually I figure that people might want
> to build back PG branches on newer platforms at some point, so that
> it's useful to apply portability fixes across-the-board. On the
> other hand, since it's only a co
Michael Paquier writes:
> Applied on HEAD then. Thanks for the discussion!
Should we back-patch that? Usually I figure that people might want
to build back PG branches on newer platforms at some point, so that
it's useful to apply portability fixes across-the-board. On the
other hand, since it
On Thu, Aug 13, 2020 at 02:35:28PM +0900, Michael Paquier wrote:
> Okay, thanks for confirming. Let's do so then, I'll just wait a bit
> to see if there are more comments from others.
Applied on HEAD then. Thanks for the discussion!
--
Michael
signature.asc
Description: PGP signature
On Thu, Aug 13, 2020 at 06:54:41AM -0400, Joe Conway wrote:
> On 8/13/20 1:22 AM, Michael Paquier wrote:
>> Joe, what's the version of libselinux used in rhinoceros? 2.5?
>
> rpm -q libselinux
> libselinux-2.5-15.el7.x86_64
Thanks!
--
Michael
signature.asc
Description: PGP signature
On 8/13/20 1:22 AM, Michael Paquier wrote:
> On Wed, Aug 12, 2020 at 10:50:21PM -0400, Tom Lane wrote:
>> Ummm ... aren't you going to get some cast-away-const warnings now?
>> Or are all of the called functions declared as taking "const char *"
>> not just "char *"?
>
> Let me see.. The function
On Thu, Aug 13, 2020 at 01:29:35AM -0400, Tom Lane wrote:
> Well, "you get a compiler warning" isn't a reason to consider the version
> unsupported. There are probably going to be a few other warnings you get
> when building on an ancient platform --- as long as it works, I think
> we're fine. So
Michael Paquier writes:
> On Wed, Aug 12, 2020 at 10:50:21PM -0400, Tom Lane wrote:
>> Ummm ... aren't you going to get some cast-away-const warnings now?
> Let me see.. The function signatures we use have been visibly changed
> in 9eb9c932, which comes down to a point between 2.2.2 and 2.3, and
On Wed, Aug 12, 2020 at 10:50:21PM -0400, Tom Lane wrote:
> Ummm ... aren't you going to get some cast-away-const warnings now?
> Or are all of the called functions declared as taking "const char *"
> not just "char *"?
Let me see.. The function signatures we use have been visibly changed
in 9eb9
Michael Paquier writes:
> Per the following commit in upstream SELinux, security_context_t has
> been marked as deprecated, generating complains with
> -Wdeprecated-declarations:
> https://github.com/SELinuxProject/selinux/commit/7a124ca2758136f49cc38efc26fb1a2d385ecfd9
Huh. Apparently it's been
Hi all,
Per the following commit in upstream SELinux, security_context_t has
been marked as deprecated, generating complains with
-Wdeprecated-declarations:
https://github.com/SELinuxProject/selinux/commit/7a124ca2758136f49cc38efc26fb1a2d385ecfd9
This can be seen with Debian GID when building con
15 matches
Mail list logo
