Re: Preparing for OpenVPN 3 package review

[Alexander Ploumistos]

On Wed, Feb 19, 2020 at 8:05 AM 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.

David is both an upstream developer and the package maintainer in 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

Re: Announcement: EPEL Steering Committee Changes

[Nico Kadel-Garcia]

On Wed, Feb 19, 2020 at 1:01 AM 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.

I also dislike modularity: it's costing me time and money resolving
mismatched dependencies for components I use that pull dependencies
that are both base packages and modularity published. Fedora seems to
have stepped back from their early enthusiasm as the difficulties
become more clear. But if he's got the skills and is willing to do the
work, Someone at EPEL needs to be comfortable enough with modularity
to resolve the overlaps with RHEL 8/CentOS 8 built-in modularity.
___
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

[Vitaly Zaitsev via devel]

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.

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

Re: Announcement: EPEL Steering Committee Changes

[Igor Gnatenko]

Then who is the best person?

On Wed, Feb 19, 2020, 07:11 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.
>
> --
> John M. Harris, Jr.___
> 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

[John M. Harris Jr]

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.

-- 
John M. Harris, Jr.

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

Re: URGENT: users prompted to upgrade to F32

[Ken Dreyer]

On Mon, Feb 17, 2020 at 10:52 AM Adam Williamson
 wrote:

> Since this is an API endpoint of a real system which needs to be
> updated correctly when the release events actually happen, it should
> have the benefits pkgdb used to be (the information should be reliable
> and timely)

Do we have stats on how many hits per second that current endpoint receives?

It would be a bummer to inadvertently bring down Bodhi because of this feature.

What do you think about having Bodhi write out a flat file to disk or
something for Apache to serve in a similar way, so it doesn't have to
go through mod_wsgi or touch the database for that URL?

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

[389-devel] 389 DS nightly 2020-02-19 - 96% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2020/02/19/report-389-ds-base-1.4.3.3-20200219gitd98699a.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

Bodhi weirdness

[Richard Shaw]

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

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

Re: s390x builder problem? disk full, or ?

[Kevin Fenzi]

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

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: Koji build gets consistently stuck

[Jerry James]

On Tue, Feb 18, 2020 at 5:40 PM Kevin Fenzi  wrote:
> I wonder if it's some kind of loop in qt5 headers?
>
> So, I'd say try and duplicate it in a i686 mock chroot on a x86_64
> machine and see if you can gather enough info for a c++ or qt5 bug.

Meanwhile, I've got an mscore build running
(https://koji.fedoraproject.org/koji/buildinfo?buildID=1463853) that
normally takes about 25 minutes, but has been going on i386 for over 8
hours now.  It also is a Qt application.  However, when I try the
build in mock, what I'm seeing is 4 g++ invocations, with 4
/usr/bin/as invocations as subprocesses, and it is the assembler that
doesn't seem to be finishing.  I filed a binutils bug about that:

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

but maybe I didn't dig deep enough.  If I can scrape together a little
time tonight, I will try to debug it a bit more.
-- 
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

[Bug 1804004] perl-PerlIO-Layers-0.012 is available

[bugzilla]

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



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

-- 
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: Packages for Fedora Jam

[Erich Eickmeyer]

Hi Elliott,

On Tuesday, February 18, 2020 5:48:21 PM PST Elliott Sales de Andrade wrote:
> Hi Erich,
> 
> On Tue, 18 Feb 2020 at 12:10, Erich Eickmeyer 
> wrote:
> > I have filed bugzilla reports for each one and blocked FE-NEEDSPONSOR for
> > each
 one. I'd like to get these sponsored as soon as possible.
> >
> >
> 
> 
> To clarify, it is not the packages that need to be sponsored, it is *you*.
> https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Get_S
> ponsored

Thank you so much for that clarification. Still relatively new to this, in 
Ubuntu it's the packages that get sponsored, not the person. So, it's just a 
bit of a change of a change in mentality when it comes to sponsorship. :) 

Erich


___
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: Koji build gets consistently stuck

[Orcan Ogetbil]

On Tue, 18 Feb 2020 at 19:40, Kevin Fenzi wrote:
>
> So, I'd say try and duplicate it in a i686 mock chroot on a x86_64
> machine and see if you can gather enough info for a c++ or qt5 bug.
>
> Hope that helps.

Thanks Kevin,
Strangely, as I was attempting to try out what you suggested I got a
"build complete" notification email. I took a glance at the logs to
find a possible clue of what happened and I found the following in
build.log:
---
[100%] Built target muse
< 20 hour break (this line is not in the log) >
In file included from /usr/include/string.h:495,
 from /usr/include/qt5/QtCore/qarraydata.h:44,
 from /usr/include/qt5/QtCore/qbytearray.h:46,
 from /usr/include/qt5/QtCore/qstring.h:49,
 from /usr/include/qt5/QtCore/qdir.h:43,
 from /usr/include/qt5/QtCore/QDir:1,
 from
/builddir/build/BUILD/muse-3.0.2/synti/deicsonze/deicsonzegui.cpp:30:
In function 'char* strncpy(char*, const char*, size_t)',
inlined from 'void DeicsOnzeGui::setInitSetPath(const QString&)'
at /builddir/build/BUILD/muse-3.0.2/synti/deicsonze/deicsonzegui.cpp:2522:10:
/usr/include/bits/string_fortified.h:106:34: warning: 'char*
__builtin_strncpy(char*, const char*, unsigned int)' specified bound
256 equals destination size [-Wstringop-truncation]
  106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
  |  ^~
---
Seems to me like a valid warning, however it doesn't explain the delay.

Another interesting observation that I forgot to add to the original
post was, the scratch build in koji went through fine before I tried
the actual build.

Maybe your magic touch helped? :)

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

[Bug 1796331] perl-Sereal-Encoder-4.008 is available

[bugzilla]

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



--- Comment #18 from Fedora Update System  ---
perl-Sereal-4.009-1.el8, perl-Sereal-Decoder-4.009-1.el8,
perl-Sereal-Encoder-4.009-1.el8 has been pushed to the Fedora EPEL 8 stable
repository. If problems still persist, please make note of it in this bug
report.

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

[Bug 1796979] perl-Sereal-4.009 is available

[bugzilla]

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



--- Comment #9 from Fedora Update System  ---
perl-Sereal-4.009-1.el8, perl-Sereal-Decoder-4.009-1.el8,
perl-Sereal-Encoder-4.009-1.el8 has been pushed to the Fedora EPEL 8 stable
repository. If problems still persist, please make note of it in this bug
report.

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

[Bug 1796332] perl-Sereal-Decoder-4.008 is available

[bugzilla]

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



--- Comment #18 from Fedora Update System  ---
perl-Sereal-4.009-1.el8, perl-Sereal-Decoder-4.009-1.el8,
perl-Sereal-Encoder-4.009-1.el8 has been pushed to the Fedora EPEL 8 stable
repository. If problems still persist, please make note of it in this bug
report.

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

[Bug 1796330] perl-Sereal-4.008 is available

[bugzilla]

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



--- Comment #15 from Fedora Update System  ---
perl-Sereal-4.009-1.el8, perl-Sereal-Decoder-4.009-1.el8,
perl-Sereal-Encoder-4.009-1.el8 has been pushed to the Fedora EPEL 8 stable
repository. If problems still persist, please make note of it in this bug
report.

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

[Bug 1796978] perl-Sereal-Encoder-4.009 is available

[bugzilla]

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



--- Comment #9 from Fedora Update System  ---
perl-Sereal-4.009-1.el8, perl-Sereal-Decoder-4.009-1.el8,
perl-Sereal-Encoder-4.009-1.el8 has been pushed to the Fedora EPEL 8 stable
repository. If problems still persist, please make note of it in this bug
report.

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

[Bug 1796977] perl-Sereal-Decoder-4.009 is available

[bugzilla]

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



--- Comment #9 from Fedora Update System  ---
perl-Sereal-4.009-1.el8, perl-Sereal-Decoder-4.009-1.el8,
perl-Sereal-Encoder-4.009-1.el8 has been pushed to the Fedora EPEL 8 stable
repository. If problems still persist, please make note of it in this bug
report.

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

Re: Packages for Fedora Jam

[Elliott Sales de Andrade]

Hi Erich,

On Tue, 18 Feb 2020 at 12:10, Erich Eickmeyer  wrote:
> I have filed bugzilla reports for each one and blocked FE-NEEDSPONSOR for each
> one. I'd like to get these sponsored as soon as possible.
>

To clarify, it is not the packages that need to be sponsored, it is *you*.
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Get_Sponsored

> I'd appreciate your help!
> Erich
> 
> Erich Eickmeyer
> Fedora Jam
> Ubuntu Studio
>

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

[Bug 1804004] perl-PerlIO-Layers-0.012 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
perl-PerlIO-Layers-0.012-1.fc30 has been pushed to the Fedora 30 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-9870bec3a8

-- 
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: s390x builder problem? disk full, or ?

[Kevin Fenzi]

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. 

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: Koji build gets consistently stuck

[Kevin Fenzi]

On Tue, Feb 18, 2020 at 06:46:05PM -0500, Orcan Ogetbil wrote:
> In an effort to update the fluidsynth library version, which comes
> with a soname bump, in rawhide (F33) I created a side tag
> f33-build-side-19396. All but one dependent packages are rebuilt. The
> last dependent is the muse package.
> 
> I tried to rebuild muse in the side tag three times. In all of the
> attempts the i686 target build gets stalled at the end of %build. Here
> is the latest build, which still ongoing for 18 hours as I'm writing
> this email:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=41579850
> As a comparison, the slowest builder (s390x) finishes the build in
> about 15 minutes.
> 
> How do I debug this? Where to file a ticket?

Well, if you just want info on what the builder is stuck on, an
infrastructure ticket. 

Since I am already here:

It seems to be using 100% of 1 cpu running: 

kojibui+ 3203495 99.3  2.4 388244 372724 ?   RFeb18 1127:51 
/usr/libexec/gcc/i686-redhat-linux/10/cc1plus -quiet -I
/builddir/build/BUILD/muse-3.0.2/i686-redhat-linux-gnu/synti/deicsonze

  |   `-rpmbuild,3201583 -bb --target i686 --nodeps 
/builddir/build/SPECS/muse.spec
  |   `-sh,3201611 -e /var/tmp/rpm-tmp.cEJyaS
  |   `-make,3201975 -j6
  |   `-make,3201978 -f CMakeFiles/Makefile2 all
  |   `-make,3203442 -f 
synti/deicsonze/CMakeFiles/deicsonze.dir/build.make ...
  |   `-c++,3203494 -DQT_CORE_LIB -DQT_GUI_LIB 
-DQT_NO_DEBUG -DQT_SVG_LIB -DQT_UITOOLS_LIB ..
.
  |   |-cc1plus,3203495 -quiet -I ...
  |   `-as,3203496 -I 
/builddir/build/BUILD/muse-3.0.2/i686-redhat-linux-gnu/synti/deicso
nze -I ...

strace of that process doesn't show anything happening. 

Looking at open files: 

...
lr-x--. 1 kojibuilder mock 64 Feb 19 00:37 11 -> 
/var/lib/mock/f33-build-side-19396-19429711-1367041/root/usr/include
/c++/10/bits/std_function.h
lr-x--. 1 kojibuilder mock 64 Feb 19 00:37 12 -> 
/var/lib/mock/f33-build-side-19396-19429711-1367041/root/usr/include
/qt5/QtCore/qmap.h
lr-x--. 1 kojibuilder mock 64 Feb 19 00:37 13 -> 
/var/lib/mock/f33-build-side-19396-19429711-1367041/root/usr/include
/qt5/QtCore/qvariant.h
lr-x--. 1 kojibuilder mock 64 Feb 19 00:37 14 -> 
/var/lib/mock/f33-build-side-19396-19429711-1367041/root/usr/include
/qt5/QtCore/qset.h
lr-x--. 1 kojibuilder mock 64 Feb 19 00:37 15 -> 
/var/lib/mock/f33-build-side-19396-19429711-1367041/root/builddir/bu
ild/BUILD/muse-3.0.2/muse/memory.h
lr-x--. 1 kojibuilder mock 64 Feb 19 00:37 16 -> 
/var/lib/mock/f33-build-side-19396-19429711-1367041/root/builddir/bu
ild/BUILD/muse-3.0.2/muse/evdata.h
lr-x--. 1 kojibuilder mock 64 Feb 19 00:37 17 -> 
/var/lib/mock/f33-build-side-19396-19429711-1367041/root/builddir/bu
ild/BUILD/muse-3.0.2/muse/mpevent.h
lr-x--. 1 kojibuilder mock 64 Feb 19 00:37 18 -> 
/var/lib/mock/f33-build-side-19396-19429711-1367041/root/builddir/bu
ild/BUILD/muse-3.0.2/synti/libsimpleplugin/simpler_plugin.h
lr-x--. 1 kojibuilder mock 64 Feb 19 00:37 19 -> 
/var/lib/mock/f33-build-side-19396-19429711-1367041/root/usr/include
/qt5/QtWidgets/qstyleoption.h
lr-x--. 1 kojibuilder mock 64 Feb 19 00:37 20 -> 
/var/lib/mock/f33-build-side-19396-19429711-1367041/root/usr/include
/qt5/QtGui/qtextformat.h

I wonder if it's some kind of loop in qt5 headers?

So, I'd say try and duplicate it in a i686 mock chroot on a x86_64
machine and see if you can gather enough info for a c++ or qt5 bug.

Hope that helps.

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

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

[Kevin Fenzi]

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


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

Koji build gets consistently stuck

[Orcan Ogetbil]

In an effort to update the fluidsynth library version, which comes
with a soname bump, in rawhide (F33) I created a side tag
f33-build-side-19396. All but one dependent packages are rebuilt. The
last dependent is the muse package.

I tried to rebuild muse in the side tag three times. In all of the
attempts the i686 target build gets stalled at the end of %build. Here
is the latest build, which still ongoing for 18 hours as I'm writing
this email:
https://koji.fedoraproject.org/koji/taskinfo?taskID=41579850
As a comparison, the slowest builder (s390x) finishes the build in
about 15 minutes.

How do I debug this? Where to file a ticket?

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

Re: How to deal with large number of bugs related to the, "multiple definition of..." issue

[Björn Persson]

Ronaldo Mercado wrote:
>One way I have seen this solved is to have a #define, say '#define MAIN'
>
>On the header file "header.h" you would have a declaration and a definition 
>only if MAIN is defined, e.g.
>
>extern int y;  /* declaration */
>#ifdef MAIN
>int y;  /* definition */
>#endif
>
>Most c files would include "header.h" and main.c would do this instead
>
>#define MAIN
>#include "header.h"

After preprocessing that is exactly the same as this:

header.h:
extern int y;

main.c:
#include "header.h"
int y;

So just do that instead.

Björn Persson


pgp4rdh5xchOV.pgp
Description: OpenPGP digital signatur
___
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

Preparing for OpenVPN 3 package review

[David Sommerseth]

Hi,

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.

I'm fairly rusty on the Fedora packaging, but I have opened a discussion on
the Fedora security ML related to an rpmlint complaint (which I believe is
more or less a false-positive, from a Fedora perspective).  But if someone got
some time to help out doing some initial review, I would appreciate it.

Everything used for the Fedora Copr builds are available here:


If there are any questions, I'm always available on IRC (dazo) or on e-mail. I
will also file the official package review bugzilla once we've sorted out the
worst glaring issues.


[0]

[1] 


-- 
kind regards,

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

Re: Another take on RStudio (review swaps?)

[Iñaki Ucar]

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

s390x builder problem? disk full, or ?

[Kaleb Keithley]

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

--

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

Re: mock build failures for f32/33

[Michael Cronenworth]

On 2/18/20 1:00 PM, Stephen John Smoogen wrote:

The mock in f30 updates-testing mock-2.0-2.fc30.noarch fixed it for me
and I was able to build packages for f32 and rawhide locally.


Ugh. The maintainer used a custom update name and that threw me off. First time I've 
seen that used.

___
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: mock build failures for f32/33

[Stephen John Smoogen]

On Tue, 18 Feb 2020 at 13:55, Michael Cronenworth  wrote:
>
> On 2/18/20 8:49 AM, Till Hofmann wrote:
> > On 2/18/20 3:44 PM, Richard Shaw wrote:
> >> I am unable to build packages using mock for either f32 or f33 which is
> >> very problematic.
> > Afaik you need mock from updates-testing for the new config/keys.
>
> No one has pushed out an update for them besides Rawhide.
>
> We need one pushed.

The mock in f30 updates-testing mock-2.0-2.fc30.noarch fixed it for me
and I was able to build packages for f32 and rawhide locally.





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

Re: mock build failures for f32/33

[Michael Cronenworth]

On 2/18/20 8:49 AM, Till Hofmann wrote:

On 2/18/20 3:44 PM, Richard Shaw wrote:

I am unable to build packages using mock for either f32 or f33 which is
very problematic.

Afaik you need mock from updates-testing for the new config/keys.


No one has pushed out an update for them besides Rawhide.

We need one pushed.
___
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

[Troy Dawson]

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.

Troy
___
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: Leonardo Rossetti

[Leonardo Rossetti]

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

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

Regards,
-- 

Leonardo Rossetti

Senior Software Engineer,

Red Hat 

lross...@redhat.com
M: +55-11-99703-0621

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

[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Co

[smooge]

Dear all,

You are kindly invited to the meeting:
   EPEL Steering Co on 2020-02-19 from 18:00:00 to 19:00:00 GMT
   At freenode@fedora-meeting

The meeting will be about:
This is the weekly EPEL Steering Committee Meeting. A general agenda is the 
following:

#meetingname EPEL
#topic Intros
#topic Old Business
#topic EPEL-6
#topic EPEL-7
#topic EPEL-8
#topic Openfloor
#endmeeting




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

___
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

[EPEL-devel] Announcement: EPEL Steering Committee Changes

[Stephen John Smoogen]

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

Announcement: EPEL Steering Committee Changes

[Stephen John Smoogen]

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

Packages for Fedora Jam

[Erich Eickmeyer]

Hello everyone!

In my efforts to bring over tools from Ubuntu Studio that we've been using, I 
noticed we were missing some dependencies of studio-controls. With that in 
mind, I have packaged said dependencies (one of which was in UnitedRPMs that I 
simply took the .spec from and gave it some Fedora standardization).

https://bugzilla.redhat.com/show_bug.cgi?id=1803945 (zita-ajbridge, allows 
ALSA devices to become JACK clients)
https://bugzilla.redhat.com/show_bug.cgi?id=1804307 (python3-jack-client, a 
JACK client library for Python3)

Additionally, and to get familiar with Fedora's packaging, I did this one 
first:

https://bugzilla.redhat.com/show_bug.cgi?id=1801352 (raysession, an audio 
application session manager, replaces Non Session Manager and LADISH for 
functionality)

I have filed bugzilla reports for each one and blocked FE-NEEDSPONSOR for each 
one. I'd like to get these sponsored as soon as possible.

I'd appreciate your help!
Erich

Erich Eickmeyer
Fedora Jam
Ubuntu Studio

___
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 1804031] perl-Package-New-0.09 is available

[bugzilla]

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

Tom "spot" Callaway  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
Last Closed||2020-02-18 16:51:21



--- Comment #3 from Tom "spot" Callaway  ---
0.09 in F32 and rawhide.

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

gcc10 issues with yubihms-shell

[Jakub Jelen]

Hello Fedora devel, Jakub,

with gcc10 landing in Fedora rawhide, we got a new failures of build of
above package [1].

The code looks reasonable, we have a possible workaround, but before
implementing that in upstream and downstream, I would like to check
whether it is really something to fix in the our code or a bug in gcc
error checking (see the upstream issue).

Did anyone see similar issue with their packages? Any comments? Ideas?

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1800289
[2] https://github.com/Yubico/yubihsm-shell/issues/71

Regards,
-- 
Jakub Jelen
Senior Software Engineer
Security Technologies
Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Intent to Orphan/Retire dspam

[Nathanael D. Noblet]

Hello,

  Years ago I was managing mail servers and really liked dspam's
accuracy and resource consumption so added it to fedora and maintained
it. Sadly shortly after adding it upstream went through a number of
ownership changes and nothing has been added to it in years. I no
longer use it, upstream is essentially dead and it is now FTBS in F32.

  I'm planning on orphaning it unless someone wants it.

Sincerely,
-- 
Nathanael
___
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

[Petr Pisar]

On Thu, Feb 13, 2020 at 07:54:24AM -0500, Matthew Miller wrote:
> I've been saying this for a while as if it's fact, but of course it's not
> actually fact until approved, so I'm puting this to the EPEL team to
> hopefully do so.
> 
> The current guidelines * say:
> 
>EPEL packages should only enhance and never disturb the Enterprise Linux
>distributions they were built for. Thus packages from EPEL should never
>replace packages from the target base distribution - including those on the
>base distribution as well as layered products; kernel-modules further are
>not allowed, as they can disturb the base kernel easily.
> 
> With modularity in EPEL 8, we have the opportunity to allow more flexibility
> while preserving the primary goal of not disturbing the base distribution.
> Therefore, I propose adding:
> 
>   In EPEL 8 or later, it is permitted to have module streams which contain
>   packages with alternate versions to those provided in RHEL. These packages
>   may be newer, built with different options, or even older to serve
>   compatibility needs. These MUST NOT be the default stream -- in every
>   case, explicit user action must be required to opt in to these versions.
> 
> 
> (Note that the base package _does not_ have to be part of a module for this
> to work.)
> 
> What do you think?
> 
> 
Nicely and clearly stated.

-- Petr


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

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

[Petr Pisar]

On Sat, Feb 15, 2020 at 07:15:55PM -0700, Ken Dreyer wrote:
> On Thu, Feb 13, 2020 at 5:54 AM Matthew Miller  
> wrote:
> >
> >   In EPEL 8 or later, it is permitted to have module streams which contain
> >   packages with alternate versions to those provided in RHEL. These packages
> >   may be newer, built with different options, or even older to serve
> >   compatibility needs. These MUST NOT be the default stream -- in every
> >   case, explicit user action must be required to opt in to these versions.
> 
> Is there any chance that a module in EPEL 8 will be named identically
> to a module in RHEL 8? If that happens, what is the process to choose
> between RHEL's module and EPEL's module?
> 
> This is not entirely hypothetical :) We face this situation if we
> consider putting Ceph into a module in RHEL 8 and a module in EPEL 8.
> 
This was discussed in fall last year without any conclusion. There was
a proposal force all EPEL streams having a prefix (e.g "epel-") to prevent
from clashes.

In my opinion the situation with same named streams is similar to situation
with same named packages. If RHEL is going to add new package that already
exists in EPEL, RHEL uses an higher NEVRA of the package and EPEL will remove
the package later. You can do the same with module streams.

Module streams also have versions. The version is based on a RHEL version and
a time when the module was built. That itself ensures incrasing stream
versions. But that's not enough to ensure an upgrade path on package level.

The reason is that if a stream is enabled, all of its versions that exist in
the repositories are inspected and all of their packages are made available. 
That
means that if a RHEL repository contains multiple versions of a stream, then
DNF will see all the historical packages. That would apply to EPEL
repositories too.

A solution is that RHEL will ensurure that each package of the stream will
have an higher NEVRA than the EPEL one. See it's the same as with non-modular
packages. The only difference is that you need account more packages than the
usual one.

The only remaining issue is what to do with packages that existed in EPEL
repository but were not added into RHEL repository. Well, technically it does
not matter that there is an old package.

When it would matter is when RHEL decided to add the package as non-modular
one and at the same time the RHEL stream would be a default one. Then DNF
would prefer the old modular package because the stream is default now. EPEL
could solve it by removing the old module from its repositories. But what if
the the user had already have the package from EPEL stream installed. In that
case, I believe, I'm not sure how exactly DNF implements it, DNF would kept
considering the package as modular because DNF cashes modular metadata of
installed packages for the case when a repository becomes unavailable.

A long term solution is DNF to support obsoleting modular packages by
non-modular packages or handling end-of-life streams better. As far as I know
this has not yet been designed, neither implemented.

So the bottom line is: Prefixed streams should provide a bullet proof
mitigation. Until DNF gains the ability to obsolete a stream, there will be
slight risk of creeping out-dated EPEL content into the installation.

-- Petr


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

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

[Petr Pisar]

On Sat, Feb 15, 2020 at 05:15:56PM -0500, Matthew Miller wrote:
> On Fri, Feb 14, 2020 at 05:14:31PM -0600, Chris Adams wrote:
> > Unless... does RHEL have modules that replace base packages?  I admit, I
> > haven't fully got my head wrapped around all the effects of modularity.
> 
> I'm not sure if RHEL has any such modules, but it is functionally possible.
>   
There is a perl-DBI module that provides a perl-DBI package that replaces
a base perl-DBI package. There are more modules like that.

It's an alternative approach to the stub streams discussed in this thread.

-- Petr


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

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

[Stephen John Smoogen]

On Tue, 18 Feb 2020 at 10:34, Petr Pisar  wrote:

> On Sat, Feb 15, 2020 at 05:12:29PM -0500, Matthew Miller wrote:
> > On Sat, Feb 15, 2020 at 11:27:46AM -0500, Stephen John Smoogen wrote:
> > > From my also little understanding of modularity, this is so you can
> > > reinstall base perl packages. In some ways ( I am glossing over things
> > > here), modular rpms always beat bare rpms because a module can put in
> rules
> > > to say 'you can install this package but it does not work with these
> rpms
> > > so they need to be removed'. So I think any modules we write which
> would
> > > over-ride non-modular packages, we would also need to write a 'get me
> back
> > > my f'ing defaults' module which stubs in a similar way the perl and
> some
> > > other modules do.
> >
> > No, this is not the case. If the module isn't enabled its packages will
> just
> > be ignored. It's only if you enable the module that you get the RPMs from
> > that module.
> >
> Exactly. If you want to revert back to a non-modular package, just reset
> the module
> (e.g. "dnf module --reset perl"). That will disappear modular packages from
> from the repository and make the non-modular packages available again.
>
> Here is a simple explanation what enabling a module stream means: If you
> enable a module stream ("dnf module --enable perl:5.24"), DNF obtains a
> list
> of binary packages belonging to that stream (e.g. perl-interpreter-5.24.4),
> makes them available (to dnf install, repoquery etc.) and at the same time
> makes the same-named packages (either non-modular or from a different
> stream
> of the same module) unavailable (e.g. perl-interpreter-5.26.3 disappears).
> When you reset the module, you effectively reverts it. This process of
> making
> the packages avaiable/unavailable DNF calles a modular filtering.
>
> The purpose of the stub (without packages) perl:5.26 stream is different
> and
> mostly unrelated . It is there to enable having modules above the perl
> module
> in an easy way. Otherwise the layered module maintainers would have take
> care
> whether they target Perl 5.26 that is non modular or Perl 5.24 that is
> modular. The dummy perl:5.26 stream provides a unified modular interface to
> other modules.
>
>
OK I was clearly confused and not correctly remembering why you had said
perl:5.26 was there. I apologize for the misinformation here.



> EPEL packagers that want to provide an alternative stream to non-modular
> packages are not required to provide the dummy streams. Although the dummy
> streams can become handy later for the very same reason. The dummy streams
> can
> added later when needed and when found useful.
>
> -- Petr
> ___
> 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
>


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

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

[Petr Pisar]

On Sat, Feb 15, 2020 at 05:12:29PM -0500, Matthew Miller wrote:
> On Sat, Feb 15, 2020 at 11:27:46AM -0500, Stephen John Smoogen wrote:
> > From my also little understanding of modularity, this is so you can
> > reinstall base perl packages. In some ways ( I am glossing over things
> > here), modular rpms always beat bare rpms because a module can put in rules
> > to say 'you can install this package but it does not work with these rpms
> > so they need to be removed'. So I think any modules we write which would
> > over-ride non-modular packages, we would also need to write a 'get me back
> > my f'ing defaults' module which stubs in a similar way the perl and some
> > other modules do.
> 
> No, this is not the case. If the module isn't enabled its packages will just
> be ignored. It's only if you enable the module that you get the RPMs from
> that module.
> 
Exactly. If you want to revert back to a non-modular package, just reset the 
module
(e.g. "dnf module --reset perl"). That will disappear modular packages from
from the repository and make the non-modular packages available again.

Here is a simple explanation what enabling a module stream means: If you
enable a module stream ("dnf module --enable perl:5.24"), DNF obtains a list
of binary packages belonging to that stream (e.g. perl-interpreter-5.24.4),
makes them available (to dnf install, repoquery etc.) and at the same time
makes the same-named packages (either non-modular or from a different stream
of the same module) unavailable (e.g. perl-interpreter-5.26.3 disappears).
When you reset the module, you effectively reverts it. This process of making
the packages avaiable/unavailable DNF calles a modular filtering.

The purpose of the stub (without packages) perl:5.26 stream is different and
mostly unrelated . It is there to enable having modules above the perl module
in an easy way. Otherwise the layered module maintainers would have take care
whether they target Perl 5.26 that is non modular or Perl 5.24 that is
modular. The dummy perl:5.26 stream provides a unified modular interface to
other modules.

EPEL packagers that want to provide an alternative stream to non-modular
packages are not required to provide the dummy streams. Although the dummy
streams can become handy later for the very same reason. The dummy streams can
added later when needed and when found useful.

-- Petr


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

Re: Intent to retire clalsadrv

[Miro Hrončok]

On 17. 02. 20 23:47, Guido Aulisi wrote:

I'm going to retire clalsadrv, it's been deprecated upstream [0] for a
long time and it has been replaced by zita-alsa-pcmi.
Nothing depends on it in rawhide according to this query:

dnf --disablerepo='*' --enablerepo='rawhide' repoquery --whatrequires clalsadrv 
--alldep


Please, always also add --enablerepo='rawhide-source'. You can do:

  $ repoquery --repo=rawhide{,-source} --whatrequires clalsadrv --alldep

(Also nothing in this case, but might be in other cases.)

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

[Bug 1804272] New: Upgrade perl-Convert-UUlib to 1.62

[bugzilla]

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

Bug ID: 1804272
   Summary: Upgrade perl-Convert-UUlib to 1.62
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Convert-UUlib
  Assignee: redhat-bugzi...@linuxnetz.de
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
redhat-bugzi...@linuxnetz.de
  Target Milestone: ---
Classification: Fedora



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

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

[Bug 1804044] perl-Log-ger-0.029 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Log-ger-0.029-1.fc33
   ||perl-Log-ger-0.029-1.fc32
 Resolution|--- |RAWHIDE
Last Closed||2020-02-18 15:14:06



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

[Fedora compose checker]

No missing expected images.

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

New failures (same test not failed in Fedora-32-20200214.n.1):

ID: 522958  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/522958
ID: 522967  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/522967
ID: 522980  Test: x86_64 Server-dvd-iso install_vncconnect_server
URL: https://openqa.fedoraproject.org/tests/522980
ID: 522983  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/522983
ID: 523009  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/523009
ID: 523020  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/523020
ID: 523045  Test: x86_64 universal install_updates_img_local
URL: https://openqa.fedoraproject.org/tests/523045
ID: 523049  Test: x86_64 universal install_delete_pata@uefi
URL: https://openqa.fedoraproject.org/tests/523049
ID: 523054  Test: x86_64 universal install_scsi_updates_img
URL: https://openqa.fedoraproject.org/tests/523054
ID: 523055  Test: x86_64 universal install_xfs@uefi
URL: https://openqa.fedoraproject.org/tests/523055
ID: 523058  Test: x86_64 universal install_multi_empty
URL: https://openqa.fedoraproject.org/tests/523058
ID: 523061  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/523061
ID: 523071  Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/523071
ID: 523075  Test: x86_64 universal install_shrink_ntfs
URL: https://openqa.fedoraproject.org/tests/523075
ID: 523077  Test: x86_64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/523077
ID: 523082  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/523082
ID: 523088  Test: x86_64 universal install_btrfs
URL: https://openqa.fedoraproject.org/tests/523088
ID: 523091  Test: x86_64 universal install_blivet_no_swap@uefi
URL: https://openqa.fedoraproject.org/tests/523091
ID: 523093  Test: x86_64 universal install_multi_empty@uefi
URL: https://openqa.fedoraproject.org/tests/523093
ID: 523094  Test: x86_64 universal install_no_swap
URL: https://openqa.fedoraproject.org/tests/523094
ID: 523097  Test: x86_64 universal install_pxeboot
URL: https://openqa.fedoraproject.org/tests/523097
ID: 523104  Test: x86_64 universal install_kickstart_user_creation
URL: https://openqa.fedoraproject.org/tests/523104

Old failures (same test failed in Fedora-32-20200214.n.1):

ID: 522950  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/522950
ID: 522951  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/522951
ID: 522952  Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.fedoraproject.org/tests/522952
ID: 522953  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/522953
ID: 522954  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/522954
ID: 522963  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/522963
ID: 522964  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/522964
ID: 522965  Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation
URL: https://openqa.fedoraproject.org/tests/522965
ID: 522966  Test: x86_64 Server-dvd-iso install_vnc_server
URL: https://openqa.fedoraproject.org/tests/522966
ID: 522975  Test: x86_64 Server-dvd-iso install_repository_hd_variation
URL: https://openqa.fedoraproject.org/tests/522975
ID: 522990  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/522990
ID: 522991  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/522991
ID: 522992  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/522992
ID: 522993  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/522993
ID: 522994  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/522994
ID: 523014  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/523014
ID: 523018  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/523018
ID: 523027  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/523027
ID: 523030  Test: x86_64 universal install_multi
URL: https://openqa.fedoraproject.org/tests/523030
ID: 

Re: mock build failures for f32/33

[Till Hofmann]

Hi Richard,

On 2/18/20 3:44 PM, Richard Shaw wrote:
> I am unable to build packages using mock for either f32 or f33 which is
> very problematic.

Afaik you need mock from updates-testing for the new config/keys.

Kind regards,
Till
___
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

mock build failures for f32/33

[Richard Shaw]

I am unable to build packages using mock for either f32 or f33 which is
very problematic.

warning:
/var/lib/mock/fedora-rawhide-x86_64/root/var/cache/dnf/fedora-2d95c80a1fa0a67d/packages/gdb-minimal-9.1-3.fc33.x86_64.rpm:
Header V3 RSA/SHA256 Signature, key ID 9570ff31: NOKEY
fedora
1.6 MB/s | 1.6 kB 00:00
GPG key at
file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-32-primary
(0x12C944D0) is already installed
fedora
1.6 MB/s | 1.6 kB 00:00
GPG key at
file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-32-primary
(0x12C944D0) is already installed
fedora
1.6 MB/s | 1.6 kB 00:00
GPG key at
file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-31-primary
(0x3C3359C4) is already installed
The GPG keys listed for the "fedora" repository are already installed but
they are not correct for this package.
Check that the correct key URLs are configured for this repository..
Failing package is: gdb-minimal-9.1-3.fc33.x86_64
 GPG Keys are configured as:
file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-32-primary,
file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-32-primary,
file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-31-primary
Public key for pcre-8.44-1.fc33.x86_64.rpm is not installed. Failing
package is: pcre-8.44-1.fc33.x86_64
 GPG Keys are configured as:
file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-32-primary,
file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-32-primary,
file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-31-primary
Public key for redhat-rpm-config-151-1.fc33.noarch.rpm is not installed.
Failing package is: redhat-rpm-config-151-1.fc33.noarch
 GPG Keys are configured as:
file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-32-primary,
file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-32-primary,
file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-31-primary
Error: GPG check FAILED
ERROR:
Exception(/home/build/fedora-scm/forks/libax25/libax25-0.0.12-0.1.fc33.src.rpm)
Config(fedora-rawhide-x86_64) 0 minutes 6 seconds
INFO: Results and/or logs in:
/home/build/fedora-scm/forks/libax25/results_libax25/0.0.12/0.1.fc33
ERROR: Command failed:
 # /usr/bin/dnf --installroot /var/lib/mock/fedora-rawhide-x86_64/root/ -y
--releasever 32 --setopt=deltarpm=False --allowerasing
--disableplugin=local --disableplugin=spacewalk update
--setopt=tsflags=nocontexts

What's up?

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

BackupPC SELinux HELP!

[Richard Shaw]

I've got a bug report[1] I've been trying to figure out but have not been
able to figure it out.

I keep re-teaching myself SELinux every time I run into a problem but this
one is just too convoluted. For those that don't know BackupPC is perl
based (which doesn't application of selinux contexts) so I have to compile
a C wrapper, and then all of it is run through apache.

The existing selinux settings in the spec file[2] have worked well for many
years across multiple Fedora and EPEL releases until now...

So is initrc_t still appropriate? Or is there a systemd equivalent? And is
that what he's suggesting?

I tried applying his patch to the spec but it broke BackupPC on my CentOS 7
server even though it's systemD based.

I've played with creating a service domain for backuppc but not sure if I
need to go that far since everything is run through httpd...

Thanks,
Richard

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1791369
[2] https://src.fedoraproject.org/rpms/BackupPC/blob/master/f/BackupPC.spec
___
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: Who maintains the service at mbs.fedoraproject.org:443?

[Leigh Griffin]

On Mon, Feb 17, 2020 at 2:55 PM Pierre-Yves Chibon 
wrote:

> On Mon, Feb 17, 2020 at 09:44:21AM -0500, Michael McLean wrote:
> >That's the fm-orchestrator rest api. The code maintenance has
> transferred
> >from the Factory 2.0 team to the RHEL Build team (i.e. the "Koji
> team").
> >Historically, the Factory team has handled the Fedora infra
> deployments.
> >However, I think we should move towards having that work more like
> Koji
> >itself, where infra handles the infra parts.
>
> This is a discussion we may want to start sooner rather than later as it
> involves resources which are already thin.
>

Happy to have that conversation but in the short term, this is not
something we can call on and our relationship will be to run it, restart it
and ping the right people when it hits a problem.


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


-- 

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

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

[Fedora compose checker]

No missing expected images.

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

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

New failures (same test not failed in Fedora-Rawhide-20200214.n.1):

ID: 522779  Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.fedoraproject.org/tests/522779
ID: 522780  Test: x86_64 Server-dvd-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/522780
ID: 522785  Test: x86_64 Server-dvd-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/522785
ID: 522790  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/522790
ID: 522791  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/522791
ID: 522794  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/522794
ID: 522807  Test: x86_64 Server-dvd-iso install_vncconnect_server
URL: https://openqa.fedoraproject.org/tests/522807
ID: 522856  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/522856
ID: 522857  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/522857
ID: 522869  Test: x86_64 universal install_repository_http_graphical 
**GATING**
URL: https://openqa.fedoraproject.org/tests/522869
ID: 522873  Test: x86_64 universal install_repository_http_variation 
**GATING**
URL: https://openqa.fedoraproject.org/tests/522873
ID: 522882  Test: x86_64 universal install_blivet_no_swap
URL: https://openqa.fedoraproject.org/tests/522882
ID: 522886  Test: x86_64 universal install_delete_pata **GATING**
URL: https://openqa.fedoraproject.org/tests/522886
ID: 522887  Test: x86_64 universal install_delete_pata@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/522887
ID: 522891  Test: x86_64 universal install_sata@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/522891
ID: 522893  Test: x86_64 universal install_xfs@uefi
URL: https://openqa.fedoraproject.org/tests/522893
ID: 522904  Test: x86_64 universal install_blivet_ext3@uefi
URL: https://openqa.fedoraproject.org/tests/522904
ID: 522927  Test: x86_64 universal install_btrfs@uefi
URL: https://openqa.fedoraproject.org/tests/522927
ID: 522941  Test: x86_64 universal upgrade_minimal_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/522941
ID: 522942  Test: x86_64 universal install_kickstart_user_creation 
**GATING**
URL: https://openqa.fedoraproject.org/tests/522942
ID: 522949  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/522949

Old failures (same test failed in Fedora-Rawhide-20200214.n.1):

ID: 522777  Test: x86_64 Server-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/522777
ID: 522778  Test: x86_64 Server-boot-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/522778
ID: 522781  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/522781
ID: 522792  Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation
URL: https://openqa.fedoraproject.org/tests/522792
ID: 522802  Test: x86_64 Server-dvd-iso install_repository_hd_variation
URL: https://openqa.fedoraproject.org/tests/522802
ID: 522817  Test: x86_64 Everything-boot-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/522817
ID: 522818  Test: x86_64 Everything-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/522818
ID: 522819  Test: x86_64 Workstation-live-iso install_default@uefi 
**GATING**
URL: https://openqa.fedoraproject.org/tests/522819
ID: 522820  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/522820
ID: 522821  Test: x86_64 Workstation-live-iso install_default_upload 
**GATING**
URL: https://openqa.fedoraproject.org/tests/522821
ID: 522836  Test: x86_64 KDE-live-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/522836
ID: 522841  Test: x86_64 KDE-live-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/522841
ID: 522845  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/522845
ID: 522847  Test: x86_64 KDE-live-iso install_no_user **GATING**
URL: https://openqa.fedoraproject.org/tests/522847
ID: 522854  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/522854
ID: 522867  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud **GATING**
URL: https://openqa.fedoraproject.org/tests/522867

Re: Disabling Fedora 29 chroots in Copr

[Jakub Kadlcik]

Thank you guys!

Jakub

On Tue, Feb 18, 2020 at 12:42 PM Frantisek Zatloukal
 wrote:
>
> Got one about a day ago :)
>
> On Tue, Feb 18, 2020 at 12:17 PM Jakub Kadlcik  wrote:
>>
>> I would like to ask you, can anyone with non Red Hat email confirm,
>> that they get the notifications? The subject is
>>
>> > [Copr] upcoming deletion of outdated chroots in your projects
>>
>>
>> Thank you,
>> Jakub
>>
>>
>> On Mon, Feb 17, 2020 at 12:21 AM Jakub Kadlcik  wrote:
>> >
>> > Hello,
>> >
>> > we have just disabled Fedora 29 chroots in Copr.
>> >
>> > According to the Fedora wiki [1], Fedora 29 reached the end of its life
>> > on 2019-11-30 and therefore we are disabling it in Copr.
>> >
>> > That effectively means that from this moment, it is no longer possible
>> > to submit builds for the following chroots:
>> >
>> > - fedora-29-x86_64
>> > - fedora-29-i386
>> > - fedora-29-ppc64le
>> > - fedora-29-aarch64
>> >
>> > Additionally, according to Outdated chroots removal policy [2], Copr is
>> > going to preserve existing build results in those chroots for another
>> > 180 days and then automatically remove them unless you take an action
>> > and prolong the chroots life span in your projects. Read more about this
>> > feature in the  Copr - Removing outdated chroots blog post [3].
>> >
>> >
>> > [1] https://fedoraproject.org/wiki/End_of_life
>> > [2] 
>> > https://docs.pagure.org/copr.copr/copr_outdated_chroots_removal_policy.html
>> > [3] http://frostyx.cz/posts/copr-removing-outdated-chroots
>> >
>> > 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
>
>
>
> --
>
> Best regards / S pozdravem,
>
> František Zatloukal
> Quality Engineer
> 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
___
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: Disabling Fedora 29 chroots in Copr

[Frantisek Zatloukal]

Got one about a day ago :)

On Tue, Feb 18, 2020 at 12:17 PM Jakub Kadlcik  wrote:

> I would like to ask you, can anyone with non Red Hat email confirm,
> that they get the notifications? The subject is
>
> > [Copr] upcoming deletion of outdated chroots in your projects
>
>
> Thank you,
> Jakub
>
>
> On Mon, Feb 17, 2020 at 12:21 AM Jakub Kadlcik 
> wrote:
> >
> > Hello,
> >
> > we have just disabled Fedora 29 chroots in Copr.
> >
> > According to the Fedora wiki [1], Fedora 29 reached the end of its life
> > on 2019-11-30 and therefore we are disabling it in Copr.
> >
> > That effectively means that from this moment, it is no longer possible
> > to submit builds for the following chroots:
> >
> > - fedora-29-x86_64
> > - fedora-29-i386
> > - fedora-29-ppc64le
> > - fedora-29-aarch64
> >
> > Additionally, according to Outdated chroots removal policy [2], Copr is
> > going to preserve existing build results in those chroots for another
> > 180 days and then automatically remove them unless you take an action
> > and prolong the chroots life span in your projects. Read more about this
> > feature in the  Copr - Removing outdated chroots blog post [3].
> >
> >
> > [1] https://fedoraproject.org/wiki/End_of_life
> > [2]
> https://docs.pagure.org/copr.copr/copr_outdated_chroots_removal_policy.html
> > [3] http://frostyx.cz/posts/copr-removing-outdated-chroots
> >
> > 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
>


-- 

Best regards / S pozdravem,

František Zatloukal
Quality Engineer
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

Re: Disabling Fedora 29 chroots in Copr

[Till Hofmann]

On 2/18/20 12:15 PM, Jakub Kadlcik wrote:
> I would like to ask you, can anyone with non Red Hat email confirm,
> that they get the notifications? The subject is
> 
>> [Copr] upcoming deletion of outdated chroots in your projects
> 

I received the notification. I have a posteo.de email.

Kind regards,
Till
___
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: Disabling Fedora 29 chroots in Copr

[Jakub Kadlcik]

I would like to ask you, can anyone with non Red Hat email confirm,
that they get the notifications? The subject is

> [Copr] upcoming deletion of outdated chroots in your projects


Thank you,
Jakub


On Mon, Feb 17, 2020 at 12:21 AM Jakub Kadlcik  wrote:
>
> Hello,
>
> we have just disabled Fedora 29 chroots in Copr.
>
> According to the Fedora wiki [1], Fedora 29 reached the end of its life
> on 2019-11-30 and therefore we are disabling it in Copr.
>
> That effectively means that from this moment, it is no longer possible
> to submit builds for the following chroots:
>
> - fedora-29-x86_64
> - fedora-29-i386
> - fedora-29-ppc64le
> - fedora-29-aarch64
>
> Additionally, according to Outdated chroots removal policy [2], Copr is
> going to preserve existing build results in those chroots for another
> 180 days and then automatically remove them unless you take an action
> and prolong the chroots life span in your projects. Read more about this
> feature in the  Copr - Removing outdated chroots blog post [3].
>
>
> [1] https://fedoraproject.org/wiki/End_of_life
> [2] 
> https://docs.pagure.org/copr.copr/copr_outdated_chroots_removal_policy.html
> [3] http://frostyx.cz/posts/copr-removing-outdated-chroots
>
> 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

ppisar pushed to perl-Specio (f31). "Correct a changelog entry"

[notifications]

Notification time stamped 2020-02-18 07:21:01 UTC

From 281022df124b36014ddfc03d5fef8029203bb262 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Feb 18 2020 07:20:25 +
Subject: Correct a changelog entry


---

diff --git a/perl-Specio.spec b/perl-Specio.spec
index c260bd9..4e7dc46 100644
--- a/perl-Specio.spec
+++ b/perl-Specio.spec
@@ -163,7 +163,7 @@ make test
 %{_mandir}/man3/Test::Specio.3*
 
 %changelog
-* Tue Feb 18 2020 Petr Pisar  - 0.45-2
+* Tue Feb 18 2020 Petr Pisar  - 0.44-2
 - Correct a perl-Specio license to "Artistic 2.0 and (GPL+ or Artistic)"
 
 * Thu Aug 15 2019 Paul Howarth  - 0.44-1



https://src.fedoraproject.org/rpms/perl-Specio/c/281022df124b36014ddfc03d5fef8029203bb262?branch=f31
___
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

ppisar pushed to perl-Specio (f30). "Correct a perl-Specio license to "Artistic 2.0 and (GPL+ or Artistic)""

[notifications]

Notification time stamped 2020-02-18 07:19:51 UTC

From 99159fd4d2b0f9cc8d1b5f7603fb010b01d707e0 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Feb 18 2020 07:19:24 +
Subject: Correct a perl-Specio license to "Artistic 2.0 and (GPL+ or Artistic)"


---

diff --git a/perl-Specio.spec b/perl-Specio.spec
index 22aa089..6d35ff8 100644
--- a/perl-Specio.spec
+++ b/perl-Specio.spec
@@ -7,9 +7,12 @@
 
 Name:  perl-Specio
 Version:   0.43
-Release:   2%{?dist}
+Release:   3%{?dist}
 Summary:   Type constraints and coercions for Perl
-License:   Artistic 2.0
+# lib/Specio/PartialDump.pm:   GPL+ or Artistic
+#  

+# other files: Artistic 2.0
+License:   Artistic 2.0 and (GPL+ or Artistic)
 URL:   https://metacpan.org/release/Specio
 Source0:   
https://cpan.metacpan.org/authors/id/D/DR/DROLSKY/Specio-%{version}.tar.gz
 BuildArch: noarch
@@ -157,6 +160,9 @@ make test
 %{_mandir}/man3/Test::Specio.3*
 
 %changelog
+* Tue Feb 18 2020 Petr Pisar  - 0.43-3
+- Correct a perl-Specio license to "Artistic 2.0 and (GPL+ or Artistic)"
+
 * Sat Feb 02 2019 Fedora Release Engineering  - 
0.43-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-Specio/c/99159fd4d2b0f9cc8d1b5f7603fb010b01d707e0?branch=f30
___
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

ppisar pushed to perl-Specio (f31). "Correct a perl-Specio license to "Artistic 2.0 and (GPL+ or Artistic)""

[notifications]

Notification time stamped 2020-02-18 07:16:12 UTC

From c16d6b5cb2f9cfca003a3705224775d72512b664 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Feb 18 2020 07:15:18 +
Subject: Correct a perl-Specio license to "Artistic 2.0 and (GPL+ or Artistic)"


---

diff --git a/perl-Specio.spec b/perl-Specio.spec
index e4837fd..c260bd9 100644
--- a/perl-Specio.spec
+++ b/perl-Specio.spec
@@ -9,9 +9,12 @@
 
 Name:  perl-Specio
 Version:   0.44
-Release:   1%{?dist}
+Release:   2%{?dist}
 Summary:   Type constraints and coercions for Perl
-License:   Artistic 2.0
+# lib/Specio/PartialDump.pm:   GPL+ or Artistic
+#  

+# other files: Artistic 2.0
+License:   Artistic 2.0 and (GPL+ or Artistic)
 URL:   https://metacpan.org/release/Specio
 Source0:   
https://cpan.metacpan.org/modules/by-module/Test/Specio-%{version}.tar.gz
 BuildArch: noarch
@@ -160,6 +163,9 @@ make test
 %{_mandir}/man3/Test::Specio.3*
 
 %changelog
+* Tue Feb 18 2020 Petr Pisar  - 0.45-2
+- Correct a perl-Specio license to "Artistic 2.0 and (GPL+ or Artistic)"
+
 * Thu Aug 15 2019 Paul Howarth  - 0.44-1
 - Update to 0.44
   - Replaced the use of B with XString if it is installed; the latter is much



https://src.fedoraproject.org/rpms/perl-Specio/c/c16d6b5cb2f9cfca003a3705224775d72512b664?branch=f31
___
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

ppisar pushed to perl-Specio (f32). "Correct a perl-Specio license to "Artistic 2.0 and (GPL+ or Artistic)""

[notifications]

Notification time stamped 2020-02-18 07:13:41 UTC

From 2b868307e5e147a5c4ef9e38167e70dfeaef0c7c Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Feb 18 2020 07:11:36 +
Subject: Correct a perl-Specio license to "Artistic 2.0 and (GPL+ or Artistic)"


---

diff --git a/perl-Specio.spec b/perl-Specio.spec
index 9b75b58..d89b6d4 100644
--- a/perl-Specio.spec
+++ b/perl-Specio.spec
@@ -9,9 +9,12 @@
 
 Name:  perl-Specio
 Version:   0.45
-Release:   2%{?dist}
+Release:   3%{?dist}
 Summary:   Type constraints and coercions for Perl
-License:   Artistic 2.0
+# lib/Specio/PartialDump.pm:   GPL+ or Artistic
+#  

+# other files: Artistic 2.0
+License:   Artistic 2.0 and (GPL+ or Artistic)
 URL:   https://metacpan.org/release/Specio
 Source0:   
https://cpan.metacpan.org/modules/by-module/Test/Specio-%{version}.tar.gz
 BuildArch: noarch
@@ -161,6 +164,9 @@ make test
 %{_mandir}/man3/Test::Specio.3*
 
 %changelog
+* Tue Feb 18 2020 Petr Pisar  - 0.45-3
+- Correct a perl-Specio license to "Artistic 2.0 and (GPL+ or Artistic)"
+
 * Thu Jan 30 2020 Fedora Release Engineering  - 
0.45-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-Specio/c/2b868307e5e147a5c4ef9e38167e70dfeaef0c7c?branch=f32
___
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

ppisar pushed to perl-Specio (master). "Correct a perl-Specio license to "Artistic 2.0 and (GPL+ or Artistic)""

[notifications]

Notification time stamped 2020-02-18 07:12:26 UTC

From 2b868307e5e147a5c4ef9e38167e70dfeaef0c7c Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Feb 18 2020 07:11:36 +
Subject: Correct a perl-Specio license to "Artistic 2.0 and (GPL+ or Artistic)"


---

diff --git a/perl-Specio.spec b/perl-Specio.spec
index 9b75b58..d89b6d4 100644
--- a/perl-Specio.spec
+++ b/perl-Specio.spec
@@ -9,9 +9,12 @@
 
 Name:  perl-Specio
 Version:   0.45
-Release:   2%{?dist}
+Release:   3%{?dist}
 Summary:   Type constraints and coercions for Perl
-License:   Artistic 2.0
+# lib/Specio/PartialDump.pm:   GPL+ or Artistic
+#  

+# other files: Artistic 2.0
+License:   Artistic 2.0 and (GPL+ or Artistic)
 URL:   https://metacpan.org/release/Specio
 Source0:   
https://cpan.metacpan.org/modules/by-module/Test/Specio-%{version}.tar.gz
 BuildArch: noarch
@@ -161,6 +164,9 @@ make test
 %{_mandir}/man3/Test::Specio.3*
 
 %changelog
+* Tue Feb 18 2020 Petr Pisar  - 0.45-3
+- Correct a perl-Specio license to "Artistic 2.0 and (GPL+ or Artistic)"
+
 * Thu Jan 30 2020 Fedora Release Engineering  - 
0.45-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-Specio/c/2b868307e5e147a5c4ef9e38167e70dfeaef0c7c?branch=master
___
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-Cloud-31-20200218.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: perl-Digest-SHA3, perl-Gtk3-WebKit (was: Re: Orphaned packages looking for new maintainers)

[Tomáš Popela]

I'm sorry as I didn't see this downstream patch -
https://src.fedoraproject.org/rpms/perl-Gtk3-WebKit/blob/master/f/Gtk3-WebKit-0.06-Port-to-webkitgtk4.patch
.
Then it's fine and sorry for the noise.

Tom

On Tue, Feb 18, 2020 at 10:14 AM Tomáš Popela  wrote:

> On Mon, Feb 17, 2020 at 6:33 PM Richard W.M. Jones 
> wrote:
>
>> On Mon, Feb 17, 2020 at 04:24:22PM +0100, Miro Hrončok wrote:
>> > rjones: perl-Digest-SHA3, perl-Gtk3-WebKit
>>
>
> No open bugs in perl-Gtk3-WebKit? Please read
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/7APAJVWLKRJWNLIW2N4SOGL2JOOYLW5N/
>  and https://lwn.net/Articles/730185/ and
> https://blogs.gnome.org/mcatanzaro/2016/02/01/on-webkit-security-updates/
> . The package should be removed from Fedora as it puts the users in the
> risk.
>
___
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: perl-Digest-SHA3, perl-Gtk3-WebKit (was: Re: Orphaned packages looking for new maintainers)

[Tomáš Popela]

On Mon, Feb 17, 2020 at 6:33 PM Richard W.M. Jones 
wrote:

> On Mon, Feb 17, 2020 at 04:24:22PM +0100, Miro Hrončok wrote:
> > rjones: perl-Digest-SHA3, perl-Gtk3-WebKit
>

No open bugs in perl-Gtk3-WebKit? Please read
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/7APAJVWLKRJWNLIW2N4SOGL2JOOYLW5N/
 and https://lwn.net/Articles/730185/ and
https://blogs.gnome.org/mcatanzaro/2016/02/01/on-webkit-security-updates/
. The package should be removed from Fedora as it puts the users in the
risk.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages looking for new maintainers

[Paul Howarth]

On Tue, 18 Feb 2020 08:53:26 +0100
Reini Urban  wrote:
> > $ repoquery --repo=rawhide{,-source} --whatrequires
> > perl-Cpanel-JSON-XS inxi-0:3.0.37-2.fc32.noarch
> > openqa-0:4.6-43.20200205git4861e34.fc33.noarch
> >  
> 
> 
> Oh, interesting. Didn't know it were so many.
> I'm upstream on this and I'm planning to rename it to perl-JSON-Safe
> soon. https://github.com/rurban/Cpanel-JSON-XS/issues/142
> With a backcompat Cpanel::JSON::XS package included of course, but the
> repos would need to change.
> Looks like quite some work ahead.

I wouldn't worry too much about this. If you include the backcompat
Cpanel::JSON::XS package then the packaged RPM will "provide"
perl(Cpanel::JSON::XS), which will satisfy the dependencies.

I'm anticipating a fairly smooth switch-over actually (I'm Fedora
maintainer of the perl-Cpanel-JSON-XS package). The only issues that I
expect to crop up would be where people expect to use the
cpanel_json_xs script (unless you're going to provide a backcompat
script too) or have a dependency on the package name rather than the
module, though that too would probably be fixed by having the
perl-JSON-Safe RPM package obsolete+provide perl-Cpanel-JSON-XS.

Cheers, Paul.
___
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 1804004] perl-PerlIO-Layers-0.012 is available

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
FEDORA-2020-9870bec3a8 has been submitted as an update to Fedora 30.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-9870bec3a8

-- 
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 1804004] perl-PerlIO-Layers-0.012 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

   Fixed In Version|perl-PerlIO-Layers-0.012-1. |perl-PerlIO-Layers-0.012-1.
   |fc33|fc32



-- 
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: Orphaned packages looking for new maintainers

[Pierre-Yves Chibon]

On Tue, Feb 18, 2020 at 07:41:56AM -, Miro Hrončok wrote:
> > Hm, I'm not seeing these orphaned and I pretty sure I have never maintained 
> > them:
> > https://src.fedoraproject.org/rpms/perl-IO-Socket-Timeout
> > https://src.fedoraproject.org/rpms/perl-PerlIO-via-Timeout
> > 
> > bug in the script?
> 
> They have been since adapted by @pghmcfc.
> 
> You have never maintained them, but your package depends on them:
> 
>   perl-Redis requires perl(IO::Socket::Timeout)
>   gitolite3 requires perl(Redis)
>   pagure requires gitolite3
> 
> (Also perl-IO-Socket-Timeout requires perl(PerlIO::via::Timeout).)
> 
> No bug in the script.  Although not the first "I have never maintained those" 
> reaction at all. How to make it easier to understand by affected maintainers?

The top of the section says: "Affected (co)maintainers", so I took it as I am a
co-maintainer of that package and thus I'm affected by it being orphaned.

Maybe simply saying: "Affected (co)maintainers (either directly or via packages'
dependencies)" would make it clearer that the list takes into account the
dependency tree.

I think the best/clearer output may just be something like:
pingou: perl-IO-Socket-Timeout (in the dependency tree for pagure), foo (in the
dependency tree for bar)...
but it may be too much pain for the gain.


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

[Bug 1804044] perl-Log-ger-0.029 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   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

[Bug 1804004] perl-PerlIO-Layers-0.012 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-PerlIO-Layers-0.012-1.
   ||fc33



--- Comment #3 from Petr Pisar  ---
An enhancement release suitable for all Fedoras.

-- 
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 1804004] perl-PerlIO-Layers-0.012 is available

[bugzilla]

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

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: Orphaned packages looking for new maintainers

[Vít Ondruch]

Dne 18. 02. 20 v 8:41 Miro Hrončok napsal(a):
>> Hm, I'm not seeing these orphaned and I pretty sure I have never maintained 
>> them:
>> https://src.fedoraproject.org/rpms/perl-IO-Socket-Timeout
>> https://src.fedoraproject.org/rpms/perl-PerlIO-via-Timeout
>>
>> bug in the script?
> They have been since adapted by @pghmcfc.
>
> You have never maintained them, but your package depends on them:
>
>   perl-Redis requires perl(IO::Socket::Timeout)
>   gitolite3 requires perl(Redis)
>   pagure requires gitolite3
>
> (Also perl-IO-Socket-Timeout requires perl(PerlIO::via::Timeout).)
>
> No bug in the script.  Although not the first "I have never maintained those" 
> reaction at all. How to make it easier to understand by affected maintainers?


If the email sent to specific maintainers was personalized with the
details from the full log, that would probably help. But it is
admittedly more work.

Or if there were links to the full log. But the log is just plain text ...


Vít


> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
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-Cloud-30-20200218.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