thunderbird-enigmail: how to claim ownership for F31 if package is retired in rawhide?

[Felix Schwarz]

Hey,

thunderbird-enigmail was retired in rawhide after being orphaned for more than
6 weeks. However F30+F31 still have the RPM but it does not work at all due to
Thunderbird changes.

I'm not interested in taking over the master branch but I'd like to ensure
that F31 ships working software. Which procedure should I follow to claim
ownership on the F31 branch?

(Obviously I'm not too keen on applying the whole un-retirement process which
involves a potentially very long package review.)

Felix
___
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: Fedora 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance

[Jan Kratochvil]

On Thu, 07 Nov 2019 22:36:44 +0100, Jan Kratochvil wrote:
> On Thu, 07 Nov 2019 15:59:41 +0100, Victor Stinner wrote:
> > I cannot explain why inlining cannot be done more often in libpython.
> > 
> > I cannot explain why PLT is needed when a libpython function calls a 
> > libpython function.
> 
> Could you re-run the benchmark with shared library but with
> -fno-semantic-interposition? I have run it locally but it takes a lot of time.

nbody python3-3.7.5-1.fc30.x86_64: Mean +- std dev: 217 ms +- 2 ms
nbody -fno-semantic-interposition: Mean +- std dev: 203 ms +- 3 ms - 6.9%
nbody static linkage claim:-27%

So -fno-semantic-interposition does help but it is not the whole static gain.


Jan
___
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 1769359] [RFE] EPEL8 branch of perl-B-Compiling

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|andrea.v...@gmail.com   |jples...@redhat.com



--- Comment #1 from Jitka Plesnikova  ---
https://pagure.io/releng/fedora-scm-requests/issue/19495
https://pagure.io/releng/fedora-scm-requests/issue/19496

-- 
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 1769996] [RFE] EPEL8 branch of perl-Log-Dispatch-Array

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED



--- Comment #1 from Jitka Plesnikova  ---
https://pagure.io/releng/fedora-scm-requests/issue/19491
https://pagure.io/releng/fedora-scm-requests/issue/19492

-- 
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 1769995] [RFE] EPEL8 branch of perl-Devel-StackTrace-WithLexicals

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED



--- Comment #1 from Jitka Plesnikova  ---
https://pagure.io/releng/fedora-scm-requests/issue/19493
https://pagure.io/releng/fedora-scm-requests/issue/19494

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

[389-devel] 389 DS nightly 2019-11-08 - 96% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2019/11/08/report-389-ds-base-1.4.2.3-20191108git6dcf406.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 1769280] [RFE] EPEL8 branch of perl-CLASS

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #1 from Fedora Update System  ---
FEDORA-EPEL-2019-94e44db817 has been submitted as an update to Fedora EPEL 8.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-94e44db817

-- 
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: Modularity: The Official Complaint Thread

[Orion Poplawski]

On 11/5/19 1:17 PM, Stephen Gallagher wrote:
> I'd like to gather a constructive list of the actual use-cases that
> you feel Modularity is causing problems for, with the following
> stipulations: Any *subjective* problems will be ignored. "I think
> writing YAML is harder than writing a spec file" is an example of a
> subjective opinion. Similarly, "change inevitably results in some
> learning curve" is a basic maxim of innovation and is not in and of
> itself an argument not to change. "Modularity requires me to write
> both a spec file and a YAML file, thereby increasing the total work"
> is an *objective* observation (and a valid one; I'm going to include
> it below in my own starter list). If you aren't sure if it's
> objective, a useful question is "is it quantitatively measurable?"
> (AKA "Can I assign a number to it and see that number increase or
> decrease when changing something about the implementation?")

I find the global exclusion of packages built but not shipped in an enabled
module baffling and makes it very hard to provide updates/alternatives to
those packages.  For example:

- I installed a RHEL8.0 system and my kickstart requested "koan" to be 
installed.

- koan is provided by the rhn-tools module, and so that got enabled

- rhn-tools builds a very old version of koan that comes from the cobbler
package.  But it doesn't ship cobbler (or cobbler-web).

- As a cobbler packager I want to test out the latest version of cobbler built
from my COPR - so I enable that and run:

# dnf install cobbler
Copr repo for cobbler owned by orion 695  B/s | 1.9 kB 00:02
No match for argument: cobbler
Error: Unable to find a match

WAT?

dnf -v is no help, neither is --debugsolver as near as I can tell.

Beyond the horrible UX above, this seems so counter to the idea that we are
building a platform upon which others can build and extend.  In this case I
can simply disable the rhn-tools module, but what if I wanted something else
from that module?

Hopefully the UX is better in Fedora (I haven't tested), but I believe the
exclusion property remains.

This is also creating challenges for CentOS to re-add missing -devel packages
(https://lists.centos.org/pipermail/centos-devel/2019-November/018082.html)
though I hear whispers of a fix in the works so I am hopeful...

-- 
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/




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

[389-devel] Re: Check for anonymous bind in conn / pb_op

[William Brown]

> On 7 Nov 2019, at 19:40, Ludwig Krispenz  wrote:
> 
> 
> On 11/07/2019 04:45 AM, William Brown wrote:
>> What's the correct way to check if the connection is bound as anonymous with 
>> the pb_op or connection struct? It's not obviously jumping out at me, and my 
>> grep skills have failed me?
> do what aclanom_is_client_anonymus () does, check SLAPI_REQUESTOR_DN

Thanks Ludwig, that's a great idea. :) 

>> 
>> 
>> 
>> --
>> Sincerely,
>> 
>> William
>> ___
>> 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/, Registered seat: Grasbrunn,
> Commercial register: Amtsgericht Muenchen, HRB 153243,
> Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, 
> Eric Shander
> ___
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

—
Sincerely,

William Brown

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

Re: Modularity: The Official Complaint Thread

[Miro Hrončok]

On 07. 11. 19 22:03, Stephen Gallagher wrote:
I am currently working up a report on what exactly that will entail. I hope to 
have it ready to share tomorrow.


Note that I have promised to share some draft about what would be needed if we 
decide to got this way, but I'm certainly not able to do it before tomorrow. 
Looking forward to what what yoi will share and I can add some of my thoughts, 
if not already there.


Thank You very much Stephen for taking this proposal seriously!

--
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: Fedora 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance

[Kevin Kofler]

Chris Adams wrote:
> Alternately, is there some way to reduce the overhead of the dynamic
> library (that could help multiple languages)?

-fno-semantic-interposition

Can this please be tried on the dynamically linked Python?

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: Fedora 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance

[Florian Weimer]

* Vít Ondruch:

> Dne 07. 11. 19 v 16:05 Tom Hughes napsal(a):
>> On 07/11/2019 14:59, Victor Stinner wrote:
>>
>>> I cannot explain why PLT is needed when a libpython function calls a
>>> libpython function.
>>
>> Because an exported symbol in an ELF shared library is subject to
>> potential interposition using LD_PRELOAD so the calls need to go
>> through the PLT to be resolved.
>
>
> Not sure what PLT is (pre load table?), but is it something what could
> be disabled?

Procedure Linkage Table.

It can be disabled by using hidden symbols.  For internal symbols, that
is easy.  For symbols that are used externally, I do not think we have
good toolchain support.  Link-time optimization can detect truly
internal symbols and make them hidden.  Some targets can also perform
relaxation of relocations, eliminating most of the PLT indirection
overhead if it turns out a function is not exported after all and
therefore cannot be interposed.  But that needs a version script, and it
can't work for calls to functions that are in fact public.

In glibc, we create hidden aliases for public functions which should not
be interposed.  It's not too bad if you have preprocessor macros for
this task, but you do need to annotate each function declaration and
definition separately.

> This sounds like the whole system could be 25% faster if we link
> statically.

Not reallly, quite a few system components already do this kind of
optimization.

Toolchain support for this is quite poor however.  Ideally, we would
have a compilation mode that reuses the annotations that Windows uses,
but given that our system headers currently lack __dllimport specifiers
(or whatever they are called), even with that approach, it's quite a lot
of work.  I might be mistaken about this, but I think there was a huge
conflict about some intermediate visibility setting (protected?) that
might help with this, basically creating non-interposable function
symbols, but I don't think it's usable for that in its current state.

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

Re: Fedora 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance

[Jan Kratochvil]

On Thu, 07 Nov 2019 15:59:41 +0100, Victor Stinner wrote:
> I cannot explain why inlining cannot be done more often in libpython.
> 
> I cannot explain why PLT is needed when a libpython function calls a 
> libpython function.

Could you re-run the benchmark with shared library but with
-fno-semantic-interposition? I have run it locally but it takes a lot of time.


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

[389-devel] please review: PR - 50697 - Fix various UI bugs

[Mark Reynolds]

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

--

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

Re: EPEL-8 builds

[Denis Arnaud]

Date: Thu, 7 Nov 2019 11:23:11 -0500
> Message-ID:
>  sjrbn+...@mail.gmail.com>
>
> On Thu, 7 Nov 2019 at 05:13, Peter Robinson  wrote:
> > I'd like to know why people are pushing EPEL-8 builds without engaging
> > with the maintainers of the packages. I've had a few packages where
> > I'm the only maintainer and I've explicitly not built them for EPEL-8
> > for reasons yet people are now coming without any engagement what so
> > ever and building them where they won't have to support the packages
> > no understand why the maintainer hasn't built them in the first place.
> >
>

I may be one of those people, as I recently needed Xapian bindings for EPEL
8 for a few of my own packages. It may have been my mistake, but my
assumption so far was that if I were to ask for the creation of the EPEL 8
branch for any given package, I would automatically become a
(co-)maintainer for that branch. So, of course, in my head, but I thought
it was the case more formally too, I have become a (co-)maintainer of
Xapian at least on EPEL 8. And if you need some help for other branches,
count me in.

Sorry for the miscommunication, if any. I naively thought that the
interactions on Pagure and Bugzilla (where those EPEL 8 branches were
requested in the first place: any change on those Bugzilla records trigger
emails to all the stakeholders; so, nothing has been hidden here) were
explicit enough, and didn't want to bother you by duplicating those
messages.

And if, for any reason of your own, you do not wish my continuing to be a
co-maintainer of Xapian on at least EPEL 8, then be it; we will have to
find a solution or I'll have to orphan my own packages on EPEL 8 altogether.

Kind regards

Denis
___
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 1769955] [RFE] EPEL8 branch of perl-DateTime-TimeZone

[bugzilla]

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



--- Comment #2 from Emmanuel Seyman  ---
Sorry about that, it's been a long day.

-- 
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 1769996] New: [RFE] EPEL8 branch of perl-Log-Dispatch-Array

[bugzilla]

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

Bug ID: 1769996
   Summary: [RFE] EPEL8 branch of perl-Log-Dispatch-Array
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Log-Dispatch-Array
  Assignee: jples...@redhat.com
  Reporter: emman...@seyman.fr
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jose.p.oliveira@gmail.com,
jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



It would be helpful if this module was packaged for EPEL8 (needed for
perl-Plack).

-- 
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 1769995] New: [RFE] EPEL8 branch of perl-Devel-StackTrace-WithLexicals

[bugzilla]

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

Bug ID: 1769995
   Summary: [RFE] EPEL8 branch of
perl-Devel-StackTrace-WithLexicals
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Devel-StackTrace-WithLexicals
  Assignee: jples...@redhat.com
  Reporter: emman...@seyman.fr
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



It would be helpful if this module was packaged for EPEL8 (needed for
perl-Plack).

-- 
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: Modularity: The Official Complaint Thread

[Stephen Gallagher]

On Thu, Nov 7, 2019 at 3:54 PM Kevin Kofler  wrote:

> Christopher Engelhard wrote:
> > Personally, I like a solution along the lines of what e.g. Kevin Kofler
> > suggested earlier, that is
> >
> > 1) every package has a default version
> > 2) any default version can only depend on default versions
> > 3) the package manager distinguishes between 'install default, which
> > happens to be version X' and 'install version X, which happens to be
> > default', with automatic upgrade of 'X -> X' and 'default -> default'
> > being OK and 'X -> default' or 'default -> X' requiring user intervention
> > 4) where (2) cannot be achieved, we use compat packages as before
> >
> > though I freely admit that I absolutely cannot judge how difficult that
> > is to actually implement.
>
> The easiest way to implement this is actually to simply make the default
> versions non-modular again and ship only alternate versions as modules
> (i.e., Miro's proposal).



I am currently working up a report on what exactly that will entail. I hope
to have it ready to share tomorrow.



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

Re: Modularity: The Official Complaint Thread

[Kevin Kofler]

Christopher Engelhard wrote:
> Personally, I like a solution along the lines of what e.g. Kevin Kofler
> suggested earlier, that is
> 
> 1) every package has a default version
> 2) any default version can only depend on default versions
> 3) the package manager distinguishes between 'install default, which
> happens to be version X' and 'install version X, which happens to be
> default', with automatic upgrade of 'X -> X' and 'default -> default'
> being OK and 'X -> default' or 'default -> X' requiring user intervention
> 4) where (2) cannot be achieved, we use compat packages as before
> 
> though I freely admit that I absolutely cannot judge how difficult that
> is to actually implement.

The easiest way to implement this is actually to simply make the default 
versions non-modular again and ship only alternate versions as modules 
(i.e., Miro's proposal).

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: Something wrong with kernel-headers on fedora 30?

[James Cassell]

On Thu, Nov 7, 2019, at 3:46 PM, James Cassell wrote:
> 
> On Thu, Nov 7, 2019, at 2:50 PM, Laura Abbott wrote:
> > On 11/7/19 1:31 PM, James Cassell wrote:
> > > 
> > > On Thu, Nov 7, 2019, at 1:23 PM, Joseph D. Wagner wrote:
> > >> I am on kernel 5.3.8 but I still have
> > >> kernel-headers-5.3.6-200.fc30.x86_64, which hasn't updated.
> > >>
> > >> Is there a reason a new kernel-headers package hasn't been generated for
> > >> the newer versions?  Has it be superseded by another package? If so,
> > >> then dependencies on glibc-headers need to be fixed.
> > >>
> > > 
> > > I've also been confused why kernel-headers is a separate SRPM...
> > > 
> > 
> > The short answer is that kernel-headers doesn't need to be rebuilt
> > each time.
> > 
> > The longer answer is that we split it out to solve an issue
> > where kernel-headers were being built unnecessarily and triggering
> > rebuilds when they shouldn't. That problem is now being solved
> > another way but it's also useful to be able to build kernel-headers
> > independently so that if we don't want to build a kernel but do
> > want the headers we can easily do so.
> > 
> > kernel-headers is related to the userspace API and is not tied
> > to a particular kernel version. If the userspace API doesn't
> > change there's no need to rebuild. Is there a problem you're
> > seeing by not having an updated kernel-headers?
> > 
> 
> I compile my own patched kernel with a higher EVR than the packaged 
> kernel, but the kernel-headers package seems to pull in the kernel of 
> the same version despite my having a later one installed.
> 

I should clarify that I'm doing a `fedpkg mockbuild` so the packaging should be 
identical to the shipped kernel.

> Thanks for taking a look and explaining!
> 
> 
> 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

[Bug 1769956] [RFE] EPEL8 branch of perl-Math-Random-ISAAC

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #2 from Fedora Update System  ---
FEDORA-EPEL-2019-9b66b750c5 has been submitted as an update to Fedora EPEL 8.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-9b66b750c5

-- 
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: Something wrong with kernel-headers on fedora 30?

[James Cassell]

On Thu, Nov 7, 2019, at 2:50 PM, Laura Abbott wrote:
> On 11/7/19 1:31 PM, James Cassell wrote:
> > 
> > On Thu, Nov 7, 2019, at 1:23 PM, Joseph D. Wagner wrote:
> >> I am on kernel 5.3.8 but I still have
> >> kernel-headers-5.3.6-200.fc30.x86_64, which hasn't updated.
> >>
> >> Is there a reason a new kernel-headers package hasn't been generated for
> >> the newer versions?  Has it be superseded by another package? If so,
> >> then dependencies on glibc-headers need to be fixed.
> >>
> > 
> > I've also been confused why kernel-headers is a separate SRPM...
> > 
> 
> The short answer is that kernel-headers doesn't need to be rebuilt
> each time.
> 
> The longer answer is that we split it out to solve an issue
> where kernel-headers were being built unnecessarily and triggering
> rebuilds when they shouldn't. That problem is now being solved
> another way but it's also useful to be able to build kernel-headers
> independently so that if we don't want to build a kernel but do
> want the headers we can easily do so.
> 
> kernel-headers is related to the userspace API and is not tied
> to a particular kernel version. If the userspace API doesn't
> change there's no need to rebuild. Is there a problem you're
> seeing by not having an updated kernel-headers?
> 

I compile my own patched kernel with a higher EVR than the packaged kernel, but 
the kernel-headers package seems to pull in the kernel of the same version 
despite my having a later one installed.

Thanks for taking a look and explaining!


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

[Bug 1763637] EPEL8 builds

[bugzilla]

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



--- Comment #1 from Paul Howarth  ---
Steve, I'm happy to do this if you're busy or uninterested.

-- 
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 1769974] New: [RFE] EPEL8 branch of perl-Hash-MultiValue

[bugzilla]

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

Bug ID: 1769974
   Summary: [RFE] EPEL8 branch of perl-Hash-MultiValue
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Hash-MultiValue
  Assignee: robinlee.s...@gmail.com
  Reporter: emman...@seyman.fr
QA Contact: extras...@fedoraproject.org
CC: jose.p.oliveira@gmail.com,
perl-devel@lists.fedoraproject.org,
robinlee.s...@gmail.com
  Target Milestone: ---
Classification: Fedora



It would be helpful if this module was packaged for EPEL8 (it is needed for
perl-Plack).

I will be happy to maintain this branch, if need be.

-- 
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: Encrypted DNS in Fedora

[Nicolas Mailhot via devel]

Le jeudi 07 novembre 2019 à 18:32 +0100, Sheogorath via devel a écrit :
> 
> The talk is right on many points, but I think it dismisses the most
> essential point DoH does right: DNS is a decision of the device
> owner.

And the owner should be able to delegate this decision to the network
manager.

Suggesting static config is good enough outside the enterprise is a
joke. Count the number of networked things in the modern home, it grows
every years. A lot of those roam, either because they are designed to
roam (smartphones) or because people vacation, because they like to
share their stuff with friends and families, because they like to show
of. A lot of those are cheap-ass gadgets that will revert (reset) to
factory settings at the slightest problem (sometimes, just because the
battery is dead, the juice was cut, and settings are kept in memory).

Ansible or puppet are not designed to solve such generic situations.

Network management is no longer an enterprise-only concern.

Treating it as a sysadmin problem does not work.

The network happened. And not only internet side.

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

Re: Encrypted DNS in Fedora

[Michael Catanzaro]

On Thu, Nov 7, 2019 at 12:20 pm, David Sommerseth  
wrote:
Please just watch the talk by Paul Vixie (who is one of the really 
big DNS
gurus these days, even ISC BIND maintainer for quite some years).  
And you

will see that DoH is pointless when you have DoT.


Looks like we're headed towards a DNS war. This should be interesting.

___
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: Something wrong with kernel-headers on fedora 30?

[stan via devel]

On Thu, 07 Nov 2019 13:31:23 -0500
"James Cassell"  wrote:

> On Thu, Nov 7, 2019, at 1:23 PM, Joseph D. Wagner wrote:
> > I am on kernel 5.3.8 but I still have 
> > kernel-headers-5.3.6-200.fc30.x86_64, which hasn't updated.
> > 
> > Is there a reason a new kernel-headers package hasn't been
> > generated for the newer versions?  Has it be superseded by another
> > package? If so, then dependencies on glibc-headers need to be fixed.
> >   
> 
> I've also been confused why kernel-headers is a separate SRPM...

I have nothing to do with this change, but it has been in place for at
least 6 months, and maybe almost a year.  If the kernel api doesn't
change with a new version, there is no need to create new header files.
I assume it was done to cut down on compile time, spec file complexity,
and installation size and time (resource churn).

Maybe someone else can clarify more authoritatively.
___
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: Something wrong with kernel-headers on fedora 30?

[Laura Abbott]

On 11/7/19 1:31 PM, James Cassell wrote:


On Thu, Nov 7, 2019, at 1:23 PM, Joseph D. Wagner wrote:

I am on kernel 5.3.8 but I still have
kernel-headers-5.3.6-200.fc30.x86_64, which hasn't updated.

Is there a reason a new kernel-headers package hasn't been generated for
the newer versions?  Has it be superseded by another package? If so,
then dependencies on glibc-headers need to be fixed.



I've also been confused why kernel-headers is a separate SRPM...



The short answer is that kernel-headers doesn't need to be rebuilt
each time.

The longer answer is that we split it out to solve an issue
where kernel-headers were being built unnecessarily and triggering
rebuilds when they shouldn't. That problem is now being solved
another way but it's also useful to be able to build kernel-headers
independently so that if we don't want to build a kernel but do
want the headers we can easily do so.

kernel-headers is related to the userspace API and is not tied
to a particular kernel version. If the userspace API doesn't
change there's no need to rebuild. Is there a problem you're
seeing by not having an updated kernel-headers?

Thanks,
Laura
___
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: Add a rule to have a compose when Fedora branched

[Miro Hrončok]

On 07. 11. 19 18:35, Ben Cotton wrote:

Here's the link to the Community Blog post that looks at the schedule options:
https://communityblog.fedoraproject.org/accommodating-flock-in-the-release-schedule/


From the post:

I’m inclined to go with option 0, plus a brief freeze after branch.


This seems like  best option to me as well.

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

[Bug 1744684] [RFE] EPEL8 branch of perl-Mojolicious

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #2 from Fedora Update System  ---
FEDORA-EPEL-2019-c299272a2f has been submitted as an update to Fedora EPEL 8.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c299272a2f

-- 
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 1769955] [RFE] EPEL8 branch of perl-DateTime-TimeZone

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 CC||p...@city-fan.org
 Resolution|--- |NOTABUG
Last Closed||2019-11-07 19:41:09



--- Comment #1 from Paul Howarth  ---
perl-DateTime-TimeZone-2.19-1.el8 is in CRB / PowerTools.

-- 
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 1762900] Bugzilla for EL8

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1762900
Bug 1762900 depends on bug 1769955, which changed state.

Bug 1769955 Summary: [RFE] EPEL8 branch of perl-DateTime-TimeZone
https://bugzilla.redhat.com/show_bug.cgi?id=1769955

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |NOTABUG



-- 
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: Jenkins plugin upgrade to change from fedmsg to fedora-messaging

[Jim Bair]

Hello Fedora teams!

We performed the upgrade this morning, however we ran into a few issues and
we rolled back to the previous configuration.

We will try again next week and when we have that firmed up, I'll send
another email to the groups at large.

Thanks,

-Jim


On Tue, Nov 5, 2019 at 10:50 AM Jim Bair  wrote:

> Hello Fedora CI and Devel Teams!
>
> The CI team will be performing a Jenkins plugin upgrade this Thursday to
> allow us to switch from fedmsg to fedora-messaging. While performing this
> upgrade, dist-git tests will be temporarily unavailable. When the upgrade
> is complete and things appear good, we will reply-all here.
>
> Please note that this is simply an upgrade to the plugin itself; while it
> allows the use of the fedora-messaging bus, we will continue to use fedmsg
> after the upgrade to validate plugin stability. If all goes well, our plan
> is to switch to fedora-messaging next week (tentatively on Wednesday the
> 13th).
>
> If you have any questions or concerns, by all means please reach out to me.
>
> Thank you!
>
> -Jim Bair
>
___
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 1762900] Bugzilla for EL8

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1762900
Bug 1762900 depends on bug 1769953, which changed state.

Bug 1769953 Summary: [RFE] EPEL8 branch of perl-DateTime
https://bugzilla.redhat.com/show_bug.cgi?id=1769953

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |NOTABUG



-- 
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 1769953] [RFE] EPEL8 branch of perl-DateTime

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |NOTABUG
Last Closed||2019-11-07 19:38:20



--- Comment #1 from Paul Howarth  ---
perl-DateTime-1.50-1.el8 is in CRB / PowerTools.

-- 
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 1769956] [RFE] EPEL8 branch of perl-Math-Random-ISAAC

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED



--- Comment #1 from Emmanuel Seyman  ---
https://pagure.io/releng/fedora-scm-requests/issue/19483
https://pagure.io/releng/fedora-scm-requests/issue/19484

-- 
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 1762900] Bugzilla for EL8

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Depends On||1769953, 1769955, 1761852,
   ||1769956




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1761852
[Bug 1761852] perl-Email-Sender for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1769953
[Bug 1769953] [RFE] EPEL8 branch of perl-DateTime
https://bugzilla.redhat.com/show_bug.cgi?id=1769955
[Bug 1769955] [RFE] EPEL8 branch of perl-DateTime-TimeZone
https://bugzilla.redhat.com/show_bug.cgi?id=1769956
[Bug 1769956] [RFE] EPEL8 branch of perl-Math-Random-ISAAC
-- 
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 1769955] [RFE] EPEL8 branch of perl-DateTime-TimeZone

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Blocks||1762900




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1762900
[Bug 1762900] Bugzilla for EL8
-- 
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 1769956] [RFE] EPEL8 branch of perl-Math-Random-ISAAC

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Blocks||1762900




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1762900
[Bug 1762900] Bugzilla for EL8
-- 
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 1769953] [RFE] EPEL8 branch of perl-DateTime

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Blocks||1762900




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1762900
[Bug 1762900] Bugzilla for EL8
-- 
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 1761852] perl-Email-Sender for EL8

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Blocks||1762900




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1762900
[Bug 1762900] Bugzilla for EL8
-- 
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 1769956] New: [RFE] EPEL8 branch of perl-Math-Random-ISAAC

[bugzilla]

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

Bug ID: 1769956
   Summary: [RFE] EPEL8 branch of perl-Math-Random-ISAAC
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Math-Random-ISAAC
  Assignee: emman...@seyman.fr
  Reporter: emman...@seyman.fr
QA Contact: extras...@fedoraproject.org
CC: dd...@cpan.org, emman...@seyman.fr,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



This is needed for Bugzilla.

-- 
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 1769955] New: [RFE] EPEL8 branch of perl-DateTime-TimeZone

[bugzilla]

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

Bug ID: 1769955
   Summary: [RFE] EPEL8 branch of perl-DateTime-TimeZone
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-DateTime-TimeZone
  Assignee: jples...@redhat.com
  Reporter: emman...@seyman.fr
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Can we get a build for EPEL8? I need it for Bugzilla.

-- 
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 1769953] New: [RFE] EPEL8 branch of perl-DateTime

[bugzilla]

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

Bug ID: 1769953
   Summary: [RFE] EPEL8 branch of perl-DateTime
   Product: Fedora EPEL
   Version: epel8
Status: NEW
 Component: perl-DateTime
  Assignee: trem...@tremble.org.uk
  Reporter: emman...@seyman.fr
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, p...@city-fan.org,
perl-devel@lists.fedoraproject.org, st...@silug.org,
trem...@tremble.org.uk
  Target Milestone: ---
Classification: Fedora



Can we get a build for EPEL8? I need it for Bugzilla.

-- 
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: Something wrong with kernel-headers on fedora 30?

[James Cassell]

On Thu, Nov 7, 2019, at 1:23 PM, Joseph D. Wagner wrote:
> I am on kernel 5.3.8 but I still have 
> kernel-headers-5.3.6-200.fc30.x86_64, which hasn't updated.
> 
> Is there a reason a new kernel-headers package hasn't been generated for 
> the newer versions?  Has it be superseded by another package? If so, 
> then dependencies on glibc-headers need to be fixed.
> 

I've also been confused why kernel-headers is a separate SRPM...

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

Re: List of Python 2 packages to be removed mid-November (= in a week)

[Ralf Corsepius]

On 11/7/19 2:34 PM, Miro Hrončok wrote:

On 07. 11. 19 13:59, Felix Schwarz wrote:


Am 07.11.19 um 13:01 schrieb Petr Viktorin:

If this took you by surprise, don't panic. It's possible to change the
default. Let us know and we'll work things out.


Somehow I feel like I don't understand the report – or we are 
approaching an
(almost) unmitigated disaster here: There are so many "high profile" 
packages

which are slated for removal that we might wipe out half of our Python
packaging eco system.


What are the high profile packages you are talking about?


Fedora - Combined wiht the modules insanity, you guys seem to be keen on 
shifting Fedora into non-usability and into non-importance.


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

Something wrong with kernel-headers on fedora 30?

[Joseph D. Wagner]

I am on kernel 5.3.8 but I still have 
kernel-headers-5.3.6-200.fc30.x86_64, which hasn't updated.


Is there a reason a new kernel-headers package hasn't been generated for 
the newer versions?  Has it be superseded by another package? If so, 
then dependencies on glibc-headers need to be fixed.


Joseph D. Wagner
___
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: EPEL-8 builds

[Miro Hrončok]

On 07. 11. 19 18:28, Kevin Fenzi wrote:

On Thu, Nov 07, 2019 at 04:48:41PM +, Peter Robinson wrote:

On Thu, Nov 7, 2019 at 4:36 PM Miroslav Suchý  wrote:


Dne 07. 11. 19 v 11:12 Peter Robinson napsal(a):

I'd like to know why people are pushing EPEL-8 builds without engaging
with the maintainers of the packages.


Because they can?
Nothing in guidelines say: "you have to contact maintainer of different branch when 
you request new one".


If there's specific reasons that a maintainer wouldn't want it in el8
surely the right thing to do would be to engage so they could at least
offer to co-maintain it for el8. I feel it's wrong to assume that
someone is able to take on the load of maintaining the package for the
lifetime of el8 without engagement. If the person doesn't have the
time or interest it just ends up with something that will bitrot and
give everyone a bad experience.

I feel the guidelines should include those requirements or something
similar else it's just hostile to expect that someone takes up that
extra load whether they want to or not!.


Yeah, the epel guidelines do, but I don't think there's any enforcement.
:(

Long back in the pkgdb days the way it worked is that you request a
branch and if you are maintainer/comaintainer you can just have it, if
you are not you had to wait at least a week for the maintainers to
ack/nack the request. Sadly, I don't think there was any notification of
these, so people would just request and wait a week and get the branch.

Perhaps we can add a check to the new branch request thing that
hopefully will land soon. Pingou? I'd even be ok with just requiring you
be a maintainer to request the branch.



https://pagure.io/releng/issue/8844

--
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: EPEL-8 builds

[Stephen John Smoogen]

On Thu, 7 Nov 2019 at 12:29, Kevin Fenzi  wrote:
>
> On Thu, Nov 07, 2019 at 04:48:41PM +, Peter Robinson wrote:
> > On Thu, Nov 7, 2019 at 4:36 PM Miroslav Suchý  wrote:
> > >
> > > Dne 07. 11. 19 v 11:12 Peter Robinson napsal(a):
> > > > I'd like to know why people are pushing EPEL-8 builds without engaging
> > > > with the maintainers of the packages.
> > >
> > > Because they can?
> > > Nothing in guidelines say: "you have to contact maintainer of different 
> > > branch when you request new one".
> >
> > If there's specific reasons that a maintainer wouldn't want it in el8
> > surely the right thing to do would be to engage so they could at least
> > offer to co-maintain it for el8. I feel it's wrong to assume that
> > someone is able to take on the load of maintaining the package for the
> > lifetime of el8 without engagement. If the person doesn't have the
> > time or interest it just ends up with something that will bitrot and
> > give everyone a bad experience.
> >
> > I feel the guidelines should include those requirements or something
> > similar else it's just hostile to expect that someone takes up that
> > extra load whether they want to or not!.
>
> Yeah, the epel guidelines do, but I don't think there's any enforcement.
> :(
>
> Long back in the pkgdb days the way it worked is that you request a
> branch and if you are maintainer/comaintainer you can just have it, if
> you are not you had to wait at least a week for the maintainers to
> ack/nack the request. Sadly, I don't think there was any notification of
> these, so people would just request and wait a week and get the branch.
>
> Perhaps we can add a check to the new branch request thing that
> hopefully will land soon. Pingou? I'd even be ok with just requiring you
> be a maintainer to request the branch.
>
> It's completely not right to sign someone else up for a bunch of work
> without their consent.
>
>

I agree 100% on that. If it turns out that it was something I did, I
need to be made comaintainer on those packages and deal with it.


-- 
Stephen J Smoogen.
___
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: Add a rule to have a compose when Fedora branched

[Ben Cotton]

Here's the link to the Community Blog post that looks at the schedule options:
https://communityblog.fedoraproject.org/accommodating-flock-in-the-release-schedule/

I have disabled comments on that post so that we can keep the
conversation on this thread.


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
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: Encrypted DNS in Fedora

[Sheogorath via devel]

On Thu, 2019-11-07 at 07:47 -0700, stan via devel wrote:
> On Thu, 7 Nov 2019 12:20:50 +0100
> David Sommerseth  wrote:
>  
> > Please just watch the talk by Paul Vixie (who is one of the really
> > big DNS gurus these days, even ISC BIND maintainer for quite some
> > years).  And you will see that DoH is pointless when you have DoT.
> > But DoT can also go much further than DoH will, when you consider
> > the
> > bigger part of the DNS query chain.
> 
> Thank you for pointing to that talk.  I found it very informative, as
> a
> mostly ignorant user of DNS.  I run knot-resolver as a local caching
> DNS
> server, pulling from, ironically, 1.1.1.1 via the router, and
> bypassing
> my ISP's DNS servers.  Really opened my eyes.
> 

The talk is right on many points, but I think it dismisses the most
essential point DoH does right: DNS is a decision of the device owner.

When you are the real owner of the device, you can configure the device
to use whatever DoH server you want. This includes company DoH servers.

We have to stop to make security products that rely on the same
mechanisms as an attacker would use.

For corporate environments use Puppet, Ansible, GPOs, MDM, whatever
your company device management you have to use at scale anyway, to
configure your preferred DoH server, which then can apply all the
measures he is talking about to protect things.

For private setups: Take the 10 minutes it takes to configure devices
properly instead of relying on easy to break network attacker-based
solutions.

And when you give a device to your kids, then it will probably just
take them one internet search to learn how to use the /etc/hosts file
in order to access evilpage.com.

I agree that DoH and DoT doesn't bring so much more privacy, but it
provides integrity to DNS that unencrypted DNS even with DNSSec is
lagging as an attack can always opt to not answer for a specific domain
name.

And whenever or not applications of the system should implement it, is
probably decided by how fast the system side will decide to deploy
encrypted DNS effectively.

-- 
Signed
Sheogorath

OpenPGP: https://shivering-isles.com/openpgp/0xFCB98C2A3EC6F601.txt


signature.asc
Description: This is a digitally signed message part
___
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: EPEL-8 builds

[Kevin Fenzi]

On Thu, Nov 07, 2019 at 04:48:41PM +, Peter Robinson wrote:
> On Thu, Nov 7, 2019 at 4:36 PM Miroslav Suchý  wrote:
> >
> > Dne 07. 11. 19 v 11:12 Peter Robinson napsal(a):
> > > I'd like to know why people are pushing EPEL-8 builds without engaging
> > > with the maintainers of the packages.
> >
> > Because they can?
> > Nothing in guidelines say: "you have to contact maintainer of different 
> > branch when you request new one".
> 
> If there's specific reasons that a maintainer wouldn't want it in el8
> surely the right thing to do would be to engage so they could at least
> offer to co-maintain it for el8. I feel it's wrong to assume that
> someone is able to take on the load of maintaining the package for the
> lifetime of el8 without engagement. If the person doesn't have the
> time or interest it just ends up with something that will bitrot and
> give everyone a bad experience.
> 
> I feel the guidelines should include those requirements or something
> similar else it's just hostile to expect that someone takes up that
> extra load whether they want to or not!.

Yeah, the epel guidelines do, but I don't think there's any enforcement.
:(

Long back in the pkgdb days the way it worked is that you request a
branch and if you are maintainer/comaintainer you can just have it, if
you are not you had to wait at least a week for the maintainers to
ack/nack the request. Sadly, I don't think there was any notification of
these, so people would just request and wait a week and get the branch. 

Perhaps we can add a check to the new branch request thing that
hopefully will land soon. Pingou? I'd even be ok with just requiring you
be a maintainer to request the branch.

It's completely not right to sign someone else up for a bunch of work
without their consent. 

kevin


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

Re: Encrypted DNS in Fedora

[Nicolas Mailhot via devel]

Le mercredi 06 novembre 2019 à 07:11 +0100, Tomasz Torcz a écrit :
> On Tue, Nov 05, 2019 at 10:00:17PM +0100, Nicolas Mailhot via devel
> wrote:
> > Le mardi 05 novembre 2019 à 19:45 +0100, Tomasz Torcz a écrit :
> > > 
> > >   I don't agree with centralisation.  You should run your own DoH
> > > endpoint,
> > > using Google's, Cloudflare's or Quad9's servers is a shortcut.
> > 
> > DoH has zero integration and manageability. “It’s not centralized”
> > (but
> > you have to set manually DoH settings in all apps *or* rely on a
> > centralized Google DoH whitelist) is an utter joke.
> 
>   Setting in all apps? Excuse me?  You run your stub DoH resolver
> on ::1 and put ::1 in resolv.conf. 

That won't be honored by DoH-enabled apps that refuse to honor system
resolution.

That won't be honoured by all the other things on your network, unless
you reparameter every and each one of them by hand (assuming they
support DoH, or allow setting a DNS resolver manually in the first
place)

That won't be honoured by the smartphone of your visitors, by their pet
smart collar, etc, unless you spend 15 minutes figuring how to
reconfigure them at the start of their visit, and reconfigure them back
at the end. Don't bother giving them your wifi code.

So, no smart tv, no internet radio, no smart toaster, no resolved
network path to your gaming console, no nothing for them. Back to the
dark ages where nothing worked by default, networks were an enterprise-
only thing, and ISPs felt entitled to charge multiples if you plugged
more than one computer at the end of their cable.

That's what your single-system “solution” actually means.

Using DoH today means, in practical terms, using Google-approved
resolvers, and names Google know of (bye bye private networks) because
that's the only common ground DoH apps agree on, and the only practical
way to synchronize DoH naming results with the rest of the network
world.

Distributing DoH settings has not been specified yet, and even if it
were (for example DHCP side) there is zero commitment by Google or any
of the other DoH supporters to honor it. So, *just* *like* *for*
*http2*, Google will only specify the parts of the protocol it is
interested in, go AWOL for the other parts, and block their
standardisation by refusing to implement them even if someone managed
the specification (Google owns enough of the Internet to veto anything
it does not like). And Chrome will have an enterprise mode that allows
everything it blocks for home/SOHO users, and good bye any free-
software-like level field for others.

That's why using DoH in any form is a terrible idea right now. It's not
finished in practical terms. Its proponents have both the ability, and
the record track, of not playing nice once the parts they want get
adopted.

And I didn't even get into technical DoT/DoH comparisons, or asked you
if your DoH endpoint was packaged into Fedora, in a solid enough form
to run in production without getting owned.

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

[Bug 1769913] New: perl-Object-Remote-0.004000-10.fc32 FTBFS: tests fail with Use of uninitialized value $_ in hash element at /builddir/build/BUILD/Object-Remote-0.004000/blib/lib/Object/Remote/FatNo

[bugzilla]

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

Bug ID: 1769913
   Summary: perl-Object-Remote-0.004000-10.fc32 FTBFS: tests fail
with Use of uninitialized value $_ in hash element at
/builddir/build/BUILD/Object-Remote-0.004000/blib/lib/
Object/Remote/FatNode.pm line 127
   Product: Fedora
   Version: rawhide
   URL: https://koschei.fedoraproject.org/package/perl-Object-
Remote
Status: NEW
 Component: perl-Object-Remote
  Assignee: jples...@redhat.com
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



perl-Object-Remote-0.004000-10.fc32 fails to build in Fedora 32 because tests
fail like this:

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
# No tests run!
#   Failed test 'No tests run for subtest "proxy kept"'
#   at t/await.t line 61.
Use of uninitialized value $_ in hash element at
/builddir/build/BUILD/Object-Remote-0.004000/blib/lib/Object/Remote/FatNode.pm
line 127.
Compilation failed in require at
/builddir/build/BUILD/Object-Remote-0.004000/blib/lib/Object/Remote/Role/Connector/PerlInterpreter.pm
line 209.
# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 255 just after 1.

A difference between passing and failing build root is at
.

-- 
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 1769902] perl-Log-Report-1.28-3.fc32 FTBFS: t/43exc-xml-libxml.t fails with libxml2-2.9.10

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
Link ID||CPAN 130934



-- 
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: EPEL-8 builds

[Peter Robinson]

On Thu, Nov 7, 2019 at 4:36 PM Miroslav Suchý  wrote:
>
> Dne 07. 11. 19 v 11:12 Peter Robinson napsal(a):
> > I'd like to know why people are pushing EPEL-8 builds without engaging
> > with the maintainers of the packages.
>
> Because they can?
> Nothing in guidelines say: "you have to contact maintainer of different 
> branch when you request new one".

If there's specific reasons that a maintainer wouldn't want it in el8
surely the right thing to do would be to engage so they could at least
offer to co-maintain it for el8. I feel it's wrong to assume that
someone is able to take on the load of maintaining the package for the
lifetime of el8 without engagement. If the person doesn't have the
time or interest it just ends up with something that will bitrot and
give everyone a bad experience.

I feel the guidelines should include those requirements or something
similar else it's just hostile to expect that someone takes up that
extra load whether they want to or not!.

> Of course, it is better if they ask you first. And of course, you can ask 
> those people directly too :)

Believe me I have asked them, I wanted to know though in a public
forum without naming and shaming.
___
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: EPEL-8 builds

[Miro Hrončok]

On 07. 11. 19 17:35, Miroslav Suchý wrote:

Dne 07. 11. 19 v 11:12 Peter Robinson napsal(a):

I'd like to know why people are pushing EPEL-8 builds without engaging
with the maintainers of the packages.


Because they can?
Nothing in guidelines say: "you have to contact maintainer of different branch 
when you request new one".


Either they are co-maintainers of the package and they don't have to ask.

Or they need provenpackager privileges to push and I'd suggest that that should 
require either asking or some kind of emergency.


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

[Bug 1769902] New: perl-Log-Report-1.28-3.fc32 FTBFS: t/43exc-xml-libxml.t fails with libxml2-2.9.10

[bugzilla]

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

Bug ID: 1769902
   Summary: perl-Log-Report-1.28-3.fc32 FTBFS:
t/43exc-xml-libxml.t fails with libxml2-2.9.10
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Log-Report
  Assignee: ppi...@redhat.com
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



perl-Log-Report-1.28-3.fc32 fails to build in Fedora 32 because a test fails:

t/43exc-xml-libxml.t .. 1/? 
#   Failed test 'error 1'
#   at t/43exc-xml-libxml.t line 31.
# Structures begin differing at:
#  $got->[1]{errno} = '13074'
# $expected->[1]{errno} = '13077'
# Looks like you failed 1 test of 4.
t/43exc-xml-libxml.t .. Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/4 subtests 

This is triggered by upgrading libxml2 from 2.9.9-7.fc32 to 2.9.10-1.fc32.

-- 
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: EPEL-8 builds

[Ben Rosser]

On Thu, Nov 7, 2019 at 11:36 AM Miroslav Suchý  wrote:
>
> Dne 07. 11. 19 v 11:12 Peter Robinson napsal(a):
> > I'd like to know why people are pushing EPEL-8 builds without engaging
> > with the maintainers of the packages.
>
> Because they can?
> Nothing in guidelines say: "you have to contact maintainer of different 
> branch when you request new one".
>
> Of course, it is better if they ask you first. And of course, you can ask 
> those people directly too :)

Well... there are actually EPEL guidelines that say you should contact
the maintainer first:

https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Getting_a_Fedora_package_in_EPEL
https://fedoraproject.org/wiki/Getting_a_Fedora_package_in_EPEL

Ben Rosser
___
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: Fedora 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance

[Chris Adams]

Once upon a time, Miro Hrončok  said:
> If we build things statically with libraries, it's a can full of worms.
> What needs to be said about this change that we don't staticaly link
> against different libraries, we just build CPython source into one
> "fat" executable instead of splitting it into a tiny wrapper and a
> "fat" libpython.

It might be useful to see how other interpreters that are built like
this perform; I know perl has used libperl.so for ages (maybe all the
perl5 time?).  Does it have the same performance impact, and if so,
can/should it be switched to /usr/bin/perl linking the core static?

Alternately, is there some way to reduce the overhead of the dynamic
library (that could help multiple languages)?
-- 
Chris Adams 
___
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: EPEL-8 builds

[Miroslav Suchý]

Dne 07. 11. 19 v 11:12 Peter Robinson napsal(a):

I'd like to know why people are pushing EPEL-8 builds without engaging
with the maintainers of the packages.


Because they can?
Nothing in guidelines say: "you have to contact maintainer of different branch when 
you request new one".

Of course, it is better if they ask you first. And of course, you can ask those 
people directly too :)

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

[Bug 1769870] perl-Image-Sane-4-1.fc32 FTBFS: t/81_scanimage-perl.t test fails with sane-backends-1.0.28

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
Link ID||CPAN 130933



-- 
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: List of Python 2 packages to be removed mid-November (= in a week)

[Kevin Fenzi]

On Thu, Nov 07, 2019 at 01:01:09PM +0100, Petr Viktorin wrote:
> Dear maintainers,
> here is an updated list of packages that (transitively, at build or run
> time) require Python 2 and have not yet got a FESCo exception to do so.
> If you were bcced on this e-mail, it affects one or more of your packages.
...snip...
> kevin
>   pylibacl
> (→ PY2)
...snip...
>   pyxattr
> python2-pyxattr (→ PY2)
>   rdiff-backup
> (→ PY2)

We requested an exception here for these: https://pagure.io/fesco/issue/2262

kevin


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

Re: Python Annual Release Cycle adjusted to match odd-numbered Fedora releases

[Miro Hrončok]

On 07. 11. 19 17:28, Kevin Fenzi wrote:

On Thu, Nov 07, 2019 at 01:42:30PM +0100, Felix Schwarz wrote:


Am 07.11.19 um 13:31 schrieb Miro Hrončok:

"[2 months for RCs instead of 1] allows for synchronizing the schedule of
Python release management with Fedora. They've been historically very helpful
in early finding regressions not only in core Python but also in third-party
libraries, helping moving the community forward. It seems like a bargain to
make a slight adjustment of our schedule to help Fedora help us make 3.9 and
beyond better releases."
-- Łukasz Langa, Python 3.8 and 3.9 Release Manager


That's a good time to say "thank you, Miro". :-)
(also on behalf of the upstream projects where I am involved and where you
submitted Python 3.8 patches)


Completely agreed! I think the python-sig has done an outstanding job
with 3.8 and all the python2->python3 work. It's not been easy, but they
have done a great job with it.


Thank you, on behalf of the SIG.

--
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: Fedora 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance

[Miro Hrončok]

On 07. 11. 19 17:15, Vít Ondruch wrote:


Dne 07. 11. 19 v 16:05 Tom Hughes napsal(a):

On 07/11/2019 14:59, Victor Stinner wrote:


I cannot explain why PLT is needed when a libpython function calls a
libpython function.


Because an exported symbol in an ELF shared library is subject to
potential interposition using LD_PRELOAD so the calls need to go
through the PLT to be resolved.



Not sure what PLT is (pre load table?), but is it something what could
be disabled?

This sounds like the whole system could be 25% faster if we link statically.


If we build things statically with libraries, it's a can full of worms.
What needs to be said about this change that we don't staticaly link against 
different libraries, we just build CPython source into one "fat" executable 
instead of splitting it into a tiny wrapper and a "fat" libpython.


--
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: Python Annual Release Cycle adjusted to match odd-numbered Fedora releases

[Kevin Fenzi]

On Thu, Nov 07, 2019 at 01:42:30PM +0100, Felix Schwarz wrote:
> 
> Am 07.11.19 um 13:31 schrieb Miro Hrončok:
> > "[2 months for RCs instead of 1] allows for synchronizing the schedule of
> > Python release management with Fedora. They've been historically very 
> > helpful
> > in early finding regressions not only in core Python but also in third-party
> > libraries, helping moving the community forward. It seems like a bargain to
> > make a slight adjustment of our schedule to help Fedora help us make 3.9 and
> > beyond better releases."
> > -- Łukasz Langa, Python 3.8 and 3.9 Release Manager
> 
> That's a good time to say "thank you, Miro". :-)
> (also on behalf of the upstream projects where I am involved and where you
> submitted Python 3.8 patches)

Completely agreed! I think the python-sig has done an outstanding job
with 3.8 and all the python2->python3 work. It's not been easy, but they
have done a great job with it. 

Thank you python sig. 

kevin


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

Re: Fedora 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance

[Tomasz Torcz]

On Thu, Nov 07, 2019 at 05:15:18PM +0100, Vít Ondruch wrote:
> This sounds like the whole system could be 25% faster if we link statically.

  Yeah, that's the advantage of static linking.  This brings us stuff
like statically linked distibutions - https://sta.li/faq/
  Generally advantages of dynamic libraries prevail over speed.

-- 
Tomasz TorczOnce you've read the dictionary,
xmpp: zdzich...@chrome.pl   every other book is just a remix.
___
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: Modularity: The Official Complaint Thread

[Adam Williamson]

On Thu, 2019-11-07 at 05:06 +0100, Kevin Kofler wrote:
> Pierre-Yves Chibon wrote:
> > Symbiotic is, I think, the best way to describe the Red Hat/Fedora
> > relationship.
> 
> Well, a symbiosis has to go both ways. In this case, I unfortunately get the 
> feeling that this feature was implemented to comply with RHEL's needs and 
> RHEL's needs only (enterprise server use cases where everything is 
> containerized, virtualized, or even physically separated, so dependency 
> version conflicts between unrelated applications do not matter) and forced 
> upon Fedora ignoring our needs and our objections. So I would rather 
> describe the relationship as "parasitic" rather than "symbiotic", sorry.

It's funny cause there's a person in the LWN Fedora 31 release
complaining about the half-baked Modularity that Fedora invented for
its desktop use cases being forced on EL. :P

https://lwn.net/Articles/803539/

In reality the truth is, as always, more messy and complicated than any
neat theory. As you know we've been kicking this stuff around in Fedora
for years, all the way back to Rings and before...and in part
Modularity grew out of that process. But it's *also* true that at some
point some folks within RH got very interested in its potential
usefulness for certain RHEL use cases, and were very keen to get it
into RHEL 8 in a form that's useful for those purposes, and both those
forces *together* led to the flurry of work and strong desire to get
bits of Modularity landed in recent Fedoras.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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: EPEL-8 builds

[Stephen John Smoogen]

On Thu, 7 Nov 2019 at 05:13, Peter Robinson  wrote:
>
> Hi,
>
> I'd like to know why people are pushing EPEL-8 builds without engaging
> with the maintainers of the packages. I've had a few packages where
> I'm the only maintainer and I've explicitly not built them for EPEL-8
> for reasons yet people are now coming without any engagement what so
> ever and building them where they won't have to support the packages
> no understand why the maintainer hasn't built them in the first place.
>

What were the packages that this happened with? It is hard to know why
without a list



-- 
Stephen J Smoogen.
___
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 1769870] perl-Image-Sane-4-1.fc32 FTBFS: t/81_scanimage-perl.t test fails with sane-backends-1.0.28

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

Summary|perl-Image-Sane-4-1.fc32|perl-Image-Sane-4-1.fc32
   |FTBFS:  |FTBFS:
   ||t/81_scanimage-perl.t test
   ||fails with
   ||sane-backends-1.0.28



-- 
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 1769870] New: perl-Image-Sane-4-1.fc32 FTBFS:

[bugzilla]

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

Bug ID: 1769870
   Summary: perl-Image-Sane-4-1.fc32 FTBFS:
   Product: Fedora
   Version: 29
Status: NEW
 Component: perl-Image-Sane
  Assignee: ppi...@redhat.com
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



perl-Image-Sane-4-1.fc32 fails to build Fedora 32 because a test fails:

t/2_exit.t . ok
Output format is not set, using pnm as a default.
#   Failed test '--device=test --test 2>&1'
#   at t/81_scanimage-perl.t line 41.
#  got: 'scanimage: scanning image of size 157x196 pixels at 8
bits/pixel
# scanimage: acquiring gray frame, 8 bits/sample
# scanimage: reading one scanline, 157 bytes... PASS
# scanimage: reading one byte...PASS
# scanimage: stepped read, 2 bytes...   PASS
# scanimage: stepped read, 4 bytes...   PASS
# scanimage: stepped read, 8 bytes...   PASS
# scanimage: stepped read, 16 bytes...  PASS
# scanimage: stepped read, 32 bytes...  PASS
# scanimage: stepped read, 64 bytes...  PASS
# scanimage: stepped read, 128 bytes... PASS
# scanimage: stepped read, 256 bytes... PASS
# scanimage: stepped read, 255 bytes... PASS
# scanimage: stepped read, 127 bytes... PASS
# scanimage: stepped read, 63 bytes...  PASS
# scanimage: stepped read, 31 bytes...  PASS
# scanimage: stepped read, 15 bytes...  PASS
# scanimage: stepped read, 7 bytes...   PASS
# scanimage: stepped read, 3 bytes...   PASS
# '
# expected: 'Output format is not set, using pnm as a default.
# scanimage: scanning image of size 157x196 pixels at 8 bits/pixel
# scanimage: acquiring gray frame, 8 bits/sample
# scanimage: reading one scanline, 157 bytes... PASS
# scanimage: reading one byte...PASS
# scanimage: stepped read, 2 bytes...   PASS
# scanimage: stepped read, 4 bytes...   PASS
# scanimage: stepped read, 8 bytes...   PASS
# scanimage: stepped read, 16 bytes...  PASS
# scanimage: stepped read, 32 bytes...  PASS
# scanimage: stepped read, 64 bytes...  PASS
# scanimage: stepped read, 128 bytes... PASS
# scanimage: stepped read, 256 bytes... PASS
# scanimage: stepped read, 255 bytes... PASS
# scanimage: stepped read, 127 bytes... PASS
# scanimage: stepped read, 63 bytes...  PASS
# scanimage: stepped read, 31 bytes...  PASS
# scanimage: stepped read, 15 bytes...  PASS
# scanimage: stepped read, 7 bytes...   PASS
# scanimage: stepped read, 3 bytes...   PASS
# '
[...]
t/81_scanimage-perl.t (Wstat: 1280 Tests: 6 Failed: 5)
  Failed tests:  2-6
  Non-zero exit status: 5

A difference between passing and failing test is at
.

An rebase of sane-backends from 1.0.27-24.fc29 to 1.0.28-1.fc29 looks
suspicious. Please note that sane-backends was upgraded in all Fedoras and the
tests fail in all Fedoras now.

-- 
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 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance

[Vít Ondruch]

Dne 07. 11. 19 v 16:05 Tom Hughes napsal(a):
> On 07/11/2019 14:59, Victor Stinner wrote:
>
>> I cannot explain why PLT is needed when a libpython function calls a
>> libpython function.
>
> Because an exported symbol in an ELF shared library is subject to
> potential interposition using LD_PRELOAD so the calls need to go
> through the PLT to be resolved.


Not sure what PLT is (pre load table?), but is it something what could
be disabled?

This sounds like the whole system could be 25% faster if we link statically.


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

[Bug 1769866] perl-GStreamer-0.20-17.fc32 FTBFS: Unsatisfied gstreamer-devel >= 0.10.0 build dependency

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

Summary|perl-GStreamer-0.20-17.fc32 |perl-GStreamer-0.20-17.fc32
   |FTBFS: Missing  |FTBFS: Unsatisfied
   |gstreamer-devel >= 0.10.0   |gstreamer-devel >= 0.10.0
   |build dependency|build dependency



-- 
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: Getting notified on broken deps from updates-testing

[Miro Hrončok]

On 07. 11. 19 16:26, Fabio Valentini wrote:

On Thu, Nov 7, 2019 at 10:14 AM Miro Hrončok  wrote:


On 07. 11. 19 9:55, Fabio Valentini wrote:

On Thu, Nov 7, 2019, 09:25 Miro Hrončok mailto:mhron...@redhat.com>> wrote:

 On 06. 11. 19 23:10, Randy Barlow wrote:
  > On Wed, 2019-11-06 at 21:32 +0100, Miro Hrončok wrote:
  >> Is there any good way to get notified about this sort of problems in
  >> timely manner prior to the update being pushed? This is currently not
  >> optimal.
  >
  > I'm not familiar with an existing solution to this problem, but I agree
  > that it is not optimal.
  >
  > I had a chat or three with Brian Stinson about some ways we could deal
  > with problems like this. Today, when we CI packages (i.e., Bodhi
  > gating), we typically just run the tests associated with the package
  > being altered. Brian suggested that we could *also* run the tests of
  > the packages that depend on the package being altered, against the
  > altered package. This way if a change to something (like pyramid) would
  > break a dependent package's tests (such as cornice), then the update
  > for pyramid should get a failed test result on its tests tab. The
  > problem is that this does increase the load on the test system greatly,
  > but perhaps we can get enough hardware to make that OK. Not sure.


 Having this sort of CI would be awesome, however it looks like it's not on 
the
 top of the TODO list:

 RFE: Koschei-like CI (opened  8 months ago)
 https://pagure.io/fedora-ci/general/issue/45

 RFE: Check if dependent packages install (opened 8 months ago)
 https://pagure.io/fedora-ci/general/issue/46

 Support automatic execution of tests of dependent components (opened 1 
year ago)
 https://pagure.io/fedora-ci/general/issue/7


 And either way, since CI is opt-in, I would need to go and setup CI for 
all of
 dependencies (including transitive) of all my packages. I haven't really
 checked
 how big is this tree but I suppose it is enormous.


Would an automated daily report (like the broken rawhide deps report that we
used to have) help? I could hack that together for different fedora branches +
updates-testing pretty easily, and adding notifications when a broken dependency
gets added in -testing wouldn't be hard either.


I've mostl started this thread to see if I indeed need to script this.

If you could look into it, ut would be awesome.

This is very useful as starting point (rawhide example):

$ sudo dnf --repo=rawhide makecache
$ installcheck x86_64 /var/cache/dnf/rawhide*.solv*

(Igor has shown this to me at Flock.)

It would probably need some interface that let me filter my packages. And
multi-repo for released Fedora.

This is what we use for Python 2 in rawhide:

https://github.com/fedora-python/portingdb/blob/master/portingdb/check_fti.py


Oh, I didn't know installcheck existed.
I've used repoclosure to get unsatisfied dependencies for all packages
(including unsatisfied BRs).

My initial work is here:
https://pagure.io/fedora-health-check


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

[Bug 1769866] New: perl-GStreamer-0.20-17.fc32 FTBFS: Missing gstreamer-devel >= 0.10.0 build dependency

[bugzilla]

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

Bug ID: 1769866
   Summary: perl-GStreamer-0.20-17.fc32 FTBFS: Missing
gstreamer-devel >= 0.10.0 build dependency
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-GStreamer
  Assignee: emman...@seyman.fr
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



perl-GStreamer-0.20-17.fc32 cannot be built in Fedora 32 because there is no
package that would satisfy "gstreamer-devel >= 0.10.0" build-time dependency.

-- 
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: Getting notified on broken deps from updates-testing

[Fabio Valentini]

On Thu, Nov 7, 2019 at 10:14 AM Miro Hrončok  wrote:
>
> On 07. 11. 19 9:55, Fabio Valentini wrote:
> > On Thu, Nov 7, 2019, 09:25 Miro Hrončok  > > wrote:
> >
> > On 06. 11. 19 23:10, Randy Barlow wrote:
> >  > On Wed, 2019-11-06 at 21:32 +0100, Miro Hrončok wrote:
> >  >> Is there any good way to get notified about this sort of problems in
> >  >> timely manner prior to the update being pushed? This is currently 
> > not
> >  >> optimal.
> >  >
> >  > I'm not familiar with an existing solution to this problem, but I 
> > agree
> >  > that it is not optimal.
> >  >
> >  > I had a chat or three with Brian Stinson about some ways we could 
> > deal
> >  > with problems like this. Today, when we CI packages (i.e., Bodhi
> >  > gating), we typically just run the tests associated with the package
> >  > being altered. Brian suggested that we could *also* run the tests of
> >  > the packages that depend on the package being altered, against the
> >  > altered package. This way if a change to something (like pyramid) 
> > would
> >  > break a dependent package's tests (such as cornice), then the update
> >  > for pyramid should get a failed test result on its tests tab. The
> >  > problem is that this does increase the load on the test system 
> > greatly,
> >  > but perhaps we can get enough hardware to make that OK. Not sure.
> >
> >
> > Having this sort of CI would be awesome, however it looks like it's not 
> > on the
> > top of the TODO list:
> >
> > RFE: Koschei-like CI (opened  8 months ago)
> > https://pagure.io/fedora-ci/general/issue/45
> >
> > RFE: Check if dependent packages install (opened 8 months ago)
> > https://pagure.io/fedora-ci/general/issue/46
> >
> > Support automatic execution of tests of dependent components (opened 1 
> > year ago)
> > https://pagure.io/fedora-ci/general/issue/7
> >
> >
> > And either way, since CI is opt-in, I would need to go and setup CI for 
> > all of
> > dependencies (including transitive) of all my packages. I haven't really
> > checked
> > how big is this tree but I suppose it is enormous.
> >
> >
> > Would an automated daily report (like the broken rawhide deps report that we
> > used to have) help? I could hack that together for different fedora 
> > branches +
> > updates-testing pretty easily, and adding notifications when a broken 
> > dependency
> > gets added in -testing wouldn't be hard either.
>
> I've mostl started this thread to see if I indeed need to script this.
>
> If you could look into it, ut would be awesome.
>
> This is very useful as starting point (rawhide example):
>
> $ sudo dnf --repo=rawhide makecache
> $ installcheck x86_64 /var/cache/dnf/rawhide*.solv*
>
> (Igor has shown this to me at Flock.)
>
> It would probably need some interface that let me filter my packages. And
> multi-repo for released Fedora.
>
> This is what we use for Python 2 in rawhide:
>
> https://github.com/fedora-python/portingdb/blob/master/portingdb/check_fti.py

Oh, I didn't know installcheck existed.
I've used repoclosure to get unsatisfied dependencies for all packages
(including unsatisfied BRs).

My initial work is here:
https://pagure.io/fedora-health-check

I'll set up a cron job to generate and push this data daily.
Once (or if) the list of broken stuff ever gets smaller I can also set
up automated notifications ...

Fabio

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

The same RPM macro but different value for arch/noarch builds - how?

[Peter Lemenkov]

Hello All,
We have a set of macros for Erlang libraries rpm building. Some of
these macros evaliated before actual build (if I understand RPM build
process correctly) and their actual value depends on a type of a
package - arch-dependent or noarch.

Previously we've used %{buildarch} macro to distinguish between
noarch-packages and arch-specific and that  worked well enough.
Unfortunately this macro was removed recently.

Is there a way to pass "noarch" to some scripts from
/usr/lib/rpms/macros.d when building noarch package? Spec-file was
marked already as BuildArch: noarch. Where this information is stored
now?

-- 
With best regards, Peter Lemenkov.
___
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: Fedora 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance

[Tom Hughes]

On 07/11/2019 14:59, Victor Stinner wrote:


I cannot explain why PLT is needed when a libpython function calls a libpython 
function.


Because an exported symbol in an ELF shared library is subject to
potential interposition using LD_PRELOAD so the calls need to go
through the PLT to be resolved.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
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: List of Python 2 packages to be removed mid-November (= in a week)

[Miro Hrončok]

On 07. 11. 19 14:59, Felix Schwarz wrote:


Am 07.11.19 um 14:57 schrieb Felix Schwarz:

Is there some automation to remove "python2-" subpackages or do you plan some
"single hero"-style changes? If neither what is the plan for maintainers who
just don't do anything?


I should do more reading before replying to emails :-/

Change description says:
"The package removal will be executed in an automated fashion."


However, there are some things that still need to be considered here.

1. Automation is not 100 % accurate (some packages are very custom), there is a 
great deal of single-hero-style adapting of the automation results. I've been 
doing this for a ~year. I use Zbyszek's 
https://pagure.io/pyrenamer/blob/master/f/depython2ize.py and adapt the package 
by hand.


2. Some maintainers prefer a singlespec with %ifs and our automation just 
deletes stuff.


3. Some packages FTBFS for unrelated reasons.

4. Some packagers will be angry if we touch their packages. They will say we are 
militant, hostile or that we haven't warned them enough. They will say that they 
were working on porting. Unfortunately, this is an arguably controversial change 
and we anticipate push back after it gets done.



What **I think** we'll do is that once the deadline passes, we'll say "remove 
your Python 2 packages from this list and don't care about the dependencies". A 
great amount of packages is maintained by the SIG and we can handle it. Another 
great amount is maintained by maintainer who actually want to do this.


For the rest, we might create bugzillas like we do here:

https://bugzilla.redhat.com/showdependencytree.cgi?id=PY2REMOVAL_resolved=1

Note that this is not the current plan, but just my rough thoughts.
The truth is, the "execution" of this change is still not fully figured out.
We'll keep devel@ informed.

--
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: Fedora 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance

[Victor Stinner]

> Where are these number coming from?

There are pyperformance results:
https://fedoraproject.org/wiki/Changes/PythonStaticSpeedup#Benefit_to_Fedora

It's the official benchmark suite to measure the Python performance on 
speed.python.org.

I ran the benchmarks on my laptop using CPU isolation (isolcpus and rcu_nocbs 
Linux kernel parameters).

> And what is the reason for the performance hit for dynamically linked Python?

Honestly, the speedup doesn't make any sense to me :-D But I only trust 
benchmark results, not beliefs nor documentations about compilers and linkers.

I looked at the assembly to compare statically linked and dynamically linked 
"python3.8" binaries. I noticed two main differences:

* function calls in dynamically linked Python use the PTL thing: it's not a 
direct function call, there is an indirection
* I see inlining more often in the statically linked Python

Reminder: currently (dynamically linked Python), /usr/bin/python3.8 is 
basically just a single function call to Py_BytesMain(argc, argv). ALL Python 
code lives in libpython.

I cannot explain why inlining cannot be done more often in libpython.

I cannot explain why PLT is needed when a libpython function calls a libpython 
function.

> Yea. This sounds like a bug/deficiency in the linking system, and the
> problem is possibly attacked from the wrong direction.

IMHO compilers and linkers are doing their best to optimize libpython, but the 
nature of libpython (a dynamic .so library) prevents some kinds of 
optimizations.

It seems like putting all code into an *application* allows to go further in 
term of optimization.

By the way, the two binaries that I analyzed are optimized using LTO (Link Time 
Optimization) *and* PGO (Profile Guided Optimization). They are the most 
advanced optimizations technics!

Victor
___
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: Encrypted DNS in Fedora

[stan via devel]

On Thu, 7 Nov 2019 12:20:50 +0100
David Sommerseth  wrote:
 
> Please just watch the talk by Paul Vixie (who is one of the really
> big DNS gurus these days, even ISC BIND maintainer for quite some
> years).  And you will see that DoH is pointless when you have DoT.
> But DoT can also go much further than DoH will, when you consider the
> bigger part of the DNS query chain.

Thank you for pointing to that talk.  I found it very informative, as a
mostly ignorant user of DNS.  I run knot-resolver as a local caching DNS
server, pulling from, ironically, 1.1.1.1 via the router, and bypassing
my ISP's DNS servers.  Really opened my eyes.

For convenience, repeating it here.
https://www.youtube.com/watch?v=8SJorQ9Ufm8
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages looking for new maintainers (incl. wine, dosbox, nextcloud, owncloud)

[Michael Cronenworth]

On 11/7/19 1:52 AM, Frantisek Zatloukal wrote:
I can take wine if you want that only as a last resort :) But, I'd be happy if you 
would co-maintain that, more people looking after the package like this is always 
better.


FAS: frantisekz


Andreas was the primary owner but has been away from Fedora for quite some time. 
Looks like someone finally did a URM on him. I've filed a request for primary 
ownership, but co-maintainers are always welcome.


https://pagure.io/releng/issue/8979
___
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: List of Python 2 packages to be removed mid-November (= in a week)

[Felix Schwarz]

Am 07.11.19 um 14:57 schrieb Felix Schwarz:
> Is there some automation to remove "python2-" subpackages or do you plan some
> "single hero"-style changes? If neither what is the plan for maintainers who
> just don't do anything?

I should do more reading before replying to emails :-/

Change description says:
"The package removal will be executed in an automated fashion."

sorry for the noise
Felix
___
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: List of Python 2 packages to be removed mid-November (= in a week)

[Felix Schwarz]

Am 07.11.19 um 14:47 schrieb Miro Hrončok:
> On 07. 11. 19 14:41, Felix Schwarz wrote:
>> However the wiki page says:
>> "All packages depending on any python2 package will be removed."
> 
> All "binary" packages.
(...)
>> So maybe I just misunderstood the change. What happens when a package like
>> python-six still produces a Python 2 subpackage after $CUTOFF_DATE ?
> 
> We'll remove python2-six and keep python3-six.

Thank you very much for the clarification.

But how exactly will you ensure that the python2 subpackage is going away?
(not just python-six but regarding all the other python packages)

Is there some automation to remove "python2-" subpackages or do you plan some
"single hero"-style changes? If neither what is the plan for maintainers who
just don't do anything?

> Sorry for the confusion.

Thank you for your explanation + all the preparation leading to this step.

Felix
___
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: List of Python 2 packages to be removed mid-November (= in a week)

[Miro Hrončok]

On 07. 11. 19 14:41, Felix Schwarz wrote:

Hi Miro,

Am 07.11.19 um 14:34 schrieb Miro Hrončok:

We actually are wiping out the entire Python 2 ecosystem here, that is the 
point.


Ok, maybe I misunderstood the change.
Just to be clear: I'm fine with the Python 2 package removal (though I expect
I'll continue to develop Python 2 code outside of Fedora for many years to 
come).

However the wiki page says:
"All packages depending on any python2 package will be removed."


All "binary" packages.


To me this means if there is a python2-six subpackage after a certain cutoff
date we also remove the actual Fedora "python-six" package because it produces
a Python 2 subpackage which can not be built any longer.

In that sense I feel like "python3-six" is a high-profile package because its
removal would cause quite a lot of dependent packages to be removed.

So maybe I just misunderstood the change. What happens when a package like
python-six still produces a Python 2 subpackage after $CUTOFF_DATE ?


We'll remove python2-six and keep python3-six.

Sorry for the confusion.

--
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: List of Python 2 packages to be removed mid-November (= in a week)

[Felix Schwarz]

Hi Miro,

Am 07.11.19 um 14:34 schrieb Miro Hrončok:
> We actually are wiping out the entire Python 2 ecosystem here, that is the 
> point.

Ok, maybe I misunderstood the change.
Just to be clear: I'm fine with the Python 2 package removal (though I expect
I'll continue to develop Python 2 code outside of Fedora for many years to 
come).

However the wiki page says:
"All packages depending on any python2 package will be removed."

To me this means if there is a python2-six subpackage after a certain cutoff
date we also remove the actual Fedora "python-six" package because it produces
a Python 2 subpackage which can not be built any longer.

In that sense I feel like "python3-six" is a high-profile package because its
removal would cause quite a lot of dependent packages to be removed.

So maybe I just misunderstood the change. What happens when a package like
python-six still produces a Python 2 subpackage after $CUTOFF_DATE ?

Felix
___
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: List of Python 2 packages to be removed mid-November (= in a week)

[Miro Hrončok]

On 07. 11. 19 13:59, Felix Schwarz wrote:


Am 07.11.19 um 13:01 schrieb Petr Viktorin:

If this took you by surprise, don't panic. It's possible to change the
default. Let us know and we'll work things out.


Somehow I feel like I don't understand the report – or we are approaching an
(almost) unmitigated disaster here: There are so many "high profile" packages
which are slated for removal that we might wipe out half of our Python
packaging eco system.


What are the high profile packages you are talking about?

We actually are wiping out the entire Python 2 ecosystem here, that is the 
point.


However I hope that I might misinterpret the report:

pviktori
   python-six
 python2-six (→ PY2)


The spec file says:

# python2 is enabled by default, Fedora 32+ exception is anticipated
%bcond_without python2


However when I check the fesco tracker I don't find any issue to request the
exception:
https://pagure.io/fesco/issues?status=all_pattern=six


It was expected, but so far no package with an exception request needed it.


There are many, many more packages like python-mako and python-sqlalchemy and
it would be *very* painful if they went away (as we'd have to remove *a lot*
of dependent packages).


All the dependent packages are listed in this report.
What listed packages would be painful to remove?

Note that I don't recognize libraries as high profile, unless they are needed by 
high profile software. If you disagree and consider a library high profile by 
itself, you can request an exception for that library, but unless you make a 
very strong case, I'd vote against.



I could probably fix a few packages myself but right now I don't have any
"extra powers" besides being a regular maintainer. Requesting the necessary
permissions would take quite a while as I am trying to get in touch with some
maintainers basically for months (without success).


What packages you need to fix?


The problem seems to be that even packages maintained by the Python SIG still
require python2 (without fesco exception).


Some of mine as well. I'm waiting for the deadline to drop them, if not other 
package with exception drags them in.



What can I do to cut down the number of Python 2 subpackages?


Wait.

--
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: Please, IMHO, resolve in some way the Samba MIT kerberos problem.

[Simo Sorce]

On Mon, 2019-11-04 at 20:45 -0500, Nico Kadel-Garcia wrote:
> On Mon, Nov 4, 2019 at 8:39 AM Neal Gompa  wrote:
> 
> > The problem with the Samba team's advice is that it essentially
> > prevents the MIT Kerberos AD-DC implementation from getting any
> > better. Without people using it, we can't know what needs to be fixed.
> > The Red Hat FreeIPA team has been working on making this functionality
> > work well with MIT Kerberos for nearly a decade. The main reason it's
> > not in RHEL/CentOS 8 is because the functionality is too new for them
> > to turn it on.
> 
> I've been using Samba effectively for multi-platform integration and
> account manage since 1996. This is not quite before Red Hat existed,
> but it's close. d. I have never found FreeIPA to be useful in a
> personal or professional environment. It relies on Samba for
> integration with AD. Without robust integration with AD, I have no use
> for FreeIPA. And I don't know *anyone* who uses a FreeIPA server.
> 
> Perhaps it's time to drop FreeIPA?

Perhaps it's time to learn to behave.

> > Also, declaring that it is experimental is meaningless. What defines
> > it as experimental? Is there any particular known massive breakage?
> > We're not going to ship Heimdal Kerberos because the two Kerberos
> > implementations are incompatible and supporting both would be a
> > massive nightmare.
> 
> That aounsa like a question for the Samba lists. I'm active over
> there. Want me to double check the status?
> 
> > At this point, the only way Samba Team will stop calling it
> > experimental is when lots of folks are using it. That's why Fedora
> > ships with it enabled. We have the opportunity to help make that
> > better upstream.
> 
> I think they're confused by the fact that Fedora and Red Hat, for
> *years*, shipped with a "samba-dc" suite of packages that didn't
> actually contain any software. The samba-dc packages basically said
> "go away you silly English knighits or I shall taunt you a second
> time". Samba-dc packages shouldnever have been published this way: it
> would have been saner and safer to set a "Conflicts: samba-dc*" with
> the primary samba package if these features were not enabled, rather
> than publishing empty and useless packages. This is, in fact, what I
> do with my published backports of Samba to RHEL with the dc enabled
> with Heimdal.. I've been having some adventures with building those
> lately due to modularity and the activation of zstd for RPM and the
> instability of Fedora 31 in virtualized environments, but I received
> workarounds from mock developers for that a few days ago.
> 
> If people want to play with packages with the Heimdal libraries
> enabled, I publish my RPM building repos over at
> https://github.com/nkadel/samba4repo/. It's dependent on other
> compatibility libraries due to gnutls requirements and some missing
> libraries in RHEL 8, but I've had good seccess with it on various
> tests with Fedora 30. Fedora 31. has so far proven impossible for
> me to keep alive in a virtualization environment long enough to
> actually test.
> ___
> 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

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
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: List of Python 2 packages to be removed mid-November (= in a week)

[Miro Hrončok]

On 07. 11. 19 14:04, Jun Aruga wrote:

## What exactly is happening?

The formal change proposal is here:
https://fedoraproject.org/wiki/Changes/RetirePython2

Packages requiring Python 2 will be removed starting November 15 (unless
they have an exception).
Components with all essential subpackages removed will be retired.
The removal will be (semi-)automated.

Source packages only BuildRequiring removed packages will fail to build,
and will be removed according to the regular FTBFS policy.


Will this happen only for rawhide?
How about f31, f30, f29 branch?


This is a Fedora 32 change. This will only happen in rawhide.
We cannot remove packages from released Fedoras anyway.

--
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: List of Python 2 packages to be removed mid-November (= in a week)

[Jun Aruga]

> ## What exactly is happening?
>
> The formal change proposal is here:
> https://fedoraproject.org/wiki/Changes/RetirePython2
>
> Packages requiring Python 2 will be removed starting November 15 (unless
> they have an exception).
> Components with all essential subpackages removed will be retired.
> The removal will be (semi-)automated.
>
> Source packages only BuildRequiring removed packages will fail to build,
> and will be removed according to the regular FTBFS policy.

Will this happen only for rawhide?
How about f31, f30, f29 branch?

-- 
Jun | He - His - Him
___
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 1769773] Add perl-Cache-LRU to EPEL8

[bugzilla]

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



--- Comment #1 from Jitka Plesnikova  ---
https://pagure.io/releng/fedora-scm-requests/issue/19473
https://pagure.io/releng/fedora-scm-requests/issue/19474

-- 
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: List of Python 2 packages to be removed mid-November (= in a week)

[Felix Schwarz]

Am 07.11.19 um 13:01 schrieb Petr Viktorin:
> If this took you by surprise, don't panic. It's possible to change the
> default. Let us know and we'll work things out.

Somehow I feel like I don't understand the report – or we are approaching an
(almost) unmitigated disaster here: There are so many "high profile" packages
which are slated for removal that we might wipe out half of our Python
packaging eco system.

However I hope that I might misinterpret the report:
> pviktori
>   python-six
> python2-six (→ PY2)

The spec file says:
> # python2 is enabled by default, Fedora 32+ exception is anticipated
> %bcond_without python2

However when I check the fesco tracker I don't find any issue to request the
exception:
https://pagure.io/fesco/issues?status=all_pattern=six


There are many, many more packages like python-mako and python-sqlalchemy and
it would be *very* painful if they went away (as we'd have to remove *a lot*
of dependent packages).


I could probably fix a few packages myself but right now I don't have any
"extra powers" besides being a regular maintainer. Requesting the necessary
permissions would take quite a while as I am trying to get in touch with some
maintainers basically for months (without success).

The problem seems to be that even packages maintained by the Python SIG still
require python2 (without fesco exception).

To be clear: This is a about packages with active upstream, which support
Python 3 and just happen to have a Python 2 subpackage in Fedora rawhide.

What can I do to cut down the number of Python 2 subpackages?

Felix
___
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 1769775] Add perl-GraphViz to EPEL8

[bugzilla]

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



--- Comment #1 from Petr Pisar  ---
https://pagure.io/releng/fedora-scm-requests/issue/19471
https://pagure.io/releng/fedora-scm-requests/issue/19472

-- 
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 1769775] Add perl-GraphViz to EPEL8

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|jples...@redhat.com |ppi...@redhat.com



-- 
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: Python Annual Release Cycle adjusted to match odd-numbered Fedora releases

[Miro Hrončok]

On 07. 11. 19 13:42, Felix Schwarz wrote:


Am 07.11.19 um 13:31 schrieb Miro Hrončok:

"[2 months for RCs instead of 1] allows for synchronizing the schedule of
Python release management with Fedora. They've been historically very helpful
in early finding regressions not only in core Python but also in third-party
libraries, helping moving the community forward. It seems like a bargain to
make a slight adjustment of our schedule to help Fedora help us make 3.9 and
beyond better releases."
-- Łukasz Langa, Python 3.8 and 3.9 Release Manager


That's a good time to say "thank you, Miro". :-)
(also on behalf of the upstream projects where I am involved and where you
submitted Python 3.8 patches)


Felix, your appreciation means a lot to me.

--
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: Python Annual Release Cycle adjusted to match odd-numbered Fedora releases

[Miro Hrončok]

On 07. 11. 19 13:42, Felix Schwarz wrote:


Am 07.11.19 um 13:31 schrieb Miro Hrončok:

"[2 months for RCs instead of 1] allows for synchronizing the schedule of
Python release management with Fedora. They've been historically very helpful
in early finding regressions not only in core Python but also in third-party
libraries, helping moving the community forward. It seems like a bargain to
make a slight adjustment of our schedule to help Fedora help us make 3.9 and
beyond better releases."
-- Łukasz Langa, Python 3.8 and 3.9 Release Manager


That's a good time to say "thank you, Miro". :-)
(also on behalf of the upstream projects where I am involved and where you
submitted Python 3.8 patches)


Felix, your appreciation means a lot to me.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org

[Bug 1768805] perl-RDF-Trine for EL8

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Depends On||1769775




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1769775
[Bug 1769775] Add perl-GraphViz to EPEL8
-- 
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 1769775] New: Add perl-GraphViz to EPEL8

[bugzilla]

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

Bug ID: 1769775
   Summary: Add perl-GraphViz to EPEL8
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-GraphViz
  Assignee: jples...@redhat.com
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, lkund...@v3.sk,
perl-devel@lists.fedoraproject.org,
rc040...@freenet.de, vanmeeuwen+fed...@kolabsys.com
Blocks: 1768805
  Target Milestone: ---
Classification: Fedora



Please add perl-GraphViz package to EPEL8. It's almost a hard dependency of
perl-RDF-Trine.


Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1768805
[Bug 1768805] perl-RDF-Trine for EL8
-- 
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: Python Annual Release Cycle adjusted to match odd-numbered Fedora releases

[Felix Schwarz]

Am 07.11.19 um 13:31 schrieb Miro Hrončok:
> "[2 months for RCs instead of 1] allows for synchronizing the schedule of
> Python release management with Fedora. They've been historically very helpful
> in early finding regressions not only in core Python but also in third-party
> libraries, helping moving the community forward. It seems like a bargain to
> make a slight adjustment of our schedule to help Fedora help us make 3.9 and
> beyond better releases."
> -- Łukasz Langa, Python 3.8 and 3.9 Release Manager

That's a good time to say "thank you, Miro". :-)
(also on behalf of the upstream projects where I am involved and where you
submitted Python 3.8 patches)

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