date:20200331

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

Bug 1811621 Summary: [RFE] EPEL8 branch of perl-JSON-Parse
https://bugzilla.redhat.com/show_bug.cgi?id=1811621

   What|Removed |Added

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



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

Re: silly question: finding root.log/build.log of FTBS F32 package (slim)

For some reason the cmake setup is not linking with libXft causing
undefined references during linking. I did not explore this but just forced
it with LDFLAGS. I got a good build with both rawhide and Fedora 31.

I committed my updates to master so you can take it from there (do a fedpkg
pull).

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: silly question: finding root.log/build.log of FTBS F32 package (slim)

Apparently %systemd_postun requires an argument now but did not before. I'm
dong a test build now and will commit my updates if successful but will not
perform a formal build.

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: silly question: finding root.log/build.log of FTBS F32 package (slim)

The root of the problem seems to be this but I can't find the bad macro or
the line number:

slim.spec: E: specfile-error error: This macro requires some arguments

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

[Bug 1815667] perl-CPAN-Perl-Releases-5.20200320 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2
   |0200320-1.fc33  |0200320-1.fc33
   |perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2
   |0200320-1.fc32  |0200320-1.fc32
   |perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2
   |0200320-1.fc31  |0200320-1.fc31
   ||perl-CPAN-Perl-Releases-5.2
   ||0200320-1.fc30



--- Comment #8 from Fedora Update System  ---
FEDORA-2020-cada965801 has been pushed to the Fedora 30 stable repository.
If problem still persists, 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 1813602] perl-CPAN-Perl-Releases-5.20200314 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2
   |0200314-1.fc33  |0200314-1.fc33
   |perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2
   |0200320-1.fc32  |0200320-1.fc32
   |perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2
   |0200320-1.fc31  |0200320-1.fc31
   ||perl-CPAN-Perl-Releases-5.2
   ||0200320-1.fc30



--- Comment #11 from Fedora Update System  ---
FEDORA-2020-cada965801 has been pushed to the Fedora 30 stable repository.
If problem still persists, 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 1813720] perl-Pod-Usage-1.70 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Pod-Usage-1.70-1.fc33  |perl-Pod-Usage-1.70-1.fc33
   |perl-Pod-Usage-1.70-1.fc32  |perl-Pod-Usage-1.70-1.fc32
   |perl-Pod-Usage-1.70-1.fc31  |perl-Pod-Usage-1.70-1.fc31
   ||perl-Pod-Usage-1.70-1.fc30



--- Comment #9 from Fedora Update System  ---
FEDORA-2020-9360ad9872 has been pushed to the Fedora 30 stable repository.
If problem still persists, 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: silly question: finding root.log/build.log of FTBS F32 package (slim)

2020-03-31 Thread Globe Trotter via devel

 Thanks! Yes, I believe that I took it from someone (can't recall who). Crikes, 
rewriting a spec file to make it up to date may not be that easy for me. Let us 
see.
Thanks again!
On Tuesday, March 31, 2020, 9:17:01 PM CDT, Richard Shaw 
 wrote:  
 
 On Tue, Mar 31, 2020 at 9:05 PM Globe Trotter via devel 
 wrote:

Hi,
I am the maintainer of slim. As per BZ and here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=41322154
slim was unable to build  BuildError: error building package (arch armv7hl), 
mock exited with status 1; see root.log for more information However, I can not 
figure out where to see this root.log. I am sorry for this stupid quesiton, but 
when I rebuild something, I usually get links to where these are. Where do I 
find this.


It doesn't look like the spec can even be parsed... Something must be off. 
There are conditionals in the spec for Fedora 15 so that tells me the spec file 
is in major need of an overhaul. Also cmake is being called directly instead of 
using %cmake.
Thanks,Richard ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
  ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: silly question: finding root.log/build.log of FTBS F32 package (slim)

On Tue, Mar 31, 2020 at 9:05 PM Globe Trotter via devel <
devel@lists.fedoraproject.org> wrote:

> Hi,
>
> I am the maintainer of slim. As per BZ and here:
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=41322154
>
> slim was unable to build
>
> BuildError: error building package (arch armv7hl), mock exited with status 1; 
> see root.log for more information
>
> However, I can not figure out where to see this root.log. I am sorry for
> this stupid quesiton, but when I rebuild something, I usually get links to
> where these are. Where do I find this.
>
>
It doesn't look like the spec can even be parsed... Something must be off.
There are conditionals in the spec for Fedora 15 so that tells me the spec
file is in major need of an overhaul. Also cmake is being called directly
instead of using %cmake.

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

[Bug 1819006] perl-Test-Simple-1.302174 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
FEDORA-2020-c3468a5e1b has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-c3468a5e1b`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-c3468a5e1b

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-de...@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-de...@lists.fedoraproject.org

Re: silly question: finding root.log/build.log of FTBS F32 package (slim)

2020-03-31 Thread Samuel Sieb


On 3/31/20 7:04 PM, Globe Trotter via devel wrote:

I am the maintainer of slim. As per BZ and here:

https://koji.fedoraproject.org/koji/taskinfo?taskID=41322154

slim was unable to build

BuildError: error building package (arch armv7hl), mock exited with status 1; 
see root.log for more information

However, I can not figure out where to see this root.log. I am sorry for 
this stupid quesiton, but when I rebuild something, I usually get links 
to where these are. Where do I find this.


That's a very old build.  It's state is "expired" so I assume that the 
logs have already been garbage collected.  You'll need to run a new build.

___
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: Odd build failure on Fedora 32

2020-03-31 Thread Luya Tshimbalanga

Thank you for explaining the root cause of the issue. Is the fix 
available on the build system for Fedora 32 at this time of writing so I 
can run YaraRay build?


Thanks again.

On 2020-03-30 1:49 p.m., Jonathan Wakely wrote:

On 29/03/20 11:31 -0700, Luya Tshimbalanga wrote:

Hello team,

Can someone investigate the failure on Fedora 32 YafaRay? It seems 
related to boost [2].


It's a GCC bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94190

It's fixed in this GCC update which has been submitted for testing:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-b2de059578
___
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


--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer
___
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

silly question: finding root.log/build.log of FTBS F32 package (slim)

2020-03-31 Thread Globe Trotter via devel

Hi,
I am the maintainer of slim. As per BZ and here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=41322154
slim was unable to build  BuildError: error building package (arch armv7hl), 
mock exited with status 1; see root.log for more information However, I can not 
figure out where to see this root.log. I am sorry for this stupid quesiton, but 
when I rebuild something, I usually get links to where these are. Where do I 
find this.
TIA!
___
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 1813602] perl-CPAN-Perl-Releases-5.20200314 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2
   |0200314-1.fc33  |0200314-1.fc33
   |perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2
   |0200320-1.fc32  |0200320-1.fc32
   ||perl-CPAN-Perl-Releases-5.2
   ||0200320-1.fc31



--- Comment #10 from Fedora Update System  ---
FEDORA-2020-06d0a81f9f has been pushed to the Fedora 31 stable repository.
If problem still persists, 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 1815667] perl-CPAN-Perl-Releases-5.20200320 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2
   |0200320-1.fc33  |0200320-1.fc33
   |perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2
   |0200320-1.fc32  |0200320-1.fc32
   ||perl-CPAN-Perl-Releases-5.2
   ||0200320-1.fc31



--- Comment #7 from Fedora Update System  ---
FEDORA-2020-06d0a81f9f has been pushed to the Fedora 31 stable repository.
If problem still persists, 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 1813720] perl-Pod-Usage-1.70 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Pod-Usage-1.70-1.fc33  |perl-Pod-Usage-1.70-1.fc33
   |perl-Pod-Usage-1.70-1.fc32  |perl-Pod-Usage-1.70-1.fc32
   ||perl-Pod-Usage-1.70-1.fc31



--- Comment #8 from Fedora Update System  ---
FEDORA-2020-0acf97c1e1 has been pushed to the Fedora 31 stable repository.
If problem still persists, 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 1814532] perl-Encode-3.05 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Encode-3.05-444.fc33   |perl-Encode-3.05-444.fc33
   ||perl-Encode-3.05-444.fc32
 Resolution|--- |ERRATA
Last Closed||2020-04-01 00:19:00



--- Comment #8 from Fedora Update System  ---
FEDORA-2020-f85e3cdf82 has been pushed to the Fedora 32 stable repository.
If problem still persists, 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 1815682] perl-Module-CoreList-5.20200320 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Module-CoreList-5.2020 |perl-Module-CoreList-5.2020
   |0320-1.fc33 |0320-1.fc33
   ||perl-Module-CoreList-5.2020
   ||0320-1.fc32
 Resolution|--- |ERRATA
Last Closed||2020-04-01 00:18:43



--- Comment #9 from Fedora Update System  ---
FEDORA-2020-88b16e03ec has been pushed to the Fedora 32 stable repository.
If problem still persists, 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 1816303] perl-DBD-Pg-3.10.5 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-DBD-Pg-3.10.5-1.fc33   |perl-DBD-Pg-3.10.5-1.fc33
   ||perl-DBD-Pg-3.10.5-1.fc32
 Resolution|--- |ERRATA
Last Closed||2020-04-01 00:17:58



--- Comment #2 from Fedora Update System  ---
FEDORA-2020-6651f17f19 has been pushed to the Fedora 32 stable repository.
If problem still persists, 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 1813720] perl-Pod-Usage-1.70 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Pod-Usage-1.70-1.fc33  |perl-Pod-Usage-1.70-1.fc33
   ||perl-Pod-Usage-1.70-1.fc32
 Resolution|--- |ERRATA
Last Closed||2020-04-01 00:16:32



--- Comment #7 from Fedora Update System  ---
FEDORA-2020-d708f52a27 has been pushed to the Fedora 32 stable repository.
If problem still persists, 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 1813602] perl-CPAN-Perl-Releases-5.20200314 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2
   |0200314-1.fc33  |0200314-1.fc33
   ||perl-CPAN-Perl-Releases-5.2
   ||0200320-1.fc32
 Resolution|--- |ERRATA
Last Closed||2020-04-01 00:16:50



--- Comment #9 from Fedora Update System  ---
FEDORA-2020-9825755f88 has been pushed to the Fedora 32 stable repository.
If problem still persists, 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 1815667] perl-CPAN-Perl-Releases-5.20200320 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2
   |0200320-1.fc33  |0200320-1.fc33
   ||perl-CPAN-Perl-Releases-5.2
   ||0200320-1.fc32
 Resolution|--- |ERRATA
Last Closed||2020-04-01 00:16:52



--- Comment #6 from Fedora Update System  ---
FEDORA-2020-9825755f88 has been pushed to the Fedora 32 stable repository.
If problem still persists, 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

[389-devel] Re: Please have a look at rewriters design

2020-03-31 Thread William Brown



> On 1 Apr 2020, at 01:04, Ludwig Krispenz  wrote:
> 
> Hi,
> 
> I was away and am late in the discussion, maybe too late.
> 

Not too late, it's not released in production yet ;). There are two PR's that 
have been discussed here:

https://pagure.io/389-ds-base/pull-request/50988

https://pagure.io/389-ds-base/pull-request/50981

> In my understanding what you mean by "generic" is that for a new rewriter you 
> do not need a plugin, but to provide some rewrite functions and specify them 
> in a rewriters config entry. But there is still the need to write rewriter 
> functions, compile  and deploy them, and instead of plugins you now have a 
> new interface of "filterRewriter" and "returendAttrRewriter functions - so 
> far not documented anywhere.
> 
> Under generic rewriter I would understand an approach where you do not need 
> to provide own functions, but have a rewriter plugin, which does rewriting 
> based on rules in rewrite config entries, eg in which subtree, for which 
> entries (filter to select), how to map a saerch filter, how to rename attrs 
> on return,

I had the same feeling too, to have these statically in libslapd, and much 
simpler than resolving symbols and dlopen. However, it's looking more like it 
will be a plugin style, but without using the current slapi plugin architecture 
- just a symload at start up. The reason for this that thierry explained is 
that freeipa plans to link to samba or sssd as part of one of the rewriter 
classes, and we don't want that to become a dependency of 389-ds.

I have argued in the past for a "lib-ipa" that has the needed shared logic 
between various pieces of the project, but honestly, I forgot if that ever 
happened. I think these days sssd is libipa in a lot of ways ... 

Anyway, that's why Thierry want's to have a symload in this case :) 

> 
> Best regards,
> Ludwig
> 
> 
> On 03/19/2020 01:09 AM, William Brown wrote:
>> 
>>> On 19 Mar 2020, at 04:08, thierry bordaz  wrote:
>>> 
>>> 
>>> 
>>> On 3/18/20 1:51 AM, William Brown wrote:
> On 18 Mar 2020, at 04:08, thierry bordaz  wrote:
> 
> Hi William,
> 
> I updated the design according to our offline exchange
 Thanks Thierry, I appreciate the conversation and the updates to the 
 document: it made clear there were extra details up in your brain but not 
 in words yet :) it's always hard to remember all the details as we write 
 things, so thanks for the discussion. Like you said, it's always good to 
 have a team who is really invested and cares about the work we do!
 
 
 Your design for the core server version looks much better! Thank you. I 
 still think there are some missing points. The reason to have a libpath 
 rather than inbuild is to avoid a potential linking to sssd/samba. I think 
 also that the problem space of the global catalog here needs to be looked 
 at too. This feature is not in isolation, it's really a part of that.
>>> Okay, I will work on a new PR making core server able to retrieve/registers 
>>> rewriters.
>>> 
>>> I think the "need" to improve the usability of rewriters is not specific to 
>>> global catalog. Global Catalog is just an opportunity to implement it. I 
>>> think parts of slapi-nis, integration of vsphere, GC (and likely others) 
>>> are also use case for rewriters. They were implemented in different ways 
>>> because rewriters were not easy to use or simply not known.
>> Yes, that's perfectly reasonable, and shouldn't stop your idea from being 
>> created - what's concerning me is that without a full picture you don't know 
>> how far to take these rewriters or what direction, or what might be needed.
>> 
 This means we have a whole set of deployment cases to look at.
 
 So the deployment will look like:
 
 IPA DS --> IPA GC
 
 
 So an ipaAccount from the IPA DS instance will be "copied and transformed" 
 into the IPA GC. This process is as yet undefined (it sounds like it may 
 be offline or something else ...). We are simply not dealing with one 
 instance now, but an out-of-band replication and transformation process. 
 It's unclear whether the data transform is during this loading process, or 
 in the IPA GC somehow.
 
 From what I understand, it sounds like a method to take an ipaAccount and 
 transform it to an AD GC account stub. Then inside of that IPA GC there 
 are some virtual attributes you wish to add like objectSid binary vs 
 string representations, objectCategory, maybe others.
 
 So from our discussion, we have currently focused on "how do we transform 
 entries within a single directory server". But that's not the problem 
 here. We are saying:
 
 "We take an entry from IPA DS, transform it to an IPA GC stub entry, and 
 then apply a set of further "in memory" transformations"
>>> One of the biggest issue with GC is schema. IPA DS and IPA GC have not 
>>> compatible

Re: Fedora 32 FTBFS packages to be orphaned in 1 week


On 31. 03. 20 23:00, Robert-André Mauchin wrote:

On Sunday, 29 March 2020 13:13:53 CEST you wrote:

golang-github-influxdata-flux eclipseo
golang-github-influxdata-influxdb eclipseo
golang-github-nats-io-streaming eclipseo
golang-github-opencontainers-runc eclipseo
golang-k8s-kubernetes eclipseo
golang-k8s-legacy-cloud-providers eclipseo
golang-vitesseclipseo


I intend to update them all but I haven't got the time nor was I able to get
reviews processed for some of them.


Switch the bugzillas to ASSIGNED and get back to that later?

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

[EPEL-devel] Re: What is the proper way to handle python3 python36 in RHEL7


On 01. 04. 20 0:06, Miro Hrončok wrote:

On 31. 03. 20 23:40, Erinn Looney-Triggs wrote:
Interestingly... no it did not and the reason is I built against rhel-7-x86_64 
in mock not epel-7-x86_64. I believe there is a macro override for 
epel-7-x86_64 hence why I was getting a dependency against python3-dbus.


Correct.


Ok so this would be a bug to file against the package then. Thanks.


I'm just gonna do it rigth away.


https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-0745794f21

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

[EPEL-devel] Re: What is the proper way to handle python3 python36 in RHEL7


On 31. 03. 20 23:40, Erinn Looney-Triggs wrote:
Interestingly... no it did not and the reason is I built against rhel-7-x86_64 
in mock not epel-7-x86_64. I believe there is a macro override for epel-7-x86_64 
hence why I was getting a dependency against python3-dbus.


Correct.


Ok so this would be a bug to file against the package then. Thanks.


I'm just gonna do it rigth away.

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

Re: CPE Git Forge Decision

2020-03-31 Thread Paul Frields

On Tue, Mar 31, 2020 at 5:23 PM Adam Williamson
 wrote:
>
> On Tue, 2020-03-31 at 17:06 -0400, Paul Frields wrote:
> >
> > > Sure. I tend to think of these as 'upstream projects' that we (Fedora)
> > > consume as a downstream. Project hosting has always been a kinda
> > > optional bolt-on, I think; going back to the days of fedorahosted.org I
> > > don't think we've ever hosted everything "Fedora-adjacent" in our own
> > > hosting service, it's always been a "use it if you want to" thing, and
> > > the rule for using a project in Fedora has always been "is it open
> > > source?", not "how is it hosted?".
> >
> > Although the Council changed that hard line some time ago.
>
> Someone told me that a few minutes ago; either I wasn't aware at the
> time or have forgotten, but my personal opinion is that this was a
> mistake.
>
> > > For that reason, I think the "what to do with Pagure.io?" element of
> > > this discussion is less critical than the src.fp.o part.
> > >
> > > >  A critical part of
> > > > our infrastructure the NFS shared storage also run an proprietary 
> > > > software
> > > > (NetApp).
> > >
> > > That's been covered already, and was why I put the "(more or less)"
> > > caveat into my quote. Of course, when you're getting to storage
> > > appliances, you're getting into pretty fuzzy territory, because we
> > > don't worry about the openness of the firmware running on our servers
> > > and stuff like that either...we've never quite been at FSF levels of
> > > ideological purity. But to me, this is at a different level to that.
> >
> > I see what we do for a dist-git fronting forge as far less compelling
> > for "purity level" tests because nearly all the meaningful content is
> > still easily copied and/or forked. Using open source for our specific
> > authentication needs (self-service groups, etc.), for instance, is a
> > recent example of a more compelling level, and the CPE group is
> > putting time into that project accordingly.
>
> I'm not sure I entirely understand the argument here. Are you saying we
> should only care if the specific things we need in Fedora are open
> source - like our CLI integrations and so on? If so, isn't that
> entirely naturally compatible with using Gitlab CE? After all, if all
> you want the external project to be is a generic git forge and you plan
> to write all the integration on top of that yourself, Gitlab CE does
> that job fine?

No, rather what I meant is that since git is git, and I still have my
data (and in the cases of all GitLab flavors AFAICT, nearly all the
meaningful metadata), I don't find it compelling whether the service
itself is fully open source. In fact, I wouldn't be opposed to using
GitHub if that were going to gain us some advantage for collaboration
that made it worthwhile.

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

[EPEL-devel] Re: What is the proper way to handle python3 python36 in RHEL7

2020-03-31 Thread Erinn Looney-Triggs


On 3/31/20 3:23 PM, Miro Hrončok wrote:

%{python3} = python3


%{python3} = /usr/bin/python3

At least in Fedora. In EPEL, most likely as well.


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

There's a bug in the macros.


But that bug has nothing to do with either %python3 or 
%python3_pkgversion.



Requires: %{python3}
Requires: %{python3}-dbus


What does this supposed to evaluate to?


Yeah my apologies I left out the most important part of the spec file:

%global python3 python%{python3_pkgversion}
%global python3_other python%{python3_other_pkgversion}




Anyway, the inconsistency problem is:

python36-dbus on EPEL 7 does not provide python3-dbus (can be fixed by 
adding %python_provide %{name} to the EPEL package)


Ok so this would be a bug to file against the package then. Thanks.




python3-dbus in RHEL 8 does not provide python36-dbus (can be fixed by 
changing RHEL's %python_provide and rebuilding the RHEL package, not 
sure if that will go trough)


Understandably.




I am looking into python3_pkgversion macro but that doesn't seem to 
be correct either.


This should work on both EPEL 7 and EPEL 8:

    Requires: python%{python3_pkgversion}-dbus

Doesn't it?

    $ mock -r epel-7-x86_64 shell
     sh-4.2# rpm --eval '%python3_pkgversion'
    36

    $ mock -r epel-8-x86_64 shell
     sh-4.4# rpm --eval '%python3_pkgversion'
    3


Interestingly... no it did not and the reason is I built against 
rhel-7-x86_64 in mock not epel-7-x86_64. I believe there is a macro 
override for epel-7-x86_64 hence why I was getting a dependency against 
python3-dbus.


I finally ended up doing this for the moment, which I do not like very 
much and I will probably fix here shortly:


%if 0%{?rhel} == 7
Requires: python36-dbus
%else
Requires: %{python3}-dbus
%endif


Thanks all for all the good information, it is appreciated.

-Erinn



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

Fedora rawhide compose report: 20200330.n.1 changes

2020-03-31 Thread Fedora Rawhide Report

OLD: Fedora-Rawhide-20200329.n.0
NEW: Fedora-Rawhide-20200330.n.1

= SUMMARY =
Added images:5
Dropped images:  0
Added packages:  12
Dropped packages:1
Upgraded packages:   244
Downgraded packages: 0

Size of added packages:  592.23 MiB
Size of dropped packages:213.20 KiB
Size of upgraded packages:   4.28 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Cloud_Base raw-xz ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20200330.n.1.ppc64le.raw.xz
Image: Server dvd s390x
Path: Server/s390x/iso/Fedora-Server-dvd-s390x-Rawhide-20200330.n.1.iso
Image: Server boot s390x
Path: Server/s390x/iso/Fedora-Server-netinst-s390x-Rawhide-20200330.n.1.iso
Image: Cloud_Base qcow2 ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20200330.n.1.ppc64le.qcow2
Image: Cloud_Base vmdk ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20200330.n.1.ppc64le.vmdk

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: assetfinder-0.1.0-1.fc33
Summary: Find domains and subdomains related to a given domain
RPMs:assetfinder golang-github-tomnomnom-assetfinder-devel
Size:9.74 MiB

Package: eclipse-1:4.15-3.module_f33+8420+75d411ed
Summary: An open, extensible IDE
RPMs:eclipse-contributor-tools eclipse-equinox-osgi eclipse-jdt 
eclipse-p2-discovery eclipse-pde eclipse-platform eclipse-swt
Size:534.86 MiB

Package: eclipse-ecf-3.14.7-1.module_f33+8420+75d411ed
Summary: Eclipse Communication Framework (ECF) Eclipse plug-in
RPMs:eclipse-ecf-core eclipse-ecf-runtime eclipse-ecf-sdk
Size:4.51 MiB

Package: eclipse-emf-1:2.21.0-1.module_f33+8420+75d411ed
Summary: EMF and XSD Eclipse plug-ins
RPMs:eclipse-emf-core eclipse-emf-runtime eclipse-emf-sdk eclipse-emf-xsd
Size:14.90 MiB

Package: git-repair-1.20200102-1.fc33
Summary: Repairs a damaged git repository
RPMs:git-repair
Size:12.01 MiB

Package: golang-github-jsonnet-bundler-0.3.1-2.fc33
Summary: A jsonnet package manager
RPMs:golang-github-jsonnet-bundler golang-github-jsonnet-bundler-devel
Size:13.59 MiB

Package: nyancat-1.5.2-4.fc33
Summary: Nyancat rendered in your terminal
RPMs:nyancat
Size:120.00 KiB

Package: perl-Gnome2-Vte-0.11-15.fc33
Summary: Perl interface to the Gtk2 Virtual Terminal Emulation library
RPMs:perl-Gnome2-Vte
Size:296.49 KiB

Package: python-asteval-0.9.18-1.fc33
Summary: Evaluator of Python expression using ast module
RPMs:python-asteval-doc python3-asteval
Size:195.95 KiB

Package: python-flask-restx-0.2.0-1.fc33
Summary: Framework for fast, easy and documented API development with Flask
RPMs:python3-flask-restx
Size:1.59 MiB

Package: python-pysmt-0.8.0-2.fc33
Summary: Solver-agnostic library for SMT Formulae manipulation and solving
RPMs:python3-pysmt
Size:370.53 KiB

Package: python-winacl-0.0.2-1.fc33
Summary: Python ACL/ACE/Security Descriptor manipulation library
RPMs:python3-winacl
Size:75.22 KiB


= DROPPED PACKAGES =
Package: nuvola-app-groove-2.0-2.fc28
Summary: Microsoft Groove for Nuvola Player 3
RPMs:nuvola-app-groove
Size:213.20 KiB


= UPGRADED PACKAGES =
Package:  HepMC3-3.2.1-2.fc33
Old package:  HepMC3-3.2.1-1.fc33
Summary:  C++ Event Record for Monte Carlo Generators
RPMs: HepMC3 HepMC3-devel HepMC3-doc HepMC3-interfaces-devel 
HepMC3-rootIO HepMC3-rootIO-devel HepMC3-search HepMC3-search-devel 
python3-HepMC3 python3-HepMC3-rootIO python3-HepMC3-search
Size: 44.28 MiB
Size change:  12.48 KiB
Changelog:
  * Sun Mar 29 2020 Mattias Ellert  - 3.2.1-2
  - Initialize ROOT in rootIO python bindings - avoids problem on EPEL 7 ppc64le
  - Use upstream's fix for parallel python tests


Package:  aether-connector-okhttp-0.17.6-3.module_f33+8420+75d411ed
Old package:  aether-connector-okhttp-0.17.6-3.module_f33+8406+feb0be7b
Summary:  OkHttp Aether Connector
RPMs: aether-connector-okhttp aether-connector-okhttp-javadoc
Size: 115.91 KiB
Size change:  6 B

Package:  antlr32-3.2-23.module_f33+8420+75d411ed
Old package:  antlr32-3.2-23.module_f33+8406+feb0be7b
Summary:  ANother Tool for Language Recognition
RPMs: antlr32-java antlr32-javadoc antlr32-maven-plugin antlr32-tool
Size: 1.55 MiB
Size change:  -2.42 KiB

Package:  apache-commons-collections-3.2.2-15.module_f33+8420+75d411ed
Old package:  apache-commons-collections-3.2.2-15.module_f33+8406+feb0be7b
Summary:  Provides new interfaces, implementations and utilities for Java 
Collections
RPMs: apache-commons-collections apache-commons-collections-javadoc 
apache-commons-collections-testframework
Size: 1.12 MiB
Size change:  -527 B

Package:  apache-commons-compress-1.19-1.module_f33+8420+75d411ed
Old package:  apache-commons-compress-1.19-1.module_f33+8406+feb0be7b
Summary:  Java API for working

[EPEL-devel] Re: What is the proper way to handle python3 python36 in RHEL7


%{python3} = python3


%{python3} = /usr/bin/python3

At least in Fedora. In EPEL, most likely as well.


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

There's a bug in the macros.


But that bug has nothing to do with either %python3 or %python3_pkgversion.


Requires: %{python3}
Requires: %{python3}-dbus


What does this supposed to evaluate to?

Anyway, the inconsistency problem is:

python36-dbus on EPEL 7 does not provide python3-dbus (can be fixed by adding 
%python_provide %{name} to the EPEL package)


python3-dbus in RHEL 8 does not provide python36-dbus (can be fixed by changing 
RHEL's %python_provide and rebuilding the RHEL package, not sure if that will go 
trough)



I am looking into python3_pkgversion macro but that doesn't seem to be correct 
either.


This should work on both EPEL 7 and EPEL 8:

Requires: python%{python3_pkgversion}-dbus

Doesn't it?

$ mock -r epel-7-x86_64 shell
 sh-4.2# rpm --eval '%python3_pkgversion'
36

$ mock -r epel-8-x86_64 shell
 sh-4.4# rpm --eval '%python3_pkgversion'
3


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

Re: CPE Git Forge Decision

On Tue, 2020-03-31 at 17:06 -0400, Paul Frields wrote:
> 
> > Sure. I tend to think of these as 'upstream projects' that we (Fedora)
> > consume as a downstream. Project hosting has always been a kinda
> > optional bolt-on, I think; going back to the days of fedorahosted.org I
> > don't think we've ever hosted everything "Fedora-adjacent" in our own
> > hosting service, it's always been a "use it if you want to" thing, and
> > the rule for using a project in Fedora has always been "is it open
> > source?", not "how is it hosted?".
> 
> Although the Council changed that hard line some time ago.

Someone told me that a few minutes ago; either I wasn't aware at the
time or have forgotten, but my personal opinion is that this was a
mistake.

> > For that reason, I think the "what to do with Pagure.io?" element of
> > this discussion is less critical than the src.fp.o part.
> > 
> > >  A critical part of
> > > our infrastructure the NFS shared storage also run an proprietary software
> > > (NetApp).
> > 
> > That's been covered already, and was why I put the "(more or less)"
> > caveat into my quote. Of course, when you're getting to storage
> > appliances, you're getting into pretty fuzzy territory, because we
> > don't worry about the openness of the firmware running on our servers
> > and stuff like that either...we've never quite been at FSF levels of
> > ideological purity. But to me, this is at a different level to that.
> 
> I see what we do for a dist-git fronting forge as far less compelling
> for "purity level" tests because nearly all the meaningful content is
> still easily copied and/or forked. Using open source for our specific
> authentication needs (self-service groups, etc.), for instance, is a
> recent example of a more compelling level, and the CPE group is
> putting time into that project accordingly.

I'm not sure I entirely understand the argument here. Are you saying we
should only care if the specific things we need in Fedora are open
source - like our CLI integrations and so on? If so, isn't that
entirely naturally compatible with using Gitlab CE? After all, if all
you want the external project to be is a generic git forge and you plan
to write all the integration on top of that yourself, Gitlab CE does
that job fine?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: CPE Git Forge Decision

2020-03-31 Thread Paul Frields

On Tue, Mar 31, 2020 at 3:25 PM Adam Williamson
 wrote:
>
> On Tue, 2020-03-31 at 21:18 +0200, Clement Verna wrote:
> > On Tue, 31 Mar 2020 at 20:04, Adam Williamson 
> > wrote:
> >
> > > On Tue, 2020-03-31 at 13:55 -0400, Matthew Miller wrote:
> > > > On Tue, Mar 31, 2020 at 10:44:35AM -0700, Adam Williamson wrote:
> > > > > I'm sorry, but I have to agree with Kevin and Michael here to a
> > > > > significant extent. Running our own project on open source code has
> > > > > always been a very big bright line for Fedora.
> > > >
> > > > You don't have to be sorry! I think it's very clear that this is the 
> > > > general
> > > > community view.
> > > >
> > > > > I think Iñaki's take on the "oh, you contribute to Github projects so
> > > > > no problem right?" angle is correct.
> > > >
> > > > Let me be sorry, though. That wasn't mean to be a "oh you..." 
> > > > statement. It
> > > > was that other open source projects are not held to this standard, not 
> > > > to
> > > > "gotcha" Michael or anyone else for their contributions elsewhere.
> > >
> > > I mean, held by who? This is a standard we have (more or less) held
> > > ourselves to. Which, if you think about it, means it's a standard
> > > that's in our DNA: we're a group of people who *thought it was
> > > important enough to hold ourselves to that standard*. Would it be
> > > hypocritical for someone outside of Fedora who happily uses software
> > > from other projects that are hosted on Github or whatever to criticize
> > > us if we were to do this? Sure, it would be. But this here is not that,
> > > it's us holding ourselves to our own standards.
> > >
> > > Speaking personally, sure, I contribute to Github-hosted projects. I
> > > maintain one project on Github (because it's extremely adjacent to
> > > another project that's hosted on Github and the maintainers of that
> > > project asked me to have it there, so I did). Hell, I send in fixes for
> > > entirely proprietary things sometimes...because my overriding itch is,
> > > if something is there, at least it had better *work* properly. But I
> > > certainly would not consider hosting work that's a fundamental part of
> > > Fedora on a proprietary system, I've always seen that as a *complete*
> > > non-starter - whether we were considering test automation, result
> > > tracking, event organization, anything like that, the very first rule
> > > has always been, if it's not open source it's just not on the list at
> > > all. And as far as I've noticed, that has been the same for all other
> > > core Fedora stuff, for many years.
> > >
> >
> > To add some nuance to stat statement a quite big chunk of the Fedora Infra
> > apps are hosted on GitHub (https://github.com/fedora-infra), and relatively
> > critical things like Bodhi, FAS, mirrormanager, . As far as I know most
> > of Fedora CoreOS (and Silverblue ?) is also on GitHub.
>
> Sure. I tend to think of these as 'upstream projects' that we (Fedora)
> consume as a downstream. Project hosting has always been a kinda
> optional bolt-on, I think; going back to the days of fedorahosted.org I
> don't think we've ever hosted everything "Fedora-adjacent" in our own
> hosting service, it's always been a "use it if you want to" thing, and
> the rule for using a project in Fedora has always been "is it open
> source?", not "how is it hosted?".

Although the Council changed that hard line some time ago.

> For that reason, I think the "what to do with Pagure.io?" element of
> this discussion is less critical than the src.fp.o part.
>
> >  A critical part of
> > our infrastructure the NFS shared storage also run an proprietary software
> > (NetApp).
>
> That's been covered already, and was why I put the "(more or less)"
> caveat into my quote. Of course, when you're getting to storage
> appliances, you're getting into pretty fuzzy territory, because we
> don't worry about the openness of the firmware running on our servers
> and stuff like that either...we've never quite been at FSF levels of
> ideological purity. But to me, this is at a different level to that.

I see what we do for a dist-git fronting forge as far less compelling
for "purity level" tests because nearly all the meaningful content is
still easily copied and/or forked. Using open source for our specific
authentication needs (self-service groups, etc.), for instance, is a
recent example of a more compelling level, and the CPE group is
putting time into that project accordingly.

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

Re: CPE Git Forge Decision

2020-03-31 Thread clime

Dne út 31. bře 2020 21:00 uživatel Clement Verna 
napsal:

>
>
> On Tue, 31 Mar 2020 at 14:57, Neal Gompa  wrote:
>
>> On Tue, Mar 31, 2020 at 7:10 AM Clement Verna 
>> wrote:
>> >
>> > I just want to give a bit of insight from someone who is working day to
>> day on Fedora's infrastructure, since I believe that might help give a bit
>> more empathy towards the Why of this decision.
>> >
>> > For me the Fedora's Infrastructure is in a very bad shape there is a
>> fair load of technical debt and trying to change or improve anything
>> results in a long list of reason why we can do it because services X
>> depends on service Y which depends on Z.  Since I joined the CPE team
>> (little bit more than 2 years ago) we have not been able to make any kind
>> of significant progress towards fighting this technical debt. Every year we
>> fill a white board with what needs to be done :
>> >
>> > Python 3 apps migration,
>> > FAS replacement,
>> > fedmsg retirement,
>> > FMN replacement,
>> > Fedora-packages replacement,
>> > PDC replacement,
>> > Porting application to OIDC,
>> > Improve Releng automation,
>> > Improving Anitya and the-new-hotness,
>> > .
>> >
>> > Every single year the same items are coming back because we spend most
>> of our time firefighting services to keep users happy and keep Fedora
>> release schedule. This has a very demoralizing effect on the people working
>> in the team, it seems like we will never be able to make any significant
>> improvement, and our day to day job is to close couple tickets and you keep
>> watching the pile of tickets growing. There is no feeling of accomplishment
>> and a general sentiment that whatever we do, it will suck.
>> >
>> > A little over a year ago we have expressed our need to drop
>> applications, this is something we have to do to be able to stay sane and
>> keep a sustainable life-work balance. From that effort to handover
>> applications (Elections, Nuancier, Fedocal, Badges) to another group of
>> people in the community, not much happened mainly because of GDPR and the
>> legal responsibility of owning such applications, but as far as I know we
>> don't do much maintenance work on these applications any more since we now
>> have a few volunteers that are looking after them or helping with finding
>> an alternative solution.
>> >
>> > Now on the list of application we develop and run, I think Pagure is
>> logical candidate to try and find an alternative to it, but before doing
>> this it was important to make sure we captured all the use case and feature
>> needed from a git forge and see if any of these justified spending cycles
>> in development and maintenance work. My understanding of the decision is
>> that Pagure does not provide any significant advantage over GitLab. I know
>> that for many, the fact that Pagure is developed by Fedora is an advantage,
>> but from my perspective as someone that as to deal with all the other
>> services in Fedora's Infra this is a major disadvantage.
>> >
>> > Overall I think it is important to keep in mind that there is a lot of
>> work happening behind the scene to provide the people in the Fedora
>> community a good experience contributing to Fedora. I think we are doing a
>> good job at it, but that takes us an enormous effort and over the long term
>> this is not sustainable, also keeping in mind that we keep adding and want
>> to keep adding new things to Fedora.
>> >
>> > I hope that my perspective helps a little.
>> >
>>
>> Clement,
>>
>> I want to say thank you for all the hard work you do as a member of
>> the Fedora community and as a member of the CPE team. You've done
>> fantastic work for the community and it's always a pleasure to work
>> with you. And that goes for all the members of the CPE team. I totally
>> understand where you are coming from. And it *is* very demoralizing to
>> see the same things over and over again, looking as if you've made no
>> progress on these things. I've been there with my work at $DAYJOB
>> before, many times. And as you and others are aware, I've been poking
>> around throughout infrastructure projects to help with some of these
>> initiatives over the years, so I'm keenly aware of the size and scope
>> of many of these.
>>
>> However, I think some of this is self-inflicted. I don't want to
>> entirely rehash my original email with my thoughts on this, so please
>> read that for more detail[1], but I think we *really* should consider
>> that the lack of community exposure to to the codebases themselves
>> (especially as an avenue for contributing to the Fedora Project!) is
>> an underlying problem here. This has created a persistent cycle of
>> "community member makes cool project to support Fedora" → "it gets
>> adopted silently and no one really talks about it or advertises it" →
>> "nobody knows about it and the community member is the only one
>> working on it" → "the community member burns out and it gets piled
>> onto Fedora Engineering/CPE to

Re: Fedora 32 FTBFS packages to be orphaned in 1 week

2020-03-31 Thread Robert-André Mauchin

On Sunday, 29 March 2020 13:13:53 CEST you wrote:
> golang-github-influxdata-flux eclipseo
> golang-github-influxdata-influxdb eclipseo
> golang-github-nats-io-streaming eclipseo
> golang-github-opencontainers-runc eclipseo
> golang-k8s-kubernetes eclipseo
> golang-k8s-legacy-cloud-providers eclipseo
> golang-vitesseclipseo

I intend to update them all but I haven't got the time nor was I able to get 
reviews processed for some of them.

___
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: CPE Git Forge Decision

2020-03-31 Thread Robbie Harwood

Clement Verna  writes:

> Neal Gompa  wrote:
>> Clement Verna  wrote:
>>
>> As for Pagure itself, I think this is where we fundamentally
>> disagree.  I think it behooves us to own and provide an experience
>> tailored for our community from beginning to end. That's why we have
>> Koji, Bodhi, Dist-Git, and many other tools in that part of the
>> lifecycle. The packager experience is literally the lifeblood of the
>> project, and our contributors are the core of what makes Fedora
>> successful. Pagure gives us an opportunity to do right by them that I
>> *really* don't think we can do with any alternatives.
>
> I am not convinced that having a custom git forge is mandatory to
> provide an great experience to the community. I wasn't really around
> the community before Pagure, but I as far as I understand it the
> experience was better before Pagure and people were able to do more
> self servicing. I believe that there is an alternative to having the
> packager workflow tightly coupled to the git forge, this is also maybe
> a good opportunity to rethink some of that workflow and explore
> different solutions.

Well, this continues to conflate "git forge" and "solution for
dist-git".

Before pagure, we had a (no-webui) git serving dist-git with other
services (e.g., pkgdb) stapled on.  More self-servicing was possible
because it was a more mature project.  In my opinion, the move to pagure
happened prematurely due to lack of feature parity - a problem we're
still dealing with today, which I think is what your "self servicing" is
in reference to.

Before pagure, we also had fedorahosted, which was our solution for
hosting projects, combining trac and a few other things.  Migration was
*painful*, and there have been many rocky parts along the way, but the
experience now is definitely better than fedorahosted.  It's far less
pleasant than a github project, though.

My impression is that most folks on this thread are more worried about
dist-git and its integrations than a general git forge, while it feels
like all CPE wants to talk about is the git forge.  You can't just use a
git forge as a dist-git: it takes a lot of integration work, which is
invisible because right now it's been done and just works™.  The refusal
to consider that this work exists in the decision worries me.

So long as it's open and we host it, I don't personally care what we
choose - as long as we can actually use it.

Thanks,
--Robbie

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

Re: CPE Git Forge Decision

2020-03-31 Thread Przemek Klosowski via devel


On 3/31/20 1:40 PM, Bruno Wolff III wrote:

On Tue, Mar 31, 2020 at 13:08:05 -0400,
 Matthew Miller  wrote:


We did communicate as the very top line of our gathered requirements 
that
open source is essential to our community and central to our 
feedback. I'm

not trying to be soft on that. Let's just not do purity-test level
assessments and instead focus on our goals.


The response from CPE made it sound like they just counted 
requirements rather than evalutating how important each requirement 
was to each group. Perhaps that was not intended, but that's they way 
it sounds. I think that being able to theorectically switch from 
hosted to self-hosted in short order (like in a month), should have 
been a deal breaking requirement from Fedora in case something at 
Gitlab changed that prevented using their hosted service. That implies 
having access to the source (capable of running our instance) with a 
free license and regular exports of the data in our hands. It doesn't 
sound like that is a requirement from the response provided by CPE.


Because of switching costs, this is likely to prevent us from going 
back to Pagure if it does develop a vibrant independent community. 
That would be unfortunate. 


This particular dilemma reminds me very much of the time when the LInux 
kernel developers weren't using version control, and it became clear 
that one is needed. Linus just refused to use CVS, and after some 
controversy, the core developers decided to use Larry McVoy's 
proprietary BitKeeper distributed VCS. This solved the technical problem 
and was successfully used for few years (2002 to 2005, IIRC).


Bitkeeper critics were pointing out that while the Linux community was 
free to use it to keep the source code, the Bitkeeper terms of use 
prohibited the non-commercial users from extracting the metadata 
(history, logs, etc). This issue kept causing problems, finally spurring 
Linus to sit down and invent git, and the rest is history.


It is important to remember that BitKeeper, while proprietary, had a 
very friendly and close relationship with the FOSS community, both when 
they joined forces and even when they were parting ways.  Still, the 
official Linux git log ( 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?ofs=905000 
) lacks the development history preceding 2005-04-16, and starts with 
one heck of a commit:


2005-04-16 	[PATCH] mmtimer build fix 
 
	Christoph Lameter 	1 	-1/+1
2005-04-16 	Linux-2.6.12-rc2 
v2.6.12-rc2 
 
	Linus Torvalds 	17291 	-0/+6718755


Perhaps the relevant lesson is that the only permanent thing is that 
nothing is permanent. Decisions that seem inevitable and superior do not 
necessarily continue to be so, and it's good to have a contingency plan 
for such eventalthough I am pretty sure that Linus did NOT plan to 
work on git in 2002.


Disclaimer: I wrote down my personal best recollections and opinions. 
Please draw your own conclusions and analogies; I ask for your 
indulgence hoping that it will be enlightening to at least someone.


___
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: CPE Git Forge Decision

On Tue, 2020-03-31 at 21:18 +0200, Clement Verna wrote:
> On Tue, 31 Mar 2020 at 20:04, Adam Williamson 
> wrote:
> 
> > On Tue, 2020-03-31 at 13:55 -0400, Matthew Miller wrote:
> > > On Tue, Mar 31, 2020 at 10:44:35AM -0700, Adam Williamson wrote:
> > > > I'm sorry, but I have to agree with Kevin and Michael here to a
> > > > significant extent. Running our own project on open source code has
> > > > always been a very big bright line for Fedora.
> > > 
> > > You don't have to be sorry! I think it's very clear that this is the
> > general
> > > community view.
> > > 
> > > > I think Iñaki's take on the "oh, you contribute to Github projects so
> > > > no problem right?" angle is correct.
> > > 
> > > Let me be sorry, though. That wasn't mean to be a "oh you..." statement.
> > It
> > > was that other open source projects are not held to this standard, not to
> > > "gotcha" Michael or anyone else for their contributions elsewhere.
> > 
> > I mean, held by who? This is a standard we have (more or less) held
> > ourselves to. Which, if you think about it, means it's a standard
> > that's in our DNA: we're a group of people who *thought it was
> > important enough to hold ourselves to that standard*. Would it be
> > hypocritical for someone outside of Fedora who happily uses software
> > from other projects that are hosted on Github or whatever to criticize
> > us if we were to do this? Sure, it would be. But this here is not that,
> > it's us holding ourselves to our own standards.
> > 
> > Speaking personally, sure, I contribute to Github-hosted projects. I
> > maintain one project on Github (because it's extremely adjacent to
> > another project that's hosted on Github and the maintainers of that
> > project asked me to have it there, so I did). Hell, I send in fixes for
> > entirely proprietary things sometimes...because my overriding itch is,
> > if something is there, at least it had better *work* properly. But I
> > certainly would not consider hosting work that's a fundamental part of
> > Fedora on a proprietary system, I've always seen that as a *complete*
> > non-starter - whether we were considering test automation, result
> > tracking, event organization, anything like that, the very first rule
> > has always been, if it's not open source it's just not on the list at
> > all. And as far as I've noticed, that has been the same for all other
> > core Fedora stuff, for many years.
> > 
> 
> To add some nuance to stat statement a quite big chunk of the Fedora Infra
> apps are hosted on GitHub (https://github.com/fedora-infra), and relatively
> critical things like Bodhi, FAS, mirrormanager, . As far as I know most
> of Fedora CoreOS (and Silverblue ?) is also on GitHub.

Sure. I tend to think of these as 'upstream projects' that we (Fedora)
consume as a downstream. Project hosting has always been a kinda
optional bolt-on, I think; going back to the days of fedorahosted.org I
don't think we've ever hosted everything "Fedora-adjacent" in our own
hosting service, it's always been a "use it if you want to" thing, and
the rule for using a project in Fedora has always been "is it open
source?", not "how is it hosted?".

For that reason, I think the "what to do with Pagure.io?" element of
this discussion is less critical than the src.fp.o part.

>  A critical part of
> our infrastructure the NFS shared storage also run an proprietary software
> (NetApp).

That's been covered already, and was why I put the "(more or less)"
caveat into my quote. Of course, when you're getting to storage
appliances, you're getting into pretty fuzzy territory, because we
don't worry about the openness of the firmware running on our servers
and stuff like that either...we've never quite been at FSF levels of
ideological purity. But to me, this is at a different level to that.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: CPE Git Forge Decision

2020-03-31 Thread Clement Verna

On Tue, 31 Mar 2020 at 20:04, Adam Williamson 
wrote:

> On Tue, 2020-03-31 at 13:55 -0400, Matthew Miller wrote:
> > On Tue, Mar 31, 2020 at 10:44:35AM -0700, Adam Williamson wrote:
> > > I'm sorry, but I have to agree with Kevin and Michael here to a
> > > significant extent. Running our own project on open source code has
> > > always been a very big bright line for Fedora.
> >
> > You don't have to be sorry! I think it's very clear that this is the
> general
> > community view.
> >
> > > I think Iñaki's take on the "oh, you contribute to Github projects so
> > > no problem right?" angle is correct.
> >
> > Let me be sorry, though. That wasn't mean to be a "oh you..." statement.
> It
> > was that other open source projects are not held to this standard, not to
> > "gotcha" Michael or anyone else for their contributions elsewhere.
>
> I mean, held by who? This is a standard we have (more or less) held
> ourselves to. Which, if you think about it, means it's a standard
> that's in our DNA: we're a group of people who *thought it was
> important enough to hold ourselves to that standard*. Would it be
> hypocritical for someone outside of Fedora who happily uses software
> from other projects that are hosted on Github or whatever to criticize
> us if we were to do this? Sure, it would be. But this here is not that,
> it's us holding ourselves to our own standards.
>
> Speaking personally, sure, I contribute to Github-hosted projects. I
> maintain one project on Github (because it's extremely adjacent to
> another project that's hosted on Github and the maintainers of that
> project asked me to have it there, so I did). Hell, I send in fixes for
> entirely proprietary things sometimes...because my overriding itch is,
> if something is there, at least it had better *work* properly. But I
> certainly would not consider hosting work that's a fundamental part of
> Fedora on a proprietary system, I've always seen that as a *complete*
> non-starter - whether we were considering test automation, result
> tracking, event organization, anything like that, the very first rule
> has always been, if it's not open source it's just not on the list at
> all. And as far as I've noticed, that has been the same for all other
> core Fedora stuff, for many years.
>

To add some nuance to stat statement a quite big chunk of the Fedora Infra
apps are hosted on GitHub (https://github.com/fedora-infra), and relatively
critical things like Bodhi, FAS, mirrormanager, . As far as I know most
of Fedora CoreOS (and Silverblue ?) is also on GitHub. A critical part of
our infrastructure the NFS shared storage also run an proprietary software
(NetApp).


>
> So, is it a high standard? Sure. Is it one many other projects don't
> try to meet? Sure. But it's one that, as I see it, we have held for a
> long time and that in itself creates a context and an expectation that
> we can't just dismiss and say "oh, hey, about that? yeah, that doesn't
> matter any more."
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
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: What is the proper way to handle python3 python36 in RHEL7

2020-03-31 Thread Troy Dawson

The correct way in EPEL7 is to use
  python%{python3_pkgversion}

%{python3} = python3
python%{python3_pkgversion} = python36
python%{python3_other_pkgversion} = python34 ?? (I think, maybe python38)

On Tue, Mar 31, 2020 at 11:47 AM Erinn Looney-Triggs
 wrote:
>
> Thanks for the quick reply. Disappointing, but it happens.
> ___
> 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 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: CPE Git Forge Decision

2020-03-31 Thread Tomasz Torcz

On Tue, Mar 31, 2020 at 11:34:35AM -0700, Adam Williamson wrote:
> On Tue, 2020-03-31 at 12:55 +0200, Tomasz Torcz wrote:
> > > 
> > > What really worries to me is that:
> > > * using GitLab as SaaS is being considered, and
> > > * for self-hosting, using the proprietary "enterprise" editions is not
> > >   excluded.
> > > 
> > > I think that using anything other than Free Software as the hosting 
> > > platform 
> > > for Fedora should be an absolute no go. In other words, self-hosted 
> > > GitLab 
> > > CE or Pagure, no other options.
> > 
> >   Being self-hosted is a nice goal, but not important enough.
> > There are parts of Fedora infrastructure which are not using Fedora,
> > but other distributions like RHEL.  We seem to have not problem in
> > using proprietary SAAS solutions for critical stuff.
> 
> What 'proprietary SAAS solutions' are we 'using for critical stuff'?

  GitLab Ultimate editon for managing source code of distribution.
We are not using it yet, but it looks very plausible that we will in the
future.


> Bruno explained the RHEL point. To his explanation I'd add, don't
> forget that EPEL is part of Fedora - in fact it's the most widely-used
> thing the Fedora project produces. And we use a lot of EPEL packages on
> the infra systems we (still) have running RHEL and/or CentOS. So this
> is also an important element of dogfooding.

  Personally I'd prefer people wanting to use Fedora packages just
to use Fedora distribution.


-- 
Tomasz TorczOnly gods can safely risk perfection,
to...@pipebreaker.pl it's a dangerous thing for a man.  — Alia
___
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: CPE Git Forge Decision

On Tue, 2020-03-31 at 20:59 +0200, Clement Verna wrote:
> 
> > The Fedora community itself has indicated that they want to keep on
> > with Pagure, and many Fedorans are Pythonistas, which means that
> > everyone can easily contribute to help make it better for everyone.
> > 
> 
> Genuine question, from the people that have participated in this thread,
> How many could dedicated couple hours a week to work on Pagure ? I think
> many community member are already struggling to keep up with their current
> level of contribution, I am not sure than everyone can easily contribute to
> Pagure. But I am happy to wrong :-).

I could, I've written patches for it before in fact. I would actually
be doing this already except that I knew this process was going on and
didn't want to burn work on it, and it's a little difficult to know
what kind of work I can just jump in and do and expect to be accepted
beyond very straightforward bug fixes. But if there was a co-ordinated
effort around this and I could rely on there being someone I can bounce
"hey, is it OK if I do ?" or "what do we really need to try and get
done right now?" type questions off, I'd certainly be able to find a
couple of hours to do some stuff.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora-Rawhide-20200330.n.1 compose check report

2020-03-31 Thread Fedora compose checker

No missing expected images.

Compose FAILS proposed Rawhide gating check!
3 of 43 required tests failed
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

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

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

ID: 561998  Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/561998
ID: 562003  Test: x86_64 Server-dvd-iso 
server_role_deploy_domain_controller **GATING**
URL: https://openqa.fedoraproject.org/tests/562003
ID: 562005  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart 
**GATING**
URL: https://openqa.fedoraproject.org/tests/562005
ID: 562006  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/562006
ID: 562007  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/562007
ID: 562008  Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING**
URL: https://openqa.fedoraproject.org/tests/562008
ID: 562009  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/562009
ID: 562093  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/562093
ID: 562105  Test: x86_64 universal install_blivet_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/562105
ID: 562137  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/562137
ID: 562140  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/562140
ID: 562142  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/562142

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

ID: 562000  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/562000
ID: 562014  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/562014
ID: 562036  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/562036
ID: 562049  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/562049
ID: 562103  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/562103

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

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

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

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

ID: 561970  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/561970
ID: 561971  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/561971
ID: 561975  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/561975
ID: 561979  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/561979
ID: 561982  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/561982
ID: 561983  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/561983
ID: 562028  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/562028
ID: 562030  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/562030
ID: 562062  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/562062
ID: 562067  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/562067
ID: 562084  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/562084
ID: 562094  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/562094
ID: 562112  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/562112
ID: 562128  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/562128
ID: 562136  Test: x86_64 universal install_serial_console
URL: https://openqa.fedoraproject.org/tests/562136

Passed openQA tests: 139/171 (x86_64)

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

ID: 561974  Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.fedoraproject.org/tests/561974
ID: 561995  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/561995
ID: 562068  Test: x86_64 universal

Re: CPE Git Forge Decision

2020-03-31 Thread Chris Murphy

On Tue, Mar 31, 2020 at 2:37 AM Leigh Griffin  wrote:
>
>
>
> On Mon, Mar 30, 2020 at 10:38 PM Chris Murphy  wrote:
>>
>> On Mon, Mar 30, 2020 at 5:56 AM Leigh Griffin  wrote:
>> >
>> > We haven't ironed out the full details but what was incredibly clear to us 
>> > was that Gitlab was the decision to make. The next step in getting there 
>> > is what we are engaging in now to get thoughts and suggestions and expect 
>> > several threads in that capacity from a technical perspective in the 
>> > coming weeks and months.
>>
>>
>> It is not incredibly clear to the respondents on devel@. I don't care
>> to imagine what stronger disagreement on this particular point looks
>> like.
>
>
> I respect that there is disagreement but Gitlab is the choice we are making.


Why this choice? That's what's not clear. And it's not fair to call
this mere disagreement, because the decision can't even be properly
absorbed. It is prima facie not an open or transparent process, yet is
being claimed to have been. That contradiction is not trust enhancing.



>>
>> On Mon, Mar 30, 2020 at 4:27 AM Iñaki Ucar  wrote:
>> >
>> > I was referring to, and I was expecting, an open conversation about
>> > the User Story list, an open analysis of the requirements list. In
>> > other words:
>> >
>> > 1. Open conversation to gather requirements. Done.
>> > 2. Publication of User Story list.
>> > 3. Open conversation to discuss (2).
>> > 4. Publication of the final decision.
>> >
>> > I was expecting (3), and it's missing.
>>
>>
>> I concur, and don't think the missing piece has been adequately
>> addressed. There's a reason why there's bewilderment at the decision,
>> it's not ignorable.
>
>
> How would you like us to address it more clearly? Fedora has had the 
> publication of its User Story list, a threads worth of discussion on it 
> occured and it was submitted. As have other stakeholder groups. I think the 
> crux here is that we didn't publish the entire stakeholder User Stories for 
> dissemination to each individual stakeholder group. With each group valuing 
> something different, as is obvious from the discussion around individual 
> requirements that has occured in several threads here, we didn't feel the 
> value would have been there. That's on me for not looping the comms back in 
> and I apologise for that.
>
>>
>> Were there deliberations by CPE Team in between (2) and (4)?
>
> Yes, several hundred person hours worth of analysis, meetings and dissecting 
> the requirements.

It would be addressed more clearly by seeing the summary,
distillation, metric, method, by which those hundreds of hours were
turned into the decision.

These entire threads are a verbose way of saying "show your work."

>
>>
>> Is there
>> a record of those deliberations?
>
>
> No, they were mostly video calls / in person meetings and the result is the 
> User Story list and decision document for sharing.

I think a summary of the first hour of these several hundred hours,
and the last hour, would be useful. There's no way to reconstruct
this? Deliberative bodies should be keeping notes, summary of major
decisions, pros, cons, liabilities, prioritization of conflicting
requirements, what things are in and out of scope, etc. There must be
something to show.


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

Re: CPE Git Forge Decision

2020-03-31 Thread Clement Verna

On Tue, 31 Mar 2020 at 14:57, Neal Gompa  wrote:

> On Tue, Mar 31, 2020 at 7:10 AM Clement Verna 
> wrote:
> >
> > I just want to give a bit of insight from someone who is working day to
> day on Fedora's infrastructure, since I believe that might help give a bit
> more empathy towards the Why of this decision.
> >
> > For me the Fedora's Infrastructure is in a very bad shape there is a
> fair load of technical debt and trying to change or improve anything
> results in a long list of reason why we can do it because services X
> depends on service Y which depends on Z.  Since I joined the CPE team
> (little bit more than 2 years ago) we have not been able to make any kind
> of significant progress towards fighting this technical debt. Every year we
> fill a white board with what needs to be done :
> >
> > Python 3 apps migration,
> > FAS replacement,
> > fedmsg retirement,
> > FMN replacement,
> > Fedora-packages replacement,
> > PDC replacement,
> > Porting application to OIDC,
> > Improve Releng automation,
> > Improving Anitya and the-new-hotness,
> > .
> >
> > Every single year the same items are coming back because we spend most
> of our time firefighting services to keep users happy and keep Fedora
> release schedule. This has a very demoralizing effect on the people working
> in the team, it seems like we will never be able to make any significant
> improvement, and our day to day job is to close couple tickets and you keep
> watching the pile of tickets growing. There is no feeling of accomplishment
> and a general sentiment that whatever we do, it will suck.
> >
> > A little over a year ago we have expressed our need to drop
> applications, this is something we have to do to be able to stay sane and
> keep a sustainable life-work balance. From that effort to handover
> applications (Elections, Nuancier, Fedocal, Badges) to another group of
> people in the community, not much happened mainly because of GDPR and the
> legal responsibility of owning such applications, but as far as I know we
> don't do much maintenance work on these applications any more since we now
> have a few volunteers that are looking after them or helping with finding
> an alternative solution.
> >
> > Now on the list of application we develop and run, I think Pagure is
> logical candidate to try and find an alternative to it, but before doing
> this it was important to make sure we captured all the use case and feature
> needed from a git forge and see if any of these justified spending cycles
> in development and maintenance work. My understanding of the decision is
> that Pagure does not provide any significant advantage over GitLab. I know
> that for many, the fact that Pagure is developed by Fedora is an advantage,
> but from my perspective as someone that as to deal with all the other
> services in Fedora's Infra this is a major disadvantage.
> >
> > Overall I think it is important to keep in mind that there is a lot of
> work happening behind the scene to provide the people in the Fedora
> community a good experience contributing to Fedora. I think we are doing a
> good job at it, but that takes us an enormous effort and over the long term
> this is not sustainable, also keeping in mind that we keep adding and want
> to keep adding new things to Fedora.
> >
> > I hope that my perspective helps a little.
> >
>
> Clement,
>
> I want to say thank you for all the hard work you do as a member of
> the Fedora community and as a member of the CPE team. You've done
> fantastic work for the community and it's always a pleasure to work
> with you. And that goes for all the members of the CPE team. I totally
> understand where you are coming from. And it *is* very demoralizing to
> see the same things over and over again, looking as if you've made no
> progress on these things. I've been there with my work at $DAYJOB
> before, many times. And as you and others are aware, I've been poking
> around throughout infrastructure projects to help with some of these
> initiatives over the years, so I'm keenly aware of the size and scope
> of many of these.
>
> However, I think some of this is self-inflicted. I don't want to
> entirely rehash my original email with my thoughts on this, so please
> read that for more detail[1], but I think we *really* should consider
> that the lack of community exposure to to the codebases themselves
> (especially as an avenue for contributing to the Fedora Project!) is
> an underlying problem here. This has created a persistent cycle of
> "community member makes cool project to support Fedora" → "it gets
> adopted silently and no one really talks about it or advertises it" →
> "nobody knows about it and the community member is the only one
> working on it" → "the community member burns out and it gets piled
> onto Fedora Engineering/CPE to maintain". This is basically how CPE
> team got >100 codebases.
>

I agree with that, but for me there also a bit of a chicken and egg
problem. I think we don't

Fedora-32-20200330.n.1 compose check report

2020-03-31 Thread Fedora compose checker

No missing expected images.

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

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

ID: 562187  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/562187
ID: 562246  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/562246
ID: 562293  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/562293
ID: 562312  Test: x86_64 universal install_pxeboot
URL: https://openqa.fedoraproject.org/tests/562312

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

ID: 562209  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/562209
ID: 56  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/56

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

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

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

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

ID: 562143  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/562143
ID: 562144  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/562144
ID: 562148  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/562148
ID: 562152  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/562152
ID: 562155  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/562155
ID: 562156  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/562156
ID: 562178  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/562178
ID: 562201  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/562201
ID: 562203  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/562203
ID: 562235  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/562235
ID: 562257  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/562257
ID: 562267  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/562267
ID: 562276  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/562276
ID: 562285  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/562285
ID: 562301  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/562301
ID: 562309  Test: x86_64 universal install_serial_console
URL: https://openqa.fedoraproject.org/tests/562309
ID: 562310  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/562310
ID: 562313  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/562313
ID: 562315  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/562315

Passed openQA tests: 146/171 (x86_64)

New passes (same test not passed in Fedora-32-20200328.n.0):

ID: 562191  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/562191
ID: 562199  Test: x86_64 Workstation-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/562199
ID: 562218  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/562218
ID: 562221  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/562221

Skipped non-gating openQA tests: 1 of 173

Installed system changes in test x86_64 Server-dvd-iso install_default_upload: 
1 packages(s) added since previous compose: tcl
1 packages(s) removed since previous compose: jimtcl
4 services(s) added since previous compose: plymouth-quit-wait.service, 
plymouth-quit.service, plymouth-read-write.service, plymouth-start.service
Previous test data: https://openqa.fedoraproject.org/tests/559434#downloads
Current test data: https://openqa.fedoraproject.org/tests/562148#downloads

Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: 
1 packages(s) added since previous compose: tcl
1 packages(s) removed since previous compose: jimtcl
4 services(s) added since previous compose: plymouth-quit-wait.service, 
plymouth-quit.service, plymouth-read-write.service, plymouth-start.service
Previous test data:

Re: CPE Git Forge Decision

On Tue, Mar 31, 2020 at 12:40:55PM -0500, Bruno Wolff III wrote:
...snip...
> 
> Because of switching costs, this is likely to prevent us from going back to
> Pagure if it does develop a vibrant independent community. That would be
> unfortunate.

So, currently we are using pagure on src.fedoraproject.org, but it's not
just pagure, it's a integration layer over the top of pagure too. 

I'd like to see if we can, as part of this: a) adjust our packaging
workflow (as many threads on this list have talked about) and b) after
that, try and reduce that integration layer as much as we can and c)
hopefully make it so we could move the backend git repos / forge later
if we wanted to without recreating a big integration layer.

As part of that we could also provide whats needed for the integration
and the pagure community could add anything they don't already have on
their roadmap. 

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: Fedora 32: setup with encrypted LVM

2020-03-31 Thread Dario Lesca

Il giorno dom, 22/03/2020 alle 20.55 +0100, Dario Lesca ha scritto:
> It's this behavior  a new feature or it's a bug of Anaconda on Fedora
> 32 ?

It's a Bug.
I have fill this bugzilla:
"Anaconda create LV filesystem encrypted on a VG already encrypted"
https://bugzilla.redhat.com/show_bug.cgi?id=1819360

Thanks

-- 
Dario Lesca
(inviato dal mio Linux Fedora 31 Workstation)
___
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: What is the proper way to handle python3 python36 in RHEL7

2020-03-31 Thread Erinn Looney-Triggs

Thanks for the quick reply. Disappointing, but it happens.
___
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: CPE Git Forge Decision

2020-03-31 Thread Chris Murphy

On Tue, Mar 31, 2020 at 11:45 AM Adam Williamson
 wrote:
>
> On Tue, 2020-03-31 at 13:08 -0400, Matthew Miller wrote:
> > On Tue, Mar 31, 2020 at 10:48:55AM -0500, Michael Catanzaro wrote:
> > > Some failure of process or communication must have occurred
> > > somewhere along the lines, because open source should have been the
> > > first and most important requirement. A proprietary software
> > > solution is incompatible with the ethos and purpose of the Fedora
> > > project. I ask CPE to revise its requirements list to include open
> > > source as the first and most important requirement from the Fedora
> > > community. If that's incompatible with CentOS's need for merge
> > > request approvals or whatever else, then we need to accept that
> > > sharing the same forge is simply not going to work.
> >
> > Obviously open source is one of our key foundations. And it is part of who
> > we are even before those foundations were drafted. Nonetheless, I want to
> > gently discuss this a little bit. We make an entirely open source and free
> > software operating system. We support and promote and advocate for open
> > source and free content. But we can't do everything, and at some point, this
> > becomes "this is why we can't have nice things". I see that you've made
> > contributions to other open source projects on GitHub and (hosted) GitLab
> > this month. Lots of Fedora contributors have and will continue to do so.
> > Many use that as their main hosting. It's not ideal, but it's not the end of
> > the world. I don't see Fedora making use of non-open hosted services as the
> > end of the world either, if that is what is best for us.
> >
> > We did communicate as the very top line of our gathered requirements that
> > open source is essential to our community and central to our feedback. I'm
> > not trying to be soft on that. Let's just not do purity-test level
> > assessments and instead focus on our goals.
>
> I'm sorry, but I have to agree with Kevin and Michael here to a
> significant extent. Running our own project on open source code has
> always been a very big bright line for Fedora.
>
> I'm not necessarily saying it's a hill we should die on, but at the
> very least, choosing a proprietary hosted solution for something as
> fundamental as our dist-git needs to be treated as a Very Big Deal and
> needs to be a decision that is handled a *lot* better than this one has
> been handled.
>
> You said in another email that the tooling choice ultimately has to be
> largely made by the team that is responsible for the work and it
> wouldn't really work for Council to order them to do something they
> can't practically do, and I see the truth in that, but at the same time
> I think there has to be a balance there. Does this "the team decides
> what works for them" principle extend as far as the team being able to
> choose unilaterally to go against principles Fedora has been working
> very hard to maintain for about as long as it has existed, and that are
> listed right up there front and centre as our Foundations? That, to me,
> seems like a decision that Council ought at the very least to be deeply
> involved in - much more than seems to have been the case here (which
> seems to have been that we wrote up some requirements and sent them off
> to "the team", which smooshed them into some kind of summary and then
> made a decision - a decision which seems to have had a rather confused
> context, as various people don't seem to be on the same page about
> whether a choice was supposed to be made about "dist-git", or
> "pagure.io", or "Pagure", or CentOS's or Red Hat's use of Pagure, or
> any or all of these things somehow smooshed together).
>
> I think if I turned up tomorrow and said that QA had decided we're
> going to use a proprietary hosted service for managing release
> validation testing there would be significant pushback against that,
> and I think that pushback would be valid, and I'm not sure it would be
> appropriate for us to say "tough, we made that decision so that's
> what's happening". I don't think it's necessarily appropriate for that
> to happen here either.
>
> I understand there are practical resource considerations and so on
> here, but I still think this merits more high level and serious
> consideration. At the very least, if we have somehow reached a point
> where Red Hat is no longer willing to provide sufficient resources to
> run Fedora on the lines the Fedora community wants it to be run, we
> need to recognize that this is a significant problem that needs to be
> properly aired and discussed and resolved. In this context I'll note
> that the apparent significant headcount reduction of RH people working
> on Fedora infrastructure over the last few years is in itself a
> worrying trend, particularly if you consider it while reading Clement's
> email.
>
> I think Iñaki's take on the "oh, you contribute to Github projects so
> no problem right?" angle is correct.

I concur with

Re: CPE Git Forge Decision

On Tue, 2020-03-31 at 12:55 +0200, Tomasz Torcz wrote:
> On Tue, Mar 31, 2020 at 12:42:18PM +0200, Kevin Kofler wrote:
> > Leigh Griffin wrote:
> > > Thank you for your patience while the CPE Team worked through an
> > > incredible number of requirements from multiple stakeholder sources. On
> > > Friday evening we announced on the Community Blog
> > >  our
> > > decision to adopt Gitlab as our Git Forge and to retain pagure.io to
> > > ultimately hand over to the Community to maintain. It wasn't an easy
> > > decision by any stretch of the imagination and we hope that the compromise
> > > that we are striking will help to allow Pagure flourish and to give a
> > > choice of Forges for your usage. I'm happy to field any questions or
> > > comments about this decision.
> > 
> > What really worries to me is that:
> > * using GitLab as SaaS is being considered, and
> > * for self-hosting, using the proprietary "enterprise" editions is not
> >   excluded.
> > 
> > I think that using anything other than Free Software as the hosting 
> > platform 
> > for Fedora should be an absolute no go. In other words, self-hosted GitLab 
> > CE or Pagure, no other options.
> 
>   Being self-hosted is a nice goal, but not important enough.
> There are parts of Fedora infrastructure which are not using Fedora,
> but other distributions like RHEL.  We seem to have not problem in
> using proprietary SAAS solutions for critical stuff.

What 'proprietary SAAS solutions' are we 'using for critical stuff'?

Bruno explained the RHEL point. To his explanation I'd add, don't
forget that EPEL is part of Fedora - in fact it's the most widely-used
thing the Fedora project produces. And we use a lot of EPEL packages on
the infra systems we (still) have running RHEL and/or CentOS. So this
is also an important element of dogfooding.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Koji is failing on s390x

2020-03-31 Thread Artem Tim

> But it might be my fault.

No, i have the same issue with different packages at this time as well. But now 
it's fine.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 32 compose report: 20200330.n.1 changes

2020-03-31 Thread Fedora Branched Report

OLD: Fedora-32-20200328.n.0
NEW: Fedora-32-20200330.n.1

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

Size of added packages:  14.04 MiB
Size of dropped packages:494.73 KiB
Size of upgraded packages:   4.68 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Design_suite live x86_64
Path: Labs/x86_64/iso/Fedora-Design_suite-Live-x86_64-32-20200330.n.1.iso

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: elementary-notifications-0-0.2.20200318.gitba4310b.fc32
Summary: GTK Notifications Server
RPMs:elementary-notifications
Size:256.42 KiB

Package: golang-github-logrusorgru-aurora-2.0-1.fc32
Summary: Golang ultimate ANSI-colors that supports Printf/Sprintf methods
RPMs:golang-github-logrusorgru-aurora-devel
Size:28.62 KiB

Package: libpasraw-1.3.0-4.fc32
Summary: Pascal interface to libraw
RPMs:libpasraw libpasraw-devel
Size:190.45 KiB

Package: ocaml-ppx-deriving-yojson-3.5.2-1.fc32
Summary: JSON codec generator for OCaml
RPMs:ocaml-ppx-deriving-yojson ocaml-ppx-deriving-yojson-devel 
ocaml-ppx-deriving-yojson-doc
Size:3.43 MiB

Package: python-eccodes-0.9.7-1.fc32
Summary: Python interface to the ecCodes GRIB and BUFR decoder/encoder
RPMs:python3-eccodes
Size:701.59 KiB

Package: python-gilt-1.2.1-2.fc32
Summary: Gilt is a git layering tool
RPMs:python-gilt-doc python3-gilt
Size:227.49 KiB

Package: python-pytest-datafiles-2.0-1.fc32
Summary: A pytest plugin to create a 'tmpdir' containing predefined content
RPMs:python3-pytest-datafiles
Size:16.89 KiB

Package: python-ssdeep-3.4-2.fc32
Summary: Python wrapper for the ssdeep library
RPMs:python3-ssdeep python3-ssdeep-doc
Size:316.98 KiB

Package: rust-fedora-update-feedback-0.5.1-1.fc32
Summary: Provide feedback for fedora updates (inspired by fedora-easy-karma)
RPMs:fedora-update-feedback
Size:8.85 MiB

Package: sgtk-menu-1.3.1-3.fc32
Summary: GTK launcher for sway & other WMs
RPMs:sgtk-menu
Size:60.60 KiB


= DROPPED PACKAGES =
Package: libocrdma-1.0.8-6.fc27
Summary: User-space Library for Emulex ROCE Device
RPMs:libocrdma libocrdma-static
Size:281.53 KiB

Package: nuvola-app-groove-2.0-2.fc28
Summary: Microsoft Groove for Nuvola Player 3
RPMs:nuvola-app-groove
Size:213.20 KiB


= UPGRADED PACKAGES =
Package:  ModemManager-1.12.8-1.fc32
Old package:  ModemManager-1.12.6-1.fc32
Summary:  Mobile broadband modem management service
RPMs: ModemManager ModemManager-devel ModemManager-glib 
ModemManager-glib-devel ModemManager-vala
Size: 10.99 MiB
Size change:  9.95 KiB
Changelog:
  * Tue Mar 24 2020 Lubomir Rintel  - 1.12.8-1
  - Update to 1.12.8 release


Package:  PyYAML-5.3.1-1.fc32
Old package:  PyYAML-5.3-4.fc32
Summary:  YAML parser and emitter for Python
RPMs: python3-pyyaml
Size: 972.77 KiB
Size change:  4.61 KiB
Changelog:
  * Thu Mar 19 2020 John Eckersberg  - 5.3.1-1
  - New upstream release 5.3.1 (rhbz#1814882)
  - Fixes CVE-2020-1747 (rhbz#1807367,1809011)


Package:  R-highlight-0.5.0-1.fc32
Old package:  R-highlight-0.4.7.2-7.fc32
Summary:  R Syntax Highlighter
RPMs: R-highlight
Size: 2.71 MiB
Size change:  1.93 KiB
Changelog:
  * Fri Mar 20 2020 Mattias Ellert  - 0.5.0-1
  - Update to 0.5.0


Package:  R-qtl-1.46.2-1.fc32
Old package:  R-qtl-1.44.9-7.fc32
Summary:  Tools for analyzing QTL experiments
RPMs: R-qtl
Size: 26.25 MiB
Size change:  -70.08 KiB
Changelog:
  * Sat Mar 21 2020 Mattias Ellert  - 1.46.2-1
  - Update to 1.46-2


Package:  R-units-0.6.6-1.fc32
Old package:  R-units-0.6.5-3.fc32
Summary:  Measurement Units for R Vectors
RPMs: R-units
Size: 3.83 MiB
Size change:  -942 B
Changelog:
  * Fri Mar 20 2020 I??aki ??car  - 0.6.6-1
  - Update to 0.6-6


Package:  WoeUSB-3.3.1-2.fc32
Old package:  WoeUSB-3.3.1-1.fc32
Summary:  Windows USB installation media creator
RPMs: WoeUSB
Size: 3.78 MiB
Size change:  -1008.49 KiB
Changelog:
  * Mon Mar 16 2020 mprahl  - 3.3.1-2
  - Stop building for s390x due to RHBZ#1813540


Package:  ccdciel-0.9.68-3.fc32
Old package:  ccdciel-0.9.68-2.fc32
Summary:  CCD capture software
RPMs: ccdciel
Size: 25.70 MiB
Size change:  4.95 KiB
Changelog:
  * Wed Mar 18 2020 Mattia Verga  - 0.9.68-3
  - Add libpasraw to Requires


Package:  ckeditor-4.14.0-1.fc32
Old package:  ckeditor-4.13.1-2.fc32
Summary:  WYSIWYG text editor to be used inside web pages
RPMs: ckeditor ckeditor-samples
Size: 855.24 KiB
Size change:  1.23 KiB
Changelog:
  * Fri Mar 20 2020 Shawn Iwinski  - 4.14.0-1
  - Update to 4.14.0 (RHBZ #1810020)
  - CVE-2020-9281 (RHBZ #1814825,1814826,1814827)
  -

Re: Koji is failing on s390x

2020-03-31 Thread Jun Aruga

> should be https://pagure.io/koji/issue/1974
>
> What's the size of the srpm?

Thanks for sharing the info.

It's 238 KB.

```
$ ls -hl rubygem-puma-4.3.3-1.fc32.src.rpm
-rw-rw-r-- 1 jaruga jaruga 238K Mar 31 19:52 rubygem-puma-4.3.3-1.fc32.src.rpm
```

But it might be my fault.
I was putting rubygem-puma-master.spec file as a backup.
Then when running `fedpkg srpm`, it seems rubygem-puma-master.spec was
included in the SRPM file rubygem-puma-4.3.3-1.fc32.src.rpm.
It's a invalid state.

```
$ pwd
/home/jaruga/fed/rubygem-puma

$ ls
...
rubygem-puma.spec
rubygem-puma-master.spec
...
```

Now after removing the file, the build succeeded.
Sorry for disturbing it.

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

Re: fedpkg clone fails with Permission denied (publickey).

Actually it worked now... Go figure.

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: CPE Git Forge Decision

On Tue, 2020-03-31 at 13:55 -0400, Matthew Miller wrote:
> On Tue, Mar 31, 2020 at 10:44:35AM -0700, Adam Williamson wrote:
> > I'm sorry, but I have to agree with Kevin and Michael here to a
> > significant extent. Running our own project on open source code has
> > always been a very big bright line for Fedora.
> 
> You don't have to be sorry! I think it's very clear that this is the general
> community view.
> 
> > I think Iñaki's take on the "oh, you contribute to Github projects so
> > no problem right?" angle is correct.
> 
> Let me be sorry, though. That wasn't mean to be a "oh you..." statement. It
> was that other open source projects are not held to this standard, not to
> "gotcha" Michael or anyone else for their contributions elsewhere.

I mean, held by who? This is a standard we have (more or less) held
ourselves to. Which, if you think about it, means it's a standard
that's in our DNA: we're a group of people who *thought it was
important enough to hold ourselves to that standard*. Would it be
hypocritical for someone outside of Fedora who happily uses software
from other projects that are hosted on Github or whatever to criticize
us if we were to do this? Sure, it would be. But this here is not that,
it's us holding ourselves to our own standards.

Speaking personally, sure, I contribute to Github-hosted projects. I
maintain one project on Github (because it's extremely adjacent to
another project that's hosted on Github and the maintainers of that
project asked me to have it there, so I did). Hell, I send in fixes for
entirely proprietary things sometimes...because my overriding itch is,
if something is there, at least it had better *work* properly. But I
certainly would not consider hosting work that's a fundamental part of
Fedora on a proprietary system, I've always seen that as a *complete*
non-starter - whether we were considering test automation, result
tracking, event organization, anything like that, the very first rule
has always been, if it's not open source it's just not on the list at
all. And as far as I've noticed, that has been the same for all other
core Fedora stuff, for many years.

So, is it a high standard? Sure. Is it one many other projects don't
try to meet? Sure. But it's one that, as I see it, we have held for a
long time and that in itself creates a context and an expectation that
we can't just dismiss and say "oh, hey, about that? yeah, that doesn't
matter any more."
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: CPE Git Forge Decision

2020-03-31 Thread Bruno Wolff III


On Tue, Mar 31, 2020 at 13:08:05 -0400,
 Matthew Miller  wrote:


We did communicate as the very top line of our gathered requirements that
open source is essential to our community and central to our feedback. I'm
not trying to be soft on that. Let's just not do purity-test level
assessments and instead focus on our goals.


The response from CPE made it sound like they just counted requirements 
rather than evalutating how important each requirement was to each group. 
Perhaps that was not intended, but that's they way it sounds. I think that 
being able to theorectically switch from hosted to self-hosted in short 
order (like in a month), should have been a deal breaking requirement from 
Fedora in case something at Gitlab changed that prevented using their 
hosted service. That implies having access to the source (capable of running 
our instance) with a free license and regular exports of the data in our 
hands. It doesn't sound like that is a requirement from the response 
provided by CPE.


Because of switching costs, this is likely to prevent us from going back 
to Pagure if it does develop a vibrant independent community. That would 
be unfortunate.

___
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: CPE Git Forge Decision

On Tue, Mar 31, 2020 at 10:44:35AM -0700, Adam Williamson wrote:
> I'm sorry, but I have to agree with Kevin and Michael here to a
> significant extent. Running our own project on open source code has
> always been a very big bright line for Fedora.

You don't have to be sorry! I think it's very clear that this is the general
community view.

> I think Iñaki's take on the "oh, you contribute to Github projects so
> no problem right?" angle is correct.

Let me be sorry, though. That wasn't mean to be a "oh you..." statement. It
was that other open source projects are not held to this standard, not to
"gotcha" Michael or anyone else for their contributions elsewhere.


-- 
Matthew Miller

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

Re: CPE Git Forge Decision

On Tue, Mar 31, 2020 at 10:31:21AM -0700, Adam Williamson wrote:
> I specifically mentioned at least the FSF angle on this mailing list,
> over a month ago:
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EJAKU3MO4T5ZEWEBUWIRSGBWTFQU44QK/
> 
> so at least that part certainly *should* have been, if we assume it's
> reasonable to expect those making this decision to be paying attention
> to this list.

I did forward that on to Leigh and Jim.

-- 
Matthew Miller

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

Re: CPE Git Forge Decision

On Tue, Mar 31, 2020 at 07:30:16PM +0200, Iñaki Ucar wrote:
> That's a false equivalence. Yes, many of us maintain projects on
> GitHub and/or GitLab due to a variety of reasons, but if any of them
> die tomorrow, I simply change the "upstream" in my clones and keep
> going. If Fedora starts using GitLab EE for its dist-git, for example,
> and GitLab dies tomorrow, then we have a very big problem.

Bigger scale, but isn't it basically the same problem?


-- 
Matthew Miller

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

Re: CPE Git Forge Decision

On Tue, 2020-03-31 at 13:08 -0400, Matthew Miller wrote:
> On Tue, Mar 31, 2020 at 10:48:55AM -0500, Michael Catanzaro wrote:
> > Some failure of process or communication must have occurred
> > somewhere along the lines, because open source should have been the
> > first and most important requirement. A proprietary software
> > solution is incompatible with the ethos and purpose of the Fedora
> > project. I ask CPE to revise its requirements list to include open
> > source as the first and most important requirement from the Fedora
> > community. If that's incompatible with CentOS's need for merge
> > request approvals or whatever else, then we need to accept that
> > sharing the same forge is simply not going to work.
> 
> Obviously open source is one of our key foundations. And it is part of who
> we are even before those foundations were drafted. Nonetheless, I want to
> gently discuss this a little bit. We make an entirely open source and free
> software operating system. We support and promote and advocate for open
> source and free content. But we can't do everything, and at some point, this
> becomes "this is why we can't have nice things". I see that you've made
> contributions to other open source projects on GitHub and (hosted) GitLab
> this month. Lots of Fedora contributors have and will continue to do so.
> Many use that as their main hosting. It's not ideal, but it's not the end of
> the world. I don't see Fedora making use of non-open hosted services as the
> end of the world either, if that is what is best for us.
> 
> We did communicate as the very top line of our gathered requirements that
> open source is essential to our community and central to our feedback. I'm
> not trying to be soft on that. Let's just not do purity-test level
> assessments and instead focus on our goals.

I'm sorry, but I have to agree with Kevin and Michael here to a
significant extent. Running our own project on open source code has
always been a very big bright line for Fedora.

I'm not necessarily saying it's a hill we should die on, but at the
very least, choosing a proprietary hosted solution for something as
fundamental as our dist-git needs to be treated as a Very Big Deal and
needs to be a decision that is handled a *lot* better than this one has
been handled.

You said in another email that the tooling choice ultimately has to be
largely made by the team that is responsible for the work and it
wouldn't really work for Council to order them to do something they
can't practically do, and I see the truth in that, but at the same time
I think there has to be a balance there. Does this "the team decides
what works for them" principle extend as far as the team being able to
choose unilaterally to go against principles Fedora has been working
very hard to maintain for about as long as it has existed, and that are
listed right up there front and centre as our Foundations? That, to me,
seems like a decision that Council ought at the very least to be deeply
involved in - much more than seems to have been the case here (which
seems to have been that we wrote up some requirements and sent them off
to "the team", which smooshed them into some kind of summary and then
made a decision - a decision which seems to have had a rather confused
context, as various people don't seem to be on the same page about
whether a choice was supposed to be made about "dist-git", or
"pagure.io", or "Pagure", or CentOS's or Red Hat's use of Pagure, or
any or all of these things somehow smooshed together).

I think if I turned up tomorrow and said that QA had decided we're
going to use a proprietary hosted service for managing release
validation testing there would be significant pushback against that,
and I think that pushback would be valid, and I'm not sure it would be
appropriate for us to say "tough, we made that decision so that's
what's happening". I don't think it's necessarily appropriate for that
to happen here either.

I understand there are practical resource considerations and so on
here, but I still think this merits more high level and serious
consideration. At the very least, if we have somehow reached a point
where Red Hat is no longer willing to provide sufficient resources to
run Fedora on the lines the Fedora community wants it to be run, we
need to recognize that this is a significant problem that needs to be
properly aired and discussed and resolved. In this context I'll note
that the apparent significant headcount reduction of RH people working
on Fedora infrastructure over the last few years is in itself a
worrying trend, particularly if you consider it while reading Clement's
email.

I think Iñaki's take on the "oh, you contribute to Github projects so
no problem right?" angle is correct.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list --

Re: CPE Git Forge Decision

On Tue, 2020-03-31 at 17:47 +0200, jkone...@redhat.com wrote:
> -- snip --
> > As for Pagure itself, I think this is where we fundamentally
> > disagree.
> > I think it behooves us to own and provide an experience tailored for
> > our community from beginning to end. That's why we have Koji, Bodhi,
> > Dist-Git, and many other tools in that part of the lifecycle. The
> > packager experience is literally the lifeblood of the project, and
> > our
> > contributors are the core of what makes Fedora successful. Pagure
> > gives us an opportunity to do right by them that I *really* don't
> > think we can do with any alternatives.
> > 
> > That does *not* mean that CPE team should be the sole owner of the
> > Pagure *codebase*. On that point, I agree. And that's why I've spent
> > a
> > lot of time and energy since late 2018 working on building up that
> > community. It's finally starting to bear fruit too: there's at least
> > one entity interested in building a product around it and
> > contributing
> > to help support that product, there's the FSF preparing to launch a
> > new forge using Pagure, there's the Trisquel GNU+Linux distribution
> > working on a Pagure deployment to host their code and packaging, and
> > there's a few other things I've got up my sleeve to help broaden the
> > community with not just users, but also contributors.
> 
> It's great to hear this. Thanks a lot Neal for trying to find
> consumers. I'm not sure if this information was available to Fedora
> infrastructure during the decision. It means that we may have another
> contributors.

I specifically mentioned at least the FSF angle on this mailing list,
over a month ago:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EJAKU3MO4T5ZEWEBUWIRSGBWTFQU44QK/

so at least that part certainly *should* have been, if we assume it's
reasonable to expect those making this decision to be paying attention
to this list.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: CPE Git Forge Decision

2020-03-31 Thread Iñaki Ucar

On Tue, 31 Mar 2020 at 19:15, Matthew Miller  wrote:
>
> On Tue, Mar 31, 2020 at 10:48:55AM -0500, Michael Catanzaro wrote:
> > Some failure of process or communication must have occurred
> > somewhere along the lines, because open source should have been the
> > first and most important requirement. A proprietary software
> > solution is incompatible with the ethos and purpose of the Fedora
> > project. I ask CPE to revise its requirements list to include open
> > source as the first and most important requirement from the Fedora
> > community. If that's incompatible with CentOS's need for merge
> > request approvals or whatever else, then we need to accept that
> > sharing the same forge is simply not going to work.
>
> Obviously open source is one of our key foundations. And it is part of who
> we are even before those foundations were drafted. Nonetheless, I want to
> gently discuss this a little bit. We make an entirely open source and free
> software operating system. We support and promote and advocate for open
> source and free content. But we can't do everything, and at some point, this
> becomes "this is why we can't have nice things". I see that you've made
> contributions to other open source projects on GitHub and (hosted) GitLab
> this month. Lots of Fedora contributors have and will continue to do so.
> Many use that as their main hosting. It's not ideal, but it's not the end of
> the world. I don't see Fedora making use of non-open hosted services as the
> end of the world either, if that is what is best for us.

That's a false equivalence. Yes, many of us maintain projects on
GitHub and/or GitLab due to a variety of reasons, but if any of them
die tomorrow, I simply change the "upstream" in my clones and keep
going. If Fedora starts using GitLab EE for its dist-git, for example,
and GitLab dies tomorrow, then we have a very big problem.

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

Re: Heads-up: RPM 4.16 alpha coming to rawhide

2020-03-31 Thread Gary Buhrmaster

On Tue, Mar 31, 2020 at 6:43 AM Panu Matilainen  wrote:

> Based on rpm-specs-latest.tar.xz from this morning, there are thirtysome
> packages relying on this behavior, which will need fixing to be
> buildable with 4.16.

Is there a list of those thirty something packages
somewhere so that those particular packagers
can potentially get a heads up?
___
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: fedpkg clone fails with Permission denied (publickey).

On Tue, Mar 31, 2020 at 12:11 PM Kevin Fenzi  wrote:

> On Tue, Mar 31, 2020 at 07:14:46AM -0500, Richard Shaw wrote:
> > However, I'm still not able to log into the test instances.
>
> Any of them? Odd. Can you file an infra ticket and we can look closer...
>

Let me try, I've only attempted rawhide so far.

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: Upgrade tooling

On Mon, Mar 30, 2020 at 10:13:19AM +0300, Panu Matilainen wrote:
> strategy into RHEL world, people could only start using file
> triggers and rich dependencies in RHEL and EPEL 9 which I can only
> assume will be released some year in the future. Think about that
> for a while.

For what it's worth, Red Hat has committed to an official three year cadence,
so you don't need to assume: it's 2022.

-- 
Matthew Miller

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

Re: Fedora 33 System-Wide Change proposal: Sqlite RpmDB

On Tue, Mar 31, 2020 at 02:46:01PM +0300, Panu Matilainen wrote:
> 
> The soname doesn't change and no dependencies on any rawhide
> latest-and-greatest otherwise, so from that side there shouldn't be any
> issues.
> 
> The only real incompatibility should be on the spec parse side - the bare
> word vs quoted strings thing in specs (as explained in my heads-up message),
> which affects a handful of packages but is also trivial for packagers to fix
> if they encounter it.

ok

> I could live with switching at beginning of May, but end of May / sometime
> in June is terribly late in the cycle for this. So if choosing between
> these, it'd kinda have to be with f31 builders.

ok. 

> OTOH there are various other possibilities too, including but probably not
> limited to:
> 
> a) Switch in two stages: override the database to bdb on builders, change
> rawhide on our own schedule and then remove builder override when it suits
> infra
> b) See if the copr bootstrap is usable now in koji
> c) Just leave the builders alone and see what happens. In theory it should
> all just work regardless as long as all installations are done from outside
> of the chroot.
> 
> In any case, we wont be switching anything at all before we have a working
> agreement with infra over the steps.

Sure. we can test some of these in staging. 

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: fedpkg clone fails with Permission denied (publickey).

On Tue, Mar 31, 2020 at 07:14:46AM -0500, Richard Shaw wrote:
> On Sun, Mar 29, 2020 at 1:28 PM Kevin Fenzi  wrote:
> 
> > On Sun, Mar 29, 2020 at 12:32:33PM -0500, Richard Shaw wrote:
> > > Long story short I lost my home directory where I do all of my packager
> > > activities (separate from my main user) so I'm setting things up from
> > > scratch.
> > >
> > > I created new ssh keys and uploaded the public key to
> > > admin.fedoraproject.org and pasted into pagure.io. It's been over an
> > hour
> > > and I'm still getting:
> >
> > Yeah, please try again now.
> >
> > Currently the sync time is really long due to various reasons.
> > I'll try and impove this next week...
> >
> > In the mean time I have done a manual sync.
> >
> 
> Thanks for that! Meant to say something earlier.
> 
> However, I'm still not able to log into the test instances.

Any of them? Odd. Can you file an infra ticket and we can look closer... 

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: CPE Git Forge Decision

On Tue, Mar 31, 2020 at 10:48:55AM -0500, Michael Catanzaro wrote:
> Some failure of process or communication must have occurred
> somewhere along the lines, because open source should have been the
> first and most important requirement. A proprietary software
> solution is incompatible with the ethos and purpose of the Fedora
> project. I ask CPE to revise its requirements list to include open
> source as the first and most important requirement from the Fedora
> community. If that's incompatible with CentOS's need for merge
> request approvals or whatever else, then we need to accept that
> sharing the same forge is simply not going to work.

Obviously open source is one of our key foundations. And it is part of who
we are even before those foundations were drafted. Nonetheless, I want to
gently discuss this a little bit. We make an entirely open source and free
software operating system. We support and promote and advocate for open
source and free content. But we can't do everything, and at some point, this
becomes "this is why we can't have nice things". I see that you've made
contributions to other open source projects on GitHub and (hosted) GitLab
this month. Lots of Fedora contributors have and will continue to do so.
Many use that as their main hosting. It's not ideal, but it's not the end of
the world. I don't see Fedora making use of non-open hosted services as the
end of the world either, if that is what is best for us.

We did communicate as the very top line of our gathered requirements that
open source is essential to our community and central to our feedback. I'm
not trying to be soft on that. Let's just not do purity-test level
assessments and instead focus on our goals.

-- 
Matthew Miller

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

Re: Nvidia binary drivers fail to install on Fedora 32

...snip...

Perhaps you all could take this to the rpmfusion mailing lists?

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: What is the proper way to handle python3 python36 in RHEL7

2020-03-31 Thread Stephen Gallagher

On Tue, Mar 31, 2020 at 12:51 PM Erinn Looney-Triggs
 wrote:
>
> I am trying to build a package for RHEL 7 and RHEL 8 that depends on an EPEL 
> (for RHEL 7) package python36-dbus the requires section goes like so:
> Requires: %{python3}
> Requires: %{python3}-dbus
>
> This puts in a requirement for python3-dbus for RHEL 7 which doesn't exist, 
> the package is actually python36-dbus, however short of a conditional saying 
> if rhel 7 then package name is python36-dbus is there a clean and scalable 
> way to make sure the package version is correct?
>
> I am looking into python3_pkgversion macro but that doesn't seem to be 
> correct either. Does anyone know how I should do this now with a single spec 
> file for both RHEL 7 and 8 that doesn't contain a conditional expression?

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

There's a bug in the macros.
___
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] What is the proper way to handle python3 python36 in RHEL7

2020-03-31 Thread Erinn Looney-Triggs

I am trying to build a package for RHEL 7 and RHEL 8 that depends on an EPEL 
(for RHEL 7) package python36-dbus the requires section goes like so:
Requires: %{python3}
Requires: %{python3}-dbus

This puts in a requirement for python3-dbus for RHEL 7 which doesn't exist, the 
package is actually python36-dbus, however short of a conditional saying if 
rhel 7 then package name is python36-dbus is there a clean and scalable way to 
make sure the package version is correct?

I am looking into python3_pkgversion macro but that doesn't seem to be correct 
either. Does anyone know how I should do this now with a single spec file for 
both RHEL 7 and 8 that doesn't contain a conditional expression? 

Thanks,
-Erinn
___
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: Heads-up: RPM 4.16 alpha coming to rawhide

2020-03-31 Thread Björn Persson

Panu Matilainen wrote:
> new expression features (in 
> spec %if and macros) including but not limited to ternary operator (eg 
> %[1==0?"yes":"no"])

For dependencies I'm told that the syntax is
 if  else . So the syntax for
conditional expressions is different in different contexts within the
RPM spec language?

Björn Persson


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

Re: Koji is failing on s390x

2020-03-31 Thread Dan Horák

On Tue, 31 Mar 2020 17:36:28 +0200
Jun Aruga  wrote:

> Koji is failing to build before creating root.log and build.log on
> s390x right now.
> Is it a known issue?
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=42916760
> https://koji.fedoraproject.org/koji/taskinfo?taskID=42916889
> 
> Traceback (most recent call last):
>   File "/usr/lib/python3.7/site-packages/koji/daemon.py", line 1294,
> in runTask response = (handler.run(),)
>   File "/usr/lib/python3.7/site-packages/koji/tasks.py", line 313, in
> run return koji.util.call_with_argcheck(self.handler, self.params,
> self.opts) File "/usr/lib/python3.7/site-packages/koji/util.py", line
> 263, in call_with_argcheck
> return fu ...

should be https://pagure.io/koji/issue/1974

What's the size of the srpm?


Dan
___
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 1799856] perl-Syntax-Highlight-Perl6: FTBFS in Fedora rawhide/f32

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

Petr Pisar  changed:

   What|Removed |Added

   Fixed In Version||perl-STD-2010-19.fc33



-- 
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: Nvidia binary drivers fail to install on Fedora 32

2020-03-31 Thread Gary Buhrmaster

On Tue, Mar 31, 2020 at 3:57 PM Kevin Kofler  wrote:

> But ideally 

You seem to have a lot of thoughts about changes
and improvements to the process.

When should the RPMFusion community expect
you to complete those improvements?
___
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: Nvidia binary drivers fail to install on Fedora 32

2020-03-31 Thread Kevin Kofler

Leigh Scott wrote:
> Your kmod idea is flawed, the new kernel builds will always be at
> least 7 days behind fedora kernel. This is due to 2 pushes being required
> to get the new akmods to stable repo, I haven't got enough time  to do
> more pushes (sign, mash and sync repo's).

That also really calls for more automation. Also, an automated rebuild 
against a kernel that is already in Fedora stable updates should go directly 
to stable and so require only 1 push, not 2.

But ideally, the automated rebuild would already happen when the kernel is 
in Fedora updates-testing and the kmod would then end up in testing. Then, 
when the Fedora update goes stable, the RPM Fusion kmod should also (ideally 
automatically) go to stable. So you would always be at most 1 push behind, 
and the goal is to ensure that the push happens in a timely manner through 
better automation. (The push should just be a matter of you clicking on a 
button or running a ./push.sh script and not consume your time as it seems 
to do right now, judging from your description. And the kmod rebuilds should 
really be completely automatic and not require you to do anything at all.)

As for the inevitable synchronization issue that will happen anyway (also 
due to mirroring), have you seen my boolean Requires proposal? I think that 
implementing that correctly should guarantee that the kernel and the kmod 
are only upgraded together (without requiring special handling in DNF as in 
the old experimental Yum plugin). In principle, that should even work if the 
kmod is 7-14 days behind depending on schedule alignment.

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

Re: CPE Git Forge Decision

2020-03-31 Thread Michael Catanzaro

On Tue, Mar 31, 2020 at 12:42 pm, Kevin Kofler  
wrote:

What really worries to me is that:
* using GitLab as SaaS is being considered, and
* for self-hosting, using the proprietary "enterprise" editions is not
  excluded.

I think that using anything other than Free Software as the hosting 
platform
for Fedora should be an absolute no go. In other words, self-hosted 
GitLab

CE or Pagure, no other options.


Very rare for me to say this, but: I agree with Kevin.

As I see it, the Fedora community was not interested in GitHub because 
it's not open source. It seemed like we all agreed on that, and I 
assume Council communicated that to CPE. Now, GitLab Community Edition 
(GitLab CE) is open source (and high-quality), but it seems almost 
certain that the plan is to use GitLab Enterprise Edition (GitLab EE). 
Although CPE says they continue to evaluate which edition will used and 
how it will be hosted, the identified requirements clearly cannot be 
satisfied by GitLab CE.


Some failure of process or communication must have occurred somewhere 
along the lines, because open source should have been the first and 
most important requirement. A proprietary software solution is 
incompatible with the ethos and purpose of the Fedora project. I ask 
CPE to revise its requirements list to include open source as the first 
and most important requirement from the Fedora community. If that's 
incompatible with CentOS's need for merge request approvals or whatever 
else, then we need to accept that sharing the same forge is simply not 
going to work.


If open source is really not going to be a requirement, then we can ask 
Council to politely reject CPE's offer to continue hosting our forge, 
and instead round up some budget to keep Pagure running without help 
from CPE.


Michael

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

Re: CPE Git Forge Decision

2020-03-31 Thread jkonecny

-- snip --
> 
> As for Pagure itself, I think this is where we fundamentally
> disagree.
> I think it behooves us to own and provide an experience tailored for
> our community from beginning to end. That's why we have Koji, Bodhi,
> Dist-Git, and many other tools in that part of the lifecycle. The
> packager experience is literally the lifeblood of the project, and
> our
> contributors are the core of what makes Fedora successful. Pagure
> gives us an opportunity to do right by them that I *really* don't
> think we can do with any alternatives.
> 
> That does *not* mean that CPE team should be the sole owner of the
> Pagure *codebase*. On that point, I agree. And that's why I've spent
> a
> lot of time and energy since late 2018 working on building up that
> community. It's finally starting to bear fruit too: there's at least
> one entity interested in building a product around it and
> contributing
> to help support that product, there's the FSF preparing to launch a
> new forge using Pagure, there's the Trisquel GNU+Linux distribution
> working on a Pagure deployment to host their code and packaging, and
> there's a few other things I've got up my sleeve to help broaden the
> community with not just users, but also contributors.

It's great to hear this. Thanks a lot Neal for trying to find
consumers. I'm not sure if this information was available to Fedora
infrastructure during the decision. It means that we may have another
contributors.

I think Fedora Infra should talk to these potential contributors to
find out how much they are willing to contribute to Pagure and re-think 
the decision based on that. It's big difference if this is just a
Fedora tool or if it is used and developed by others too.

Jirka

> 
> Are there deficiencies in Pagure? Of course there are. I'm not
> claiming that Pagure is perfect. But I think that keeping on with
> Pagure and giving that community an opportunity to close the gap on
> needed features for Fedora/CentOS/Red Hat is the right way to go.
> Right now, I don't *know* what the important gaps are. I can make
> some
> guesses, but it'd be a lot better if we had a list of missing
> features
> and their relative important and why. That would help focus
> development to meet those needs.
> 
> The Fedora community itself has indicated that they want to keep on
> with Pagure, and many Fedorans are Pythonistas, which means that
> everyone can easily contribute to help make it better for everyone.
> 
> Anyway, I hope this helps clarify my position on the matter!
> 
> [1]: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/Y5XXXHJCSDMOHA7FEZ3DNZYPGCTZBVH6/
> 
> 
> 
> 
> -- 
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
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 1799856] perl-Syntax-Highlight-Perl6: FTBFS in Fedora rawhide/f32

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

Petr Pisar  changed:

   What|Removed |Added

  Flags|needinfo?(jplesnik@redhat.c |
   |om) |



--- Comment #11 from Petr Pisar  ---
This is caused by perl-STD. I will fix it and rebuild this package.

-- 
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: CPE Git Forge Decision

2020-03-31 Thread jkonecny

On Tue, 2020-03-31 at 12:47 +0200, Felix Schwarz wrote:
> Am 31.03.20 um 12:42 schrieb Kevin Kofler:
> > I think that using anything other than Free Software as the hosting
> > platform 
> > for Fedora should be an absolute no go. In other words, self-hosted 
> > GitLab 
> > CE or Pagure, no other options.
> 
> +1 with one minor(?) exception:
> I'm ok with using a hosted version provided that the software (and
> its
> dependencies) is part of the Fedora repos and there are provisions to
> extract
> the data (e.g. database) from the hosted version without any data
> loss and
> load it in a self-hosted version using Fedora RPMs.

+1 from me too. We really should not use proprietary for Fedora. It's
similar to use Windows machines to build Linux kernel.


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

[EPEL-devel] Re: RHEL8 package list

2020-03-31 Thread Troy Dawson

On Tue, Mar 31, 2020 at 7:55 AM Kevin Fenzi  wrote:
>
> On Tue, Mar 31, 2020 at 06:49:45AM -, Mattia Verga wrote:
> > > On Sun, Mar 29, 2020 at 10:52 AM Kevin Fenzi 
> To be clear, I didn't write this, Troy did. ;)
>
> > >
> > > Please file a bug in bugzilla, requesting both of these to be added to 
> > > EPEL8.
> > > It's possible that we might need to use the older version from Fedora
> > > 30 (kpmcore-3.3.0-5 and kde-partitionmanager-3.3.1-4)
> > >
> > > Troy
> > Yes, currently there are old versions of both in epel8-playground (those 
> > you built some time ago)... I only wanted to check if there was the 
> > possibility to upgrade them to the latest version, but util-linux is still 
> > too old to support them.
> >
> > Mattia
>
> kevin

I can now elaborate a little bit more.
A few weeks ago I tried to update kpmcore and kde-partitionmanager in
my preparation for the qt5/kde update that is coming with RHEL 8.2.
But with no luck.  Even when I forced the rpm build to try to use the
older util-linux, things didn't build properly.

So, in summary, I will try to get pdmcore and kde-partitionmanager
into regular EPEL8, and not just playground.
During the upcoming qt5/kde/plasma update that is going to happen with
RHEL 8.2, those two packages will not be updated.
The testing I have done (not extensive) shows that, although older,
they still work.

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

Koji is failing on s390x

2020-03-31 Thread Jun Aruga

Koji is failing to build before creating root.log and build.log on
s390x right now.
Is it a known issue?

https://koji.fedoraproject.org/koji/taskinfo?taskID=42916760
https://koji.fedoraproject.org/koji/taskinfo?taskID=42916889

Traceback (most recent call last):
  File "/usr/lib/python3.7/site-packages/koji/daemon.py", line 1294, in runTask
response = (handler.run(),)
  File "/usr/lib/python3.7/site-packages/koji/tasks.py", line 313, in run
return koji.util.call_with_argcheck(self.handler, self.params, self.opts)
  File "/usr/lib/python3.7/site-packages/koji/util.py", line 263, in
call_with_argcheck
return fu ...

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

Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V3

2020-03-31 Thread Stephen Gallagher

I sent out the V2 version of the Change on Friday and then promptly
managed to injure myself and be away from email until today. I've read
through the email threads again this morning and I decided that,
rather than try to address them one by one, I'd try again with a V3
that hopefully answers some of the repeated questions and concerns on
that list.

Please see the newly-updated
https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
for more details[1].


[1] 
https://fedoraproject.org/w/index.php?title=Changes%2FELN_Buildroot_and_Compose=revision=569904=569809
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org

Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V3

2020-03-31 Thread Stephen Gallagher

I sent out the V2 version of the Change on Friday and then promptly
managed to injure myself and be away from email until today. I've read
through the email threads again this morning and I decided that,
rather than try to address them one by one, I'd try again with a V3
that hopefully answers some of the repeated questions and concerns on
that list.

Please see the newly-updated
https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
for more details[1].


[1] 
https://fedoraproject.org/w/index.php?title=Changes%2FELN_Buildroot_and_Compose=revision=569904=569809
___
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: The Git forge decision (was CPE Weekly: 2020-03-28)

On Tue, Mar 31, 2020 at 09:30:57AM -0500, Bruno Wolff III wrote:
> It's more than that. While the community edition of gitlab (assuming
> we don't get stuck with the proprietary version) is technically open
> source, the main fork is run by Gitlab who have a conflict of
> interest in adding features that compete with their enterprise
> edition. If it comes down to needing a change they don't want to
> add, then we need to be willing to maintain a fork or switch to
> something else. While this is true for a lesser amount for using any
> free software, there normally isn't the same incentive for most
> projects to reject enhancements submitted back upstream.

Sure, this is a reasonable concern. Open core isn't my favorite
business model. But, doing open source as a business is hard. Not
everyone can be Red Hat. :) We have good relationships with people over
there -- I've talked with them before about other things -- and I think
we'll be able to navigate anything that comes up.

-- 
Matthew Miller

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

Re: CPE Git Forge Decision

2020-03-31 Thread Neal Gompa

On Tue, Mar 31, 2020 at 10:37 AM Bruno Wolff III  wrote:
>
> On Tue, Mar 31, 2020 at 12:55:39 +0200,
>   Tomasz Torcz  wrote:
> >
> >  Being self-hosted is a nice goal, but not important enough.
> >There are parts of Fedora infrastructure which are not using Fedora,
> >but other distributions like RHEL.  We seem to have not problem in
> >using proprietary SAAS solutions for critical stuff.
>
> RHEL is a special case, as CENTOS provides a free drop in replacement and
> switching from CENTOS to Fedora shouldn't be much work. Is there other
> proprietary software at the OS level or above, that is used for Fedora
> infrastructure?
>

The only part of Fedora Infrastructure itself that is proprietary (to
the best of my knowledge) is the NetApp storage appliances that have
been in place since Koji was deployed back in 2007. I think if we were
to do this all over again today, we would be using Gluster or Ceph,
but it's a ton of work for no gain to change storage stuff right now.

The change to SaaS GitLab will make a user-facing visible change to a
proprietary solution for the core of the distribution. And even
ignoring that, I sincerely think the user experience will be much
worse with almost no avenue to fix it.

> >  I truly envy Debian and their ability to dogfood, running their
> >infra on Debian. With minor exception: although they self-host GitLab,
> >it seems to be different than their distribution packages.
>
> I think the difference is the support window for Fedora. In a way CENTOS
> is an LTS version of Fedora.

Over the years, more of Fedora Infrastructure has migrated from RHEL
to Fedora because RHEL doesn't work out very well for some of our
infrastructure.

For example, all the Koji builders are on Fedora, as is Bodhi. While
it is true that RHEL/CentOS can be considered somewhat as an LTS of
Fedora, it's not an equivalent distribution. Red Hat makes different
choices and cuts down what's available dramatically. The discussion
about ELN pushes that distinction to the forefront.

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

[Bug 1799856] perl-Syntax-Highlight-Perl6: FTBFS in Fedora rawhide/f32

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|jples...@redhat.com |ppi...@redhat.com



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

[389-devel] Re: Please have a look at rewriters design

2020-03-31 Thread Ludwig Krispenz

Hi,

I was away and am late in the discussion, maybe too late.

In my understanding what you mean by "generic" is that for a new
rewriter you do not need a plugin, but to provide some rewrite functions
and specify them in a rewriters config entry. But there is still the
need to write rewriter functions, compile and deploy them, and instead
of plugins you now have a new interface of "filterRewriter" and
"returendAttrRewriter functions - so far not documented anywhere.

Under generic rewriter I would understand an approach where you do not
need to provide own functions, but have a rewriter plugin, which does
rewriting based on rules in rewrite config entries, eg in which subtree,
for which entries (filter to select), how to map a saerch filter, how to
rename attrs on return,

Best regards,
Ludwig

On 03/19/2020 01:09 AM, William Brown wrote:

On 19 Mar 2020, at 04:08, thierry bordaz wrote:

On 3/18/20 1:51 AM, William Brown wrote:

On 18 Mar 2020, at 04:08, thierry bordaz wrote:

Hi William,

I updated the design according to our offline exchange

Thanks Thierry, I appreciate the conversation and the updates to the document:
it made clear there were extra details up in your brain but not in words yet :)
it's always hard to remember all the details as we write things, so thanks for
the discussion. Like you said, it's always good to have a team who is really
invested and cares about the work we do!

Your design for the core server version looks much better! Thank you. I still
think there are some missing points. The reason to have a libpath rather than
inbuild is to avoid a potential linking to sssd/samba. I think also that the
problem space of the global catalog here needs to be looked at too. This
feature is not in isolation, it's really a part of that.

Okay, I will work on a new PR making core server able to retrieve/registers
rewriters.

I think the "need" to improve the usability of rewriters is not specific to
global catalog. Global Catalog is just an opportunity to implement it. I think parts of
slapi-nis, integration of vsphere, GC (and likely others) are also use case for
rewriters. They were implemented in different ways because rewriters were not easy to use
or simply not known.

Yes, that's perfectly reasonable, and shouldn't stop your idea from being
created - what's concerning me is that without a full picture you don't know
how far to take these rewriters or what direction, or what might be needed.

This means we have a whole set of deployment cases to look at.

So the deployment will look like:

IPA DS --> IPA GC

So an ipaAccount from the IPA DS instance will be "copied and transformed" into
the IPA GC. This process is as yet undefined (it sounds like it may be offline or
something else ...). We are simply not dealing with one instance now, but an out-of-band
replication and transformation process. It's unclear whether the data transform is during
this loading process, or in the IPA GC somehow.

From what I understand, it sounds like a method to take an ipaAccount and
transform it to an AD GC account stub. Then inside of that IPA GC there are
some virtual attributes you wish to add like objectSid binary vs string
representations, objectCategory, maybe others.

So from our discussion, we have currently focused on "how do we transform entries
within a single directory server". But that's not the problem here. We are saying:

"We take an entry from IPA DS, transform it to an IPA GC stub entry, and then apply a set of
further "in memory" transformations"

One of the biggest issue with GC is schema. IPA DS and IPA GC have not
compatible schema. They can not be in the same replication topology.
So provisioning of IPA GC requires transformations rules to present an other
"view" of IPA DS data. Those transformations will be on the write path (i.e.
stored in DB/indexed). This transformation work is almost done and is completely
independent of 389-ds.
All of this is "write" path: provisioning (online or offline) and
transformation.

The problem for IPA GC is now on the "read" path. AD clients are use to smart
shortcuts/control that are supported by IPA GC.
This is the IPA GC instance that will register the rewriters to act as GC does.

Yep, I'm aware :)

If that's the process, why not do all the transforms as required in the DS -> GC
load process? You raised a critically key point - we have a concern about the write
path as the transform point due to IO or time to do the transform, but it sounds like
you have to do this anyway as an element of the DS -> GC process.

Some of the transformation rules, on the write path, are quite complex. Looking
at slapi-nis config entries gives an idea what is needed. In addition to those
transformations, DS to GC online provisioning is not simple at all. Relying on
sync-repl, you then need to transform a received entry into an update. At the
moment it is an offline provisioning via transformation and

[EPEL-devel] Re: RHEL8 package list

On Tue, Mar 31, 2020 at 06:49:45AM -, Mattia Verga wrote:
> > On Sun, Mar 29, 2020 at 10:52 AM Kevin Fenzi  > 
> > Please file a bug in bugzilla, requesting both of these to be added to 
> > EPEL8.
> > It's possible that we might need to use the older version from Fedora
> > 30 (kpmcore-3.3.0-5 and kde-partitionmanager-3.3.1-4)
> > 
> > Troy
> Yes, currently there are old versions of both in epel8-playground (those you 
> built some time ago)... I only wanted to check if there was the possibility 
> to upgrade them to the latest version, but util-linux is still too old to 
> support them.
> 
> Mattia

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

Re: The Git forge decision (was CPE Weekly: 2020-03-28)

2020-03-31 Thread Bruno Wolff III


On Tue, Mar 31, 2020 at 10:33:46 -0400,
 Matthew Miller  wrote:


I understand the attachment we have as a project to Pagure -- someone
in our community made it, after all, and lots of others have made
direct and indirect contributions. I feel that too! But, we all know
that it needs significant development work for scaling, stability, and
features.


It's more than that. While the community edition of gitlab (assuming we 
don't get stuck with the proprietary version) is technically open source, 
the main fork is run by Gitlab who have a conflict of interest in adding 
features that compete with their enterprise edition. If it comes down to 
needing a change they don't want to add, then we need to be willing to 
maintain a fork or switch to something else. While this is true for a 
lesser amount for using any free software, there normally isn't the 
same incentive for most projects to reject enhancements submitted back 
upstream.

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

Re: Fedora 33 System-Wide Change proposal: java-11-openjdk as system JDK in F33

On 30. 03. 20 18:52, Miro Hrončok wrote:

On 30. 03. 20 17:47, Jiri Vanek wrote:

On 3/30/20 5:04 PM, Miro Hrončok wrote:

On 30. 03. 20 16:04, Ben Cotton wrote:

* Contingency mechanism: Return jdk8 as system jdk and mass rebuild
again. Note, that this may be very hard, because during build of
packages by jdk8, by jdk11 built dependencies will be picekd up, so
build will fail. Maybe several iterations of mass rebuild will be
needed.

Can we lease do this in a side tag instead and verify basic functionality
before we merge it to

rawhide? Than the contingency might just be: Don't merge the side tag.

Sounds like good idea..the way how to go. Only I'm not familiar with how it
works.

Note that it implies that the change owners coordinate the rebuilds.

See this documentation for how we do Python upgrades of this sort (except in
Python, we need to rebuild "everything" and in a correct order, while the Java
thing seem to generally run fine when built with an older version, so tings get
easier for you):

https://fedoraproject.org/wiki/SIGs/Python/UpgradingPython#Once_ready.2C_move_into_Fedora_proper

Feel free to reach out to me in case you'd like to talk about this more. The
linked document is not very user friendly.

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

Re: CPE Git Forge Decision

2020-03-31 Thread Bruno Wolff III


On Tue, Mar 31, 2020 at 12:55:39 +0200,
 Tomasz Torcz  wrote:


 Being self-hosted is a nice goal, but not important enough.
There are parts of Fedora infrastructure which are not using Fedora,
but other distributions like RHEL.  We seem to have not problem in
using proprietary SAAS solutions for critical stuff.


RHEL is a special case, as CENTOS provides a free drop in replacement and 
switching from CENTOS to Fedora shouldn't be much work. Is there other 
proprietary software at the OS level or above, that is used for Fedora 
infrastructure?



 I truly envy Debian and their ability to dogfood, running their
infra on Debian. With minor exception: although they self-host GitLab,
it seems to be different than their distribution packages.


I think the difference is the support window for Fedora. In a way CENTOS 
is an LTS version of 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: The Git forge decision (was CPE Weekly: 2020-03-28)

On Mon, Mar 30, 2020 at 10:20:00AM +0200, Miro Hrončok wrote:
> The original proposal promised Fedora Council involvement. I wonder
> where that happened, I could not found any Pagure ticket nor a
> Council mailing list thread about this.

We were asked to help collect the user stories and requirements. We
also gave the strong feedback that the community wasn't interested in
GitHub for a variety of reasons, which isn't a user-story per se but
obviously important.

I understand the attachment we have as a project to Pagure -- someone
in our community made it, after all, and lots of others have made
direct and indirect contributions. I feel that too! But, we all know
that it needs significant development work for scaling, stability, and
features.

Miro says somewhere else in this thread 

   FESCo cannot actually make anyone do anything. So even if FESCo
   says: "The dist-git will run on Pagure", CPE can say: "Whatever, but
   we are not maintaining it."

This is true of the Council as well, of course. Ultimately, the CPE
team is going to put huge amounts of time, effort, and money into
running this. So, I feel very comfortable in saying that this really is
that team's decision to make.

At the same time, having a dist-git and a git-forge at all is totally
meaningless if the Fedora contributor community's needs aren't served.
I see the Council's role here in making sure they are.

And, while obviously communication could have been better and maybe a
longer process would have helped, ultimately, I have a lot of trust for
the people who work on CPE. Let's help them figure out how to best help
all of us.

-- 
Matthew Miller

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

[Bug 1799856] perl-Syntax-Highlight-Perl6: FTBFS in Fedora rawhide/f32

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



--- Comment #10 from Petr Pisar  ---
This is triggered with updating perl-YAML-LibYAML from 1:0.80-1.fc32 to
1:0.81-1.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

[Bug 1799856] perl-Syntax-Highlight-Perl6: FTBFS in Fedora rawhide/f32