Re: swap on ZRAM, zswap, and Rust was: Better interactivity in low-memory situations
On Wed, Sep 18, 2019 at 6:57 PM Tom Seewald wrote: > > Hi Chris, > > Does zswap actually keep the data compressed when the DRAM-based swap is > full, and it writes to the spill-over non-volatile swap device? > > I'm not an expert on this at all, however my understanding was that zswap > must decompress the data before it writes to the backing swap. But perhaps I > am misunderstanding the purpose of zswap_writeback_entry()[1] and/or what it > does. > > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/zswap.c#n828 I don't know. But based on the tests I mention upthread, I'm not sure how uncompressed pages are being swapped to disk. But then those times don't account for even a 2:1 compression ratio, which is the best that zbud/lz4 can achieve. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: swap on ZRAM, zswap, and Rust was: Better interactivity in low-memory situations
Hi Chris, Does zswap actually keep the data compressed when the DRAM-based swap is full, and it writes to the spill-over non-volatile swap device? I'm not an expert on this at all, however my understanding was that zswap must decompress the data before it writes to the backing swap. But perhaps I am misunderstanding the purpose of zswap_writeback_entry()[1] and/or what it does. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/zswap.c#n828 ___ 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: swap on ZRAM, zswap, and Rust was: Better interactivity in low-memory situations
Zbyszek, Do you have any advice on how to assess 'swap on ZRAM' versus 'zswap' by default for Fedora Workstation? They're really too similar from a user point of view, I think it really comes down to the technical arguments. 1a. 'swap on ZRAM' compresses only that which goes to the ZRAM device 1b. zswap compresses everything whether it goes to the memory pool or swap on disk. 2a. 'swap on ZRAM' must be configured to give priority to the ZRAM device; once full, disk swap (if present) is used 2b. zswap anticipates the future usage of data, favoring the memory or disk swap locations accordingly They both appear equally easy to enable by default for clean installs and upgrades. I'd say 'swap on ZRAM' is well suited for the cases where there's no existing swap partition, and low memory devices. Whereas zswap is better suited for average to higher end systems, where the main goal is swap avoidance, but where zswap can help moderate the worst performance effects of the transition to disk based swap. It seems premature to drop the creation of a swap partition at installation time. I think that'd be unexpected by most users. And might have some consequences other than (unsupported) hibernation use case. So my assessment, at this point, would be to recommend zswap for Fedora Workstation. Likely using zbud/lz4. Maybe by Fedora 33 there will be more confidence and testing done on z3fold. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Please test varnish-6.0.4-2.fc29
I just submitted a Bodhi update for varnish-6.0.4-2.fc29, [ https://bodhi.fedoraproject.org/updates/FEDORA-2019-8a85a90af6 | https://bodhi.fedoraproject.org/updates/FEDORA-2019-8a85a90af6 ] It fixes a medium risk security update, VSV3 aka CVE-2019-15892. Please test and add karma. br, Ingvar Hagelund ___ 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-20190918.n.2 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 4 of 45 required tests failed, 2 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: 16/152 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-Rawhide-20190916.n.0): ID: 453757 Test: x86_64 KDE-live-iso install_no_user **GATING** URL: https://openqa.fedoraproject.org/tests/453757 ID: 453844 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/453844 Old failures (same test failed in Fedora-Rawhide-20190916.n.0): ID: 453720 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller **GATING** URL: https://openqa.fedoraproject.org/tests/453720 ID: 453721 Test: x86_64 Server-dvd-iso server_freeipa_replication_master URL: https://openqa.fedoraproject.org/tests/453721 ID: 453722 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/453722 ID: 453723 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart **GATING** URL: https://openqa.fedoraproject.org/tests/453723 ID: 453725 Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING** URL: https://openqa.fedoraproject.org/tests/453725 ID: 453726 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/453726 ID: 453731 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/453731 ID: 453735 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/453735 ID: 453753 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/453753 ID: 453763 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/453763 ID: 453768 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/453768 ID: 453769 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/453769 ID: 453772 Test: x86_64 Silverblue-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/453772 ID: 453835 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/453835 ID: 453836 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/453836 Soft failed openQA tests: 4/152 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-Rawhide-20190916.n.0): ID: 453807 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/453807 Old soft failures (same test soft failed in Fedora-Rawhide-20190916.n.0): ID: 453747 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/453747 ID: 453837 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/453837 ID: 453839 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/453839 Passed openQA tests: 132/152 (x86_64) New passes (same test not passed in Fedora-Rawhide-20190916.n.0): ID: 453767 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/453767 ID: 453781 Test: x86_64 universal install_mirrorlist_graphical URL: https://openqa.fedoraproject.org/tests/453781 ID: 453806 Test: x86_64 universal install_delete_partial URL: https://openqa.fedoraproject.org/tests/453806 ID: 453842 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/453842 ID: 453843 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/453843 Skipped non-gating openQA tests: 1 of 154 Installed system changes in test x86_64 Workstation-live-iso install_default_upload: 1 packages(s) removed since previous compose: conmon System load changed from 0.63 to 0.34 Previous test data: https://openqa.fedoraproject.org/tests/451470#downloads Current test data: https://openqa.fedoraproject.org/tests/453739#downloads Installed system changes in test x86_64 Workstation-live-iso install_default@uefi: 1 packages(s) removed since previous compose: conmon 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.5-org.freedesktop.problems@0.service
Re: Fedora 31 Beta Release Announcement
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. >> * 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.) > 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? > 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. > 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 getting an unreasonable "plan" with a totally insufficient transition period rubber-stamped by FESCo, dropping random leaf packages they hoped nobody would notice (when actually, those leaf packages are the whole reason we need the compatibility stack to begin with; the leaf packages are what the users actually use and need!), ignoring all feedback (at least all that did not just blindly agree with their nonsense "plan"), "fixing" "bugs" (typically just removing Python 2 support from random packages in the hope nobody would notice), etc., etc., etc. See qt (4) and kdelibs (4), and qt3 and kdelibs3, for how compatibility should work. > So sorry, but you can't expect every obsolete hardware technology and > software stack from previous decade gets to hold everyone else hostage. Compatibility is not "holding" anyone "hostage". Nobody is forced to use old hardware or compatibility libraries. The unilateral removal of such "obsolete" technologies is what is holding users hostage. 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: [EXT] Re: [Test-Announce] Fedora 31 Beta Release Announcement
I want to keep "old" stuff in, because there's no reason to drop the support for systems that we already support, if we can do so without breaking anything. On September 18, 2019 7:07:30 PM UTC, "Anderson, Charles R" wrote: >So, not only do you want to keep "old" stuff in Fedora (i686), but now >you want to revert/remove "new" stuff (modules) too? I'm beginning to >think that Fedora just isn't a good fit for you. > >On Wed, Sep 18, 2019 at 06:22:52PM +, John M. Harris, Jr. wrote: >> Removing modules is a potential solution to this, as it would >simplify package management. >> >> On September 18, 2019 8:29:49 AM UTC, Petr Pisar >wrote: >> >On 2019-09-18, Ralf Corsepius wrote: >> >> Error: >> >> Problem 1: package crypto-utils-2.5-4.fc29.x86_64 requires >> >> libperl.so.5.28()(64bit), but none of the providers an be >installed >> >>- package crypto-utils-2.5-4.fc29.x86_64 requires >> >> perl(:MODULE_COMPAT_5.28.0), but none of the providers can be >> >installed >> >>- perl-libs-4:5.28.2-439.fc30.x86_64 does not belong to a >> >distupgrade >> >> repository >> > >> >crypto-utils has not been rebuilt against Perl 5.30 because the >package >> >fails to build for an unrelated reason and was retired (bug >#1674777) >> >and obsoleted in fedora-obsolete-packages-31-31 that is in >> >updates-testing now. Enabling updates-testing repository or waiting >> >a bit for the stabilization should help you. >> > >> >>- problem with installed package crypto-utils-2.5-4.fc29.x86_64 >> >>- package >perl-libs-4:5.28.2-439.module_f31+6019+b24e098f.x86_64 >> >is >> >> excluded >> > >> >Funnily DNF finds out that you could actually get that package >> >satisfied >> >if you enabled a modular Perl. Unfortunatelly DNF does not report >what >> >module stream the modular perl-libs packages comes from. There is >> >indeed >> >some room for improvement. DNF could start recommending "maybe you >> >wanted >> >to enable perl:5.28 stream?" :) >> > >> >-- 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 -- 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
Renewing the Modularity objective
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
Re: [EXT] Re: [Test-Announce] Fedora 31 Beta Release Announcement
So, not only do you want to keep "old" stuff in Fedora (i686), but now you want to revert/remove "new" stuff (modules) too? I'm beginning to think that Fedora just isn't a good fit for you. On Wed, Sep 18, 2019 at 06:22:52PM +, John M. Harris, Jr. wrote: > Removing modules is a potential solution to this, as it would simplify > package management. > > On September 18, 2019 8:29:49 AM UTC, Petr Pisar wrote: > >On 2019-09-18, Ralf Corsepius wrote: > >> Error: > >> Problem 1: package crypto-utils-2.5-4.fc29.x86_64 requires > >> libperl.so.5.28()(64bit), but none of the providers an be installed > >>- package crypto-utils-2.5-4.fc29.x86_64 requires > >> perl(:MODULE_COMPAT_5.28.0), but none of the providers can be > >installed > >>- perl-libs-4:5.28.2-439.fc30.x86_64 does not belong to a > >distupgrade > >> repository > > > >crypto-utils has not been rebuilt against Perl 5.30 because the package > >fails to build for an unrelated reason and was retired (bug #1674777) > >and obsoleted in fedora-obsolete-packages-31-31 that is in > >updates-testing now. Enabling updates-testing repository or waiting > >a bit for the stabilization should help you. > > > >>- problem with installed package crypto-utils-2.5-4.fc29.x86_64 > >>- package perl-libs-4:5.28.2-439.module_f31+6019+b24e098f.x86_64 > >is > >> excluded > > > >Funnily DNF finds out that you could actually get that package > >satisfied > >if you enabled a modular Perl. Unfortunatelly DNF does not report what > >module stream the modular perl-libs packages comes from. There is > >indeed > >some room for improvement. DNF could start recommending "maybe you > >wanted > >to enable perl:5.28 stream?" :) > > > >-- 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: Fedora 31 Beta Release Announcement
On 9/18/19 1:38 PM, John M. Harris, Jr. wrote: Thank you for this link, looks like there's not a lot of issues, and most are closed. Don't assume closed = fixed. You'll see some of them are closed due to lack of input from the reporter and some are closed due to being reported against EOL versions of Fedora. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 Beta Release Announcement
On Wed, 18 Sep 2019 at 14:32, John M. Harris, Jr. wrote: > > These "obsolete" stacks you refer to can easily coexist with newer software, > or newer hardware. They currently do, for example. I really don't understand > why there is so much hostility against anything perceived as being old here. > Because people have different takes on what 'First' means. To the set of packagers/developers 'who are hostile' it means working on the cutting edge to bleeding edge software and not having to spend time on things which are old. If they wanted to work on older stuff they would do so in CentOS/RHEL/Debian space. This really isn't a new thing. We have had some version of this conversation even back when Fedora was Red Hat Linux and people wanted to know why Red Hat had dropped something which had worked perfectly well in 4.2 for some newer thing they didn't want. This is my last email on this because we have pretty much said everything once again. -- 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
Retiring u2f-hidraw-policy soon!
u2f-hidraw-policy is obsoleted by an upstream systemd change. Thanks to the systemd people for doing this! I have asked systemd to obsolete u2f-hidraw-policy in all branches when they apply the update: https://bugzilla.redhat.com/show_bug.cgi?id=1753381 and I'll be retiring u2f-hidraw-policy in rawhide soon. 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. Enjoy your new u2f devices with wider Linux support! ___ 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
Thank you for this link, looks like there's not a lot of issues, and most are closed. On September 18, 2019 4:59:33 PM UTC, Michael Cronenworth wrote: >On 9/17/19 7:01 PM, John M. Harris, Jr. wrote: >> The thing is, i686 still works. The kernel still builds as well, >without issue. I >> have no idea what the issues that have been mentioned are, and I've >kept asking. >> Nobody has given me an answer. Nobody has pointed me to an issue, or >I'd be >> working on that in my free time. > >https://bugzilla.redhat.com/show_bug.cgi?id=1489998 >___ >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: Fedora 31 Beta Release Announcement
These "obsolete" stacks you refer to can easily coexist with newer software, or newer hardware. They currently do, for example. I really don't understand why there is so much hostility against anything perceived as being old here. On September 18, 2019 10:24:31 AM UTC, "Zbigniew Jędrzejewski-Szmek" wrote: >On Wed, Sep 18, 2019 at 11:56:49AM +0200, Kevin Kofler wrote: >> John M. Harris, Jr. wrote: >> > These are generic servers. I can provide a link to the vendor's >website >> > when I get home. It is not Dell, Lenovo or similar, those are >currently >> > selling mostly x86_64. Additionally, many users don't want to buy a >new >> > computer just because a software project made the decision to >randomly >> > drop support for their architecture. I am certainly one of those. >The >> > hardware is fine, perfect working condition. I don't understand why >we >> > should simply turn these to e-waste because somebody flipped the >> > proverbial switch. > >Hi Kevin, > >you are not being fair in this assessment. Going point by point: > >> * dropping, in short succession, of the i686 kernel, the i686 images, >and >> then even the i686 repositories even though there are legitimate >use cases >> for them on an x86_64 kernel (e.g., building multilib packages), > >So... building multilib packages is still very much supported. You >cannot >*run* a pure-i686 environment, but you can 32 bit development. > >> * 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. > >> * the reenforcement of the mass-retirement procedures and the >resulting >> aggressive mass-retirement of hundreds of FTBFS or orphaned >packages, with >> no regards to why (or even if, in the latter case) they fail to >build, >> whether they still work, how essential they are, nor what or how >many >> other packages (including essential ones) depend on them, > >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. > >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. > >> * the unprecedentedly aggressive removal of Python 2 and anything >remotely >> related to it, where useful packages can arbitrarily be vetoed by >> committee (see e.g. https://pagure.io/fesco/issue/2223 ). > >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. > >So sorry, but you can't expect every obsolete hardware technology and >software stack from previous decade gets to hold everyone else hostage. > >Zbyszek >___ >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: Fedora 31 Beta Release Announcement
Agreed, especially when there is little to no call for such a thing. For example, Python 2 and Python 3 can and do coexist. i686 builds can coexist with x86_64 builds. On September 18, 2019 9:56:49 AM UTC, Kevin Kofler wrote: >John M. Harris, Jr. wrote: >> These are generic servers. I can provide a link to the vendor's >website >> when I get home. It is not Dell, Lenovo or similar, those are >currently >> selling mostly x86_64. Additionally, many users don't want to buy a >new >> computer just because a software project made the decision to >randomly >> drop support for their architecture. I am certainly one of those. The >> hardware is fine, perfect working condition. I don't understand why >we >> should simply turn these to e-waste because somebody flipped the >> proverbial switch. > >Unfortunately, Fedora has lately become mainly about randomly dropping >support for things: >* dropping, in short succession, of the i686 kernel, the i686 images, >and >then even the i686 repositories even though there are legitimate use >cases > for them on an x86_64 kernel (e.g., building multilib packages), >* 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, >* the reenforcement of the mass-retirement procedures and the resulting >aggressive mass-retirement of hundreds of FTBFS or orphaned packages, >with > no regards to why (or even if, in the latter case) they fail to build, > whether they still work, how essential they are, nor what or how many > other packages (including essential ones) depend on them, >* the unprecedentedly aggressive removal of Python 2 and anything >remotely > related to it, where useful packages can arbitrarily be vetoed by > committee (see e.g. https://pagure.io/fesco/issue/2223 ). > >All these are moves which are leaving, will leave, or would leave >thousands >of users in the cold when and if they have been, are, will be, or would >be >implemented. > >I miss the times when Fedora was still an inclusive project, focused on > >adding things rather than on removing them. > >Each time you drop an architecture (e.g. i686), a subset of an >architecture >(e.g. pre-AVX2 x86_64), or one or more packages, you are excluding >dozens, >hundreds, thousands, or even millions of users. Removing things is >actively >harmful to Fedora. > >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 -- 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: [Test-Announce] Fedora 31 Beta Release Announcement
Removing modules is a potential solution to this, as it would simplify package management. On September 18, 2019 8:29:49 AM UTC, Petr Pisar wrote: >On 2019-09-18, Ralf Corsepius wrote: >> Error: >> Problem 1: package crypto-utils-2.5-4.fc29.x86_64 requires >> libperl.so.5.28()(64bit), but none of the providers can be installed >>- package crypto-utils-2.5-4.fc29.x86_64 requires >> perl(:MODULE_COMPAT_5.28.0), but none of the providers can be >installed >>- perl-libs-4:5.28.2-439.fc30.x86_64 does not belong to a >distupgrade >> repository > >crypto-utils has not been rebuilt against Perl 5.30 because the package >fails to build for an unrelated reason and was retired (bug #1674777) >and obsoleted in fedora-obsolete-packages-31-31 that is in >updates-testing now. Enabling updates-testing repository or waiting >a bit for the stabilization should help you. > >>- problem with installed package crypto-utils-2.5-4.fc29.x86_64 >>- package perl-libs-4:5.28.2-439.module_f31+6019+b24e098f.x86_64 >is >> excluded > >Funnily DNF finds out that you could actually get that package >satisfied >if you enabled a modular Perl. Unfortunatelly DNF does not report what >module stream the modular perl-libs packages comes from. There is >indeed >some room for improvement. DNF could start recommending "maybe you >wanted >to enable perl:5.28 stream?" :) > >-- 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 -- 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: Fedora in GNOME Online Accountes
Hey, Speaking as someone who understands a little bit of all the pieces involved here, but without claiming to be an expert in anything ... I would expect Flatpak containers to consume Kerberos in roughly the same way as Toolbox [1] containers do. First, the host must be configured to use KCM credential caches [2]. That's been the case since Fedora 27. The container should similarly be configured to use KCM. Then you bind mount the KCM socket into the container, and things (eg., klist, kinit, other libkrb5 consumers, etc.) should work. On Fedora, you can see the path to the socket with: $ systemctl show --value --property Listen sssd-kcm.socket There's also libkrb5 API to do the same. The socket usually lives at /var/run/.heim_org.h5l.kcm-socket Now, since this is Flatpak, we may eventually want to have a desktop portal to gate access to the socket instead of giving the application blanket access. I vaguely recall these old mockups from pre-Flatpak days, but they very likely need to be revisited: https://wiki.gnome.org/Design/Whiteboards/EnterpriseLogin I hope that makes sense. Cheers, Rishi [1] https://github.com/debarshiray/toolbox [2] https://fedoraproject.org/wiki/Changes/KerberosKCMCache ___ 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
mcatanz...@gnome.org writes: > Robbie Harwood wrote: > >> Can you link the bug you've filed about this? > > I don't even know where to file a bug. Which component? kerberos? > xdg-desktop-portal? When filing bugs that you don't know the cause of, it's best to start with the highest level component that doesn't exhibit the behavior you want and let the maintainers narrow it down and possibly reassign. So: probably gnome-online-accounts. > It's seems less like a bug in any Fedora component, rather something > that's never been designed to work. How is kerberos supposed to work > under flatpak without a desktop portal to make it work? I don't know. There's basically no chance of it ever working if there's no bug :) > It needs people who understand both kerberos and flatpak to think > about it. Well, they probably don't exist, so if you don't want to file a bug, you're out of luck. I (krb5 maintainer) don't "understand" flatpak, at any rate (beyond knowing that I don't have a use case for it). Thanks, --Robbie signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 Beta Release Announcement
On 9/17/19 7:01 PM, John M. Harris, Jr. wrote: The thing is, i686 still works. The kernel still builds as well, without issue. I have no idea what the issues that have been mentioned are, and I've kept asking. Nobody has given me an answer. Nobody has pointed me to an issue, or I'd be working on that in my free time. https://bugzilla.redhat.com/show_bug.cgi?id=1489998 ___ 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: swap on ZRAM, zswap, and Rust was: Better interactivity in low-memory situations
Hi, thank you for all the testing and comparisons between different approaches. It looks really interesting. > The ideal scenario is to get everyone on the same page, and so far it > looks like systemd's zram-generator, built in Rust, meets all the > requirements. That needs to be confirmed, but also right now there's a > small problem, it's not working. So we kinda need a someone familiar > with Rust and systemd to take this on, if we want to use the same > thing everywhere. > https://github.com/systemd/zram-generator/issues/4 For a while, the only feedback I had for zram-generator was from people interested in rust. It's great that somebody is giving it a go ;) I think the report in that issue is a slight exaggeration — IIUC, this failure only occurs if zram-generator.conf is created and systemctl daemon-reload and systemctl start swap.target called on a running system. After reboot, things would still work. Obviously, it would be better to handle this case too. I pushed some commits to the master branch now that close all the four open issues, and this case should be handled too now. If anything is wrong, please report it here or in bugzilla. I'll tag a new version with those changes in a few days if nothing else pops up. Zbyszek PS. I had a really surprising failure mode: on a VM with 2GB RAM (as shown by free), the genarator was doing nothing and simply exiting with no error. It turns out that the machine had "maximum allocation" bigger than "current allocation", and for a brief momment during boot /proc/meminfo would report more memory. Took me a while to figure this one out. Zbyszek ___ 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 Wed, 18 Sep 2019, 11:21 Felipe Borges, wrote: > Hi! > > On Wed, Sep 18, 2019 at 11:07 AM wrote: > > > > Hello, I don't know if this is the right place to ask this question. > > Btw, on Fedora 31, in the Online Accounts list there is a "Fedora" > > voice alongside "Google", "Nextcloud" and so on. What is its purpose? > > The "Fedora" account is just a branded Kerberos account. By adding a > Fedora account in GNOME Online Accounts you would get automatically > signed on whenever you'd need to enter your FAS credentials. This > means while accessing Pagure, participating in discussions in > discussion.fedoraproject.org, and also while using Bodhi, Koji, and > all. > Not everything afaict, pagure uses API keys for example, some Fedora services are kerberised but it's far from all. > ___ 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 10:06:21AM -0400, Randy Barlow wrote: > On Tue, 2019-09-17 at 19:15 -0400, Stephen John Smoogen wrote: > > fork it and make Memdora for low memory systems. > > If you make Memdora, then you will also need to think of four values > that start with M: > > Mriends > Mreedom > Mirst > Meatures Magic Mobility Mirth Maturity Zbyszek ___ 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
Minimization Objective report
This is the Minimization Objective [0] update. Status: Discovery phase == systemd-sysusers == Many packages pull in Systemd because of systemd-sysusers to create new users. This is fine in traditional setups where there already is Systemd, but for containers, that means pulling additional 60MB just to create a new user. This is being discussed. [1][2] One way to approach this is creating a "systemd-container-stub" basically something that says it's systemd, and might even have some functionality (like adding users) but doesn't have the baggage of systemd. We plan to coordinate with the Container SIG about approaching this problem as a bigger topic of accommodating traditional-environment-oriented packages in containers. == Weekly meeting == Discussing a new approach to the weekly meeting — the agenda and when to hold it. [3] == How to get involved == See if there is anything interesting to you on action plan [42], or reach out with something you think is useful but is missing there. Open a ticket in the tracker [43] or discuss in #fedora-devel on IRC. Cheers, Adam [0] Objective: https://docs.fedoraproject.org/en-US/minimization/ [1] Systemd-sysuser discussion: https://pagure.io/minimization/issue/13 [2] Systemd-sysuser discussion: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/6YX6CEFBPU3XVZZEHTN6CBH2F7JDF35N/#EJD4BNBE52JTEOPKAT6HFOO4HVUPBTCH [3] Meeting discussion: https://pagure.io/minimization/issue/14 [42] Action plan: https://docs.fedoraproject.org/en-US/minimization/action-plan/ [43] Issue tracker: https://pagure.io/minimization/issues -- Adam Šamalík --- Senior Software Engineer Red Hat ___ 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: Licensing of the bundled libraries
Michal Schorm wrote: > Hello, > > Q: > Is it needed to explicitly list (or pack) license (files) of a library > that a package bundles? [1] > And if yes, what's the right way to do so? > > The built package only contain 1 binary (and it's manpage and license > file). In this case - when no sources are packed - I'd understand that > it is sufficient to list and pack only the single license of the > resulting project. > Is that correct? I think this faq should cover it: https://fedoraproject.org/wiki/Licensing:FAQ#What_is_.22effective_license.22_and_do_I_need_to_know_that_for_the_License:_tag.3F In short, you have the option of either tracking the single aggregate/combined-work (effective) license, or listing licenses of individual components. -- Rex ___ 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-legal-list] Licensing of the bundled libraries
On 2019-09-18, Michal Schorm wrote: > Is it needed to explicitly list (or pack) license (files) of a library > that a package bundles? [1] If the bundled library code is part of the binary package, then yes, you need to list and to package the license. > And if yes, what's the right way to do so? > The same as for a nonbundled code. There is no distinction whether the code is original or borrowed from a different upstream. -- 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
Minimization Team Meeting notes 2019-09-18
Minutes: https://meetbot.fedoraproject.org/fedora-meeting-1/2019-09-18/minimization.2019-09-18-15.01.html Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-1/2019-09-18/minimization.2019-09-18-15.01.txt Log: https://meetbot.fedoraproject.org/fedora-meeting-1/2019-09-18/minimization.2019-09-18-15.01.log.html #fedora-meeting-1: Minimization Team Meeting Meeting started by asamalik at 15:01:28 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-1/2019-09-18/minimization.2019-09-18-15.01.log.html . Meeting summary --- * Roll call (asamalik, 15:01:28) * === Admin === (asamalik, 15:06:05) * To add topics to the agenda, tag an issue with the Meeting label in the Pagure tracker (https://pagure.io/minimization/issues) (asamalik, 15:08:19) * #13 systemd-sysusers versus containers (asamalik, 15:11:51) * LINK: https://pagure.io/minimization/issue/13 (asamalik, 15:11:56) * systemd-sysuser is for adding system users. It is beginning to become more poplular in Fedora. t pulls in systemd, which can add up to 60M to a container. (tdawson, 15:22:52) * We have tried seperating systemd-sysuser from systemd, unsuccessfully. (tdawson, 15:23:33) * We are currently looking into some type of "systemd-container-stub", that will be a substiture for systemd, as well as have the functionality of adding system users. (tdawson, 15:24:48) * We should talk with the containers-sig about a bigger topic of accommodating traditional-environment-oriented packages in containers (tdawson, 15:25:35) * === Focus & what's next? === (asamalik, 15:26:24) * since this objective is approved in it's first phase (the Discovery Phase) until the end of September, asamalik will be drafting a specific proposal for the next phase in the following two weeks, and proposing it to the Fedora Council — ideas very welcome! (asamalik, 15:28:24) * === Open Floor === (asamalik, 15:33:37) * We're thinking about changing how to approach this meeting — maybe only have it when we have actual topics to talk about. Discuss here: https://pagure.io/minimization/issue/14 (asamalik, 15:49:26) Meeting ended at 15:50:41 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * asamalik (54) * tdawson (31) * jaruga (13) * zodbot (11) * ignatenkobrain (0) * salimma (0) * feborges (0) * pbrobinson (0) * zbyszek (0) * Son_Goku (0) * lorbus (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- Adam Šamalík --- Senior Software Engineer Red Hat ___ 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 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. I actually filed a feature request against DNF (bug #1753140) to report the module stream. When modules proliferate Fedora more, the amount of users who enabled a stream and cannot install a non-modular package will surge. Giving them a chance to know what module reset back to default is a handy. -- 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: Fedora in GNOME Online Accountes
On Wed, Sep 18, 2019 at 10:43 am, Robbie Harwood wrote: Can you link the bug you've filed about this? I don't even know where to file a bug. Which component? kerberos? xdg-desktop-portal? It's seems less like a bug in any Fedora component, rather something that's never been designed to work. How is kerberos supposed to work under flatpak without a desktop portal to make it work? I don't know. It needs people who understand both kerberos and flatpak to think about it. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Test-Announce] Fedora 31 Beta Release Announcement
On Wed, 2019-09-18 at 09:15 +0200, Ralf Corsepius wrote: > On 9/17/19 4:04 PM, Mohan Boddu wrote: > > > Since this is a Beta release, we expect that you may encounter bugs or > > missing features. To report issues encountered during testing, contact the > > Fedora QA team via the mailing list or in #fedora-qa on Freenode. > > Some not so pleasant results: > > # dnf system-upgrade download --refresh --releasever=31 > Before you continue ensure that your system is fully upgraded by running > "dnf --refresh upgrade". Do you want to continue [y/N]: y > ... > Ignoring repositories: rpmfusion-free-updates, rpmfusion-nonfree-updates > Modular dependency problems: > > Problem 1: conflicting requests >- nothing provides module(platform:f30) needed by module > eclipse:2019-06:3020190807134759:6ebe2c0f-0.x86_64 > Problem 2: module jmc:latest:3120190813124555:7188e41a-0.x86_64 > requires module(eclipse), but none of the providers can be installed >- conflicting requests >- nothing provides module(platform:f30) needed by module > eclipse:2019-06:3020190807134759:6ebe2c0f-0.x86_64 This basically means 'eclipse module has not been rebuilt for F31 platform'. I believe https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-33a1b20f0a is the fix for this, so it should be resolved once that gets pushed stable. > Problem 2: problem with installed package > libopenshot-0.2.3-2.20190406git101f25a.fc30.x86_64 >- package libopenshot-0.2.3-2.20190406git101f25a.fc31.x86_64 requires > libjsoncpp.so.19()(64bit), but none of the providers can be installed >- libopenshot-0.2.3-2.20190406git101f25a.fc30.x86_64 does not belong > to a distupgrade repository >- jsoncpp-1.8.4-6.fc30.x86_64 does not belong to a distupgrade repository That's not a Fedora package, it's from a third-party repository, so you need to talk to the third party in question ;) It looks like their package just needs a rebuild. -- 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: [Test-Announce] Fedora 31 Beta Release Announcement
On Wed, 2019-09-18 at 12:11 +0200, Kalev Lember wrote: > On 9/18/19 10:29, Petr Pisar wrote: > > On 2019-09-18, Ralf Corsepius wrote: > > > - package perl-libs-4:5.28.2-439.module_f31+6019+b24e098f.x86_64 is > > > excluded > > > > Funnily DNF finds out that you could actually get that package satisfied > > if you enabled a modular Perl. Unfortunatelly DNF does not report what > > module stream the modular perl-libs packages comes from. There is indeed > > some room for improvement. DNF could start recommending "maybe you wanted > > to enable perl:5.28 stream?" :) > > 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? It didn't get *moved* to a module, no. There are just *alternative versions* available in a module: https://src.fedoraproject.org/modules/perl that module has no default stream, which means that if you just install Fedora and do 'dnf install perl' (or do anything else which causes a perl package to get installed) you'll get the non-modular package. You'll only get a modular package if you explicitly enable the module. As Petr points out, what's happening here is DNF is noticing that a package in one of the module streams satisfies the missing dependency, but that package is 'excluded' (because that module stream is not enabled). And as he also points out, DNF could stand to explain this much more clearly. -- 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
Release rpkg-1.59
Hi all, a new version rpkg-1.59 is released. Currently, just Fedora 31 packages are eligible to be moved into the stable repository, feel free to try other waiting distributions in Bodhi. The release contains new features and bug fixes as well. Among considerable new features are new commands to operate Koji side-tags and porting libmodulemd library to version 2. Features and improvements (as well as bugfixes) include: - Add argument to skip build option for container-build - Ignore error when adding exclude patterns - Path to lookaside repo fix - Add commands for interacting with Koji side-tag plugin - Do not delete files related to gating on import - Support integer values in the optional module-build arguments - container-build: add --build-release argument - Allow some arguments for container-build together - git-changelog: Fix running on Python 3 - Port to libmodulemd 2 API - Module-overview allows filtering by owner - Different import --offline command behaviour - Show nvr in container-build - Custom handler for koji watch_tasks - Unittests for clone command - Fix clone --branches - Make gitbuildhash work for windows builds More specific changelog (web documentation): https://docs.pagure.org/rpkg/releases/1.59.html Bodhi Updates: https://bodhi.fedoraproject.org/updates/?builds=rpkg-1.59-1.el6&builds=rpkg-1.59-1.el7&builds=rpkg-1.59-1.fc29&builds=rpkg-1.59-1.fc30&builds=rpkg-1.59-1.fc31 Alternative link: https://bodhi.fedoraproject.org/updates/?packages=rpkg&page=1 rpkg is available from PyPI. Thanks to all contributors. Regards Ondrej Nosek ___ 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
mcatanz...@gnome.org writes: > Felipe Borges wrote: > >> The "Fedora" account is just a branded Kerberos account. By adding a >> Fedora account in GNOME Online Accounts you would get automatically >> signed on whenever you'd need to enter your FAS credentials. This >> means while accessing Pagure, participating in discussions in >> discussion.fedoraproject.org, and also while using Bodhi, Koji, and >> all. > > Sadly, it's broken for me because it still doesn't work in flatpak. :( > > I wonder if we can get the right people together to discuss how to make > this work. Can you link the bug you've filed about this? Thanks, --Robbie signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: systemd-sysusers versus containers
On Tue, Sep 17, 2019 at 10:34 AM Daniel Walsh wrote: > > On 9/17/19 8:04 AM, Colin Walters wrote: > > > > On Mon, Sep 16, 2019, at 12:45 PM, Troy Dawson wrote: > >> systemd-sysusers seeks to unify user creation[1]. It also has the > >> benefit of being able to create users on bootup. But, it pulls in the > >> entire systemd infrastructure with all it's dependencies. > >> > >> containers do not need systemd to run. They are trying to be as small > >> as possible. But if a package in container needs to add a user, then > >> systemd is pulled in and that container grows by up to 60M.[2] > >> > >> Minimizing containers, both in the short term and long term, are > >> important to the minimization team. We have opened an issue for > >> this.[3] > > As I said in the big thread, what we should aim to minimize is containers > > built via multi-stage build; nothing else is going to be small. > > > > The user ID is a very interesting topic...bigger picture for example, > > OpenShift defaults to the `MustRunAsRange` SCC[1] - ensuring a uid is > > dynamically allocated for the container. So the `useradd` and `sysusers` > > stuff isn't relevant. > > (We have a longstanding issue though that the uid isn't in the passwd > > database but I think podman is growing some code to fix that) > Podman and CRI-O handle this now, by adding the runasuser to the > /etc/passwd inside of the container, if it does not exists. > > > > For non-Kubernetes systems (e.g. installing RPMs on a host) - I think in a > > lot of cases, using systemd dynamic users is best: > > http://0pointer.net/blog/dynamic-users-with-systemd.html > > Where possible - using it for e.g. postgres would probably be somewhat of a > > surprise for admins. > > > > It'd be useful in this discussion to look at particular containers - I'm > > guessing it's things like nginx and postgres where we want to ship both an > > RPM and a container image? And where things intersect here is whether or > > not the RPM depends on systemd. Maybe the least bad thing is to introduce > > a `systemd-container-stub` package that is empty except for Provides? > > Dunno...it's messy. > > > > A whole lot of service software is container-only - it doesn't make sense > > to make RPMs for them, which sidesteps a lot of this. > > > > [1] > > https://docs.openshift.com/container-platform/3.11/architecture/additional_concepts/authorization.html#security-context-constraints One of the comments in the ticket was to try pulling out systemd-sysusers into it's own sub-package. systemd-sysusers requires libsystemd-shared Pulling libsystemd-shared into it's own sub-package shows that it requires cryptsetup-libs which sets up a circular dependency back to systemd. After many attempts, just using rpm packaging techniques, I have been unsuccessful in breaking the circular dependency. The only way I can see to do it is either remove some functionality, or do some type of re-writting of code in systemd and/or one of the packages in the circular dependency. The "systemd-container-stub" is looking more and more like the way to go. Troy ___ 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 Tue, 2019-09-17 at 19:15 -0400, Stephen John Smoogen wrote: > fork it and make Memdora for low memory systems. If you make Memdora, then you will also need to think of four values that start with M: Mriends Mreedom Mirst Meatures 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: Fedora in GNOME Online Accountes
On Wed, Sep 18, 2019 at 11:18 am, Felipe Borges wrote: The "Fedora" account is just a branded Kerberos account. By adding a Fedora account in GNOME Online Accounts you would get automatically signed on whenever you'd need to enter your FAS credentials. This means while accessing Pagure, participating in discussions in discussion.fedoraproject.org, and also while using Bodhi, Koji, and all. Sadly, it's broken for me because it still doesn't work in flatpak. :( I wonder if we can get the right people together to discuss how to make this work. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-31-20190918.n.0 compose check report
No missing expected images. Failed openQA tests: 7/152 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-31-20190917.n.2): ID: 45 Test: x86_64 Server-dvd-iso server_remote_logging_server URL: https://openqa.fedoraproject.org/tests/45 ID: 453334 Test: x86_64 Server-dvd-iso server_remote_logging_client URL: https://openqa.fedoraproject.org/tests/453334 ID: 453357 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/453357 ID: 453367 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/453367 Old failures (same test failed in Fedora-31-20190917.n.2): ID: 453335 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/453335 ID: 453372 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/453372 ID: 453373 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/453373 ID: 453376 Test: x86_64 Silverblue-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/453376 Soft failed openQA tests: 3/152 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-31-20190917.n.2): ID: 453329 Test: x86_64 Server-dvd-iso realmd_join_sssd URL: https://openqa.fedoraproject.org/tests/453329 Old soft failures (same test soft failed in Fedora-31-20190917.n.2): ID: 453351 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/453351 ID: 453448 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/453448 Passed openQA tests: 142/152 (x86_64) New passes (same test not passed in Fedora-31-20190917.n.2): ID: 453355 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/453355 ID: 453370 Test: x86_64 KDE-live-iso desktop_background URL: https://openqa.fedoraproject.org/tests/453370 ID: 453371 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/453371 ID: 453385 Test: x86_64 universal install_mirrorlist_graphical URL: https://openqa.fedoraproject.org/tests/453385 ID: 453426 Test: x86_64 universal install_simple_encrypted@uefi URL: https://openqa.fedoraproject.org/tests/453426 ID: 453459 Test: x86_64 universal install_rescue_encrypted@uefi URL: https://openqa.fedoraproject.org/tests/453459 Skipped non-gating openQA tests: 1 of 154 Installed system changes in test x86_64 Workstation-live-iso install_default_upload: System load changed from 0.51 to 0.72 Previous test data: https://openqa.fedoraproject.org/tests/452951#downloads Current test data: https://openqa.fedoraproject.org/tests/453343#downloads Installed system changes in test x86_64 Workstation-live-iso install_default@uefi: 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.44 to 0.23 Previous test data: https://openqa.fedoraproject.org/tests/452953#downloads Current test data: https://openqa.fedoraproject.org/tests/453345#downloads Installed system changes in test x86_64 KDE-live-iso install_default_upload: 1 services(s) added since previous compose: pcscd.service System load changed from 1.79 to 1.38 Average CPU usage changed from 1.98095238 to 74.45714286 Previous test data: https://openqa.fedoraproject.org/tests/452966#downloads Current test data: https://openqa.fedoraproject.org/tests/453358#downloads Installed system changes in test x86_64 KDE-live-iso install_default@uefi: Used mem changed from 903 MiB to 748 MiB Previous test data: https://openqa.fedoraproject.org/tests/452968#downloads Current test data: https://openqa.fedoraproject.org/tests/453360#downloads Installed system changes in test x86_64 Silverblue-dvd_ostree-iso install_default_upload: Used swap changed from 10 MiB to 4 MiB System load changed from 0.55 to 0.78 Previous test data: https://openqa.fedoraproject.org/tests/452983#downloads Current test data: https://openqa.fedoraproject.org/tests/453375#downloads Installed system changes in test x86_64 Silverblue-dvd_ostree-iso install_default@uefi: System load changed from 0.33 to 0.44 Average CPU usage changed from 5.0 to 30.45238095 Previous test data: https://openqa.fedoraproject.org/tests/452985#downloads Current test data: https://openqa.fedoraproject.org/tests/453377#downloads Installed system changes in test x86_64 universal install_
Fedora 31 compose report: 20190918.n.0 changes
OLD: Fedora-31-20190917.n.2 NEW: Fedora-31-20190918.n.0 = SUMMARY = Added images:10 Dropped images: 0 Added packages: 7 Dropped packages:0 Upgraded packages: 131 Downgraded packages: 0 Size of added packages: 147.20 MiB Size of dropped packages:0 B Size of upgraded packages: 4.17 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 8.25 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Server dvd s390x Path: Server/s390x/iso/Fedora-Server-dvd-s390x-31-20190918.n.0.iso Image: Container_Base docker aarch64 Path: Container/aarch64/images/Fedora-Container-Base-31-20190918.n.0.aarch64.tar.xz Image: Cloud_Base vmdk s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-31-20190918.n.0.s390x.vmdk Image: Container_Base docker s390x Path: Container/s390x/images/Fedora-Container-Base-31-20190918.n.0.s390x.tar.xz Image: KDE raw-xz armhfp Path: Spins/armhfp/images/Fedora-KDE-armhfp-31-20190918.n.0-sda.raw.xz Image: Everything boot s390x Path: Everything/s390x/iso/Fedora-Everything-netinst-s390x-31-20190918.n.0.iso Image: Container_Minimal_Base docker s390x Path: Container/s390x/images/Fedora-Container-Minimal-Base-31-20190918.n.0.s390x.tar.xz Image: Server boot s390x Path: Server/s390x/iso/Fedora-Server-netinst-s390x-31-20190918.n.0.iso Image: Cloud_Base qcow2 s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-31-20190918.n.0.s390x.qcow2 Image: Cloud_Base raw-xz s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-31-20190918.n.0.s390x.raw.xz = DROPPED IMAGES = = ADDED PACKAGES = Package: conmon-2:2.0.0-2.fc31 Summary: OCI container runtime monitor RPMs:conmon Size:177.00 KiB Package: moka-icon-theme-5.4.0-2.20190530gitc0355ea.fc31 Summary: Moka Icon Theme RPMs:moka-icon-theme Size:59.92 MiB Package: oomd-0.2.0-4.fc31 Summary: Userspace Out-Of-Memory (OOM) killer RPMs:oomd Size:869.26 KiB Package: patat-0.8.2.3-1.fc31 Summary: Terminal-based presentations using Pandoc RPMs:patat Size:82.41 MiB Package: python-MDAnalysis-0.20.1-1.fc31 Summary: Analyze and manipulate molecular dynamics trajectories RPMs:python-MDAnalysis-doc python3-MDAnalysis Size:3.58 MiB Package: python-fsspec-0.4.4-1.fc31~bootstrap Summary: Specification for Pythonic file system interfaces RPMs:python3-fsspec Size:91.70 KiB Package: python-sybil-1.2.0-2.fc31 Summary: Automated testing for the examples in your documentation RPMs:python-sybil-doc python3-sybil Size:187.69 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: aircrack-ng-1.5.2-8.fc31 Old package: aircrack-ng-1.5.2-7.fc31 Summary: 802.11 (wireless) sniffer and WEP/WPA-PSK key cracker RPMs: aircrack-ng Size: 15.19 MiB Size change: 2.65 KiB Changelog: * Sun Aug 25 2019 Zbigniew J??drzejewski-Szmek - 1.5.2-8 - Rebuilt for hwloc-2.0 Package: amiri-fonts-0.111-1.fc31 Old package: amiri-fonts-0.109-6.fc31 Summary: A classical Arabic font in Naskh style RPMs: amiri-fonts amiri-fonts-common amiri-quran-fonts Size: 971.99 KiB Size change: -3.95 KiB Changelog: * Mon Sep 09 2019 Mosaab Alzoubi - 0.111-1 - Update to 0.111 Package: ansible-2.8.5-1.fc31 Old package: ansible-2.8.4-1.fc31 Summary: SSH-based configuration management, deployment, and task execution system RPMs: ansible ansible-doc Size: 19.78 MiB Size change: 8.08 KiB Changelog: * Mon Aug 19 2019 Miro Hron??ok - 2.8.4-2 - Rebuilt for Python 3.8 * Fri Sep 13 2019 Kevin Fenzi - 2.8.5-1 - Update to 2.8.5. Package: buildah-1.11.1-2.git413bd1f.fc31 Old package: buildah-1.11.0-1.git2c5da1b.fc31 Summary: A command line tool used for creating OCI Images RPMs: buildah Size: 36.82 MiB Size change: 95.38 KiB Changelog: * Thu Sep 12 2019 Lokesh Mandvekar (Bot) - 1.11.1-2.git413bd1f - bump to v1.11.1 - autobuilt 413bd1f Package: calibre-3.48.0-1.fc31 Old package: calibre-3.46.0-1.git20190819.fc31 Summary: E-book converter and library manager RPMs: calibre Size: 119.30 MiB Size change: 229.41 KiB Changelog: * Fri Sep 13 2019 Zbigniew J??drzejewski-Szmek - 3.48.0-1 - Update to 3.48.0 (#1751909) Package: catfish-1.4.8-2.fc31 Old package: catfish-1.4.8-1.fc31 Summary: A handy file search tool RPMs: catfish Size: 244.77 KiB Size change: 210 B Changelog: * Mon Aug 19 2019 Miro Hron??ok - 1.4.8-1.1 - Rebuilt for Python 3.8 * Fri Sep 13 2019 Mamoru TASAKA - 1.4.8-2 - set GDK_BACKEND as x11 explicitly (ref: bug 1702891) Package: ceph-2:14.2.3-1.fc31 Old package: ceph-2:14.2.2-2.fc31 Summary: User space components of the Ceph file system RPMs: ceph ceph-base ceph-common ceph-fuse ceph-grafana-dashboards ceph-mds ceph-mgr ceph-mgr-dashboard ceph-mgr-diskprediction-cloud ceph-mgr-diskprediction-local ceph-mgr-rook ceph-mgr-ssh ceph-mon
Re: [Test-Announce] Fedora 31 Beta Release Announcement
> Featuritis? Actually, do not see any usefulness in any module. *any* module ? Maybe you just haven't met the right use case yet. I maintain packages of MariaDB and MySQL projects. There's no better way I can imagine, to develop two version of the packages of the DB, than modules. Fedora have MariaDB 10.3 in base. 10.4 in modules. I maintain both, I actively fix both and I try to cooperate with upstream to get it so stable, that Fedora could switch to 10.4. [1] Apart from that, I don't want to force useres to do the upgrade immediatelly. I'm providing both 10.3 and 10.4 as modules (even though 10.3 is also in base), so the user can switch to the desired stream and stay with it, no matter when I introduce the new version into the base Fedora. of course, I don't plan to mainatin the 10.3 forever after the change will be made, but I believe i surely might come handy to someone, who wants the up-to-date and secure Fedora, but haven't got time to upgrade 10.3->10.4 yet. Althought I agree with that many of the modularized packages are not useffull modularized, and / or creates more issues that way; I certainly find the modularity usefull. As per Unix motto "do one thing and do it well" [2], I never expected modularity to solve all of my problems and use cases. Just some. And it did. Just fine. For me. ( Disclaimer: modularity will need time to also comply with the part "do it well" ;) ) [1] https://fedoraproject.org/wiki/Changes/MariaDB_10.4 [2] https://en.wikipedia.org/wiki/Unix_philosophy#Do_One_Thing_and_Do_It_Well -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Wed, Sep 18, 2019 at 2:07 PM Ralf Corsepius wrote: > > On 9/18/19 12:11 PM, Kalev Lember wrote: > > > > On 9/18/19 10:29, Petr Pisar wrote: > >> On 2019-09-18, Ralf Corsepius wrote: > >>> - package perl-libs-4:5.28.2-439.module_f31+6019+b24e098f.x86_64 is > >>> excluded > >> > >> Funnily DNF finds out that you could actually get that package satisfied > >> if you enabled a modular Perl. Unfortunatelly DNF does not report what > >> module stream the modular perl-libs packages comes from. There is indeed > >> some room for improvement. DNF could start recommending "maybe you wanted > >> to enable perl:5.28 stream?" :) > > Openly said, to me, the modules are permanent source of troubles. > > > 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? > Featuritis? Actually, do not see any usefulness in any module. > > Ralf > ___ > 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
orphaning git-remote-bzr
Hi guys, I am orphaning the git-remote-bzr package. Regarding the repoquery, there are not any other rpms depending on that package. Cheers, -- Petr Stodulka OS & Application Modernization IRC nicks: pstodulk, skytak Senior Software Engineer Red Hat Czech s.r.o. ___ 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: Proposal to use repo files in Anaconda environment
On Wed, Sep 18, 2019 at 8:03 AM Nico Kadel-Garcia wrote: > > You also have to pre-build your filesystems to have a place to copy > the files into at installation time. If you're going to go to that > much work, why are you bothering with yum? Why not just pre-build and > install a base operating system, which is much, much faster and > notably more network efficient than pulling down and installing RPMs? > I've installed roughly. 20,000 hosts this way in my career, it > works really well for clusters. I think you missed the point here. For livecd-tools and lorax, kickstart is *the* language to define an image to build. But pykickstart will (reasonably) not accept grammar added that Anaconda doesn't want to use. I'm fine with that, because the point of using kickstart in livecd-tools is that you can take your mass deployment and turn it into an image with no effort with appliance-creator. Same goes for lorax. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora in GNOME Online Accountes
On Wed, 2019-09-18 at 13:52 +0200, Sheogorath via devel wrote: > On 9/18/19 11:18 AM, Felipe Borges wrote: > > Hi! > > > > On Wed, Sep 18, 2019 at 11:07 AM wrote: > > > Hello, I don't know if this is the right place to ask this > > > question. > > > Btw, on Fedora 31, in the Online Accounts list there is a > > > "Fedora" > > > voice alongside "Google", "Nextcloud" and so on. What is its > > > purpose? > > > > The "Fedora" account is just a branded Kerberos account. By adding > > a > > Fedora account in GNOME Online Accounts you would get automatically > > signed on whenever you'd need to enter your FAS credentials. This > > means while accessing Pagure, participating in discussions in > > discussion.fedoraproject.org, and also while using Bodhi, Koji, and > > all. > > > > Just out of curiosity, is this done by a patch or with a separate > package? Looks like https://gitlab.gnome.org/GNOME/gnome-online-accounts/merge_requests/27 -- Ernestas Kulik Associate Software Engineer - Base Operating Systems (Core Services/ABRT) Red Hat Czech, s.r.o. ___ 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 12:11 PM, Kalev Lember wrote: On 9/18/19 10:29, Petr Pisar wrote: On 2019-09-18, Ralf Corsepius wrote: - package perl-libs-4:5.28.2-439.module_f31+6019+b24e098f.x86_64 is excluded Funnily DNF finds out that you could actually get that package satisfied if you enabled a modular Perl. Unfortunatelly DNF does not report what module stream the modular perl-libs packages comes from. There is indeed some room for improvement. DNF could start recommending "maybe you wanted to enable perl:5.28 stream?" :) Openly said, to me, the modules are permanent source of troubles. 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? Featuritis? Actually, do not see any usefulness in any module. Ralf ___ 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: Proposal to use repo files in Anaconda environment
On Wed, Sep 18, 2019 at 4:49 AM wrote: > > Hi James, > > On Tue, 2019-09-17 at 09:57 -0400, James Cassell wrote: > > In general, I'd prefer to extend the ks repo command. > > > > My main concern is that the original-ks.cfg or anaconda-ks.cfg might > > no longer provide a complete description of how a particular system > > was installed, so it'd like that info exposed on the installed system > > somehow. > > It's not really related. What we are talking here about is to add repo > files in the installation environment. The output kickstart file will > be the same as before. What will change is the environment used for the > installation. I used to use '%pre' to first build up the file systems, then to pre-install localized configuration files. Mind you, I also threw out most of the rest of the kickstart configuraiton operations and worked from a deployment tarball, much like mock uses local tarballs to build chroot cages, and used chroot cages to build those tarballs for deployment. This was *much, much faster* than doing RPM baed installations on top of a bare filesystem. It's also possible, if you're desperate for leverage, to do the kickstart install with a minimal list of packages and use multiple '%post' stanzas to activate additional repositories and complete installation of other suites of software. It's really too bad that the GUI for reading and building kickstarts has never handled multiple '%pre' or '%post' stanzas, it would have made this much easier. > > As for implementation, perhaps base64 zlib compressed. repo passed as > > a cmdline arg would be useful to avoid having to create updates.img. > > Could also be done as --repofilecontent for the repo command. > > Personally, I'm not really sure what would be the benefit here. Also > you have a limitation on what you can pass in the kernel command line > so I guess having 3 repo files this way is a no-go. > > I think it's already possible to place a .repo file from ks %pre? > > Yes it is. However, you have to do that manually and download gpg keys > and certificates somewhere (which is not secure in general). You also have to pre-build your filesystems to have a place to copy the files into at installation time. If you're going to go to that much work, why are you bothering with yum? Why not just pre-build and install a base operating system, which is much, much faster and notably more network efficient than pulling down and installing RPMs? I've installed roughly. 20,000 hosts this way in my career, it works really well for clusters. ___ 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: Intent to unretire ladspa-swh-plugins
Can you also unretire and build lv2-mdala-plugins? It is needed for pulseeffects but lv2-mdala-plugins use python2 in build script and I do not have knowledge how to rewrite it to python3. I can only add python2 to BR and correct shebang but it seems wrong because python2 will be erased soon. -- Best regards, Vasiliy Glazov чт, 12 сент. 2019 г. в 18:19, stan via devel : > > On Thu, 12 Sep 2019 13:32:45 +0100 > "Ryan Walklin" wrote: > > > Thanks for the clarification, I hadn't realised the LV2 versions of > > the plugins weren't working. I've managed to get the F29 version as > > you suggest, and patched (attached) the scripts to force Python 2 so > > I can run the GUI from the launcher. Upstream seems to have updated > > the GUI to Python 3, but as mentioned there are some bugs with their > > config parser currently. > > Thanks for the patch. I had caught the generic python reference in the > python file, but not the one in the gtk file. Now, I can have normal > operation. > ___ > 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 in GNOME Online Accountes
On 9/18/19 11:18 AM, Felipe Borges wrote: > Hi! > > On Wed, Sep 18, 2019 at 11:07 AM wrote: >> >> Hello, I don't know if this is the right place to ask this question. >> Btw, on Fedora 31, in the Online Accounts list there is a "Fedora" >> voice alongside "Google", "Nextcloud" and so on. What is its purpose? > > The "Fedora" account is just a branded Kerberos account. By adding a > Fedora account in GNOME Online Accounts you would get automatically > signed on whenever you'd need to enter your FAS credentials. This > means while accessing Pagure, participating in discussions in > discussion.fedoraproject.org, and also while using Bodhi, Koji, and > all. > Just out of curiosity, is this done by a patch or with a separate package? -- Signed Sheogorath OpenPGP: https://shivering-isles.com/openpgp/0xFCB98C2A3EC6F601.txt 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
Licensing of the bundled libraries
Hello, Q: Is it needed to explicitly list (or pack) license (files) of a library that a package bundles? [1] And if yes, what's the right way to do so? The built package only contain 1 binary (and it's manpage and license file). In this case - when no sources are packed - I'd understand that it is sufficient to list and pack only the single license of the resulting project. Is that correct? -- The package is 'pgloader' and it is now on a review to enter Fedora. [2] -- [1] https://fedoraproject.org/wiki/Packaging:LicensingGuidelines?rd=Packaging/LicensingGuidelines#Multiple_Licensing_Scenarios [2] https://bugzilla.redhat.com/show_bug.cgi?id=1748233 -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- ___ 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
Open NeuroFedora team meeting: 1500 UTC on Thursday, 19th September
Hello everyone, You are invited to attend the Open NeuroFedora team meeting this week on Thursday at 1500UTC in #fedora-neuro on IRC (Freenode): https://webchat.freenode.net/?channels=#fedora-neuro You can convert the meeting time to your local time using: $ date --date='TZ="UTC" 1500 next Thu' or use this link: https://www.timeanddate.com/worldclock/fixedtime.html?msg=NeuroFedora+team+meeting&iso=20190919T15&p1=1440&ah=1 The meeting will be chaired by @ankursinha. The agenda for the meeting is: - Introductions and roll call. - Tasks from last week's meeting: https://meetbot.fedoraproject.org/teams/neurofedora/neurofedora.2019-09-12-15.01.html - Pagure tickets: https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open&tags=S%3A+Next+meeting - Neuroscience query of the week. - Next meeting day, and chair. - Open floor. In the "Neuroscience query of the week" section, we hope to provide attendees with the chance to ask about a neuroscience topic that they are curious about. Please go through the tickets on Pagure, and mark any other tickets that need to be discussed with the "S: Next meeting" tag. We hope to see you there! -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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
[Test-Announce] Fedora 31 Branched 20190918.n.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 31 Branched 20190918.n.0. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Notable package version changes: pungi - 1.1: pungi-4.1.38-2.fc31.src, 20190918.n.0: pungi-4.1.39-1.fc31.src Test coverage information for the current release can be seen at: https://www.happyassassin.net/testcase_stats/31 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_31_Branched_20190918.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_31_Branched_20190918.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_31_Branched_20190918.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_31_Branched_20190918.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_31_Branched_20190918.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_31_Branched_20190918.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_31_Branched_20190918.n.0_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@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
On Wed, Sep 18, 2019 at 11:56:49AM +0200, Kevin Kofler wrote: > John M. Harris, Jr. wrote: > > These are generic servers. I can provide a link to the vendor's website > > when I get home. It is not Dell, Lenovo or similar, those are currently > > selling mostly x86_64. Additionally, many users don't want to buy a new > > computer just because a software project made the decision to randomly > > drop support for their architecture. I am certainly one of those. The > > hardware is fine, perfect working condition. I don't understand why we > > should simply turn these to e-waste because somebody flipped the > > proverbial switch. Hi Kevin, you are not being fair in this assessment. Going point by point: > * dropping, in short succession, of the i686 kernel, the i686 images, and > then even the i686 repositories even though there are legitimate use cases > for them on an x86_64 kernel (e.g., building multilib packages), So... building multilib packages is still very much supported. You cannot *run* a pure-i686 environment, but you can 32 bit development. > * 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. > * the reenforcement of the mass-retirement procedures and the resulting > aggressive mass-retirement of hundreds of FTBFS or orphaned packages, with > no regards to why (or even if, in the latter case) they fail to build, > whether they still work, how essential they are, nor what or how many > other packages (including essential ones) depend on them, 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. 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. > * the unprecedentedly aggressive removal of Python 2 and anything remotely > related to it, where useful packages can arbitrarily be vetoed by > committee (see e.g. https://pagure.io/fesco/issue/2223 ). 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. So sorry, but you can't expect every obsolete hardware technology and software stack from previous decade gets to hold everyone else hostage. Zbyszek ___ 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 10:29, Petr Pisar wrote: On 2019-09-18, Ralf Corsepius wrote: - package perl-libs-4:5.28.2-439.module_f31+6019+b24e098f.x86_64 is excluded Funnily DNF finds out that you could actually get that package satisfied if you enabled a modular Perl. Unfortunatelly DNF does not report what module stream the modular perl-libs packages comes from. There is indeed some room for improvement. DNF could start recommending "maybe you wanted to enable perl:5.28 stream?" :) 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? -- 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: Fedora 31 Beta Release Announcement
John M. Harris, Jr. wrote: > These are generic servers. I can provide a link to the vendor's website > when I get home. It is not Dell, Lenovo or similar, those are currently > selling mostly x86_64. Additionally, many users don't want to buy a new > computer just because a software project made the decision to randomly > drop support for their architecture. I am certainly one of those. The > hardware is fine, perfect working condition. I don't understand why we > should simply turn these to e-waste because somebody flipped the > proverbial switch. Unfortunately, Fedora has lately become mainly about randomly dropping support for things: * dropping, in short succession, of the i686 kernel, the i686 images, and then even the i686 repositories even though there are legitimate use cases for them on an x86_64 kernel (e.g., building multilib packages), * 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, * the reenforcement of the mass-retirement procedures and the resulting aggressive mass-retirement of hundreds of FTBFS or orphaned packages, with no regards to why (or even if, in the latter case) they fail to build, whether they still work, how essential they are, nor what or how many other packages (including essential ones) depend on them, * the unprecedentedly aggressive removal of Python 2 and anything remotely related to it, where useful packages can arbitrarily be vetoed by committee (see e.g. https://pagure.io/fesco/issue/2223 ). All these are moves which are leaving, will leave, or would leave thousands of users in the cold when and if they have been, are, will be, or would be implemented. I miss the times when Fedora was still an inclusive project, focused on adding things rather than on removing them. Each time you drop an architecture (e.g. i686), a subset of an architecture (e.g. pre-AVX2 x86_64), or one or more packages, you are excluding dozens, hundreds, thousands, or even millions of users. Removing things is actively harmful to Fedora. 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 in GNOME Online Accountes
On Wed, Sep 18, 2019 at 11:21 AM Felipe Borges wrote: The "Fedora" account is just a branded Kerberos account. By adding a Fedora account in GNOME Online Accounts you would get automatically signed on whenever you'd need to enter your FAS credentials. Love it. -- Ismael Olea http://olea.org/diario/ ___ 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 Wed, 2019-09-18 at 11:18 +0200, Felipe Borges wrote: > The "Fedora" account is just a branded Kerberos account. By adding a > Fedora account in GNOME Online Accounts you would get automatically > signed on whenever you'd need to enter your FAS credentials. This > means while accessing Pagure, participating in discussions in > discussion.fedoraproject.org, and also while using Bodhi, Koji, and > all. :-O Nice! Thank you for the answer. Ciao, A. ___ 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
Hi! On Wed, Sep 18, 2019 at 11:07 AM wrote: > > Hello, I don't know if this is the right place to ask this question. > Btw, on Fedora 31, in the Online Accounts list there is a "Fedora" > voice alongside "Google", "Nextcloud" and so on. What is its purpose? The "Fedora" account is just a branded Kerberos account. By adding a Fedora account in GNOME Online Accounts you would get automatically signed on whenever you'd need to enter your FAS credentials. This means while accessing Pagure, participating in discussions in discussion.fedoraproject.org, and also while using Bodhi, Koji, and all. > > Thanks, > A. > ___ > 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
Fedora in GNOME Online Accountes
Hello, I don't know if this is the right place to ask this question. Btw, on Fedora 31, in the Online Accounts list there is a "Fedora" voice alongside "Google", "Nextcloud" and so on. What is its purpose? Thanks, A. ___ 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
glassfish-el-3.0.1~b11 license change
Since the pre release version ~b11 (last was ~b08) some files in the directory "/api/src/main/java/javax/el" no longer contain two licenses (CDDL and ASL 2.0) but only ASL 2.0. Therefore I am adding ASL 2.0 as an additional license. -- Marián Konček ___ 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
python-asgiref license change
The license of python-asgiref has been changed from "BSD" to "BSD and ASL 2.0" (due to bundling). https://src.fedoraproject.org/rpms/python-asgiref/c/cb241f277fdc2f3042dfade0b942df8c6a7acd0f?branch=master -- 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: Proposal to use repo files in Anaconda environment
Hi James, On Tue, 2019-09-17 at 09:57 -0400, James Cassell wrote: > In general, I'd prefer to extend the ks repo command. > > My main concern is that the original-ks.cfg or anaconda-ks.cfg might > no longer provide a complete description of how a particular system > was installed, so it'd like that info exposed on the installed system > somehow. It's not really related. What we are talking here about is to add repo files in the installation environment. The output kickstart file will be the same as before. What will change is the environment used for the installation. > > As for implementation, perhaps base64 zlib compressed. repo passed as > a cmdline arg would be useful to avoid having to create updates.img. > Could also be done as --repofilecontent for the repo command. Personally, I'm not really sure what would be the benefit here. Also you have a limitation on what you can pass in the kernel command line so I guess having 3 repo files this way is a no-go. > > I think it's already possible to place a .repo file from ks %pre? Yes it is. However, you have to do that manually and download gpg keys and certificates somewhere (which is not secure in general). Please if you have other reactions, could you please use the comment section in the document? It would be great to have everything at one place. Best Regards, Jirka ___ 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: About OCaml 4.08.1 final for F31 and rebuild tracking
On Wed, Sep 18, 2019 at 09:47:49AM +0800, Robin Lee wrote: > Hi, Richard! > > Any plan to push 4.08.1 final to F31? Unfortunately the scripts I use to do the whole rebuild cannot cope with updates and overrides, so I can only run them against Rawhide, so no. I need to rewrite them anyway because they depend on the deprecated camlp4, but that's not going to happen for a while. The RC2 version we have in F31 is very close to 4.08.1. > And how do you track packages that need to rebuild for new OCaml? I usually add new OCaml packages when I see them added to Fedora. > The 'ocaml-ocp-indent' package is not rebuilt for the recent OCaml > 4.08.1 updates. So it has broken dependency in F31 and Rawhide. I will push a bump and rebuild for this one. It was missing from my scripts for some reason, but I've added it now. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ 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
Hi Kevin, Thanks for the explanation. See my comments below. On Tue, 2019-09-17 at 09:28 -0700, 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. ;( I don't think it's your fault or anyone else. I think it's a fault of the system here and that is what I want to fix. > > 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. Definitely good point! > > * 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. 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. 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. 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. Other than this one point I agree with what you just wrote. Jirka ___ 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 2019-09-18, Ralf Corsepius wrote: > Error: > Problem 1: package crypto-utils-2.5-4.fc29.x86_64 requires > libperl.so.5.28()(64bit), but none of the providers can be installed >- package crypto-utils-2.5-4.fc29.x86_64 requires > perl(:MODULE_COMPAT_5.28.0), but none of the providers can be installed >- perl-libs-4:5.28.2-439.fc30.x86_64 does not belong to a distupgrade > repository crypto-utils has not been rebuilt against Perl 5.30 because the package fails to build for an unrelated reason and was retired (bug #1674777) and obsoleted in fedora-obsolete-packages-31-31 that is in updates-testing now. Enabling updates-testing repository or waiting a bit for the stabilization should help you. >- problem with installed package crypto-utils-2.5-4.fc29.x86_64 >- package perl-libs-4:5.28.2-439.module_f31+6019+b24e098f.x86_64 is > excluded Funnily DNF finds out that you could actually get that package satisfied if you enabled a modular Perl. Unfortunatelly DNF does not report what module stream the modular perl-libs packages comes from. There is indeed some room for improvement. DNF could start recommending "maybe you wanted to enable perl:5.28 stream?" :) -- 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: [Test-Announce] Fedora 31 Beta Release Announcement
On 9/17/19 4:04 PM, Mohan Boddu wrote: Since this is a Beta release, we expect that you may encounter bugs or missing features. To report issues encountered during testing, contact the Fedora QA team via the mailing list or in #fedora-qa on Freenode. Some not so pleasant results: # dnf system-upgrade download --refresh --releasever=31 Before you continue ensure that your system is fully upgraded by running "dnf --refresh upgrade". Do you want to continue [y/N]: y ... Ignoring repositories: rpmfusion-free-updates, rpmfusion-nonfree-updates Modular dependency problems: Problem 1: conflicting requests - nothing provides module(platform:f30) needed by module eclipse:2019-06:3020190807134759:6ebe2c0f-0.x86_64 Problem 2: module jmc:latest:3120190813124555:7188e41a-0.x86_64 requires module(eclipse), but none of the providers can be installed - conflicting requests - nothing provides module(platform:f30) needed by module eclipse:2019-06:3020190807134759:6ebe2c0f-0.x86_64 Error: Problem 1: package crypto-utils-2.5-4.fc29.x86_64 requires libperl.so.5.28()(64bit), but none of the providers can be installed - package crypto-utils-2.5-4.fc29.x86_64 requires perl(:MODULE_COMPAT_5.28.0), but none of the providers can be installed - perl-libs-4:5.28.2-439.fc30.x86_64 does not belong to a distupgrade repository - problem with installed package crypto-utils-2.5-4.fc29.x86_64 - package perl-libs-4:5.28.2-439.module_f31+6019+b24e098f.x86_64 is excluded - package perl-libs-4:5.28.2-439.module_f31+6050+a462f342.x86_64 is excluded Problem 2: problem with installed package libopenshot-0.2.3-2.20190406git101f25a.fc30.x86_64 - package libopenshot-0.2.3-2.20190406git101f25a.fc31.x86_64 requires libjsoncpp.so.19()(64bit), but none of the providers can be installed - libopenshot-0.2.3-2.20190406git101f25a.fc30.x86_64 does not belong to a distupgrade repository - jsoncpp-1.8.4-6.fc30.x86_64 does not belong to a distupgrade repository Ralf ___ 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
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? -- Miroslav Suchy, RHCA Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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
