[EPEL-devel] Fedora EPEL 6 updates-testing report

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 165  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b6c663378c   
unrtf-0.21.9-8.el6
  21  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-4b684248e8   
drupal7-7.60-2.el6
  15  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-018b328024   
icecast-2.4.4-1.el6
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-307ddb503d   
php-PHPMailer-5.2.27-1.el6


The following builds have been pushed to Fedora EPEL 6 updates-testing

prosody-0.11.0-1.el6
vrms-rpm-2.0-1.el6

Details about builds:



 prosody-0.11.0-1.el6 (FEDORA-EPEL-2018-430decee3b)
 Flexible communications server for Jabber/XMPP

Update Information:

Prosody 0.11.0 ==  See upstream's blog post at
https://blog.prosody.im/prosody-0-11-0-released/ for a full overview of the
release features.  This release includes significant improvements to MUC and
Pubsub, adds support for vCard4, mobile battery optimisations and Lua 5.2.
Upgrade notes -  There are some changes that users running previous
versions of Prosody should be aware of:  Modules added -*
`mod_csi_simple`  This is a renamed version of the `mod_csi_pump` community
module. If you are using `mod_csi_pump` or do not yet have a CSI module set up,
we encourage you to use this one.* `mod_muc_mam`  This replaces the
community module `mod_mam_muc` (note the name change!).  It provides support
for archiving and querying chatroom messages using XEP-0313. It should be added
to `modules_enabled` under your MUC component:  ``` Component
"rooms.example.com" "muc" modules_enabled = { "muc_mam"; } ```
* `mod_vcard4`, `mod_vcard_legacy`  Prosody now offers support for vCard4 in
`mod_vcard4`. Since most clients today do not yet support this format, if you
use this module you should also enable `mod_vcard_legacy`.  These modules
are separate to the old `mod_vcard`, which still exists and works for services
that want to continue just supporting the older vcard-temp protocol.  Modules
removed ---  The following modules were deprecated in previous
releases and have been removed in 0.11:* `mod_storage_sql1`   *
`mod_compression`   * `mod_privacy`  MySQL schema upgrade 
Some limitations were found with the current MySQL schema that prevented it from
working properly with our new pubsub and PEP features. Prosody will refuse to
connect to the database until this is fixed, but this can be done easily with
the following command:  ``` prosodyctl mod_storage_sql upgrade ```  Lua 5.2
---  The recommended Lua version for 0.11 is Lua 5.2, while Lua 5.1 is still
supported for the platforms that need it. However the 0.11.x series is the last
series that will still support Lua 5.1 (and by extension, LuaJIT).

ChangeLog:

* Mon Nov 19 2018 Robert Scheck  0.11.0-1
- Upgrade to 0.11.0




 vrms-rpm-2.0-1.el6 (FEDORA-EPEL-2018-02303a1628)
 Report non-free software

Update Information:

Update to upstream release 2.0

ChangeLog:

* Tue Nov 20 2018 Artur Iwicki  - 2.0-1
- Update to newest upstream release
- No longer a noarch package


___
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

[Bug 1651942] Upgrade perl-File-Slurp to 9999.25

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-File-Slurp-.25-1.fc29 has been pushed to the Fedora 29 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-94d7ac7a1d

-- 
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 1651941] Upgrade perl-CPAN-Perl-Releases to 3.82

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
perl-CPAN-Perl-Releases-3.82-1.fc29 has been pushed to the Fedora 29 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-f87a5b1816

-- 
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 1651943] Upgrade perl-Module-CoreList to 5.20181120

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
perl-Module-CoreList-5.20181120-1.fc29 has been pushed to the Fedora 29 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-3cfb210f6d

-- 
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 1651941] Upgrade perl-CPAN-Perl-Releases to 3.82

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
perl-CPAN-Perl-Releases-3.82-1.fc27 has been pushed to the Fedora 27 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-c47509e11d

-- 
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: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

[Kevin Kofler]

Matthew Miller wrote:
> Leigh, it may be "lame" to you, but it's important to many people with
> bandwidth limitations or slower connections. There's always room for
> improvement but let's please not talk about other people's work in this
> way. Thank you.

The thing is, with a fast network and a slow CPU, deltarpms actually slow 
you down. No wonder users in such a situation hate them.

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 1651941] Upgrade perl-CPAN-Perl-Releases to 3.82

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-CPAN-Perl-Releases-3.82-1.fc28 has been pushed to the Fedora 28 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-0184dea376

-- 
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 1651943] Upgrade perl-Module-CoreList to 5.20181120

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-Module-CoreList-5.20181120-1.fc28 has been pushed to the Fedora 28 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-fbc92bbd6a

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

Fedora Rawhide-20181121.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 22/142 (x86_64), 7/24 (i386), 1/2 (arm)

New failures (same test did not fail in Rawhide-20181120.n.0):

ID: 311037  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/311037
ID: 311048  Test: x86_64 Server-dvd-iso server_cockpit_default
URL: https://openqa.fedoraproject.org/tests/311048
ID: 311057  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/311057
ID: 311060  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/311060
ID: 311061  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/311061
ID: 311068  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/311068
ID: 311081  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/311081
ID: 311085  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/311085
ID: 34  Test: x86_64 universal install_multi
URL: https://openqa.fedoraproject.org/tests/34
ID: 38  Test: x86_64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/38
ID: 311122  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/311122
ID: 311148  Test: x86_64 universal install_software_raid
URL: https://openqa.fedoraproject.org/tests/311148
ID: 311150  Test: x86_64 universal install_btrfs
URL: https://openqa.fedoraproject.org/tests/311150
ID: 311176  Test: x86_64 universal install_kickstart_hdd
URL: https://openqa.fedoraproject.org/tests/311176
ID: 311181  Test: x86_64 universal install_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/311181
ID: 311188  Test: i386 universal install_scsi_updates_img
URL: https://openqa.fedoraproject.org/tests/311188
ID: 311190  Test: i386 universal install_software_raid
URL: https://openqa.fedoraproject.org/tests/311190
ID: 311198  Test: i386 universal install_blivet_lvmthin
URL: https://openqa.fedoraproject.org/tests/311198
ID: 311200  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/311200
ID: 311201  Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/311201

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

ID: 311038  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/311038
ID: 311053  Test: x86_64 Server-dvd-iso realmd_join_sssd
URL: https://openqa.fedoraproject.org/tests/311053
ID: 311076  Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/311076
ID: 311079  Test: x86_64 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/311079
ID: 311080  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/311080
ID: 311083  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/311083
ID: 311099  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/311099
ID: 311120  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/311120
ID: 311121  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/311121
ID: 311172  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/311172

Soft failed openQA tests: 2/142 (x86_64), 2/24 (i386)
(Tests completed, but using a workaround for a known bug)

New soft failures (same test did not soft fail in Rawhide-20181120.n.0):

ID: 311098  Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/311098
ID: 311102  Test: x86_64 AtomicHost-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/311102

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

ID: 311062  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/311062
ID: 311087  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/311087

Passed openQA tests: 105/142 (x86_64), 15/24 (i386)

New passes (same test did not pass in Rawhide-20181120.n.0):

ID: 311042  Test: x86_64 Server-dvd-iso base_update_cli
URL: https://openqa.fedoraproject.org/tests/311042
ID: 311134  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/311134
ID: 311137  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/311137
ID: 311151  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/311151
ID: 311159  Test: 

[EPEL-devel] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 165  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3835d39d1a   
unrtf-0.21.9-8.el7
 116  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f9d6ff695a   
bibutils-6.6-1.el7 ghc-hs-bibutils-6.6.0.0-1.el7 pandoc-citeproc-0.3.0.1-4.el7
  99  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d   
condor-8.6.11-1.el7
  71  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3492a96896   
myrepos-1.20180726-1.el7
  21  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-bdb21ebc3f   
drupal7-7.60-2.el7
  14  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-32e0cee0bb   
perl-Mojolicious-7.94-1.el7
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-9051b49e75   
suricata-4.0.6-1.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-fc29932f12   
pdns-4.0.6-2.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f9270bbaec   
pdns-recursor-4.1.7-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-a09ace87bb   
php-PHPMailer-5.2.27-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-0e73364530   
python-paramiko-2.1.1-0.9.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-c25e48ded1   
bird-1.6.4-2.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-2206653eb9   
python-django-1.11.13-4.el7 python-django16-1.6.11.7-5.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

ignition-0.28.0-11.gitf707912.el7
moodle-3.1.15-1.el7
pidgin-groupchat-typing-notifications-3-1.el7
prosody-0.11.0-1.el7
purple-discord-0-21.20181108gita5dd44f.el7
purple-hangouts-0-61.20181118hg833609a.el7
resultsdb-2.1.2-1.el7
vrms-rpm-2.0-1.el7
wsjtx-1.9.1-2.el7

Details about builds:



 ignition-0.28.0-11.gitf707912.el7 (FEDORA-EPEL-2018-d7d22c4141)
 First boot installer and configuration tool

Update Information:

newest iteration of igntion-dracut modules upstream

ChangeLog:

* Tue Nov 20 2018 Jonathan Lebon  - 0.28.0-11.git7b83454
- Bump to ignition-dracut 7b83454
* Thu Oct 25 2018 Dusty Mabe  - 0.28.0-10.gitf707912
- Bump to ignition-dracut decf63f
- * 03d8438 30ignition: only instmods if module available
* Thu Oct 25 2018 Dusty Mabe  - 0.28.0-9.gitf707912
- Bump to ignition-dracut 7ee64ca
- * 3ec0b39 remove ignition-remount-sysroot.service files
  * 66335f2 ignition: run files stage at original CL ordering
  * 0301a03 ignition-disks.service: drop Requires=network.target
  * a0bc135 ignition-ask-var-mount.service: use RemainAfterExit=yes
  * ecf5779 module-setup.sh: explicitly install qemu_fw_cfg
* Mon Oct 15 2018 Dusty Mabe  - 0.28.0-8.gitf707912
- Bump to ignition-dracut 4bdfb34
- * 6d0763a module-setup: Make mkfs.btrfs optional
* Wed Oct 10 2018 Jonathan Lebon  - 0.28.0-7.gitf707912
- Backport patch for handling sysctl files correctly
  https://github.com/coreos/coreos-assembler/pull/128
  https://github.com/openshift/machine-config-operator/pull/123




 moodle-3.1.15-1.el7 (FEDORA-EPEL-2018-3f65916e08)
 A Course Management System

Update Information:

CVE-2018-16854

ChangeLog:

* Wed Nov 21 2018 Gwyn Ciesla  - 3.1.15-1
- 3.1.15

References:

  [ 1 ] Bug #1652022 - CVE-2018-16854 moodle: Login CSRF vulnerability in login 
form [epel-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1652022
  [ 2 ] Bug #1652021 - CVE-2018-16854 moodle: Login CSRF vulnerability in login 
form [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1652021




 pidgin-groupchat-typing-notifications-3-1.el7 (FEDORA-EPEL-2018-b1e948d2d4)
 Adds typing notifications for group chats in Pidgin

Update Information:

Updated to latest upstream version.

ChangeLog:

* Wed Nov 21 2018 Vitaly Zaitsev  - 3-1
- Updated to version 3.
* Fri Jul 13 2018 Fedora Release Engineering  - 2-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild
* Fri Feb  9 2018 Fedora Release Engineering  - 2-6
- Rebuilt for 

[389-devel] 389 DS nightly 2018-11-22 - 91% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2018/11/22/report-389-ds-base-1.4.0.19-20181122git7ee2be8.fc29.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

Fedora rawhide compose report: 20181121.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20181120.n.0
NEW: Fedora-Rawhide-20181121.n.0

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  3
Dropped packages:1
Upgraded packages:   63
Downgraded packages: 0

Size of added packages:  4.84 MiB
Size of dropped packages:65.11 MiB
Size of upgraded packages:   5.25 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: perl-Mojo-SQLite-3.001-1.fc30
Summary: Tiny Mojolicious wrapper for SQLite
RPMs:perl-Mojo-SQLite
Size:53.67 KiB

Package: python-pymatreader-0.0.17-1.fc30
Summary: Convenient reader for Matlab mat files
RPMs:python-pymatreader-doc python3-pymatreader
Size:4.69 MiB

Package: python-xnat-0.3.11-2.fc30
Summary: A new XNAT client that exposes XNAT objects/functions as python 
objects/functions.
RPMs:python3-xnat
Size:98.39 KiB


= DROPPED PACKAGES =
Package: cutegram-3.0-0.12gitbfdceb3.fc29
Summary: Cutegram is a telegram client by Aseman Land
RPMs:cutegram
Size:65.11 MiB


= UPGRADED PACKAGES =
Package:  armadillo-9.200.4-1.fc30
Old package:  armadillo-9.100.5-1.fc30
Summary:  Fast C++ matrix library with syntax similar to MATLAB and Octave
RPMs: armadillo armadillo-devel
Size: 8.61 MiB
Size change:  31.49 KiB
Changelog:
  * Tue Nov 20 2018 Jos?? Matos  - 9.200.4-1
  - update to 9.200.4


Package:  brise-0.38.20180515-1.fc30
Old package:  brise-0.35-8.fc29
Summary:  The official Rime schema repository
RPMs: brise
Size: 35.02 MiB
Size change:  -74.42 MiB
Changelog:
  * Wed Nov 21 2018 Peng Wu  - 0.38.20180515-1
  - Update to 0.38.20180515


Package:  buildah-1.5-11.dev.git2ac987a.fc30
Old package:  buildah-1.5-10.dev.gitc9cb148.fc30
Summary:  A command line tool used for creating OCI Images
RPMs: buildah
Size: 23.51 MiB
Size change:  62.86 KiB
Changelog:
  * Wed Nov 21 2018 Lokesh Mandvekar (Bot)  - 
1.5-11.dev.git2ac987a
  - autobuilt 2ac987a


Package:  cabal-install-2.0.0.1-8.fc30
Old package:  cabal-install-2.0.0.1-7.fc30
Summary:  The command-line interface for Cabal and Hackage
RPMs: cabal-install
Size: 35.91 MiB
Size change:  1.29 KiB
Changelog:
  * Wed Nov 21 2018 Jens Petersen  - 2.0.0.1-8
  - no longer requires ghc-Cabal-devel


Package:  couchdb-1.7.1-12.fc30
Old package:  couchdb-1.7.1-10.fc29
Summary:  A document database server, accessible via a RESTful JSON API
RPMs: couchdb
Size: 19.92 MiB
Size change:  -16.55 KiB
Changelog:
  * Wed Nov 21 2018 Peter Lemenkov  - 1.7.1-12
  * Thu Jul 12 2018 Fedora Release Engineering  - 
1.7.1-11
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild


Package:  csnappy-0-13.20181121gitb476930.fc30
Old package:  csnappy-0-12.20180322git51802a8.fc29
Summary:  Snappy compression library ported to C
RPMs: csnappy csnappy-devel
Size: 148.83 KiB
Size change:  -3.85 KiB
Changelog:
  * Wed Nov 21 2018 Petr Pisar  - 0-13.20181121gitb476930
  - Rebased to b47693024402fa8760edcd4fed71131cbd5ac175


Package:  deepin-api-3.9.0-1.fc30
Old package:  deepin-api-3.1.20-3.fc29
Summary:  Go-lang bingding for dde-daemon
RPMs: deepin-api golang-deepin-api-devel
Size: 160.07 MiB
Size change:  65.64 MiB
Changelog:
  * Sat Aug 25 2018 mosquito  - 3.1.26-1
  - Update to 3.1.26
  - build error with gobject-introspection 1.58 by gir-generator
https://github.com/linuxdeepin/developer-center/issues/604

  * Fri Nov 09 2018 mosquito  - 3.5.0-1
  - Update to 3.5.0

  * Wed Nov 21 2018 mosquito  - 3.9.0-1
  - Update to 3.9.0


Package:  deepin-calculator-1.0.9-1.fc30
Old package:  deepin-calculator-1.0.2-2.fc29
Summary:  An easy to use calculator for ordinary users
RPMs: deepin-calculator
Size: 1.74 MiB
Size change:  -597.62 KiB
Changelog:
  * Mon Jul 23 2018 mosquito  - 1.0.4-1
  - Update to 1.0.4

  * Thu Aug 02 2018 mosquito  - 1.0.5-1
  - Update to 1.0.5

  * Sat Aug 25 2018 mosquito  - 1.0.6-1
  - Update to 1.0.6

  * Fri Nov 09 2018 mosquito  - 1.0.9-1
  - Update to 1.0.9


Package:  deepin-calendar-1.2.5-1.fc30
Old package:  deepin-calendar-1.1.1-3.fc29
Summary:  Calendar for Deepin Desktop Environment
RPMs: deepin-calendar
Size: 583.88 KiB
Size change:  -9.73 KiB
Changelog:
  * Fri Jul 20 2018 mosquito  - 1.2.3-1
  - Update to 1.2.3

  * Thu Aug 02 2018 mosquito  - 1.2.4-1
  - Update to 1.2.4

  * Fri Aug 10 2018 mosquito  - 1.2.5-1
  - Update to 1.2.5


Package:  deepin-control-center-4.7.6.1-1.fc30
Old package:  deepin-control-center-4.3.7-3.fc29
Summary:  New control center for Linux Deepin
RPMs: deepin-control-center
Size: 25.04 MiB
Size change:  5.02 MiB
Changelog:
  * Thu Jul 12 2018 Fedora Release Engineering  - 
4.3.7-4

Re: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

[Jonathan Dieter]

On Wed, 2018-11-21 at 14:36 +0100, Kamil Paral wrote:
> On Fri, Nov 16, 2018 at 11:13 PM Jonathan Dieter  wrote:
> > For reference, this is in reply to Paul's email about lifecycle
> > objectives, specifically focusing on problem statement #1[1].
> > 
> > 
> > Have rpm use zchunk as its compression format, removing the need for
> > deltarpms, and thus reducing compose time.  This will require changes
> > to both the rpm format and new features in the zchunk format.
> > 
> 
> Hey Jonathan,
> 
> thanks for working on this. The proposed changes sound good to me.
> I'm a bit worried that zchunk is not yet a proven format, so it might
> be a good idea to use it for metadata first, see whether it works as
> expected, and then push it for RPM files. But that's for more
> technical people to judge.
> 
> I have some concrete questions, though:
> 1. I have noticed that especially with large RPMs (firefox, chrome,
> atom, game data like 0ad-data, etc), my PCs are mostly bottlenecked
> by CPU when installing them. And that's with a modern 3.5+GHz CPU.
> That's because RPM decompression runs in a single thread only, and xz
> is just unbelievably slow. I wonder, would zchunk used as an RPM
> compression algorithm improve this substantially? Can it decompress
> in multiple threads and/or does it have much faster decompression
> speeds (and how much)? I don't care about RPM size increase, but I'd
> really like to have them installed fast. (That's of course just my
> personal preference, but this also affects the speed of mock builds
> and such, so I think it's relevant.)

The zstd compression that zchunk uses internally is designed to be
faster than even gzip at decompression.  Currently zchunk is single-
threaded, but, given that each chunk is independent, making it multi-
threaded should be pretty trivial, and is on the todo list.

> 2. In our past QA efforts in Fedora, we had use cases for retrieving
> rpm header data without retrieving the actual content (the payload).
> That was for cases when we needed to check e.g. dependency issues,
> but the rpms were not placed in a repository yet (i.e. no easy access
> to their metadata) and it was slow and wasteful to download the whole
> rpm just to get the header. Will the new zchunk compression still
> make it possible to retrieve just the header without accessing all
> the payload data? (It would be great to make this accessible from
> Python and not just C, but that's a plea I should direct to rpm
> maintainers, I guess).

The zchunk format supports the concept of multiple independent streams
in a single file.  A zchunk rpm would contain two streams, the rpm
header and the rpm payload.  Since downloading a zchunk file is two
steps already (downloading the zchunk header, and then downloading the
required chunks), it should be easy enough to download only the chunks
needed for the rpm header stream.

As for a python API, I would love for zchunk to have that too, but
haven't had the time yet.

I hope that helps.

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: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

[Jonathan Dieter]

On Wed, 2018-11-21 at 11:31 -0500, Colin Walters wrote:
> After having introduced a new format (OSTree) into the ecosystem here,
> as well as working a lot on the Docker/OCI ecosystem, one thing I want
> to emphasize is:
> 
> A lot of Red Hat's customers don't connect their systems to the Internet,
> they want easy offline mirroring.  OSTree supports that, and it's
> also possible to do with OCI images of course.
> 
> But, a lot organizations use e.g. https://jfrog.com/artifactory/
> which today doesn't support OSTree (it does support RPM and Docker/OCI).
> So any format break for RPM wouldn't be usable until Artifactory gains
> support for it.  And even after that happened you'd have in some
> places a large lag time for it to be deployed.
> 
> In general, any data format break is going to impose a lot higher
> costs than you might imagine.

Thanks for bringing up these points.  You are undoubtedly correct that
there's an unknown cost associated with these changes, but hopefully
the cost will become a little clearer once we have a POC.

> (Also on this topic, I should note that the OSTree data format cleanly
>  fixes a lot of the issues being discussed here; it has deltas, and also
>  doesn't make the mistake of checksumming compressed data,
>  when performing updates only changed files are rewritten, not to mention
>  a whole transactional update system, etc.)

Yep.  I've experimented with OSTree and love the concepts behind it.  I
don't think we're quite ready to ditch the classic rpm systems yet,
though.

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: Automating package maintainers responsivity check

[Jonathan Wakely]

On 18/11/18 09:44 +, Mattia Verga wrote:

Il 11/17/18 10:59 PM, Philip Kovacs ha scritto:


  You want to attract packagers, not irritate them.


In my opinion, "irritating" is when a maintainer doesn't reply to bugs that 
users fill in Bugzilla. If they can't found enough time to reply or change state of any 
bug in a six months period, than maybe it is better someone else take care of their 
package.


This assumes there is a queue of ready and willing (and competent)
volunteers to take on packages that get automatically orphaned. Is
that true? I doubt it. If those people exist, why aren't they already
offering to co-maintain packages, or responding to some of those open
bugs?

I don't think those people exist. Not in significant numbers anyway.

Automatically taking away packages from inactive maintainers is
probably just going to mean even more work for a small handful of
people who already do tons of work for the distro anyway. They'll have
to take on all those orphaned packages, to ensure the distro keeps
working. I don't want to overload those people.


Being a volunteer doesn't mean to not have any responsibility.


___
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: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

[Mohan Boddu]

+1 to the reducing compose time, although there are many other things that
we have to do to make it even faster.

There are many good points that people are bringing up here, but I hope it
wont have any bottlenecks as that of xz compression.

Also since its a very young technology we should spend some good quality of
time in testing.

Thanks for working on this.

On Fri, Nov 16, 2018 at 5:13 PM Jonathan Dieter  wrote:

> For reference, this is in reply to Paul's email about lifecycle
> objectives, specifically focusing on problem statement #1[1].
>
> 
> Have rpm use zchunk as its compression format, removing the need for
> deltarpms, and thus reducing compose time.  This will require changes
> to both the rpm format and new features in the zchunk format.
> 
>
> *deltarpm background*
> As part of the compose process, deltarpms are generated between each
> new rpm and both the GA version of the rpm and the previous version.
> This process is very CPU and memory intensive, especially for large
> rpms.
>
> This also means that deltarpms are only useful for an end user if they
> are either updating from GA or have been diligent about keeping their
> system up-to-date.  If a user is updating a package from N-2 to N,
> there will be no deltarpm and the full rpm will be downloaded.
>
> *zchunk background*
> As some are aware, I've been working on zchunk[2], a compression format
> that's designed for highly efficient deltas, and using it minimize
> metadata downloads[3].
>
> The core idea behind zchunk is that a file is split into independently
> compressed chunks and the checksum of each compressed chunk is stored
> in the zchunk header.  When downloading a new version of the file, you
> download the zchunk header first, check which chunks you already have,
> and then download the rest.
>
> *Proposal*
> My proposal would be to make zchunk the rpm compression format for
> Fedora.  This would involve a few additions to the zchunk format[4]
> (something the format has been designed to accommodate), and would
> require some changes to the rpm file format.
>
> *Benefit*
> The benefit of zchunked rpms is that, when downloading an updated rpm,
> you would only need to download the chunks that have changed from
> what's on your system.
>
> The uncompressed local chunks would be combined with the downloaded
> compressed chunks to create a local rpm that will pass signature
> verification without needing to recompress the uncompressed local
> chunks, making this computationally much faster than rebuilding a
> deltarpm, a win for users.
>
> The savings wouldn't be as good as what deltarpm can achieve, but
> deltarpms would be redundant and could be removed, completely
> eliminating a large step from the compose process.
>
> *Drawbacks*
>1. Downloading a new release of a zchunked rpm would be larger than
>   downloading the equivalent deltarpm.  This is offset by the fact
>   that the client is able to work out which chunks it needs no matter
>   what the original rpm is, rather than needing a specific original
>   rpm as deltarpm does.
>2. The rebuilt rpm may not be byte-for-byte identical to the original,
>   but will be able to be validated without decompression, as explained
>   in the next section
>
> *Changes*
> The zchunk format would need to be extended to allow for a zchunked rpm
> to contain both the uncompressed chunks that were already on the local
> system and the newly downloaded compressed chunks while still passing
> signature verification.  This would also require moving signature
> verification to zchunk.
>
> The rpm file format has to be changed because the zchunk header needs
> to be at the beginning of the file in order for the zchunk library
> figure out which chunks it needs to download.  My suggestions for
> changes to the rpm file format are as follows:
>
>1. Signing should be moved to the zchunk format as described at the
>   beginning of this section
>2. The rpm header should be stored in one stream inside the zchunk
>   file.  This allows it to be easily extracted separately from the
>   data
>3. The rpm cpio should be stored in a second stream inside the zchunk
>   file.
>4. At minimum, an optional zchunk element should be set to identify
>   zchunk rpms as rpms rather than regular zchunk files.  If desired,
>   optional elements could also be set containing %{name}, %[version},
>   %{release}, %{arch} and %{epoch}.  This would allow this information
>   to be read easily without needing to extract the rpm header stream.
>
> *Final notes*
> I realize this is a massive proposal, zchunk is still very young, and
> we're still working on getting the dnf zchunk pull requests reviewed.
> I do think it's feasible and provides an opportunity to eliminate a
> pain point from our compose process while still reducing the download
> size for our users.
>
> [1]:
>
> 

[Bug 1648308] Upgrade perl-Net-UPnP to 1.4.5

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Net-UPnP-1.4.5-1.fc30  |perl-Net-UPnP-1.4.5-1.fc30
   |perl-Net-UPnP-1.4.5-1.fc27  |perl-Net-UPnP-1.4.5-1.fc27
   |perl-Net-UPnP-1.4.5-1.fc28  |perl-Net-UPnP-1.4.5-1.fc28
   ||perl-Net-UPnP-1.4.5-1.fc29



--- Comment #10 from Fedora Update System  ---
perl-Net-UPnP-1.4.5-1.fc29 has been pushed to the Fedora 29 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: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

[Colin Walters]

On Sat, Nov 17, 2018, at 12:24 PM, Jonathan Dieter wrote:

> Agreed, that this would be a massive format change and should therefore
> be a major version bump for RPM.  New versions of RPM should still be
> able to read and install old-format rpms, but, as you point out, old
> versions of RPM won't be able to read or install new-format rpms. 
> Unfortunately, I don't see any way around this.

After having introduced a new format (OSTree) into the ecosystem here,
as well as working a lot on the Docker/OCI ecosystem, one thing I want
to emphasize is:

A lot of Red Hat's customers don't connect their systems to the Internet,
they want easy offline mirroring.  OSTree supports that, and it's
also possible to do with OCI images of course.

But, a lot organizations use e.g. https://jfrog.com/artifactory/
which today doesn't support OSTree (it does support RPM and Docker/OCI).
So any format break for RPM wouldn't be usable until Artifactory gains
support for it.  And even after that happened you'd have in some
places a large lag time for it to be deployed.

In general, any data format break is going to impose a lot higher
costs than you might imagine.

(Also on this topic, I should note that the OSTree data format cleanly
 fixes a lot of the issues being discussed here; it has deltas, and also
 doesn't make the mistake of checksumming compressed data,
 when performing updates only changed files are rewritten, not to mention
 a whole transactional update system, etc.)
___
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: Container updates available in bodhi

[Ken Dreyer]

On Thu, Nov 15, 2018 at 6:09 AM Clement Verna  wrote:
>
> On Thu, 15 Nov 2018 at 13:55, Petr Pisar  wrote:
>> And unrelated question: The koji build NVR does not contain dist-git
>> name space. Does that mean there will be race conditions between rpms
>> and container builds when the NVR string will conflict and preventing
>> from an successfull koji build?
>
> OSBS grabs from koji the latest NVR available and increments the release
> number, so we would not have identical NVR. But indeed that could mess up the
> build of the rpm package if the release number was already used by OSBS,
> that's something that needs to be improved.

I think it's a good idea for Koji content generators to import builds
named with a particular suffix.

For OSBS, it makes sense to have all the container builds named with a
"-container" suffix. This is how we do it in another Koji+OSBS
instance I use. I guess there is nothing in OSBS (yet!) that enforces
this convention for the "BZComponent' or "com.redhat.component" labels
in the Dockerfile.

When we use name suffixes with content generator builds, we won't have
Release number collisions, or pollute "koji list-tagged --latest" or
"koji list-builds --package", or throw off getAverageBuildDuration,
etc.

- Ken
___
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: prevent accidentally creating branches in dist-git

[Jason L Tibbitts III]

> "DM" == Dusty Mabe  writes:

DM> I personally think this should be the default for all projects but I
DM> don't know if there is a way to easily make that happen when a
DM> project gets created.

I'm sure there could be.  But I'd go further and say that we should set
that on all existing repositories and then let folks opt out if they
wish.

 - J<
___
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: prevent accidentally creating branches in dist-git

[Neal Gompa]

On Tue, Nov 20, 2018 at 9:26 AM Dusty Mabe  wrote:
>
>
> I've certainly made the mistake of accidentally creating branches
> in dist-git and now being stuck with them because we can't delete
> them. Now that src.fedoraproject.org (dist-git) is backed by a newer
> version of pagure you can prevent creating new branches by `git push`.
>
> For your project in the web UI:
>
> - Go to the `Settings` menu
> - Select `Hooks` from the left hand side
> - Expand `Prevent creating new branches by git push`
> - Click the checkbox
> - Click `Update`
>
> I personally think this should be the default for all projects but
> I don't know if there is a way to easily make that happen when a project
> gets created.
>
> Hope this helps someone!

This is amazing. Please tell me there's an API call to set this for
all my projects? Because I just want this for every package I
maintain, excluding forks (obviously)!



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

Re: Something is broken in low-level components, processes segfault

[Petr Pisar]

On 2018-11-21, Igor Gnatenko  wrote:
> https://apps.fedoraproject.org/koschei/build/5700914
>
>   process didn't exit successfully: `/usr/bin/rustc --crate-name
> glib_sys src/lib.rs --color never --crate-type lib
> --emit=dep-info,link -C opt-level=3 -C metadata=20d7ee6da134c60a -C
> extra-filename=-20d7ee6da134c60a --out-dir
> /builddir/build/BUILD/glib-sys-0.6.0/target/release/deps -L
> dependency=/builddir/build/BUILD/glib-sys-0.6.0/target/release/deps
> --extern 
> bitflags=/builddir/build/BUILD/glib-sys-0.6.0/target/release/deps/libbitflags-056f832aae1b729d.rlib
> --extern 
> libc=/builddir/build/BUILD/glib-sys-0.6.0/target/release/deps/liblibc-626066f325dbf1d3.rlib
> -Copt-level=3 -Cdebuginfo=2 -Clink-arg=-Wl,-z,relro,-z,now -l
> glib-2.0` (signal: 11, SIGSEGV: invalid memory reference)
>
> There were just libxcrypt/glibc/llvm/annobin updates, so it's hard to
> guess what exactly is broken.
>
It's triggered by upgrading glibc from 2.28.9000-17.fc30 to
2.28.9000-18.fc30.

-- Petr
___
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: prevent accidentally creating branches in dist-git

[Ken Dreyer]

Wow, thanks Dusty!

This should definitely be the default for Pagure dist-git.
On Tue, Nov 20, 2018 at 7:25 AM Dusty Mabe  wrote:
>
>
> I've certainly made the mistake of accidentally creating branches
> in dist-git and now being stuck with them because we can't delete
> them. Now that src.fedoraproject.org (dist-git) is backed by a newer
> version of pagure you can prevent creating new branches by `git push`.
>
> For your project in the web UI:
>
> - Go to the `Settings` menu
> - Select `Hooks` from the left hand side
> - Expand `Prevent creating new branches by git push`
> - Click the checkbox
> - Click `Update`
>
> I personally think this should be the default for all projects but
> I don't know if there is a way to easily make that happen when a project
> gets created.
>
> Hope this helps someone!
> Dusty
> ___
> 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

[Bug 1651942] Upgrade perl-File-Slurp to 9999.25

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #1 from Fedora Update System  ---
perl-File-Slurp-.25-1.fc29 has been submitted as an update to Fedora 29.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-94d7ac7a1d

-- 
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: Installed (but unpackaged) file(s) found on s390x and armv7hl: .s390x.debug.#dwz#

[Josef Ridky]

Hi folks,

I have found this error even during netpbm build [1].
Do we have any progress with it? I couldn't found anything related to dwz crash 
in build log. (Maybe I just overlooked it).

[1] https://kojipkgs.fedoraproject.org//work/tasks/6251/31036251/build.log

Regards 

Josef Ridky
Associate Software Engineer
Core Services Team
Red Hat Czech, s.r.o.

- Original Message -
| From: "Vít Ondruch" 
| To: devel@lists.fedoraproject.org
| Sent: Friday, July 27, 2018 10:07:08 AM
| Subject: Re: Installed (but unpackaged) file(s) found on s390x and armv7hl: 
.s390x.debug.#dwz#
| 
| 
| 
| 
| 
| Dne 27.7.2018 v 00:31 Mark Wielaard napsal(a):
| 
| 
| 
| On Wed, 2018-07-25 at 21:04 +0300, Pavel Alexeev wrote:
| 
| 
| 
| On 07/23/2018 12:36 PM, Dan Horák wrote:
| 
| 
| 
| On Mon, 23 Jul 2018 10:43:43 +0200
| Mark Wielaard  wrote:
| 
| 
| 
| On Sun, Jul 22, 2018 at 10:52:38PM +0300, Pavel Alexeev wrote:
| 
| 
| 
| Hello.
| 
| I try build new version of perdition package.
| 
| It build fine
| ( https://koji.fedoraproject.org/koji/taskinfo?taskID=28526416 )
| on
| all architectures except armv7hl and s390x. On that I got
| ( https://kojipkgs.fedoraproject.org//work/tasks/6424/28526424/b uild.log):
| 
| error: Installed (but unpackaged) file(s) found:
| /usr/lib/debug/usr/sbin/perdition.imap4-2.2-
| 1.fc29.s390x.debug.#dwz#.sWwnyG
| /usr/lib/debug/usr/sbin/perdition.imap4s-2.2-
| 1.fc29.s390x.debug.#dwz#.eE9BPY
| /usr/lib/debug/usr/sbin/perdition.imaps-2.2-
| 1.fc29.s390x.debug.#dwz#.WRTN7g
| /usr/lib/debug/usr/sbin/perdition.managesieve-2.2-
| 1.fc29.s390x.debug.#dwz#.GWCloz
| /usr/lib/debug/usr/sbin/perdition.pop3-2.2-
| 1.fc29.s390x.debug.#dwz#.
| 2Sm2W5 /usr/lib/debug/usr/sbin/perdition.pop3s-2.2-
| 1.fc29.s390x.debug.#dwz#.kvArfo
| 
| Could someone please help me solve that problem?
| It looks like dwz crashed and left those temporary files behind.
| Strangely there are no indication in the log files that dwz
| crashed.
| But there is an rm -f statement in the log right before the
| find-debuginfo.sh/dwz invocation that does seem to touch those
| files.
| I cannot explain where that comes from. It must be somewhere at
| the
| end of the %install phase, but there is nothing in the .spec file
| that hints at where it is coming from.
| 
| It might be necessary to run on a real s390x or armv7vhl machine
| to track down what is going on.
| so I can reproduce that locally on my rawhide s390x guest
| 
| Mark, I'll give you the machine info thru other channels.
| Sorry, is there any progress?
| Sorry, I did sent an update, but it apparently didn't go to the list
| for some reason. See attached.
| 
| Unfortunately some other things came up, so I couldn't immediately try
| to look deeper. And I managed to loose the files that helped me
| replicate the issue.
| 
| Now trying to rebuild the package I suddenly get these errors:
| 
| ssl.c: In function '__perdition_verify_callback':
| ssl.c:243:35: error: dereferencing pointer to incomplete type
| 'X509_STORE_CTX' {aka 'struct x509_store_ctx_st'}
|   if (__perdition_verify_result(ctx->error, cert)
|    ^~
| ssl.c: In function '__perdition_ssl_check_common_name':
| ssl.c:714:42: error: dereferencing pointer to incomplete type
| 'X509_NAME_ENTRY' {aka 'struct X509_name_entry_st'}
|    if (!__perdition_ssl_compare_key(key, e->value->data,
|   ^~
| make[3]: *** [Makefile:643: ssl.o] Error 1
| 
| Please note that OpenSSL 1.1.1 landed in Rawhide a few days ago. That could
| explain this errors ...
| 
| V.
| 
| 
| 
| 
| 
| 
| 
| Should I fill bug for that? Against what component?
| It really looks like a bug in dwz, so please file a bug against that.
| I think a workaround for now would be to add %undefine
| _find_debuginfo_dwz_opts to your spec. But I haven't been able to test
| because of the above error.
| 
| Cheers,
| 
| Mark
| 
| 
| ___
| 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/message/KORDFM5B3FXCY3RJ2MYBH5MT4YBNPJBJ/
| 
| 
| ___
| 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/message/MHONT5U3VWPVA324CKYBNE5TCB2RVZ43/
| 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora 

Re: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

[Zdenek Kabelac]

Dne 21. 11. 18 v 14:36 Kamil Paral napsal(a):
On Fri, Nov 16, 2018 at 11:13 PM Jonathan Dieter > wrote:


For reference, this is in reply to Paul's email about lifecycle
objectives, specifically focusing on problem statement #1[1].


Have rpm use zchunk as its compression format, removing the need for
deltarpms, and thus reducing compose time.  This will require changes
to both the rpm format and new features in the zchunk format.



Hey Jonathan,

thanks for working on this. The proposed changes sound good to me. I'm a bit 
worried that zchunk is not yet a proven format, so it might be a good idea to 
use it for metadata first, see whether it works as expected, and then push it 
for RPM files. But that's for more technical people to judge.


I have some concrete questions, though:
1. I have noticed that especially with large RPMs (firefox, chrome, atom, game 
data like 0ad-data, etc), my PCs are mostly bottlenecked by CPU when 
installing them. And that's with a modern 3.5+GHz CPU. That's because RPM 
decompression runs in a single thread only, and xz is just unbelievably slow. 
I wonder, would zchunk used as an RPM compression algorithm improve this 
substantially? Can it decompress in multiple threads and/or does it have much 
faster decompression speeds (and how much)? I don't care about RPM size 
increase, but I'd really like to have them installed fast. (That's of course 
just my personal preference, but this also affects the speed of mock builds 
and such, so I think it's relevant.)


Well I'm ATM way more concerned about  absurd size of rpm REPO metadata size.

Often my upgrade first download   200MB of metadata to update 20MB of actual 
RPMs.

Please anyone - fix this first before anyone starts to parallelise 
decompression - this is minimal problem compared with the amount of processed 
metadata


Next topic is - to replace/rewrite ONLY new files - files that has NOT changed 
might not be written at all (write of files takes way more time then its 
decompression)  - in fact such file might not be even decompressed (depends on 
compression layout).


Thanks

Zdenek
___
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: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

[Kamil Paral]

On Fri, Nov 16, 2018 at 11:13 PM Jonathan Dieter  wrote:

> For reference, this is in reply to Paul's email about lifecycle
> objectives, specifically focusing on problem statement #1[1].
>
> 
> Have rpm use zchunk as its compression format, removing the need for
> deltarpms, and thus reducing compose time.  This will require changes
> to both the rpm format and new features in the zchunk format.
> 
>

Hey Jonathan,

thanks for working on this. The proposed changes sound good to me. I'm a
bit worried that zchunk is not yet a proven format, so it might be a good
idea to use it for metadata first, see whether it works as expected, and
then push it for RPM files. But that's for more technical people to judge.

I have some concrete questions, though:
1. I have noticed that especially with large RPMs (firefox, chrome, atom,
game data like 0ad-data, etc), my PCs are mostly bottlenecked by CPU when
installing them. And that's with a modern 3.5+GHz CPU. That's because RPM
decompression runs in a single thread only, and xz is just unbelievably
slow. I wonder, would zchunk used as an RPM compression algorithm improve
this substantially? Can it decompress in multiple threads and/or does it
have much faster decompression speeds (and how much)? I don't care about
RPM size increase, but I'd really like to have them installed fast. (That's
of course just my personal preference, but this also affects the speed of
mock builds and such, so I think it's relevant.)
2. In our past QA efforts in Fedora, we had use cases for retrieving rpm
header data without retrieving the actual content (the payload). That was
for cases when we needed to check e.g. dependency issues, but the rpms were
not placed in a repository yet (i.e. no easy access to their metadata) and
it was slow and wasteful to download the whole rpm just to get the header.
Will the new zchunk compression still make it possible to retrieve just the
header without accessing all the payload data? (It would be great to make
this accessible from Python and not just C, but that's a plea I should
direct to rpm maintainers, I guess).

Thanks,
Kamil
___
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

Something is broken in low-level components, processes segfault

[Igor Gnatenko]

https://apps.fedoraproject.org/koschei/build/5700914

  process didn't exit successfully: `/usr/bin/rustc --crate-name
glib_sys src/lib.rs --color never --crate-type lib
--emit=dep-info,link -C opt-level=3 -C metadata=20d7ee6da134c60a -C
extra-filename=-20d7ee6da134c60a --out-dir
/builddir/build/BUILD/glib-sys-0.6.0/target/release/deps -L
dependency=/builddir/build/BUILD/glib-sys-0.6.0/target/release/deps
--extern 
bitflags=/builddir/build/BUILD/glib-sys-0.6.0/target/release/deps/libbitflags-056f832aae1b729d.rlib
--extern 
libc=/builddir/build/BUILD/glib-sys-0.6.0/target/release/deps/liblibc-626066f325dbf1d3.rlib
-Copt-level=3 -Cdebuginfo=2 -Clink-arg=-Wl,-z,relro,-z,now -l
glib-2.0` (signal: 11, SIGSEGV: invalid memory reference)

There were just libxcrypt/glibc/llvm/annobin updates, so it's hard to
guess what exactly is broken.

Help is very much appreciated.
___
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: mass-removal of LANG=anything-not-C.UTF-8 in packages

[Zbigniew Jędrzejewski-Szmek]

On Wed, Nov 21, 2018 at 12:13:41PM +, Peter Robinson wrote:
> On Wed, Nov 21, 2018 at 12:09 PM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On Tue, Nov 06, 2018 at 09:21:09AM -0600, Dennis Gilmore wrote:
> > > the build group in koji is defined as
> > > 
> > > build
> > > build
> > > None
> > > false
> > > true
> > > 
> > >   bash
> >
> > Hmm, where is this defined?
> 
> In koji:
> koji list-groups f30

Thanks. https://pagure.io/releng/issue/7926.

> > >  and in f30 comps the buildsys-build group is
> > > 
> > > buildsys-build
> >
> > https://pagure.io/fedora-comps/pull-request/346

Zbyszek
___
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: mass-removal of LANG=anything-not-C.UTF-8 in packages

[Peter Robinson]

On Wed, Nov 21, 2018 at 12:09 PM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Tue, Nov 06, 2018 at 09:21:09AM -0600, Dennis Gilmore wrote:
> > the build group in koji is defined as
> > 
> > build
> > build
> > None
> > false
> > true
> > 
> >   bash
>
> Hmm, where is this defined?

In koji:
koji list-groups f30

> >  and in f30 comps the buildsys-build group is
> > 
> > buildsys-build
>
> https://pagure.io/fedora-comps/pull-request/346
>
> Zbyszek
> ___
> 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: mass-removal of LANG=anything-not-C.UTF-8 in packages

[Zbigniew Jędrzejewski-Szmek]

On Tue, Nov 06, 2018 at 09:21:09AM -0600, Dennis Gilmore wrote:
> the build group in koji is defined as 
> 
> build
> build
> None
> false
> true
> 
>   bash

Hmm, where is this defined?

>  and in f30 comps the buildsys-build group is 
> 
> buildsys-build

https://pagure.io/fedora-comps/pull-request/346

Zbyszek
___
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 1651943] Upgrade perl-Module-CoreList to 5.20181120

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-Module-CoreList-5.20181120-1.fc29 has been submitted as an update to
Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-3cfb210f6d

-- 
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 1651943] Upgrade perl-Module-CoreList to 5.20181120

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-Module-CoreList-5.20181120-1.fc28 has been submitted as an update to
Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-fbc92bbd6a

-- 
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 1651941] Upgrade perl-CPAN-Perl-Releases to 3.82

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-CPAN-Perl-Releases-3.82-1.fc27 has been submitted as an update to Fedora
27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-c47509e11d

-- 
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 1651941] Upgrade perl-CPAN-Perl-Releases to 3.82

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-CPAN-Perl-Releases-3.82-1.fc28 has been submitted as an update to Fedora
28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-0184dea376

-- 
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 1651941] Upgrade perl-CPAN-Perl-Releases to 3.82

[bugzilla]

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



--- Comment #1 from Fedora Update System  ---
perl-CPAN-Perl-Releases-3.82-1.fc29 has been submitted as an update to Fedora
29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-f87a5b1816

-- 
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 1651943] Upgrade perl-Module-CoreList to 5.20181120

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Module-CoreList-5.2018
   ||1120-1.fc30



--- Comment #1 from Petr Pisar  ---
An enhancement release suitable for Fedora ≥ 28.

-- 
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 Lifecycles: imagine longer-term possibilities

[Daniel P . Berrangé]

On Tue, Nov 20, 2018 at 01:36:06PM -0500, Neal Gompa wrote:
> On Tue, Nov 20, 2018 at 12:49 PM Daniel P. Berrangé  
> wrote:
> >
> > On Tue, Nov 20, 2018 at 12:15:17PM -0500, Neal Gompa wrote:
> > >
> > > The problem with merged source trees (aka source-git) is that it
> > > implies forking projects. It's an easy trap to start having vendor
> > > trees and maintain your own functionality independent from upstream.
> > > Fundamentally, I don't want having patches to be too easy, because
> > > then people _will_ do that. Fedora should strive to remain close to
> > > upstream projects and interact with them to make things better[1].
> > >
> > > And the thing is, it's not like I'm unfamiliar with merged source
> > > models. I've worked in distributions that operated that way, and the
> > > consequence is almost always that things are patched and changed
> > > without ever interacting with upstream. Of course, that's their choice
> > > to do so, but most distributions do not have "upstream-first" as a
> > > specific goal.
> >
> > IMHO this is an overly negative view. It is making a presumption
> > that package maintainers are in general bad at what they do and
> > must be made to jump through hoops to "force" them to do the
> > right thing, no matter what the cost to good maintainers.
> >
> 
> This is a fairly realistic view, because I assume packagers are
> inherently lazy when it comes to maintenance. That is, they'll take
> the easiest path possible. And that's perfectly rational.

That's an argument for merged source trees, as it makes maint
easier allowing maintainers to get more work done in less time.

> You're confusing this with trust. And yes, there's some trust to give
> here, but keeping a (tiny) amount of friction for small patch sets
> that increases as your patch load goes up just further encourages not
> maintaining heavy patch loads.

Well we just fundamentally disagree - heavy patch loads are not an
inherantly bad thing that needs discouraging. They're only bad if
they are full of non-upstreamed stuff. If they're pulling bug fixes
into Fedora to improve our quality they are a very good thing.

> > IOW, when patches are a burden, the maintainers are less likely
> > to fix bugs present in Fedora, even if the fix is available
> > upstream. This is counter to what our users want/expect.
> >
> 
> You're assuming that packages have stupid high patch loads like
> libvirt and qemu do. Most don't. And really, the fact you guys just
> backport a bunch instead of just bumping to new versions is something
> I've never really understood.

libvirt / qemu really don't have a stupid high patch load in Fedora
because Fedora's 6 month cycle means they're never very far behind
upstream. Most of the patches to QEMU tend to be CVE backports.

Rebasing to new versions inside the stable releases is not a
straightforward thing. There is always a risk of regression
when doing that and users get very upset of a previously working
guest OS stops booting due to rebasing in middle of a stable
release.  We have rebased in the past but not any more because
not rebasing leads to a more stable offering on balance.

> > > I have not yet seen a practical example of merged source trees
> > > improving the quality of package maintenance.
> >
> > I'll have to disagree on this. I've found merged source trees to make
> > it significantly quicker and more reliable for me to get fixes from
> > upstream pulled back into Fedora packages.
> >
> 
> Is that because upstream is too slow to release fixes, or is that
> because you don't like bumping to new versions?

Upstream QEMU releases once every 4 months and libvirt monthly. Even
if we did change our minds & decide to rebase, it is still too long
to wait for pulling in security fixes and other critical functional
fixes.

> Merged source trees make it much easier to not update the software.
> But split source trees (like our current model) encourage fixes to be
> pushed upstream and bend workflows towards updating to newer versions
> because that's easier.

I will always prefer to rebase to newer versions if I think it is
viable without too high a risk of regressions. Even if rebasing
frequently there's still a need to maintain patches and anything
that makes that easier is a win. Use of merged source trees for
maint doesn't have any bearing on the willingness to take rebases
or leave patches downstream-only.


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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: 

[Bug 1651941] Upgrade perl-CPAN-Perl-Releases to 3.82

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-CPAN-Perl-Releases-3.8
   ||2-1.fc30



-- 
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: [HEADS UP] Meson 0.48.0

[Milan Crha]

On Tue, 2018-09-25 at 08:43 +0200, Igor Gnatenko wrote:
> new meson release is out (release notes) which removes tools which
> are deprecated for quite long time:
> * mesonconf
> * mesonintrospect
> * mesontest
> * wraptool

Hi,
having installed meson-0.48.1-1.fc29.noarch and trying to build
geocode-glib 3.26.0 (the latest upstream release 
https://download.gnome.org/sources/geocode-glib/ as of now), it fails
to build due to missing mesontest:

  =
  Building module geocode-glib in /home/user/fp/.flatpak-
  builder/build/geocode-glib-2
  =
  ERROR: Command 'mesontest' not found

> F28 and EPEL7 won't get update because of this incompatibility,
> but if you need it for building updates -- let me know and I will
> consider pushing it even there.

From the above I believe you should not add this to the stable releases
"if anyone needs it", unless you do some proof that it won't break more
than the geocode-glib (and/or fix the breakage at the same time).

I mean this just as a notice/confirmation that there are packages which
can be broken with this change, as you pointed out.
Bye,
Milan
___
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 1651944] New: Upgrade perl-Net-Whois-Raw to 2.99021

[bugzilla]

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

Bug ID: 1651944
   Summary: Upgrade perl-Net-Whois-Raw to 2.99021
   Product: Fedora
   Version: rawhide
 Component: perl-Net-Whois-Raw
  Assignee: dd...@cpan.org
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: dd...@cpan.org, perl-devel@lists.fedoraproject.org



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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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 1651943] New: Upgrade perl-Module-CoreList to 5.20181120

[bugzilla]

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

Bug ID: 1651943
   Summary: Upgrade perl-Module-CoreList to 5.20181120
   Product: Fedora
   Version: rawhide
 Component: perl-Module-CoreList
  Assignee: ppi...@redhat.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: jose.p.oliveira@gmail.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com,
st...@silug.org, tcall...@redhat.com



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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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 1651942] New: Upgrade perl-File-Slurp to 9999.25

[bugzilla]

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

Bug ID: 1651942
   Summary: Upgrade perl-File-Slurp to .25
   Product: Fedora
   Version: rawhide
 Component: perl-File-Slurp
  Assignee: rc040...@freenet.de
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: lxt...@gmail.com, p...@city-fan.org,
perl-devel@lists.fedoraproject.org,
rc040...@freenet.de



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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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 1651941] New: Upgrade perl-CPAN-Perl-Releases to 3.82

[bugzilla]

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

Bug ID: 1651941
   Summary: Upgrade perl-CPAN-Perl-Releases to 3.82
   Product: Fedora
   Version: rawhide
 Component: perl-CPAN-Perl-Releases
  Assignee: jples...@redhat.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org



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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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

Fedora rawhide compose report: 20181120.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20181119.n.0
NEW: Fedora-Rawhide-20181120.n.0

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  9
Dropped packages:1
Upgraded packages:   108
Downgraded packages: 0

Size of added packages:  631.47 MiB
Size of dropped packages:1.55 MiB
Size of upgraded packages:   6.08 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: golang-github-fogleman-gg-1.1.0-1.20181120git0e0ff3a.fc30
Summary: Go Graphics - 2D rendering in Go with a simple API
RPMs:golang-github-fogleman-gg-devel
Size:24.20 KiB

Package: graphlcd-base-1.0.2-3.fc30
Summary: GraphLCD drivers and tools
RPMs:glcddrivers glcdgraphics glcdskin graphlcd-common graphlcd-devel 
graphlcd-tools
Size:1.86 MiB

Package: hpx-1.2.0-3.fc30
Summary: General Purpose C++ Runtime System
RPMs:hpx hpx-devel hpx-examples hpx-mpich hpx-mpich-devel 
hpx-mpich-examples hpx-openmpi hpx-openmpi-devel hpx-openmpi-examples
Size:219.68 MiB

Package: imwheel-1.0.0-0.1.pre12.fc30
Summary: Mouse Event to Key Event Mapper Daemon
RPMs:imwheel
Size:415.38 KiB

Package: mailman3-3.2.0-1.fc30
Summary: The GNU mailing list manager
RPMs:mailman3
Size:1.36 MiB

Package: mariadb-3:10.4.0-1.alpha.module_2503+dfd2c8c4
Summary: A very fast and robust SQL database server
RPMs:mariadb mariadb-backup mariadb-bench mariadb-common 
mariadb-connect-engine mariadb-cracklib-password-check mariadb-devel 
mariadb-embedded mariadb-embedded-devel mariadb-errmsg mariadb-gssapi-server 
mariadb-oqgraph-engine mariadb-rocksdb-engine mariadb-server 
mariadb-server-galera mariadb-server-utils mariadb-sphinx-engine mariadb-test 
mariadb-tokudb-engine
Size:399.60 MiB

Package: python-efel-3.0.22-1.fc30
Summary: Electrophys Feature Extraction Library
RPMs:python3-efel
Size:964.81 KiB

Package: python-pyphi-1.1.0-2.fc30
Summary: A library for computing integrated information
RPMs:python-pyphi-doc python3-pyphi
Size:5.42 MiB

Package: vdr-graphlcd-1.0.1-3.fc30
Summary: VDR plugin: Output to graphic LCD
RPMs:vdr-graphlcd
Size:2.18 MiB


= DROPPED PACKAGES =
Package: liborigin2-2.0.0-19.fc29
Summary: Library for reading OriginLab OPJ project files
RPMs:liborigin2 liborigin2-devel liborigin2-doc
Size:1.55 MiB


= UPGRADED PACKAGES =
Package:  GraphicsMagick-1.3.31-1.fc30
Old package:  GraphicsMagick-1.3.30-3.fc29
Summary:  An ImageMagick fork, offering faster image generation and better 
quality
RPMs: GraphicsMagick GraphicsMagick-c++ GraphicsMagick-c++-devel 
GraphicsMagick-devel GraphicsMagick-doc GraphicsMagick-perl
Size: 11.79 MiB
Size change:  -587.62 KiB
Changelog:
  * Tue Nov 20 2018 Rex Dieter  - 1.3.31-1
  - GraphicsMasgick-1.3.31


Package:  Lmod-7.8.9-1.fc30
Old package:  Lmod-7.8.6-1.fc30
Summary:  Environmental Modules System in Lua
RPMs: Lmod
Size: 1.27 MiB
Size change:  964 B
Changelog:
  * Tue Nov 20 2018 Orion Poplawski  - 7.8.9-1
  - Update to 7.8.9


Package:  adwaita-icon-theme-3.31.1-1.fc30
Old package:  adwaita-icon-theme-3.30.0-1.fc30
Summary:  Adwaita icon theme
RPMs: adwaita-cursor-theme adwaita-icon-theme adwaita-icon-theme-devel
Size: 11.96 MiB
Size change:  -111.13 KiB
Changelog:
  * Tue Nov 20 2018 Kalev Lember  - 3.31.1-1
  - Update to 3.31.1


Package:  ant-1.10.5-3.fc30
Old package:  ant-1.10.5-2.fc30
Summary:  Java build tool
RPMs: ant ant-antlr ant-apache-bcel ant-apache-bsf ant-apache-log4j 
ant-apache-oro ant-apache-regexp ant-apache-resolver ant-apache-xalan2 
ant-commons-logging ant-commons-net ant-javadoc ant-javamail ant-jdepend 
ant-jmf ant-jsch ant-junit ant-junit5 ant-lib ant-manual ant-swing ant-testutil 
ant-xz
Size: 5.18 MiB
Size change:  5.06 KiB
Changelog:
  * Mon Nov 19 2018 Zbigniew J??drzejewski-Szmek  - 
0:1.10.5-3
  - Use C.UTF-8 locale
See 
https://fedoraproject.org/wiki/Changes/Remove_glibc-langpacks-all_from_buildroot


Package:  aspectjweaver-1.8.9-7.fc30
Old package:  aspectjweaver-1.8.9-6.fc29
Summary:  Java byte-code weaving library
RPMs: aspectjweaver aspectjweaver-javadoc
Size: 2.27 MiB
Size change:  104 B
Changelog:
  * Mon Nov 19 2018 Zbigniew J??drzejewski-Szmek  - 1.8.9-7
  - Add BR:glibc-langpack-en
See 
https://fedoraproject.org/wiki/Changes/Remove_glibc-langpacks-all_from_buildroot


Package:  autoarchive-1.3.0-7.fc30
Old package:  autoarchive-1.3.0-6.fc29
Summary:  A simple backup tool that uses tar
RPMs: autoarchive
Size: 172.71 KiB
Size change:  -92 B
Changelog:
  * Mon Nov 19 2018 Zbigniew J??drzejewski-Szmek  - 1.3.0-7
  - Drop explicit locale setting
See 
https://fedoraproject.org/wiki/Changes/Remove_glibc-langpacks-all_from_buildroot


Package:  

Fedora Rawhide-20181120.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 10/142 (x86_64), 2/24 (i386), 1/2 (arm)

New failures (same test did not fail in Rawhide-20181119.n.0):

ID: 310612  Test: x86_64 Server-dvd-iso base_update_cli
URL: https://openqa.fedoraproject.org/tests/310612
ID: 310646  Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/310646
ID: 310731  Test: x86_64 universal install_repository_http_variation
URL: https://openqa.fedoraproject.org/tests/310731
ID: 310757  Test: i386 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/310757

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

ID: 310608  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/310608
ID: 310623  Test: x86_64 Server-dvd-iso realmd_join_sssd
URL: https://openqa.fedoraproject.org/tests/310623
ID: 310649  Test: x86_64 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/310649
ID: 310650  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/310650
ID: 310653  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/310653
ID: 310669  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/310669
ID: 310690  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/310690
ID: 310691  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/310691
ID: 310742  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/310742

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

New soft failures (same test did not soft fail in Rawhide-20181119.n.0):

ID: 310657  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/310657
ID: 310769  Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/310769

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

ID: 310631  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/310631
ID: 310632  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/310632
ID: 310704  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/310704
ID: 310707  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/310707
ID: 310721  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/310721
ID: 310729  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/310729
ID: 310770  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/310770

Passed openQA tests: 126/142 (x86_64), 18/24 (i386)

New passes (same test did not pass in Rawhide-20181119.n.0):

ID: 310622  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/310622
ID: 310626  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/310626
ID: 310638  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/310638
ID: 310652  Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/310652
ID: 310656  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/310656
ID: 310674  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/310674

Skipped openQA tests: 1 of 168

Installed system changes in test x86_64 Server-boot-iso install_default: 
System load changed from 1.12 to 1.30
Previous test data: https://openqa.fedoraproject.org/tests/310292#downloads
Current test data: https://openqa.fedoraproject.org/tests/310604#downloads

Installed system changes in test x86_64 Server-dvd-iso install_default_upload: 
System load changed from 1.56 to 1.17
Used mem changed from 194 MiB to 165 MiB
Previous test data: https://openqa.fedoraproject.org/tests/310294#downloads
Current test data: https://openqa.fedoraproject.org/tests/310606#downloads

Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: 
System load changed from 1.28 to 1.44
Used mem changed from 197 MiB to 166 MiB
Previous test data: https://openqa.fedoraproject.org/tests/310295#downloads
Current test data: https://openqa.fedoraproject.org/tests/310607#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default@uefi: 
1 packages(s) removed since previous compose: libknet1
System load changed from 2.26 to