[Bug 1805029] perl-IRI-0.011 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|ppi...@redhat.com   |
   Doc Type|--- |If docs needed, set a value



-- 
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: Self Introduction: Chihurumnaya Ibiam

[Benson Muite]

On Thu, Feb 20, 2020, at 2:20 AM, Chihurumnaya Ibiam wrote:
> Good day, 
> 
> I've been working mostly with python at Sugar Labs for some time now, I'm yet 
> to file a review request but I'm currently helping co-maintain the sugar* 
> packages;
> I'm from Nigeria.
> 
> I'm glad to be part of the fedora project maintainers community.
> -- 
> Ibiam Chihurumnaya 
> ibiamchihurumn...@gmail.com

Welcome to Fedora.

> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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: Self Introduction: Leonardo Rossetti

[Dominik 'Rathann' Mierzejewski]

Hello, Leo.

On Tuesday, 18 February 2020 at 19:06, Leonardo Rossetti wrote:
> Hello everyone,
> 
> My name Leonardo (commonly called Leo), I am a software engineer from São
> Paulo, Brazil.
> 
> I've recently joined the community platform engineering team in Red Hat and
> I wanted to go through the process of creating, building and shipping an
> RPM package so I decided to create one for the operator-sdk tooling as a
> start.
> 
> I've just opened a ticket for my first rpm package:
> https://bugzilla.redhat.com/show_bug.cgi?id=1804346

Ooh, operator-sdk! Good to see this one packaged in Fedora. I've added
myself to Cc and put in a comment, too.

> I am very excited to start contributing to my favorite linux distro!

That's great, welcome on board!

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

Re: Outage: Migration of Copr servers - 2020-02-23 06:00 UTC

[Pavel Raiskup]

Also note that since the next Monday we will have to shut-down all our
ppc64le builders in Fedora Copr.  Fedra infrastructure is going to move
them to (some) new datacenter - assemple, and make them available for copr
builds again.  But we don't yet have ETA.

We will disable the ppc64le chroots ourselves, so you shouldn't observe
any expected CI build failures and so on (the builds won't even start),
but if you need to have something done in ppc64le please do it now.  The
build results will stay available during the movement.

Pavel

On Wednesday, February 19, 2020 2:13:53 PM CET Jakub Kadlcik wrote:
> There will be an outage starting at 2020-02-23 06:00 UTC, which will last
> approximately 7 hours (but can take more if something goes wrong).
> 
> To convert UTC to your local time, take a look at
> https://fedoraproject.org/wiki/UTCHowto
> or run:
> 
> date -d '2020-02-23 06:00 UTC'
> 
> Reason for outage:
> 
> Moving Copr servers from OpenStack to Amazon AWS because OpenStack is
> going to be shut down soon.
> 
> Affected Services:
> 
> copr-frontend - https://copr.fedorainfracloud.org
> copr-backend - https://copr-be.cloud.fedoraproject.org/
> copr-distgit
> copr-keygen
> 
> Backend repositories should remain available during the outage.
> 
> Ticket Link:
> 
> https://pagure.io/fedora-infrastructure/issue/8668
> 
> Contact Information:
> 
> Please join #fedora-admin in irc.freenode.net or add comments to the
> ticket for this outage above.
> 
> 
> Jakub
> ___
> copr-devel mailing list -- copr-de...@lists.fedorahosted.org
> To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/copr-de...@lists.fedorahosted.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: Another take on RStudio (review swaps?)

[Iñaki Ucar]

Great, thanks, I'll take yours!

El jue., 20 feb. 2020 4:01, Jerry James  escribió:

> On Wed, Feb 19, 2020 at 1:17 PM Iñaki Ucar 
> wrote:
> > I managed to solve the issue with the Java stack size for the s390x
> > builder. The new koji scratch build succeeded, and now the review
> > should be quick and easy:
>
> That's great!  I will take the review.  If an OCaml review is okay,
> would you mind reviewing ocaml-lablgtk3?
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1796271
>
> Thanks,
> --
> Jerry James
> http://www.jamezone.org/
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Self Introduction: Chihurumnaya Ibiam

[Dominik 'Rathann' Mierzejewski]

Hello!

On Thursday, 20 February 2020 at 00:20, Chihurumnaya Ibiam wrote:
> Good day,
> 
> I've been working mostly with python at Sugar Labs for some time now,
> I'm yet to file a review request but I'm currently helping co-maintain
> the sugar* packages;
> I'm from Nigeria.
> 
> I'm glad to be part of the fedora project maintainers community.

Welcome to Fedora! It's good to have you on board.

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

[Bug 1805029] New: perl-IRI-0.011 is available

[bugzilla]

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

Bug ID: 1805029
   Summary: perl-IRI-0.011 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-IRI
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.011
Current version/release in rawhide: 0.010-2.fc32
URL: http://search.cpan.org/dist/IRI/

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

-- 
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-32-20200219.n.0 compose check report

[Fedora compose checker]

No missing expected images.

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

New failures (same test not failed in Fedora-32-20200218.n.0):

ID: 523757  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/523757
ID: 523762  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/523762
ID: 523772  Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/523772
ID: 523780  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/523780
ID: 523783  Test: x86_64 Server-dvd-iso realmd_join_sssd
URL: https://openqa.fedoraproject.org/tests/523783
ID: 523784  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/523784
ID: 523785  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/523785
ID: 523787  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/523787
ID: 523790  Test: x86_64 Everything-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/523790
ID: 523791  Test: x86_64 Everything-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/523791
ID: 523823  Test: x86_64 KDE-live-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/523823
ID: 523830  Test: x86_64 Silverblue-dvd_ostree-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/523830
ID: 523846  Test: x86_64 universal install_kickstart_hdd
URL: https://openqa.fedoraproject.org/tests/523846

Old failures (same test failed in Fedora-32-20200218.n.0):

ID: 523748  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/523748
ID: 523792  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/523792
ID: 523793  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/523793
ID: 523809  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/523809
ID: 523827  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/523827
ID: 523841  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/523841
ID: 523845  Test: x86_64 universal install_kickstart_firewall_disabled
URL: https://openqa.fedoraproject.org/tests/523845
ID: 523848  Test: x86_64 universal install_kickstart_nfs
URL: https://openqa.fedoraproject.org/tests/523848
ID: 523849  Test: x86_64 universal install_kickstart_user_creation
URL: https://openqa.fedoraproject.org/tests/523849
ID: 523853  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/523853
ID: 523854  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/523854
ID: 523866  Test: x86_64 universal install_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/523866
ID: 523872  Test: x86_64 universal install_blivet_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/523872
ID: 523873  Test: x86_64 universal install_kickstart_firewall_configured
URL: https://openqa.fedoraproject.org/tests/523873
ID: 523879  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/523879
ID: 523882  Test: x86_64 universal install_blivet_software_raid
URL: https://openqa.fedoraproject.org/tests/523882
ID: 523890  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/523890
ID: 523899  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/523899
ID: 523902  Test: x86_64 universal install_software_raid
URL: https://openqa.fedoraproject.org/tests/523902
ID: 523905  Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/523905
ID: 523912  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/523912
ID: 523915  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/523915
ID: 523917  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/523917
ID: 523918  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/523918

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

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

ID: 523749  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/523749
ID: 523750  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: 

[Bug 1797859] perl-Sereal-Encoder-4.011 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #7 from Fedora Update System  ---
perl-Sereal-4.011-1.el8, perl-Sereal-Decoder-4.011-1.el8,
perl-Sereal-Encoder-4.011-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-2020-6e8731a2e6

-- 
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 1797860] perl-Sereal-4.011 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #7 from Fedora Update System  ---
perl-Sereal-4.011-1.el8, perl-Sereal-Decoder-4.011-1.el8,
perl-Sereal-Encoder-4.011-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-2020-6e8731a2e6

-- 
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 1797858] perl-Sereal-Decoder-4.011 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #7 from Fedora Update System  ---
perl-Sereal-4.011-1.el8, perl-Sereal-Decoder-4.011-1.el8,
perl-Sereal-Encoder-4.011-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-2020-6e8731a2e6

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

Schedule for Thursday's FPC Meeting (2020-02-20 17:00 UTC)

[James Antill]

 Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2020-02-20 17:00 UTC in #fedora-meeting-1 on 
irc.freenode.net.

 Local time information (via. uitime):

= Day: Thursday ==
2020-02-20 09:00 PST  US/Pacific
2020-02-20 12:00 EST  --> US/Eastern <--
2020-02-20 17:00 GMT  Europe/London 
2020-02-20 17:00 UTC  UTC   
2020-02-20 18:00 CET  Europe/Berlin 
2020-02-20 18:00 CET  Europe/Paris  
2020-02-20 22:30 IST  Asia/Calcutta 
 New Day: Friday -
2020-02-21 01:00 HKT  Asia/Hong_Kong
2020-02-21 01:00 +08  Asia/Singapore
2020-02-21 02:00 JST  Asia/Tokyo
2020-02-21 03:00 AEST Australia/Brisbane


 Links to all tickets below can be found at: 

https://pagure.io/packaging-committee/issues?status=Open=meeting

= Followups =

#topic #907 Which %__foo macros for executables are acceptable? 
.fpc 907
https://pagure.io/packaging-committee/issue/907

#topic #909 Suggest that linting/measuring-coverage is not for %check
.fpc 909
https://pagure.io/packaging-committee/issue/909

= New business =

#topic #946 Bootstrap Exception for .NET Core 3.1 (dotnet3.1) 
.fpc 946
https://pagure.io/packaging-committee/issue/946


= Pull Requests =

#topic #pr-814 Add SELinux Independent Policy Guidelines 
https://pagure.io/packaging-committee/pull-request/814

#topic #pr-938 Add Package Review Process page 
https://pagure.io/packaging-committee/pull-request/938

#topic #pr-940 Revisit the Python guidelines 
https://pagure.io/packaging-committee/pull-request/940

= Open Floor = 

 For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at:

https://pagure.io/packaging-committee/issues?status=Open=meeting

 If you would like to add something to this agenda, you can:
  * Reply to this e-mail
  * File a new ticket at: https://pagure.io/packaging-committee
  * E-mail me directly
  * Bring it up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 compose report: 20200219.n.0 changes

[Fedora Branched Report]

OLD: Fedora-32-20200218.n.0
NEW: Fedora-32-20200219.n.0

= SUMMARY =
Added images:1
Dropped images:  0
Added packages:  10
Dropped packages:2
Upgraded packages:   188
Downgraded packages: 0

Size of added packages:  12.50 MiB
Size of dropped packages:271.60 KiB
Size of upgraded packages:   3.42 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -25.67 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Silverblue dvd-ostree x86_64
Path: Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-32-20200219.n.0.iso

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: ghc-filepath-bytestring-1.4.2.1.6-1.fc32
Summary: Library for manipulating RawFilePaths in a cross platform way
RPMs:ghc-filepath-bytestring ghc-filepath-bytestring-devel 
ghc-filepath-bytestring-doc ghc-filepath-bytestring-prof
Size:1.52 MiB

Package: ghc-lens-family-core-1.2.3-1.fc32
Summary: Haskell 98 Lens Families
RPMs:ghc-lens-family-core ghc-lens-family-core-devel 
ghc-lens-family-core-doc ghc-lens-family-core-prof
Size:1.06 MiB

Package: golang-github-crewjam-httperr-0.2.0-1.fc32
Summary: A golang error object that speaks HTTP
RPMs:golang-github-crewjam-httperr-devel
Size:17.99 KiB

Package: golang-github-zyedidia-highlight-0-0.1.20200218git291680f.fc32
Summary: Go package for syntax highlighting
RPMs:golang-github-zyedidia-highlight golang-github-zyedidia-highlight-devel
Size:4.25 MiB

Package: libfido2-1.3.0-3.fc32
Summary: FIDO2 library
RPMs:fido2-tools libfido2 libfido2-devel
Size:995.92 KiB

Package: libx86-1.1-30.fc32
Summary: Library for making real-mode x86 calls
RPMs:libx86 libx86-devel
Size:129.92 KiB

Package: nodejs-toidentifier-1.0.0-1.fc32
Summary: Convert a string of words to a JavaScript identifier
RPMs:nodejs-toidentifier
Size:9.61 KiB

Package: rust-procs-0.9.11-1.fc32
Summary: Modern replacement for ps
RPMs:procs
Size:3.67 MiB

Package: tpm2-tss-engine-1.0.1-1.fc32
Summary: OpenSSL Engine for TPM2 devices using the tpm2-tss software stack
RPMs:tpm2-tss-engine tpm2-tss-engine-devel tpm2-tss-engine-utilities
Size:324.09 KiB

Package: vmem-1.8-1.fc32
Summary: Volatile Memory Development Kit
RPMs:libvmem libvmem-debug libvmem-devel libvmmalloc libvmmalloc-debug 
libvmmalloc-devel
Size:572.01 KiB


= DROPPED PACKAGES =
Package: jboss-transaction-1.2-api-1.1.1-2.fc32
Summary: Transaction 1.2 API
RPMs:jboss-transaction-1.2-api jboss-transaction-1.2-api-javadoc
Size:95.04 KiB

Package: jettison-1.4.0-2.fc32
Summary: JSON StAX implementation
RPMs:jettison jettison-javadoc
Size:176.56 KiB


= UPGRADED PACKAGES =
Package:  BackupPC-4.3.2-1.fc32
Old package:  BackupPC-4.3.1-4.fc32
Summary:  High-performance backup system
RPMs: BackupPC
Size: 2.07 MiB
Size change:  10.69 KiB
Changelog:
  * Tue Feb 18 2020 Richard Shaw  - 4.3.2-1
  - Update to 4.3.2.
  - Update SELinux permissions, fixes RHBZ#1791369.


Package:  NetworkManager-1:1.22.8-1.fc32
Old package:  NetworkManager-1:1.22.6-2.fc32
Summary:  Network connection manager and user applications
RPMs: NetworkManager NetworkManager-adsl NetworkManager-bluetooth 
NetworkManager-cloud-setup NetworkManager-config-connectivity-fedora 
NetworkManager-config-server NetworkManager-dispatcher-routing-rules 
NetworkManager-libnm NetworkManager-libnm-devel NetworkManager-ovs 
NetworkManager-ppp NetworkManager-team NetworkManager-tui NetworkManager-wifi 
NetworkManager-wwan
Size: 27.18 MiB
Size change:  50.63 KiB
Changelog:
  * Tue Feb 18 2020 Antonio Cardace  - 1:1.22.8-1
  - Update to 1.22.8


Package:  R-3.6.2-5.fc32
Old package:  R-3.6.2-3.fc32
Summary:  A language for data analysis and graphics
RPMs: R R-core R-core-devel R-devel R-java R-java-devel libRmath 
libRmath-devel libRmath-static
Size: 340.72 MiB
Size change:  -4.72 MiB
Changelog:
  * Tue Feb 18 2020 Tom Callaway  - 3.6.2-4
  - fix conditionals so that Fedora builds against system openblas for 
lapack/blas
and we only generate the R lapack/blas libs on RHEL 5-6-7 (where system 
lapack/openblas
is not reliable). Thanks to Dirk Eddelbuettel for pointing out the error.

  * Tue Feb 18 2020 Tom Callaway  - 3.6.2-5
  - fix openblas conditionals, openblas has wider arch support everywhere 
except el7


Package:  R-expm-0.999.4-5.fc32
Old package:  R-expm-0.999.4-4.fc32
Summary:  Computation of the matrix exponential and related quantities
RPMs: R-expm
Size: 1.08 MiB
Size change:  -900 B
Changelog:
  * Tue Feb 18 2020 Tom Callaway  - 0.999.4-5
  - rebuild for R without libRlapack.so


Package:  R-gss-2.1.10-5.fc32
Old package:  R-gss-2.1.10-4.fc32
Summary:  General Smoothing Splines
RPMs: R-gss
Size: 7.14 MiB
Size change:  -28 B
Changelog:
  * Tue Feb 18 2020 Tom Callaway  - 2.1.10-5
  - rebuild against R

[389-devel] 389 DS nightly 2020-02-20 - 97% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2020/02/20/report-389-ds-base-1.4.3.3-20200220git031c0b9.fc31.x86_64.html
___
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: Another take on RStudio (review swaps?)

[Jerry James]

On Wed, Feb 19, 2020 at 1:17 PM Iñaki Ucar  wrote:
> I managed to solve the issue with the Java stack size for the s390x
> builder. The new koji scratch build succeeded, and now the review
> should be quick and easy:

That's great!  I will take the review.  If an OCaml review is okay,
would you mind reviewing ocaml-lablgtk3?

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

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

Re: Fedora-Rawhide-20200219.n.0 compose check report

[Adam Williamson]

On Wed, 2020-02-19 at 09:29 +, Fedora compose checker wrote:
> No missing expected images.
> 
> Compose FAILS proposed Rawhide gating check!
> 24 of 43 required tests failed, 17 results missing
> openQA tests matching unsatisfied gating requirements shown with **GATING** 
> below
> 
> Failed openQA tests: 88/158 (x86_64), 1/2 (arm)

The results here are a bit of a lie. Up till yesterday, just about
every test really *was* failing, due to this bug:

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

but that's resolved now. A lot of the initial failures on this compose
were false negatives, caused by GNOME icons and widgets changing a bit
since the last time the tests got that far, and also by a change to
fedora-repos which caused openQA some trouble.

I've fixed the needles and re-run the tests; you can see the current
results at
https://openqa.fedoraproject.org/tests/overview?distri=fedora=Rawhide=Fedora-Rawhide-20200219.n.0=1
. Some of the remaining failures (mostly the Server-dvd-iso tests) are
due to the fedora-repos issue; I'm not doing a hacky workaround for
those for this compose, because we've just fixed the problem (I hope)
in fedora-repos and so it should be OK for tomorrow's compose. I'm also
not going to re-generate this report for the same reason, let's just
wait for tomorrow's compose for (hopefully) fully accurate data.

I'm currently diagnosing and reporting some failures which are *real*
bugs - notably UEFI live installs seem to be broken, and so do software
RAID installs.

Thanks folks!
-- 
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

Self Introduction: Chihurumnaya Ibiam

[Chihurumnaya Ibiam]

Good day,

I've been working mostly with python at Sugar Labs for some time now, I'm
yet to file a review request but I'm currently helping co-maintain the
sugar* packages;
I'm from Nigeria.

I'm glad to be part of the fedora project maintainers community.

-- 

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

Re: s390x builder problem? disk full, or ?

[Kevin Fenzi]

On Wed, Feb 19, 2020 at 01:17:29PM -0500, R P Herrold wrote:
> On Wed, 19 Feb 2020, Kaleb Keithley wrote:
> 
> long ago
>   diskcheck
> was in Centos 2, and early Fedora
>   /var/ftp/pub/nfs/mirror/redhat/fedora/1/SRPMS/diskcheck-1.4-5.src.rpm
> 
> Why not build and install it so the admins would get warnings 
> ?

Because it's not that simple. 
 
> Also, when a build fails for:
>   error: create archive failed on file  
>   cpio: write failed - No space left on device
> 
> why not also emit a fedbus, or related message ?

Sure we could, but what action do we take?

kojid keeps track of buildroots it has still around and culls those from
failed or successfull builds. It also won't accept new builds if there's
too low a space. The problem shows up when there's a ton of small
buildroots (koschei) or multiple large builds unpack on the same builder
and mess up each other. 

Hopefully adjust koschei will fix most of this... but after that we
should just tweak the kojid parameters until we get something that
works. (I note that I saw no signs of this while koschei was off). 

kevin


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

Re: s390x builder problem? disk full, or ?

[Kevin Fenzi]

On Wed, Feb 19, 2020 at 01:05:59PM -0500, Kaleb Keithley wrote:
> 
> The original issue seemed to clear itself up. Or at least by random chance
> I got a builder that wasn't full.

Its not got anything to do will full as far as we can tell.
It seems sporadic. The best kind of bugs to try and solve. ;( 
> 
> But since you rebooted I've fired off a build, only to have it die at the
> very end writing the rpm files. :-(
> 
> https://koji.fedoraproject.org/koji/getfile?taskID=41651353=DEFAULT=build.log=-4000
> 
> it's not the kernel, but never the less, these aren't quick builds,
> especially on s390x so it's very frustrating.

That issue is disk space, which is unfortunately a complex issue on
builders. 

That builder (BTW, please post links to top level taskid. it makes it
easier to find things) has currently 59 buildroots on it since I
rebooted it yesterday, taking up about 81GB of space. I suspect most of
those builds are koschei ones, but it could be some are things like
libreoffice or large module builds. Hopefully we can get koschei to stop
taking up space soon... but then past that we need to lower the time to
keep failed buildroots around or prevent so many builds using the same
builders. ie, think of the case where your build and say libreoffice
were using the same builder... it could easily take up all space between
the two, but be fine one at a time. 
> 
> Let's push it back up the hill

Sorry for the hassles. ;( 

kevin


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

Re: Another take on RStudio (review swaps?)

[Iñaki Ucar]

I managed to solve the issue with the Java stack size for the s390x
builder. The new koji scratch build succeeded, and now the review
should be quick and easy:

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

Iñaki

On Tue, 18 Feb 2020 at 20:23, Iñaki Ucar  wrote:
>
> On Tue, 18 Feb 2020 at 08:39, Iñaki Ucar  wrote:
> >
> > On Tue, 18 Feb 2020 at 01:11, Jerry James  wrote:
> > >
> > > On Sun, Feb 16, 2020 at 10:06 AM Iñaki Ucar  
> > > wrote:
> > > > If anyone is interested in pushing this forward, I can review
> > > > something in exchange. Note that the koji scratch build fails on s390x
> > > > due to a Java stack overflow. Does anyone know what's the default in
> > > > that arch and how to increase it?
> > >
> > > You can find the default like this:
> > >
> > > java -XX:+PrintFlagsFinal
> > >
> > > Then look for ThreadStackSize in the output.  It is 1024 on my x86_64
> > > machine with Java 8, and 1536 on an s390x machine where I have an
> > > account.  Pass -Xss to java or -J-Xss to javac to increase it.
> >
> > Thanks, Jerry. Is there an environment variable to do that? In this
> > package there is an "ant" invocation buried in the cmake-based build
> > system, so I tried
> >
> > %ifarch s390 s390x
> > export _JAVA_OPTIONS="-Xss16M"
> > %endif
> >
> > with no luck. The compilation still fails with a Java stack overflow,
> > so I suppose that this env variable is not being used.
>
> I tried also exporting ANT_OPTS="-Xss..." with no luck either. I'm
> getting out of ideas.
>
> And still the package needs a reviewer. :) :)
>
> Iñaki



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

Review Swap

[Breno Brand Fernandes]

Hi,

Would someone mind swapping reviews?
I am building puppet 6 for EPEL 8 and this one[1] is a dependency.

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

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

[rpms/perl-Scalar-List-Utils] PR #1: Spec file cleanups: Use make_build and make_install macros

[Jan Pazdziora]

adelton commented on the pull-request: `Spec file cleanups: Use make_build and 
make_install macros` that you are following:
``
I did not plan to do a rebuild just for this change.
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Scalar-List-Utils/pull-request/1
___
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

[rpms/perl-libintl-perl] PR #1: Spec file cleanups: Use make_build and make_install macros

[Emmanuel Seyman]

eseyman merged a pull-request against the project: `perl-libintl-perl` that you 
are following.

Merged pull-request:

``
Spec file cleanups: Use make_build and make_install macros
``

https://src.fedoraproject.org/rpms/perl-libintl-perl/pull-request/1
___
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

[rpms/perl-libintl-perl] PR #1: Spec file cleanups: Use make_build and make_install macros

[Emmanuel Seyman]

The pull-request: `Spec file cleanups: Use make_build and make_install macros` 
of project: `perl-libintl-perl` has been assigned to `eseyman` by eseyman.

https://src.fedoraproject.org/rpms/perl-libintl-perl/pull-request/1
___
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: s390x builder problem? disk full, or ?

[R P Herrold]

On Wed, 19 Feb 2020, Kaleb Keithley wrote:

long ago
diskcheck
was in Centos 2, and early Fedora
/var/ftp/pub/nfs/mirror/redhat/fedora/1/SRPMS/diskcheck-1.4-5.src.rpm

Why not build and install it so the admins would get warnings 
?

Also, when a build fails for:
error: create archive failed on file  
cpio: write failed - No space left on device

why not also emit a fedbus, or related message ?

-- Russ herrold



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: s390x builder problem? disk full, or ?

[Kaleb Keithley]

On Tue, Feb 18, 2020 at 9:59 PM Kevin Fenzi  wrote:

> On Tue, Feb 18, 2020 at 04:41:42PM -0800, Kevin Fenzi wrote:
> > On Tue, Feb 18, 2020 at 02:05:07PM -0500, Kaleb Keithley wrote:
> > > several of my `koji --scratch --arch-overide=s390x ...`  builds have
> failed
> > > with error; reading package header (after the rebuildSRPM)
> > >
> > > Latest is https://koji.fedoraproject.org/koji/taskinfo?taskID=41622496
> > >
> > > (guess I could reopen my s390x disk full ticket. Or open a new one.)
> >
> > Sure, but thats not going to magicially make us solve the problem. ;(
> >
> > It seems to happen sporadically, when the s390x builders are under heavy
> > load. It seems to happen to the Zvm instances more than the Kvm
> > instances. :(
> >
> > I think they might be in odd states, so I am going to try and reboot
> > them tonight when things aren't as busy and see if that helps any.
>
> FWIW, I have rebooted all the s390x builders now.
>
> Hopefully that will help with this issue...
>

The original issue seemed to clear itself up. Or at least by random chance
I got a builder that wasn't full.

But since you rebooted I've fired off a build, only to have it die at the
very end writing the rpm files. :-(

https://koji.fedoraproject.org/koji/getfile?taskID=41651353=DEFAULT=build.log=-4000

it's not the kernel, but never the less, these aren't quick builds,
especially on s390x so it's very frustrating.

Let's push it back up the hill

--

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

[rpms/perl-FCGI] PR #1: Spec file cleanups: Use make_build and make_install macros

[Petr Pisar]

ppisar merged a pull-request against the project: `perl-FCGI` that you are 
following.

Merged pull-request:

``
Spec file cleanups: Use make_build and make_install macros
``

https://src.fedoraproject.org/rpms/perl-FCGI/pull-request/1
___
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 1797860] perl-Sereal-4.011 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |MODIFIED



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

-- 
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 1797859] perl-Sereal-Encoder-4.011 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |MODIFIED



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

-- 
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 1797858] perl-Sereal-Decoder-4.011 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |MODIFIED



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

-- 
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: Bodhi weirdness

[Adam Williamson]

On Wed, 2020-02-19 at 10:38 +0100, Fabio Valentini wrote:
> On Wed, Feb 19, 2020 at 4:08 AM Richard Shaw  wrote:
> > This isn't the first time that this has happened but I have pushed multiple 
> > builds in one bodhi update through the web interface and:
> > 
> > 1. It takes forever
> > 2. Only one (or some) updates are created, others are dropped
> > 
> > What gives? It's a PITA to create the same update again...
> 
> I've been seeing similar issues, but I couldn't figure out a way to
> reproduce them. Often, creating the first update works fine, but
> subsequent update creation requests spin forever.
> Most of the time, the "Submit" button when creating a new update just
> spins forever, but checking in another window, the update indeed is
> already created. Or sometimes, editing an update text body doesn't
> take effect when clicking "Save" ...
> Since this "endless hang but mostly succeed anyway" also happens when
> creating updates from the bodhi CLI / REST API, I assume this is not a
> frontend issue, but a backend issue ...

At least part of the problem is a frontend issue.

https://github.com/fedora-infra/bodhi/issues/3837
-- 
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

Points of contact for Modularity

[Petr Šabata]

Just a minor FYI announcement:

As most of the original Modularity Team is moving on to face new
challenges, Red Hat's effort will now be primarily represented by the
software management group, with Daniel Mach coming up with an updated
Modularity Objective in the following weeks.

In essence, everything remains the same; continue using the Pagure
tracker and our IRC channel when interacting with the team -- just
expect to see "new" faces from now on. The weekly meetings are
temporarily cancelled until the group agrees on a new time slot and
way of working.

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

Review elementary-tweaks

[Harsh Jain]

Hey,
I would really appreciate if someone would be kind enough to review my
first package .It is the elementary-tweaks tool built for pantheon de.
https://bugzilla.redhat.com/show_bug.cgi?id=1802177
I have no experience in reviewing a package but if someone has a simple
review, maybe I can do that .
Thanks,
Harsh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[rpms/perl-Scalar-List-Utils] PR #1: Spec file cleanups: Use make_build and make_install macros

[Tom Stellard]

tstellar commented on the pull-request: `Spec file cleanups: Use make_build and 
make_install macros` that you are following:
``
Thanks, were you planning to submit a new build with this change or would you 
like me to do it?
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Scalar-List-Utils/pull-request/1
___
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: Qt, GNOME, and fonts

[Jan Grulich]

Hi,

can you try to run with QT_DEBUG_PLUGINS=1 and attach here the output? Does 
uninstalling QGnomePlatform package make any difference? Can you be more 
specific about where exactly you are trying to change the font which doesn't 
apply? I opened the "Style" option and there is tons of configuration so I'm 
kinda lost as I don't know MuseScore at all.

Regards,
Jan

On úterý 18. února 2020 0:08:31 CET Jerry James wrote:
> I am trying to track down a font problem with MuseScore:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1790829
> 
> The problem is that everything is displayed in Cantarell, no matter
> which font the user actually selects.  In the style menu, one can pop
> up a list of fonts to choose from, and even though every font on the
> system is displayed by name, the text samples are all displayed in
> Cantarell.
> 
> I spent several hours with GDB trying to figure this out (which is how
> I was able to determine that Cantarell is the font we're always
> looking at), but I still don't understand what is happening.  It
> finally dawned on me that I'm running a GNOME desktop, but MuseScore
> is a Qt application.  So I logged out, logged into a KDE Plasma
> session, and (drum roll please) all of the fonts displayed correctly.
> 
> The bug submitter pointed out that if one downloads the AppImage
> created by MuseScore upstream, that displays all of the fonts
> correctly. Even on my GNOME desktop, that is true.  The fonts are all
> correct.  I can see that all of the Qt and X libraries are baked into
> the AppImage, but why does that matter?
> 
> Does anybody have experience with this sort of thing?  It would be
> nice if we could display the fonts correctly when running on a GNOME
> desktop.  Thanks,
> -- 
> Jerry James
> http://www.jamezone.org/
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List
> Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List
> Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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

[rpms/perl-Net-SSLeay] PR #1: Spec file cleanups: Use make_build and make_install macros

[Paul Howarth]

pghmcfc merged a pull-request against the project: `perl-Net-SSLeay` that you 
are following.

Merged pull-request:

``
Spec file cleanups: Use make_build and make_install macros
``

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

[EPEL-devel] Re: Proposed official change to EPEL guidelines: modules and RHEL

[Troy Dawson]

On Wed, Feb 19, 2020 at 4:17 AM Pablo Sebastián Greco
 wrote:
>
>
> On 18/2/20 21:06, Kevin Fenzi wrote:
> > On Sat, Feb 15, 2020 at 05:17:01PM -0500, Matthew Miller wrote:
> >> On Fri, Feb 14, 2020 at 03:04:17PM -0800, Kevin Fenzi wrote:
> >>> This is what I was trying to get to in the thread recently about
> >>> libssh2. However it's still not entirely clear to me.
> >>>
> >>> Does this mean if there's a package foo that is a rhel package, but not
> >>> in a module, that it can be overlapped with a foo package thats in a
> >>> epel non default module? ie, does it only mean the modular case or does
> >>> it mean any rpm?
> >> I don't understand the last sentence. To the first question: yes, and that
> >> non-default module package will only get installed if the module is
> >> explicitly enabled.
> > Consider:
> >
> > 1. foo rpm that is in the RHEL baseos. It's not in any module.
> > Can epel make a foo (non default) module that overrides it?
> >
> > 2. foo rpm that is in a RHEL default module.
> > Can epel make a foo (non default) module that overrides it?
> >
> > 3. foo rpm that is in a RHEL non default module.
> > Can epel make a foo (non default) module that overrides it?
> >
> > I think we all agree 3 is fine.
> > I think 2 could cause problems, but perhaps it would work.
> > I would think 1 would be fine also.
> Kevin, I think 1 is a problem, because IIRC, if a package is part of a
> module, its non-modular version is automatically hidden.

Only if that module is default, or that module is enabled.
Otherwise the regular, non-module, rpm is what you see.

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

Re: fedora-gpg-keys not updated yet again

[Vít Ondruch]

This is the time of the year again and I must say that the situation
improved. The process was:


~~~

$ sudo dnf update fedora-gpg-keys

$ sudo dnf update fedora-repos --release 33

~~~


Where for the second command, you have to confirm the GPG key import.

Please note that the `--release 33` has to be specified, because while
the fedora-rawhide repos points to a `rawhide` mirror:


~~~

metalink=https://mirrors.fedoraproject.org/metalink?repo=rawhide=$basearch

~~~


The GPG key refers to `$releasever`


~~~

gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch

~~~


This is discussed in https://pagure.io/releng/issue/7445 AFAIK.



Vít


Dne 19. 08. 19 v 10:50 Zbigniew Jędrzejewski-Szmek napsal(a):
> This seems to repeat every 6 months: rawhide mock is broken on stable
> Fedora, people are scrambling to install the right gpg keys, dnf reports
> unsigned packages.
>
> Looking at https://bodhi.fedoraproject.org/updates/?packages=fedora-repos,
> there is still no F30 package with the right keys.
>
> Can we *please* send out the FN+1 and FN+2 keys a month before branching,
> to *all* releases of Fedora, so we can avoid this pointless scramble?
>
> Zbyszek
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Qt, GNOME, and fonts

[Fabio Valentini]

On Tue, Feb 18, 2020 at 12:09 AM Jerry James  wrote:
>
> I am trying to track down a font problem with MuseScore:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1790829
>
> The problem is that everything is displayed in Cantarell, no matter
> which font the user actually selects.  In the style menu, one can pop
> up a list of fonts to choose from, and even though every font on the
> system is displayed by name, the text samples are all displayed in
> Cantarell.
>
> I spent several hours with GDB trying to figure this out (which is how
> I was able to determine that Cantarell is the font we're always
> looking at), but I still don't understand what is happening.  It
> finally dawned on me that I'm running a GNOME desktop, but MuseScore
> is a Qt application.  So I logged out, logged into a KDE Plasma
> session, and (drum roll please) all of the fonts displayed correctly.
>
> The bug submitter pointed out that if one downloads the AppImage
> created by MuseScore upstream, that displays all of the fonts
> correctly. Even on my GNOME desktop, that is true.  The fonts are all
> correct.  I can see that all of the Qt and X libraries are baked into
> the AppImage, but why does that matter?
>
> Does anybody have experience with this sort of thing?  It would be
> nice if we could display the fonts correctly when running on a GNOME
> desktop.  Thanks,

It sounds like this might be a problem with QGnomePlatform, which
handles Qt application's appearance settings when they run on GNOME,
IIRC.

Fabio

> --
> Jerry James
> http://www.jamezone.org/
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Announcement: EPEL Steering Committee Changes

[Charalampos Stratakis]

- Original Message -
> From: "Stephen John Smoogen" 
> To: "EPEL Development List" , 
> "Development discussions related to Fedora"
> 
> Sent: Tuesday, February 18, 2020 6:35:26 PM
> Subject: Announcement: EPEL Steering Committee Changes
> 
> Hi,
> 
> It has been a pleasure for me to be a part of and help lead the
> EPEL steering committee for the last couple of years. It has not
> always been smooth sailing but I have found it an enjoyable experience.
> 
> However, as you may know the Fedora project will be moving to a
> different data-center later this spring (from Phoenix to northern
> Virginia). Being involved in the planning and implementation of this
> project, I do not think that I will be able to give EPEL the time
> investment it deserve for the next 6 to 9 months. With EPEL-8 still
> ramping up and the various opportunities with modularity, I do
> not think it is a fair that EPEL suffers from this lack of time.
> 
> As such, I would like to step down as chair/member of the steering
> committee and nominate Troy Dawson as my replacement. Troy formerly
> worked on Scientific Linux and has worked on OpenShift and other
> projects at Red Hat for the last several years.  It is clear he has a
> good eye on the concerns and problems enterprise users have. Recently,
> Troy helped get the initial RHEL-8 and EPEL-8 out the door with
> multiple builds and updates to various macro files.
> 
> Once the move is completed and the close down of the old site is done,
> I look forward to getting involved again in EPEL.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 

Thank you for all your work throughout the years.

I believe Troy would be an excellent replacement. I've worked with him before 
on some initiatives and he's always been very supportive and swift in answering 
questions and figuring out issues from the tiniest detail to the higher level.

So Stephen good luck on your next endeavors and Troy welcome :)

-- 
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[rpms/perl-Net-SSLeay] PR #1: Spec file cleanups: Use make_build and make_install macros

[Tom Stellard]

tstellar commented on the pull-request: `Spec file cleanups: Use make_build and 
make_install macros` that you are following:
``
Ok, I've fixed the comment now.
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Net-SSLeay/pull-request/1
___
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: Announcement: EPEL Steering Committee Changes

[Peter Boy]

> Am 19.02.2020 um 06:59 schrieb John M. Harris Jr :
> 
> Based on this, I'm not so sure that Troy is the best person to take that 
> place 
> within EPEL's Steering Committee. ..., as he is a member of the 
> Modularity team, this is not a good sign for what's to come.


Whether modularity is good news or a nightmare, it is a fact in EL 8. Troy 
obviously being familiar with it might be the best to make it work as smooth as 
possible. Besides I remember him as very supportive from Scientific Linux 
(sadly gone with EL8)so I'd appreciate it.  


—
Dr. Peter Boy
University of Bremen
Mary-Sommerville-Str. 5
28359 Bremen
Germany

p...@zes.uni-bremen.de
www.zes.uni-bremen.de


 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Announcement: EPEL Steering Committee Changes

[Neal Gompa]

On Tue, Feb 18, 2020 at 1:12 PM Troy Dawson  wrote:
>
> On Tue, Feb 18, 2020 at 9:36 AM Stephen John Smoogen  wrote:
> >
> > Hi,
> >
> > It has been a pleasure for me to be a part of and help lead the
> > EPEL steering committee for the last couple of years. It has not
> > always been smooth sailing but I have found it an enjoyable experience.
> >
> > However, as you may know the Fedora project will be moving to a
> > different data-center later this spring (from Phoenix to northern
> > Virginia). Being involved in the planning and implementation of this
> > project, I do not think that I will be able to give EPEL the time
> > investment it deserve for the next 6 to 9 months. With EPEL-8 still
> > ramping up and the various opportunities with modularity, I do
> > not think it is a fair that EPEL suffers from this lack of time.
> >
> > As such, I would like to step down as chair/member of the steering
> > committee and nominate Troy Dawson as my replacement. Troy formerly
> > worked on Scientific Linux and has worked on OpenShift and other
> > projects at Red Hat for the last several years.  It is clear he has a
> > good eye on the concerns and problems enterprise users have. Recently,
> > Troy helped get the initial RHEL-8 and EPEL-8 out the door with
> > multiple builds and updates to various macro files.
> >
> > Once the move is completed and the close down of the old site is done,
> > I look forward to getting involved again in EPEL.
>
> Thank you Stephen for all that you've done for the EPEL community the
> past several years.  I hope the move goes smooth so that you can
> return to us sooner, rather than later.
>
> I will do my best to keep EPEL steering in the right direction.
>

I second the nomination of Troy. He's been a pleasure to work with and
has done fantastic work to bring KDE Plasma to RHEL/CentOS users after
Red Hat ripped it out of RHEL for RHEL 8.

The fact that he's a member of modularity team means that he can
easily take our feedback and have it incorporated into improving the
system, which is a huge boon for us as RHEL 8 leverages that
everywhere.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Announcement: EPEL Steering Committee Changes

[Neal Gompa]

On Tue, Feb 18, 2020 at 1:12 PM Troy Dawson  wrote:
>
> On Tue, Feb 18, 2020 at 9:36 AM Stephen John Smoogen  wrote:
> >
> > Hi,
> >
> > It has been a pleasure for me to be a part of and help lead the
> > EPEL steering committee for the last couple of years. It has not
> > always been smooth sailing but I have found it an enjoyable experience.
> >
> > However, as you may know the Fedora project will be moving to a
> > different data-center later this spring (from Phoenix to northern
> > Virginia). Being involved in the planning and implementation of this
> > project, I do not think that I will be able to give EPEL the time
> > investment it deserve for the next 6 to 9 months. With EPEL-8 still
> > ramping up and the various opportunities with modularity, I do
> > not think it is a fair that EPEL suffers from this lack of time.
> >
> > As such, I would like to step down as chair/member of the steering
> > committee and nominate Troy Dawson as my replacement. Troy formerly
> > worked on Scientific Linux and has worked on OpenShift and other
> > projects at Red Hat for the last several years.  It is clear he has a
> > good eye on the concerns and problems enterprise users have. Recently,
> > Troy helped get the initial RHEL-8 and EPEL-8 out the door with
> > multiple builds and updates to various macro files.
> >
> > Once the move is completed and the close down of the old site is done,
> > I look forward to getting involved again in EPEL.
>
> Thank you Stephen for all that you've done for the EPEL community the
> past several years.  I hope the move goes smooth so that you can
> return to us sooner, rather than later.
>
> I will do my best to keep EPEL steering in the right direction.
>

I second the nomination of Troy. He's been a pleasure to work with and
has done fantastic work to bring KDE Plasma to RHEL/CentOS users after
Red Hat ripped it out of RHEL for RHEL 8.

The fact that he's a member of modularity team means that he can
easily take our feedback and have it incorporated into improving the
system, which is a huge boon for us as RHEL 8 leverages that
everywhere.


-- 
真実はいつも一つ！/ 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

Outage: Migration of Copr servers - 2020-02-23 06:00 UTC

[Jakub Kadlcik]

There will be an outage starting at 2020-02-23 06:00 UTC, which will last
approximately 7 hours (but can take more if something goes wrong).

To convert UTC to your local time, take a look at
https://fedoraproject.org/wiki/UTCHowto
or run:

date -d '2020-02-23 06:00 UTC'

Reason for outage:

Moving Copr servers from OpenStack to Amazon AWS because OpenStack is
going to be shut down soon.

Affected Services:

copr-frontend - https://copr.fedorainfracloud.org
copr-backend - https://copr-be.cloud.fedoraproject.org/
copr-distgit
copr-keygen

Backend repositories should remain available during the outage.

Ticket Link:

https://pagure.io/fedora-infrastructure/issue/8668

Contact Information:

Please join #fedora-admin in irc.freenode.net or add comments to the
ticket for this outage above.


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

Re: Announcement: EPEL Steering Committee Changes

[Stephen John Smoogen]

On Wed, 19 Feb 2020 at 01:01, John M. Harris Jr  wrote:
>
> On Tuesday, February 18, 2020 10:35:26 AM MST Stephen John Smoogen wrote:
> > Hi,
> >
> > It has been a pleasure for me to be a part of and help lead the
> > EPEL steering committee for the last couple of years. It has not
> > always been smooth sailing but I have found it an enjoyable experience.
> >
> > However, as you may know the Fedora project will be moving to a
> > different data-center later this spring (from Phoenix to northern
> > Virginia). Being involved in the planning and implementation of this
> > project, I do not think that I will be able to give EPEL the time
> > investment it deserve for the next 6 to 9 months. With EPEL-8 still
> > ramping up and the various opportunities with modularity, I do
> > not think it is a fair that EPEL suffers from this lack of time.
> >
> > As such, I would like to step down as chair/member of the steering
> > committee and nominate Troy Dawson as my replacement. Troy formerly
> > worked on Scientific Linux and has worked on OpenShift and other
> > projects at Red Hat for the last several years.  It is clear he has a
> > good eye on the concerns and problems enterprise users have. Recently,
> > Troy helped get the initial RHEL-8 and EPEL-8 out the door with
> > multiple builds and updates to various macro files.
> >
> > Once the move is completed and the close down of the old site is done,
> > I look forward to getting involved again in EPEL.
>
> Based on this, I'm not so sure that Troy is the best person to take that place
> within EPEL's Steering Committee. As an enterprise admin, RHEL8 has been
> nothing but a nightmare to deal with because of Modularity. I know Troy didn't
> singlehandedly sign off on that nonsense, but, as he is a member of the
> Modularity team, this is not a good sign for what's to come.
>

The chairperson's job is mainly to find out what work can be done with
the volunteers who show up on any particular day. Beyond that they do
not get to dictate anything beyond what is on the agenda for the next
meeting. Most of the work is motivating people and helping others find
solutions with the tools that are currently available. That said, Troy
has shown a great ability to deal with that situation with the many
years of working in the Scientific Linux community.

In the end, the EPEL steering committee does the best it can with the
cards it is dealt with. If RHEL-8 is going to be modular, then you
work out how to make modularity work with it. If RHEL-9 moved to
MacOS-X .dmg files.. you deal with that and get packages out the door
for administrators in a way that works best with that OS.


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

[EPEL-devel] Re: Proposed official change to EPEL guidelines: modules and RHEL

[Pablo Sebastián Greco]

On 18/2/20 21:06, Kevin Fenzi wrote:

On Sat, Feb 15, 2020 at 05:17:01PM -0500, Matthew Miller wrote:

On Fri, Feb 14, 2020 at 03:04:17PM -0800, Kevin Fenzi wrote:

This is what I was trying to get to in the thread recently about
libssh2. However it's still not entirely clear to me.

Does this mean if there's a package foo that is a rhel package, but not
in a module, that it can be overlapped with a foo package thats in a
epel non default module? ie, does it only mean the modular case or does
it mean any rpm?

I don't understand the last sentence. To the first question: yes, and that
non-default module package will only get installed if the module is
explicitly enabled.

Consider:

1. foo rpm that is in the RHEL baseos. It's not in any module.
Can epel make a foo (non default) module that overrides it?

2. foo rpm that is in a RHEL default module.
Can epel make a foo (non default) module that overrides it?

3. foo rpm that is in a RHEL non default module.
Can epel make a foo (non default) module that overrides it?

I think we all agree 3 is fine.
I think 2 could cause problems, but perhaps it would work.
I would think 1 would be fine also.
Kevin, I think 1 is a problem, because IIRC, if a package is part of a 
module, its non-modular version is automatically hidden.

kevin


Pablo.
___
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: Preparing for OpenVPN 3 package review

[Vitaly Zaitsev via devel]

On 19.02.2020 09:32, Tom Hughes wrote:
> In this case I believe that although the client is intended to be
> protocol compatible with openvpn 2 it's basically an entirely new
> program with a totally different architecture and user interface
> so parallel packaging seems reasonable.

I think it will be better to create compat openvpn2 package and switch
regular openvpn to version 3.x in Rawhide.

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

Orphaned netty (outdated + open security issues)

[Fabio Valentini]

Hi everybody,

The Stewardship SIG has decided to orphan netty. None of our packages
still depend on it.
We were also unable to update the package to newer versions, and the
currently available version has some open security issues associated
with it:

- CVE-2019-20444: https://bugzilla.redhat.com/show_bug.cgi?id=1798525
- CVE-2019-20445: https://bugzilla.redhat.com/show_bug.cgi?id=1798511
- CVE-2020-7237: https://bugzilla.redhat.com/show_bug.cgi?id=1796276

These issues need to be resolved by whomever picks the package up.

Fabio + the Stewardship SIG
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Preparing for OpenVPN 3 package review

[Vít Ondruch]

Dne 19. 02. 20 v 9:32 Tom Hughes napsal(a):
> On 19/02/2020 07:05, Vitaly Zaitsev via devel wrote:
>> On 18.02.2020 22:29, David Sommerseth wrote:
>>> We released the OpenVPN 3 Linux v8 beta release early last week [0],
>>> with the
>>> Fedora Copr repository [1] updated as well.  Now things are working
>>> so well it
>>> is about time to get this package into the mainline Fedora
>>> repositories.
>>
>> Fedora already has OpenVPN package, so you cannot add another one,
>> because when version 3.0 will be released by upstream, Fedora's package
>> will be updated and it will cause package conflict, which is strictly
>> forbidden by Fedora guidelines.
>
> That's certainly how things typically works, but it's certainly
> not the only one - see python3 for example.
>
> In this case I believe that although the client is intended to be
> protocol compatible with openvpn 2 it's basically an entirely new
> program with a totally different architecture and user interface
> so parallel packaging seems reasonable.


In that case, it would be much better to rename openvpn to openvpn2 and
rebase the openvpn to version 3 without suffix.


Vít


>
>
> In addition I think that this is only the client, so the existing
> package will still be needed for server usage for now. I'm not
> totally sure about that though as the package is a little confusing
> on that front - it calls itself a client but also has a -client
> subpackage.
>
> Tom
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Bodhi weirdness

[Ankur Sinha]

On Wed, Feb 19, 2020 10:38:16 +0100, Fabio Valentini wrote:
> On Wed, Feb 19, 2020 at 4:08 AM Richard Shaw  wrote:
> >
> > This isn't the first time that this has happened but I have pushed multiple 
> > builds in one bodhi update through the web interface and:
> >
> > 1. It takes forever
> > 2. Only one (or some) updates are created, others are dropped
> >
> > What gives? It's a PITA to create the same update again...
> 
> I've been seeing similar issues, but I couldn't figure out a way to
> reproduce them. Often, creating the first update works fine, but
> subsequent update creation requests spin forever.
> Most of the time, the "Submit" button when creating a new update just
> spins forever, but checking in another window, the update indeed is
> already created. Or sometimes, editing an update text body doesn't
> take effect when clicking "Save" ...
> Since this "endless hang but mostly succeed anyway" also happens when
> creating updates from the bodhi CLI / REST API, I assume this is not a
> frontend issue, but a backend issue ...


I think I saw the same issue and had filed it:
https://pagure.io/fedora-infrastructure/issue/8603

Now upstream at:
https://github.com/fedora-infra/bodhi/issues/3918

-- 
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: Bodhi weirdness

[Fabio Valentini]

On Wed, Feb 19, 2020 at 4:08 AM Richard Shaw  wrote:
>
> This isn't the first time that this has happened but I have pushed multiple 
> builds in one bodhi update through the web interface and:
>
> 1. It takes forever
> 2. Only one (or some) updates are created, others are dropped
>
> What gives? It's a PITA to create the same update again...

I've been seeing similar issues, but I couldn't figure out a way to
reproduce them. Often, creating the first update works fine, but
subsequent update creation requests spin forever.
Most of the time, the "Submit" button when creating a new update just
spins forever, but checking in another window, the update indeed is
already created. Or sometimes, editing an update text body doesn't
take effect when clicking "Save" ...
Since this "endless hang but mostly succeed anyway" also happens when
creating updates from the bodhi CLI / REST API, I assume this is not a
frontend issue, but a backend issue ...

Fabio

> 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Announcement: EPEL Steering Committee Changes

[Leigh Griffin]

On Tue, Feb 18, 2020 at 5:36 PM Stephen John Smoogen 
wrote:

> Hi,
>
> It has been a pleasure for me to be a part of and help lead the
> EPEL steering committee for the last couple of years. It has not
> always been smooth sailing but I have found it an enjoyable experience.
>

Thank you for your passion, drive and commitment to making this such a
success for our Communities.

>
> However, as you may know the Fedora project will be moving to a
> different data-center later this spring (from Phoenix to northern
> Virginia). Being involved in the planning and implementation of this
> project, I do not think that I will be able to give EPEL the time
> investment it deserve for the next 6 to 9 months. With EPEL-8 still
> ramping up and the various opportunities with modularity, I do
> not think it is a fair that EPEL suffers from this lack of time.
>
> As such, I would like to step down as chair/member of the steering
> committee and nominate Troy Dawson as my replacement. Troy formerly
> worked on Scientific Linux and has worked on OpenShift and other
> projects at Red Hat for the last several years.  It is clear he has a
> good eye on the concerns and problems enterprise users have. Recently,
> Troy helped get the initial RHEL-8 and EPEL-8 out the door with
> multiple builds and updates to various macro files.
>

Troy has great experience in this area and more importantly shares the
passion and drive that Smooge has always shown for this. I think he is a
great choice.

>
> Once the move is completed and the close down of the old site is done,
> I look forward to getting involved again in EPEL.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford 

Communications House

Cork Road, Waterford City

lgrif...@redhat.com
M: +353877545162 IM: lgriffin
@redhatjobs    redhatjobs
 @redhatjobs


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

[rpms/perl-Net-SSLeay] PR #1: Spec file cleanups: Use make_build and make_install macros

[Paul Howarth]

pghmcfc commented on the pull-request: `Spec file cleanups: Use make_build and 
make_install macros` that you are following:
``
If you fix the comment I'll merge the PR.
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Net-SSLeay/pull-request/1
___
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-Rawhide-20200219.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Compose FAILS proposed Rawhide gating check!
24 of 43 required tests failed, 17 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

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

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

ID: 523331  Test: x86_64 Server-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/523331
ID: 523332  Test: x86_64 Server-boot-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/523332
ID: 52  Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.fedoraproject.org/tests/52
ID: 523334  Test: x86_64 Server-dvd-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/523334
ID: 523335  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/523335
ID: 523339  Test: x86_64 Server-dvd-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/523339
ID: 523344  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/523344
ID: 523345  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/523345
ID: 523346  Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation
URL: https://openqa.fedoraproject.org/tests/523346
ID: 523347  Test: x86_64 Server-dvd-iso install_vnc_server
URL: https://openqa.fedoraproject.org/tests/523347
ID: 523348  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/523348
ID: 523356  Test: x86_64 Server-dvd-iso install_repository_hd_variation
URL: https://openqa.fedoraproject.org/tests/523356
ID: 523361  Test: x86_64 Server-dvd-iso install_vncconnect_server
URL: https://openqa.fedoraproject.org/tests/523361
ID: 523364  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/523364
ID: 523371  Test: x86_64 Everything-boot-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/523371
ID: 523372  Test: x86_64 Everything-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/523372
ID: 523373  Test: x86_64 Workstation-live-iso install_default@uefi 
**GATING**
URL: https://openqa.fedoraproject.org/tests/523373
ID: 523375  Test: x86_64 Workstation-live-iso install_default_upload 
**GATING**
URL: https://openqa.fedoraproject.org/tests/523375
ID: 523390  Test: x86_64 KDE-live-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/523390
ID: 523395  Test: x86_64 KDE-live-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/523395
ID: 523399  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/523399
ID: 523401  Test: x86_64 KDE-live-iso install_no_user **GATING**
URL: https://openqa.fedoraproject.org/tests/523401
ID: 523408  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/523408
ID: 523411  Test: x86_64 universal install_multi **GATING**
URL: https://openqa.fedoraproject.org/tests/523411
ID: 523412  Test: x86_64 universal install_repository_http_graphical 
**GATING**
URL: https://openqa.fedoraproject.org/tests/523412
ID: 523413  Test: x86_64 universal install_blivet_xfs
URL: https://openqa.fedoraproject.org/tests/523413
ID: 523414  Test: x86_64 universal install_kickstart_firewall_configured 
**GATING**
URL: https://openqa.fedoraproject.org/tests/523414
ID: 523415  Test: x86_64 universal install_xfs
URL: https://openqa.fedoraproject.org/tests/523415
ID: 523416  Test: x86_64 universal install_repository_http_variation 
**GATING**
URL: https://openqa.fedoraproject.org/tests/523416
ID: 523417  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/523417
ID: 523418  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/523418
ID: 523419  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/523419
ID: 523422  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/523422
ID: 523423  Test: x86_64 universal install_multi@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/523423
ID: 523424  Test: x86_64 universal install_no_swap@uefi
URL: https://openqa.fedoraproject.org/tests/523424
ID: 523425  Test: x86_64 universal install_blivet_no_swap
URL: https://openqa.fedoraproject.org/tests/523425
ID: 523426  Test: x86_64 universal install_updates_img_local
URL: https://openqa.fedoraproject.org/tests/523426
ID: 523427  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/523427
ID: 523428  Test: x86_64 

Fedora-Cloud-31-20200219.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 1/1 (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: Announcement: EPEL Steering Committee Changes

[Peter Robinson]

> > It has been a pleasure for me to be a part of and help lead the
> > EPEL steering committee for the last couple of years. It has not
> > always been smooth sailing but I have found it an enjoyable experience.
> >
> > However, as you may know the Fedora project will be moving to a
> > different data-center later this spring (from Phoenix to northern
> > Virginia). Being involved in the planning and implementation of this
> > project, I do not think that I will be able to give EPEL the time
> > investment it deserve for the next 6 to 9 months. With EPEL-8 still
> > ramping up and the various opportunities with modularity, I do
> > not think it is a fair that EPEL suffers from this lack of time.
> >
> > As such, I would like to step down as chair/member of the steering
> > committee and nominate Troy Dawson as my replacement. Troy formerly
> > worked on Scientific Linux and has worked on OpenShift and other
> > projects at Red Hat for the last several years.  It is clear he has a
> > good eye on the concerns and problems enterprise users have. Recently,
> > Troy helped get the initial RHEL-8 and EPEL-8 out the door with
> > multiple builds and updates to various macro files.
> >
> > Once the move is completed and the close down of the old site is done,
> > I look forward to getting involved again in EPEL.
>
> Based on this, I'm not so sure that Troy is the best person to take that place
> within EPEL's Steering Committee. As an enterprise admin, RHEL8 has been
> nothing but a nightmare to deal with because of Modularity. I know Troy didn't
> singlehandedly sign off on that nonsense, but, as he is a member of the
> Modularity team, this is not a good sign for what's to come.

I disagree, opinions of the state of modularity should not have
anything to do with the decision of someone leading a steering
committee. The technical solution to a problem which is completely off
topic and out of control of this group is a completely different role
to leading a group. For the later I feel Troy is an excellent choice.

As for the former it's the job of the whole steering committee, not an
individual, to decide the direction of something like EPEL and how to
make it work/interact with modularity but having someone that knows
something like what modularity involves can only help make the RHEL
modularity team aware of the issues that an important project, such as
EPEL, is having with it in order to improve it for the community can
not be overstated.

While it's perfectly within your right to make statements like this
doing so without suggesting a suitable alternative I feel is
inappropriate. It's all too easy to throw stones from the fence. If
you feel so strongly about it maybe you could step up to work on the
steering committee to ensure that EPEL-8 is a success in spite of
modularity. I'm sure there's more than enough room for both of you and
I'm sure Troy would welcome the extra people!

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

Re: Preparing for OpenVPN 3 package review

[Tom Hughes]

On 19/02/2020 07:05, Vitaly Zaitsev via devel wrote:

On 18.02.2020 22:29, David Sommerseth wrote:

We released the OpenVPN 3 Linux v8 beta release early last week [0], with the
Fedora Copr repository [1] updated as well.  Now things are working so well it
is about time to get this package into the mainline Fedora repositories.


Fedora already has OpenVPN package, so you cannot add another one,
because when version 3.0 will be released by upstream, Fedora's package
will be updated and it will cause package conflict, which is strictly
forbidden by Fedora guidelines.


That's certainly how things typically works, but it's certainly
not the only one - see python3 for example.

In this case I believe that although the client is intended to be
protocol compatible with openvpn 2 it's basically an entirely new
program with a totally different architecture and user interface
so parallel packaging seems reasonable.

In addition I think that this is only the client, so the existing
package will still be needed for server usage for now. I'm not
totally sure about that though as the package is a little confusing
on that front - it calls itself a client but also has a -client
subpackage.

Tom

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