Re: Removing unsupported AUTH_DES interfaces in libtirpc.
* Steve Dickson: > About a year ago I stub out the interfaces > and had them return an error if called. > No one has complained... > > This time I would like to remove interfaces > so there will be no support whatsoever to > pass some upcoming audits... Are you sure this is necessary? If there is no actual DES implementation, it won't matter for certification. > This means I will need to change the SONAME for > libtirpc which will effect a large other packages. Is this really necessary? I expect that a lot of projects migrated to libtirpc with an expectation that it would provide a similar level of ABI stability as glibc. Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill ___ 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: Removing unsupported AUTH_DES interfaces in libtirpc.
On Mon, Oct 19, 2020 at 01:21:35PM -0400, Steve Dickson wrote: > Hello, > > About a year ago I stub out the interfaces > and had them return an error if called. > No one has complained... > > This time I would like to remove interfaces > so there will be no support whatsoever to > pass some upcoming audits... Hi, there are three semi-independent ways how to remove an interface: 1. functional stubbing out (which you said is already done) 2. removal of the function from headers 3. removal of the function from ABI and the resulting required SONAME change (1. affects programs that use the function at runtime. 2. affects programs which use the function during compilation. 3. affects all programs that use the library.) Part 1. is already done, and we are discussing 3.: IMHO the best option is not to this at all. SONAME changes in libraries low in the stack are simply quite problematic. It is OK for leaf libraries with a limited number of users, but even there barely so. While we can rebuild distro packages, user programs will still require relinking, making users angry. What about just doing 2. instead, so that we can make certain that *new* builds are not trying to use those functions. glibc doesn't change SONAME, libsystemd doesn't change SONAME, etc. We have symbol versioning, which allows precise dependencies on specific symbols. Use that instead, just never remove any symbols, but only add new ones. Symbol versioning is nicely integrated with rpm dependency autogenerators, so packages get granular dependencies on the specific symbols they use. Returning to the original question: if you absolutely must do an incompatible SONAME, then please provide a compat package with the old SONAME. Maybe it could even be built from the same sources. But it seems that the only motivation in this particular case is legal pretend-work (since the functions were already stubbed out, just removing the stub has no functional effect except ticking off a box somewhere). That just doesn't seem like a good enough motivation to go through the work for both packagers and users. > This means I will need to change the SONAME for > libtirpc which will effect a large other packages. 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
Fedora-33-20201019.0 compose check report
No missing expected images. Failed openQA tests: 2/181 (x86_64) ID: 701335 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/701335 ID: 701345 Test: x86_64 Workstation-live-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/701345 Soft failed openQA tests: 10/181 (x86_64) (Tests completed, but using a workaround for a known bug) ID: 701287 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/701287 ID: 701306 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/701306 ID: 701333 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/701333 ID: 701346 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/701346 ID: 701366 Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/701366 ID: 701369 Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/701369 ID: 701383 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/701383 ID: 701395 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/701395 ID: 701417 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/701417 ID: 701420 Test: x86_64 universal upgrade_2_minimal_uefi@uefi URL: https://openqa.fedoraproject.org/tests/701420 Passed openQA tests: 169/181 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
Arnoldas Skinderis writes: I'am also have Thikpads and MSI running BIOS and some of those machines still are the beast in some terms. Dropping BIOS would pretty much force me to use something else. I don't want to lose Fedora. Ditto. My Thinkpad W520 is the best damn Fedora laptop. Ever. I have two newer laptops, they run Fedora just fine, but the legendary Thinkpad keyboard is generations ahead of the crappy chiclets on the other one. Laughably easy to maintain. In the ten or so years I had it, I only had to replace that keyboard once, that's it. Oh, and put a new touchpad sticker, to replace the worn-out membrane cover. This beast, as long as it can still run Fedora, will likely outlive me, and I'll have to will it to someone… pgpXQY6J1Akw_.pgp 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 33 Candidate RC-1.2 Available Now!
According to the schedule [1], Fedora 33 Candidate RC-1.2 is now available for testing. Please help us complete all the validation testing! For more information on release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Test coverage information for the current release can be seen at: https://www.happyassassin.net/testcase_stats/33 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_33_RC_1.2_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_33_RC_1.2_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_33_RC_1.2_Base https://fedoraproject.org/wiki/Test_Results:Fedora_33_RC_1.2_Server https://fedoraproject.org/wiki/Test_Results:Fedora_33_RC_1.2_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_33_RC_1.2_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_33_RC_1.2_Security_Lab All RC priority test cases for each of these test pages [2] must pass in order to meet the RC Release Criteria [3]. Help is available on #fedora-qa on irc.freenode.net [4], or on the test list [5]. Current Blocker and Freeze Exception bugs: http://qa.fedoraproject.org/blockerbugs/current [1] http://fedorapeople.org/groups/schedule/f-33/f-33-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan [3] https://fedoraproject.org/wiki/Fedora_33_RC_Release_Criteria [4] irc://irc.freenode.net/fedora-qa [5] https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/ ___ 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: The future of legacy BIOS support in Fedora.
On 10/19/20 11:33 AM, Hans de Goede wrote: I guess those machines are more or less the cut-off point and slower machines are not worth keeping around. But that means that there still are a ton of BIOS machines worth keeping around. Note that even most sandy bridge machines do not support UEFI and those machines are still very capable. I've got ~30 non-EFI Acer TimelineX Aspire 3820Ts, circa ~ 2009-10 still in 'production' across the enterprise. e.g., dmesg | grep DMI: [0.00] DMI: Acer Aspire 3820/JM31_CP, BIOS V1.19 10/27/2010 They currently run (recently migrated) grep _NAME /etc/os-release PRETTY_NAME="Fedora 32 (Server Edition)" CPE_NAME="cpe:/o:fedoraproject:fedora:32" uname -rm 5.8.15-201.fc32.x86_64 x86_64 **ALL* have cat /proc/cpuinfo |grep "^model name" model name : Intel(R) Core(TM) i3 CPU M 370 @ 2.40GHz , 8GB RAM free totalusedfree shared buff/cache available Mem:7806944 673488 3105532 102896 4027924 6733392 Swap: 8388604 0 8388604 , 500GB ssds, hwinfo --disk | grep Device: Device: "CT1000MX500SSD1" and run libreoffice-x11-6.4.7.2-1.fc32.x86_64 VirtualBox-6.1-6.1.14_140239_fedora32-1.x86_64 (Win10 guests) Firefox 81.0.2 Thunderbird 78.3.3 as well as java --version openjdk 15 2020-09-15 OpenJDK Runtime Environment 20.9 (build 15+36) OpenJDK 64-Bit Server VM 20.9 (build 15+36, mixed mode, sharing) a number run PhpStorm 2020.3 EAP Build #PS-203.4818.52, built on October 15, 2020 &/or Eclipse Platform Version: 2020-03 (4.15) Build id: I20200305-0155 My own manages nginx/php & mariadb quite nicely as well. Are these screamin' fast? Do they have 8K screens to play video games on? No. Of course not. But they are *perfectly* serviceable/functional; and that's just one model of 'oldies' around here. All that^ is _still_ more 'juice' than many a VPS ... what it requires to make old boxes 'serve well' is some due diligence on right-sizing your kernel/app/server/tool/etc configs. AND a distro (even if it's a DIY LFS ...) that makes it possible. It really just is way too early / too soon to cut of BIOS booting support. big emphasis on the 'way'. i for one am certainly glad that that's the decision that's been taken, and that i won't have to face migrating to yet-another-OS because of bad enterprise policy decisions. esp, since Fedora's grown on me ... ___ 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: The future of legacy BIOS support in Fedora.
Hi, On 10/19/20 6:47 PM, Stephen John Smoogen wrote: > The issue is that while 'moore's' law was no longer doubling every 18months > it was still working and tasks had to be rewritten to work with more > cores/threads/etc. As that happened the software's need for more CPU power > has increased to the point were a 10+ year computer isn't very useful for > 'modern' software (browser and various applications). Instead if you want to > have something work on a 2012 system well.. just use software from 2012. It > is still available. Sure you can install Linux on that 15 year old computer > but if you have to tell the user well you can't actually use a browser, an > editor or half the things you can do on your cheapest smart-phone.. what use > is that computer? My daughter actually took a 12+ years old (one of the first 64 bit core 2 duo models) laptop (Dell Latitude E6400) with her to school for a project last week and happily ran a browser (latest firefox) and libreoffice on it without issues. Sure I've probably upgraded the RAM a bit at some point (I don't remember when I did that, so a long time ago) and I dropped in a SSD something like 5 years ago I guess. But with those 2 upgrades it still is a fine machine for a lot of things. And the PC in the living room used for netflix, disney+ and primevideo is another core 2 duo (one of the later gens) models happily doing what we ask of it; and my wife's home-office machine is another ... I guess those machines are more or less the cut-off point and slower machines are not worth keeping around. But that means that there still are a ton of BIOS machines worth keeping around. Note that even most sandy bridge machines do not support UEFI and those machines are still very capable. It really just is way too early / too soon to cut of BIOS booting support. Regards, Hans ___ 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: The future of legacy BIOS support in Fedora.
> >> This proposal was soundly rejected, so don't worry about it. > > > > That's great news. Thank you! > I am not thrilled that this has been rejected since efi support is not > so good on Fedora. How do you mean, it's supported quite well IMO with support for things like secure boot and UEFI capsule updates for updating system firmware I feel it's in quite good state with people improving on things constantly. > Devices that are BIOS can IIRC still use efi using a boot tool > installed to the MBR which emulates EFI > and than loads the EFI loader. This would be a one time step. Why bother, just adds an extra layer of complexity with no added benefits that UEFI provides. > Hopefully Fedora will have enough resources to support systemd-boot on > Fedora Silverblue, > which has never worked so far due to ostree naming conventions I see that less likely because of the need to have a already stretched team supporting yet another boot path. > https://github.com/ostreedev/ostree/issues/1951 > ___ > 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: The future of legacy BIOS support in Fedora.
On Mon, Oct 19, 2020 at 5:46 PM Damian Ivanov wrote: > > >> This proposal was soundly rejected, so don't worry about it. > > > > That's great news. Thank you! > I am not thrilled that this has been rejected since efi support is not > so good on Fedora. > Devices that are BIOS can IIRC still use efi using a boot tool > installed to the MBR which emulates EFI > and than loads the EFI loader. This would be a one time step. I believe EFI emulation would be too big to fit in the 446 bytes available in the MBR, so one would need a biosboot partition for that EFI emulator, but the other issue (as I recall) was that the EFI emulation had been using IP that may not be appropriately "free" (fat32?). Perhaps now that that IP has been contributed to OIN (and the various legal reviews and processes for Fedora to properly utilize those patents are complete) there may be a future path forward (if someone is so motivated). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1882958] perl-MIME-Base64-3.16 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1882958 --- Comment #8 from Fedora Update System --- FEDORA-MODULAR-2020-6e1fd68a2e has been pushed to the Fedora 32 Modular testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-6e1fd68a2e See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-de...@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org
[Bug 1870878] perl-Module-CoreList-5.20200820 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1870878 --- Comment #17 from Fedora Update System --- FEDORA-MODULAR-2020-6e1fd68a2e has been pushed to the Fedora 32 Modular testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-6e1fd68a2e See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-de...@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
>> This proposal was soundly rejected, so don't worry about it. > > That's great news. Thank you! I am not thrilled that this has been rejected since efi support is not so good on Fedora. Devices that are BIOS can IIRC still use efi using a boot tool installed to the MBR which emulates EFI and than loads the EFI loader. This would be a one time step. Hopefully Fedora will have enough resources to support systemd-boot on Fedora Silverblue, which has never worked so far due to ostree naming conventions https://github.com/ostreedev/ostree/issues/1951 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1870861] perl-version-0.9927 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1870861 --- Comment #4 from Fedora Update System --- FEDORA-MODULAR-2020-6e1fd68a2e has been pushed to the Fedora 32 Modular testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-6e1fd68a2e See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-de...@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org
[Bug 1880857] perl-Module-CoreList-5.20200920 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1880857 --- Comment #16 from Fedora Update System --- FEDORA-MODULAR-2020-6e1fd68a2e has been pushed to the Fedora 32 Modular testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-6e1fd68a2e See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-de...@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On Mon, Oct 19, 2020 at 8:27 PM Michael Catanzaro wrote: > On Mon, Oct 19, 2020 at 8:16 pm, Arnoldas Skinderis > wrote: > > I'am also have Thikpads and MSI running BIOS and some of those > > machines still are the beast in some terms. Dropping BIOS would > > pretty much force me to use something else. > > I don't want to lose Fedora. > > This proposal was soundly rejected, so don't worry about it. > That's great news. Thank you! > > ___ > 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: The future of legacy BIOS support in Fedora.
On Mon, Oct 19, 2020 at 8:16 pm, Arnoldas Skinderis wrote: I'am also have Thikpads and MSI running BIOS and some of those machines still are the beast in some terms. Dropping BIOS would pretty much force me to use something else. I don't want to lose Fedora. This proposal was soundly rejected, so don't worry about it. ___ 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
Removing unsupported AUTH_DES interfaces in libtirpc.
Hello, About a year ago I stub out the interfaces and had them return an error if called. No one has complained... This time I would like to remove interfaces so there will be no support whatsoever to pass some upcoming audits... This means I will need to change the SONAME for libtirpc which will effect a large other packages. The last time I did this all hell broke out so I'm trying to avoid that this time. So can someone please point me to the correct way to change a SONAME without cause total chaos tia, steved. ___ 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: The future of legacy BIOS support in Fedora.
On Mon, Oct 19, 2020 at 7:48 PM Stephen John Smoogen wrote: > > > On Mon, 19 Oct 2020 at 02:15, Subsentient > wrote: > >> I figure I'll add my two cents for as little as that's worth. >> >> Personally, I use extlinux with a custom, barebones configuration. On my >> EFI systems, I use syslinux EFI. I like the simplicity of syntax for >> syslinux's configuration and how small it is, but that's me, and it's not >> going to be everyone's preference. >> >> I also own several legacy BIOS based systems that cannot support EFI, and >> they work fine, including my daily driver Thinkpad T410. >> While I know it will still be possible for *very* advanced Linux users >> such as me to get Fedora working on BIOS systems with my own bootloader of >> choice even if Fedora drops support, it would create a maintenance nuisance >> if I need to boot a recovery ISO etc or reinstall Fedora from scratch, e.g. >> in drive failure. And, of course, most Fedora users can't easily swap out a >> bootloader, they just haven't spent the energy learning those parts of the >> OS. >> >> Though, that would hardly be my concern. As sad as I was to see i686 >> support dropped, I could at least understand the reasoning behind it, given >> how few people used it and how large of a maintenance task it was. I myself >> didn't really use any systems that needed it. This, however, is different. >> >> Personally, I despise GRUB2, that's why I switched to syslinux when >> distros dropped GRUB1. I find GRUB2 very bloated, needlessly complicated, >> with too many magic black boxes. >> That said, dropping BIOS support simply to adopt another bootloader in >> its place is a deeply disturbing proposition. There are many BIOS based >> systems still in service, and there will be for quite some time. >> >> My Thinkpad was manufactured in 2011 and still only supports BIOS. In >> 2012, I started seeing EFI-based PCs on the market due to Windows 8 and >> MSFT's push for secure boot. Apple was an exception, they started using EFI >> as soon as they switched to Intel. The rest of the world remained on BIOS >> until 2012. >> >> Are you seriously considering dropping support for all systems older than >> 8 years of age? Even if I could mostly work around such a decision, it >> would anger me and I imagine a great many other users, purely on >> ideological grounds. I would consider switching distributions, and I've >> been a Fedora loyalist since 2009. >> >> Do you remember when Linux was touted as a lightweight alternative for >> older PCs, and you could install flagship distros on grandma's PC to >> breathe new life into it? I do. I don't want to live in the timeline where >> the only distros that run on such things are puppy linux and similar. >> > > I'am also have Thikpads and MSI running BIOS and some of those machines still are the beast in some terms. Dropping BIOS would pretty much force me to use something else. I don't want to lose Fedora. > I think the issue is that people have rose coloured glasses about how much > 'life' we could get out of someone's older PC... and how old that desktop > was. In the 30 years I have worked in PC/Unix, I would say that before > 2004, it was rare that it breathed new life into 2+ year old technology as > much as that the Linux kernel worked with all the hardware by then. Working > on an 1985 i386 in 1993 with Linux was great, but it was not any faster > than Windows 3.11 for a lot of things. A i486 with Linux was not running as > 'fast' as a i586 with Windows 95 in 1997. You could get some better usage > from older hardware as long as you kept the tasks run meant to run in such > a 'limited' environment. But as soon as Grandpa wanted to open Netscape or > Staroffice.. you would watch a mouse crawl as you ran out of swap. > > Having upgraded lots of "Grand-pa's" computer for 2 decades, I can say > that their computers were rarely older than 4-5 years old until after 2008. > It is only after Moore's law 'broke' after 2003 stopped seeing doubling cpu > speeds every 18 months that trying to keep hardware useful longer than 5 > years has been possible. When clock speeds were no longer doubling and > 'standard' hardware memory bought came in a window of 2GB to 4 GB for a > decade, being able to keep hardware longer really started happening. At > that point, most of the time there was no giant performance boost for most > things people did on the computer and unless you were into gaming, or > professions using a CPU to its max... most people stuck with the old stuff. > > The issue is that while 'moore's' law was no longer doubling every > 18months it was still working and tasks had to be rewritten to work with > more cores/threads/etc. As that happened the software's need for more CPU > power has increased to the point were a 10+ year computer isn't very useful > for 'modern' software (browser and various applications). Instead if you > want to have something work on a 2012 system well.. just use software from > 2012. It i
Re: The future of legacy BIOS support in Fedora.
On Mon, 19 Oct 2020 at 02:15, Subsentient wrote: > I figure I'll add my two cents for as little as that's worth. > > Personally, I use extlinux with a custom, barebones configuration. On my > EFI systems, I use syslinux EFI. I like the simplicity of syntax for > syslinux's configuration and how small it is, but that's me, and it's not > going to be everyone's preference. > > I also own several legacy BIOS based systems that cannot support EFI, and > they work fine, including my daily driver Thinkpad T410. > While I know it will still be possible for *very* advanced Linux users > such as me to get Fedora working on BIOS systems with my own bootloader of > choice even if Fedora drops support, it would create a maintenance nuisance > if I need to boot a recovery ISO etc or reinstall Fedora from scratch, e.g. > in drive failure. And, of course, most Fedora users can't easily swap out a > bootloader, they just haven't spent the energy learning those parts of the > OS. > > Though, that would hardly be my concern. As sad as I was to see i686 > support dropped, I could at least understand the reasoning behind it, given > how few people used it and how large of a maintenance task it was. I myself > didn't really use any systems that needed it. This, however, is different. > > Personally, I despise GRUB2, that's why I switched to syslinux when > distros dropped GRUB1. I find GRUB2 very bloated, needlessly complicated, > with too many magic black boxes. > That said, dropping BIOS support simply to adopt another bootloader in its > place is a deeply disturbing proposition. There are many BIOS based systems > still in service, and there will be for quite some time. > > My Thinkpad was manufactured in 2011 and still only supports BIOS. In > 2012, I started seeing EFI-based PCs on the market due to Windows 8 and > MSFT's push for secure boot. Apple was an exception, they started using EFI > as soon as they switched to Intel. The rest of the world remained on BIOS > until 2012. > > Are you seriously considering dropping support for all systems older than > 8 years of age? Even if I could mostly work around such a decision, it > would anger me and I imagine a great many other users, purely on > ideological grounds. I would consider switching distributions, and I've > been a Fedora loyalist since 2009. > > Do you remember when Linux was touted as a lightweight alternative for > older PCs, and you could install flagship distros on grandma's PC to > breathe new life into it? I do. I don't want to live in the timeline where > the only distros that run on such things are puppy linux and similar. > I think the issue is that people have rose coloured glasses about how much 'life' we could get out of someone's older PC... and how old that desktop was. In the 30 years I have worked in PC/Unix, I would say that before 2004, it was rare that it breathed new life into 2+ year old technology as much as that the Linux kernel worked with all the hardware by then. Working on an 1985 i386 in 1993 with Linux was great, but it was not any faster than Windows 3.11 for a lot of things. A i486 with Linux was not running as 'fast' as a i586 with Windows 95 in 1997. You could get some better usage from older hardware as long as you kept the tasks run meant to run in such a 'limited' environment. But as soon as Grandpa wanted to open Netscape or Staroffice.. you would watch a mouse crawl as you ran out of swap. Having upgraded lots of "Grand-pa's" computer for 2 decades, I can say that their computers were rarely older than 4-5 years old until after 2008. It is only after Moore's law 'broke' after 2003 stopped seeing doubling cpu speeds every 18 months that trying to keep hardware useful longer than 5 years has been possible. When clock speeds were no longer doubling and 'standard' hardware memory bought came in a window of 2GB to 4 GB for a decade, being able to keep hardware longer really started happening. At that point, most of the time there was no giant performance boost for most things people did on the computer and unless you were into gaming, or professions using a CPU to its max... most people stuck with the old stuff. The issue is that while 'moore's' law was no longer doubling every 18months it was still working and tasks had to be rewritten to work with more cores/threads/etc. As that happened the software's need for more CPU power has increased to the point were a 10+ year computer isn't very useful for 'modern' software (browser and various applications). Instead if you want to have something work on a 2012 system well.. just use software from 2012. It is still available. Sure you can install Linux on that 15 year old computer but if you have to tell the user well you can't actually use a browser, an editor or half the things you can do on your cheapest smart-phone.. what use is that computer? > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an ema
Re: F33 beta: where are my Rust packages?
Big thanks, these were very helpful. If anyone's interested, here are the bodhi updates for the packages: - copydeps: https://bodhi.fedoraproject.org/updates/FEDORA-2020-6b5ea5655a - desed: https://bodhi.fedoraproject.org/updates/FEDORA-2020-bbc06105dd A.FI. ___ 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-IoT-33-20201019.0 compose check report
No missing expected images. Soft failed openQA tests: 1/16 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-IoT-33-20201016.0): ID: 700991 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/700991 Passed openQA tests: 15/16 (x86_64) Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default_upload: System load changed from 0.05 to 0.23 Previous test data: https://openqa.fedoraproject.org/tests/698471#downloads Current test data: https://openqa.fedoraproject.org/tests/700992#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-33-20201019.n.0 compose check report
No missing expected images. Soft failed openQA tests: 10/181 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-33-20201018.n.0): ID: 700715 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/700715 ID: 700734 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/700734 ID: 700761 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/700761 ID: 700774 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/700774 ID: 700794 Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/700794 ID: 700797 Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/700797 ID: 700811 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/700811 ID: 700823 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/700823 ID: 700845 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/700845 ID: 700848 Test: x86_64 universal upgrade_2_minimal_uefi@uefi URL: https://openqa.fedoraproject.org/tests/700848 Passed openQA tests: 171/181 (x86_64) Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: System load changed from 0.06 to 0.18 Previous test data: https://openqa.fedoraproject.org/tests/73#downloads Current test data: https://openqa.fedoraproject.org/tests/700723#downloads Installed system changes in test x86_64 Workstation-live-iso install_default_upload: Used swap changed from 32 MiB to 18 MiB System load changed from 0.76 to 0.64 Previous test data: https://openqa.fedoraproject.org/tests/700038#downloads Current test data: https://openqa.fedoraproject.org/tests/700758#downloads Installed system changes in test x86_64 Workstation-live-iso install_default@uefi: Used swap changed from 33 MiB to 18 MiB Previous test data: https://openqa.fedoraproject.org/tests/700040#downloads Current test data: https://openqa.fedoraproject.org/tests/700760#downloads Installed system changes in test x86_64 KDE-live-iso install_default_upload: Used mem changed from 1198 MiB to 909 MiB Used swap changed from 36 MiB to 9 MiB System load changed from 0.93 to 1.43 Previous test data: https://openqa.fedoraproject.org/tests/700057#downloads Current test data: https://openqa.fedoraproject.org/tests/700777#downloads Installed system changes in test x86_64 KDE-live-iso install_default@uefi: Used swap changed from 10 MiB to 9 MiB Previous test data: https://openqa.fedoraproject.org/tests/700198#downloads Current test data: https://openqa.fedoraproject.org/tests/700778#downloads Installed system changes in test x86_64 Silverblue-dvd_ostree-iso install_default_upload: Used swap changed from 23 MiB to 28 MiB Previous test data: https://openqa.fedoraproject.org/tests/700074#downloads Current test data: https://openqa.fedoraproject.org/tests/700794#downloads Installed system changes in test x86_64 Silverblue-dvd_ostree-iso install_default@uefi: System load changed from 0.33 to 0.50 Previous test data: https://openqa.fedoraproject.org/tests/700077#downloads Current test data: https://openqa.fedoraproject.org/tests/700797#downloads Installed system changes in test x86_64 universal install_package_set_kde: Used swap changed from 5 MiB to 5 MiB Average CPU usage changed from 7.62857143 to 22.2667 Previous test data: https://openqa.fedoraproject.org/tests/700118#downloads Current test data: https://openqa.fedoraproject.org/tests/700838#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-Rawhide-20201019.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 24 of 43 required tests failed, 17 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 95/181 (x86_64) Old failures (same test failed in Fedora-Rawhide-20201018.n.0): ID: 700379 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/700379 ID: 700380 Test: x86_64 Server-dvd-iso install_vncconnect_server URL: https://openqa.fedoraproject.org/tests/700380 ID: 700386 Test: x86_64 Server-dvd-iso install_vnc_server URL: https://openqa.fedoraproject.org/tests/700386 ID: 700398 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/700398 ID: 700417 Test: x86_64 Everything-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/700417 ID: 700418 Test: x86_64 Everything-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/700418 ID: 700421 Test: x86_64 Workstation-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/700421 ID: 700439 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/700439 ID: 700480 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/700480 ID: 700507 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/700507 ID: 700508 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/700508 ID: 700525 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/700525 ID: 700528 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/700528 ID: 700541 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/700541 ID: 700611 Test: x86_64 Server-dvd-iso install_repository_hd_variation URL: https://openqa.fedoraproject.org/tests/700611 ID: 700612 Test: x86_64 Server-boot-iso install_default **GATING** URL: https://openqa.fedoraproject.org/tests/700612 ID: 700613 Test: x86_64 Everything-boot-iso install_default **GATING** URL: https://openqa.fedoraproject.org/tests/700613 ID: 700614 Test: x86_64 Server-boot-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/700614 ID: 700615 Test: x86_64 Everything-boot-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/700615 ID: 700616 Test: x86_64 KDE-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/700616 ID: 700632 Test: x86_64 universal install_blivet_resize_lvm URL: https://openqa.fedoraproject.org/tests/700632 ID: 700633 Test: x86_64 universal install_delete_pata **GATING** URL: https://openqa.fedoraproject.org/tests/700633 ID: 700634 Test: x86_64 Workstation-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/700634 ID: 700641 Test: x86_64 universal install_mirrorlist_graphical **GATING** URL: https://openqa.fedoraproject.org/tests/700641 ID: 700647 Test: x86_64 universal install_multi **GATING** URL: https://openqa.fedoraproject.org/tests/700647 ID: 700652 Test: x86_64 universal install_simple_free_space URL: https://openqa.fedoraproject.org/tests/700652 ID: 700653 Test: x86_64 universal install_sata **GATING** URL: https://openqa.fedoraproject.org/tests/700653 ID: 700654 Test: x86_64 universal install_resize_lvm URL: https://openqa.fedoraproject.org/tests/700654 ID: 700655 Test: x86_64 universal install_software_raid URL: https://openqa.fedoraproject.org/tests/700655 ID: 700656 Test: x86_64 universal install_delete_partial URL: https://openqa.fedoraproject.org/tests/700656 ID: 700657 Test: x86_64 Workstation-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/700657 ID: 700658 Test: x86_64 universal install_repository_http_graphical **GATING** URL: https://openqa.fedoraproject.org/tests/700658 ID: 700659 Test: x86_64 universal install_sata@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/700659 ID: 700660 Test: x86_64 universal install_delete_pata@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/700660 ID: 700661 Test: x86_64 Server-dvd-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/700661 ID: 700662 Test: x86_64 universal install_multi_empty URL: https://openqa.fedoraproject.org/tests/700662 ID: 700663 Test: x86_64 Server-dvd-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/700663 ID: 700688 Test: x86_64 universal install_simple_encrypted URL: https://openqa.fedoraproject.org/tests/700688 ID: 700690 Test: x86_64 universal install_multi@uefi **GATING** URL: https://openqa.fedoraproject.org
[Test-Announce] Fedora-IoT 33 RC 20201019.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora-IoT 33 RC 20201019.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 Test coverage information for the current release can be seen at: https://www.happyassassin.net/testcase_stats/33iot 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-IoT_33_RC_20201019.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_33_RC_20201019.0_General 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: Package downgrades from fedora 32 -> fedora 33 (updated + annotated list inside)
On Sat, Oct 03, 2020 at 12:53:28AM +0200, Fabio Valentini wrote: > - strace is newer in 32 than in 33: > 0:5.8-1.fc32 > 0:5.7.0.6.7ab6-1.fc33 FWIW, the 5.9-1 version is available (but not in stable). ___ 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 33 compose report: 20201019.n.0 changes
OLD: Fedora-33-20201018.n.0 NEW: Fedora-33-20201019.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 0 Dropped packages:0 Upgraded packages: 0 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 0 B Size of downgraded packages: 0 B Size change of upgraded packages: 0 B Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = = DOWNGRADED PACKAGES = ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora rawhide compose report: 20201019.n.0 changes
OLD: Fedora-Rawhide-20201018.n.0 NEW: Fedora-Rawhide-20201019.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 0 Dropped packages:0 Upgraded packages: 41 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 1.56 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 407.56 KiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: adobe-afdko-3.5.1-1.fc34 Old package: adobe-afdko-3.4.0-3.fc33 Summary: Adobe Font Development Kit for OpenType RPMs: adobe-afdko Size: 4.63 MiB Size change: 10.51 KiB Changelog: * Fri Oct 16 2020 Vishal Vijayraghavan - 3.5.1-1 - Build for latest release 3.5.1 Package: apitrace-9.0-0.10.git1aa8391.fc34 Old package: apitrace-9.0-0.9.git433f99b.fc33 Summary: Tools for tracing OpenGL RPMs: apitrace apitrace-gui apitrace-libs Size: 17.83 MiB Size change: 150.89 KiB Changelog: * Sun Oct 18 2020 Sandro Mani - 9.0-0.10.git1aa8391 - Update to git 1aa8391 Package: bpytop-1.0.43-1.fc34 Old package: bpytop-1.0.42-1.fc34 Summary: Linux/OSX/FreeBSD resource monitor RPMs: bpytop Size: 64.55 KiB Size change: 286 B Changelog: * Sun Oct 18 2020 Artem Polishchuk - 1.0.43-1 - build(update): 1.0.43 Package: chisel-1.7.2-1.fc34 Old package: chisel-1.7.1-1.fc34 Summary: TCP tunnel over HTTP RPMs: chisel golang-github-jpillora-chisel-devel Size: 14.17 MiB Size change: -9.22 KiB Changelog: * Sun Oct 18 2020 Fabian Affolter - 1.7.2-1 - Update ot latest upstream release 1.7.2 (#1889172) Package: chromium-86.0.4240.75-1.fc34 Old package: chromium-85.0.4183.121-2.fc34 Summary: A WebKit (Blink) powered web browser RPMs: chrome-remote-desktop chromedriver chromium chromium-common chromium-headless Size: 420.07 MiB Size change: 445.46 KiB Changelog: * Wed Oct 14 2020 Tom Callaway - 86.0.4240.75-1 - update to 86.0.4240.75 Package: cockpit-230-1.fc34 Old package: cockpit-229-1.fc34 Summary: Web Console for Linux servers RPMs: cockpit cockpit-bridge cockpit-dashboard cockpit-doc cockpit-kdump cockpit-machines cockpit-networkmanager cockpit-packagekit cockpit-pcp cockpit-selinux cockpit-sosreport cockpit-storaged cockpit-system cockpit-tests cockpit-ws Size: 19.54 MiB Size change: 150.76 KiB Changelog: * Wed Oct 14 2020 Sanne Raymaekers - 230-1 - storage: List entries from /etc/crypttab that are still locked Package: dlib-19.20-7.fc34 Old package: dlib-19.20-6.fc33 Summary: A modern C++ toolkit containing machine learning algorithms RPMs: dlib dlib-devel dlib-doc python3-dlib Size: 27.75 MiB Size change: -3.71 KiB Changelog: * Fri Oct 02 2020 Miro Hron??ok - 19.20-7 - Changes/Python Upstream Architecture Names Package: dummy-test-package-crested-0-1925 Old package: dummy-test-package-crested-0-1912 Summary: Dummy Test Package called Crested RPMs: dummy-test-package-crested Size: 124.98 KiB Size change: 844 B Changelog: * Sun Oct 18 2020 packagerbot - 0-1913 - rebuilt * Sun Oct 18 2020 packagerbot - 0-1914 - rebuilt * Sun Oct 18 2020 packagerbot - 0-1915 - rebuilt * Sun Oct 18 2020 packagerbot - 0-1916 - rebuilt * Sun Oct 18 2020 packagerbot - 0-1917 - rebuilt * Sun Oct 18 2020 packagerbot - 0-1918 - rebuilt * Sun Oct 18 2020 packagerbot - 0-1919 - rebuilt * Sun Oct 18 2020 packagerbot - 0-1920 - rebuilt * Sun Oct 18 2020 packagerbot - 0-1921 - rebuilt * Sun Oct 18 2020 packagerbot - 0-1922 - rebuilt * Sun Oct 18 2020 packagerbot - 0-1923 - rebuilt * Mon Oct 19 2020 packagerbot - 0-1924 - rebuilt * Mon Oct 19 2020 packagerbot - 0-1925 - rebuilt Package: dummy-test-package-gloster-0-1811.fc34 Old package: dummy-test-package-gloster-0-1797.fc34 Summary: Dummy Test Package called Gloster RPMs: dummy-test-package-gloster Size: 116.83 KiB Size change: 921 B Changelog: * Sun Oct 18 2020 packagerbot - 0-1798 - rebuilt * Sun Oct 18 2020 packagerbot - 0-1799 - rebuilt * Sun Oct 18 2020 packagerbot - 0-1800 - rebuilt * Sun Oct 18 2020 packagerbot - 0-1801 - rebuilt * Sun Oct 18 2020 packagerbot - 0-1802 - rebuilt * Sun Oct 18 2020 packagerbot - 0-1803 - rebuilt * Sun Oct 18 2020 packagerbot - 0-1804 - rebuilt * Sun Oct 18 2020 packagerbot - 0-1805 - rebuilt * Sun Oct 18 2020 packagerbot - 0-1806 - rebuilt * Sun Oct 18 2020 packagerbot - 0-1807 - rebuilt * Sun Oct 18 2020 packagerbot - 0-1808 - rebuilt * Mon Oct 19 2020 packagerbot - 0-1809 - rebuilt * Mon Oct 19 2020 packagerbot - 0-1810 - rebuilt
perl-HTML-CalendarMonthSimple license change : Public Domain -> BSD
Hi, perl-HTML-CalendarMonthSimple was previously tagged as Public Domain, but upstream added a LICENSE file to 1.26 release, so I changed the License tag to BSD accordingly. Regards, Xavier ___ 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-Cloud-31-20201019.0 compose check report
No missing expected images. Passed openQA tests: 7/7 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Orphaned packages (including pdc-client) looking for new maintainers
The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/ This report is available at: https://churchyard.fedorapeople.org/orphans-2020-10-19.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager.fedorainfracloud.org/ For all orphaned packages, see https://packager.fedorainfracloud.org/orphan Package (co)maintainersStatus Change apache-commons-configuration fnasser, mizdebsk, orphan, spike1 weeks ago celt071orphan 0 weeks ago huborphan, ralph, sgallagh 2 weeks ago jboss-interceptors-1.2-api orphan 5 weeks ago jboss-jsf-2.1-api orphan 1 weeks ago log4j12mizdebsk, orphan5 weeks ago metadata-extractor2cquad, orphan 1 weeks ago nodejs-http-signature nodejs-sig, orphan, patches 5 weeks ago nodejs-node-static nodejs-sig, orphan, tdawson 5 weeks ago nodejs-noptnodejs-sig, orphan, patches 5 weeks ago pdc-client bliu, chcao, cheng, chuzhang, 1 weeks ago lholecek, lsedlar, nphilipp, orphan perl-Math-FFT orphan 0 weeks ago pipsi orphan, python-sig 3 weeks ago powermock dchen, jerboaa, lef, neugens, 2 weeks ago orphan pyqtrailer orphan 1 weeks ago python-XStatic-jQuery openstack-sig, orphan, rdopiera 2 weeks ago python-beanbag orphan 1 weeks ago python-dpath orphan 1 weeks ago python-libsass orphan 1 weeks ago pytrailer orphan 1 weeks ago vdr-skinsoppalusikka orphan 4 weeks ago vtun orphan 3 weeks ago The following packages require above mentioned packages: Depending on: celt071 (1), status change: 2020-10-17 (0 weeks ago) mumble (maintained by: carlwgeorge) mumble-1.3.2-2.fc34.src requires celt071-devel = 0.7.1-20.fc33 mumble-1.3.2-2.fc34.x86_64 requires celt071(x86-64) = 0.7.1-20.fc33 Depending on: jboss-interceptors-1.2-api (1), status change: 2020-09-13 (5 weeks ago) geronimo-jcdi-1.1-api (maintained by: jjelen) geronimo-jcdi-1.1-api-1.0-10.fc33.src requires mvn(org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.2_spec) = 1.0.1.Final Depending on: jboss-jsf-2.1-api (1), status change: 2020-10-06 (1 weeks ago) apache-commons-chain (maintained by: jjelen) apache-commons-chain-1.2-24.fc33.noarch requires mvn(org.jboss.spec.javax.faces:jboss-jsf-api_2.1_spec) = 2.0.2.Final apache-commons-chain-1.2-24.fc33.src requires mvn(org.jboss.spec.javax.faces:jboss-jsf-api_2.1_spec) = 2.0.2.Final Depending on: log4j12 (3), status change: 2020-09-13 (5 weeks ago) apache-commons-configuration (maintained by: fnasser, mizdebsk, orphan, spike) apache-commons-configuration-1.10-15.fc32.src requires mvn(log4j:log4j:1.2.17) = 1.2.17 apache-log4j-extras (maintained by: coolsvap, gil, moceap) apache-log4j-extras-1.2.17.1-18.fc33.noarch requires mvn(log4j:log4j:1.2.17) = 1.2.17 apache-log4j-extras-1.2.17.1-18.fc33.src requires mvn(log4j:log4j:1.2.17) = 1.2.17 azureus (maintained by: djuran) azureus-5.7.6.0-13.fc34.noarch requires log4j12 = 1.2.17-30.fc34 azureus-5.7.6.0-13.fc34.src requires log4j12 = 1.2.17-30.fc34 Depending on: nodejs-nopt (2), status change: 2020-09-08 (5 weeks ago) nodejs-markdown (maintained by: nodejs-sig, patches, sdgathman) nodejs-markdown-0.5.0-13.fc32.noarch requires npm(nopt) = 3.0.6 nodejs-touch (maintained by: jsmith)
Fedora-Cloud-32-20201019.0 compose check report
No missing expected images. Soft failed openQA tests: 1/7 (x86_64) (Tests completed, but using a workaround for a known bug) ID: 700314 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/700314 Passed openQA tests: 6/7 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Next Open NeuroFedora Meeting: 1300 UTC on Monday, 19th October (today)
Hello everyone, Please join us at the next Open NeuroFedora team meeting today at 1300UTC in #fedora-neuro on IRC (Freenode). The meeting is a public meeting, and open for everyone to attend. https://webchat.freenode.net/?channels=#fedora-neuro The channel is bridged to Telegram, so you can also join us there on the @NeuroFedora group: https://t.me/NeuroFedora You can convert the meeting time to your local time using this command in a terminal: $ date --date='TZ="UTC" 1300 today' or you can use this link: https://www.timeanddate.com/worldclock/fixedtime.html?msg=NeuroFedora+Meeting&iso=20201019T13&p1=1440&ah=1 The meeting will be chaired by @ankursinha. The agenda for the meeting is: - New introductions and roll call. - Tasks from last week's meeting: https://meetbot.fedoraproject.org/sresults/?group_id=fedora-neuro&type=channel https://meetbot-raw.fedoraproject.org/fedora-neuro/2020-10-05/%22neurofedora%22.2020-10-05-13.05.html - Open Pagure tickets: https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open&tags=S%3A+Next+meeting - Open NeuroFedora bugs: https://tinyurl.com/neurofedora-bugs - Koschei packages check: https://koschei.fedoraproject.org/groups/neuro-sig - CompNeuro lab compose status check. - Neuroscience query of the week. - Next meeting day, and chair. - Open floor. 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