Re: Fedora CI - installability gone wild, cannot dnf install base packages
Adam, again hank you. I clicked too soon for the previous email. With flatpack, I can launch aisleriot from the gui, but while in terminal mode, with the icon in the dash, no such luck. No aisleriot with sudo dnf install aisleriot or with sudo dnf reinstall aisleriot I am aware of grub install being version 0.5. I have much trepidation of it not working right. Just today before responding (3 hrs ago) I did a fresh install of Fedora41. After grub giving me the device selection, and my selecting the device, grub gives me three options. (1) Automatic, for my tests, works A-1. The second option shows me my previous partition assignments, but won't accept to properly handle btrfs partitions. We know we cannot reuse a btrfs partition, but must create a new one. (No message re unable to reuse btrfs). For the third option, via the submenu, I tried to rm via the option to delete selective partitions, it would tell me it was done, but then I was unable to assign new partitions. I dont know why it was waiting. I tried to backout and try a second time. No luck. This work had to be done in pre-preparation, before launching the installation. I know your Mr QA, and have the smarts to make fixes, but perhaps you can provide the delopper(s) with proof of my issues. I am prepared to do once/day forward testing of the overnight stuff, if that will help you. I am perhaps out of place, but focus on grub. I mentioned option 3 to manually setup a partition where the submenu to choose format(partition/btrfs) with details if there is a mid-process correction attempted. You get a lockup, forcing reboot. LeslieAgain, thank you for your response. And by-the-way, the very latest grub2-mkconfig does indentify, but does not build the entry for Fedora40, or earlier Fedora release. My bios allows me, on fresh boot, to do a drive select. I always use a full drive (4 such for testing, 2 nvme, 2 SSD). Adam, many years ago I lived in Vancouver, on Spanish Banks, while I attended UBC. I know you live in Vancouver or suburb. Enjoy a great province. On Saturday, September 14, 2024 at 11:41:00 a.m. EDT, Adam Williamson wrote: On Sat, 2024-09-14 at 03:33 +, Chen Chen wrote: > I just made a PR on https://src.fedoraproject.org/rpms/glfw/pull-request/6 > Then the installability test failed because it got a 403 on "dnf install > createrepo_c". > https://artifacts.dev.testing-farm.io/ef6b74c1-7335-499c-a15a-c367b6dfa25a/ > > Checked that the package indeed lives in el8 > > [root@sirius ~]# dnf info createrepo_c-libs > > Last metadata expiration check: 2:04:56 ago on Sat 14 Sep 2024 09:11:34 AM > > CST. > > Available Packages > > Name : createrepo_c-libs > > Version : 0.17.7 > > Release : 6.el8 > > Architecture : x86_64 > > Size : 115 k > > Source : createrepo_c-0.17.7-6.el8.src.rpm > > Repository : appstream > > Summary : Library for repodata manipulation > > URL : https://github.com/rpm-software-management/createrepo_c > > License : GPLv2+ > > Description : Libraries for applications using the createrepo_c library > > : for easy manipulation with a repodata. > > and the URL from the log is not accessible from public Internet > > wget > > https://composes.stream.centos.org/stream-8/production/latest-CentOS-Stream/compose/AppStream/x86_64/os/Packages/createrepo_c-0.17.7-6.el8.x86_64.rpm > > Connecting to composes.stream.centos.org > > (composes.stream.centos.org)|2600:9000:271a:a800:16:bca0:9700:93a1|:443... > > connected. > > HTTP request sent, awaiting response... 403 Forbidden > > 2024-09-14 11:23:04 ERROR 403: Forbidden. > > How can I trigger another CI run and whom should I report this problem to? > testing-farm.io or CI group guys? The problem is not in CI, it's in CentOS infra - that URL ought to work fine but is currently 403. I've filed a ticket at https://pagure.io/centos-infra/issue/1495 , hopefully that will get it resolved. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ 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
Re: Donate 1 minute of your time to test upgrades from F40 to F41
I have frustrations with bugzilla, and please, if you can, try the following sudo dnf/dnf5 install meld aisleriot With every days F41 update the above crashes, and then... dnf update (always fails to fetch updates) Thanks in advance Leslie Satenstein On Wednesday, September 4, 2024 at 06:37:58 a.m. EDT, Ben Beasley wrote: It looks like most or all of these issues come from the third-party signal-libringrtc package, which I think must have come from https://download.opensuse.org/repositories/network:/im:/signal/Fedora_40/x86_64/. It would have to be rebuilt for Fedora 41. It doesn’t look like there is a https://download.opensuse.org/repositories/network:/im:/signal/Fedora_41/x86_64/ yet. On 9/3/24 8:32 AM, Globe Trotter via devel wrote: > $ sudo dnf --releasever=41 --enablerepo=updates-testing --assumeno distro-sync > Last metadata expiration check: 0:01:26 ago on Tue 03 Sep 2024 07:30:01 AM > CDT. > Error: > Problem 1: problem with installed package >signal-libringrtc-2.46.1-1.1.x86_64 > - package signal-libringrtc-2.46.1-1.1.x86_64 from @System requires >libabsl_strings.so.2401.0.0()(64bit), but none of the providers can be >installed > - package signal-libringrtc-2.46.1-1.1.x86_64 from @System requires >libabsl_throw_delegate.so.2401.0.0()(64bit), but none of the providers can be >installed > - package signal-libringrtc-2.46.1-1.1.x86_64 from network_im_signal >requires libabsl_strings.so.2401.0.0()(64bit), but none of the providers can >be installed > - package signal-libringrtc-2.46.1-1.1.x86_64 from network_im_signal >requires libabsl_throw_delegate.so.2401.0.0()(64bit), but none of the >providers can be installed > - abseil-cpp-20240116.2-1.fc40.x86_64 from @System does not belong to a >distupgrade repository > Problem 2: problem with installed package nodejs-electron-30.4.0-2.3.x86_64 > - package nodejs-electron-30.4.0-2.3.x86_64 from @System requires >libabsl_cord.so.2401.0.0()(64bit), but none of the providers can be installed > - package nodejs-electron-30.4.0-2.3.x86_64 from @System requires >libabsl_cordz_info.so.2401.0.0()(64bit), but none of the providers can be >installed > - package nodejs-electron-30.4.0-2.3.x86_64 from @System requires >libabsl_hash.so.2401.0.0()(64bit), but none of the providers can be installed > - package nodejs-electron-30.4.0-2.3.x86_64 from @System requires >libabsl_int128.so.2401.0.0()(64bit), but none of the providers can be installed > - package nodejs-electron-30.4.0-2.3.x86_64 from @System requires >libabsl_raw_hash_set.so.2401.0.0()(64bit), but none of the providers can be >installed > - package nodejs-electron-30.4.0-2.3.x86_64 from @System requires >libabsl_raw_logging_internal.so.2401.0.0()(64bit), but none of the providers >can be installed > - package nodejs-electron-30.4.0-2.3.x86_64 from @System requires >libabsl_spinlock_wait.so.2401.0.0()(64bit), but none of the providers can be >installed > - package nodejs-electron-30.4.0-2.3.x86_64 from @System requires >libabsl_status.so.2401.0.0()(64bit), but none of the providers can be installed > - package nodejs-electron-30.4.0-2.3.x86_64 from @System requires >libabsl_statusor.so.2401.0.0()(64bit), but none of the providers can be >installed > - package nodejs-electron-30.4.0-2.3.x86_64 from @System requires >libabsl_str_format_internal.so.2401.0.0()(64bit), but none of the providers >can be installed > - package nodejs-electron-30.4.0-2.3.x86_64 from @System requires >libabsl_strings.so.2401.0.0()(64bit), but none of the providers can be >installed > - package nodejs-electron-30.4.0-2.3.x86_64 from @System requires >libabsl_synchronization.so.2401.0.0()(64bit), but none of the providers can be >installed > - package nodejs-electron-30.4.0-2.3.x86_64 from @System requires >libabsl_throw_delegate.so.2401.0.0()(64bit), but none of the providers can be >installed > - package nodejs-electron-30.4.0-2.3.x86_64 from @System requires >libabsl_time.so.2401.0.0()(64bit), but none of the providers can be installed > - package nodejs-electron-30.4.0-2.3.x86_64 from network_im_signal >requires libabsl_cord.so.2401.0.0()(64bit), but none of the providers can be >installed > - package nodejs-electron-30.4.0-2.3.x86_64 from network_im_signal >requires libabsl_cordz_info.so.2401.0.0()(64bit), but none of the providers >can be installed > - package nodejs-electron-30.4.0-2.3.x86_64 from network_im_signal >requires libabsl_hash.so.2401.0.0()(64bit), but none of the providers can be >installed > - package nodejs-electron-30.4.0-2.3.x86_64 from network_im_signal >requires libabsl_int128.so.2401.0.0()(64bit), but none of the providers can be >installed > - package nodejs-electron-30.4.0-2.3.x86_64 from network_im_signal >requires libabsl_raw_hash_set.so.2401.0.0()(64bit), but none of the providers >can be installed > - package nodejs-electron-30.4.0-2.3.x86_64 from network_im
Fellow Fedora Linux User, and Q/A leader Can't use aisleriot and MELD.
I am on the mailing list but don't know where to post bug--omission. Bugzilla, at times, is a pita to use. The Aisleriot game, and also the MELD graphical diff command are missing some libraries.It is one/some python items that are missing and used by at least the two mentioned. Leslie Satenstein On Monday, August 26, 2024 at 02:14:53 a.m. EDT, Adam Williamson wrote: # F10 Blocker Review meeting # Date: 2024-08-26 # Time: 16:00 UTC # Location: https://matrix.to/#/#blocker-review:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org Hi folks! It's time for a Fedora 41 blocker review meeting! We have 1 proposed blocker and 1 proposed freeze exception for Beta, and 2 proposed blockers for Final. Here is a handy link which should show you the meeting time in your local time: https://www.timeanddate.com/worldclock/fixedtime.html?msg=Fedora+41+Blocker+review+meeting&iso=20240826T16&p1=1440&ah=2 The meeting will be on Matrix. Click the link above to join in a web client - you can authenticate with your FAS account - or use a dedicated client of your choosing. If you have time today, you can take a look at the proposed or accepted blockers before the meeting - the full lists can be found here: https://qa.fedoraproject.org/blockerbugs/ . Remember, you can also now vote on bugs outside of review meetings! If you look at the bug list in the blockerbugs app, you'll see links labeled "Vote!" next to all proposed blockers and freeze exceptions. Those links take you to tickets where you can vote. https://pagure.io/fedora-qa/blocker-review has instructions on how exactly you do it. We usually go through the tickets shortly before the meeting and apply any clear votes, so the meeting will just cover bugs where there wasn't a clear outcome in the ticket voting yet. **THIS MEANS IF YOU VOTE NOW, THE MEETING WILL BE SHORTER!** We'll be evaluating these bugs to see if they violate any of the Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F40 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Have a good day and see you tomorrow! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Pyliblo3 fails to build on Fedora 41 with python 3.13.0
Add to the following, "Aisleriot" and "Meld" I definitely need "Meld". Leslie Satenstein On Monday, August 26, 2024 at 12:22:18 p.m. EDT, Adam Williamson wrote: On Mon, 2024-08-26 at 07:40 +, Martin Gansser wrote: > I am trying to build pyliblo3 from your repo on Fedora 41 with python 3.13.0. > I've got a build error during compilation: > > # wget https://github.com/gesellkammer/pyliblo3/archive/refs/heads/master.zip > # unzip pyliblo3-master.zip; cd pyliblo3-master; ./setup build > > root@fc41:/tmp/pyliblo3-master# ./setup.py build > running build > running build_py > creating build > creating build/lib.linux-x86_64-cpython-313 > creating build/lib.linux-x86_64-cpython-313/pyliblo3 > copying pyliblo3/__init__.py -> build/lib.linux-x86_64-cpython-313/pyliblo3 > copying pyliblo3/_liblo.pyi -> build/lib.linux-x86_64-cpython-313/pyliblo3 > running build_ext > Compiling pyliblo3/_liblo.pyx because it changed. > [1/1] Cythonizing pyliblo3/_liblo.pyx > /usr/lib64/python3.13/site-packages/Cython/Compiler/Main.py:381: > FutureWarning: Cython directive 'language_level' not set, using '3str' for > now (Py3). This has changed from earlier releases! File: > /tmp/pyliblo3-master/pyliblo3/_liblo.pxd > tree = Parsing.p_module(s, pxd, full_module_name) > building 'pyliblo3._liblo' extension > creating build/temp.linux-x86_64-cpython-313 > creating build/temp.linux-x86_64-cpython-313/pyliblo3 > gcc -fno-strict-overflow -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 > -DNDEBUG -fcf-protection -fexceptions -fcf-protection -fexceptions > -fcf-protection -fexceptions -O3 -fPIC -Ipyliblo3 -I/usr/include > -I/usr/local/include -I/usr/include/python3.13 -c pyliblo3/_liblo.c -o > build/temp.linux-x86_64-cpython-313/pyliblo3/_liblo.o -fno-strict-aliasing > -Werror-implicit-function-declaration -Wfatal-errors > pyliblo3/_liblo.c: In function ‘__pyx_f_8pyliblo3_6_liblo__msg_callback’: > pyliblo3/_liblo.c:9011:92: error: passing argument 1 of ‘lo_blob_dataptr’ > from incompatible pointer type [-Wincompatible-pointer-types] > 9011 | __pyx_t_7 = __Pyx_PyBytes_FromCString(((unsigned char >*)lo_blob_dataptr((__pyx_v_argv[__pyx_v_i]; if (unlikely(!__pyx_t_7)) >__PYX_ERR(0, 274, __pyx_L1_error) > | > ~^~~~ > | > | > | > lo_arg * > pyliblo3/_liblo.c:1353:78: note: in definition of macro > ‘__Pyx_PyBytes_FromCString’ > 1353 | #define __Pyx_PyBytes_FromCString(s) __Pyx_PyBytes_FromString((const >char*)s) > | > ^ > compilation terminated due to -Wfatal-errors. > error: command '/usr/bin/gcc' failed with exit code 1 > > if i edit pyliblo3-master/pyliblo3/_liblo.c > and change the line 9011 to: > __pyx_t_7 = __Pyx_PyBytes_FromCString((unsigned char > *)lo_blob_dataptr(*(struct lo_blob_ **)&__pyx_v_argv[__pyx_v_i])); if > (unlikely(!__pyx_t_7)) __PYX_ERR(0, 274, __pyx_L1_error) > > pyliblo3 compiles with ./setup build. > but how can I patch this file permanently ? I'm a bit confused who you're directing this to. Who is the "you" in "your repo"? You seem to be the person who submitted the review request for this package: https://bugzilla.redhat.com/show_bug.cgi?id=2307912 If you want to maintain a package, you should probably know how to generate and include patches, it's a basic skill for package maintenance. There is a guide at https://rpm-packaging-guide.github.io/#patching-software , although for software maintained in git, I would usually do it by checking out upstream git, committing the change to my local checkout, then using git format-patch to produce a patch file and copying it to the package directory. Miro already posted a patch for this issue in the FTBFS bug for pyliblo: https://bugzilla.redhat.com/show_bug.cgi?id=2248131#c5 -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ 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/co
Re: F41 Change Proposal: Make OpenSSL distrust SHA-1 signatures by default (system-wide)
If you do not mind, I did a bit of touch-up to the opening paragraphs. A hashing function takes as input, a piece of input data, and maps it to a fixed-size output (20 bytes in case of SHA-1). Cryptographic hash functions need to satisfy several more properties, and the one we are concerned with is "collision resistance". "Collision resistance" is a measure/value of computational infeasibility, such that the finding of another input, not necessarily of the same size as the original, and experiencing that the Cryptographic hash function creates a hashed output value containing same value as the original. END OF TOUCHUP. Signatures are a different thing altogether: a bit of data attached to a message attesting that the party is in possession of the private key. For technical reasons, it's not the input data that is signed, but the hash of it; this makes hashing the weak link in our situation. With the change landed, it's the openssl composite signature verification operation that will be disabled, not everything that says SHA-1 on the tin. The kinds of scenarios that can conceivably break include: * an openssl wrapper library failing tests because the operation it exercises is now prohibited * some ill-designed protocol with no cryptographic agility (no way to switch to, say, RSA+SHA-2) will become unusable with no workaround other than allowing RSA-SHA1 back * your proprietary eye tracker drivers will fail to start or claim your license to use it is no longer valid or something * user pairing with an old unsupported iPad will see cryptic errors instead * other similarly exotic stuff which I don't even know exists and is hard to predict to fail without our detection tool or flipping the switch and seeing what breaks. The kinds of scenarios that shouldn't be affected: * you verifying a Fedora 10 ISO download with sha1sum (integrity protection) * the website you hosting using SHA1() MariaDB function for password salting (though you should better switch to SHA2()) * your $sha1$4$jtNX3nZ2$hBNaIXkt4wBI2o5rsi8KejSjNqIq entry in /etc/shadow on an old install * SHA-1 HMAC in TLS (integrity protection, doesn't need collision resistance) * other SHA-1 usage that has nothing to do with signatures Hope that clarifies things. --- Just an unrelated personal remark since I've got to the thread now: Yes, I believe the scenarios above should be broken by default and require an explicit opt-in to work again. I'm not a fan of openssl failing to provide an API to re-enable it back per-process, but, on the other hand, gnutls went this extra mile and I haven't heard of it actually being used. I still consider a system-wide opt-back-in to be better than never switching. (or even a per-process-tree one, if you use runcp). But no matter what I think of the situation though, Fedora is a community distro (that "always aims to provide the future, first") and if the Fedora community makes it clear once again that shipping secure defaults is not a desired property, I'll just relent and, likely, return with even more snark about all the "commitment to innovation" several releases later. Those unwilling to switch their crypto-policy for their proverbial eye tracker that they've already bought discontinued in 2016, and insisting that the said eye tracker now must now define the security baseline for millions of other Fedora installations: you have the means to stop me, it has been done once, and you can do it again. On Mon, Jun 10, 2024 at 1:44 PM Vít Ondruch wrote: > > I wish this proposal included some examples of what might get broken and > what will keep working. I guess I am not the only one who have very > vague understanding what is difference between "signatures" and > "hashing" or other purposes SHA1 can be used for. > > > Vít > > > Dne 08. 06. 24 v 0:43 Aoife Moloney napsal(a): > > Wiki - Changes/OpenSSLDistrustSHA1SigVer - Fedora Project Wiki > > Discussion Topic - > > F41 Change Proposal: Make OpenSSL distrust SHA-1 signatures by default > > (system-wide) > > > > This is a proposed Change for Fedora Linux. > > This document represents a proposed Change. As part of the Changes > > process, proposals are publicly announced in order to receive > > community feedback. This proposal will only be implemented if approved > > by the Fedora Engineering Steering Committee. > > > > == Summary == > > OpenSSL will no longer trust cryptographic signatures using SHA-1 by > > default, starting from Fedora 41. > > > > == Owner == > > * Name: [[User:Asosedkin| Alexander Sosedkin]] > > * Email: asose...@redhat.com > > > > > > == Detailed Description == > > We would like to deprecate SHA-1 in signatures, because chosen-prefix > > collision attacks on SHA-1 are becoming increasingly feasible. > > Specifically, SHA-1 is a Shambles claims a complexity of > > 2^63.4, and a cost of 45k US dollars, with an estimated cost of 10k US > > dollars by 2025 to find a chosen-prefix collision for a SHA-1 > > signature. >
Re: F41 Change Proposal: Anaconda as native Wayland application (System Wide)
Sounds good! Leslie Satenstein On Friday, May 31, 2024 at 11:05:14 a.m. EDT, Adam Williamson wrote: On Fri, 2024-05-31 at 13:36 +0200, Jiri Konecny wrote: > To my knowledge it shouldn't be. Fedora Workstation is already running > on Wayland by default for quite some time and even Live ISO is already > Wayland. To my knowledge Wayland don't have issues with graphics cards > in general. GNOME has a fallback mechanism where it automatically runs the X.org session if the Wayland session doesn't work. I believe that is active on the live image. Of course, as telemetry is evil, we have absolutely no idea how many Fedora users actually hit this mechanism. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Feedback wanted: Testing side-tag for switching dnf5 in Rawhide
AdamI believe in the KISS principle. Do a simplification change that does it for the great number of new Fedora users who are coming from other desktop/laptop/business systems. Linux is gaining #users. Let us make their migration to Fedora for end-user people as simple as possible for this function. Leslie Satenstein On Thursday, May 2, 2024 at 04:28:44 p.m. EDT, Adam Williamson wrote: On Thu, 2024-05-02 at 15:41 -0400, Przemek Klosowski via devel wrote: > On 5/2/24 14:34, Gary Buhrmaster wrote: > > While I follow the philosophy of updating > > regularly, there are likely some who install Fnn, and > > never update, and then would expect an update to > > Fnn+2 to work without issue(s). > > -- > > The CLI update strongly suggests doing 'dnf update --refresh' before > system-upgrade. It doesn't require it though. > > I always thought it's an odd workflow; why doesn't it just force it? > While it might take a long while to complete on a stale system, it's > recommended anyway, isn't it? I would actually hugely prefer we amend that to say `dnf --refresh offline-upgrade download; dnf offline-upgrade reboot` or so. It's a footgun as it stands. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Test-Announce] Fedora Linux 40 Final is GO Need to fix up for good grub.cfg Cant install Workstation and KDE on same system.
Even when the two distros are on separate drives. I have tested all combinations, and Fedora40 grub2-mkconfig does not allow two Fedora40's on the same system. Try it. Put F40Workstation on one drive and F40KDE on a second drive Leslie Satenstein On Thursday, April 18, 2024 at 04:45:35 p.m. EDT, Samuel Sieb wrote: On 4/18/24 12:42, Leslie Satenstein via devel wrote: > With my testing, I could not install one copy of Fedora40gnome and then > on the same system the copy of Fedora40KDE. > > Whatever came second, has a signature for grub2-mkconfig, that causes > the first F40 menuentrys to be replaced by the latter. My computer bios > shows the same duplicates. > > But I am OK with F39 and F40 being on the same drive. Please don't massively cross-post like this. Having multiple installs of Fedora on the same system is not a "supported" configuration. You're kind of on your own for that. -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Test-Announce] Fedora Linux 40 Final is GO Need to fix up for good grub.cfg Cant install Workstation and KDE on same system.
Hi Guys, With my testing, I could not install one copy of Fedora40gnome and then on the same system the copy of Fedora40KDE. Whatever came second, has a signature for grub2-mkconfig, that causes the first F40 menuentrys to be replaced by the latter. My computer bios shows the same duplicates. But I am OK with F39 and F40 being on the same drive. Leslie Satenstein On Thursday, April 18, 2024 at 02:27:24 p.m. EDT, Aoife Moloney wrote: The Fedora Linux 40 Final RC1.14 compose is GO and will be shipped live on Tuesday, 23rd April. For more information please check the Go/No-Go meeting minutes[1] or log[2], and a huge thank you to everyone involved in this release! [1] https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-04-18/f40-final-go-no-go-meeting.2024-04-18-17.01.html [2] https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-04-18/f40-final-go-no-go-meeting.2024-04-18-17.01.log.html -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Test-Announce] Re: Fedora 40 Candidate RC-1.12 Available Now! GRUB ISSUE
Yesterday, Nov10, a set of "Final candidate" for Fedora 40 was posted. Adam requested that we test it to the ends and make sure all is OK. So, I suppose positively, that tomorrow, Friday, we will know if Fedora 40 is a go/nogo. For me, as a single distro to be installed, it is ready to go. However, if you want a Gnome version on one drive, and a KDE version on a second drive, you may be out of luck. The problem I am experiencing is with each produced grub menu, each seems to prevent two Fedoras 40's from being listed within the boot menu. Not with workstation, the first, or the boot menu of the second (KDE). >From the desktop computer bios, I see both devices listed, and yes, via the >bios, I can boot the alternate Fedora40 version. However, using the bios' >presentation in order to select the Fedora Linux to boot is wrong!! I would use RH's bugzilla to report this issue, but right now, the Fedora activity is heavily focused on videos, documentation, web pages... etc. At this time, there is no "unlimited" number of people to provide Fedora 40 installation support. I will await post-install to see if grub.cfg can be less restrictive. Leslie Satenstein PSMy confignvme0 Fedora39 nvme1 Fedora40 Gnomesdax Fedora KDEsdbx Non Fedora setupsdc-sdf Empty,Backups, and available 1tb drives. -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Looking for people to be stewards of rpminspect-data-fedora
I was noticing a missing file, titled a logfile, (Who did the inspection when, and was it OK) Leslie Satenstein On Wednesday, April 10, 2024 at 10:05:34 a.m. EDT, David Cantrell wrote: On 4/9/24 17:14, Kevin Fenzi wrote: > On Tue, Apr 09, 2024 at 01:55:41PM -0400, David Cantrell wrote: >> Hello all, >> >> I am looking for multiple people to help be upstream stewards of the >> rpminspect-data-fedora project. This is a project that contains config >> files and rules for running rpminspect on Fedora builds. It is a package >> containing distribution policy. It needs people to look over it and review >> and merge contributions from other developers, do occassional releases, and >> ensure that it is updated as new releases of Fedora are started (and we get >> new dist tags). >> >> The project currently lives here: >> >> https://github.com/rpminspect/rpminspect-data-fedora >> >> But absolutely can move depending on the desires of the individuals who take >> over maintenance. I created these rules files in the data package for >> rpminspect so that different vendors can customize how rpminspect runs and >> reacts to findings. Maintenance of the rules is independent of the software >> maintenance. >> >> If you are interested, please email me directly and we can get going on the >> logistics. If you have general questions, feel free to ask here. > > I wonder if this isn't something we should have the QE or releng teams > manage... ie, adding new branch info (releng), adjusting tests (qe)? > I think that's a good idea. Syncing the creation of new dist tag files in rpminspect-data-fedora could be aligned with creating them in koji, etc. QE and rel-eng don't specifically have to own doing that work, just making sure it has been taken care of by one of the rpminspect-data-fedora stewards. Right now package maintainers can control how rpminspect runs with a local rpminspect config file in the dist-git repo. However, some things cannot be overridden with that config file so those changes have to be made in the vendor data package. So having someone review those changes and collectively sign off on them is also a good idea for process control. (An example of something that has to be in the vendor data package and cannot be in the local package's rpminspect config file is an executable that needs to carry setuid or setgid bits.) -- David Cantrell Red Hat, Inc. | Boston, MA | EST5EDT -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
I am an old geezer with about 60 years of IT experience, from mainframe to cellphone.I am self-convinced that dropping gnome for KDE as a default would be BAD.Why?Today, everyone who ones a cellphone, has on his phone a set of icons. Some are there by default, some are there as extra applications that the user added. The Cellphone user is very comfortable with Gnome. So much so, that I believe that if he was given KDE as the interface, two things would happen. a) The user will switch to Gnome, or b) The user will find a way to add his favourite applications to the desktop. What then is a compromise that will satisfy the Gnome and KDE "bigots"? Consider: The Fedora 41/42 installation program can ask the user if he prefers "Menu" or "icon" interface. The above approach satisfied both camps. Leslie Satenstein On Friday, April 5, 2024 at 08:16:54 a.m. EDT, Kevin Kofler via devel wrote: Peter Boy wrote: > I'm probably not the right person to comment on this, because I completely > abandoned Fedora Desktop when it was hit (badly) by Gnome 3. That > destroyed my daily workflow and work routines and made it unusable (for > me), or at least barely usable for serious professional work not related > to software development (and I ended up using MacOS to this day). Which is exactly why I proposed back then to make Plasma (which actually operates more similarly to GNOME 2 than GNOME 3 does) the default. :-) >> == Summary == >> Switch the default desktop experience for Workstation to KDE Plasma. >> The GNOME desktop is moved to a separate spin / edition, retaining >> release-blocking status. > > This is an absolute no-go! It would break everyone’s usage of Fedora > Workstation It would be a major change, yes. Though not really different from the aforementioned upgrade to GNOME 3 with its completely redesigned user experience, which was also done. If Workstation were never allowed to change its user experience, it would be shipping MATE nowadays, not GNOME. > and is in irreconcilable contradiction to the characteristics of an > „Edition" as defined with Fedora.next. How so? > And that is not „just“ a technical issue (the FESCo domain), but a basic > Fedora principle. If you believe a basic Fedora principle is being violated, please bring that up with the Council. > Another proposal is to make it an „Edition“. But basically, a merely KDE > Desktop is not „edition-able“. Among others, an edition is meant to cover > a specific use case and a long-term and (more or less) perfectly designed > and engineered solution for this. So we have desktop (Workstation) and > server. Among server we have several Editions, the universal Fedora > Server, container centric CoreOS, edge centric IoT and Cloud. Each of the > server-like Editions covers a destined, specific use case without > overlapping. > > For the desktop area I don’t see a non-overlapping use case between Gnome > and KDE. It’s just a different tool for the same use case. This exact argument was already used 10 years ago to reject our (that was before I left the KDE SIG, though this issue was one of the triggers for me leaving the SIG) request for a Plasma Edition. 10 years later, we still have no way out of this dilemma. The definition of an Edition needs to be refined or completely replaced to get out of this catch-22. As part of the process to look for a non-overlapping use case, there was an attempt to focus specifically on scientific applications, which eventually lead to the Scientific Lab, but that did not make it to an Edition either, just to a Lab. The overlap issue is also going to hinder other deliverables' efforts to become Editions. E.g., Silverblue mostly overlaps with Workstation and CoreOS: Workstation for the general use cases (workstation/desktop usage), CoreOS for the atomic and container-oriented use cases. > And if we are willing to accept an exception and accept KDE desktop as an > Edition, I don’t see that the current SIG qualifies as an edition-capable > working group. Given the recent discussion about Wayland / X11, I don’t > see any obligation/commitment to ensure long-term reliability and > trouble-free usability. Instead, I see in the discussion an unbridled > desire to introduce something new (that's good) without regard for > backwards compatibility and uninterrupted usability (that's bad, we need > both). And obviously the resources to manage both (Wayland and X11) in one > working group are also lacking (and given the schism, possibly also the > willingness to do so). That particular concern, however, is one that I also share. The working group should be required to accept at least one of us plasma-workspace-x11 maintainers (it can be Sérgio M. Basto or Steven A. Falco if they do not accept me) into the working group. > That may change and can change, of course. But that’s nothing for F42, > rather for F52. It just requires creating a new working group. That can be done inst
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
There is, if you add 1 extension, a category menu. That is the menu that is similar to other desktop interfaces such as Budgie, XFCE, and other. Leslie Satenstein On Thursday, April 4, 2024 at 08:03:13 a.m. EDT, Stephen Smoogen wrote: On Thu, 4 Apr 2024 at 04:38, Vít Ondruch wrote: Maybe you should give it second try. What I am going to say is not meant to be a bash in any way. I am on my 10th try for GNOME3/40. For everything they move to somewhere my brain says is intuitive, there always seems to be something else moved which I have to relearn or fight past patterns for. Just like code refactoring, I realize all the movements and changes are for good reasons versus just 'moving for movement sake'. My brain just rebels against it in an almost painful way. Again this isn't a rag on GNOME. I find that I can adapt only so much to desktop changes and prefer something which stays the same while I focus on my work. Other people find such changes easy and others find the lack of changes I want to be painful for their brains. I understand where GNOME is going and I agree that it is a purpose they should shoot for 100%. It just isn't easy for me to stay on the bus. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Topic change for one minute With the Everything.iso, there is a recovery option, which presents questions pertaining to a Fedora installation needing a security scan (eg systemctl daemon-reload). Has anyone succeeded in the recovery script working to completion? I raise the question here, as it is not a distro issue, but a recovery issue, and I do not know to which topic I should raise the bugzilla report. End of topic change. Leslie Satenstein On Wednesday, April 3, 2024 at 12:22:14 p.m. EDT, Michael Catanzaro wrote: On Tue, Apr 2 2024 at 06:18:31 PM -07:00:00, Adam Williamson wrote: > I mean, we really don't need to speculate about this much. We did an > entire overhaul of the project - Fedora.next - which was explicitly > based around making it much more focused and less of a > choose-your-own- > adventure, specifically including making the download page much more > opinionated. AFAIR, the numbers Matthew tracks strongly indicate this > was associated with a very significant immediate bump in Fedora usage. Yes, promoting Fedora Workstation over all the other desktops has been key to the success of Fedora over the past 10 years. I suspect it was the right choice, because Fedora has grown considerably from our unrelenting focus on attracting so many GNOME desktop users to the Fedora edition that receives the most investment. But there is a continuum of strategies we can use to promote our default desktop over other options, and I wonder if we've erred too far in favor of Fedora Workstation and against Fedora KDE Plasma Desktop here. The Plasma spin is much "bigger" than the other spins, it's of comparable quality to Fedora Workstation, and it is release blocking. It just seems strange to relegate it to a secondary downloads page regardless of how popular it is, while the non-desktop editions (some of which are frankly relatively niche) get featured very prominently. I'm not sure what the solution is here. Kevin's suggestion of featuring all spins equally risks overloading users with difficult choices and diluting our focus on what we do well, and I hesitate to open the doors for all spins to request a place on the main download page. I suppose I think of KDE Plasma as "special" relative to all the others due to its relatively large upstream developer community and user base, so I guess I'd like to see some way to elevate the status of Plasma in Fedora without also jeopardizing the special status of Fedora Workstation. We should have a very compelling reason if we're going to continue hiding one of our strongest products, and I don't think we do anymore. Our reputation as a quality GNOME distro has become so strong that it's not going to be damaged by other Fedora desktop offerings. So here are three brainstorming proposals: (a) Fedora KDE Plasma Desktop becomes a Fedora edition. We'd need to be careful about how we do it. I would still promote Fedora Workstation as the main/recommended "leading" desktop, would call Plasma an "alternative desktop option," and would strongly caution against use of the word "Workstation" anywhere in the branding for the Plasma version. That is, let's continue to steer undecided users towards Fedora Workstation, while making Plasma easier to find and presenting it more prominently than it is today. (b) Alternatively, elevate the positioning of all spins on the fedoraproject.org homepage. Place the link to the spins right next to the link to Fedora Workstation, above the atomic desktops (which are sadly still experimental), above the Fedora labs and ALT downloads, and honestly probably above the non-desktop Fedora editions. Nobody is going to be confused as to which one is the primary product. (c) Do both of the above, because they aren't mutually exclusive proposals. 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Hi Adam, I lived through the 2011 period, and at that time the number of people available for KDE software support was insufficient. In an earlier response I suggested that a single website is where we should be focusing more info about the various isos. We don't need a separate set of web pages per iso, as it is a disadvange. A user could browse the one Fedora site and select the ISO that suits his needs. And by the way, I started with Fedora 0.1, when the printed computer magazines had CDs with Fedora included. (grin) Yeah, I remember the big whoo-haaa when we went from 800meg CDs to 2048meg DVDS. Leslie SatensteinGrandpa, aged 83. On Tuesday, April 2, 2024 at 03:37:30 p.m. EDT, Adam Williamson wrote: On Tue, 2024-04-02 at 21:05 +0200, Kevin Kofler via devel wrote: > Aoife Moloney wrote: > > Switch the default desktop experience for Workstation to KDE Plasma. > > The GNOME desktop is moved to a separate spin / edition, retaining > > release-blocking status. > > It is funny that the KDE SIG is proposing that now. I have a sense of déjà- > vu: > https://fedoraproject.org/wiki/Features/KDE_Plasma_Desktop_by_default > > Back then, the KDE SIG was NOT willing to support my proposal (even though > the timing would have been ideal, given that GNOME was badly hit at the time > by the GNOME 3 transition and users disappointed by the radical cuts in > customizability). Now they are refloating it as their own, without even > citing my original proposal. Kevin, I know you and I have been around forever and 2011 feels like yesterday, but it was really quite a long time ago. Some of the people involved in the proposal didn't even use Fedora in 2011. Heck, there are probably people using Fedora who weren't *born* in 2011. If you compare the KDE SIG member list from May 2011 (approx. time of your old proposal) and the current one, the only people who appear on both lists are Rex Dieter and Than Ngo, neither of whom is an owner of this Change proposal. https://fedoraproject.org/wiki/SIGs/KDE https://fedoraproject.org/w/index.php?title=SIGs/KDE&oldid=239023 -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Perhaps something like the "Everything.iso" could be top-leveled on the website, to include Workstation, KDE, et al, in their full "Everything.iso" details. That will let me decide, beforehand, what it is that I want to download. Keep the individual iso-webpage relationship simple, referring to the suggested new top-level website pages. Leslie Satenstein On Tuesday, April 2, 2024 at 03:37:30 p.m. EDT, Adam Williamson wrote: On Tue, 2024-04-02 at 21:05 +0200, Kevin Kofler via devel wrote: > Aoife Moloney wrote: > > Switch the default desktop experience for Workstation to KDE Plasma. > > The GNOME desktop is moved to a separate spin / edition, retaining > > release-blocking status. > > It is funny that the KDE SIG is proposing that now. I have a sense of déjà- > vu: > https://fedoraproject.org/wiki/Features/KDE_Plasma_Desktop_by_default > > Back then, the KDE SIG was NOT willing to support my proposal (even though > the timing would have been ideal, given that GNOME was badly hit at the time > by the GNOME 3 transition and users disappointed by the radical cuts in > customizability). Now they are refloating it as their own, without even > citing my original proposal. Kevin, I know you and I have been around forever and 2011 feels like yesterday, but it was really quite a long time ago. Some of the people involved in the proposal didn't even use Fedora in 2011. Heck, there are probably people using Fedora who weren't *born* in 2011. If you compare the KDE SIG member list from May 2011 (approx. time of your old proposal) and the current one, the only people who appear on both lists are Rex Dieter and Than Ngo, neither of whom is an owner of this Change proposal. https://fedoraproject.org/wiki/SIGs/KDE https://fedoraproject.org/w/index.php?title=SIGs/KDE&oldid=239023 -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Linux 40 Beta Released
Check outIndex of /compose/branched | | | | Index of /compose/branched | | | Leslie Satenstein On Wednesday, March 27, 2024 at 04:51:18 a.m. EDT, Barry wrote: > On 26 Mar 2024, at 15:09, Kevin Fenzi wrote: > > I think it was being edited when you looked? > > It seems to have the details now? Or is there something missing? All there now. Original visible was just one line. Barry -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: openQA update test backlog - now clearing
Adam Please checkout bugzilla 2264943 I seem to have issues to post this bug where it can be reviewed on time for pre-release. Leslie Satenstein The bug readsBug 2264943 - Fedora40 anaconda Beta is not propagating keyboard selection to target system (edit) Description of problem: I use Canadian French keyboard layout. With beta 19Feb2024, workstation, I do change keyboard layout. 1) After initial (hello) setup and prior to performing the installation, I noted that the keyboard layout change to CF, is not migrated to Fedora settings (I check gnome keyboard layout and the USA layout is present). I set it manually. 2) I proceed to do the installation. 3) On reboot, the logon screen appears to be using the default (iso) keyboard layout, My keyboard includes the "#" character, and during initial login, it is being accepted on upper case 3, but CF keyboard setting has it on upper case 1, CF was not migrated to login prompt screen/window. 4) After logging in, the keyboard layouts(user and root) are correct. It is only the login screen. 5) With the beta, the computer system bios is also not fully updated. It still points to the pre-beta version (Fedora 39). Version-Release number of selected component (if applicable): Fedora 40 beta dated 19Feb2024. How reproducible: Switch keyboard layout during beta installation and then try to login using that layout. Use special character(s) in your password. Steps to Reproduce: 1. as above 2. 3. Actual results: wrong greater menu keyboard processing. Expected results: As with anaconda, (pre-new beta), the login keyboard should handle the user setup during the installation process. Additional info: I can do some tests. my email address is as above. Please note, my secondary test intalling with Everything.iso crashes before completion. On Monday, February 19, 2024 at 02:51:56 p.m. EST, Adam Williamson wrote: Hey folks! just a quick note in case anyone was waiting for openQA tests on their update. it seems one of the worker hosts got into some kind of stuck state, a lot of jobs were stuck at 'uploading'. unfortunately these are jobs that are set to *only* run on that host, so they were stuck permanently. I've rebooted that host and it's picking up the backlog now, it should work through it over the next few hours. the most-delayed update seems to be FEDORA-2024-84788cb473 , which is 16 hours old. sorry again! -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Introduction
Thank you. Leslie Satenstein On Sunday, February 4, 2024 at 06:08:37 p.m. EST, Luis Correia wrote: Hi, I'm a long time Fedora user and used to help develop the Ralink Wireless driver (rt2x00) that's been present in the kernel for a long time. I'm now entering the process of helping maintain the mixxx package over at rpmfusion. Hope to be useful with this new venture. Luis Correia -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Rawhide Beta Everything.iso and other ISOs -- btrfs -- serious issue
I am not registered as an official test person. But I have been using Fedora for the past 20 years. I have been doing some tests with KDE,Gnome,xfce (all Fedora Rawhide distros). With the Everything.iso, here is an example of a problem I have a previous kde/gnome/kde installation that has pre-existing btrfs / (eg root).The installation scripts have a checkmark indicated for reformat and I choose that for / which is, an existing btrfs that I wish to overwrite.There is no checkmark or option for delete/recreate of a btrfs partition. With the installation scripts I tested, the new anaconda balks and will not allow reformat of any previously used existing btrfs formatted partition. With the Everything.iso, there is no way to excape to root, in order to perform a delete. This shortcoming in the anaconda script means that I must exit the installation, use my existing Fedora 39 to delete the btrfs partition, and then try again. By the way, Fedora 39 Everything.iso has the delete partition (btrfs ) option Do you want me to use bugzilla to post the above? Better still if you format this email to the developer of the new anaconda interface. Leslie SatensteinPS. Existing (Fedora 39 and earlier ) anaconda works perfectly. -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Mass rebuild: git push --no-verify
AgreeThank you. See below Leslie Satenstein On Thursday, January 18, 2024 at 01:35:13 p.m. EST, kevin wrote: On Thu, Jan 18, 2024 at 09:15:18AM -0700, Jerry James wrote: > On Thu, Jan 18, 2024 at 4:50 AM Tomas Hrcka wrote: > > This is not a good idea. Because of a few packages that are not rebuilding > > we would disable the hook for every push the script does. > > My thinking is that the hook is not useful for automated build scripts > anyway, so disabling it doesn't hurt. See my previous replies in this > thread. yeah... * Current setup with the hook: Bunch of fonts don't even get touched by the mass rebuild Some other packages with problems caught by the hook also are completely missed. * With --no-verify: Bunch of fonts do rebuild in the mass rebuild Some packages with problems get a mass rebuild commit at least and attempted build. It might fail, but it's at least tried. The mass rebuild is only doing a bump/rebuild. There's no reason it should ever cause something that be caught by the hook, and if it did, it would be better for it to do the commit anyhow and cause a failed build. IMHO. So, I think we should run with --no-verify. kevin -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposals Requiring Infra Changes - Deadline Today
Sometimes it is overly burdensome to want to submit a suggestion. I have run the Rawhide Fedora 40 beta of Dec 19, 2023 and would like to propose an additional radio button for anaconda installer. There are currently three options, of which the third is not yet available. I would like to present a 4th option (o) Replace/Upgrade an existing Fedora Installation. With this additional option, I would be able, with one workspace.iso do an installation, or upgrade an existing Fedora xx to the current Fedora xx+1. The benefits. Well, as I see it, in one place, the ability to do an installation or a system upgrade. Implementing this (o) allows me to never have to redo an installation using the "Everything.iso". Leslie SatensteinMontreal, Quebec By the way, with the Holidays and New Years around the corner, may I wish all the lovers of Fedora and participants to this forum, a happy and safe holiday. If you are driving, take extra care as road conditions are "dangerously slippery in places". On Wednesday, December 20, 2023 at 09:50:10 a.m. EST, Aoife Moloney wrote: Hi all, Today is the final day to submit Change Proposals that require infrastructure changes for Fedora Linux 40. Changes do not have to be accepted by this deadline, but they must be submitted. Thanks,Aoife -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Possible deprecation/removal of Initial Setup from Fedora
I am not sure of the difference between text mode and graphical mode, except that I am an end-user of anaconda,and I use it via the Everything.iso. Therein, anaconda is a mixed mode, with text / graphical for partition management(creating, mounting,deleting) and graphical mode for application and application-group selection/subselection. FWIW, I like the existing functionality, with one suggest enhancement -- put a 2 line text description for each of the subgroups that are part of a main group. Leslie Satenstein On Monday, November 27, 2023 at 11:22:17 a.m. EST, Adam Williamson wrote: On Mon, 2023-11-27 at 14:12 +0100, mkol...@redhat.com wrote: > On Fri, 2023-11-24 at 15:15 -0800, Adam Williamson wrote: > > On Tue, 2023-11-21 at 13:34 +0100, Jiri Konecny wrote: > > > Hello everyone, > > > > > > Is Anaconda Initial Setup important for your project or workflow? > > > What > > > functionality is absolutely necessary for you? Do you use the text > > > mode > > > or the graphical mode? Are you aware of any alternatives? Is there > > > anything that would prevent you from migrating to one of the > > > proposed > > > alternatives? Also please feel free to share this mail to any > > > relevant > > > groups. > > > > In addition to the other uses identified: if you do a KDE install and > > set the root password but do not create a user account, i-s will run > > on > > first boot and allow (not sure if it requires) user creation. This is > > probably the case for other non-GNOME desktops too (GNOME uses its > > own > > gnome-initial-setup). > Sure, but is this really necessary on those images ? If it only > triggers if no user account is present only only provides user > creation, what about enforcing user creation at installation time > instead ? > > That would simplify the whole thing, as there would be less scenarios > to test/debug/go wrong. The problem, as always, is different use cases. We want to very strongly encourage people to create a user before logging in on KDE installs, as we really don't want people using KDE as root. But for a small headless install, someone might want to operate as root without a user account. Workstation has sorted this out by disabling user/root spokes in the installer entirely and having its own g-i-s which requires creation of an admin user, but we don't have anything like that in place for KDE currently. So we have to try and manage both KDE and e.g. a minimal or Server install as best we can, using essentially the same workflows. If someone wants to do some customization for KDE, of course, that could help. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Possible deprecation/removal of Initial Setup from Fedora
I am a devout anaconda bigot, and I exclusively use the Everything.iso with it. Of course, I use it via terminal mode. A feature I relish in anaconda, is the ability to manage disks and partitions.(using the right most radio button)My system has 2 SSD and 6 disks, and with anaconda, I select all of them and thenuse the mentioned disk management to build the target system along with a completed /etc/fstab. If I was looking to improve anaconda, I would add a one or two line description against each group.the right most application selection column. As well, an option to offer a way to respond to what "Gerd Hoffmann" was posting, Please do not add another tool, just embellish anaconda to include the extra functionality. Leslie Satenstein On Friday, November 24, 2023 at 06:18:47 p.m. EST, Adam Williamson wrote: On Fri, 2023-11-24 at 13:38 +0100, Jiri Konecny wrote: > Hi, > > I wonder, I thought that the server images are usually using Anaconda to > create a user during installation. Am I missing something? No, I think you're right there. initial-setup is not part of the anaconda-deployed Server package set. anaconda - as it does for all other spins/editions except Workstation - requires you to create a root password or admin user, so you can always log in. I think if initial-setup was included in the package set, it would run on boot if you didn't *both* set the root password *and* create a user (as it does on spins where it is installed, e.g. KDE), but it isn't. I tested this with a Server DVD image I had lying around; doing an install with only root password (no user created) didn't run initial- setup on boot, and rpm shows initial-setup not installed. However, as dgilmore noted, the Server ARM disk images certainly do rely on initial-setup. > > Best Regards, > Jirka > > Dne 22. 11. 23 v 13:53 Gerd Hoffmann napsal(a): > > On Tue, Nov 21, 2023 at 08:07:06AM -0800, Davide Cavalca wrote: > > > On 2023-11-21 04:34, Jiri Konecny wrote: > > > > Is Anaconda Initial Setup important for your project or workflow? What > > > > functionality is absolutely necessary for you? Do you use the text > > > > mode or the graphical mode? Are you aware of any alternatives? Is > > > > there anything that would prevent you from migrating to one of the > > > > proposed alternatives? Also please feel free to share this mail to any > > > > relevant groups. > > > The Fedora Asahi Remix uses initial-setup (in text mode) for our Server > > > and > > > Minimal variants. > > I think this is used by *all* server images. It offers to set the root > > password and add users, so without that you simply can't login ... > > > > take care, > > Gerd > > -- > > ___ > > 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 > > Do not reply to spam, report it: > > https://pagure.io/fedora-infrastructure/new_issue > -- > ___ > 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 > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 candidate composes coming - here's the plan
Hi Adam, are bugs related to Fedora gnome that I posted on the forum ignored? I and a few others have smaller / older graphics cards. They are new enough to work with the USB type cable. On all my Fedora versions, (38-40), Wayland gnome, beginning around 5 October, 2023, began locking up. Bugzilla 2241955. FYI, All three Fedora versions (38,39,40), prior to that date worked 100% with Wayland.Since that date, only the x11 versions work. (I am unable to test Rawhide 40, as it is Wayland only. I would like to see a comment in the 2241955 that it will be handled during the second week following F39 go live. Leslie Satenstein On Wednesday, October 25, 2023 at 02:24:06 p.m. EDT, Adam Williamson wrote: Hey folks! Just to keep everyone in the loop regarding F39 plans. As you may have noticed, we've slipped once or twice already (depending on whether you count the "early target date") and are in danger of slipping again. The go/no-go meeting is scheduled for tomorrow (2023- 10-26). The outstanding blockers are all Raspberry Pi-related, aside from the shim one we've been waiving for several releases and intend to waive again. Matthew Miller, Kevin Fenzi and I came up with this plan: we're going to run a compose right now without fixes for the two outstanding Pi blockers (2241252 and 2244305). If QA can get sufficient testing on this done by the go/no-go meeting, we can discuss the possibility of shipping it and noting that there are known issues with Raspberry Pi that are taking time to resolve, and Pi users should not install or upgrade to F39 until they're resolved (or something like that). If at any point a fix for 2241252 shows up, we'll run another compose with the fix included. If that gets sufficient testing by the time of the meeting, we can also consider that as a candidate to ship. If ARM team decide to attempt a fix for 2244305 we'd also pull that in, but if not, we think it's reasonable to consider revoting or waiving that bug, as it seems not to happen very commonly or consistently and the proposed "fix" apparently comes with tradeoffs of some kind. So, QA folks, please stand ready to test one or two candidate composes soon. If we wind up with two, we will consider most test results to apply to both, as the only difference should be uboot-tools; we would want to run ARM hardware tests, at least, on both composes if possible. The usual announcement mails will be sent for the completed composes. Thanks folks! -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Test-Announce] 2023-10-16 @ 15:00 UTC - Fedora QA Meeting
14 Oct version Everything.iso anaconda failed on my system at the step where it has to create the network setup for the target Gnome system. Up to that point, installation went well. Same place for workstation setup. Sorry, can't seem to post elsewhere, Someone please Leslie Satenstein On Saturday, October 14, 2023 at 02:34:57 p.m. EDT, Adam Williamson wrote: # Fedora Quality Assurance Meeting # Date: 2023-10-16 # Time: 15:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: ** #fedora-meeting on irc.libera.chat ** Greetings testers! It's time for another QA meeting. As usual lately, please note this meeting will really be *on IRC*. The Matrix bridge is still down and the meeting bot for Matrix is not quite done yet. So please use an IRC client or the web client - https://web.libera.chat/#fedora-meeting - to join. If anyone has any other items for the agenda, please reply to this email and suggest them! Thanks. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 39 status 3. Test Day / community event status 4. Open floor -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Live USB iso boot not working since Fedora 37, still broken in 39 Beta
Please look at 2241955 – Fedora 39 Wayland initialization code has something missing -- my system crashes | | | | 2241955 – Fedora 39 Wayland initialization code has something missing --... | | | Leslie Satenstein On Thursday, October 5, 2023 at 04:51:35 p.m. EDT, Adam Williamson wrote: On Thu, 2023-10-05 at 16:36 -0400, Neal Gompa wrote: > On Thu, Oct 5, 2023 at 4:03 AM Matthias Saou wrote: > > > > Hi, > > > > I continued digging some more, and it turns out there is a one liner > > fix for the issue that has been merged upstream: > > > > https://github.com/dracutdevs/dracut/pull/2196 > > > > Would there be any hope to get this backported to be included in Fedora > > 39? The scope of the change is ridiculously tiny, limited to this > > single modules.d/90dmsquash-live/iso-scan.sh file which is exclusively > > used for this broken feature. > > > > It would be really great to get the final Fedora 39 iso working again. > > > > An update has been proposed: > https://bodhi.fedoraproject.org/updates/FEDORA-2023-f71507e281 The bug still needs to be accepted as an FE for this to make final, though. https://pagure.io/fedora-qa/blocker-review/issue/1382 -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaning all my packages
Hi Todd Zullinger Got your message! Leslie Satenstein PS. I share your views. I am a senior, age 82.7 (Born Jan 1941), and while I did a great deal of QA / Testing,I am very disappointed in the direction that both the Europeans and Americans are heading. There is, underway now, a strong European attack against the government, regarding FOSS. If the government wins, much opensource will be considered propriatory. The Americans will "Monkey see, Monkey do", to incorporate the same. You made a decision that I support. Take care. On Tuesday, October 3, 2023 at 10:25:40 a.m. EDT, Todd Zullinger wrote: Hi, I'm orphaning all my packages (which I effectively did months ago). It's been fun being a maintainer since 2006. However, I am not interested in contributing to a project where the primary sponsor and downstream no longer provides source code freely and openly. It's simply not consistent with why I use and contribute to Fedora and Free/Open Source Software in general. I'm a maintainer of the following packages: cgit git paperkey I'm an admin of the following packages: fail2ban rubygem-asciidoctor I have commit privileges on these additional packages: asciidoc git-filter-repo rpmlint Thanks, -- Todd Zullinger ___ To | | | | OpenID transaction in progress | | | ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Lastpass-cli license correction
When you are back with Fedora 38,39,40, I will register and do a contribution payment. Leslie Satenstein On Friday, September 1, 2023 at 01:15:14 p.m. EDT, Robert-André Mauchin wrote: Hello Fedoreans an others, Lastpass-cli license will be corrected from GPL-2.0-only to: GPL-2.0-only WITH cryptsetup-OpenSSL-exception AND OpenSSL In the next 1.3.5 update. Which will hopefully makes the program functional again. Best regards, Robert-André ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: zlib-ng as a compat replacement for zlib
Thank you. Leslie Satenstein On Saturday, September 2, 2023 at 09:29:36 a.m. EDT, Daniel Alley wrote: Yeah, the Zstd default of 3 is tuned to be roughly on par with alternatives but much faster. To get better compression than gzip you generally need to go to higher levels. ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Dropping of sshd.socket unit
Sounds good! Leslie Satenstein On Monday, August 21, 2023 at 05:08:06 a.m. GMT-4, Lennart Poettering wrote: On Do, 17.08.23 08:25, Chris Adams (li...@cmadams.net) wrote: > Once upon a time, Lennart Poettering said: > > Yes, and if this is not what you want, then disable the > > ratelimit. That's what I am saying? > > It would be useful for systemd to have "cooldown periods" for things, > similar to inetd and classic init, where misbehaving things (whether > services or sockets) were paused for a time (configurable even) and then > returned to service. AFAIK this is a flaw in general in systemd's > limits; if something exceeds them, it takes manual intervention to reset > them. There's a TODO list item for that upstream already. https://github.com/systemd/systemd/blob/main/TODO#L153 Definitely makes sense, and should be very easy to add, the underlying concepts are all implemented, it's just a matter of exposing this under new options. Lennart -- Lennart Poettering, Berlin ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Mock v5.0 released (and mock-core-configs v39)
Will the current fixes allow test installations of the workspaces.iso? True Ivan test using the everything.iso, but we do want the installation programs to work fully What is stopping workspace installs is: gnome.display.manager Sent from Yahoo Mail on Android On Thu, Aug 10, 2023 at 3:22 p.m., Kevin Fenzi wrote: On Thu, Aug 10, 2023 at 09:58:30AM -0700, Adam Williamson wrote: > On Thu, 2023-08-10 at 08:56 -0700, Adam Williamson wrote: > > On Thu, 2023-08-10 at 10:58 +0200, Pavel Raiskup wrote: > > > Hello maintainers! > > > > > > Let me announce a new release of Mock v5.0 (the chroot build environment > > > manager for building RPMs). > > > > > > This release release brings lots of changes, though the one that I'd > > > like to underline is that we turned --use-bootstrap-image ON by default. > > > This effectively means that Mock uses Podman to pull the bootstrap image > > > from image registries (instead of installing it from scratch with `dnf > > > --installroot`). Thus Podman is now in `Recommends:`, not just > > > `Suggests:`. Should you have any issues, you can temporarily revert this > > > change with `--no-bootstrap-image` (--scrub=all first!). Alternatively > > > set `config_opts["use_bootstrap_image"] = False` in configuration. > > > > Unfortunately this seems to be broken on Rawhide, whether you use the > > 'fedora-40' or 'fedora-rawhide' name: > > Update: nirik has fixed this for now. We think the Rawhide nightly > script is messing up the registry when it runs, he'll try and fix that > later. And I think thats now fixed (was some leftover armhfp stuff. ;) kevin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]
SUSE has also jumped in to say they will provide an alternative, but compatible Linux to RH. Leslie Satenstein On Tuesday, July 11, 2023 at 06:49:38 a.m. GMT-4, Kevin Kofler via devel wrote: Oracle has (finally – the community projects Rocky and Alma were much quicker to react) made an announcement about the situation: https://www.oracle.com/news/announcement/blog/keep-linux-open-and-free-2023-07-10/ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)
>From what I read, the metrics accumulation has an option to turn off the >collection, as well as the transmission Sent from Yahoo Mail on Android On Thu, Jul 6, 2023 at 8:53 p.m., Michael Catanzaro wrote: On Thu, Jul 6 2023 at 11:08:15 PM +0200, Björn Persson wrote: > As a non-user of Gnome 3 who normally never runs any Gnome 3 settings > programs, I get the impression that Fedora 40 will begin accumulating > unused metrics somewhere in the filesystem. To prevent a constantly > growing waste of storage space, I'll have to run one of two Gnome 3 > settings programs – which may or may not require starting a Gnome 3 > desktop session – and find the right switch to either turn on > uploading > or turn off collection. I'll have to remember to do that after > upgrading around a year from now, and also on any new installations in > the distant future. > > If my impression is wrong, then the change proposal needs to be > amended. Well this change proposal is for Fedora Workstation specifically. That's in the title. :) I would envision installing eos-event-recorder-daemon via a Recommends: from the gnome-control-center and gnome-initial-setup packages (and probably also by adding it to the workstation-product comps group), so if you don't have gnome-initial-setup or gnome-control-center installed, you wouldn't get in on upgrade. I'm not sure whether I want to amend this level of detail into the change proposal in case we might want to change the specifics of how it gets installed, but that's just to give you an idea of what I'm thinking currently. Certainly the metrics components should not be installed for non-GNOME users as part of this change proposal. However, I've heard that Fedora KDE might also be interested in adding metrics once we have this working in Workstation. But that would be up to the people contributing to Fedora KDE and would need to be proposed separately. I think eos-event-recorder-daemon uses some sort of ring buffer to eventually discard old events, so that storage space does not increase forever and should not become an issue? But please don't quote me on this; I have a lot of comments to respond to, and I'm not super familiar with the code, and I don't want to dive in to look at how it works right now. If there's really an issue with space growing without bound, then that's a bug we should fix, but I don't think it's so. (BTW, the GNOME 3 era concluded with the release of GNOME 40 in Fedora 34, so I wouldn't except Fedora users to still be using GNOME 3. :) 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Red Hat & Fedora -- largely stepping out of this ecosystem
Hi Leon. I replied inline. Leslie Satenstein On Friday, June 30, 2023 at 11:16:48 a.m. EDT, Leon Fauster via devel wrote: Am 30.06.23 um 15:41 schrieb Leslie Satenstein via devel: > What should I do, if the person I gave the software to, removes my > copyright, rebrands the software and sells my software as their own? > Is it right? And when I release a bug fix, they take it, insert the > fix into the rebranded copy they are selling, and they quietly say, > "Screw You, Leslie". Ask yourself; how does open source methodology works? Just using your words: Apple Inc. releases a bug fix, RedHat takes it, insert it into the rebranded copy (RHEL) they are selling ... https://git.centos.org/rpms/webkit2gtk3/c/f1679e95706409206b768d4f0a03563066c52bda?branch=c8 WITH APPLE's invitation/request. The fix was to help non-applie users make better use of Apple's offerings. Leslie -- Leon ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Red Hat & Fedora -- largely stepping out of this ecosystem
I agree with RH's decision. I write software and release it as gpl3, source, it and all build Makefiles! I give it out, and to those, I ask, only to provide me with bug reports or some patch ideas to make the offering better. What should I do, if the person I gave the software to, removes my copyright, rebrands the software and sells my software as their own? Is it right? And when I release a bug fix, they take it, insert the fix into the rebranded copy they are selling, and they quietly say, "Screw You, Leslie". Suppose I was the government, and I did that same offer to end-users. Would the redistribution be legit, and even honest, if from the government, and it was for remuneration? The right-or-wrong activity is really a discussion about ownership and rules for sharing. In the Leslie case, Leslie is the owner. In the government case, the people are the owners. What right does a company have the right to clone and rebrand my product and resell it? Under the gpl3, they have an unenforceable obligation to provide me with bug reports. They do not have a moral right to redistribute my software as their own, and for remuneration. In two cases, at least two companies offer Linux as known Red Hat, clones. We understand that they copy the sources, the bug fixes, and rebrand the software as their own. In most cases, vanilla in -- vanilla out. But it is not revenue in, revenue shared. What should Red Hat do to recover the costs for development of new features, documentation, distribution, bug-fixes, 24/7 support as well, the infrastructure that allowed an individual to freely download the entire package. The clones have none of those obligations or costs? Red Hat is financing Centos and Fedora. Moreover, visit https://kojipkgs.fedoraproject.org/compose/ to get a small idea of the investment, operating costs, and end-user benefits. Recall, Red Hat shareholders are not a government body. Perhaps it is time to provide a gpl4 rule that encompasses or replaces gpl3. Leslie Satenstein On Thursday, June 29, 2023 at 12:41:44 p.m. EDT, Todd Zullinger wrote: Carlos O'Donell wrote: > On 6/26/23 18:47, Jeff Law wrote: >> What Red Hat has done may be technically legal and perhaps good for >> its business. However, to me it's ethically unconscionable. Those >> who know me know I'm not an zealot, but I do have a baseline set of >> ethical values and Red Hat crossed that line. > > Why is it ethically unconscionable? There is a lot of confusion around > what has happened and why. What you are saying, and what actually happened > don't line up in my mind :-) Something I'm having trouble with is Red Hat's position that you can choose to be a customer or to exercise your rights under the GPL, but you cannot be both. I don't know how to view that as anything other than sacrificing the spirit of F/OSS to help the books. I am sympathetic to the odd/difficult nature of running a business based on F/OSS. Until now I thought Red Hat was doing it pretty well. I thought Jeff's message was well written. I am still struggling with whether I should take the same path. :( -- Todd ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fw: Two Years of Fedora Releases
Hello from Montreal, Canada I have been a Fedora user for about 20 years. In all that time, it was known that the frequency of Fedora updates are as you described. However, I just want to remind you that when a new release of Fedora is published, that Fedora also provides a utility (a dnf release upgrade) that will perform the necessary changes to easily move you to the next Fedora version, In the past, for very long periods between upgrades, there was available "Centos". Centos was used for servers and for desktop applications that were "frozen in time". Open CentOS is no more. Perhaps you should explore using RedHat and/or CentOS for your very long-term needs. Fedora is a community distribution generally targeting single independent users or families, where we Linux devotees look for product improvements along with good stability, and in return, we report technical issues hat are encountered and often, solutions or work-arounds. Some of us use Fedora as a home-server, supporting the family needs. In closing, as a community edition, Fedora is not meant to be supported for more than 18 months, beginning from the date of release of that version. I wish you well in your search for a long-term solution for your needs. Yours truly, Leslie Satenstein - Forwarded Message - From: مصعب الزعبي To: devel@lists.fedoraproject.org Sent: Friday, June 23, 2023 at 06:41:22 a.m. EDTSubject: Two Years of Fedora Releases Dear Fedora development community, As you know Fedora releases every 6 months for one year of lifetime. This is good for development and new features implementation. But it is not good for stability and sustainability. When upgrading the system every 6 months, alot of resources will be trashed!! For Fedora users and Fedora itself. It will be more stable, effective, natural-friendly and feasible if we make Fedora lifetime as: - One year between releases. - Two year of release lifetime. Kind Regards, MOSAAB___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: LibreOffice packages
No LibreOffice, no continuation with Fedora. LO better be there with F39. Without it, all you have is Firefox. It is not enough to keep Fedora Diehards from jumping to another popular distribution. Leslie Sent from Yahoo Mail on Android On Fri, Jun 2, 2023 at 8:07 p.m., Sandro wrote: On 02-06-2023 16:09, Matthew Miller wrote: > On Fri, Jun 02, 2023 at 01:55:30AM +0200, Sandro wrote: >> However, it surprises me that for a package, that is part of the >> deliverables of Fedora releases, no coordination effort was made to >> transition the package from Red Hat maintenance to Fedora >> maintenance. I would even go as far as that this should have been > > I think this sentiment is getting ahead of things. This thread _is_ that > effort. Asking people to submit a Change when they want or need to stop > working on something seems... burdensome. (And, uh, what happens if that > change is rejected? There's no _making_ people do things.) So, what is the contingency plan then? LibreOffice is a huge package and I could imagine that taking over maintenance of it is not an easy endeavor. Taking into consideration the circumstances explained in replies later, I can understand that hands were tied. Yet, the decision to stop shipping LibreOffice is one that affects future RHEL releases and Red Hat's customers. Yet, the decision to orphan the LibreOffice stack of packages affects a much larger group of users. What will we ship in Fedora if we were to follow in Red Hat's footsteps? LibreOffice Flatpak? That may prove to be the straw that broke the camel's back. As I said before, I don't want to to reiterate the Flatpak vs. RPM discussion. But maybe that topic needs to be picked up and discussed, so we get a better understanding of where this will leave us. Let's hope that at least some lessons will be learned from this rather rushed decision. At least that is what it appears to be. -- Sandro ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: Fedora Images on Azure (Self-Contained Change proposal)
I like the idea. I will definitely go for it, in a show of hands or vote.
Sent from Yahoo Mail on Android
On Thu, May 11, 2023 at 2:16 p.m., Adam
Williamson wrote: On Fri, 2023-04-21 at 13:49
-0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Fedora_Images_On_Azure
>
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal will only be implemented if approved
> by the Fedora Engineering Steering Committee.
>
> == Summary ==
>
> Azure is a massive public cloud and offering an official Fedora Cloud
> image there would expand Fedora's user base. It also gives Fedora
> Cloud users more options when selecting public clouds.
>
> == Owner ==
> * Name: [[User:mhayden| Major Hayden]], [[User:davdunc| David Duncan]]
> * Email: ma...@redhat.com, davd...@amazon.com
>
> == Detailed Description ==
> We want to:
>
> * Get Azure images built via the existing Pungi processes
> * Publish Azure images via Azure's image gallery
> * Test these images during regularly scheduled Fedora Cloud test days
> before final release
> * Ensure that the Azure URN is linked on the Fedora website in the
> cloud downloads section (similar to how AWS images are listed today)
>
> == Feedback ==
> Another alternative would be to offer a VHD download option from a
> mirror, but that
> would require users to download the image and upload it to Azure on
> their own. This
> could be challenging for users without technical skills to complete
> these steps or for
> users with slow network connectivity.
>
> == Benefit to Fedora ==
> * Expands Fedora's official image public cloud footprint to Azure
> (currently just AWS and GCP)
> * Allows Azure customers to launch official Fedora images which were
> tested before launch
> * Raises awareness around Fedora Cloud images
>
> == Scope ==
> * Proposal owners: Isolated change that does not affect the OS itself
> but does improve its availability in public clouds.
> * Other developers: Does not affect other developers or features in Fedora.
>
> * Release engineering: [https://pagure.io/releng/issue/11398 #11398]
> * Policies and guidelines: N/A (not needed for this Change)
> * Trademark approval: N/A (not needed for this Change)
> * Alignment with Community Initiatives: N/A
>
>
> == Upgrade/compatibility impact ==
> This is a net new offering in a cloud where Fedora was not previously offered.
>
>
> == How To Test ==
> * Verify that the Fedora image appears in Azure's image gallery
> * Launch an Azure VM with the new Fedora image
> * Complete the usual verification that is done on other clouds during
> [https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230418.n.1_Cloud
> test days]
>
>
> == User Experience ==
> Customers on Azure will notice that a new Fedora official images is
> available to them.
> Users of other platforms, such as workstation and server, will not see a
> change.
> Customers of other clouds, such as AWS, will not see a change either.
>
> == Dependencies ==
> All dependencies are already packaged and tested. One of the biggest
> is the Azure Linux
> agent ({{package|WALinuxAgent}}), but it has been packaged in Fedora
> for multiple releases and is
> verified to work on Azure.
>
>
> == Contingency Plan ==
> * Contingency mechanism: N/A (not a System Wide Change)
> * Contingency deadline: N/A (not a System Wide Change)
> * Blocks release? No
>
>
> == Documentation ==
> N/A (not a System Wide Change)
>
> == Release Notes ==
> Fedora Cloud Edition is now available for use in Microsoft Azure.
So I missed this one before it was approved, but there's a key question
for quality purposes. Does this Change envisage Azure being added to
the list of "Supported cloud environments" in
https://fedoraproject.org/wiki/Basic_Release_Criteria#Release-blocking_images_must_boot
or not? If it does, this adds an additional set of validation testing
work which somebody needs to do, or automate somehow. Either way we
will probably want to add an Azure column to
https://fedoraproject.org/wiki/Template:Cloud_test_matrix , but the
question is whether it's considered required/blocking testing or not.
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://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
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe
Re: F39 proposal: BiggerESP (Self-Contained Change proposal)
Leslie Satenstein Some end-user feedback. I believe in the KISS approach (Keep It Simple S). I would consider /boot as a btrfs volume, and not a sub-volume, but why bother? For me, it being a btrfs partition is definitely not a priority or urgency, as I use rsync for backup/restore of the ext4 partition. For my desktop setup, I have several disks with independent btrfs partitions.These are not sub-volumes, again, they are fully independent. I manually add them to my /etc/fstab after I install the vanilla Fedora Linux distribution I make use of them as I independent volumes. They definitely are not sub-volumes. Some common sense.= Most user disks today are of size 500gigs or more.I do not concern myself with 1024 megs for /boot. I also reserve/use 500megs for /boot/efi Better to spend energy on other things. On Wednesday, May 10, 2023 at 11:12:20 a.m. EDT, Simo Sorce wrote: On Tue, 2023-05-09 at 12:37 -0400, Neal Gompa wrote: > On Tue, May 9, 2023 at 12:31 PM Lennart Poettering > wrote: > > > > On Di, 09.05.23 08:22, Neal Gompa (ngomp...@gmail.com) wrote: > > > > > I've been asked to consider converting /boot to a Btrfs subvolume so > > > that it no longer has a fixed space allocation to deal with the ever > > > increasing amount of firmware required for NVIDIA GPUs[1]. This is > > > currently incompatible with how systemd views the world, because the > > > "discoverable partition spec" is wired to partitions, and there is no > > > equivalent spec for subvolumes of a volume. And I imagine that > > > XBOOTLDR (whatever that is) also would have a problem with this. > > > > This makese no sense. If you want /boot to just be a subvolume of the > > rootfs btrfs, then this would imply it's also covered by the same > > security choices, i.e. encryption. We want to bind that sooner or > > later to things like TPM2, FIDO2, PKCS11. And that's simply not > > feasible from a boot loader environment. > > > > Hence, the place the kernel is loaded from (regardless if you call it > > /efi or /boot or /boot/efi, and regardless what fs it is) must be > > accessible from the boot loader easily, without requiring > > implementation of TPM2/FIDO2/PKCS11 hookup in the boot loader. > > > > Hence: btrfs subvols won't work for this > > If we're not using LUKS for encryption, then this is not a problem. > We're generally looking toward encrypting subvolumes individually > using the upcoming Btrfs native encryption capability rather than > using LUKS. That allows us to > > 1. Pick which subvolumes are encrypted > 2. Pick the security binding method per subvolume > > For example, the root and home subvolumes would use TPM or some other > non-interactive binding. The user subvolume in home would decrypt with > user login. Neal, I think you are barking up the wrong tree here. The design of the boot loader *nedds* to be simple. Simple means, VFAT and *no trust* in the filesystem, individual files are signed and verified. Only the bare minimum *necessary* is in the boot partition, which means kernel images and the bare minimum init image needed to unlock and mount the root partition. There is no point in building a more complex system than that and load tons of garbage drivers in the EFI. Booting is a staged system, and should be kept as simple as possible to avoid duplication (which means subtle bugs and a ton of maintenance overhead). Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: Man-pages-ru Retirement (Self-Contained Change proposal)
Off Topic I have been developing C code with Fedora for about 20 years. I know by heart, the usual such as stdlib, malloc, ... etc.But on occasion, when I see some code with a typo for the type definition (example misspelled.h). I would like to be able to enter "man.stdio.h" or "man ctype.h" or "man whatever.h" etc, and get the include file abbreviated content listing. As an example, man stdio yields very very little info. Neither does "man stdio.h" As I see it, "man whatever.h" should be the table of contents for the "whatever.h" include file include file, but I can get a listing of what is therein. I have to go to /usr/include to do my top level research. As a developer, and I believe, other developers who use C, C++, Rust, etc, I would like to do a man "whatever.h" to optain a list of the defines, and from that list, I would choose to select the entry for which I need more information. Please give some thought to the programmer sitting at a terminal and who is debugging someone else's code. Leslie Satenstein On Thursday, April 27, 2023 at 02:22:21 p.m. EDT, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/ManPagesRuRetirement This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Retiring man-pages-ru because it is already part of the man-pages-l10n. == Owner == * Name: [[User:ljavorsk| Lukas Javorsky]] * Email: ljavo...@redhat.com == Detailed Description == Upstream (man-pages-l10n) has integrated Russian translations for man-pages. It means we no longer need to have a specific (man-pages-ru) package for it. [https://salsa.debian.org/manpages-l10n-team/manpages-l10n/-/commit/37b44f5a8ad3999501c79a20b67a27e17cc65630 Upstream commit containing the change] The plan is simple: 1) Deprecate man-pages-ru package 2) Enable 'ru' translations for man-pages-l10n (temporary disabled due to conflicts). [https://src.fedoraproject.org/rpms/man-pages-l10n/c/00a88c237e1fd7cdef9c52665128b155cf14243c?branch=rawhide Commit disabling it] Also add Obsolete and Provides for man-pages-ru package. == Feedback == Early feedback from the community is positive, the feedback is located in this ([https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/WGLMJ7XXB5JUER57GEOZQBFMNKHD5FSZ/ Devel list announce]) == Benefit to Fedora == Fedora shouldn't maintain a redundant package. This change would make it easier for the maintainer as well as for the packages that requires man-pages-l10n and man-pages-ru. == Scope == * Proposal owners: Package man-pages-ru will be retired, and the man-pages-l10n will contain the Russian translations. * Other developers: Change the names of their BuildRequires/Requires accordingly. * Release engineering: No action required * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == When following the plan in Detailed Description there will be no need for manual action. Everything will be handled by the automated dnf upgrade. == How To Test == == User Experience == == Dependencies == List of the packages from Fedora 39 === man-pages-ru === dnf repoquery --whatrequires man-pages-ru | pkgname dnf repoquery --whatrequires '/usr/share/man/ru/*' | pkgname == Contingency Plan == * Contingency mechanism: Remove the man-pages-l10n build with Russian translation enabled. Revert deprecation of the man-pages-ru package. * Contingency deadline: Beta freeze * Blocks release? No ''NOTE: If we don't finish this change by the deadline, it is possible to just complete this change with the next release.'' == Documentation == [https://salsa.debian.org/manpages-l10n-team/manpages-l10n/-/commit/37b44f5a8ad3999501c79a20b67a27e17cc65630 Upstream issue] [https://bugzilla.redhat.com/show_bug.cgi?id=2163421 Bugzilla tracker] [https://sourceforge.net/p/man-pages-ru/discussion/1102373/thread/7dda92a232/ man-pages-l10n upstream discussion with man-pages-ru upstream about this] == Release Notes == -- 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To uns
Re: F39 proposal: FontAwesome6 (Self-Contained Change proposal)
Hi Developers. Because of some issues, I cannot log into the site to provide an improvement request for Fedora. I present a discussion idea, and a suggestion. I would like to suggest a change for the /etc/fstab to replace the use of UUID= with PARTUUID=... The Benefit When one has to restore a partition, it is often necessary to reformat same first, followed by the restoration using a backup. With UUID=.. the reformat causes a new UUID value to be created. BUT with PARTUUID= , the value it has fixed for the life of the partition. It, PARTUUID= is invariant from the time the partition is created. In a multi-boot environment, it is a change I manually make to each /etc/fstab. Currently I am multi-booting Fedora 37 Gnome, 38Gnome, 38KDE, 38Cinnamon to do my own QA on the presented distros, and also to check how my own software is functioning under the four mentioned. Since the new installer is in progress, I would would like to propose that the change be considered. Ben and Matt, I have issues with access. That is why I am using this email response to propose a future (Fedora 39) change. By the way, manually changing the fstab entries from UUID= to PARTUUID= works flawlessly. If you do not want to incorporate said change, then a simple program to do it is easy to write and test. I have such program underway. Leslie SatensteinMontreal. On Friday, March 10, 2023 at 04:15:59 p.m. EST, Matthew Miller wrote: > Some user-facing applications will be able to display the latest > versions of the FontAwesome icons, which have undergone a number of > updates and cleanups to provide a more pleasing look. In addition, > many new icons have been added in the 5.x and 6.x versions. For > example, version 6.x contains a Fedora icon, while previous versions > do not. Version 5.x contains an an unauthorized not-so-great single-color hackup of the "classic" logo. Version 6.x contains an authorized rendition of the legit current logo. Is 6.x backwards compatible with 5? -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proposal: drop delta rpms (for real this time)
Got it. Leslie Satenstein On Tuesday, February 21, 2023 at 03:48:23 p.m. EST, Matthew Miller wrote: I was asked to weigh in on https://pagure.io/releng/issue/7215 as a priority. Last time we talked about this we didn't really get anywhere... https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/JYKVELSBJQMEK6KEFXG354ZDZDDX4C5G/#RLEUYSWOUVUS53YAP7WQQNN7HNEBIC4E ... and that ticket hasn't moved, because fixing it isn't trivial. What we're doing now — as has been the case for several years, already noted in the previous discussion — has very little end-user value. Also as noted in that thread (as in the ticket)... that's unfortunate, because it did bring some real benefits (and could possibly do even more.) But, I think it's time to move on. We have ostree and various container-delta approaches. We should focus on those — and give DeltaRPMs a sad, fond farewell. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Btrfs question for Fedora 33 beta. How can I add nocow to /var
Hi Chris, This weekend past, I did create /opt and /var as subvolumes. For the empty /opt, it was easy. For /var, it took the live ISO to help with moving directory /var to subvolume /var I also intend to do the same with /sys on this, my beta system, Later this week I will install the "release version" on a second drive as a second system, when it is available. The rational for my doing the subvolume exercise is the following: 1) Under default installation, each snapfile of root has a copy of all subdirectories including active /var, and /sys. I noted that /var/log and /var/cache is rather volatile. My SSD size is 120gigs 2) By isolating /var, /opt and /sys the root snapshot becomes less bloated. 3) The /sys directory rarely has changes according to my survey of directory and file dates. One subvolume taken when there is a change is OK for me. 4) But /var/log is quite active, as is /var/cache. I will be using btrfs defragment on /var. 5) Having /var as nodatacow puts /var to the same risk level as when /var was on the ext4 system. I will be using fstrim -a (to do SSD trims) and I want to user snapper, to manage the subvolume snapshots. The generations of snapshots for /var and / will be my objective. I will be using crontab and a script to take snapshots just before the script launches "sudo dnf update -y". This switch to btrfs is a learning experience for me. Fedora is my passion, From my studies, I may discover that you are absolutely right to state that I do not need to make the extra subvolumes. The advantage I have over you is my career. It is called "retirement". Retirement comes with spare time to study, to learn, to write code, to explore, experiment and to share experiences. ___ 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: Btrfs question for Fedora 33 beta. How can I add nocow to /var
I forgot to mention, that one way tI can isolate /var is to use a separate partition. Ditto for /opt ___ 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
Btrfs question for Fedora 33 beta. How can I add nocow to /var
I am looking to some performance considerations for the /etc/fstab btrs default config generated by anaconda. It appears to have created a subvol for root (root00) and for home (home00). I would like to put in /opt with it's subvol, and to migrate the /var to a subvol where I can specify nodatacow. Leaving /var as a directory under /, without specifying nodatacow concerns me as it is a very "busy" directory, and can fill up the root00 subvol quite quickly. I tried to create the two subvars, without success. I even went so far as to examine the grub menu entries. Is this not possible with Fed33 beta? ___ 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
