date:20190624

On Mon, Jun 24, 2019 at 9:37 PM Ralf Corsepius  wrote:
>
> On 6/21/19 7:26 PM, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels
> >
> > == Summary ==
> > Stop building i686 kernels, reduce the i686 package to a
> > kernel-headers package that can be used to build 32bit versions of
> > everything else.
>
> How does this affect the i386 as secondary architecture?
>
> Actually, I feel this proposal is a violoent cheat and should actually
> be entitled: Drop i386 as secondary architecture.

It is not a violent cheat. It was proposed this way 2 years ago. At
the time a SIG was created to maintain i686 so that it could continue
as a secondary arch. They are inactive. See the post in the SIG there.
When a call for a status was made (as the only traffic on their list
so far this year), it got a single reply from someone saying that they
would no longer have 32bit hardware as of August.

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

[Fedocal] Reminder meeting : Modularity Team (weekly)

2019-06-24 Thread nils

Dear all,

You are kindly invited to the meeting:
   Modularity Team (weekly) on 2019-06-25 from 15:00:00 to 16:00:00 UTC
   At fedora-meetin...@irc.freenode.net

The meeting will be about:
Meeting of the Modularity Team.

More information available at: [Modularity Team 
Docs](https://docs.pagure.org/modularity/)

The agenda for the meeting is available as flagged tickets [in the Modularity 
repository](https://pagure.io/modularity/issues?status=Open=Meeting).



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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 31 System-Wide Change proposal: No More i686 Kernels

2019-06-24 Thread Ralf Corsepius


On 6/21/19 7:26 PM, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels

== Summary ==
Stop building i686 kernels, reduce the i686 package to a
kernel-headers package that can be used to build 32bit versions of
everything else.


How does this affect the i386 as secondary architecture?

Actually, I feel this proposal is a violoent cheat and should actually 
be entitled: Drop i386 as secondary architecture.


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

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

2019-06-24 Thread updates

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-de51ed6706   
drupal7-uuid-1.3-1.el6
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-d5dca753d6   
GraphicsMagick-1.3.32-1.el6
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-12f1eb1b1f   
tomcat-7.0.94-1.el6


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

wp-cli-2.2.0-2.el6

Details about builds:



 wp-cli-2.2.0-2.el6 (FEDORA-EPEL-2019-576b228e04)
 The command line interface for WordPress

Update Information:

has been changed bindir wp-cli to wp according to the documentation  
update wp-cli to 2.2.0

ChangeLog:

* Sun Jun 23 2019 Luis M. Segundo  - 2.2.0-2
- include man
- change bindir wp-cli to wp
* Sat Jun  8 2019 Luis M. Segundo  - 2.2.0-1
- update to 2.2.0.


___
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 31 Self-Contained Change proposal: Move test.support module to python3-test subpackage

On Tue, 2019-06-25 at 00:26 +0200, Miro Hrončok wrote:
> On 25. 06. 19 0:18, Yaakov Selkowitz wrote:
> > On Mon, 2019-06-24 at 23:09 +0200, Miro Hrončok wrote:
> > > On 24. 06. 19 22:25, Yaakov Selkowitz wrote:
> > > > On Mon, 2019-06-24 at 22:10 +0200, Miro Hrončok wrote:
> > > > > On 24. 06. 19 22:06, Yaakov Selkowitz wrote:
> > > > > > On Mon, 2019-06-24 at 12:09 -0400, Ben Cotton wrote:
> > > > > > > https://fedoraproject.org/wiki/Changes/Move_test.support_module_to_python3-test_subpackage
> > > > > > > 
> > > > > > > == Summary ==
> > > > > > > 
> > > > > > > Move test.support from python3-libs to
> > > > > > > python3-test subpackage.
> > > > > > > 
> > > > > > > == Owner ==
> > > > > > > * Name: [[User:lbalhar| Lumír Balhar]]
> > > > > > > * Email: [mailto:lbal...@redhat.com| lbal...@redhat.com]
> > > > > > > 
> > > > > > > 
> > > > > > > == Detailed Description ==
> > > > > > > 
> > > > > > > Python test modules should be used only for testing Python itself.
> > > > > > > However, some packages have buildtime or runtime dependency on 
> > > > > > > parts
> > > > > > > of Python test modules. The aim of this change is to move the most
> > > > > > > popular Python test module test.support from
> > > > > > > python3-libs to python3-test subpackage
> > > > > > > which will help us discover packages which depend on it and also
> > > > > > > identify parts of the module which might be useful to move to 
> > > > > > > standard
> > > > > > > library.
> > > > > > 
> > > > > > The main reason for this change is to *experiment* and see what 
> > > > > > breaks
> > > > > > when it is moved?  Why can't that be done in copr instead?
> > > > > 
> > > > > The main reason for this change is to make packaging of Python easier 
> > > > > (and more
> > > > > explicit) and less error prone in the future. Discovering packages 
> > > > > that need
> > > > > test.support is a secondary goal that help upstream but does not help 
> > > > > Fedora much.
> > > > > 
> > > > > Should the change be reworded so this is more clear?
> > > > 
> > > > I would say the scoping should happen (e.g. in copr) first, then we'll
> > > > know what the scope (and hence feasibility) of this change truly is.
> > > 
> > > What will the scoping actually tell us? If it tells us that X hundred 
> > > packages
> > > need to add BR for python3-test, we'll just do that and report the list to
> > > upstream. We can do that during the mass rebuild.
> > 
> > If there would indeed be X hundred packages affected, would this move
> > still make sense?  The python3-test subpackage is even larger than most
> > of the rest of python3 combined, and the vast majority of it is
> > irrelevant to other packages.  Such usage would indicate to me that
> > some work needs to be done within the ecosystem to respect its official
> > status as internal-only.  (Perhaps, in that case, a move to python3-
> > devel could be considered instead.)
> 
> Good questions. What number of affected packages do you think would be 
> crucial?
> I say X hundred, because I don't anticipate it will go to thousands. However 
> with 3000 Python packages, couple hundreds is IMHO not a big deal. Note that 
> this is  build dependency, not a runtime one.

Nevertheless, there has been a great deal of effort recently to shrink
buildroots and speed up build times.  Having to add BR: python3-test to
packages would mean adding a download of ~9MiB and an installation of
~3K files to every single affected package's build time.  IMO this
needs to be fully scoped before consideration.

-- 
Yaakov Selkowitz
Senior Software Engineer - Platform Enablement
Red Hat, Inc.

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

[Bug 1723600] New: perl-EV-4.26 is available

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

Bug ID: 1723600
   Summary: perl-EV-4.26 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-EV
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: carl@george.computer, emman...@seyman.fr,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 4.26
Current version/release in rawhide: 4.25-3.fc31
URL: https://metacpan.org/release/EV

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

-- 
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 31 System-Wide Change proposal: No More i686 Kernels

2019-06-24 Thread Zbigniew Jędrzejewski-Szmek

On Mon, Jun 24, 2019 at 10:35:40AM -0700, Kevin Fenzi wrote:
> On 6/24/19 10:00 AM, Justin Forbes wrote:
> > On Mon, Jun 24, 2019 at 11:41 AM Zbigniew Jędrzejewski-Szmek
> >  wrote:
> 
> ...snip...
> 
> >> Maybe the Change could be renamed to reflect the full impact:
> >> "No more i686 kernels or images"?
> > 
> > Changed on the wiki.
> 
> Note that as far as I recall, this also means containers, as we need a
> kernel to build those, right?

I'm don't know about all the possible ways we build containers in
Fedora, but intrinsically, there's certainly no reason to require an
amd64 kernel to build a 32-bit image. (*)

Zbyszek

(*) E.g.
  dnf -y --releasever=31 --installroot=/var/lib/machines/f28-32 \
--disablerepo='*' --enablerepo=fedora --enablerepo=updates install \
systemd passwd dnf fedora-release vim-minimal --forcearch=i686
still works.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 31 Self-Contained Change proposal: Move test.support module to python3-test subpackage

On 25. 06. 19 0:18, Yaakov Selkowitz wrote:

On Mon, 2019-06-24 at 23:09 +0200, Miro Hrončok wrote:

On 24. 06. 19 22:25, Yaakov Selkowitz wrote:

On Mon, 2019-06-24 at 22:10 +0200, Miro Hrončok wrote:

On 24. 06. 19 22:06, Yaakov Selkowitz wrote:

On Mon, 2019-06-24 at 12:09 -0400, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/Move_test.support_module_to_python3-test_subpackage

== Summary ==

Move test.support from python3-libs to
python3-test subpackage.

== Owner ==
* Name: [[User:lbalhar| Lumír Balhar]]
* Email: [mailto:lbal...@redhat.com| lbal...@redhat.com]

== Detailed Description ==

Python test modules should be used only for testing Python itself.
However, some packages have buildtime or runtime dependency on parts
of Python test modules. The aim of this change is to move the most
popular Python test module test.support from
python3-libs to python3-test subpackage
which will help us discover packages which depend on it and also
identify parts of the module which might be useful to move to standard
library.

The main reason for this change is to *experiment* and see what breaks
when it is moved? Why can't that be done in copr instead?

The main reason for this change is to make packaging of Python easier (and more
explicit) and less error prone in the future. Discovering packages that need
test.support is a secondary goal that help upstream but does not help Fedora
much.

Should the change be reworded so this is more clear?

I would say the scoping should happen (e.g. in copr) first, then we'll
know what the scope (and hence feasibility) of this change truly is.

What will the scoping actually tell us? If it tells us that X hundred packages
need to add BR for python3-test, we'll just do that and report the list to
upstream. We can do that during the mass rebuild.

If there would indeed be X hundred packages affected, would this move
still make sense? The python3-test subpackage is even larger than most
of the rest of python3 combined, and the vast majority of it is
irrelevant to other packages. Such usage would indicate to me that
some work needs to be done within the ecosystem to respect its official
status as internal-only. (Perhaps, in that case, a move to python3-
devel could be considered instead.)

Good questions. What number of affected packages do you think would be crucial?
I say X hundred, because I don't anticipate it will go to thousands. However
with 3000 Python packages, couple hundreds is IMHO not a big deal. Note that
this is build dependency, not a runtime one.

--
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 31 Self-Contained Change proposal: Move test.support module to python3-test subpackage

On Mon, 2019-06-24 at 23:09 +0200, Miro Hrončok wrote:
> On 24. 06. 19 22:25, Yaakov Selkowitz wrote:
> > On Mon, 2019-06-24 at 22:10 +0200, Miro Hrončok wrote:
> > > On 24. 06. 19 22:06, Yaakov Selkowitz wrote:
> > > > On Mon, 2019-06-24 at 12:09 -0400, Ben Cotton wrote:
> > > > > https://fedoraproject.org/wiki/Changes/Move_test.support_module_to_python3-test_subpackage
> > > > > 
> > > > > == Summary ==
> > > > > 
> > > > > Move test.support from python3-libs to
> > > > > python3-test subpackage.
> > > > > 
> > > > > == Owner ==
> > > > > * Name: [[User:lbalhar| Lumír Balhar]]
> > > > > * Email: [mailto:lbal...@redhat.com| lbal...@redhat.com]
> > > > > 
> > > > > 
> > > > > == Detailed Description ==
> > > > > 
> > > > > Python test modules should be used only for testing Python itself.
> > > > > However, some packages have buildtime or runtime dependency on parts
> > > > > of Python test modules. The aim of this change is to move the most
> > > > > popular Python test module test.support from
> > > > > python3-libs to python3-test subpackage
> > > > > which will help us discover packages which depend on it and also
> > > > > identify parts of the module which might be useful to move to standard
> > > > > library.
> > > > 
> > > > The main reason for this change is to *experiment* and see what breaks
> > > > when it is moved?  Why can't that be done in copr instead?
> > > 
> > > The main reason for this change is to make packaging of Python easier 
> > > (and more
> > > explicit) and less error prone in the future. Discovering packages that 
> > > need
> > > test.support is a secondary goal that help upstream but does not help 
> > > Fedora much.
> > > 
> > > Should the change be reworded so this is more clear?
> > 
> > I would say the scoping should happen (e.g. in copr) first, then we'll
> > know what the scope (and hence feasibility) of this change truly is.
> 
> What will the scoping actually tell us? If it tells us that X hundred 
> packages 
> need to add BR for python3-test, we'll just do that and report the list to 
> upstream. We can do that during the mass rebuild.

If there would indeed be X hundred packages affected, would this move
still make sense?  The python3-test subpackage is even larger than most
of the rest of python3 combined, and the vast majority of it is
irrelevant to other packages.  Such usage would indicate to me that 
some work needs to be done within the ecosystem to respect its official
status as internal-only.  (Perhaps, in that case, a move to python3-
devel could be considered instead.)

-- 
Yaakov Selkowitz
Senior Software Engineer - Platform Enablement
Red Hat, Inc.

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

Self Introduction: Dylan Stephano-Shachter

2019-06-24 Thread Dylan Stephano-Shachter

Hello,

I have just submitted my first request to maintain a fedora package. I am a 
developer out of Boston, MA. I currently work for Nasuni. I have been using 
Fedora for a long time and I have been packaging rpms for about 2 years now. I 
already have some contributions to existing packages. I am, as of now, looking 
for a sponsor from the packaging group.

The package I submitted is insights-core, the python data collection framework 
used in Redhat Insights.

I am excited to start contributing in a more significant way to the Fedora 
project.___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 31 Self-Contained Change proposal: Move test.support module to python3-test subpackage

On 24. 06. 19 22:25, Yaakov Selkowitz wrote:

On Mon, 2019-06-24 at 22:10 +0200, Miro Hrončok wrote:

On 24. 06. 19 22:06, Yaakov Selkowitz wrote:

On Mon, 2019-06-24 at 12:09 -0400, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/Move_test.support_module_to_python3-test_subpackage

== Summary ==

Move test.support from python3-libs to
python3-test subpackage.

== Owner ==
* Name: [[User:lbalhar| Lumír Balhar]]
* Email: [mailto:lbal...@redhat.com| lbal...@redhat.com]

== Detailed Description ==

The main reason for this change is to *experiment* and see what breaks
when it is moved? Why can't that be done in copr instead?

Should the change be reworded so this is more clear?

I would say the scoping should happen (e.g. in copr) first, then we'll
know what the scope (and hence feasibility) of this change truly is.

Re: Fedora 31 Self-Contained Change proposal: Move test.support module to python3-test subpackage

On Mon, 2019-06-24 at 22:10 +0200, Miro Hrončok wrote:
> On 24. 06. 19 22:06, Yaakov Selkowitz wrote:
> > On Mon, 2019-06-24 at 12:09 -0400, Ben Cotton wrote:
> > > https://fedoraproject.org/wiki/Changes/Move_test.support_module_to_python3-test_subpackage
> > > 
> > > == Summary ==
> > > 
> > > Move test.support from python3-libs to
> > > python3-test subpackage.
> > > 
> > > == Owner ==
> > > * Name: [[User:lbalhar| Lumír Balhar]]
> > > * Email: [mailto:lbal...@redhat.com| lbal...@redhat.com]
> > > 
> > > 
> > > == Detailed Description ==
> > > 
> > > Python test modules should be used only for testing Python itself.
> > > However, some packages have buildtime or runtime dependency on parts
> > > of Python test modules. The aim of this change is to move the most
> > > popular Python test module test.support from
> > > python3-libs to python3-test subpackage
> > > which will help us discover packages which depend on it and also
> > > identify parts of the module which might be useful to move to standard
> > > library.
> > 
> > The main reason for this change is to *experiment* and see what breaks
> > when it is moved?  Why can't that be done in copr instead?
> 
> The main reason for this change is to make packaging of Python easier (and 
> more 
> explicit) and less error prone in the future. Discovering packages that need 
> test.support is a secondary goal that help upstream but does not help Fedora 
> much.
> 
> Should the change be reworded so this is more clear?

I would say the scoping should happen (e.g. in copr) first, then we'll
know what the scope (and hence feasibility) of this change truly is.

-- 
Yaakov Selkowitz
Senior Software Engineer - Platform Enablement
Red Hat, Inc.

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

Re: Fedora 31 Self-Contained Change proposal: Move test.support module to python3-test subpackage

On 24. 06. 19 22:06, Yaakov Selkowitz wrote:

On Mon, 2019-06-24 at 12:09 -0400, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/Move_test.support_module_to_python3-test_subpackage

== Summary ==

Move test.support from python3-libs to
python3-test subpackage.

== Owner ==
* Name: [[User:lbalhar| Lumír Balhar]]
* Email: [mailto:lbal...@redhat.com| lbal...@redhat.com]

== Detailed Description ==

The main reason for this change is to *experiment* and see what breaks
when it is moved? Why can't that be done in copr instead?

Should the change be reworded so this is more clear?

Re: Fedora 31 Self-Contained Change proposal: Move test.support module to python3-test subpackage

On Mon, 2019-06-24 at 12:09 -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Move_test.support_module_to_python3-test_subpackage
> 
> == Summary ==
> 
> Move test.support from python3-libs to
> python3-test subpackage.
> 
> == Owner ==
> * Name: [[User:lbalhar| Lumír Balhar]]
> * Email: [mailto:lbal...@redhat.com| lbal...@redhat.com]
> 
> 
> == Detailed Description ==
> 
> Python test modules should be used only for testing Python itself.
> However, some packages have buildtime or runtime dependency on parts
> of Python test modules. The aim of this change is to move the most
> popular Python test module test.support from
> python3-libs to python3-test subpackage
> which will help us discover packages which depend on it and also
> identify parts of the module which might be useful to move to standard
> library.

The main reason for this change is to *experiment* and see what breaks
when it is moved?  Why can't that be done in copr instead?

> Also, [https://docs.python.org/3/library/test.html#module-test.support
> the Python documentation] says test.support is not a public module.
> Other things should not depend on it, and if something is useful
> outside the CPython test suite, we should ideally take it out of
> test.support.
> 
> == Benefit to Fedora ==
> 
> The main benefit here is that moving it all to -test is less fragile
> and more consistent.
> 
> It also helps us understand which parts of Python test suite are
> useful and which is worth to move to the standard library.
> 
> There were also a few bugs caused by parts of the test module packaged
> in different subpackages and by differences between Python 2 and 3 -
> [https://bugzilla.redhat.com/show_bug.cgi?id=1651245 RHBZ#1651245],
> [https://bugzilla.redhat.com/show_bug.cgi?id=1528899 RHBZ#1528899],
> [https://bugzilla.redhat.com/show_bug.cgi?id=596258 RHBZ#596258]
> 
> == Scope ==
> * Proposal owners:
> ** Move test.support from python3-libs to
> python3-test subpackage.
> ** Identify as many as possible affected packages and try to fix their
> buildtime/runtime issues caused by the change.
> 
> * Other developers:
> ** If a package depends on test.support module which we
> move to -test subpackage, change the build/runtime dependencies
> definition accordingly.
> 
> * Release engineering: N/A (not a System Wide Change)
> 
> * Policies and guidelines: N/A (not a System Wide Change)
> 
> * Trademark approval: N/A (not needed for this Change)
> 
> == Upgrade/compatibility impact ==
> Test modules should not be used as a runtime dependency so there is no
> impact on an upgrade.
> 
> == How To Test ==
> 
> N/A (not a System Wide Change)
> 
> == User Experience ==
> The user experience should not be affected.
> 
> == Dependencies ==
> N/A (not a System Wide Change)
> 
> == Contingency Plan ==
> 
> * Contingency mechanism: Changes will be mostly done in Python
> specfile and they can be easily reverted in case of some unexpected
> issues. The second possibility is to set Provides to temporarily
> deactivate the impact of the change.
> * Contingency deadline: N/A (not a System Wide Change)
> * Blocks release? N/A (not a System Wide Change)
> * Blocks product? No.
> 
> == Documentation ==
> N/A (not a System Wide Change)
> 
> == Release Notes ==
> Since this affects only a few packages, no release notes are necessary.


-- 
Yaakov Selkowitz
Senior Software Engineer - Platform Enablement
Red Hat, Inc.

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

Re: Fedora 31 System-Wide Change proposal: No More i686 Kernels

2019-06-24 Thread Chris Adams

Once upon a time, Kevin Fenzi  said:
> On 6/24/19 10:00 AM, Justin Forbes wrote:
> > On Mon, Jun 24, 2019 at 11:41 AM Zbigniew Jędrzejewski-Szmek
> >  wrote:
> 
> ...snip...
> 
> >> Maybe the Change could be renamed to reflect the full impact:
> >> "No more i686 kernels or images"?
> > 
> > Changed on the wiki.
> 
> Note that as far as I recall, this also means containers, as we need a
> kernel to build those, right?

If there are no i686 images, and no i686 containers, and anaconda can't
install i686 userspace with x86_64 kernel... is there any regular way to
consume i686 applications?  It seems like the only reason to continue
building i686 RPMs would be for multilib (and their build dependencies),
which is a small subset of the total RPMs.

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

Re: Fedora 31 System-Wide Change proposal: No More i686 Kernels

On Mon, Jun 24, 2019 at 1:39 PM Nicolas Mailhot via devel
 wrote:
>
> Le lundi 24 juin 2019 à 18:50 +0200, Igor Gnatenko a écrit :
> >  But packages will be still built for i686 architecture and then
> > shipped in repos (not completely sure if having i686-only repo is
> > useful, but they will be in x86_64 repos definitely).
>
> It would be nice if they were finally split in an optional repo. That's
> a lot of files that are mirrored by default for x86_64, that x86_64
> users have little use for
>
I would kind of expect over time that other packages would be excluded
from 32bit i686 because there is little use for them, but this is that
first step to getting there. Clearly the world is not ready for
killing off all 32bit, Ubuntu has even supposedly reversed their
decision there, but a lot of things can go away without ever being
noticed when you aren't booting a 32bit kernel.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 31 System-Wide Change proposal: No More i686 Kernels

2019-06-24 Thread Nicolas Mailhot via devel

Le lundi 24 juin 2019 à 18:50 +0200, Igor Gnatenko a écrit :
>  But packages will be still built for i686 architecture and then
> shipped in repos (not completely sure if having i686-only repo is
> useful, but they will be in x86_64 repos definitely).

It would be nice if they were finally split in an optional repo. That's
a lot of files that are mirrored by default for x86_64, that x86_64
users have little use for

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

Re: Fedora 31 System-Wide Change proposal: No More i686 Kernels

2019-06-24 Thread Kevin Fenzi

On 6/24/19 10:00 AM, Justin Forbes wrote:
> On Mon, Jun 24, 2019 at 11:41 AM Zbigniew Jędrzejewski-Szmek
>  wrote:

...snip...

>> Maybe the Change could be renamed to reflect the full impact:
>> "No more i686 kernels or images"?
> 
> Changed on the wiki.

Note that as far as I recall, this also means containers, as we need a
kernel to build those, right?

kevin



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

Re: HEADS-UP: soname version bump for zita-convolver

2019-06-24 Thread Igor Gnatenko

Hi Guido,

On Mon, Jun 24, 2019 at 6:59 PM Guido Aulisi  wrote:
>
> Hello,
> I'm going to update zita-convolver library to version 4 in the next
> weeks, it will be a rather slow job because of holidays :-)
>
> According to dnf this update will impact the packages listed below:
>
> guitarix-0:0.37.3-3.fc30.x86_64
> jconvolver-0:0.9.2-17.fc30.x86_64
> ladspa-zam-plugins-0:3.10-5.fc30.x86_64
> lv2-guitarix-plugins-0:0.37.3-3.fc30.x86_64
> lv2-ir-plugins-0:1.3.4-4.fc30.x86_64
> lv2-x42-plugins-0:0.10.0-0.1.20190507.fc31.x86_64
> lv2-zam-plugins-0:3.10-5.fc30.x86_64
> pulseeffects-0:4.5.0-1.fc30.i686
> pulseeffects-0:4.5.0-1.fc30.x86_64
> zam-plugins-0:3.10-5.fc30.x86_64
> zita-convolver-devel-0:3.1.0-17.fc30.i686
> zita-convolver-devel-0:3.1.0-17.fc30.x86_64
>
> I can rebuild most of them, but not pulseeffects, I've got no commit
> privileges on that.

Please ping me on IRC or over the email and I'll take care of it.

> jconvolver and zam-plugins need to be upgraded to latest versions to
> work with new zita-convolver library, I will upgrade them.
>
> Bye
> Guido
>
> fas account: tartina
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [EPEL-devel] Re: RHEL 7.7 Beta


On 19. 06. 19 23:58, Miro Hrončok wrote:

On 19. 06. 19 19:22, Kevin Fenzi wrote:

On 6/12/19 1:48 AM, Miro Hrončok wrote:

On 12. 06. 19 8:14, Thomas Stephen Lee wrote:

Hi,

Just for your information.

https://www.redhat.com/en/blog/red-hat-enterprise-linux-77-beta-now-available


Python 3.6 is there in 7.7

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7-beta/html/7.7_release_notes/overview 




thanks


In that case, let's proceed with:

https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/19
https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/20
https://src.fedoraproject.org/rpms/python34/pull-request/35

Starting here: https://bugzilla.redhat.com/show_bug.cgi?id=1719633


But we don't want to actually land that until 7.7 is out right?


We do. It is designed to work, after 7.7 GA python-rpm-macros package gets 
retired on EPEL.


Everything ready as an EPEL7 update, with buildroot overrides:

https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f505f7d2fb

If you get some weird failures, please report it there.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org

[EPEL-devel] Re: RHEL 7.7 Beta


On 19. 06. 19 23:58, Miro Hrončok wrote:

On 19. 06. 19 19:22, Kevin Fenzi wrote:

On 6/12/19 1:48 AM, Miro Hrončok wrote:

On 12. 06. 19 8:14, Thomas Stephen Lee wrote:

Hi,

Just for your information.

https://www.redhat.com/en/blog/red-hat-enterprise-linux-77-beta-now-available


Python 3.6 is there in 7.7

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7-beta/html/7.7_release_notes/overview 




thanks


In that case, let's proceed with:

https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/19
https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/20
https://src.fedoraproject.org/rpms/python34/pull-request/35

Starting here: https://bugzilla.redhat.com/show_bug.cgi?id=1719633


But we don't want to actually land that until 7.7 is out right?


We do. It is designed to work, after 7.7 GA python-rpm-macros package gets 
retired on EPEL.


Everything ready as an EPEL7 update, with buildroot overrides:

https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f505f7d2fb

If you get some weird failures, please report it there.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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 31 System-Wide Change proposal: No More i686 Kernels

On Mon, Jun 24, 2019 at 11:41 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Mon, Jun 24, 2019 at 11:11:41AM -0500, Justin Forbes wrote:
> > On Mon, Jun 24, 2019 at 10:41 AM Fabio Valentini  
> > wrote:
> > >
> > > On Mon, Jun 24, 2019, 17:28 Stephen John Smoogen  wrote:
> > >>
> > >>
> > >>
> > >> On Fri, 21 Jun 2019 at 14:15, Ben Cotton  wrote:
> > >>>
> > >>> https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels
> > >>>
> > >>> == Summary ==
> > >>> Stop building i686 kernels, reduce the i686 package to a
> > >>> kernel-headers package that can be used to build 32bit versions of
> > >>> everything else.
> > >>>
> > >>
> > >> OK I think this has a followup change which is sort of buried below:
> > >>
> > >> No more i686 kernels mean that the i686 compose (aka .iso/etc) do
> > >> not happen. The only way would be for someone to engineer making
> > >> anaconda install an x86_64 kernel and i686 user space work. That
> > >> is a lot of work and probably a little late to start on. Howver
> > >> as the below mentioned absentee sponsor of i686.. I have no
> > >> problems with this.
>
> Maybe the Change could be renamed to reflect the full impact:
> "No more i686 kernels or images"?

Changed on the wiki.

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

Orphaned packages need you


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

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

This e-mail was shortened, see the full report at:
https://churchyard.fedorapeople.org/orphans-2019-06-24.txt

Packages retired today:
clpbar compat-openssl10-pkcs11-helper rubygem-commander rubygem-paranoia

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

Package  (co)maintainers   Status Change

aesh  gil, lef, orphan 2 weeks ago
bean-validation-api   gil, lef, orphan 2 weeks ago
cdi-api1  gil, orphan  2 weeks ago
checkstyledbhole, greghellings, lef,   5 weeks ago
  mizdebsk, nsantos, orphan,
  rmyers
clpbardcantrel, orphan 7 weeks ago
cmdtest   orphan   5 weeks ago
compat-openssl10-pkcs11-helperorphan, rdieter  7 weeks ago
concurrentorphan   2 weeks ago
cookccgil, lef, orphan 2 weeks ago
cookxml   orphan   2 weeks ago
crypto-utils  jorton, orphan   3 weeks ago
csvcatorphan   1 weeks ago
cxf-build-utils   gil, lef, orphan 2 weeks ago
cxf-xjc-utils gil, lef, orphan 2 weeks ago
dreampie  cicku, orphan1 weeks ago
emma  lef, orphan  2 weeks ago
faience-icon-themeorphan   1 weeks ago
fedocal   infra-sig, orphan3 weeks ago
felix-configadmin orphan   2 weeks ago
felix-osgi-obr-resolver   orphan   2 weeks ago
flr   orphan   5 weeks ago
genbackupdata orphan   5 weeks ago
gnome-shell-extension-simple- orphan   1 weeks ago
dock
gnumed-server orphan   5 weeks ago
gscribble orphan   5 weeks ago
hibernate-commons-annotations gil, lef, orphan 2 weeks ago
hibernate-hql gil, lef, orphan 2 weeks ago
hibernate-jpa-2.0-api gil, lef, orphan 2 weeks ago
hibernate-search  gil, lef, orphan 2 weeks ago
hibernate-validator   gil, lef, orphan 2 weeks ago
jacorbgil, lef, orphan 2 weeks ago
jandexgil, orphan  2 weeks ago
jaxws-jboss-httpserver-httpspilef, orphan  2 weeks ago
jaxws-undertow-httpspigil, lef, orphan 2 weeks ago
jberetgil, lef, orphan 2 weeks ago
jboss-annotations-1.1-api orphan   2 weeks ago
jboss-classfilewriter gil, lef, orphan 2 weeks ago
jboss-common-core gil, lef, orphan 2 weeks ago
jboss-connector-1.7-api   lef, orphan  2 weeks ago
jboss-dmr gil, lef, orphan 2 weeks ago
jboss-ejb-3.1-api orphan   2 weeks ago
jboss-el-2.2-api  orphan   2 weeks ago
jboss-el-3.0-api  gil, lef, orphan 2 weeks ago
jboss-httpserver  orphan   2 weeks ago
jboss-iiop-client lef, orphan  2 weeks ago
jboss-integration lef, orphan  2 weeks ago
jboss-interceptors-1.1-apiorphan   2 weeks ago
jboss-invocation  gil, lef, orphan 2 weeks ago
jboss-jacc-1.5-apilef, orphan  2 weeks

[389-devel] Re: Porting Perl scripts

2019-06-24 Thread Mark Reynolds



On 6/24/19 12:28 PM, Rich Megginson wrote:

On 6/24/19 10:00 AM, Mark Reynolds wrote:



On 6/24/19 11:46 AM, Simon Pichugin wrote:

Hi team,
I am working on porting our admin Perl scripts to Python CLI.
Please, check the list and share your opinion:

- cl-dump.pl - dumps and decodes changelog. Is it used often (if at 
all)?
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html-single/configuration_command_and_file_reference/index#cl_dump.pl_Dump_and_decode_changelog 

This is used often actually, and is a good debugging tool.   I think 
it just creates a task, so it should be ported to CLI (added to 
replication CLI sub commands)
- logconv.pl - parse and analise the access logs. Pretty big one, is 
it priority? How much people use it?

   issue is created -https://pagure.io/389-ds-base/issue/50283
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html-single/configuration_command_and_file_reference/index#logconv_pl 


Does not need to be ported as its a standalone tool



Would be great to eliminate perl altogether . . . but this one will be 
tricky to port to python . . .


Yes it would be nice to port this script, but it will be a lot of work 
(especially with the database implementation).  There was a ticket open 
to track this effort: https://pagure.io/389-ds-base/issue/50283


Now what I really meant though is that this is a lower priority effort 
since it's not actually interacting with DS.  Basically it's just 
looking at text files so there is no lib389 porting involved.  Maybe we 
can target this work for 389-ds-base-1.4.3?


Or build these stats into DS and make it a new monitor entry? Not sure 
if this is feasible, and it would only report stats from the last server 
startup.   Something to think about though...


Mark





- migrate.pl - which migration scenarios do we plan to support?
   Do we depricate old ones? Do we need the script?
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html-single/configuration_command_and_file_reference/index#migrate-ds.pl 


This script is obsolete IMHO

- ns_accountstatus.pl, ns_inactivate.pl, ns_activate.pl - the issue is
   discussed here -https://pagure.io/389-ds-base/issue/50206
   I think we should extend status at least. Also, William put there 
some

   of his thoughts. What do you think, guys? Will we refactor
   (kinda depricate) some "account lock" as William proposing?
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html-single/configuration_command_and_file_reference/index#ldif2db.pl_Import-ns_accountstatus.pl_Establish_account_status 

I will update the ticket, but we need the same functionality of the 
ns_* tools, especially the new status work that went into 
ns_accountstatus.pl - that all came from customer escalations so we 
must not lose that functionality.

- syntax-validate.pl - it probably will go to 'healthcheck' tool
   issue is created -https://pagure.io/389-ds-base/issue/50173
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html-single/configuration_command_and_file_reference/index#syntax-validate.pl 


Yes

- repl_monitor.pl - should we make it a part of 'healthcheck' too?
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html-single/configuration_command_and_file_reference/index#repl_monitor.pl_Monitor_replication_status 


Yes

Thanks,
Simon

___
389-devel mailing list --389-devel@lists.fedoraproject.org
To unsubscribe send an email to389-devel-le...@lists.fedoraproject.org
Fedora Code of 
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List 
Archives:https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org


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

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org


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

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:

Re: Fedora 31 System-Wide Change proposal: No More i686 Kernels

2019-06-24 Thread Igor Gnatenko

Hi Fabio,

On Mon, Jun 24, 2019 at 6:35 PM Fabio Valentini  wrote:
>
> On Mon, Jun 24, 2019, 17:28 Stephen John Smoogen  wrote:
>>
>>
>>
>> On Fri, 21 Jun 2019 at 14:15, Ben Cotton  wrote:
>>>
>>> https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels
>>>
>>> == Summary ==
>>> Stop building i686 kernels, reduce the i686 package to a
>>> kernel-headers package that can be used to build 32bit versions of
>>> everything else.
>>>
>>
>> OK I think this has a followup change which is sort of buried below:
>>
>> No more i686 kernels mean that the i686 compose (aka .iso/etc) do not 
>> happen. The only way would be for someone to engineer making anaconda 
>> install an x86_64 kernel and i686 user space work. That is a lot of work and 
>> probably a little late to start on. Howver as the below mentioned absentee 
>> sponsor of i686.. I have no problems with this.
>
>
> Does this affect i686 multilib support in x86_64?

From what I understand, no. We will just stop building live images and
such. But packages will be still built for i686 architecture and then
shipped in repos (not completely sure if having i686-only repo is
useful, but they will be in x86_64 repos definitely).

>
> Fabio
>
>
>>
>>> == Owner ==
>>> * Name: [[User:jforbes| Justin Forbes]]
>>> * Email: jfor...@fedoraproject.org
>>>
>>> == Detailed Description ==
>>> The i686 kernel is of limited use as most x86 hardware supports 64bit
>>> these days.  It has been in a status of "community supported" for
>>> several Fedora releases now.  As such, it gets very little testing,
>>> and issues frequently appear upstream. These tend to go unnoticed for
>>> long periods of time. When issues are found, it is often a long time
>>> before they are fixed because they are considered low priority by most
>>> developers upstream.  This can leave other architectures waiting for
>>> important updates, and provides a less than desirable experience for
>>> people choosing to run a 32bit kernel.
>>> With this proposal, the i686 kernel will no longer be built. A kernel
>>> headers package will still exist, and all 32bit packages should
>>> continue to build as normal. The main difference is there would no
>>> longer be bootable 32bit images.
>>>
>>> This was last proposed with Fedora 27, but it was deferred as an i686
>>> SIG was to be created to handle issues going forward.  That SIG has
>>> been largely unresponsive.  The only thread so far this year has been
>>> a thread starting with "Hello, I noticed that the x86 group hasn't had
>>> any reports in a while. As the absentee sponsor of the group, I would
>>> like to remind people on the list and interested in keeping x86_32 in
>>> Fedora releases that there is general work which needs to be done by
>>> people interested. "  And the only response was one person saying they
>>> would no longer have access to legacy i686 hardware as of August.
>>>
>>> == Benefit to Fedora ==
>>> More testable kernel updates, faster fixes for security bugs, and
>>> lowered exposure.
>>>
>>> == Scope ==
>>> * Proposal owners:
>>> Changes to the kernel spec to stop the actual i686 builds, but keep
>>> the kernel-headers package.
>>>
>>> * Other developers: NA
>>>
>>> * Release engineering: [https://pagure.io/releng/issue/8461]
>>> ** 
>>> [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List
>>> of deliverables]]: Drop i686 based images
>>> * Policies and guidelines: N/A (not needed for this change)
>>> * Trademark approval: N/A (not needed for this Change)
>>>
>>> == Upgrade/compatibility impact ==
>>> 32bit i686 users will need to reinstall as x86_64 with the next release.
>>>
>>> == How To Test ==
>>> N/A Nothing to test, we simply stop producing a flavor of the kernel
>>> package. As there is no direct upgrade path from i686 -> x86_64, users
>>> with capable hardware will have to reinstall.
>>>
>>> == User Experience ==
>>> The few 32bit users will have the full lifecycle of Fedora 30 to
>>> choose a time to upgrade to a 64bit installation.  Some old hardware
>>> will no longer be supported by fedora.
>>>
>>> == Dependencies ==
>>> 32 bit x86 images can no longer be built.
>>>
>>> == Contingency Plan ==
>>> * Contingency mechanism: (What to do?  Who will do it?) Start building
>>> an i686 kernel again
>>> * Contingency deadline: As QA requires for image candidates
>>> * Blocks release? Yes
>>> * Blocks product? product Fedora 31
>>>
>>> == Documentation ==
>>> The lack of an i686 image will need to be documented.
>>
>> --
>> Stephen J Smoogen.
>>
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
>

Re: Fedora 31 System-Wide Change proposal: No More i686 Kernels

2019-06-24 Thread Zbigniew Jędrzejewski-Szmek

On Mon, Jun 24, 2019 at 11:11:41AM -0500, Justin Forbes wrote:
> On Mon, Jun 24, 2019 at 10:41 AM Fabio Valentini  wrote:
> >
> > On Mon, Jun 24, 2019, 17:28 Stephen John Smoogen  wrote:
> >>
> >>
> >>
> >> On Fri, 21 Jun 2019 at 14:15, Ben Cotton  wrote:
> >>>
> >>> https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels
> >>>
> >>> == Summary ==
> >>> Stop building i686 kernels, reduce the i686 package to a
> >>> kernel-headers package that can be used to build 32bit versions of
> >>> everything else.
> >>>
> >>
> >> OK I think this has a followup change which is sort of buried below:
> >>
> >> No more i686 kernels mean that the i686 compose (aka .iso/etc) do
> >> not happen. The only way would be for someone to engineer making
> >> anaconda install an x86_64 kernel and i686 user space work. That
> >> is a lot of work and probably a little late to start on. Howver
> >> as the below mentioned absentee sponsor of i686.. I have no
> >> problems with this.

Maybe the Change could be renamed to reflect the full impact:
"No more i686 kernels or images"?

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

[389-devel] Re: Porting Perl scripts

2019-06-24 Thread Rich Megginson


On 6/24/19 10:00 AM, Mark Reynolds wrote:



On 6/24/19 11:46 AM, Simon Pichugin wrote:

Hi team,
I am working on porting our admin Perl scripts to Python CLI.
Please, check the list and share your opinion:

- cl-dump.pl - dumps and decodes changelog. Is it used often (if at all)?
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html-single/configuration_command_and_file_reference/index#cl_dump.pl_Dump_and_decode_changelog

This is used often actually, and is a good debugging tool.   I think it just 
creates a task, so it should be ported to CLI (added to replication CLI sub 
commands)

- logconv.pl - parse and analise the access logs. Pretty big one, is it 
priority? How much people use it?
   issue is created -https://pagure.io/389-ds-base/issue/50283
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html-single/configuration_command_and_file_reference/index#logconv_pl

Does not need to be ported as its a standalone tool



Would be great to eliminate perl altogether . . . but this one will be tricky 
to port to python . . .



- migrate.pl - which migration scenarios do we plan to support?
   Do we depricate old ones? Do we need the script?
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html-single/configuration_command_and_file_reference/index#migrate-ds.pl

This script is obsolete IMHO

- ns_accountstatus.pl, ns_inactivate.pl, ns_activate.pl - the issue is
   discussed here -https://pagure.io/389-ds-base/issue/50206
   I think we should extend status at least. Also, William put there some
   of his thoughts. What do you think, guys? Will we refactor
   (kinda depricate) some "account lock" as William proposing?
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html-single/configuration_command_and_file_reference/index#ldif2db.pl_Import-ns_accountstatus.pl_Establish_account_status
I will update the ticket, but we need the same functionality of the ns_* tools, especially the new status work that went into ns_accountstatus.pl - that all came from customer escalations so 
we must not lose that functionality.

- syntax-validate.pl - it probably will go to 'healthcheck' tool
   issue is created -https://pagure.io/389-ds-base/issue/50173
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html-single/configuration_command_and_file_reference/index#syntax-validate.pl

Yes

- repl_monitor.pl - should we make it a part of 'healthcheck' too?
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html-single/configuration_command_and_file_reference/index#repl_monitor.pl_Monitor_replication_status

Yes

Thanks,
Simon

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


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


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

Re: Fedora 31 System-Wide Change proposal: No More i686 Kernels

On Mon, Jun 24, 2019 at 10:41 AM Fabio Valentini  wrote:
>
> On Mon, Jun 24, 2019, 17:28 Stephen John Smoogen  wrote:
>>
>>
>>
>> On Fri, 21 Jun 2019 at 14:15, Ben Cotton  wrote:
>>>
>>> https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels
>>>
>>> == Summary ==
>>> Stop building i686 kernels, reduce the i686 package to a
>>> kernel-headers package that can be used to build 32bit versions of
>>> everything else.
>>>
>>
>> OK I think this has a followup change which is sort of buried below:
>>
>> No more i686 kernels mean that the i686 compose (aka .iso/etc) do not 
>> happen. The only way would be for someone to engineer making anaconda 
>> install an x86_64 kernel and i686 user space work. That is a lot of work and 
>> probably a little late to start on. Howver as the below mentioned absentee 
>> sponsor of i686.. I have no problems with this.
>
>
> Does this affect i686 multilib support in x86_64?
No, the kernel-headers package will still be built for i686, and 32bit
userspace is still being built, we just stop producing the actual
kernel, and bootable 32bit images.

>
> Fabio
>
>
>>
>>> == Owner ==
>>> * Name: [[User:jforbes| Justin Forbes]]
>>> * Email: jfor...@fedoraproject.org
>>>
>>> == Detailed Description ==
>>> The i686 kernel is of limited use as most x86 hardware supports 64bit
>>> these days.  It has been in a status of "community supported" for
>>> several Fedora releases now.  As such, it gets very little testing,
>>> and issues frequently appear upstream. These tend to go unnoticed for
>>> long periods of time. When issues are found, it is often a long time
>>> before they are fixed because they are considered low priority by most
>>> developers upstream.  This can leave other architectures waiting for
>>> important updates, and provides a less than desirable experience for
>>> people choosing to run a 32bit kernel.
>>> With this proposal, the i686 kernel will no longer be built. A kernel
>>> headers package will still exist, and all 32bit packages should
>>> continue to build as normal. The main difference is there would no
>>> longer be bootable 32bit images.
>>>
>>> This was last proposed with Fedora 27, but it was deferred as an i686
>>> SIG was to be created to handle issues going forward.  That SIG has
>>> been largely unresponsive.  The only thread so far this year has been
>>> a thread starting with "Hello, I noticed that the x86 group hasn't had
>>> any reports in a while. As the absentee sponsor of the group, I would
>>> like to remind people on the list and interested in keeping x86_32 in
>>> Fedora releases that there is general work which needs to be done by
>>> people interested. "  And the only response was one person saying they
>>> would no longer have access to legacy i686 hardware as of August.
>>>
>>> == Benefit to Fedora ==
>>> More testable kernel updates, faster fixes for security bugs, and
>>> lowered exposure.
>>>
>>> == Scope ==
>>> * Proposal owners:
>>> Changes to the kernel spec to stop the actual i686 builds, but keep
>>> the kernel-headers package.
>>>
>>> * Other developers: NA
>>>
>>> * Release engineering: [https://pagure.io/releng/issue/8461]
>>> ** 
>>> [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List
>>> of deliverables]]: Drop i686 based images
>>> * Policies and guidelines: N/A (not needed for this change)
>>> * Trademark approval: N/A (not needed for this Change)
>>>
>>> == Upgrade/compatibility impact ==
>>> 32bit i686 users will need to reinstall as x86_64 with the next release.
>>>
>>> == How To Test ==
>>> N/A Nothing to test, we simply stop producing a flavor of the kernel
>>> package. As there is no direct upgrade path from i686 -> x86_64, users
>>> with capable hardware will have to reinstall.
>>>
>>> == User Experience ==
>>> The few 32bit users will have the full lifecycle of Fedora 30 to
>>> choose a time to upgrade to a 64bit installation.  Some old hardware
>>> will no longer be supported by fedora.
>>>
>>> == Dependencies ==
>>> 32 bit x86 images can no longer be built.
>>>
>>> == Contingency Plan ==
>>> * Contingency mechanism: (What to do?  Who will do it?) Start building
>>> an i686 kernel again
>>> * Contingency deadline: As QA requires for image candidates
>>> * Blocks release? Yes
>>> * Blocks product? product Fedora 31
>>>
>>> == Documentation ==
>>> The lack of an i686 image will need to be documented.
>>
>> --
>> Stephen J Smoogen.
>>
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To

Fedora 31 Self-Contained Change proposal: Move test.support module to python3-test subpackage

2019-06-24 Thread Ben Cotton

https://fedoraproject.org/wiki/Changes/Move_test.support_module_to_python3-test_subpackage

== Summary ==

Move test.support from python3-libs to
python3-test subpackage.

== Owner ==
* Name: [[User:lbalhar| Lumír Balhar]]
* Email: [mailto:lbal...@redhat.com| lbal...@redhat.com]


== Detailed Description ==

Python test modules should be used only for testing Python itself.
However, some packages have buildtime or runtime dependency on parts
of Python test modules. The aim of this change is to move the most
popular Python test module test.support from
python3-libs to python3-test subpackage
which will help us discover packages which depend on it and also
identify parts of the module which might be useful to move to standard
library.

Also, [https://docs.python.org/3/library/test.html#module-test.support
the Python documentation] says test.support is not a public module.
Other things should not depend on it, and if something is useful
outside the CPython test suite, we should ideally take it out of
test.support.

== Benefit to Fedora ==

The main benefit here is that moving it all to -test is less fragile
and more consistent.

It also helps us understand which parts of Python test suite are
useful and which is worth to move to the standard library.

There were also a few bugs caused by parts of the test module packaged
in different subpackages and by differences between Python 2 and 3 -
[https://bugzilla.redhat.com/show_bug.cgi?id=1651245 RHBZ#1651245],
[https://bugzilla.redhat.com/show_bug.cgi?id=1528899 RHBZ#1528899],
[https://bugzilla.redhat.com/show_bug.cgi?id=596258 RHBZ#596258]

== Scope ==
* Proposal owners:
** Move test.support from python3-libs to
python3-test subpackage.
** Identify as many as possible affected packages and try to fix their
buildtime/runtime issues caused by the change.

* Other developers:
** If a package depends on test.support module which we
move to -test subpackage, change the build/runtime dependencies
definition accordingly.

* Release engineering: N/A (not a System Wide Change)

* Policies and guidelines: N/A (not a System Wide Change)

* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
Test modules should not be used as a runtime dependency so there is no
impact on an upgrade.

== How To Test ==

N/A (not a System Wide Change)

== User Experience ==
The user experience should not be affected.

== Dependencies ==
N/A (not a System Wide Change)

== Contingency Plan ==

* Contingency mechanism: Changes will be mostly done in Python
specfile and they can be easily reverted in case of some unexpected
issues. The second possibility is to set Provides to temporarily
deactivate the impact of the change.
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
* Blocks product? No.

== Documentation ==
N/A (not a System Wide Change)

== Release Notes ==
Since this affects only a few packages, no release notes are necessary.

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

HEADS-UP: soname version bump for zita-convolver

2019-06-24 Thread Guido Aulisi

Hello,
I'm going to update zita-convolver library to version 4 in the next
weeks, it will be a rather slow job because of holidays :-)

According to dnf this update will impact the packages listed below:

guitarix-0:0.37.3-3.fc30.x86_64
jconvolver-0:0.9.2-17.fc30.x86_64
ladspa-zam-plugins-0:3.10-5.fc30.x86_64
lv2-guitarix-plugins-0:0.37.3-3.fc30.x86_64
lv2-ir-plugins-0:1.3.4-4.fc30.x86_64
lv2-x42-plugins-0:0.10.0-0.1.20190507.fc31.x86_64
lv2-zam-plugins-0:3.10-5.fc30.x86_64
pulseeffects-0:4.5.0-1.fc30.i686
pulseeffects-0:4.5.0-1.fc30.x86_64
zam-plugins-0:3.10-5.fc30.x86_64
zita-convolver-devel-0:3.1.0-17.fc30.i686
zita-convolver-devel-0:3.1.0-17.fc30.x86_64

I can rebuild most of them, but not pulseeffects, I've got no commit
privileges on that.

jconvolver and zam-plugins need to be upgraded to latest versions to
work with new zita-convolver library, I will upgrade them.

Bye
Guido

fas account: tartina


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

[389-devel] Re: Porting Perl scripts

2019-06-24 Thread Mark Reynolds



On 6/24/19 11:46 AM, Simon Pichugin wrote:

Hi team,
I am working on porting our admin Perl scripts to Python CLI.
Please, check the list and share your opinion:

- cl-dump.pl - dumps and decodes changelog. Is it used often (if at all)?
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html-single/configuration_command_and_file_reference/index#cl_dump.pl_Dump_and_decode_changelog
This is used often actually, and is a good debugging tool.   I think it 
just creates a task, so it should be ported to CLI (added to replication 
CLI sub commands)


- logconv.pl - parse and analise the access logs. Pretty big one, is it 
priority? How much people use it?
   issue is created - https://pagure.io/389-ds-base/issue/50283
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html-single/configuration_command_and_file_reference/index#logconv_pl

Does not need to be ported as its a standalone tool


- migrate.pl - which migration scenarios do we plan to support?
   Do we depricate old ones? Do we need the script?
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html-single/configuration_command_and_file_reference/index#migrate-ds.pl

This script is obsolete IMHO


- ns_accountstatus.pl, ns_inactivate.pl, ns_activate.pl - the issue is
   discussed here - https://pagure.io/389-ds-base/issue/50206
   I think we should extend status at least. Also, William put there some
   of his thoughts. What do you think, guys? Will we refactor
   (kinda depricate) some "account lock" as William proposing?
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html-single/configuration_command_and_file_reference/index#ldif2db.pl_Import-ns_accountstatus.pl_Establish_account_status
I will update the ticket, but we need the same functionality of the ns_* 
tools, especially the new status work that went into ns_accountstatus.pl 
- that all came from customer escalations so we must not lose that 
functionality.


- syntax-validate.pl - it probably will go to 'healthcheck' tool
   issue is created - https://pagure.io/389-ds-base/issue/50173
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html-single/configuration_command_and_file_reference/index#syntax-validate.pl

Yes


- repl_monitor.pl - should we make it a part of 'healthcheck' too?
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html-single/configuration_command_and_file_reference/index#repl_monitor.pl_Monitor_replication_status

Yes


Thanks,
Simon

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

[389-devel] Porting Perl scripts

2019-06-24 Thread Simon Pichugin

Hi team,
I am working on porting our admin Perl scripts to Python CLI.
Please, check the list and share your opinion:

- cl-dump.pl - dumps and decodes changelog. Is it used often (if at all)?
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html-single/configuration_command_and_file_reference/index#cl_dump.pl_Dump_and_decode_changelog

- logconv.pl - parse and analise the access logs. Pretty big one, is it 
priority? How much people use it?
  issue is created - https://pagure.io/389-ds-base/issue/50283
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html-single/configuration_command_and_file_reference/index#logconv_pl

- migrate.pl - which migration scenarios do we plan to support?
  Do we depricate old ones? Do we need the script?
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html-single/configuration_command_and_file_reference/index#migrate-ds.pl

- ns_accountstatus.pl, ns_inactivate.pl, ns_activate.pl - the issue is
  discussed here - https://pagure.io/389-ds-base/issue/50206
  I think we should extend status at least. Also, William put there some
  of his thoughts. What do you think, guys? Will we refactor
  (kinda depricate) some "account lock" as William proposing?
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html-single/configuration_command_and_file_reference/index#ldif2db.pl_Import-ns_accountstatus.pl_Establish_account_status

- syntax-validate.pl - it probably will go to 'healthcheck' tool
  issue is created - https://pagure.io/389-ds-base/issue/50173
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html-single/configuration_command_and_file_reference/index#syntax-validate.pl

- repl_monitor.pl - should we make it a part of 'healthcheck' too?
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html-single/configuration_command_and_file_reference/index#repl_monitor.pl_Monitor_replication_status

Thanks,
Simon


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

Re: Fedora 31 System-Wide Change proposal: No More i686 Kernels

2019-06-24 Thread Fabio Valentini

On Mon, Jun 24, 2019, 17:28 Stephen John Smoogen  wrote:

>
>
> On Fri, 21 Jun 2019 at 14:15, Ben Cotton  wrote:
>
>> https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels
>>
>> == Summary ==
>> Stop building i686 kernels, reduce the i686 package to a
>> kernel-headers package that can be used to build 32bit versions of
>> everything else.
>>
>>
> OK I think this has a followup change which is sort of buried below:
>
> No more i686 kernels mean that the i686 compose (aka .iso/etc) do not
> happen. The only way would be for someone to engineer making anaconda
> install an x86_64 kernel and i686 user space work. That is a lot of work
> and probably a little late to start on. Howver as the below mentioned
> absentee sponsor of i686.. I have no problems with this.
>

Does this affect i686 multilib support in x86_64?

Fabio



> == Owner ==
>> * Name: [[User:jforbes| Justin Forbes]]
>> * Email: jfor...@fedoraproject.org
>>
>> == Detailed Description ==
>> The i686 kernel is of limited use as most x86 hardware supports 64bit
>> these days.  It has been in a status of "community supported" for
>> several Fedora releases now.  As such, it gets very little testing,
>> and issues frequently appear upstream. These tend to go unnoticed for
>> long periods of time. When issues are found, it is often a long time
>> before they are fixed because they are considered low priority by most
>> developers upstream.  This can leave other architectures waiting for
>> important updates, and provides a less than desirable experience for
>> people choosing to run a 32bit kernel.
>> With this proposal, the i686 kernel will no longer be built. A kernel
>> headers package will still exist, and all 32bit packages should
>> continue to build as normal. The main difference is there would no
>> longer be bootable 32bit images.
>>
>> This was last proposed with Fedora 27, but it was deferred as an i686
>> SIG was to be created to handle issues going forward.  That SIG has
>> been largely unresponsive.  The only thread so far this year has been
>> a thread starting with "Hello, I noticed that the x86 group hasn't had
>> any reports in a while. As the absentee sponsor of the group, I would
>> like to remind people on the list and interested in keeping x86_32 in
>> Fedora releases that there is general work which needs to be done by
>> people interested. "  And the only response was one person saying they
>> would no longer have access to legacy i686 hardware as of August.
>>
>> == Benefit to Fedora ==
>> More testable kernel updates, faster fixes for security bugs, and
>> lowered exposure.
>>
>> == Scope ==
>> * Proposal owners:
>> Changes to the kernel spec to stop the actual i686 builds, but keep
>> the kernel-headers package.
>>
>> * Other developers: NA
>>
>> * Release engineering: [https://pagure.io/releng/issue/8461]
>> **
>> [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List
>> of deliverables]]: Drop i686 based images
>> * Policies and guidelines: N/A (not needed for this change)
>> * Trademark approval: N/A (not needed for this Change)
>>
>> == Upgrade/compatibility impact ==
>> 32bit i686 users will need to reinstall as x86_64 with the next release.
>>
>> == How To Test ==
>> N/A Nothing to test, we simply stop producing a flavor of the kernel
>> package. As there is no direct upgrade path from i686 -> x86_64, users
>> with capable hardware will have to reinstall.
>>
>> == User Experience ==
>> The few 32bit users will have the full lifecycle of Fedora 30 to
>> choose a time to upgrade to a 64bit installation.  Some old hardware
>> will no longer be supported by fedora.
>>
>> == Dependencies ==
>> 32 bit x86 images can no longer be built.
>>
>> == Contingency Plan ==
>> * Contingency mechanism: (What to do?  Who will do it?) Start building
>> an i686 kernel again
>> * Contingency deadline: As QA requires for image candidates
>> * Blocks release? Yes
>> * Blocks product? product Fedora 31
>>
>> == Documentation ==
>> The lack of an i686 image will need to be documented.
>>
> --
> Stephen J Smoogen.
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Orphaning rubygem-shotgun

2019-06-24 Thread Vít Ondruch

Hi all,

I don't have any use for rubygem-shotgun, so I have orphaned the package.


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

Re: Reporting is disabled because the generated backtrace has low informational value

2019-06-24 Thread Chris Murphy

On Mon, Jun 24, 2019 at 5:57 AM  wrote:
>
> On Mon, Jun 24, 2019 at 6:50 AM, mcatanz...@gnome.org wrote:
> > That's not right. The backtrace was processed on the retrace server,
> > so installing debuginfo locally should not be required.
> >
> > I think it's a longstanding ABRT bug.
> >
> > Michael
>
> Oh, I forgot what I was actually planning to write about when I decided
> to send a mail. ABRT doesn't support reporting crashes from flatpak
> apps. It's a feature we requested a while ago [1]. In the meantime, if
> a flatpak app crashes, you'll have to generate a backtrace manually
> using the flatpak-coredumpctl command:
>
> $ flatpak-coredumpctl org.gnome.Epiphany.Devel//master
>
> So that's easy, but the backtrace will be useless unless you have debug
> symbols installed for both the runtime and the application. I can never
> remember how to do that and there doesn't exist documentation anywhere
> that I can see. ABRT will need to learn how to do all of this.
>
> None of this is relevant to Chris's crash, because he's not reporting
> that a flatpak application is crashing. He's reporting that flatpak
> itself is crashing. ABRT should already be able to handle this like it
> does any other bug, and it's surely an ABRT bug for it to have failed
> here.


I'm gonna add all of this to the recent abrt solicitation for features
and complaints.

-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 31 System-Wide Change proposal: No More i686 Kernels

2019-06-24 Thread Stephen John Smoogen

On Fri, 21 Jun 2019 at 14:15, Ben Cotton  wrote:

> https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels
>
> == Summary ==
> Stop building i686 kernels, reduce the i686 package to a
> kernel-headers package that can be used to build 32bit versions of
> everything else.
>
>
OK I think this has a followup change which is sort of buried below:

No more i686 kernels mean that the i686 compose (aka .iso/etc) do not
happen. The only way would be for someone to engineer making anaconda
install an x86_64 kernel and i686 user space work. That is a lot of work
and probably a little late to start on. Howver as the below mentioned
absentee sponsor of i686.. I have no problems with this.

== Owner ==
> * Name: [[User:jforbes| Justin Forbes]]
> * Email: jfor...@fedoraproject.org
>
> == Detailed Description ==
> The i686 kernel is of limited use as most x86 hardware supports 64bit
> these days.  It has been in a status of "community supported" for
> several Fedora releases now.  As such, it gets very little testing,
> and issues frequently appear upstream. These tend to go unnoticed for
> long periods of time. When issues are found, it is often a long time
> before they are fixed because they are considered low priority by most
> developers upstream.  This can leave other architectures waiting for
> important updates, and provides a less than desirable experience for
> people choosing to run a 32bit kernel.
> With this proposal, the i686 kernel will no longer be built. A kernel
> headers package will still exist, and all 32bit packages should
> continue to build as normal. The main difference is there would no
> longer be bootable 32bit images.
>
> This was last proposed with Fedora 27, but it was deferred as an i686
> SIG was to be created to handle issues going forward.  That SIG has
> been largely unresponsive.  The only thread so far this year has been
> a thread starting with "Hello, I noticed that the x86 group hasn't had
> any reports in a while. As the absentee sponsor of the group, I would
> like to remind people on the list and interested in keeping x86_32 in
> Fedora releases that there is general work which needs to be done by
> people interested. "  And the only response was one person saying they
> would no longer have access to legacy i686 hardware as of August.
>
> == Benefit to Fedora ==
> More testable kernel updates, faster fixes for security bugs, and
> lowered exposure.
>
> == Scope ==
> * Proposal owners:
> Changes to the kernel spec to stop the actual i686 builds, but keep
> the kernel-headers package.
>
> * Other developers: NA
>
> * Release engineering: [https://pagure.io/releng/issue/8461]
> **
> [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List
> of deliverables]]: Drop i686 based images
> * Policies and guidelines: N/A (not needed for this change)
> * Trademark approval: N/A (not needed for this Change)
>
> == Upgrade/compatibility impact ==
> 32bit i686 users will need to reinstall as x86_64 with the next release.
>
> == How To Test ==
> N/A Nothing to test, we simply stop producing a flavor of the kernel
> package. As there is no direct upgrade path from i686 -> x86_64, users
> with capable hardware will have to reinstall.
>
> == User Experience ==
> The few 32bit users will have the full lifecycle of Fedora 30 to
> choose a time to upgrade to a 64bit installation.  Some old hardware
> will no longer be supported by fedora.
>
> == Dependencies ==
> 32 bit x86 images can no longer be built.
>
> == Contingency Plan ==
> * Contingency mechanism: (What to do?  Who will do it?) Start building
> an i686 kernel again
> * Contingency deadline: As QA requires for image candidates
> * Blocks release? Yes
> * Blocks product? product Fedora 31
>
> == Documentation ==
> The lack of an i686 image will need to be documented.
>
-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Orphaning rubygem-formtastic

2019-06-24 Thread Vít Ondruch

Hi everybody,

I have orphaned rubygem-formtastic, because I have no use for it and
nothing else depends on it.


Vít


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

Re: Reporting is disabled because the generated backtrace has low informational value

2019-06-24 Thread mcatanzaro


On Mon, Jun 24, 2019 at 6:50 AM, mcatanz...@gnome.org wrote:
That's not right. The backtrace was processed on the retrace server, 
so installing debuginfo locally should not be required.


I think it's a longstanding ABRT bug.

Michael


Oh, I forgot what I was actually planning to write about when I decided 
to send a mail. ABRT doesn't support reporting crashes from flatpak 
apps. It's a feature we requested a while ago [1]. In the meantime, if 
a flatpak app crashes, you'll have to generate a backtrace manually 
using the flatpak-coredumpctl command:


$ flatpak-coredumpctl org.gnome.Epiphany.Devel//master

So that's easy, but the backtrace will be useless unless you have debug 
symbols installed for both the runtime and the application. I can never 
remember how to do that and there doesn't exist documentation anywhere 
that I can see. ABRT will need to learn how to do all of this.


None of this is relevant to Chris's crash, because he's not reporting 
that a flatpak application is crashing. He's reporting that flatpak 
itself is crashing. ABRT should already be able to handle this like it 
does any other bug, and it's surely an ABRT bug for it to have failed 
here.


[1] https://github.com/abrt/abrt/issues/1196

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Reporting is disabled because the generated backtrace has low informational value

2019-06-24 Thread mcatanzaro

On Sun, Jun 23, 2019 at 9:34 PM, Sam Varshavchik 
 wrote:
That's your key piece of info. You're missing the debuginfo package, 
without it the backtrace has no info.


With a native, directly-installed RPM, the debug repo gets 
automatically enabled, and the debuginfo packages gets automatically 
fetched and installed. I guess with flatpacks, this is not automatic. 
Don't know much about flatpaks, but this is what you need to figure 
out how to make it happen.


That's not right. The backtrace was processed on the retrace server, so 
installing debuginfo locally should not be required.


I think it's a longstanding ABRT bug.

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

gawk major update (unannounced) breaks INPLACE_SUFFIX

2019-06-24 Thread Igor Gnatenko

Hello,

I just noticed that more than 700 of Rust packages are broken due to
gawk update (4.2.1 → 5.0.0). This is… bad.

https://bugzilla.redhat.com/show_bug.cgi?id=1723359
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: ABRT CLI rework

2019-06-24 Thread Dominik 'Rathann' Mierzejewski

On Friday, 21 June 2019 at 13:39, Ernestas Kulik wrote:
> Hi,
> 
> As we are all well aware, ABRT has two CLI tools (abrt-cli, from
> abrt-tui and abrt, from abrt-cli-ng). For a long while now, we in the

I wasn't. I've just installed it and I can see some UI differences
already.

1. `abrt ls' doesn't show which package the crashing binary belongs to
   while `abrt-cli ls' does.
2. Same for crash reason.
3. `abrt' without any parameters outputs a condensed version of
   `abrt ls', which is great!
4. `abrt' has a 'bt' option, which is great. `abrt-cli' lacks this.
5. Same for 'gdb' and 'di'.

All in all, abrt-cli-ng seems to be much better in terms of convenient
features. My only compliant is point 1 above, which seems to be covered
by https://github.com/abrt/abrt/issues/841 .

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 1723300] New: Upgrade perl-Promises to 1.02

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

Bug ID: 1723300
   Summary: Upgrade perl-Promises to 1.02
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Promises
  Assignee: dd...@cpan.org
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: dd...@cpan.org, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest Fedora delivers 1.01 version. Upstream released 1.02. When you have free
time, please upgrade it.

-- 
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: ABRT CLI rework

2019-06-24 Thread Miroslav Suchý

Dne 21. 06. 19 v 19:00 Chris Murphy napsal(a):
> I only ever use abrt-cli. I don't even have abrt on Fedora Workstation
> (or Server). This is a lot of abrt stuff...

Do not judge by the number of packages.
Most of those packages have only few files.

-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1721468] Upgrade perl-Proc-ProcessTable to 0.59

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

Jitka Plesnikova  changed:

   What|Removed |Added

URL||https://metacpan.org/releas
   ||e/Proc-ProcessTable
Summary|Upgrade |Upgrade
   |perl-Proc-ProcessTable to   |perl-Proc-ProcessTable to
   |0.58|0.59



-- 
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 1718809] Upgrade perl-WWW-Form-UrlEncoded to 0.26

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-WWW-Form-UrlEncoded-0.
   ||26-1.fc31
 Resolution|--- |RAWHIDE
Last Closed||2019-06-24 07:49:29



-- 
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 1722166] perl-Dancer2-0.208000 is available

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 CC|emman...@seyman.fr  |
   Fixed In Version||perl-Dancer2-0.208000-1.fc3
   ||1
 Resolution|--- |RAWHIDE
   Assignee|dd...@cpan.org  |jples...@redhat.com
Last Closed||2019-06-24 07:44:15



-- 
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: HEADS UP: DynamicBuildRequires are available

2019-06-24 Thread Pavel Raiskup

On Wednesday, June 19, 2019 10:14:34 PM CEST Pavel Raiskup wrote:
> Mirek submitted regular update for F30 [1] so even better (users will have
> *that* mock as well).  Once it reaches stable, it will be propagated to Copr
> builders automatically.
> 
> [1] https://bodhi.fedoraproject.org/updates/FEDORA-2019-efe97323a7 

I've checked this is working fine now [2] even in Copr.  Thanks to everywone
involved!

[2] 
https://copr-be.cloud.fedoraproject.org/results/praiskup/ping/fedora-rawhide-x86_64/00943575-rust-grep/

Pavel


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 1723234] perl-Test-Compile-2.0.1 is available