CPE Weekly Update – Week 20 2022
Hi everyone, This is a weekly report from the CPE (Community Platform Engineering) Team. If you have any questions or feedback, please respond to this report or contact us on #redhat-cpe channel on libera.chat (https://libera.chat/). Week: 16th May - 20th May 2022 If you wish to read this in form of a blog post, check the post on Fedora community blog: https://communityblog.fedoraproject.org/cpe-weekly-update---week-20-2022/ # Highlights of the week ## Infrastructure & Release Engineering Goal of this Initiative --- Purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work. It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.). The ARC (which is a subset of the team) investigates possible initiatives that CPE might take on. Link to planning board: https://zlopez.fedorapeople.org/I&R-2022-05-18.pdf Update -- ### Fedora Infra * Fedora Media Writer 5.0.1 is live/done for both windows and macos! * Email from @redhat.com users to @fedoraproject.org users who use gmail is broken due to SPF changes on rh side. [INC2210845 ](https://redhat.service-now.com/surl.do?n=INC2210845) * Switched to linux-system-roles.nbde_client (automatically unlocking encrypted devices via network) role from our home grown incomplete one after working thru a dracut bug in RHEL8.3+ * RHEL9 content synced and already switched epel9 to use it. * Mass update/reboot in progress, outage later today to finish. ### CentOS Infra including CentOS CI * CentOS Stream storage migration spike (Netapp for nfs/iscsi) (ongoing) * Duffy fixes and tests (ec2 provisioning working) * Git.centos.org pagure upgrade/migration (blocked, waiting on internal Red Hat Team) * 9 stream build targets on cbs/koji now consuming centos9s-buildroot repositories straight from upstream kojihub for Stream 9 (no latency) * Business as usual (mirrors, tags) ### Release Engineering * Archiving older releases * Updating the EOL release date will be part of the release schedule ### Any Other Bussiness * All the zuul jobs are now migrated to [centralized repository](https://pagure.io/fedora-infra/zuul) ## CentOS Stream Goal of this Initiative --- This initiative is working on CentOS Stream/Emerging RHEL to make this new distribution a reality. The goal of this initiative is to prepare the ecosystem for the new CentOS Stream. Updates --- * Changes to the c8s module migration code to automatically filter to modules that are released. * Migration of packages to new c8s infrastructure is moving along. * Fixing the ELN Everything installer. ## CentOS Duffy CI Goal of this Initiative --- Duffy is a system within CentOS CI Infra which allows tenants to provision and access bare metal resources of multiple architectures for the purposes of CI testing. We need to add the ability to checkout VMs in CentOS CI in Duffy. We have OpenNebula hypervisor available, and have started developing playbooks which can be used to create VMs using the OpenNebula API, but due to the current state of how Duffy is deployed, we are blocked with new dev work to add the VM checkout functionality. Updates --- * Deployment: apply database schema migrations * Test per tenant quotas and provisioning on EC2 ## Package Automation (Packit Service) Goal of this initiative --- Automate RPM packaging of infra apps/packages Updates --- * Mostly business as usual, lots of dependencies * A fair amount of manual packaging needs to happen for most of our applications first * Reducing a lot of dependency pinning * Unfortunately packit [doesn’t support monorepos](https://github.com/packit/packit/issues/1543) at the moment so Bodhi and Datanommer will be blocked until they do. It’s on their roadmap. * scoady pto for ~2 weeks ## Flask-oidc: oauth2client replacement Goal of this initiative --- Flask-oidc is a library used across the Fedora infrastructure and is the client for ipsilon for its authentication. flask-oidc uses oauth2client. This library is now deprecated and no longer maintained. This will need to be replaced with authlib. Updates: * Starting to [implement](https://github.com/fedora-infra/test-auth/blob/authlib_dev/test_auth/flask_oidc.py) flask-oidc api using authlib. ## EPEL Goal of this initiative --- Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special Interest Group that creates, maintains, and manages a high quality set of additional packages for Enterprise Linux, including, but not limited to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), Oracle Linux (OL). EPEL packages are usually based on their Fedora counterparts and will never conflict with or replace packages
Announcing the Fedora BIOS boot SIG
Hi All, Now that FESCo has decided (1) that Fedora will keep supporting BIOS booting, the people working on Fedora's bootloader stack will need help from the Fedora community to keep Fedora booting on systems which require Legacy BIOS to boot. To help with this the Fedora BIOS boot SIG (special interest group) has been formed. The main goal of this SIG are to help the Fedora bootloader people by: 1) Doing regular testing of nightly Fedora N + 1 composes on hardware which only supports BIOS booting 2) Triaging and/or fixing BIOS boot related bugs. A biosboot-...@lists.fedoraproject.org mailinglist and bugzilla account has been created, which will be used to discuss testing result and as assignee / Cc for bootloader bugzillas which are related to BIOS booting. If you are interested in helping with Fedora BIOS boot support please subscribe to the email-list: https://lists.fedoraproject.org/admin/lists/biosboot-sig.lists.fedoraproject.org/ and add yourself to the Members section of the SIG's wiki page: https://fedoraproject.org/wiki/SIGs/BiosBoot Regards, Hans 1) https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/KCJCEQMHITAQUW4SMWU3AXIPZ65GSDSU/ ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-34-20220520.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-34-20220518.0): ID: 1274437 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1274437 ID: 1274445 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1274445 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Test-Announce] Fedora 37 Rawhide 20220520.n.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 37 Rawhide 20220520.n.0. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Notable package version changes: anaconda - 20220517.n.0: anaconda-37.7-1.fc37.src, 20220520.n.0: anaconda-37.7-2.fc37.src parted - 20220517.n.0: parted-3.5-1.fc37.src, 20220520.n.0: parted-3.5-2.fc37.src Test coverage information for the current release can be seen at: https://openqa.fedoraproject.org/testcase_stats/37 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_37_Rawhide_20220520.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_37_Rawhide_20220520.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_37_Rawhide_20220520.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_37_Rawhide_20220520.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_37_Rawhide_20220520.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_37_Rawhide_20220520.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_37_Rawhide_20220520.n.0_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: [CentOS-devel] [EPEL-devel] RHEL moving to issues.redhat.com only long term
On Fri, May 20, 2022 at 1:42 AM Thomas Stephen Lee wrote: > > The package I need is redhat-lsb-core. We have no plans to add redhat-lsb-core at this time. Most users are able to port their software to use the fields in /etc/os-release. josh > On Fri, May 20, 2022 at 1:57 AM Josh Boyer wrote: > > > > On Thu, May 19, 2022 at 4:11 PM Kevin Fenzi wrote: > > > > > > On Thu, May 19, 2022 at 07:37:46AM +0200, Branislav Náter wrote: > > > > Hi, > > > > > > > > On Thu, May 19, 2022 at 4:15 AM Thomas Stephen Lee > > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > I am trying to request a package for RHEL 9, but I cannot find RHEL > > > > > under Projects at issues.redhat.com. > > > > > What is the correct project for RHEL 9 ? > > > > > > > > > > > > > You have to file a bug for "distribution" component in Bugzilla. > > > > > > Please don't file it there. :) > > > > Small point of clarification. If you want to add a package to Red Hat > > Enterprise Linux 9 (the product), then you should likely open a > > support case via the Customer Portal and request it as an RFE. > > > > If you want to request a subpackage of an existing RHEL 9 package that > > is not included in RHEL, follow this and replace 8 with 9: > > https://wiki.centos.org/FAQ/CentOS8/UnshippedPackages > > > > If you want to add a package to Extra Packages for Enterprise Linux 9 > > (the wonderful community project), then follow what Kevin says below. > > > > It really depends on the exact thing you are after. > > > > josh > > > > > > > Take a look at the handy doc: > > > > > > https://docs.fedoraproject.org/en-US/epel/epel-package-request/ > > > > > > If anything is unclear there, please do let us know. > > > > > > While RHEL may be moving to jira with RHEL10, EPEL is very likely to > > > stay with whatever Fedora is using (currently bugzilla). > > > > > > kevin > > > ___ > > > CentOS-devel mailing list > > > centos-de...@centos.org > > > https://lists.centos.org/mailman/listinfo/centos-devel > > > > ___ > > CentOS-devel mailing list > > centos-de...@centos.org > > https://lists.centos.org/mailman/listinfo/centos-devel > ___ > CentOS-devel mailing list > centos-de...@centos.org > https://lists.centos.org/mailman/listinfo/centos-devel ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 5/17/22 00:10, Fabio Valentini wrote: On Mon, May 16, 2022 at 4:54 PM Andrew Hughes wrote: Let me join the train of -1 votes. I consider this a step entirely in the wrong direction. The JDK should be linked to system libraries wherever possible just like our other packages. Language interpreters/JITs are not exempt from that. In fact, I see very little value in providing JDK packages at all if they are built that way. I expect JDK users would disagree with you. JDKs from other vendors (Amazon, Azul, Oracle, etc.) are built in exactly this way. We (and likely other GNU/Linux distributions) are the exception here. I don't think this is a valid argument, because you're looking at OpenJDK in isolation. As far as I know, almost all compilers and runtimes we ship in Fedora are built with a certain amount of downstream patches that make them "slightly different" than what you might install in binary form from "$foo-lang.org" (if only to make them usable to build other packages that use them), so OpenJDK is not an exception here at all. I would even argue that users are *aware* that the compilers / runtimes that are provided by Linux distributions are at least *slightly modified* (if only to cater to linux distribution use cases), and will already fall back to "official" binaries, when necessary. If you really want to lower your maintenance burden for OpenJDK packages, I'd start by not shipping four (or soon five?) different versions of them. For example, do we really still need java-1.8.0-openjdk? Or is it time to retire the ancient Java packages that only still work on a Java runtime that's almost a decade old? Or, can even java-11-openjdk be dropped in the near future, since java-17-openjdk is the default for Fedora 36 and future Fedora releases? And do we actually need the "java-latest-openjdk" version at all? If anybody needs such an up-to-date Java compiler / runtime for their development work, they'll surely already download an official binary distribution. Well yes. Taht is of course option to support only system jdk and be done with that. We will need to continue t build - but never release- -latest- package, so we are able to bootsrap next system jdk (21 or what) Note one super huge bad side effect - the new system jdk will be totally untested, including integration. Thus saying, I woudl ratehr support 4 static different fully jdks tested, then 1 jdk build 4times, which is fully untested Thanx! J. Fabio ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 5/18/22 14:40, Felix Schwarz wrote: Am 18.05.22 um 11:27 schrieb Peter Boy: We didn’t lost Eclipse, we switched from RPM to another distribution method. Do you mean the Eclipse flatpak? I tried the flatpak but in the end went back to upstream's plain binaries as the Flatpak does not work well when using pydev. So for my use case Fedora lost Eclipse. I tend to agree. No flatpak ide ever proeprly fored for me, especially becasue of impossibility to use any custom jdk or thrd party servers (including in fedora packed ones) proeprly. On the other side, huge java projecs (like eclipse or netbeasn) are so complex and so impossibel to pack properly, that wgeted tarball remmains win win. Even in time of those ides packed,the tarballs freom web was quite a lot better. J:( Felix ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 5/18/22 17:31, Neal Gompa wrote: On Wed, May 18, 2022 at 11:28 AM Peter Boy wrote: Am 18.05.2022 um 16:36 schrieb Vitaly Zaitsev via devel : On 18/05/2022 11:27, Peter Boy wrote: We didn’t lost Eclipse, we switched from RPM to another distribution method. The same with Netbeans. No RPMS in Fedora repositories => Fedora lost them. You neglect the reality. One alternative installation source is flatpak, that is gaining approval among more and more Fedora developers, and more and more are switching to it. There may still be initial difficulties, but this is a clear trend. Meanwhile, this is also an accepted Fedora repository. Not that I think that's great, but it's the reality. Another way is to run software as a „black box“ container. If I run CoreOS or Silverblue I would primarily look in container repositories, not any dnf find … These two options do not use a Fedora Java runtime, I'm still new to silverblue, so I don not parse. What does it use if not system java please? Or you just download the jar or Linux installation tar from the project. They usually contain a shell script to invoke the jre and provide a class path. That’s all you need for a java app. So Fedora (= Fedora users) can use it as they could for years. There is nothing lost. But circumstances and the nature of management and maintenance are changing. 20 years ago we had no virtualization and no containers, no generic package managers as flatpack, snap, etc. And Java development was much more about using ant and source code libraries instead of maven and depository dependencies. Java was almost never about source code libraries, that's been the problem the entire time. The entire focus has been on introspectable binary JAR files, which is how most libraries are distributed. That's what makes Java the odd duck out compared to most ecosystems. It also I would say this is one fo the strengths of the java. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
I don't think so. The entire Java ecosystem on Fedora was destroyed by Fedora Modularity. Volunteers tried several times to revive it but failed due to opposition. I personally heavily agree:((( The modularity was great idea, but worst implementation ever. And for java it was indeed death blow which will take years to fix. J. -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
Btw, I know this because I fixed a gazillion font related bugs in OpenJDK in the past, most of which in the OpenJDK 6 and 7 era, I rarely ever had to touch 8 or later. I make my own IntelliJ packages for my own use that rips out their Java runtime and uses Fedora's OpenJDK. :) Idea still provides that JBR-less tarball isnt it? Also the idealauncher honour java_home, so it can work with "any" jdk. I run idea only with fedora system jdk, and if I find some trace of JBR, it is removed withotu compromises. HAd issues with thsi just recenlty, after f36 udpate, which have java-17-oepnjdk suddnely, whch idea was not ready. dnf install of 11 resovled it withotu issues -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 5/18/22 13:02, Fabio Valentini wrote: On Wed, May 18, 2022 at 12:28 PM jiri vanek wrote: Once, long ago, we were the leader in the Linux Java ecosystem, but ironically as Red Hat's influence in OpenJDK grew, investment in Fedora dwindled. That really is not true. But maybe we were doing to much to keep any java somehow alive. This proposal will untie our hands, and we wil be able to focus to toher things - exactl those which you propose. My experience with trying to keep Java packages in Fedora alive does not allow me to agree with you. I tried to keep Java ecosystem from disintegrating *twice* and both times I was discouraged by Red Hat employees. Can you elaborate more please? I guess one of this interactions was me. Which makes me double courious what caused you this experience. We've also lost most of our Java based apps to even test OpenJDK with. What the heck are we supposed to do to test and give karma? We lost Eclipse last year, and we lost IntellJ and NetBeans several years ago. Azureus was removed a year ago, too. The larger Java community stopped encouraging the development of desktop apps more than seven years ago, Excelent point - the reason why they quit, is that it is impossible to maintain compelte dependency chain, and having downloadable blob is so much easier for the maintenance. And JDK world is moving into this direction. If we will not be allowed to do so, JDK can leave fedora at all. That's not a valid argument, though, is it? If you have the choice between doing something that is 1) hard or 2) forbidden, then you don't really have a choice, do you? That is correct. But afaik there are three 1) hard 2) a bit easier 3) forbidden As fedora ahve bundling already allwod, the 2 is choice if 1 was attempted and proved to cost really a lot. Redistributing binary blobs or pre-compiled JAR files is not something we can do with Fedora RPM packages. As writtten several times - this si not true. It will eb always source codebuilt in koji. Of course it would be much simpler if we could just take JAR files from Maven Central and wrap them in an RPM, but that is forbidden in Fedora for good reason. Here I agree. if fedora move to prepacked blobs, then all freedome of source is gone. No way. If I ever suggest that, I will give you happily my address so you can take proper steps to stop it;) And that does not even account for the packages in Fedora that contain some amount of Java support code or tools that happen to be written in Java, and so rely on at least some parts of the Java ecosystem (javac, maybe maven or ant) to be available as RPMs during package builds. But that is again not going to change. I fail to understand your point here. Nor did I got why my argument is not valid. Maybe you misunderstood "having downloadable blob is so much easier for the maintenance" I ment downloadable from internet, not as rpms. Some simple mvn assembly:assembly which will do all the build work on developer's local machine, and then mvn release:release which will publish on project's web page and maintianer is done. On contrary, with more then 10 dependencies (unpacked for distro) it is already quite a fight to put it in. And if dependency (version) hell strikes, the apckager is lsot, where upstream maintainer and publisher is not. Fabio ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
Just to repeat i one more times, and maybe a bit more loudly - the rendering seems to be SAME for both static and dynamic linking. Please anybody who complains in this thread, can yo have any proof that dynamic linking really makes yor eyes bleed?? J. On 5/18/22 15:48, Mario Torre wrote: On Tue, May 10, 2022 at 11:52 PM Neal Gompa wrote: I'm confused how this would not negatively impact the user experience, because things like FreeType and HarfBuzz in Fedora have features and configuration that are non-default that improve the font rendering capabilities of applications that link to FreeType. I would rather have our shared maintenance and evolution of font stuff be reused in Java too... The rendering is always done in OpenJDK, those libraries are not used for the actual rendering. The generation of glyphs types and the metrics are obtained via those libraries, but it's been ages since the old patented algorithms would produce better quality, and anyway those would not be available in Fedora anyway. There are settings that influence the rendering, which is why sometimes users have worse quality on KDE vs Gnome, but those aren't settings in the libraries, are configurations such as environment variables or gnome properties. If you experience font quality differences, I would pretty much like to know, this would be a bug. They would also be very surprising though, applications such as IntelliJ bundle their own JDKs, I recall once one argument was exactly because of "better" font rendering, which is clearly not an actual argument. Btw, I know this because I fixed a gazillion font related bugs in OpenJDK in the past, most of which in the OpenJDK 6 and 7 era, I rarely ever had to touch 8 or later. Cheers, Mario -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 5/18/22 18:01, Neal Gompa wrote: On Wed, May 18, 2022 at 11:55 AM jiri vanek wrote: You can imagine TCK as gigantic and pretty good testsuite, runing 24hours with quite complicated setup. The pull and setup and run is completely autoamted, but it is a lot of HW you need (all architecures x all oses x all jdks). In adition, you need human power to keep with TCK evolution, sometimes to dapt setup, and to check resutls if they fails... and.. to fix it. We have HW from Red hat, and we deal with failures we keep track with usptream and TCK evolution. But it is not easy from human resources point of view. At this point, I'd rather have an OpenJDK in Fedora than not. If that means switching to bundled libraries, then fine. But all bundled libraries need to be documented in the spec file and that information needs to be kept up to date. I deeply appreciate your understanding. Can we do this without going down the route of building only once at one distribution tag and tagging the binary into everything else? If we do only this dirst part, then the TCK burden would not be lifted. Still it make maintaneace much more easy. -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 5/18/22 18:22, Fabio Valentini wrote: On Wed, May 18, 2022 at 6:04 PM Neal Gompa wrote: On Wed, May 18, 2022 at 11:55 AM jiri vanek wrote: You can imagine TCK as gigantic and pretty good testsuite, runing 24hours with quite complicated setup. The pull and setup and run is completely autoamted, but it is a lot of HW you need (all architecures x all oses x all jdks). In adition, you need human power to keep with TCK evolution, sometimes to dapt setup, and to check resutls if they fails... and.. to fix it. We have HW from Red hat, and we deal with failures we keep track with usptream and TCK evolution. But it is not easy from human resources point of view. At this point, I'd rather have an OpenJDK in Fedora than not. If that means switching to bundled libraries, then fine. But all bundled libraries need to be documented in the spec file and that information needs to be kept up to date. Can we do this without going down the route of building only once at one distribution tag and tagging the binary into everything else? I agree. Can we discuss alternative routes to reduce maintenance burden for OpenJDK than what you're currently planning for the long term? thanx for this understanidng:( Maybe we can think about whether it's absolutely necessary to keep maintaining three different LTS versions of OpenJDK? Dropping at least java-1.8.0-openjdk would already reduce maintenance burden for OpenJDK packages by over 25% (given that 1.8.0 seems to cause you most of the problems recenty). This would of course help, but I would rahter keep 4 different jdks packed once, then 1 jdk packed 4 times. Still we will need to maintain usually 1, but very opften two system jdks, and we will need to continue maintain java-latest-openjdk as we need it to bootsrap next main jdk. Also we need java-lates-opnjdk live in release, not jsut in buidlroot, so we can tune integration of future jdk fluently. If statically linking against bundled versions of *some* dependencies would really help that much, it might also be worth considering, as a last resort, to keep OpenJDK packages in Fedora at all. However, I personally am strongly against the "follow-up" proposal, MoveFedoraJDKsToBecomePortableJDKs. Most importantly, the "Known issues" section on this wiki page sounds to me like it should be completely out of the question to actually go forward with the proposal. We are going to fix known issue. Unless the known issues are solved, we can not continue. All except debuginfo are somehow solvable. Can you please enumerate what parts of known issues toruel syou most? that would be super valuable information. I rate them all moreover in same level, as anoying, but really fixable (not jsut workaround-able) for common benefit. Some time ago, jiri vanek wrote: We realy do no like this change, but we do not see another way. I wonder how this happened? Has this issue been brewing for a while? We have the issues which led to this proposal since jdk 11 appeared in fedora. The issue was unluckily not getting away, and was jsut getting worse, until this proposal occured. Or will Red Hat be downsizing the OpenJDK team in the near future? ;) nope, but the multiplying of JDK employees is unluckily nor following multiplying of JDKs... Fabio ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 20/05/2022 14:03, Jiri Vanek wrote: As writtten several times - this si not true. It will eb always source codebuilt in koji. From https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs: Make the normal rpms to not built jdk, but to repack the portable rpms with all integration -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 37: Add kernel parameters that help prevent local exploits
On Thursday, 19 May 2022 04:15:16 BST Hellosway Here via devel wrote: > Add `slab_nomerge init_on_alloc=1 init_on_free=1 page_alloc.shuffle=1 pti=on > randomize_kstack_offset=on vsyscall=none ` as default kernel command line > arguments. This can help prevent local exploits by making it harder to > exploit the kernel. I do not think there will be any breakage, I have been > using these for a long time. The performance impact is minimal, a few of > these can improve performance. A question, then: if these options are helpful to performance and/or security, why are they not yet the kernel's defaults? If there are tradeoffs that mean that these aren't suitable for general use, then Fedora needs to know what those tradeoffs are before it can make the decision, while if they're a simple net improvement, then upstream kernel developers should be happy to switch the defaults over without requiring a kernel argument. > This can help increase the security of Fedora, while also not causing any > other problems. Many users do not know what kernel command line arguments > are, so doing this will help them with the security of their system. This > does not address every problem, or even most of them, but every little bit > matters. If that's the case, why doesn't the upstream kernel switch them over? Is there an ABI break caused by some of these? A major performance regression on some workloads (if so, which workloads and does Fedora care)? Known bugs that upstream hasn't tracked down yet? -- Simon Farnsworth ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 5/18/22 18:32, Vitaly Zaitsev via devel wrote: On 18/05/2022 18:01, Neal Gompa wrote: At this point, I'd rather have an OpenJDK in Fedora than not. If that means switching to bundled libraries, then fine. But all bundled libraries need to be documented in the spec file and that information needs to be kept up to date. They also want to bundle pre-built binaries into dependent packages. wait, what? What do you mean? And waht give you this impression? Or are you already in the follwoing year, when the attempt will be doen to build each JDK in koji just once, and ship it to al llive fedoras? -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 5/18/22 19:14, Michael Catanzaro wrote: On Wed, May 18 2022 at 12:01:33 PM -0400, Neal Gompa wrote: At this point, I'd rather have an OpenJDK in Fedora than not. I'll bite: why? Just so that it's easily available via RPM? It's starting to sound like Fedora would be providing very little value here on top of what is offered by upstream. At a certain point, getting your software directly from upstream might make more sense. For leaf application this is siple. But for uttermost root of one huge depndency chain, it would be bad. If that means switching to bundled libraries, then fine. But all bundled libraries need to be documented in the spec file and that information needs to be kept up to date. Provides: bundled(foo) is very important. With this, every time a CVE is found in a dependent library, Product Security is going to report a bug against Java, and it will be expected to be fixed in Java. It's a lot of extra responsibility. Without the Provides, tracking such issues is impractical. Every bundled library needs a Provides, not only the ones that would be affected by this change. I agree. and it will be there/ 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 on the list, report it: https://pagure.io/fedora-infrastructure -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 5/18/22 18:34, Vitaly Zaitsev via devel wrote: On 18/05/2022 17:51, jiri vanek wrote: You can not put uncertified JDK to fedora. Why not? And we can no longer properly support certified dynamic builds Hire new maintainers who can. Who shold hire them. You? Me? Fedoraproject? -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 5/18/22 18:36, Neal Gompa wrote: On Wed, May 18, 2022 at 12:33 PM jiri vanek wrote: Hi Neal! We are participating on Wakefield too. Why do you think JDK in feora should miss it ? It does nto metter if it is static or dynamic one, it will just run correctly under wayaland. Or do I miss something? The runtime libraries for integrating into Wayland are evolving at a fast pace. Moreover, if you build only once on the oldest distribution and tag up, it becomes even more difficult to take advantage of improvements to Wayland components in the distribution. My gut feeling is that changing OpenJDK to not rely on system libraries will make this considerably harder because we will have to wait for upstream to sync up and then pull it down. Additionally, depending on what their CI target is, it may wind up being even more difficult because older distributions *cannot* build some newer libraries because of missing build or runtime components. I've been dealing with that enough with KDE Plasma in Fedora and EPEL that I'm concerned we'd be in trouble with Wakefield on Fedora with this proposal. Thanx for writing it up. As wakefield is targetting jdk 20 at soonest, I wil both keep it in mind for wakefile project, and for Fedora jdk, this may be an interesting testing how the bundling actually works. My rough assumtpion would be, that it will remain runtime-laoding part, as JDK have to decide, if it is on X or Wayland, and load acordingly. -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On Wednesday, 18 May 2022 at 17:18, Vitaly Zaitsev via devel wrote: > On 18/05/2022 17:04, Stephen Smoogen wrote: > > It generally means and is interpreted as 'not true with the intention of > > deceiving'. 'incorrect' is considered 'not true'. > > The Oxford English Dictionary gives the following answer: > > lie (noun) - an intentionally false statement > used with reference to a situation involving deception or founded on a > mistaken impression Exactly. So, you implied malicious intent where there was none. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 20/05/2022 14:46, Dominik 'Rathann' Mierzejewski wrote: Exactly. So, you implied malicious intent where there was none. we don't know for sure. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 20/05/2022 14:28, Jiri Vanek wrote: wait, what? What do you mean? And waht give you this impression? https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs: > Make the normal rpms to not built jdk, but to repack the portable rpms with all integration Or are you already in the follwoing year, when the attempt will be doen to build each JDK in koji just once, and ship it to al llive fedoras? Repackaging of anything even it was built in Koji is strictly prohibited. All packages must be built from sources. No exceptions. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 20/05/2022 14:33, Jiri Vanek wrote: Who shold hire them. You? Me? Fedoraproject? Red Hat. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On Fri, 20 May 2022 at 08:43, Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> wrote: > On 20/05/2022 14:03, Jiri Vanek wrote: > > As writtten several times - this si not true. It will eb always source > > codebuilt in koji. > > From https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs: > > I looked through the wiki history and it has said the following since the first page in April 8th: ``` It is also not a goal, to pack third party blob. Jdk will still continue to build in koji as it should. ``` Is there some other section which counters this? > Make the normal rpms to not built jdk, but to repack the portable rpms > with all integration > > > -- > Sincerely, >Vitaly Zaitsev (vit...@easycoding.org) > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > -- 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 37: Add kernel parameters that help prevent local exploits
On Fri, 20 May 2022 13:26:14 +0100 Simon Farnsworth via devel wrote: > On Thursday, 19 May 2022 04:15:16 BST Hellosway Here via devel wrote: > > Add `slab_nomerge init_on_alloc=1 init_on_free=1 > > page_alloc.shuffle=1 pti=on randomize_kstack_offset=on > > vsyscall=none ` as default kernel command line arguments. This can > > help prevent local exploits by making it harder to exploit the > > kernel. I do not think there will be any breakage, I have been > > using these for a long time. The performance impact is minimal, a > > few of these can improve performance. > > A question, then: if these options are helpful to performance and/or > security, why are they not yet the kernel's defaults? > > If there are tradeoffs that mean that these aren't suitable for > general use, then Fedora needs to know what those tradeoffs are > before it can make the decision, while if they're a simple net > improvement, then upstream kernel developers should be happy to > switch the defaults over without requiring a kernel argument. > > > This can help increase the security of Fedora, while also not > > causing any other problems. Many users do not know what kernel > > command line arguments are, so doing this will help them with the > > security of their system. This does not address every problem, or > > even most of them, but every little bit matters. > > If that's the case, why doesn't the upstream kernel switch them over? > Is there an ABI break caused by some of these? A major performance > regression on some workloads (if so, which workloads and does Fedora > care)? Known bugs that upstream hasn't tracked down yet? As an anecdotal point of reference, I compile a local custom kernel, and have had kernel hardening set as defaults from their implementation. I have not noticed any issues. With the 5.18 series, however, there was a security measure that I didn't think I needed, so I didn't implement it. Initialize kernel stack variables at function entry (zero-init everything (strongest and safest)) --->│ │ │ │[*] Poison kernel stack before returning from syscalls │ │ │ │[ ] Report stack depth analysis instrumentation │ │ │ │(100) Minimum stack frame size of functions tracked by STACKLEAK │ │ │ │[ ] Show STACKLEAK metrics in the /proc file system │ │ │ │[*] Allow runtime disabling of kernel stack erasing │ │ │ │[*] Enable heap memory zeroing on allocation by default │ │ │ │[*] Enable heap memory zeroing on free by default │ │ │ │[*] Enable register zeroing on function exit I don't bother with the STACKLEAK metrics or stack depth analysis. I also have the random implementations mentioned above turned on via configuration options, and so compiled into the kernel as defaults. These are all small hits to performance, and as someone in the US Congress once said, 'a billion here and a billion there, and pretty soon you're talking real money'. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Announcing the Fedora BIOS boot SIG
Thank you Hans! Glad Fedora will remain relevant for keeping old hardware useful. Happy to help any way I can. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-IoT-36-20220520.0 compose check report
No missing expected images. Failed openQA tests: 2/15 (x86_64), 3/15 (aarch64) Old failures (same test failed in Fedora-IoT-36-20220516.0): ID: 1274891 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server@uefi URL: https://openqa.fedoraproject.org/tests/1274891 ID: 1274898 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi URL: https://openqa.fedoraproject.org/tests/1274898 ID: 1274899 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/1274899 ID: 1274906 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi URL: https://openqa.fedoraproject.org/tests/1274906 ID: 1274913 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi URL: https://openqa.fedoraproject.org/tests/1274913 Passed openQA tests: 13/15 (x86_64), 12/15 (aarch64) Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default_upload@uefi: System load changed from 0.02 to 0.24 Previous test data: https://openqa.fedoraproject.org/tests/1269441#downloads Current test data: https://openqa.fedoraproject.org/tests/1274885#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Rawhide-20220520.n.0 compose check report
Missing expected images: Minimal raw-xz armhfp Compose FAILS proposed Rawhide gating check! 7 of 43 required tests failed, 9 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 24/231 (x86_64), 23/161 (aarch64) New failures (same test not failed in Fedora-Rawhide-20220519.n.0): ID: 1274479 Test: x86_64 Server-dvd-iso server_cockpit_default **GATING** URL: https://openqa.fedoraproject.org/tests/1274479 ID: 1274511 Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING** URL: https://openqa.fedoraproject.org/tests/1274511 ID: 1274516 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart **GATING** URL: https://openqa.fedoraproject.org/tests/1274516 ID: 1274526 Test: x86_64 Workstation-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/1274526 ID: 1274527 Test: x86_64 Workstation-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/1274527 ID: 1274528 Test: x86_64 Workstation-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/1274528 ID: 1274551 Test: x86_64 KDE-live-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/1274551 ID: 1274553 Test: x86_64 KDE-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/1274553 ID: 1274554 Test: x86_64 KDE-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/1274554 ID: 1274555 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/1274555 ID: 1274573 Test: x86_64 Silverblue-dvd_ostree-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/1274573 ID: 1274576 Test: x86_64 Silverblue-dvd_ostree-iso desktop_terminal URL: https://openqa.fedoraproject.org/tests/1274576 ID: 1274577 Test: x86_64 Silverblue-dvd_ostree-iso evince URL: https://openqa.fedoraproject.org/tests/1274577 ID: 1274578 Test: x86_64 Silverblue-dvd_ostree-iso eog URL: https://openqa.fedoraproject.org/tests/1274578 ID: 1274583 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/1274583 ID: 1274584 Test: x86_64 Silverblue-dvd_ostree-iso gnome_text_editor URL: https://openqa.fedoraproject.org/tests/1274584 ID: 1274585 Test: x86_64 Silverblue-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/1274585 ID: 1274683 Test: aarch64 Cloud_Base-qcow2-qcow2 base_reboot_unmount@uefi URL: https://openqa.fedoraproject.org/tests/1274683 ID: 1274691 Test: x86_64 Workstation-upgrade upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/1274691 ID: 1274734 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/1274734 ID: 1274752 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/1274752 ID: 1274768 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/1274768 ID: 1274789 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/1274789 ID: 1274797 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/1274797 ID: 1274804 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/1274804 ID: 1274808 Test: aarch64 universal install_addrepo_metalink_graphical@uefi URL: https://openqa.fedoraproject.org/tests/1274808 ID: 1274810 Test: aarch64 universal install_arabic_language@uefi URL: https://openqa.fedoraproject.org/tests/1274810 ID: 1274831 Test: aarch64 universal install_cyrillic_language@uefi URL: https://openqa.fedoraproject.org/tests/1274831 ID: 1274834 Test: aarch64 universal install_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/1274834 ID: 1274842 Test: aarch64 universal install_european_language@uefi URL: https://openqa.fedoraproject.org/tests/1274842 ID: 1274850 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/1274850 Old failures (same test failed in Fedora-Rawhide-20220519.n.0): ID: 1274616 Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi URL: https://openqa.fedoraproject.org/tests/1274616 ID: 1274617 Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi URL: https://openqa.fedoraproject.org/tests/1274617 ID: 1274618 Test: aarch64 Server-dvd-iso install_btrfs_preserve_home@uefi URL: https://openqa.fedoraproject.org/tests/1274618 ID: 1274619 Test: aarch64 Server-dvd-iso install_btrfs_preserve_home_uefi@uefi URL: https://openqa.fedoraproject.org/tests/1274619 ID: 1274646 Test: aarch64 Server-dvd-iso server_cockpit_default@uefi URL: https://openqa.fedoraproject.org/tests/1274646 ID: 1274713 Test: aarch64 Workstation-upgrade upgrade_desktop_64bit@uefi URL: https://openqa.fedoraproject.org/t
Heads up: openjpeg2-2.5.0 and gdal-3.5.0 coming to rawhide
Hi I'll build openjpeg2-2.5.0 and gdal-3.5.0 for rawhide in the side tag f37-build-side-53899. I've switched gdal to the new cmake based build, and at the same time merged the mingw package with the native one. I'll rebuild affected packages as listed below. Thanks Sandro --- lizams bes blender cloudcompare compat-ffmpeg4 darktable dcm2niix eccodes efl engauge-digitizer ffmpeg freeimage gazebo gdal gdcm geeqie ghostscript gimp GMT gpac grass gstreamer1-plugins-bad-free ImageMagick liblas librasterlite2 mapnik mapserver merkaartor mingw-freeimage mingw-gstreamer1-plugins-bad-free mingw-opencv mingw-poppler mtpaint mupdf ncl opencv OpenImageIO OpenSceneGraph openslide osgearth paraview PDAL poppler postgis python-fiona python-pillow python-PyMuPDF python-rasterio qgis qmapshack qsstv R-rgdal saga vfrnav vips vtk webkit2gtk3 zathura-pdf-mupdf ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
What happened to umask?
For years, Red Hat Linux / Fedora systems have had a umask of 0002 for regular users as part of the "user private group" scheme [*]. Basically the idea is that you can set a directory group-sticky and use it as a common work area for a group of users. A change a couple of years ago seems to have partially changed this - the code in /etc/profile was removed with the idea that it should be controlled by pam_umask / login.defs instead. https://pagure.io/setup/c/102b349c39e196cc1e34e645c9310acdab7afeef?branch=master https://bugzilla.redhat.com/show_bug.cgi?id=1722387 However, the corresponding code in /etc/bashrc was left .This means that for a *login* shell (VT, ssh session, etc.) the umask is 0022 but for an interactive *non-login* shell (e.g., gnome-terminal with default settings) the umask stayed 0002. I'm not sure how much the change from 0002 to 0022 was thought through - that idea first appears in https://bugzilla.redhat.com/show_bug.cgi?id=1722387#c4 with Tomas Mraz saying: I do not think that the default umask should be 002 for regular users." - I would have expected a short change proposal, honestly. It seems like we need to do one of two things: - Go back to the old behavior, maybe by using the usergroups option to pam_umask and removing the code from /etc/bashrc - Or just go fully to 0022 by removing the code from /etc/bashrc. What do people think? If the current situation has lasted for several years, it clearly isn't *that* much of a concern to most people :-) - Owen [*] https://docs.fedoraproject.org/en-US/fedora/latest/system-administrators-guide/basic-system-configuration/Managing_Users_and_Groups/#s2-users-groups-private-groups ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: What happened to umask?
On Fri, May 20, 2022 at 8:13 PM Owen Taylor wrote: > > For years, Red Hat Linux / Fedora systems have had a umask of 0002 for > regular users as part of the "user private group" scheme [*]. Basically the > idea is that you can set a directory group-sticky and use it as a common work > area for a group of users. > > A change a couple of years ago seems to have partially changed this - the > code in /etc/profile was removed with the idea that it should be controlled > by pam_umask / login.defs instead. > > > https://pagure.io/setup/c/102b349c39e196cc1e34e645c9310acdab7afeef?branch=master > https://bugzilla.redhat.com/show_bug.cgi?id=1722387 > > However, the corresponding code in /etc/bashrc was left .This means that for > a *login* shell (VT, ssh session, etc.) the umask is 0022 but for an > interactive *non-login* shell (e.g., gnome-terminal with default settings) > the umask stayed 0002. > > I'm not sure how much the change from 0002 to 0022 was thought through - that > idea first appears in https://bugzilla.redhat.com/show_bug.cgi?id=1722387#c4 > with Tomas Mraz saying: I do not think that the default umask should be 002 > for regular users." - I would have expected a short change proposal, honestly. > > It seems like we need to do one of two things: > > - Go back to the old behavior, maybe by using the usergroups option to > pam_umask and removing the code from /etc/bashrc > - Or just go fully to 0022 by removing the code from /etc/bashrc. > > What do people think? If the current situation has lasted for several years, > it clearly isn't *that* much of a concern to most people :-) > > - Owen > > [*] > https://docs.fedoraproject.org/en-US/fedora/latest/system-administrators-guide/basic-system-configuration/Managing_Users_and_Groups/#s2-users-groups-private-groups > I think we should complete the transition to 0022 umask. IIRC, this is how most Linux distributions have it work today, so we should fall in line here, unless there's a compelling reason not to. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: What happened to umask?
On Fri, May 20, 2022 at 9:08 PM Neal Gompa wrote: > > On Fri, May 20, 2022 at 8:13 PM Owen Taylor wrote: > > > > For years, Red Hat Linux / Fedora systems have had a umask of 0002 for > > regular users as part of the "user private group" scheme [*]. Basically the > > idea is that you can set a directory group-sticky and use it as a common > > work area for a group of users. > > > > A change a couple of years ago seems to have partially changed this - the > > code in /etc/profile was removed with the idea that it should be controlled > > by pam_umask / login.defs instead. > > > > > > https://pagure.io/setup/c/102b349c39e196cc1e34e645c9310acdab7afeef?branch=master > > https://bugzilla.redhat.com/show_bug.cgi?id=1722387 > > > > However, the corresponding code in /etc/bashrc was left .This means that > > for a *login* shell (VT, ssh session, etc.) the umask is 0022 but for an > > interactive *non-login* shell (e.g., gnome-terminal with default settings) > > the umask stayed 0002. > > > > I'm not sure how much the change from 0002 to 0022 was thought through - > > that idea first appears in > > https://bugzilla.redhat.com/show_bug.cgi?id=1722387#c4 with Tomas Mraz > > saying: I do not think that the default umask should be 002 for regular > > users." - I would have expected a short change proposal, honestly. > > > > It seems like we need to do one of two things: > > > > - Go back to the old behavior, maybe by using the usergroups option to > > pam_umask and removing the code from /etc/bashrc > > - Or just go fully to 0022 by removing the code from /etc/bashrc. > > > > What do people think? If the current situation has lasted for several > > years, it clearly isn't *that* much of a concern to most people :-) > > > > - Owen > > > > [*] > > https://docs.fedoraproject.org/en-US/fedora/latest/system-administrators-guide/basic-system-configuration/Managing_Users_and_Groups/#s2-users-groups-private-groups > > > > I think we should complete the transition to 0022 umask. IIRC, this is > how most Linux distributions have it work today, so we should fall in > line here, unless there's a compelling reason not to. This came up for me a few days ago. Some high security distributions elect to set the umask to '077' by default, typically though a setting in /etc/profile.d/, so that sharing with the group or with others requires specific steps. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
