Re: how to set passwrod for Fedora LiveCD (Fedora 30)?
Thanks, but that is what I thought I did. sed ' /#default_user/a\ default_user liveuser ' /etc/slim.conf sed ' /#auto_login/a\ autologin yes ' /etc/slim.conf sed ' /sessions/ c\ sessions openbox ' /etc/slim.conf I will try Samuel's suggestion. Thanks! On Friday, May 31, 2019, 12:33:14 AM CDT, Julen Landa Alustiza wrote: What about configuring the dm to autologin with liveuser? On May 31, 2019 7:07:32 AM GMT+02:00, Samuel Sieb wrote: >On 5/30/19 6:45 AM, Globe Trotter via devel wrote: >> Thanks! I posted the kickstart file earlier, but I have no other >lines >> to set the password, but I still get prompted for a password. > >I assume you've tried just pressing enter with no password? > >> So I was wondering if I can explicitly set the password so that I >know >> what to type when it asks for one. > >You can add a line like the following: >user --groups=wheel --name=myuser --password="" >That should create a user with no password. > >> I did not have a problem with this in F29. I was not asked for the >> password. Something changed with regard to permissions in F30 and I >am >> trying to find out what/or how to set the password. > >I don't see anything in the kickstart files that would change that, but > >maybe if you can login as a different user, you can look around and see > >what's happened. Or you could mount the live filesystem and see if you > >can find something. >___ >devel mailing list -- devel@lists.fedoraproject.org >To unsubscribe send an email to devel-le...@lists.fedoraproject.org >Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html >List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >List Archives: >https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Julen Landa Alustiza ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: how to set passwrod for Fedora LiveCD (Fedora 30)?
What about configuring the dm to autologin with liveuser? On May 31, 2019 7:07:32 AM GMT+02:00, Samuel Sieb wrote: >On 5/30/19 6:45 AM, Globe Trotter via devel wrote: >> Thanks! I posted the kickstart file earlier, but I have no other >lines >> to set the password, but I still get prompted for a password. > >I assume you've tried just pressing enter with no password? > >> So I was wondering if I can explicitly set the password so that I >know >> what to type when it asks for one. > >You can add a line like the following: >user --groups=wheel --name=myuser --password="" >That should create a user with no password. > >> I did not have a problem with this in F29. I was not asked for the >> password. Something changed with regard to permissions in F30 and I >am >> trying to find out what/or how to set the password. > >I don't see anything in the kickstart files that would change that, but > >maybe if you can login as a different user, you can look around and see > >what's happened. Or you could mount the live filesystem and see if you > >can find something. >___ >devel mailing list -- devel@lists.fedoraproject.org >To unsubscribe send an email to devel-le...@lists.fedoraproject.org >Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html >List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >List Archives: >https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Julen Landa Alustiza 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
jplesnik pushed to perl-IO-FDPass (master). "Perl 5.30 rebuild"
Notification time stamped 2019-05-31 05:31:57 UTC
From 2a63f8167f2ba255f3ce7a7626012375e61581bc Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova
Date: May 31 2019 05:31:50 +
Subject: Perl 5.30 rebuild
---
diff --git a/perl-IO-FDPass.spec b/perl-IO-FDPass.spec
index 8565b44..ae13c9c 100644
--- a/perl-IO-FDPass.spec
+++ b/perl-IO-FDPass.spec
@@ -1,6 +1,6 @@
Name: perl-IO-FDPass
Version: 1.2
-Release: 9%{?dist}
+Release: 10%{?dist}
Summary: Pass a file descriptor over a socket
License: GPL+ or Artistic
URL: https://metacpan.org/release/IO-FDPass
@@ -62,6 +62,9 @@ make test
%{_mandir}/man3/IO::FDPass.3*
%changelog
+* Fri May 31 2019 Jitka Plesnikova - 1.2-10
+- Perl 5.30 rebuild
+
* Fri Feb 01 2019 Fedora Release Engineering - 1.2-9
- Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
https://src.fedoraproject.org/rpms/perl-IO-FDPass/c/2a63f8167f2ba255f3ce7a7626012375e61581bc?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
jplesnik pushed to perl-WWW-Form-UrlEncoded (master). "Perl 5.30 rebuild"
Notification time stamped 2019-05-31 05:13:41 UTC
From 7856d9037b217eb5b6f0d7543fa24014ae419f79 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova
Date: May 31 2019 05:13:34 +
Subject: Perl 5.30 rebuild
---
diff --git a/perl-WWW-Form-UrlEncoded.spec b/perl-WWW-Form-UrlEncoded.spec
index 2ccc6cf..6570723 100644
--- a/perl-WWW-Form-UrlEncoded.spec
+++ b/perl-WWW-Form-UrlEncoded.spec
@@ -1,6 +1,6 @@
Name: perl-WWW-Form-UrlEncoded
Version:0.25
-Release:2%{?dist}
+Release:3%{?dist}
Summary:Parser and builder for application/x-www-form-urlencoded
License:GPL+ or Artistic
URL:https://metacpan.org/release/WWW-Form-UrlEncoded
@@ -60,6 +60,9 @@ like HTTP::Body's urlencoded parser.
%{_mandir}/man3/*
%changelog
+* Fri May 31 2019 Jitka Plesnikova - 0.25-3
+- Perl 5.30 rebuild
+
* Sat Feb 02 2019 Fedora Release Engineering -
0.25-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
https://src.fedoraproject.org/rpms/perl-WWW-Form-UrlEncoded/c/7856d9037b217eb5b6f0d7543fa24014ae419f79?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
jplesnik pushed to perl-Sub-Exporter-Lexical (master). "Perl 5.30 rebuild"
Notification time stamped 2019-05-31 05:12:31 UTC
From 74b9e802ed5f234665ef533a35cf35cff36e65e4 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova
Date: May 31 2019 05:12:24 +
Subject: Perl 5.30 rebuild
---
diff --git a/perl-Sub-Exporter-Lexical.spec b/perl-Sub-Exporter-Lexical.spec
index 29f5dd2..ff739c5 100644
--- a/perl-Sub-Exporter-Lexical.spec
+++ b/perl-Sub-Exporter-Lexical.spec
@@ -1,6 +1,6 @@
Name: perl-Sub-Exporter-Lexical
Version:0.092292
-Release:8%{?dist}
+Release:9%{?dist}
Summary:Export lexically-available subs with Sub::Exporter
License:GPL+ or Artistic
URL:https://metacpan.org/release/Sub-Exporter-Lexical
@@ -54,6 +54,9 @@ rm $RPM_BUILD_ROOT%{perl_vendorlib}/Sub/Exporter/snippet.pl
%{_mandir}/man3/*
%changelog
+* Fri May 31 2019 Jitka Plesnikova - 0.092292-9
+- Perl 5.30 rebuild
+
* Sat Feb 02 2019 Fedora Release Engineering -
0.092292-8
- Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
https://src.fedoraproject.org/rpms/perl-Sub-Exporter-Lexical/c/74b9e802ed5f234665ef533a35cf35cff36e65e4?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: how to set passwrod for Fedora LiveCD (Fedora 30)?
On 5/30/19 6:45 AM, Globe Trotter via devel wrote: Thanks! I posted the kickstart file earlier, but I have no other lines to set the password, but I still get prompted for a password. I assume you've tried just pressing enter with no password? So I was wondering if I can explicitly set the password so that I know what to type when it asks for one. You can add a line like the following: user --groups=wheel --name=myuser --password="" That should create a user with no password. I did not have a problem with this in F29. I was not asked for the password. Something changed with regard to permissions in F30 and I am trying to find out what/or how to set the password. I don't see anything in the kickstart files that would change that, but maybe if you can login as a different user, you can look around and see what's happened. Or you could mount the live filesystem and see if you can find something. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
jplesnik pushed to perl-Encode-IMAPUTF7 (master). "Perl 5.30 rebuild"
Notification time stamped 2019-05-31 05:02:05 UTC
From 6cddf4b024ef1efa0cc6339aea717d52ba7abf97 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova
Date: May 31 2019 05:01:58 +
Subject: Perl 5.30 rebuild
---
diff --git a/perl-Encode-IMAPUTF7.spec b/perl-Encode-IMAPUTF7.spec
index e3d1419..128900e 100644
--- a/perl-Encode-IMAPUTF7.spec
+++ b/perl-Encode-IMAPUTF7.spec
@@ -2,7 +2,7 @@
Name: perl-Encode-IMAPUTF7
Version:1.05
-Release:9%{?dist}
+Release:10%{?dist}
Summary:Process the special UTF-7 variant required by IMAP
License:GPL+ or Artistic
URL:https://metacpan.org/release/Encode-IMAPUTF7
@@ -42,6 +42,9 @@ make test
%_mandir/man3/*
%changelog
+* Fri May 31 2019 Jitka Plesnikova - 1.05-10
+- Perl 5.30 rebuild
+
* Fri Feb 01 2019 Fedora Release Engineering -
1.05-9
- Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
https://src.fedoraproject.org/rpms/perl-Encode-IMAPUTF7/c/6cddf4b024ef1efa0cc6339aea717d52ba7abf97?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[389-devel] 389 DS nightly 2019-05-31 - 93% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2019/05/31/report-389-ds-base-1.4.1.2-2.fc30.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
Re: xindy, texlive, and concurrency
On Sat, May 18, 2019 at 5:46 PM Kevin Fenzi wrote: > Also, If it's just a lack of funds stopping you from getting to Hungary, > we do have sponsorship, so might be work putting in for that. (Or course > it could be any number of other things, but thought I would mention it > if it's just funds. :) Good grief, I never replied to this. Sorry. My email inbox is in a state of perpetual disarray. Thanks for the tip. I'll have to talk this over with my spouse and boss, the two people who will care most if I'm gone for a few days. :-) -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-612bab5fc3 drupal7-7.67-1.el6 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-5ff064965f drupal7-entity-1.9-1.el6 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-50e0fd4815 drupal7-ds-2.16-1.el6 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-fe7c636c57 drupal7-uuid-1.2-1.el6 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-6326ff7745 drupal7-xmlsitemap-2.6-1.el6 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-65bad7ac43 drupal7-context-3.10-1.el6 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-5621f2527a drupal7-path_breadcrumbs-3.4-1.el6 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-1af316b5db drupal7-module_filter-2.2-1.el6 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-e90e3284bc drupal7-views-3.23-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing mozilla-https-everywhere-2019.5.13-1.el6 singularity-3.2.1-1.el6 spectre-meltdown-checker-0.42-1.el6 Details about builds: mozilla-https-everywhere-2019.5.13-1.el6 (FEDORA-EPEL-2019-84fd95bff3) HTTPS enforcement extension for Mozilla Firefox Update Information: - UI and functionality patches for stable rules - Translations string fixes - Minor npm updates for HSTS pruning ChangeLog: * Tue May 21 2019 Russell Golden - 2019.5.13-1 - UI and functionality patches for stable rules - Translations string fixes - Minor npm updates for HSTS pruning References: [ 1 ] Bug #1709619 - mozilla-https-everywhere-2019.5.13 is available https://bugzilla.redhat.com/show_bug.cgi?id=1709619 singularity-3.2.1-1.el6 (FEDORA-EPEL-2019-9a2a974d76) Application and environment virtualization Update Information: Update to 3.2.1 ChangeLog: * Wed May 29 2019 Dave Dykstra - 3.2.1-1 - Update to upstream 3.2.1-1 * Mon May 20 2019 Dave Dykstra - 3.2.0-1.1 - Add PR #3419 * Mon May 20 2019 Dave Dykstra - 3.2.0-1 - Update to upstream 3.2.0-1 References: [ 1 ] Bug #1696499 - singularity-3.2.1-rc1 is available https://bugzilla.redhat.com/show_bug.cgi?id=1696499 spectre-meltdown-checker-0.42-1.el6 (FEDORA-EPEL-2019-2c02a8e195) Spectre & Meltdown vulnerability/mitigation checker for Linux Update Information: Update to 0.42 * Feature: add FreeBSD MDS mitigation detection * Feature: add mocking functionality to help debugging, dump data to mock the behavior of your CPU with `--dump-mock-data` * Fix: AMD, ARM and CAVIUM are not vulnerable to MDS * Fix: RDCL_NO bit wasn't taking precedence for L1TF check on some newer Intel CPUs * Fix: The MDS_NO bit on newer Intel CPUs is now recognized and used * Fix: remove libvirtd from hypervisor detection to avoid false positives ([#278](https://github.com/speed47/spectre-meltdown-checker/issues/278)) * Fix: under BSD, the data returned when reading MSR was incorrectly formatted * Misc: update builtin MCEdb from v110 to v111 ChangeLog: * Thu May 30 2019 Reto Gantenbein - 0.42-1 - Update to 0.42 ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 289 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d condor-8.6.11-1.el7 97 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f8311ec8a2 tor-0.3.5.8-1.el7 64 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-d2c1368294 cinnamon-3.6.7-5.el7 57 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-50a6a1ddfd afflib-3.7.18-2.el7 30 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c499781e80 python-gnupg-0.4.4-1.el7 28 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b bubblewrap-0.3.3-2.el7 13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-1605b73a09 drupal7-7.67-1.el7 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-87fa8d93b6 drupal7-entity-1.9-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-b909a6e178 sleuthkit-4.6.6-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-9cab93353c drupal7-ds-2.16-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-2c1ec539fd drupal7-uuid-1.2-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f614c9a4bc drupal7-xmlsitemap-2.6-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-8278894e4d drupal7-context-3.10-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-de5e3216ff drupal7-path_breadcrumbs-3.4-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-748b40598c drupal7-module_filter-2.2-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-53f9189a5e drupal7-views-3.23-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-043371cfab rust-1.35.0-1.el7 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-fc63c75ab1 hostapd-2.8-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing isync-1.3.1-1.el7 mozilla-https-everywhere-2019.5.13-1.el7 python-pyngus-2.3.0-1.el7 singularity-3.2.1-1.el7 spectre-meltdown-checker-0.42-1.el7 xorgxrdp-0.2.10-1.el7 Details about builds: isync-1.3.1-1.el7 (FEDORA-EPEL-2019-6fc3c83374) A tool to synchronize IMAP4 and Maildir mailboxes Update Information: Support for SNI (rhbz#1632958) ChangeLog: * Wed May 29 2019 Fabian Affolter - 1.3.1-1 - Support for SNI (rhbz#1632958) - Update to new upstream version 1.3.1 (rhbz#1714679) * Fri Feb 1 2019 Fedora Release Engineering - 1.3.0-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild * Fri Jul 13 2018 Fedora Release Engineering - 1.3.0-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild * Wed Feb 7 2018 Fedora Release Engineering - 1.3.0-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild * Sun Jan 7 2018 Michael J Gruber - 1.3.0-1 - Update to new upstream version 1.3.0 (rhbz#1497574) * Sun Oct 1 2017 Fabian Affolter - 1.2.3-1 - Update to new upstream version 1.2.3 (rhbz#1497526) * Wed Aug 2 2017 Fedora Release Engineering - 1.2.1-6 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Binutils_Mass_Rebuild * Wed Jul 26 2017 Fedora Release Engineering - 1.2.1-5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild * Sat Mar 25 2017 Fabian Affolter - 1.2.1-4 - Fix FTBFS (rhbz#1423747) * Fri Feb 10 2017 Fedora Release Engineering - 1.2.1-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild * Thu Feb 4 2016 Fedora Release Engineering - 1.2.1-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild * Tue Nov 10 2015 Fabian Affolter - 1.2.1-1 - Update to new upstream version 1.2.0 (rhbz#1279883) * Wed Jun 17 2015 Fedora Release Engineering - 1.2.0-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild References: [ 1 ] Bug #1632958 - isync fails to sync to gmail with TLS and SNI https://bugzilla.redhat.com/show_bug.cgi?id=1632958 [ 2 ] Bug #1714679 - isync-1.3.1 is available https://bugzilla.redhat.com/show_bug.cgi?id=1714679 mozilla-https-everywhere-2019.5.13-1.el7 (FEDORA-EPEL-2019-bd51fcdac7) HTTPS enforcement extension for Mozilla Firefox Update Information: - UI and functionality patches for stable rules - Translations string fixes - Minor npm updates for HSTS pruning
[Bug 1710584] Not validating valid IPv6 CIDR addresses
https://bugzilla.redhat.com/show_bug.cgi?id=1710584 Fedora Update System changed: What|Removed |Added Status|MODIFIED|CLOSED Fixed In Version||perl-Net-CIDR-0.20-1.el6 Resolution|--- |ERRATA Last Closed||2019-05-31 00:40:46 --- Comment #2 from Fedora Update System --- perl-Net-CIDR-0.20-1.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
On Thursday, May 30, 2019 10:38:25 AM CEST Miroslav Suchý wrote: > Dne 29. 05. 19 v 23:52 Josh Boyer napsal(a): > > If we did this, wouldn't it make it very difficult to use tools like > > mock on RHEL / CentOS 7 to build for Fedora 3x? > > Speaking of Mock: > Either the RPM on host need to understand the new format/compression **or** > the packages in @buildsys group (including transitional deps) have to be in > old format - then you can build for Fedora 3x using bootstrap feature. I need to underline this, it would be really really really bad if we were not able to --installroot fedora chroots at least on RHEL 8. How likely is a backport of zstd support into RPM in EL7+? Regarding @buildsys group and compat compression; if we were OK to use `mock --bootstrap-chroot`, we could limit the package compatibility set (not really subset) to dnf + dnf-utils + deps (see dnf_install_command in site-defaults.cfg). But TBH I don't view this idea as feasible/maintainable solution, "Requires:" do change all the time... Another slightly more realistic way around would be to not --installroot the bootstrap chroot in mock, but rely on some distributed "bootstrap" root cache tarball (a standard, safe way) instead. > Both of them would be painful. Typo: "having none of them would be painful", and very likely to happen. Pavel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Re: Proposal: EPEL 8 Branch Strategy
On Thu, May 30, 2019, at 6:57 PM, Stephen Gallagher wrote: > On Thu, May 30, 2019 at 4:25 PM James Cassell > wrote: > > > > > > > > > Historical composes are intended to be frozen and unchanging, but this > > > > approach leaves open the possibility of tagging other builds into > > > > epel8-8.Y and regenerating the compose if the need arises. It will > > > > need to be communicated that these repositories will not receive > > > > updates and are intended to be only a snapshot of the past that is > > > > known to work with a particular RHEL 8.Y base. > > > > > > > This will be very helpful, especially if the epel-release .repo file honors > > the $releasever variable. > > > Can you explain what behavior you see here? I can't really parse from > your reply what you think/expect to have happen here, and I'd like to > make sure we address it properly. The use case is preventing updates past a minor version without explicit administrator action. We're able to do this by forcing the $releasever yum variable to be 7.50 (for RHEL) or 7.5.1804 (for CentOS). It would be convenient to keep this approach working by using the yum var in the repo file, with requisite symlinks in place on the mirrors. The repo file as is today would likely work for this purpose (but I don't have it in front of me to verify.) V/r, James Cassell ___ 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://getfedora.org/code-of-conduct.html 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: Proposal: EPEL 8 Branch Strategy
On Thu, May 30, 2019 at 4:25 PM James Cassell wrote: > > > > > > Historical composes are intended to be frozen and unchanging, but this > > > approach leaves open the possibility of tagging other builds into > > > epel8-8.Y and regenerating the compose if the need arises. It will > > > need to be communicated that these repositories will not receive > > > updates and are intended to be only a snapshot of the past that is > > > known to work with a particular RHEL 8.Y base. > > > > This will be very helpful, especially if the epel-release .repo file honors > the $releasever variable. Can you explain what behavior you see here? I can't really parse from your reply what you think/expect to have happen here, and I'd like to make sure we address it properly. ___ 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://getfedora.org/code-of-conduct.html 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: Proposal: EPEL 8 Branch Strategy
On Thu, May 30, 2019 at 4:02 PM Troy Dawson wrote: > > On Thu, May 30, 2019 at 12:18 PM Kevin Fenzi wrote: > > Also might there be people who want to always keep something in rawhide > > and never push it to the stable stream? Or do we want to encourage only > > things destined for the next minor change land in epel8-rawhide? > > > > Yes. We need to keep that in consideration. > When cleaning up the -testing branches of EPEL6 and EPEL7 we found > there were people who had versions in -testing that they never > intended to push to stable. > Once EPEL8/7 has modularity, there will be an official way to do that, > but until that happens, we need to assume that some people will use > rawhide as a way to have a second version of their package. > Right, I think Troy has the pulse of it. I think the current design is compatible with that, though. I see the following common cases from most to least common: 1) Leave package.cfg in epel8, build only there -> epel8 repo and epel8-rawhide repo 2) Remove package.cfg in epel 8. Build stable in epel8 -> epel8 repo. Build major release planned for an upcoming (not necessarily next...) X.Y release in Rawhide -> epel8-rawhide repo. 3) Remove package.cfg in epel 8. Build stable in epel8 -> epel8 repo. Build rolling release in epel8-rawhide of the latest upstream bits, not necessarily ever planning to move it into stable -> epel8-rawhide repo. Case 3 I think will slowly disappear once we enable (and simplify creation of) modules in EPEL 8, since they'll be able to just provide a non-default stream. ___ 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://getfedora.org/code-of-conduct.html 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: Proposal: EPEL 8 Branch Strategy
On Thu, May 30, 2019 at 3:18 PM Kevin Fenzi wrote: > > > As discussed in the EPEL SIG meeting yesterday, I've written up my > > thoughts on how to handle epel8 branches. > > TLDR: I like it. ;) > > > # Considerations > > * The process must be simple for a Fedora packager to adapt to > > * It must be possible to stage big (possibly backwards-incompatible) changes > > * Where possible, the packager experience should be the same as EPEL 7 > > > > # Proposal > > There will be two branches created for EPEL 8 in dist-git for each > > component: > > > > ## epel8: > > Most packagers will do their work here. This branch will be set up by > > default with a package.cfg file containing: > > ``` > > [koji] > > targets = epel8 epel8-rawhide > > ``` > > Recent fedpkg supports using package.cfg files in the root of the > > dist-git repository to trigger builds for multiple releases at the > > same time. > > > > > > ## epel8-rawhide: > > This branch will be left alone until and unless the packager decides > > that they want to stage a major (possibly incompatible) change for the > > next RHEL 8.Y minor release. At that time, they will need to remove > > the package.cfg file from the epel8 branch and manually merge the > > proposed changes desired into the epel8-rawhide branch and build > > there. > > Also might there be people who want to always keep something in rawhide > and never push it to the stable stream? Or do we want to encourage only > things destined for the next minor change land in epel8-rawhide? > > > The package.cfg setup will mean that running `fedpkg build` in the > > epel8 branch will cause it to be built both for the > > epel8-rawhide-candidate and epel8-stable-candidate tags in Koji. > > How about we just call the stable tag 'epel8-candidate' ? > Sure, that's actually a vestige of my first draft of this, which I rewrote which had "epel8" as the combined repo and "epel-stable" as the branched-off one for when you wanted to lock things. After consideration, I realized that packagers acting like EPEL 7 (generally only doing the stable, compatible release) would be the common case and I reversed that to the version you see here. I left the tag names specific to eliminate ambiguity, but that's entirely a cosmetic choice and as long as they're unique and consistent, I don't care what they are, particularly. > > Packages built for epel8-rawhide-candidate will behave similarly to > > Rawhide in Fedora and be signed and tagged into an epel8-rawhide > > compose. > > > > Packages built for epel8-stable-candidate will behave similarly to > > Fedora stable releases and be required to go through Bodhi to get to > > an epel8 compose (and associated epel8-testing compose). > > > > For packages operating in the default configuration, the packager will > > need to build in the epel8 branch and then submit the built package to > > Bodhi, just as they would have done for EPEL 7. The side-effect here > > is that the build will also produce a build that goes to the > > epel8-rawhide repository without Bodhi intervention. > > Or we could at some point hook in gating, just like fedora rawhide. > Sorry, just had a dream of a pleasant future. ;) > I suppose I should have phrased that differently, or just said "processed in the same manner as Fedora Rawhide". But yes, if we can get these properly gated, that's also great. > > > > When the time comes where an incompatible change needs to land, they > > must be coordinated to land on an approved schedule. The exact > > mechanism of scheduling and coordinating this is out of scope for this > > document and will be decided on by the EPEL Steering Committee. > > Yeah, but we should probibly try and figure it out. > I was worried that the logistics of this would derail the conversation about the branching, so I tried to preempt that. The timing is something that will be a policy, the rest of this proposal is about technical design. > I guess there is: > A. Right after the new minor release comes out > B. Right after the new minor release comes out for CentOS > C. Some arbitrary time after the new minor release comes out. > No comment at this time :) > > > > At this time, the packager must remove the package.cfg file from the > > epel8 branch and package the new version in the epel8-rawhide branch. > > With the package.cfg file removed from the epel8 branch, builds in > > that branch will be built only for the epel8-stable-candidate tag. As > > before, composes including these builds will be managed by Bodhi > > updates. Building from the epel8 branch will therefore not be > > automatically built for epel8-rawhide any longer. > > > > Builds intended for the epel8-rawhide repository will need to be built > > instead from the epel8-rawhide branch, which will build against the > > epel8-rawhide-candidate target, which will then be signed and pushed > > to the epel8-rawhide repository like before. > > > > Once the package is approved to be promoted from the epel8-rawhide > >
[389-devel] please review: Ticket 49361 - Use IPv6 friendly network functions
https://pagure.io/389-ds-base/pull-request/50415 ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
On 5/30/19 2:38 PM, Chris Murphy wrote: On Thu, May 30, 2019 at 3:31 PM Samuel Sieb wrote: On 5/30/19 1:56 PM, Chris Murphy wrote: I have no idea how deltarpm works, but if working on bit level difference on uncompressed data, I don't see why local rebuild needs to use the same compression level as the Fedora build system. If it's working on compressed data, well I'm not sure how that works, in particular if pixz is used which gives non-reproducible results. I was going to suggest earlier that deltarpm could use a faster compression when repacking. But then I realized that the result has to be be bit-exact with the original so the package signing is still intact. Package signing happens after compression? Compression is an optimization, in no way does it affect the validity of the payload. My understanding is that the signature is calculated over the compressed payload. (I couldn't find any clear documentation on it with a quick search.) I see that would make it simpler and somewhat quicker to verify, but it does cause problems with things like deltarpm and recompressing packages. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Using fedora-active-user: unable to find fedora_cert
On Thu, 2019-05-30 at 22:42 +0100, Tom Hughes wrote: > On 30/05/2019 22:38, Adam Williamson wrote: > > > I'd kinda rather there was a standard way for all such things to read > > the username from a standard file, because my Fedora username is not my > > system username and passing --user or --username or whatever to > > everything is a pain. > > Don't most things look at $FAS_USERNAME for that? > > There's ~/.fedora.upn as well though I'm not sure what looks > at that? That's...sorta my whole point. :P Clearly if you can think of two mechanisms and you don't know what uses which...there isn't a standard... (I know some things used to look at ~/.fedora.cert to figure it out, too). -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Using fedora-active-user: unable to find fedora_cert
On 30/05/2019 22:38, Adam Williamson wrote: I'd kinda rather there was a standard way for all such things to read the username from a standard file, because my Fedora username is not my system username and passing --user or --username or whatever to everything is a pain. Don't most things look at $FAS_USERNAME for that? There's ~/.fedora.upn as well though I'm not sure what looks at that? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
On Thu, May 30, 2019 at 3:31 PM Samuel Sieb wrote: > > On 5/30/19 1:56 PM, Chris Murphy wrote: > > On Thu, May 30, 2019 at 8:40 AM Daniel Mach wrote: > >> > >> Dne 30. 05. 19 v 0:05 Neal Gompa napsal(a): > >>> > >>> I'm pretty sure this would break DeltaRPMs, since none of the drpm > >>> software has been updated to handle zstd compression. Neither drpm nor > >>> deltarpm handle it today. > >>> > >> Thanks for heads-up. We'll look into it and provide a fix soon. > > > > I have no idea how deltarpm works, but if working on bit level > > difference on uncompressed data, I don't see why local rebuild needs > > to use the same compression level as the Fedora build system. If it's > > working on compressed data, well I'm not sure how that works, in > > particular if pixz is used which gives non-reproducible results. > > I was going to suggest earlier that deltarpm could use a faster > compression when repacking. But then I realized that the result has to > be be bit-exact with the original so the package signing is still intact. Package signing happens after compression? Compression is an optimization, in no way does it affect the validity of the payload. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Using fedora-active-user: unable to find fedora_cert
On Thu, 2019-05-30 at 09:43 -0700, Kevin Fenzi wrote: > On 5/30/19 3:22 AM, Ankur Sinha wrote: > > On Thu, May 30, 2019 11:50:12 +0200, Didier Fabert wrote: > > > Hi Ankur, > > > > Hi Didier, > > > > > You have to create a directory and download one file to get script > > > working. > > > In the same directory of fedora-active-user.py > > > > > > mkdir fedora_cert > > > curl -fsSL -o fedora_cert/__init__.py > > > https://pagure.io/fedora-packager/raw/master/f/src/fedora_cert/__init__.py > > > > > > I modify a little this script and send pypingou a PR[1] > > > > Thanks for that. I've used your fork, downloaded fedora_cert as you > > suggest and it works now. > > Ideally it should drop fedora-cert use entirely. It looks like currently > all it uses it for is to figure out your username. Instead it should > default to your local user name or take a --user or something. :) I'd kinda rather there was a standard way for all such things to read the username from a standard file, because my Fedora username is not my system username and passing --user or --username or whatever to everything is a pain. Things that need to do this include, just off the top of my head, the bodhi and koji clients, fedpkg...I know some of them have implementations of this, I don't know if they all agree on how to do it... -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
On 5/30/19 1:56 PM, Chris Murphy wrote: On Thu, May 30, 2019 at 8:40 AM Daniel Mach wrote: Dne 30. 05. 19 v 0:05 Neal Gompa napsal(a): I'm pretty sure this would break DeltaRPMs, since none of the drpm software has been updated to handle zstd compression. Neither drpm nor deltarpm handle it today. Thanks for heads-up. We'll look into it and provide a fix soon. I have no idea how deltarpm works, but if working on bit level difference on uncompressed data, I don't see why local rebuild needs to use the same compression level as the Fedora build system. If it's working on compressed data, well I'm not sure how that works, in particular if pixz is used which gives non-reproducible results. I was going to suggest earlier that deltarpm could use a faster compression when repacking. But then I realized that the result has to be be bit-exact with the original so the package signing is still intact. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1715645] New: perl-Pod-Simple-3.38 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1715645 Bug ID: 1715645 Summary: perl-Pod-Simple-3.38 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Pod-Simple Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jose.p.oliveira@gmail.com, ka...@ucw.cz, perl-devel@lists.fedoraproject.org, ppi...@redhat.com, st...@silug.org, tcall...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 3.38 Current version/release in rawhide: 3.37-2.fc31 URL: http://search.cpan.org/dist/Pod-Simple/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/3246/ -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Using fedora-active-user: unable to find fedora_cert
Hi,
On Thu, May 30, 2019 at 09:43:38AM -0700, Kevin Fenzi wrote:
> Ideally it should drop fedora-cert use entirely. It looks like currently
> all it uses it for is to figure out your username. Instead it should
> default to your local user name or take a --user or something. :)
IMHO it should default to this:
if os.path.exists(os.path.expanduser('~/.fedora.upn')):
with open(os.path.expanduser('~/.fedora.upn'), 'r') as f:
username = f.read().replace('\n', '')
else:
username = getpass.getuser()
Kind regards
Till
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
On Thu, May 30, 2019 at 8:40 AM Daniel Mach wrote: > > Dne 30. 05. 19 v 0:05 Neal Gompa napsal(a): > > > > I'm pretty sure this would break DeltaRPMs, since none of the drpm > > software has been updated to handle zstd compression. Neither drpm nor > > deltarpm handle it today. > > > Thanks for heads-up. We'll look into it and provide a fix soon. I think the net resources consumed by all parties needs to be considered. Whether xz:2 or zstd:19, multiplied by thousands of users, that's energy and heat. I have no idea how deltarpm works, but if working on bit level difference on uncompressed data, I don't see why local rebuild needs to use the same compression level as the Fedora build system. If it's working on compressed data, well I'm not sure how that works, in particular if pixz is used which gives non-reproducible results. Another idea for the training dictionary: the training could be done per RPM at create time based on the files for that RPM, and stuff the dictionary in the RPM. No versioning needed. The speed and compression improvements are significant enough it's plausible whatever hit there is for training is overcome by the gain, even at lower compression levels. But it probably needs testing to know. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Re: Proposal: EPEL 8 Branch Strategy
On Thu, May 30, 2019, at 3:18 PM, Kevin Fenzi wrote: > > As discussed in the EPEL SIG meeting yesterday, I've written up my > > thoughts on how to handle epel8 branches. > [...] > > > > When the time comes where an incompatible change needs to land, they > > must be coordinated to land on an approved schedule. The exact > > mechanism of scheduling and coordinating this is out of scope for this > > document and will be decided on by the EPEL Steering Committee. > > Yeah, but we should probibly try and figure it out. > > I guess there is: > A. Right after the new minor release comes out > B. Right after the new minor release comes out for CentOS > C. Some arbitrary time after the new minor release comes out. > I'd be in favor of B. [...] > > # Historical Composes > > Since major changes may occur at RHEL 8.Y releases, we want to support > > allowing our users to lock onto a repository that matches that > > release. For this, we will generate historical composes, which will > > match the stable package set of the prior minor release once the new > > minor release comes out. > > > > At 00:00 UTC of the day following a new RHEL 8.Y release, an updated > > epel-release package will be pushed, updating the %dist tag to the new > > .epel8_Y value. All new builds will thus have the new dist tag. A > > script will be run at this time to apply a new Koji tag (epel8-8.Y) to > > the latest build of a package with one of the following tags: [ > > epel8-stable, epel8-stable-pending ]. A compose of the epel8.Y > > repository will be created at this time from all packages currently > > tagged as epel8-8.Y. > > So, we will also have to unpush/obsolete/close all pending bodhi updates > right? Since things will need rebuilding with the new dist tag for the > new minor. I'd say just cancel any karma, reset the timer, then let them go out as-is once/if they again pass the bodhi process. > > > > Historical composes are intended to be frozen and unchanging, but this > > approach leaves open the possibility of tagging other builds into > > epel8-8.Y and regenerating the compose if the need arises. It will > > need to be communicated that these repositories will not receive > > updates and are intended to be only a snapshot of the past that is > > known to work with a particular RHEL 8.Y base. > This will be very helpful, especially if the epel-release .repo file honors the $releasever variable. V/r, James Cassell ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
On Thu, May 30, 2019 at 3:07 PM Kevin Fenzi wrote: > > So, most of my concerns have already been mentioned by other folks in > this thread: > > * No rhel7/8 support will annoy people, and also increase burden on > fedora infrastructure since we would have to move our koji hubs to > Fedora instead of RHEL to be able to read the rpms made on builders. > (Or ship a custom rpm, but we have done that before and it's been always > a nightmare). I'm actually okay with the thought of Koji hub moving to Fedora. I'd rather see most of our infra running on Fedora so that we don't get kneecapped by RHEL moving too slowly. Our transition to Python 3 was made way more complicated by the fact our infrastructure ran on RHEL 6 or RHEL 7, where Python 3 wasn't available in a useful manner for a very long time. Having our own infra run on our distribution that we have a say in makes a huge difference in being able to move things forward. Not that I hate RHEL or anything, but we don't have a say in anything when it comes to RHEL, and they don't really care about bugs we report that afflict us that much. Not exactly the most solid foundation to run a distribution's infrastructure on, wouldn't you say? That said, I'm less happy about the thought that inspecting Fedora RPMs on RHEL 8 or openSUSE is going to be a royal pain. Ecosystem-wise, no one really prepared for a distribution to switch to zstd so quickly. Thankfully, it's easier to support than things like modularity, which break the entire way people do things. If we decide to do this, at least I'll try to see to get things fixed on the SUSE side. Maybe someone can push for this to be fixed on the RHEL side as well? > > * This cannot land until we finish sorting out armv7 builder issues. > (see bug https://bugzilla.redhat.com/show_bug.cgi?id=1576593 ). > I am trying to see if we can get away with a f29 userspace and a > specific kernel we think works. Until this is moved however, all the > armv7 buildvm's are on fedora 27, so they wouldn't be able to handle > this change. > Ugh, I didn't realize this is still a problem. It _should_ work with an F30 userspace on the F27 kernel, but that's gross... :( > * The drpm issue is somewhat minor in my mind since we don't produce > very useful drpms right now (due to pungi not having anything more than > the last updates compose to build them against). > This feels more like a failing on pungi. We don't have archives or indexes of what old composes looked like to maintain drpm content? > So, this definitely needs extra coordination if we decide to go for it. I agree. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Re: Proposal: EPEL 8 Branch Strategy
On Thu, May 30, 2019 at 12:18 PM Kevin Fenzi wrote: > > > As discussed in the EPEL SIG meeting yesterday, I've written up my > > thoughts on how to handle epel8 branches. > > TLDR: I like it. ;) > > > # Considerations > > * The process must be simple for a Fedora packager to adapt to > > * It must be possible to stage big (possibly backwards-incompatible) changes > > * Where possible, the packager experience should be the same as EPEL 7 > > > > # Proposal > > There will be two branches created for EPEL 8 in dist-git for each > > component: > > > > ## epel8: > > Most packagers will do their work here. This branch will be set up by > > default with a package.cfg file containing: > > ``` > > [koji] > > targets = epel8 epel8-rawhide > > ``` > > Recent fedpkg supports using package.cfg files in the root of the > > dist-git repository to trigger builds for multiple releases at the > > same time. > > > > > > ## epel8-rawhide: > > This branch will be left alone until and unless the packager decides > > that they want to stage a major (possibly incompatible) change for the > > next RHEL 8.Y minor release. At that time, they will need to remove > > the package.cfg file from the epel8 branch and manually merge the > > proposed changes desired into the epel8-rawhide branch and build > > there. > > Also might there be people who want to always keep something in rawhide > and never push it to the stable stream? Or do we want to encourage only > things destined for the next minor change land in epel8-rawhide? > Yes. We need to keep that in consideration. When cleaning up the -testing branches of EPEL6 and EPEL7 we found there were people who had versions in -testing that they never intended to push to stable. Once EPEL8/7 has modularity, there will be an official way to do that, but until that happens, we need to assume that some people will use rawhide as a way to have a second version of their package. > > The package.cfg setup will mean that running `fedpkg build` in the > > epel8 branch will cause it to be built both for the > > epel8-rawhide-candidate and epel8-stable-candidate tags in Koji. > > How about we just call the stable tag 'epel8-candidate' ? > > > Packages built for epel8-rawhide-candidate will behave similarly to > > Rawhide in Fedora and be signed and tagged into an epel8-rawhide > > compose. > > > > Packages built for epel8-stable-candidate will behave similarly to > > Fedora stable releases and be required to go through Bodhi to get to > > an epel8 compose (and associated epel8-testing compose). > > > > For packages operating in the default configuration, the packager will > > need to build in the epel8 branch and then submit the built package to > > Bodhi, just as they would have done for EPEL 7. The side-effect here > > is that the build will also produce a build that goes to the > > epel8-rawhide repository without Bodhi intervention. > > Or we could at some point hook in gating, just like fedora rawhide. > Sorry, just had a dream of a pleasant future. ;) > > > > > When the time comes where an incompatible change needs to land, they > > must be coordinated to land on an approved schedule. The exact > > mechanism of scheduling and coordinating this is out of scope for this > > document and will be decided on by the EPEL Steering Committee. > > Yeah, but we should probibly try and figure it out. > > I guess there is: > A. Right after the new minor release comes out > B. Right after the new minor release comes out for CentOS > C. Some arbitrary time after the new minor release comes out. > > > > > At this time, the packager must remove the package.cfg file from the > > epel8 branch and package the new version in the epel8-rawhide branch. > > With the package.cfg file removed from the epel8 branch, builds in > > that branch will be built only for the epel8-stable-candidate tag. As > > before, composes including these builds will be managed by Bodhi > > updates. Building from the epel8 branch will therefore not be > > automatically built for epel8-rawhide any longer. > > > > Builds intended for the epel8-rawhide repository will need to be built > > instead from the epel8-rawhide branch, which will build against the > > epel8-rawhide-candidate target, which will then be signed and pushed > > to the epel8-rawhide repository like before. > > > > Once the package is approved to be promoted from the epel8-rawhide > > compose to the stable compose, the package.cfg should be recreated in > > the epel8 branch (this can be automated to make it easier) and a new > > build will be made in the epel8 branch that will produce builds in the > > epel8-stable-candidate and epel8-rawhide-candidate tags, with the > > former then being submitted to Bodhi. This new build must naturally > > have a higher ENVR to preserve the upgrade path. > > > > ## %dist tag > > Packages built against epel8-rawhide-candidate will be built with a > > %dist tag of .epel8_rawhide > > Packages built against epel8-rawhide-candidate will be
[389-devel] please review: Ticket 50413 - ds-replcheck should always display a Result Summary
https://pagure.io/389-ds-base/pull-request/50414 ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
[EPEL-devel] Re: Proposal: EPEL 8 Branch Strategy
On 30. 05. 19 20:21, Stephen Gallagher wrote: ## epel8-rawhide: This branch will be left alone until and unless the packager decides that they want to stage a major (possibly incompatible) change for the next RHEL 8.Y minor release. At that time, they will need to remove the package.cfg file from the epel8 branch and manually merge the proposed changes desired into the epel8-rawhide branch and build there. Just a small consideration here: Can this thing not be called Rawhide? Rawhide is Fedora. I'd like to keep that clear, so when we talk about rawhide in various places, we don't have to say: Fedora Rawhide (although we often do). Imagine this conversation: A: I want to do a major cleanup of %scripts in Fedora. B: But what about EPEL? A: I'll do it in Rawhide only. Having an EPEL Rawhide makes the last statement ambiguous. -- 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://getfedora.org/code-of-conduct.html 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: Proposal: EPEL 8 Branch Strategy
> As discussed in the EPEL SIG meeting yesterday, I've written up my > thoughts on how to handle epel8 branches. TLDR: I like it. ;) > # Considerations > * The process must be simple for a Fedora packager to adapt to > * It must be possible to stage big (possibly backwards-incompatible) changes > * Where possible, the packager experience should be the same as EPEL 7 > > # Proposal > There will be two branches created for EPEL 8 in dist-git for each component: > > ## epel8: > Most packagers will do their work here. This branch will be set up by > default with a package.cfg file containing: > ``` > [koji] > targets = epel8 epel8-rawhide > ``` > Recent fedpkg supports using package.cfg files in the root of the > dist-git repository to trigger builds for multiple releases at the > same time. > > > ## epel8-rawhide: > This branch will be left alone until and unless the packager decides > that they want to stage a major (possibly incompatible) change for the > next RHEL 8.Y minor release. At that time, they will need to remove > the package.cfg file from the epel8 branch and manually merge the > proposed changes desired into the epel8-rawhide branch and build > there. Also might there be people who want to always keep something in rawhide and never push it to the stable stream? Or do we want to encourage only things destined for the next minor change land in epel8-rawhide? > The package.cfg setup will mean that running `fedpkg build` in the > epel8 branch will cause it to be built both for the > epel8-rawhide-candidate and epel8-stable-candidate tags in Koji. How about we just call the stable tag 'epel8-candidate' ? > Packages built for epel8-rawhide-candidate will behave similarly to > Rawhide in Fedora and be signed and tagged into an epel8-rawhide > compose. > > Packages built for epel8-stable-candidate will behave similarly to > Fedora stable releases and be required to go through Bodhi to get to > an epel8 compose (and associated epel8-testing compose). > > For packages operating in the default configuration, the packager will > need to build in the epel8 branch and then submit the built package to > Bodhi, just as they would have done for EPEL 7. The side-effect here > is that the build will also produce a build that goes to the > epel8-rawhide repository without Bodhi intervention. Or we could at some point hook in gating, just like fedora rawhide. Sorry, just had a dream of a pleasant future. ;) > > When the time comes where an incompatible change needs to land, they > must be coordinated to land on an approved schedule. The exact > mechanism of scheduling and coordinating this is out of scope for this > document and will be decided on by the EPEL Steering Committee. Yeah, but we should probibly try and figure it out. I guess there is: A. Right after the new minor release comes out B. Right after the new minor release comes out for CentOS C. Some arbitrary time after the new minor release comes out. > > At this time, the packager must remove the package.cfg file from the > epel8 branch and package the new version in the epel8-rawhide branch. > With the package.cfg file removed from the epel8 branch, builds in > that branch will be built only for the epel8-stable-candidate tag. As > before, composes including these builds will be managed by Bodhi > updates. Building from the epel8 branch will therefore not be > automatically built for epel8-rawhide any longer. > > Builds intended for the epel8-rawhide repository will need to be built > instead from the epel8-rawhide branch, which will build against the > epel8-rawhide-candidate target, which will then be signed and pushed > to the epel8-rawhide repository like before. > > Once the package is approved to be promoted from the epel8-rawhide > compose to the stable compose, the package.cfg should be recreated in > the epel8 branch (this can be automated to make it easier) and a new > build will be made in the epel8 branch that will produce builds in the > epel8-stable-candidate and epel8-rawhide-candidate tags, with the > former then being submitted to Bodhi. This new build must naturally > have a higher ENVR to preserve the upgrade path. > > ## %dist tag > Packages built against epel8-rawhide-candidate will be built with a > %dist tag of .epel8_rawhide > Packages built against epel8-rawhide-candidate will be built with a > %dist tag of .epel8_Y where “Y” is the latest stable release of RHEL > 8. > > This dist tag structure ensures that the version of the package in the > stable epel8 repository will win out over the one in the epel8-rawhide > repository if all other aspects of the EVR are the same. (So one would > only pick up a newer version from epel8-rawhide if it was indeed a > higher version number.) It does also mean you have to do another build of anything to get it stable. The rawhide build never goes stable, just a rebuilt version of it does... thats a bit more work, but not too bad. > # Historical Composes > Since major
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
So, most of my concerns have already been mentioned by other folks in this thread: * No rhel7/8 support will annoy people, and also increase burden on fedora infrastructure since we would have to move our koji hubs to Fedora instead of RHEL to be able to read the rpms made on builders. (Or ship a custom rpm, but we have done that before and it's been always a nightmare). * This cannot land until we finish sorting out armv7 builder issues. (see bug https://bugzilla.redhat.com/show_bug.cgi?id=1576593 ). I am trying to see if we can get away with a f29 userspace and a specific kernel we think works. Until this is moved however, all the armv7 buildvm's are on fedora 27, so they wouldn't be able to handle this change. * The drpm issue is somewhat minor in my mind since we don't produce very useful drpms right now (due to pungi not having anything more than the last updates compose to build them against). So, this definitely needs extra coordination if we decide to go for it. kevin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
On 5/30/19 7:54 AM, Daniel Mach wrote: I think before approving such changes, owners need to do mass rebuilds on their own and provide a graph of changes in size between original compression format and new one(s). Doing that equals to the mass rebuild. I'd rather do an analysis and if the numbers look sane, I'd prefer doing a mass rebuild in a side tag so we can use the builds if the results are sane. Hammering koji with so many scratch builds doesn't sound right to me. Is it possible to just recompress the rpms instead of doing a full build? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 288 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d condor-8.6.11-1.el7 96 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f8311ec8a2 tor-0.3.5.8-1.el7 64 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-d2c1368294 cinnamon-3.6.7-5.el7 57 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-50a6a1ddfd afflib-3.7.18-2.el7 30 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c499781e80 python-gnupg-0.4.4-1.el7 28 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b bubblewrap-0.3.3-2.el7 13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-1605b73a09 drupal7-7.67-1.el7 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-87fa8d93b6 drupal7-entity-1.9-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-b909a6e178 sleuthkit-4.6.6-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-9cab93353c drupal7-ds-2.16-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-2c1ec539fd drupal7-uuid-1.2-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f614c9a4bc drupal7-xmlsitemap-2.6-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-8278894e4d drupal7-context-3.10-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-de5e3216ff drupal7-path_breadcrumbs-3.4-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-748b40598c drupal7-module_filter-2.2-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-53f9189a5e drupal7-views-3.23-1.el7 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-043371cfab rust-1.35.0-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing certbot-0.34.2-3.el7 hostapd-2.8-1.el7 python-acme-0.34.2-1.el7 python-certbot-apache-0.34.2-1.el7 python-certbot-dns-cloudflare-0.34.2-1.el7 python-certbot-dns-cloudxns-0.34.2-1.el7 python-certbot-dns-digitalocean-0.34.2-1.el7 python-certbot-dns-dnsimple-0.34.2-1.el7 python-certbot-dns-dnsmadeeasy-0.34.2-1.el7 python-certbot-dns-gehirn-0.34.2-1.el7 python-certbot-dns-google-0.34.2-1.el7 python-certbot-dns-linode-0.34.2-1.el7 python-certbot-dns-luadns-0.34.2-1.el7 python-certbot-dns-nsone-0.34.2-1.el7 python-certbot-dns-ovh-0.34.2-1.el7 python-certbot-dns-rfc2136-0.34.2-1.el7 python-certbot-dns-route53-0.34.2-1.el7 python-certbot-dns-sakuracloud-0.34.2-1.el7 python-certbot-nginx-0.34.2-1.el7 python-dns-lexicon-3.2.6-1.el7 Details about builds: certbot-0.34.2-3.el7 (FEDORA-EPEL-2019-389d1dd572) A free, automated certificate authority client Update Information: python-dns-lexicon - Update to 3.2.6 python-acme, certbot, python-certbot-* - Update to 0.34.2 certbot - Run renew timer twice daily with 12-hour random delay - Update `--renew-hook` to `--deploy-hook` ChangeLog: * Tue May 28 2019 Eli Young - 0.34.2-3 - Fix build on Python 2 * Tue May 28 2019 Eli Young - 0.34.2-2 - Update --renew-hook to --deploy-hook (#1665755) * Tue May 28 2019 Eli Young - 0.34.2-1 - Update to 0.34.2 (#1686184) (#1705300) - Run rewew timer twice daily with 12-hour random delay References: [ 1 ] Bug #1685778 - python-dns-lexicon-3.2.6 is available https://bugzilla.redhat.com/show_bug.cgi?id=1685778 [ 2 ] Bug #1686201 - python-acme-0.34.2 is available https://bugzilla.redhat.com/show_bug.cgi?id=1686201 [ 3 ] Bug #1686184 - certbot-0.34.2 is available https://bugzilla.redhat.com/show_bug.cgi?id=1686184 [ 4 ] Bug #1665755 - Replace --renew-hook with --deploy-hook in systemd units https://bugzilla.redhat.com/show_bug.cgi?id=1665755 [ 5 ] Bug #1686185 - python-certbot-apache-0.34.2 is available https://bugzilla.redhat.com/show_bug.cgi?id=1686185 [ 6 ] Bug #1686186 - python-certbot-dns-cloudflare-0.34.2 is available https://bugzilla.redhat.com/show_bug.cgi?id=1686186 [ 7 ] Bug #1686187 - python-certbot-dns-cloudxns-0.34.2 is available https://bugzilla.redhat.com/show_bug.cgi?id=1686187 [ 8 ] Bug #1686188 - python-certbot-dns-digitalocean-0.34.2 is available https://bugzilla.redhat.com/show_bug.cgi?id=1686188 [ 9 ] Bug #1686189 - python-certbot-dns-dnsimple-0.34.2 is available https://bugzilla.redhat.com/show_bug.cgi?id=1686189 [ 10 ] Bug #1686190 - python-certbot-dns-dnsmadeeasy-0.34.2 is available https://bugzilla.redhat.com/show_bug.cgi?id=1686190 [ 11 ] Bug #1686191 - python-certbot-dns-gehirn-0.34.2 is
[EPEL-devel] Proposal: EPEL 8 Branch Strategy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 As discussed in the EPEL SIG meeting yesterday, I've written up my thoughts on how to handle epel8 branches. # Considerations * The process must be simple for a Fedora packager to adapt to * It must be possible to stage big (possibly backwards-incompatible) changes * Where possible, the packager experience should be the same as EPEL 7 # Proposal There will be two branches created for EPEL 8 in dist-git for each component: ## epel8: Most packagers will do their work here. This branch will be set up by default with a package.cfg file containing: ``` [koji] targets = epel8 epel8-rawhide ``` Recent fedpkg supports using package.cfg files in the root of the dist-git repository to trigger builds for multiple releases at the same time. ## epel8-rawhide: This branch will be left alone until and unless the packager decides that they want to stage a major (possibly incompatible) change for the next RHEL 8.Y minor release. At that time, they will need to remove the package.cfg file from the epel8 branch and manually merge the proposed changes desired into the epel8-rawhide branch and build there. The package.cfg setup will mean that running `fedpkg build` in the epel8 branch will cause it to be built both for the epel8-rawhide-candidate and epel8-stable-candidate tags in Koji. Packages built for epel8-rawhide-candidate will behave similarly to Rawhide in Fedora and be signed and tagged into an epel8-rawhide compose. Packages built for epel8-stable-candidate will behave similarly to Fedora stable releases and be required to go through Bodhi to get to an epel8 compose (and associated epel8-testing compose). For packages operating in the default configuration, the packager will need to build in the epel8 branch and then submit the built package to Bodhi, just as they would have done for EPEL 7. The side-effect here is that the build will also produce a build that goes to the epel8-rawhide repository without Bodhi intervention. When the time comes where an incompatible change needs to land, they must be coordinated to land on an approved schedule. The exact mechanism of scheduling and coordinating this is out of scope for this document and will be decided on by the EPEL Steering Committee. At this time, the packager must remove the package.cfg file from the epel8 branch and package the new version in the epel8-rawhide branch. With the package.cfg file removed from the epel8 branch, builds in that branch will be built only for the epel8-stable-candidate tag. As before, composes including these builds will be managed by Bodhi updates. Building from the epel8 branch will therefore not be automatically built for epel8-rawhide any longer. Builds intended for the epel8-rawhide repository will need to be built instead from the epel8-rawhide branch, which will build against the epel8-rawhide-candidate target, which will then be signed and pushed to the epel8-rawhide repository like before. Once the package is approved to be promoted from the epel8-rawhide compose to the stable compose, the package.cfg should be recreated in the epel8 branch (this can be automated to make it easier) and a new build will be made in the epel8 branch that will produce builds in the epel8-stable-candidate and epel8-rawhide-candidate tags, with the former then being submitted to Bodhi. This new build must naturally have a higher ENVR to preserve the upgrade path. ## %dist tag Packages built against epel8-rawhide-candidate will be built with a %dist tag of .epel8_rawhide Packages built against epel8-rawhide-candidate will be built with a %dist tag of .epel8_Y where “Y” is the latest stable release of RHEL 8. This dist tag structure ensures that the version of the package in the stable epel8 repository will win out over the one in the epel8-rawhide repository if all other aspects of the EVR are the same. (So one would only pick up a newer version from epel8-rawhide if it was indeed a higher version number.) # Historical Composes Since major changes may occur at RHEL 8.Y releases, we want to support allowing our users to lock onto a repository that matches that release. For this, we will generate historical composes, which will match the stable package set of the prior minor release once the new minor release comes out. At 00:00 UTC of the day following a new RHEL 8.Y release, an updated epel-release package will be pushed, updating the %dist tag to the new .epel8_Y value. All new builds will thus have the new dist tag. A script will be run at this time to apply a new Koji tag (epel8-8.Y) to the latest build of a package with one of the following tags: [ epel8-stable, epel8-stable-pending ]. A compose of the epel8.Y repository will be created at this time from all packages currently tagged as epel8-8.Y. Historical composes are intended to be frozen and unchanging, but this approach leaves open the possibility of tagging other builds into epel8-8.Y and regenerating the compose if the
Stale packages in Fedora 30
Since I was looking at a copy of the F30 repo for amd64, here's a list of a bunch of packages whose dist tag suggests they haven't rebuilt successfully in any currently-supported Fedora release. I'm sure some of these are incompletely retired or there's otherwise some good reason for it, this is just to raise visibility. Fedora 21 dia-gnomeDIAicons-0.1-5.fc21.src.rpm jam-control-1.03-4.fc21.src.rpm publican-fedora-4.0-2.fc21.src.rpm rubygem-chunky_png-1.2.7-3.fc21.src.rpm rubygem-dotenv-0.8.0-3.fc21.src.rpm rubygem-gruff-0.3.6-8.fc21.src.rpm rubygem-hydra-0.24.0-6.fc21.src.rpm rubygem-kwalify-0.7.2-10.fc21.src.rpm rubygem-rmail-1.0.0-11.fc21.src.rpm rubygem-rspec-longrun-0.1.2-4.fc21.src.rpm rubygem-rufus-scheduler-2.0.4-9.fc21.src.rpm rubygem-xmpp4r-0.5-11.fc21.src.rpm rubygem-xmpp4r-simple-0.8.8-11.fc21.src.rpm R-xtable-1.7.1-4.fc21.src.rpm Fedora 22 eurephia-1.1.0-9.fc22.src.rpm hail-0.8-0.16.gf9c5b967.fc22.src.rpm kde-plasma-activitymanager-0.5-8.fc22.src.rpm kguitar-0.5.1-19.926svn.fc22.src.rpm pam_radius-1.4.0-2.fc22.src.rpm prozilla-2.0.4-18.fc22.src.rpm rubygem-authlogic-3.4.2-1.fc22.src.rpm rubygem-cookiejar-0.3.2-5.fc22.src.rpm rubygem-text-format-1.0.0-13.fc22.src.rpm sslogger-0.96-13.fc22.src.rpm steadyflow-0.2.0-4.fc22.src.rpm telepathy-haze-0.8.0-3.fc22.src.rpm udev-browse-0.3-5.fc22.src.rpm Fedora 23 brewtarget-2.1.0-3.fc23.src.rpm centerim-4.22.10-19.fc23.src.rpm escape-200912250-12.fc23.src.rpm fbdesk-1.4.1-19.fc23.src.rpm fedorainfinity-screensaver-theme-1.0.0-10.fc23.src.rpm fedora-screensaver-theme-1.0.0-12.fc23.src.rpm gnue-common-0.6.9-16.fc23.src.rpm gtkmathview-0.8.0-19.fc23.src.rpm horst-3.0-6.fc23.src.rpm kawa-2.0-2.fc23.src.rpm kmplayer-0.11.3c-10.fc23.src.rpm libexplain-1.4-4.fc23.src.rpm manaplus-1.3.10.27.2-8.fc23.src.rpm python-jabberbot-0.15-4.fc23.src.rpm qdevelop-0.29-5.fc23.src.rpm qutim-0.3.2-5.git.6f3a98a.fc23.src.rpm rubygem-openstack-quantum-client-0.1.5-9.fc23.src.rpm rubygem-puppet-lint-1.1.0-2.fc23.src.rpm rubygem-sanitize-2.1.0-5.fc23.src.rpm taskjuggler-2.4.3-22.fc23.src.rpm teal-1_40b-14.fc23.src.rpm Fedora 24 ayttm-0.6.3-14.fc24.src.rpm blobwars-1.19-13.fc24.src.rpm clojure-1.7.0-1.fc24.src.rpm dumbster-1.6-20.fc24.src.rpm elasticsearch-1.7.1-3.fc24.src.rpm font-manager-0.7.2-4.fc24.src.rpm free42-1.4.77-1.fc24.src.rpm gnomint-1.2.1-128.fc24.src.rpm golang-github-skynetservices-skydns-2.5.3-0.1.a.git8688008.fc24.src.rpm gyachi-1.2.11-14.fc24.src.rpm hoard-3.8-12.fc24.src.rpm homerun-1.2.5-5.fc24.src.rpm ht-2.0.22-4.fc24.src.rpm jboss-jaxb-intros-1.0.2-10.fc24.src.rpm jboss-web-8.0.0-0.6.Alpha1.fc24.src.rpm jboss-web-native-2.0.10-9.fc24.src.rpm jenkins-antisamy-markup-formatter-plugin-1.3-2.fc24.src.rpm jenkins-ant-plugin-1.2-6.fc24.src.rpm jenkins-commons-jelly-1.1.20120928-10.fc24.src.rpm jenkins-crypto-util-1.4-6.fc24.src.rpm jenkins-external-monitor-job-plugin-1.4-4.fc24.src.rpm jenkins-extras-memory-monitor-1.9-3.fc24.src.rpm jenkins-icon-shim-1.0.4-4.fc24.src.rpm jenkins-instance-identity-1.4-5.fc24.src.rpm jenkins-javadoc-plugin-1.3-4.fc24.src.rpm jenkins-jexl-1.1-5.20111212.fc24.src.rpm jenkins-ldap-plugin-1.11-3.fc24.src.rpm jenkins-matrix-auth-plugin-1.2-3.fc24.src.rpm jenkins-matrix-project-plugin-1.6-2.fc24.src.rpm jenkins-pam-auth-plugin-1.2-3.fc24.src.rpm jenkins-ssh-cli-auth-1.2-8.fc24.src.rpm jenkins-ssh-credentials-plugin-1.11-4.fc24.src.rpm jenkins-sshd-1.6-7.fc24.src.rpm jenkins-ssh-slaves-plugin-1.10-3.fc24.src.rpm json4s-3.2.7-4.fc24.src.rpm js-yui2-2.9.0-10.fc24.src.rpm jutils-1.0.1-13.20110719svn.fc24.src.rpm kcemirror-0.1.5-16.fc24.src.rpm libhttpserver-0.9.0-3.fc24.src.rpm libnasl-2.2.11-18.fc24.src.rpm lostirc-0.4.6-22.fc24.src.rpm mahout-collection-codegen-plugin-1.0-4.fc24.src.rpm maven-changelog-plugin-2.3-2.fc24.src.rpm maven-ejb-plugin-2.3-14.fc24.src.rpm maven-help-plugin-2.2-8.fc24.src.rpm maven-hpi-plugin-1.113-5.fc24.src.rpm maven-rar-plugin-2.4-2.fc24.src.rpm maven-repository-plugin-2.3.1-14.fc24.src.rpm mcollective-2.8.4-2.fc24.src.rpm mhwaveedit-1.4.22-9.fc24.src.rpm mingw-llvm-3.0-11.fc24.src.rpm mycila-licenses-1-4.fc24.src.rpm ncbi-blast+-2.2.31-4.fc24.src.rpm openpts-0.2.6-13.fc24.src.rpm opensaml-java-xmltooling-1.3.4-12.fc24.src.rpm Pound-2.7-3.fc24.src.rpm primer3-2.3.6-6.fc24.src.rpm quake3-1.36-26.svn2102.fc24.src.rpm racoon2-20100526a-32.fc24.src.rpm Ray-2.3.1-12.fc24.src.rpm rescu-1.8.2-0.2.gitbeb9897.fc24.src.rpm rubygem-compass-1.0.1-3.fc24.src.rpm rubygem-connection_pool-2.2.0-2.fc24.src.rpm rubygem-riot-0.12.7-3.fc24.src.rpm scalaz-7.0.0-6.fc24.src.rpm silvia-0.2.2-0.11.9324db2git.fc24.src.rpm snoopy-2.2.6-3.fc24.src.rpm snownews-1.5.12-14.fc24.src.rpm SocketW-031026-9.fc24.src.rpm sugar-colordeducto-7-7.fc24.src.rpm sugar-xoeditor-13-4.fc24.src.rpm sugar-yupana-17-3.fc24.src.rpm termit-2.9.6-8.fc24.src.rpm tunneler-1.1.1-17.fc24.src.rpm w3c-libwww-5.4.1-0.27.20060206cvs.fc24.src.rpm xar-1.5.2-15.fc24.src.rpm zhu3d-4.2.6-7.fc24.src.rpm Fedora 25 emacs-pymacs-0.25-8.fc25.src.rpm gogoc-1.2-49.fc25.src.rpm
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
On Thu, 2019-05-30 at 12:20 -0400, Adam Jackson wrote:
> - What's the mean and/or median size of an rpm in Fedora, and what
> difference in {de,}compression time would that likely experience?
Just to follow up on this since it was quick to math out. For Fedora
30's x86_64 repo, various "averages" and some nearby binary rpms to
each:
Arithmetic mean: 1347495
-rw-r--r--. 1 ajax ajax 13532128 Feb 9 16:52
texlive-pgfplots-doc-svn47373-25.fc30.noarch.rpm
-rw-r--r--. 1 ajax ajax 13522512 Feb 17 19:28
Singular-doc-4.1.1p3-4.fc30.x86_64.rpm
-rw-r--r--. 1 ajax ajax 13452180 Feb 7 11:45
asterisk-sounds-core-es-g722-1.6.1-5.fc30.noarch.rpm
-rw-r--r--. 1 ajax ajax 13411540 Mar 14 10:27
eclipse-dtp-1.14.102-4.fc30.noarch.rpm
-rw-r--r--. 1 ajax ajax 13358352 Mar 13 05:50
gcc-go-9.0.1-0.10.fc30.x86_64.rpm
Geometric mean: 104613
-rw-r--r--. 1 ajax ajax 104624 Feb 9 16:55
texlive-datetime2-polish-doc-svn36692.1.0-25.fc30.noarch.rpm
-rw-r--r--. 1 ajax ajax 104624 Feb 3 21:55 usbutils-010-3.fc30.x86_64.rpm
-rw-r--r--. 1 ajax ajax 104612 Aug 17 2018
samtools-libs-0.1.19-16.fc29.x86_64.rpm
-rw-r--r--. 1 ajax ajax 104600 Feb 5 11:43
kf5-khtml-devel-5.55.0-1.fc30.x86_64.rpm
-rw-r--r--. 1 ajax ajax 104588 Feb 2 00:49 objenesis-2.6-4.fc30.noarch.rpm
Median: 71064
-rw-r--r--. 1 ajax ajax 71068 Feb 7 01:26 dagger-1.2.2-10.fc30.noarch.rpm
-rw-r--r--. 1 ajax ajax 71068 Feb 24 17:02
gnome-shell-extension-system-monitor-applet-36-4.20190224git2583911.fc30.noarch.rpm
-rw-r--r--. 1 ajax ajax 71064 Feb 15 10:55
cbi-plugins-javadoc-1.1.5-5.fc30.noarch.rpm
-rw-r--r--. 1 ajax ajax 71064 Mar 11 08:03
opensips-acc-2.4.5-1.fc30.x86_64.rpm
-rw-r--r--. 1 ajax ajax 71060 Feb 2 05:40
libgrss-devel-0.7.0-8.fc30.x86_64.rpm
-rw-r--r--. 1 ajax ajax 71040 Feb 2 23:15
mbuffer-20181119-2.fc30.x86_64.rpm
So I kind of take it back. Even single-threaded and at zstd level 19
you'll get about 1MB/s of output (according to your sample table in the
change proposal), and something like 90% of packages are below 1MB
compressed, so I'm hard pressed to care about <1s of difference in
compression time for the vast majority of packages.
Possibly more interesting are the 21 biggest packages (an almost
arbitrary number, the 22nd biggest is the first one that's not noarch):
-rw-r--r--. 1 ajax ajax 1690320420 Feb 1 08:13
FlightGear-data-2018.3.2-1.fc30.noarch.rpm
-rw-r--r--. 1 ajax ajax 1378818072 Feb 16 12:29
speed-dreams-robots-base-2.2.2-2.fc30.noarch.rpm
-rw-r--r--. 1 ajax ajax 918112496 Mar 20 11:06
xonotic-data-0.8.2-6.fc30.noarch.rpm
-rw-r--r--. 1 ajax ajax 913953504 Feb 7 11:46
astrometry-data-4204-0.76-2.fc30.noarch.rpm
-rw-r--r--. 1 ajax ajax 876513824 Feb 16 12:29
redeclipse-data-1.5.6-9.fc30.noarch.rpm
-rw-r--r--. 1 ajax ajax 795939928 Feb 6 15:24
alienarena-data-7.71.0-2.fc30.noarch.rpm
-rw-r--r--. 1 ajax ajax 763842068 Feb 4 15:33
0ad-data-0.0.23b-2.fc30.noarch.rpm
-rw-r--r--. 1 ajax ajax 520122860 Aug 23 2018
supertuxkart-data-0.9.3-2.fc30.5.noarch.rpm
-rw-r--r--. 1 ajax ajax 518557008 Mar 13 15:44
kicad-packages3d-5.1.0-1.fc30.noarch.rpm
-rw-r--r--. 1 ajax ajax 496263868 Feb 3 22:27
vdrift-data-20141020-16.fc30.noarch.rpm
-rw-r--r--. 1 ajax ajax 464651048 Feb 7 11:46
astrometry-data-4205-0.76-2.fc30.noarch.rpm
-rw-r--r--. 1 ajax ajax 447486852 Feb 3 17:35
warsow-data-2.1.2-3.fc30.noarch.rpm
-rw-r--r--. 1 ajax ajax 426017596 Feb 26 22:33
wesnoth-data-1.14.6-1.fc30.noarch.rpm
-rw-r--r--. 1 ajax ajax 413617108 Feb 3 17:15
vegastrike-data-0.5.1-18.r1.fc30.noarch.rpm
-rw-r--r--. 1 ajax ajax 400129316 Feb 2 01:53
openarena-0.8.8-14.fc30.noarch.rpm
-rw-r--r--. 1 ajax ajax 398661608 Feb 6 21:49
berusky2-data-0.9-10.fc30.noarch.rpm
-rw-r--r--. 1 ajax ajax 398113064 Jan 31 08:12
btbuilder-data-0.5.16-4.fc30.noarch.rpm
-rw-r--r--. 1 ajax ajax 382267140 Mar 9 14:26
pioneer-data-20190203-2.fc30.noarch.rpm
-rw-r--r--. 1 ajax ajax 367174128 Feb 1 21:20
julius-japanese-models-4.4.2.1-5.fc30.noarch.rpm
-rw-r--r--. 1 ajax ajax 357514216 Feb 9 16:48
texlive-kerkis-svn15878.0-25.fc30.noarch.rpm
-rw-r--r--. 1 ajax ajax 353033380 Aug 17 2018
torcs-data-1.3.7-4.fc28.noarch.rpm
Or, the biggest desktop apps, since they're likely to see frequent
rebuilds, which are basically: eclipse, libreoffice, and firefox.
- ajax
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Wiki page correction: GRUB2
On Thu, May 30, 2019 at 10:40 AM Adam Williamson wrote: > > On Thu, 2019-05-30 at 10:29 -0600, Chris Murphy wrote: > > On Thu, May 30, 2019 at 9:26 AM Adam Williamson > > wrote: > > > > My suggested change for this section: > > > > > > > > Install the bootloader files > > > > If you don't already have the relevant packages installed, do for > > > > Fedora 22 and later versions with DNF or with YUM for older Fedora > > > > releases: > > > > > > > > - dnf install grub2-efi shim > > > > + dnf install grub2-efi-ia32 grub2-efi-x64 > > > > - yum install grub2-efi shim > > > > > > Uh. We *do* have users who don't use x86_64 arch... > > > > Right. And the original command works there. > > But...your suggestion is to remove both of the original commands...you > put '-' next to both those lines. Yes, the suggestion is flawed. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Wiki page correction: GRUB2
On Thu, May 30, 2019 at 10:39 AM Adam Williamson wrote: > On Thu, 2019-05-30 at 10:29 -0600, Chris Murphy wrote: > > Installing: > > grub2-efi-ia32 > > shim-x64 > > > > That is obviously wrong, it could never work. On x86_64 the original > > command should install 32-bit and 64-bit shim and GRUB EFI binaries. > > Well, it's sort of a problem, because both the packages provide 'grub2- > efi' and dnf's behaviour in this case is to pick one, not install both. How does netinstall handle this? I'm guessing it must be true anaconda checks sysfs for firmware bitness, and is explicitly installing only the correct shim and grub2 EFI packages for that bitness. > The only way to get both installed when you call 'dnf install grub2- > efi' would be to have some sort of dependency relationship between > them, I guess. Sounds good. But, what is the use case we're trying to solve with this wiki? The case where the user intentionally removed GRUB, perhaps in favor of some other bootloader, changed their mind, and they now want to install GRUB again? Why is it missing in the first place? I don't really care about that use case, and would demote it to the end of the wiki. And really, those users don't need install instructions. What they need is a decoder ring so they know the minimum GRUB packages by name they need to install per arch and firmware type, and maybe firmware bitness. They just need a chart. The use case I care about, are those who have had GRUB inadvertently stepped on through no (or only a little) fault of their own. This helps folks on #fedora and users@ who keep having to repeat themselves for this use case, where they could just say "here read this simple wiki". When the wiki is not concise, and instead is a giant text wall of idiosyncratic workarounds for obscure problems almost no one else is bound to have, it isn't nearly as useful. Looking at the GRUB2 wiki, I'd like to chop out 3/4ths of it. Much of it is obsolete, without even considering Fedora 30's bootloaderspec changes. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Copr builders moved to Fedora 30, added AARCH64 support
On 5/30/19 5:00 AM, Pavel Raiskup wrote: > Hello, fyi, ...snip... > As a bonus, we now have builders (F30) for aarch64 architecture! Expect > slightly slower queue processing there than on other architectures (only > up 8 builders, and slightly slower boxes). Feel free to try them, and - as > always - please report the issues :-) ...snip... great news! Thanks for all your work on this... kevin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Using fedora-active-user: unable to find fedora_cert
On 5/30/19 3:22 AM, Ankur Sinha wrote: > On Thu, May 30, 2019 11:50:12 +0200, Didier Fabert wrote: >> Hi Ankur, > > Hi Didier, > >> You have to create a directory and download one file to get script working. >> In the same directory of fedora-active-user.py >> >> mkdir fedora_cert >> curl -fsSL -o fedora_cert/__init__.py >> https://pagure.io/fedora-packager/raw/master/f/src/fedora_cert/__init__.py >> >> I modify a little this script and send pypingou a PR[1] > > Thanks for that. I've used your fork, downloaded fedora_cert as you > suggest and it works now. Ideally it should drop fedora-cert use entirely. It looks like currently all it uses it for is to figure out your username. Instead it should default to your local user name or take a --user or something. :) I'm sure pingou would love PR's... kevin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: requesting feedback on Mock default
On 5/30/19 1:49 AM, Miroslav Suchý wrote: > Hi, > you - fedora developers - are most significant users of Mock. Therefore I > would like to ask you about feedback on: > > https://github.com/rpm-software-management/mock/issues/266 > > The summary is: > Previously all output - both stdout and stderr - were mixed together. Like > you will get on normal console. > Nowadays, if there is output to stderr, mock will prefix it with BUILDSTDER > to indicate that it is coming from stdout. > > I can definitely make this configurable. That is easy. The question is, what > should be the default? Prefix the stderr? > Or print it without the prefix and mix stdout and stderr together? > > I would love to hear your opinion. Either here in the mailing list or > directly in the issue mentioned above. I think the prefix is useful/nice. So, they can be mixed, but both prefixed so you can tell which stream it came from. kevin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Wiki page correction: GRUB2
On Thu, 2019-05-30 at 10:29 -0600, Chris Murphy wrote: > On Thu, May 30, 2019 at 9:26 AM Adam Williamson > wrote: > > > My suggested change for this section: > > > > > > Install the bootloader files > > > If you don't already have the relevant packages installed, do for > > > Fedora 22 and later versions with DNF or with YUM for older Fedora > > > releases: > > > > > > - dnf install grub2-efi shim > > > + dnf install grub2-efi-ia32 grub2-efi-x64 > > > - yum install grub2-efi shim > > > > Uh. We *do* have users who don't use x86_64 arch... > > Right. And the original command works there. But...your suggestion is to remove both of the original commands...you put '-' next to both those lines. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Wiki page correction: GRUB2
On Thu, 2019-05-30 at 10:29 -0600, Chris Murphy wrote: > On Thu, May 30, 2019 at 9:26 AM Adam Williamson > wrote: > > > My suggested change for this section: > > > > > > Install the bootloader files > > > If you don't already have the relevant packages installed, do for > > > Fedora 22 and later versions with DNF or with YUM for older Fedora > > > releases: > > > > > > - dnf install grub2-efi shim > > > + dnf install grub2-efi-ia32 grub2-efi-x64 > > > - yum install grub2-efi shim > > > > Uh. We *do* have users who don't use x86_64 arch... > > Right. And the original command works there. > > I think we have a packaging problem on x86_64. On a cleanly installed > Fedora 31 Workstation, I have > > shim-x64-15-8.x86_64 > shim-ia32-15-8.x86_64 > grub2-pc-2.02-84.fc31.x86_64 > grub2-efi-ia32-cdboot-2.02-84.fc31.x86_64 > grub2-tools-extra-2.02-84.fc31.x86_64 > grub2-tools-efi-2.02-84.fc31.x86_64 > grub2-tools-minimal-2.02-84.fc31.x86_64 > grub2-pc-modules-2.02-84.fc31.noarch > grub2-tools-2.02-84.fc31.x86_64 > grub2-efi-x64-2.02-84.fc31.x86_64 > grub2-common-2.02-84.fc31.noarch > grub2-efi-x64-cdboot-2.02-84.fc31.x86_64 > grub2-efi-ia32-2.02-84.fc31.x86_64 > > If I remove: > shim-x64-15-8.x86_64 > shim-ia32-15-8.x86_64 > grub2-efi-x64-2.02-84.fc31.x86_64 > grub2-efi-x64-cdboot-2.02-84.fc31.x86_64 > grub2-efi-ia32-2.02-84.fc31.x86_64 > grub2-efi-ia32-cdboot-2.02-84.fc31.x86_64 > > And then: > # dnf install grub2-efi shim > > I get the following (edited for legibility) > > Installing: > grub2-efi-ia32 > shim-x64 > > That is obviously wrong, it could never work. On x86_64 the original > command should install 32-bit and 64-bit shim and GRUB EFI binaries. Well, it's sort of a problem, because both the packages provide 'grub2- efi' and dnf's behaviour in this case is to pick one, not install both. The only way to get both installed when you call 'dnf install grub2- efi' would be to have some sort of dependency relationship between them, I guess. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Wiki page correction: GRUB2
On Thu, May 30, 2019 at 9:26 AM Adam Williamson wrote: > > My suggested change for this section: > > > > Install the bootloader files > > If you don't already have the relevant packages installed, do for > > Fedora 22 and later versions with DNF or with YUM for older Fedora > > releases: > > > > - dnf install grub2-efi shim > > + dnf install grub2-efi-ia32 grub2-efi-x64 > > - yum install grub2-efi shim > > Uh. We *do* have users who don't use x86_64 arch... Right. And the original command works there. I think we have a packaging problem on x86_64. On a cleanly installed Fedora 31 Workstation, I have shim-x64-15-8.x86_64 shim-ia32-15-8.x86_64 grub2-pc-2.02-84.fc31.x86_64 grub2-efi-ia32-cdboot-2.02-84.fc31.x86_64 grub2-tools-extra-2.02-84.fc31.x86_64 grub2-tools-efi-2.02-84.fc31.x86_64 grub2-tools-minimal-2.02-84.fc31.x86_64 grub2-pc-modules-2.02-84.fc31.noarch grub2-tools-2.02-84.fc31.x86_64 grub2-efi-x64-2.02-84.fc31.x86_64 grub2-common-2.02-84.fc31.noarch grub2-efi-x64-cdboot-2.02-84.fc31.x86_64 grub2-efi-ia32-2.02-84.fc31.x86_64 If I remove: shim-x64-15-8.x86_64 shim-ia32-15-8.x86_64 grub2-efi-x64-2.02-84.fc31.x86_64 grub2-efi-x64-cdboot-2.02-84.fc31.x86_64 grub2-efi-ia32-2.02-84.fc31.x86_64 grub2-efi-ia32-cdboot-2.02-84.fc31.x86_64 And then: # dnf install grub2-efi shim I get the following (edited for legibility) Installing: grub2-efi-ia32 shim-x64 That is obviously wrong, it could never work. On x86_64 the original command should install 32-bit and 64-bit shim and GRUB EFI binaries. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
On Wed, 2019-05-29 at 16:19 -0400, Ben Cotton wrote:
> * Faster koji builds (installations in build roots)
The numbers here seem to indicate that you'll have faster koji build
_setup_. But getting comparable compression rates as xz means spending
(apparently) significantly more time at successful build completion.
That's likely a win overall, especially when we consider the local mock
case of "why is this build failing", where you're likely to iterate
several times until you succeed. Still, it would be nice to see some
more detailed numbers to back that up. For example:
- For the minimal buildroot, what's the difference in download size and
decompression time?
- What's the mean and/or median size of an rpm in Fedora, and what
difference in {de,}compression time would that likely experience?
- Which package's mock buildroot has the largest size (compressed or
not, though it's probably the same either way), and what time
difference would that package experience with this change?
- ajax
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
On Thu, May 30, 2019 at 5:01 PM Daniel Mach wrote: > Dne 30. 05. 19 v 8:39 Igor Gnatenko napsal(a): > > Last time I was about to propose this in F29, I did mass-rebuild myself > > and while decompressing was faster in most of the cases, the size was > > definitely worse. So definitely "Lower bandwidth on mirrors if we choose > > the highest compression level" is under the question. > My current observation is that compression ratio differs per package, > sometimes xz.2 wins, sometimes it's zstd.19. > The data I initially picked compresses better with zstd, while > recompiled RPMs that are installed in fedora:30 docker image have almost > equal size. > > BTW, which compression level did you use? > >From what I remember, I've tried at least 4-5 different ones. > Could you share some of your observations and stats if you still have them? > No, they were all on my RH laptop. But in short, quite some packages were actually bigger and building time was much slower in many cases. I think you'd want to check on 0ad-data package for something big. I never tested unpacking time because package size was bigger overall so I decided not to spend much time on it. > > > > I think before approving such changes, owners need to do mass rebuilds > > on their own and provide a graph of changes in size between original > > compression format and new one(s). > Doing that equals to the mass rebuild. > I'd rather do an analysis and if the numbers look sane, I'd prefer doing > a mass rebuild in a side tag so we can use the builds if the results are > sane. Hammering koji with so many scratch builds doesn't sound right to me. > Just use resources you have inside company :) If you don't have, I can donate some. > > > Just saying it works better on Firefox doesn't sound to me like the way > > to go. > Firefox was an example. > The other table shows real-life data based on RPMs available on Fedora > LiveCD. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Bodhi 4.0.0 deployed, one known issue so far
On Thu, 2019-05-30 at 16:13 +0200, Robert-André Mauchin wrote: > I've installed Bodhi 4 from Rawhide but fedpkg doesn't seem to be > compatible > with it yet: > > Could not execute update: This system has bodhi v4, which is > unsupported. https://pagure.io/fedpkg/issue/330 signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
On Thu, May 30, 2019 at 4:16 PM Ben Cotton wrote: > > Daniel added more contingency details to the proposal[1], but I want > to call out the contingency date. Right now it is listed as a week > before the final freeze, which is way too late. I would suggest that > the end of the mass rebuild is the appropriate contingency point. If a > second mass rebuild is required to revert this change, we can't wait > until right before final freeze. Major features should be complete prior to Beta Freeze so any contingency needs to be before that, in the case of something that needs a mass rebuild it obviously needs to be complete prior to that and if something comes up during mass rebuild I suspect a contingency should be executed around that time as if there's another (partial) rebuild needed that should happen before branching. Peter ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Wiki page correction: GRUB2
On Wed, 2019-05-29 at 17:43 -0600, Chris Murphy wrote: > On Wed, May 29, 2019 at 5:52 AM Michal Schorm wrote: > > Hello, > > > > I'd like to propose tiny correction for the Fedora wiki page about GRUB2 > > [1]. > > > > However I'm not confident enought to edit it prior to any discussions, > > so that's why I'm writing here. > > > > In the chapter "Updating GRUB 2 configuration on UEFI systems" > > In the section "Install the bootloader files" > > I believe, there should be an information added, that the 'grub2-efi' > > package *must* match your architecture. So e.g. for x86_64, you want > > the 'grub2-efi-x64' package. > > No. You can have x86_64 CPU but the firmware is 32-bit, hence ia32 > which is why there is: > > grub2-efi-ia32-1:2.02-81.fc30.x86_64.rpm > > The user space will still be 64-bit but the EFI binaries will be > 32-bit for the rare firmware floating out there that require it. There > isn't a problem with 32-bit and 64-bit EFI binaries being located on > the same EFI system volume in EFI/fedora, the firmware figures it out > (I think by filenaming convention which is mentioned in the UEFI > spec). > > My suggested change for this section: > > Install the bootloader files > If you don't already have the relevant packages installed, do for > Fedora 22 and later versions with DNF or with YUM for older Fedora > releases: > > - dnf install grub2-efi shim > + dnf install grub2-efi-ia32 grub2-efi-x64 > - yum install grub2-efi shim Uh. We *do* have users who don't use x86_64 arch... -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
Daniel added more contingency details to the proposal[1], but I want to call out the contingency date. Right now it is listed as a week before the final freeze, which is way too late. I would suggest that the end of the mass rebuild is the appropriate contingency point. If a second mass rebuild is required to revert this change, we can't wait until right before final freeze. [1] https://fedoraproject.org/w/index.php?title=Changes/Switch_RPMs_to_zstd_compression=544657 -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
> Dne 30. 05. 19 v 14:57 Kevin Kofler napsal(a): > > Jason L Tibbitts III wrote: > > > >>> "BC" == Ben Cotton writes: > >> BC> * The recommended compression level is 19. The builds will take > >> BC> longer, but the additional compression time is negligible in the > >> BC> total build time and it pays off in better compression ratio than xz > >> BC> lvl2 has. > >> > >> That seems different than other results I've seen. According to the > >> wikipedia page (https://en.wikipedia.org/wiki/Zstandard) and the > >> references therein, Ubuntu found that zstd level 19 was faster but with > >> poorer compression when compared with xz level 2 (which is the same > >> level that we use now). > I haven't recompiled all Fedora, hoping that the package set I used > (Livecd RPMs) is a good sample. Thanks for pointing this out. > > > > > If the smallest size is the goal, wouldn't it be worth trying to just use a > > higher xz level instead? > That would increase the compression ratio, but I don't know the impact > on compression and decompression times and also required memory for both > operations. > On modern system with NVMEs, CPU seems to be the bottleneck and it might > get worse if we increase xz compression level. What about constrained systems where there's limited CPU, that could be a container or a low end cloud instance without any guarantee of resources or a Raspberry Pi. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
> Dne 30. 05. 19 v 8:39 Igor Gnatenko napsal(a): > > Last time I was about to propose this in F29, I did mass-rebuild myself > > and while decompressing was faster in most of the cases, the size was > > definitely worse. So definitely "Lower bandwidth on mirrors if we choose > > the highest compression level" is under the question. > My current observation is that compression ratio differs per package, > sometimes xz.2 wins, sometimes it's zstd.19. > The data I initially picked compresses better with zstd, while > recompiled RPMs that are installed in fedora:30 docker image have almost > equal size. > > BTW, which compression level did you use? > Could you share some of your observations and stats if you still have them? > > > > > I think before approving such changes, owners need to do mass rebuilds > > on their own and provide a graph of changes in size between original > > compression format and new one(s). > Doing that equals to the mass rebuild. > I'd rather do an analysis and if the numbers look sane, I'd prefer doing > a mass rebuild in a side tag so we can use the builds if the results are > sane. Hammering koji with so many scratch builds doesn't sound right to me. The gcc team use a different process, they don't use koji at all when they test new gcc releases against the Fedora package set, you should probably reach out to them to find out their process and what infrastructure they use. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
Dne 30. 05. 19 v 14:57 Kevin Kofler napsal(a): Jason L Tibbitts III wrote: "BC" == Ben Cotton writes: BC> * The recommended compression level is 19. The builds will take BC> longer, but the additional compression time is negligible in the BC> total build time and it pays off in better compression ratio than xz BC> lvl2 has. That seems different than other results I've seen. According to the wikipedia page (https://en.wikipedia.org/wiki/Zstandard) and the references therein, Ubuntu found that zstd level 19 was faster but with poorer compression when compared with xz level 2 (which is the same level that we use now). I haven't recompiled all Fedora, hoping that the package set I used (Livecd RPMs) is a good sample. Thanks for pointing this out. If the smallest size is the goal, wouldn't it be worth trying to just use a higher xz level instead? That would increase the compression ratio, but I don't know the impact on compression and decompression times and also required memory for both operations. On modern system with NVMEs, CPU seems to be the bottleneck and it might get worse if we increase xz compression level. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
Dne 30. 05. 19 v 8:39 Igor Gnatenko napsal(a): Last time I was about to propose this in F29, I did mass-rebuild myself and while decompressing was faster in most of the cases, the size was definitely worse. So definitely "Lower bandwidth on mirrors if we choose the highest compression level" is under the question. My current observation is that compression ratio differs per package, sometimes xz.2 wins, sometimes it's zstd.19. The data I initially picked compresses better with zstd, while recompiled RPMs that are installed in fedora:30 docker image have almost equal size. BTW, which compression level did you use? Could you share some of your observations and stats if you still have them? I think before approving such changes, owners need to do mass rebuilds on their own and provide a graph of changes in size between original compression format and new one(s). Doing that equals to the mass rebuild. I'd rather do an analysis and if the numbers look sane, I'd prefer doing a mass rebuild in a side tag so we can use the builds if the results are sane. Hammering koji with so many scratch builds doesn't sound right to me. Just saying it works better on Firefox doesn't sound to me like the way to go. Firefox was an example. The other table shows real-life data based on RPMs available on Fedora LiveCD. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
Dne 30. 05. 19 v 0:05 Neal Gompa napsal(a): I'm pretty sure this would break DeltaRPMs, since none of the drpm software has been updated to handle zstd compression. Neither drpm nor deltarpm handle it today. Thanks for heads-up. We'll look into it and provide a fix soon. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
Dne 29. 05. 19 v 23:52 Josh Boyer napsal(a):
On Wed, May 29, 2019 at 4:20 PM Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/Switch_RPMs_to_zstd_compression
= Switch RPMs to zstd compression =
== Summary ==
Binary RPMs are currently compressed with xz level 2.
Switching to zstd would increase decompression speed significantly.
== Owner ==
* Name: [[User:dmach| Daniel Mach]]
* Email: dm...@redhat.com
== Detailed Description ==
* The change requires setting a new compression algorithm in rpm
macros. Then a mass rebuild of all packages is required.
The gcc team often does mass rebuilds on the side prior to updating
gcc in Fedora. Would it be possible to do the same or leverage their
rebuild work with the default changed in RPM to see what the true
overall savings is? That would get us a lot more data to see if it's
truly going to benefit the distro in terms of size and installation
speed.
I rebuilt the packages that are available in fedora:30 docker image:
https://copr.fedorainfracloud.org/coprs/dmach/fedora-zstd/
The overall size is roughly equal to xz compressed RPMs.
It's not comparable with the whole Fedora repo, but it's a good start.
I can build more packages if a larger sample is needed.
* The macro for setting the compression is: %define _binary_payload w19.zstdio
* The recommended compression level is 19. The builds will take
longer, but the additional compression time is negligible in the total
build time and it pays off in better compression ratio than xz lvl2
has.
* SRPM payload compression should stay at gzip (there's almost no
benefit in changing the compression, because SRPM's contents is
compressed already)
=== Use case: Firefox installation ===
I rebuilt firefox-66.0.5-1.fc30 with zstd level19.
Then I compared installation times with the original (xz compressed) package:
{| class="wikitable"
|-
! Compression !! Target File System !! Time
|-
| xz level 2 || tmpfs || 8s
|-
| xz level 2 || ext4 on nvme || 11s
|-
| zstd level 19 || tmpfs || 2s
|-
| zstd level 19 || ext4 on nvme || 4s
|-
|}
=== Comparison of compression algorithms and levels ===
Following table shows '''cpio''' and '''compressed cpio''' extraction
times into a tmpfs. Actual times in decompressing RPMs will differ due
to extracting on an actual disk and also some overhead in the RPM tool
(checks, scriptlets).
{| class="wikitable"
|-
! Compression !! Level!! Size B !! Size GiB
!! Compression time !! Compression time, 4 threads !!
Decompression time !! Comment
|-
| CPIO || -|| 5016785692 || 4,7
|| -|| -|| -
||
|-
| xz|| 2|| 1615017616 || 1,6
|| 9m55s|| -|| 1m36s
|| slow decompression
|-
| pxz || 2|| 1631869880 || 1,6
|| -|| 6m11s|| 1m38s
|| slow decompression
|-
| gzip || 9|| 2086354992 || 2,0
|| 10m23s || -|| 31s
|| insufficient compression ratio
|-
| bzip2 || 9|| 1889161565 || 1,8
|| 8m || -|| 2m50s
|| very slow decompression; compression ratio could be
better
|-
| zstd || 3|| 1913536587 || 1,8
|| 31s || 29s || 6,5s
||
|-
| zstd || 10 || 1737928978 || 1,7
|| 3m27s|| 2m34s|| 6,3s
||
|-
| zstd || 15 || 1717303256 || 1,7
|| 9m37s|| 6m34s|| 6,3s
|| identical compression speed to xz; fast decompression;
slightly worse compression ratio than xz
|-
| zstd || 17 || 1635525492 || 1,6
|| 16m16s || 11m20s || 6,7s
||
|-
| zstd || 19 || 1575843696 || 1,5
|| 24m2s|| 18m55s || 7,7s
||
|-
|}
== Benefit to Fedora ==
* Faster installations/upgrades of user systems
* Faster koji builds (installations in build roots)
* Faster container builds
* Lower bandwidth on mirrors if we choose the highest compression level
== Scope ==
* Proposal owners: submit a patch to redhat-rpm-config
* Other developers: redhat-rpm-config maintainer: include the patch
and make a new build
* Release engineering: [https://pagure.io/releng/issue/8345 #8345]
mass rebuild is needed
== Upgrade/compatibility impact ==
* RPM in Fedora supports zstd compression already (from Fedora 28,
rpm-4.14.0-0.rc2.5.fc28). No impact on Fedora users is expected.
* Fedora <= 27 and some other distros will not be able to decompress
zstd-compressed RPMs.
If we did this, wouldn't it
[Bug 1715484] perl-Pod-Simple-3.37 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1715484 Petr Pisar changed: What|Removed |Added External Bug ID||Github ||perl-pod/pod-simple/issues/ ||102 Fixed In Version||perl-Pod-Simple-3.37-2.fc31 --- Comment #2 from Petr Pisar --- This release bundles Pod::Escapes by an accident. I removed it. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Bodhi 4.0.0 deployed, one known issue so far
On Wednesday, 29 May 2019 18:47:51 CEST Randy Barlow wrote: > On Wed, 2019-05-29 at 11:58 -0400, Josh Boyer wrote: > > Could you make a container image based on F30 that can be run on > > F29/EPEL 7/8? That offers users a way to use the new tool on the OS > > of their choice and avoids you having to write new code or bring back > > a bunch of dependencies to the Fedora release itself. > > Yeah anyone could easily do this (just a FROM line [note: it's in > Rawhide, not F30] and a RUN dnf install line), but there are also > dependencies on bodhi-client in EPEL 7 and F29/30 so it wouldn't fully > address the issue. Any end user who wants to work around it could do > this though, and I have also provided a Copr[0] that has the new Bodhi > client that you can use too. > > I also considered modularity, but there's currently a stay on adding > new packages to the default stream since RPMs can't currently depend on > modules (and things do depend on Bodhi). > > Miro and I have proposed on the FESCo ticket to create a bodhi3-client > package and upgrade F29/30 to Bodhi 4. > > > [0] https://copr.fedorainfracloud.org/coprs/bowlofeggs/bodhi I've installed Bodhi 4 from Rawhide but fedpkg doesn't seem to be compatible with it yet: Could not execute update: This system has bodhi v4, which is unsupported. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
Hello, Ben Cotton. Wed, 29 May 2019 16:19:48 -0400 you wrote: > Switching to zstd would increase decompression speed significantly. Good change, but it will significantly increase Delta RPM rebuild process especially on HDD, that's why drpm should be disabled by default to achieve maximum speed. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: how to set passwrod for Fedora LiveCD (Fedora 30)?
On Thursday, May 30, 2019, 1:04:24 AM CDT, Samuel Sieb wrote: On 5/29/19 10:52 PM, Globe Trotter via devel wrote: >> Thanks again! I do have these lines in my fedora-live-base.ks also (that >> is being called by fedora-live-shunya-30.ks). >> >> >> # add fedora user with no passwd >> action "Adding live user" useradd \$USERADDARGS -c "Live System User" >> liveuser >> passwd -d liveuser > /dev/null >> usermod -aG wheel liveuser > /dev/null > Then if you don't have any other lines to set the password, then there > should not be a password on that account. Thanks! I posted the kickstart file earlier, but I have no other lines to set the password, but I still get prompted for a password. So I was wondering if I can explicitly set the password so that I know what to type when it asks for one. I did not have a problem with this in F29. I was not asked for the password. Something changed with regard to permissions in F30 and I am trying to find out what/or how to set the password. Many thanks again! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1715484] perl-Pod-Simple-3.37 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1715484 Tom "spot" Callaway changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |RAWHIDE Last Closed||2019-05-30 13:45:09 --- Comment #1 from Tom "spot" Callaway --- 3.37 in rawhide. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
On Wed, May 29, 2019 at 10:20 PM Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Switch_RPMs_to_zstd_compression
>
> = Switch RPMs to zstd compression =
>
> == Summary ==
> Binary RPMs are currently compressed with xz level 2.
> Switching to zstd would increase decompression speed significantly.
>
> == Owner ==
> * Name: [[User:dmach| Daniel Mach]]
> * Email: dm...@redhat.com
>
> == Detailed Description ==
> * The change requires setting a new compression algorithm in rpm
> macros. Then a mass rebuild of all packages is required.
> * The macro for setting the compression is: %define _binary_payload
> w19.zstdio
> * The recommended compression level is 19. The builds will take
> longer, but the additional compression time is negligible in the total
> build time and it pays off in better compression ratio than xz lvl2
> has.
> * SRPM payload compression should stay at gzip (there's almost no
> benefit in changing the compression, because SRPM's contents is
> compressed already)
>
> === Use case: Firefox installation ===
> I rebuilt firefox-66.0.5-1.fc30 with zstd level19.
> Then I compared installation times with the original (xz compressed)
> package:
>
> {| class="wikitable"
> |-
> ! Compression !! Target File System !! Time
> |-
> | xz level 2 || tmpfs || 8s
> |-
> | xz level 2 || ext4 on nvme || 11s
> |-
> | zstd level 19 || tmpfs || 2s
> |-
> | zstd level 19 || ext4 on nvme || 4s
> |-
> |}
>
>
> === Comparison of compression algorithms and levels ===
> Following table shows '''cpio''' and '''compressed cpio''' extraction
> times into a tmpfs. Actual times in decompressing RPMs will differ due
> to extracting on an actual disk and also some overhead in the RPM tool
> (checks, scriptlets).
>
> {| class="wikitable"
> |-
> ! Compression !! Level!! Size B !! Size GiB
> !! Compression time !! Compression time, 4 threads !!
> Decompression time !! Comment
> |-
> | CPIO || -|| 5016785692 || 4,7
> || -|| -|| -
> ||
> |-
> | xz|| 2|| 1615017616 || 1,6
> || 9m55s|| -|| 1m36s
> || slow decompression
> |-
> | pxz || 2|| 1631869880 || 1,6
> || -|| 6m11s|| 1m38s
> || slow decompression
> |-
> | gzip || 9|| 2086354992 || 2,0
> || 10m23s || -|| 31s
> || insufficient compression ratio
> |-
> | bzip2 || 9|| 1889161565 || 1,8
> || 8m || -|| 2m50s
> || very slow decompression; compression ratio could be
> better
> |-
> | zstd || 3|| 1913536587 || 1,8
> || 31s || 29s || 6,5s
> ||
> |-
> | zstd || 10 || 1737928978 || 1,7
> || 3m27s|| 2m34s|| 6,3s
> ||
> |-
> | zstd || 15 || 1717303256 || 1,7
> || 9m37s|| 6m34s|| 6,3s
> || identical compression speed to xz; fast decompression;
> slightly worse compression ratio than xz
> |-
> | zstd || 17 || 1635525492 || 1,6
> || 16m16s || 11m20s || 6,7s
> ||
> |-
> | zstd || 19 || 1575843696 || 1,5
> || 24m2s|| 18m55s || 7,7s
> ||
> |-
> |}
>
> == Benefit to Fedora ==
> * Faster installations/upgrades of user systems
> * Faster koji builds (installations in build roots)
> * Faster container builds
> * Lower bandwidth on mirrors if we choose the highest compression level
>
> == Scope ==
> * Proposal owners: submit a patch to redhat-rpm-config
> * Other developers: redhat-rpm-config maintainer: include the patch
> and make a new build
> * Release engineering: [https://pagure.io/releng/issue/8345 #8345]
> mass rebuild is needed
>
> == Upgrade/compatibility impact ==
> * RPM in Fedora supports zstd compression already (from Fedora 28,
> rpm-4.14.0-0.rc2.5.fc28). No impact on Fedora users is expected.
> * Fedora <= 27 and some other distros will not be able to decompress
> zstd-compressed RPMs.
>
> == How To Test ==
> * dnf install
> * rpm -q --qf "%{PAYLOADCOMPRESSOR} %{PAYLOADFLAGS}\n"
> * expected output: zstd 19
>
> Also the overall system installation time should decrease significantly.
>
> == User Experience ==
> See '''Benefit to Fedora'''
>
> == Dependencies ==
> N/A
>
> == Contingency Plan ==
> * Contingency mechanism: Not needed, Fedora will stay at current
> compression.
> * Contingency deadline: N/A
> * Blocks release? No
> * Blocks product? N/A
>
> == Documentation ==
> N/A
>
> == Release Notes ==
> RPMs have
[Bug 1715484] New: perl-Pod-Simple-3.37 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1715484 Bug ID: 1715484 Summary: perl-Pod-Simple-3.37 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Pod-Simple Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jose.p.oliveira@gmail.com, ka...@ucw.cz, perl-devel@lists.fedoraproject.org, ppi...@redhat.com, st...@silug.org, tcall...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 3.37 Current version/release in rawhide: 3.36-1.fc31 URL: http://search.cpan.org/dist/Pod-Simple/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/3246/ -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
Jason L Tibbitts III wrote: >> "BC" == Ben Cotton writes: > BC> * The recommended compression level is 19. The builds will take > BC> longer, but the additional compression time is negligible in the > BC> total build time and it pays off in better compression ratio than xz > BC> lvl2 has. > > That seems different than other results I've seen. According to the > wikipedia page (https://en.wikipedia.org/wiki/Zstandard) and the > references therein, Ubuntu found that zstd level 19 was faster but with > poorer compression when compared with xz level 2 (which is the same > level that we use now). If the smallest size is the goal, wouldn't it be worth trying to just use a higher xz level instead? 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1712142] perl-PAR-1.016 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1712142 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-PAR-1.016-1.fc31 |perl-PAR-1.016-1.fc31 ||perl-PAR-1.016-1.fc30 Resolution|--- |ERRATA Last Closed||2019-05-30 12:51:35 --- Comment #3 from Fedora Update System --- perl-PAR-1.016-1.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Copr builders moved to Fedora 30, added AARCH64 support
Hello, fyi, Fedora Copr builders were recently upgraded to Fedora 30 (from F28). The major change is that `yum` package is not working ideally on F30 anymore, and soon (on F31) there will be no `yum` at all [1]. Mock (which is used on builders) though uses /usr/bin/yum-deprecated (yum) by default for epel* chroots installation usually (on Fedora host), even though it may use /usr/bin/yum symlink to /usr/bin/dnf as a fallback. The major difference from mock perspective (and why yum-deprecated is actually preferred, when available) is that dnf might calculate the install transactions a little bit differently from yum. And repositories for epel are designed for/tested against yum; ... so using dnf can cause some unexpected problems.. We decided to move to dnf (dnf-yum) rather sooner in Copr, to have a bit more time for solving potential problems, and inform others. So if you face any related issues to this movement in copr (packages were installed fine before, but are not now), you might want to enable the bootstrap_chroot feature in your copr project; go to: Project -> Settings -> [x] Enable mock's use_bootstrap_container experimental feature .. and if useful, fill a bug report. For more info about bootstrap_chroot feature consult the man 1 mock. As a bonus, we now have builders (F30) for aarch64 architecture! Expect slightly slower queue processing there than on other architectures (only up 8 builders, and slightly slower boxes). Feel free to try them, and - as always - please report the issues :-) If you happen to work with epel* and mock on F30: - yum.rpm requires up2date urlgrabber package (rhbz#1707657) on highly python3-oriented F30, and to avoid unnecessary hassle you might want to rather uninstall yum package, but when you do this.. - using dnf (/bin/yum) for epel* builds might lead to problems with bootstrap chroot installation (elfutils from DTS from sclo* repos installed instead of default elfutils) [2] - also systemd-resolved running on host (even when it is unused) might cause some problems with name resolution in --bootstrap chroot, resp. if you happen to use --enable-network; work-around is to disable systemd-resolved.service [1] https://src.fedoraproject.org/rpms/yum/blob/master/f/dead.package [2] https://github.com/rpm-software-management/mock/pull/268 Hope that the transition will be smooth, happy building! Pavel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1705295] perl-Gtk3-0.035 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1705295 Jitka Plesnikova changed: What|Removed |Added Status|NEW |CLOSED CC||jples...@redhat.com Fixed In Version||perl-Gtk3-0.035-1.fc31 Resolution|--- |RAWHIDE Assignee|berra...@redhat.com |jples...@redhat.com Last Closed||2019-05-30 11:58:11 -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1715236] perl-SQL-Translator-1.60 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1715236 Jitka Plesnikova changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-SQL-Translator-1.60-1. ||fc31 Resolution|--- |RAWHIDE Last Closed||2019-05-30 11:49:00 -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
jplesnik pushed to perl-Net-LDAP-SID (master). "Perl 5.30 rebuild"
Notification time stamped 2019-05-30 11:48:41 UTC
From c7d90364faeb46fc33b9b26d61c127556d409699 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova
Date: May 30 2019 11:48:34 +
Subject: Perl 5.30 rebuild
---
diff --git a/perl-Net-LDAP-SID.spec b/perl-Net-LDAP-SID.spec
index e856790..2db33b4 100644
--- a/perl-Net-LDAP-SID.spec
+++ b/perl-Net-LDAP-SID.spec
@@ -1,6 +1,6 @@
Name: perl-Net-LDAP-SID
Version:0.001
-Release:8%{?dist}
+Release:9%{?dist}
Summary:Net::LDAP::SID Perl module
License:Artistic 2.0
URL:https://metacpan.org/release/Net-LDAP-SID
@@ -43,6 +43,9 @@ Active Directory Security Identifier manipulation
%{_mandir}/man3/*
%changelog
+* Thu May 30 2019 Jitka Plesnikova - 0.001-9
+- Perl 5.30 rebuild
+
* Fri Feb 01 2019 Fedora Release Engineering -
0.001-8
- Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
https://src.fedoraproject.org/rpms/perl-Net-LDAP-SID/c/c7d90364faeb46fc33b9b26d61c127556d409699?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
jplesnik pushed to perl-Crypt-IDEA (master). "Perl 5.30 rebuild"
Notification time stamped 2019-05-30 11:39:51 UTC
From 3ab6b538d05eb389321db4de9673b82c9036b690 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova
Date: May 30 2019 11:39:44 +
Subject: Perl 5.30 rebuild
---
diff --git a/perl-Crypt-IDEA.spec b/perl-Crypt-IDEA.spec
index 91d064b..1ae3ede 100644
--- a/perl-Crypt-IDEA.spec
+++ b/perl-Crypt-IDEA.spec
@@ -1,7 +1,7 @@
Summary: Perl interface to IDEA block cipher
Name: perl-Crypt-IDEA
Version: 1.10
-Release: 14%{?dist}
+Release: 15%{?dist}
License: BSD with advertising
Url: https://metacpan.org/release/Crypt-IDEA
Source0:
https://cpan.metacpan.org/authors/id/D/DP/DPARIS/Crypt-IDEA-%{version}.tar.gz
@@ -65,6 +65,9 @@ make test
%{_mandir}/man3/Crypt::IDEA.3*
%changelog
+* Thu May 30 2019 Jitka Plesnikova - 1.10-15
+- Perl 5.30 rebuild
+
* Fri Feb 01 2019 Fedora Release Engineering -
1.10-14
- Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
https://src.fedoraproject.org/rpms/perl-Crypt-IDEA/c/3ab6b538d05eb389321db4de9673b82c9036b690?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
jplesnik pushed to perl-Mock-Config (master). "Perl 5.30 rebuild"
Notification time stamped 2019-05-30 11:31:04 UTC
From 7df8c05b53f9c74035c30017f0b8c708bd0a7f01 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova
Date: May 30 2019 11:30:57 +
Subject: Perl 5.30 rebuild
---
diff --git a/perl-Mock-Config.spec b/perl-Mock-Config.spec
index 46047d0..6bab96c 100644
--- a/perl-Mock-Config.spec
+++ b/perl-Mock-Config.spec
@@ -1,6 +1,6 @@
Name: perl-Mock-Config
Version:0.03
-Release:7%{?dist}
+Release:8%{?dist}
Summary:Temporarily set Config or XSConfig values
License:Artistic 2.0
URL:https://metacpan.org/release/Mock-Config
@@ -44,6 +44,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Thu May 30 2019 Jitka Plesnikova - 0.03-8
+- Perl 5.30 rebuild
+
* Fri Feb 01 2019 Fedora Release Engineering -
0.03-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
https://src.fedoraproject.org/rpms/perl-Mock-Config/c/7df8c05b53f9c74035c30017f0b8c708bd0a7f01?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Modularity tooling intro?
Dne 30. 05. 19 v 11:16 Paul Howarth napsal(a): > Any pointers anyone? http://frostyx.cz/posts/how-to-build-modules-in-copr -- Miroslav Suchy, RHCA Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Stuck Package Review pass-pwned
I'll take this one. On Thu, May 30, 2019, 12:46 Brian (bex) Exelbierd wrote: > Hi, > > Bug 1711303 - Review Request: pass-pwned - Password-Store extension > for Have I Been Pwned > https://bugzilla.redhat.com/show_bug.cgi?id=1711303 > > is stuck. It got an awesome first pass on 19 May, but has received no > updates since then and has no assignee. > > Can someone take a look? > > thanks, > > bex > -- > Brian "bex" Exelbierd (he/him/his) > Fedora Community Action & Impact Coordinator > @bexelbie | http://www.winglemeyer.org > bexel...@redhat.com | b...@pobox.com > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity tooling intro?
Maybe this is the document.
https://docs.fedoraproject.org/en-US/modularity/making-modules/
In my understanding below command executes "mbs-manager" internally.
I do not run "mbs-manager" command directly.
```
$ fedpkg module-build
```
On Thu, May 30, 2019 at 11:17 AM Paul Howarth wrote:
>
> Hi everyone,
>
> I have a bunch of packages in a local repo built for various versions
> of Fedora and CentOS, and am looking to build some of them for EL-8.
> Clearly the way to go for an EL-8 add-on repo is to build modules, so
> that it what I'd like to do. However, I want to do it on my own
> infrastructure and hence use the lower-level tooling such as
> mbs-manager/mock and local git repos rather than fedpkg/koji/dist-git.
>
> There's quite a bit of documentation around about building modules but
> what I've found seems to be either out of date (e.g. uses "mbs-build",
> which no longer exists) or is based on fedpkg, which abstracts away the
> lower-level operation and is geared towards Fedora infrastructure.
>
> Is there some documentation somewhere that covers getting started with
> the tools like mbs-manager?
>
> I thought this workshop looked like a good starting point:
> https://github.com/fedora-modularity/workshop
>
> When I discovered that "mbs-build" no longer exists, I tried using
> "mbs-manager" but clearly I'm missing something:
>
> $ mbs-manager build_module_locally --file test-module.yaml -s platform:f30
> 2019-05-30 09:51:04,712 - MainThread - urllib3.util.retry - DEBUG - Converted
> retries value: 3 -> Retry(total=3, connect=None, read=None, redirect=None,
> status=None)
> 2019-05-30 09:51:04,863 - MainThread - moksha.hub - WARNING - Cannot find
> qpid python module. Make sure you have python-qpid installed.
> 2019-05-30 09:51:05,577 - MainThread - MBS.utils.submit - DEBUG - Submitted
> normal module build for test-module:f30:20190530085105
> Traceback (most recent call last):
> File "/usr/bin/mbs-manager", line 11, in
> load_entry_point('module-build-service==2.19.1', 'console_scripts',
> 'mbs-manager')()
> File "/usr/lib/python3.7/site-packages/module_build_service/manage.py",
> line 251, in manager_wrapper
> manager.run()
> File "/usr/lib/python3.7/site-packages/flask_script/__init__.py", line 417,
> in run
> result = self.handle(argv[0], argv[1:])
> File "/usr/lib/python3.7/site-packages/flask_script/__init__.py", line 386,
> in handle
> res = handle(*args, **config)
> File "/usr/lib/python3.7/site-packages/flask_script/commands.py", line 216,
> in __call__
> return self.run(*args, **kwargs)
> File "/usr/lib/python3.7/site-packages/module_build_service/manage.py",
> line 167, in build_module_locally
> username, handle, params, stream=str(stream), skiptests=skiptests)
> File
> "/usr/lib/python3.7/site-packages/module_build_service/utils/submit.py", line
> 503, in submit_module_build_from_yaml
> return submit_module_build(username, mmd, params)
> File
> "/usr/lib/python3.7/site-packages/module_build_service/utils/submit.py", line
> 633, in submit_module_build
> mmds = generate_expanded_mmds(db.session, mmd, raise_if_stream_ambigous,
> default_streams)
> File "/usr/lib/python3.7/site-packages/module_build_service/utils/mse.py",
> line 417, in generate_expanded_mmds
> current_mmd = Modulemd.Module.new_from_string(mmd.dumps())
> TypeError: :
> Argument 0 does not allow None as a value
>
> Any pointers anyone?
>
> Paul.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Jun Aruga / He - His - Him
jar...@redhat.com / IRC: jaruga
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Stuck Package Review pass-pwned
Hi, Bug 1711303 - Review Request: pass-pwned - Password-Store extension for Have I Been Pwned https://bugzilla.redhat.com/show_bug.cgi?id=1711303 is stuck. It got an awesome first pass on 19 May, but has received no updates since then and has no assignee. Can someone take a look? thanks, bex -- Brian "bex" Exelbierd (he/him/his) Fedora Community Action & Impact Coordinator @bexelbie | http://www.winglemeyer.org bexel...@redhat.com | b...@pobox.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Using fedora-active-user: unable to find fedora_cert
On Thu, May 30, 2019 11:50:12 +0200, Didier Fabert wrote: > Hi Ankur, Hi Didier, > You have to create a directory and download one file to get script working. > In the same directory of fedora-active-user.py > > mkdir fedora_cert > curl -fsSL -o fedora_cert/__init__.py > https://pagure.io/fedora-packager/raw/master/f/src/fedora_cert/__init__.py > > I modify a little this script and send pypingou a PR[1] Thanks for that. I've used your fork, downloaded fedora_cert as you suggest and it works now. -- Thanks, Regards, Ankur Sinha "FranciscoD" https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
HEADS UP: freetype 2.10.0 in rawhide
Hi, I've rebased freetype to 2.10.0 in rawhide. The package is binary compatible with previous version so there should be no issues when running your packages against it. There are some new functions and 2 API changes which should not affect you. You can see detailed list of changes here: https://sourceforge.net/projects/freetype/files/freetype2/2.10.0/ Regards Marek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Trying to contact package maintainer: Filip Szymański
Hello, Would anyone know how to contact Filip? There are a few pending bugs that they've not replied to yet[1]. The one I care about is updating urlscan[2] where I've also opened a PR that has gone unnoticed[3]. - I have been unable to check Filip's activity using fedora-active-user, so I've done it manually (will use the tool too once I've figured out howto) - Nothing shows when searching their FAS on fedocal. - Their last activity on bodhi was a year ago[4]. - Their last activity on koji was also a year ago[5]. - Their last activity on the -devel list was more than a year ago[6] - Datagrepper also does not indicate any recent activity: http get https://apps.fedoraproject.org/datagrepper/raw user==fszymanski - I've already requested Filip to respond on the urlscan bug multiple times since 2018-08-07[7]. - I also e-mailed Filip requesting co-maintainership of the package a few days go and have, unfortunately, not heard back. If we are unable to contact Filip, I will go ahead an open a FESCO ticket following the non-responsive maintainer process[8]. My primary interest lies in helping maintain urlscan, but there are one or two other packages that also require a look into. [1] https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=fszymanski.pl%40gmail.com_to1=1=substring_id=10220041_format=advanced [2] https://bugzilla.redhat.com/show_bug.cgi?id=1612483 [3] https://src.fedoraproject.org/rpms/urlscan/pull-request/1 [4] https://bodhi.fedoraproject.org/users/fszymanski [5] https://koji.fedoraproject.org/koji/userinfo?userID=3371 [6] https://lists.fedoraproject.org/archives/search?count=100=devel%40lists.fedoraproject.org=fszymanski [7] https://bugzilla.redhat.com/show_bug.cgi?id=1612483#c1 [8] https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/ -- Thanks, Regards, Ankur Sinha "FranciscoD" https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Using fedora-active-user: unable to find fedora_cert
Hi Ankur, You have to create a directory and download one file to get script working. In the same directory of fedora-active-user.py mkdir fedora_cert curl -fsSL -o fedora_cert/__init__.py https://pagure.io/fedora-packager/raw/master/f/src/fedora_cert/__init__.py I modify a little this script and send pypingou a PR[1] Cheers, Didier. [1] https://github.com/pypingou/fedora-active-user/pull/13 Le 30/05/2019 à 11:24, Ankur Sinha a écrit : Hello, Could someone please clarify how fedora-active-user[1] is to be used? It is unable to find the fedora_cert python bits, and fedora-packager no longer seems to include this either[2]. [1] https://github.com/pypingou/fedora-active-user [2] https://src.fedoraproject.org/rpms/fedora-packager/blob/master/f/fedora-packager.spec#_78 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
HEADS UP: PyPy3.5 updated to PyPy3.6
The new pypy3 build (running in rawhide and intended for rawhide only) will update from PyPy3.5 7.0.0 to PyPy3.6 7.1.1. See [1] for the actual change. Tox works (we tested it on the CI and Lumír did some sanity checks as well). If you need this on F29 or F30, feel free to grab it from Copr [2], where it is automatically rebuilt from master. See the latest 3 release announcements to get the idea about PyPy3.6 [3][4][5]. We will be updating PyPy2.7 to 7.1.1 as well soon. [1] https://src.fedoraproject.org/rpms/pypy3/pull-request/11 [2] https://copr.fedorainfracloud.org/coprs/g/python/pypy36/ [3] http://doc.pypy.org/en/latest/release-v7.0.0.html [4] http://doc.pypy.org/en/latest/release-v7.1.0.html [5] http://doc.pypy.org/en/latest/release-v7.1.1.html -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Using fedora-active-user: unable to find fedora_cert
Hello, Could someone please clarify how fedora-active-user[1] is to be used? It is unable to find the fedora_cert python bits, and fedora-packager no longer seems to include this either[2]. [1] https://github.com/pypingou/fedora-active-user [2] https://src.fedoraproject.org/rpms/fedora-packager/blob/master/f/fedora-packager.spec#_78 -- Thanks, Regards, Ankur Sinha "FranciscoD" https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
On Wed, May 29, 2019 at 9:27 PM Josh Boyer wrote:
>
> On Wed, May 29, 2019 at 6:07 PM Neal Gompa wrote:
> >
> > On Wed, May 29, 2019 at 5:53 PM Josh Boyer
> > wrote:
> > >
> > > On Wed, May 29, 2019 at 4:20 PM Ben Cotton wrote:
> > > >
> > > > https://fedoraproject.org/wiki/Changes/Switch_RPMs_to_zstd_compression
> > > >
> > > > = Switch RPMs to zstd compression =
> > > >
> > > > == Summary ==
> > > > Binary RPMs are currently compressed with xz level 2.
> > > > Switching to zstd would increase decompression speed significantly.
> > > >
> > > > == Owner ==
> > > > * Name: [[User:dmach| Daniel Mach]]
> > > > * Email: dm...@redhat.com
> > > >
> > > > == Detailed Description ==
> > > > * The change requires setting a new compression algorithm in rpm
> > > > macros. Then a mass rebuild of all packages is required.
> > >
> > > The gcc team often does mass rebuilds on the side prior to updating
> > > gcc in Fedora. Would it be possible to do the same or leverage their
> > > rebuild work with the default changed in RPM to see what the true
> > > overall savings is? That would get us a lot more data to see if it's
> > > truly going to benefit the distro in terms of size and installation
> > > speed.
> > >
> >
> > This is news to me, as I've never heard of any "side mass rebuilds".
> > They're prohibitively expensive to do, which is why we do only one per
> > release anyway.
>
> They do them quite frequently outside of the Fedora infrastructure.
>
I'm not surprised. Fedora infrastructure tooling isn't great at
allowing people to experiment with big changes. When I did the pkgconf
change, I did a chunk of it in COPR and in a local OBS instance
because it's basically impossible to test big changes in Fedora, which
limits what kind of contributors can make big changes.
It might just annoy me enough to talk about it at Flock, even...
> > > > * The macro for setting the compression is: %define _binary_payload
> > > > w19.zstdio
> > > > * The recommended compression level is 19. The builds will take
> > > > longer, but the additional compression time is negligible in the total
> > > > build time and it pays off in better compression ratio than xz lvl2
> > > > has.
> > > > * SRPM payload compression should stay at gzip (there's almost no
> > > > benefit in changing the compression, because SRPM's contents is
> > > > compressed already)
> > > >
> > > > === Use case: Firefox installation ===
> > > > I rebuilt firefox-66.0.5-1.fc30 with zstd level19.
> > > > Then I compared installation times with the original (xz compressed)
> > > > package:
> > > >
> > > > {| class="wikitable"
> > > > |-
> > > > ! Compression !! Target File System !! Time
> > > > |-
> > > > | xz level 2 || tmpfs || 8s
> > > > |-
> > > > | xz level 2 || ext4 on nvme || 11s
> > > > |-
> > > > | zstd level 19 || tmpfs || 2s
> > > > |-
> > > > | zstd level 19 || ext4 on nvme || 4s
> > > > |-
> > > > |}
> > > >
> > > >
> > > > === Comparison of compression algorithms and levels ===
> > > > Following table shows '''cpio''' and '''compressed cpio''' extraction
> > > > times into a tmpfs. Actual times in decompressing RPMs will differ due
> > > > to extracting on an actual disk and also some overhead in the RPM tool
> > > > (checks, scriptlets).
> > > >
> > > > {| class="wikitable"
> > > > |-
> > > > ! Compression !! Level!! Size B !! Size GiB
> > > > !! Compression time !! Compression time, 4 threads !!
> > > > Decompression time !! Comment
> > > > |-
> > > > | CPIO || -|| 5016785692 || 4,7
> > > > || -|| -|| -
> > > > ||
> > > > |-
> > > > | xz|| 2|| 1615017616 || 1,6
> > > > || 9m55s|| -|| 1m36s
> > > > || slow decompression
> > > > |-
> > > > | pxz || 2|| 1631869880 || 1,6
> > > > || -|| 6m11s|| 1m38s
> > > > || slow decompression
> > > > |-
> > > > | gzip || 9|| 2086354992 || 2,0
> > > > || 10m23s || -|| 31s
> > > > || insufficient compression ratio
> > > > |-
> > > > | bzip2 || 9|| 1889161565 || 1,8
> > > > || 8m || -|| 2m50s
> > > > || very slow decompression; compression ratio could be
> > > > better
> > > > |-
> > > > | zstd || 3|| 1913536587 || 1,8
> > > > || 31s || 29s || 6,5s
> > > > ||
> > > > |-
> > > > | zstd || 10 || 1737928978 || 1,7
> > > > || 3m27s|| 2m34s|| 6,3s
> > > > ||
> > > > |-
> > > > | zstd || 15 || 1717303256 || 1,7
> > > > || 9m37s|| 6m34s
Modularity tooling intro?
Hi everyone,
I have a bunch of packages in a local repo built for various versions
of Fedora and CentOS, and am looking to build some of them for EL-8.
Clearly the way to go for an EL-8 add-on repo is to build modules, so
that it what I'd like to do. However, I want to do it on my own
infrastructure and hence use the lower-level tooling such as
mbs-manager/mock and local git repos rather than fedpkg/koji/dist-git.
There's quite a bit of documentation around about building modules but
what I've found seems to be either out of date (e.g. uses "mbs-build",
which no longer exists) or is based on fedpkg, which abstracts away the
lower-level operation and is geared towards Fedora infrastructure.
Is there some documentation somewhere that covers getting started with
the tools like mbs-manager?
I thought this workshop looked like a good starting point:
https://github.com/fedora-modularity/workshop
When I discovered that "mbs-build" no longer exists, I tried using
"mbs-manager" but clearly I'm missing something:
$ mbs-manager build_module_locally --file test-module.yaml -s platform:f30
2019-05-30 09:51:04,712 - MainThread - urllib3.util.retry - DEBUG - Converted
retries value: 3 -> Retry(total=3, connect=None, read=None, redirect=None,
status=None)
2019-05-30 09:51:04,863 - MainThread - moksha.hub - WARNING - Cannot find qpid
python module. Make sure you have python-qpid installed.
2019-05-30 09:51:05,577 - MainThread - MBS.utils.submit - DEBUG - Submitted
normal module build for test-module:f30:20190530085105
Traceback (most recent call last):
File "/usr/bin/mbs-manager", line 11, in
load_entry_point('module-build-service==2.19.1', 'console_scripts',
'mbs-manager')()
File "/usr/lib/python3.7/site-packages/module_build_service/manage.py", line
251, in manager_wrapper
manager.run()
File "/usr/lib/python3.7/site-packages/flask_script/__init__.py", line 417,
in run
result = self.handle(argv[0], argv[1:])
File "/usr/lib/python3.7/site-packages/flask_script/__init__.py", line 386,
in handle
res = handle(*args, **config)
File "/usr/lib/python3.7/site-packages/flask_script/commands.py", line 216,
in __call__
return self.run(*args, **kwargs)
File "/usr/lib/python3.7/site-packages/module_build_service/manage.py", line
167, in build_module_locally
username, handle, params, stream=str(stream), skiptests=skiptests)
File "/usr/lib/python3.7/site-packages/module_build_service/utils/submit.py",
line 503, in submit_module_build_from_yaml
return submit_module_build(username, mmd, params)
File "/usr/lib/python3.7/site-packages/module_build_service/utils/submit.py",
line 633, in submit_module_build
mmds = generate_expanded_mmds(db.session, mmd, raise_if_stream_ambigous,
default_streams)
File "/usr/lib/python3.7/site-packages/module_build_service/utils/mse.py",
line 417, in generate_expanded_mmds
current_mmd = Modulemd.Module.new_from_string(mmd.dumps())
TypeError: :
Argument 0 does not allow None as a value
Any pointers anyone?
Paul.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
requesting feedback on Mock default
Hi, you - fedora developers - are most significant users of Mock. Therefore I would like to ask you about feedback on: https://github.com/rpm-software-management/mock/issues/266 The summary is: Previously all output - both stdout and stderr - were mixed together. Like you will get on normal console. Nowadays, if there is output to stderr, mock will prefix it with BUILDSTDER to indicate that it is coming from stdout. I can definitely make this configurable. That is easy. The question is, what should be the default? Prefix the stderr? Or print it without the prefix and mix stdout and stderr together? I would love to hear your opinion. Either here in the mailing list or directly in the issue mentioned above. -- Miroslav Suchy, RHCA Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
Dne 29. 05. 19 v 23:52 Josh Boyer napsal(a): > If we did this, wouldn't it make it very difficult to use tools like > mock on RHEL / CentOS 7 to build for Fedora 3x? Speaking of Mock: Either the RPM on host need to understand the new format/compression **or** the packages in @buildsys group (including transitional deps) have to be in old format - then you can build for Fedora 3x using bootstrap feature. Both of them would be painful. But I guess the former is more feasible. -- Miroslav Suchy, RHCA Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
On Wed, 2019-05-29 at 18:05 -0400, Neal Gompa wrote: > On Wed, May 29, 2019 at 5:53 PM Josh Boyer wrote: > > > > If we did this, wouldn't it make it very difficult to use tools like > > mock on RHEL / CentOS 7 to build for Fedora 3x? Or does RHEL 7 RPM > > support zstd? > > > > We're pretty much screwed here. Also, since RHEL 8's rpm package does > not have zstd support compiled in, it too cannot handle the RPMs. > > Cf. https://git.centos.org/rpms/rpm/blob/c8/f/SPECS/rpm.spec#_17-18 I just wanted to point out my post[1] in November where I suggested using zchunk as the compression format for rpm. IIRC, the main concern with that proposal was compatibility with RHEL. The one main advantage using zchunk would have over zstd would be the ability to completely eliminated drpms, but, as mentioned in that thread, it would require some changes to the RPM format. Jonathan 1: https://lists.fedorahosted.org/archives/list/devel@lists.fedoraproject.org/thread/YHKXMJHZW3O6EWA2WYMFWOC22KTVTPLB/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
Last time I was about to propose this in F29, I did mass-rebuild myself and
while decompressing was faster in most of the cases, the size was
definitely worse. So definitely "Lower bandwidth on mirrors if we choose
the highest compression level" is under the question.
I think before approving such changes, owners need to do mass rebuilds on
their own and provide a graph of changes in size between original
compression format and new one(s).
Just saying it works better on Firefox doesn't sound to me like the way to
go.
On Wed, May 29, 2019 at 10:21 PM Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Switch_RPMs_to_zstd_compression
>
> = Switch RPMs to zstd compression =
>
> == Summary ==
> Binary RPMs are currently compressed with xz level 2.
> Switching to zstd would increase decompression speed significantly.
>
> == Owner ==
> * Name: [[User:dmach| Daniel Mach]]
> * Email: dm...@redhat.com
>
> == Detailed Description ==
> * The change requires setting a new compression algorithm in rpm
> macros. Then a mass rebuild of all packages is required.
> * The macro for setting the compression is: %define _binary_payload
> w19.zstdio
> * The recommended compression level is 19. The builds will take
> longer, but the additional compression time is negligible in the total
> build time and it pays off in better compression ratio than xz lvl2
> has.
> * SRPM payload compression should stay at gzip (there's almost no
> benefit in changing the compression, because SRPM's contents is
> compressed already)
>
> === Use case: Firefox installation ===
> I rebuilt firefox-66.0.5-1.fc30 with zstd level19.
> Then I compared installation times with the original (xz compressed)
> package:
>
> {| class="wikitable"
> |-
> ! Compression !! Target File System !! Time
> |-
> | xz level 2 || tmpfs || 8s
> |-
> | xz level 2 || ext4 on nvme || 11s
> |-
> | zstd level 19 || tmpfs || 2s
> |-
> | zstd level 19 || ext4 on nvme || 4s
> |-
> |}
>
>
> === Comparison of compression algorithms and levels ===
> Following table shows '''cpio''' and '''compressed cpio''' extraction
> times into a tmpfs. Actual times in decompressing RPMs will differ due
> to extracting on an actual disk and also some overhead in the RPM tool
> (checks, scriptlets).
>
> {| class="wikitable"
> |-
> ! Compression !! Level!! Size B !! Size GiB
> !! Compression time !! Compression time, 4 threads !!
> Decompression time !! Comment
> |-
> | CPIO || -|| 5016785692 || 4,7
> || -|| -|| -
> ||
> |-
> | xz|| 2|| 1615017616 || 1,6
> || 9m55s|| -|| 1m36s
> || slow decompression
> |-
> | pxz || 2|| 1631869880 || 1,6
> || -|| 6m11s|| 1m38s
> || slow decompression
> |-
> | gzip || 9|| 2086354992 || 2,0
> || 10m23s || -|| 31s
> || insufficient compression ratio
> |-
> | bzip2 || 9|| 1889161565 || 1,8
> || 8m || -|| 2m50s
> || very slow decompression; compression ratio could be
> better
> |-
> | zstd || 3|| 1913536587 || 1,8
> || 31s || 29s || 6,5s
> ||
> |-
> | zstd || 10 || 1737928978 || 1,7
> || 3m27s|| 2m34s|| 6,3s
> ||
> |-
> | zstd || 15 || 1717303256 || 1,7
> || 9m37s|| 6m34s|| 6,3s
> || identical compression speed to xz; fast decompression;
> slightly worse compression ratio than xz
> |-
> | zstd || 17 || 1635525492 || 1,6
> || 16m16s || 11m20s || 6,7s
> ||
> |-
> | zstd || 19 || 1575843696 || 1,5
> || 24m2s|| 18m55s || 7,7s
> ||
> |-
> |}
>
> == Benefit to Fedora ==
> * Faster installations/upgrades of user systems
> * Faster koji builds (installations in build roots)
> * Faster container builds
> * Lower bandwidth on mirrors if we choose the highest compression level
>
> == Scope ==
> * Proposal owners: submit a patch to redhat-rpm-config
> * Other developers: redhat-rpm-config maintainer: include the patch
> and make a new build
> * Release engineering: [https://pagure.io/releng/issue/8345 #8345]
> mass rebuild is needed
>
> == Upgrade/compatibility impact ==
> * RPM in Fedora supports zstd compression already (from Fedora 28,
> rpm-4.14.0-0.rc2.5.fc28). No impact on Fedora users is expected.
> * Fedora <= 27 and some other distros will not be able to decompress
> zstd-compressed RPMs.
>
> == How To Test
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
On Wed, 2019-05-29 at 18:32 -0400, James Cassell wrote: > > Would this help with drpms similar to how it helps with faster yum > repo metadata downloads? My biggest problem with drpms is the slow > rebuild speed which is usually slower than my download bandwidth. It > would be a big win if zstd helps here. Unfortunately not. The drpm rebuild process involves recompressing the rpm, so we'd be affected by the compression speed, not the decompression speed. With zstd compression level > 15, the drpm rebuild speed would actually slow down (possibly quite significantly). Jonathan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
On Wed, 2019-05-29 at 20:15 -0600, Chris Murphy wrote: > 'dnf info deltarpm' says > URL : http://gitorious.org/deltarpm/deltarpm > which has an expired certificate, but pushing passed that it says > current version 3.6 is 5 years old. Is this really maintained or > updatabled? Upstream has changed to https://github.com/rpm-software-management/deltarpm. The code is still maintained, but there's not much active development. I can't speak for the upstream maintainer, but I would guess that a PR that adds zstd support would probably be welcomed. Jonathan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Perl 5.30 upgrade
Hello, Perl 5.30 was released on May 22 2019 and Perl 5.30 change is almost approved by FESCo [1]. I have required `f31-perl' build-root for this purpose [2] and it was created. To prevent possible conflict with Python 3.8 rebuild, I start the rebuild today and you can be notified via mail about commits/builds in next days. The merge to rawhide won't be done before approving changes by FESCo. Please do not build anything into `f31-perl'. Boot-strapping core modules is very peculiar. I also track all changes. You can do your upgrades into rawhide freely in parallel. You can check status on Perl 5.30 change page [3] Regards, Jitka Plesnikova [1] https://pagure.io/fesco/issue/2134 [2] https://pagure.io/releng/issue/8384 [3] https://fedoraproject.org/wiki/Changes/perl5.30#Current_Status -- Jitka Plesnikova Software Engineer Red Hat ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: how to set passwrod for Fedora LiveCD (Fedora 30)?
On 5/29/19 10:52 PM, Globe Trotter via devel wrote: Thanks again! I do have these lines in my fedora-live-base.ks also (that is being called by fedora-live-shunya-30.ks). # add fedora user with no passwd action "Adding live user" useradd \$USERADDARGS -c "Live System User" liveuser passwd -d liveuser > /dev/null usermod -aG wheel liveuser > /dev/null Then if you don't have any other lines to set the password, then there should not be a password on that account. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
