Re: VirtualBox and HOST kernel-5.17.12 weirdness
On 6/4/22 14:17, Ian Laurie wrote: Is anyone else seeing crashes and other strange events in VirtualBox 6.1.34 (from RPMFusion) with Linux guests when the Linux host is running Fedora 36 with kernel-5.17.12? When I first started to see problems on my first host I blamed my SSD drive, memory etc until I noticed the same problems on another host system. The 2 hosts are running very different h/w (one is an ASUS laptop the other an Intel NUC). Long story short I can fix all the problem on both hosts by booting kernel-5.15.11. Weirdness examples... (1) If you boot Fedora 36 Cinnamon guest, login, launch a terminal and just drag it around the screen... Cinnamon crashes. Sometimes the terminal accepts text, sometimes not requiring the VM to be terminated the nasty way. (2) GNOME... similar to above but you get knocked back to the greeter. (3) Xfce... if you run updates, a lot of the downloads have hashes that don't match, requiring re-download. This happens in Cinnamon also. (4) Any GUI... if you run TOR browser it crashes quickly with error 139 usually, or randomly some other error. I am not blaming the kernel, the issue could be a kernel change VirtualBox isn't compatible with. But since I have this on 2 host was wondering if others are already some way along in working out the problem. Sorry, typo, should be "I can fix all the problems on both hosts by booting kernel-5.17.11". -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
VirtualBox and HOST kernel-5.17.12 weirdness
Is anyone else seeing crashes and other strange events in VirtualBox 6.1.34 (from RPMFusion) with Linux guests when the Linux host is running Fedora 36 with kernel-5.17.12? When I first started to see problems on my first host I blamed my SSD drive, memory etc until I noticed the same problems on another host system. The 2 hosts are running very different h/w (one is an ASUS laptop the other an Intel NUC). Long story short I can fix all the problem on both hosts by booting kernel-5.15.11. Weirdness examples... (1) If you boot Fedora 36 Cinnamon guest, login, launch a terminal and just drag it around the screen... Cinnamon crashes. Sometimes the terminal accepts text, sometimes not requiring the VM to be terminated the nasty way. (2) GNOME... similar to above but you get knocked back to the greeter. (3) Xfce... if you run updates, a lot of the downloads have hashes that don't match, requiring re-download. This happens in Cinnamon also. (4) Any GUI... if you run TOR browser it crashes quickly with error 139 usually, or randomly some other error. I am not blaming the kernel, the issue could be a kernel change VirtualBox isn't compatible with. But since I have this on 2 host was wondering if others are already some way along in working out the problem. -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Request to change default /etc/resolv.conf symlink
Do we have any list of significant applications, which use /etc/resolv.conf only? It is used by most of DNS related tools I manage. dig and host use dns only. Sure, they would not be able to report split-DNS required hosts correctly. But browsers tend to use getaddrinfo() glibc calls AFAIK. Can you name some important? On 04. 06. 22 2:56, Michael Catanzaro wrote: Hi, This would break split DNS for applications that read /etc/resolv.conf directly. For desktop systems, that's generally way more important than DNSSEC. For split DNS to work, /etc/resolv.conf needs to be managed by either systemd-resolved or dnsmasq. We would go back to dark ages DNS where requests go to the wrong VPN connection and where local network devices like printers don't work as expected. (I understand that your proposal would have no impact on applications that use glibc for name resolution, but inconsistency in results when using glibc vs. /etc/resolv.conf would be a pretty dissatisfying default.) I admit dnsmasq, which I maintain, has existing integration with NM, which can provide required functionality. It has its own set of problems however, therefore I am not pushing it as a replacement in general. In contrast, DNSSEC is unlikely to be useful for most desktops unless adoption improves dramatically, which seems unlikely. Accordingly, I do not support your proposal. There is no real chance of DNSSEC increased adoption if default configuration does not allow its use. I know there are more networks where it is not working. But current setup prevents it use always, on all networks. Even on those where it worked fine on f32. For servers, the opposite is generally true: DNSSEC is generally way more important than split DNS. Of course, there will be exceptions -- e.g. you're familiar with cases where DNSSEC is needed on desktops, and servers on some complex networks apparently really do require split DNS -- but it's true as a generalization. So if we are forced to choose between working split DNS vs. working DNSSEC, I would pick the split DNS for desktop editions, and DNSSEC for server editions. (On servers, the main benefit of systemd-resolved is the DNS cache.) Sure, I admit servers need DNSSEC more and are actually able to use it already. Also tend to use more often more advanced DNS caches. Of course, it's best if we can do both well. I remember previously watching systemd-resolved DNSSEC issues that you considered to be important in: https://bugzilla.redhat.com/show_bug.cgi?id=1879028 which were, eventually, mostly resolved. Based on your comment #28 in that issue, I had understood that you were more or less satisfied. Well, I had not reopened that bug only because it were slight improvement. But I wanted it working in default configuration, which is requested explicitly: https://bugzilla.redhat.com/show_bug.cgi?id=1945309 You and I have exchanged few comments, but maintainers never wrote a single line. What I would have a tracker for, when those bugs don't receive a single comment after 6 months? I don't keep bitting by resolved only because I always disable it ASAP on my machines. I report every issue I find, but very little of them have any progress. But I see you've been discovering more bugs: https://github.com/systemd/systemd/issues/created_by/pemensik Perhaps it could help the systemd-resolved developers if you could create a list/tracker with issues in order of priority/importance? Having a tracker doesn't mean they'll be fixed, but it might help attract attention to the bugs. Michael I can set severity in bugzilla, but they tend to be ignored. I don't know how to express severity on github issues, which at least receive some feedback. -- Petr Menšík Software Engineer, RHEL Red Hat, http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following builds have been pushed to Fedora EPEL 8 updates-testing cppad-2022.4-1.el8 powerline-2.8.3-3.el8 Details about builds: cppad-2022.4-1.el8 (FEDORA-EPEL-2022-d0ffa65802) C++ Algorithmic Differentiation (AD), cppad-devel and cppad-doc Update Information: Advance to upstream 2022.4. Include 2022 bug fixes. ChangeLog: * Sat May 21 2022 Brad Bell - 2022.4-1 - Advance to upstream 2022.4. Main motivation for this is to make cppad_eigen.hpp work with Eigen 3.4.0. powerline-2.8.3-3.el8 (FEDORA-EPEL-2022-f3c11e6a2c) The ultimate status-line/prompt utility Update Information: Build `powerline` binary with correct linker flags ChangeLog: * Fri Jun 3 2022 Christoph Erhardt - 2.8.3-3 - Build `powerline` binary with correct linker flags - Make Fontconfig symlink relative - Change fontconfig dependency to fontpackages-filesystem (#2093167) References: [ 1 ] Bug #2093167 - powerline-fonts shouldn't have a dependency to fontconfig https://bugzilla.redhat.com/show_bug.cgi?id=2093167 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2091187] Please build perl-File-Tail for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2091187 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #2 from Fedora Update System --- FEDORA-EPEL-2022-b0942ce6d9 has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-b0942ce6d9 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2091187 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Fedora EPEL 9 updates-testing report
The following builds have been pushed to Fedora EPEL 9 updates-testing czmq-4.2.1-1.el9 eccodes-2.26.0-1.el9 lua-bitop-1.0.2-10.el9 ncview-2.1.8-15.el9 perl-File-Tail-1.3-24.el9 powerline-2.8.3-3.el9 Details about builds: czmq-4.2.1-1.el9 (FEDORA-EPEL-2022-d196078275) High-level C binding for 0MQ (ZeroMQ) Update Information: New build for EPEL9 ChangeLog: * Fri Jun 3 2022 Denis Arnaud - 4.2.1-1 - Initial build for EPEL 9 References: [ 1 ] Bug #2088387 - Please branch and build czmq (and czmq-devel) in epel9 https://bugzilla.redhat.com/show_bug.cgi?id=2088387 eccodes-2.26.0-1.el9 (FEDORA-EPEL-2022-1b85e98cbe) WMO data format decoding and encoding Update Information: First epel9 version ChangeLog: * Fri Jun 3 2022 Jos de Kloe - 2.26.0-1 - First epel9 version References: [ 1 ] Bug #2092093 - Please branch and build eccodes for EPEL9 https://bugzilla.redhat.com/show_bug.cgi?id=2092093 lua-bitop-1.0.2-10.el9 (FEDORA-EPEL-2022-e3cbc55e18) C extension module for Lua which adds bit-wise operations on numbers Update Information: Build for EPEL9 ChangeLog: * Thu Jan 20 2022 Fedora Release Engineering - 1.0.2-10 - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild * Thu Jul 22 2021 Fedora Release Engineering - 1.0.2-9 - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild * Tue Jan 26 2021 Fedora Release Engineering - 1.0.2-8 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild * Tue Jul 28 2020 Fedora Release Engineering - 1.0.2-7 - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild * Wed Jan 29 2020 Fedora Release Engineering - 1.0.2-6 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild References: [ 1 ] Bug #2092881 - Please branch and build lua-bitop for EPEL 9 https://bugzilla.redhat.com/show_bug.cgi?id=2092881 ncview-2.1.8-15.el9 (FEDORA-EPEL-2022-afd7ab83e5) A visual browser for netCDF format files Update Information: Build for EPEL9 ChangeLog: * Thu Jan 20 2022 Fedora Release Engineering - 2.1.8-15 - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild * Wed Aug 11 2021 Orion Poplawski - 2.1.8-14 - Rebuild for netcdf 4.8.0 * Tue Aug 10 2021 Orion Poplawski - 2.1.8-13 - Rebuild for netcdf 4.8.0 * Thu Jul 22 2021 Fedora Release Engineering - 2.1.8-12 - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild * Tue Jan 26 2021 Fedora Release Engineering - 2.1.8-11 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild * Tue Jul 28 2020 Fedora Release Engineering - 2.1.8-10 - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild * Wed Jan 29 2020 Fedora Release Engineering - 2.1.8-9 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild perl-File-Tail-1.3-24.el9 (FEDORA-EPEL-2022-b0942ce6d9) Perl extension for reading from continuously updated files Update Information: Build for EPEL9 ChangeLog: * Mon May 30 2022 Jitka Plesnikova - 1.3-24 - Perl 5.36 rebuild * Fri Jan 21 2022 Fedora Release Engineering - 1.3-23 - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild * Thu Jul 22 2021 Fedora Release
Re: Request to change default /etc/resolv.conf symlink
On Sat, 2022-06-04 at 00:45 +0200, Petr Menšík wrote: > Hello, > > We reported issues with DNSSEC tools stopped working with resolved were > enabled shortly before f33 release. I admit I have not noticed soon > enough, because I haven't noticed how it behaves. We were promised a > quick fix back then. Since f33 systemd-resolved is installed by default > on Workstation and Server. > > But the issue remains unchanged still in Fedora 37. Any attempt to use > DNSSEC without manual change just fails. You can try delv from > bind-utils, unbound-host -rD from unbound or drill -S > src.fedoraproject.org from ldns-utils. They all fail on default > installation. I have reported multiple bugs, which remains in NEW state > for years. I have reported also upstream issues, which are either > ignored or closed without proper fix. An assertion like this ought to be backed with evidence. For the record, here are all the issues pemensik has filed against systemd upstream: https://github.com/systemd/systemd/issues?q=is%3Aissue+author%3Apemensik+ and downstream: https://bugzilla.redhat.com/buglist.cgi?component=systemd=pemensik=1=substring_id=12644494=Fedora_format=advanced so folks can read them and draw their own conclusions about the responses. There seem to be some which were addressed and closed, and some which have extensive discussion from various points of view. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Request to change default /etc/resolv.conf symlink
Hi, This would break split DNS for applications that read /etc/resolv.conf directly. For desktop systems, that's generally way more important than DNSSEC. For split DNS to work, /etc/resolv.conf needs to be managed by either systemd-resolved or dnsmasq. We would go back to dark ages DNS where requests go to the wrong VPN connection and where local network devices like printers don't work as expected. (I understand that your proposal would have no impact on applications that use glibc for name resolution, but inconsistency in results when using glibc vs. /etc/resolv.conf would be a pretty dissatisfying default.) In contrast, DNSSEC is unlikely to be useful for most desktops unless adoption improves dramatically, which seems unlikely. Accordingly, I do not support your proposal. For servers, the opposite is generally true: DNSSEC is generally way more important than split DNS. Of course, there will be exceptions -- e.g. you're familiar with cases where DNSSEC is needed on desktops, and servers on some complex networks apparently really do require split DNS -- but it's true as a generalization. So if we are forced to choose between working split DNS vs. working DNSSEC, I would pick the split DNS for desktop editions, and DNSSEC for server editions. (On servers, the main benefit of systemd-resolved is the DNS cache.) Of course, it's best if we can do both well. I remember previously watching systemd-resolved DNSSEC issues that you considered to be important in: https://bugzilla.redhat.com/show_bug.cgi?id=1879028 which were, eventually, mostly resolved. Based on your comment #28 in that issue, I had understood that you were more or less satisfied. But I see you've been discovering more bugs: https://github.com/systemd/systemd/issues/created_by/pemensik Perhaps it could help the systemd-resolved developers if you could create a list/tracker with issues in order of priority/importance? Having a tracker doesn't mean they'll be fixed, but it might help attract attention to the bugs. 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
Re: Installing ffmeg-free degrades firefox video support
Otto Urpelainen wrote: > This is unexpected, because one would expect that installing any variant > of ffmpeg would improve video support, not degrade it. My hypothesis is > that Firefox prefers ffmpeg over openh264, but is not careful enough to > check if the ffmpeg it detects actually supports h264. The thing is, ffmpeg-free actually does support H.264, using (dlopened) OpenH264. What it does not support is the decoder called just "h264" (the native FFmpeg decoder for H.264), which I presume Firefox hardcodes. > It seems clear that there is a bug somewhere, but I cannot decide, > where, hence this post to devel. Should Fedora's Firefox actually have > media.ffmpeg.enabled set to false by default, because Fedora's variant > of ffmpeg has this problem? Should upstream Firefox be smarted about > which decoder library it attempts to use? Or should ffmpeg-free package > do something to avoid this from happening. Any opinions are welcome! As explained above, one issue is that Firefox seems to hardcode the name of the FFmpeg decoder to use. It should not do that. It should instead request any decoder for the H.264 format using the appropriate API (and also query whether the found FFmpeg supports H.264 to begin with, as you state). 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Updated criteria proposal: networking requirements
On Fri, Jun 3 2022 at 04:35:41 PM -0700, Adam Williamson wrote: Using the default network configuration tools for the console and for release-blocking desktops, it must be possible to establish a working connection to common OpenVPN, openconnect-supported and vpnc-supported VPN servers with typical configurations. I would add Wireguard too, plus a limitation that the criterion only applies if the desktop ships with support for these protocols. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
Updated criteria proposal: networking requirements
Hi folks! Some time ago I proposed some specific networking release criteria. I revived the thread back in February, and meeting discussion suggested we should be more intentional and specific about wifi requirements. So, looking at it again, I suggest adding an additional footnote: Footnote titled "Wireless networks": Common wireless network configurations using supported hardware as defined above are covered by this criterion. This includes access to home and enterprise wireless networks using 802.11 series connection protocols and WPA2 and WPA3 personal and enterprise security protocols. Bugs that are specific to particular hardware or configurations will be assessed according to [[Blocker_Bug_FAQ|hardware-dependent-issues|the normal considerations for such issues]]. Here is the full proposal again, with the new footnote included: # === Network requirements === Each of these requirements apply to both installer and installed system environments. For any given installer environment, the 'default network configuration tools' are considered to be those the installer documents as supported ways to configure networking (e.g. for anaconda-based environments, configuration via kernel command line options, a kickstart, or interactively in anaconda itself are included). Basic networking It must be possible to establish both IPv4 and IPv6 network connections using both typical router-provided addressing systems (e.g. DHCP on IPv4 or SLAAC or IPv6) and static addressing. The default network configuration tools for the console, for release-blocking desktops and for installer environments must work well enough to allow typical network connection configuration operations without major workarounds. Standard network functions such as address resolution and connections with common protocols such as ping, HTTP and ssh must work as expected. Footnote titled "Supported hardware": Supported network hardware is hardware for which the Fedora kernel includes drivers and, where necessary, for which a firmware package is available. If support for a commonly-used piece or type of network hardware that would usually be present is omitted, that may constitute a violation of this criterion, after consideration of the [[Blocker_Bug_FAQ|hardware-dependent- issues|normal factors for hardware-dependent issues]]. Similarly, violations of this criteria that are hardware or configuration dependent are, as usual, subject to consideration of those factors when determining whether they are release-blocking. Footnote titled "Wireless networks": Common wireless network configurations using supported hardware as defined above are covered by this criterion. This includes access to home and enterprise wireless networks using 802.11 series connection protocols and WPA2 and WPA3 personal and enterprise security protocols. Bugs that are specific to particular hardware or configurations will be assessed according to [[Blocker_Bug_FAQ|hardware-dependent-issues|the normal considerations for such issues]]. VPN connections Using the default network configuration tools for the console and for release-blocking desktops, it must be possible to establish a working connection to common OpenVPN, openconnect-supported and vpnc-supported VPN servers with typical configurations. Footnote titled "Supported servers and configurations": As there are many different VPN server applications and configurations, blocker reviewers must use their best judgment in determining whether violations of this criterion are likely to be encountered commonly enough to block a release, and if so, at which milestone. As a general principle, the more people are likely to use affected servers and the less complicated the configuration required to hit the bug, the more likely it is to be a blocker. # Any more thoughts, comments, adjustments etc? Thanks! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Request to change default /etc/resolv.conf symlink
Petr Menšík writes: If systemd-resolved ever becomes capable as a good DNS cache, we can return it back to domain port. I don't think it is ready for that. Search the archives of the users list for systemd-resolved complaints. I've done my share. Perhaps a bunch of them coming from @redhat.com will result in some changes, but I doubt it. pgpMpvbeZ4m5q.pgp Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Self Introduction: Yizheng Xie
Welcome (again) Yizheng! On Fri, 2022-06-03 at 21:56 +, Yizheng Xie via devel wrote: > Hello, Fedora developer community! > > My name is Yizheng Xie (Fedora Project Username: yizhengxie). > Currently I am a Production Engineer Intern in Meta Kernel Team, > specifically in Linux Userspace projects. I am a first-year master > student in Boston University in Computer Science. My software > engineering skills are most solid in Python, Java, C++ and Golang. > > I will work on Rust Packaging Tooling this summer under the > guidance from Michel (Fedora Project Username:salimma). I am > happy to continue contributing as a package maintainer after my > internship! > Great having you here (both at Fedora and at Meta)! I sponsored Yizheng as a packager - he'll be co-maintaining some packages to get experience with packaging - and will be mentoring him throughout the process. Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Request to change default /etc/resolv.conf symlink
Hello, We reported issues with DNSSEC tools stopped working with resolved were enabled shortly before f33 release. I admit I have not noticed soon enough, because I haven't noticed how it behaves. We were promised a quick fix back then. Since f33 systemd-resolved is installed by default on Workstation and Server. But the issue remains unchanged still in Fedora 37. Any attempt to use DNSSEC without manual change just fails. You can try delv from bind-utils, unbound-host -rD from unbound or drill -S src.fedoraproject.org from ldns-utils. They all fail on default installation. I have reported multiple bugs, which remains in NEW state for years. I have reported also upstream issues, which are either ignored or closed without proper fix. It stop any my attempts at getting DNSSEC more popular and used. It is clearly not high on systemd team priority list. For years. It has caused regression without a proper fix. I request to change default resolv.conf back to file generated by Network Manager. We have resolve nss plugin listed in /etc/nsswitch.conf, so it would still cache all name requests from glibc. But it would not interfere with DNS specialized tools in a weird way, like LLMNR [1]. I don't think systemd-resolved provides any other record types than reverse mapping or addresses. All that can be safely provided via resolve nss plugin, where it would not cause any regressions. A minimal change would be using /run/systemd/resolve/resolv.conf as a target of current /etc/resolv.conf symlink. If systemd-resolved ever becomes capable as a good DNS cache, we can return it back to domain port. I don't think it is ready for that. Opinions? Regards, Petr 1. https://github.com/systemd/systemd/issues/23494 -- Petr Menšík Software Engineer, RHEL Red Hat, http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: RPM Macros for Build Flags (System-Wide Change proposal)
Ben Cotton kirjoitti 2.6.2022 klo 22.27: * Policies and guidelines: ** The Fedora packaging policy will be updated to require that new flags added to redhat-rpm-config come with their own RPM macro. By the proposal owners, I presume? The guidelines should also be updated to present the new macros as the preferred way of modifying build flags. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Install Using GPT on x86_64 BIOS by Default (System-Wide Change proposal)
> Am 03.06.2022 um 07:17 schrieb Neal Gompa : > > > It's not *that* typical in my experience. Most of the SME server > environments I know of don't have that. It's more common in larger > server environments, but they also typically use hardware RAID there > instead of software RAID. We don’t have detailed numbers how Fedora is used. But we know from questions and discussions that people use software raid. And software raid is supported by Anaconda for years now. And in my memory, these were all cases in the private or SME environment, and often with rented hardware in some commercial data centers, where hardware raid is usually offered at a considerable price premium. Anyway, we have users who use software raid and rely on us as a distribution, and they should be able to continue to do so in my opinion. > If we care about this behavior, we should have a test case to verify > this behavior for all three Anaconda install modes (MBR+BIOS, > GPT+BIOS, UEFI). If this is truly something we care about, then we > should have communicated this need to the Anaconda team so that they > would care about it, independent of this feature. We have test cases for the former 2 in issue #87 (https://pagure.io/fedora-server/issue/87) and Stephen Gallagher copied it to a bugzilla bug report (https://bugzilla.redhat.com/show_bug.cgi?id=2092116). I’ll add a UEFI test case to a separate issue this weekend. I’ve it already in place on my test equipment here and have just to copy and paste it. > dmraid has been unmaintained … Yes, of course, it’s mdadm. That was a slip into the good old days. Don’t mind. > calling it "mischief" is disingenuous, since until this week, nobody > ever mentioned this case at all. We even discussed the GPT thing > before I proposed the Change and it did not come up. > Yes, when we discussed this in the server IRC meeting before the change proposal was published, I hadn't thought of it either. But all of us know it since about one year. But we missed to pick it up carry it forward. > You know why I want this Change, and I even wrote it into the > proposal. We have to do *something* to start preparing new installs > for a world when legacy BIOS is *gone*, and switching to GPT is a > simple first step to doing that. Yes, I know, and we completely agree on that from the very beginning. My only suggestion is to organize this changeover process in such a way that our users are not negatively affected in any way. And about this there were (hopefully just) misunderstandings, which we could clarify by now. The changeover only affects Workstation and Server anyway. All others are either spins of Workstation or do not use Anaconda. So, let’s try to convince the Anaconda team to fix the GPT biosboot issue until beta. And if they need more time, let’s either postpone the switch to F38 or switch Workstation now (provided there are no software raid users) and switch Server as soon as the Anaconda bug is fixed. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
Installing ffmeg-free degrades firefox video support
I have discovered that installing the ffmpeg-free package degrades Firefox video support. Without any kind of ffmpeg installed, Firefox is able to play all the videos I want to watch. Installing RPM Fusion's ffmpeg package does not change this. But, installing ffmpeg-free from Fedora repositories causes some videos not to play. This is unexpected, because one would expect that installing any variant of ffmpeg would improve video support, not degrade it. My hypothesis is that Firefox prefers ffmpeg over openh264, but is not careful enough to check if the ffmpeg it detects actually supports h264. As a workaround, I can set media.ffmpeg.enabled in Firefox's about:config to false. Then all videos play again, even with ffmpeg-free installed. Here is an example video from Youtube that can be used as a reproducer: https://www.youtube.com/watch?v=ETsAH96BsBg It seems clear that there is a bug somewhere, but I cannot decide, where, hence this post to devel. Should Fedora's Firefox actually have media.ffmpeg.enabled set to false by default, because Fedora's variant of ffmpeg has this problem? Should upstream Firefox be smarted about which decoder library it attempts to use? Or should ffmpeg-free package do something to avoid this from happening. Any opinions are welcome! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
Self Introduction: Yizheng Xie
Hello, Fedora developer community! My name is Yizheng Xie (Fedora Project Username: yizhengxie). Currently I am a Production Engineer Intern in Meta Kernel Team, specifically in Linux Userspace projects. I am a first-year master student in Boston University in Computer Science. My software engineering skills are most solid in Python, Java, C++ and Golang. I will work on Rust Packaging Tooling this summer under the guidance from Michel (Fedora Project Username: salimma). I am happy to continue contributing as a package maintainer after my internship! Thank you! Yizheng ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
F37 proposal: Erlang 25 (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/Erlang_25
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 ==
Update Erlang/OTP to version 25.
== Owner ==
* Name: [[User:Peter|Peter Lemenkov]], [[SIGs/Erlang|Fedora Erlang
SIG]], [[User:bowlofeggs|Randy Barlow]], [[User:jcline|Jeremy Cline]]
* Email: lemen...@gmail.com, erl...@lists.fedoraproject.org,
bowlofe...@fedoraproject.org, jcl...@fedoraproject.org
== Detailed Description ==
Upgrade Erlang to version 25 which brings a lot of changes. Just a few
highlights [https://www.erlang.org/blog/my-otp-25-highlights/ from
many]:
* [https://www.erlang.org/blog/parallel-signal-sending-optimization/
The Many-to-One Parallel Signal Sending Optimization].
* [https://www.erlang.org/blog/type-based-optimizations-in-the-jit/
Type-Based Optimizations in the JIT].
* New 'maybe' operator.
* The JIT now supports the AArch64 (ARM64) architecture.
* Better support for perf and gdb.
* Better error reporting in some cases.
Aside from this, we plan to further improve quality of Erlang and
related packages. These are shortcomings we want to address:
* Finish switching to rebar3 as a main build tool and deprecate rebar2.
** Improve [[User:Peter/Erlang_Packaging_Guidelines|Erlang Packaging
Guidelines]] according to this switch and promote it as the official
guideline.
* Every daemon written in Erlang has its own logging solution which
doesn't use neither syslog nor Journald. We should start switching
them to unified logger.
* We should allow D-Bus API via [https://github.com/lizenn/erlang-dbus
erlang-dbus] library or any other recent implementations..
* SELinux rules for main Erlang applications (Ejabberd, CouchDB,
RabbitMQ) are still outdated or missing.
== Benefit to Fedora ==
Fedora users, both developers and end-users, will have visible
benefits from using Fedora-provided packages. Namely:
* Improved scalability and robustness.
* Much easier developing and debugging.
== Scope ==
* Proposal owners:
** [https://bugzilla.redhat.com/show_bug.cgi?id=2055490 Upgrade Erlang
to the latest version (25.0)].
** Every Erlang daemon's systemd unit should require epmd.socket.
** Upgrade outdated packages:
*** {{package|riak|Riak}}
{{package|riak|Riak}} has has been retired. We have to re-add it back.
*** {{package|ejabberd|Ejabberd}}
*** {{package|rabbitmq-server|RabbitMQ}}.
*** {{package|couchdb|CouchDB}}
{{package|riak|CouchDB}} has has been retired. We have to re-add it back.
** {{package|erlang-rebar3|rebar3}}
** Package GDB macros for easier coredump debugging (see also
[https://bugzilla.redhat.com/show_bug.cgi?id=663253 this ticket]).
* Other developers: N/A
* Release engineering: TBA
* Policies and guidelines:
** We should promote officially
[[User:Peter/Erlang_Packaging_Guidelines|Erlang Packaging
Guidelines]].
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
* Binaries compiled with Erlang 22 and older are no longer compatible.
== How To Test ==
* Ensure that high-grade Erlang applications are still working:
{| border="1"
|-
| '''Name''' || '''Tested'''
|-
| {{package|couchdb}} || {{no}} (package was retired :( )
|-
| {{package|ejabberd}} || {{no}}
|-
| {{package|elixir}} || {{no}}
|-
| {{package|rabbitmq-server}} || {{no}}
|-
| {{package|riak}} || {{no}} (package was retired :( )
|-
| {{package|wings}} || {{no}}
|}
* Collect feedback from volunteers regarding their experience with
this Erlang/OTP version
== User Experience ==
Users will get more robust, scalable, and fast Erlang applications.
== Dependencies ==
The following packages must be rebuilt: NIF-libraries.
== Contingency Plan ==
* Contingency mechanism: None necessary. Instead of falling back to
the previous version we should fix existing packages in order to help
the Community. We should also monitor upstream development process for
potentially discovered issues and proactively apply patches (as we
already did with [[Features/Erlang_R14|Erlang R14]],
[[Features/Erlang_R15|Erlang R15]], [[Features/Erlang_R16|Erlang
R16]], [[Changes/BetterErlangSupport|Erlang 17]],
[[Changes/Erlang_18|Erlang 18]], [[Changes/Erlang_19|Erlang 19]],
[[Changes/Erlang_20|Erlang 20]], [[Changes/Erlang_21|Erlang 21]],
[[Changes/Erlang_22|Erlang 22]], [[Changes/Erlang_23|Erlang 23]], and
[[Changes/Erlang_24|Erlang 24]]). It should be noted that this change
consists from an independent or loosely coupled smaller changes. If we
fail to deliver some changes in time, we should reschedule these exact
changes to the future Fedora release while keeping already implemented
ones.
* Contingency deadline: N/A
* Blocks release? N/A
* Blocks product? N/A
== Documentation ==
* [https://www.erlang.org/news/157 Erlang/OTP 25.0 release notes]
== Release Notes ==
Erlang/OTP 25.0 is available in
F37 proposal: Erlang 25 (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/Erlang_25
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 ==
Update Erlang/OTP to version 25.
== Owner ==
* Name: [[User:Peter|Peter Lemenkov]], [[SIGs/Erlang|Fedora Erlang
SIG]], [[User:bowlofeggs|Randy Barlow]], [[User:jcline|Jeremy Cline]]
* Email: lemen...@gmail.com, erl...@lists.fedoraproject.org,
bowlofe...@fedoraproject.org, jcl...@fedoraproject.org
== Detailed Description ==
Upgrade Erlang to version 25 which brings a lot of changes. Just a few
highlights [https://www.erlang.org/blog/my-otp-25-highlights/ from
many]:
* [https://www.erlang.org/blog/parallel-signal-sending-optimization/
The Many-to-One Parallel Signal Sending Optimization].
* [https://www.erlang.org/blog/type-based-optimizations-in-the-jit/
Type-Based Optimizations in the JIT].
* New 'maybe' operator.
* The JIT now supports the AArch64 (ARM64) architecture.
* Better support for perf and gdb.
* Better error reporting in some cases.
Aside from this, we plan to further improve quality of Erlang and
related packages. These are shortcomings we want to address:
* Finish switching to rebar3 as a main build tool and deprecate rebar2.
** Improve [[User:Peter/Erlang_Packaging_Guidelines|Erlang Packaging
Guidelines]] according to this switch and promote it as the official
guideline.
* Every daemon written in Erlang has its own logging solution which
doesn't use neither syslog nor Journald. We should start switching
them to unified logger.
* We should allow D-Bus API via [https://github.com/lizenn/erlang-dbus
erlang-dbus] library or any other recent implementations..
* SELinux rules for main Erlang applications (Ejabberd, CouchDB,
RabbitMQ) are still outdated or missing.
== Benefit to Fedora ==
Fedora users, both developers and end-users, will have visible
benefits from using Fedora-provided packages. Namely:
* Improved scalability and robustness.
* Much easier developing and debugging.
== Scope ==
* Proposal owners:
** [https://bugzilla.redhat.com/show_bug.cgi?id=2055490 Upgrade Erlang
to the latest version (25.0)].
** Every Erlang daemon's systemd unit should require epmd.socket.
** Upgrade outdated packages:
*** {{package|riak|Riak}}
{{package|riak|Riak}} has has been retired. We have to re-add it back.
*** {{package|ejabberd|Ejabberd}}
*** {{package|rabbitmq-server|RabbitMQ}}.
*** {{package|couchdb|CouchDB}}
{{package|riak|CouchDB}} has has been retired. We have to re-add it back.
** {{package|erlang-rebar3|rebar3}}
** Package GDB macros for easier coredump debugging (see also
[https://bugzilla.redhat.com/show_bug.cgi?id=663253 this ticket]).
* Other developers: N/A
* Release engineering: TBA
* Policies and guidelines:
** We should promote officially
[[User:Peter/Erlang_Packaging_Guidelines|Erlang Packaging
Guidelines]].
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
* Binaries compiled with Erlang 22 and older are no longer compatible.
== How To Test ==
* Ensure that high-grade Erlang applications are still working:
{| border="1"
|-
| '''Name''' || '''Tested'''
|-
| {{package|couchdb}} || {{no}} (package was retired :( )
|-
| {{package|ejabberd}} || {{no}}
|-
| {{package|elixir}} || {{no}}
|-
| {{package|rabbitmq-server}} || {{no}}
|-
| {{package|riak}} || {{no}} (package was retired :( )
|-
| {{package|wings}} || {{no}}
|}
* Collect feedback from volunteers regarding their experience with
this Erlang/OTP version
== User Experience ==
Users will get more robust, scalable, and fast Erlang applications.
== Dependencies ==
The following packages must be rebuilt: NIF-libraries.
== Contingency Plan ==
* Contingency mechanism: None necessary. Instead of falling back to
the previous version we should fix existing packages in order to help
the Community. We should also monitor upstream development process for
potentially discovered issues and proactively apply patches (as we
already did with [[Features/Erlang_R14|Erlang R14]],
[[Features/Erlang_R15|Erlang R15]], [[Features/Erlang_R16|Erlang
R16]], [[Changes/BetterErlangSupport|Erlang 17]],
[[Changes/Erlang_18|Erlang 18]], [[Changes/Erlang_19|Erlang 19]],
[[Changes/Erlang_20|Erlang 20]], [[Changes/Erlang_21|Erlang 21]],
[[Changes/Erlang_22|Erlang 22]], [[Changes/Erlang_23|Erlang 23]], and
[[Changes/Erlang_24|Erlang 24]]). It should be noted that this change
consists from an independent or loosely coupled smaller changes. If we
fail to deliver some changes in time, we should reschedule these exact
changes to the future Fedora release while keeping already implemented
ones.
* Contingency deadline: N/A
* Blocks release? N/A
* Blocks product? N/A
== Documentation ==
* [https://www.erlang.org/news/157 Erlang/OTP 25.0 release notes]
== Release Notes ==
Erlang/OTP 25.0 is available in
[Bug 2091187] Please build perl-File-Tail for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2091187 Fedora Update System changed: What|Removed |Added Status|NEW |MODIFIED --- Comment #1 from Fedora Update System --- FEDORA-EPEL-2022-b0942ce6d9 has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-b0942ce6d9 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2091187 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Review swaps
Dear all, I'm looking to package task (https://taskfile.dev/) for Fedora and would like to offer to swap reviews: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2078117 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2078118 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2093467 All three spec files were generated automatically and the reviews should be trivial (at least I hope so). Thanks all, fuller -- Mark E. Fuller, Ph.D. ful...@fedoraproject.org ful...@stossrohr.net @fuller:one.ems.host https://www.stossrohr.net PGP Fingerprint: 73F1 A30C BDF4 DB4B C75F FD0F D599 E76C FFCA BF60 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 Change: Replace jwhois package with whois for Fedora Workstation (Self-Contained Change proposal)
Hi, see: https://pagure.io/fedora-comps/pull-request/729 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Help with go spec file
Hi Mark, Hau idatzi du Mark E. Fuller (ful...@fedoraproject.org) erabiltzaileak (2022 eka. 3, or. (17:52)): > > Hi all, > > I'm fairly new to go and am looking to make a spec file and build > jsonnet (https://github.com/google/go-jsonnet/, https://jsonnet.org/). go-jsonnet is already packaged: https://src.fedoraproject.org/rpms/golang-github-google-jsonnet/ If you want to update or extend it, feel free to open a pull request. > 1) What is the preferred way to ignore (or remove) unnecessary > BUILD.bazel files? There is one in cmd/ which is obviously not a > buildable command, and so this results in an error in the naive use case. You can remove the files in the %prep section for example. > 2) How should nested folders in cmd/ be built? Here, again, the basic > template throws an error since cmd/internal contains no *.go files, only > a BUILD.bezel file and a nested cmd directory. Look at the spec file of the already packaged version. If something is missing you can add following the example. Kind regards, Mikel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: News from printing world aka PWG May 2022 meetup
Thank you for that COPR repository. I think using SNAPs on Fedora is wrong. I don't like what snaps do with mounted filesystems and consider flatpak more appropriate replacement. But flatpak wants to isolate application from the system. Those apps require to integrate into the system on the other hand. I assume from provided explanation that printer apps needs direct access to USB ports and therefore are not good candidate for placing into some kind of container. It needs a direct access to the host hardware, therefore it belongs to the system. Or is it possible to forward just limited sets of of USB devices into a container? Could perhaps alternative package with unreleased snapshots be provided? That would allow packaging required printer apps, which cannot use stable versions. Should be module considered for applications and new version of cups filters? On 03. 06. 22 3:14, Brandon Nielsen via devel wrote: On 5/19/22 3:27 AM, Zdenek Dohnal wrote: [Snip] - Till Kamppeter wrote printer applications which covers all printer drivers in Debian distribution - we don't have any additional printer driver package in Fedora, so all our driver packages are covered as well Since there were some questions the last time this came up, see this[0] gnome-control-center upstream discussion for how printer applications may be integrated into the desktop environment printer configuration. - printer applications (the solution for driver-only printers how to work with IPP-only CUPS) are available as SNAPs in Fedora (feel free to try them and leave feedback at the respective OpenPrinting project https://github.com/orgs/OpenPrinting/repositories ), packaging them as RPMs is blocked due dependency on cups-filters 2.0, which is not released yet (though IIRC someone from Fedora community - maybe Brandon Nielsen - has them in copr) That would be me[1], though I haven't been giving them the attention they need lately. [Snip] [0] - https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/1878 [1] - https://copr.fedorainfracloud.org/coprs/nielsenb/printer-apps/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 -- Petr Menšík Software Engineer, RHEL Red Hat, http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
Help with go spec file
Hi all,
I'm fairly new to go and am looking to make a spec file and build
jsonnet (https://github.com/google/go-jsonnet/, https://jsonnet.org/).
The go2rpm utility has proven very helpful, but there appear to be two
irregularities with building this package that I don't know offhand how
to address (including from reading
https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/).
1) What is the preferred way to ignore (or remove) unnecessary
BUILD.bazel files? There is one in cmd/ which is obviously not a
buildable command, and so this results in an error in the naive use case.
2) How should nested folders in cmd/ be built? Here, again, the basic
template throws an error since cmd/internal contains no *.go files, only
a BUILD.bezel file and a nested cmd directory.
Thank you all,
fuller
--
Mark E. Fuller, Ph.D.
ful...@fedoraproject.org
ful...@stossrohr.net
@fuller:one.ems.host
https://www.stossrohr.net
PGP Fingerprint: 73F1 A30C BDF4 DB4B C75F FD0F D599 E76C FFCA BF60# Generated by go2rpm 1.6.0
%bcond_without check
# https://github.com/google/go-jsonnet
%global goipath github.com/google/go-jsonnet
Version:0.18.0
%gometa
%global common_description %{expand:
This an implementation of Jsonnet in pure Go.
It is a feature complete, production-ready implementation.
It is compatible with the original Jsonnet C++ implementation.
Bindings to C and Python are available (but not battle-tested yet).}
%global golicenses LICENSE
%global godocs README.md linter/README.md
Name: %{goname}
Release:%autorelease
Summary:None
# Upstream license specification: Apache-2.0
License:ASL 2.0
URL:%{gourl}
Source0:%{gosource}
%description
%{common_description}
%gopkg
%prep
%goprep
%generate_buildrequires
%go_generate_buildrequires
%build
for cmd in cmd/* ; do
%gobuild -o %{gobuilddir}/bin/$(basename $cmd) %{goipath}/$cmd
done
for cmd in c-bindings; do
%gobuild -o %{gobuilddir}/bin/$(basename $cmd) %{goipath}/$cmd
done
%install
%gopkginstall
install -m 0755 -vd %{buildroot}%{_bindir}
install -m 0755 -vp %{gobuilddir}/bin/* %{buildroot}%{_bindir}/
%if %{with check}
%check
%gocheck
%endif
%files
%license LICENSE
%doc README.md linter/README.md
%{_bindir}/*
%gopkgfiles
%changelog
%autochangelog
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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
[Bug 2091743] perl-Catalyst-Plugin-Session-0.43 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2091743 Upstream Release Monitoring changed: What|Removed |Added Summary|perl-Catalyst-Plugin-Sessio |perl-Catalyst-Plugin-Sessio |n-0.42 is available |n-0.43 is available --- Comment #1 from Upstream Release Monitoring --- Releases retrieved: 0.43 Upstream release that is considered latest: 0.43 Current version/release in rawhide: 0.41-14.fc36 URL: https://metacpan.org/release/Catalyst-Plugin-Session Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/18278/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-Catalyst-Plugin-Session -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2091743 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Install Using GPT on x86_64 BIOS by Default (System-Wide Change proposal)
On Thu, Jun 2, 2022 at 6:19 PM Peter Boy wrote: > > > > > Am 02.06.2022 um 22:42 schrieb Neal Gompa : > > > > > > It's not standard at all. We don't even test for this setup regularly. > > It's not a test case, and it's not even supposed to work right now. > > It’s standard as it is a typical use case in private or SME environments. If that's true there should be plenty of people willing to put in the work to make this work reliably. So far they haven't, in particular on UEFI. > And do you really think we distribute dmraid for years now "and it's not even > supposed to work right now.“? dmraid is deprecated in favor of either mdadm or LVM based RAID (both use the kernel's md driver as the backend), for a very long time. dmraid is even deprecate at least as far back as RHEL 7.6 > And don't hide behind formalistic arguments that just suit you by chance. > Your change proposal deliberately makes it impossible for existing server > users (or makes it unnecessarily overly difficult) who have relied (and could > rely) on us so far to continue using Fedora Server. I consider this > irresponsible. And I don't understand why you stubbornly insist on this > change proposal as is, instead of looking for solutions that keep mischief > away from our users and change to GPT as default (which is undoubtedly the > future standard). GPT is already the default when the drive size is > 2 TB, for about a decade. GPT is the default on UEFI since the start. So the problem you're talking about, while real, seems to be a low enough of a priority that no one really wants to fix the problem - so far. You continue to use emotionally charged language as both a distraction from the real issue as well as a motivator to stop a feature. The reality is MBR support is going away, because BIOS support is going away. This feature is part of moving forward with that reality. We cannot make people do work they don't want to do. The solution to the degraded raid problem is actually relatively well understood, it's just that insufficient resources have come forward to actually solve the issue. But that cannot be an impediment for making other necessary changes. > > Also, any system with drives >=2TB will get GPT automatically, you > > can't have MBR in those setups. All this does is remove the default > > special case for smaller disks. > > This is a completely different case. For disks > 2 TB simply nothing changes, > neither better nor worse. For disks < 2 TB your change proposal results in a > deterioration. Why do you want it so badly? It's not completely different, it results in the *exact* problem you're complaining about. You don't get to say the effect of GPT > 2T is OK, but it's a negative when applied to < 2T as if your entire strategy for working "standard" and "typical" use cases means < 2T drives are mandatory. If the use case is important, the issue needs to be fixed. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: RPM Macros for Build Flags (System-Wide Change proposal)
On 6/3/22 02:24, Vít Ondruch wrote:
Hi Tom,
Since you are looking into this and I like this proposal, have you considered
to look alto into `%extension_*flags`:
https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/macros#_120-123
I have not considered this. Do you think there is some way this proposal
could be extended to help solve this problem as well?
-Tom
This is longstanding issue:
https://bugzilla.redhat.com/1284684
Where we have several proposals for fix, but non of them is really appealing to
me:
https://src.fedoraproject.org/rpms/ruby/pull-request/110
https://src.fedoraproject.org/rpms/ruby/pull-request/117
BTW isn't the `_flag_` prefix too generic? And also, the initial underscore
implies that this is internal macro which should ideally not be used. So should
it be rather removed or not?
Vít
Dne 02. 06. 22 v 21:27 Ben Cotton napsal(a):
https://fedoraproject.org/wiki/Changes/RPMMacrosForBuildFlags
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 ==
Create a corresponding macro for each compiler flag in the
redhat-rpm-config macro file and create "extra flag" macros to make it
easier for packages to add and remove compiler flags.
== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email:
== Detailed Description ==
The macros file in the redhat-rpm-config package contains a list of
default compiler flags for packages to use when compiling C, C++, and
Fortran packages. There is currently no standard way to remove or add
to the set of default flags. Most packages use a combination of echo
and sed to remove unwanted flags or add new ones. Some examples:
compiler-rt:
[https://src.fedoraproject.org/rpms/compiler-rt/blob/rawhide/f/compiler-rt.spec#_6
global optflags %(echo %{optflags} -D_DEFAULT_SOURCE)]
julia:
[https://src.fedoraproject.org/rpms/julia/blob/rawhide/f/julia.spec#_267
%global optflags %(echo %{optflags} | sed 's/-Wp,-D_GLIBCXX_ASSERTIONS
//')]
This change will add new macros which will make it easier for packages
to add and remove their own compiler flags. This strategy is already
used to some extent with feature macros like %{_lto_cflags},
%{_hardening_cflags}, etc, but these new macros will give packagers
even more fine-grained control over the options.
The proposed macros for adding new flags are:
%_pkg_extra_cflags
%_pkg_extra_cxxflags
%_pkg_extra_fflags
%_pkg_extra_ldflags
These will be added to %{build_cflags}, %{build_cxxflags},
%{build_fflags}, and %{build_ldflags} respectively to allow packges to
add their own flags to the default list: e.g.
%build_cflags %{optflags} %{_pkg_extra_cflags}
The proposed new macros to represent existing flags are:
%_flag_fstack_protector_strong -fstack-protector-strong
%_flag_z_now -Wl,-z,now
%_flag_z_defs -Wl,-z,defs
%_flag_flto_auto -flto=auto
%_flag_ffat_lto_objects -ffat-lto-objects
%_flag_o -O2
%_flag_f_exceptions -fexceptions
%_flag_g -g
%_flag_grecord_gcc_switches -grecord-gcc-switches
%_flag_pipe -pipe
%_flag_wall -Wall
%_flag_werror_format_security -Werror=format-security
%_flag_fortify_source -Wp,-D_FORTIFY_SOURCE=2
%_flag_glibcxx_assertions -Wp,-D_GLIBCXX_ASSERTIONS
%_flag_asynchronous_unwind_tables -fasynchronous-unwind-tables
%_flag_fstack_clash_protection -fstack-clash-protection
%_flag_fcf_protection -fcf-protection
%_flag_mbranch_protection_standard -mbranch-protection=standard
With these new macros, the examples from above could be re-written as:
compiler-rt: %global _pkg_extra_cflags -D_DEFAULT_SOURCE
julia: %global _flag_glibcxx_assertions %{nil}
For more details see the
[https://src.fedoraproject.org/fork/tstellar/rpms/redhat-rpm-config/c/0ee9a8c989b55c631f870ad311cdca87329034be?branch=macro-flags
Prototype Implementation].
In addition to adding these new macros, the packaging guidelines will
be updated to require that all new flags added to redhat-rpm-config
have their own RPM macro.
== Benefit to Fedora ==
* It will provide a standard way to disable existing compiler flags or
enable new ones that is more simple and robust than the existing echo
+ sed solution.
* It will make it easier to determine which packages disable or add
compiler flags by doing a simple grep of the spec files.
* It will make it easier for toolchain developers to experiment with
adding new flags to the distribution as this can be done with a simple
macro definition instead of patching redhat-rpm-config.
== Scope
Re: F37 proposal: RPM Macros for Build Flags (System-Wide Change proposal)
On 6/3/22 03:43, Fabio Valentini wrote: On Fri, Jun 3, 2022 at 11:25 AM Vít Ondruch wrote: BTW isn't the `_flag_` prefix too generic? And also, the initial underscore implies that this is internal macro which should ideally not be used. So should it be rather removed or not? I agree that the "_flag_" prefix might be a little too generic, but what would be a better alternative? Maybe something like _optflag_, to match what they are "collected into" (i.e. %optflags)? What about prefixing them with _build_flag_ The redhat-rpm-config docs[1], recommend using the %build_*flags macros instead of %optflags, so maybe we should try to match that. [1] https://src.fedoraproject.org/rpms/redhat-rpm-config//blob/rawhide/f/buildflags.md -Tom Also, macro names with single leading underscores are *fine* (see also %_bindir, %_libdir, %_datadir, etc.). Those with *double* leading underscores are the ones that should be considered "internal" implementation details. 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Install Using GPT on x86_64 BIOS by Default (System-Wide Change proposal)
On Thu, Jun 2, 2022 at 3:27 PM Peter Boy wrote: > > > > > Am 02.06.2022 um 19:20 schrieb Zbigniew Jędrzejewski-Szmek > > : > > > > On Mon, May 30, 2022 at 09:18:27AM +0200, Peter Boy wrote: > >> > >> ... > >> > >> And even those who can continue to use Fedora Server via update are under > >> the threat of having to switch distributions overnight in the event of a > >> technical error. Fedora will become unusable for them. A great "feature", > >> that you would like to introduce, obviously at all costs. > > > > Is 'inst.mbr' a viable workaround? (The bug mentions 'inst.gpt' to trigger > > the issue.) > > > According to the latest Anaconda documentation [1] there is no option > inst.mbr, there is just inst.gpt. Maybe, it is an undocumented feature. > > And do we really want our users to fiddle around with editing boot line > options as a standard procedure for using a standard use case? Define standard. I can't tell what you mean by it here. Bootable degraded raid is not a common use case. It's not a default and preset configuration in the installer. You really have to know what you're doing, and you have to know the installer's idiosyncrasies to make the installation work this way. This use case is not in the Server edition product requirements doc, or technical spec doc, or in Fedora release criterion It is true that the use case is reasonable and useful, but it is also unusual. If it's really important, then it at least needs a discussion on the test@ list, with QA folks about how to go about making it a release criterion, which minimally involves (a) writing up the criterion, using unambiguous language, narrowly defining the requirement (b) documentation changes (c) creating test cases (d) resources to actually run the test cases every release cycle (e) optionally+hopfully some portion of the testing can be automated but all the previous items are prerequisites to that. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora elections voting now open
Voting in the Fedora Linux 36 elections is now open. Go to the Elections app[1] to cast your vote. Voting closes at 23:59 UTC on Thursday 16 June. Don't forget to claim your "I Voted" badge when you cast your ballot. Links to candidate interviews are in the Elections app and on the Community Blog[2]. [1] https://elections.fedoraproject.org/ [2] https://communityblog.fedoraproject.org/f36-elections-voting-now-open/ -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel-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
Fedora elections voting now open
Voting in the Fedora Linux 36 elections is now open. Go to the Elections app[1] to cast your vote. Voting closes at 23:59 UTC on Thursday 16 June. Don't forget to claim your "I Voted" badge when you cast your ballot. Links to candidate interviews are in the Elections app and on the Community Blog[2]. [1] https://elections.fedoraproject.org/ [2] https://communityblog.fedoraproject.org/f36-elections-voting-now-open/ -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel-announce@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
CPE Weekly Update – Week 22 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: May 30st to June 3rd 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-22-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 Update -- ### Fedora Infra * Got to the bottom of an issue causing python38 modules to not be available in the epel8 buildroot * Bunch of reinstalling of openqa workers to help AdamW isolate a lockup issue. Still ongoing. * Moved some more ocp3->ocp4 apps. * Tracked down a https push segfault on src.fp.o to the new jq package in rhel 8.6 (downgraded and filed bug) * Got internetx02 (new donated hw replacement for 01) installed with rhel9. * New ipsilon release! Many thanks Abompard! (dedicated otp field, email or login works, and more) ### CentOS Infra including CentOS CI * Artifacts storage node replacement for CI (ready/deployed but to be announced in wider communication plan) https://pagure.io/centos-infra/issue/605 * CBS/koji proxy/settings tuning due to introduced change for gitlab (breaking some builds/tests) https://pagure.io/centos-infra/issue/782 * Roadmap for CentOS CI move to EC2 (working on communication plan) * Business as usual (mirrors proposals, tags) * Blocked: * Git.centos.org (waiting on EXD) * Stream storage migration (waiting on IT) ### Release Engineering * F34 is going EOL in one week * glibc update broke ostree updates in f36, more info https://pagure.io/releng/issue/10816 * Business as usual ## 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 --- * Initial push of c8s packages to gitlab. * New Content Resolver feature: it's now showing repo per package in views. * Fedora ELN: Repositories are now closer to CentOS Stream, the Everything repository has been replaced with Extras which contains the packages not explicitly included in the other Variants. ## 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 --- * Client CLI (almost there) * Migration Preparations ## Package Automation (Packit Service) Goal of this initiative --- Automate RPM packaging of infra apps/packages Updates --- * Business as usual * Continued work on noggin-messages and datanommer-models ## 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 in the base Enterprise Linux distributions. EPEL uses much of the same infrastructure as Fedora, including buildsystem, bugzilla instance, updates manager, mirror manager and more. Updates --- * This week we have 5863 (+99) packages, from 2672 (+6) source packages * amavis installation from epel9 problem resolved by backporting upstream patch to switch dependency from libidn to libidn2 * Backported java_arches macro from Fedora to epel9 * Working on a method for enabling CRB repository when epel-release is installed * Deployed fix for some CRB module packages not showing up in the epel8 buildroot, but it caused too many non-default module packages to be included so it had to be rolled back. * Retired lmdb-epel since lmdb-devel was added to RHEL8/RHEL9. Later discovered that some users still depend on the lmdb
Re: F37 proposal: RPM Macros for Build Flags (System-Wide Change proposal)
On Fri, Jun 3, 2022 at 11:25 AM Vít Ondruch wrote: > > BTW isn't the `_flag_` prefix too generic? And also, the initial > underscore implies that this is internal macro which should ideally not > be used. So should it be rather removed or not? I agree that the "_flag_" prefix might be a little too generic, but what would be a better alternative? Maybe something like _optflag_, to match what they are "collected into" (i.e. %optflags)? Also, macro names with single leading underscores are *fine* (see also %_bindir, %_libdir, %_datadir, etc.). Those with *double* leading underscores are the ones that should be considered "internal" implementation details. 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
Fedora-Cloud-34-20220603.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-20220602.0): ID: 1288571 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1288571 ID: 1288579 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1288579 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
Re: F37 proposal: RPM Macros for Build Flags (System-Wide Change proposal)
Hi Tom,
Since you are looking into this and I like this proposal, have you
considered to look alto into `%extension_*flags`:
https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/macros#_120-123
This is longstanding issue:
https://bugzilla.redhat.com/1284684
Where we have several proposals for fix, but non of them is really
appealing to me:
https://src.fedoraproject.org/rpms/ruby/pull-request/110
https://src.fedoraproject.org/rpms/ruby/pull-request/117
BTW isn't the `_flag_` prefix too generic? And also, the initial
underscore implies that this is internal macro which should ideally not
be used. So should it be rather removed or not?
Vít
Dne 02. 06. 22 v 21:27 Ben Cotton napsal(a):
https://fedoraproject.org/wiki/Changes/RPMMacrosForBuildFlags
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 ==
Create a corresponding macro for each compiler flag in the
redhat-rpm-config macro file and create "extra flag" macros to make it
easier for packages to add and remove compiler flags.
== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email:
== Detailed Description ==
The macros file in the redhat-rpm-config package contains a list of
default compiler flags for packages to use when compiling C, C++, and
Fortran packages. There is currently no standard way to remove or add
to the set of default flags. Most packages use a combination of echo
and sed to remove unwanted flags or add new ones. Some examples:
compiler-rt:
[https://src.fedoraproject.org/rpms/compiler-rt/blob/rawhide/f/compiler-rt.spec#_6
global optflags %(echo %{optflags} -D_DEFAULT_SOURCE)]
julia:
[https://src.fedoraproject.org/rpms/julia/blob/rawhide/f/julia.spec#_267
%global optflags %(echo %{optflags} | sed 's/-Wp,-D_GLIBCXX_ASSERTIONS
//')]
This change will add new macros which will make it easier for packages
to add and remove their own compiler flags. This strategy is already
used to some extent with feature macros like %{_lto_cflags},
%{_hardening_cflags}, etc, but these new macros will give packagers
even more fine-grained control over the options.
The proposed macros for adding new flags are:
%_pkg_extra_cflags
%_pkg_extra_cxxflags
%_pkg_extra_fflags
%_pkg_extra_ldflags
These will be added to %{build_cflags}, %{build_cxxflags},
%{build_fflags}, and %{build_ldflags} respectively to allow packges to
add their own flags to the default list: e.g.
%build_cflags %{optflags} %{_pkg_extra_cflags}
The proposed new macros to represent existing flags are:
%_flag_fstack_protector_strong -fstack-protector-strong
%_flag_z_now -Wl,-z,now
%_flag_z_defs -Wl,-z,defs
%_flag_flto_auto -flto=auto
%_flag_ffat_lto_objects-ffat-lto-objects
%_flag_o -O2
%_flag_f_exceptions-fexceptions
%_flag_g -g
%_flag_grecord_gcc_switches-grecord-gcc-switches
%_flag_pipe-pipe
%_flag_wall-Wall
%_flag_werror_format_security -Werror=format-security
%_flag_fortify_source -Wp,-D_FORTIFY_SOURCE=2
%_flag_glibcxx_assertions -Wp,-D_GLIBCXX_ASSERTIONS
%_flag_asynchronous_unwind_tables -fasynchronous-unwind-tables
%_flag_fstack_clash_protection -fstack-clash-protection
%_flag_fcf_protection -fcf-protection
%_flag_mbranch_protection_standard -mbranch-protection=standard
With these new macros, the examples from above could be re-written as:
compiler-rt: %global _pkg_extra_cflags -D_DEFAULT_SOURCE
julia: %global _flag_glibcxx_assertions %{nil}
For more details see the
[https://src.fedoraproject.org/fork/tstellar/rpms/redhat-rpm-config/c/0ee9a8c989b55c631f870ad311cdca87329034be?branch=macro-flags
Prototype Implementation].
In addition to adding these new macros, the packaging guidelines will
be updated to require that all new flags added to redhat-rpm-config
have their own RPM macro.
== Benefit to Fedora ==
* It will provide a standard way to disable existing compiler flags or
enable new ones that is more simple and robust than the existing echo
+ sed solution.
* It will make it easier to determine which packages disable or add
compiler flags by doing a simple grep of the spec files.
* It will make it easier for toolchain developers to experiment with
adding new flags to the distribution as this can be done with a simple
macro definition instead of patching redhat-rpm-config.
== Scope ==
* Proposal owners:
** Proposal owners will update the redhat-rpm-config package and add
the new macros.
** Proposal owners will test the changes to ensure that the
[Test-Announce] Kernel 5.18 Test Week 2022-06-05 through 2022-06-11
Hey All, I would like to invite all of you to participate in the Kernel 5.18 Test week is happening from 2022-06-05 to 2022-06-11. It's fairly simple, head over to the wiki [0] and read in detail about the test week and simply run the test case mentioned in[1] and enter your results. As usual, the Fedora QA team will hangout at #fedora-test-...@libera.chat for question and discussion. BTW, we have the fedora community survey happening[2] and the election happening too[3] Needless to say, you will get a badge for participating in all activities talked about in this email! [0] http://fedoraproject.org/wiki/Test_Day:2022-06-05_Kernel_5.18_Test_Week [1] https://testdays.fedoraproject.org/events/136 [2] https://discussion.fedoraproject.org/t/2022-fedora-community-survey/39569 [3] https://elections.fedoraproject.org/ -- //sumantro Fedora QE TRIED AND PERSONALLY TESTED, ERGO TRUSTED ___ 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
Fedora-Cloud-36-20220603.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-36-20220602.0): ID: 1288262 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1288262 ID: 1288270 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1288270 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
