[Bug 1761539] [RFE] Please build for EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761539 --- Comment #2 from Fedora Update System --- FEDORA-EPEL-2019-4f7883722e has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-4f7883722e -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Modularity and the system-upgrade path
On Wed, Oct 16, 2019 at 12:21 AM John M. Harris Jr wrote: > > On Tuesday, October 15, 2019 9:13:40 PM MST Neal Gompa wrote: > > the end goal of the modularity project is to enable > > a fully modularized distribution > > Was this ever clarified anywhere? I highly doubt that it would have been able > to even begin, if that goal had been communicated.. Especially considering > that's not even possible. > That was how this project started. Fedora Server Boltron was the first attempt at it, but it was a lot more than they could do at once, so it was scaled back. However, I don't think there will be any more scaling back of the modularity project. It's far too important for that to happen. And to be fair, while it is a hard problem to solve, it's a worthy one. It makes sense and if done well, could really distinguish Fedora from the rest in providing a way for codifying individual lifecycles separately from the distribution. Moreover, with all the container circus stuff going on, it's become even more important to enable some kind of parallel availability. Sadly, I think a lot of people are learning that investing so little in infrastructure tooling (especially build and release tooling) for the past decade has really hurt them. Koji living off 1.5 people for several years, no *real* attempt to improve packager workflows since the move to Dist-Git in 2010, and generally increasing package collection with complex dependency chains has led to a situation where all of our bandages have to come off at once, and we can see that the wounds didn't heal as well as we thought. Even the work to port our tooling to Python 3 has shown how badly Fedora's tools have been maintained. What's worse, opportunities to build communities around those tools to broaden the user and contributor base clearly weren't taken, which allowed them to devolve into Fedora-specific tooling or just plain rot. There's a lot of corrective actions happening, some of it potentially overreacting, but a lot of it is very justified. It's going to be a long, hard road to get a good quality of life for Fedora contributors again. There's more for table stakes, we've had serious UX regressions in the past five years, and we have to start seriously examining contributor pain points and dealing with them. -- 真実はいつも一つ！/ 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 the system-upgrade path
On Tuesday, October 15, 2019 9:13:40 PM MST Neal Gompa wrote: > the end goal of the modularity project is to enable > a fully modularized distribution Was this ever clarified anywhere? I highly doubt that it would have been able to even begin, if that goal had been communicated.. Especially considering that's not even possible. -- John M. Harris, Jr. Splentity ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 the system-upgrade path
On Wed, Oct 16, 2019 at 12:11 AM John M. Harris Jr wrote: > > On Tuesday, October 15, 2019 9:07:51 PM MST Neal Gompa wrote: > > On Wed, Oct 16, 2019 at 12:05 AM John M. Harris Jr > > wrote: > > > > > > > > > On Tuesday, October 15, 2019 6:26:31 PM MST Stephen Gallagher wrote: > > > > > > > given that we're talking about the need to migrate defaults > > > > > > > > > > > > To clarify, that has not been decided, and a prominent option mentioned > > > in > > > this thread is the option to simply require that there is a non-modular > > > package. > > > > > > > > > > > > I think we can pretty much guarantee that's not going to happen. > > Unfortunately, modularization is a one-way road, given how modularity > > is implemented in DNF and how our distribution policies are currently > > structured. > > > > It just means that people need to *really* think of the consequences > > of modularizing content, because there's basically no going back after > > that. We have no escape hatches or transition mechanisms to go from > > modular to non-modular variants of the same RPMs. > > That's not what the proposal is. The proposal is to require a non-modular > version, an "ursine package", for modular packages, instead of default > modules. We cannot remove already existing default modules without further breaking things. Moreover, DNF will refuse to expose non-modular RPMs if it's aware of modular ones that have existed at some point. The best we can do is stop people from making more. We have no process for de-modularization and I fully expect us to not have one ever, as the end goal of the modularity project is to enable a fully modularized distribution. Even RHEL 8 isn't a full realization of that vision. -- 真実はいつも一つ！/ 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 the system-upgrade path
On Tuesday, October 15, 2019 9:07:51 PM MST Neal Gompa wrote: > On Wed, Oct 16, 2019 at 12:05 AM John M. Harris Jr > wrote: > > > > > > On Tuesday, October 15, 2019 6:26:31 PM MST Stephen Gallagher wrote: > > > > > given that we're talking about the need to migrate defaults > > > > > > > > To clarify, that has not been decided, and a prominent option mentioned > > in > > this thread is the option to simply require that there is a non-modular > > package. > > > > > > > I think we can pretty much guarantee that's not going to happen. > Unfortunately, modularization is a one-way road, given how modularity > is implemented in DNF and how our distribution policies are currently > structured. > > It just means that people need to *really* think of the consequences > of modularizing content, because there's basically no going back after > that. We have no escape hatches or transition mechanisms to go from > modular to non-modular variants of the same RPMs. That's not what the proposal is. The proposal is to require a non-modular version, an "ursine package", for modular packages, instead of default modules. -- John M. Harris, Jr. Splentity ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 the system-upgrade path
On Wed, Oct 16, 2019 at 12:05 AM John M. Harris Jr wrote: > > On Tuesday, October 15, 2019 6:26:31 PM MST Stephen Gallagher wrote: > > given that we're talking about the need to migrate defaults > > To clarify, that has not been decided, and a prominent option mentioned in > this thread is the option to simply require that there is a non-modular > package. > I think we can pretty much guarantee that's not going to happen. Unfortunately, modularization is a one-way road, given how modularity is implemented in DNF and how our distribution policies are currently structured. It just means that people need to *really* think of the consequences of modularizing content, because there's basically no going back after that. We have no escape hatches or transition mechanisms to go from modular to non-modular variants of the same RPMs. -- 真実はいつも一つ！/ 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 the system-upgrade path
On Tuesday, October 15, 2019 6:26:31 PM MST Stephen Gallagher wrote: > given that we're talking about the need to migrate defaults To clarify, that has not been decided, and a prominent option mentioned in this thread is the option to simply require that there is a non-modular package. -- John M. Harris, Jr. Splentity ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Recommending proprietary software in Fedora
On Tuesday, October 15, 2019 8:59:18 PM MST Leigh Scott wrote: > > On Wed, Oct 16, 2019 at 12:44 AM, John M. Harris Jr > > > > > As previously mentioned in this thread, we already approved Steam for > > F28. > > > > > > This was also previously addressed earlier in this thread, where I > > quoted the relevant portion of the policy in full. Please consider > > previous replies in this thread before posting new ones. > > > > Michael > > > Don't waste your time answering this troll, he isn't listening. I am not a troll, and I definitely am listening. I read the third party software guidelines very carefully, on both the FESCo page, and the Workstation Group's page. -- John M. Harris, Jr. Splentity ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Recommending proprietary software in Fedora
> On Wed, Oct 16, 2019 at 12:44 AM, John M. Harris Jr > > As previously mentioned in this thread, we already approved Steam for > F28. > > > This was also previously addressed earlier in this thread, where I > quoted the relevant portion of the policy in full. Please consider > previous replies in this thread before posting new ones. > > Michael Don't waste your time answering this troll, he isn't listening. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Recommending proprietary software in Fedora
On Tuesday, October 15, 2019 6:58:07 PM MST mcatanz...@gnome.org wrote: > On Wed, Oct 16, 2019 at 12:44 AM, John M. Harris Jr > > wrote: > > Proprietary software is certainly a subset of third party software, > > however, > > please read the Workstation group's own page about third party > > software. > > According to that documentation, the Workstation group itself or > > FESCo is > > meant to approve it before it is allowed, > > As previously mentioned in this thread, we already approved Steam for > F28. > > > and it may require Fedora Legal sign-off, as it may present > > considerable risk. > > This was also previously addressed earlier in this thread, where I > quoted the relevant portion of the policy in full. Please consider > previous replies in this thread before posting new ones. > > Michael What you've just said is clearly not in line with what has been quoted, otherwise I would not have written the response that I did. Please read the content of my previous message. -- John M. Harris, Jr. Splentity ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Recommending proprietary software in Fedora
On Tuesday, October 15, 2019 7:01:49 PM MST mcatanz...@gnome.org wrote: > On Wed, Oct 16, 2019 at 12:19 AM, Kevin Kofler > > wrote: > > By actively offering the proprietary Chrome to the users instead of > > explaining the above, you are actually pointing them towards using > > proprietary software instead of Free Software for no reason. > > I think you're probably right that people mainly want Chrome for the > multimedia support. But well, surely you are well aware that we'll > never be able to point to the rpmfusion codecs packages in any official > location. I know it's very frustrating, but the legal team is just > trying to protect Red Hat (and Fedora). It would be helpful to please > keep your argumentation within the realm of the legal constraints we > have to respect. > > Michael If we can't point to that, but *can* point to *proprietary software* "in any official location", we're obviously doing something wrong. Protecting Fedora is not achieved by recommending proprietary software. -- John M. Harris, Jr. Splentity ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Recommending proprietary software in Fedora
On Wed, Oct 16, 2019 at 12:19 AM, Kevin Kofler wrote: By actively offering the proprietary Chrome to the users instead of explaining the above, you are actually pointing them towards using proprietary software instead of Free Software for no reason. I think you're probably right that people mainly want Chrome for the multimedia support. But well, surely you are well aware that we'll never be able to point to the rpmfusion codecs packages in any official location. I know it's very frustrating, but the legal team is just trying to protect Red Hat (and Fedora). It would be helpful to please keep your argumentation within the realm of the legal constraints we have to respect. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Recommending proprietary software in Fedora
On Wed, Oct 16, 2019 at 12:44 AM, John M. Harris Jr wrote: Proprietary software is certainly a subset of third party software, however, please read the Workstation group's own page about third party software. According to that documentation, the Workstation group itself or FESCo is meant to approve it before it is allowed, As previously mentioned in this thread, we already approved Steam for F28. and it may require Fedora Legal sign-off, as it may present considerable risk. This was also previously addressed earlier in this thread, where I quoted the relevant portion of the policy in full. Please consider previous replies in this thread before posting new ones. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Failure creating Fedora ID
On Tue, 2019-10-15 at 23:52 +, devloca...@gmail.com wrote: > I would like to log a serious issue with https://SoftwareCollections.org > > It says I need a Fedora ID. > > I go sign up for one, I am asked for a password, I input it twice when > creating the account. > > I get an email that says: "here is your new password" and that I must click > on a link to use this second password to change my password. > Jesus why? I created one already, and then you sent me a new one to use. > > So I go and try to change my password from the one the Fedora ID project gave > me, and I get a fucking error. > > some of the characters I am using are lower case alpha letters > some of the characters I am using are upper case alpha letters > some of the characters I am using are numbers > some of the characters I am using are symbols like ! > > With this, I get a fucking error message that says the following. > > --- > Your password could not be changed. > Change Password > Passphrases need to be of a certain complexity to prevent attackers from > guessing it by having a computer try different combinations of characters in > rapid succession. To make such brute force attacks harder we enforce some > minimum levels of strength: > > A passphrase with symbols, upper and lowercase letters, and digits must be at > least 9 characters So is your password at least 9 characters? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity and the system-upgrade path
On Fri, Oct 4, 2019 at 10:57 AM Stephen Gallagher wrote:
>
> Right now, there are two conflicting requirements in Fedora Modularity
> that we need to resolve.
>
> 1. Once a user has selected a stream, updates should follow that
> stream and not introduce incompatiblities. Selected streams should not
> be changed without direct action from the user.
> 2. So far as possible, Modularity should be invisible to those who
> don't specifically need it. This means being able to set default
> streams so that `yum install package` works for module-provided
> content.
>
> Where this becomes an issue is at system-upgrade time (moving from
> Fedora 30->31 or continuously tracking Rawhide). Because of
> requirement 1, we cannot automatically move users between streams, but
> in the case of release upgrades we often want to move to a new default
> for the distribution.
>
>
> The Modularity WG has generally agreed that we want and need to
> support behavior of the following use-cases:
>
>
> Use Case 1:
>
> On Fedora 30, user Alice runs
>
> yum install Foo
>
> The package "Foo" is provided by a module "foo" with a default stream
> "v1.0". Because it's available in a default stream, the package is
> installed and the module stream "foo:v1.0" is implicitly enabled for
> the system.
>
>
>
> Fedora 31 is released. On Fedora 31, the module "foo" has a new
> default stream "v1.1". When upgrading from Fedora 30 to Fedora 31,
> Alice expects the package Foo she installed to be upgraded to version
> 1.1, because that's what would have happened if it was provided as a
> package from the non-modular repositories.
>
>
>
> Use Case 2:
>
> On Fedora 30, user Bob runs
>
> yum enable foo:v1.0
>
> In this case, the "v1.0" stream of the "foo" module has a dependency
> on the "v2.4" stream of the "bar" module. So when enabling "foo:v1.0",
> the system also implicitly enables "bar:v2.4".
>
>
>
> Fedora 31 is released. On Fedora 31, the module stream "foo:v1.0" now
> depends on "bar:v2.5" instead of "bar:v2.4". The user, caring only
> about "foo:v1.0" would expect the upgrade to complete, adjusting the
> dependencies as needed.
>
>
One thing that came up in this thread was the lack of a concept of
"Obsoletes" in the modular metadata. This was initially done
intentionally, because we had the original constraint 1) above
("Selected streams should not be changed without direct action from
the user.").
However, given that we're talking about the need to migrate defaults
anyway, I think it may be worth considering adding something like an
Obsoletes mechanism, but with a little more nuance.
Alternate Proposal:
Most things from the original proposal in the first message of this
thread remains the same except:
Module stream metadata would gain two new optional attributes,
"upgrades:" and "obsoletes:".
If the "upgrades: " field exists in the metadata, libdnf
should switch to this stream if the following conditions are met:
1) Changing the stream would not introduce conflicts.
2) The stream is marked as `default_enabled` or `dep_enabled`.
The "obsoletes: " field would be stronger. Its use
should require a special exemption (with a strong justification) and
it would cause libdnf to switch from that stream to this one
*unconditionally* (failing the transaction if that transition would
cause conflicts). This would essentially be an "emergency escape" if
we need it.
This would obviate the need for handling changes to the default stream
in favor of having explicit transitions encoded by the packager into
the module metadata.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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 1762085] New: perl-Term-Table-0.014 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1762085 Bug ID: 1762085 Summary: perl-Term-Table-0.014 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Term-Table Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 0.014 Current version/release in rawhide: 0.013-4.fc31 URL: http://search.cpan.org/dist/Term-Table/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/12715/ -- 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 1761523] Upgrade perl-Test-TCP to 2.22
https://bugzilla.redhat.com/show_bug.cgi?id=1761523 --- Comment #6 from Fedora Update System --- perl-Test-TCP-2.22-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-07ab40db53 -- 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 1761157] Plans for EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761157 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- perl-Test-MockObject-1.20180705-5.el8, perl-UNIVERSAL-can-1.20140328-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-64f72a1021 -- 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 1761982] [RFE] EPEL-8 branch for perl-IPC-ShareLite
https://bugzilla.redhat.com/show_bug.cgi?id=1761982 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- perl-IPC-ShareLite-0.17-30.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-2248907bc4 -- 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 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-04183e6fbf scapy-2.4.3-2.el8 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-1c488e885d python-ecdsa-0.13.3-1.el8 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-942baf668f nsd-4.2.2-1.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing borgbackup-1.1.10-2.el8 capstone-4.0.1-9.el8 chromium-77.0.3865.90-3.el8 cros-guest-tools-1.0-0.18.20191015gita93ea04.el8 dh-make-2.201902-1.el8 fpaste-0.4.0.0-1.el8 libprelude-5.1.1-1.el8 libpreludedb-5.1.0-2.el8 nordugrid-arc-nagios-plugins-2.0.0~rc2-1.el8 nss-mdns-0.14.1-3.el8 nuttcp-8.1.4-2.el8 openfortivpn-1.10.0-1.el8 perl-Algorithm-C3-0.10-16.el8 perl-Apache-Session-1.93-15.el8 perl-Authen-Radius-0.31-1.el8 perl-Cache-Cache-1.08-15.el8 perl-Class-ErrorHandler-0.04-14.el8 perl-Crypt-CBC-2.33-25.el8 perl-Crypt-IDEA-1.10-16.el8 perl-Data-HexDump-0.02-28.el8 perl-IPC-ShareLite-0.17-30.el8 perl-Test-MockObject-1.20180705-5.el8 perl-UNIVERSAL-can-1.20140328-15.el8 pjproject-2.9-2.el8 prelude-correlator-5.1.0-1.el8 prelude-lml-5.1.0-2.el8 prelude-lml-rules-5.1.0-1.el8 prelude-manager-5.1.0-2.el8 python-lark-parser-0.7.7-1.el8 python-pathspec-0.6.0-1.el8 tor-0.4.1.6-1.el8 torsocks-2.3.0-1.el8 vim-airline-0.10-5.20191011git297ca3d.el8 zchunk-1.1.2-3.el8 Details about builds: borgbackup-1.1.10-2.el8 (FEDORA-EPEL-2019-8824b61704) A deduplicating backup program with compression and authenticated encryption Update Information: initial release for EPEL8 References: [ 1 ] Bug #1757602 - Request to package borgbackup for EPEL 8 https://bugzilla.redhat.com/show_bug.cgi?id=1757602 capstone-4.0.1-9.el8 (FEDORA-EPEL-2019-3392b128f3) A lightweight multi-platform, multi-architecture disassembly framework Update Information: buld initial capstone package for rhel8 References: [ 1 ] Bug #1761628 - Please build capstone for EPEL8 https://bugzilla.redhat.com/show_bug.cgi?id=1761628 chromium-77.0.3865.90-3.el8 (FEDORA-EPEL-2019-ca762fcbf8) A WebKit (Blink) powered web browser Update Information: Build for EPEL-8. Also nss-mdns. References: [ 1 ] Bug #1761950 - nothing provides nss-mdns(x86-64) needed by wine-core-4.0.2-1.el8.x86_64 https://bugzilla.redhat.com/show_bug.cgi?id=1761950 cros-guest-tools-1.0-0.18.20191015gita93ea04.el8 (FEDORA-EPEL-2019-6769084761) Chromium OS integration meta package Update Information: Update to latest master release and remove cros-adapta theme due to missing dependencies. ChangeLog: * Tue Oct 15 2019 Jason Montleon jmont...@redhat.com 1.0-0.18.20191015gita93ea04 - Update to upstream master - Removed cros-adapta theme for CentOS 8 due to missing dependencies dh-make-2.201902-1.el8 (FEDORA-EPEL-2019-1c665d1c1c) Tool that converts source archives into Debian package source Update Information: Add dh-make to epel 8 References: [ 1 ] Bug #1742709 - dh-make-2.201902 is available https://bugzilla.redhat.com/show_bug.cgi?id=1742709 fpaste-0.4.0.0-1.el8 (FEDORA-EPEL-2019-616dcfad69) A simple tool for
[Bug 1761844] perl-Cache-Cache for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761844 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- perl-Cache-Cache-1.08-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-3ba3478946 -- 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 1761848] perl-Class-ErrorHandler for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761848 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #5 from Fedora Update System --- perl-Class-ErrorHandler-0.04-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-7753b96208 -- 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 1761843] perl-Authen-Radius for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761843 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- perl-Authen-Radius-0.31-1.el8, perl-Data-HexDump-0.02-28.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-f1454f413f -- 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 1761841] perl-Apache-Session for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761841 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- perl-Apache-Session-1.93-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-485ec66ebe -- 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
Failure creating Fedora ID
I would like to log a serious issue with https://SoftwareCollections.org It says I need a Fedora ID. I go sign up for one, I am asked for a password, I input it twice when creating the account. I get an email that says: "here is your new password" and that I must click on a link to use this second password to change my password. Jesus why? I created one already, and then you sent me a new one to use. So I go and try to change my password from the one the Fedora ID project gave me, and I get a fucking error. some of the characters I am using are lower case alpha letters some of the characters I am using are upper case alpha letters some of the characters I am using are numbers some of the characters I am using are symbols like ! With this, I get a fucking error message that says the following. --- Your password could not be changed. Change Password Passphrases need to be of a certain complexity to prevent attackers from guessing it by having a computer try different combinations of characters in rapid succession. To make such brute force attacks harder we enforce some minimum levels of strength: A passphrase with symbols, upper and lowercase letters, and digits must be at least 9 characters A passphrase with upper and lowercase letters and digits must be at least 10 characters A passphrase with lowercase letters and digits must be at least 12 characters A passphrase with letters alone must be made of at least 3 different characters and be at least 20 characters long Remember that these are minimum levels. You are encouraged to make your passphrases longer and more complex than the minimum values. --- Will Fedora Infrastructure please fix this? you are sucking time out of my day by blocking the ID that I need to create log another support issue (that is blocking my fucking day). I had to find a way in here to log this because I can't log a Fedora Infrastructure issue with an ID that I am trying to create on your infrastructure that seems to be broken. I have never seen this where I am issued a new password, after being asked to create one, then after getting the new password told to go change it. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 1756026] [RFE] perl-HTTP-Cache-Transparent epel8 build request
https://bugzilla.redhat.com/show_bug.cgi?id=1756026 Bug 1756026 depends on bug 1756420, which changed state. Bug 1756420 Summary: perl-Test-RequiresInternet for EL8 https://bugzilla.redhat.com/show_bug.cgi?id=1756420 What|Removed |Added Status|ON_QA |CLOSED Resolution|--- |ERRATA -- 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 1756030] [RFE] perl-Unicode-String build for epel8
https://bugzilla.redhat.com/show_bug.cgi?id=1756030 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-Unicode-String-2.10-12 ||.el8 Resolution|--- |ERRATA Last Closed||2019-10-15 23:43:24 --- Comment #4 from Fedora Update System --- perl-Unicode-String-2.10-12.el8 has been pushed to the Fedora EPEL 8 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 1756420] perl-Test-RequiresInternet for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1756420 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-Test-RequiresInternet- ||0.05-15.el8 Resolution|--- |ERRATA Last Closed||2019-10-15 23:43:22 --- Comment #4 from Fedora Update System --- perl-Test-RequiresInternet-0.05-15.el8 has been pushed to the Fedora EPEL 8 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
[EPEL-devel] Fedora EPEL 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-e7cdb404e5 libapreq2-2.13-2.el6 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-5393542b88 opendmarc-1.3.2-1.el6 9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-864944c688 python34-3.4.10-4.el6 9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-ee7bc290a9 golang-1.13.1-1.el6 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-55ba7663e0 yara-3.11.0-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing python-urllib-gssapi-1.0.1-13.el6 wordpress-5.1.3-1.el6 Details about builds: python-urllib-gssapi-1.0.1-13.el6 (FEDORA-EPEL-2019-dd9283f5d0) A GSSAPI/SPNEGO authentication handler for urllib/urllib2 Update Information: - Introduce for epel6 References: [ 1 ] Bug #1755010 - RFE - build python-urllib-gssapi for epel https://bugzilla.redhat.com/show_bug.cgi?id=1755010 wordpress-5.1.3-1.el6 (FEDORA-EPEL-2019-be9b8a3985) Blog tool and publishing platform Update Information: **WordPress 5.1.3 Security Release** **Security Updates** *Props to Evan Ricafort for finding an issue where stored XSS (cross-site scripting) could be added via the Customizer. *Props to J.D. Grimes who found and disclosed a method of viewing unauthenticated posts. *Props to Weston Ruter for finding a way to create a stored XSS to inject Javascript into style tags. *Props to David Newman for highlighting a method to poison the cache of JSON GET requests via the Vary: Origin header. *Props to Eugene Kolodenker who found a server- side request forgery in the way that URLs are validated. *Props to Ben Bidner of the WordPress Security Team who discovered issues related to referrer validation in the admin. ChangeLog: * Tue Oct 15 2019 Remi Collet - 5.1.3-1 - WordPress 5.1.3 Security Release ___ 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 1761523] Upgrade perl-Test-TCP to 2.22
https://bugzilla.redhat.com/show_bug.cgi?id=1761523 --- Comment #5 from Fedora Update System --- perl-Test-TCP-2.22-1.fc30 has been pushed to the Fedora 30 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-c942d609d8 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Recommending proprietary software in Fedora
On Tuesday, October 15, 2019 12:16:06 PM MST Kevin Fenzi wrote: > On Tue, Oct 15, 2019 at 11:42:33AM -0700, John M. Harris Jr wrote: > > On Tuesday, October 15, 2019 11:39:20 AM MST Kevin Fenzi wrote: > > > On Tue, Oct 15, 2019 at 05:05:51PM +, John M. Harris, Jr. wrote: > > > > There is a difference between ignoring proprietary software, and > > > > providing > > > > installation methods for it in the distro. It is against the first of > > > > the > > > > Four Foundations, Freedom, to include these repositories. It's one > > > > thing > > > > if the user seeks out the software and installs it themselves, it's > > > > another if we're baiting them into installing software that does not > > > > provide the four Essential Freedoms. > > > > > > > > Not only that, but we can make no guarantee as to the state of these > > > > repos > > > > or the state of the software, as it is proprietary. This is also a > > > > potential issue for Fedora Legal. > > > > > > As noted upthread, this policy was approved by the Fedora Council and > > > definitely passed through Fedora Legal. > > > > > > I understand that some folks disagree, but I don't think re-litigating > > > it at this point is very productive unless there's some new information > > > that has come to light. > > > > > > kevin > > > > I can't see where recommending *proprietary* software was approved, only > > third party software. > > proprietary software is a subset of third party software right? > > One of the early drivers of this discussion as I recall was chrome, > which is definitely a third party software that is also proprietary. > > Anyhow, I guess if the workstation working group hasn't answered things > to your satisfaction, you're welcome to open a council ticket and ask > them to clarify. > > kevin Proprietary software is certainly a subset of third party software, however, please read the Workstation group's own page about third party software. According to that documentation, the Workstation group itself or FESCo is meant to approve it before it is allowed, and it may require Fedora Legal sign-off, as it may present considerable risk. -- John M. Harris, Jr. Splentity ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: [HEADS UP] Fedora 32 MPFR 4 rebuilds in a side tag
On Tue, Oct 8, 2019 at 2:08 PM Jerry James wrote: > An update of mpfr from version 3.1.6 to version 4.0.2 is about to begin in > Rawhide in a side tag: > > https://fedoraproject.org/wiki/Changes/mpfr-4.0.2 > > If you see a "Rebuild for mpfr 4" commit in your package repo, then please > coordinate with me before building your package in Rawhide. If you do need to > build it, please do so in the side tag, like so: > > $ fedpkg build --target=f32-mpfr4 > > A build of mpfr, and 2 builds apiece of libmpc and gcc will be needed before > the other builds can be started. Given the length of time it takes to build > gcc, it will probably be about 2 days before the other packages can be built. > I estimate those other packages will take 2 to 3 days to build, so overall I > expect 4 to 5 days of building before we can merge back into Rawhide. The builds have all been tagged into Rawhide. Thank you everyone for your patience. If you see any problems related to mpfr, please CC me on any bugs you file. -- 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: 2020 Datacenter Move: Request for comments
I've added about 20 more talks and I believe that the talks are now all public. There are a few left in the "bex review" bucket that are not properly labeled. This may mean the talk didn't get recorded properly. I am sorry for the delays. regards, bex On Thu, Oct 3, 2019 at 9:40 AM Michal Konecny wrote: > > > On 2019-10-02 16:45, Fabio Valentini wrote: > > On Wed, Oct 2, 2019 at 3:07 AM Brian (bex) Exelbierd > > wrote: > >> > >> > >> On Tue, Oct 1, 2019 at 10:05 AM Pavel Valena > wrote: > >>> - Original Message - > From: "Jun Aruga" > To: "Development discussions related to Fedora" < > devel@lists.fedoraproject.org> > Cc: "Fedora Infrastructure" > Sent: Monday, September 30, 2019 8:27:22 PM > Subject: Re: 2020 Datacenter Move: Request for comments > > > There's also a video about it from Flock 2019: > > > https://www.youtube.com/watch?v=phCHilTEQb4=PL0x39xti0_64C75dRUuwlXlfYRgjgdEP4=8=0s > Thanks. But why is the video mode "Unlisted" not public? > > -- > Jun | He - His - Him > >>> Making it public is just a `cosmetic` change IMO, as the `Flock 2019` > list is public. But maybe it enhances visibility(searchability?) also. > >>> > >>> CCing Bex for comments. ;) > >> > >> The ones in this list should be listed. There are about 22 videos > still to be reviewed for final clearance. I am in 2 weeks of f2f meetings > so i am trying to get to them ASAP. > > Looking at the fedora youtube channel and the playlist, *all videos > > except one* (Fedora Flatpaks) are still unlisted. > > > > Fabio > This could explain, why I got notification only for Fedora Flatpaks > video, when I'm subscribed to Fedora Channel on Youtube. > > Michal > > > >> regards, > >> > >> bex > >>> > >>> Thanks, > >>> Pavel > >> > >> > >> -- > >> Brian "bex" Exelbierd (he/him/his) > >> Fedora Community Action & Impact Coordinator > >> @bexelbie | http://www.winglemeyer.org > >> bexel...@redhat.com | b...@pobox.com > >> ___ > >> devel mailing list -- devel@lists.fedoraproject.org > >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org > >> Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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 > > -- > Role: Fedora CPE Team - Software Engineer > IRC: mkonecny > FAS: zlopez > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Brian "bex" Exelbierd (he/him/his) Fedora Community Action & Impact Coordinator @bexelbie | http://www.winglemeyer.org bexel...@redhat.com | b...@pobox.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Recommending proprietary software in Fedora
Kevin Fenzi wrote: > One of the early drivers of this discussion as I recall was chrome, > which is definitely a third party software that is also proprietary. And one where it is entirely pointless to install the proprietary version because there is Chromium (i.e., the Free Software version) in the Fedora repositories. (Or as an alternative, there is also Falkon, which uses QtWebEngine, which is derived from Chromium code.) Support for patent-encumbered codecs can be obtained from RPM Fusion free (chromium-libs-media-freeworld), also as Free Software. (For Falkon, there is qt5-qtwebengine-freeworld.) Support for Flash and Widevine DRM can be obtained (for both Chromium and QtWebEngine) by dropping the respective proprietary blob into the correct location on the file system. Those will still be proprietary, but you do not have to use the proprietary version of the entire browser for that. And I am actually browsing the web just fine with Falkon without those blobs, though of course there are sites requiring them. By actively offering the proprietary Chrome to the users instead of explaining the above, you are actually pointing them towards using proprietary software instead of Free Software for no reason. 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: Modules in Non-Modular Buildroot
Matthew Miller wrote: > Upgrades need to work, though. And they need to work regardless of whether > we ban default modules or not. So, given that, I'm not _really_ seeing big > differences in practice for the user beteen these two proposals, and the > one (no default streams) negates one of the whole intended advantages of > the entire thing. > > What am I missing? I don't see how requiring a non-modular default version negates a central advantage of Modularity. You can still offer all the versions of your module and get all the benefits of Modularity. You just cannot force the module onto all users, because that turned out to be causing many more problems than it solves. 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: Modules in Non-Modular Buildroot
Joe Orton wrote: > If you don't want to ship any of your packages as modules I think that's > great and you should continue doing that. On the other hand, I want to > move a bunch of my packages to module-only because I think I can do a > better job serving Fedora users that way. How so? That is the big question that you are leaving unanswered: In what way do you think you can do a better job serving Fedora users with module- only packages than by also delivering a non-modular version (along with the modular version for those who actually want it)? Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1761491] Request to build perl-Moose for EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761491 Paul Howarth changed: What|Removed |Added Depends On||1762023 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1762023 [Bug 1762023] [RFE] EPEL-8 branch for perl-List-SomeUtils -- 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 1762023] [RFE] EPEL-8 branch for perl-List-SomeUtils
https://bugzilla.redhat.com/show_bug.cgi?id=1762023 Paul Howarth changed: What|Removed |Added Blocks||1761491 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1761491 [Bug 1761491] Request to build perl-Moose for EPEL8 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1762023] New: [RFE] EPEL-8 branch for perl-List-SomeUtils
https://bugzilla.redhat.com/show_bug.cgi?id=1762023 Bug ID: 1762023 Summary: [RFE] EPEL-8 branch for perl-List-SomeUtils Product: Fedora Version: rawhide Status: NEW Component: perl-List-SomeUtils Assignee: jples...@redhat.com Reporter: p...@city-fan.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora This is needed for perl-Moose. Its dependency perl-ExtUtils-HasCompiler is not yet in EPEL-8. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot
On Tue, Oct 15, 2019 at 10:13 AM Adam Williamson wrote: > What's happening right now is the process of us trying something out > and finding out where the problems are. That's what happens when you > invent new stuff, it's harder than just carrying on doing the old > stuff. I agree Adam. I think Neal's summary helps and I appreciate it. I agree it's negative, but I think there is one additional aspect from my point of view: There are some proponents of Modularity that keep pitching the idea to me that everything I do needs to go into a module, like, yesterday. Maybe we can tone that messaging down a bit around Fedora for a while. - Ken - Ken ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 1762022] perl-Crypt-DH-GMP for EL 8
https://bugzilla.redhat.com/show_bug.cgi?id=1762022 --- Comment #1 from Xavier Bachelot --- Some deps are missing: No matching package to install: 'perl(Crypt::DH)' No matching package to install: 'perl(Math::BigInt::GMP)' No matching package to install: 'perl(Module::Install::XSUtil)' -- 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 1762022] perl-Crypt-DH-GMP for EL 8
https://bugzilla.redhat.com/show_bug.cgi?id=1762022 Xavier Bachelot changed: What|Removed |Added Blocks||1762021 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1762021 [Bug 1762021] perl-Net-OpenID-Common for EL8 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1762021] perl-Net-OpenID-Common for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1762021 Xavier Bachelot changed: What|Removed |Added Depends On||1762022 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1762022 [Bug 1762022] perl-Crypt-DH-GMP for EL 8 -- 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 1762022] New: perl-Crypt-DH-GMP for EL 8
https://bugzilla.redhat.com/show_bug.cgi?id=1762022 Bug ID: 1762022 Summary: perl-Crypt-DH-GMP for EL 8 Product: Fedora EPEL Version: epel8 Status: NEW Component: perl-Crypt-DH-GMP Assignee: jples...@redhat.com Reporter: xav...@bachelot.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Hi, Could you please build perl-Crypt-DH-GMP in EPEL 8 ? It's in the dependency chain of a package I'd like to build for EPEL 8. Regards, Xavier -- 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 1761858] perl-Net-OpenID-Server for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761858 Xavier Bachelot changed: What|Removed |Added Depends On||1762021 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1762021 [Bug 1762021] perl-Net-OpenID-Common for EL8 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1762021] perl-Net-OpenID-Common for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1762021 Xavier Bachelot changed: What|Removed |Added Blocks||1761858 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1761858 [Bug 1761858] perl-Net-OpenID-Server for EL8 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1762021] New: perl-Net-OpenID-Common for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1762021 Bug ID: 1762021 Summary: perl-Net-OpenID-Common for EL8 Product: Fedora EPEL Version: epel8 Status: NEW Component: perl-Net-OpenID-Common Assignee: jples...@redhat.com Reporter: xav...@bachelot.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Hi, Could you please build perl-Net-OpenID-Common in EPEL 8 ? It's in the dependency chain of a package I'd like to build for EPEL 8. Regards, Xavier -- 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 1761860] perl-String-Random for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761860 --- Comment #1 from Xavier Bachelot --- master rebuilds properly against epel8 target. -- 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 1761856] perl-HTML-Template for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761856 --- Comment #1 from Xavier Bachelot --- No matching package to install: 'perl(GTop)' No matching package to install: 'perl(IPC::SharedCache)' -- 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 1761855] perl-GD-SecurityImage for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761855 --- Comment #1 from Xavier Bachelot --- Missing BR: perl-GD is in epel-testing (perl-GD-2.71-1.el8). -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1761854] perl-FCGI-ProcManager for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761854 --- Comment #1 from Xavier Bachelot --- master builds properly against epel8 target. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1761852] perl-Email-Sender for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761852 Xavier Bachelot changed: What|Removed |Added Depends On||1761157 --- Comment #1 from Xavier Bachelot --- Quite some missing deps... No matching package to install: 'perl(Email::Abstract) >= 3.006' No matching package to install: 'perl(Email::Address)' No matching package to install: 'perl(Email::Simple) >= 1.998' No matching package to install: 'perl(Moo) >= 1.08' No matching package to install: 'perl(Moo::Role)' No matching package to install: 'perl(MooX::Types::MooseLike::Base)' No matching package to install: 'perl(Sub::Override)' No matching package to install: 'perl(Test::MinimumVersion)' No matching package to install: 'perl(Test::MockObject)' No matching package to install: 'perl(Throwable::Error) >= 0.23' perl-Test-MockObject has a bug filed (1761157) perl-Test-MinimumVersion has no bug, but built as perl-Test-MinimumVersion-0.101082-11.el8 The others don't have bug or build, I'll file bug for them : perl-Email-Abstract perl-Email-Address perl-Email-Simple perl-Moo perl-MooX-Types-MooseLike perl-Sub-Override perl-Throwable Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1761157 [Bug 1761157] Plans for EPEL8 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1761157] Plans for EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761157 Xavier Bachelot changed: What|Removed |Added Blocks||1761852 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1761852 [Bug 1761852] perl-Email-Sender for EL8 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot
Tomasz Torcz writes: > On Tue, Oct 15, 2019 at 01:56:11PM -0400, Robbie Harwood wrote: >> Matthew Miller writes: >> >> > On Tue, Oct 15, 2019 at 12:36:15PM +0200, Miro Hrončok wrote: >> >>> As package maintainers we all make technical decisions which have >> >>> significant impact on our users every day - whether that's in the >> >>> choice of defaults, choice of build flags, or whatever. Honestly >> >>> delivering as modules-vs-non-modules is a completely trivial issue >> >>> compared to most of the stuff I spend time on. If "yum install X" >> >>> still works most people just don't care about the RPM/dnf/repo >> >>> mechanics behind that. >> >> >> >> Except it works only half way. The installation works. Later, >> >> dependencies are broken. Upgrades are broken. "yum remove X" does not >> >> undo the action completely. >> >> >> >> The main issue is: user just enabled a module without doing it >> >> explicitly. The user needs to know how to handle modules in order to >> >> recover. >> > >> > I never expect "yum remove X" to be the inverse of "yum install >> > X". DNF's magical leaf tracking makes it a bit more so, but not >> > exactly. So, I don't think we should make that a very high priority >> > concern (although if we can improve it, so much the better). >> >> I don't think it's an unreasonable expectation, especially for those >> coming from APT land (Debian, Ubuntu) where `apt install foo` *is* the >> inverse operation of `apt remove foo`. > > It isn't, you need to supplement it with `apt autoremove` to get rid > of auto-installed dependencies. > We have `dnf history undo X` to invert installation command. Ah, you're right. It is the case with aptitude, but not with apt or apt-get. Sorry for the noise. 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
[Bug 1761843] perl-Authen-Radius for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761843 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #2 from Fedora Update System --- FEDORA-EPEL-2019-f1454f413f has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f1454f413f -- 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 1761851] perl-Crypt-URandom for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761851 --- Comment #1 from Xavier Bachelot --- master rebuilds properly against epel8 target. -- 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 1761841] perl-Apache-Session for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761841 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #2 from Fedora Update System --- FEDORA-EPEL-2019-485ec66ebe has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-485ec66ebe -- 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 1761850] perl-Crypt-Rijndael for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761850 --- Comment #1 from Xavier Bachelot --- master rebuilds properly against epel8 target. -- 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 1761844] perl-Cache-Cache for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761844 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #2 from Fedora Update System --- FEDORA-EPEL-2019-3ba3478946 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-3ba3478946 -- 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 1761846] perl-Config-IniFiles for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761846 --- Comment #1 from Xavier Bachelot --- master rebuilds properly against epel8 target. -- 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 1761860] perl-String-Random for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761860 Xavier Bachelot changed: What|Removed |Added Blocks||1761842 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1761842 [Bug 1761842] perl-Authen-Captcha for EL8 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1761842] perl-Authen-Captcha for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761842 Xavier Bachelot changed: What|Removed |Added Depends On||1761860 --- Comment #1 from Xavier Bachelot --- perl-GD has been built already and is in epel-testing (perl-GD-2.71-1.el8). perl-String-Random is missing though. Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1761860 [Bug 1761860] perl-String-Random for EL8 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1761845] perl-Cache-Memcached for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761845 --- Comment #1 from Xavier Bachelot --- Master rebuilds properly against epel8 target. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Packaging graph-tool: help speeding up build
On Tue, Oct 15, 2019 14:17:50 -0500, Richard Shaw wrote: > On Tue, Oct 15, 2019 at 11:48 AM Ankur Sinha wrote: > > > One option is to roll the dice with -j2 and hope you get one of the nice > builders. May be quicker overall to risk a OOM failure on a build or two until > you get a good builder :) The koji build got all the way to the end with j1, and it only took 22 hours. At least we know it can be done XD. https://koji.fedoraproject.org/koji/taskinfo?taskID=38295704 I'm going to try some spec file tricks to only use -j2 if _smp_build_ncpus > 6, which implies we're using a better builder. Hopefully that'll speed things up a bit, otherwise we just let it run for a day. -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London 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: Help needed with failing PPC build: cannot find MPI with openmpi
Hi Orion, On Tue, Sep 17, 2019 15:37:57 -0600, Orion Poplawski wrote: > > I have no idea as I really don't know exactly what --enable-mpi-cxx does. I > was surprised that it didn't appear to affect more packages. F30 still seems to suffer from this issue. Any chance the fix could be include there also please? https://koji.fedoraproject.org/koji/taskinfo?taskID=38314982 -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London 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
[Bug 1761982] [RFE] EPEL-8 branch for perl-IPC-ShareLite
https://bugzilla.redhat.com/show_bug.cgi?id=1761982 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #2 from Fedora Update System --- FEDORA-EPEL-2019-2248907bc4 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-2248907bc4 -- 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 1761841] perl-Apache-Session for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761841 Paul Howarth changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from Paul Howarth --- https://pagure.io/releng/fedora-scm-requests/issue/18326 https://pagure.io/releng/fedora-scm-requests/issue/18327 -- 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 1761848] perl-Class-ErrorHandler for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761848 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #4 from Fedora Update System --- FEDORA-EPEL-2019-7753b96208 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-7753b96208 -- 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 1761981] perl-SNMP-Info-3.70 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1761981 --- Comment #2 from Upstream Release Monitoring --- the-new-hotness/release-monitoring@fedoraproject.org's scratch build of perl-SNMP-Info-3.70-1.fc29.src.rpm for rawhide completed http://koji.fedoraproject.org/koji/taskinfo?taskID=38313374 -- 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 1761988] perl-Crypt-DES for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761988 --- Comment #1 from Xavier Bachelot --- perl-Crypt-CBC-2.33-25.el8 has already been built and can be added as an override, thanks to Paul Howarth. -- 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 1761849] perl-Crypt-DES_EDE3 for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761849 Xavier Bachelot changed: What|Removed |Added Depends On||1761988 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1761988 [Bug 1761988] perl-Crypt-DES for EL8 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1761988] perl-Crypt-DES for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761988 Xavier Bachelot changed: What|Removed |Added Blocks||1761849 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1761849 [Bug 1761849] perl-Crypt-DES_EDE3 for EL8 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1761988] New: perl-Crypt-DES for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761988 Bug ID: 1761988 Summary: perl-Crypt-DES for EL8 Product: Fedora EPEL Version: epel8 Status: NEW Component: perl-Crypt-DES Assignee: jpazdzi...@redhat.com Reporter: xav...@bachelot.org QA Contact: extras...@fedoraproject.org CC: jpazdzi...@redhat.com, perl-devel@lists.fedoraproject.org, st...@silug.org Target Milestone: --- Classification: Fedora Hi, Could you please build perl-Crypt-DES in EPEL 8 ? It's in the dependency chain of a package I'd like to build for EPEL 8. Regards, Xavier -- 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 1761843] perl-Authen-Radius for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761843 Paul Howarth changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from Paul Howarth --- https://pagure.io/releng/fedora-scm-requests/issue/18324 https://pagure.io/releng/fedora-scm-requests/issue/18325 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Packaging graph-tool: help speeding up build
On Tue, Oct 15, 2019 at 11:48 AM Ankur Sinha wrote: > On Tue, Oct 15, 2019 11:14:42 -0500, Richard Shaw wrote: > > I was doing good until I hit this one, went through all 8GB of swap... > > > > g++: fatal error: Killed signal terminated program cc1plus > > compilation terminated. > > make[4]: *** [Makefile:598: graph_community_network_eavg_imp1.lo] Error 1 > > make[4]: *** Waiting for unfinished jobs > > Ugh, looks like it'll have to be -j1. I spoke to folks in > #fedora-releng, and while we do have builders with 128gigs of RAM along > with builders with 16gigs, there's no way to force a build to use the > one or the other---it's just luck. I could maybe detect what machine it is > in > the spec depending on the value of _smp_mflags.. > One option is to roll the dice with -j2 and hope you get one of the nice builders. May be quicker overall to risk a OOM failure on a build or two until you get a good builder :) Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Recommending proprietary software in Fedora
On Tue, Oct 15, 2019 at 11:42:33AM -0700, John M. Harris Jr wrote: > On Tuesday, October 15, 2019 11:39:20 AM MST Kevin Fenzi wrote: > > On Tue, Oct 15, 2019 at 05:05:51PM +, John M. Harris, Jr. wrote: > > > There is a difference between ignoring proprietary software, and providing > > > installation methods for it in the distro. It is against the first of the > > > Four Foundations, Freedom, to include these repositories. It's one thing > > > if the user seeks out the software and installs it themselves, it's > > > another if we're baiting them into installing software that does not > > > provide the four Essential Freedoms. > > > > > > Not only that, but we can make no guarantee as to the state of these repos > > > or the state of the software, as it is proprietary. This is also a > > > potential issue for Fedora Legal. > > As noted upthread, this policy was approved by the Fedora Council and > > definitely passed through Fedora Legal. > > > > I understand that some folks disagree, but I don't think re-litigating > > it at this point is very productive unless there's some new information > > that has come to light. > > > > kevin > > I can't see where recommending *proprietary* software was approved, only > third > party software. proprietary software is a subset of third party software right? One of the early drivers of this discussion as I recall was chrome, which is definitely a third party software that is also proprietary. Anyhow, I guess if the workstation working group hasn't answered things to your satisfaction, you're welcome to open a council ticket and ask them to clarify. 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
[Bug 1761848] perl-Class-ErrorHandler for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761848 --- Comment #3 from Xavier Bachelot --- https://pagure.io/releng/fedora-scm-requests/issue/18318 https://pagure.io/releng/fedora-scm-requests/issue/18319 -- 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 1761849] perl-Crypt-DES_EDE3 for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761849 --- Comment #4 from Xavier Bachelot --- https://pagure.io/releng/fedora-scm-requests/issue/18316 https://pagure.io/releng/fedora-scm-requests/issue/18317 -- 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 1761982] [RFE] EPEL-8 branch for perl-IPC-ShareLite
https://bugzilla.redhat.com/show_bug.cgi?id=1761982 Xavier Bachelot changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|jples...@redhat.com |xav...@bachelot.org --- Comment #1 from Xavier Bachelot --- https://pagure.io/releng/fedora-scm-requests/issue/18314 https://pagure.io/releng/fedora-scm-requests/issue/18315 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: [NeuroFedora] Open NeuroFedora team meeting: 1500 UTC on Thursday, 17th October
Hello, On Tue, Oct 15, 2019 13:58:11 +0530, Aniket Pradhan wrote: > > In the "Neuroscience query of the week" section, we hope to provide > attendees with the chance to ask about a neuroscience topic that they > are curious about. I listened to this podcast today, and thought it was very good. Instead of discussing a paper, could we listen to this and discuss it at the meeting? It's intended for a non-expert audience like us. https://brainsciencepodcast.com/bsp/2019/159-mitchelll It speaks about how our brain develops, what affects it, and how that shapes us. It's about an hour long. You can download it using any Podcast app and listen to it on the commute, or while you cook dinner like I did ;) (I use Antennapod on my Android: https://github.com/AntennaPod/AntennaPod) -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London 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
[Bug 1761983] New: Requesting perl-Redis for EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761983 Bug ID: 1761983 Summary: Requesting perl-Redis for EPEL8 Product: Fedora EPEL Version: epel8 OS: Linux Status: NEW Component: perl-Redis Assignee: dd...@cpan.org Reporter: kel...@retromud.org QA Contact: extras...@fedoraproject.org CC: dd...@cpan.org, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Description of problem: perl-Redis is missing from EPEL8. Requires maintainer to request a branch. Willing to help if maintainer needs it. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1761982] [RFE] EPEL-8 branch for perl-IPC-ShareLite
https://bugzilla.redhat.com/show_bug.cgi?id=1761982 Paul Howarth changed: What|Removed |Added Blocks||1761844 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1761844 [Bug 1761844] perl-Cache-Cache for EL8 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Recommending proprietary software in Fedora
On Tuesday, October 15, 2019 11:39:20 AM MST Kevin Fenzi wrote: > On Tue, Oct 15, 2019 at 05:05:51PM +, John M. Harris, Jr. wrote: > > There is a difference between ignoring proprietary software, and providing > > installation methods for it in the distro. It is against the first of the > > Four Foundations, Freedom, to include these repositories. It's one thing > > if the user seeks out the software and installs it themselves, it's > > another if we're baiting them into installing software that does not > > provide the four Essential Freedoms. > > > > Not only that, but we can make no guarantee as to the state of these repos > > or the state of the software, as it is proprietary. This is also a > > potential issue for Fedora Legal. > As noted upthread, this policy was approved by the Fedora Council and > definitely passed through Fedora Legal. > > I understand that some folks disagree, but I don't think re-litigating > it at this point is very productive unless there's some new information > that has come to light. > > kevin I can't see where recommending *proprietary* software was approved, only third party software. -- John M. Harris, Jr. Splentity ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 1761844] perl-Cache-Cache for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761844 Paul Howarth changed: What|Removed |Added Status|NEW |ASSIGNED Depends On||1761982 --- Comment #1 from Paul Howarth --- https://pagure.io/releng/fedora-scm-requests/issue/18312 https://pagure.io/releng/fedora-scm-requests/issue/18313 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1761982 [Bug 1761982] [RFE] EPEL-8 branch for perl-IPC-ShareLite -- 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 1761982] New: [RFE] EPEL-8 branch for perl-IPC-ShareLite
https://bugzilla.redhat.com/show_bug.cgi?id=1761982 Bug ID: 1761982 Summary: [RFE] EPEL-8 branch for perl-IPC-ShareLite Product: Fedora EPEL Version: epel8 Status: NEW Component: perl-IPC-ShareLite Assignee: jples...@redhat.com Reporter: p...@city-fan.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org, st...@silug.org, xav...@bachelot.org Target Milestone: --- Classification: Fedora This is needed for perl-Cache-Cache. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Recommending proprietary software in Fedora
On Tue, Oct 15, 2019 at 05:05:51PM +, John M. Harris, Jr. wrote: > There is a difference between ignoring proprietary software, and providing > installation methods for it in the distro. It is against the first of the > Four Foundations, Freedom, to include these repositories. It's one thing if > the user seeks out the software and installs it themselves, it's another if > we're baiting them into installing software that does not provide the four > Essential Freedoms. > > Not only that, but we can make no guarantee as to the state of these repos or > the state of the software, as it is proprietary. This is also a potential > issue for Fedora Legal. As noted upthread, this policy was approved by the Fedora Council and definitely passed through Fedora Legal. I understand that some folks disagree, but I don't think re-litigating it at this point is very productive unless there's some new information that has come to light. 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
[Bug 1761981] New: perl-SNMP-Info-3.70 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1761981 Bug ID: 1761981 Summary: perl-SNMP-Info-3.70 is available Product: Fedora Version: rawhide Status: NEW Component: perl-SNMP-Info Keywords: FutureFeature, Triaged Assignee: w...@gouldfamily.org Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: ktdre...@ktdreyer.com, perl-devel@lists.fedoraproject.org, w...@gouldfamily.org Target Milestone: --- Classification: Fedora Latest upstream release: 3.70 Current version/release in rawhide: 3.68-3.fc31 URL: http://search.cpan.org/dist/SNMP-Info/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/3318/ -- 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 1761981] perl-SNMP-Info-3.70 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1761981 --- Comment #1 from Upstream Release Monitoring --- Created attachment 1626125 --> https://bugzilla.redhat.com/attachment.cgi?id=1626125=edit [patch] Update to 3.70 (#1761981) -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot
On Tue, Oct 15, 2019 at 01:56:11PM -0400, Robbie Harwood wrote: > Matthew Miller writes: > > > On Tue, Oct 15, 2019 at 12:36:15PM +0200, Miro Hrončok wrote: > >>> As package maintainers we all make technical decisions which have > >>> significant impact on our users every day - whether that's in the > >>> choice of defaults, choice of build flags, or whatever. Honestly > >>> delivering as modules-vs-non-modules is a completely trivial issue > >>> compared to most of the stuff I spend time on. If "yum install X" > >>> still works most people just don't care about the RPM/dnf/repo > >>> mechanics behind that. > >> > >> Except it works only half way. The installation works. Later, > >> dependencies are broken. Upgrades are broken. "yum remove X" does not > >> undo the action completely. > >> > >> The main issue is: user just enabled a module without doing it > >> explicitly. The user needs to know how to handle modules in order to > >> recover. > > > > I never expect "yum remove X" to be the inverse of "yum install > > X". DNF's magical leaf tracking makes it a bit more so, but not > > exactly. So, I don't think we should make that a very high priority > > concern (although if we can improve it, so much the better). > > I don't think it's an unreasonable expectation, especially for those > coming from APT land (Debian, Ubuntu) where `apt install foo` *is* the > inverse operation of `apt remove foo`. It isn't, you need to supplement it with `apt autoremove` to get rid of auto-installed dependencies. We have `dnf history undo X` to invert installation command. -- Tomasz .. oo o. oo o. .o .o o. o. oo o. .. Torcz.. .o .o .o .o oo oo .o .. .. oo oo o.o.o. .o .. o. o. o. o. o. o. oo .. .. o. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Way to visualize where Fedora contributors are around the world?
Hi Marius and all, I just don't see anything. Just a normal map. I don't get any security warning, but I don't see any data either. Javascript is working elsewhere for me, so I don't think that's the issue. Kind regards, Lailah On Sat, 12 Oct 2019 at 23:19, Marius Schwarz wrote: > hi, > > Am 12.10.19 um 22:38 schrieb Silvia Sánchez: > > > > I don't think the Ambassadors map is still working. I opened it but it > > shows only the geography, not Ambassadors or contributors pinpointed. > > I couldn't even see myself. > > > > It does work,sort of, but some graphics are missing. The positions are > just white boxes with a border. > > It needs Javascript and the tiles are coming in via http, while the > website has https in use => security warning. > > 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 > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Co
Dear all, You are kindly invited to the meeting: EPEL Steering Co on 2019-10-16 from 18:00:00 to 19:00:00 GMT At freenode@fedora-meeting The meeting will be about: This is the weekly EPEL Steering Committee Meeting. A general agenda is the following: #meetingname EPEL #topic Intros #topic Old Business #topic EPEL-6 #topic EPEL-7 #topic EPEL-8 #topic Openfloor #endmeeting Source: https://apps.fedoraproject.org/calendar/meeting/9364/ ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot
Matthew Miller writes: > On Tue, Oct 15, 2019 at 12:36:15PM +0200, Miro Hrončok wrote: >>> As package maintainers we all make technical decisions which have >>> significant impact on our users every day - whether that's in the >>> choice of defaults, choice of build flags, or whatever. Honestly >>> delivering as modules-vs-non-modules is a completely trivial issue >>> compared to most of the stuff I spend time on. If "yum install X" >>> still works most people just don't care about the RPM/dnf/repo >>> mechanics behind that. >> >> Except it works only half way. The installation works. Later, >> dependencies are broken. Upgrades are broken. "yum remove X" does not >> undo the action completely. >> >> The main issue is: user just enabled a module without doing it >> explicitly. The user needs to know how to handle modules in order to >> recover. > > I never expect "yum remove X" to be the inverse of "yum install > X". DNF's magical leaf tracking makes it a bit more so, but not > exactly. So, I don't think we should make that a very high priority > concern (although if we can improve it, so much the better). I don't think it's an unreasonable expectation, especially for those coming from APT land (Debian, Ubuntu) where `apt install foo` *is* the inverse operation of `apt remove foo`. 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
[Bug 1761859] perl-Regexp-Assemble for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1761859 Paul Howarth changed: What|Removed |Added Status|NEW |ASSIGNED Depends On||1761961 --- Comment #1 from Paul Howarth --- https://pagure.io/releng/fedora-scm-requests/issue/18310 https://pagure.io/releng/fedora-scm-requests/issue/18311 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1761961 [Bug 1761961] [RFE] EPEL-8 branch for perl-Test-File-Contents -- 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 1761961] [RFE] EPEL-8 branch for perl-Test-File-Contents
https://bugzilla.redhat.com/show_bug.cgi?id=1761961 Paul Howarth changed: What|Removed |Added Blocks||1761859 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1761859 [Bug 1761859] perl-Regexp-Assemble for EL8 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1761961] New: [RFE] EPEL-8 branch for perl-Test-File-Contents
https://bugzilla.redhat.com/show_bug.cgi?id=1761961 Bug ID: 1761961 Summary: [RFE] EPEL-8 branch for perl-Test-File-Contents Product: Fedora EPEL Version: epel8 Status: NEW Component: perl-Test-File-Contents Assignee: jples...@redhat.com Reporter: p...@city-fan.org QA Contact: extras...@fedoraproject.org CC: iarn...@gmail.com, jples...@redhat.com, perl-devel@lists.fedoraproject.org, st...@silug.org Target Milestone: --- Classification: Fedora This is needed for perl-Regexp-Assemble. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Modularity and the system-upgrade path
On 15. 10. 19 19:13, Kevin Fenzi wrote: So, I see the following modules (in rawhide anyhow) that don't seem to have non modular versions: avocado cri-o django dwm eclipse gimp jmc lizardfs mysql ninja perl-bootstrap stratis Do all of those have default streams? I don't know all but I think that at least gimp, django, mysql have nonmodular "dafault" versions. In case of gimp, it has both nonmodular version and a default modular stream. perl-bootstrap is probably needed only to bootstrap Perl. Eclipse has a nonmodular version that fails to install because other stuff has default streams. Yes, some of the modules would need to be "converted back". Better to do it when we can still count them on our fingers. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot
On Tue, Oct 15, 2019 at 12:52 PM Josh Boyer wrote: > > On Tue, Oct 15, 2019 at 12:27 PM Neal Gompa wrote: > > > > On Tue, Oct 15, 2019 at 12:13 PM Adam Williamson > > wrote: > > > > > > On Tue, 2019-10-15 at 11:35 -0400, Neal Gompa wrote: > > > > On Tue, Oct 15, 2019 at 11:22 AM Matthew Miller > > > > wrote: > > > > > On Tue, Oct 15, 2019 at 12:36:15PM +0200, Miro Hrončok wrote: > > > > > > > As package maintainers we all make technical decisions which have > > > > > > > significant impact on our users every day - whether that's in the > > > > > > > choice > > > > > > > of defaults, choice of build flags, or whatever. Honestly > > > > > > > delivering as > > > > > > > modules-vs-non-modules is a completely trivial issue compared to > > > > > > > most of > > > > > > > the stuff I spend time on. If "yum install X" still works most > > > > > > > people > > > > > > > just don't care about the RPM/dnf/repo mechanics behind that. > > > > > > > > > > > > Except it works only half way. The installation works. Later, > > > > > > dependencies are broken. Upgrades are broken. "yum remove X" does > > > > > > not undo the action completely. > > > > > > > > > > > > The main issue is: user just enabled a module without doing it > > > > > > explicitly. The user needs to know how to handle modules in order to > > > > > > recover. > > > > > > > > > > I never expect "yum remove X" to be the inverse of "yum install X". > > > > > DNF's > > > > > magical leaf tracking makes it a bit more so, but not exactly. So, I > > > > > don't > > > > > think we should make that a very high priority concern (although if > > > > > we can > > > > > improve it, so much the better). > > > > > > > > > > Upgrades need to work, though. And they need to work regardless of > > > > > whether > > > > > we ban default modules or not. So, given that, I'm not _really_ > > > > > seeing big > > > > > differences in practice for the user beteen these two proposals, and > > > > > the one > > > > > (no default streams) negates one of the whole intended advantages of > > > > > the > > > > > entire thing. > > > > > > > > > > What am I missing? > > > > > > > > > > > > > Upgrades can never work without changing fundamental properties of > > > > modules. > > > > > > > > There are two traits of modules that break everything: > > > > * Module activation is introduces a hard lock of content source > > > > * There is no concept of module transitions > > > > > > > > In the RHEL world, these two qualities are not great, but they are > > > > serviceable (RHEL 9 is going to hurt!). In the Fedora world, they make > > > > having default modules essentially untenable. It could even be argued > > > > that non-default modules are not serviceable either. > > > > > > > > There is no way in modularity to say that a module is being replaced > > > > with another. There's also no way to say that a module is going away > > > > and transition accordingly. Moreover, since modules have a strong > > > > dependency on an abstract property that is defined as a consequence of > > > > the system content (the "platform" module), it is not possible to have > > > > orphan modules that are still binary compatible as you upgrade. > > > > Finally, modularization and foregoing non-modular versions of content > > > > has an implicit commitment that you *never* demodularize because there > > > > is no module transition capabilities in the modularity technology. > > > > > > > > These flaws boil down to Fedora Modularity being a failure because the > > > > technology does not account for the needs of Fedora as a distribution, > > > > as a project, or as a community. > > > > > > I think this is actually a very cogent summary of the major problems > > > we're dealing with in modularity right now, but it's *also* needlessly > > > negative. > > > > > > Inventing new stuff is hard. You rarely get it right the first time. > > > Speaking personally here I think it was a big mistake to do this second > > > version of Modularity as fast as we did and drop it into RHEL 8 before > > > it had been in Fedora for two minutes, that was an unforced error; but > > > even if we hadn't done that, I'm not surprised the second cut at > > > Modularity isn't perfect. The second cut at RPM wasn't perfect either, > > > that's why we're on 4.x not 2.x. :) > > > > > > What's happening right now is the process of us trying something out > > > and finding out where the problems are. That's what happens when you > > > invent new stuff, it's harder than just carrying on doing the old > > > stuff. > > > > > > So: I'm on board with most of what you say here, but there's no need to > > > say it means Modularity is "a failure". It means right now it's not > > > entirely baked and we're realizing the concept needs extending and > > > perhaps reworking a bit, just like we realized with the *first* cut at > > > Modularity which we abandoned between a Beta release and a Final > > > release. This is causing us to have to
Re: Recommending proprietary software in Fedora
There is a difference between ignoring proprietary software, and providing installation methods for it in the distro. It is against the first of the Four Foundations, Freedom, to include these repositories. It's one thing if the user seeks out the software and installs it themselves, it's another if we're baiting them into installing software that does not provide the four Essential Freedoms. Not only that, but we can make no guarantee as to the state of these repos or the state of the software, as it is proprietary. This is also a potential issue for Fedora Legal. On October 15, 2019 5:00:37 PM UTC, Przemek Klosowski via devel wrote: >On 10/14/19 6:19 AM, Kevin Kofler wrote: >> mcatanz...@gnome.org wrote: >>> John, the third-party software policy was approved after a long and >>> contentious debate: >>> >>> >https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpagure.io%2FFedora-Council%2Ftickets%2Fissue%2F121data=02%7C01%7Cprzemek.klosowski%40nist.gov%7Cb6880a9e2cb041668b5508d7509033d6%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637066452583661821sdata=%2BJLzyHYQO1Oh5yBaRTF9AxAhX9ZD2tQOldCoBBtieRE%3Dreserved=0 >> That policy is still completely at odds with the Fedora objectives. >> Recommending proprietary software is entirely incompatible with the >Freedom >> goal and actively works against it. So this policy needs to be >revisited to >> exclude proprietary software or repealed entirely. >> >It's a difficult choice. My understanding is that Fedora does not >'recommend' proprietary software, but rather allows it to be found, in >response to people searching for it by either specific terms (package >name) or specific functionality. > >Are you arguing that the only choice compatible with Fedora principles >is to ignore the existence of proprietary software? I think this would >be contrary to the interests of the users. Speaking for myself, when >people ask me about image editing software, I say that I recommend the >FOSS product GIMP, but that there is also an excellent proprietary >Photoshop. I am not comfortable just mentioning one to the exclusion of > >the other. > >I think the overall goal for FOSS software is to be technically >excellent and compete successfully with proprietary software. Ignoring >non-FOSS software is actually counterproductive to that goal. >___ >devel mailing list -- devel@lists.fedoraproject.org >To unsubscribe send an email to devel-le...@lists.fedoraproject.org >Fedora Code of Conduct: >https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >List Archives: >https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Sent from my mobile device. Please excuse my brevity.___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Recommending proprietary software in Fedora
On 10/14/19 6:19 AM, Kevin Kofler wrote: mcatanz...@gnome.org wrote: John, the third-party software policy was approved after a long and contentious debate: https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpagure.io%2FFedora-Council%2Ftickets%2Fissue%2F121data=02%7C01%7Cprzemek.klosowski%40nist.gov%7Cb6880a9e2cb041668b5508d7509033d6%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637066452583661821sdata=%2BJLzyHYQO1Oh5yBaRTF9AxAhX9ZD2tQOldCoBBtieRE%3Dreserved=0 That policy is still completely at odds with the Fedora objectives. Recommending proprietary software is entirely incompatible with the Freedom goal and actively works against it. So this policy needs to be revisited to exclude proprietary software or repealed entirely. It's a difficult choice. My understanding is that Fedora does not 'recommend' proprietary software, but rather allows it to be found, in response to people searching for it by either specific terms (package name) or specific functionality. Are you arguing that the only choice compatible with Fedora principles is to ignore the existence of proprietary software? I think this would be contrary to the interests of the users. Speaking for myself, when people ask me about image editing software, I say that I recommend the FOSS product GIMP, but that there is also an excellent proprietary Photoshop. I am not comfortable just mentioning one to the exclusion of the other. I think the overall goal for FOSS software is to be technically excellent and compete successfully with proprietary software. Ignoring non-FOSS software is actually counterproductive to that goal. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Modules in Non-Modular Buildroot
On Tue, Oct 15, 2019 at 12:27 PM Neal Gompa wrote: > > On Tue, Oct 15, 2019 at 12:13 PM Adam Williamson > wrote: > > > > On Tue, 2019-10-15 at 11:35 -0400, Neal Gompa wrote: > > > On Tue, Oct 15, 2019 at 11:22 AM Matthew Miller > > > wrote: > > > > On Tue, Oct 15, 2019 at 12:36:15PM +0200, Miro Hrončok wrote: > > > > > > As package maintainers we all make technical decisions which have > > > > > > significant impact on our users every day - whether that's in the > > > > > > choice > > > > > > of defaults, choice of build flags, or whatever. Honestly > > > > > > delivering as > > > > > > modules-vs-non-modules is a completely trivial issue compared to > > > > > > most of > > > > > > the stuff I spend time on. If "yum install X" still works most > > > > > > people > > > > > > just don't care about the RPM/dnf/repo mechanics behind that. > > > > > > > > > > Except it works only half way. The installation works. Later, > > > > > dependencies are broken. Upgrades are broken. "yum remove X" does > > > > > not undo the action completely. > > > > > > > > > > The main issue is: user just enabled a module without doing it > > > > > explicitly. The user needs to know how to handle modules in order to > > > > > recover. > > > > > > > > I never expect "yum remove X" to be the inverse of "yum install X". > > > > DNF's > > > > magical leaf tracking makes it a bit more so, but not exactly. So, I > > > > don't > > > > think we should make that a very high priority concern (although if we > > > > can > > > > improve it, so much the better). > > > > > > > > Upgrades need to work, though. And they need to work regardless of > > > > whether > > > > we ban default modules or not. So, given that, I'm not _really_ seeing > > > > big > > > > differences in practice for the user beteen these two proposals, and > > > > the one > > > > (no default streams) negates one of the whole intended advantages of the > > > > entire thing. > > > > > > > > What am I missing? > > > > > > > > > > Upgrades can never work without changing fundamental properties of > > > modules. > > > > > > There are two traits of modules that break everything: > > > * Module activation is introduces a hard lock of content source > > > * There is no concept of module transitions > > > > > > In the RHEL world, these two qualities are not great, but they are > > > serviceable (RHEL 9 is going to hurt!). In the Fedora world, they make > > > having default modules essentially untenable. It could even be argued > > > that non-default modules are not serviceable either. > > > > > > There is no way in modularity to say that a module is being replaced > > > with another. There's also no way to say that a module is going away > > > and transition accordingly. Moreover, since modules have a strong > > > dependency on an abstract property that is defined as a consequence of > > > the system content (the "platform" module), it is not possible to have > > > orphan modules that are still binary compatible as you upgrade. > > > Finally, modularization and foregoing non-modular versions of content > > > has an implicit commitment that you *never* demodularize because there > > > is no module transition capabilities in the modularity technology. > > > > > > These flaws boil down to Fedora Modularity being a failure because the > > > technology does not account for the needs of Fedora as a distribution, > > > as a project, or as a community. > > > > I think this is actually a very cogent summary of the major problems > > we're dealing with in modularity right now, but it's *also* needlessly > > negative. > > > > Inventing new stuff is hard. You rarely get it right the first time. > > Speaking personally here I think it was a big mistake to do this second > > version of Modularity as fast as we did and drop it into RHEL 8 before > > it had been in Fedora for two minutes, that was an unforced error; but > > even if we hadn't done that, I'm not surprised the second cut at > > Modularity isn't perfect. The second cut at RPM wasn't perfect either, > > that's why we're on 4.x not 2.x. :) > > > > What's happening right now is the process of us trying something out > > and finding out where the problems are. That's what happens when you > > invent new stuff, it's harder than just carrying on doing the old > > stuff. > > > > So: I'm on board with most of what you say here, but there's no need to > > say it means Modularity is "a failure". It means right now it's not > > entirely baked and we're realizing the concept needs extending and > > perhaps reworking a bit, just like we realized with the *first* cut at > > Modularity which we abandoned between a Beta release and a Final > > release. This is causing us to have to deal with some icky problems, > > but again, that's not *new*. We had to deal with some fairly icky > > problems when systemd showed up. We had to deal with some fairly icky > > problems when grub2 showed up. It's a process we've dealt with before. > > We know
