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

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

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

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

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

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

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

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

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

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

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

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

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

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

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&hide_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&search_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

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

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

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

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

[Miro Hrončok]

Hello,

I'd like to inform you that [PEP 602] "Annual Release Cycle for Python" has been 
approved and [PEP 596] "Python 3.9 Release Schedule" is pending approval:


tl;dr New Python 3.X versions will be released annually, with RC period adjusted 
to make it possible to update Python in odd-numbered Fedora releases. We plan to 
submit the Python 3.9 change proposal for Fedora 33 after the first Python 3.9 
alpha (expected in ~2 weeks).



The Python 3.8 update was postponed from Fedora 31 to Fedora 32 because the 
schedule was too tight. With 3.9 and the recent adjustments, we expect that 
Fedora 33 is a reasonable target release, but we are prepared to reevaluate that 
after branching.


Like with 3.8, we plan to rebuild Fedora packages with Python 3.9 pre-releases, 
file bugs, and coordinate fixes both to Python and the software that uses it. We 
hope to make that process smoother, but even more effective at finding and 
resolving incompatibilities. With the shorter cycle, we anticipate less 
incompatibilities.



Quotes from PEP 602:

(Rationale and Goals)
"This change provides the following advantages: ... allows for synchronizing the 
schedule of Python release management with external distributors like Fedora 
who've been historically very helpful in finding regressions early not only in 
core Python but also in third-party libraries, helping moving the community 
forward to support the latest version of Python from Day 1"


(Rejected Ideas)
"While [keeping 4 betas over 4 months and a final month for the release 
candidate] would make the release calendar a bit cleaner, it would make it very 
hard for external distributors like Fedora to release the newest version of 
Python as soon as possible. We are adjusting Python's calendar here in the hope 
that this will enable Fedora to integrate the newest version of Python with the 
newest version of Fedora as both are being developed which makes both projects 
better."


Quotes from the [python-dev] mailing list:

"...in order to give the community enough time to provide feedback in the betas 
while having enough time to thoroughly test the RC and to prep for the final 
release so the delay from Python's final release to any new project releases is 
minimal. It should also fit into the release schedule of Linux distributions 
like Fedora better than previously proposed so the distributions can test the RC 
when they start preparing for their own October releases."

-- Brett Cannon, Python Steering Council member

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


[PEP 596] https://www.python.org/dev/peps/pep-0596/
[PEP 602] https://www.python.org/dev/peps/pep-0602/
[python-dev] 
https://mail.python.org/archives/list/python-...@python.org/thread/KE7OS4PZASZMFTW2FP2MWZU5R4Q2QZKU/

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

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

[Petr Viktorin]

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.

The default action will be to remove such packages starting November 15.

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.
The mid-November deadline is not for removing *all* of Python 2, but for 
getting exceptions.


If you are already working to port to Python 3, sorry for the spam! But, 
time is running out. Consider getting an exception so the package isn't 
removed in November. Or remove the package (if nothing depends on it) 
and re-introduce it when it's ported. (We'll be happy to help, with 
reviews or otherwise.)
If you want to remove the Python 2 package, but you're waiting for 
something that depends on it, please make sure you know what the 
maintainer(s) of the dependent package are planning to do. (Hopefully 
you have fewer dependents than "python27" or "python2-setuptools", and 
your questions can be more targeted than this e-mail.)
If you want to continue using Python 2, please let us know ASAP. We can 
guide you through filing the FESCo exception.


If you talked to us (on e-mail or Bugzilla) and think your package is 
fine as it is, but you don't have a FESCo exception (or a request for 
one), then there was a misunderstanding. We're sorry for our side of it. 
Please get a FESCo exception for your package.


Note: Packages that BuildRequire python27, and have no other Python 2 
dependencies, have a blanket exception for Fedora 32:

https://pagure.io/fesco/issue/2250
They aren't listed below.
Also note: Orphaned Python 2 packages also aren't listed below, but will 
be removed unless someone adopts them and gets an exception.



## Why the FESCo exception?

It's a bit of process meant to ensure all the relevant people know that 
a package *and its dependencies* will stay in Fedora, despite using an 
(upstream-)unmaintained interpreter.
With hundreds of packages, all different, we unfortunately do need a bit 
of bureaucracy.
Due to the volume, the Python 2 removal will be *automated*, so if you 
have an "obvious exception", it's still important to let *humans* know, 
so they can adapt their automation.



## Why now?

The current maintainers of python27 don't want to maintain it forever, 
without upstream support. But we also don't want to just drop it and let 
everything burn, hence all this fuss.
The policy and messaging around deprecating and removing Python 2 has 
been getting stronger and stronger ever since the Python 3.0 release in 
2008.

If you still need more time, please let us know.


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


https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/


## The list

Here is the package breakdown sorted by maintainers.
The list contains the shortest dependency path to Python 2. The arrow 
means "depends on".


The data is based on the latest rawhide compose, so it might be a bit 
out of date.


If you find a bogus dependency, such as a dependency that can be 
resolved in a non-Python 2 way, please let us know, so we can blacklist it.


aarem
  pdf-stapler
(→ PY2)
python2-staplelib (→ PY2)
  python-PyPDF2
python2-PyPDF2 (→ PY2)
  python2-more-itertools
(→ PY2)
abbot
  protobuf
python2-protobuf (→ PY2)
abompard
  python-coverage
python2-coverage (→ PY2)
  python-mako
python2-mako (→ PY2)
  python-pysocks
python2-pysocks (→ PY2)
  python-urllib3
python2-urllib3 (→ PY2)
ajmitchell
  NFStest
(→ PY2)
alexl
  dbus
(BuildRequires: python2-gobject → PY2)
  dbus-python
python2-dbus (→ PY2)
  gnome-python2
gnome-python2-canvas (→ PY2)
gnome-python2-devel (→ PY2)
gnome-python2-gconf (→ PY2)
gnome-python2-gnome (→ PY2)
gnome-python2-gnomevfs (→ PY2)
  gnome-python2-desktop
(→ gnome-python2-canvas → PY2)
gnome-python2-gnomekeyring (→ PY2)
gnome-python2-libwnck (→ PY2)
gnome-python2-rsvg (→ PY2)
alsadi
  dumb-init
(BuildRequires: python2-mock → PY2)
amigadave
  dbus
(BuildRequires: python2-gobject → PY2)
amluto
  python-musicbrainzngs
python2-musicbrainzngs (→ PY2)
anishpatil
  gnome-transliteration
(→ python2-gobject → PY2)
aperezbios
  sugar
(→ PY2)
sugar-cp-* (→ sugar → PY2)
  telepathy-salut
(BuildRequires: python2-dbus → PY2)
apevec
  pyparsing
python2-pyparsing (→ PY2)
  python-distutils-extra
  

Re: Encrypted DNS in Fedora

[David Sommerseth]

On 06/11/2019 18:56, Michael Catanzaro wrote:
> On Wed, Nov 6, 2019 at 4:54 pm, David Sommerseth  wrote:
>> Yes, TLSv1.3 with encrypted SNI will help to some degree, but still there IP
>> addresses you connect to will still provide meta data which can be used to
>> profile you and give an indication of what kind of sites you visit.
> 
> Well that's the whole point right there. In combination with ESNI, it's no
> longer possible to tell which domain you are visiting on a particular vhost.
> It's not perfect, but that's still tremendously better than nothing. It is why
> Mozilla and EFF are strongly promoting DoH.
> 

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.

Plus, ignoring the local networks DNS also has its own set of challenges when
being added directly to browsers.  Like hostnames only available inside a
local network will no longer be available.  But again, watch the talk, these
points are well covered there.


-- 
kind regards,

David Sommerseth
___
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

[Christopher Engelhard]

On 11/5/2019 9: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, 

Thank you, that seems like a very good way forward.

> 6. We don't provide a direct solution for parallel-installability.
> This is an intentional design decision, but it *is* arguably a
> regression from SCL functionality, so I'll include it here.

Others have made this point before, but I want to emphasise how 
important this is:
If we decide that parallel installability is a non-goal - which IMO is a 
reasonable decision to make - we accept that this (via having module 
streams as dependencies) will at some point cause conflicts between 
mostly unrelated pieces of software. This breaks one of the core use 
cases of a software repository:

C1:
- if a user wants some (end-user) software, they install it via the 
software manager, knowing they get a reasonably up-to-date version
- if they hit 'update' when asked to do so, they maintain all their 
software in the 'reasonably up-to-date' state
- beyond that, *they don't have to care*.

Given that, we need mitigation strategies - at a technical or policy 
level - other than containers/VMs, because those are not viable 
solutions for this use case*.

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.

Christopher

*i.e. for most desktop users or anyone for whom computers are tools 
rather than infrastructure, really.
___
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.

[Sérgio Basto]

On Wed, 2019-11-06 at 23:28 -0500, Nico Kadel-Garcia wrote:
> On Wed, Nov 6, 2019 at 1:00 PM Dario Lesca 
> wrote:
> > Il giorno mer, 06/11/2019 alle 09.03 -0500, Nico Kadel-Garcia ha
> > scritto:
> > > > Can the Fedora samba maintainers do that?
> > > > 
> > > > Thank
> > > > 
> > > 
> > > They are very welcome to my work.
> > > 
> > 
> > Then why do not use your samba.spec for build official samba
> > package at
> > least on Fedora?
> 
> Because the last 3 times I tried to start submitting packages
> directly
> to Fedora I found the process very burdensome and frustrating, and
> got
> no meaningful help when I asked. 

I can help you here as I'm a Fedora packager maintainer . 

> Also, it seemed clear that actually
> building Samba with Heimdal Kerberos was unwelcome to Fedora or Red
> Hat. And the last time I spoke with any of the authors of Kerberos
> about the mess, it took them a while to stop laughing about the mess.
> And yes, I know a bunch of the original authors socially, though not
> professionally.

Have you Pull request and BugZilla reports with that information 

> > It already contain the MIT or Heimdal Kerberos flag:
> > 
> > %global with_system_mit_krb5 0
> > 
> > Is sufficient set it to '1' for default packaging and who wants to
> > use
> > heimdal can rebuild it setting this flag to '0' via line command
> > 
> > This is another way to resolve this issue
> > 
> > Thanks
> 
> Well, yes. That's why I publish the suite. I was under the strong
> impression that it wouldn't be welcome due to the announced desire
> "not to support another Kerberos" in Fedora or for Red Hat as a
> company. But since it works, works well, and Samba supports it, I'll
> continue to publish the updates for a while. I admit that my
> packaging
> relies extensively on Rawhide for updates, and I do resync
> occasionally for maximum compatibility.
> 
> If anyone can resolve the Kerberos discrepancies and get full domain
> controller working well for Samba with MIT Kerberos, I'll be happy to
> congratulate them and buy them beer or maybe even dinner. 

That is the (only) way 

> I''m in the
> Boston area, and hey, maybe I even know them.  I admit that I
> anticipate that, with the recent purchase by IBM, that FreeIPA will
> be
> dropped as a non-viable project, which would allow a a switch to
> Heimdal based Kerberos with a future Fedora release. Since FreeIPa's
> creation in 2007, I've not seen a single case where Samba, especially
> Samba in collaboration with Active Directory, wasn't a better choice.
> 
> But I could be wrong. I've only been publishing Samba ports and
> working with it professionally since. 1993? In networks up of to
> 13,000 servers? So what do I know?
> ___
> 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
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

EPEL-8 builds

[Peter Robinson]

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.

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

bibutils change soversion anounce

[Vascom]

Bibutils 6.8 change soversion to 6.8.

I am update it for rawhide, F31, F30.

As I see no one package not require it so I will no rebuild anything else.
___
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: Getting notified on broken deps from updates-testing

[Miro Hrončok]

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

--
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: Orphaned packages looking for new maintainers (incl. wine, dosbox, nextcloud, owncloud)

[Hans de Goede]

Hi,

I will take dynamite. I've filed an ownership request for this here:
https://pagure.io/releng/issue/8975

Regards,

Hans


On 06-11-2019 20:15, Miro Hrončok wrote:

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Request package ownership via releng issues:
https://pagure.io/releng/issues

Full report available at:
https://churchyard.fedorapeople.org/orphans-2019-11-06.txt
grep it for your FAS username and follow the dependency chain.

    Package  (co)maintainers    Status 
Change

FUR orphan 0 weeks ago
WindowMaker orphan 0 weeks ago
WindowMaker-extra   orphan 0 weeks ago
airsnort    orphan 0 weeks ago
apache-mime4j   orphan 2 weeks ago
aterm   orphan 0 weeks ago
base64coder jcapik, mizdebsk, orphan   0 weeks ago
batik   jvanek, mizdebsk, orphan   0 weeks ago
bibus   orphan 2 weeks ago
bubblemon   orphan 0 weeks ago
castor-maven-plugin orphan 5 weeks ago
classmate   lef, orphan    0 weeks ago
cli-parser  lef, orphan    0 weeks ago
diffuse cicku, fab, orphan 4 weeks ago
dillo   aarem, orphan  0 weeks ago
dosbox  fcami, orphan  0 weeks ago
dynamite    orphan 0 weeks ago
eclipse-abrt    orphan, sopotc 1 weeks ago
eclipse-cdt akurtakov, eclipse-sig,    1 weeks ago
     jjohnstn, kdaniel, orphan,
     rgrunber
eclipse-epp-logging orphan, sopotc 1 weeks ago
eclipse-launchbar   eclipse-sig, orphan, sopotc    1 weeks ago
extra166y   orphan 2 weeks ago
fbdesk  orphan 0 weeks ago
felix-osgi-foundation   orphan 2 weeks ago
freealut    jwrdegoede, orphan, pwalter    0 weeks ago
glassfish-gmbal orphan 0 weeks ago
glassfish-management-api    orphan 0 weeks ago
glassfish-pfl   orphan 0 weeks ago
gnu-regexp  dbhole, mizdebsk, orphan   5 weeks ago
grizzly orphan 0 weeks ago
grizzly-npn orphan 0 weeks ago
ht  orphan 0 weeks ago
isight-firmware-tools   jmontleon, orphan  2 weeks ago
jackson-dataformat-xml  dchen, lef, orphan 0 weeks ago
jandex-maven-plugin lef, orphan    0 weeks ago
java-oauth  lef, orphan    0 weeks ago
jboss-connector-1.6-api gil, lef, orphan   0 weeks ago
jboss-jaspi-1.1-api lef, orphan    0 weeks ago
jboss-jsp-2.3-api   orphan 0 weeks ago
jcsp    orphan 2 weeks ago
jersey  dchen, gwei3, orphan   0 weeks ago
js-excanvas nodejs-sig, orphan, rathann,   5 weeks ago
     williamjmorenor
json_diff   orphan 4 weeks ago
lcms    ajax, alexl, caillon, caolanm, 0 weeks ago
     gnome-sig, johnp, mbarnes,
     orphan, rhughes, rstrode, ssp
leafnode    orphan 4 weeks ago
libAfterImage

Re: Getting notified on broken deps from updates-testing

[Fabio Valentini]

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.

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

Re: Modularity: The Official Complaint Thread

[Pierre-Yves Chibon]

On Thu, Nov 07, 2019 at 05:06:33AM +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.

I can understand the feeling if you look only at modularity, but the symbiotic
relationship between Fedora and Red Hat go way beyond just this project, and you
have been in the community for longer than I have, so I know that you know this
:)


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

[Miro Hrončok]

On 05. 11. 19 21:17, Stephen Gallagher wrote:

I'm sure there are other pain points and I encourage you to share
them. Please adhere to the guidelines about objectively measurable
issues, though.


M4. Since modularity started in Fedora, I've observed a pattern. A certain dnf 
behavior is UX unfriendly, weird or arguably buggy. The dnf team refuses to fix 
it with "our hands are tied by modularity spec". Later it takes ages to create 
an ugly workaround or the bugs are not fixed.


Put it in somewhat measurable issue. Since modularity:

 - there is a significantly higher number of dnf usability problems
 - dnf usability bugs take significantly more time to fix
 - dnf usability bugs are CLOSED WONTFIX/CANTFIX significantly more often
 - dnf usability bugs are left open without a fix significantly more often

Note that I haven't done any actual statistic, this is based only on my personal 
experience. Chances are, this was always the case and before modularity I was 
just lucky not to experience this.


This is one of the examples of this:
https://bugzilla.redhat.com/show_bug.cgi?id=1636285

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

[Miro Hrončok]

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.


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

[Alexander Bokovoy]

On ke, 06 marras 2019, Scott Schmit wrote:

On Mon, Nov 04, 2019 at 03:14:34PM +0100, Dario Lesca wrote:

Il giorno lun, 04/11/2019 alle 08.38 -0500, Neal Gompa ha scritto:
> What defines it as experimental?

https://wiki.samba.org/index.php/Running_a_Samba_AD_DC_with_MIT_Kerberos_KDC
> Using MIT Kerberos is still considered experimental.


I'd say you've buried the lede, as the rest at the link is much worse:


Samba 4.7 and later versions have shipped with code to support
building the Samba AD DC using MIT Kerberos. Since the time of the
release a number of issues, *including security issues*, have been
found by real-world use. However sadly the Samba Team has not been
able to resource the resolution of these issues to a standard that we
are happy with, and so Samba 4.9.3, 4.8.7 and 4.7.12 releases mark
this mode more clearly as experimental.

As an experimental feature, *we will not be issuing security patches*
for this feature, including for:
* S4U2Self crash with MIT KDC build


[emphasis mine]  (That said, the linked-to crasher was fixed about 3.5
months after the report.  I have no idea how that compares to typical
response times.)

I find that text worrying.  Of course, all software has the potential
for vulnerabilities, and some software is better quality than other
software in general.  Still, it's not hard to imagine people relying on
the security features in higher risk environments than they might
otherwise because "of course Fedora is using high quality security code"
and/or "it's Samba/MIT Kerberos, of course it's high quality" ... and
then it isn't.

From the wording above, it seems that Samba is no longer as confident as
they used to be that their MIT Kerberos integration is solid (i.e., they
weren't always calling it experimental), so they've (now) made the risks
explicit in their documentation.  Fedora doesn't appear to be passing
that information along (yet).


The statement was made to make sure people who have no idea what various
backends within Samba mean don't create environments that cannot be
realistically supported by upstream right now.

There is ongoing work on making both MIT Kerberos and Samba to work
together properly in Samba AD DC environment. This work continues for
eight years already, sponsored by Red Hat, and shows the level of
complexity that we have to deal with.

To get you a bit of understanding where we are in this area, Isaac
Boukris found last year a number of security issues with Kerberos
implementations in Windows, MIT Kerberos, and Heimdal that basically
made all Active Directory implemenations broken:

- Local privilege escalation on Windows:
 
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-0734

- Unconstrained Kerberos S4U2Self delegation in Heimdal and Samba AD:
 https://www.samba.org/samba/security/CVE-2018-16860.html

- Samba AD DC S4U2Self Crash in MIT Kerberos
 https://www.samba.org/samba/security/CVE-2018-16853.html

- Reachable assertion in MIT Kerberos S4U2Self implementation before version 
1.17
 https://access.redhat.com/security/cve/cve-2018-20217

Isaac also added support for constraint-based resource delegation to MIT
Kerberos this year (https://github.com/krb5/krb5/pull/912) and is
working right now on fixing remaining S4U implementation details to
allow Samba AD DC with MIT Kerberos to be a thing. The latter spans to
both projects. A note: Heimdal implementation misses protocol
compatibility in this area by a long shot and Samba AD DC with Heimdal
does not behave correctly in quite a number of places. It ignores some
of the real checks required by the MS-KILE specification completely.


That's an easy thing to overlook -- I'm willing to assume that the Samba
project didn't send out an all points bulletin to all the distros
warning about it, but does it make sense to reconsider the default?

Maybe not, for all the reasons already stated.  In that case, I'd say
the ethical thing would be to do *something* to make sure that users are
participating in the experiment with full knowledge of the risks.


I believe users have this information already since Fedora 29 release:

https://docs.fedoraproject.org/en-US/fedora/f29/release-notes/sysadmin/File_Servers/#_samba_ad_dc

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
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