orphaning python-cassandra-driver
Hello. I'm going to orphan python-cassandra-driver. I have zero personal interest in this package and also comaintainers don't care. Moreover, cassandra itself is orphaned so it doesn't make sense to keep this package in Fedora. Have a nice day. Lumír ___ 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: Retiring u2f-hidraw-policy soon!
On 18. 09. 19 20:37, Andrew Lutomirski wrote: I guess that Fedora policy says that I should *not* retire it in stable branches, so I'll leave it alone there unless someone tells me otherwise. That is correct, we actually cannot remove a package from an already released fedora. You can retire it on f31 before the final freeze. -- 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
aarch64 test systems implementation
Are the aarch64 test systems running on real or emulated hardware? (Is there a way to tell?) I ask because I'm seeing bad numerical results from a test and would like to know if I can eliminate qemu as a possible cause -- not that I think that's likely. ___ 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-20190919.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 4 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: 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: 18/152 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-Rawhide-20190918.n.2): ID: 454070 Test: x86_64 Workstation-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/454070 ID: 454098 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/454098 ID: 454110 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/454110 Old failures (same test failed in Fedora-Rawhide-20190918.n.2): ID: 454051 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller **GATING** URL: https://openqa.fedoraproject.org/tests/454051 ID: 454052 Test: x86_64 Server-dvd-iso server_freeipa_replication_master URL: https://openqa.fedoraproject.org/tests/454052 ID: 454053 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/454053 ID: 454054 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart **GATING** URL: https://openqa.fedoraproject.org/tests/454054 ID: 454056 Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING** URL: https://openqa.fedoraproject.org/tests/454056 ID: 454057 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/454057 ID: 454062 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/454062 ID: 454066 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/454066 ID: 454084 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/454084 ID: 454094 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/454094 ID: 454099 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/454099 ID: 454100 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/454100 ID: 454103 Test: x86_64 Silverblue-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/454103 ID: 454166 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/454166 ID: 454167 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/454167 ID: 454175 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/454175 Soft failed openQA tests: 2/152 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Rawhide-20190918.n.2): ID: 454168 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/454168 ID: 454170 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/454170 Passed openQA tests: 120/152 (x86_64) New passes (same test not passed in Fedora-Rawhide-20190918.n.2): ID: 454088 Test: x86_64 KDE-live-iso install_no_user URL: https://openqa.fedoraproject.org/tests/454088 ID: 454138 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/454138 Skipped gating openQA tests: 4/152 (x86_64) New skipped gating tests (same test not skipped in Fedora-Rawhide-20190918.n.2): ID: 454076 Test: x86_64 Workstation-live-iso base_update_cli **GATING** URL: https://openqa.fedoraproject.org/tests/454076 ID: 454077 Test: x86_64 Workstation-live-iso base_system_logging **GATING** URL: https://openqa.fedoraproject.org/tests/454077 ID: 454079 Test: x86_64 Workstation-live-iso desktop_terminal **GATING** URL: https://openqa.fedoraproject.org/tests/454079 ID: 454080 Test: x86_64 Workstation-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/454080 Skipped non-gating openQA tests: 9 of 154 Installed system changes in test x86_64 KDE-live-iso install_default_upload: Used mem changed from 853 MiB to 734 MiB System load changed from 0.83 to 1.91 Average CPU usage changed from 38.48095238 to 4.15714286 Previous test data: https://openqa.fedoraproject.org/tests/453754#downloads Current test data: https://openqa.fedoraproject.org/tests/454085#downloads Installed system changes in test x86_64 KDE-live-iso install_default@uefi: System load changed from 0.47 to 1.46 Previous test data: https://openqa.fedoraproject.org/tests/453756#downloads Current test data: https:/
Fedora rawhide compose report: 20190919.n.0 changes
OLD: Fedora-Rawhide-20190918.n.2 NEW: Fedora-Rawhide-20190919.n.0 = SUMMARY = Added images:2 Dropped images: 0 Added packages: 2 Dropped packages:6 Upgraded packages: 68 Downgraded packages: 0 Size of added packages: 1.65 MiB Size of dropped packages:12.39 MiB Size of upgraded packages: 1.86 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 103.94 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Python_Classroom live x86_64 Path: Labs/x86_64/iso/Fedora-Python-Classroom-Live-x86_64-Rawhide-20190919.n.0.iso Image: Astronomy_KDE live x86_64 Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-Rawhide-20190919.n.0.iso = DROPPED IMAGES = = ADDED PACKAGES = Package: eralchemy-1.2.10-2.fc32 Summary: Entity Relation Diagrams generation tool RPMs:eralchemy python3-eralchemy Size:37.54 KiB Package: kokkos-3.0.0-0.1.190912gitd93e239.fc32 Summary: Kokkos C++ Performance Portability Programming RPMs:kokkos kokkos-devel Size:1.61 MiB = DROPPED PACKAGES = Package: ironjacamar-1.3.4-7.fc30 Summary: Java Connector Architecture 1.7 implementation RPMs:ironjacamar ironjacamar-javadoc Size:11.87 MiB Package: jboss-jacc-1.4-api-1.0.2-17.fc31 Summary: JBoss JACC 1.4 API RPMs:jboss-jacc-1.4-api jboss-jacc-1.4-api-javadoc Size:97.29 KiB Package: jboss-jaspi-1.0-api-1.0.1-18.fc31 Summary: JBoss Java Authentication SPI for Containers 1.0 API RPMs:jboss-jaspi-1.0-api jboss-jaspi-1.0-api-javadoc Size:111.10 KiB Package: jboss-naming-5.0.6-0.18.CR1.fc31 Summary: JBoss Naming RPMs:jboss-naming jboss-naming-javadoc Size:170.61 KiB Package: jboss-transaction-spi-7.3.0-7.fc31 Summary: JBoss Transaction SPI RPMs:jboss-transaction-spi jboss-transaction-spi-javadoc Size:110.55 KiB Package: rhq-plugin-annotations-3.0.4-17.fc31 Summary: RHQ plugin annotations RPMs:rhq-plugin-annotations rhq-plugin-annotations-javadoc Size:39.20 KiB = UPGRADED PACKAGES = Package: R-littler-0.3.8-5.fc32 Old package: R-littler-0.3.8-4.fc31 Summary: littler: R at the Command-Line via 'r' RPMs: R-littler R-littler-examples Size: 1.64 MiB Size change: -653 B Changelog: * Thu Sep 19 2019 Mattias Ellert - 0.3.8-5 - Unify specfile Package: atril-1.22.2-1.fc32 Old package: atril-1.22.1-2.fc31 Summary: Document viewer RPMs: atril atril-caja atril-devel atril-libs atril-thumbnailer Size: 9.09 MiB Size change: 121.69 KiB Changelog: * Wed Sep 18 2019 Wolfgang Ulbrich - 1.22.2-1 - update to 1.22.2 Package: awscli-1.16.241-1.fc32 Old package: awscli-1.16.235-2.fc32 Summary: Universal Command Line Environment for AWS RPMs: awscli Size: 1.32 MiB Size change: 15.14 KiB Changelog: * Thu Sep 19 2019 David Duncan - 5.2.25-5 - Python 3 support (from upstream pull request) - Use Python 3 for Fedora 31+ and EPEL 8+ Package: caja-1.22.2-1.fc32 Old package: caja-1.22.1-4.fc32 Summary: File manager for MATE RPMs: caja caja-core-extensions caja-devel caja-schemas Size: 21.56 MiB Size change: 109.10 KiB Changelog: * Wed Sep 18 2019 Wolfgang Ulbrich - 1.22.2-1 - update to 1.22.2 Package: caja-extensions-1.22.1-1.fc32 Old package: caja-extensions-1.22.0-2.fc31 Summary: Set of extensions for caja file manager RPMs: caja-beesu caja-extensions-common caja-image-converter caja-open-terminal caja-sendto caja-sendto-devel caja-share caja-wallpaper caja-xattr-tags Size: 1.21 MiB Size change: -8.17 KiB Changelog: * Wed Sep 18 2019 Wolfgang Ulbrich - 1.22.1-1 - update to 1.22.1 Package: containernetworking-plugins-0.8.2-0.4.dev.git291ab6c.fc32 Old package: containernetworking-plugins-0.8.2-0.3.dev.git23d5525.fc32 Summary: Libraries for writing CNI plugin RPMs: containernetworking-plugins containernetworking-plugins-devel containernetworking-plugins-unit-test-devel Size: 53.33 MiB Size change: -2.54 KiB Changelog: * Wed Sep 18 2019 Lokesh Mandvekar (Bot) - 0.8.2-0.4.dev.git291ab6c - autobuilt 291ab6c Package: engrampa-1.22.2-1.fc32 Old package: engrampa-1.22.1-2.fc31 Summary: MATE Desktop file archiver RPMs: engrampa Size: 6.54 MiB Size change: 65.27 KiB Changelog: * Wed Sep 18 2019 Wolfgang Ulbrich - 1.22.2-1 - update to 1.22.2 Package: eom-1.22.2-1.fc32 Old package: eom-1.22.1-3.fc32 Summary: Eye of MATE image viewer RPMs: eom eom-devel Size: 11.93 MiB Size change: 90.88 KiB Changelog: * Wed Sep 18 2019 Wolfgang Ulbrich - 1.22.2-1 - update to 1.22.2 Package: fedora-review-0.7.3-1.fc32 Old package: fedora-review-0.7.2-3.fc32 Summary: Review tool for fedora rpm packages RPMs: fedora-review fedora-review-plugin-ruby fedora-review-tests Size: 17.59 MiB Size change: 10.49 KiB
Re: Renewing the Modularity objective
I'd suggest that the Modularity team could preapre a list of example
use cases that will present the strenghts of the modularity.
I believe, there are currently many examples of packages that took a
path to become only modular and it always created more issues than it
solved.
Let's focus on a simple use cases first, which only modularity can
solve the best and leave the more complicated ones for later - after a
careful consideration if turning some regular packages into only
modules would really help both packager and user experience.
Keep in mind, there are still wide gaps in the modularity packager
experience, new bugs spawning every now and then.
In light of this persistent situation, I honor the new goal currently
set of focusing at those issues.
--
I'll start with my use case, which IMHO can be used as a great case
advocating for modularity.
I'm a maintainer of MariaDB, MySQL and some software around.
While the new major version of the database is being developed, I'd
love to pack it in Fedora, test it, offer it to the users and provide
feedback to the upstream, solving the uprising issues with them way
before the GA.
Because I want to keep a stable version in the base Fedora, I'm using
modules to provide both of them.
E.g. when MySQL 8 was being developed ( pre-GA releases ), I normally
maintained the MySQL 5.7 (latest stable major version) in the base
Fedora, while having MySQL 8 as a module.
When the MySQL 8 went GA, I had MySQL 5.7 in Fedora N and MySQL 8 in Fedora N+1.
However at the same time I also provided MySQL 5.7 as a module in both
Fedora N and N+1. Same for MySQL 8 module (in both Fedora N & N+1).
That way, the users weren't forced to upgrade right away (once the
Fedora N went EOL), but they got time to prepare and / or test it
first.
In a case, when user is hungry for the very latest version, he has the
MySQL 8 available before it went ot the base Fedora, and even before
the MySQL 8 went GA, so he can provide feedback to the upstream either
directly or through me (via BZ).
Since the upgrades between Fedora releases with modules when the
version in Fedora base changes are still not really thought through,
you (as a user) need the same module in the both Fedora N & N+1,
beacuse you can't upgrade Fedora version from MySQL 5.7 that was in
base to MySQL 5.7 module, since newly there is MySQL 8 is in the base
Fedora.
I believe no other applicable solution is as elegant for my use case,
as modularity has.
COPR repositories are hidden from the users (you first need to know
which repo you want to use before getting it's content), and the
builds from there are not pushed through the updtae system (BODHI) to
discover bugs early.
New package (named e.g. 'mysql-8' ) is also far from "elegant"
solution. Even further when I (the pkg mainatiner) plan to soon (once
GA is released) update to that version in the original package.
The same for MariaDB 10.3 -> 10.4; future 10.4 -> 10.5 ...
--
I strogly believe a list of use cases like this would make the
modularity much more clear to both mainatiners and users.
Stick to Unix philosophy ("Do One Thing and Do It Well") and don't
rush or even try to make modules from everything.
--
Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
--
On Wed, Sep 18, 2019 at 9:32 PM Ben Cotton wrote:
>
> Now that Modularity is available for all Fedora variants, it's time to
> address issues discovered and improve the experience for packagers and
> users. The Modularity team identified a number of projects that will
> improve the usefulness of Modularity and the experience of creating
> modules for packagers. Thoe team is proposing a renewed objective to
> the Fedora Council.
>
> You can read the proposal at:
> https://pagure.io/Fedora-Council/council-docs/pull-request/61#request_diff
>
> The Council will vote on this in two weeks.
>
> This is also posted to the Community Blog:
> https://communityblog.fedoraproject.org/renewing-the-modularity-objective/
>
> --
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://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
Estimate the size of iso file based on a kickstart file
Hi all, Given a kickstart file (flatten) and we intend to make an iso using it, is there a tool or service by which we can estimate the size of the final iso (based on the packages defined in the kickstart file) before actually creating the iso? -- Best Regards, Kalpa Welivitigoda http://about.me/callkalpa ___ 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: Estimate the size of iso file based on a kickstart file
On Thu, Sep 19, 2019 at 8:11 AM Kalpa Welivitigoda wrote: > > Hi all, > > Given a kickstart file (flatten) and we intend to make an iso using > it, is there a tool or service by which we can estimate the size of > the final iso (based on the packages defined in the kickstart file) > before actually creating the iso? Since a kickstart file can refer to RPM's stored on the ISO file, or on a separate website, and those RPM's are the majority of the bulk of an installation DVD, it's not clear you can gracefully do this. A single RPM file can drag in a *lot* of dependencies that may change based on upstream updates. Why try to guess rather than simply running the tool, which will be pretty fast if you work from a local yum mirror? ___ 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
YACBSIPT, rawhide ceph build stuck in bodhi, again
Someone with privs please kick it. Thanks https://bodhi.fedoraproject.org/updates/FEDORA-2019-995f3ae953 ___ 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: Renewing the Modularity objective
On 2019-09-19, Michal Schorm wrote: > While the new major version of the database is being developed, I'd > love to pack it in Fedora, test it, offer it to the users and provide > feedback to the upstream, solving the uprising issues with them way > before the GA. > Because I want to keep a stable version in the base Fedora, I'm using > modules to provide both of them. > E.g. when MySQL 8 was being developed ( pre-GA releases ), I normally > maintained the MySQL 5.7 (latest stable major version) in the base > Fedora, while having MySQL 8 as a module. > When MySQL 8 is being developed and being packages as module, do you build the module for Rawhide only or for all Fedoras? If you build it for all Fedoras, how do you deal with incompatible changes during the MySQL 8 developement. I'm hitting on the Fedora Updates Policy that forbids incompatible changes in stable Fedoras. If you build it for Rawhide only, how do you ensure that the module is not inheritted into a stable Fedora on branching. Because in case of branching F31 relengs tried very hard to branch the module and rebuild them. (Despite I told them not to do that with perl:5.26.) I'm still missing an offical recognition that there can be modules under development in stable Fedora. Otherwise we have no way of developing new modules. Fedora tries very hard to align module lifecycle to Fedora lifecycle. It does not work for me. -- Petr ___ 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: aarch64 test systems implementation
On Thu, Sep 19, 2019 at 12:28 PM Dave Love wrote: > > Are the aarch64 test systems running on real or emulated hardware? (Is > there a way to tell?) > > I ask because I'm seeing bad numerical results from a test and would > like to know if I can eliminate qemu as a possible cause -- not that I > think that's likely. Do you mean a system to test SRPM on aarch64? or a system to test a open source code? Do you mean CI testing system or an aarch64 server for adhoc test? ___ 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: Renewing the Modularity objective
> When MySQL 8 is being developed and being packages as module, do you > build the module for Rawhide only or for all Fedoras? > > If you build it for all Fedoras, how do you deal with incompatible > changes during the MySQL 8 developement. I'm hitting on the Fedora > Updates Policy that forbids incompatible changes in stable Fedoras. > > If you build it for Rawhide only, how do you ensure that the module is > not inheritted into a stable Fedora on branching. Because in case of > branching F31 relengs tried very hard to branch the module and rebuild > them. (Despite I told them not to do that with perl:5.26.) That's a great observation. Ususally when the package (module in this case) is prone to breaking bugs, I develop it in Rawhide and only later, (e.g. Beta, but it depends from upstream to upstream) I extend the build to other Fedoras. > I'm still missing an offical recognition that there can be modules under > development in stable Fedora. Otherwise we have no way of developing new > modules. Fedora tries very hard to align module lifecycle to Fedora > lifecycle. It does not work for me. That's surely an *absolute need* to have an option to mark a module as "under developement" or something simmilar and have that anchored in the guidelines, if we want to use this chance a modularity technically offers. -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Thu, Sep 19, 2019 at 2:33 PM Petr Pisar wrote: > > On 2019-09-19, Michal Schorm wrote: > > While the new major version of the database is being developed, I'd > > love to pack it in Fedora, test it, offer it to the users and provide > > feedback to the upstream, solving the uprising issues with them way > > before the GA. > > Because I want to keep a stable version in the base Fedora, I'm using > > modules to provide both of them. > > E.g. when MySQL 8 was being developed ( pre-GA releases ), I normally > > maintained the MySQL 5.7 (latest stable major version) in the base > > Fedora, while having MySQL 8 as a module. > > > When MySQL 8 is being developed and being packages as module, do you > build the module for Rawhide only or for all Fedoras? > > If you build it for all Fedoras, how do you deal with incompatible > changes during the MySQL 8 developement. I'm hitting on the Fedora > Updates Policy that forbids incompatible changes in stable Fedoras. > > If you build it for Rawhide only, how do you ensure that the module is > not inheritted into a stable Fedora on branching. Because in case of > branching F31 relengs tried very hard to branch the module and rebuild > them. (Despite I told them not to do that with perl:5.26.) > > I'm still missing an offical recognition that there can be modules under > development in stable Fedora. Otherwise we have no way of developing new > modules. Fedora tries very hard to align module lifecycle to Fedora > lifecycle. It does not work for me. > > -- Petr > ___ > 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: [Test-Announce] Fedora 31 Beta Release Announcement
On 9/18/19 17:41, Petr Pisar wrote: On 2019-09-18, Kalev Lember wrote: Hm, did perl get moved to the modular repo? That sounds like it is going to cause more issues than solve as it's not a leaf package. Why can't it stay as a regular package? Perl is still a regular package and until Fedora allows modules in a build root I wan't even start thinking about removing non-modular perl. But I provide modulerized perl in addition to the non-modular one. And there is indeed not much use of it if you don't want to sascrifice all the other Perl packages. Though, this crypto-tools error showed me one of the uses I did not realize before. I just found it interesting and wanted to pointed it out. Ahh, great :) Thanks, Petr! -- Kalev ___ 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: Renewing the Modularity objective
> I'd suggest that the Modularity team could preapre a list of example > use cases that will present the strenghts of the modularity. I just share below my project for me to investigate use cases to switch a modules stream with Fedora (and RHEL) container and Travis CI. It's not general module examples but only examples to switch a module. But I believe that the way to show the example with actual command lines with the Fedora container and Travis CI helps someone to advocate the list of the example use cases. https://github.com/junaruga/switch-module-stream -- Jun | He - His - Him ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Estimate the size of iso file based on a kickstart file
On 9/19/19 8:25 AM, Nico Kadel-Garcia wrote: > On Thu, Sep 19, 2019 at 8:11 AM Kalpa Welivitigoda > wrote: >> Hi all, >> >> Given a kickstart file (flatten) and we intend to make an iso using >> it, is there a tool or service by which we can estimate the size of >> the final iso (based on the packages defined in the kickstart file) >> before actually creating the iso? > Since a kickstart file can refer to RPM's stored on the ISO file, or > on a separate website, and those RPM's are the majority of the bulk of > an installation DVD, it's not clear you can gracefully do this. A > single RPM file can drag in a *lot* of dependencies that may change > based on upstream updates. Why try to guess rather than simply running > the tool, which will be pretty fast if you work from a local yum > mirror? Doesn't anaconda do a test to see if the install will fit? I vaguely recall (or imagine, with age it seems there's little difference sometimes) seeing such a message. If so, that would handle all the dependency recursion and from there a statistical factor for the expected compression should get a reasonably close estimate, no? -- John 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
specfile dependecy to pip package
Hi,
I'm maintainer of libcbor package and in fedora 30 has been removed
python3-sphinx package which is required to build documentation for
libcbor. I can changa the dependency to python2-sphinx but thats not what I
really want to do. Another option is to install sphinx via pip3. However in
build phase it will show an error which says:
sphinx-build -b man -d build/doctrees source build/man
Traceback (most recent call last):
File "/usr/local/bin/sphinx-build", line 6, in
from sphinx.cmd.build import main
ModuleNotFoundError: No module named 'sphinx'
make: *** [Makefile:131: man] Error 1
(it needs breathe package and that is installed as well using pip3)
Now I have two questions:
1. How can I write to specfile that I need a pip package?
I tried:
BuildRequires: %{py3_dist Sphinx} >= 2.2.0
And as well:
BuildRequires: %{py3_dist sphinx} >= 2.2.0
Both of those will show an dependency error even when I install sphinx
and breathe using pip3:
python3dist(sphinx) >= 2.2.0 is needed by libcbor-0.5.0-5.fc30.x86_64
2. How to fix that error from sphinx-build?
I tried to install even sphinx-multibuild (using pip) but did not succeed.
It is suspicious that sphinx package need sphinx and it can not find it.
Regards,
Marek Tamaskovic
___
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: specfile dependecy to pip package
python3-sphinx not removed.
Look at
https://koji.fedoraproject.org/koji/packageinfo?packageID=6297
чт, 19 сент. 2019 г. в 16:03, Marek Tamaskovic :
>
> Hi,
> I'm maintainer of libcbor package and in fedora 30 has been removed
> python3-sphinx package which is required to build documentation for libcbor.
> I can changa the dependency to python2-sphinx but thats not what I really
> want to do. Another option is to install sphinx via pip3. However in build
> phase it will show an error which says:
>
> sphinx-build -b man -d build/doctrees source build/man
> Traceback (most recent call last):
> File "/usr/local/bin/sphinx-build", line 6, in
> from sphinx.cmd.build import main
> ModuleNotFoundError: No module named 'sphinx'
> make: *** [Makefile:131: man] Error 1
>
> (it needs breathe package and that is installed as well using pip3)
>
> Now I have two questions:
>
> 1. How can I write to specfile that I need a pip package?
> I tried:
>
> BuildRequires: %{py3_dist Sphinx} >= 2.2.0
>
> And as well:
>
> BuildRequires: %{py3_dist sphinx} >= 2.2.0
>
> Both of those will show an dependency error even when I install sphinx and
> breathe using pip3:
>
> python3dist(sphinx) >= 2.2.0 is needed by libcbor-0.5.0-5.fc30.x86_64
>
>
> 2. How to fix that error from sphinx-build?
> I tried to install even sphinx-multibuild (using pip) but did not succeed.
> It is suspicious that sphinx package need sphinx and it can not find it.
>
> Regards,
> Marek Tamaskovic
> ___
> 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: specfile dependecy to pip package
Hi Marek,
Marek Tamaskovic writes:
> Hi,
> I'm maintainer of libcbor package and in fedora 30 has been removed
> python3-sphinx package which is required to build documentation for
> libcbor. I can changa the dependency to python2-sphinx but thats not what I
> really want to do. Another option is to install sphinx via pip3.
You cannot/should not install packages via pip during rpmbuild as mock &
koji don't allow network connections (at least by default).
> However in build phase it will show an error which says:
>
> sphinx-build -b man -d build/doctrees source build/man
> Traceback (most recent call last):
> File "/usr/local/bin/sphinx-build", line 6, in
> from sphinx.cmd.build import main
> ModuleNotFoundError: No module named 'sphinx'
> make: *** [Makefile:131: man] Error 1
>
> (it needs breathe package and that is installed as well using pip3)
>
> Now I have two questions:
>
> 1. How can I write to specfile that I need a pip package?
> I tried:
>
> BuildRequires: %{py3_dist Sphinx} >= 2.2.0
>
> And as well:
>
> BuildRequires: %{py3_dist sphinx} >= 2.2.0
>
> Both of those will show an dependency error even when I install sphinx
> and breathe using pip3:
>
> python3dist(sphinx) >= 2.2.0 is needed by libcbor-0.5.0-5.fc30.x86_64
>
In Fedora 30 there is only Sphinx 1.8.4, so you'll have to patch your
package to work with an older version of sphinx.
>
> 2. How to fix that error from sphinx-build?
> I tried to install even sphinx-multibuild (using pip) but did not succeed.
> It is suspicious that sphinx package need sphinx and it can not find it.
>
> Regards,
> Marek Tamaskovic
> ___
> 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
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 Beta Release Announcement
On Wed, Sep 18, 2019 at 5:25 PM Kevin Kofler wrote: > > Zbigniew Jędrzejewski-Szmek wrote: > > So... building multilib packages is still very much supported. You cannot > > *run* a pure-i686 environment, but you can 32 bit development. > > You have to configure a slow, non-mirrored repository for that instead of > just using the same mirrored URL pattern (with $basearch substituted > automatically) as for the still fully supported architectures. And there is > no real technical reason to do that, the only goal was to deliberately > inconvenience users attempting to use the software. > This is true for building locally for i686. You cannot do 32-bit development with multilib x86_64 content. > >> * the insane proposal to require AVX2 for x86_64, which has thankfully > >> not been implemented so far, but against which we will likely have to > >> fight again and again during the next few years, > > > > This proposal was rejected very forcefully. fedora-devel was unanimous > > with >100 messages, which I have never seen apart from that once case. > > If it get's proposed again, you can expect the same result. > > I have seen several features with similarly overwhelmingly negative > fedora-devel feedback that were waved through by FESCo anyway. (See, e.g., > Modularity, where from the beginning, I and others had pointed out the > provably unsolvable flaws in the core design axioms, which, very > unsurprisingly, materialized exactly as predicted, see > https://communityblog.fedoraproject.org/modularity-vs-libgit/ . All this did > not prevent the feature from getting approved and implemented.) > The difference was the modularity only managed to make it in originally by being described as a purely add-on concept. It was individual packagers that started breaking the world by churning core packages into modules. Everyone knew up front that the hardware change was bad and there's no way to sneak that in without breaking people. It's not going in anytime soon. > > Well, yes. Unmaintained packages are retired. Sorry, but it's either that > > or development of new things in Fedora stops, because every change is > > hamstrung by uninstallable and unbuildable packages. We just can't have > > packages with no maintainers. > > Most packages with no maintainers actually still just work (without even a > rebuild). Some require a trivial rebuild. Only a handful are actually > broken, and those are reasonable candidates for a removal. But removing > working packages only for the lack of a maintainer serves no purpose and is > a pure disservice to the users of the package. > > There is often no reasonable alternative tool for the purpose. So what are > the users of the removed package supposed to do? > Become maintainers of the package? This is sort of the point of the system. Someone needs to take care of it, and if there's a user, they can become a maintainer. Ideally, most consumers of the package (dependency-wise) would consider at least being co-maintainers of their direct dependencies. > > Those removals are not quick: FTBFS packages are retired after *months*, > > orphaning usually only happens when there are long-standing unresolved > > bugs. In most cases, the package is bitrotting for multiple releases > > before any removal happens. > > Orphaning usually happens because the maintainer explicitly orphans the > package. The policies then leave only 6 weeks for the package to get adopted > before it will get retired! That is not "long-standing" at all. > > And if an otherwise maintained package FTBFS, if it does not actually need > any change, I don't see how this is even an issue at all. > It appears quick because we've have the FTBFS orphaning process be broken for three years. There's a lot of breakage to catch up on. Regular orphanings are happening because for some reason we allow orphaned packages to be used as inputs for modules, so now we have this giant mess of dead packages that aren't dead. This is a very broken policy and should be fixed, but I suspect that it won't be, because that would force module packages to always have a non-modular counterpart in the distribution, based on how our tools work. > > That's very much unfair. The python team has put an _insane_ amount of > > work into telling everyone about the transition, planning all the > > steps, filing bugs, retiring leaf packages first, asking for feedback, > > fixing bugs, etc, etc, etc. "Agressive" would be all python2 packages > > were simply dropped after F32 branching. > > If only they had instead put such an "_insane_ amount of work" into actually > maintaining, and committing to maintain for at least 5 to 10 more years, the > python2 compatibility package, which is actually not work-intensive at all > (just backport security fixes from Python 3 as they happen, which they'll > likely have to do for RHEL anyway). > > Instead, a lot of time was wasted spamming everyone about the impending > scorched earth "transition", quickly getti
Re: specfile dependecy to pip package
On 19. 09. 19 15:12, Dan Čermák wrote: In Fedora 30 there is only Sphinx 1.8.4, so you'll have to patch your package to work with an older version of sphinx. Or stop building the docs on Fedora 30 and only build it on Fedora 31+. -- 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: Fedora 31 Beta Release Announcement
Neal Gompa wrote: > This is true for building locally for i686. You cannot do 32-bit > development with multilib x86_64 content. Yes, that is my point. Well, actually, you can do some amount of 32-bit development with multilib -devel packages, but mock RPM builds require a complete 32-bit chroot. So multilib is not even self-hosting (i.e., the removal of the 32-bit repositories makes Fedora no longer a self-hosting distribution). > The difference was the modularity only managed to make it in > originally by being described as a purely add-on concept. It was > individual packagers that started breaking the world by churning core > packages into modules. That could have been prevented by policy, but deliberately was not, because the people behind Modularity had exactly this (moving random packages to module-only) as their hidden agenda. I had warned about this part, too, and asked for policies ensuring that modules remain purely optional. I only got excuses (of the kind "it is not planned anyway, but we are strictly against actually banning it" – ha ha, guess why) and no such policy, and FESCo failed to require the requested policy and took the Modularity people's (obviously dishonest – again, why on Earth would they have been against such a policy if they truly had no plans to do the exact opposite?) word for it. > Everyone knew up front that the hardware change was bad and there's no > way to sneak that in without breaking people. It's not going in > anytime soon. Hopefully! > Become maintainers of the package? This is sort of the point of the > system. Someone needs to take care of it, and if there's a user, they > can become a maintainer. Ideally, most consumers of the package > (dependency-wise) would consider at least being co-maintainers of > their direct dependencies. It is absolutely not realistic to expect all end users to become package maintainers. > It appears quick because we've have the FTBFS orphaning process be > broken for three years. There's a lot of breakage to catch up on. For the orphaned packages, the process is quick by policy, it only allows for 6 weeks! And I still do not see why the lack of a maintainer is by itself (without actual issues with the package being reported by actual users) a reason to remove a package. From a user standpoint, it is better to have an unmaintained package of the software I need than none at all! The FTBFS process has slightly more reasonable time frames, but I disagree that FTBFS is by itself an issue worth orphaning or retiring packages for to begin with. A failure to build only becomes an issue if I need to change something in the package or rebuild it due to some soname bump, and that is the point where I will fix it anyway. Otherwise, those FTBFS bugs are only an annoyance forcing me to spend time on irrelevant issues rather than on real ones. > Regular orphanings are happening because for some reason we allow > orphaned packages to be used as inputs for modules, so now we have > this giant mess of dead packages that aren't dead. This is a very > broken policy and should be fixed, but I suspect that it won't be, > because that would force module packages to always have a non-modular > counterpart in the distribution, based on how our tools work. Forcing all packages to have a non-modular version would fix a lot of the insanity of Modularity. I would be all in favor of that as well! >> See qt (4) and kdelibs (4), and qt3 and kdelibs3, for how compatibility >> should work. > > Those transitions had the benefit of the major consumer (KDE) moving > forward relatively quickly after. Python 2 is not in the same state. > In many cases, Fedora is the driver for packages getting ported to > Python 3, and if we hadn't done it, it likely wouldn't have ever > happened. This is one of the major things I consider valuable about > Fedora. If we don't do it, I do not believe anyone else would. But there is just no way that Fedora can get all upstream software ported to Python 3, and so, radically removing Python 2 will deprive users of software they need and that has no supported alternative. There is the FESCo exception process, but it is clearly not working, because FESCo can veto any package from being provided, see e.g.: https://pagure.io/fesco/issue/2223 It should be the call of the maintainer of the package whether they still want to provide the package, and if not, they should orphan it and leave somebody else the chance to pick it up. But in no way should it require the approval of a committee that can (and does, see above) say "no" arbitrarily. > Look, if something is actually declared dead and unmaintained and > there is an upgrade path, then it is on us to help everyone get > through that upgrade path. That is literally the point of a > distribution. We have a set of opinions of how the distribution is put > together, maintained, and evolved. While I disagree with the removal > of i686 content from the mir
Re: Fedora in GNOME Online Accountes
So with help from Rishi, we got it working by: * Adding a config file [1] into the container. * Poking a hole in the flatpak sandbox [2], though this is clearly a nasty hack. I think this will do for now, though improvements would be good [1] https://gitlab.gnome.org/GNOME/gnome-build-meta/merge_requests/389/diffs [2] https://gitlab.gnome.org/GNOME/epiphany/commit/bba622a1b92c29cad65af3ca27f4d6be55a925c9 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages looking for new maintainers
Hello, I would like to claim python-volatility and python-impacket,. Michal Ambroz -- Původní e-mail -- Od: Miro Hrončok Komu: Development discussions related to Fedora , devel-annou...@lists.fedoraproject.org Datum: 16. 9. 2019 12:01:28 Předmět: Orphaned packages looking for new maintainers "The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Request package ownership via releng issues: https://pagure.io/releng/issues Full report available at: https://churchyard.fedorapeople.org/orphans-2019-09-16.txt grep it for your FAS username and follow the dependency chain. Package (co)maintainers Status Change 7kaa orphan 7 weeks ago PyRTF orphan 1 weeks ago R-ALL orphan 3 weeks ago R-AnnotationDbi orphan 3 weeks ago R-BSgenome orphan 3 weeks ago R-BSgenome.Celegans.UCSC.ce2 orphan 3 weeks ago R-Biobase orphan 3 weeks ago R-BiocGenerics orphan 3 weeks ago R-Biostrings orphan 3 weeks ago R-BufferedMatrix orphan 3 weeks ago R-BufferedMatrixMethods orphan 3 weeks ago R-DynDoc orphan 3 weeks ago R-GenomicFeatures orphan 3 weeks ago R-GenomicRanges orphan 3 weeks ago R-IRanges orphan 3 weeks ago R-ROC orphan 3 weeks ago R-affy orphan 3 weeks ago R-affydata orphan 3 weeks ago R-affyio orphan 3 weeks ago R-fibroEset orphan 3 weeks ago R-hgu133acdf orphan 3 weeks ago R-hgu95av2cdf orphan 3 weeks ago R-hgu95av2probe orphan 3 weeks ago R-maanova orphan 3 weeks ago R-multtest alexlan, orphan 3 weeks ago R-pls orphan 3 weeks ago R-preprocessCore orphan 3 weeks ago R-statmod orphan 3 weeks ago R-tkWidgets orphan 3 weeks ago R-widgetTools orphan 3 weeks ago RackTables orphan 1 weeks ago TeXamator orphan 1 weeks ago XmlSchema msimacek, orphan 1 weeks ago Xnee orphan 4 weeks ago access-modifier-annotation mizdebsk, orphan 2 weeks ago accumulo ctubbsii, milleruntime, 4 weeks ago mizdebsk, orphan acegisecurity mizdebsk, orphan 2 weeks ago adapta-backgrounds orphan 0 weeks ago adapta-gtk-theme orphan 0 weeks ago adevs orphan 4 weeks ago akuma orphan 2 weeks ago alacarte alexl, caillon, caolanm, 0 weeks ago johnp, mbarnes, orphan, rhughes, ssp annotation-indexer mizdebsk, orphan 2 weeks ago anyremote orphan 1 weeks ago apache-commons-csv mizdebsk, orphan, spike 2 weeks ago apache-commons-discovery lkundrak, mizdebsk, orphan, 2 weeks ago spike apache-commons-el fnasser, mizdebsk, orphan, 2 weeks ago spike apache-commons-launcher orphan 1 weeks ago apache-mina orphan 2 weeks ago apache-poi gil, lef, orphan 6 weeks ago apache-sshd gil, orphan 2 weeks ago arptools jhrozek, orphan 2 weeks ago asterisk-gui orphan 4 weeks ago audio-convert-mod orphan 0 weeks ago b43-tools orphan 1 weeks ago batti orphan 0 weeks ago belier orphan 3 weeks ago bing orphan 5 weeks ago bios_extract orphan 1 weeks ago bitlyclip orphan, ralph 6 weeks ago boxes jhrozek, orphan 2 weeks ago bridge-method-injector mizdebsk, orphan 2 weeks ago bundling-detection-java mizdebsk, orphan 2 weeks ago bytecode-compatibility- mizdebsk, orphan 2 weeks ago transformer c3p0 orphan 2 weeks ago captcp orphan 1 weeks ago cassandra acaringi, hhorak, jjanco, 1 weeks ago orphan certmaster alikins, orphan, robert, 1 weeks ago wakko666 cfv dfateyev, orphan 2 weeks ago check-mk orphan 1 weeks ago checkdns orphan 4 weeks ago chm2pdf orphan 0 weeks ago comedilib orphan 1 weeks ago concurrentunit orphan 1 weeks ago constant-pool-scanner mizdebsk, orphan 2 weeks ago curator ctubbsii, milleruntime, 4 weeks ago orphan, tstclair dfish orphan 4 weeks ago dia-CMOS orphan 0 weeks ago dia-Digital orphan 0 weeks ago dia-electric2 orphan 0 weeks ago dia-electronic orphan 0 weeks ago disper orphan 3 weeks ago drobo-utils imntreal, orphan 1 weeks ago dwdiff jhrozek, orphan 2 weeks ago easybashgui orphan 4 weeks ago emma orphan 2 weeks ago enunciate orphan, pahuang 7 weeks ago epydoc orphan, thias 1 weeks ago espresso-ab orphan 0 weeks ago euca2ools orphan 0 weeks ago ezmorph gil, lkundrak, orphan 6 weeks ago felix-main orphan 1 weeks ago fishpoll marionline, orphan 1 weeks ago fluxbox dchen, orphan 0 weeks ago freenx-server orphan 1 weeks ago fsniper jhrozek, orphan 2 weeks ago func alikins, orphan, robert, 0 weeks ago wakko666 fuse-python moezroy, orphan 1 weeks ago gadget orphan 1 weeks ago gcc-python-plugin jakub, orphan 0 weeks ago geronimo-jaspic-spec mizdebsk, orphan 2 weeks ago ginfo orphan, stevetraylen 0 weeks ago git-bz orphan 1 weeks ago gitflow infra-sig, orpha
Re: aarch64 test systems implementation
Jun Aruga writes: > On Thu, Sep 19, 2019 at 12:28 PM Dave Love > wrote: >> >> Are the aarch64 test systems running on real or emulated hardware? (Is >> there a way to tell?) >> >> I ask because I'm seeing bad numerical results from a test and would >> like to know if I can eliminate qemu as a possible cause -- not that I >> think that's likely. > > Do you mean a system to test SRPM on aarch64? or a system to test a > open source code? > Do you mean CI testing system or an aarch64 server for adhoc test? I don't know why it matters, but I'm testing dynamic micro-architecture selection added to a library I've packaged. ___ 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
Logs from Open NeuroFedora team meeting at 1500 UTC on Thursday, 19th September
Hello, The logs from the NeuroFedora team meeting on 19th September are below: - HTML logs: https://meetbot.fedoraproject.org/fedora-neuro/2019-09-19/neurofedora.2019-09-19-15.00.log.html - HTML minutes: https://meetbot.fedoraproject.org/fedora-neuro/2019-09-19/neurofedora.2019-09-19-15.00.html The raw minutes are pasted below for your convenience: = #fedora-neuro: NeuroFedora 2019-09-19 = Meeting started by FranciscoD at 15:00:45 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-neuro/2019-09-19/neurofedora.2019-09-19-15.00.log.html . Meeting summary --- * Agenda summary (FranciscoD, 15:02:23) * https://lists.fedoraproject.org/archives/list/neuro-...@lists.fedoraproject.org/thread/CF7RE5AC6O2TH5PPOX7KVCQUKDPBTHWI/ (FranciscoD, 15:02:26) * Introductions and roll-call (FranciscoD, 15:02:34) * Tasks from last meeting (FranciscoD, 15:02:40) * Pagure tickets (FranciscoD, 15:02:44) * Bugs (FranciscoD, 15:02:47) * Neuroscience query of the week (FranciscoD, 15:02:56) * Next meeting chair (FranciscoD, 15:03:02) * Open floor (FranciscoD, 15:03:08) * Introductions and roll call (FranciscoD, 15:03:16) * Tasks from last meeting on 12th Sep 2019 (FranciscoD, 15:08:06) * Minutes: https://meetbot.fedoraproject.org/teams/neurofedora/neurofedora.2019-09-12-15.01.html (FranciscoD, 15:08:27) * FranciscoD dan1mal open comps PR: DONE (FranciscoD, 15:08:43) * dan1mal to update their user page on wiki: https://fedoraproject.org/wiki/User:Dan1mal: DONE (FranciscoD, 15:09:10) * FranciscoD submit change proposal: DONE (FranciscoD, 15:09:35) * Change propsal was sent out to devel-announce and devel lists: https://fedoraproject.org/wiki/Changes/Comp_Neuro_Lab (FranciscoD, 15:09:47) * FranciscoD write OSB workshop event report: PENDING, Reassigning (FranciscoD, 15:10:06) * ACTION: FranciscoD write OSB workshop event report (FranciscoD, 15:10:11) * mhough send out logs: DONE (FranciscoD, 15:10:21) * Pagure tickets (FranciscoD, 15:10:53) * Pagure tickets marked for this meeting: https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open&tags=S%3A+Next+meeting (FranciscoD, 15:11:11) * Issue #250: Figure out badges rule to award badge automatically to pagure group members: https://pagure.io/neuro-sig/NeuroFedora/issue/250 (FranciscoD, 15:11:40) * Issue #678: You're a member of the Neuro Fedora SIG - fedora-badges : https://pagure.io/fedora-badges/issue/678 (FranciscoD, 15:12:07) * riecatnor improved the badge, please give your comments (FranciscoD, 15:12:19) * Improved version of badge: https://pagure.io/fedora-badges/issue/678#comment-597731 (FranciscoD, 15:12:36) * Issue #250: Figure out badges rule to award badge automatically to pagure group members - NeuroFedora - waiting on Badges #678 (FranciscoD, 15:14:06) * Issue #274: Flock: conference reports - NeuroFedora - https://pagure.io/neuro-sig/NeuroFedora/issue/274 (FranciscoD, 15:14:39) * ACTION: FranciscoD close #274 on Monday (FranciscoD, 15:15:14) * Issue #292: A default bibliography manager for inclusion in NeuroFedora groups/image - NeuroFedora - https://pagure.io/neuro-sig/NeuroFedora/issue/292 (FranciscoD, 15:15:31) * BibTeX format and explanations: https://en.wikipedia.org/wiki/BibTeX (FranciscoD, 15:19:18) * LINK: https://github.com/zotero I remember this as well... Zotero is a manager, right? (MeWjOr, 15:19:38) * LINK: https://www.zotero.org/download/ -> version 5.0 for Linux (FranciscoD, 15:22:15) * LINK: https://www.zotero.org/support/dev/client_coding/building_the_standalone_client (FranciscoD, 15:26:16) * ACTION: FranciscoD add zotero and jabref to docs (FranciscoD, 15:29:02) * AGREED: Add zotero + jabref to docs and not work on packaging them up at the moment (FranciscoD, 15:29:19) * https://fedoraproject.org/wiki/Changes/Policy#How_is_a_change_accepted.3F -> next steps here (FranciscoD, 15:33:18) * ACTION: FranciscoD file ticket with infra requesting fedorapeople space to host our test lab image (FranciscoD, 15:35:18) * Next steps for lab image: generate test images (FranciscoD, 15:36:44) * PR#410: Add neuro-fedora related groups and categories - fedora-comps - https://pagure.io/fedora-comps/pull-request/410 -> filed already, waiting for merge (FranciscoD, 15:37:32) * ACTION: FranciscoD poke/ping comps PR in 2 weeks (FranciscoD, 15:38:13) * Open bugs (FranciscoD, 15:38:41) * Open bugs: https://tinyurl.com/neurofedora-bugs (FranciscoD, 15:38:59) * NOTE: All python-fsl* packages must be submitted as a single update (FranciscoD, 15:40:50) * Neuroscience query of the week (FranciscoD, 15:47:42) * Next meeting time and chair (FranciscoD, 15:55:03) * Next meeting will
Re: Fedora 31 Beta Release Announcement
On Wed, 2019-09-18 at 23:24 +0200, Kevin Kofler wrote: > And if an otherwise maintained package FTBFS, if it does not actually > need > any change, I don't see how this is even an issue at all. FTBFS packages can get CVEs filed against them and then they can be difficult to fix. There are a few problems: * The FTBFS package often has no maintainer to notice the CVE in the first place, which means it is likely to just be vulnerable without any other packagers noticing. * If someone does notice the CVE and wants to fix it, they have to first figure out why the package doesn't build. This is at a minimum extra work for the maintainer, and in some cases it could be that it is impossible to fix the FTBFS (for example, if the package requires an older dependency than is in the distribution that was removed or upgraded years ago). * If it is impossible to fix the FTBFS and there is a CVE, we also cannot remove the vulnerable package from stable releases. The current policy does curtail that last problem (but does not eliminate it entirely) by removing some FTBFS packages before they have CVEs. Of course, we do have unmaintained software in the distribution despite this policy, but the policy does lead to *fewer* unmaintained packages, which means fewer packages with the above problems. The FTBFS policy essentially is an "are you there?" to the maintainer. It is a disservice to our users to provide them with unmaintained packages, and this is one tool we have to find out if packagers are still around. signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: aarch64 test systems implementation
> > Do you mean a system to test SRPM on aarch64? or a system to test a > > open source code? > > Do you mean CI testing system or an aarch64 server for adhoc test? > > I don't know why it matters, but I'm testing dynamic micro-architecture > selection added to a library I've packaged. Because there are some proper choices depending on the situation. * Test by mock command (aarch64 qemu environment). (SRPM, adhoc) https://github.com/rpm-software-management/mock/wiki/Feature-forcearch * Test by Koji (aarch64 native) (SRPM, a kind of CI) * Test by Copr (aarch64 native or qemu. I am not sure) * Test by Packit service (aarch64 native, maybe) (SRPM, CI) * Test qemu-user-static RPM and aarch64 container * on local (Source, adhoc) * with CI services (Source, CI) * Test with Travis CI with qemu (aarch64 qemu environment) (Source, CI) * Test with native aarch64 supporting CI (Source CI) * only CI: Shippable CI, Drone CI, * Works on ARM (free aarch64 server for open source) (Source, adhoc or CI) For 2nd half, below documents might be helpful for you. * https://github.com/junaruga/fedora-workshop-multiarch * https://github.com/junaruga/ci-multi-arch-test Jun ___ 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: specfile dependecy to pip package
Thank you guys. Regards MT On Thu, Sep 19, 2019 at 3:36 PM Miro Hrončok wrote: > On 19. 09. 19 15:12, Dan Čermák wrote: > > In Fedora 30 there is only Sphinx 1.8.4, so you'll have to patch your > > package to work with an older version of sphinx. > > Or stop building the docs on Fedora 30 and only build it on Fedora 31+. > > -- > 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 > ___ 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: aarch64 test systems implementation
On Thu, 19 Sep 2019 at 06:28, Dave Love wrote: > > Are the aarch64 test systems running on real or emulated hardware? (Is > there a way to tell?) > > I ask because I'm seeing bad numerical results from a test and would > like to know if I can eliminate qemu as a possible cause -- not that I > think that's likely. It depends on what level of emulation you mean. Are you meaning "is it an x86_64 acting like a aarch64?" then the answer is no. If you are meaning "is it an aarch64 guest system on an aarch64" then probably yes... we don't have enough hardware to not use virtualization which does have some emulation at some level. -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: libb2-0.98.1 on Rawhide
libb2-0.98.1 built On 09/09/19 20:09, Felix Schwarz wrote: > > Would you mind pinging me again when the new package is actually built in > rawhide? > > I will run borg's test suite against the new libb2 then. The test suite is > pretty comprehensive so this should be a good indicator if we need to fix > something in borg. > > Felix -- --- Antonio Trande Fedora Project mailto 'sagitter at fedoraproject dot org' GPG key: 0x6e0331dd1699e4d7 GPG key server: https://keys.openpgp.org/ signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Orphaning some packages
Hello, I would like to take-over the pefile. Michal Ambroz -- Původní e-mail -- Od: Othman Madjoudj Komu: Development discussions related to Fedora Datum: 15. 9. 2019 3:11:24 Předmět: Orphaning some packages "Hello, I'm going to orphan the following packages, reason is cited in the parentheses. rpms/moin (1.9 branch is Python2 only, 2.0 branch will support Python3 however no stable yet) rpms/epydoc (no upstream release since 2008) rpms/python-crypto2.1 (was needed in EPEL6 which is EOL) rpms/python-paramiko1.10 (was needed in EPEL6 which is EOL) rpms/python-pybloomfiltermmap (was needed for 3rd party software which I dont use anymore) rpms/python-pefile (idem) rpms/pyftpdlib (idem) Best regards -Othman ___ 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: aarch64 test systems implementation
On 9/19/19 3:27 AM, Dave Love wrote: > Are the aarch64 test systems running on real or emulated hardware? (Is > there a way to tell?) You mean the ones listed at https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers ? If so, they are vm's running on real hardware with kvm. kevin -- > > I ask because I'm seeing bad numerical results from a test and would > like to know if I can eliminate qemu as a possible cause -- not that I > think that's likely. > ___ > 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 > signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: YACBSIPT, rawhide ceph build stuck in bodhi, again
On 9/19/19 5:26 AM, Kaleb Keithley wrote: > Someone with privs please kick it. Thanks > > https://bodhi.fedoraproject.org/updates/FEDORA-2019-995f3ae953 Done. Do note that you can do this too, just untag it from f32-pending and tag it again into f32-pending. And I am again sorry we don't have this fixed... kevin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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 Beta Release Announcement
* John M. Harris, Jr. [17/09/2019 21:27] : > > I can provide a link to the vendor's website when I get home. I'm interested in this. Emmanuel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 32 Self-Contained Change proposal: Django 3
https://fedoraproject.org/wiki/Changes/Django3
== Summary ==
This change is about upgrading {{package|python-django}} to
[https://docs.djangoproject.com/en/3.0/releases/3.0/ version 3.0]. A
compatibility package is not planned (but it is part of the
contingency plan).
== Owner ==
* Name: [[User:churchyard| Miro Hrončok]]
* Email:
* Name: [[User:mrunge| Matthias Runge]]
* Email:
== Detailed Description ==
The {{package|python-django}} package will be updated to 3.0.
Django 3.0 begins the journey to making Django fully async-capable by
providing support for running as an ASGI application.
This is in addition to the existing WSGI support. Django intends to
support both for the foreseeable future. Async features will only be
available to applications that run under ASGI, however.
== Benefit to Fedora ==
Fedora will be able to provide the latest and current release of Django.
== Scope ==
* '''Proposal owners:''' upgrade {{package|python-django}} to 3.0
prerelease as soon as this change is accepted
([https://src.fedoraproject.org/rpms/python-django/pull-request/9 pull
request]).
* '''Django libraries/apps owners:''' Test that your packages work
with Django 3. Update, contact upstream for help. Retire leaf packages
with libraries if not compatible.
* Release engineering: no impact with Release Engineering is anticipated
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)
List of packages directly requiring {{package|python3-django}}:
* {{package|graphite-web}}
* {{package|kobo}}
* {{package|python-django-ajax-selects}}
* {{package|python-django-angular}}
* {{package|python-django-annoying}}
* {{package|python-django-appconf}}
* {{package|python-django-authority}}
* {{package|python-django-babel}}
* {{package|python-django-cacheops}}
* {{package|python-django-compressor}}
* {{package|python-django-contact-form}}
* {{package|python-django-cors-headers}}
* {{package|python-django-database-url}}
* {{package|python-django-debreach}}
* {{package|python-django-debug-toolbar}}
* {{package|python-django-filter}}
* {{package|python-django-formtools}}
* {{package|python-django-haystack}}
* {{package|python-django-helpdesk}}
* {{package|python-django-js-asset}}
* {{package|python-django-jsonfield}}
* {{package|python-django-macros}}
* {{package|python-django-markdownx}}
* {{package|python-django-mptt}}
* {{package|python-django-nose}}
* {{package|python-django-pipeline}}
* {{package|python-django-post_office}}
* {{package|python-django-pyscss}}
* {{package|python-django-pytest}}
* {{package|python-django-redis}}
* {{package|python-django-registration}}
* {{package|python-django-rest-framework}}
* {{package|python-django-rest-framework-composed-permissions}}
* {{package|python-django-reversion}}
* {{package|python-django-robots}}
* {{package|python-django-rq}}
* {{package|python-django-simple-captcha}}
* {{package|python-django-tables2}}
* {{package|python-django-tagging}}
* {{package|python-django-taggit}}
* {{package|python-django-tastypie}}
* {{package|python-django-threadedcomments}}
* {{package|python-django-timezone-field}}
* {{package|python-django-tinymce}}
* {{package|python-djangoql}}
* {{package|python-livereload}}
* {{package|python-pelican}}
* {{package|python-whitenoise}}
* {{package|python3-openid}}
== Upgrade/compatibility impact ==
Eventually removed packages need to be obsoleted.
== How To Test ==
# dnf update python3-django
Test that Fedora packaged Django applications still function as
before, open Bugzillas if they don't.
== User Experience ==
Users using RPM installed Django to develop Django apps might be
affected by this change. We shall recommend either using Python venvs
for users who develop Django apps. See the developer portal, we are
already
[https://developer.fedoraproject.org/tech/languages/python/django-installation.html
recommending that].
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Proposal
owners will introduce a python-django2 compatibility
package if everything goes south.
* Contingency deadline: beta freeze
== Documentation ==
https://docs.djangoproject.com/en/3.0/releases/3.0/
== Release Notes ==
TBD
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://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: Add a rule to have a compose when Fedora branched
On 9/18/19 12:02 AM, Miroslav Suchý wrote: > Dne 17. 09. 19 v 18:28 Kevin Fenzi napsal(a): >> Branching is not just "oh, make a new compose". There's a ton of >> steps/work that happens then, including: >> >> * Making a new branch on all active rpms >> * Switching to a new signing key in rawhide. >> * New pungi-fedora config, new comps, new kickstarts. >> * Setting up new koji tags, etc. > > Is this process documented somewhere (Maitai, UML, jBPM)? I am only > aware of Fedora release schedule. > How many of these actions are triggered automatically and how many of > them has to be started by hand? Releng has scripts for it: https://pagure.io/releng/blob/master/f/scripts/branching and an SOP (although it needs some work): https://docs.pagure.org/releng/sop_mass_branching.html Most of the actions are human run. There's nothing really to trigger off of. If we had time we could possibly roll all of this into a ansible playbook or the like. kevin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Add a rule to have a compose when Fedora branched
On Tue, Sep 17, 2019 at 12:30 PM Kevin Fenzi wrote: > > On 9/17/19 8:04 AM, Miro Hrončok wrote: > > On 17. 09. 19 17:00, jkone...@redhat.com wrote: > >> If that is not doable what about taking last Rawhide compose and mark > >> that as first compose of newly branched Fedora? The only thing I'm > >> asking for is to have a base ground which is not available right now. > > > > That is actually a nice proposal. I wonder whether it is technically > > possible. CCing (hopefully) relevant people. > > It is not. > > Branching is not just "oh, make a new compose". There's a ton of > steps/work that happens then, including: > > * Making a new branch on all active rpms > * Switching to a new signing key in rawhide. > * New pungi-fedora config, new comps, new kickstarts. > * Setting up new koji tags, etc. > > I'm sorry for the delay in a f31 compose this time. ;( > > Here's my suggestions: > > * Make sure branching isn't right after flock. Mohan was traveling and > we were both jetlagged so I think it was harder to watch things. Yeah, I was traveling and on PTO for the first week after branching. > > > * We should leverage rawhide gating in the next branched: Set it up for > gating just like rawhide (this time we didn't) and then actually disable > allowing new builds in until we have a compose. This would hsave saved > us many days of people landing broken stuff we had to sort out. We could > at least get a compose to have to start with. The next compose might get > a pile, but at least we don't have to fight a moving target. > > * somehow figure out the pungi-gather segfaulting issue and fix it. This > doomed several composes. > > * Now that we have composes somewhat faster, we can run 3-4 a day at > least, so that should speed up fixing things. > > * Stop rawhide composes until we have a branched compose. This may not > be needed with the change to make rawhide use 'rawhide' and not the > number, but we should consider it if we don't have a compose to avoid > confusion. I agree with all the suggestions, but as far as I can tell, the issue is because everything happened all at once, pungi-gather segfaulting, python 3.8 landing in rawhide and may be others. "Minimal Compose" which is on my plate for a long time would also help, which will build a image when certain packages gets built. > > > kevin > > ___ > 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 Beta Release Announcement
* Kevin Kofler [19/09/2019 16:12] : > > That could have been prevented by policy, but deliberately was not, because > the people behind Modularity had exactly this (moving random packages to > module-only) as their hidden agenda. I'm quite certain that forbidding people to move to module-only would mean that we would not only not have a Java stack in Fedora but also no Java module too. You can argue that that's a good thing. Mikolaj wouldn't have gotten half the abuse he got for being the last remaining member of the Java SIG and we wouldn't have crazy conspiracies accussing people of moving packages to module-only because $REASON but having a Java module is better than not having one. Emmanuel ___ 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 compose report: 20190919.n.1 changes
OLD: Fedora-31-20190918.n.0 NEW: Fedora-31-20190919.n.1 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 6 Dropped packages:0 Upgraded packages: 44 Downgraded packages: 0 Size of added packages: 1.70 MiB Size of dropped packages:0 B Size of upgraded packages: 2.40 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 219.03 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = Package: gnome-firmware-3.34.0-4.fc31 Summary: Install firmware on devices RPMs:gnome-firmware Size:269.29 KiB Package: gnome-shell-extension-appindicator-30-7.fc31 Summary: AppIndicator/KStatusNotifierItem support for GNOME Shell RPMs:gnome-shell-extension-appindicator Size:29.42 KiB Package: gthree-0.2.0-2.fc31 Summary: Gthree is a GObject/Gtk+ port of three.js RPMs:gthree gthree-devel Size:1.11 MiB Package: mate-optimus-19.10.4-1.fc31 Summary: NVIDIA Optimus GPU switcher RPMs:mate-optimus Size:26.92 KiB Package: python-listparser-0.18-3.fc31 Summary: Parse OPML, FOAF, and iGoogle subscription lists RPMs:python-listparser-doc python3-listparser Size:208.53 KiB Package: video-downloader-0.1.5-6.fc31 Summary: Download videos from websites like YouTube and many others RPMs:video-downloader Size:65.66 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: atril-1.22.2-1.fc31 Old package: atril-1.22.1-2.fc31 Summary: Document viewer RPMs: atril atril-caja atril-devel atril-libs atril-thumbnailer Size: 9.09 MiB Size change: 121.50 KiB Changelog: * Wed Sep 18 2019 Wolfgang Ulbrich - 1.22.2-1 - update to 1.22.2 Package: caja-1.22.2-1.fc31 Old package: caja-1.22.1-2.fc31 Summary: File manager for MATE RPMs: caja caja-core-extensions caja-devel caja-schemas Size: 21.56 MiB Size change: 96.27 KiB Changelog: * Wed Sep 18 2019 Wolfgang Ulbrich - 1.22.2-1 - update to 1.22.2 Package: caja-extensions-1.22.1-1.fc31 Old package: caja-extensions-1.22.0-2.fc31 Summary: Set of extensions for caja file manager RPMs: caja-beesu caja-extensions-common caja-image-converter caja-open-terminal caja-sendto caja-sendto-devel caja-share caja-wallpaper caja-xattr-tags Size: 1.21 MiB Size change: -7.36 KiB Changelog: * Wed Sep 18 2019 Wolfgang Ulbrich - 1.22.1-1 - update to 1.22.1 Package: cinnamon-4.2.4-2.fc31 Old package: cinnamon-4.2.3-2.fc31 Summary: Window management and application launching for GNOME RPMs: cinnamon cinnamon-devel-doc Size: 8.38 MiB Size change: -1.62 KiB Changelog: * Wed Sep 04 2019 Leigh Scott - 4.2.4-1 - Update to 4.2.4 release * Sat Sep 14 2019 Leigh Scott - 4.2.4-2 - Fix cinnamon-settings default issue (rhbz#1752134) Package: crun-0.9.1-1.fc31 Old package: crun-0.8-1.fc31 Summary: OCI runtime written in C RPMs: crun Size: 622.01 KiB Size change: 17.48 KiB Changelog: * Mon Sep 09 2019 Dan Walsh - 0.8-2 - Add provides oci-runtime * Tue Sep 10 2019 Jindrich Novy - 0.8-3 - Add versioned oci-runtime provide. * Wed Sep 11 2019 Giuseppe Scrivano - 0.9-1 - built version 0.9 * Fri Sep 13 2019 Giuseppe Scrivano - 0.9.1-1 - built version 0.9.1 Package: cups-1:2.2.12-2.fc31 Old package: cups-1:2.2.12-1.fc31 Summary: CUPS printing system RPMs: cups cups-client cups-devel cups-filesystem cups-ipptool cups-libs cups-lpd Size: 38.14 MiB Size change: 1.67 KiB Changelog: * Fri Sep 13 2019 Zdenek Dohnal - 1:2.2.12-2 - fix cupsctl usage Package: drawing-0.4.4-1.fc31 Old package: drawing-0.4.2-1.fc31 Summary: Drawing application for the GNOME desktop RPMs: drawing Size: 1.15 MiB Size change: 6.03 KiB Changelog: * Wed Sep 04 2019 Artem Polishchuk - 0.4.3-1 - Update to 0.4.3 * Tue Sep 10 2019 Artem Polishchuk - 0.4.4-1 - Update to 0.4.4 Package: engrampa-1.22.2-1.fc31 Old package: engrampa-1.22.1-2.fc31 Summary: MATE Desktop file archiver RPMs: engrampa Size: 6.54 MiB Size change: 64.96 KiB Changelog: * Wed Sep 18 2019 Wolfgang Ulbrich - 1.22.2-1 - update to 1.22.2 Package: eom-1.22.2-1.fc31 Old package: eom-1.22.1-2.fc31 Summary: Eye of MATE image viewer RPMs: eom eom-devel Size: 11.93 MiB Size change: 96.84 KiB Changelog: * Fri Sep 06 2019 Nikola Forr?? - 1.22.1-3 - rebuilt for exempi 2.5.1 * Wed Sep 18 2019 Wolfgang Ulbrich - 1.22.2-1 - update to 1.22.2 Package: flat-remix-icon-theme-0.0.20190908-3.fc31 Old package: flat-remix-icon-theme-0.0.20190413-2.fc31 Summary: Icon theme inspired on material design RPMs: flat-remix-icon-theme Size: 18.82 MiB Size change: 1.01 MiB Changelog: * Fri Sep 13 2019 Artem Polishchuk - 0.0.20190908-3 - Update to 20190908
Fedora-31-20190919.n.1 compose check report
No missing expected images. Failed openQA tests: 6/152 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-31-20190918.n.0): ID: 454715 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/454715 ID: 454727 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/454727 ID: 454728 Test: x86_64 Silverblue-dvd_ostree-iso desktop_background URL: https://openqa.fedoraproject.org/tests/454728 ID: 454781 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/454781 Old failures (same test failed in Fedora-31-20190918.n.0): ID: 454679 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/454679 ID: 454717 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/454717 ID: 454720 Test: x86_64 Silverblue-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/454720 Soft failed openQA tests: 2/152 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-31-20190918.n.0): ID: 454695 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/454695 ID: 454792 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/454792 Passed openQA tests: 144/152 (x86_64) New passes (same test not passed in Fedora-31-20190918.n.0): ID: 454673 Test: x86_64 Server-dvd-iso realmd_join_sssd URL: https://openqa.fedoraproject.org/tests/454673 ID: 454677 Test: x86_64 Server-dvd-iso server_remote_logging_server URL: https://openqa.fedoraproject.org/tests/454677 ID: 454678 Test: x86_64 Server-dvd-iso server_remote_logging_client URL: https://openqa.fedoraproject.org/tests/454678 ID: 454711 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/454711 Skipped non-gating openQA tests: 1 of 154 Installed system changes in test x86_64 Workstation-live-iso install_default_upload: 1 packages(s) added since previous compose: conmon System load changed from 0.72 to 0.29 Previous test data: https://openqa.fedoraproject.org/tests/453343#downloads Current test data: https://openqa.fedoraproject.org/tests/454687#downloads Installed system changes in test x86_64 Workstation-live-iso install_default@uefi: Used mem changed from 827 MiB to 948 MiB 1 packages(s) added since previous compose: conmon 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.23 to 0.66 Previous test data: https://openqa.fedoraproject.org/tests/453345#downloads Current test data: https://openqa.fedoraproject.org/tests/454689#downloads Installed system changes in test x86_64 KDE-live-iso install_default_upload: Used mem changed from 721 MiB to 883 MiB 1 services(s) added since previous compose: dbus-:1.6-org.freedesktop.problems@0.service loaded active running dbus-:1.6-org.freedesktop.problems@0.service 2 services(s) removed since previous compose: dbus-:1.7-org.freedesktop.problems@0.service loaded active running dbus-:1.7-org.freedesktop.problems@0.service, pcscd.service System load changed from 1.38 to 0.52 Average CPU usage changed from 74.45714286 to 15.31904762 Previous test data: https://openqa.fedoraproject.org/tests/453358#downloads Current test data: https://openqa.fedoraproject.org/tests/454702#downloads Installed system changes in test x86_64 KDE-live-iso install_default@uefi: Used mem changed from 748 MiB to 894 MiB 1 services(s) added since previous compose: dbus-:1.6-org.freedesktop.problems@0.service loaded active running dbus-:1.6-org.freedesktop.problems@0.service 1 services(s) removed since previous compose: dbus-:1.7-org.freedesktop.problems@0.service loaded active running dbus-:1.7-org.freedesktop.problems@0.service System load changed from 0.48 to 0.64 Previous test data: https://openqa.fedoraproject.org/tests/453360#downloads Current test data: https://openqa.fedoraproject.org/tests/454704#downloads Installed system changes in test x86_64 Silverblue-dvd_ostree-iso install_default_upload: System load changed from 0.78 to 0.45 Previous test data: https://openqa.fedoraproject.org/tests/453375#downloads Current test data: https://openqa.fe
Re: No More i686 Kernels, No i686 Repositories
On Mon, Sep 16, 2019 at 03:19:38PM -0500, Bruno Wolff III wrote: > On Mon, Sep 16, 2019 at 13:15:08 -0700, > You can crossgrade using dnf. I wrote about it a few weeks ago. The > process worked pretty smoothly for me. Maybe worth a Fedora Magazine article (with a "not supported" disclaimer)? -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora in GNOME Online Accountes
On Thu, Sep 19, 2019 at 09:42:04AM -0500, Michael Catanzaro wrote: > So with help from Rishi, we got it working by: > * Adding a config file [1] into the container. > * Poking a hole in the flatpak sandbox [2], though this is clearly a > nasty hack. > I think this will do for now, though improvements would be good Nasty hack and all, this is really cool! Thanks everyone for working to make this happen! -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Add a rule to have a compose when Fedora branched
On 9/18/19 1:41 AM, jkone...@redhat.com wrote: > Hi Kevin, > Thanks for the explanation. See my comments below. ...snip... >> * Stop rawhide composes until we have a branched compose. This may >> not >> be needed with the change to make rawhide use 'rawhide' and not the >> number, but we should consider it if we don't have a compose to avoid >> confusion. > > Where should I signed this? :) > > But now for real, from my understanding you are basically proposing > improved version of what Miro mentioned somewhere here in the thread. > That means make freeze after branching. I definitely agree on that. Well, I was not saying we should go into Beta freeze immediately and stay in it until Beta is out. I was just saying we should have a temporary freeze right after branching until we have a completed branched compose. Then we can open things up again until Beta freeze. > Aside of that you are suggesting Rawhide should freeze too before the > branched Fedora has a compose. Not sure if that would really help > because if the Rawhide will *unfreeze* the same date as when the > branched Fedora have first compose then we don't have a time to react. Well, I am not sure we need to stop rawhide until we have a branched compose. This time it would have helped because mirrormanager pointed all the branched repos to rawhide since there was no branched, so it caused a lot of confusion. if we can land the change to make rawhide use 'rawhide' as it's version, it would avoid this confusion, as people wanted to switch to branched would need to explicitly sync to it (which means it has to exist). > In my F31 case most importantly copr will be in similar situation that > they will use Rawhide *new* compose (if they won't be really fast) > instead of the old one for a new Fedora chroot. And I don't think we > want to add some lag between the successful Fedora compose and the > Rawhide one. I'm not sure what you mean here, can you expand on it or provide an example? > > Other than this one point I agree with what you just wrote. > > Jirka kevin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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 Beta Release Announcement
Randy Barlow wrote: > It is a disservice to our users to provide them with unmaintained > packages, It is a disservice to our users to NOT provide them with unmaintained packages. If, as a user, you NEED a package, you would rather have it present but unmaintained than not have it at all! Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 Beta Release Announcement
On Thu, 19 Sep 2019 at 16:46, Emmanuel Seyman wrote: > > * Kevin Kofler [19/09/2019 16:12] : > > > > That could have been prevented by policy, but deliberately was not, because > > the people behind Modularity had exactly this (moving random packages to > > module-only) as their hidden agenda. > > I'm quite certain that forbidding people to move to module-only would mean > that we would not only not have a Java stack in Fedora but also no Java > module too. > > You can argue that that's a good thing. Mikolaj wouldn't have gotten half > the abuse he got for being the last remaining member of the Java SIG and > we wouldn't have crazy conspiracies accussing people of moving packages > to module-only because $REASON but having a Java module is better than > not having one. > That is not taking all of Kevin's proposal. In his proposal, that would just mean that whatever last working version of Java would stay there until the end of time. If it stopped compiling on updates, then the last version which did stays in Fedora until provably broken. He might also say that Java is a curse and if it went away.. that would just mean people would go back to coding in C++ as they should. However that is speculation on my part. -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: No More i686 Kernels, No i686 Repositories
That wouldn't work, as the systems do not support 64 bit. On September 19, 2019 8:59:55 PM UTC, Matthew Miller wrote: >On Mon, Sep 16, 2019 at 03:19:38PM -0500, Bruno Wolff III wrote: >> On Mon, Sep 16, 2019 at 13:15:08 -0700, >> You can crossgrade using dnf. I wrote about it a few weeks ago. The >> process worked pretty smoothly for me. > >Maybe worth a Fedora Magazine article (with a "not supported" >disclaimer)? > >-- >Matthew Miller > >Fedora Project Leader >___ >devel mailing list -- devel@lists.fedoraproject.org >To unsubscribe send an email to devel-le...@lists.fedoraproject.org >Fedora Code of Conduct: >https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >List Archives: >https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Sent from my mobile device. Please excuse my brevity.___ 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: Add a rule to have a compose when Fedora branched
On 19. 09. 19 23:29, Kevin Fenzi wrote: * Stop rawhide composes until we have a branched compose. This may not be needed with the change to make rawhide use 'rawhide' and not the number, but we should consider it if we don't have a compose to avoid confusion. Where should I signed this?:) But now for real, from my understanding you are basically proposing improved version of what Miro mentioned somewhere here in the thread. That means make freeze after branching. I definitely agree on that. Well, I was not saying we should go into Beta freeze immediately and stay in it until Beta is out. I was just saying we should have a temporary freeze right after branching until we have a completed branched compose. Then we can open things up again until Beta freeze. To clarify: That's exactly what I meant. -- 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: Fedora 31 Beta Release Announcement
We had Java in Fedora long before modules, but not having a Java module would certainly be the case in that scenario, and that'd be fine. We've been able to install multiple different Java versions on the same Fedora install for some time now, something which is not possible with modules. On September 19, 2019 8:45:39 PM UTC, Emmanuel Seyman wrote: >* Kevin Kofler [19/09/2019 16:12] : >> >> That could have been prevented by policy, but deliberately was not, >because >> the people behind Modularity had exactly this (moving random packages >to >> module-only) as their hidden agenda. > >I'm quite certain that forbidding people to move to module-only would >mean >that we would not only not have a Java stack in Fedora but also no Java >module too. > >You can argue that that's a good thing. Mikolaj wouldn't have gotten >half >the abuse he got for being the last remaining member of the Java SIG >and >we wouldn't have crazy conspiracies accussing people of moving packages >to module-only because $REASON but having a Java module is better than >not having one. > >Emmanuel >___ >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 -- Sent from my mobile device. Please excuse my brevity.___ 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: YACBSIPT, rawhide ceph build stuck in bodhi, again
On Thu, Sep 19, 2019 at 2:18 PM Kevin Fenzi wrote: > On 9/19/19 5:26 AM, Kaleb Keithley wrote: > > Someone with privs please kick it. Thanks > > > > https://bodhi.fedoraproject.org/updates/FEDORA-2019-995f3ae953 > > Done. Do note that you can do this too, just untag it from f32-pending > and tag it again into f32-pending. > Okay, cool. I wish someone had told me sooner, I'd have stopped bothering people for this. :-) Thanks -- Kaleb ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Updating double-conversion in rawhide
I'll be updating double-coversion in rawhide soon. This involves a soname bump, but there are very few deps and I'll be rebuilding those. I did a test build here: https://copr.fedorainfracloud.org/coprs/orion/double-conversion/builds/ and found no issues related to the update. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 Beta Release Announcement
Once upon a time, Kevin Kofler said: > Randy Barlow wrote: > > It is a disservice to our users to provide them with unmaintained > > packages, > > It is a disservice to our users to NOT provide them with unmaintained > packages. If, as a user, you NEED a package, you would rather have it > present but unmaintained than not have it at all! I disagree. A lot of users don't really understand the nature of free software, distributions, etc. If they install Fedora and an unmaintained package doesn't work for them, they tend to blame Fedora and look at other distributions (or blame Linux and go back to Windows or Mac). Maybe eventually they realize the particular application is crap and circle back to Fedora, but they often don't. A distribution is not supposed to be just a big dump of software, hopefully some of it working (like the early days of Linux where everybody just uploaded their programs to a few big FTP sites); it's supposed to be a system of things that are usable. Even if someone does try to work with Fedora on a broken application, who is going to get the bug reports? Who is going to respond? No response still looks bad to the average user. -- Chris Adams ___ 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 Beta Release Announcement
On 9/19/19 7:12 AM, Kevin Kofler wrote: It is absolutely not realistic to expect all end users to become package maintainers. Sure, isn't it also unrealistic to expect to receive a massive library of software and contribute nothing in return? Do you have an inherent right to the product of the work that other people do to fulfill their own needs? Free Software requires participation. You've complained that Fedora has become about dropping things, but those "things" don't exist unless someone makes them. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 Beta Release Announcement
On Thu, 2019-09-19 at 20:36 -0700, Gordon Messmer wrote: > On 9/19/19 7:12 AM, Kevin Kofler wrote: > > It is absolutely not realistic to expect all end users to become package > > maintainers. > > Sure, isn't it also unrealistic to expect to receive a massive library > of software and contribute nothing in return? Do you have an inherent > right to the product of the work that other people do to fulfill their > own needs? Free Software requires participation. > > You've complained that Fedora has become about dropping things, but > those "things" don't exist unless someone makes them. Please note, I'm not sure if you're aware, but it's certainly not the case that Kevin "contribute[s] nothing in return". He's worked on Fedora packaging, especially around KDE, for many years. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 Beta Release Announcement
On 9/19/19 9:28 PM, Adam Williamson wrote: Please note, I'm not sure if you're aware, but it's certainly not the case that Kevin "contribute[s] nothing in return". He's worked on Fedora packaging, especially around KDE, for many years. I was thinking about users in general, in response to Kevin's statement, and not about Kevin himself. But I'll also note that I thought I saved that message to think about a while before I sent it. I'm very tired today, and I know my judgement is off. So, I apologize. ___ 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 Beta Release Announcement
On Thu, 2019-09-19 at 21:56 -0700, Gordon Messmer wrote: > On 9/19/19 9:28 PM, Adam Williamson wrote: > > Please note, I'm not sure if you're aware, but it's certainly not the > > case that Kevin "contribute[s] nothing in return". He's worked on > > Fedora packaging, especially around KDE, for many years. > > I was thinking about users in general, in response to Kevin's statement, > and not about Kevin himself. > > But I'll also note that I thought I saved that message to think about a > while before I sent it. I'm very tired today, and I know my judgement > is off. So, I apologize. No worries, I wasn't sure which way your mail was intended to be read so I just wanted to make sure you knew :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
