Re: Debates/back and forths
John you're comparing apples and oranges. One is active the other is passive. One uses your space allocation the other doesn't. On Sat, Aug 31, 2019, 19:07 John Harris wrote: > On Friday, August 30, 2019 5:40:22 AM MST Gerald B. Cox wrote: > > You just explained exactly why it was different ;-) > > I'm sorry if you believe that to be the case, but it is not. I explained > that > you can mute on both platforms, if you choose to do so. > > -- > John M. Harris, Jr. > Splentity > https://splentity.com/ > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
On Sun, Sep 1, 2019 at 3:51 AM Florian Weimer wrote: > > * Neal Gompa: > > > Well, technically, the correct thing to do would be for Mock to > > support downloading bootstrap images to speed up bootstrap. These > > images could be regularly produced by Fedora infrastructure and made > > available on the mirror network for all targets we support as a > > project. They'd be useful for COPR too, as then it can permanently > > switch to bootstrap mode. > > I don't think this could work because there too many different > buildroots nowadays, and building and storing the bootstrap images would > take too much resources. > Bootstrap images are thankfully quite simple, as they just need to be enough to run rpm+dnf. That makes them relatively consistent. > And if build images are the future, perhaps podman integration is the > answer. Although the image distribution protocol is probably the worst > part of Docker. > Anything involving OCI is probably not the answer here, since that whole system depends on the brain-damaged OCI specification. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
* Neal Gompa: > Well, technically, the correct thing to do would be for Mock to > support downloading bootstrap images to speed up bootstrap. These > images could be regularly produced by Fedora infrastructure and made > available on the mirror network for all targets we support as a > project. They'd be useful for COPR too, as then it can permanently > switch to bootstrap mode. I don't think this could work because there too many different buildroots nowadays, and building and storing the bootstrap images would take too much resources. And if build images are the future, perhaps podman integration is the answer. Although the image distribution protocol is probably the worst part of Docker. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
skychart package updates broken after module retirement
Recently, I requested to retire Skychart module and this has been done in F31 and F32: https://pagure.io/releng/issue/8640 Now I'm trying to push an update to Skychart classic RPMs, Koji shows it as tagged both in F30-updates-testing and F31-updates-testing, but there's no sign of them in the repositories: https://koji.fedoraproject.org/koji/buildinfo?buildID=1366604 https://koji.fedoraproject.org/koji/buildinfo?buildID=1366605 # dnf repository-packages updates-testing info skychart Ultima verifica della scadenza dei metadati: 0:07:19 fa il dom 1 set 2019, 11:28:40. Errore: Nessun pacchetto corrispondente Could the module retirement and the missing update be related? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora rawhide compose report: 20190901.n.0 changes
OLD: Fedora-Rawhide-20190831.n.0 NEW: Fedora-Rawhide-20190901.n.0 = SUMMARY = Added images:8 Dropped images: 0 Added packages: 1 Dropped packages:4 Upgraded packages: 61 Downgraded packages: 0 Size of added packages: 8.04 MiB Size of dropped packages:10.97 MiB Size of upgraded packages: 2.46 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -6.68 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Container_Minimal_Base docker aarch64 Path: Container/aarch64/images/Fedora-Container-Minimal-Base-Rawhide-20190901.n.0.aarch64.tar.xz Image: Container_Base docker ppc64le Path: Container/ppc64le/images/Fedora-Container-Base-Rawhide-20190901.n.0.ppc64le.tar.xz Image: Container_Minimal_Base docker x86_64 Path: Container/x86_64/images/Fedora-Container-Minimal-Base-Rawhide-20190901.n.0.x86_64.tar.xz Image: Container_Base docker aarch64 Path: Container/aarch64/images/Fedora-Container-Base-Rawhide-20190901.n.0.aarch64.tar.xz Image: Container_Minimal_Base docker s390x Path: Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20190901.n.0.s390x.tar.xz Image: Container_Base docker x86_64 Path: Container/x86_64/images/Fedora-Container-Base-Rawhide-20190901.n.0.x86_64.tar.xz Image: Container_Minimal_Base docker ppc64le Path: Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20190901.n.0.ppc64le.tar.xz Image: Container_Base docker s390x Path: Container/s390x/images/Fedora-Container-Base-Rawhide-20190901.n.0.s390x.tar.xz = DROPPED IMAGES = = ADDED PACKAGES = Package: rpm-4.15.0-0.rc1.1.module_f32+6132+579ddc64 Summary: The RPM package management system RPMs:python2-rpm python3-rpm rpm rpm-apidocs rpm-build rpm-build-libs rpm-cron rpm-devel rpm-libs rpm-plugin-audit rpm-plugin-ima rpm-plugin-prioreset rpm-plugin-selinux rpm-plugin-syslog rpm-plugin-systemd-inhibit rpm-sign rpm-sign-libs Size:8.04 MiB = DROPPED PACKAGES = Package: curve25519-java-0.1.0-7.fc31 Summary: Implementation of Curve25519 in Java RPMs:curve25519-java curve25519-java-javadoc Size:50.78 KiB Package: goffice08-0.8.17-22.fc31 Summary: Goffice support libraries RPMs:goffice08 goffice08-devel Size:10.35 MiB Package: jeromq-0.3.6-7.fc31 Summary: Pure Java implementation of libzmq RPMs:jeromq jeromq-javadoc Size:429.55 KiB Package: xcape-1.2-5.20180106git6ded5b4.fc31 Summary: Use a modifier key as another key when pressed and released on its own RPMs:xcape Size:158.05 KiB = UPGRADED PACKAGES = Package: HepMC3-3.1.2-1.fc32 Old package: HepMC3-3.1.1-3.fc31 Summary: C++ Event Record for Monte Carlo Generators RPMs: HepMC3 HepMC3-devel HepMC3-doc HepMC3-interfaces-devel HepMC3-rootIO HepMC3-rootIO-devel HepMC3-search HepMC3-search-devel Size: 35.24 MiB Size change: -15.92 MiB Changelog: * Sat Aug 31 2019 Mattias Ellert - 3.1.2-1 - Update to version 3.1.2 - Drop patches accepted upstream or previously backported Package: ansible-review-0.13.7-6.fc32 Old package: ansible-review-0.13.7-5.fc31 Summary: Reviews Ansible playbooks, roles and inventory and suggests improvements RPMs: python3-ansible-review Size: 53.44 KiB Size change: -77 B Changelog: * Mon Aug 19 2019 Miro Hron??ok - 0.13.7-6 - Rebuilt for Python 3.8 Package: audacious-plugins-3.10.1-4.fc32 Old package: audacious-plugins-3.10.1-3.fc31 Summary: Plugins for the Audacious audio player RPMs: audacious-plugins audacious-plugins-amidi audacious-plugins-exotic audacious-plugins-jack Size: 8.79 MiB Size change: -23.45 KiB Changelog: * Sat Aug 31 2019 Hans de Goede - 3.10.1-4 - Rebuilt for libsidplayfp-2.0 (rhbz#1723876) - Make bundled(game-music-emu) provides versioned Package: buildah-1.12.0-0.1.dev.git1a1a728.fc32 Old package: buildah-1.11.0-0.38.dev.git57db70c.fc32 Summary: A command line tool used for creating OCI Images RPMs: buildah Size: 36.76 MiB Size change: -17 B Changelog: * Sat Aug 31 2019 Lokesh Mandvekar (Bot) - 1.12.0-0.1.dev.git1a1a728 - bump to 1.12.0 - autobuilt 1a1a728 Package: calibre-3.47.0-1.fc32 Old package: calibre-3.46.0-2.git20190819.fc32 Summary: E-book converter and library manager RPMs: calibre Size: 118.86 MiB Size change: -270.11 KiB Changelog: * Sat Aug 31 2019 Kevin Fenzi - 3.47.0-1 - Update to 3.47.0 Package: clang-8.0.0-4.fc32 Old package: clang-8.0.0-3.fc31.1 Summary: A C language family front-end for LLVM RPMs: clang clang-analyzer clang-devel clang-libs clang-tools-extra git-clang-format python3-clang Size: 119.46 MiB Size change: -678.19 KiB Changelog: * Mon Aug 19 2019 Miro Hron??ok - 8.0.0-3.2 - Rebuilt for Python 3.8 * Tue Aug 20 2019 sguel...@redhat.com - 8.0.0-4 - Rebuilt for Python 3.8 Package: duplicity-0.8.04-1.fc32 Old package
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
On Sun, Sep 1, 2019 at 3:31 AM Florian Weimer wrote: > > * Kevin Fenzi: > > > On 8/29/19 11:44 PM, Miroslav Suchý wrote: > >> Dne 29. 08. 19 v 18:58 Kamil Dudka napsal(a): > >>> What is the recommended way to build Fedora 31+ RPMs on a RHEL-7 host? > >> > >> I think that no one contemplate supporting RHEL 7 regarding zstd. The real > >> thing is "how to build Fedora 31+ RPMs on a > >> RHEL-8 host"? > >> https://bugzilla.redhat.com/show_bug.cgi?id=1715799 > >> > > > > Couldn't this be a use for bootstrap mode? Or is it still not working? > > Bootstrap mode still uses the host RPM. > > mock would have to bundle its own RPM (and DNF) for better backwards > compatibility, which is probably the right thing to do in the long term > anyway. > Well, technically, the correct thing to do would be for Mock to support downloading bootstrap images to speed up bootstrap. These images could be regularly produced by Fedora infrastructure and made available on the mirror network for all targets we support as a project. They'd be useful for COPR too, as then it can permanently switch to bootstrap mode. Alternatively, Mock could be taught how to manually unpack enough packages with libarchive to get rpm + dnf working, and use that to bootstrap into a real rootfs to do stuff. This strategy is what obs-build does (though it only needs rpm since dependency solving is built into obs-build). -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
* Kevin Fenzi: > On 8/29/19 11:44 PM, Miroslav Suchý wrote: >> Dne 29. 08. 19 v 18:58 Kamil Dudka napsal(a): >>> What is the recommended way to build Fedora 31+ RPMs on a RHEL-7 host? >> >> I think that no one contemplate supporting RHEL 7 regarding zstd. The real >> thing is "how to build Fedora 31+ RPMs on a >> RHEL-8 host"? >> https://bugzilla.redhat.com/show_bug.cgi?id=1715799 >> > > Couldn't this be a use for bootstrap mode? Or is it still not working? Bootstrap mode still uses the host RPM. mock would have to bundle its own RPM (and DNF) for better backwards compatibility, which is probably the right thing to do in the long term anyway. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-31-20190901.n.0 compose check report
No missing expected images. Failed openQA tests: 14/142 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-31-20190831.n.0): ID: 439634 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/439634 ID: 439708 Test: x86_64 universal install_pxeboot@uefi URL: https://openqa.fedoraproject.org/tests/439708 Old failures (same test failed in Fedora-31-20190831.n.0): ID: 439597 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/439597 ID: 439605 Test: x86_64 Workstation-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/439605 ID: 439607 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/439607 ID: 439632 Test: x86_64 KDE-live-iso desktop_background URL: https://openqa.fedoraproject.org/tests/439632 ID: 439635 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/439635 ID: 439656 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/439656 ID: 439663 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/439663 ID: 439689 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/439689 ID: 439694 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/439694 ID: 439698 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/439698 ID: 439699 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/439699 ID: 439700 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/439700 ID: 439703 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/439703 Soft failed openQA tests: 3/142 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-31-20190831.n.0): ID: 439629 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/439629 Old soft failures (same test soft failed in Fedora-31-20190831.n.0): ID: 439693 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/439693 ID: 439695 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/439695 Passed openQA tests: 113/142 (x86_64) New passes (same test not passed in Fedora-31-20190831.n.0): ID: 439570 Test: x86_64 Server-dvd-iso install_repository_hd_variation URL: https://openqa.fedoraproject.org/tests/439570 ID: 439623 Test: x86_64 KDE-live-iso install_no_user URL: https://openqa.fedoraproject.org/tests/439623 Skipped non-gating openQA tests: 13 of 144 Installed system changes in test x86_64 KDE-live-iso install_default_upload: Used mem changed from 851 MiB to 727 MiB 1 services(s) added since previous compose: dbus-:1.7-org.freedesktop.problems@0.service loaded active running dbus-:1.7-org.freedesktop.problems@0.service 1 services(s) removed since previous compose: dbus-:1.6-org.freedesktop.problems@0.service loaded active running dbus-:1.6-org.freedesktop.problems@0.service System load changed from 0.49 to 1.50 Average CPU usage changed from 14.43809524 to 71.40952381 Previous test data: https://openqa.fedoraproject.org/tests/439318#downloads Current test data: https://openqa.fedoraproject.org/tests/439620#downloads Installed system changes in test x86_64 KDE-live-iso install_default@uefi: System load changed from 0.41 to 0.99 Previous test data: https://openqa.fedoraproject.org/tests/439320#downloads Current test data: https://openqa.fedoraproject.org/tests/439622#downloads Installed system changes in test x86_64 universal install_package_set_kde: Used mem changed from 756 MiB to 911 MiB 1 services(s) added since previous compose: pcscd.service System load changed from 0.25 to 0.38 Average CPU usage changed from 2.1333 to 20.04285714 Previous test data: https://openqa.fedoraproject.org/tests/439375#downloads Current test data: https://openqa.fedoraproject.org/tests/439677#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Workstation and disabled by default firewall
On Sun, Sep 1, 2019 at 7:16 AM wrote: > > On Sat, Aug 31, 2019 at 6:37 PM, Nico Kadel-Garcia > wrote: > > If 30 years in DevOps and system security in both large and small > > networks count for anything, this makes *complete* sense. The > > distinction between a "Workstation" deployment and a "Server" or > > "Everything" deployment should not include leaving the Workstation > > completely vulnerable to the most casual script kiddie attacks after > > they install *any* services, especially including MySQL, DNS, Samba, > > or Tomcat, Jenkins, or anything else. > > Well that's why installed network services are disabled by default in > Fedora, unless the package receives an exception from FESCo. This isn't > Debian where installing a package is expected to result in the service > being up and running. If you 'systemctl start' your service and the > firewall breaks it, that's just annoying. > > Michael There is "annoying", and there is "dangerously exposing your host" while you're first learning about the service. I'd encourage leaving the training wheels on until the service administrator can bother to learn about firewalls and take off the training wheels. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
On Sun, Sep 1, 2019 at 3:52 AM Florian Weimer wrote: > > * Neal Gompa: > > > Well, technically, the correct thing to do would be for Mock to > > support downloading bootstrap images to speed up bootstrap. These > > images could be regularly produced by Fedora infrastructure and made > > available on the mirror network for all targets we support as a > > project. They'd be useful for COPR too, as then it can permanently > > switch to bootstrap mode. > > I don't think this could work because there too many different > buildroots nowadays, and building and storing the bootstrap images would > take too much resources. The "correct thing to do" would be not to make work more difficult for long-term maintainers and people backporting software from the testing bed that Fedora provides and not break backwards compatibility for source code packages in the name of a very modest improvement in compression. Maybe don't use zstd for SRPM? > And if build images are the future, perhaps podman integration is the > answer. Although the image distribution protocol is probably the worst > part of Docker. And chroot cages was the future. As were micro virtual machines. As are "immutable images" this year. Software packaging is not going away anytime in the foreseeable future. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Workstation and disabled by default firewall
On Sat, Aug 31, 2019 at 6:37 PM, Nico Kadel-Garcia wrote: If 30 years in DevOps and system security in both large and small networks count for anything, this makes *complete* sense. The distinction between a "Workstation" deployment and a "Server" or "Everything" deployment should not include leaving the Workstation completely vulnerable to the most casual script kiddie attacks after they install *any* services, especially including MySQL, DNS, Samba, or Tomcat, Jenkins, or anything else. Well that's why installed network services are disabled by default in Fedora, unless the package receives an exception from FESCo. This isn't Debian where installing a package is expected to result in the service being up and running. If you 'systemctl start' your service and the firewall breaks it, that's just annoying. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-Rawhide-20190901.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 10 of 45 required tests failed, 6 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Unsatisfied gating requirements that could not be mapped to openQA tests: FAILED: compose.cloud.all MISSING: fedora.Workstation-boot-iso.x86_64.64bit - compose.install_default MISSING: fedora.Workstation-boot-iso.x86_64.uefi - compose.install_default Failed openQA tests: 26/152 (x86_64), 1/2 (arm) Old failures (same test failed in Fedora-Rawhide-20190831.n.0): ID: 439414 Test: x86_64 Server-boot-iso install_default **GATING** URL: https://openqa.fedoraproject.org/tests/439414 ID: 439415 Test: x86_64 Server-boot-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/439415 ID: 439432 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller **GATING** URL: https://openqa.fedoraproject.org/tests/439432 ID: 439433 Test: x86_64 Server-dvd-iso server_freeipa_replication_master URL: https://openqa.fedoraproject.org/tests/439433 ID: 439434 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/439434 ID: 439435 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart **GATING** URL: https://openqa.fedoraproject.org/tests/439435 ID: 439437 Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING** URL: https://openqa.fedoraproject.org/tests/439437 ID: 439438 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/439438 ID: 439443 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/439443 ID: 439447 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/439447 ID: 439448 Test: x86_64 Everything-boot-iso install_default **GATING** URL: https://openqa.fedoraproject.org/tests/439448 ID: 439449 Test: x86_64 Everything-boot-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/439449 ID: 439451 Test: x86_64 Workstation-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/439451 ID: 439453 Test: x86_64 Workstation-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/439453 ID: 439481 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/439481 ID: 439483 Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/439483 ID: 439485 Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/439485 ID: 439512 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/439512 ID: 439519 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/439519 ID: 439545 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/439545 ID: 439547 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/439547 ID: 439548 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/439548 ID: 439550 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/439550 ID: 439554 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/439554 ID: 439555 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/439555 ID: 439556 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/439556 ID: 439559 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/439559 Soft failed openQA tests: 1/152 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-Rawhide-20190831.n.0): ID: 439475 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/439475 Passed openQA tests: 105/152 (x86_64) Skipped gating openQA tests: 4/152 (x86_64) Old skipped gating tests (same test skipped in Fedora-Rawhide-20190831.n.0): ID: 439457 Test: x86_64 Workstation-live-iso base_update_cli **GATING** URL: https://openqa.fedoraproject.org/tests/439457 ID: 439458 Test: x86_64 Workstation-live-iso base_system_logging **GATING** URL: https://openqa.fedoraproject.org/tests/439458 ID: 439460 Test: x86_64 Workstation-live-iso desktop_terminal **GATING** URL: https://openqa.fedoraproject.org/tests/439460 ID: 439461 Test: x86_64 Workstation-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/439461 Skipped non-gating openQA tests: 17 of 154 Installed system changes in test x86_64
Fedora 31 compose report: 20190901.n.0 changes
OLD: Fedora-31-20190831.n.0 NEW: Fedora-31-20190901.n.0 = SUMMARY = Added images:1 Dropped images: 1 Added packages: 0 Dropped packages:0 Upgraded packages: 0 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 0 B Size of downgraded packages: 0 B Size change of upgraded packages: 0 B Size change of downgraded packages: 0 B = ADDED IMAGES = Image: SoaS live x86_64 Path: Spins/x86_64/iso/Fedora-SoaS-Live-x86_64-31-20190901.n.0.iso = DROPPED IMAGES = Image: Silverblue dvd-ostree aarch64 Path: Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-31-20190831.n.0.iso = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = = DOWNGRADED PACKAGES = ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Orphaned jsch-agent-proxy
I've orphaned jsch-agent-proxy, previously maintained by the Stewardship SIG. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: testing oomd, cgroupsv2, was: Better interactivity in low-memory situations
Per this suggestion [1] by hakavlad (Alexey Avramov), I did a single test with earlyoom, a user space service that's already packaged for Fedora. I have not yet tested nohang, also mentioned. I chose a configuration that has fairly consistently (>80%) resulted in a total hang for more than 30m. And the result with earlyoom is that while responsiveness in the GUI was still bad, the longest GUI freeze lasted ~8 minutes ending in oom which is certainly a lot better than a 30+ minute hang. It's entirely subjective, but my opinion is the system was legitimately lost within the 1st minute of hang, and a reasonable user can choose to give up at that point. Is this an improvement? Yes, the oom happens sooner, and maybe more testing will prove it's more predictable. Is it good enough? No. Should Fedora enable earlyoom in Fedora 32 Workstation? Maybe. Configuration: CPU i7-2820QM RAM: 7837M swap on ZRAM (lz4): 7836M (there is no other swap) BOOT_IMAGE=(hd5,gpt6)/boot/vmlinuz-5.3.0-0.rc6.git1.1.fc32.x86_64 root=UUID=72df6d5b-26d1-47ff-a9ab-33f6a0b2c4cf ro rootflags=subvol=root log_buf_len=4M systemd.debug-shell=1 printk.devkmsg=on slub_debug=FZPU Logs [2] [3] [4] all monotonic time, and screenshot [5]. The screenshot monotonic time equivalent is ~ [ 4890.404675] which coincides with GUI totally hung, and a sysrq+t issued via ssh. There's a lot going on including some i915 weirdness that I've been informed by upstream is swap related, but I don't know the significance of these kernel/gnome-shell page allocation failure complaints (they don't taint the kernel). But suffice to say there are questionable things happening well before the oom kill is issued. [1] https://pagure.io/fedora-workstation/issue/98#comment-594295 [2] Full journal https://drive.google.com/open?id=1nnZupWFnGfqu41aYs-u3UL8ir180YiL_ [3] dmesg only https://drive.google.com/open?id=1FNc7e-XuIiIAzSdBkOg98x9jgYEQQWbr [4] earlyoom messages only https://drive.google.com/open?id=1drd570PRbUiiSnCwoP26DMSgSo93SdAC [5] screenshot shows top and iotop at the time of heavy CPU, IO, memory and swap pressure https://drive.google.com/open?id=1unLv11HmHW3bYOJvlLSuZYSiv6gyw7L3 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
inotify-tools with dead upstream cannot be fixed in Fedora
Hi, Fix stack overflow in: `inotifytools_replace_filename` https://bugzilla.redhat.com/show_bug.cgi?id=1741472 Not sure how to fix this crashing bug. Upstream is dead while Fedora package maintainer requires to upstream the fix first. A Catch 22. Debian has the crasher fixed by an off-trunk simple patch, Fedora cannot? Jan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
* Nico Kadel-Garcia: > On Sun, Sep 1, 2019 at 3:52 AM Florian Weimer wrote: >> >> * Neal Gompa: >> >> > Well, technically, the correct thing to do would be for Mock to >> > support downloading bootstrap images to speed up bootstrap. These >> > images could be regularly produced by Fedora infrastructure and made >> > available on the mirror network for all targets we support as a >> > project. They'd be useful for COPR too, as then it can permanently >> > switch to bootstrap mode. >> >> I don't think this could work because there too many different >> buildroots nowadays, and building and storing the bootstrap images would >> take too much resources. > > The "correct thing to do" would be not to make work more difficult for > long-term maintainers and people backporting software from the testing > bed that Fedora provides and not break backwards compatibility for > source code packages in the name of a very modest improvement in > compression. The improvements in installation time are quite significant. But there will always be interesting new RPM features as long as the software is being maintained, and some of them will break the existing bootstrapping mechanism if they leak into the core package set. > Maybe don't use zstd for SRPM? That doesn't really help with constructing the buildroot, which is the hard problem anyway. >> And if build images are the future, perhaps podman integration is the >> answer. Although the image distribution protocol is probably the worst >> part of Docker. > > And chroot cages was the future. As were micro virtual machines. As > are "immutable images" this year. > > Software packaging is not going away anytime in the foreseeable > future. I meant this strictly for distributing the bootstrapping environment. It wouldn't really make sense for mock to grow its own container image infrastructure. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Better interactivity in low-memory situations
On Mon, Aug 12, 2019 at 5:47 PM Emery Berger wrote: > > For what it's worth, my research group attacked basically exactly this > problem some time ago. We built a modified Linux kernel that we called > Redline that was utterly resilient to fork bombs, malloc bombs, and so on. No > process could take down the system, much less unprivileged ones. I think some > of the ideas we described back then would be worth adopting / adapting today > (the code is of course hopelessly out of date: we published our paper on this > at OSDI 2008). I'm unable to find a concurring or dissenting opinions on this. What kind of peer review has it received? Was it ever raised with upstream kernel developers? What were there responses? I wonder if the question of interactivity is just not a priority upstream still, as they see various competing user space solutions for this problem and that this suggests a generic solution is either not practical to incorporate into the kernel, or maybe it isn't desired? -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Is Modularity (MBS) dead?
Hello, Being one of the biggest users of Modularity (more than 25 modules) I'm surprised that: 1) Many builds are stuck for more than half a month (https://mbs.fedoraproject.org/module-build-service/1/module-builds/5639, 13 Aug) 2) F32 branching was not handled well, basically all Rust modules can't be built due to wrong way of branching (https://pagure.io/releng/issue/8718) 3) New modules (even which contain just one component) don't start even after 30 minutes (https://mbs.fedoraproject.org/module-build-service/1/module-builds/6151) So did I miss some announcement that Modularity is RIP and nobody should use it or just nobody cares about it and I should find more reliable way to deliver Rust apps? -- -Igor Gnatenko ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1543336] please provide missing Fedora 27 Perl modules
https://bugzilla.redhat.com/show_bug.cgi?id=1543336 Denis Fateyev changed: What|Removed |Added Flags||needinfo?(cpanc...@gmail.co ||m) --- Comment #21 from Denis Fateyev --- What is the current status of this bug? -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1746993] perl-WWW-Mechanize-1.92 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1746993 Emmanuel Seyman changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-WWW-Mechanize-1.92-1.f ||c32 Resolution|--- |RAWHIDE Last Closed||2019-09-01 08:57:10 --- Comment #2 from Emmanuel Seyman --- Built for rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=1368647 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-fabd190d13 clamav-0.101.4-1.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing disktype-9-29.el8 icewm-1.6.1-4.el8 jack-audio-connection-kit-1.9.12-8.el8 nordugrid-arc-6.2.0-1.el8 tegrarcm-1.8-5.el8 Details about builds: disktype-9-29.el8 (FEDORA-EPEL-2019-cab63b93bc) Detect the content format of a disk or disk image Update Information: Introduce for epel8 icewm-1.6.1-4.el8 (FEDORA-EPEL-2019-0bd783bf03) Window manager designed for speed, usability, and consistency Update Information: Initial package jack-audio-connection-kit-1.9.12-8.el8 (FEDORA-EPEL-2019-d0925b1f23) The Jack Audio Connection Kit Update Information: Introduce for epel8 nordugrid-arc-6.2.0-1.el8 (FEDORA-EPEL-2019-44fc6eee61) Advanced Resource Connector Middleware Update Information: ARC for EPEL 8. tegrarcm-1.8-5.el8 (FEDORA-EPEL-2019-fafd3cb727) Send code to a Tegra device in recovery mode Update Information: Introduced for epel8 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 383 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d condor-8.6.11-1.el7 159 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-d2c1368294 cinnamon-3.6.7-5.el7 125 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c499781e80 python-gnupg-0.4.4-1.el7 123 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b bubblewrap-0.3.3-2.el7 59 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-12067fc897 dosbox-0.74.3-2.el7 13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-1a711333e8 nghttp2-1.31.1-2.el7 13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-e1ddf9b607 sleuthkit-4.6.7-1.el7 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-dea2d705d0 python-mitogen-0.2.8-1.el7 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-b4713b164c chromium-76.0.3809.132-1.el7 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-ca3444781e perl-SOAP-Lite-1.10-2.el7 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-954cf3770a seamonkey-2.49.5-1.el7 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-9bc2214140 nsd-4.2.2-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing R-3.6.1-2.el7 cmake3-3.14.6-2.el7 nordugrid-arc6-6.2.0-1.el7 pcsc-cyberjack-3.99.5final.SP13-1.el7 Details about builds: R-3.6.1-2.el7 (FEDORA-EPEL-2019-86e61d9c02) A language for data analysis and graphics Update Information: Update R to 3.6.1. ChangeLog: * Fri Aug 30 2019 Tom Callaway - 3.6.1-2 - conditionalize macro usage so that it only happens on Fedora 31+ and EPEL-8 * Fri Aug 16 2019 Tom Callaway - 3.6.1-1 - update to 3.6.1 * Sun Aug 11 2019 Elliott Sales de Andrade - 3.6.0-5 - Remove unused and nonfunctional macros and helper script * Wed Jul 24 2019 Fedora Release Engineering - 3.6.0-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild * Sun Jul 21 2019 Elliott Sales de Andrade - 3.6.0-3 - Add automated dependency generator to R-devel - Add standard Provides for bundled libraries * Thu Jun 13 2019 Tom Callaway - 3.6.0-2 - use devtoolset toolchain to compile on el6/el7 for C++11 support References: [ 1 ] Bug #1744723 - R-devel requires R-rpm-macros https://bugzilla.redhat.com/show_bug.cgi?id=1744723 [ 2 ] Bug #1727281 - R-3.6.1 is available https://bugzilla.redhat.com/show_bug.cgi?id=1727281 cmake3-3.14.6-2.el7 (FEDORA-EPEL-2019-fb4870874a) Cross-platform make system Update Information: - Update to cmake-3.14.6 (rhbz#1746146, rhbz#1746104) - Do not use system jsoncpp - Split off appdata file as external source file Note: Please, check issues pointed at [this comment](https://bugzilla.redhat.com/show_bug.cgi?id=1746146#c0). ChangeLog: * Sun Sep 1 2019 Antonio Trande - 3.14.6-2 - Fix rename patches * Tue Aug 27 2019 Antonio Trande - 3.14.6-1 - Update to cmake-3.14.6 (rhbz#1746146, rhbz#1746104) - Do not use system jsoncpp - Split off appdata file as external source file References: [ 1 ] Bug #1746146 - Lots of cmake -> cmake3 changes missing in cmake-data https://bugzilla.redhat.com/show_bug.cgi?id=1746146 [ 2 ] Bug #1746104 - cmake3-data packages backup files created by patch https://bugzilla.redhat.com/show_bug.cgi?id=1746104 nordugrid-arc6-6.2.0-1.el7 (FEDORA-EPEL-2019-4ba4e4e51d) Advanced Resource Connector Middleware Update Information: ARC 6.2.0. ChangeLog: * Sun Sep 1 2019 Mattias Ellert - 6.2.0-1 - Update to version 6.2.0 pcsc-cyberjack-3.99.5final.SP13-1.el7 (FEDORA-EPEL-2019-7202c9) PC/SC driver for REINER SCT cyberjack USB chip card reader
[389-devel] Re: Docker releases of 389
Hey all, RC images have been pushed: https://hub.docker.com/r/389ds/dirsrv I'll try to accomodate as much feedback as possible, aiming for 1.4.2 to be out first fully supported release. Sounds okay? > On 29 Aug 2019, at 12:55, William Brown wrote: > > Hi all, > > I've been wanting this for a long time and I think we're almost there - I'd > like us to start offering docker images of 389 Directory Server as part of > our upstream release process. > > I have discussed this with Mark already and we both think we are reasonably > happy with the idea and the state we're in. > > -- The Technical Process and Details: > > As there is significant interest within SUSE for containerised 389, as well > as open tooling as part of build.opensuse.org, the current proposed process > is: > > Source Release -> OBS:network:ldap -> OBS:389-ds-container -> docker hub > > Because this pipeline is automated between source to the container, and this > is already part of my responsibility as the SUSE package manager, it's a > small amount of effort to then mirror the container to docker hub. > > I have already established an organisation on docker hub, and will be giving > Mark access to be able to manage this as well. > > https://cloud.docker.com/u/389ds/repository/list > > Initially we'll name the image as: > > 389ds/dirsrv:1.4.rc > > Once we are happy with the process, and have received some community feedback > we'll move to: > > 389ds/dirsrv:1.4.1 > 389ds/dirsrv:1.4.2 > 389ds/dirsrv:1.4 # points to latest 1.4.X > 389ds/dirsrv:latest # points to newest version > > We would of course encourage people to use the "latest" tag. > > -- Support > > During the rc phase we would announce that the container support is "best > effort" and we'll obviously work to resolve issues, but it's not suitable for > production work loads. > > Once we are happy with this for a few releases, we'll move to the same > support levels as our normal releases - best effort community, and patch > backporting as we normally do. For official support, contact a vendor like > SUSE or Red Hat. > > -- Future / Downstreams > > The design of the container integration is such that we should be able to > easily swap the suse/fedora/rhel as the base image, so downstreams should be > able to easily adopt the dscontainer tool and have customers pivot from the > upstream image to their vendor image quite easily. > > A future container option is to supply a tools container that has a shell + > ds* tools, so that you can have a work flow such as: > > docker run -v 389ds:/data 389ds/dirsrv:latest > docker run -i -t -v 389ds:/data 389ds/tools:latest > # shell inside of the tools container > # dsconf > > -- Testing today: > > To test the image as it exists today: > > docker pull > registry.opensuse.org/home/firstyear/containers/389-ds-container:latest > > > Thoughts and feedback? > > If there are no objects, I'll push the rc to docker hub early next week (2nd > or 3rd of Sep) > > -- > Sincerely, > > William > ___ > 389-devel mailing list -- 389-devel@lists.fedoraproject.org > To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org -- Sincerely, William ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
[389-devel] 389 DS nightly 2019-09-02 - 95% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2019/09/02/report-389-ds-base-1.4.1.6-20190901git0c94f21.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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-af80b147c4 python-mitogen-0.2.8-1.el6 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-54cf4d603d seamonkey-2.49.5-1.el6 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-0ba49c0abc nsd-4.2.2-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing pcsc-cyberjack-3.99.5final.SP13-1.el6 Details about builds: pcsc-cyberjack-3.99.5final.SP13-1.el6 (FEDORA-EPEL-2019-b3e2bc80eb) PC/SC driver for REINER SCT cyberjack USB chip card reader Update Information: * Update to new upstream version SP13 (rev cyberJack@1374) * Add support for cyberJack one MF ChangeLog: * Sun Sep 1 2019 Robert Scheck - 3.99.5final.SP13-1 - Update to new upstream version SP13 (#1554806) - Drop requirements for 'initscripts' from specfile (#1592381) * Fri Jul 26 2019 Fedora Release Engineering - 3.99.5final.SP12-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild * Fri Feb 1 2019 Fedora Release Engineering - 3.99.5final.SP12-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild * Thu Jul 19 2018 Patrick C. F. Ernzer 3.99.5final.SP12-1 - new upstream version - man8/cyberjack.8 no longer present it seems * Fri Jul 13 2018 Fedora Release Engineering - 3.99.5final.SP11-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild * Mon Feb 19 2018 Jens Lody - 3.99.5final.SP11-3 - Added BuildRequires for gcc and gcc-c++. * Thu Feb 8 2018 Fedora Release Engineering - 3.99.5final.SP11-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild References: [ 1 ] Bug #1592381 - [pcsc-cyberjack] Drop requirements for 'initscripts' from specfile https://bugzilla.redhat.com/show_bug.cgi?id=1592381 [ 2 ] Bug #1554806 - pcsc-cyberjack-3.99.5final.SP13 is available https://bugzilla.redhat.com/show_bug.cgi?id=1554806 [ 3 ] Bug #1644548 - Version pcsc-cyberjack-3.99.5final.SP12 was released https://bugzilla.redhat.com/show_bug.cgi?id=1644548 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
