date:20191009

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

Bug ID: 1760159
   Summary: perl-DateTime-Locale-1.25 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-DateTime-Locale
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.25
Current version/release in rawhide: 1.24-3.fc31
URL: http://search.cpan.org/dist/DateTime-Locale/

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

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

[389-devel] Re: Future of nunc-stans

2019-10-09 Thread William Brown


> On 9 Oct 2019, at 19:55, Ludwig Krispenz  wrote:
> 
> Hi William,
> 
> I like your radical approach :-)
> 
> In my opinion our connection code is getting to complicated by maintaining 
> two different implementations in parallel -  not separated, but intermangled 
> (and even more complicated by turbo mode). So I agree we should have only 
> one, but which one ? In my opinion nunc stans is the theoretically better 
> approach, but nobody is confident enough to rely on nunc stans alone. The 
> conntable mode has its problems (especially if handling many concurrent 
> connections, and worse if they are established almost at the same 
> time)(otherwise we would not have experimented with nunc stans), but is 
> stable and for most of the use cases efficient enough.

I think you nailed it in one - we aren't confident in nunc-stans today, so 
let's keep what works and improve that. There are already many similar concepts 
- work queues, threads, even slapi_conn_t. I think that it would be possible to 
bring "nunc-stans ideas" into reworking and improvement to the current 
connection code instead. 

> 
> So reducing the complexity by removing nunc stans (and maybe also turbo mode) 
> and then do cleanup and try to improve the bottlenecks would be an acceptable 
> approach to me.

Agree. It also means we can make much smaller changes in an easier to control 
and test fashion I think. 

> 
> In my opinion the core of the problem of the "old" connection code is that 
> the main thread is handling new connections and already established 
> connections and so does iterate over the connection table. Using an event 
> model looks like the best way to handle this, but if it doesn't work we need 
> to look for other improvements without breaking things.
> Your suggestion to make the conn table data structure more lean and flexible 
> is one option. In sun ds, when I didn't know about event queues I did split 
> the main thread, one handling new connections and multiple to handle 
> established connections (parts of teh conn table) - reusing the existing 
> mechanisms, just splitting the load. Maybe we can also think in this 
> direction.

I think so too. We can certainly have some ideas about what actually does the 
polling vs what does accepting, or better, event management etc. There are some 
ideas to have smaller groups of workers too to improve thread locality and help 
improve concurrency too.

So maybe I'll put together a patch to remove nunc-stans soon then, and start to 
look at the existing connection code and options to improve that + some 
profiling.

I still would like to hear about my original question though as quoted below, I 
think Mark might have some comments :) 

>> The main question is *why* do we want it merged?
>> Is it performance? Recently I provided a patch that yielded an approximate 
>> ~30% speed up in the entire server through put just by changing our existing 
>> connection code.
>> Is it features? What features are we wanting from this? We have no 
>> complaints about our current threading model and thread allocations.
>> Is it maximum number of connections? We can always change the conntable to a 
>> better datastructure that would help scale this number higher (which would 
>> also yield a performance gain).

—
Sincerely,

William Brown

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

Re: FreeCAD required updates (PySide2 & Coin4)

2019-10-09 Thread Richard Shaw

On Tue, Oct 8, 2019 at 3:54 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Tue, Oct 08, 2019 at 08:32:47AM +0200, Ralf Corsepius wrote:
> > >
> > >Those are fairly substantial changes, but time is of essence here.
> > I could not disagree more. Quality and stability is of more essence,
> here.
>
> Richard is working on updating Coin to the latest version along with the
> dependent packages. The PRs were for rawhide. I don't think there's much
> choice: we need to update to latest versions of packages and rawhide is
> the appropriate place to do it, and we are early in the release cycle.
>

So the PRs were for Rawhide, but the bug I'm trying to fix exists on all
supported Fedora releases. I wasn't planning on updating F29 at this point
but F30 does have a lot of life left.

I don't like the idea of major upgrades within a release but the list of
dependencies (as noted by the list of PRs) is fairly small and through my
COPR I have found no *build* issues with the update.

I'm open to suggestion here but I don't like leaving broken software in
Fedora and basically having to tell the user, "It's fixed in Rawhide so
you'll get it eventually..."

Thoughts?

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

FedoraRespin-30-updates-20191009.0 compose check report

Missing expected images:

Soas live x86_64

Failed openQA tests: 2/31 (x86_64)

ID: 466138  Test: x86_64 KDE-live-iso release_identification
URL: https://openqa.fedoraproject.org/tests/466138
ID: 466148  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/466148

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

ID: 466130  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/466130

Passed openQA tests: 28/31 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 Final Freeze

2019-10-09 Thread Mamoru TASAKA


Sérgio Basto wrote on 2019/10/10 3:06:


Hi,

Some minutes before started "Final Freeze" we send some packages to
stable on bodhi [1], but bodhi didn't push then ... .
I.e After final freeze announce could we have the last bodhi push ? I
my point of view is not fair as a developer , having to deal with Bodhi
delays ...

Thanks

[1]
https://bodhi.fedoraproject.org/updates/FEDORA-2019-75145b258c


Because as written on https://fedoraproject.org/wiki/Releases/31/Schedule
(and as some people already complains about it), the freeze time was
2019-10-08 0:00 UTC, not 2019-10-08 23:59 UTC . So when the final freeze
announce was sent, it was _already_ frozen.

Regards,
Mamoru



On Tue, 2019-10-08 at 12:55 -0400, Mohan Boddu wrote:

Hi all,

Today, October 8th 2019, is an important day on the Fedora 31
schedule [1], with significant cut-offs.

Today we have the Final Freeze [2]. This means that only packages
which fix accepted blocker or freeze exception bugs [3][4][5] will be
marked as 'stable' and included in the Final composes. Other builds
will remain in updates-testing until the Final release is approved,
at
which point the Final freeze is lifted and packages can move to the
'updates' repository, pending updates will be pushed before final
release as zero day updates.

[1] https://fedoraproject.org/wiki/Releases/31/Schedule
[2] https://fedoraproject.org/wiki/Milestone_freezes
[3] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
[4]
https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
[5]
https://qa.fedoraproject.org/blockerbugs/milestone/31/final/buglist

Regards,
Mohan Boddu
Release Engineering



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 7 is broken for python3 related builds


On 09. 10. 19 21:23, Nico Kadel-Garcia wrote:

I'm not happy that RHEL upstream selected to use "python3" instead of
"python36" as the package name for their release of Python 3.6. Like
modularity, it's solving one problem but generating others.


All RHEL python3 packages also provide their python36 names. Where is the 
problem? If there is some, how can we fix it?


Complete the reverse process. Have all EPEL python 36 modules “provide” 
python3-module, as well.


If you give me a list of packages that you need, I can rebuild them to add the 
provide. Please don't just say "all", but actually either only give me the ones 
that block you or all that still don't have it.


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

Re: EPEL 7 is broken for python3 related builds


On 10. 10. 19 2:11, Nico Kadel-Garcia wrote:

On Wed, Oct 9, 2019 at 6:24 PM Miro Hrončok  wrote:


On 09. 10. 19 21:23, Nico Kadel-Garcia wrote:

On Oct 9, 2019, at 8:03 AM, Miro Hrončok  wrote:

On 09. 10. 19 13:47, Nico Kadel-Garcia wrote:
   It's going to be a while before EPEL gets all of the "python36"
labeled packages rebuilt to say "Provides: python3-module" as well as
"Provides: python36-module" for complete consistency with the altered
name used by RHEL. The epel-rpm-macros package sets the python modules
to set "python3_pkgversion" to be "36" instead of plain "3", and helps
find and resolve the python dependencies from the slightly older EPEL
versions. It also helps distinguish new built modules as being EPEL
based instead of merely RHEL or CentOS based.


How does epel-rpm-macros package sets the python modules to do that?
What kind of sorcery is there? AFAIk it is the %python_provide macro defined in 
python-rpm-macors (required by python3-devel).



It restores the python3_pkgversion to “36”, which EPEL packages expect and set 
requirements for.



I've just double checked and the package that sets this is indeed
epel-rpm-macros. But it is pulled to the buildroot for all epel7 builds.


I'm not happy that RHEL upstream selected to use "python3" instead of
"python36" as the package name for their release of Python 3.6. Like
modularity, it's solving one problem but generating others.


All RHEL python3 packages also provide their python36 names. Where is the 
problem? If there is some, how can we fix it?


Complete the reverse process. Have all EPEL python 36 modules “provide” 
python3-module, as well. Otherwise, building the packages with mock or koji is 
a bit of an adventure.


What adventure? Just BRing python%{python3_pkgversion}-foo as always worked
prior to this change and it still works afterwards.


Except that, for RHEL 7.7 and CentOS 7.7, they set python3_pkgversion
to "3". epel-rpm-macros restores it to "36", and re-enables build-time
dependency on the python36 modules that are only available from EPEL.
Fedora SRPM's have taken to listing dependencies as "python3-module",
so if you try to build a Fedora SRPM on RHEL or CentOS without doing
this "epel-rpm-macros" and replacing "python3-" with
"python%{python3_pkgversion}", you can't resolve the dependencies.


That wasn't possible before either.

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

Re: EPEL 7 is broken for python3 related builds

2019-10-09 Thread Nico Kadel-Garcia

On Wed, Oct 9, 2019 at 6:24 PM Miro Hrončok  wrote:
>
> On 09. 10. 19 21:23, Nico Kadel-Garcia wrote:
> >> On Oct 9, 2019, at 8:03 AM, Miro Hrončok  wrote:
> >>> On 09. 10. 19 13:47, Nico Kadel-Garcia wrote:
> >>>   It's going to be a while before EPEL gets all of the "python36"
> >>> labeled packages rebuilt to say "Provides: python3-module" as well as
> >>> "Provides: python36-module" for complete consistency with the altered
> >>> name used by RHEL. The epel-rpm-macros package sets the python modules
> >>> to set "python3_pkgversion" to be "36" instead of plain "3", and helps
> >>> find and resolve the python dependencies from the slightly older EPEL
> >>> versions. It also helps distinguish new built modules as being EPEL
> >>> based instead of merely RHEL or CentOS based.
> >>
> >> How does epel-rpm-macros package sets the python modules to do that?
> >> What kind of sorcery is there? AFAIk it is the %python_provide macro 
> >> defined in python-rpm-macors (required by python3-devel).
> >
> >
> > It restores the python3_pkgversion to “36”, which EPEL packages expect and 
> > set requirements for.
>
>
> I've just double checked and the package that sets this is indeed
> epel-rpm-macros. But it is pulled to the buildroot for all epel7 builds.
>
> >>> I'm not happy that RHEL upstream selected to use "python3" instead of
> >>> "python36" as the package name for their release of Python 3.6. Like
> >>> modularity, it's solving one problem but generating others.
> >>
> >> All RHEL python3 packages also provide their python36 names. Where is the 
> >> problem? If there is some, how can we fix it?
> >
> > Complete the reverse process. Have all EPEL python 36 modules “provide” 
> > python3-module, as well. Otherwise, building the packages with mock or koji 
> > is a bit of an adventure.
>
> What adventure? Just BRing python%{python3_pkgversion}-foo as always worked
> prior to this change and it still works afterwards.

Except that, for RHEL 7.7 and CentOS 7.7, they set python3_pkgversion
to "3". epel-rpm-macros restores it to "36", and re-enables build-time
dependency on the python36 modules that are only available from EPEL.
Fedora SRPM's have taken to listing dependencies as "python3-module",
so if you try to build a Fedora SRPM on RHEL or CentOS without doing
this "epel-rpm-macros" and replacing "python3-" with
"python%{python3_pkgversion}", you can't resolve the dependencies.

I've run full force into this with backporting things like updated
releases of awscli.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

No missing expected images.

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

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

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

ID: 465484  Test: x86_64 KDE-live-iso base_update_cli **GATING**
URL: https://openqa.fedoraproject.org/tests/465484
ID: 465502  Test: x86_64 Silverblue-dvd_ostree-iso desktop_terminal
URL: https://openqa.fedoraproject.org/tests/465502

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

ID: 465431  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/465431
ID: 465489  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/465489
ID: 465493  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/465493
ID: 465496  Test: x86_64 Silverblue-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/465496

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

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

ID: 465470  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/465470

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

ID: 465542  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/465542
ID: 465547  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/465547
ID: 465549  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/465549

Passed openQA tests: 144/153 (x86_64)

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

ID: 465541  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/465541
ID: 465579  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/465579

Skipped non-gating openQA tests: 1 of 155

Installed system changes in test x86_64 Server-dvd-iso install_default_upload: 
1 packages(s) added since previous compose: psmisc
Previous test data: https://openqa.fedoraproject.org/tests/464174#downloads
Current test data: https://openqa.fedoraproject.org/tests/465427#downloads

Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: 
1 packages(s) added since previous compose: psmisc
1 services(s) removed since previous compose: pcscd.service
Previous test data: https://openqa.fedoraproject.org/tests/464176#downloads
Current test data: https://openqa.fedoraproject.org/tests/465429#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default_upload: 
Used mem changed from 886 MiB to 1002 MiB
Used swap changed from 3 MiB to 5 MiB
3 packages(s) added since previous compose: criu, libnet, runc
1 services(s) added since previous compose: bolt.service
System load changed from 0.52 to 0.94
Average CPU usage changed from 13.49523810 to 33.3667
Previous test data: https://openqa.fedoraproject.org/tests/464209#downloads
Current test data: https://openqa.fedoraproject.org/tests/465462#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default@uefi: 
3 packages(s) added since previous compose: criu, libnet, runc
1 services(s) added since previous compose: bolt.service
Average CPU usage changed from 6.80952381 to 26.05238095
Previous test data: https://openqa.fedoraproject.org/tests/464211#downloads
Current test data: https://openqa.fedoraproject.org/tests/465464#downloads

Installed system changes in test x86_64 KDE-live-iso install_default_upload: 
Used mem changed from 747 MiB to 870 MiB
System load changed from 4.29 to 3.06
Average CPU usage changed from 71.01904762 to 32.29523810
Previous test data: https://openqa.fedoraproject.org/tests/464224#downloads
Current test data: https://openqa.fedoraproject.org/tests/465477#downloads

Installed system changes in test x86_64 KDE-live-iso install_default@uefi: 
System load changed from 1.70 to 1.52
Previous test data: https://openqa.fedoraproject.org/tests/464226#downloads
Current test data: https://openqa.fedoraproject.org/tests/465479#downloads

Installed system changes in test x86_64 Silverblue-dvd_ostree-iso 
install_default_upload: 
Mount /run/user/1000 contents changed to 114.0824338% of previous size
Used mem changed from 725 MiB to 881 MiB
Used Swap grew from 0 to 9 MiB
1

Fedora-31-20191008.n.1 compose check report

No missing expected images.

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

New failures (same test not failed in Fedora-31-20191007.n.0):

ID: 464926  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/464926
ID: 464927  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/464927
ID: 464940  Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/464940
ID: 464982  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/464982
ID: 464986  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/464986

Old failures (same test failed in Fedora-31-20191007.n.0):

ID: 464868  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/464868
ID: 464907  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/464907
ID: 464930  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/464930
ID: 464933  Test: x86_64 Silverblue-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/464933

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

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

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

Passed openQA tests: 144/153 (x86_64)

Skipped non-gating openQA tests: 1 of 155

Installed system changes in test x86_64 Workstation-live-iso 
install_default_upload: 
System load changed from 0.62 to 0.73
Average CPU usage changed from 11.14285714 to 30.72380952
Previous test data: https://openqa.fedoraproject.org/tests/464364#downloads
Current test data: https://openqa.fedoraproject.org/tests/464899#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default@uefi: 
System load changed from 0.33 to 0.49
Previous test data: https://openqa.fedoraproject.org/tests/464366#downloads
Current test data: https://openqa.fedoraproject.org/tests/464901#downloads

Installed system changes in test x86_64 KDE-live-iso install_default_upload: 
System load changed from 0.54 to 3.80
Previous test data: https://openqa.fedoraproject.org/tests/464379#downloads
Current test data: https://openqa.fedoraproject.org/tests/464914#downloads

Installed system changes in test x86_64 KDE-live-iso install_default@uefi: 
System load changed from 1.88 to 2.16
Previous test data: https://openqa.fedoraproject.org/tests/464381#downloads
Current test data: https://openqa.fedoraproject.org/tests/464916#downloads

Installed system changes in test x86_64 Silverblue-dvd_ostree-iso 
install_default@uefi: 
Mount /run/user/1000 contents changed to 114.1315015% of previous size
Previous test data: https://openqa.fedoraproject.org/tests/464397#downloads
Current test data: https://openqa.fedoraproject.org/tests/464934#downloads

Installed system changes in test x86_64 universal install_package_set_kde: 
System load changed from 0.29 to 1.33
Previous test data: https://openqa.fedoraproject.org/tests/464446#downloads
Current test data: https://openqa.fedoraproject.org/tests/465007#downloads
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora-31-20191009.n.0 compose check report

No missing expected images.

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

New failures (same test not failed in Fedora-31-20191008.n.1):

ID: 465842  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/465842

Old failures (same test failed in Fedora-31-20191008.n.1):

ID: 465793  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/465793
ID: 465832  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/465832
ID: 465855  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/465855
ID: 465858  Test: x86_64 Silverblue-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/465858

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

New soft failures (same test not soft failed in Fedora-31-20191008.n.1):

ID: 465911  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/465911

Passed openQA tests: 148/153 (x86_64)

New passes (same test not passed in Fedora-31-20191008.n.1):

ID: 465819  Test: x86_64 Server-dvd-iso realmd_join_sssd
URL: https://openqa.fedoraproject.org/tests/465819
ID: 465851  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/465851
ID: 465852  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/465852
ID: 465865  Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/465865
ID: 465907  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/465907

Skipped non-gating openQA tests: 1 of 155

Installed system changes in test x86_64 Workstation-live-iso 
install_default_upload: 
System load changed from 0.73 to 0.53
Previous test data: https://openqa.fedoraproject.org/tests/464899#downloads
Current test data: https://openqa.fedoraproject.org/tests/465824#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default@uefi: 
System load changed from 0.49 to 0.38
Previous test data: https://openqa.fedoraproject.org/tests/464901#downloads
Current test data: https://openqa.fedoraproject.org/tests/465826#downloads

Installed system changes in test x86_64 KDE-live-iso install_default_upload: 
System load changed from 3.80 to 1.36
Average CPU usage changed from 38.46190476 to 28.29047619
Previous test data: https://openqa.fedoraproject.org/tests/464914#downloads
Current test data: https://openqa.fedoraproject.org/tests/465839#downloads

Installed system changes in test x86_64 KDE-live-iso install_default@uefi: 
System load changed from 2.16 to 0.76
Previous test data: https://openqa.fedoraproject.org/tests/464916#downloads
Current test data: https://openqa.fedoraproject.org/tests/465841#downloads

Installed system changes in test x86_64 universal install_package_set_minimal: 
System load changed from 0.00 to 0.12
Previous test data: https://openqa.fedoraproject.org/tests/464992#downloads
Current test data: https://openqa.fedoraproject.org/tests/465917#downloads

Installed system changes in test x86_64 universal install_package_set_kde: 
Used mem changed from 776 MiB to 1000 MiB
1 services(s) added since previous compose: pcscd.service
System load changed from 1.33 to 2.22
Average CPU usage changed from 1.53809524 to 86.46190476
Previous test data: https://openqa.fedoraproject.org/tests/465007#downloads
Current test data: https://openqa.fedoraproject.org/tests/465932#downloads
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot


On 10. 10. 19 1:44, Stephen John Smoogen wrote:

On Wed, 9 Oct 2019 at 18:46, Miro Hrončok  wrote:





What I miss in the description is:

1. How does this thing actually work? is there an additional repository composed
from the default streams available in Koji only?

2. How are conflicts between packages from the default streams and ursine
package be handled?

3. What is the local experience if the packager is using mock. What if they are
using rpmbuild directly?



So from doing a lot of builds with mock, then the packager should be
ok because mock pulls in modules and you can define in mock which
module streams you want if you needed something differently. For
rpmbuild it is a bit harder because you may have used one module on
your local system and built with another.. However in someways this is
similar to rpm where I might have installed an F31 package on my F30
system to test something and then found out my local rpmbuild didn't
work.

In many ways I found working with mock easier than working with any of
the other system tools when dealing with modules. The file is very
well commented and it was clear what I needed to do to make it work.
So I can't answer anything else.. but I think the local experience for
mock users will be smoother than elsewhere.


What I really care about here is that the mock experience more or less equals 
the Koji experience. I.e. I don't want the packagers to (need to) enable modules 
in mock when in fact in Koji they are not enabled, but some other magic is 
happening.


Having a description about what this change actually does to enable modules in 
the buildroot will hopefully steer this discussion more to the specifics of how 
to enable the same thing in mock (by default).


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

Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot

2019-10-09 Thread Stephen John Smoogen

On Wed, 9 Oct 2019 at 18:46, Miro Hrončok  wrote:
>

> What I miss in the description is:
>
> 1. How does this thing actually work? is there an additional repository 
> composed
> from the default streams available in Koji only?
>
> 2. How are conflicts between packages from the default streams and ursine
> package be handled?
>
> 3. What is the local experience if the packager is using mock. What if they 
> are
> using rpmbuild directly?
>

So from doing a lot of builds with mock, then the packager should be
ok because mock pulls in modules and you can define in mock which
module streams you want if you needed something differently. For
rpmbuild it is a bit harder because you may have used one module on
your local system and built with another.. However in someways this is
similar to rpm where I might have installed an F31 package on my F30
system to test something and then found out my local rpmbuild didn't
work.

In many ways I found working with mock easier than working with any of
the other system tools when dealing with modules. The file is very
well commented and it was clear what I needed to do to make it work.
So I can't answer anything else.. but I think the local experience for
mock users will be smoother than elsewhere.

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

[Bug 1760037] perl-Role-Tiny-2.001003 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

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

Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot


On 09. 10. 19 22:46, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/Modules_In_Non-Modular_Buildroot

Enable module default streams in the buildroot repository for modular
and non-modular RPMs.

== Summary ==
This Change (colloquially referred to as "Ursa Prime") enables the
Koji build-system to include the RPM artifacts provided by module
default streams in the buildroot when building non-modular (or
"traditional") RPMs.

== Owner ==
* Name: [[User:Sgallagh| Stephen Gallagher]]
* Email: sgall...@redhat.com
* Responsible WG: Modularity WG

== Detailed Description ==
As a major part of the Modularity design, we have a concept of default
module streams. These streams are built as modules, but the RPM
artifacts they deliver are intended to be used just like non-modular
RPMS. The aspirational goal is that a user of the system who never
executes a module-specific command (such as `dnf module install
nodejs:8`) should experience no meaningful changes in behavior from
how they would interact with a completely non-modular system. In
practice, this may mean that the informational output of package
managers may indicate that modules are being enabled and used, but a
user that does not have a specific reason to interact with the
selection of a module stream should have that managed on their behalf.


If this is the goal of default modular streams, wouldn't it be in fact much 
easier to keep the default versions as urisne packages?



Similarly, the experience for package maintainers of non-modular
packages should be unaffected by an RPM dependency moving from the
non-modular repository into a default module stream. Up to the
present, this has not been the case; no module stream content has been
available in the non-modular buildroot for other packages to consume.
Koji builds of non-modular RPMs have had only the other non-modular
RPMs from that release available to their buildroots. In contrast,
building on local systems has access to both the non-modular RPMs and
the RPMs from any of the default module streams. With this Change,
Koji builds will have the same behavior and be able to depend on
content provided by default module streams. It also enables the same
behavior for Modular builds: the `platform` stream will now include
the contents of the default module streams for each release and do not
need to be explicitly specified in the modulemd `buildrequires`.


What I miss in the description is:

1. How does this thing actually work? is there an additional repository composed 
from the default streams available in Koji only?


2. How are conflicts between packages from the default streams and ursine 
package be handled?


3. What is the local experience if the packager is using mock. What if they are 
using rpmbuild directly?


4. How are we handling default streams with dependencies on non-default streams 
of other modules?



...
== Scope ==
* Proposal owners:
# Update Packaging Guidelines with
[https://pagure.io/modularity/issue/146#comment-600328 requirements]
for module default streams
# Create a Pungi configuration to generate the buildroot from the
default module streams.
# Include `default_modules_scm_url` in the platform virtual module specification
# Configure Koji tags for inheriting the new modular-defaults
buildroot into the standard buildroot

* Other developers:

Packagers of default module streams will be required to conform to the
[https://pagure.io/modularity/issue/146#comment-600328 policy]
regarding visibility of stream artifacts. Any default module stream
that is not in compliance by one week before Beta Freeze will cease to
be a default stream.


What are the packagers of ursine packages that are shadowed by their modular 
counterparts supposed to do here (assuming such shadowing happens)?


What are the packagers of modular packages that are shadowed by their ursine 
counterparts supposed to do here (assuming such shadowing happens)?



...
== How To Test ==
# Build a modular stream
# Make that stream a default stream (or a buildroot override)
# Build a non-modular RPM that requires an artifact RPM from the modular stream.


How can I test this as an ursine package maintainer assuming I have build 
dependencies that were ursine packages but now will be form modules?



...
== Contingency Plan ==
* Contingency mechanism: Disable the buildroot inheritance in Koji to
revert to the current behavior.


Assuming ursine packges will be retired from Fedora, what is the contingency 
there? Consider this scenario:


1. maintainers of the ook module welcome this change and finally they retire ook 
from ursine Fedora, shipping only the default ook:12 modular stream.

2. maintainers of ook-cool and ook-free happily build against modular ook:12
3. a previously unknown fundamental flaw in design triggers the contingency plan
4. ook-cool and ook-free FTBFS, maintainer of ook do no longer wish to maintain 
ook as ursine package, because the entire depndncy tree to make that happen was

Re: Modularity and the system-upgrade path

Robbie Harwood wrote:
> What's missing from a more Debian-style solution [1] (for instance) is a
> more full understanding of dependencies.  We could implement "Provides:"
> (or something like it) and be done with it.  This also could have the
> side affect of making package version upgrades more clean.
[snip]
> 
> So does having "foo-full" and "foo-minimal" both provide "foo" :)

This is already possible now. "Provides: foo" has been implemented in RPM 
for decades.

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

Re: Modularity and the system-upgrade path

Fabio Valentini wrote:
> Why am I not getting rid of the feeling that Modularity is getting shoved
> down our throats no matter the objections we raise?

I have had that feeling from day one. Things have not improved since. So you 
are not alone with that feeling.

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

Re: Modularity and the system-upgrade path

Miro Hrončok wrote:
> I disagree strongly with the reasons provided in the logs, but clearly, we
> should aim for solution 1. if solution 2. is not negotiable by the
> modularity WG.

+1

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

Re: Defining the future of the packager workflow in Fedora

Matthew Miller wrote:
> Yeah, I agree that there's a problem with non-parallel-installable modules
> that aren't effectively leaves.

The problem does not only happen if the module is a non-leaf at module 
level, but there can also be conflicts at package level, if the modules 
bundle non-leaf packages that then conflict between the 2 modules. 
(Actually, there could even be package-level conflicts from leaf packages in 
2 different modules, but usually, the conflicting packages are bundled for a 
reason, so they are typically not leaves.) So banning non-leaf modules would 
not by itself be enough to solve the problem (because the modules would then 
resort to bundling the non-leaf packages they need and running into the 
package-level conflicts).

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

Re: Defining the future of the packager workflow in Fedora

Dridi Boukelmoune wrote:
> Modularity should have been opt-in until major bugs are ironed out,
> and maybe we would have realized in time that either it's great or it
> doesn't solve anything the problem it's addressing.

+1

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

Re: Review swap (htslib)

Jun Aruga wrote:
> Someone, could give us advice about below situation, if the new
> package htslib's "/usr/lib64/libhts.so.1.9" is valid?
> "1.9" is upstream software's version. "2" is ABI's version (so version).

This can happen with non-autotools, non-libtool projects. libtool enforces 
some strict rules where the full version must be of the form 
major.minor.revision and the major version just major. (Actually, libtool 
doesn't even let you specify major and minor directly, but LT_CURRENT and 
LT_AGE, and it computes major=LT_CURRENT-LT_AGE and minor=LT_AGE for you.) 
Other build systems such as CMake allow you to set arbitrary strings as the 
major version and the full version, and the major version need not 
necessarily be a prefix of the full version. So they will let you get away 
with 1.9 as the full version and 2 as the major version.

There is nothing wrong with arbitrary versions if the build system used by 
upstream allows them. The Fedora packages should NOT change the upstream 
versioning scheme because it would make the packages incompatible with 
upstream.

So, to sum it up, yes, /usr/lib64/libhts.so.1.9 and /usr/lib64/libhts.so.2 
is a valid combination. Unusual, but valid.

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

Re: EPEL 7 is broken for python3 related builds


On 09. 10. 19 21:23, Nico Kadel-Garcia wrote:

On Oct 9, 2019, at 8:03 AM, Miro Hrončok  wrote:

On 09. 10. 19 13:47, Nico Kadel-Garcia wrote:
  It's going to be a while before EPEL gets all of the "python36"
labeled packages rebuilt to say "Provides: python3-module" as well as
"Provides: python36-module" for complete consistency with the altered
name used by RHEL. The epel-rpm-macros package sets the python modules
to set "python3_pkgversion" to be "36" instead of plain "3", and helps
find and resolve the python dependencies from the slightly older EPEL
versions. It also helps distinguish new built modules as being EPEL
based instead of merely RHEL or CentOS based.


How does epel-rpm-macros package sets the python modules to do that?
What kind of sorcery is there? AFAIk it is the %python_provide macro defined in 
python-rpm-macors (required by python3-devel).



It restores the python3_pkgversion to “36”, which EPEL packages expect and set 
requirements for.



I've just double checked and the package that sets this is indeed 
epel-rpm-macros. But it is pulled to the buildroot for all epel7 builds.



I'm not happy that RHEL upstream selected to use "python3" instead of
"python36" as the package name for their release of Python 3.6. Like
modularity, it's solving one problem but generating others.


All RHEL python3 packages also provide their python36 names. Where is the 
problem? If there is some, how can we fix it?


Complete the reverse process. Have all EPEL python 36 modules “provide” 
python3-module, as well. Otherwise, building the packages with mock or koji is 
a bit of an adventure.


What adventure? Just BRing python%{python3_pkgversion}-foo as always worked 
prior to this change and it still works afterwards.


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

[Bug 1760112] New: [RFE] EPEL8 branch of perl-Test-Number-Delta

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

Bug ID: 1760112
   Summary: [RFE] EPEL8 branch of perl-Test-Number-Delta
   Product: Fedora EPEL
   Version: epel8
Status: NEW
 Component: perl-Test-Number-Delta
  Assignee: tcall...@redhat.com
  Reporter: de...@fateyev.com
QA Contact: extras...@fedoraproject.org
CC: jose.p.oliveira@gmail.com,
perl-devel@lists.fedoraproject.org,
tcall...@redhat.com
  Target Milestone: ---
Classification: Fedora



Description of problem:
Please provide "perl-Test-Number-Delta" package for epel8.

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

[Bug 1760111] New: [RFE] EPEL8 branch of perl-Params-Coerce

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

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



Description of problem:
Please provide "perl-Params-Coerce" package for epel8.

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

[EPEL-devel] EPEL 7 - Packages that won't install - Pass 1

2019-10-09 Thread Troy Dawson

Hello,
With the release of RHEL 7.7 and CentOS 7.7, it is time to do a check
of what still installs, and what doesn't.  The good new, is that this
isn't as bad as it was with 7.6.  But, there are still some problems.
Below are the packages that don't install because something is
missing.  Either a package went away, was never there, or was updated
to an incompatible version.  Fixing these packages fixes many other
packages that depend on these.
In a day or two I will start filing bugzilla's if these packages are not fixed.

* Misc broken packages
dnsperf-2.2.1-3.el7.x86_64 source: dnsperf
-- bind updated
freshmaker-0.1.1-1.el7.x86_64 source: freshmaker
-- nothing provides python2-krbcontext
gerbv-2.7.0-2.el7.x86_64 source: gerbv
-- nothing provides electronics-menu
koji-containerbuild-builder-0.6.6-3.el7.noarch source: koji-containerbuild
-- nothing provides osbs-client
-- nothing provides python-osbs-client
kstars-17.08.2-2.1.el7.x86_64 source: kstars
-- libraw udpated
libnodeupdown-backend-openib-1.14-8.el7.x86_64 source: whatsup
-- opensm updated
lxqt-session-0.14.1-3.el7.x86_64 source: lxqt-session
-- nothing provides openbox-theme-mistral-thin
-- Only broken in epel-testing
mingw32-qt5-qtbase-5.6.0-3.el7.noarch source: mingw-qt5-qtbase
-- nothing provides mingw32-postgresql
mingw64-qt5-qtbase-5.6.0-3.el7.noarch source: mingw-qt5-qtbase
-- nothing provides mingw64-postgresql
python2-jaydebeapi-1.1.1-2.el7.noarch source: python-jaydebeapi
-- nothing provides python2-jpype
python2-pyvirtualize-0.9-6.20181003git57d2307.el7.noarch source:
python-pyvirtualize
-- nothing provides python2-pyvmomi
python36-dionaea-0.7.0-1.el7.1.x86_64 source: dionaea
-- nothing provides python36-bson
python36-sphinx-autobuild-0.7.1-9.el7.noarch source: python-sphinx-autobuild
-- nothing provides python3-{argh,livereload,pathtools,etc...}
qtpass-1.2.3-1.el7.x86_64 source: qtpass
-- nothing provides pass
spyder-2.3.7-4.el7.noarch source: spyder
-- nothing provides python-rope

* qt5 packages (RHEL 7 qt5 was updated to qt5-qtbase-5.9.7)
fcitx-qt5-1.2.2-2.el7.x86_64 source: fcitx-qt5
libqtxdg-2.0.0-12.el7.x86_64 source: libqtxdg
lxqt-qtplugin-0.11.1-11.el7.x86_64 source: lxqt-qtplugin
-- Fix is in epel-testing
qt5ct-0.35-1.el7.x86_64source: qt5ct
qt5-qtquick1-5.7.1-1.2bc722agit.el7.x86_64 source: qt5-qtquick1
-- Fix is in epel-testing
qt5-qtstyleplugins-5.0.0-26.el7.x86_64 source: qt5-qtstyleplugins
-- Fix is in epel-testing

* golang-*-devel (Not really broken, you should never need to install these)
** I will not file bugzilla's on these.  These -devel packages are
only used for rpm making.
golang-github-aws-aws-sdk-go-devel
golang-github-coreos-go-log-devel
golang-github-goraft-raft-devel
golang-github-rackspace-gophercloud-devel
golang-github-spacemonkeygo-spacelog-devel
golang-golangorg-oauth2-devel
golang-google-golangorg-cloud-devel

Troy Dawson
___
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: Modularity and the system-upgrade path


On 09. 10. 19 18:30, Matthew Miller wrote:

The problem is that the RHEL approach to modules only works because
RHEL is centrally developed and can be correctly coordinated to
overcome issues in the design. This is not true in Fedora, and there
doesn't seem to be allowances for this difference.


This seems *partly* fair. It's in some ways a natural consequence of Red Hat
funding the work and having to fit into RHEL release schedules. But I think
we can also get attention and work towards Fedora's needs -- especially with
8 out the door and 9 just twinkle in product management's eye.


And this is exactly the best time to stop and plan for a little and before we 
implement the a very fragile workaround proposed at the beginning of the thread 
just to approach the ideal state of "default modular packages behave just like 
regular packages".


In RHEL, we put some packages in modules to have the ability to declare: This 
module is only supported for X years, unlike the rest of RHEL.


In Fedora, we plan to maintain and treat the default modular streams the same 
way we do with regular packages. We have the ability to keep them as regular 
packages. This approach was clearly treated positively by the community in this 
thread so far. Let's keep modularity in Fedora to do what it was promised to do: 
Make it possible to install alternate versions of software. Instead, the 
majority of Fedora's modules is one stream only. I seriously think that brings 
no benefit to the users and it makes everything needlessly more complicated.


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

[EPEL-devel] Re: A plan regarding SCLs in EPEL 8

2019-10-09 Thread Kevin Fenzi

On Mon, Oct 07, 2019 at 01:16:47PM -0500, Merlin Mathesius wrote:
> I was asked to draft a plan stating what EPEL 8 should do regarding
> Software Collections. The draft I came up with is included below.

Looks good to me. +1 here. 

> EPEL Steering Committee: Please ratify this plan or provide feedback as
> necessary. When it's ready, and I will prepare a PR for this to land in
> https://pagure.io/epel/blob/master/f/docs/source

That would be great... 

kevin
--
> 
> Regards,
> 
> Merlin
> 
> --
> 
> 
> *Regarding EPEL and Software Collections*
> *Background*
> 
> For RHEL 8, Red Hat made the decision to provide multiple versions of
> software in the form of App Stream modules instead of Red Hat Software
> Collections (RHSCLs).
> 
> SCLs are maintained by the CentOS Software Collections SIG, not the EPEL
> SIG.
> 
> RHEL 8 comes with the scl-utils and scl-utils-build packages--which contain
> tools for using and building SCLs. These packages appear to function as
> expected with RHEL 8 and CentOS 8.
> 
> *Recommendations*
> 
> EPEL will not provide SCL support, although it will not prohibit use of the
> SCL tools provided with RHEL 8.
> 
> EPEL will not provide any SCLs.
> 
> EPEL encourages the community to follow Red Hat’s lead and provide multiple
> versions of software for RHEL 8 and CentOS 8 in the form of modules rather
> than SCLs.
> 
> For use cases that require the parallel installation of multiple versions
> of the same component, EPEL recommends the same solution as RHEL 8:
> containers.
> 
> --

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



signature.asc
Description: PGP signature
___
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

Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot

https://fedoraproject.org/wiki/Changes/Modules_In_Non-Modular_Buildroot

Enable module default streams in the buildroot repository for modular
and non-modular RPMs.

== Summary ==
This Change (colloquially referred to as "Ursa Prime") enables the
Koji build-system to include the RPM artifacts provided by module
default streams in the buildroot when building non-modular (or
"traditional") RPMs.

== Owner ==
* Name: [[User:Sgallagh| Stephen Gallagher]]
* Email: sgall...@redhat.com
* Responsible WG: Modularity WG

== Detailed Description ==
As a major part of the Modularity design, we have a concept of default
module streams. These streams are built as modules, but the RPM
artifacts they deliver are intended to be used just like non-modular
RPMS. The aspirational goal is that a user of the system who never
executes a module-specific command (such as `dnf module install
nodejs:8`) should experience no meaningful changes in behavior from
how they would interact with a completely non-modular system. In
practice, this may mean that the informational output of package
managers may indicate that modules are being enabled and used, but a
user that does not have a specific reason to interact with the
selection of a module stream should have that managed on their behalf.

Similarly, the experience for package maintainers of non-modular
packages should be unaffected by an RPM dependency moving from the
non-modular repository into a default module stream. Up to the
present, this has not been the case; no module stream content has been
available in the non-modular buildroot for other packages to consume.
Koji builds of non-modular RPMs have had only the other non-modular
RPMs from that release available to their buildroots. In contrast,
building on local systems has access to both the non-modular RPMs and
the RPMs from any of the default module streams. With this Change,
Koji builds will have the same behavior and be able to depend on
content provided by default module streams. It also enables the same
behavior for Modular builds: the `platform` stream will now include
the contents of the default module streams for each release and do not
need to be explicitly specified in the modulemd `buildrequires`.

Note: This Change does not address the other major Modularity issue we
are facing around distribution upgrades with differing default
streams. When discussing this Change, please keep that topic separate.

== Benefit to Fedora ==

This will simplify the lives of package maintainers in Fedora in two
primary ways. I'll use a hypothetical example of the Node.js
interpreter and a JSApp package which is capable of running on Node.js
10 or 12 (but requires newer features than are provided by Node.js 8).
Additionally, the JSApp package requires the same versions of Node.js
at build-time.

* Fedora 29 ships `nodejs:8`, `nodejs:10` and `nodejs:12` module
streams. The `nodejs:10` stream is set as the default stream.
* Fedora 30 ships `nodejs:8`, `nodejs:10` and `nodejs:12` module
streams. The `nodejs:10` stream is set as the default stream.
* Fedora 31 ships `nodejs:10` and `nodejs:12` module streams. The
`nodejs:12` stream is set as the default stream. The `nodejs:14`
stream will likely become available during the F31 lifetime.
* Fedora 32 ships `nodejs:10` and `nodejs:12` module streams. The
`nodejs:12` stream is set as the default stream. The `nodejs:14`
stream will likely become available during the F32 lifetime.

On Fedora 29 through 31, the Node.js package maintainer needs to build
the `nodejs:10` package both as a module and as a non-modular RPM in
the distribution so that the JSApp package can be built. With this
Change, the Node.js package maintainer in Fedora 32+ will only need to
build the various Node.js streams and make one of them the default
stream. The packages from it will then be added to the buildroot for
non-modular packages. This will also make the packaging process
somewhat more efficient, as the maintainer needs only to manage the
module stream and the MBS will build it for all configured platforms.

Similarly, from the perspective of dependent maintainers, there will
no longer be anxiety about needing to move their package to a module
if one or more of their dependencies drops their non-modular version
in favor of a default stream. Their builds will continue to work as
they do today.

== Scope ==
* Proposal owners:
# Update Packaging Guidelines with
[https://pagure.io/modularity/issue/146#comment-600328 requirements]
for module default streams
# Create a Pungi configuration to generate the buildroot from the
default module streams.
# Include `default_modules_scm_url` in the platform virtual module specification
# Configure Koji tags for inheriting the new modular-defaults
buildroot into the standard buildroot

* Other developers:

Packagers of default module streams will be required to conform to the
[https://pagure.io/modularity/issue/146#comment-600328 policy]
regarding visibility of stream artifacts. Any

Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot

https://fedoraproject.org/wiki/Changes/Modules_In_Non-Modular_Buildroot

Enable module default streams in the buildroot repository for modular
and non-modular RPMs.

== Summary ==
This Change (colloquially referred to as "Ursa Prime") enables the
Koji build-system to include the RPM artifacts provided by module
default streams in the buildroot when building non-modular (or
"traditional") RPMs.

== Owner ==
* Name: [[User:Sgallagh| Stephen Gallagher]]
* Email: sgall...@redhat.com
* Responsible WG: Modularity WG

== Detailed Description ==
As a major part of the Modularity design, we have a concept of default
module streams. These streams are built as modules, but the RPM
artifacts they deliver are intended to be used just like non-modular
RPMS. The aspirational goal is that a user of the system who never
executes a module-specific command (such as `dnf module install
nodejs:8`) should experience no meaningful changes in behavior from
how they would interact with a completely non-modular system. In
practice, this may mean that the informational output of package
managers may indicate that modules are being enabled and used, but a
user that does not have a specific reason to interact with the
selection of a module stream should have that managed on their behalf.

Similarly, the experience for package maintainers of non-modular
packages should be unaffected by an RPM dependency moving from the
non-modular repository into a default module stream. Up to the
present, this has not been the case; no module stream content has been
available in the non-modular buildroot for other packages to consume.
Koji builds of non-modular RPMs have had only the other non-modular
RPMs from that release available to their buildroots. In contrast,
building on local systems has access to both the non-modular RPMs and
the RPMs from any of the default module streams. With this Change,
Koji builds will have the same behavior and be able to depend on
content provided by default module streams. It also enables the same
behavior for Modular builds: the `platform` stream will now include
the contents of the default module streams for each release and do not
need to be explicitly specified in the modulemd `buildrequires`.

Note: This Change does not address the other major Modularity issue we
are facing around distribution upgrades with differing default
streams. When discussing this Change, please keep that topic separate.

== Benefit to Fedora ==

This will simplify the lives of package maintainers in Fedora in two
primary ways. I'll use a hypothetical example of the Node.js
interpreter and a JSApp package which is capable of running on Node.js
10 or 12 (but requires newer features than are provided by Node.js 8).
Additionally, the JSApp package requires the same versions of Node.js
at build-time.

* Fedora 29 ships `nodejs:8`, `nodejs:10` and `nodejs:12` module
streams. The `nodejs:10` stream is set as the default stream.
* Fedora 30 ships `nodejs:8`, `nodejs:10` and `nodejs:12` module
streams. The `nodejs:10` stream is set as the default stream.
* Fedora 31 ships `nodejs:10` and `nodejs:12` module streams. The
`nodejs:12` stream is set as the default stream. The `nodejs:14`
stream will likely become available during the F31 lifetime.
* Fedora 32 ships `nodejs:10` and `nodejs:12` module streams. The
`nodejs:12` stream is set as the default stream. The `nodejs:14`
stream will likely become available during the F32 lifetime.

On Fedora 29 through 31, the Node.js package maintainer needs to build
the `nodejs:10` package both as a module and as a non-modular RPM in
the distribution so that the JSApp package can be built. With this
Change, the Node.js package maintainer in Fedora 32+ will only need to
build the various Node.js streams and make one of them the default
stream. The packages from it will then be added to the buildroot for
non-modular packages. This will also make the packaging process
somewhat more efficient, as the maintainer needs only to manage the
module stream and the MBS will build it for all configured platforms.

Similarly, from the perspective of dependent maintainers, there will
no longer be anxiety about needing to move their package to a module
if one or more of their dependencies drops their non-modular version
in favor of a default stream. Their builds will continue to work as
they do today.

== Scope ==
* Proposal owners:
# Update Packaging Guidelines with
[https://pagure.io/modularity/issue/146#comment-600328 requirements]
for module default streams
# Create a Pungi configuration to generate the buildroot from the
default module streams.
# Include `default_modules_scm_url` in the platform virtual module specification
# Configure Koji tags for inheriting the new modular-defaults
buildroot into the standard buildroot

* Other developers:

Packagers of default module streams will be required to conform to the
[https://pagure.io/modularity/issue/146#comment-600328 policy]
regarding visibility of stream artifacts. Any

Re: django-pytest vs pytest-django

2019-10-09 Thread Jason L Tibbitts III

> "DM" == David Moreau-Simard  writes:

DM> I don't have the bandwidth to take care of pytest-django right now.
DM> Would it be acceptable to propose a new package without %check until
DM> it gets packaged ?

It's OK to disable tests you can't run because they have additional
dependencies which aren't in the distribution, though certainly the
alternative of packaging that dependency and running all of the tests is
preferable.

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

Open NeuroFedora team meeting: 1500 UTC on Thursday, 10th October

2019-10-09 Thread Ankur Sinha

Hello everyone,

You are all invited to attend the Open NeuroFedora team meeting this week
on Thursday (10th October) at 1500UTC in #fedora-neuro on IRC (Freenode):

https://webchat.freenode.net/?channels=#fedora-neuro

You can convert the meeting time to your local time using:
$ date --date='TZ="UTC" 1500 next Thu'

or use this link:
https://www.timeanddate.com/worldclock/fixedtime.html?msg=Neuro-Fedora+team+meeting=20191010T15=%3A

The meeting will be chaired by @ankursinha (FranciscoD). The agenda for the 
meeting
is:

- Introductions and roll call.
- Tasks from last week's meeting:
  
https://meetbot.fedoraproject.org/teams/neurofedora/neurofedora.2019-10-03-15.06.html
- Pagure tickets: 
https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open=S%3A+Next+meeting
- Open bugs: https://tinyurl.com/neurofedora-bugs
- Neuroscience query of the week.
- Next meeting day, and chair.
- Open floor.

In the "Neuroscience query of the week" section, we hope to provide
attendees with the chance to ask about a neuroscience topic that they
are curious about.

Please go through the tickets on Pagure, and mark any other tickets that
need to be discussed with the "S: Next meeting" tag.

We hope to see you there!

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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

Re: EPEL 7 is broken for python3 related builds

2019-10-09 Thread Stephen John Smoogen

On Wed, 9 Oct 2019 at 15:24, Nico Kadel-Garcia  wrote:
>
>
>
> > On Oct 9, 2019, at 8:03 AM, Miro Hrončok  wrote:
> >
> >> On 09. 10. 19 13:47, Nico Kadel-Garcia wrote:
> >>  It's going to be a while before EPEL gets all of the "python36"
> >> labeled packages rebuilt to say "Provides: python3-module" as well as
> >> "Provides: python36-module" for complete consistency with the altered
> >> name used by RHEL. The epel-rpm-macros package sets the python modules
> >> to set "python3_pkgversion" to be "36" instead of plain "3", and helps
> >> find and resolve the python dependencies from the slightly older EPEL
> >> versions. It also helps distinguish new built modules as being EPEL
> >> based instead of merely RHEL or CentOS based.
> >
> > How does epel-rpm-macros package sets the python modules to do that?
> > What kind of sorcery is there? AFAIk it is the %python_provide macro 
> > defined in python-rpm-macors (required by python3-devel).
>
>
> It restores the python3_pkgversion to “36”, which EPEL packages expect and 
> set requirements for.
>
> >> I'm not happy that RHEL upstream selected to use "python3" instead of
> >> "python36" as the package name for their release of Python 3.6. Like
> >> modularity, it's solving one problem but generating others.
> >
> > All RHEL python3 packages also provide their python36 names. Where is the 
> > problem? If there is some, how can we fix it?
>
> Complete the reverse process. Have all EPEL python 36 modules “provide” 
> python3-module, as well. Otherwise, building the packages with mock or koji 
> is a bit of an adventure.

Could we have an example package which is currently broken showing
what you are seeing? I say this because I am most likely going to pull
out a package to test which will work which doesn't invalidate your
problem.. it just means I was lucky.




-- 
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: EPEL 7 is broken for python3 related builds

2019-10-09 Thread Nico Kadel-Garcia



> On Oct 9, 2019, at 8:03 AM, Miro Hrončok  wrote:
> 
>> On 09. 10. 19 13:47, Nico Kadel-Garcia wrote:
>>  It's going to be a while before EPEL gets all of the "python36"
>> labeled packages rebuilt to say "Provides: python3-module" as well as
>> "Provides: python36-module" for complete consistency with the altered
>> name used by RHEL. The epel-rpm-macros package sets the python modules
>> to set "python3_pkgversion" to be "36" instead of plain "3", and helps
>> find and resolve the python dependencies from the slightly older EPEL
>> versions. It also helps distinguish new built modules as being EPEL
>> based instead of merely RHEL or CentOS based.
> 
> How does epel-rpm-macros package sets the python modules to do that?
> What kind of sorcery is there? AFAIk it is the %python_provide macro defined 
> in python-rpm-macors (required by python3-devel).


It restores the python3_pkgversion to “36”, which EPEL packages expect and set 
requirements for.

>> I'm not happy that RHEL upstream selected to use "python3" instead of
>> "python36" as the package name for their release of Python 3.6. Like
>> modularity, it's solving one problem but generating others.
> 
> All RHEL python3 packages also provide their python36 names. Where is the 
> problem? If there is some, how can we fix it?

Complete the reverse process. Have all EPEL python 36 modules “provide” 
python3-module, as well. Otherwise, building the packages with mock or koji is 
a bit of an adventure.



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

Fedora 31 compose report: 20191009.n.0 changes

2019-10-09 Thread Fedora Branched Report

OLD: Fedora-31-20191008.n.1
NEW: Fedora-31-20191009.n.0

= SUMMARY =
Added images:3
Dropped images:  2
Added packages:  0
Dropped packages:0
Upgraded packages:   0
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   0 B
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Server boot armhfp
Path: Server/armhfp/iso/Fedora-Server-netinst-armhfp-31-20191009.n.0.iso
Image: Server dvd armhfp
Path: Server/armhfp/iso/Fedora-Server-dvd-armhfp-31-20191009.n.0.iso
Image: Server raw-xz armhfp
Path: Server/armhfp/images/Fedora-Server-armhfp-31-20191009.n.0-sda.raw.xz

= DROPPED IMAGES =
Image: Python_Classroom vagrant-libvirt x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-31-20191008.n.1.x86_64.vagrant-libvirt.box
Image: Python_Classroom vagrant-virtualbox x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-31-20191008.n.1.x86_64.vagrant-virtualbox.box

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =

= DOWNGRADED PACKAGES =
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 1759042] Please build perl-OLE-Storage_Lite for EPEL 8

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-Digest-MD4-1.9-23.el8, perl-OLE-Storage_Lite-0.19-27.el8,
perl-Spreadsheet-WriteExcel-2.40-17.el8 has been pushed to the Fedora EPEL 8
testing repository. If problems still persist, please make note of it in this
bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-e98bb2e24f

-- 
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 1758479] perl-DBD-CSV for EL8

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-DBD-CSV-0.54-5.el8, perl-SQL-Statement-1.412-13.el8 has been pushed to the
Fedora EPEL 8 testing repository. If problems still persist, please make note
of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-dd49a0dcde

-- 
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 1759489] perl-Net-Patricia packages for EPEL 8

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-Net-CIDR-Lite-0.21-26.el8, perl-Net-Patricia-1.22-23.el8 has been pushed
to the Fedora EPEL 8 testing repository. If problems still persist, please make
note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-21b8d6dfae

-- 
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 1752674] [RFE] EPEL8 branch of perl-Test-MockModule

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

-- 
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 1753028] [RFE] EPEL8 branch of perl-Test-CheckManifest

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

-- 
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 1758564] perl-SQL-Statement for EL8

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
perl-DBD-CSV-0.54-5.el8, perl-SQL-Statement-1.412-13.el8 has been pushed to the
Fedora EPEL 8 testing repository. If problems still persist, please make note
of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-dd49a0dcde

-- 
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 1759043] Please build perl-Spreadsheet-WriteExcel for EPEL 8

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-Digest-MD4-1.9-23.el8, perl-OLE-Storage_Lite-0.19-27.el8,
perl-Spreadsheet-WriteExcel-2.40-17.el8 has been pushed to the Fedora EPEL 8
testing repository. If problems still persist, please make note of it in this
bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-e98bb2e24f

-- 
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 1759039] Please build perl-Crypt-RC4 for EPEL 8

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

-- 
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 1758589] perl-Math-Base-Convert for EL8

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

-- 
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 1758580] perl-Test-Dependencies for EL8

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

-- 
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 1754947] perl-Monitoring-Plugin is missing in EPEL-8

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #6 from Fedora Update System  ---
perl-Math-Calc-Units-1.07-26.el8, perl-Monitoring-Plugin-0.40-1.el8 has been
pushed to the Fedora EPEL 8 testing repository. If problems still persist,
please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bd2e51adf9

-- 
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 1754281] [RFE] EPEL-8 branch for perl-Coro-Multicore

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2019-10-09 18:55:32



--- Comment #4 from Fedora Update System  ---
perl-Coro-Multicore-1.03-3.el8 has been pushed to the Fedora EPEL 8 stable
repository. If problems still persist, please make note of it in this bug
report.

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

[Bug 1754852] [RFE] EPEL8 branch of perl-Test-Output

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-Test-Output-1.03.1-9.e
   ||l8
 Resolution|--- |ERRATA
Last Closed||2019-10-09 18:55:37



--- Comment #4 from Fedora Update System  ---
perl-Test-Output-1.03.1-9.el8 has been pushed to the Fedora EPEL 8 stable
repository. If problems still persist, please make note of it in this bug
report.

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

[Bug 1754282] [RFE] EPEL-8 branch for perl-Compress-LZF

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

Bug 1754281 Summary: [RFE] EPEL-8 branch for perl-Coro-Multicore
https://bugzilla.redhat.com/show_bug.cgi?id=1754281

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA



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

[Bug 1744683] [RFE] EPEL8 branch for perl-SOAP-Lite

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-SOAP-Lite-1.27-7.el8
 Resolution|--- |ERRATA
Last Closed||2019-10-09 18:55:26



--- Comment #6 from Fedora Update System  ---
perl-SOAP-Lite-1.27-7.el8 has been pushed to the Fedora EPEL 8 stable
repository. If problems still persist, please make note of it in this bug
report.

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

Fedora 31 Final Release Readiness Meeting

Dear all,

Join us on irc.freenode.net in #fedora-meeting-1 for the Fedora 31
Final Release Readiness  meeting. This meeting will be held on
Thursday, 2019-10-17 at 19:00 UTC.

We will meet to make sure we are coordinated and ready for the release
of Fedora 31 Final. Please note that this meeting will be held even if
the release is delayed at the Go/No-Go meeting on the same day two
hours earlier.

You may receive this message several times in order to open this
meeting to the teams and to raise awareness, so hopefully more team
representatives will come to this meeting. This meeting works best
when we have representatives from all of the teams.

For more information, see
https://fedoraproject.org/wiki/Release_Readiness_Meetings.

View the meeting on Fedocal:
https://apps.fedoraproject.org/calendar/Fedora%20release/2019/10/17/#m9630

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

[POC-change] Fedora packages point of contact updates

2019-10-09 Thread nobody

Change in package status over the last 168 hours


0 packages were orphaned


0 packages were retired


0 packages unorphaned
-

0 packages were unretired


0 packages were given


0 packages had new branches



Sources: https://github.com/pypingou/fedora-owner-change
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 1760071] New: perl-Pod-Markdown-3.200 is available

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

Bug ID: 1760071
   Summary: perl-Pod-Markdown-3.200 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Pod-Markdown
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, p...@city-fan.org,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 3.200
Current version/release in rawhide: 3.101-4.fc31
URL: http://search.cpan.org/dist/Pod-Markdown/

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

-- 
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 1760037] perl-Role-Tiny-2.001003 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



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

-- 
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 1760037] perl-Role-Tiny-2.001003 is available

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

Paul Howarth  changed:

   What|Removed |Added

   Fixed In Version||perl-Role-Tiny-2.001003-1.f
   ||c32



-- 
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 1760037] perl-Role-Tiny-2.001003 is available

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|emman...@seyman.fr  |p...@city-fan.org



-- 
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: Has fedpkg + dist-git replaced rpmbuild for building new/local packages?

2019-10-09 Thread Ankur Sinha

On Wed, Oct 09, 2019 11:54:14 +0100, Ankur Sinha wrote:
> On Wed, Oct 09, 2019 11:52:28 +0300, Panu Matilainen wrote:
> > On 10/8/19 3:26 PM, Ankur Sinha wrote:
> > > On Tue, Oct 08, 2019 13:03:48 +0300, Panu Matilainen wrote:
> > > > 
> > > > 
> > > > Look, I'm no more in love with the traditional layout than anybody, I'm 
> > > > just
> > > > saying changing the default is not as simple as you'd like to think. 
> > > > Anybody
> > > > wanting to work on changing the default is welcome to propose it 
> > > > upstream,
> > > > patches welcome and all.
> > > 
> > > Would keeping this Fedora specific to begin with help slowly migrate
> > > people over? What if we announce this via the change process for F32?
> > > The change will be to modify `/usr/lib/rpm/macros` to use per-directory
> > > locations as you'd suggested in the snippet since it is closer to the
> > > dist-git workflow that is now in use. People can still easily revert to
> > > rpmbuild/*, and the contingency plan will be to just not make the
> > > change. I don't know how this would affect rpmdev-buildtree and how to
> > > handle that (remove it?).
> > > 
> > 
> > Changing rpm defaults will break existing setups, people will be unhappy and
> > I'll get the blame regardless of who actually did it.
> > 
> > I'd rather suggest changing rpmdev-setuptree to configure things that way,
> > it already modifies ~/.rpmmacros in various ways, some totally redundant
> > (like setting %_topdir to a longtime rpm default).
> > That starts nudging people towards that direction, but leaves existing
> > setups alone.
> 
> Sure. That sounds good. I'll see what I can come up with an open PRs
> etc.

PR filed: https://pagure.io/rpmdevtools/pull-request/48

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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

Re: Fedora 31 Final Freeze

2019-10-09 Thread Sérgio Basto


Hi,

Some minutes before started "Final Freeze" we send some packages to
stable on bodhi [1], but bodhi didn't push then ... .
I.e After final freeze announce could we have the last bodhi push ? I
my point of view is not fair as a developer , having to deal with Bodhi
delays ... 

Thanks

[1]
https://bodhi.fedoraproject.org/updates/FEDORA-2019-75145b258c

On Tue, 2019-10-08 at 12:55 -0400, Mohan Boddu wrote:
> Hi all,
> 
> Today, October 8th 2019, is an important day on the Fedora 31
> schedule [1], with significant cut-offs.
> 
> Today we have the Final Freeze [2]. This means that only packages
> which fix accepted blocker or freeze exception bugs [3][4][5] will be
> marked as 'stable' and included in the Final composes. Other builds
> will remain in updates-testing until the Final release is approved,
> at
> which point the Final freeze is lifted and packages can move to the
> 'updates' repository, pending updates will be pushed before final
> release as zero day updates.
> 
> [1] https://fedoraproject.org/wiki/Releases/31/Schedule
> [2] https://fedoraproject.org/wiki/Milestone_freezes
> [3] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
> [4] 
> https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
> [5] 
> https://qa.fedoraproject.org/blockerbugs/milestone/31/final/buglist
> 
> Regards,
> Mohan Boddu
> Release Engineering
> ___
> devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
> To unsubscribe send an email to 
> devel-announce-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: FreeCAD required updates (PySide2 & Coin4)

2019-10-09 Thread Mauricio Tavares

Stupid question: does FreeCAD have nightly packages (like openscad)?
If so, how complicate would it be to run the coin4 version there for a
while so people can monkey with it and find issues? Then give some
time; if it seems to work happy, make it production.

Just my two pesos Russos.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: FreeCAD required updates (PySide2 & Coin4)

2019-10-09 Thread Simo Sorce

On Tue, 2019-10-08 at 10:07 -0500, Richard Shaw wrote:
> On Tue, Oct 8, 2019 at 1:35 AM Ralf Corsepius  wrote:
> 
> > On 10/8/19 8:03 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > > On Mon, Oct 07, 2019 at 04:34:28PM -0400, Scott Talbert wrote:
> > > > On Mon, 7 Oct 2019, Richard Shaw wrote:
> > > > 
> > > > > I am in the midst of updating the freecad package in two major ways:
> > > > > Qt4 -> Qt5 (via PySide -> PySide2, which also facilitates moving from
> > 
> > Python
> > > > > 2 to 3)
> > > > > and
> > > > > Coin3 -> Coin4 (Which requires several other packages move to Coin4)
> > > > > 
> > > > > I have been working with the Coin2/3, SoQt, & SIMVoleon maintainer
> > 
> > Ralf but
> > > > > I stopped getting responses. The last response by email being 
> > > > > September
> > > > > 13th.
> > > > > 
> > > > > I have even submitted pull requests so my requested changes can be
> > 
> > easily
> > > > > evaluated.
> > > > > 
> > > > > https://src.fedoraproject.org/rpms/SoQt/pull-request/2
> > > > > https://src.fedoraproject.org/rpms/OpenSceneGraph/pull-request/2
> > > > > https://src.fedoraproject.org/rpms/SIMVoleon/pull-request/1
> > > > > 
> > > > > Updating to Coin4 is required to take care of a longstanding bug[1]
> > > > > 
> > > > > So I'm trying to be nice but I don't think it's doing any good to wait
> > 
> > for a
> > > > > reply that may never come meanwhile the users could easily get the
> > 
> > idea that
> > > > > I (or Fedora) don't care about fixing bugs.
> > > 
> > > Those are fairly substantial changes, but time is of essence here.
> > 
> > I could not disagree more. Quality and stability is of more essence, here.
> > 
> 
> Very few of us (packagers) are computer scientists or the like or paid like
> RHEL to evaluate every possible problem that could arise with adopting new
> releases of software. Nor can we all be expected to backport fixes in every
> case. If you want that, run RHEL/CentOS instead. In the case of Coin4 is
> addresses a REAL issue with FreeCAD and Coin3. I built test packages of the
> whole stack and even went so far as to create a COPR to test the result and
> moving to Coin4 does indeed fix the problem with importing SVG images as
> geometry.
> 
> So what do you suggest I do instead? Fedora tends to run the latest
> versions of packages on purpose.
> 
> 
> > I reviewed all three PRs, and they look fine. (One needs a rebase).
> > > I think you should just push and build all packages.
> > 
> > You don't want to know what I think of this.
> > 
> 
> I knew you probably wouldn't like the changes which is why I bent over
> backwards to be nice about it including submitting pull requests and
> communicating with you over email.
> 
> I even implemented the alternatives for Coin4 that you have on Coin2/3 just
> so they would be compatible instead of just conflicting with Coin2 (which
> is a leaf package in Fedora and Coin3 which will be a leaf package after
> moving the dependencies over).
> 
> I appreciate all the work you did maintaining the Coin3D stack over the
> years in Fedora but at the end of the day we are package maintainers not
> owners, a clarification that was referenced a few years ago.
> 
> Unfortunately I had to resort to posting here on the mailing list to
> provoke a response because 3 emails and almost a month later you couldn't
> even reply just to say "I'm really busy but I will review your changes."
> 
> So again I ask, what was I supposed to do? Ignore a REAL issue because you
> don't like people touching your packages? Wait indefinitely?
> 
> How long would you wait if you were in my position? What should I have done
> differently?
> 
> FreeCAD has been in a terrible state in Fedora for years and after a crap
> ton of work with getting PySIde2 into Fedora, updating the Coin stack I
> would like to be able to ship FUNCTIONAL packages.
> 
> Thanks,
> Richard

Richard I use FreeCAD in Fedora and I want to tahnk you for your work,
it is really appreciated, I think you did the right thing given the
circumstances.

If a maintainer wants to have a say, they have to do the work, or be
completely responsive at least, otherwise they need to let go and let
the ones that care do the work have their way.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



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

Re: Fedora 31 Final Go/No-Go meeting

On Wed, Oct 9, 2019 at 1:20 PM Ben Cotton  wrote:
>
> The Go/No-Go meeting for the Fedora 31 Beta release will be held on

I mean final, of course.


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

[Test-Announce] Re: Fedora 31 Final Go/No-Go meeting

On Wed, Oct 9, 2019 at 1:20 PM Ben Cotton  wrote:
>
> The Go/No-Go meeting for the Fedora 31 Beta release will be held on

I mean final, of course.


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

Fedora 31 Final Go/No-Go meeting

Dear all,

The Go/No-Go meeting for the Fedora 31 Beta release will be held on
Thursday, 2019-10-17 at 17:00 UTC in #fedora-meeting-1. For more
information, see: https://fedoraproject.org/wiki/Go_No_Go_Meeting

View the meeting on Fedocal at:
https://apps.fedoraproject.org/calendar/Fedora%20release/2019/10/17/#m9631

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

[Test-Announce] Fedora 31 Final Go/No-Go meeting

Dear all,

The Go/No-Go meeting for the Fedora 31 Beta release will be held on
Thursday, 2019-10-17 at 17:00 UTC in #fedora-meeting-1. For more
information, see: https://fedoraproject.org/wiki/Go_No_Go_Meeting

View the meeting on Fedocal at:
https://apps.fedoraproject.org/calendar/Fedora%20release/2019/10/17/#m9631

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

Fedora rawhide compose report: 20191009.n.0 changes

2019-10-09 Thread Fedora Rawhide Report

OLD: Fedora-Rawhide-20191007.n.0
NEW: Fedora-Rawhide-20191009.n.0

= SUMMARY =
Added images:0
Dropped images:  3
Added packages:  31
Dropped packages:42
Upgraded packages:   176
Downgraded packages: 2

Size of added packages:  56.16 MiB
Size of dropped packages:232.10 MiB
Size of upgraded packages:   3.03 GiB
Size of downgraded packages: 13.98 MiB

Size change of upgraded packages:   -29.81 MiB
Size change of downgraded packages: 71.46 KiB

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Security live x86_64
Path: Labs/x86_64/iso/Fedora-Security-Live-x86_64-Rawhide-20191007.n.0.iso
Image: LXQt raw-xz armhfp
Path: Spins/armhfp/images/Fedora-LXQt-armhfp-Rawhide-20191007.n.0-sda.raw.xz
Image: Workstation raw-xz aarch64
Path: 
Workstation/aarch64/images/Fedora-Workstation-Rawhide-20191007.n.0.aarch64.raw.xz

= ADDED PACKAGES =
Package: R-cyclocomp-1.1.0-1.fc32
Summary: Cyclomatic Complexity of R Code
RPMs:R-cyclocomp
Size:40.65 KiB

Package: R-xmlparsedata-1.0.3-1.fc32
Summary: Parse Data of 'R' Code as an 'XML' Tree
RPMs:R-xmlparsedata
Size:28.80 KiB

Package: cawbird-1.0.2-2.fc32
Summary: Fork of the Corebird GTK Twitter client that continues to work with 
Twitter
RPMs:cawbird
Size:2.57 MiB

Package: flamethrower-0.10-3.fc32
Summary: A DNS performance and functional testing utility
RPMs:flamethrower
Size:1.40 MiB

Package: golang-github-anaskhan96-soup-1.1.1-1.fc32
Summary: Web Scraper in Go, similar to BeautifulSoup
RPMs:golang-github-anaskhan96-soup-devel
Size:16.16 KiB

Package: golang-github-hajimehoshi-mp3-0.2.1-1.fc32
Summary: MP3 decoder in pure Go
RPMs:golang-github-hajimehoshi-mp3-devel
Size:10.63 MiB

Package: golang-github-hajimehoshi-oto-0.5.0-1.fc32
Summary: Low-level library to play sound on multiple platforms
RPMs:golang-github-hajimehoshi-oto-devel
Size:30.91 KiB

Package: golang-github-jroimartin-gocui-0.4.0-1.fc32
Summary: Minimalist Go package aimed at creating Console User Interfaces
RPMs:golang-github-jroimartin-gocui-devel
Size:37.89 KiB

Package: golang-github-lunixbochs-vtclean-1.0.0-1.fc32
Summary: Strips terminal escapes from text, can preserve color
RPMs:golang-github-lunixbochs-vtclean golang-github-lunixbochs-vtclean-devel
Size:3.48 MiB

Package: golang-github-mbndr-figlet4go-0-0.1.20191009gitd6cef5b.fc32
Summary: Port of figlet to golang
RPMs:golang-github-mbndr-figlet4go golang-github-mbndr-figlet4go-devel
Size:3.51 MiB

Package: golang-github-tomnomnom-xtermcolor-0.1.2-2.fc32
Summary: Command to convert color.Colour to the nearest xterm/bash/shell color
RPMs:golang-github-tomnomnom-xtermcolor 
golang-github-tomnomnom-xtermcolor-devel
Size:3.02 MiB

Package: jdeparser-2.0.3-1.fc32
Summary: Source generator library for Java
RPMs:jdeparser jdeparser-javadoc
Size:310.54 KiB

Package: libretro-desmume2015-0-0.1.20170817gitc27bb71.fc32
Summary: Port of Desmume to libretro
RPMs:libretro-desmume2015
Size:805.26 KiB

Package: libretro-gambatte-0-0.1.20190823git4d9ad7b.fc32
Summary: Libretro implementation of libgambatte
RPMs:libretro-gambatte
Size:693.19 KiB

Package: libretro-stella2014-0-0.1.20190921git6d74ad9.fc32
Summary: Port of Stella to libretro
RPMs:libretro-stella2014
Size:2.20 MiB

Package: mypaint2-brushes-2.0.1-1.fc32
Summary: Collections of brushes for MyPaint
RPMs:mypaint2-brushes mypaint2-brushes-devel
Size:2.64 MiB

Package: octave-iso2mesh-1.9.1-1.fc32
Summary: A 3D surface and volumetric mesh generator for MATLAB/Octave
RPMs:iso2mesh-demos octave-iso2mesh
Size:7.05 MiB

Package: octave-jnifti-0.5-1.fc32
Summary: Fast NIfTI-1/2 reader and NIfTI-to-JNIfTI converter for MATLAB/Octave
RPMs:jnifti-demos octave-jnifti
Size:10.10 MiB

Package: octave-mcxlab-0.9.5-1.fc32
Summary: MCXLAB - A GPU Monte Carlo 3-D photon transport simulator for 
MATLAB/Octave
RPMs:octave-mcxlab
Size:5.29 MiB

Package: octave-zmat-0.9-1.fc32
Summary: A portable data compression/decompression toolbox for MATLAB/Octave
RPMs:octave-zmat
Size:606.33 KiB

Package: perl-MusicBrainz-DiscID-0.06-1.fc32
Summary: Perl interface for the MusicBrainz libdiscid library
RPMs:perl-MusicBrainz-DiscID
Size:108.04 KiB

Package: perl-WebService-MusicBrainz-1.0.5-3.fc32
Summary: Perl interface to search the musicbrainz.org database
RPMs:perl-WebService-MusicBrainz
Size:18.53 KiB

Package: python-enthought-sphinx-theme-0.6.1-2.fc32
Summary: Sphinx theme for Enthought projects
RPMs:python3-enthought-sphinx-theme
Size:526.85 KiB

Package: python-spdx-2.5.0-1.fc32
Summary: SPDX license list database
RPMs:python3-spdx
Size:317.27 KiB

Package: python-spdx-lookup-0.3.2-1.fc32
Summary: SPDX license list query tool
RPMs:python3-spdx-lookup
Size:17.20 KiB

Package: python-upt-fedora-0.3-1.fc32
Summary: Fedora backend for upt
RPMs:python3-upt-fedora
Size:26.26 KiB

[Bug 1760037] New: perl-Role-Tiny-2.001003 is available

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

Bug ID: 1760037
   Summary: perl-Role-Tiny-2.001003 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Role-Tiny
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: dd...@cpan.org, emman...@seyman.fr, iarn...@gmail.com,
p...@city-fan.org, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 2.001003
Current version/release in rawhide: 2.001001-1.fc32
URL: http://search.cpan.org/dist/Role-Tiny/

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

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

Re: Modularity and the system-upgrade path

2019-10-09 Thread Matthew Miller

On Wed, Oct 09, 2019 at 06:39:07AM -0400, Neal Gompa wrote:
> It's being pushed so hard because it has been promoted as a top level
> objective, and because it's in RHEL now, no one can afford to let it
> fail. It *has* to succeed for RHEL, and for Fedora to remain a natural
> upstream for RHEL, it *must* succeed here too.

Yes; Modularity was created in response to the too-fast/too-slow issue we
see from opposite sides of the coin in both Fedora and RHEL -- and work on
it was funded by Red Hat. I'm happy to encourage work towards this problem
from basically any quarter, because I think it's a fundamental one we need
to solve in order to continue to be relevant not just as an upstream for
RHEL but in general.

> The problem is that the RHEL approach to modules only works because
> RHEL is centrally developed and can be correctly coordinated to
> overcome issues in the design. This is not true in Fedora, and there
> doesn't seem to be allowances for this difference.

This seems *partly* fair. It's in some ways a natural consequence of Red Hat
funding the work and having to fit into RHEL release schedules. But I think
we can also get attention and work towards Fedora's needs -- especially with
8 out the door and 9 just twinkle in product management's eye.

-- 
Matthew Miller

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

Re: Fedora 32 Self-Contained Change proposal: Replace Bazaar with Breezy


On 09. 10. 19 17:19, Miro Hrončok wrote:

On 09. 10. 19 16:08, Miro Hrončok wrote:

On 09. 10. 19 16:00, Neal Gompa wrote:

Could we get Breezy in Fedora 31 (not replacing Bazaar) so that people
can start using it? Aside from the Obsoletes and the symlinks, there's
no particular reason that we couldn't have it in F31, and conditioning
for below F32 would make things easier...


I think we could, if we double check for conflicts. For example the 
/usr/bin/git-remote-bzr file needs to be removed or renamed.


I'll start by backporting the dependencies.


I've also imported breezy with a bcond (off now) that replaces bzr.

https://src.fedoraproject.org/rpms/breezy/c/7f084c727721b09c3406aaa636a0d8b5c081452e?branch=master 


And https://bodhi.fedoraproject.org/updates/FEDORA-2019-7fb253a20a

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

Heads-up: openQA scheduling outage over last 2 days

2019-10-09 Thread Adam Williamson

Hey folks! Just to let folks know that the openQA job scheduling robot
(for the production instance) had a bad day and needed to go lie down
for a bit, so it didn't schedule any tests for any new composes or
critpath updates that appeared from about Oct 07 17:08:42 UTC until
about Oct 09 15:00:00 (about 20 minutes ago). Thanks to Christian
Heimes for alerting me to this. I just gave it a mug of tea and a
headache pill and some sympathetic conversation and it's back in top
form and scheduling tests again; it's scheduled all the things it
missed and the test system is catching up with the backlog, so results
will start appearing for updates and composes that were missed soon.
Sorry for any inconvenience.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 Self-Contained Change proposal: Replace Bazaar with Breezy


On 09. 10. 19 16:08, Miro Hrončok wrote:

On 09. 10. 19 16:00, Neal Gompa wrote:

Could we get Breezy in Fedora 31 (not replacing Bazaar) so that people
can start using it? Aside from the Obsoletes and the symlinks, there's
no particular reason that we couldn't have it in F31, and conditioning
for below F32 would make things easier...


I think we could, if we double check for conflicts. For example the 
/usr/bin/git-remote-bzr file needs to be removed or renamed.


I'll start by backporting the dependencies.


I've also imported breezy with a bcond (off now) that replaces bzr.

https://src.fedoraproject.org/rpms/breezy/c/7f084c727721b09c3406aaa636a0d8b5c081452e?branch=master

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

Reminder: DevConf.CZ CfP open through 1 November

You may have seen this posted in a few places, but the DevConf.CZ Call
for Proposals is open. As in years past, there is a dedicated Fedora
track in addition to tracks on Community, IoT, cloud/containers,
microservices, networking, desktop, and more. DevConf.CZ is 24–26
Jaunary 2020 in Brno, CZ.

Open TestCon's (30–31 March, 2020 in Beijing, CN) CfP is also open
through 31 October.

You can see more information about both conferences and links to
proposal submissions on the Community Blog post:
https://communityblog.fedoraproject.org/devconf-cz-and-open-testcon-cfps-open/

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

Reminder: DevConf.CZ CfP open through 1 November

You may have seen this posted in a few places, but the DevConf.CZ Call
for Proposals is open. As in years past, there is a dedicated Fedora
track in addition to tracks on Community, IoT, cloud/containers,
microservices, networking, desktop, and more. DevConf.CZ is 24–26
Jaunary 2020 in Brno, CZ.

Open TestCon's (30–31 March, 2020 in Beijing, CN) CfP is also open
through 31 October.

You can see more information about both conferences and links to
proposal submissions on the Community Blog post:
https://communityblog.fedoraproject.org/devconf-cz-and-open-testcon-cfps-open/

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

[Test-Announce] Reminder: Open TestCon CfP open through 31 October

You may have seen this posted in a few places, but the Open TestCon
CfP is open through 31 October. This conference is focused on testing
quality in open source projects. It will be held 30–31 March 2020 in
Beijing, CN.

Additionally, the DevConf.CZ (24–26 January in Brno, CZ) CfP is open
through 1 November. DevConf.CZ has tracks dedicated to Fedora and
Quality/Testing.

You can see more information about both conferences and links to
proposal submissions on the Community Blog post:
https://communityblog.fedoraproject.org/devconf-cz-and-open-testcon-cfps-open/

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

Re: Fedora 32 Self-Contained Change proposal: Replace Bazaar with Breezy


On 09. 10. 19 16:00, Neal Gompa wrote:

Could we get Breezy in Fedora 31 (not replacing Bazaar) so that people
can start using it? Aside from the Obsoletes and the symlinks, there's
no particular reason that we couldn't have it in F31, and conditioning
for below F32 would make things easier...


I think we could, if we double check for conflicts. For example the 
/usr/bin/git-remote-bzr file needs to be removed or renamed.


I'll start by backporting the dependencies.


Also, bzr failed to build in Fedora 31, last I checked... So does this
mean we simply don't have a Bazaar implementation for Fedora 31?


It failed to build but it is still there. We have an implementation that is not 
rebuildable and possibly insecure, as we cannot fix any CVE.


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

Re: Fedora 32 Self-Contained Change proposal: Replace Bazaar with Breezy

2019-10-09 Thread Neal Gompa

On Wed, Oct 9, 2019 at 9:15 AM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/ReplaceBazaarWithBreezy
>
> Note that this was originally discussed on the devel mailing list:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RQW6L265IIVHUIHNXPELEFMIBQX67DLC/#TBWSCGWFSGUFFYIBEAIOSPSP43WYQ7WI
>
> == Summary ==
> This change is about replacing the {{package|bzr}} package with
> {{package|breezy}}.
> [https://bazaar.canonical.com/en/ Bzr (Bazaar)] is a version control
> system, [https://www.breezy-vcs.org/ Breezy (brz)] is a fork of
> Bazaar. Breezy will obsolete and replace Bazaar in Fedora 32.
>
> == Owner ==
> * Name: [[User:churchyard| Miro Hrončok]]
> * Email: 
>
> * Name: [[User:dormouse| Marcel Plch]]
> * Email: 
>
>
> == Detailed Description ==
> The {{package|breezy}} package will be introduced. It provides and
> obsoletes bzr and git-remote-bzr, it
> contains /usr/bin/bzr (link to /usr/bin/brz)
> and /usr/bin/git-remote-bzr.
>
> Packages {{package|bzr}} and {{package|git-remote-bzr}} will be retired.
>
> The reasons for this include:
>
> * bzr is Python 2 only and [[Changes/RetirePython2|Python 2 is retired]]
> * bzr [https://bugzilla.redhat.com/show_bug.cgi?id=1734995 fails to
> build from source]
> * bzr [https://bugzilla.redhat.com/show_bug.cgi?id=1758870 fails to install]
> * bzr [https://pagure.io/fesco/issue/2227 has no maintainer]
>
> == Benefit to Fedora ==
> Users of Fedora will be able to use bazaar repositories via breezy. If
> we don't do this, bzr would be simply removed without a replacement.
>
> == Scope ==
> * '''Proposal owners:''' package {{package|breezy}} and it's
> dependencies (see [https://bugzilla.redhat.com/show_bug.cgi?id=1754964
> the package review])
>
> * '''Other developers:''' Test that your packages work with breezy
> ({{package|trac-bazaar-plugin}}, {{package|etckeeper}},
> {{package|ikiwiki}}, {{package|python-vcstools}},
> {{package|python-wstool}}, {{package|golang-github-masterminds-vcs}},
> {{package|python-pip}} are impacted). Adapt, drop the dependency or
> retire the packages.
>
> * Release engineering: no impact with Release Engineering is anticipated
> * Policies and guidelines: N/A
> * Trademark approval: N/A (not needed for this Change)
>
> == Upgrade/compatibility impact ==
> Eventually removed depndent packages need to be obsoleted.
>
> Breezy aims to be compatible with bazaar, but there might be some differences.
>
> == How To Test ==
> Test that installing bzr installs breezy, test that you can use it 
> successfully.
> Test that bzr gets replaced by breezy when upgrading to Fedora 32.
>
> == User Experience ==
> Users installing bzr will get breezy instead. The bzr
> command will be provided as a symbolic link to the brz
> (breezy) command. The basic API of that command should be the same.
>

Could we get Breezy in Fedora 31 (not replacing Bazaar) so that people
can start using it? Aside from the Obsoletes and the symlinks, there's
no particular reason that we couldn't have it in F31, and conditioning
for below F32 would make things easier...

Also, bzr failed to build in Fedora 31, last I checked... So does this
mean we simply don't have a Bazaar implementation for Fedora 31?


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

Fedora 32 Self-Contained Change proposal: Replace Bazaar with Breezy

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

Note that this was originally discussed on the devel mailing list:
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/RQW6L265IIVHUIHNXPELEFMIBQX67DLC/#TBWSCGWFSGUFFYIBEAIOSPSP43WYQ7WI

== Summary ==
This change is about replacing the {{package|bzr}} package with
{{package|breezy}}.
[https://bazaar.canonical.com/en/ Bzr (Bazaar)] is a version control
system, [https://www.breezy-vcs.org/ Breezy (brz)] is a fork of
Bazaar. Breezy will obsolete and replace Bazaar in Fedora 32.

== Owner ==
* Name: [[User:churchyard| Miro Hrončok]]
* Email: 

* Name: [[User:dormouse| Marcel Plch]]
* Email: 


== Detailed Description ==
The {{package|breezy}} package will be introduced. It provides and
obsoletes bzr and git-remote-bzr, it
contains /usr/bin/bzr (link to /usr/bin/brz)
and /usr/bin/git-remote-bzr.

Packages {{package|bzr}} and {{package|git-remote-bzr}} will be retired.

The reasons for this include:

* bzr is Python 2 only and [[Changes/RetirePython2|Python 2 is retired]]
* bzr [https://bugzilla.redhat.com/show_bug.cgi?id=1734995 fails to
build from source]
* bzr [https://bugzilla.redhat.com/show_bug.cgi?id=1758870 fails to install]
* bzr [https://pagure.io/fesco/issue/2227 has no maintainer]

== Benefit to Fedora ==
Users of Fedora will be able to use bazaar repositories via breezy. If
we don't do this, bzr would be simply removed without a replacement.

== Scope ==
* '''Proposal owners:''' package {{package|breezy}} and it's
dependencies (see [https://bugzilla.redhat.com/show_bug.cgi?id=1754964
the package review])

* '''Other developers:''' Test that your packages work with breezy
({{package|trac-bazaar-plugin}}, {{package|etckeeper}},
{{package|ikiwiki}}, {{package|python-vcstools}},
{{package|python-wstool}}, {{package|golang-github-masterminds-vcs}},
{{package|python-pip}} are impacted). Adapt, drop the dependency or
retire the packages.

* Release engineering: no impact with Release Engineering is anticipated
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
Eventually removed depndent packages need to be obsoleted.

Breezy aims to be compatible with bazaar, but there might be some differences.

== How To Test ==
Test that installing bzr installs breezy, test that you can use it successfully.
Test that bzr gets replaced by breezy when upgrading to Fedora 32.

== User Experience ==
Users installing bzr will get breezy instead. The bzr
command will be provided as a symbolic link to the brz
(breezy) command. The basic API of that command should be the same.

== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?) Proposal
owners will orphan both breezy and bzr (sorry, but not sorry).
* Contingency deadline: final freeze
* Blocks release? No
* Blocks product? No

== Documentation ==


# https://breezy-vcs.org/doc/en/

== Release Notes ==
TBD


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

Re: Intent to unretire libresample package, needs re-review

2019-10-09 Thread Jared K. Smith

On Wed, Oct 9, 2019 at 8:57 AM Richard Shaw  wrote:

> I can take it unless someone gets to it first. I'm in training today and
> then have to catch up everything else once I'm done so it may be a few days
> :)
>

Thanks... let me know if you'd like me to review one of your packages in
return.

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

Fedora 32 Self-Contained Change proposal: Replace Bazaar with Breezy

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

Note that this was originally discussed on the devel mailing list:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RQW6L265IIVHUIHNXPELEFMIBQX67DLC/#TBWSCGWFSGUFFYIBEAIOSPSP43WYQ7WI

== Summary ==
This change is about replacing the {{package|bzr}} package with
{{package|breezy}}.
[https://bazaar.canonical.com/en/ Bzr (Bazaar)] is a version control
system, [https://www.breezy-vcs.org/ Breezy (brz)] is a fork of
Bazaar. Breezy will obsolete and replace Bazaar in Fedora 32.

== Owner ==
* Name: [[User:churchyard| Miro Hrončok]]
* Email: 

* Name: [[User:dormouse| Marcel Plch]]
* Email: 


== Detailed Description ==
The {{package|breezy}} package will be introduced. It provides and
obsoletes bzr and git-remote-bzr, it
contains /usr/bin/bzr (link to /usr/bin/brz)
and /usr/bin/git-remote-bzr.

Packages {{package|bzr}} and {{package|git-remote-bzr}} will be retired.

The reasons for this include:

* bzr is Python 2 only and [[Changes/RetirePython2|Python 2 is retired]]
* bzr [https://bugzilla.redhat.com/show_bug.cgi?id=1734995 fails to
build from source]
* bzr [https://bugzilla.redhat.com/show_bug.cgi?id=1758870 fails to install]
* bzr [https://pagure.io/fesco/issue/2227 has no maintainer]

== Benefit to Fedora ==
Users of Fedora will be able to use bazaar repositories via breezy. If
we don't do this, bzr would be simply removed without a replacement.

== Scope ==
* '''Proposal owners:''' package {{package|breezy}} and it's
dependencies (see [https://bugzilla.redhat.com/show_bug.cgi?id=1754964
the package review])

* '''Other developers:''' Test that your packages work with breezy
({{package|trac-bazaar-plugin}}, {{package|etckeeper}},
{{package|ikiwiki}}, {{package|python-vcstools}},
{{package|python-wstool}}, {{package|golang-github-masterminds-vcs}},
{{package|python-pip}} are impacted). Adapt, drop the dependency or
retire the packages.

* Release engineering: no impact with Release Engineering is anticipated
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
Eventually removed depndent packages need to be obsoleted.

Breezy aims to be compatible with bazaar, but there might be some differences.

== How To Test ==
Test that installing bzr installs breezy, test that you can use it successfully.
Test that bzr gets replaced by breezy when upgrading to Fedora 32.

== User Experience ==
Users installing bzr will get breezy instead. The bzr
command will be provided as a symbolic link to the brz
(breezy) command. The basic API of that command should be the same.

== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?) Proposal
owners will orphan both breezy and bzr (sorry, but not sorry).
* Contingency deadline: final freeze
* Blocks release? No
* Blocks product? No

== Documentation ==


# https://breezy-vcs.org/doc/en/

== Release Notes ==
TBD


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

Re: Intent to unretire libresample package, needs re-review

2019-10-09 Thread Richard Shaw

On Wed, Oct 9, 2019 at 7:47 AM Jared K. Smith 
wrote:

> I intend to unretire the "libresample" package in Fedora, now that I have
> it building properly from source again.  It needs a re-review, which I've
> asked for at https://bugzilla.redhat.com/show_bug.cgi?id=1759928.
>

I can take it unless someone gets to it first. I'm in training today and
then have to catch up everything else once I'm done so it may be a few days
:)

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

Intent to unretire libresample package, needs re-review

2019-10-09 Thread Jared K. Smith

I intend to unretire the "libresample" package in Fedora, now that I have
it building properly from source again.  It needs a re-review, which I've
asked for at https://bugzilla.redhat.com/show_bug.cgi?id=1759928.

I will open a Rel-Eng ticket for unretirement once the package has been
re-reviewed.

--
Jared Smith
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: jnovy pushed to mc (master). "- just keep perl-interpreter BR because of man2hlp, (..more)"

2019-10-09 Thread Jindrich Novy

Hi all,

decided to disable aspell support in mc as a whole. Note it is disabled by
default configure option in mc anyway. A beneficial side effect is we have
now even smaller dependency footprint and the annoying message while
editing *any* file goes away without aspell + friends installed.

This whole feature just opens can of worms on so many levels.

Jindrich

On Wed, Oct 9, 2019 at 2:01 PM Nikola Forró  wrote:

> On Tue, 2019-10-08 at 18:42 +0100, Tomasz Kłoczko wrote:
> > IMO above shows clearly that adding "aspell-en" in mc or aspell
> > dependencies does not solve issue .. at all.
> > Kind of mitigation of that problem should be IMO change aspell error
> > message (by add Fedora/any rpm based distro patch) informing that
> > system has missing aspell- package.
>
> This sounds reasonable, making a maintainable downstream patch could be
> tricky though. I'll try to come up with something.
>
> Thanks,
> Nikola
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 7 is broken for python3 related builds


On 09. 10. 19 13:47, Nico Kadel-Garcia wrote:

  It's going to be a while before EPEL gets all of the "python36"
labeled packages rebuilt to say "Provides: python3-module" as well as
"Provides: python36-module" for complete consistency with the altered
name used by RHEL. The epel-rpm-macros package sets the python modules
to set "python3_pkgversion" to be "36" instead of plain "3", and helps
find and resolve the python dependencies from the slightly older EPEL
versions. It also helps distinguish new built modules as being EPEL
based instead of merely RHEL or CentOS based.


How does epel-rpm-macros package sets the python modules to do that?
What kind of sorcery is there? AFAIk it is the %python_provide macro defined in 
python-rpm-macors (required by python3-devel).



I'm not happy that RHEL upstream selected to use "python3" instead of
"python36" as the package name for their release of Python 3.6. Like
modularity, it's solving one problem but generating others.


All RHEL python3 packages also provide their python36 names. Where is the 
problem? If there is some, how can we fix it?


--
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: jnovy pushed to mc (master). "- just keep perl-interpreter BR because of man2hlp, (..more)"

2019-10-09 Thread Nikola Forró

On Tue, 2019-10-08 at 18:42 +0100, Tomasz Kłoczko wrote:
> IMO above shows clearly that adding "aspell-en" in mc or aspell
> dependencies does not solve issue .. at all.
> Kind of mitigation of that problem should be IMO change aspell error
> message (by add Fedora/any rpm based distro patch) informing that
> system has missing aspell- package.

This sounds reasonable, making a maintainable downstream patch could be
tricky though. I'll try to come up with something.

Thanks,
Nikola
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Review swap (htslib)

2019-10-09 Thread Zbigniew Jędrzejewski-Szmek

On Tue, Oct 08, 2019 at 06:03:26PM +0200, Jun Aruga wrote:
> Someone, could give us advice about below situation, if the new
> package htslib's "/usr/lib64/libhts.so.1.9" is valid?
> "1.9" is upstream software's version. "2" is ABI's version (so version).

The patterns used in filenames of so objects aren't really well defined.
In particular, the numbers typically used like libfoo.so.MAJOR.MINOR.PATCH
are only informative.

The libhts convention is: libhts.so.SO_VERSION → libhts.so.PROJECT_VERSION.
Upstream correctly says that there's no chance of conflict because 
PROJECT_VERSION
always includes a dot and SO_VERSION doesn't. The compiler doesn't care.

I'd say that this is a bit misleading, but not wrong. Not worth deviating
from upstream.

FTR:
In [34]: d = os.scandir('/usr/lib64') 
...: for e in d: 
...: if e.is_symlink() and '.so.' in e.name and not 
e.name.startswith('.'): 
...:  t = os.readlink(e.path) 
...:  if e.name not in t and '.so.' in t: 
...:  print(e.name, t) 
...:

libgcalc-1.so.0.0.0 libgcalc-1.so.0
libosgFX.so.131 libosgFX.so.3.4.1
libcrypto.so.10 libcrypto.so.1.0.2o
libzzip-0.so.12 libzzip-0.so.13
libosgManipulator.so.131 libosgManipulator.so.3.4.1
libosgUtil.so.131 libosgUtil.so.3.4.1
libXaw.so.7 libXaw7.so.7
libexiv2.so.27 libexiv2.so.0.27.2
libOpenThreads.so.20 libOpenThreads.so.3.3.0
libosgWidget.so.131 libosgWidget.so.3.4.1
libosgParticle.so.131 libosgParticle.so.3.4.1
libgcr-3.so.1 libgcr-ui-3.so.1.0.0
libosgText.so.131 libosgText.so.3.4.1
libzzipfseeko-0.so.12 libzzipfseeko-0.so.13
libclucene-contribs-lib.so.1 libclucene-contribs-lib.so.2.3.3.4
libjsoncpp.so.21 libjsoncpp.so.1.9.1
libgit2.so.28 libgit2.so.0.28.3
libkbookmarkmodel_private.so.6 libkbookmarkmodel_private.so.5.97.0
libosgVolume.so.131 libosgVolume.so.3.4.1
libssl.so.10 libssl.so.1.0.2o
libosgViewer.so.131 libosgViewer.so.3.4.1
libmono-2.0.so.1.0.0 libmonosgen-2.0.so.1.0.0
libosgDB.so.131 libosgDB.so.3.4.1
libzzipmmapped-0.so.10 libzzipmmapped-0.so.13
libssh_threads.so.4.8.1 libssh.so.4.8.1
libzzip-0.so.11 libzzip-0.so.13
libzzipmmapped-0.so.11 libzzipmmapped-0.so.13
libosgSim.so.131 libosgSim.so.3.4.1
libosgTerrain.so.131 libosgTerrain.so.3.4.1
libv8_libbase.so.7 /usr/lib64/libnode.so.72
libKF5KExiv2.so.15.0.0 libKF5KExiv2.so.5.0.0
libzzip-0.so.10 libzzip-0.so.13
libminizip.so.2.5 libminizip.so.2.8.9
libosgAnimation.so.131 libosgAnimation.so.3.4.1
libGLX_system.so.0 /usr/lib64/libGLX_mesa.so.0
libutempter.so.0 libutempter.so.1.1.6
libzzipfseeko-0.so.10 libzzipfseeko-0.so.13
libv8.so.7 /usr/lib64/libnode.so.72
libclucene-shared.so.1 libclucene-shared.so.2.3.3.4
libv8_libplatform.so.7 /usr/lib64/libnode.so.72
libzzipfseeko-0.so.11 libzzipfseeko-0.so.13
libgcc_s.so.1 libgcc_s-9-20190827.so.1
libclucene-core.so.1 libclucene-core.so.2.3.3.4
libosgShadow.so.131 libosgShadow.so.3.4.1
libopencc.so.2 libopencc.so.1.0.0
libssh_threads.so.4 libssh.so.4.8.1
libosgUI.so.131 libosgUI.so.3.4.1
libclutter-glx-1.0.so.0 libclutter-1.0.so.0.2600.2
libosgPresentation.so.131 libosgPresentation.so.3.4.1
libosgGA.so.131 libosgGA.so.3.4.1
libosg.so.131 libosg.so.3.4.1
libfbclient.so.2 libfbclient.so.3.0.4
libmono-2.0.so.1 libmonosgen-2.0.so.1
libgit2.so.27 libgit2.so.0.27.8
libzzipmmapped-0.so.12 libzzipmmapped-0.so.13
libgcr-3.so.1.0.0 libgcr-ui-3.so.1.0.0
libopenjp2.so.7 libopenjp2.so.2.3.1

... so yeah, this happens quite a bit.

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

Re: EPEL 7 is broken for python3 related builds

2019-10-09 Thread Nico Kadel-Garcia

On Wed, Oct 9, 2019 at 5:33 AM Miro Hrončok  wrote:
>
> On 09. 10. 19 4:34, Nico Kadel-Garcia wrote:
> > On Tue, Oct 8, 2019 at 1:56 PM Irina Boverman  wrote:
> >>
> >> Using "BuildRequires:  python%{python3_pkgversion}-devel" results in this 
> >> error:
> >>
> >> fedpkg scratch-build
> >> DEBUG util.py:593:  No matching package to install: 'python36-devel'
> >
> > A lot of Fedora .spec files use "python3-devel" and various "pyton3-"
> > modules. If you switch this to "python%{python3_pkgversion}-", *AND*
> > if you add "BuildRequires: epel-rpm-mocros" for rhel based
> > environments, it works much better to play nicely with the new RHEL
> > and the existing EPEL packages.
>
> Why do you need to add "BuildRequires: epel-rpm-mocros"?

 It's going to be a while before EPEL gets all of the "python36"
labeled packages rebuilt to say "Provides: python3-module" as well as
"Provides: python36-module" for complete consistency with the altered
name used by RHEL. The epel-rpm-macros package sets the python modules
to set "python3_pkgversion" to be "36" instead of plain "3", and helps
find and resolve the python dependencies from the slightly older EPEL
versions. It also helps distinguish new built modules as being EPEL
based instead of merely RHEL or CentOS based.

I'm not happy that RHEL upstream selected to use "python3" instead of
"python36" as the package name for their release of Python 3.6. Like
modularity, it's solving one problem but generating others.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Has fedpkg + dist-git replaced rpmbuild for building new/local packages?

2019-10-09 Thread Ankur Sinha

On Wed, Oct 09, 2019 11:52:28 +0300, Panu Matilainen wrote:
> On 10/8/19 3:26 PM, Ankur Sinha wrote:
> > On Tue, Oct 08, 2019 13:03:48 +0300, Panu Matilainen wrote:
> > > 
> > > 
> > > Look, I'm no more in love with the traditional layout than anybody, I'm 
> > > just
> > > saying changing the default is not as simple as you'd like to think. 
> > > Anybody
> > > wanting to work on changing the default is welcome to propose it upstream,
> > > patches welcome and all.
> > 
> > Would keeping this Fedora specific to begin with help slowly migrate
> > people over? What if we announce this via the change process for F32?
> > The change will be to modify `/usr/lib/rpm/macros` to use per-directory
> > locations as you'd suggested in the snippet since it is closer to the
> > dist-git workflow that is now in use. People can still easily revert to
> > rpmbuild/*, and the contingency plan will be to just not make the
> > change. I don't know how this would affect rpmdev-buildtree and how to
> > handle that (remove it?).
> > 
> 
> Changing rpm defaults will break existing setups, people will be unhappy and
> I'll get the blame regardless of who actually did it.
> 
> I'd rather suggest changing rpmdev-setuptree to configure things that way,
> it already modifies ~/.rpmmacros in various ways, some totally redundant
> (like setting %_topdir to a longtime rpm default).
> That starts nudging people towards that direction, but leaves existing
> setups alone.

Sure. That sounds good. I'll see what I can come up with an open PRs
etc.

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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

Re: Modularity and the system-upgrade path

2019-10-09 Thread Neal Gompa

On Wed, Oct 9, 2019 at 6:32 AM Fabio Valentini  wrote:
>
> On Wed, Oct 9, 2019, 12:29 Miro Hrončok  wrote:
>>
>> On 04. 10. 19 21:31, Miro Hrončok wrote:
>> > On 04. 10. 19 16:57, Stephen Gallagher wrote:
>> >> Right now, there are two conflicting requirements in Fedora Modularity
>> >> that we need to resolve.
>> >>
>> >> 1. Once a user has selected a stream, updates should follow that
>> >> stream and not introduce incompatiblities. Selected streams should not
>> >> be changed without direct action from the user.
>> >> 2. So far as possible, Modularity should be invisible to those who
>> >> don't specifically need it. This means being able to set default
>> >> streams so that `yum install package` works for module-provided
>> >> content.
>> >>
>> >> Where this becomes an issue is at system-upgrade time (moving from
>> >> Fedora 30->31 or continuously tracking Rawhide). Because of
>> >> requirement 1, we cannot automatically move users between streams, but
>> >> in the case of release upgrades we often want to move to a new default
>> >> for the distribution.
>> >
>> >
>> > Wouldn't it be easier if the "default stream" would just behave like a 
>> > regular
>> > package?
>> >
>> > I can think of two solutions of that:
>> >
>> > 1. (drastic for modular maintainers)
>> >
>> > We keep miantaining the default versions of things as ursine packages. We 
>> > only
>> > modularize alternate versions.
>> >
>> > Pros: Users who don't want alternate versions won't be affected by 
>> > imperfections
>> > of our modular design. No Ursa Major/Prime needed in the buildroot.
>> >
>> > Cons: Modular maintainers who do modules with just one stream because it is
>> > easier for them would need to rollback to what's easier for everybody else 
>> > but
>> > them. Modular maintainers who do multiple modular streams would need to 
>> > maintain
>> > both the alternate streams and ursine packages.
>> >
>> >
>> > 2. (potentially dangerous consequences?)
>> >
>> > We put the default modular stream into our regular repos, similarly to 
>> > what we
>> > try to do in the buildroot. "dnf install Foo" would install the Foo 
>> > package and
>> > would not enbale any streams or modules. The modular maintainers would keep
>> > maintaining the modules as now, the infrastructure would compose the 
>> > defaults
>> > into the regular repo (or an additional but default-enabled one).
>> >
>> > Pros: Maintainers would keep doing what they desire.
>> >
>> > Cons: We would need to make this technically possible and figure out all 
>> > the
>> > corner cases (however AFAIK this needs to be done for the "modules in 
>> > buildroot"
>> > thing as well).
>> >
>> > WDYT?
>>
>> So despite providing zero feedback here, this was voted at the modularity 
>> meeting:
>>
>> * Tagging Module Defaults into non-modular repo  (sgallagh, 15:41:37)
>>* AGREED: We disagree with merging default streams into the main repo
>>  as non-modular packages. Our approach is to implement a mechanism of
>>  following default streams to give people the experience they want.
>>  (+4 0 -0)  (asamalik, 16:07:40)
>>
>> https://meetbot.fedoraproject.org/fedora-meeting-3/2019-10-08/modularity.2019-10-08-15.08.html
>>
>> I disagree strongly with the reasons provided in the logs, but clearly, we
>> should aim for solution 1. if solution 2. is not negotiable by the 
>> modularity WG.
>
>
> Why am I not getting rid of the feeling that Modularity is getting shoved 
> down our throats no matter the objections we raise?
>

It's being pushed so hard because it has been promoted as a top level
objective, and because it's in RHEL now, no one can afford to let it
fail. It *has* to succeed for RHEL, and for Fedora to remain a natural
upstream for RHEL, it *must* succeed here too.

The problem is that the RHEL approach to modules only works because
RHEL is centrally developed and can be correctly coordinated to
overcome issues in the design. This is not true in Fedora, and there
doesn't seem to be allowances for this difference.


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

Re: Modularity and the system-upgrade path

2019-10-09 Thread Fabio Valentini

On Wed, Oct 9, 2019, 12:29 Miro Hrončok  wrote:

> On 04. 10. 19 21:31, Miro Hrončok wrote:
> > On 04. 10. 19 16:57, Stephen Gallagher wrote:
> >> Right now, there are two conflicting requirements in Fedora Modularity
> >> that we need to resolve.
> >>
> >> 1. Once a user has selected a stream, updates should follow that
> >> stream and not introduce incompatiblities. Selected streams should not
> >> be changed without direct action from the user.
> >> 2. So far as possible, Modularity should be invisible to those who
> >> don't specifically need it. This means being able to set default
> >> streams so that `yum install package` works for module-provided
> >> content.
> >>
> >> Where this becomes an issue is at system-upgrade time (moving from
> >> Fedora 30->31 or continuously tracking Rawhide). Because of
> >> requirement 1, we cannot automatically move users between streams, but
> >> in the case of release upgrades we often want to move to a new default
> >> for the distribution.
> >
> >
> > Wouldn't it be easier if the "default stream" would just behave like a
> regular
> > package?
> >
> > I can think of two solutions of that:
> >
> > 1. (drastic for modular maintainers)
> >
> > We keep miantaining the default versions of things as ursine packages.
> We only
> > modularize alternate versions.
> >
> > Pros: Users who don't want alternate versions won't be affected by
> imperfections
> > of our modular design. No Ursa Major/Prime needed in the buildroot.
> >
> > Cons: Modular maintainers who do modules with just one stream because it
> is
> > easier for them would need to rollback to what's easier for everybody
> else but
> > them. Modular maintainers who do multiple modular streams would need to
> maintain
> > both the alternate streams and ursine packages.
> >
> >
> > 2. (potentially dangerous consequences?)
> >
> > We put the default modular stream into our regular repos, similarly to
> what we
> > try to do in the buildroot. "dnf install Foo" would install the Foo
> package and
> > would not enbale any streams or modules. The modular maintainers would
> keep
> > maintaining the modules as now, the infrastructure would compose the
> defaults
> > into the regular repo (or an additional but default-enabled one).
> >
> > Pros: Maintainers would keep doing what they desire.
> >
> > Cons: We would need to make this technically possible and figure out all
> the
> > corner cases (however AFAIK this needs to be done for the "modules in
> buildroot"
> > thing as well).
> >
> > WDYT?
>
> So despite providing zero feedback here, this was voted at the modularity
> meeting:
>
> * Tagging Module Defaults into non-modular repo  (sgallagh, 15:41:37)
>* AGREED: We disagree with merging default streams into the main repo
>  as non-modular packages. Our approach is to implement a mechanism of
>  following default streams to give people the experience they want.
>  (+4 0 -0)  (asamalik, 16:07:40)
>
>
> https://meetbot.fedoraproject.org/fedora-meeting-3/2019-10-08/modularity.2019-10-08-15.08.html
>
> I disagree strongly with the reasons provided in the logs, but clearly, we
> should aim for solution 1. if solution 2. is not negotiable by the
> modularity WG.
>

Why am I not getting rid of the feeling that Modularity is getting shoved
down our throats no matter the objections we raise?


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

Re: Modularity and the system-upgrade path

On 04. 10. 19 21:31, Miro Hrončok wrote:

On 04. 10. 19 16:57, Stephen Gallagher wrote:

Right now, there are two conflicting requirements in Fedora Modularity
that we need to resolve.

1. Once a user has selected a stream, updates should follow that
stream and not introduce incompatiblities. Selected streams should not
be changed without direct action from the user.
2. So far as possible, Modularity should be invisible to those who
don't specifically need it. This means being able to set default
streams so that `yum install package` works for module-provided
content.

Where this becomes an issue is at system-upgrade time (moving from
Fedora 30->31 or continuously tracking Rawhide). Because of
requirement 1, we cannot automatically move users between streams, but
in the case of release upgrades we often want to move to a new default
for the distribution.

Wouldn't it be easier if the "default stream" would just behave like a regular
package?

I can think of two solutions of that:

1. (drastic for modular maintainers)

We keep miantaining the default versions of things as ursine packages. We only
modularize alternate versions.

Pros: Users who don't want alternate versions won't be affected by imperfections
of our modular design. No Ursa Major/Prime needed in the buildroot.

Cons: Modular maintainers who do modules with just one stream because it is
easier for them would need to rollback to what's easier for everybody else but
them. Modular maintainers who do multiple modular streams would need to maintain
both the alternate streams and ursine packages.

2. (potentially dangerous consequences?)

We put the default modular stream into our regular repos, similarly to what we
try to do in the buildroot. "dnf install Foo" would install the Foo package and
would not enbale any streams or modules. The modular maintainers would keep
maintaining the modules as now, the infrastructure would compose the defaults
into the regular repo (or an additional but default-enabled one).

Pros: Maintainers would keep doing what they desire.

Cons: We would need to make this technically possible and figure out all the
corner cases (however AFAIK this needs to be done for the "modules in buildroot"
thing as well).

WDYT?

So despite providing zero feedback here, this was voted at the modularity
meeting:

* Tagging Module Defaults into non-modular repo (sgallagh, 15:41:37)
* AGREED: We disagree with merging default streams into the main repo
as non-modular packages. Our approach is to implement a mechanism of
following default streams to give people the experience they want.
(+4 0 -0) (asamalik, 16:07:40)

https://meetbot.fedoraproject.org/fedora-meeting-3/2019-10-08/modularity.2019-10-08-15.08.html

I disagree strongly with the reasons provided in the logs, but clearly, we
should aim for solution 1. if solution 2. is not negotiable by the modularity WG.

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

Re: [modularity] modularity team meeting minutes (Oct. 08, 2019)

2019-10-09 Thread Fabio Valentini

On Tue, Oct 8, 2019, 23:18 Langdon White  wrote:

> Minutes:
> https://meetbot.fedoraproject.org/fedora-meeting-3/2019-10-08/modularity.2019-10-08-15.08.html
> Minutes (text):
> https://meetbot.fedoraproject.org/fedora-meeting-3/2019-10-08/modularity.2019-10-08-15.08.txt
> Log:
> https://meetbot.fedoraproject.org/fedora-meeting-3/2019-10-08/modularity.2019-10-08-15.08.log.html
>
> ==
> #fedora-meeting-3: Modularity Team Meeting
> ==
>
> Meeting started by langdon at 15:08:18 UTC. The full logs are available
> at
>
> https://meetbot.fedoraproject.org/fedora-meeting-3/2019-10-08/modularity.2019-10-08-15.08.log.html
>
> Meeting summary
>
> ---
> * roll call  (langdon, 15:08:37)
>
> * agenda  (langdon, 15:10:08)
>   * update on ursa prime  (langdon, 15:10:16)
>   * update on libmodulemd  (langdon, 15:11:23)
>
> * update on ursa prime  (langdon, 15:12:33)
>   * Ursa Prime will be deployed to production next Tuesday  (sgallagh,
> 15:21:41)
>   * Ursa Prime configuration will initially be limited to Rawhide/F32
> and EPEL8[-playground] buildroots  (sgallagh, 15:22:08)
>   * The remaining tasks to be done for Ursa Prime: 1) modify the
> f32/rawhide platform.yaml record in MBS to enable this feature, 2)
> set up a repo compose based on the defaults+overrides inputs, 3)
> configure koji tags and targets so that the rawhide target is a
> merged repo containing the modular and non-modular content  (contyk,
> 15:24:19)
>   * ACTION: contyk and sgallagh to work with nirik to finish those three
> tasks.  (sgallagh, 15:25:53)
>   * LINK:
>
> https://www.dictionary.com/browse/six-of-one--half-a-dozen-of-the-other
> (langdon, 15:29:24)
>

What are the consequences of this for packages that are maintained

- as both normal and modular packages,
- as modules only?

In particular, which "incarnation" of the package will land in the repos if
it's available from both sources? If it's just the highest version, this
will inevitably lead to conflicts and broken dependencies for dependent
packages.

Fabio


> * libmodulemd update  (langdon, 15:29:33)
>   * LINK: https://github.com/fedora-modularity/libmodulemd/issues/368
> (sgallagh, 15:31:20)
>   * ACTION: sgallagh to investigate libmodulemd 2.x migration for COPR
> (sgallagh, 15:39:10)
>   * slow migration away from libmodulemd 1.x is resulting in increasing
> maintenance burden  (sgallagh, 15:39:51)
>
> * Tagging Module Defaults into non-modular repo  (sgallagh, 15:41:37)
>   * AGREED: We disagree with merging default streams into the main repo
> as non-modular packages. Our approach is to implement a mechanism of
> following default streams to give people the experience they want.
> (+4 0 -0)  (asamalik, 16:07:40)
>
> Meeting ended at 16:11:58 UTC.
>
> Action Items
> 
> * contyk and sgallagh to work with nirik to finish those three tasks.
> * sgallagh to investigate libmodulemd 2.x migration for COPR
>
> Action Items, by person
> ---
> * contyk
>   * contyk and sgallagh to work with nirik to finish those three tasks.
> * sgallagh
>   * contyk and sgallagh to work with nirik to finish those three tasks.
>   * sgallagh to investigate libmodulemd 2.x migration for COPR
> * **UNASSIGNED**
>   * (none)
>
> People Present (lines said)
> ---
> * sgallagh (87)
> * langdon (77)
> * asamalik (53)
> * contyk (42)
> * zodbot (13)
>
> Generated by `MeetBot`_ 0.1.4
>
> .. _`MeetBot`: http://wiki.debian.org/MeetBot
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [modularity] modularity team meeting minutes (Oct. 08, 2019)

2019-10-09 Thread Neal Gompa

On Wed, Oct 9, 2019 at 6:08 AM Jun Aruga  wrote:
>
> > * Tagging Module Defaults into non-modular repo  (sgallagh, 15:41:37)
> >   * AGREED: We disagree with merging default streams into the main repo
> > as non-modular packages. Our approach is to implement a mechanism of
> > following default streams to give people the experience they want.
> > (+4 0 -0)  (asamalik, 16:07:40)
>
> What is the consequence of this for module maintainers?
> Each module maintainer regularly does not have to update
> "fedora-module-defaults" repository's .yaml file any more?
> https://pagure.io/releng/fedora-module-defaults
>

The consequence is that we'll remain dependent on modulemd for
defaults. That means we *still* need to care about
fedora-module-defaults.


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

Re: [modularity] modularity team meeting minutes (Oct. 08, 2019)

2019-10-09 Thread Jun Aruga

> * Tagging Module Defaults into non-modular repo  (sgallagh, 15:41:37)
>   * AGREED: We disagree with merging default streams into the main repo
> as non-modular packages. Our approach is to implement a mechanism of
> following default streams to give people the experience they want.
> (+4 0 -0)  (asamalik, 16:07:40)

What is the consequence of this for module maintainers?
Each module maintainer regularly does not have to update
"fedora-module-defaults" repository's .yaml file any more?
https://pagure.io/releng/fedora-module-defaults

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

[389-devel] Re: Future of nunc-stans

2019-10-09 Thread Ludwig Krispenz


Hi William,

I like your radical approach :-)

In my opinion our connection code is getting to complicated by 
maintaining two different implementations in parallel -  not separated, 
but intermangled (and even more complicated by turbo mode). So I agree 
we should have only one, but which one ? In my opinion nunc stans is the 
theoretically better approach, but nobody is confident enough to rely on 
nunc stans alone. The conntable mode has its problems (especially if 
handling many concurrent connections, and worse if they are established 
almost at the same time)(otherwise we would not have experimented with 
nunc stans), but is stable and for most of the use cases efficient enough.


So reducing the complexity by removing nunc stans (and maybe also turbo 
mode) and then do cleanup and try to improve the bottlenecks would be an 
acceptable approach to me.


In my opinion the core of the problem of the "old" connection code is 
that the main thread is handling new connections and already established 
connections and so does iterate over the connection table. Using an 
event model looks like the best way to handle this, but if it doesn't 
work we need to look for other improvements without breaking things.
Your suggestion to make the conn table data structure more lean and 
flexible is one option. In sun ds, when I didn't know about event queues 
I did split the main thread, one handling new connections and multiple 
to handle established connections (parts of teh conn table) - reusing 
the existing mechanisms, just splitting the load. Maybe we can also 
think in this direction.


Regards,
Ludwig

On 10/09/2019 01:32 AM, William Brown wrote:



On 9 Oct 2019, at 09:18, Rich Megginson  wrote:

On 10/8/19 4:55 PM, William Brown wrote:

Hi everyone,
In our previous catch up (about 4/5 weeks ago when I was visiting Matus/Simon), 
we talked about nunc-stans and getting it at least cleaned up and into the code 
base.
I've been looking at it again, and really thinking about it and reflecting on 
it and I have a lot of questions and ideas now.
The main question is *why* do we want it merged?
Is it performance? Recently I provided a patch that yielded an approximate ~30% 
speed up in the entire server through put just by changing our existing 
connection code.
Is it features? What features are we wanting from this? We have no complaints 
about our current threading model and thread allocations.
Is it maximum number of connections? We can always change the conntable to a 
better datastructure that would help scale this number higher (which would also 
yield a performance gain).

It is mostly about the c10k problem, trying to figure out a way to use epoll, 
via an event framework like libevent, libev, or libtevent, but in a 
multi-threaded way (at the time none of those were really thread safe, or 
suitable for use in the way we do multi-threading in 389).

It wasn't about performance, although I hoped that using lock-free data structures might 
solve some of the performance issues around thread contention, and perhaps using a 
"proper" event framework might give us some performance boost e.g. the idle 
thread processing using libevent timeouts.  I think that using poll() is never going to 
scale as well as epoll() in some cases e.g. lots of concurrent connections, no matter 
what sort of datastructure you use for the conntable.

The conntable was bottlenecking because when you had:

| conn | conn | freeslot | 

it would attempt to lock each conn to see if it was free or not. This meant if 
a conn was in an io, we would block waiting for it to finish before we could 
move to the next conn to check if it was free. After changing to pthread, we 
can now do trylock, where if trylock fails it can be implied the conn slot must 
be in use, so skip it. This is how we got the 30% speed up recently (my laptop 
went from about 4200 conn/sec to over 6000).

However the conntable exists to allow the conn struct to be re-used over and 
over. There are multiple ways we could solve this. On conn free, we could 
append to a freelist to prevent iterating over the list to find a slot. We 
could use a btreemap and just alloc/dealloc conns as needed to prevent the need 
to walk and find conns (this would help sanitizers with memory too). We could 
bring in libevent directly to the main server and have it replace poll too.

And even from then, I think we should be using flamegraphs to work out where 
our time limits are too.


As far as features goes - it would be nice to give plugins the ability to 
inject event requests, get timeout events, using the same framework as the main 
server engine.


The more I have looked at the code, I guess with time and experience, the more 
hesitant I am to actually commit to merging it. It was designed by people who 
did not understand low-level concurrency issues and memory architectures of 
systems,

I resemble that remark.  I suppose you could "turn off" the lock-free code and 
use mutexes.

[EPEL-devel] Re: python3-rpm-macros


On 09. 10. 19 3:32, Orion Poplawski wrote:

I retired this:

https://bodhi.fedoraproject.org/overrides/python-rpm-macros-3-31.el7

To allow epel 7 builds get the RHEL7.7 3-32.el7 version.


Thanks. I thought that when retiring the package, the override gets 
automatically expired.


--
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: EPEL 7 is broken for python3 related builds