Re: Modularity and all the things

[Vít Ondruch]

Dne 06. 11. 19 v 5:21 Randy Barlow napsal(a):
> On Tue, 2019-11-05 at 21:17 -0500, Neal Gompa wrote:
>> This feature of "slotting" multiple EVRs of the same name actually
>> already exists in RPM. DNF currently restricts this to packages that
>> contain one of the following provides:
>> * installonlypkg(kernel)
>> * installonlypkg(kernel-module)
>> * installonlypkg(vm)
>> * multiversion(kernel)
>>
>> It's not terribly difficult to extend this functionality to apply
>> more
>> broadly than kernels and VM images wrapped in RPMs. :)
> That's a good point. I had actually noticed that the kernel was
> "special" in this regard.
>
> Is this hardcoded in dnf? When I grep for "installonly", I see this:
>
> /etc/dnf/dnf.conf:installonly_limit=3
>
> I guess that's why I get 3 kernels, but I'm wondering if I can expand
> that set as a user? Probably not a good idea to mess with ☺


Just FTR:

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

The DNF is completely different today. Anybody wants to propose this
idea again?


Vít


>
> In any case, you are right that we could make it so other packages
> allowed installing more than one of the same name using this, but there
> would need to be awareness of which ones can and can't be
> simultaneously installed, and that's what Gentoo's slot feature
> achieves. For example, we could start calling python simply "python",
> but there would have to be a way to denote that some Python's can and
> can't be parallel installed (you can't parallel install a 3.6.1 and
> 3.6.2, but you *can* parallel install a 3.6.1 and a 3.5.2), and also
> that some other packages cannot be parallel installed (like grep, since
> it occupies /usr/bin/grep). But yeah, it does sound like dnf does have
> some of the code we'd need to do that.






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

Re: Modularity and all the things

[Neal Gompa]

On Tue, Nov 5, 2019 at 11:22 PM Randy Barlow
 wrote:
>
> On Tue, 2019-11-05 at 21:17 -0500, Neal Gompa wrote:
> > This feature of "slotting" multiple EVRs of the same name actually
> > already exists in RPM. DNF currently restricts this to packages that
> > contain one of the following provides:
> > * installonlypkg(kernel)
> > * installonlypkg(kernel-module)
> > * installonlypkg(vm)
> > * multiversion(kernel)
> >
> > It's not terribly difficult to extend this functionality to apply
> > more
> > broadly than kernels and VM images wrapped in RPMs. :)
>
> That's a good point. I had actually noticed that the kernel was
> "special" in this regard.
>
> Is this hardcoded in dnf? When I grep for "installonly", I see this:
>
> /etc/dnf/dnf.conf:installonly_limit=3
>
> I guess that's why I get 3 kernels, but I'm wondering if I can expand
> that set as a user? Probably not a good idea to mess with
>

It is currently hardcoded in three places:
* 
https://github.com/rpm-software-management/libdnf/blob/35291d87e8b075fc556f1a50d144c46add412fbc/libdnf/conf/Const.hpp#L38-L42
* 
https://github.com/rpm-software-management/libdnf/blob/35291d87e8b075fc556f1a50d144c46add412fbc/libdnf/dnf-context.cpp#L912-L932
* 
https://github.com/rpm-software-management/dnf/blob/36705581ce0589176e5a12ffc91a85e0edec4c63/dnf/const.py.in#L30-L34

Changing this back to being configurable from dnf.conf or just making
it match on Provides condition (like multiversion(*) /
installonlypkg(*) ) would allow us to try it with more packages.

> In any case, you are right that we could make it so other packages
> allowed installing more than one of the same name using this, but there
> would need to be awareness of which ones can and can't be
> simultaneously installed, and that's what Gentoo's slot feature
> achieves. For example, we could start calling python simply "python",
> but there would have to be a way to denote that some Python's can and
> can't be parallel installed (you can't parallel install a 3.6.1 and
> 3.6.2, but you *can* parallel install a 3.6.1 and a 3.5.2), and also
> that some other packages cannot be parallel installed (like grep, since
> it occupies /usr/bin/grep). But yeah, it does sound like dnf does have
> some of the code we'd need to do that.

There would definitely need to be some tweaking for that, but it's not
insurmountable.


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

Re: Modularity and all the things

[Vít Ondruch]

Dne 06. 11. 19 v 12:17 Vít Ondruch napsal(a):
> Dne 06. 11. 19 v 5:21 Randy Barlow napsal(a):
>> On Tue, 2019-11-05 at 21:17 -0500, Neal Gompa wrote:
>>> This feature of "slotting" multiple EVRs of the same name actually
>>> already exists in RPM. DNF currently restricts this to packages that
>>> contain one of the following provides:
>>> * installonlypkg(kernel)
>>> * installonlypkg(kernel-module)
>>> * installonlypkg(vm)
>>> * multiversion(kernel)
>>>
>>> It's not terribly difficult to extend this functionality to apply
>>> more
>>> broadly than kernels and VM images wrapped in RPMs. :)
>> That's a good point. I had actually noticed that the kernel was
>> "special" in this regard.
>>
>> Is this hardcoded in dnf? When I grep for "installonly", I see this:
>>
>> /etc/dnf/dnf.conf:installonly_limit=3
>>
>> I guess that's why I get 3 kernels, but I'm wondering if I can expand
>> that set as a user? Probably not a good idea to mess with ☺
>
> Just FTR:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=845247
>
> The DNF is completely different today.


I meant "DNF team" of course.


Vít


>  Anybody wants to propose this
> idea again?
>
>
> Vít
>
>
>> In any case, you are right that we could make it so other packages
>> allowed installing more than one of the same name using this, but there
>> would need to be awareness of which ones can and can't be
>> simultaneously installed, and that's what Gentoo's slot feature
>> achieves. For example, we could start calling python simply "python",
>> but there would have to be a way to denote that some Python's can and
>> can't be parallel installed (you can't parallel install a 3.6.1 and
>> 3.6.2, but you *can* parallel install a 3.6.1 and a 3.5.2), and also
>> that some other packages cannot be parallel installed (like grep, since
>> it occupies /usr/bin/grep). But yeah, it does sound like dnf does have
>> some of the code we'd need to do that.
>
>
>
>
> ___
> 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


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

vagrant can't up rawhide compose

[Pavel Březina]

I'm trying vagrant image of rawhide from [1], however vagrant is unable 
to bring the machine up. It gets always stuck on "==> client: Waiting 
for domain to get an IP address..." step. Other vagrant boxes (Fedora 29 
till Fedora 31) from these cloud composes works well.


I tried to upgrade to latest vagrant upstream version (2.2.6) but that 
did not helped.


[1] 
https://kojipkgs.fedoraproject.org/compose/rawhide/latest-Fedora-Rawhide/compose/Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-Rawhide-20191105.n.0.x86_64.vagrant-libvirt.box

___
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 05. 11. 19 v 16:03 Ben Cotton napsal(a):
> https://fedoraproject.org/wiki/Changes/PythonStaticSpeedup
>
> == Summary ==
> Python 3 traditionally in Fedora was built with a shared library
> libpython3.?.so and the final binary was dynamically linked against
> that shared library. This change is about creating the static library
> and linking the final python3 binary against it, as it provides
> significant performance improvement, up to 27% depending on the
> workload. The static library will not be shipped. The shared library
> will continue to exist in a separate subpackage. In essence, python3
> will no longer depend on libpython.
>
> == Owner ==
> * Name: [[User:Cstratak| Charalampos Stratakis]], [[User:Vstinner|
> Victor Stinner]], [[User:Churchyard| Miro Hrončok]]
> * Email: python-ma...@redhat.com
>
>
> == Detailed Description ==
>
> When we compile the python3 package on Fedora (prior to this change),
> we create the libpython3.?.so shared library and the final python3
> binary (/usr/bin/python3) is dynamically linked against
> it. However by building the libpython3.?.a static library and
> statically linking the final binary against it, we can achieve a
> performance gain of 5% to 27% depending on the workload.


Where are these number coming from? And what is the reason for the
performance hit for dynamically linked Python?


Vít


>  Link time
> optimizations and profile guided optimizations also have a greater
> impact when python3 is linked statically.
>
> Since Python 3.8,
> [https://docs.python.org/3.8/whatsnew/3.8.html#debug-build-uses-the-same-abi-as-release-build
> C extensions must no longer be linked to libpython by default].
> Applications embedding Python now need to utilize the --embed flag for
> python3-config to be linked to libpython. During the
> [[Changes/Python3.8|Python 3.8 upgrade and rebuilds]] we've uncovered
> various cases of packages linking to libpython implicitly through
> various hacks within their buildsystems and fixed as many as possible.
> However, there are legitimate reasons to link an application to
> libpython and for those cases libpython should be provided so
> applications that embed Python can continue to do so.
>
> This mirrors the Debian/Ubuntu way of building Python, where they
> offer a statically linked binary and an additional libpython
> subpackage. The libpython subpackage will be created and python3-devel
> will depend on it, so packages that embed Python will keep working.
>
> The change was first done in Debian and Ubuntu years ago, followed by
> Python 3.8. manylinux1 and manylinux2010 ABI don't link C extensions
> to libpython either (to support Debian/Ubuntu).
>
> By applying this change, libpython's namespace will be separated from
> Python's, so '''C extension which are still linked to libpython'''
> might experience side effects or break.
>
> There is one exception for C extensions. If an application is linked
> to libpython in order to embed Python, C extensions used only within
> this application can continue to be linked to libpython.
>
> Currently there is no upstream option to build the static library, as
> well as the shared one and statically link the final binary to it, so
> we have to rely on a downstream patch to achieve it. We plan to work
> with upstream to incorporate the changes there as well.
>
> Before the change, python3.8 is dynamically linked to libpython3.8:
>
> 
> +---+
> |   |
> |   | ++
> |  libpython3.8.so  <-+ /usr/bin/python3.8 |
> |   | ++
> |   |
> +---+
> 
>
> After the change, python3.8 is statically linked to libpython3.8:
>
> 
>   +---+
>   |   |
>   |   /usr/bin/python3.8  |
>   |   |
> +---+ | +---+ |
> |   | | |   | |
> |   | | |   | |
> |  libpython3.8.so  | | |  libpython3.8.a   | |
> |   | | |   | |
> |   | | |   | |
> +---+ | +---+ |
>   +---+
> 
>
> As a negative side effect, when both libpython3.8.so and
> /usr/bin/python3.8 are installed, the filesystem footprint will be
> slightly increased (libpython3.8.so on Python 3.8.0, x86_64 is ~3.4M).
> OTOH only a very small amount of packages will depend on
> libpython3.8.so.
>
> == Benefit to Fedora ==
> Python's performance will increase significantly depending on the
> workload. Since many core components of the OS also depend on Python
> this could lead to an increase in their performance as well, however
> individual benchmarks 

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

[Jan Kratochvil]

On Wed, 06 Nov 2019 11:49:18 +0100, Vít Ondruch wrote:
> > we can achieve a
> > performance gain of 5% to 27% depending on the workload.
> 
> Where are these number coming from? And what is the reason for the
> performance hit for dynamically linked Python?

Yes, it looks suspicious. -fPIC was a performance hit for i686 but it no
longer affects x86_64.


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

[Alex Scheel]

- Original Message -
> From: "Ralf Corsepius" 
> To: devel@lists.fedoraproject.org
> Sent: Wednesday, November 6, 2019 3:32:03 AM
> Subject: Re: Modularity: The Official Complaint Thread
> 
> On 11/5/19 9:41 PM, Alex Scheel wrote:
> 
> > IMO, without a resolution in Fedora we'll never get one in RHEL.
> 
> And? Why should Fedora care about RHEL?

Why? Because Modularity was foisted the wrong direction.

In an ideal world, Modularity would've been proposed to Fedora,
it would've been discussed by the community, improved, perfected,
and _then_ brought into the RHEL fold only when stable! Fedora
would've _driven_ the innovation, rather than having to keep up
with whatever RHEL decided to do, being careful not to break
anything.

We don't live in an ideal world and deadlines, initial rejection
by Fedora, and issues implementing Modularity forced at least _some_
of it to go the other direction, RHEL -> Fedora.

So now we're stuck trying to improve Modularity in Fedora, without
stepping on any RHEL toes, and knowing full well that if the
community rejects Modularity in Fedora (again!), we're stuck supporting
it in RHEL through RHEL 8 (and, likely into RHEL 9). And I think that
worries some people, hence the attempt to influence discussions, name
calling,  Others however, want Fedora to remain fully independent
of RHEL, and thus have asked that _failure_ be an option explicitly
on the table. 

I don't work on Modularity though. I only have to use it. I'm, at
best, agnostic as to whether or not it survives in Fedora. But, I
do have to use it in RHEL. There, I'd far rather see it improve
(and, have a chance to influence improvements to issues I've directly
hit NOW rather than later). I'd hate to see it stagnate in its
current state.



> I for one consider RHEL not to be its partner, but it to be an
> initiative to gradually push Fedora out of this planet.

I think that's going a little far. They cater to two different
audiences: hackers or business people. The former will put up with
cutting-edge software and whatever documentation is freely available.
The latter will pay big money for support and consulting to make
sure nothing breaks, and to fix it if it does. 

I'd argue that if RHEL wanted to push anyone out, Fedora would be
a stupid target. RHEL doesn't really compete with Fedora. Target CentOS
first! Its RHEL, but free!

But we don't. Red Hat stepped _up_ its participation in CentOS. We
pay people to work on CentOS full-time, so it keeps going. I think
that's the _opposite_ of trying to push CentOS out of this planet.
Same goes for Fedora. And with RHEL 9, we've announced that we view
Fedora as the _upstream_ for RHEL. More collaboration, not less!

https://fedoramagazine.org/fedora-and-centos-stream/


I'd ask you to consider that we aren't Microsoft of the '90s... We
are human and make mistakes from time to time, but we aren't evil.
We're an Open Source company, and try our best to embody that. We
try our best to work _with_ the community, not against it. That's
why all of these modularity discussions _have_ been in the open and
happening right here, in Fedora. Not on some private mailing list
inside Red Hat. 


At any rate, Pierre's points are also valid.

- Alex

> 
> 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
> 
___
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 and all the things

[Josh Boyer]

On Tue, Nov 5, 2019 at 4:35 PM Fabio Valentini  wrote:
>
> On Tue, Nov 5, 2019 at 8:15 PM Matthew Miller  
> wrote:
> >
> > On Tue, Nov 05, 2019 at 01:08:23PM -0500, Neal Gompa wrote:
> > > I think I mentioned that it would be possible, as OpenPKG actually
> > > worked this way.
> > >
> > > The key for this would be improving the user-experience with
> > > interacting with source RPMs and spec files with DNF. We've optimized
> > > *heavily* for remote builds, but a good chunk of how Gentoo's
> > > mechanism works is built around supporting local permutations. We just
> > > don't have that fleshed out yet.
> >
> > Well, exactly. This is what I meant with my short "who is going to do that
> > work?" comment. Gentoo's solution is not a drop-in thing for Fedora and
> > would require changes to RPM, DNF, and the *significant* work of figuring
> > out what all this would mean in a binary-focused distribution. We'd
> > certainly need a whole *new* MBS equivalent, and there's surely a ton of
> > "unknown unknowns" lurking as well.
> >
> > And then all of that would get us to... sort of where we are now? Basically
> > the same thing as with Modularity's "virtual repositories" approach with
> > different tradeoffs?
> >
> > If someone thinks that my skepticism is wrong and that the Modularity team
> > is on the complete wrong path, I have no objection to anyone who wants to
> > work on something new solution, either as a prototype or a more detailed
> > proposal. Awesome! If it gets to the point where it's a viable alternative,
> > we can weigh those options. But the team in Fedora actually working on
> > Modularity today includes some pretty smart, very invested Fedora people and
> > I don't feel bad at all about standing up for their wanting to continue to
> > refine the path they've chosen and are working on.
> >
> > To me this is just like the Flatpak and Snap thing — both have some
> > strengths and weaknesses. I'm absolutely supportive of the effort of the
> > Workstation team (and Red Hat's Desktop team!) to drive that work in Fedora.
> > I happen to personally (and professionally) think that's good for Fedora.
> > But I'm _also_ happy to make room for you and whoever else to work on doing
> > something similar with Snap.
> >
> > If someone were to come by and say "I don't understand why you're doing all
> > this, when it's been solved by AppImage since 2004", I'd say the same thing
> > I'm telling Randy: you're welcome to work on that, but it's rude to tell the
> > people who are invested in building something different that _they're_ the
> > problem.
> >
> > If that's demoralizing... well, I don't know what to to tell you. I want to
> > support people doing things and exploring and contributing.
>
> That's all well and good, but you seem to be forgetting that people
> are actually getting *paid* to work on modularity for fedora.
> Any proposal for an alternative, which apparently needs to arrive at
> least at MVP / proof-of-concept quality before it is even *considered*
> as an alternative without getting called "trolling", can likely only
> be worked on in somebody's spare time. I don't think that's a fair
> requirement, and "exploring and contributing" will stay limited to RH
> employees if that's the case.

What you call unfair, I call open source winning in the industry.
Does it create an imbalance between funded vs. unfunded work?  Yes.
That is the reality of the software landscape today though, and I
think it's a net good thing even if it is somewhat departed from what
people consider open source "roots".

I would suggest people wanting to deliver competing solutions be vocal
about their intentions and provide frequent updates and comparisons.
It's not trolling if they're actively working on it, despite the
development speed.  They might not be able to produce as much code as
funded development, but often it's the ideas that matter.
Alternatively, pitch in those ideas and critiques to the project
that's being worked on and shape the direction that way.

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

[Jakub Jelinek]

On Wed, Nov 06, 2019 at 12:12:54PM +0100, Jan Kratochvil wrote:
> On Wed, 06 Nov 2019 11:49:18 +0100, Vít Ondruch wrote:
> > > we can achieve a
> > > performance gain of 5% to 27% depending on the workload.
> > 
> > Where are these number coming from? And what is the reason for the
> > performance hit for dynamically linked Python?
> 
> Yes, it looks suspicious. -fPIC was a performance hit for i686 but it no
> longer affects x86_64.

No.  It is a smaller performance hit on x86_64, no need to compute the PIC
base register at the start of functions and waste a register for it,
but still significant (mainly that indirect addressing is used for anything
not know to bind to variables in the current TU, while otherwise direct
addressing could be used).

Jakub
___
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 and all the things

[Kevin Kofler]

Randy Barlow wrote:
> *Kofler - sorry for misspelling your name Kevin.

Oh, I'm used to that. :-) Even in Vienna, where I live and where the name is 
relatively common, it keeps getting misspelled. (For the record, the name is 
originally from the Tyrol area. My father was from Alto Adige / South Tyrol 
in Italy. The name Kofler is common both in the Austrian Tyrol and in Alto 
Adige / South Tyrol.)

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

[Dario Lesca]

Il giorno mer, 06/11/2019 alle 08.52 +0100, Franta Hanzlík ha scritto:
> If I can speak for myself and for the Linux people I know, nobody
> needs a FreeIPA, and many need a Samba AD DC. And of course they want
> a stable solution if possible.
> 
> The current situation leads to either choosing a different
> distribution
> (the simplest solution), or compiling a Samba with Heimdal Kerberos
> themselves; perhaps someone chooses a commercial solution also (which
> is of course with Heimdal Kerberos).
> 
> I am not saying that the FreeIPA is useless or has no users, but in
> my
> opinion the chosen attitude to the Samba AD DC was perhaps the worst
> possible and IMO at least frustrated a lot of users (including me).
> 
> For me, thanks to Nico Kadel-Garcia, for his work to make stable as
> possible Samba AD DC in Fedora/Centos.

Thank Franta, this is exactly also my opinion, and me too thank to
Kadel-Garcia for his work.

Waiting for MIT kerberos to become stable and supported from samba
team, a simple solution is insert into official samba.spec, a flag for
easily rebuild it with heimdal kerberos, without substitute or modify
the .spec file.

Something like this:
 
$ rpmbuild --rebuild --with heimdal  samba-.src.rpm

Can the Fedora samba maintainers do that?

Thank

-- 
Dario Lesca
(inviato dal mio Linux Fedora 31 Workstation)
___
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: Use immutable CRAN URLs

[Iñaki Ucar]

Hi,

I had every intention of pushing this forward, but I never found the
time. Sorry for that. It would still be great to have these.

Iñaki


On Wed, 6 Nov 2019 at 10:11, Elliott Sales de Andrade
 wrote:
>
> Hello,
>
> On Thu, 1 Nov 2018 at 20:45, Jason L Tibbitts III  wrote:
> >
> > Since I actually had an existing pagure repo for random RPM macro
> > experiments, I just dropped the R macro stuff there.
> >
> > https://pagure.io/misc-rpm-macros
> > https://pagure.io/misc-rpm-macros/blob/master/f/macros.R-extra
> >
> > I still have some ideas to implement but feel free to test what's there.
> > To use this, you just need to check out the repo and then add a symlink
> > to macros.R-extra in /usr/lib/rpm/macros.d.
> >
> >  - J<
>
> This is a rather old email thread that I'm resurrecting, but I'm
> wondering what the state of those macros is now?
>
> We now have a place in upstream rpm where we could store these macros:
> https://github.com/rpm-software-management/R-rpm-macros
> It is currently used for automated dependency generators only.
>
> --
> Elliott



-- 
Iñaki Úcar
___
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

[HEADS-UP] Excluding unavailable Suggests from R packages

[Elliott Sales de Andrade]

Hello,

As you may or may not know, due to this F31 Change [1], all R packages
now have Suggests for all packages in their metadata automatically. In
the discussion with FPC and Legal [2], it has been determined that the
Suggests cannot apply to non-existent packages.

I have already fixed my packages, but since it has been some time
since the Change was implemented, I'm sending a heads-up that I plan
to exclude unavailable Suggests from the remaining packages listed at
[3] and below. I will be adding a %global __suggests_exclude in
accordance with the current R packaging guidelines [4]. If you wish to
implement this some other way, please let me know so I won't duplicate
your work. I will do this in approximately one week's time.

I have bcc'd the affected package maintainers, so apologies if you
receive this message multiple times.

Maintainers by package:
R-DBIspot
R-DelayedArray   spot
R-GenomeInfoDb   spot
R-GenomicAlignments  spot
R-R6 spot
R-RSQLitespot
R-Rcpp   ellert
R-Rsamtools  spot
R-S4Vectors  spot
R-SummarizedExperiment spot
R-XVectorspot
R-biomaRtspot
R-blob   spot
R-carjamatos
R-littlerellert
R-lmtest jamatos
R-memoisespot
R-msmdenisarnaud
R-multcomp   jamatos
R-rtracklayerspot
R-snow   spot
R-systemfit  jamatos
R-testthat   spot
R-waveslim   jamatos
R-zoojamatos

Packages by maintainer:
denisarnaud R-msm
ellert R-Rcpp R-littler
jamatosR-car R-lmtest R-multcomp R-systemfit R-waveslim R-zoo
spot   R-DBI R-DelayedArray R-GenomeInfoDb R-GenomicAlignments
R-R6 R-RSQLite R-Rsamtools R-S4Vectors R-SummarizedExperiment
R-XVector R-biomaRt R-blob R-memoise R-rtracklayer R-snow R-testthat

[1] https://fedoraproject.org/wiki/Changes/Automatic_R_runtime_dependencies
[2] https://pagure.io/packaging-committee/issue/914
[3] https://pagure.io/packaging-committee/issue/914#comment-608700
[4] 
https://docs.fedoraproject.org/en-US/packaging-guidelines/R/#_automatically_generated_dependencies
-- 
Elliott
___
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: Use immutable CRAN URLs

[Elliott Sales de Andrade]

Hello,

On Thu, 1 Nov 2018 at 20:45, Jason L Tibbitts III  wrote:
>
> Since I actually had an existing pagure repo for random RPM macro
> experiments, I just dropped the R macro stuff there.
>
> https://pagure.io/misc-rpm-macros
> https://pagure.io/misc-rpm-macros/blob/master/f/macros.R-extra
>
> I still have some ideas to implement but feel free to test what's there.
> To use this, you just need to check out the repo and then add a symlink
> to macros.R-extra in /usr/lib/rpm/macros.d.
>
>  - J<

This is a rather old email thread that I'm resurrecting, but I'm
wondering what the state of those macros is now?

We now have a place in upstream rpm where we could store these macros:
https://github.com/rpm-software-management/R-rpm-macros
It is currently used for automated dependency generators only.

-- 
Elliott
___
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: Trouble with install ordering and SELinux config

[Lukas Vrabec]

On 11/5/19 11:21 PM, Dridi Boukelmoune wrote:
>> Hi,
>>
>> It looks like some leftover from the past. I don't really see why it
>> should be there.
>>
>> This commit removes that:
>>
>> https://github.com/fedora-selinux/selinux-policy-macros/commit/5f366657da0c7c67f2448be03620581437c2dfbb
>>
>> Fixing it also in Rawhide and F31.
> 
> Thanks a lot! Can it also happen for epel7 and 8?
> 
> Pretty please :)
>


Please open bugzilla ticket.

THanks,
Lukas.

> Dridi
> 


-- 
Lukas Vrabec
SELinux Evangelist,
Senior Software Engineer, Security Technologies
Red Hat, Inc.



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

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

[Alexander Bokovoy]

On ke, 06 marras 2019, Miro Hrončok wrote:

On 06. 11. 19 0:26, Michael Cronenworth wrote:

On 11/5/19 4:59 PM, Kevin Kofler wrote:

… and Calamares …


... and Domoticz (Fedora), and Kodi (RPMFusion)...

Will this be as simple as a BR change in the spec or will 
application patches be necessary?



Not for most cases. See this list:


Python extension modules that currently are unnecessary linked to libpython

- changes to cmake/autotools are needed, a sed in spec might do
- if not changed, still works, but drags in the extra 3.4 MB (shared)


Non-extension software embedding Python and linking to libpython

- no changes necessary at all
- but drags in the extra 3.4 MB (shared)


Python extension modules embedding Python and linking to libpython

- needs to be evaluated case by case
- changes to cmake/autotools are needed
- changes in code might be necessary as well
- if not changed, might misbehave
- Python Maint will provide help if asked for


Do you have a list of affected packages?

Samba (and thus SSSD and FreeIPA) is affected. It is pretty fundamental
that Samba modules link to libpython and I think it was designed so by
you guys (Python team at Red Hat) when we ported Samba bindings to Python3.

# find /usr/lib64/python3.7/site-packages/samba -name '*.so' | xargs -n1 -I '{}' sh -c "ldd 
{} | egrep -q libpython && echo 'LINKED: {}' "
LINKED: 
/usr/lib64/python3.7/site-packages/samba/_glue.cpython-37m-x86_64-linux-gnu.so
LINKED: 
/usr/lib64/python3.7/site-packages/samba/_ldb.cpython-37m-x86_64-linux-gnu.so
LINKED: 
/usr/lib64/python3.7/site-packages/samba/auth.cpython-37m-x86_64-linux-gnu.so
LINKED: 
/usr/lib64/python3.7/site-packages/samba/werror.cpython-37m-x86_64-linux-gnu.so
LINKED: 
/usr/lib64/python3.7/site-packages/samba/credentials.cpython-37m-x86_64-linux-gnu.so
LINKED: 
/usr/lib64/python3.7/site-packages/samba/crypto.cpython-37m-x86_64-linux-gnu.so
LINKED: 
/usr/lib64/python3.7/site-packages/samba/dcerpc/winbind.cpython-37m-x86_64-linux-gnu.so
LINKED: 
/usr/lib64/python3.7/site-packages/samba/dcerpc/atsvc.cpython-37m-x86_64-linux-gnu.so
LINKED: 
/usr/lib64/python3.7/site-packages/samba/dcerpc/windows_event_ids.cpython-37m-x86_64-linux-gnu.so
LINKED: 
/usr/lib64/python3.7/site-packages/samba/dcerpc/auth.cpython-37m-x86_64-linux-gnu.so
LINKED: 
/usr/lib64/python3.7/site-packages/samba/dcerpc/winreg.cpython-37m-x86_64-linux-gnu.so
LINKED: 
/usr/lib64/python3.7/site-packages/samba/dcerpc/base.cpython-37m-x86_64-linux-gnu.so
LINKED: 
/usr/lib64/python3.7/site-packages/samba/dcerpc/winspool.cpython-37m-x86_64-linux-gnu.so
LINKED: 
/usr/lib64/python3.7/site-packages/samba/dcerpc/dcerpc.cpython-37m-x86_64-linux-gnu.so
LINKED: 
/usr/lib64/python3.7/site-packages/samba/dcerpc/dfs.cpython-37m-x86_64-linux-gnu.so
LINKED: 
/usr/lib64/python3.7/site-packages/samba/dcerpc/dns.cpython-37m-x86_64-linux-gnu.so
LINKED: 
/usr/lib64/python3.7/site-packages/samba/dcerpc/dnsp.cpython-37m-x86_64-linux-gnu.so
LINKED: 
/usr/lib64/python3.7/site-packages/samba/dcerpc/drsblobs.cpython-37m-x86_64-linux-gnu.so
LINKED: 
/usr/lib64/python3.7/site-packages/samba/dcerpc/drsuapi.cpython-37m-x86_64-linux-gnu.so
LINKED: 
/usr/lib64/python3.7/site-packages/samba/dcerpc/echo.cpython-37m-x86_64-linux-gnu.so
LINKED: 
/usr/lib64/python3.7/site-packages/samba/dcerpc/epmapper.cpython-37m-x86_64-linux-gnu.so
LINKED: 
/usr/lib64/python3.7/site-packages/samba/dcerpc/idmap.cpython-37m-x86_64-linux-gnu.so
LINKED: 
/usr/lib64/python3.7/site-packages/samba/dcerpc/initshutdown.cpython-37m-x86_64-linux-gnu.so
LINKED: 
/usr/lib64/python3.7/site-packages/samba/dcerpc/irpc.cpython-37m-x86_64-linux-gnu.so
LINKED: 
/usr/lib64/python3.7/site-packages/samba/dcerpc/krb5pac.cpython-37m-x86_64-linux-gnu.so
LINKED: 
/usr/lib64/python3.7/site-packages/samba/dcerpc/lsa.cpython-37m-x86_64-linux-gnu.so
LINKED: 
/usr/lib64/python3.7/site-packages/samba/dcerpc/messaging.cpython-37m-x86_64-linux-gnu.so
LINKED: 
/usr/lib64/python3.7/site-packages/samba/dcerpc/mgmt.cpython-37m-x86_64-linux-gnu.so
LINKED: 
/usr/lib64/python3.7/site-packages/samba/dcerpc/misc.cpython-37m-x86_64-linux-gnu.so
LINKED: 
/usr/lib64/python3.7/site-packages/samba/dcerpc/nbt.cpython-37m-x86_64-linux-gnu.so
LINKED: 
/usr/lib64/python3.7/site-packages/samba/dcerpc/netlogon.cpython-37m-x86_64-linux-gnu.so
LINKED: 
/usr/lib64/python3.7/site-packages/samba/dcerpc/ntlmssp.cpython-37m-x86_64-linux-gnu.so
LINKED: 
/usr/lib64/python3.7/site-packages/samba/dcerpc/preg.cpython-37m-x86_64-linux-gnu.so
LINKED: 
/usr/lib64/python3.7/site-packages/samba/dcerpc/samr.cpython-37m-x86_64-linux-gnu.so
LINKED: 
/usr/lib64/python3.7/site-packages/samba/dcerpc/security.cpython-37m-x86_64-linux-gnu.so
LINKED: 
/usr/lib64/python3.7/site-packages/samba/dcerpc/server_id.cpython-37m-x86_64-linux-gnu.so
LINKED: 
/usr/lib64/python3.7/site-packages/samba/dcerpc/smb_acl.cpython-37m-x86_64-linux-gnu.so
LINKED: 
/usr/lib64/python3.7/site-packages/samba/dcerpc/spoolss.cpython-37m-x86_64-linux-gnu.so
LINKED: 

Re: Modularity: The Official Complaint Thread

[Ralf Corsepius]

On 11/5/19 9:41 PM, Alex Scheel wrote:


IMO, without a resolution in Fedora we'll never get one in RHEL.


And? Why should Fedora care about RHEL?

I for one consider RHEL not to be its partner, but it to be an 
initiative to gradually push Fedora out of this planet.


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

[Bug 1768957] Add perl-XML-NamespaceFactory to EPEL8

[bugzilla]

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



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

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

Re: Modularity: The Official Complaint Thread

[Pierre-Yves Chibon]

On Wed, Nov 06, 2019 at 09:32:03AM +0100, Ralf Corsepius wrote:
> On 11/5/19 9:41 PM, Alex Scheel wrote:
> 
> > IMO, without a resolution in Fedora we'll never get one in RHEL.
> 
> And? Why should Fedora care about RHEL?

Because Fedora and Red Hat symbiotic.
I think this has been said at a few flock and other conferences over the years,
a quick search leads me to:
https://www.youtube.com/watch?v=hb3zTQMJggo flock 2015
https://www.youtube.com/watch?v=gJqoH4iDj2Y flock 2017
https://www.youtube.com/watch?v=utQts81V8mA devconf 2016

But it is also on redhat.com:
https://www.redhat.com/en/technologies/linux-platforms/articles/relationship-between-fedora-and-rhel
Let me quote it here:
"""
Red Hat Enterprise Linux and Fedora enjoy a mutually beneficial relationship
that ensures rapid innovation. Fedora benefits from the sponsorship and feedback
from Red Hat. In turn, Red Hat can bring leading-edge innovation to the broader
community for collaboration, enabling a rapid maturation of the technology.
"""

Symbiotic is, I think, the best way to describe the Red Hat/Fedora relationship.


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

[François Cami]

On Wed, Nov 6, 2019 at 10:30 PM Gwyn Ciesla  wrote:
>
> By all means, take them. I just don't want them to go away. :)

Thanks! We share the same concerns (no surprise) there :)

François

> --
> Gwyn Ciesla
> she/her/hers
> 
> in your fear, seek only peace
> in your fear, seek only love
> -d. bowie
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> On Wednesday, November 6, 2019 3:28 PM, François Cami  
> wrote:
>
> > On Wed, Nov 6, 2019 at 8:48 PM Gwyn Ciesla via devel
> > devel@lists.fedoraproject.org wrote:
> >
>
> > > I'll take openal-soft, pdfbox, freealut, python-httplib2, and dosbox. 
> > > FAS:limb
> >
>
> > Heh, I wanted to take openal-soft and dosbox as I've been the de-facto
> > maintainer for some time.
> > FAS: fcami
> > https://pagure.io/releng/issue/8972
> >
>
> > Gwyn, whatever works for you :)
> >
>
> > François
> >
>
> > > --
> > > Gwyn Ciesla
> > > she/her/hers
> > >
>
> > > 
> > >
>
> > > in your fear, seek only peace
> > > in your fear, seek only love
> > > -d. bowie
> > > Sent with ProtonMail Secure Email.
> > > ‐‐‐ Original Message ‐‐‐
> > > On Wednesday, November 6, 2019 1:15 PM, Miro Hrončok mhron...@redhat.com 
> > > 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
> > > > 

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

[Gwyn Ciesla via devel]

I'll take openal-soft, pdfbox, freealut, python-httplib2, and dosbox. FAS:limb


-- 
Gwyn Ciesla
she/her/hers
 
in your fear, seek only peace 
in your fear, seek only love
-d. bowie

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Wednesday, November 6, 2019 1:15 PM, 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 ellert, orphan 0 weeks ago
> libdockapp orphan 0 weeks ago
> libetpan orphan, simo 0 weeks ago
> libfixposix orphan 5 weeks ago
> libktorrent kde-sig, liquidat, nucleo, 2 weeks ago
> orphan, rdieter, tuxbrewr
> libmimedir orphan 0 weeks ago
> libnxml orphan 0 weeks ago
> libodb-boost daveisfera, orphan 4 weeks ago
> libodb-qt daveisfera, orphan 4 weeks ago
> libopensync-plugin-evolution2 mcrha, orphan 0 weeks ago
> libopensync-plugin-file orphan 0 weeks ago
> libopensync-plugin-gpe orphan 0 weeks ago
> libopensync-plugin-moto orphan 0 weeks ago
> libopensync-plugin-opie orphan 0 weeks ago
> libopensync-plugin-synce orphan 0 weeks ago
> libpolyxmass orphan 0 weeks ago
> libpqxx daveisfera, orphan, rdieter 0 weeks ago
> libsynce orphan 0 weeks ago
> libutempter alexl, caillon, caolanm, gnome- 0 weeks ago
> sig, johnp, mbarnes, mlichvar,
> orphan, rhughes, rstrode,
> tkorbar
> menulibre orphan 3 weeks ago
> mimepull java-sig, lef, orphan 0 weeks ago
> 

Unretiring stringtemplate4

[Jerry James]

I somehow overlooked the fact that stringtemplate4 was going to be
retired due to having been orphaned.  I need it for antlr3, which I
need because the cvc4 project still hasn't migrated to antlr4 (argh!).
I have filed a ticket with releng asking for it to be unretired:

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

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

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

[Robbie Harwood]

Miro Hrončok  writes:

> 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.
>
> rxvtorphan 0 weeks ago

If no one adopts rxvt, I'm happy to provide compat symlinks and such in
rxvt-unicode.

Thanks,
--Robbie


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

[Kevin Fenzi]

On Wed, Nov 06, 2019 at 11:56:13AM -0600, 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.

On the one hand, thats great and good. On the other hand, all your DoH
is going to a single provider, bypassing everything else. 

In any case, I will note here that firefox in Fedora is not going to
enable DoH like upstream firefox. I don't know about chromium. 

I think for DoH to really be useful, it needs to be in widespread use in
all the various providers/ISPs. Hopefully that happens. 

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

[Marius Schwarz]

Am 06.11.19 um 21:59 schrieb Kevin Fenzi:
>
> In any case, I will note here that firefox in Fedora is not going to
> enable DoH like upstream firefox. I don't know about chromium. 
>
>
> kevin

That's good news, as it takes about half an hour to make ff privacy
conform again. Each step less helps.

Best regards,
Marius
___
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)

[François Cami]

On Wed, Nov 6, 2019 at 8:48 PM Gwyn Ciesla via devel
 wrote:
>
> I'll take openal-soft, pdfbox, freealut, python-httplib2, and dosbox. FAS:limb

Heh, I wanted to take openal-soft and dosbox as I've been the de-facto
maintainer for some time.
FAS: fcami
https://pagure.io/releng/issue/8972

Gwyn, whatever works for you :)

François


>
> --
> Gwyn Ciesla
> she/her/hers
> 
> in your fear, seek only peace
> in your fear, seek only love
> -d. bowie
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> On Wednesday, November 6, 2019 1:15 PM, 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 ellert, orphan 0 weeks ago
> > libdockapp orphan 0 weeks ago
> > libetpan orphan, simo 0 weeks ago
> > libfixposix orphan 5 weeks ago
> > libktorrent kde-sig, liquidat, nucleo, 2 weeks ago
> > orphan, rdieter, tuxbrewr
> > libmimedir orphan 0 weeks ago
> > libnxml orphan 0 weeks ago
> > libodb-boost daveisfera, orphan 4 weeks ago
> > libodb-qt daveisfera, orphan 4 weeks ago
> > libopensync-plugin-evolution2 mcrha, orphan 0 weeks ago
> > libopensync-plugin-file orphan 0 weeks ago
> > libopensync-plugin-gpe orphan 0 weeks ago
> > 

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

[Miro Hrončok]

On 06. 11. 19 20:41, Gwyn Ciesla via devel wrote:

I'll take openal-soft, pdfbox, freealut, python-httplib2, and dosbox. FAS:limb


Thanks for the quick response.

BTW For example python-httplib2 has plenty active co-maintainers to I suspect 
they would take it as well.


It was recently orphaned via https://pagure.io/fesco/issue/2253

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

[Gwyn Ciesla via devel]

Ok. :)  And I'll take wine if absolutely no one else will, but as a last 
resort. :)


-- 
Gwyn Ciesla
she/her/hers
 
in your fear, seek only peace 
in your fear, seek only love
-d. bowie

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Wednesday, November 6, 2019 1:56 PM, Miro Hrončok  
wrote:

> On 06. 11. 19 20:41, Gwyn Ciesla via devel wrote:
> 

> > I'll take openal-soft, pdfbox, freealut, python-httplib2, and dosbox. 
> > FAS:limb
> 

> Thanks for the quick response.
> 

> BTW For example python-httplib2 has plenty active co-maintainers to I suspect
> they would take it as well.
> 

> It was recently orphaned via https://pagure.io/fesco/issue/2253
> 

> -
> 

> 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



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

Re: Encrypted DNS in Fedora

[Petr Mensik]

Hi Marius,

I maintain BIND and some similar stuff. More or less, there is already 
implementation quite similar to what you have described. Already in 
Fedora: stubby [1]. It has central list of several resolvers and uses 
them in round-robin fashion. Does not make specific order.


However, the most close solution to what is required in coordination 
with DHCP is IMO dnssec-trigger. It has very complicated design 
unfortunately.


Regards,
Petr

1. https://github.com/getdnsapi/stubby

On 11/5/19 3:07 PM, Marius Schwarz wrote:

Am 05.11.19 um 14:21 schrieb Florian Weimer:



ahm.. in which way, does the use of encryption, make a sourcelist for
dns names to ask, obsolete?

Names or servers?

"names of domainnameservers"


nscd i.e. uses resolv.conf as source for the round robin server list.

With encryption, the server address will always be 127.0.0.1 (or
potentially in the future, a UNIX domain socket) because pretty much all
the current DNS client software does not support encryption.  Running a
small local cache has other benefits as well, such as caching server
reachability information.


running a local DNS-Cache does not make so much sense as you may think.

besides the obvious reasons like short daytime usage with poweroff at
the end,
you will run into the same kind of problems, the windows local dnscache had:

It's even harder to debug customers problems, as more caches are involved.

Countless days i had to let users flush their local dns cache, to ensure
they don't connect to something outdated.

DNS is so vital to all services, that you want to have something easy to
maintain and debug, unlike NetworkManager,
which enslaves all users to the default dns names, that came via dhcp.
Last time i checked, it does not support
round robin to increase privacy. NSCD does, and if NM lets it, it's
working good. (had it running)

If someone wants to improve privacy, some rules apply:

a) you don't ask the same server for all your questions ( Round Robin
with thousands of dnscaches world wide)
b) you build a chain of trust ( DNSSEC )
c) the entire chain encrypts the traffic

It would be ok, to have a local resolver handle this for all apps and it
mimics an unencrypted ns on 127.0.0.1:53 .

But the main problem with a+b+c is, it takes a sh*tload of overhead to a
real simple thing AND as with browsers,
has absolutely no value, because the browser will tell anyone between
himself and the target, what he is connecting to.
(see other posting).

Most people won't even gain privacy protection out of it, as outbound
dns is blocked except for the ISPs dns,
the cable/dsl box they use will just send them two dns servers, not
thousands to choose from and
in the end, the browser will give them away anyway.

 From my POV, which supports the DoT as it's a good idea, "why protecting
something, that the last device sabotages anyway?"

Ok, there are more than webpages, but most used services like mail pop
imap, open one connection to a known targetport,
not hard to guess what it is and where it is.  BTW, those clients do 1
dns resolve per day, they won't profit from a local cache ;)

And even if the browser would not give the dn away in SNI or Host: , it
does not make things better, as you can simply ask the internet, which
websites are hosted on a specific ip, and you get a long list of names.
Tracking a users connections makes it always possible to build profiles,
maybe not as precise as with dns data, but good enough.

My conclusion:

DoT and DoH, if not done via a browser, and not done via one single
server, are acceptable and a valid goal for a change inside Fedora,
but they won't help in privacy protection. What is needed to reach this
special goal, takes more than Fedora or Red Hat can provide.

I personally favor DoT as it would make use of the millions of dns
server available on the net. DoH is too centralized to implement for now.


best regards,
Marius


___
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



--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973
___
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 and all the things

[Przemek Klosowski via devel]

On 11/5/19 7:18 PM, Kevin Kofler wrote:

"name mangling": Why is this a problem? First of all, it is not mangling, it
is suffixing. The original name is retained unchanged and nothing is
prepended to it, only appended. And, e.g., Qt 3, 4, and 5 are all different
packages, so why should they have the same package name?


For this specific point, it is nice to have a generic name (qt, or 
python, or sqlite, or whatever) that describes the current, default 
version. Most of my databases don't care about sqlite2, so typing 
sqlite3 feels like some sort of cargo cult ceremony. I feel the same is 
true of most software---the ecosystem evolves and tends to be compatible 
with latest version of their dependencies. The suffixed names should be 
used only if the underlying system really cares about that specific suffix.


This does not contradict any of what you said---just that I end up 
creating aliases (sqlite -> sqlite3, python -> python3, etc) that in my 
opinion should be provided by the distribution. It's not a  big deal, in 
any case: maybe the biggest practical effect of all this is that default 
names promote keeping up with the ongoing developmentit's harder to 
write Python2-dependent code if you have to explicitly invoke 
#!/bin/python2, as sort of a version-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

Getting notified on broken deps from updates-testing

[Miro Hrončok]

Hello,

it repeatedly happened to me that I'm notified by Koschei that dozens of my 
packages suddenly fail to resolve build dependencies on a released Fedora.


I usually find out that the broken update was sitting in testing for 7 days 
without any feedback, only to be pushed and receive ex-post feedback from me.


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.


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

[Kevin Fenzi]

On Wed, Nov 06, 2019 at 08:56:53PM +0100, Miro Hrončok wrote:
> On 06. 11. 19 20:41, Gwyn Ciesla via devel wrote:
> > I'll take openal-soft, pdfbox, freealut, python-httplib2, and dosbox. 
> > FAS:limb
> 
> Thanks for the quick response.
> 
> BTW For example python-httplib2 has plenty active co-maintainers to I
> suspect they would take it as well.
> 
> It was recently orphaned via https://pagure.io/fesco/issue/2253

I was going to take it, but Gwyn beat me to it. ;) 

Enjoy. 

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

[Gwyn Ciesla via devel]

By all means, take them. I just don't want them to go away. :)


-- 
Gwyn Ciesla
she/her/hers
 
in your fear, seek only peace 
in your fear, seek only love
-d. bowie

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Wednesday, November 6, 2019 3:28 PM, François Cami  
wrote:

> On Wed, Nov 6, 2019 at 8:48 PM Gwyn Ciesla via devel
> devel@lists.fedoraproject.org wrote:
> 

> > I'll take openal-soft, pdfbox, freealut, python-httplib2, and dosbox. 
> > FAS:limb
> 

> Heh, I wanted to take openal-soft and dosbox as I've been the de-facto
> maintainer for some time.
> FAS: fcami
> https://pagure.io/releng/issue/8972
> 

> Gwyn, whatever works for you :)
> 

> François
> 

> > --
> > Gwyn Ciesla
> > she/her/hers
> > 

> > 
> > 

> > in your fear, seek only peace
> > in your fear, seek only love
> > -d. bowie
> > Sent with ProtonMail Secure Email.
> > ‐‐‐ Original Message ‐‐‐
> > On Wednesday, November 6, 2019 1:15 PM, Miro Hrončok mhron...@redhat.com 
> > 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
> > > 

Re: Encrypted DNS in Fedora

[David Sommerseth]

On 05/11/2019 22:00, Nicolas Mailhot via devel wrote:
> Le mardi 05 novembre 2019 à 19:45 +0100, Tomasz Torcz a écrit :
[]
> 
> The day DoH actually gets decentralized the nowheristan state and its
> ISPs will run DoH servers like everyone else and influence their
> results exactly like today, and the nowheristan population will use the
> result by default just like they use the state and ISP servers by
> default.

DoH won't even really work here.  Yes, the DNS request is encrypted and you
knock-a-whole through their firewall, you can be fairly confident the response
has not been modified (as long as the TLS connection is validated, etc, etc).
 Except of the "knock-a-whole" aspect, DoT resolves exactly the same issues.

But what is even more important to realize is what happens *after* the DNS
query has been returned.  You connect to the IP address provided in the
response.  And if that server is encrypted but uses TLSv1.2 or older, the
hostname you are connecting to is "leaked" via the TLS negotiation (SNI
hostname is not encrypted).

The result is, you do not have any kind of privacy in regards to what services
you connect to.  A DPI capable firewall will still be able to block this access.

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.

So claiming DoH or DoT helps privacy is in best case ignorant to privacy.  In
worst case, it puts people needing privacy at risk.

If you want privacy, you need to connect to a VPN server you choose to trust.
 And that VPN provider needs to find ways to circumvent any firewall blocks as
needed.

Now DoT on the other hand can have a purpose, when used between DNS servers.


For more details about DoH challenges ... please have a look at this talk:



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

[Alexander Bokovoy]

On ke, 06 marras 2019, Miro Hrončok wrote:

On 06. 11. 19 11:41, Alexander Bokovoy wrote:

Python extension modules embedding Python and linking to libpython

- needs to be evaluated case by case
- changes to cmake/autotools are needed
- changes in code might be necessary as well
- if not changed, might misbehave
- Python Maint will provide help if asked for


Do you have a list of affected packages?


We anticipate that the number of affected packages that actually need 
to link to libpython from extension modules is (very close to) 0.


But no, we don't have a list yet. We intent to go package by package 
(see the list in the proposal) and examine the reason the file is 
linked to libpython.


We are aware about samba linking to libpython and we anticipate 
changes will be needed. This was already semi-discussed when samba 
libs didn't build with Python 3.8.


If you'd be able to help us removing this linking dependency, that would
be great.




Samba (and thus SSSD and FreeIPA) is affected. It is pretty fundamental
that Samba modules link to libpython and I think it was designed so by
you guys (Python team at Red Hat) when we ported Samba bindings to Python3.


Why is it fundamental to link extension modules to libpython?
I wasn't directly involved with porting Samba, looping Lumír in.
However note that when samba was ported, it was common to ink Python 
extension to libpython by default.


We had to support two different Python builds in parallel and had to do
a lot to link them properly to both runtimes in a correct way.



# find /usr/lib64/python3.7/site-packages/samba -name '*.so' | xargs 
-n1 -I '{}' sh -c "ldd {} | egrep -q libpython && echo 'LINKED: {}' 
"

LINKED: 
/usr/lib64/python3.7/site-packages/samba/_glue.cpython-37m-x86_64-linux-gnu.so
...


On Python 3.7, extension modules are linked to libpython by default.
On Python 3.8, extension modules are only linked to libpython if 
explicitly told so by the build system, such as sambas's waf.


Extension modules built with distutils/setuptools are not linked to libpython.

Important pointer:

https://bugzilla.redhat.com/show_bug.cgi?id=1711638#c8 ... #c34


Thanks for the link, will read later.

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

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

[rawhide]

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

Notable package version changes:
anaconda - 20191030.n.1: anaconda-32.11-1.fc32.src, 20191106.n.0: 
anaconda-32.13-1.fc32.src

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

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

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

The individual test result pages are:

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

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Miro Hrončok]

On 06. 11. 19 11:41, Alexander Bokovoy wrote:

Python extension modules embedding Python and linking to libpython

- needs to be evaluated case by case
- changes to cmake/autotools are needed
- changes in code might be necessary as well
- if not changed, might misbehave
- Python Maint will provide help if asked for


Do you have a list of affected packages?


We anticipate that the number of affected packages that actually need to link to 
libpython from extension modules is (very close to) 0.


But no, we don't have a list yet. We intent to go package by package (see the 
list in the proposal) and examine the reason the file is linked to libpython.


We are aware about samba linking to libpython and we anticipate changes will be 
needed. This was already semi-discussed when samba libs didn't build with Python 
3.8.



Samba (and thus SSSD and FreeIPA) is affected. It is pretty fundamental
that Samba modules link to libpython and I think it was designed so by
you guys (Python team at Red Hat) when we ported Samba bindings to Python3.


Why is it fundamental to link extension modules to libpython?
I wasn't directly involved with porting Samba, looping Lumír in.
However note that when samba was ported, it was common to ink Python extension 
to libpython by default.


# find /usr/lib64/python3.7/site-packages/samba -name '*.so' | xargs -n1 -I '{}' 
sh -c "ldd {} | egrep -q libpython && echo 'LINKED: {}' "
LINKED: 
/usr/lib64/python3.7/site-packages/samba/_glue.cpython-37m-x86_64-linux-gnu.so

...


On Python 3.7, extension modules are linked to libpython by default.
On Python 3.8, extension modules are only linked to libpython if explicitly told 
so by the build system, such as sambas's waf.


Extension modules built with distutils/setuptools are not linked to libpython.

Important pointer:

https://bugzilla.redhat.com/show_bug.cgi?id=1711638#c8 ... #c34


--
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: Modularity and all the things

[Randy Barlow]

On Wed, 2019-11-06 at 00:20 -0700, John M. Harris Jr wrote:
> This only works to a limited degree in Gentoo, and even then, if you
> want a stable system, you can't really install different versions of
> packages as X version of Y package will break package Z, generally
> not in the ebuild either.

Yeah I talked about this in a few other posts. When you offer parallel
availability without *full* parallel installability (Gentoo only
parallel installs certain packages), conflicts are inevitable. This is
true for Gentoo, but is also true for modularity as it exists today.

Nix might be the only solution that avoids this since it has the most
advanced form of parallel installability. I've not used Nix before, but
it sounds pretty cool.


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

[Stephen John Smoogen]

On Wed, 6 Nov 2019 at 10:24, Stephen John Smoogen  wrote:
>
> On Wed, 6 Nov 2019 at 03:35, Ralf Corsepius  wrote:
> >
> > On 11/5/19 9:41 PM, Alex Scheel wrote:
> >
> > > IMO, without a resolution in Fedora we'll never get one in RHEL.
> >
> > And? Why should Fedora care about RHEL?
> >
> > I for one consider RHEL not to be its partner, but it to be an
> > initiative to gradually push Fedora out of this planet.
> >
> >
>
> You keep saying this for over 10+ years as if there was any reality to
> what you say.  I expect that if Fedora survived to the heat death of
> the universe, you would post from the next one.. "See Red Hat and RHEL
> finally killed it."
>

Ralf and everyone else.

I lost my temper and wrote something I should not have sent.  I can
not undo the words said, but I can accept that I was in the wrong, and
sincerely apologize for them. I forgot to follow the motto I used to
have in my email signature, and I was not 'excellent to each other'. I
will be taking a break from email until I can better communicate.

Let us be kind to one another, for most of us are fighting a hard
battle. -- Ian MacClaren

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

[Nico Kadel-Garcia]

> Waiting for MIT kerberos to become stable and supported from samba
> team, a simple solution is insert into official samba.spec, a flag for
> easily rebuild it with heimdal kerberos, without substitute or modify
> the .spec file.
> 
> Something like this:
> 
> $ rpmbuild --rebuild --with heimdal  samba-.src.rpm

I set up just such a flag in my public git repo, with_ststem_mit_krb5.

> 
> Can the Fedora samba maintainers do that?
> 
> Thank
> 
They are very welcome to my work. I do make some other changes in my .spec 
files which may not be as welcome, such as splitting up contracts that obscure 
pretty formatting.
___
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: vagrant can't up rawhide compose

[Vít Ondruch]

Isn't it this issue?

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


Vít



Dne 06. 11. 19 v 14:02 Pavel Březina napsal(a):
> I'm trying vagrant image of rawhide from [1], however vagrant is
> unable to bring the machine up. It gets always stuck on "==> client:
> Waiting for domain to get an IP address..." step. Other vagrant boxes
> (Fedora 29 till Fedora 31) from these cloud composes works well.
>
> I tried to upgrade to latest vagrant upstream version (2.2.6) but that
> did not helped.
>
> [1]
> https://kojipkgs.fedoraproject.org/compose/rawhide/latest-Fedora-Rawhide/compose/Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-Rawhide-20191105.n.0.x86_64.vagrant-libvirt.box
> ___
> 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

[Stephen John Smoogen]

On Wed, 6 Nov 2019 at 03:35, Ralf Corsepius  wrote:
>
> On 11/5/19 9:41 PM, Alex Scheel wrote:
>
> > IMO, without a resolution in Fedora we'll never get one in RHEL.
>
> And? Why should Fedora care about RHEL?
>
> I for one consider RHEL not to be its partner, but it to be an
> initiative to gradually push Fedora out of this planet.
>
>

You keep saying this for over 10+ years as if there was any reality to
what you say.  I expect that if Fedora survived to the heat death of
the universe, you would post from the next one.. "See Red Hat and RHEL
finally killed 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: Modularity and all the things

[Kevin Kofler]

Randy Barlow wrote:
> Nix might be the only solution that avoids this since it has the most
> advanced form of parallel installability. I've not used Nix before, but
> it sounds pretty cool.

Unfortunately, Nix uses a completely non-standard (non-FHS) file system 
layout, essentially the Windows one. In Fedora/RHEL terms, think "every 
package is an SCL". That approach has major drawbacks, too.

I think there is no way around 1. per-package deconflicting for parallel 
installability (while maximizing FHS compliance) and 2. banning parallel 
availability for any non-leaf package for which point 1 has not yet been, 
cannot be, or will not be done. (Leaves can usually get away without 
parallel installability.)

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

[Kevin Kofler]

Alex Scheel wrote:
> In an ideal world, Modularity would've been proposed to Fedora,
> it would've been discussed by the community, improved, perfected,
> and _then_ brought into the RHEL fold only when stable! Fedora
> would've _driven_ the innovation, rather than having to keep up
> with whatever RHEL decided to do, being careful not to break
> anything.

Well, that would have been the only way to do things that would have made 
sense.

> We don't live in an ideal world and deadlines, initial rejection
> by Fedora, and issues implementing Modularity forced at least _some_
> of it to go the other direction, RHEL -> Fedora.
> 
> So now we're stuck trying to improve Modularity in Fedora, without
> stepping on any RHEL toes, and knowing full well that if the
> community rejects Modularity in Fedora (again!), we're stuck supporting
> it in RHEL through RHEL 8 (and, likely into RHEL 9). And I think that
> worries some people, hence the attempt to influence discussions, name
> calling,  Others however, want Fedora to remain fully independent
> of RHEL, and thus have asked that _failure_ be an option explicitly
> on the table.

It was purely a business decision of Red Hat to ship RHEL 8 with an 
unfinished alpha version of Modularity instead of giving it the time to 
mature in Fedora (either pushing back the RHEL 8 release (it's not like any 
release date was actually announced, nor like pushing back RHEL waiting for 
Fedora to stabilize has never been done, see how RHEL 6 was based on Fedora 
12 rather than 9 due to the major changes in Fedora 9) or pushing back 
Modularity to RHEL 9) and it is not fair that Fedora has to deal with the 
consequences of that decision.

The only mistake Fedora has made was to accept Modularity in its current 
state at all, giving in to the pressure from RHEL developers.

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

[Orcan Ogetbil]

On Wed, 6 Nov 2019 at 05:50, Vít Ondruch wrote:
> Dne 05. 11. 19 v 16:03 Ben Cotton napsal(a):
> > When we compile the python3 package on Fedora (prior to this change),
> > we create the libpython3.?.so shared library and the final python3
> > binary (/usr/bin/python3) is dynamically linked against
> > it. However by building the libpython3.?.a static library and
> > statically linking the final binary against it, we can achieve a
> > performance gain of 5% to 27% depending on the workload.
>
>
> Where are these number coming from? And what is the reason for the
> performance hit for dynamically linked Python?

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

Orcan
___
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]

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.

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

[Nico Kadel-Garcia]

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

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

Re: Getting notified on broken deps from updates-testing

[Randy Barlow]

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.


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: Modularity and all the things

[Kevin Kofler]

Randy Barlow wrote:
> On Wed, 2019-11-06 at 01:18 +0100, Kevin Kofler wrote:
>> The big difference is that Gentoo is source-based, whereas Fedora is
>> binary-based. So where Gentoo needs to ship only one ebuild (the
>> equivalent of a specfile) for foo-1.2.3 that the user can then
>> compile against different choices of dependencies, we need to ship
>> binary RPMs of that same foo-1.2.3 version for each and every
>> combination (exponentially many) of dependency versions that we want
>> to support. Which is one of the unsolved issues with  our Modularity
>> implementation, too.
> 
> This seems to be like more of a complication for the packager than for
> the user, right? I was commenting on the user experience and not the
> packager experience.
>
> I agree that the packager experience does have the crazy combinatorics,
> as adamw pointed out, but I discussed that in my reply to him.

It results in a poor user experience if the combination the user needs is 
then not available.

> You are right that the varying choices of dependencies creates
> exponential growth, but modularity has conflicts too (you can't install
> two modules that need conflicting dependency versions) and I don't see
> a way to offer the user what we are talking about without having
> conflicts.

Me neither, which is why I think it should just not be allowed. At the very 
least, a default version of something must not require a non-default version 
of a dependency that is not parallel-installable with the default version of 
that dependency.

>> I don't understand why people dislike compatibility libraries so
>> much.
> 
> I'll qualify my position as not so much that I strongly dislike it, but
> more that I would prefer if the package metadata could formally store
> the data for me, rather than encoding it in the name.

The issue is that this complicates the package management logic 
significantly (adding one more dimension to the existing 4 (NEVR)) and 
brings no measurable gain compared to just suffixing the package name.

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: Modularity and all the things

[Kevin Kofler]

Przemek Klosowski via devel wrote:
> On 11/5/19 7:18 PM, Kevin Kofler wrote:
>> "name mangling": Why is this a problem? First of all, it is not mangling,
>> it is suffixing. The original name is retained unchanged and nothing is
>> prepended to it, only appended. And, e.g., Qt 3, 4, and 5 are all
>> different packages, so why should they have the same package name?
> 
> For this specific point, it is nice to have a generic name (qt, or
> python, or sqlite, or whatever) that describes the current, default
> version. Most of my databases don't care about sqlite2, so typing
> sqlite3 feels like some sort of cargo cult ceremony. I feel the same is
> true of most software---the ecosystem evolves and tends to be compatible
> with latest version of their dependencies. The suffixed names should be
> used only if the underlying system really cares about that specific
> suffix.
> 
> This does not contradict any of what you said---just that I end up
> creating aliases (sqlite -> sqlite3, python -> python3, etc) that in my
> opinion should be provided by the distribution. It's not a  big deal, in
> any case: maybe the biggest practical effect of all this is that default
> names promote keeping up with the ongoing developmentit's harder to
> write Python2-dependent code if you have to explicitly invoke
> #!/bin/python2, as sort of a version-shaming.

You are talking about binary names there, whereas I was talking about 
package names. Though of course, to get parallel-installable packages, any 
included binaries typically have to be suffixed as well.

The drawback of renaming the binaries is that it breaks existing user 
scripts (and also other packages). For Python, the Python SIG went through 
with it anyway (unsuffixed Python is now Python 3, assuming you have python-
unversioned-command installed at all to begin with), also because they seem 
to consider breaking everything Python 2 by default to be a feature. The 
SQLite maintainer(s) decided differently.

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: Modularity and all the things

[Kevin Kofler]

Josh Boyer wrote:
> What you call unfair, I call open source winning in the industry.
> Does it create an imbalance between funded vs. unfunded work?  Yes.
> That is the reality of the software landscape today though, and I
> think it's a net good thing even if it is somewhat departed from what
> people consider open source "roots".

Some of us do not believe in capitalism, especially in the dogma that the 
markets will always do the right thing.

What I see in this case is that the design of Modularity is optimized for 
large enterprise customers (of RH/IBM) with deep pockets and their use 
cases. Those have the resources to bring up a separate container, VM, or 
even a separate physical server for every single server application they 
run. They also do not seem to consider the desktop use case to be critical. 
(I can only guess that they use Windows on all their desktops, or they would 
care.) Everyone else gets stuck in version conflict hell.

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

[Scott Schmit]

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

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.

(As a point of comparison, we've deferred to the btrfs upstream
recommendation not to install Fedora on btrfs by default.  How is this
different?)


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

[Michael Catanzaro]

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.


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

Fedora rawhide compose report: 20191106.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20191105.n.0
NEW: Fedora-Rawhide-20191106.n.0

= SUMMARY =
Added images:15
Dropped images:  9
Added packages:  8
Dropped packages:0
Upgraded packages:   89
Downgraded packages: 0

Size of added packages:  305.15 MiB
Size of dropped packages:0 B
Size of upgraded packages:   1.08 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Xfce raw-xz aarch64
Path: Spins/aarch64/images/Fedora-Xfce-Rawhide-20191106.n.0.aarch64.raw.xz
Image: Cloud_Base raw-xz aarch64
Path: Cloud/aarch64/images/Fedora-Cloud-Base-Rawhide-20191106.n.0.aarch64.raw.xz
Image: Cloud_Base raw-xz ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20191106.n.0.ppc64le.raw.xz
Image: LXDE raw-xz armhfp
Path: Spins/armhfp/images/Fedora-LXDE-armhfp-Rawhide-20191106.n.0-sda.raw.xz
Image: Workstation raw-xz aarch64
Path: 
Workstation/aarch64/images/Fedora-Workstation-Rawhide-20191106.n.0.aarch64.raw.xz
Image: Container_Base docker aarch64
Path: 
Container/aarch64/images/Fedora-Container-Base-Rawhide-20191106.n.0.aarch64.tar.xz
Image: Server raw-xz aarch64
Path: Server/aarch64/images/Fedora-Server-Rawhide-20191106.n.0.aarch64.raw.xz
Image: Cloud_Base qcow2 ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20191106.n.0.ppc64le.qcow2
Image: Cloud_Base qcow2 aarch64
Path: Cloud/aarch64/images/Fedora-Cloud-Base-Rawhide-20191106.n.0.aarch64.qcow2
Image: Minimal raw-xz aarch64
Path: Spins/aarch64/images/Fedora-Minimal-Rawhide-20191106.n.0.aarch64.raw.xz
Image: Container_Minimal_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20191106.n.0.ppc64le.tar.xz
Image: Container_Minimal_Base docker aarch64
Path: 
Container/aarch64/images/Fedora-Container-Minimal-Base-Rawhide-20191106.n.0.aarch64.tar.xz
Image: Cloud_Base vmdk ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20191106.n.0.ppc64le.vmdk
Image: Cloud_Base vmdk aarch64
Path: Cloud/aarch64/images/Fedora-Cloud-Base-Rawhide-20191106.n.0.aarch64.vmdk
Image: Container_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Base-Rawhide-20191106.n.0.ppc64le.tar.xz

= DROPPED IMAGES =
Image: Everything boot s390x
Path: 
Everything/s390x/iso/Fedora-Everything-netinst-s390x-Rawhide-20191105.n.0.iso
Image: Server dvd s390x
Path: Server/s390x/iso/Fedora-Server-dvd-s390x-Rawhide-20191105.n.0.iso
Image: Server boot s390x
Path: Server/s390x/iso/Fedora-Server-netinst-s390x-Rawhide-20191105.n.0.iso
Image: Cloud_Base raw-xz s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20191105.n.0.s390x.raw.xz
Image: Silverblue dvd-ostree x86_64
Path: 
Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20191105.n.0.iso
Image: Container_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Base-Rawhide-20191105.n.0.s390x.tar.xz
Image: Cloud_Base vmdk s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20191105.n.0.s390x.vmdk
Image: Container_Minimal_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20191105.n.0.s390x.tar.xz
Image: Cloud_Base qcow2 s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20191105.n.0.s390x.qcow2

= ADDED PACKAGES =
Package: R-Biobase-2.46.0-1.fc32
Summary: Base functions for Bioconductor
RPMs:R-Biobase
Size:10.99 MiB

Package: R-Biostrings-2.54.0-1.fc32
Summary: String objects representing biological sequences
RPMs:R-Biostrings R-Biostrings-devel
Size:67.52 MiB

Package: R-DynDoc-1.64.0-1.fc32
Summary: Functions for dynamic documents
RPMs:R-DynDoc
Size:173.07 KiB

Package: R-tkWidgets-1.64.0-1.fc32
Summary: Widgets to provide user interfaces from bioconductor
RPMs:R-tkWidgets
Size:578.04 KiB

Package: R-widgetTools-1.64.0-1.fc32
Summary: Bioconductor tools to support tcltk widgets
RPMs:R-widgetTools
Size:297.83 KiB

Package: oci-seccomp-bpf-hook-0.0.1-0.4.git3baa603a.fc32
Summary: OCI Hook to generate seccomp json files based on EBF syscalls used by 
container
RPMs:oci-seccomp-bpf-hook
Size:3.97 MiB

Package: opencascade-7.4.0-2.fc32
Summary: SDK intended for development of applications dealing with 3D CAD data
RPMs:opencascade-devel opencascade-draw opencascade-foundation 
opencascade-modeling opencascade-ocaf opencascade-visualization
Size:221.61 MiB

Package: transflac-1.0.0-3.fc32
Summary: Transcode FLAC to lossy formats
RPMs:transflac
Size:27.36 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  ClanLib06-0.6.5-47.fc32
Old package:  ClanLib06-0.6.5-45.fc31
Summary:  Version 0.6 of this Cross platform C++ game library
RPMs: ClanLib06 ClanLib06-devel
Size: 7.70 MiB
Size change:  1.24 MiB
Changelog:
  * Tue Nov 05 2019 Hans de Goede  - 0.6.5-46
  - Fix fullscreen windows not receiving events under Xwayland
  - Fix ClanLib sometimes selecting a non optimal

Re: Please, IMHO, resolve in some way the Samba MIT kerberos problem.

[Dario Lesca]

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?

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

-- 
Dario Lesca
(inviato dal mio Linux Fedora 31 Workstation)
___
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 06. 11. 19 17:44, Alexander Bokovoy wrote:

If you'd be able to help us removing this linking dependency, that would
be great.


We would. However we'd only invest the time and energy into it if this change is 
accepted, not before that. IF samba and or freeipa breaks, that would be Fedora 
32 blocker, so we would revert this change until a fix or viable workaround is 
found.


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

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

[Fedora compose checker]

No missing expected images.

Compose FAILS proposed Rawhide gating check!
1 of 45 required tests failed, 2 results missing
Unsatisfied gating requirements that could not be mapped to openQA tests:
FAILED: compose.cloud.all
MISSING: fedora.Workstation-boot-iso.x86_64.64bit - compose.install_default
MISSING: fedora.Workstation-boot-iso.x86_64.uefi - compose.install_default

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

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

ID: 480839  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/480839
ID: 480876  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/480876
ID: 480879  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/480879

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

New soft failures (same test not soft failed in Fedora-Rawhide-20191105.n.0):

ID: 480828  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/480828
ID: 480870  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/480870

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

ID: 480853  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/480853
ID: 480935  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/480935
ID: 480947  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/480947

Passed openQA tests: 138/145 (x86_64)

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

ID: 480823  Test: x86_64 Server-dvd-iso install_vnc_server
URL: https://openqa.fedoraproject.org/tests/480823

Skipped non-gating openQA tests: 1 of 147

Installed system changes in test x86_64 Server-boot-iso install_default@uefi: 
Used mem changed from 187 MiB to 161 MiB
Previous test data: https://openqa.fedoraproject.org/tests/480224#downloads
Current test data: https://openqa.fedoraproject.org/tests/480809#downloads

Installed system changes in test x86_64 Server-boot-iso install_default: 
Used mem changed from 186 MiB to 161 MiB
Previous test data: https://openqa.fedoraproject.org/tests/480223#downloads
Current test data: https://openqa.fedoraproject.org/tests/480810#downloads

Installed system changes in test x86_64 Everything-boot-iso 
install_default@uefi: 
Used mem changed from 136 MiB to 115 MiB
Previous test data: https://openqa.fedoraproject.org/tests/480259#downloads
Current test data: https://openqa.fedoraproject.org/tests/480846#downloads

Installed system changes in test x86_64 Everything-boot-iso install_default: 
Used mem changed from 135 MiB to 115 MiB
Previous test data: https://openqa.fedoraproject.org/tests/480258#downloads
Current test data: https://openqa.fedoraproject.org/tests/480847#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default_upload: 
1 services(s) added since previous compose: switcheroo-control.service
System load changed from 0.46 to 0.82
Previous test data: https://openqa.fedoraproject.org/tests/480260#downloads
Current test data: https://openqa.fedoraproject.org/tests/480848#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default@uefi: 
Used mem changed from 976 MiB to 854 MiB
1 services(s) added since previous compose: switcheroo-control.service
Previous test data: https://openqa.fedoraproject.org/tests/480262#downloads
Current test data: https://openqa.fedoraproject.org/tests/480850#downloads

Installed system changes in test x86_64 KDE-live-iso install_default@uefi: 
1 services(s) removed since previous compose: pcscd.service
System load changed from 1.86 to 2.33
Average CPU usage changed from 13.42857143 to 80.03809524
Previous test data: https://openqa.fedoraproject.org/tests/480277#downloads
Current test data: https://openqa.fedoraproject.org/tests/480864#downloads

Installed system changes in test x86_64 KDE-live-iso install_default_upload: 
Used mem changed from 848 MiB to 695 MiB
System load changed from 2.55 to 2.78
Previous test data: https://openqa.fedoraproject.org/tests/480275#downloads
Current test data: https://openqa.fedoraproject.org/tests/480865#downloads

Installed system changes in test x86_64 universal install_package_set_kde: 
System load changed from 0.75 to 0.43
Previous test data: https://openqa.fedoraproject.org/tests/480368#downloads
Current test data: https://openqa.fedoraproject.org/tests/480938#downloads
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora 

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

[Miro Hrončok]

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)maintainersStatus Change

FUR orphan 0 weeks ago
WindowMaker orphan 0 weeks ago
WindowMaker-extra   orphan 0 weeks ago
airsnortorphan 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, orphan0 weeks ago
cli-parser  lef, orphan0 weeks ago
diffuse cicku, fab, orphan 4 weeks ago
dillo   aarem, orphan  0 weeks ago
dosbox  fcami, orphan  0 weeks ago
dynamiteorphan 0 weeks ago
eclipse-abrtorphan, 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, sopotc1 weeks ago
extra166y   orphan 2 weeks ago
fbdesk  orphan 0 weeks ago
felix-osgi-foundation   orphan 2 weeks ago
freealutjwrdegoede, orphan, pwalter0 weeks ago
glassfish-gmbal orphan 0 weeks ago
glassfish-management-apiorphan 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, orphan0 weeks ago
java-oauth  lef, orphan0 weeks ago
jboss-connector-1.6-api gil, lef, orphan   0 weeks ago
jboss-jaspi-1.1-api lef, orphan0 weeks ago
jboss-jsp-2.3-api   orphan 0 weeks ago
jcsporphan 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
lcmsajax, alexl, caillon, caolanm, 0 weeks ago
gnome-sig, johnp, mbarnes,
orphan, rhughes, rstrode, ssp
leafnodeorphan 4 weeks ago
libAfterImage   ellert, orphan 0 weeks ago
libdockapp  orphan 0 weeks ago
libetpanorphan, 

Re: Encrypted DNS in Fedora

[Petr Mensik]

On 11/6/19 7:11 AM, Tomasz Torcz wrote:

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. Done, you've got DoH set
system-wide, which I believe this thread is about.
   And you run resolving endpoint on your trusted server, or on some
micro-vm in Azure or somewhere else, or even on Fedora's Communishift.
Google does not even enter the picture.

  (cutting the rest as it's irrelevant)



I agree with one sidenote. It is not required to use DoH for that, DoT 
is enough already. And it cannot contain privacy leaking headers, 
because there are just none in the protocol.


I think dnssec-trigger might be and example. It checks dnssec in current 
resolvers obtained by DHCP. If it does not support it, it uses its own. 
If they are blocked, it uses proxy. Does not know anything about 
encryption, but it might work if tuned a bit.


Problem is, it has already terrible design. It should be driven by 
network manager or something similar. Anyway, I think any encryption 
belongs to the system, not applications. But first, we need some 
system-wide tool prepared for that. Besides dnssec-trigger, there is 
getdns-stubby package. It does not allow simple use of DHCP specified 
resolvers, but it is the best solution for encrypted DNS at the moment.


Regards,
Petr
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973
___
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)

[Frantisek Zatloukal]

On Wed, Nov 6, 2019 at 9:11 PM Gwyn Ciesla via devel <
devel@lists.fedoraproject.org> wrote:

> Ok. :)  And I'll take wine if absolutely no one else will, but as a last
> resort. :)
>

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


Nico, I appreciate your passion about the software in question. However,
the problems you are keeping to ignore are very real and cause real
problems on a distribution scale. I cannot say anything about your
communication with Heimdal authors, but suspect there is clear
misunderstanding of the problem domain. Loading two different
implementations of the same API in the same address space is not going
to provide a reliable and stable execution environment. I don't believe
Heimdal authors don't know this.



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.


Fedora project infrastructure provides you enough possibilities to build
your packages. Please use COPR to provide rebuilt packages the way you
want. This is the most simple way to serve your users within Fedora
infrastructure -- it doesn't require complaining that a distribution
policy is contrary to your expectations.

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

[EPEL-devel] Re: EPEL Steering Committee Request: Allow minizip-compat

[Dominik 'Rathann' Mierzejewski]

On Monday, 04 November 2019 at 23:38, Neal Gompa wrote:
> On Mon, Nov 4, 2019 at 5:26 PM Stephen John Smoogen  wrote:
> >
> > So I started to review
> > https://bugzilla.redhat.com/show_bug.cgi?id=1767883 which is a package
> > which is normally in the zlib package but has been commented out from
> > shipping on RHEL-8. It is needed for chromium and other items so Tom
> > Callaway has made up a package for it. However the naming guidelines
> > for packages have deprecated -compat packages even though this seems
> > to have been added after that rule was put in place.
> >
> > In reviewing the package the name was the only thing which came up and
> > i would like to give it a pass versus having it renamed to minizip1.2
> > (or better yet libminizip since all it is a library) untl the upstream
> > zlib package is named that way also.
> >
> 
> Honestly, it should probably be fixed in Fedora to be minizip1 /
> minizip1-devel instead of minizip-compat / minizip-compat-devel...
> 
> But I guess that as long as it's not that in Fedora, it's fine to be
> not it in EPEL...

I'd use the correct name and add Provides with what's in Fedora to
be removed when Fedora package is renamed. I don't see a good reason
not to do it properly when you have a chance. Dropping Provides: is
easier than package renaming.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[Bug 1769359] New: [RFE] EPEL8 branch of perl-B-Compiling

[bugzilla]

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

Bug ID: 1769359
   Summary: [RFE] EPEL8 branch of perl-B-Compiling
   Product: Fedora EPEL
   Version: epel8
Status: NEW
 Component: perl-B-Compiling
  Assignee: andrea.v...@gmail.com
  Reporter: p...@city-fan.org
QA Contact: extras...@fedoraproject.org
CC: andrea.v...@gmail.com, iarn...@gmail.com,
jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



This is needed for perl-Devel-Declare.

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

[Bug 1768809] perl-XML-CommonNS for EL8

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 CC||ppi...@redhat.com
  Component|perl-XML-CommonNS   |perl-XML-CommonNS
Version|rawhide |epel8
Product|Fedora  |Fedora EPEL



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

[Bug 1768805] perl-RDF-Trine for EL8

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 CC||ppi...@redhat.com
  Component|perl-RDF-Trine  |perl-RDF-Trine
Version|rawhide |epel8
Product|Fedora  |Fedora EPEL



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

[Bug 1768807] perl-MooseX-ArrayRef for EL8

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-MooseX-ArrayRef-0.005-
   ||12.el8
   ||perl-MooseX-ArrayRef-0.005-
   ||12.el8.playground



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

[Bug 1768810] perl-XML-Namespace for EL8

[bugzilla]

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



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

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

[Bug 1768807] perl-MooseX-ArrayRef for EL8

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 CC||ppi...@redhat.com
  Component|perl-MooseX-ArrayRef|perl-MooseX-ArrayRef
Version|rawhide |epel8
Product|Fedora  |Fedora EPEL



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

[Bug 1768957] Add perl-XML-NamespaceFactory to EPEL8

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-XML-NamespaceFactory-1
   ||.02-12.el8
   ||perl-XML-NamespaceFactory-1
   ||.02-12.el8.playground



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

[Bug 1768807] perl-MooseX-ArrayRef for EL8

[bugzilla]

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



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

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

[Bug 1769280] New: [RFE] EPEL8 branch of perl-CLASS

[bugzilla]

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

Bug ID: 1769280
   Summary: [RFE] EPEL8 branch of perl-CLASS
   Product: Fedora EPEL
   Version: epel8
Status: NEW
 Component: perl-CLASS
  Assignee: robinlee.s...@gmail.com
  Reporter: p...@city-fan.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
robinlee.s...@gmail.com
  Target Milestone: ---
Classification: Fedora



Please consider branching and building this for EPEL-8.

I'm going to need it for perl-perl5i eventually.

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

[Bug 1768803] perl-Geo-Distance for EL8

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 CC||ppi...@redhat.com
  Component|perl-Geo-Distance   |perl-Geo-Distance
Version|rawhide |epel8
Product|Fedora  |Fedora EPEL



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

[Bug 1768928] Package perl-Const-Fast for EPEL8

[bugzilla]

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



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

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

[Bug 1768928] Package perl-Const-Fast for EPEL8

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Const-Fast-0.014-19.el
   ||8
   ||perl-Const-Fast-0.014-19.ep
   ||el8.playground



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

[Bug 1768806] perl-IRI for EL8

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-IRI-0.009-5.el8
   ||perl-IRI-0.009-5.el8.playgr
   ||ound



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

[Bug 1768806] perl-IRI for EL8

[bugzilla]

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



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

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

[Bug 1768957] Add perl-XML-NamespaceFactory to EPEL8

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 CC||ppi...@redhat.com
  Component|perl-XML-NamespaceFactory   |perl-XML-NamespaceFactory
Version|rawhide |epel8
Product|Fedora  |Fedora EPEL



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

[Bug 1768810] perl-XML-Namespace for EL8

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-XML-Namespace-0.02-12.
   ||el8
   ||perl-XML-Namespace-0.02-12.
   ||el8.playground



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

[Bug 1763473] ack-3.2.0 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #6 from Fedora Update System  ---
FEDORA-2019-bcfa471fda has been submitted as an update to Fedora 31.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-bcfa471fda

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

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

[Miro Hrončok]

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)maintainersStatus Change

FUR orphan 0 weeks ago
WindowMaker orphan 0 weeks ago
WindowMaker-extra   orphan 0 weeks ago
airsnortorphan 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, orphan0 weeks ago
cli-parser  lef, orphan0 weeks ago
diffuse cicku, fab, orphan 4 weeks ago
dillo   aarem, orphan  0 weeks ago
dosbox  fcami, orphan  0 weeks ago
dynamiteorphan 0 weeks ago
eclipse-abrtorphan, 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, sopotc1 weeks ago
extra166y   orphan 2 weeks ago
fbdesk  orphan 0 weeks ago
felix-osgi-foundation   orphan 2 weeks ago
freealutjwrdegoede, orphan, pwalter0 weeks ago
glassfish-gmbal orphan 0 weeks ago
glassfish-management-apiorphan 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, orphan0 weeks ago
java-oauth  lef, orphan0 weeks ago
jboss-connector-1.6-api gil, lef, orphan   0 weeks ago
jboss-jaspi-1.1-api lef, orphan0 weeks ago
jboss-jsp-2.3-api   orphan 0 weeks ago
jcsporphan 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
lcmsajax, alexl, caillon, caolanm, 0 weeks ago
gnome-sig, johnp, mbarnes,
orphan, rhughes, rstrode, ssp
leafnodeorphan 4 weeks ago
libAfterImage   ellert, orphan 0 weeks ago
libdockapp  orphan 0 weeks ago
libetpanorphan, 

[Bug 1768649] perl-Danga-Socket-1.62 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-Danga-Socket-1.62-1.fc31 has been pushed to the Fedora 31 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-1c7f66325e

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

[389-devel] please review: PR 50693 - Failed db restore task does not report an error

[Mark Reynolds]

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

--

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

[EPEL-devel] Fedora EPEL 8 updates-testing report

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c7b7c6aae7   
java-latest-openjdk-13.0.1.9-2.rolling.el8
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-9db33fcb54   
chromium-78.0.3904.70-1.el8
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-070b8cd703   
koji-1.19.0-1.el8


The following builds have been pushed to Fedora EPEL 8 updates-testing

libkml-1.3.0-24.el8
perl-Algorithm-Combinatorics-0.27-17.el8
perl-Crypt-SMIME-0.25-6.el8
perl-Crypt-X509-0.51-19.el8
perl-DateTime-Format-W3CDTF-0.07-9.el8
perl-JSON-Any-1.39-14.el8
perl-Pod-Readme-1.2.3-1.el8
perl-Safe-Isa-1.10-1.el8
perl-Test-API-0.010-6.el8
perl-Test-JSON-0.11-26.el8
perl-Test-Modern-0.013-15.el8
perl-URI-FromHash-0.05-12.el8
perl-UUID-Tiny-1.04-18.el8
perl-namespace-sweep-0.006-10.el8

Details about builds:



 libkml-1.3.0-24.el8 (FEDORA-EPEL-2019-37ee67ed15)
 Reference implementation of OGC KML 2.2

Update Information:

Build for EPEL8

References:

  [ 1 ] Bug #1763546 - Please branch and build for EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1763546




 perl-Algorithm-Combinatorics-0.27-17.el8 (FEDORA-EPEL-2019-e6c7673956)
 Efficient generation of combinatorial sequences

Update Information:

First EPEL 8 build.

References:

  [ 1 ] Bug #1768817 - perl-Algorithm-Combinatorics for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1768817




 perl-Crypt-SMIME-0.25-6.el8 (FEDORA-EPEL-2019-7bf6b1cf69)
 S/MIME message signing, verification, encryption and decryption

Update Information:

First EPEL 8 build.

References:

  [ 1 ] Bug #1758480 - perl-Crypt-SMIME for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1758480




 perl-Crypt-X509-0.51-19.el8 (FEDORA-EPEL-2019-37bf00c40e)
 Parse a X.509 certificate

Update Information:

This is the first EPEL-8 build of perl-Crypt-X509.

References:

  [ 1 ] Bug #1768801 - perl-Crypt-X509 for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1768801




 perl-DateTime-Format-W3CDTF-0.07-9.el8 (FEDORA-EPEL-2019-449467a384)
 Parse and format W3CDTF datetime strings

Update Information:

Added the package to EPEL 8

References:

  [ 1 ] Bug #1768797 - perl-DateTime-Format-W3CDTF for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1768797




 perl-JSON-Any-1.39-14.el8 (FEDORA-EPEL-2019-2fda44f1ee)
 A meta-module to make working with JSON easier

Update Information:

This package contains the Perl module JSON::Any, which provides a coherent API
to bring together the various JSON modules currently on CPAN.

References:

  [ 1 ] Bug #1769009 - perl-Test-JSON for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1769009




 perl-Pod-Readme-1.2.3-1.el8 (FEDORA-EPEL-2019-72373441f6)
 Intelligently generate a README file from POD

Update Information:

[Bug 1768804] perl-Test-JSON for EL8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-Test-JSON-0.11-26.el8 has been pushed to the Fedora EPEL 8 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-275f978327

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

[EPEL-devel] Re: EPEL Steering Committee Request: Allow minizip-compat

[Stephen John Smoogen]

On Wed, 6 Nov 2019 at 06:02, Dominik 'Rathann' Mierzejewski
 wrote:
>
> On Monday, 04 November 2019 at 23:38, Neal Gompa wrote:
> > On Mon, Nov 4, 2019 at 5:26 PM Stephen John Smoogen  
> > wrote:
> > >
> > > So I started to review
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1767883 which is a package
> > > which is normally in the zlib package but has been commented out from
> > > shipping on RHEL-8. It is needed for chromium and other items so Tom
> > > Callaway has made up a package for it. However the naming guidelines
> > > for packages have deprecated -compat packages even though this seems
> > > to have been added after that rule was put in place.
> > >
> > > In reviewing the package the name was the only thing which came up and
> > > i would like to give it a pass versus having it renamed to minizip1.2
> > > (or better yet libminizip since all it is a library) untl the upstream
> > > zlib package is named that way also.
> > >
> >
> > Honestly, it should probably be fixed in Fedora to be minizip1 /
> > minizip1-devel instead of minizip-compat / minizip-compat-devel...
> >
> > But I guess that as long as it's not that in Fedora, it's fine to be
> > not it in EPEL...
>
> I'd use the correct name and add Provides with what's in Fedora to
> be removed when Fedora package is renamed. I don't see a good reason
> not to do it properly when you have a chance. Dropping Provides: is
> easier than package renaming.
>
>

Thanks. Tom went with minizip1.2 and made some other changes and I
have hit the + button.


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

[Bug 1758758] mod_perl-2.0.11 is available

[bugzilla]

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



--- Comment #11 from Fedora Update System  ---
mod_perl-2.0.11-1.fc29 has been pushed to the Fedora 29 testing repository. If
problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-9647d0d341

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

[EPEL-devel] Fedora EPEL 6 updates-testing report

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-244e8468f8   
t1utils-1.41-1.el6
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-b3dc1811a1   
rssh-2.3.4-15.el6
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-755c983846   
golang-1.13.3-1.el6
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-cd52ee3c1e   
putty-0.73-1.el6


The following builds have been pushed to Fedora EPEL 6 updates-testing

python-configparser-4.0.2-2.el6

Details about builds:



 python-configparser-4.0.2-2.el6 (FEDORA-EPEL-2019-31e10daac8)
 Backport of Python 3 configparser module

Update Information:

Depend on python-backports    Update to 4.0.2

ChangeLog:

* Tue Nov  5 2019 Avram Lubkin  - 4.0.2-2
- Depend on python-backports
* Mon Oct 28 2019 Avram Lubkin  - 4.0.2-1
- Update to 4.0.2


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

[Bug 1768797] perl-DateTime-Format-W3CDTF for EL8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-DateTime-Format-W3CDTF-0.07-9.el8 has been pushed to the Fedora EPEL 8
testing repository. If problems still persist, please make note of it in this
bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-449467a384

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

[Bug 1758480] perl-Crypt-SMIME for EL8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #7 from Fedora Update System  ---
perl-Crypt-SMIME-0.25-6.el8 has been pushed to the Fedora EPEL 8 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-7bf6b1cf69

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

[Bug 1768817] perl-Algorithm-Combinatorics for EL8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #6 from Fedora Update System  ---
perl-Algorithm-Combinatorics-0.27-17.el8 has been pushed to the Fedora EPEL 8
testing repository. If problems still persist, please make note of it in this
bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-e6c7673956

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

[Bug 1768801] perl-Crypt-X509 for EL8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-Crypt-X509-0.51-19.el8 has been pushed to the Fedora EPEL 8 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-37bf00c40e

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

[Bug 1768800] perl-UUID-Tiny for EL8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-UUID-Tiny-1.04-18.el8 has been pushed to the Fedora EPEL 8 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-de0e17691e

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

[Bug 1768794] perl-Safe-Isa for EL8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-Safe-Isa-1.10-1.el8 has been pushed to the Fedora EPEL 8 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-b81e5766a9

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

[Bug 1768973] Add perl-URI-FromHash to EPEL8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-URI-FromHash-0.05-12.el8 has been pushed to the Fedora EPEL 8 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-2d7fab9194

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

[Bug 1768813] perl-namespace-sweep for EL8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-namespace-sweep-0.006-10.el8 has been pushed to the Fedora EPEL 8 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-973609c54f

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

[Bug 1769009] perl-JSON-Any for EL8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-JSON-Any-1.39-14.el8 has been pushed to the Fedora EPEL 8 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-2fda44f1ee

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

[Bug 1768811] perl-Test-Modern for EL8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-Test-API-0.010-6.el8, perl-Test-Modern-0.013-15.el8 has been pushed to the
Fedora EPEL 8 testing repository. If problems still persist, please make note
of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-e281f46b75

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

[Bug 1758480] perl-Crypt-SMIME for EL8

[bugzilla]

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



--- Comment #8 from Xavier Bachelot  ---
(In reply to Steve Traylen from comment #6)
> Sorry missed this, looks like you have it hand.

I too missed that I have commit rights on this package. Sorry for the noise...

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

[Bug 1765952] perl-CPAN-Perl-Releases-4.18 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-CPAN-Perl-Releases-4.1 |perl-CPAN-Perl-Releases-4.1
   |8-1.fc31|8-1.fc31
   |perl-CPAN-Perl-Releases-4.1 |perl-CPAN-Perl-Releases-4.1
   |8-1.fc30|8-1.fc30
   ||perl-CPAN-Perl-Releases-4.1
   ||8-1.fc29



--- Comment #9 from Fedora Update System  ---
perl-CPAN-Perl-Releases-4.18-1.fc29 has been pushed to the Fedora 29 stable
repository. If problems still persist, please make note of it in this bug
report.

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

[Bug 1765952] perl-CPAN-Perl-Releases-4.18 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-CPAN-Perl-Releases-4.1 |perl-CPAN-Perl-Releases-4.1
   |8-1.fc31|8-1.fc31
   ||perl-CPAN-Perl-Releases-4.1
   ||8-1.fc30



--- Comment #8 from Fedora Update System  ---
perl-CPAN-Perl-Releases-4.18-1.fc30 has been pushed to the Fedora 30 stable
repository. If problems still persist, please make note of it in this bug
report.

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