Re: Options for 64-bit time_t support on 32-bit architectures

[Florian Weimer]

* Florian Weimer:

> For Fedora, that would affect the i686 architecture only.

It was pointed out off-list that I forgot armhfp.  Sorry!

The external pressure to keep armhfp going indefinitely and switch to
a 64-bit time_t is probably larger on armhfp than on i686.  The reason
is that new armhfp devices are more often 32-bit only than new i686
devices (which can run x86-64 code).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Options for 64-bit time_t support on 32-bit architectures

[Florian Weimer]

* Michael Cronenworth:

> On 7/18/19 4:05 PM, Florian Weimer wrote:
>> Old binaries with a 32-bit time_t will continue to run, but new
>> binaries built against a current glibc will always use a 64-bit time_t
>> under this approach.

> How would this affect Wine's handling of 32-bit PE binaries? I'm
> assuming they will also break with this change without much
> knowledge of the particular handling of that variable.

glibc doesn't ship anything PE, so it's not going to affect that
directly.

I assume Wine needs 32-bit libraries, and if those are 64-bit time_t
only, and Wine use time_t-based interfaces, Wine will need to be
ported and make the appropriate conversions when going from PE to the
GNU/Linux world.  Wine will probably want to do this anyway because
native Windows (outside the C/POSIX compatibility library) does not
have the Y2038 problem.  Since 64-bit time_t ports of Wine already
exist, this should not be much of an issue.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: i686 hw builders running out of ram in cpio?

[John Reiser]

Anyone else seeing this?  It seems to only happen on physical i686
machines, not vm's, but that's based on only three builds so far.

https://koji.fedoraproject.org/koji/taskinfo?taskID=36329825

BUILDSTDERR: create archive failed: cpio: write failed - Cannot allocate 
memory


Very similar to  https://bugzilla.redhat.com/show_bug.cgi?id=1729382
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

i686 hw builders running out of ram in cpio?

[DJ Delorie]

Anyone else seeing this?  It seems to only happen on physical i686
machines, not vm's, but that's based on only three builds so far.

https://koji.fedoraproject.org/koji/taskinfo?taskID=36329825

BUILDSTDERR: create archive failed: cpio: write failed - Cannot allocate 
memory

(this is after the build itself finished, while writing out one of the RPMs)

  totalusedfree  shared  buff/cache   available
Mem:  131924260  899932   105240472201225783856   129959024
Swap:   20971442048 2095096


So far this build has failed on:
  buildhw-04.phx2.fedoraproject.org
  buildhw-02.phx2.fedoraproject.org

but has succeeded on:
  buildvm-30.phx2.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[389-devel] please review: PR 50505 - requested SSL version range not correctly applied

[Mark Reynolds]

https://pagure.io/389-ds-base/pull-request/50505

--

389 Directory Server Development Team
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

Re: Options for 64-bit time_t support on 32-bit architectures

[Michael Cronenworth]

On 7/18/19 4:05 PM, Florian Weimer wrote:

Old binaries with a 32-bit time_t will continue to run, but new
binaries built against a current glibc will always use a 64-bit time_t
under this approach.



How would this affect Wine's handling of 32-bit PE binaries? I'm assuming they will also 
break with this change without much knowledge of the particular handling of that variable.

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

Options for 64-bit time_t support on 32-bit architectures

[Florian Weimer]

There is an effort under way to enhance glibc so that it can use the
Y2038 support in the kernel.  The result will be that more 32-bit
architectures can use a 64-bit time_t.  (Currently, it's x86-64 x32
only.)

Originally, the plan was to support both ABIs in glibc for building
new applications, similar to what is currently possible with
-D_FILE_OFFSET_BITS=64 for changing the size of off_t.  However, this
turned out to be difficult to implement, and so far, no one has posted
patches which appear to be reasonably correct and complete.

The latest proposal is a single-ABI mode for development:

  

Old binaries with a 32-bit time_t will continue to run, but new
binaries built against a current glibc will always use a 64-bit time_t
under this approach.

The consequence is that in order to build 32-bit-time_t libraries
(Gtk, for example), an old glibc needs to be kept around.  In
practice, it would probably mean that it is impossible to maintain a
set of 32-bit-time_t libraries in a classic distribution build
environment (with a unified buildroot and native builds).

I do not have a strong opinion about this because I personally do not
care much about 32-bit architectures.

For Fedora, that would affect the i686 architecture only.  Given that
i686 is kept around mainly for legacy applications these days, without
a kernel and installation media, I expect that Fedora prefers
compatibility with 32-bit time_t applications.  The latest proposal
(64-bit time_t only for new applications) would therefore be
problematic to Fedora.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1726163] fusioninventory-agent-2.5.1 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|fusioninventory-agent-2.5.1 |fusioninventory-agent-2.5.1
   |-1.fc30 |-1.fc30
   ||fusioninventory-agent-2.5.1
   ||-1.fc29



--- Comment #6 from Fedora Update System  ---
fusioninventory-agent-2.5.1-1.fc29 has been pushed to the Fedora 29 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Self Introduction: Dee'Kej (looking for sponsor)

[Jason L Tibbitts III]

Welcome back to Fedora.  I've clicked the necessary sponsorship buttons.

 - J<
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Vim and spec template

[Jason L Tibbitts III]

> "ZD" == Zdenek Dohnal  writes:

ZD> Hi all, I would like to ask as Vim co-maintainer, do you find useful
ZD> for Vim to do:

ZD> - when you open new file with .spec suffix, Vim will get you basic
ZD> spec file structure?

Personally I have always found that behavior annoying.  If I open a new
file, I expect that the file would be empty.  If I want a template, I
can copy one.  Editing a new HTML file doesn't bring up a template for
HTML files, for example.

The spec template used isn't something I ever want anyway.  It uses tabs
instead of spaces and uses them in a way that implies that indentation
is somehow required.  And it includes a default release tag of
"0%{?dist}" which isn't permitted by the packaging guidelines.
(Releases start at one except when packaging prerelease software, and are
never exactly zero.)

Best to leave it to the packager to choose their own template, or to
allow somehow who wants templating behavior to configure templating in a
general way.

 - J<
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1726163] fusioninventory-agent-2.5.1 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||fusioninventory-agent-2.5.1
   ||-1.fc30
 Resolution|--- |ERRATA
Last Closed||2019-07-18 17:55:56



--- Comment #5 from Fedora Update System  ---
fusioninventory-agent-2.5.1-1.fc30 has been pushed to the Fedora 30 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1720744] perl-Crypt-Rijndael-1.14 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Crypt-Rijndael-1.14-1. |perl-Crypt-Rijndael-1.14-1.
   |fc31|fc31
   ||perl-Crypt-Rijndael-1.14-1.
   ||fc30
 Resolution|--- |ERRATA
Last Closed||2019-07-18 17:55:59



--- Comment #4 from Fedora Update System  ---
perl-Crypt-Rijndael-1.14-1.fc30 has been pushed to the Fedora 30 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: MPFR 4

[Jerry James]

On Fri, Jul 12, 2019 at 9:07 AM Jerry James  wrote:
> I'm down to these 3 still to go: arm-none-eabi-gcc-cs, avr-gcc, and
> cross-gcc.  Those gcc builds take a long time. :-)  So far the builds
> have gone smoothly.

All the builds have completed without trouble.  I did have to patch a
couple of packages to use mpfr_rootn_ui() instead of mpfr_root().
That required a little care since those two functions are only
*mostly* equivalent.  Other than that, there have been no issues at
all.

> Does anyone at RedHat know if Pavel is on vacation?  If not, what is
> the best way to contact him?

I would like to ask again if anyone who works at RedHat can check on
Pavel's status.  It would be good to know if he is not available until
, or if he is too busy to pay attention to mpfr.  Thank you.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Vim and spec template

[Steven A. Falco]

On 7/18/19 10:28 AM, Zdenek Dohnal wrote:
> 
> On 7/18/19 4:10 PM, Vitaly Zaitsev via devel wrote:
>> Hello, Zdenek Dohnal.
>>
>> Thu, 18 Jul 2019 15:51:33 +0200 you wrote:
>>
>>> Even the new .spec files, which do not have to be RPM spec files?
>>> Because Vim provides spec template for such cases.
>> I never used this feature, so I think it can be disabled by default.
> That's the thing which I asked for opinion on, not about syntax
> highlighting.

Ah - now I understand.  I thought you were asking about syntax highlighting.

I had never noticed the feature of creating a new spec file from a template, 
because I have my own .vimrc file, so the /etc/vimrc file has no effect for me.

I think having a template for just this single file type is kind of "strange".  
I'd personally be fine with removing that line from /etc/vimrc.  I'd expect 
users who want templates to set them up for themselves, rather than forcing 
users to disable templates they don't want.

Steve




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: true or false: pkgconfig(foo) vs foo-devel

[Nicolas Chauvet]

Le jeu. 18 juil. 2019 à 17:12, Philip Kovacs via devel
 a écrit :
>
> > It does not matter if the config process uses pkgconfig or not.
> > Depending on the package name is not a way to state you're not using
> > pkgconfig, it's a way to get broken builds when the package you depend
> > on gets restructured.
>
> Then the docs should be strengthened to state the case from the perspective 
> of the provider
> of the .pc and not the consumer of it:
>
> Current:
>
> "Fedora packages which use pkg-config to build against a library (e.g. 'foo') 
> on which they depend,
>  SHOULD express their build dependency correctly as pkgconfig(foo)."
>
> becomes:
>
> "Build dependencies on Fedora packages which provide pkg-config files SHOULD 
> be expressed
>  as pkgconfig(foo) and not foo-devel, whether the dependent package uses 
> pkg-config or not."

This is true for the fast majority of cases. Specially where there is
only one provider of pkgconfig(foo).

But sometime there is a need for a compat library and then I don't
know if my package may uses the main library of the compat one.
pkgconfig(foo) will pick one or the other, but using the package name
is more deterministic to me.

-- 
-

Nicolas (kwizart)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Compiling with AddressSanitizer

[Nathanael D. Noblet]

On Thu, 2019-07-18 at 10:25 +0200, Florian Weimer wrote:
> * Nathanael Noblet:
> 
> >I have been using a library for awhile now and have been
> > thinking
> >of submitting it to Fedora. Part of what I have been doing with
> > it
> >was compiling it using -fsanitize=address and leak etc. I’m
> > kinda
> >wondering about how that is handled with Fedora packages. Are we
> >able to / should we provide library package versions that are
> >compiled against these kinds of sanitizers?
> 
> Address Sanitizer does not provide ABI stability itself, and also
> removes ABI stability for glibc functions.  In general, you cannot
> use it for distribution builds.

Right, I think I didn't communicate it clearly. What I meant was having
like libfoo and libfoo-sanitized or something like that that conflict
with each other so you could install libfoo-sanitized for debug
purposes. It seems that the answer is likely no need to do it.

> 
> >Or if someone wants to do that they should recompile the RPM
> > with
> >those flags and use it locally?
> 
> Yes, rebuilding the RPM or the upstream sources is currently the only
> way.
> 
> Thanks,
> Florian

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

Self Introduction: Dee'Kej (looking for sponsor)

[David Kašpar]

Hello,

my name is David Kaspar (a.k.a. Dee'Kej), and I used to be a package
maintainer as a Red Hat employee for 3.5 years. Now that I'm no longer part
of Red Hat I can't use my old Red Hat associated accounts to help with the
work on Fedora...

Therefore I have restored my old 'deekej' FAS account, and I'm currently
looking for a sponsorship for packagers group here, because right now I
don't have any new package I would like to add into Fedora (to set a
blocker to FE-NEEDSPONSOR BZ). I hope my previous contributions &
experience will be enough for someone to grant it. :)

I used to maintain these packages:
* initscripts
* ghostscript (+ libijs, urw-base35-fonts, ...)
* gawk
* tcsh

With kind regards,

Dee'Kej
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: true or false: pkgconfig(foo) vs foo-devel

[Neal Gompa]

On Thu, Jul 18, 2019 at 10:26 AM Philip Kovacs via devel
 wrote:
>
> A "necessary and sufficient" question on the use of .pc files supplied by 
> library providers.
>
> 1. Package foo-devel installs a pkgconfig .pc file as a convenience to 
> developers.
> 2. Package bar requires headers and libraries provided by foo and is both a 
> build
> and runtime dependency of foo.
> 3. Package bar uses autotools and m4 to discover and test for the presence
> of foo.h and libfoo, but does not use not pkgconfig in any way.
>
> True or False:
>
> The spec for package bar MUST use BuildRequires: foo-devel and not
> BuildRequires: pkgconfig(foo), because bar does not use pkgconfig directly.
>
> Ref: 
> https://docs.fedoraproject.org/en-US/packaging-guidelines/PkgConfigBuildRequires/
>

Technically, I suppose the wording strongly pushes that way. It’s
certainly the guideline I use myself.

But it’s also worth examining if you can contribute upstream to change
it to use pkgconfig instead.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Vim and spec template

[Zdenek Dohnal]

On 7/18/19 4:10 PM, Vitaly Zaitsev via devel wrote:
> Hello, Zdenek Dohnal.
>
> Thu, 18 Jul 2019 15:51:33 +0200 you wrote:
>
>> Even the new .spec files, which do not have to be RPM spec files?
>> Because Vim provides spec template for such cases.
> I never used this feature, so I think it can be disabled by default.
That's the thing which I asked for opinion on, not about syntax
highlighting.
>  But
> syntax highlighting for RPM SPEC files should be enabled.
>
> --
> Sincerely,
>  Vitaly Zaitsev (vit...@easycoding.org)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

-- 
Zdenek Dohnal
Software Engineer
Red Hat Czech - Brno TPB-C




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: true or false: pkgconfig(foo) vs foo-devel

[Philip Kovacs via devel]

 > It does not matter if the config process uses pkgconfig or not. 
> Depending on the package name is not a way to state you're not using 
> pkgconfig, it's a way to get broken builds when the package you depend 
> on gets restructured.

Then the docs should be strengthened to state the case from the perspective of 
the providerof the .pc and not the consumer of it:
Current:
"Fedora packages which use pkg-config to build against a library (e.g. 'foo') 
on which they depend,  SHOULD express their build dependency correctly as 
pkgconfig(foo)."

becomes:
"Build dependencies on Fedora packages which provide pkg-config files SHOULD be 
expressed as pkgconfig(foo) and not foo-devel, whether the dependent package 
uses pkg-config or not."

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

[389-devel] Re: Do we still need sslVersionMax/sslVersionMin?

[Mark Reynolds]

On 7/17/19 11:47 PM, William Brown wrote:



On 17 Jul 2019, at 22:36, Mark Reynolds  wrote:


On 7/17/19 3:01 AM, Matus Honek wrote:

I think we cannot remove it. Setting the MIN version is a workaround
for *old clients* not even supporting current NSS' default min.
Setting up MAX version is a workaround for *broken clients* thinking
they can support something they announced but for some reason fail to
work with such a version. I believe most of deployments have some
really legacy software of which not a small amount behaves weirdly
enough these two options save lives; I have seen these issues several
times.

Did you see anyone still using SSL3?

The min is good to allow a sysadmin to clamp the min version up to something 
like TLS1.2 rather than TLS 1.0 and 1.1 which both have known issues.

So  Ithink we should leave this, but default to the NSS system wide crypto, and 
document and advise to use NSS systemd wide crypto policy instead.
Well the bug I have is now is the NSS system wide policy is overriding 
min and max ssl versions and always using (min TLS 1.2 -> max TLS 1.3).  
Looks like if you try and use SSL3 it just overrides it in the current 
version of NSS anyway.  So I am probably going to remove all the SSL3 
specific code in ssl.c.  But I'll keep the min and max settings...



On Tue, Jul 16, 2019 at 10:24 PM Mark Reynolds  wrote:

So some time ago when the poodlebleed vulnerability came out in SSL3 we
added a way to set the minimum and maximum SSL/TLS versions the server
would accept (e.g. TLS1.1 <--> TLS1.2).Current versions of NSS
already use this range by default.  I would like to remove/deprecate the
sslVersionMin/Max and just use what NSS uses by default (which should be
the system wide crypto policy).

Is anyone actually using sslVersionMin/Max?  Do we really have a need
for it anymore?

--

389 Directory Server Development Team
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org



--

389 Directory Server Development Team
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org


--

389 Directory Server Development Team
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

Re: Vim and spec template

[Vitaly Zaitsev via devel]

Hello, Zdenek Dohnal.

Thu, 18 Jul 2019 15:51:33 +0200 you wrote:

> Even the new .spec files, which do not have to be RPM spec files?
> Because Vim provides spec template for such cases.

I never used this feature, so I think it can be disabled by default. But
syntax highlighting for RPM SPEC files should be enabled.

--
Sincerely,
 Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Vim and spec template

[Nicolas Mailhot via devel]

Le 2019-07-18 15:51, Zdenek Dohnal a écrit :

On 7/18/19 3:39 PM, Vitaly Zaitsev via devel wrote:

Hello, Zdenek Dohnal.

Thu, 18 Jul 2019 13:44:56 +0200 you wrote:

What's your opinion? Is it useful feature of Vim and it should stay 
as

default, or it needs to be disabled?
I think, that *.spec files on Fedora should be treated as RPM SPEC 
files

by default.


Even the new .spec files, which do not have to be RPM spec files?
Because Vim provides spec template for such cases.


There’s no shame in shipping Fedora software with defaults oriented 
towards Fedora needs. Software needs to have default settings. 
Default-less unconfigured apps are just painful to use.


Having httpd default to realaudio mime types for rpm files was quite 
painful…


--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: true or false: pkgconfig(foo) vs foo-devel

[Nicolas Mailhot via devel]

As stated in


https://docs.fedoraproject.org/en-US/packaging-guidelines/PkgConfigBuildRequires/


pkgconfig(foo) is a more reliable marker of what ships the devel files, 
than the package name.


It does not matter if the config process uses pkgconfig or not. 
Depending on the package name is not a way to state you're not using 
pkgconfig, it's a way to get broken builds when the package you depend 
on gets restructured.


rpm filename deps are less reliable than rpm font package deps, which 
are themselves less reliable than automatically computed virtual deps


--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Vim and spec template

[Zdenek Dohnal]

On 7/18/19 3:39 PM, Vitaly Zaitsev via devel wrote:
> Hello, Zdenek Dohnal.
>
> Thu, 18 Jul 2019 13:44:56 +0200 you wrote:
>
>> What's your opinion? Is it useful feature of Vim and it should stay as
>> default, or it needs to be disabled?
> I think, that *.spec files on Fedora should be treated as RPM SPEC files
> by default.

Even the new .spec files, which do not have to be RPM spec files?
Because Vim provides spec template for such cases.

> --
> Sincerely,
>  Vitaly Zaitsev (vit...@easycoding.org)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

-- 
Zdenek Dohnal
Software Engineer
Red Hat Czech - Brno TPB-C




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Vim and spec template

[Zdenek Dohnal]

On 7/18/19 3:25 PM, Steven A. Falco wrote:
> On 7/18/19 7:44 AM, Zdenek Dohnal wrote:
>> Hi all,
>>
>> I would like to ask as Vim co-maintainer, do you find useful for Vim to do:
>>
>> - when you open new file with .spec suffix, Vim will get you basic spec
>> file structure?
>>
>> Recently I found out someone can find it as bad behavior
>> https://bugzilla.redhat.com/show_bug.cgi?id=1724126 , so I consider
>> changing the default vimrc to tell Vim 'Don't do it'.
>>
>> What's your opinion? Is it useful feature of Vim and it should stay as
>> default, or it needs to be disabled?
> I've never had a problem with it, but then I only edit rpm spec files.
>
> If you were to remove it from /etc/vimrc, would the normal syntax system 
> still provide a good way to edit rpm spec files?

Yep, AFAIK syntax while editing spec will not be changed - just
providing basic spec file structure will be removed (you will have plain
file) when you create new spec file. That could be useful for people who
creates new package from scratch though...

>
>   Steve
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

-- 
Zdenek Dohnal
Software Engineer
Red Hat Czech - Brno TPB-C



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Vim and spec template

[Vitaly Zaitsev via devel]

Hello, Zdenek Dohnal.

Thu, 18 Jul 2019 13:44:56 +0200 you wrote:

> What's your opinion? Is it useful feature of Vim and it should stay as
> default, or it needs to be disabled?

I think, that *.spec files on Fedora should be treated as RPM SPEC files
by default.

--
Sincerely,
 Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

true or false: pkgconfig(foo) vs foo-devel

[Philip Kovacs via devel]

A "necessary and sufficient" question on the use of .pc files supplied by 
library providers.
1. Package foo-devel installs a pkgconfig .pc file as a convenience to 
developers.
2. Package bar requires headers and libraries provided by foo and is both a 
build    and runtime dependency of foo.3. Package bar uses autotools and m4 to 
discover and test for the presence    of foo.h and libfoo, but does not use not 
pkgconfig in any way.
True or False:
The spec for package bar MUST use BuildRequires: foo-devel and not 
BuildRequires: pkgconfig(foo), because bar does not use pkgconfig directly.
Ref: 
https://docs.fedoraproject.org/en-US/packaging-guidelines/PkgConfigBuildRequires/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Vim and spec template

[Steven A. Falco]

On 7/18/19 7:44 AM, Zdenek Dohnal wrote:
> Hi all,
> 
> I would like to ask as Vim co-maintainer, do you find useful for Vim to do:
> 
> - when you open new file with .spec suffix, Vim will get you basic spec
> file structure?
> 
> Recently I found out someone can find it as bad behavior
> https://bugzilla.redhat.com/show_bug.cgi?id=1724126 , so I consider
> changing the default vimrc to tell Vim 'Don't do it'.
> 
> What's your opinion? Is it useful feature of Vim and it should stay as
> default, or it needs to be disabled?

I've never had a problem with it, but then I only edit rpm spec files.

If you were to remove it from /etc/vimrc, would the normal syntax system still 
provide a good way to edit rpm spec files?

Steve




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

jaxen-1.2.0 license change

[Marián Konček]

The package jaxen at least since version 1.2.0 no longer includes the 
only differently (under W3C) licensed file from the rest (BSD) which 
leaves the package with a single license (BSD).


--

Marián Konček
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Vim and spec template

[Till Hofmann]

On 7/18/19 1:44 PM, Zdenek Dohnal wrote:
> Hi all,
> 
> I would like to ask as Vim co-maintainer, do you find useful for Vim to do:
> 
> - when you open new file with .spec suffix, Vim will get you basic spec
> file structure?
> 
> Recently I found out someone can find it as bad behavior
> https://bugzilla.redhat.com/show_bug.cgi?id=1724126 , so I consider
> changing the default vimrc to tell Vim 'Don't do it'.
> 
> What's your opinion? Is it useful feature of Vim and it should stay as
> default, or it needs to be disabled?
> 

Generally, I find templates very useful, but I use the vim-template
plugin for that, and I was surprised to see that vim ships its own
template just for SPECs. Imo, everyone who wants a template should use a
plugin. Shipping one by default just for SPECs is somewhat inconsistent.

Kind regards,
Till
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Orphaning rubygem-{fission,CFPropertyList}

[Vít Ondruch]

rubygem-fission + rubygem-CFPropertyList which is its dependency used to
be used by rubygem-fog-* packages. Because these were dropped couple of
months ago, I don't have any other use for
rubygem-{fission,CFPropertyList} therefore I am orphaning them.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Vim and spec template

[Zdenek Dohnal]

Hi all,

I would like to ask as Vim co-maintainer, do you find useful for Vim to do:

- when you open new file with .spec suffix, Vim will get you basic spec
file structure?

Recently I found out someone can find it as bad behavior
https://bugzilla.redhat.com/show_bug.cgi?id=1724126 , so I consider
changing the default vimrc to tell Vim 'Don't do it'.

What's your opinion? Is it useful feature of Vim and it should stay as
default, or it needs to be disabled?

-- 
Zdenek Dohnal
Software Engineer
Red Hat Czech - Brno TPB-C




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Orphaning rubygem-ldap_fluff

[Vít Ondruch]

I don't have any use for this library, so I have orphaned it.


Vít
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Outage: Upgrade of Copr servers - 2019-07-18 05:00 UTC

[Jakub Kadlcik]

The outage is done, all our servers are now running Fedora 30 and
everything should work again.
We apologize for any inconvenience caused by the outage.

Jakub

On Tue, Jul 16, 2019 at 10:03 PM Jakub Kadlcik  wrote:
>
> There will be an outage starting at 2019-07-18 05:00 UTC, which will last
> approximately 6 hours.
>
> To convert UTC to your local time, take a look at
> https://fedoraproject.org/wiki/UTCHowto
> or run:
>
> date -d '2019-07-18 05:00 UTC'
>
> Reason for outage:
>
> Upgrade of Copr servers to Fedora 30.
>
> Affected Services:
>
> copr-frontend - https://copr.fedorainfracloud.org
> copr-backend - https://copr-be.cloud.fedoraproject.org/
> copr-distgit
> copr-keygen
>
> Ticket Link:
>
> https://pagure.io/fedora-infrastructure/issue/8006
>
> Contact Information:
>
> Please join #fedora-admin in irc.freenode.net or add comments to the
> ticket for this outage above.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Orphaned AsciiBinder

[Vít Ondruch]

AsciiBinder was introduced into Fedora to help generate Fedora
documentation. Nevertheless, it has been long replaced by Antora. I
don't have any use for AsciiBinder myself and it is deprecated upstream
(the home page should be switched of on July 31, 2019), therefore I have
orphaned rubygem-ascii_binder (+ rubygem-sitemap_generator which is
AsciiBinder dependency).


Vít
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned python2-django1.11

[Nicolas Chauvet]

Le mer. 19 juin 2019 à 15:16, Petr Viktorin  a écrit :
>
> Hello,
> Back when [Django 2.0] was released in Fedora 28, I took over Django
> 1.11 LTS as some important (to me) packages depended on it. I'm no
> longer interested in maintaining it, so I've orphaned it.
> Let me know if you want to take it. If no one does, it may be removed
> from Rawhide in 6 weeks.
>
> Depending packages and their maintainers are:
> - fts-monitoring (andreamanzi, simonm)
> - python-oauth2client (mbaldessari, ralph)
> - cobbler-web (jimi, kwizart, orion, shenson)
>
> Let me know if you need help with these packages.

I will take-over the python2-django1.11 as cobbler_web uses it (until
moved to python3 soon).
Thx

--
-

Nicolas (kwizart)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Compiling with AddressSanitizer

[Dan Čermák]

Hi Nathanael,

Nathanael Noblet  writes:

> Hello,
>
>I have been using a library for awhile now and have been thinking of 
> submitting it to Fedora. Part of what I have been doing with it was compiling 
> it using -fsanitize=address and leak etc. I’m kinda wondering about how that 
> is handled with Fedora packages. Are we able to / should we provide library 
> package versions that are compiled against these kinds of sanitizers? Or if 
> someone wants to do that they should recompile the RPM with those flags and 
> use it locally?
>

Address sanitizer is a debugging tool and beside the issues that Florian
mentioned, there are also security issues involved with running ASAN
applications in production:
https://www.openwall.com/lists/oss-security/2016/02/17/9 (not sure if
this is still relevant though).

I'd certainly suggest to build applications with ASAN, UBSAN,and MSAN,
but only do that for testing. If you want to integrate this in the
rpmbuild process, you could rebuild your application in %check with ASAN
enabled and run its test suite.


Cheers,

Dan


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Compiling with AddressSanitizer

[Dan Čermák]

Hi Nathanael,

Nathanael Noblet  writes:

> Hello,
>
>I have been using a library for awhile now and have been thinking of 
> submitting it to Fedora. Part of what I have been doing with it was compiling 
> it using -fsanitize=address and leak etc. I’m kinda wondering about how that 
> is handled with Fedora packages. Are we able to / should we provide library 
> package versions that are compiled against these kinds of sanitizers? Or if 
> someone wants to do that they should recompile the RPM with those flags and 
> use it locally?
>

Address sanitizer is a debugging tool and beside the issues that Florian
mentioned, there are also security issues involved with running ASAN
applications in production:
https://www.openwall.com/lists/oss-security/2016/02/17/9 (not sure if
this is still relevant though).

I'd certainly suggest to build applications with ASAN, UBSAN,and MSAN,
but only do that for testing. If you want to integrate this in the
rpmbuild process, you could rebuild your application in %check with ASAN
enabled and run its test suite.


Cheers,

Dan


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Compiling with AddressSanitizer

[Florian Weimer]

* Nathanael Noblet:

>I have been using a library for awhile now and have been thinking
>of submitting it to Fedora. Part of what I have been doing with it
>was compiling it using -fsanitize=address and leak etc. I’m kinda
>wondering about how that is handled with Fedora packages. Are we
>able to / should we provide library package versions that are
>compiled against these kinds of sanitizers?

Address Sanitizer does not provide ABI stability itself, and also
removes ABI stability for glibc functions.  In general, you cannot use
it for distribution builds.

>Or if someone wants to do that they should recompile the RPM with
>those flags and use it locally?

Yes, rebuilding the RPM or the upstream sources is currently the only
way.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1731013] New: Upgrade perl-Net-Stomp to 0.60

[bugzilla]

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

Bug ID: 1731013
   Summary: Upgrade perl-Net-Stomp to 0.60
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Net-Stomp
  Assignee: lkund...@v3.sk
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: fi...@andresovi.net, lkund...@v3.sk,
perl-devel@lists.fedoraproject.org, sce...@gmail.com
  Target Milestone: ---
Classification: Fedora



Latest Fedora delivers 0.57 version. Upstream released 0.60. When you have free
time, please upgrade it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Discussion around app retirements and categorizations by the CPE team

[Michal Konecny]

On 7/17/19 10:00 PM, Emmanuel Seyman wrote:

My initial reaction is that the lists of applications in categories 1 and 2
are very short. My second reaction is that this page doesn't sell me that
I should use Python in any business-critical software...
These categories are not complete at all. We didn't go through every 
application we own and put it to specific category. We only got through 
part of our list. It will be long process till we get through whole 
list. In the first CPE blog [0] about changes in our team you can see 
that we are currently maintaining 112 services and we have only 19 
people to do this.


Is release-monitoring.org also maintained by the CPE? It's being broken for
ages and I feel it's a shame it doesn't get more love.
I'm the main maintainer/developer of release-monitoring.org and I 
recently deployed a new version to staging environment, but I'm 
currently busy working with others on Rawhide Gating. I will have talk 
about future of release-monitoring.org on Flock, you can meet me there 
and we could discuss about this or feel free to add any bug to 
release-monitoring.org tracker [1].


There is currently one issue, that is blocking reporting bugs in 
bugzilla, unfortunately this is issue on bugzilla [2] side.


I'm also trying to write blog posts [3] regularly about my work.


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

Michal

[0] - 
https://communityblog.fedoraproject.org/state-of-the-community-platform-engineering-team/

[1] - https://github.com/release-monitoring/anitya/issues
[2] - https://bugzilla.redhat.com/show_bug.cgi?id=1679385
[3] - https://communityblog.fedoraproject.org/tag/release-monitoring-org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org