[Bug 1798151] perl-Devel-PatchPerl-1.86 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Devel-PatchPerl-1.86-1
   ||.fc32
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
Last Closed||2020-02-05 07:52:03



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

[rpms/perl-Filter] PR #1: Spec file cleanups: Use make_build and make_install macros

[Petr Pisar]

ppisar merged a pull-request against the project: `perl-Filter` that you are 
following.

Merged pull-request:

``
Spec file cleanups: Use make_build and make_install macros
``

https://src.fedoraproject.org/rpms/perl-Filter/pull-request/1
___
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

[rpms/perl-Digest-SHA] PR #1: Spec file cleanups: Use make_build and make_install macros

[Petr Pisar]

ppisar commented on the pull-request: `Spec file cleanups: Use make_build and 
make_install macros` that you are following:
``
Next time, please write the NO_PACKLIST=1 and NO_PERLLOCAL=1 together.

Also I believe it's a good idea to spell the %make_* macros with parentheses 
like %{make_build}. If the macro definition changes into a macro function, it 
would start ignoring any additional arguments.
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Digest-SHA/pull-request/1
___
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

[rpms/perl-Digest-SHA] PR #1: Spec file cleanups: Use make_build and make_install macros

[Petr Pisar]

ppisar merged a pull-request against the project: `perl-Digest-SHA` that you 
are following.

Merged pull-request:

``
Spec file cleanups: Use make_build and make_install macros
``

https://src.fedoraproject.org/rpms/perl-Digest-SHA/pull-request/1
___
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

[rpms/perl-HTML-Parser] PR #1: Spec file cleanups: Use make_build and make_install macros

[Jitka Plesnikova]

jplesnik merged a pull-request against the project: `perl-HTML-Parser` that you 
are following.

Merged pull-request:

``
Spec file cleanups: Use make_build and make_install macros
``

https://src.fedoraproject.org/rpms/perl-HTML-Parser/pull-request/1
___
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

[rpms/perl-GSSAPI] PR #1: Spec file cleanups: Use make_build and make_install macros

[Jitka Plesnikova]

jplesnik merged a pull-request against the project: `perl-GSSAPI` that you are 
following.

Merged pull-request:

``
Spec file cleanups: Use make_build and make_install macros
``

https://src.fedoraproject.org/rpms/perl-GSSAPI/pull-request/1
___
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

[rpms/perl-Devel-Size] PR #1: Spec file cleanups: Use make_build and make_install macros

[李瑞彬]

cheeselee merged a pull-request against the project: `perl-Devel-Size` that you 
are following.

Merged pull-request:

``
Spec file cleanups: Use make_build and make_install macros
``

https://src.fedoraproject.org/rpms/perl-Devel-Size/pull-request/1
___
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

[rpms/perl-DBI] PR #1: Spec file cleanups: Use make_build and make_install macros

[Jitka Plesnikova]

jplesnik merged a pull-request against the project: `perl-DBI` that you are 
following.

Merged pull-request:

``
Spec file cleanups: Use make_build and make_install macros
``

https://src.fedoraproject.org/rpms/perl-DBI/pull-request/1
___
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

[rpms/perl-DBD-SQLite] PR #1: Spec file cleanups: Use make_build and make_install macros

[Jitka Plesnikova]

jplesnik merged a pull-request against the project: `perl-DBD-SQLite` that you 
are following.

Merged pull-request:

``
Spec file cleanups: Use make_build and make_install macros
``

https://src.fedoraproject.org/rpms/perl-DBD-SQLite/pull-request/1
___
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: Fedora review tickets tracker pages

[Clement Verna]

On Tue, 4 Feb 2020 at 20:55, Mattia Verga via devel <
devel@lists.fedoraproject.org> wrote:

> Il 04/02/20 10:29, Miroslav Suchý ha scritto:
> >
> > People are asking for this for years. No one ever had time to do this.
> This make you most competent guy :) Just do it.
> >
> Well, I only have experience about some really small and simple django
> projects, nothing big like this. I see Fedora apps are using Pyramid or
> Flask: I suppose these are more flexible for our purposes? For example
> they can use SQLAlchemy, while Django uses its own ORM. Have you got any
> advice if I'm going to try setting up this new project?
>

The trend has been to try and consolidate on Flask + SQLAlchemy, so that
most of the services uses same technology stack. Flask also seems to have a
more active ecosystem than Pyramid.


>
> Mattia
>
>
> ___
> 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
>
___
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

Any plans on maintaining Apache NetBeans

[Code Zombie]

Currently at its version 11.2, Apache NetBeans is a great piece of
development software. Is Fedora considering to add it to its packages? Does
anyone already plan to maintain it or can I take it over?

- Mehdi
___
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] 389 DS nightly 2020-02-05 - 96% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2020/02/05/report-389-ds-base-1.4.2.7-1.fc31.x86_64.html
___
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

[Bug 1792861] perl-Exporter-5.74 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Exporter-5.74-1.fc32   |perl-Exporter-5.74-1.fc32
   |perl-Exporter-5.74-1.fc31   |perl-Exporter-5.74-1.fc31
   ||perl-Exporter-5.74-1.fc30



--- Comment #7 from Fedora Update System  ---
perl-Exporter-5.74-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: Orphaning hibernate

[Nico Kadel-Garcia]

On Tue, Feb 4, 2020 at 11:19 AM Michal Srb  wrote:

> This is more complicated and it would probably deserve a separate thread :) 
> Java and Python are completely different ecosystems. And Java ecosystem 
> (apps/libs) is just inherently unfriendly to Linux distributions. It's not 
> necessary bad or broken - it's just different.
>
> I am curious: what was the reason to develop against the packaged Java 
> libraries?
>
> Thanks,
> Michal

Provenance. If you're working from a packaged Java library, Perl
module, Python module, or any other kind of module, you know what
source it was built from, roughly how, and have some listing in RPM of
what it's compatible with. I've had people do "sudo pip install" that
broke python modules used by many other components, including rpm
itself. And I've had cases where what got built out of online
dependences did not have a single versioned component in common with
what got built a few days later, or that had circular dependency
incompatibilities and would no longer build, at all.
___
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: Looking for a proven packager to help merge some spec file cleanups

[Tom Stellard]

On 02/04/2020 06:07 PM, Neal Gompa wrote:
> On Tue, Feb 4, 2020 at 9:02 PM Tom Stellard  wrote:
>>
>> Hi,
>>
>> Is there a proven packager available to help me merge these:
>>
>> https://src.fedoraproject.org/rpms/blktrace/pull-request/2
>> https://src.fedoraproject.org/rpms/redhat-lsb/pull-request/4
>> https://src.fedoraproject.org/rpms/dmidecode/pull-request/2
>> https://src.fedoraproject.org/rpms/fxload/pull-request/1
>>
>> These are cleanups designed to make it possible to use a different
>> compiler just by defining %__cc, %__cxx, and
>> %__make /usr/bin/make CC=%{__cc} CXX=%{__cxx} HOSTCC=%{__cc}
>>
> 
> I've merged them all for you. :)
> 
> 

Thank you!
> 
___
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: GCC 10 how disable redefinition of thing error ?

[David Malcolm]

On Tue, 2020-02-04 at 21:13 -0500, David Malcolm wrote:
> On Wed, 2020-02-05 at 01:38 +, Sérgio Basto wrote:
> > Hi, 
> > Packages gpm, VirtualBox and webalizer have the building problem as
> > described for gpm in [1] , but VirtualBox have thousands of lines
> > with
> > this error , I'd like disable this check on VirtualBox until
> > VirtualBox
> > fix it , 
> > the author of pull request [1] also comment "The error also happens
> > if
> > CFLAGS=-fno-common passed explicitly." , any quick way to fix these
> > builds ? 
> 
> The easiest way is to add -fcommon to the build flags for the
> package:
>   https://gcc.gnu.org/gcc-10/porting_to.html#common
> (but FWIW it's best to fix it properly by adding extern to the decls
> in
> the headers, as C can generate slightly faster code that way).
  ^
  GCC, I meant to say
  
___
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: GCC 10 how disable redefinition of thing error ?

[David Malcolm]

On Wed, 2020-02-05 at 01:38 +, Sérgio Basto wrote:
> Hi, 
> Packages gpm, VirtualBox and webalizer have the building problem as
> described for gpm in [1] , but VirtualBox have thousands of lines
> with
> this error , I'd like disable this check on VirtualBox until
> VirtualBox
> fix it , 
> the author of pull request [1] also comment "The error also happens
> if
> CFLAGS=-fno-common passed explicitly." , any quick way to fix these
> builds ? 

The easiest way is to add -fcommon to the build flags for the package:
  https://gcc.gnu.org/gcc-10/porting_to.html#common
(but FWIW it's best to fix it properly by adding extern to the decls in
the headers, as C can generate slightly faster code that way).

Dave

> Thanks. 
> 
> [1]
> https://github.com/telmich/gpm/pull/37

___
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: Looking for a proven packager to help merge some spec file cleanups

[Neal Gompa]

On Tue, Feb 4, 2020 at 9:02 PM Tom Stellard  wrote:
>
> Hi,
>
> Is there a proven packager available to help me merge these:
>
> https://src.fedoraproject.org/rpms/blktrace/pull-request/2
> https://src.fedoraproject.org/rpms/redhat-lsb/pull-request/4
> https://src.fedoraproject.org/rpms/dmidecode/pull-request/2
> https://src.fedoraproject.org/rpms/fxload/pull-request/1
>
> These are cleanups designed to make it possible to use a different
> compiler just by defining %__cc, %__cxx, and
> %__make /usr/bin/make CC=%{__cc} CXX=%{__cxx} HOSTCC=%{__cc}
>

I've merged them all for you. :)



-- 
真実はいつも一つ！/ 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

Looking for a proven packager to help merge some spec file cleanups

[Tom Stellard]

Hi,

Is there a proven packager available to help me merge these:

https://src.fedoraproject.org/rpms/blktrace/pull-request/2
https://src.fedoraproject.org/rpms/redhat-lsb/pull-request/4
https://src.fedoraproject.org/rpms/dmidecode/pull-request/2
https://src.fedoraproject.org/rpms/fxload/pull-request/1

These are cleanups designed to make it possible to use a different
compiler just by defining %__cc, %__cxx, and 
%__make /usr/bin/make CC=%{__cc} CXX=%{__cxx} HOSTCC=%{__cc}


Thanks,
Tom
___
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

GCC 10 how disable redefinition of thing error ?

[Sérgio Basto]

Hi, 
Packages gpm, VirtualBox and webalizer have the building problem as
described for gpm in [1] , but VirtualBox have thousands of lines with
this error , I'd like disable this check on VirtualBox until VirtualBox
fix it , 
the author of pull request [1] also comment "The error also happens if
CFLAGS=-fno-common passed explicitly." , any quick way to fix these
builds ? 

Thanks. 

[1]
https://github.com/telmich/gpm/pull/37
-- 
Sérgio M. B.
___
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

[rpms/perl-Net-SSLeay] PR #1: Spec file cleanups: Use make_build and make_install macros

[Tom Stellard]

tstellar opened a new pull-request against the project: `perl-Net-SSLeay` that 
you are following:
``
Spec file cleanups: Use make_build and make_install macros
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Net-SSLeay/pull-request/1
___
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

[389-devel] Re: [PATCH] prevent slapd from hanging under unlikely circumstances

[William Brown]

> On 5 Feb 2020, at 03:10, Ludwig Krispenz  wrote:
> 
> I think I can agree with 1-8, 9 is one solution to fix the problem you 
> reported, but not yet validate that there are no other side effects, there 
> are potential postop plugins which should NOT be called for tombstone delete, 
> eg retro cl, we need to investigate side effects of the patch and evaluate 
> other solutions, I suggested one in anotehr reply.
> 
> for 10, the claim that not crying hurrah and merging a patch without further 
> investigation and testing is "doctrinal objection" is very strong and I have 
> to reject this.
> 
> Regards,
> Ludwig
> 
> On 02/04/2020 05:00 PM, Jay Fenlason wrote:
>> Ok, let's take this from the top:
>> 
>> 1: Defects that cause a server to become unresponsive are bad and must
>> be repaired as soon as possible.

I'm not objecting to this.

>> 
>> 2: Some #1 class defects are exploitable and require a CVE.  As far as
>> I can tell, this one does not, but you should keep an eye out for the
>> possibility.
>> 
>> 3: The #1 class defect I have found can be triggered in at least two
>> ways.  One requires ipa-replica-install and is hard to reproduce in a
>> test environment.  The other requires ldapdelete and is easy to
>> reproduce in an isolated VM.

Ipa replica install and ldapdelete of a tombstone/conflict both require 
cn=directory manager, which would automatically cause any reported CVE to be 
void - cn=directory manager is game over. 

>> 
>> 4: The defect is a mismatch between the plugin ABI as implemented by
>> 389-ds, and the behavior the NIS plugin expects.
>> 
>> 5: I have found no specification or documentation on said ABI, so I
>> can only guess what the correct behavior is here.
>> 
>> 6: The ABI includes two functions in the plugin: pre_delete and
>> post_delete.
>> 
>> 7: The NIS plugin expects that every call to pre_delete will be
>> followed by a call to post_delete.  It takes a lock in pre_delete and
>> releases it in post_delete.

But you didn't report an issue in NIS? You reported an issue with ldapdelete on 
tombstones and conflicts ... the slapi-nis plugin is maintained by freeipa and 
if an issue in it exists, please report it to them with reproduction steps. 

>> 
>> 8: Under some circumstances 389-ds can call pre_delete but fail to
>> call post_delete.  Because of #5, there is no way to tell if this is
>> expected behavior, but the NIS plugin clearly does not expect it.
>> 
>> 9: My patch ensures that every call to pre_delete is followed by a
>> corresponding call to post_delete.  V1 of the patch also ensures that
>> every call to post_delete is after a corresponding pre_delete call.
>> V2 relaxes the second requirement, allowing post_delete calls without
>> a corresponding pre_delete call because someone expressed worry about
>> potential regressions.
>> 
>> 10: You are refusing to merge my patch because of a doctrinal
>> objection to the use of ldapdelete in the simple reproducer.

It's not really a doctrinal objection. Replication is a really complex topic, 
and difficult to get correct. Ludwig knows a lot in this area, and has really 
good comments to make on the topic. I understand that you have an issue you 
have found in your setup, and you want to resolve it, but we have to consider 
the deployments of many thousands of other users and their replication 
experience too. For us it's important to be able to reproduce, and see the 
issue, to understand the consequences, and to make these changes carefully. 
Accepting the patch without clear understanding of it's consequences is not 
something we do.

At this time we still don't have a clear reproducer from you on "how" you 
constructed the invalid directory state. You reported the following:

> I found the bug by doing a series of "ipa-client-install" (with lots
> of arguments, followed by
> echo ca_host = {a not-firewalled IPA CA} >> /etc/ipa/default.conf
> echo [global] > /etc/ipa/installer.conf
> echo ca_host = {ditto} >> /etc/ipa/installer.conf
> echo {password} | kinit admin
> ipa hostgroup-add-member ipaservers --hosts $(hostname -f)
> ipa-relica-install --setup-ca --setup-dns --forwarder={ip addr}
> 
> followed by the replica install failing due to network issues,
> misconfigured firewalls, etc, then
> ipa-server-install --uninstall on the host
> and ipa-replica-manage del {failed install host}
> elsewhere in the mesh, sometimes with ldapdelete of the initial
> replication agreement that ipa-replica-manage did not remove.

I'm certainly not able to produce a reproduction case from these steps ... This 
is why I have questioned what ipa-replica-install is doing in a previous email, 
and I think that we need a better series of steps to attempt to reproduce, as 
well as better and clearer information about "what" has crashed/hung/failed in 
the directories in these states.

We still want to help, but please be patient with us as we want to ensure our 
fixes are the highest possible quality.

Thanks, 

—
Sincerely,

William 

[rpms/perl-NetAddr-IP] PR #1: Spec file cleanups: Use make_build and make_install macros

[Tom Stellard]

tstellar opened a new pull-request against the project: `perl-NetAddr-IP` that 
you are following:
``
Spec file cleanups: Use make_build and make_install macros
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-NetAddr-IP/pull-request/1
___
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

[rpms/perl-Math-BigInt-FastCalc] PR #1: Spec file cleanups: Use make_build and make_install macros

[Tom Stellard]

tstellar opened a new pull-request against the project: 
`perl-Math-BigInt-FastCalc` that you are following:
``
Spec file cleanups: Use make_build and make_install macros
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Math-BigInt-FastCalc/pull-request/1
___
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: Review swaps - practrand - Software package for the Randon number generation & testing

[Jiri Hladky]

Thanks a lot, Ankur!

I will follow up in the BZ itself.

Jirka

On Wed, Jan 29, 2020 at 8:44 PM Ankur Sinha  wrote:

> On Wed, Jan 29, 2020 01:18:48 +0100, Jiri Hladky wrote:
> > Hi,
>
> Hi Jirka,
>
> > I have a simple package for review. It's called practrand - a Software
> package
> > for the Randon number generation & testing
> > https://bugzilla.redhat.com/show_bug.cgi?id=1795461
>
> I see that it hasn't been taken up for review yet, so I can do it.
>
> > I offer to review some simple package in return.
>
> I have nothing that needs review at the moment, so that's OK :)
>
> --
> Thanks,
> Regards,
> Ankur Sinha "FranciscoD" (He / Him / His) |
> https://fedoraproject.org/wiki/User:Ankursinha
> Time zone: Europe/London
> ___
> 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
>
___
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

[rpms/perl-libintl-perl] PR #1: Spec file cleanups: Use make_build and make_install macros

[Tom Stellard]

tstellar opened a new pull-request against the project: `perl-libintl-perl` 
that you are following:
``
Spec file cleanups: Use make_build and make_install macros
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-libintl-perl/pull-request/1
___
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

[rpms/perl-IPC-SysV] PR #1: Spec file cleanups: Use make_build and make_install macros

[Tom Stellard]

tstellar opened a new pull-request against the project: `perl-IPC-SysV` that 
you are following:
``
Spec file cleanups: Use make_build and make_install macros
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-IPC-SysV/pull-request/1
___
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

[rpms/perl-HTML-Parser] PR #1: Spec file cleanups: Use make_build and make_install macros

[Tom Stellard]

tstellar opened a new pull-request against the project: `perl-HTML-Parser` that 
you are following:
``
Spec file cleanups: Use make_build and make_install macros
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-HTML-Parser/pull-request/1
___
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

[rpms/perl-GSSAPI] PR #1: Spec file cleanups: Use make_build and make_install macros

[Tom Stellard]

tstellar opened a new pull-request against the project: `perl-GSSAPI` that you 
are following:
``
Spec file cleanups: Use make_build and make_install macros
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-GSSAPI/pull-request/1
___
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

[rpms/perl-Filter] PR #1: Spec file cleanups: Use make_build and make_install macros

[Tom Stellard]

tstellar opened a new pull-request against the project: `perl-Filter` that you 
are following:
``
Spec file cleanups: Use make_build and make_install macros
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Filter/pull-request/1
___
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

[rpms/perl-FCGI] PR #1: Spec file cleanups: Use make_build and make_install macros

[Tom Stellard]

tstellar opened a new pull-request against the project: `perl-FCGI` that you 
are following:
``
Spec file cleanups: Use make_build and make_install macros
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-FCGI/pull-request/1
___
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

[rpms/perl-Digest-SHA] PR #1: Spec file cleanups: Use make_build and make_install macros

[Tom Stellard]

tstellar opened a new pull-request against the project: `perl-Digest-SHA` that 
you are following:
``
Spec file cleanups: Use make_build and make_install macros
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Digest-SHA/pull-request/1
___
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

[rpms/perl-Devel-Size] PR #1: Spec file cleanups: Use make_build and make_install macros

[Tom Stellard]

tstellar opened a new pull-request against the project: `perl-Devel-Size` that 
you are following:
``
Spec file cleanups: Use make_build and make_install macros
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Devel-Size/pull-request/1
___
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

[rpms/perl-DBI] PR #1: Spec file cleanups: Use make_build and make_install macros

[Tom Stellard]

tstellar opened a new pull-request against the project: `perl-DBI` that you are 
following:
``
Spec file cleanups: Use make_build and make_install macros
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-DBI/pull-request/1
___
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: Fedora review tickets tracker pages

[Mattia Verga via devel]

Il 04/02/20 10:29, Miroslav Suchý ha scritto:
>
> People are asking for this for years. No one ever had time to do this. This 
> make you most competent guy :) Just do it.
>
Well, I only have experience about some really small and simple django 
projects, nothing big like this. I see Fedora apps are using Pyramid or 
Flask: I suppose these are more flexible for our purposes? For example 
they can use SQLAlchemy, while Django uses its own ORM. Have you got any 
advice if I'm going to try setting up this new project?

Mattia


___
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

[rpms/perl-DBD-SQLite] PR #1: Spec file cleanups: Use make_build and make_install macros

[Tom Stellard]

tstellar opened a new pull-request against the project: `perl-DBD-SQLite` that 
you are following:
``
Spec file cleanups: Use make_build and make_install macros
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-DBD-SQLite/pull-request/1
___
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

Fedora 32 Change complete deadline coming up (and other schedule items)

[Ben Cotton]

The change complete (testable) deadline for Fedora 32 changes is
Tuesday 11 February. At this point, changes should be in a testable
state. Please indicate this by setting the tracker bug for your change
to the MODIFIED state.

Other upcoming schedule milestones:
* 2020-02-11: Fedora 32 branches from Rawhide
* 2020-02-25: Change complete (100%) deadline
* 2020-02-25: Bodhi updates-testing activation
* 2020-02-25: Beta freeze begins

For more information, see the schedule[1]

[1] https://fedorapeople.org/groups/schedule/f-32/f-32-devel-tasks.html

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-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-annou...@lists.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

Fedora 32 Change complete deadline coming up (and other schedule items)

[Ben Cotton]

The change complete (testable) deadline for Fedora 32 changes is
Tuesday 11 February. At this point, changes should be in a testable
state. Please indicate this by setting the tracker bug for your change
to the MODIFIED state.

Other upcoming schedule milestones:
* 2020-02-11: Fedora 32 branches from Rawhide
* 2020-02-25: Change complete (100%) deadline
* 2020-02-25: Bodhi updates-testing activation
* 2020-02-25: Beta freeze begins

For more information, see the schedule[1]

[1] https://fedorapeople.org/groups/schedule/f-32/f-32-devel-tasks.html

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-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-announce@lists.fedoraproject.org

Fedora 32 release-blocking deliverables

[Ben Cotton]

The list of release-blocking deliverables for Fedora 32 is
available[1]. If there are any changes that should be made that were
part of an already-accepted Fedora 32 Change proposal, please let me
know. If an edit is required that was not part of an accepted Change
proposal, please file a FESCo ticket[2].

Please note that this list does not include non-blocking deliverables.

[1] https://fedoraproject.org/wiki/Releases/32/ReleaseBlocking
[2] https://pagure.io/fesco/new_issue


--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-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-annou...@lists.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

Fedora 32 release-blocking deliverables

[Ben Cotton]

The list of release-blocking deliverables for Fedora 32 is
available[1]. If there are any changes that should be made that were
part of an already-accepted Fedora 32 Change proposal, please let me
know. If an edit is required that was not part of an accepted Change
proposal, please file a FESCo ticket[2].

Please note that this list does not include non-blocking deliverables.

[1] https://fedoraproject.org/wiki/Releases/32/ReleaseBlocking
[2] https://pagure.io/fesco/new_issue


--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-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-announce@lists.fedoraproject.org

Re: Possible gcc/s390x bug (was Re: Mass rebuild status)

[Marek Polacek]

On Tue, Feb 04, 2020 at 11:08:22AM -0500, Marek Polacek wrote:
> On Tue, Feb 04, 2020 at 10:51:17AM -0500, Adam Jackson wrote:
> > On Sat, 2020-02-01 at 16:59 -0800, Kevin Fenzi wrote:
> > 
> > > See
> > > https://kojipkgs.fedoraproject.org/mass-rebuild/f32-failures.html
> > > and
> > > https://kojipkgs.fedoraproject.org/mass-rebuild/f32-need-rebuild.html
> > > 
> > > for detailed lists of what needs rebuilding and what failed. 
> > 
> > libXt's failure on s390x seems to be repeatable, unique to that
> > architecture, and frankly hilarious:
> 
> Actually I can also reproduce on x86_64 with -O3:
> 
> $ ./cc1 -quiet -O3 -Werror=array-bounds ajax.i
> PassivGrab.c: In function ‘_XtCheckServerGrabsOnWidget’:
> PassivGrab.c:291:54: error: array subscript 0 is outside array bounds of 
> ‘XtServerGrabRec[1]’ {aka ‘struct _XtServerGrabRec[1]’} [-Werror=array-bounds]
> PassivGrab.c:546:21: note: while referencing ‘tempGrab’
> 
> > PassivGrab.c: In function '_XtCheckServerGrabsOnWidget':
> > PassivGrab.c:292:35: error: array subscript 0 is outside array bounds of 
> > 'XtServerGrabRec[1]' {aka 'struct _XtServerGrabRec[1]'} 
> > [-Werror=array-bounds]
> >   292 |  first.pMask = GRABEXT(pFirstGrab)->pModifiersMask;
> > PassivGrab.c:556:22: note: while referencing 'tempGrab'
> >   556 | XtServerGrabRec  tempGrab;
> >   |  ^~~~
> > 
> > Where GRABEXT here is just doing the standard C trick for incrementing
> > past the current struct and returning a (differently typed) pointer to
> > the data beyond:
> > 
> > #define GRABEXT(p) ((XtServerGrabExtPtr)((p)+1))
> > 
> > A scratch build, including a dump of PassivGrab.i in the build.log, can
> > be found here:
> > 
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=41355653
> > 
> > Any ideas?
> 
> Thanks, we'll take a look.

I've reduced the code and opened
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582

--
Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA
___
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

[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Co

[smooge]

Dear all,

You are kindly invited to the meeting:
   EPEL Steering Co on 2020-02-05 from 18:00:00 to 19:00:00 GMT
   At freenode@fedora-meeting

The meeting will be about:
This is the weekly EPEL Steering Committee Meeting. A general agenda is the 
following:

#meetingname EPEL
#topic Intros
#topic Old Business
#topic EPEL-6
#topic EPEL-7
#topic EPEL-8
#topic Openfloor
#endmeeting




Source: https://apps.fedoraproject.org/calendar/meeting/9672/

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

Re: Orphaning hibernate

[Bill Chatfield via devel]

 Great feedback. Thanks! :-)

On Tuesday, February 4, 2020, 11:19:31 AM EST, Michal Srb  
wrote:  
 
 

On Tue, Feb 4, 2020 at 5:07 PM Neal Gompa  wrote:

On Tue, Feb 4, 2020 at 10:36 AM Michal Srb  wrote:
>
> Hi Bill,
>
>
> On Tue, Feb 4, 2020 at 4:29 PM Bill Chatfield via devel 
>  wrote:
>>
>> I may take it as soon as I figure out how.
>>
>> But, if you're building a Java app, you probably use Maven to build it, so 
>> Maven is going to download from mavencentral, not the version packaged in 
>> Fedora. So I'm beginning to wonder how useful the packaged apps are. Am I 
>> missing something?
>
>
> Packaged Java apps are useful, but packaged libraries (if not used by any 
> Java app in the distribution) not so much. Nobody's going to develop anything 
> against them. Like you said, developers will fetch what they need from Maven 
> Central.
>

If we don't have packaged libraries, nobody can ship packaged
applications. And there are definitely cases where people develop
against packaged Java libraries. I used to work in one such case.
Nowadays I live primarily in the Python ecosystem, and I can live
entirely in packaged libraries there too. It'd be nice to have this
again for Java.



This is more complicated and it would probably deserve a separate thread :) 
Java and Python are completely different ecosystems. And Java ecosystem 
(apps/libs) is just inherently unfriendly to Linux distributions. It's not 
necessary bad or broken - it's just different.

I am curious: what was the reason to develop against the packaged Java 
libraries?

Thanks,Michal
 


-- 
真実はいつも一つ！/ 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

___
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
  ___
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: fleet-commander* main admin

[Peter Robinson]

On Tue, Feb 4, 2020 at 3:22 PM Miro Hrončok  wrote:
>
> Hello Alberto, Oliver,
>
> given
>
> https://siliconislandblog.wordpress.com/2019/11/20/hanging-the-red-hat/
>
> Should the three packages still owned by Alberto:
>
>   fleet-commander
>   fleet-commander-admin
>   fleet-commander-client
>
> Be reassigned to Oliver, or orphaned? We have an open bugzilla for one of them
> and bugzilla doesn't let us needinfo Alberto.

Maybe reach out to Christian as he was his manager.

> Thanks,
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> 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
___
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: [PATCH] prevent slapd from hanging under unlikely circumstances

[Ludwig Krispenz]

I think I can agree with 1-8, 9 is one solution to fix the problem you 
reported, but not yet validate that there are no other side effects, 
there are potential postop plugins which should NOT be called for 
tombstone delete, eg retro cl, we need to investigate side effects of 
the patch and evaluate other solutions, I suggested one in anotehr reply.


for 10, the claim that not crying hurrah and merging a patch without 
further investigation and testing is "doctrinal objection" is very 
strong and I have to reject this.


Regards,
Ludwig

On 02/04/2020 05:00 PM, Jay Fenlason wrote:

Ok, let's take this from the top:

1: Defects that cause a server to become unresponsive are bad and must
be repaired as soon as possible.

2: Some #1 class defects are exploitable and require a CVE.  As far as
I can tell, this one does not, but you should keep an eye out for the
possibility.

3: The #1 class defect I have found can be triggered in at least two
ways.  One requires ipa-replica-install and is hard to reproduce in a
test environment.  The other requires ldapdelete and is easy to
reproduce in an isolated VM.

4: The defect is a mismatch between the plugin ABI as implemented by
389-ds, and the behavior the NIS plugin expects.

5: I have found no specification or documentation on said ABI, so I
can only guess what the correct behavior is here.

6: The ABI includes two functions in the plugin: pre_delete and
post_delete.

7: The NIS plugin expects that every call to pre_delete will be
followed by a call to post_delete.  It takes a lock in pre_delete and
releases it in post_delete.

8: Under some circumstances 389-ds can call pre_delete but fail to
call post_delete.  Because of #5, there is no way to tell if this is
expected behavior, but the NIS plugin clearly does not expect it.

9: My patch ensures that every call to pre_delete is followed by a
corresponding call to post_delete.  V1 of the patch also ensures that
every call to post_delete is after a corresponding pre_delete call.
V2 relaxes the second requirement, allowing post_delete calls without
a corresponding pre_delete call because someone expressed worry about
potential regressions.

10: You are refusing to merge my patch because of a doctrinal
objection to the use of ldapdelete in the simple reproducer.
___
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


--
Red Hat GmbH, http://www.de.redhat.com/, Sitz: Grasbrunn,
Handelsregister: Amtsgericht München, HRB 153243,
Geschäftsführer: Charles Cachera, Laurie Krebs, Michael O'Neill, Thomas Savage
___
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-devel] Re: [PATCH] prevent slapd from hanging under unlikely circumstances

[Ludwig Krispenz]

Hi,

I agree with you that calls to pre and post should be balance, but not 
sure if your approach is the correct one. There is a condition for post 
"!delete_tombstone_entries" which prevented the call for postop plugins 
in case of the deletion of a tombstone entry. Your patch now ensures 
that it will be called in this cases. I think the correct way would be 
to also prevent the calls to preop in case of delete_tombstone_entry, 
this is an operation to remove replication artifacts and should not be 
known by plugins


Regards,
Ludwig

On 02/03/2020 04:57 PM, Jay Fenlason wrote:

Here's a backtrace of the hung server:
All of the other threads are in pthread_cond_wait(), select() or poll()

#0  0x7fce1454f35e in pthread_rwlock_wrlock ()
 at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_rwlock_wrlock.S:85
#1  0x7fce16e1acca in slapi_rwlock_wrlock (rwlock=)
 at ldap/servers/slapd/slapi2nspr.c:237
#2  0x7fce06a74748 in wrap_rwlock_wrlock (rwlock=)
 at wrap.c:328
#3  0x7fce06a7344c in plugin_wrlock () at map.c:1242
#4  0x7fce06a5d639 in backend_be_pre_write_cb (pb=)
 at back-sch.c:2381
#5  0x7fce16df8028 in plugin_call_func (list=0x55ddade18840, 
operation=operation@entry=453, pb=pb@entry=0x55ddaf08afc0, 
call_one=call_one@entry=0)
 at ldap/servers/slapd/plugin.c:2028
#6  0x7fce16df82e3 in plugin_call_list (pb=0x55ddaf08afc0, operation=453, 
list=) at ldap/servers/slapd/plugin.c:1972
#7  0x7fce16df82e3 in plugin_call_plugins (pb=pb@entry=0x55ddaf08afc0, 
whichfunction=whichfunction@entry=453) at ldap/servers/slapd/plugin.c:442
#8  0x7fce08a31c88 in ldbm_back_delete (pb=0x55ddaf08afc0)
 at ldap/servers/slapd/back-ldbm/ldbm_delete.c:373
#9  0x7fce16da8feb in op_shared_delete (pb=pb@entry=0x55ddaf08afc0)
 at ldap/servers/slapd/delete.c:324
#10 0x7fce16da9383 in do_delete (pb=pb@entry=0x55ddaf08afc0)
 at ldap/servers/slapd/delete.c:97
#11 0x55ddac64e62c in connection_dispatch_operation (pb=0x55ddaf08afc0, 
op=0x55ddadd17340, conn=0x55ddaf12ed00) at ldap/servers/slapd/connection.c:615
#12 0x55ddac64e62c in connection_threadmain ()
 at ldap/servers/slapd/connection.c:1790
#13 0x7fce14babc5b in _pt_root (arg=0x55ddaf0186c0)
 at ../../../nspr/pr/src/pthreads/ptthread.c:201
#14 0x7fce1454be65 in start_thread (arg=0x7fcdf405d700)
 at pthread_create.c:307
#15 0x7fce13bf788d in clone ()
 at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111



My thought when writing the patch was that calls to the pre delete callback
and the post delete callback should be balanced: either both of them should be
called or neither.  But you know the plugin abi better than I do, and if
you think it's ok to have the post callback called without a corresponding pre
who am I to argue?  I've just confirmed that this patch also prevents
the hangs I'm seeing:

--- a/ldap/servers/slapd/back-ldbm/ldbm_delete.c.orig   2020-01-31 
07:28:04.085861174 -0500
+++ b/ldap/servers/slapd/back-ldbm/ldbm_delete.c2020-01-31 
07:30:33.932947489 -0500
@@ -81,6 +81,7 @@
  Connection *pb_conn;
  int32_t parent_op = 0;
  struct timespec parent_time;
+int pre_delete_called = 0;
  
  if (slapi_pblock_get(pb, SLAPI_CONN_ID, _id) < 0) {

  conn_id = 0; /* connection is NULL */
@@ -371,6 +372,7 @@
  }
  if (retval == 0) {
  retval = plugin_call_plugins(pb, 
SLAPI_PLUGIN_BE_PRE_DELETE_FN);
+   pre_delete_called = 1;
  }
  if (retval)
  {
@@ -1491,7 +1493,7 @@
   * The bepostop is called even if the operation fails,
   * but not if the operation is purging tombstones.
   */
-if (!delete_tombstone_entry) {
+if (!delete_tombstone_entry || pre_delete_called) {
  plugin_call_plugins(pb, SLAPI_PLUGIN_BE_POST_DELETE_FN);
  }
  /* Need to return to cache after post op plugins are called */


Signed-off-by: Jay Fenlason 
___
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


--
Red Hat GmbH, http://www.de.redhat.com/, Sitz: Grasbrunn,
Handelsregister: Amtsgericht München, HRB 153243,
Geschäftsführer: Charles Cachera, Laurie Krebs, Michael O'Neill, Thomas Savage
___
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: 

[Bug 1798151] New: perl-Devel-PatchPerl-1.86 is available

[bugzilla]

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

Bug ID: 1798151
   Summary: perl-Devel-PatchPerl-1.86 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Devel-PatchPerl
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.86
Current version/release in rawhide: 1.84-1.fc32
URL: http://search.cpan.org/dist/Devel-PatchPerl/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/6561/

-- 
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: Orphaning hibernate

[Michal Srb]

On Tue, Feb 4, 2020 at 5:07 PM Neal Gompa  wrote:

> On Tue, Feb 4, 2020 at 10:36 AM Michal Srb  wrote:
> >
> > Hi Bill,
> >
> >
> > On Tue, Feb 4, 2020 at 4:29 PM Bill Chatfield via devel <
> devel@lists.fedoraproject.org> wrote:
> >>
> >> I may take it as soon as I figure out how.
> >>
> >> But, if you're building a Java app, you probably use Maven to build it,
> so Maven is going to download from mavencentral, not the version packaged
> in Fedora. So I'm beginning to wonder how useful the packaged apps are. Am
> I missing something?
> >
> >
> > Packaged Java apps are useful, but packaged libraries (if not used by
> any Java app in the distribution) not so much. Nobody's going to develop
> anything against them. Like you said, developers will fetch what they need
> from Maven Central.
> >
>
> If we don't have packaged libraries, nobody can ship packaged
> applications. And there are definitely cases where people develop
> against packaged Java libraries. I used to work in one such case.
> Nowadays I live primarily in the Python ecosystem, and I can live
> entirely in packaged libraries there too. It'd be nice to have this
> again for Java.
>
>
This is more complicated and it would probably deserve a separate thread :)
Java and Python are completely different ecosystems. And Java ecosystem
(apps/libs) is just inherently unfriendly to Linux distributions. It's not
necessary bad or broken - it's just different.

I am curious: what was the reason to develop against the packaged Java
libraries?

Thanks,
Michal


>
>
> --
> 真実はいつも一つ！/ 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
>
___
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

Fedora-Rawhide-20200204.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Compose FAILS proposed Rawhide gating check!
6 of 43 required tests failed, 17 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 27/158 (x86_64), 1/2 (arm)

Old failures (same test failed in Fedora-Rawhide-20200203.n.0):

ID: 516869  Test: x86_64 Server-dvd-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/516869
ID: 516908  Test: x86_64 Workstation-live-iso install_default@uefi 
**GATING**
URL: https://openqa.fedoraproject.org/tests/516908
ID: 516909  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/516909
ID: 516910  Test: x86_64 Workstation-live-iso install_default_upload 
**GATING**
URL: https://openqa.fedoraproject.org/tests/516910
ID: 516925  Test: x86_64 KDE-live-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/516925
ID: 516930  Test: x86_64 KDE-live-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/516930
ID: 516934  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/516934
ID: 516936  Test: x86_64 KDE-live-iso install_no_user **GATING**
URL: https://openqa.fedoraproject.org/tests/516936
ID: 516943  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/516943
ID: 516953  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/516953
ID: 516954  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/516954
ID: 516955  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/516955
ID: 516957  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/516957
ID: 516962  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/516962
ID: 516975  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/516975
ID: 516977  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/516977
ID: 516979  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/516979
ID: 516992  Test: x86_64 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/516992
ID: 516993  Test: x86_64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/516993
ID: 516998  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/516998
ID: 516999  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/516999
ID: 517006  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/517006
ID: 517015  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/517015
ID: 517016  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/517016
ID: 517017  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/517017
ID: 517018  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/517018
ID: 517021  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/517021
ID: 517024  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/517024

Soft failed openQA tests: 8/158 (x86_64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Rawhide-20200203.n.0):

ID: 516866  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/516866
ID: 516867  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/516867
ID: 516874  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/516874
ID: 516883  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/516883
ID: 516899  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/516899
ID: 516945  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/516945
ID: 516956  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/516956
ID: 516989  Test: x86_64 universal install_serial_console
URL: https://openqa.fedoraproject.org/tests/516989

Passed openQA tests: 67/158 (x86_64)

New passes (same test not passed in Fedora-Rawhide-20200203.n.0):

ID: 516892  Test: x86_64 Server-dvd-iso mediakit_repoclosure
URL: https://openqa.fedoraproject.org/tests/516892
ID: 516948  Test: 

Re: Possible gcc/s390x bug (was Re: Mass rebuild status)

[Marek Polacek]

On Tue, Feb 04, 2020 at 10:51:17AM -0500, Adam Jackson wrote:
> On Sat, 2020-02-01 at 16:59 -0800, Kevin Fenzi wrote:
> 
> > See
> > https://kojipkgs.fedoraproject.org/mass-rebuild/f32-failures.html
> > and
> > https://kojipkgs.fedoraproject.org/mass-rebuild/f32-need-rebuild.html
> > 
> > for detailed lists of what needs rebuilding and what failed. 
> 
> libXt's failure on s390x seems to be repeatable, unique to that
> architecture, and frankly hilarious:

Actually I can also reproduce on x86_64 with -O3:

$ ./cc1 -quiet -O3 -Werror=array-bounds ajax.i
PassivGrab.c: In function ‘_XtCheckServerGrabsOnWidget’:
PassivGrab.c:291:54: error: array subscript 0 is outside array bounds of 
‘XtServerGrabRec[1]’ {aka ‘struct _XtServerGrabRec[1]’} [-Werror=array-bounds]
PassivGrab.c:546:21: note: while referencing ‘tempGrab’

> PassivGrab.c: In function '_XtCheckServerGrabsOnWidget':
> PassivGrab.c:292:35: error: array subscript 0 is outside array bounds of 
> 'XtServerGrabRec[1]' {aka 'struct _XtServerGrabRec[1]'} [-Werror=array-bounds]
>   292 |  first.pMask = GRABEXT(pFirstGrab)->pModifiersMask;
> PassivGrab.c:556:22: note: while referencing 'tempGrab'
>   556 | XtServerGrabRec  tempGrab;
>   |  ^~~~
> 
> Where GRABEXT here is just doing the standard C trick for incrementing
> past the current struct and returning a (differently typed) pointer to
> the data beyond:
> 
> #define GRABEXT(p) ((XtServerGrabExtPtr)((p)+1))
> 
> A scratch build, including a dump of PassivGrab.i in the build.log, can
> be found here:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=41355653
> 
> Any ideas?

Thanks, we'll take a look.

Marek
___
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: Orphaning hibernate

[Neal Gompa]

On Tue, Feb 4, 2020 at 10:36 AM Michal Srb  wrote:
>
> Hi Bill,
>
>
> On Tue, Feb 4, 2020 at 4:29 PM Bill Chatfield via devel 
>  wrote:
>>
>> I may take it as soon as I figure out how.
>>
>> But, if you're building a Java app, you probably use Maven to build it, so 
>> Maven is going to download from mavencentral, not the version packaged in 
>> Fedora. So I'm beginning to wonder how useful the packaged apps are. Am I 
>> missing something?
>
>
> Packaged Java apps are useful, but packaged libraries (if not used by any 
> Java app in the distribution) not so much. Nobody's going to develop anything 
> against them. Like you said, developers will fetch what they need from Maven 
> Central.
>

If we don't have packaged libraries, nobody can ship packaged
applications. And there are definitely cases where people develop
against packaged Java libraries. I used to work in one such case.
Nowadays I live primarily in the Python ecosystem, and I can live
entirely in packaged libraries there too. It'd be nice to have this
again for Java.



-- 
真実はいつも一つ！/ 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

Fedora rawhide compose report: 20200204.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20200203.n.0
NEW: Fedora-Rawhide-20200204.n.0

= SUMMARY =
Added images:2
Dropped images:  0
Added packages:  3
Dropped packages:8
Upgraded packages:   208
Downgraded packages: 0

Size of added packages:  333.98 KiB
Size of dropped packages:16.41 MiB
Size of upgraded packages:   3.07 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   72.16 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: SoaS raw-xz armhfp
Path: Spins/armhfp/images/Fedora-SoaS-armhfp-Rawhide-20200204.n.0-sda.raw.xz
Image: SoaS live x86_64
Path: Spins/x86_64/iso/Fedora-SoaS-Live-x86_64-Rawhide-20200204.n.0.iso

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: python-readthedocs-sphinx-ext-1.0.1-1.fc32
Summary: Sphinx extension for Read the Docs overrides
RPMs:python3-readthedocs-sphinx-ext
Size:35.15 KiB

Package: python-shodan-1.21.3-3.fc32
Summary: Python library and command-line utility for Shodan.io
RPMs:python-shodan-doc python3-shodan shodan
Size:246.37 KiB

Package: string-template-maven-plugin-1.1-1.fc32
Summary: Execute StringTemplate files during a maven build
RPMs:string-template-maven-plugin string-template-maven-plugin-javadoc
Size:52.46 KiB


= DROPPED PACKAGES =
Package: elasticsearch-1.7.1-3.fc24
Summary: Open source, flexible, distributed search and analytics engine
RPMs:elasticsearch elasticsearch-javadoc
Size:15.37 MiB

Package: expresso-0.9.2-11.fc28
Summary: A lightweight, fast, test-driven development (TDD) framework for 
Node.js
RPMs:expresso
Size:33.36 KiB

Package: nuvola-app-logitech-media-server-2.2-6.fc29
Summary: Logitech Media Server for Nuvola Player 3
RPMs:nuvola-app-logitech-media-server
Size:179.51 KiB

Package: nuvola-app-plex-1.3-5.fc29
Summary: Plex integration for Nuvola Player
RPMs:nuvola-app-plex
Size:165.51 KiB

Package: nuvola-app-soundcloud-1.3-5.fc29
Summary: SoundCloud WebApp for Nuvola Player 3
RPMs:nuvola-app-soundcloud
Size:119.39 KiB

Package: nuvola-app-yandex-music-1.5-5.fc29
Summary: Yandex Music script for Nuvola Player 3
RPMs:nuvola-app-yandex-music
Size:162.71 KiB

Package: xorg-x11-drv-geode-2.11.19-10.fc31
Summary: Xorg X11 AMD Geode video driver
RPMs:xorg-x11-drv-geode
Size:142.17 KiB

Package: xorg-x11-xfwp-1.0.2-15.fc30
Summary: X.Org X11 X firewall proxy
RPMs:xorg-x11-xfwp
Size:252.77 KiB


= UPGRADED PACKAGES =
Package:  FAudio-20.02-1.fc32
Old package:  FAudio-20.01-2.fc32
Summary:  FNA is a reimplementation of the Microsoft XNA Game Studio 4.0 
Refresh libraries
RPMs: libFAudio libFAudio-devel
Size: 786.44 KiB
Size change:  2.38 KiB
Changelog:
  * Mon Feb 03 2020 Michael Cronenworth  - 20.02-1
  - Update to 20.02


Package:  Field3D-1.7.2-18.fc32
Old package:  Field3D-1.7.2-16.fc31
Summary:  Library for storing voxel data
RPMs: Field3D Field3D-devel
Size: 9.76 MiB
Size change:  -237.79 KiB
Changelog:
  * Tue Jan 28 2020 Fedora Release Engineering  - 
1.7.2-17
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild

  * Mon Feb 03 2020 Kalev Lember  - 1.7.2-18
  - Avoid hardcoding man page compression


Package:  NetworkManager-1:1.22.6-2.fc32
Old package:  NetworkManager-1:1.22.4-1.fc32
Summary:  Network connection manager and user applications
RPMs: NetworkManager NetworkManager-adsl NetworkManager-bluetooth 
NetworkManager-cloud-setup NetworkManager-config-connectivity-fedora 
NetworkManager-config-server NetworkManager-dispatcher-routing-rules 
NetworkManager-libnm NetworkManager-libnm-devel NetworkManager-ovs 
NetworkManager-ppp NetworkManager-team NetworkManager-tui NetworkManager-wifi 
NetworkManager-wwan
Size: 27.13 MiB
Size change:  233.67 KiB
Changelog:
  * Tue Jan 28 2020 Fedora Release Engineering  - 
1:1.22.4-1.1
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild

  * Mon Feb 03 2020 Beniamino Galvani  - 1:1.22.6-1
  - Update to 1.22.6

  * Mon Feb 03 2020 Beniamino Galvani  - 1:1.22.6-2
  - Fix build with GCC 10


Package:  OpenIPMI-2.0.28-3.fc32
Old package:  OpenIPMI-2.0.28-1.fc32
Summary:  IPMI (Intelligent Platform Management Interface) library and tools
RPMs: OpenIPMI OpenIPMI-devel OpenIPMI-lanserv OpenIPMI-libs 
OpenIPMI-perl python3-openipmi
Size: 7.05 MiB
Size change:  125.05 KiB
Changelog:
  * Tue Jan 28 2020 Fedora Release Engineering  - 
2.0.28-2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild

  * Mon Feb 03 2020 Vaclav Dolezal  - 2.0.28-3
  - Cleanup of openipmi-helper script; removed no-udev branch (#1579773)


Package:  anaconda-32.22-1.fc32
Old package:  anaconda-32.21-1.fc32
Summary:  Graphical system installer
RPMs: anaconda anaconda-core anaconda-dracut anaconda-gui 
anaconda-install-env-deps anaconda-live anaconda-tui anaconda-widgets 
anaconda-widgets-devel

[389-devel] Re: [PATCH] prevent slapd from hanging under unlikely circumstances

[Jay Fenlason]

Ok, let's take this from the top:

1: Defects that cause a server to become unresponsive are bad and must
be repaired as soon as possible.

2: Some #1 class defects are exploitable and require a CVE.  As far as
I can tell, this one does not, but you should keep an eye out for the
possibility.

3: The #1 class defect I have found can be triggered in at least two
ways.  One requires ipa-replica-install and is hard to reproduce in a
test environment.  The other requires ldapdelete and is easy to
reproduce in an isolated VM.

4: The defect is a mismatch between the plugin ABI as implemented by
389-ds, and the behavior the NIS plugin expects.

5: I have found no specification or documentation on said ABI, so I
can only guess what the correct behavior is here.

6: The ABI includes two functions in the plugin: pre_delete and
post_delete.

7: The NIS plugin expects that every call to pre_delete will be
followed by a call to post_delete.  It takes a lock in pre_delete and
releases it in post_delete.

8: Under some circumstances 389-ds can call pre_delete but fail to
call post_delete.  Because of #5, there is no way to tell if this is
expected behavior, but the NIS plugin clearly does not expect it.

9: My patch ensures that every call to pre_delete is followed by a
corresponding call to post_delete.  V1 of the patch also ensures that
every call to post_delete is after a corresponding pre_delete call.
V2 relaxes the second requirement, allowing post_delete calls without
a corresponding pre_delete call because someone expressed worry about
potential regressions.

10: You are refusing to merge my patch because of a doctrinal
objection to the use of ldapdelete in the simple reproducer.
___
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

Possible gcc/s390x bug (was Re: Mass rebuild status)

[Adam Jackson]

On Sat, 2020-02-01 at 16:59 -0800, Kevin Fenzi wrote:

> See
> https://kojipkgs.fedoraproject.org/mass-rebuild/f32-failures.html
> and
> https://kojipkgs.fedoraproject.org/mass-rebuild/f32-need-rebuild.html
> 
> for detailed lists of what needs rebuilding and what failed. 

libXt's failure on s390x seems to be repeatable, unique to that
architecture, and frankly hilarious:

PassivGrab.c: In function '_XtCheckServerGrabsOnWidget':
PassivGrab.c:292:35: error: array subscript 0 is outside array bounds of 
'XtServerGrabRec[1]' {aka 'struct _XtServerGrabRec[1]'} [-Werror=array-bounds]
  292 |  first.pMask = GRABEXT(pFirstGrab)->pModifiersMask;
PassivGrab.c:556:22: note: while referencing 'tempGrab'
  556 | XtServerGrabRec  tempGrab;
  |  ^~~~

Where GRABEXT here is just doing the standard C trick for incrementing
past the current struct and returning a (differently typed) pointer to
the data beyond:

#define GRABEXT(p) ((XtServerGrabExtPtr)((p)+1))

A scratch build, including a dump of PassivGrab.i in the build.log, can
be found here:

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

Any ideas?

- ajx
___
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: Change proposal discussion - Optimize SquashFS Size

[Kevin Kofler]

Kamil Paral wrote:
> I very much agree with this. The official compose gets done just once,
> lowest priority (Note that most tested configurations actually decrease
> the compose time, or increase slightly, but nothing major). The image size
> is important, so that stuff fits on a flash drive. But the proposed
> changes differ in just a few percent increase or decrease. That is not a
> major change in any way. On the other hand, the install time differences
> *are* major - we can have 30-40% reduction in install time. You can argue
> that install gets done just once and is also not an important factor. That
> is true, for a standard user. But there are areas where hundreds of
> installation are performed each day, and such a big reduction really
> matters. Of course, my job, QA, is one of those areas. CI is another. Any
> third party vendor-related testing can be impacted in the same way. The
> more we steer towards automated testing and continuous integration, the
> more important the compose time and installation time will be. And because
> usually you do many installations from a single compose, the installation
> time is the more important one.

The areas where hundreds of installations are performed from an image are 
hardly the common case, and those installations should really consider 
composing their own images with exactly the package set that they need 
(including site packages that Fedora cannot ship), images which they can 
then compress with a faster-to-decompress algorithm. I think that we should 
optimize for the standard user who installs exactly once.

And on a slow enough connection (e.g., dial-up, which is still common in 
large parts of the world), "a few percent increase or decrease" in download 
time can mean hours of difference, much more than even 30-40% of install 
time. (Assuming that your numbers are even accurate, which I have not seen 
any proof of so far.) Please do not focus on US and European users only. 
(And even here in Europe, not everyone has broadband.)

And finally, those few percent can make the difference between fitting on a 
given fixed-size physical media or not. The original change proposal of 
trying to minimize the size might actually make at least the smaller spins 
fit on a DVD again. (Even though compression alone is not a silver bullet to 
compensate all the other bloat that has been added over time. It can only 
help alleviate the impact.)

Kevin Kofler
___
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: Orphaning hibernate

[Michal Srb]

Hi Bill,


On Tue, Feb 4, 2020 at 4:29 PM Bill Chatfield via devel <
devel@lists.fedoraproject.org> wrote:

> I may take it as soon as I figure out how.
>
> But, if you're building a Java app, you probably use Maven to build it, so
> Maven is going to download from mavencentral, not the version packaged in
> Fedora. So I'm beginning to wonder how useful the packaged apps are. Am I
> missing something?
>

Packaged Java apps are useful, but packaged libraries (if not used by any
Java app in the distribution) not so much. Nobody's going to develop
anything against them. Like you said, developers will fetch what they need
from Maven Central.

Thanks,
Michal


>
> On Tuesday, February 4, 2020, 4:25:48 AM EST, Kevin Kofler <
> kevin.kof...@chello.at> wrote:
>
>
> Fabio Valentini wrote:
> > No fedora package depends on hibernate or any of its subpackages. It
> > can be safely removed.
>
> Java on Fedora is in a really really sad state when we do not even carry
> ubiquitous libraries DEVELOPED BY RED HAT! (But no, I am not signing up to
> do the work for Red Hat, also because I do not use the packaged version of
> Hibernate. That packaged Hibernate would be useful to package Java
> applications, but nobody is working on that anymore. Sad.)
>
> Kevin Kofler
> ___
> 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
> ___
> 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
>
___
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: Orphaning hibernate

[Bill Chatfield via devel]

 I may take it as soon as I figure out how.
But, if you're building a Java app, you probably use Maven to build it, so 
Maven is going to download from mavencentral, not the version packaged in 
Fedora. So I'm beginning to wonder how useful the packaged apps are. Am I 
missing something?

On Tuesday, February 4, 2020, 4:25:48 AM EST, Kevin Kofler 
 wrote:  
 
 Fabio Valentini wrote:
> No fedora package depends on hibernate or any of its subpackages. It
> can be safely removed.

Java on Fedora is in a really really sad state when we do not even carry 
ubiquitous libraries DEVELOPED BY RED HAT! (But no, I am not signing up to 
do the work for Red Hat, also because I do not use the packaged version of 
Hibernate. That packaged Hibernate would be useful to package Java 
applications, but nobody is working on that anymore. Sad.)

        Kevin Kofler
___
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
  ___
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

fleet-commander* main admin

[Miro Hrončok]

Hello Alberto, Oliver,

given

https://siliconislandblog.wordpress.com/2019/11/20/hanging-the-red-hat/

Should the three packages still owned by Alberto:

 fleet-commander
 fleet-commander-admin
 fleet-commander-client

Be reassigned to Oliver, or orphaned? We have an open bugzilla for one of them 
and bugzilla doesn't let us needinfo Alberto.


Thanks,
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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

[EPEL-devel] Re: Need to get Steering Committee consensus: packages in old modules

[Troy Dawson]

On Tue, Feb 4, 2020 at 12:37 AM Petr Pisar  wrote:
>
> On Mon, Feb 03, 2020 at 02:35:43PM -0500, Stephen John Smoogen wrote:
> > My main job is working with Fedora Infrastructure, and we are trying to
> > work out how to handle:
> >
> > https://pagure.io/fedora-infrastructure/issue/8558
> >
> > The problem is that various tools filter what packages can be branched into
> > Fedora see that libssh2 was in a module that RHEL shipped in 8.0 but it is
> > no longer in the release with 8.1.
> >
> > Do we need to make libssh2 a module?
> > Should we allow libssh2 be branched as a 'bare' package in EPEL proper?
> > Other?
> >
> RHEL keeps old packages and old modules in repositories. That means even on
> a fresh RHEL 8.1 installation you will get a virt:rhel stream that will
> provide the libssh2 package. The package will come from an older virt:rhel
> module build.
>
> Because DNF prefers modular packages over bare packages, despite that EPEL
> provides libssh2 bare package, the EPEL one will be masked and the modular
> RHEL one preferred.
>
> Because virt:rhel is a default stream, the stream is active by default and
> thus this modular filter applies by default.
>
> Hence adding a bare libssh2 package to EPEL won't help. EPEL needs to
> provide a modular libssh2 package with a higher package NEVRA if the goal is
> to overtake the libssh2 package maintenance from RHEL to EPEL.
>
> So far my humble knowledge of DNF. I believe DNF team knows about this
> limitation and one of their goals for the future is to make a modular package
> obsolescence possible.
>
> -- Petr

So, I just want to bring up something.  The customers assumptions were wrong.
1 - They said that libssh2 was in RHEL 8.0 AppStream, but removed in RHEL 8.1.
Nope, it was never in a non-module in RHEL 8 at all.
2 - They said that libssh2 is not available at all in RHEL 8.1, even
from modules.
Nope.  It totally is.
I just did a fresh install of RHEL 8.1.  This is a minimal install,
but even minimal get's the virt module enabled.
The RHEL 8.1 module has libssh2 in it.

The rumor that libssh2 was in RHEL 8.0 AppStream is false.  The rumor
that it was removed in RHEL 8.1 is false.

BUT ... that doesn't change the problem that people want libssh2 from EPEL.
I think this is a valid request and should be discussed.
I just want the facts to get straightened out.

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

Re: Change proposal discussion - Optimize SquashFS Size

[John Reiser]

On 2/3/20, David Cantrell wrote:

https://fedoraproject.org/wiki/Category:Changes/OptimizeSquashFS

   [[snip]]

Being the engineering steering committee, we all had our own ideas and
opinions about what the problem is and how best to approach it.

   [[snip]]

It seems to me that there is not enough practical experience
with anything other than the current xz (+ ext4 + squashfs).

So run an experiment, such as:  Before beta freeze, if a [rawhide]
compose starts on an odd-numbered day-of-month, then use xz.
If a compose starts on an even-numbered day, then use zstd -19 -b 1M.
At beta freeze, then reduce the frequency of changing from daily,
to weekly or less.  Changing back-and-forth ought to affect only
a small number of packages such as: compose tool, dracut, ananconda.

Such an experiment should provide experience to better-inform a choice.
___
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: Proxies for Copr repositories

[Till Hofmann]

On 2/4/20 2:58 PM, Miroslav Suchý wrote:
> Dne 04. 02. 20 v 13:18 Till Hofmann napsal(a):
>> Does COPR itself also use the CDN for builds? I usually build dependency
> 
> Yes. Since today.
> 
>> chains, and since this morning, I see a lot of build failures due to a
>> newly built package not being available. One example:
>> - The newly built dependency:
>> https://copr.fedorainfracloud.org/coprs/thofmann/ros/build/1220759/
>> - failed build, it cannot find the previously built package:
>> https://copr.fedorainfracloud.org/coprs/thofmann/ros/build/1220790/
> 
> I find the hard way, that repodata was cached too aggressively (with TTL 
> 86400).
> 
> repodata are now sent with
>   Cache-Control: no-cache
> and log files (*log) with:
>   Cache-Control: no-store
> 
> and it seems to fix this issue.
> 
> 

Yes, that explains what I'm seeing. Thanks for the fix!

I guess we need to wait 24h until the wrongly cached files expire? I'm
still seeing the issue.

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

Re: Proxies for Copr repositories

[James Cassell]

On Tue, Feb 4, 2020, at 8:58 AM, Miroslav Suchý wrote:
> Dne 04. 02. 20 v 13:18 Till Hofmann napsal(a):
> > Does COPR itself also use the CDN for builds? I usually build dependency
> 
> Yes. Since today.
> 
> > chains, and since this morning, I see a lot of build failures due to a
> > newly built package not being available. One example:
> > - The newly built dependency:
> > https://copr.fedorainfracloud.org/coprs/thofmann/ros/build/1220759/
> > - failed build, it cannot find the previously built package:
> > https://copr.fedorainfracloud.org/coprs/thofmann/ros/build/1220790/
> 
> I find the hard way, that repodata was cached too aggressively (with TTL 
> 86400).
> 
> repodata are now sent with
>   Cache-Control: no-cache
> and log files (*log) with:
>   Cache-Control: no-store
> 
> and it seems to fix this issue.
> 

Hopefully that was only set for the repomd.xml so that the remaining repodata 
can be cached. (The other files have unique names.)

V/r,
James Cassell
___
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

[modularity] Modularity team meeting canceled today

[Langdon White]

As a result of PTO, fosdem, etc, availability for the meeting today is
pretty light. We should resume next week.

Langdon
___
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

[rpms/perl-Bit-Vector] PR #1: Use make_build macro

[Tom Stellard]

tstellar commented on the pull-request: `Use make_build macro` that you are 
following:
``
> I merged it. 
> However, if you want to replace make with %make_build in Perl packages, 
> please add NO_PERLLOCAL=1 to command 'perl Makefiel.PL'.

Ok, and then should I also change make pure_install to %make_install
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Bit-Vector/pull-request/1
___
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: Proxies for Copr repositories

[Miroslav Suchý]

Dne 04. 02. 20 v 13:18 Till Hofmann napsal(a):
> Does COPR itself also use the CDN for builds? I usually build dependency

Yes. Since today.

> chains, and since this morning, I see a lot of build failures due to a
> newly built package not being available. One example:
> - The newly built dependency:
> https://copr.fedorainfracloud.org/coprs/thofmann/ros/build/1220759/
> - failed build, it cannot find the previously built package:
> https://copr.fedorainfracloud.org/coprs/thofmann/ros/build/1220790/

I find the hard way, that repodata was cached too aggressively (with TTL 86400).

repodata are now sent with
  Cache-Control: no-cache
and log files (*log) with:
  Cache-Control: no-store

and it seems to fix this issue.


-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
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

[Test-Announce] Fedora 32 Rawhide 20200204.n.0 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 32 Rawhide 20200204.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
anaconda - 20200131.n.0: anaconda-32.21-1.fc32.src, 20200204.n.0: 
anaconda-32.22-1.fc32.src
pungi - 20200131.n.0: pungi-4.1.41-4.fc32.src, 20200204.n.0: 
pungi-4.2.0-1.fc32.src

Test coverage information for the current release can be seen at:
https://www.happyassassin.net/testcase_stats/32

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20200204.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20200204.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20200204.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20200204.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20200204.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20200204.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20200204.n.0_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-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/test-annou...@lists.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

Re: Ceph license change

[Daniel P . Berrangé]

On Tue, Feb 04, 2020 at 01:01:24PM +, Sage Weil wrote:
> On Tue, 4 Feb 2020, Kaleb Keithley wrote:
> > On Mon, Feb 3, 2020 at 11:35 PM Daniel P. Berrangé 
> > wrote:
> > 
> > > On Mon, Feb 03, 2020 at 11:26:46PM +0530, Kaleb Keithley wrote:
> > > > Coming in Ceph-15 (octopus)
> > > >
> > > > From: LGPL-2.1 and CC-BY-SA-3.0 and GPL-2.0 and BSL-1.0 and BSD-3-Clause
> > > > and MIT
> > > > To:  LGPL-2.1 and LGPL-3.0 and CC-BY-SA-3.0 and GPL-2.0 and BSL-1.0
> > > and
> > > > BSD-3-Clause and MIT
> > >
> > > Do you have info on which parts of Ceph are covered by the newly
> > > introduced LGPLv3.0 ?
> > >
> > 
> > Not off hand no. Maybe the new seastar bits?
> > 
> > Sage (cc'd) made the change to the upstream .spec file.  Sage?
> 
> We changed from LGPL-2.1 to LGPL-2.1 or LGPL-3.0 in order to avoid 
> ambiguity with Apache-2.0 compatibility (we use seastar).  See
> 
> https://github.com/ceph/ceph/pull/22446
> 
> FWIW none of the Apache-2.0 code affects the client library, so this 
> should have no effect on programs linking to librados or librbd 
> (like qemu), although the "or" is a blanket change across most of the 
> code and not narrowly applied in that way.

Just to be clear, can you confirm that librados/librbd will never link
to anything that is Apache 2.0 licensed, directly or indirectly ?

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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: Review Swap

[Alejandro Álvarez Ayllón]

Hello,

I'll be happy to swap a review against this one:
https://bugzilla.redhat.com/show_bug.cgi?id=1797524

El lun., 3 feb. 2020 a las 17:57, Breno Brand Fernandes ()
escribió:

> Hi,
>
> Would someone mind swapping reviews?
> I am building puppet 6 for EPEL 8 and this one[1] is the very first
> dependency.
>
> 1 https://bugzilla.redhat.com/show_bug.cgi?id=1794229
>
> Thank you!!
>
> - B
> ___
> 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
>
___
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: Change proposal discussion - Optimize SquashFS Size

[Kamil Paral]

On Mon, Feb 3, 2020 at 5:55 PM Kevin Fenzi  wrote:

> So, I propose:
> reduce install time
> reduce image size
> reduce compose time
>
> is the order we should put them in


I very much agree with this. The official compose gets done just once,
lowest priority (Note that most tested configurations actually decrease the
compose time, or increase slightly, but nothing major). The image size is
important, so that stuff fits on a flash drive. But the proposed changes
differ in just a few percent increase or decrease. That is not a major
change in any way. On the other hand, the install time differences *are*
major - we can have 30-40% reduction in install time. You can argue that
install gets done just once and is also not an important factor. That is
true, for a standard user. But there are areas where hundreds of
installation are performed each day, and such a big reduction really
matters. Of course, my job, QA, is one of those areas. CI is another. Any
third party vendor-related testing can be impacted in the same way. The
more we steer towards automated testing and continuous integration, the
more important the compose time and installation time will be. And because
usually you do many installations from a single compose, the installation
time is the more important one.
___
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: Proxies for Copr repositories

[Till Hofmann]

On 2/4/20 10:03 AM, Miroslav Suchý wrote:
> Hi,
> I just enabled the content delivery network (CDN) for Copr repositories.
> It is provided by CloudFront from AWS. And it is provided for free by Amazon 
> to Fedora.
> [...]
> 
> If you experience any problem with CDN, please let me know.
> 

First of all, great to see faster COPR mirrors!

Does COPR itself also use the CDN for builds? I usually build dependency
chains, and since this morning, I see a lot of build failures due to a
newly built package not being available. One example:
- The newly built dependency:
https://copr.fedorainfracloud.org/coprs/thofmann/ros/build/1220759/
- failed build, it cannot find the previously built package:
https://copr.fedorainfracloud.org/coprs/thofmann/ros/build/1220790/

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

[Bug 1797943] t/02_module_pod_output.t may fail if run as root

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

Link ID||CPAN 127153



-- 
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 1797943] t/02_module_pod_output.t may fail if run as root

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |WORKSFORME
   Doc Type|--- |If docs needed, set a value
Last Closed||2020-02-04 12:01:58



--- Comment #1 from Petr Pisar  ---
It works for me in Fedora 32:

root@fedora-32:~/rpmbuild/SPECS # id
uid=0(root) gid=0(root)
groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
root@fedora-32:~/rpmbuild/SPECS # rpmbuild -ba perl-Pod-Perldoc.spec
setting SOURCE_DATE_EPOCH=1580342400
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.Q5yFjw
+ umask 022
+ cd /root/rpmbuild/BUILD
+ cd /root/rpmbuild/BUILD
+ rm -rf Pod-Perldoc-3.28
+ /usr/bin/gzip -dc /root/rpmbuild/SOURCES/Pod-Perldoc-3.28.tar.gz
+ /usr/bin/tar -xof -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd Pod-Perldoc-3.28
[...]
Wrote: /root/rpmbuild/RPMS/noarch/perl-Pod-Perldoc-3.28.01-443.fc32.noarch.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.te7blw
+ umask 022
+ cd /root/rpmbuild/BUILD
+ cd Pod-Perldoc-3.28
+ /usr/bin/rm -rf
/root/rpmbuild/BUILDROOT/perl-Pod-Perldoc-3.28.01-443.fc32.x86_64
+ RPM_EC=0
++ jobs -p
+ exit 0
root@fedora-32:~/rpmbuild/SPECS # echo $?
0

I suspect you hit  this
issue when using containers. Unless you show it affects Fedora, please follow
there.

-- 
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: [ovirt-users] [feedback needed] VirtIO Windows Drivers - new installer

[Rob Verduijn]

Hi,

It's a bit late, but I didn't get around to testing before now.
All seems to work fine.
Except for the unattended bit.

When installing the guest tools
virtio-win-gt-x64.msi /qn
The installer prompts if you trust the driver from redhat because the drivers 
are not signed.

Could you sign the drivers ? 
And if you do it with a self signed cert please provide the cert on the iso.

Rob 
___
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 1797860] perl-Sereal-4.011 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Sereal-4.011-1.fc32



--- Comment #2 from Petr Pisar  ---
Code reformatted and fixes for Perl ≥ 5.31.2. A release suitable for all
Fedoras and EPEL ≥ 8. Older Fedoras and EPEL postponed until previous build
becomes stable.

-- 
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: Ceph license change

[Daniel P . Berrangé]

On Tue, Feb 04, 2020 at 03:39:14PM +0530, Kaleb Keithley wrote:
> On Mon, Feb 3, 2020 at 11:35 PM Daniel P. Berrangé 
> wrote:
> 
> > On Mon, Feb 03, 2020 at 11:26:46PM +0530, Kaleb Keithley wrote:
> > > Coming in Ceph-15 (octopus)
> > >
> > > From: LGPL-2.1 and CC-BY-SA-3.0 and GPL-2.0 and BSL-1.0 and BSD-3-Clause
> > > and MIT
> > > To:  LGPL-2.1 and LGPL-3.0 and CC-BY-SA-3.0 and GPL-2.0 and BSL-1.0
> > and
> > > BSD-3-Clause and MIT
> >
> > Do you have info on which parts of Ceph are covered by the newly
> > introduced LGPLv3.0 ?
> >
> >
> I'm still waiting for a reply to the email I sent Sage. In the meantime I
> did a cursory inspection of the source and don't see anything new that is
> licensed with LGPL 3.0.  (I'm not a lawyer and I did not do an exhaustive
> search.)
> 
> What I do see that is new is the top-level license file (i.e. COPYING file)
> has been changed to add "... or LGPL-3..."
> 
> Again, I'm not a lawyer, but AFAIK that magic word "or" in the phrase
> "LGPL-2.1 or LGPL-3" should make it acceptable for things like QEMU that
> are GPLv2.0 only.

Thanks for the pointer. I've looked at the commit which made this change
and I'm increasingly concerned that it *will* in fact impact apps like
QEMU which are GPLv2.0 only. Here is the full text:


commit 2f361a6eeebaa0aa2cb79495f108a89a862ef8bd
Author: Sage Weil 
Date:   Wed Jun 6 16:32:53 2018 -0500

relicense LGPL-2.1 code as LGPL-2.1 or LGPL-3.0

The primary motivation to relicense is a desire to integrate with projects
that are licensed under the Apache License version 2.0.  Although opinions
vary, there are some who argue the the LGPL-2.1 and Apache-2.0 licenses
are not fully compatible.  We would like to avoid the ambiguity and
potential for controversy.

Projects we would like to consume that are Apache-2.0 licensed include
Seastar, OpenSSL (which is in the process of relicensing to Apache-2.0),
and Swagger (swagger.io).  Note that some of these are dynamically linked
or consumed via a high-level language and may or may not require a change
to LGPL-3.0, but providing the option for LGPL-3.0 certainly avoids any
uncertainty.

A few other source files are already incorporated into Ceph that claim an
Apache-2.0 license:

src/common/deleter.h
src/common/sstring.h
src/include/cpp-btree

The Ceph developers would further like to provide a license option that is
more modern than the current LGPL-2.1.  LGPL-3.0 includes updated,
clarified language around several issues and is widely considered
more modern, superior license.

Signed-off-by: Sage Weil 


So in summary

  - The historical Ceph license is primarily LGPLv2.1-only
  - This prevents Ceph from using & linking to Apache 2.0 licensed code
  - Changing "LGPLv2.1-only or LGPL-3.0-only" makes Ceph *source*
compatible with Apache 2.0

That's not the end of the story for license compatibiltiy though. The
problem here is the effect on the *combined* work, and ripples to apps
using libraries.

Although the source is dual licensed LGPLv2.1-only or LGPL-3.0-only,
the presence of Apace 2.0 code eliminates the possibility to choose
LGPLv2.1-only for the combined work. The only option left for the
combined work is thus to choose LGPL-3.0-only.

If this only affects Ceph binaries, that change is self-contained at
least, so not a big problem.

If this use of Apache 2.0 code extends to the Ceph *libraries* then this
license change ripples out to affect applications linking to Ceph.

This will make Ceph incompatible with QEMU as QEMU is GPLv2-only as a
combined work.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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 1797859] perl-Sereal-Encoder-4.011 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Sereal-Encoder-4.011-1
   ||.fc32



--- Comment #2 from Petr Pisar  ---
Code reformatted and fixes for Perl ≥ 5.31.2. Generally a bug-fix release
suitable for all Fedoras and EPEL ≥ 8. Older Fedoras and EPEL postponed until
previous build becomes stable.

-- 
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 1797860] perl-Sereal-4.011 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|ppi...@redhat.com   |
   Doc Type|--- |If docs needed, set a value



-- 
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 1797859] perl-Sereal-Encoder-4.011 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|jples...@redhat.com,|
   |ppi...@redhat.com   |
   Doc Type|--- |If docs needed, set a value



-- 
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 1797858] perl-Sereal-Decoder-4.011 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Sereal-Decoder-4.011-1
   ||.fc32



--- Comment #2 from Petr Pisar  ---
Code reformatted and fixes for Perl ≥ 5.31.2. Generally a bug-fix release
suitable for all Fedoras and EPEL ≥ 8. Older Fedoras and EPEL postponed until
previous build becomes stable.

-- 
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: Ceph license change

[Miro Hrončok]

On 04. 02. 20 11:09, Kaleb Keithley wrote:
On Mon, Feb 3, 2020 at 11:35 PM Daniel P. Berrangé > wrote:


On Mon, Feb 03, 2020 at 11:26:46PM +0530, Kaleb Keithley wrote:
 > Coming in Ceph-15 (octopus)
 >
 > From: LGPL-2.1 and CC-BY-SA-3.0 and GPL-2.0 and BSL-1.0 and BSD-3-Clause
 > and MIT
 > To:      LGPL-2.1 and LGPL-3.0 and CC-BY-SA-3.0 and GPL-2.0 and BSL-1.0 
and
 > BSD-3-Clause and MIT

Do you have info on which parts of Ceph are covered by the newly
introduced LGPLv3.0 ?


I'm still waiting for a reply to the email I sent Sage. In the meantime I did a 
cursory inspection of the source and don't see anything new that is licensed 
with LGPL 3.0.  (I'm not a lawyer and I did not do an exhaustive search.)


What I do see that is new is the top-level license file (i.e. COPYING file) has 
been changed to add "... or LGPL-3..."


Again, I'm not a lawyer, but AFAIK that magic word "or" in the phrase "LGPL-2.1 
or LGPL-3" should make it acceptable for things like QEMU that are GPLv2.0 only.


Iff the above is correct, the license field should say:

(LGPL-2.1 or LGPL-3.0) and CC-BY-SA-3.0 and GPL-2.0 and BSL-1.0 and BSD-3-Clause 
and MIT



(If we ignore that those are probably SPDX license identifiers and not what 
Fedora uses.)


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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: Ceph license change

[Kaleb Keithley]

On Mon, Feb 3, 2020 at 11:35 PM Daniel P. Berrangé 
wrote:

> On Mon, Feb 03, 2020 at 11:26:46PM +0530, Kaleb Keithley wrote:
> > Coming in Ceph-15 (octopus)
> >
> > From: LGPL-2.1 and CC-BY-SA-3.0 and GPL-2.0 and BSL-1.0 and BSD-3-Clause
> > and MIT
> > To:  LGPL-2.1 and LGPL-3.0 and CC-BY-SA-3.0 and GPL-2.0 and BSL-1.0
> and
> > BSD-3-Clause and MIT
>
> Do you have info on which parts of Ceph are covered by the newly
> introduced LGPLv3.0 ?
>
>
I'm still waiting for a reply to the email I sent Sage. In the meantime I
did a cursory inspection of the source and don't see anything new that is
licensed with LGPL 3.0.  (I'm not a lawyer and I did not do an exhaustive
search.)

What I do see that is new is the top-level license file (i.e. COPYING file)
has been changed to add "... or LGPL-3..."

Again, I'm not a lawyer, but AFAIK that magic word "or" in the phrase
"LGPL-2.1 or LGPL-3" should make it acceptable for things like QEMU that
are GPLv2.0 only.



> I'm mostly wondering if this is pre-existing code changing license in
> a way that could impact existing apps/libs linking to Ceph libaries ?
>
> eg QEMU would have a problem with LGPLv3.0 in the Ceph libraries, since
> parts of the code in QEMU are GPLv2.0-only
>
> Regards,
> Daniel
> --
> |: https://berrange.com  -o-
> https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o-
> https://fstop138.berrange.com :|
> |: https://entangle-photo.org-o-
> https://www.instagram.com/dberrange :|
> ___
> 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
>
___
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 1797665] perl-CGI-4.46 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-CGI-4.46-1.fc32
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
Last Closed||2020-02-04 09:39:25



-- 
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 1797943] New: t/02_module_pod_output.t may fail if run as root

[bugzilla]

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

Bug ID: 1797943
   Summary: t/02_module_pod_output.t may fail if run as root
   Product: Fedora
   Version: 31
  Hardware: All
OS: Linux
Status: NEW
 Component: perl-Pod-Perldoc
  Severity: medium
  Assignee: ppi...@redhat.com
  Reporter: 1014938...@qq.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Description of problem:
t/02_module_pod_output.t may fail if run as root

Version-Release number of selected component (if applicable):
perl-Pod-Perldoc-3.28.01-443.fc32

How reproducible:
run make test as root

Steps to Reproduce:
1.run rpmbuild perl-Pod-Perldoc as root user
2.
3.

Actual results:
+ make test
PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness"
"-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')"
t/*.t t/*/*.t
t/00_load.t ... ok
t/01_about_verbose.t .. ok
t/02_module_pod_output.t .. 1/7
#   Failed test 'got expected output in STDOUT'
#   at t/02_module_pod_output.t line 47.
#   undef
# doesn't match '(?^:Look up Perl documentation)'

#   Failed test 'got expected output in STDERR'
#   at t/02_module_pod_output.t line 80.
#   'Can't find any loadable formatter class in
Pod::Perldoc::Totext Pod::Perldoc::Totext Pod::Perldoc::ToText
Pod::Perldoc::ToTEXT Pod::Simple::text Pod::Simple::text Pod::Simple::Text
Pod::Simple::TEXT Pod::text Pod::text Pod::Text Pod::TEXT Pod::Perldoc::ToPod?!
# Aborting
#  at /root/rpmbuild/BUILD/Pod-Perldoc-3.28/blib/script/perldoc line 6.
# '
# doesn't match '(?^:No documentation)'
# Looks like you failed 2 tests of 7.


Expected results:
success

Additional info:

-- 
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: Fedora review tickets tracker pages

[Miroslav Suchý]

Dne 02. 02. 20 v 13:13 Mattia Verga via devel napsal(a):
> I don't have enough competence to start such a big project, but if
> anyone is interested I could give a hand.

People are asking for this for years. No one ever had time to do this. This 
make you most competent guy :) Just do it.

We (the Copr team) had some plans to run rpmlint/rpminspect after build. For 
those people who are interrest in that. I
am interrested in integration with the tool you are suggesting.
And it is probably good idea to build the package in Copr which allows reviewer 
to simply enable the Copr project and
install the results to test if it actually works.
Additionally, build in Copr last longer than scratch builds in Koji.

> BTW I think that any ticket with a last changed date before 2016 should 
> be closed to do some cleanup: there are tickets never reviewed, as well 
> as tickets approved and never imported in git or (the worst cases) 
> packages approved and imported in repositories, but whose tickets were 
> never closed...

I had an time of life when I pick up the oldest tickets. Yes, some of them were 
dead, but surprisingly large amount of
people was glad that I picked it up. I finished one review which was 7 years 
old and staled for 6 years.

Instead of automatic actions I prefer to ping the people at least twice. With a 
month grace period and only then close
the ticket.
There is always some human behind the ticket and some non-trivial amount of 
work. Just closing it can be perceived as
rude by some people.

-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
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: Orphaning hibernate

[Kevin Kofler]

Fabio Valentini wrote:
> No fedora package depends on hibernate or any of its subpackages. It
> can be safely removed.

Java on Fedora is in a really really sad state when we do not even carry 
ubiquitous libraries DEVELOPED BY RED HAT! (But no, I am not signing up to 
do the work for Red Hat, also because I do not use the packaged version of 
Hibernate. That packaged Hibernate would be useful to package Java 
applications, but nobody is working on that anymore. Sad.)

Kevin Kofler
___
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 1797720] perl-DBD-Pg-3.10.4 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-DBD-Pg-3.10.4-1.fc32
 Resolution|--- |RAWHIDE
Last Closed||2020-02-04 09:22:10



-- 
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: Change proposal discussion - Optimize SquashFS Size

[Kevin Kofler]

David Cantrell wrote:
> The goals identified:
> 
> 1) Reduce the ISO image size.
> 2) Improve installation time.
> 3) Improve image composition time.
> 
> We want input from the community on what the main goal should be

1) Reduce the ISO image size.

Kevin Kofler
___
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 1797858] perl-Sereal-Decoder-4.011 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|jples...@redhat.com,|
   |ppi...@redhat.com   |
   Doc Type|--- |If docs needed, set a value



-- 
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: Change proposal discussion - Optimize SquashFS Size

[David Schwörer]

On 2/4/20 9:32 AM, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Feb 03, 2020 at 05:22:55PM +0100, Nicolas Mailhot via devel wrote:
>> Le 2020-02-03 17:11, David Cantrell a écrit :
>>
>> Hi,
>>
>>> We want input from the community on what the main goal should be and
>>> prioritize the rest.  For example, is ISO reduction size more
>>> important than
>>> improving installation time, for instance?  If so, why?
>>
>> This is a nonsensical question
> 
> Great start for constructive discussion ;(
> 
>> without defining the target hardware and connectivity.
> 
>> Hardware with weak CPU (chromebook) and high connectivity (fiber)
>> will want as low compression as possible.
>>
>> Hardware with low connectivity or low storage (chromebooks, vms)
>> will want the highest possible compression; because I/O limits will
>> wipe out any CPU win, and dnf/packagekit caches get expensive fast.
>>
>> (chromebooks are problematic in all cases)
> 
> Right. We produce just one image that has to serve all of those cases,
> i.e. the hardware we are targeting is "the average" of all Fedora
> users. (Producing more than one image with different compression
> settings was briefly discussed also, but it seems that the storage of
> multiple images is too "costly" to justify this.)  That is why we talk
> about prioritization of goals: we need to pick something that handles
> all cases and the question is which characteristics matter most to
> users.

I think that is the wrong question. It is not a question which of the
three is most important, the question is rather, to what extend are we
willing to sacrifice one for the other.

As storage has different units than installation time, they are
inherently not comparable. We should thus come up with a metric to make
them comparable.

The obvious way to make them comparable is by multiplying size by
"download speed" [MB/s]. Thus if we can agree on a speed, they are
comparable, and we can get closer to a solution.

However, the time it takes to install isn't a reproducible, well defined
quantity, but depends on the device. A way forward is to take an average
over several systems. The arithmetic average (sum all up, divide by n =
number of samples) will give skewed results towards the slowest device.
I think geometric average (multiply all, take the n-th root) could be
useful.


So if we choose this approach, which IMHO puts the discussion now on a
more technical ground, and allows to quantify how much speed we are
willing to sacrifice for size or vice versa, we need to choose:

a) Constant to convert size to speed
b) List of test systems

Concerning a)
We could again take the geometric average of several connection.

Concerning b)
Maybe 4 test systems:
high-end system with ssd (both install source and target) and high-end cpu
medium system 1: good usb drive + target ssd, medium cpu
medium system 2: cheap usb drive + target hdd, medium cpu
slow system: something like a chromebook


I have ignored composition time, because the end user does not care in
most cases. As long as it composes in a reasonable time frame, most
users don't care.

I would thus suggest trying to optimize the above to, and restrict the
possible to options, so that compose is still acceptable.

David

> 
> Zbyszek
> ___
> 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
> 
___
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

Proxies for Copr repositories

[Miroslav Suchý]

Hi,
I just enabled the content delivery network (CDN) for Copr repositories.
It is provided by CloudFront from AWS. And it is provided for free by Amazon to 
Fedora.

Technically the original URL
  copr-be.cloud.fedoraproject.org
is now accessible using
  download.copr.fedorainfracloud.org

The original URL is and will be available. You can still use it. The second one 
is CNAME for the CDN and should be much
faster for you.

The CDN is automatically enabled for new projects. Thou, if you already have 
enabled some copr repository on your
workstation/server, it will still use the old URL.
It is fine; it will continue to work.
If you want to enable CDN for your repos you have to run:
  dnf copr remove some/project
  dnf copr enable some/project
or manually change the URL in the repo file.

If you experience any problem with CDN, please let me know.

-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
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

Fedora-Cloud-31-20200204.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 1/1 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
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

[rpms/perl-Data-Dumper] PR #1: Use make_build macro

[Petr Pisar]

ppisar merged a pull-request against the project: `perl-Data-Dumper` that you 
are following.

Merged pull-request:

``
Use make_build macro
``

https://src.fedoraproject.org/rpms/perl-Data-Dumper/pull-request/1
___
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

[EPEL-devel] Re: Need to get Steering Committee consensus: packages in old modules

[Petr Pisar]

On Mon, Feb 03, 2020 at 02:35:43PM -0500, Stephen John Smoogen wrote:
> My main job is working with Fedora Infrastructure, and we are trying to
> work out how to handle:
> 
> https://pagure.io/fedora-infrastructure/issue/8558
> 
> The problem is that various tools filter what packages can be branched into
> Fedora see that libssh2 was in a module that RHEL shipped in 8.0 but it is
> no longer in the release with 8.1.
> 
> Do we need to make libssh2 a module?
> Should we allow libssh2 be branched as a 'bare' package in EPEL proper?
> Other?
> 
RHEL keeps old packages and old modules in repositories. That means even on
a fresh RHEL 8.1 installation you will get a virt:rhel stream that will
provide the libssh2 package. The package will come from an older virt:rhel
module build.

Because DNF prefers modular packages over bare packages, despite that EPEL
provides libssh2 bare package, the EPEL one will be masked and the modular
RHEL one preferred.

Because virt:rhel is a default stream, the stream is active by default and
thus this modular filter applies by default.

Hence adding a bare libssh2 package to EPEL won't help. EPEL needs to
provide a modular libssh2 package with a higher package NEVRA if the goal is
to overtake the libssh2 package maintenance from RHEL to EPEL.

So far my humble knowledge of DNF. I believe DNF team knows about this
limitation and one of their goals for the future is to make a modular package
obsolescence possible.

-- Petr


signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org

Re: Change proposal discussion - Optimize SquashFS Size

[Zbigniew Jędrzejewski-Szmek]

On Mon, Feb 03, 2020 at 05:22:55PM +0100, Nicolas Mailhot via devel wrote:
> Le 2020-02-03 17:11, David Cantrell a écrit :
> 
> Hi,
> 
> >We want input from the community on what the main goal should be and
> >prioritize the rest.  For example, is ISO reduction size more
> >important than
> >improving installation time, for instance?  If so, why?
> 
> This is a nonsensical question

Great start for constructive discussion ;(

> without defining the target hardware and connectivity.

> Hardware with weak CPU (chromebook) and high connectivity (fiber)
> will want as low compression as possible.
> 
> Hardware with low connectivity or low storage (chromebooks, vms)
> will want the highest possible compression; because I/O limits will
> wipe out any CPU win, and dnf/packagekit caches get expensive fast.
> 
> (chromebooks are problematic in all cases)

Right. We produce just one image that has to serve all of those cases,
i.e. the hardware we are targeting is "the average" of all Fedora
users. (Producing more than one image with different compression
settings was briefly discussed also, but it seems that the storage of
multiple images is too "costly" to justify this.)  That is why we talk
about prioritization of goals: we need to pick something that handles
all cases and the question is which characteristics matter most to
users.

Zbyszek
___
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: Summary/Minutes from today's FESCo Meeting (2020-02-03)

[Zbigniew Jędrzejewski-Szmek]

On Mon, Feb 03, 2020 at 04:54:12PM +0100, Fabio Valentini wrote:
> =
> #fedora-meeting-1: FESCo (2020-02-03)
> =
> 
> 
> Meeting started by decathorpe at 15:06:32 UTC. The full logs are
> available at
> https://meetbot.fedoraproject.org/fedora-meeting-1/2020-02-03/fesco.2020-02-03-15.06.log.html
> .
> 
> 
> 
> Meeting summary
> ---
> * Init Process  (sgallagh, 15:07:23)
> 
> * #2320 F32 System-Wide Change: Enable EarlyOOM  (decathorpe, 15:09:19)
>   * FESCo acknowledges the Workstation WG's decision and does not want
> to overrule  (decathorpe, 15:13:33)
> 
> * #2323  F32 System-Wide Change: Reduce installation media size by
>   improving the compression ratio of SquashFS filesystem  (decathorpe,
>   15:13:54)
>   * AGREED: REJECTED (+0, 1, -5) proposal in its current form
> (sgallagh, 15:37:29)

See the thread started by David Cantrell ("Change proposal discussion - 
Optimize SquashFS Size")
for further discussion.

Zbyszek
___
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

[rpms/perl-DBD-MySQL] PR #1: Use make_build macro

[Jitka Plesnikova]

jplesnik commented on the pull-request: `Use make_build macro` that you are 
following:
``
I can't merge it due to mass rebuild commit. I updated your changes with using 
%make_install and NO_PERLLOCAL.
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-DBD-MySQL/pull-request/1
___
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

[rpms/perl-DBD-MySQL] PR #1: Use make_build macro

[Jitka Plesnikova]

jplesnik closed without merging a pull-request against the project: 
`perl-DBD-MySQL` that you
are following.

Closed pull-request:

``
Use make_build macro
``

https://src.fedoraproject.org/rpms/perl-DBD-MySQL/pull-request/1
___
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 1797720] perl-DBD-Pg-3.10.4 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Doc Type|--- |If docs needed, set a value



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

[rpms/perl-Compress-Bzip2] PR #1: Use make_build macro

[Jitka Plesnikova]

jplesnik merged a pull-request against the project: `perl-Compress-Bzip2` that 
you are following.

Merged pull-request:

``
Use make_build macro
``

https://src.fedoraproject.org/rpms/perl-Compress-Bzip2/pull-request/1
___
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