Re: F46 Change Proposal: Thin LTO Build Flag (self-contained)

Apologies, this change is intended for F47. -- _______________________________________________ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave@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, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

F46 Change Proposal: Thin LTO Build Flag (self-contained)

Wiki - https://fedoraproject.org/wiki/Changes/Thin-LTO-Build-Flag This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == At present, many packages are built with fat link time optimization (LTO) objects. This can increase RAM requirements and build times. There is a build flag to disable LTO completely. But by using slim objects, one can still have the performance and size improvements offered by LTO with less of a build time cost. == Owner == * Name: [[User:fed500| Benson Muite]] * Email: <benson_muite at emailplus dot org> == Detailed Description == As indicated at https://stackoverflow.com/questions/13799452/what-is-the-difference-in-gcc-between-lto-and-fat-lto-objects a thin object allows for faster compilation times than a fat object and requires less memory. Adding this as a possible option would give an intermediate option between using fat objects and no link time optimization. This would enable more codes to benefit from easy incorporation of LTO without a substantial increase in compilation times. == Feedback == == Benefit to Fedora == Fedora would benefit from more efficient use of build resources while still getting optimized executables and libraries. There has been a related discussion on https://fedoraproject.org/wiki/Changes/LTOBuildImprovements == Scope == * Proposal owners: The proposal owner (Benson Muite) will create a macro that enables LTO with thin objects. In the gcc compiler suite, this will replace the build flag `-ffat-lto-objects` by `-fno-fat-lto-objects` At present `%global _lto_cflags %nil` is used to disable LTO (see https://fedoraproject.org/wiki/LTOByDefault). A possible modification is `%global _lto_cflags %slim`. * Other developers: Using this flag will be an option. Would suggest other developers try using LTO with slim objects first before disabling LTO completely. If it seems like it would be helpful to be adopted as default, this can be done in a further system wide change. * Release engineering: [https://forge.fedoraproject.org/releng/tickets/issues #Releng issue number] No expected changes. * Policies and guidelines: N/A (not needed for this Change) If the change is adopted and after it has been tested, we should consider updating the packaging guidelines that when importing a new C/C++ or Fortran package, packagers should test if using a slim LTO is sufficient instead of disabling LTO altogether. * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: General alignment with having an efficient operating system that uses sustainable development practices, but no specific community goal. == Upgrade/compatibility impact == No changes needed. == How To Test == The main thing to test will be modifying spec files for C, C++ or Fortran that use the GCC compiler suite to try using thin objects by setting a macro and then rebuilding When previously a fat object has been used, one should check if there are faster build times and reasonable performance of the resulting outputs. If LTO had been disable due to excessive build times or RAM use, one should test if builds are now possible and if the resulting outputs are more efficient. == User Experience == * Packages will spend less time waiting for builds to complete * Users should get a larger number of optimized packages provided == Dependencies == Only rpm macros package needs to be changed. == Contingency Plan == * Contingency mechanism: Implement by the next freeze * Contingency deadline: Ideally would implement by Fedora 45 release, but before fedora 46 is also fine. * Blocks release? No == Documentation == Packaging guidelines will be updated to document the new option. See: * https://stackoverflow.com/questions/13799452/what-is-the-difference-in-gcc-between-lto-and-fat-lto-objects * https://github.com/google/highway/pull/3024 * https://fedoraproject.org/wiki/Changes/LTOBuildImprovements N/A (not a System Wide Change) == Release Notes == Release notes should not require any changes. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- _______________________________________________ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave@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, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

F46 Change Proposal: Libical4 (system-wide)

Wiki - https://fedoraproject.org/wiki/Changes/Libical4 This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Update the `libical` library to its 4.x series. It's the next generation of the `libical` library, on which the upstream focuses the most right now. == Owner == * Name: [[User:mcrha| Milan Crha]] * Email: <mcrha at redhat dot com> == Detailed Description == The `libical` upstream begun to focus the main development on the new 4.x series, which is not API compatible with the 3.x series. These cannot be used by a single executable together, similar to `libsoup2` and `libsoup3`. Unlike `libsoup`, it does not verify in runtime whether the other library is also loaded, thus it it harder to spot the leftovers. Luckily, there are not that many direct dependencies which use either `libical` or `libical-glib`, thus I'd go even without a compact package and just flip the switch. == Feedback == I asked for an opinion [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/OAT6OWZ6OCN74HVAGHZB5SSHP6BMOU6E/ on the devel list] with almost no feedback. I built the dependencies [https://copr.fedorainfracloud.org/coprs/mcrha/libical-4.x/builds/ in COPR] checking which dependencies need a custom patch and which can be build with either `libical` 3.x or 4.x. I also proposed patches to some of the projects which needed them. == Benefit to Fedora == Stay on the latest `libical` upstream stable series. == Scope == * Proposal owners: Just adapting the `libical'` spec file, already prepared in the COPR * Other developers: Simply rebuild the package against the new `libical` for those whom are ready, or carry a custom patch to port to the new API changes. * Release engineering: [https://forge.fedoraproject.org/releng/tickets/issues/13504 #13504] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: == Upgrade/compatibility impact == C API/ABI: Applications not rebuilt will fail to run due to the soname change. == Early Testing (Optional) == Do you require 'QA Blueprint' support? N Propose pull request with the needed packaging changes is here: https://src.fedoraproject.org/rpms/libical/pull-request/2 COPR build with the main users rebuilt is here: https://copr.fedorainfracloud.org/coprs/mcrha/libical-4.x/ == How To Test == There should be no user visible changes, depending whether any of the library users provide different features for different versions on the `libical`. == User Experience == It depends on the applications using the library. == Dependencies == The users of the `libical` development packages: $ dnf repoquery --whatrequires "pkgconfig(libical)" \ --whatrequires "pkgconfig(libical-glib)" \ --whatrequires "libical-glib-devel" \ --whatrequires "libical-devel" \ --recursive --disablerepo=* --enablerepo=rawhide --srpm akonadi-calendar akonadi-search calendarsupport eventviews evolution evolution-data-server folks incidenceeditor kcalutils kf6-kcalendarcore kitinerary ktnef libkgapi (excluding `libical` itself and `kf5` packages, which are orphaned at the moment). Packages requiring `libical`: $ dnf repoquery --whatrequires "libical" --recursive --srpm --disablerepo=* --enablerepo=rawhide GoldenCheetah akonadi-calendar akonadi-calendar-tools akonadi-import-wizard akonadi-search akonadiconsole akregator almanah asterisk baresip bijiben blivet-gui blogilo bluedevil blueman bluez bubblemail cairo-dock cairo-dock-plug-ins calendarsupport calindori calligraplan calls chatty cinnamon claws-mail cyrus-imapd digikam digikam-gmic-qt eventviews evolution evolution-data-server evolution-ews evolution-rspam folks g3kb-switch gdm geary glabels gnokii gnome-applets gnome-bluetooth gnome-browser-connector gnome-calendar gnome-contacts gnome-flashback gnome-initial-setup gnome-panel gnome-phone-manager gnome-pomodoro gnome-session gnome-shell gnome-shell-extension-appindicator gnome-shell-extension-background-logo gnome-shell-extension-blur-my-shell gnome-shell-extension-bubblemail gnome-shell-extension-dash-to-dock gnome-shell-extension-dash-to-panel gnome-shell-extension-disconnect-wifi gnome-shell-extension-forge gnome-shell-extension-freon gnome-shell-extension-gamemode gnome-shell-extension-gamerzilla gnome-shell-extension-gsconnect gnome-shell-extension-ibus-font gnome-shell-extension-just-perfection gnome-shell-extension-kimpanel gnome-shell-extension-logo-menu gnome-shell-extension-netspeed gnome-shell-extension-pidgin gnome-shell-extension-pipewire-settings gnome-shell-extension-pop-shell gnome-shell-extension-refresh-wifi gnome-shell-extension-suspend-button gnome-shell-extension-system-monitor-applet gnome-shell-extension-unite gnome-shell-extension-vertical-workspaces gnome-shell-extensions gnome-shell-frippery gnome-todo gparted gpaste grantlee-editor incidenceeditor itinerary kaddressbook kalarm kcalutils kdepim kdepim-addons kdepim-runtime kdepimlibs kf6-kcalendarcore kio-gdrive kitinerary kleopatra kmail kmail-account-wizard kmailtransport kmymoney kongress kontact korganizer ktnef kuser libkgapi libksieve mailcommon mailimporter maui-agenda maui-mauikit-calendar mbox-importer merkuro messagelib mimetreeparser noctalia orage osmo phosh phosh-mobile-settings phrog pidgin-chime pim-data-exporter pim-sieve-editor pimcommon recoll redwax-tool syncevolution vakzination workrave xpra yaru-theme zanshin == Contingency Plan == * Contingency mechanism: ** ABI Breakage: If the mass rebuild is unsuccessful or reveals widespread, unresolvable issues, revert to the 3.x series. * Contingency deadline: Beta freeze * Blocks release? Yes == Documentation == Upstream has a migration guide at https://github.com/libical/libical/blob/4.0/docs/MigrationGuide_to_4.md == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- _______________________________________________ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave@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, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

F46 Change Proposal Crystal Language (system-wide)

Wiki - https://fedoraproject.org/wiki/Changes/CrystalLanguage his is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == This proposal introduces official native support for the [[crystal|Crystal programming language]] compiler ({{package|crystal}}), its dependency manager ({{package|shards}}), an automated spec generator ({{package|cr2rpm}}), and standard RPM packaging macros ({{package|crystal-rpm-macros}}) into Fedora Linux. Shard libraries will be packaged following the '''Shard-as-RPM''' model, enabling offline, secure, and reproducible compilation across the distribution. == Owner == * Name: [[User:Renich|Rénich Bon Ćirić]] * Email: renich@woralelandia.com == Detailed Description == Crystal ([https://crystal-lang.org]) is a statically typed compiled language designed for developer productivity and systems-level execution performance. The Fedora implementation uses the '''Shard-as-RPM''' model: * Each shard library is packaged as an independent RPM package installing source trees to <code>%{_datadir}/crystal/shards/<name>-<version></code> (with compatibility links for default releases). * Parallel coexistence of multiple shard versions is supported without filesystem collisions, enabling applications to build against specific SemVer versions. * Network access during package builds is prohibited; dependencies are provided locally by installed RPMs. * The compiler discovers installed shard libraries offline via <code>CRYSTAL_PATH="lib:%{crystal_shards_dir}:%{_datadir}/crystal/src"</code>. * Spec generation, license mapping (SPDX), and topological mock build ordering are automated via {{package|cr2rpm}}. * Compiler bootstrapping complies with Fedora's [[Packaging:Guidelines#No_pre-compiled_binaries|No Pre-compiled Binaries Policy]] via a standard transient Koji side-tag bootstrap. == Feedback == Community feedback and architectural planning have been discussed on Fedora Discussion at [https://discussion.fedoraproject.org/t/bringing-crystal-to-fedora-linux/182632 Bringing Crystal to Fedora Linux]. == Benefit to Fedora == * '''Air-Gapped & High-Security Deployments''': Enables building and deploying Crystal software in isolated or air-gapped environments without external internet access or dynamic Git downloads. * '''Supply Chain Integrity''': Protects against upstream Git repository tampering, branch deletion, and dependency confusion by anchoring all dependencies to cryptographic RPM package checksums. * '''Centralized Security Auditing & Patching''': System administrators and security scanners (OpenSCAP, DNF, RPM) can track, audit, and patch Crystal libraries system-wide without inspecting ad-hoc vendor directories. * '''Hermetic & Reproducible Builds''': Conforms strictly with Fedora release engineering standards, ensuring deterministic builds in Koji and Mock. * '''Modern Systems Language''': Provides a high-performance compiled language with native LLVM optimization, green threads concurrency, and seamless C ABI interoperability. == Scope == * Proposal owners: ** Package and maintain {{package|crystal}}, {{package|shards}}, {{package|crystal-rpm-macros}}, and {{package|cr2rpm}}. ** Execute the initial bootstrap build in Koji using a staging side-tag. ** Publish official Crystal packaging guidelines. ** Maintain core ecosystem packages ({{package|ameba}}, {{package|flaw}}, {{package|kemal}}). * Other developers: No direct impact on existing packages. Developers can begin packaging Crystal applications and shard libraries. * Release engineering: Coordinate initial bootstrap build and provide a staging side-tag if required ([https://forge.fedoraproject.org/releng/tickets/issues/13511 RelEng Ticket #13511]). * Policies and guidelines: Fedora Packaging Guidelines updated with dedicated Crystal section ([https://discussion.fedoraproject.org/t/draft-guidelines-crystal-packaging-guidelines-changes-crystallanguage/200733 FPC Draft Discussion #200733]). * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: Expands Fedora's ecosystem of modern, memory-efficient compiled systems languages. == Upgrade/compatibility impact == No impact on existing packages or system upgrades. This change introduces new packages and does not modify existing system defaults or libraries. == How To Test == === Hardware / Environment Requirements === Standard x86_64 or aarch64 Fedora Linux system (or Mock chroot). === System Preparation === sudo dnf install crystal shards cr2rpm crystal-rpm-macros === Verification Steps === Generate a spec file from a shard repository: cr2rpm generate --path ./my-shard Analyze dependency tree and build order: cr2rpm deps --path ./my-shard --format mock Build and verify an application binary: crystal build --release -o hello src/hello.cr ./hello Run package tests in an isolated mock chroot: mock -r fedora-rawhide-x86_64 rebuild my-package.src.rpm == User Experience == Fedora users and developers can install the Crystal compiler and shards package manager directly via standard package management: sudo dnf install crystal shards Crystal binaries compile with full Fedora hardening flags (PIE, Full RELRO, Stack Protection) and integrate with GDB and LLDB out of the box. == Dependencies == * Compiler runtime: {{package|llvm-devel}}, {{package|gc-devel}}, {{package|pcre2-devel}}, {{package|libffi-devel}}. * Standard library: {{package|openssl-devel}}, {{package|zlib-devel}}, {{package|gmp-devel}}, {{package|libyaml-devel}}, {{package|libxml2-devel}}. * Opt-in/legacy event loop: {{package|libevent-devel}}. == Contingency Plan == * Contingency mechanism: Retarget for Fedora N+1. Crystal packages remain available via Copr and staging repos. * Contingency deadline: Beta freeze. * Blocks release? No. == Documentation == * Implementation Plan: [https://codeberg.org/renich/crystal-in-fedora/src/branch/master/plan.rst plan.rst] * Packaging Guidelines: [https://codeberg.org/renich/crystal-in-fedora/src/branch/master/guidelines/packaging-crystal.rst packaging-crystal.rst] * Crystal Official Site: [https://crystal-lang.org/ crystal-lang.org] * Upstream Language Repository: [https://github.com/crystal-lang/crystal github.com/crystal-lang/crystal] * Fedora Tooling & Planning Repository: [https://codeberg.org/renich/crystal-in-fedora codeberg.org/renich/crystal-in-fedora] == Release Notes == Fedora now includes official support for the Crystal programming language, including the compiler ({{package|crystal}}), dependency manager ({{package|shards}}), and full RPM packaging macros ({{package|crystal-rpm-macros}}). Developers can build native, high-performance Crystal applications and package shards offline using standard Fedora tooling. Proposal owners: Package and -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- _______________________________________________ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave@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, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

[lfs-announce] LFS 13.1 is released

The Linux From Scratch community is pleased to announce the release of LFS Version 13.1. This release is a major update to LFS. Major changes include toolchain updates to binutils-2.47, gcc-16.2.0, and glibc-2.44. In total, 46 packages were updated or added since the last release. Changes to the text have also been made throughout the book. The Linux kernel has also been updated to version 7.1.8. Overall there have been over 200 commits to LFS since the previous stable version of the book. Packages that have security updates include: glibc, coreutils, expat, Perl, Python, systemd, xz, and vim. See https://www.linuxfromscratch.org/advisories for LFS and BLFS packages that were affected by security updates since the last stable release. Please see the ChangeLog in the book for a full list of changes. Thanks for this release goes to many contributors. Notably: Douglas Reno Xi Ruoyao Joe Locash ---- Note: We would prefer to release BLFS at the same time as LFS, but that book will be delayed. We hope to release that book very soon, but in the meantime the BLFS development book is very close to the final BLFS Version 13.1. Out of over 1000 packages in that book over 99% have been built and tested with the LFS-13.1 base. ---- You can read the book online[0], or download[1] to read locally. Please direct any comments about this release to the LFS development team at lfs-dev@lists.linuxfromscratch.org. Registration for the mailing lists is required to avoid junk email. -- Bruce Dubbs LFS [0] http://www.linuxfromscratch.org/lfs/view/13.1-systemd/ [1] http://www.linuxfromscratch.org/lfs/downloads/13.1-systemd/

-- http://lists.linuxfromscratch.org/sympa/info/lfs-announce Unsubscribe: See the above information page

[announce] Next NYC*BUG: Sept 2nd, BrassMonkey

NYCBug Sept 2nd "Conference Coms Check". By Patrick McEvoy

2026-09-02 @ 18:45 local (22:45 UTC) - Backroom of Brass Monkey 55 Little West 12th St

During this informal meeting we will be testing the streaming / IRC bot forwarding  /   Peertube / discord  system we have been using for conferences with an eye towards making EuroBSDcon and future *BSD related conferences run as smoothly as possible while bringing offsite members of the community into the conversation. Bring your favorite IRC and Discord clients to the table as we test streaming system resilience and interaction from the BrassMonkey in downtown Manhattan. 

For more information, please visit:

https://www.nycbug.org/

_______________________________________________ announce mailing list announce@lists.nycbug.org https://lists.nycbug.org:8443/mailman/listinfo/announce

Debian 11 Long Term Support reaches end-of-life

------------------------------------------------------------------------ The Debian Project https://www.debian.org/ Debian 11 Long Term Support reaches end-of-life press@debian.org August 31st, 2026 https://www.debian.org/News/2026/20260831 ------------------------------------------------------------------------ The Debian Long Term Support (LTS) Team hereby announces that Debian 11 "bullseye" support has reached its end-of-life today, 31 August 2026, five years after its initial release on 14 August 2021. Starting in September, Debian will not provide further security updates for Debian 11. A subset of "bullseye" packages will be supported by external parties. Detailed information can be found at Extended LTS [1]. 1: https://wiki.debian.org/LTS/Extended The Debian LTS Team is currently providing security support for Debian 12 "bookworm", the current oldstable release. Thanks to the combined efforts of different teams including the Security Team, the Release Team, and the LTS Team, the Debian 12 life cycle encompasses five years. Debian 12 will receive Long Term Support until 30 June 2028. The supported architectures in Debian 12 LTS are amd64, i386, arm64, armhf and ppc64el. For further information about using "bookworm" LTS and upgrading from "bullseye" LTS, please refer to LTS/Using [2]. 2: https://wiki.debian.org/LTS/Using Debian and its LTS Team would like to thank all contributing users, developers, sponsors and other Debian teams who are making it possible to extend the life of previous stable releases, and who have made Bullseye LTS a success. If you rely on Debian LTS, please consider joining the team [3], providing patches, testing or funding the efforts [4]. 3: https://wiki.debian.org/LTS/Development 4: https://wiki.debian.org/LTS/Funding About Debian ------------ The Debian Project was founded in 1993 by Ian Murdock to be a truly free community project. Since then the project has grown to be one of the largest and most influential open source projects. Thousands of volunteers from all over the world work together to create and maintain Debian software. Available in 70 languages, and supporting a huge range of computer types, Debian calls itself the "universal operating system". Contact Information ------------------- For further information, please visit the Debian web pages at https://www.debian.org/ or send mail to <press@debian.org>.

Ubuntu 26.04.1 LTS released

Ubuntu 26.04.1 LTS, codenamed “Resolute Raccoon”, is here. This release continues Ubuntu's proud tradition of integrating the latest and greatest open source technologies into a high-quality, easy-to-use Linux distribution. The team has been hard at work through this cycle, together with the community and our partners, to introduce new features and fix bugs. As usual, this point release includes many updates and updated installation media has been provided, so that fewer updates will need to be downloaded after installation. These include security updates and corrections for other high-severity bugs, with a focus on maintaining stability and compatibility with Ubuntu 26.04 LTS. Kubuntu 26.04.1 LTS, Ubuntu Budgie 26.04.1 LTS, Lubuntu 26.04.1 LTS, Ubuntu Kylin 26.04.1 LTS, Ubuntu Studio 26.04.1 LTS, Xubuntu 26.04.1 LTS, Edubuntu 26.04.1 LTS, and Ubuntu Cinnamon 26.04.1 LTS are also now available. For more details on these, read their individual release notes under the Official flavors section: https://documentation.ubuntu.com/release-notes/26.04/#official-flavors Maintenance updates will be provided for 5 years from the initial 26.04 LTS release for Ubuntu Desktop, Ubuntu Server, Ubuntu Cloud, and Ubuntu Core. All the remaining flavors will be supported for 3 years. Additional security support is available with ESM (Expanded Security Maintenance). To get Ubuntu 26.04.1 LTS ------------------- To download Ubuntu 26.04.1 LTS, visit: https://ubuntu.com/download Users of Ubuntu 24.04 LTS will be offered an automatic upgrade to 26.04.1 LTS via Update Manager a couple of weeks following this release after some planned backports to address regressions in a recent version of rust-coreutils. In the meantime, those eager to make the jump can do so at any time by running: $ do-release-upgrade -d As always, upgrades to the latest version of Ubuntu are entirely free of charge. We recommend that all users read the release notes, which document caveats, workarounds for known issues, as well as more in-depth information on the release itself. They are available at: https://documentation.ubuntu.com/release-notes/26.04/ If you have a question, or if you think you may have found a bug but aren't sure, ask in any of the following places: https://matrix.to/#/#support:ubuntu.com https://discourse.ubuntu.com/support https://lists.ubuntu.com/mailman/listinfo/ubuntu-users Help shape Ubuntu ----------------- If you would like to help shape Ubuntu, look at the list of ways you can participate at: https://documentation.ubuntu.com/project/community/contribute/ About Ubuntu ------------ Ubuntu is a full-featured Linux distribution for desktops, laptops, IoT, cloud, and servers, with a fast and easy installation and regular releases. A tightly-integrated selection of excellent applications is included, and an incredible variety of add-on software is just a few clicks away. Professional services including support are available from Canonical and hundreds of other companies around the world. For more information about support, visit: https://ubuntu.com/support More information ---------------- Learn more about Ubuntu and about this release on our website: https://ubuntu.com To sign up for future Ubuntu announcements, subscribe to Ubuntu's very low-volume announcement list at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-announce On behalf of the Ubuntu Release Team, Oliver Reiche -- ubuntu-announce mailing list ubuntu-announce@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-announce

[announce] NYCBug Sept 2nd "Conference Coms Check". By Patrick McEvoy

NYCBug Sept 2nd "Conference Coms Check". By Patrick McEvoy

2026-09-02 @ 18:45 local (22:45 UTC) - Backroom of Brass Monkey 55 Little West 12th St

During this informal meeting we will be testing the streaming / IRC bot forwarding  /   Peertube / discord  system we have been using for conferences with an eye towards making EuroBSDcon and future *BSD related conferences run as smoothly as possible while bringing offsite members of the community into the conversation. Bring your favorite IRC and Discord clients to the table as we test streaming system resilience and interaction from the BrassMonkey in downtown Manhattan. 

For more information, please visit:

https://www.nycbug.org/

_______________________________________________ announce mailing list announce@lists.nycbug.org https://lists.nycbug.org:8443/mailman/listinfo/announce

Bouncing messages from freebsd-announce@FreeBSD.org

Hi, this is the Mlmmj program managing the <freebsd-announce@FreeBSD.org> mailing list. Some messages to you could not be delivered. If you're seeing this message it means things are back to normal, and it's merely for your information. Here is the list of the bounced messages: - 311, Message-ID: <20260825193315.644B33B19@freefall.freebsd.org>

FreeBSD Security Advisory FreeBSD-SA-26:59.mac_do

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-26:59.mac_do Security Advisory The FreeBSD Project Topic: Unauthorized credential switching Category: core Module: mac_do Announced: 2026-08-25 Credits: Hazley Samsudin of GovTech CSG Affects: FreeBSD 15.0 and later Corrected: 2026-08-25 15:59:49 UTC (stable/15, 15.1-STABLE) 2026-08-25 16:01:24 UTC (releng/15.1, 15.1-RELEASE-p3) 2026-08-25 16:01:03 UTC (releng/15.0, 15.0-RELEASE-p13) CVE Name: CVE-2026-58092 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit <URL:https://security.FreeBSD.org/>. I. Background mac_do(4) is a MAC policy module that allows unprivileged processes to switch credentials using setcred(2), subject to administrator-defined rules. Rules can restrict transitions based on the calling process' user and group identities. II. Problem Description In FreeBSD 15.0, the kernel structure used to represent user credentials changed: previously the primary group ID was stored in the first element of the array containing the list of supplementary group IDs, whereas now the primary group ID is stored in a dedicated field. This change was largely internal to the kernel and not user-visible. One function, group_is_primary(), was not properly updated as a part of this transition. This function is used by mac_do to determine the primary group ID of the credential after applying a transition rule, used when the rule target does not explicitly specify a group. As a result, with certain mac_do rules, it is possible for a credential switch to incorrectly set the primary group ID to the ID stored in the first element of the original credential's supplementary group array. If the list of supplementary groups is empty, this value will be 0, corresponding to the "wheel" group. For example, a rule such as "uid=1001>uid=1002" can be abused to set the primary group ID to 0 even if the process did not originally belong to group 0. III. Impact Certain mac_do rules can be abused to set a process' group ID to 0. Note however, that the rule must apply to the caller in order for the bug to be triggered, e.g., given the ruleset "uid=1001>uid=1002", the user must have user ID 1001 in order to trigger the bug. Further, logged-in users will in general have a non-empty supplementary group list, in which case the bug can at worst be used to set the credential's first supplementary group ID as its primary group ID. Processes must explicitly remove themselves from all supplementary groups, using the privileged setgroups(2) system call, in order to exploit the bug to set 0 as the primary group ID. Since membership in group 0 is often used to enable controlled privilege escalation, the bug might be further exploitable to obtain root privileges, depending on the system configuration. For instance, a ruleset such as the following could be exploited by a process running as user 1001 and with an empty supplementary group list: "uid=1001>uid=1002;gid=0>uid=0". IV. Workaround Systems that do not configure a mac_do ruleset are not affected. Rulesets which explicitly specify a target group ID are not subject to the bug. V. Solution Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date, and reboot the system. Perform one of the following: 1) To update your vulnerable system installed from base system packages: Systems running a 15.0-RELEASE or later version of FreeBSD on the amd64 or arm64 platforms, which were installed using base system packages, can be updated via the pkg(8) utility: # pkg upgrade -r FreeBSD-base # shutdown -r +10min "Rebooting for a security update" 2) To update your vulnerable system installed from binary distribution sets: Systems running a RELEASE version of FreeBSD on the amd64 or arm64 platforms which were not installed using base system packages can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install # shutdown -r +10min "Rebooting for a security update" 3) To update your vulnerable system via a source code patch: The following patches have been verified to apply to the applicable FreeBSD release branches. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch https://security.FreeBSD.org/patches/SA-26:59/mac_do.patch # fetch https://security.FreeBSD.org/patches/SA-26:59/mac_do.patch.asc # gpg --verify mac_do.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch -E -p0 < /path/to/patch c) Recompile your kernel as described in <URL:https://www.FreeBSD.org/handbook/kernelconfig.html> and reboot the system. VI. Correction details This issue is corrected as of the corresponding Git commit hash in the following stable and release branches: Branch/path Hash Revision - ------------------------------------------------------------------------- stable/15/ ae27dff4710b stable/15-n285145 releng/15.1/ 97b7439e3b06 releng/15.1-n283604 releng/15.0/ 00036dad647f releng/15.0-n281107 - ------------------------------------------------------------------------- Run the following command to see which files were modified by a particular commit: # git show --stat <commit hash> Or visit the following URL, replacing NNNNNN with the hash: <URL:https://cgit.freebsd.org/src/commit/?id=NNNNNN> To determine the commit count in a working tree (for comparison against nNNNNNN in the table above), run: # git rev-list --count --first-parent HEAD VII. References <URL:https://www.cve.org/CVERecord?id=CVE-2026-58092> The latest revision of this advisory is available at <URL:https://security.FreeBSD.org/advisories/FreeBSD-SA-26:59.mac_do.asc> -----BEGIN PGP SIGNATURE----- iQJPBAEBCgA5FiEEthUnfoEIffdcgYM7bljekB8AGu8FAmqN3YIbFIAAAAAABAAO bWFudTIsMi41KzEuMTIsMCwzAAoJEG5Y3pAfABrvS4IP/3NC1xmoJ/sd/RZLqW1f oLSf3q4coxvjbzjBsZc4um+nkiwEWdjX9ZXzZ+KR0XVV6VgXkhhEPqARmcc4OPTo nduczWRyqNzRTGzzWi0QpmY+K764ZA2rObChnc8Bs/s75dl9AXinjF9G0hMM29i7 dfcsh8vPLFPkdtXtiReGFrf7c6CryOqEZfAW71FQCv6q1/0YEiogWfeb+mvvfhOq qj2xxSAbNeIwXqOtTQ2IiZMEfFAR+0TZ506iWesxoEI9JoHBSoSkb0ZZLCUybr26 iCIhA0yA9sxnFVYvsbbLsatNTxyP9cR5gryJDYQCzwwm9TmdWp74PzGKvtdYN5TC rQi+6Ounfbt1ez6IYr6r54HCgAb7jNljiTEi0P8xJSvFuJcSvGJptzl6gZP2kIUS GH0PFIau2uXD0Lbh+aqkMAJKRnOzGx1ixCalhpFvg0b8CGEbCjiTooQaW641quWu ClquL69lzQljKikV8Qq0DobxBJRbGLREfIa8xCW4/Hf74ni7YrMQZBbzua3y4L2s lJaZumo2Capf7OT0A/ux5TAvmsY9X7pNg7K3GJ3apWgxRZu2bBeTm3j2+1skIhoN Fx7VgqyLboTxLkCUYohaLtcSav6ZKmhH8pUBkK/WutiZR8NLjfMoB8x+ZinL05Ym 0C2jYUClN06hrVUeSTwgh8Eu =Uvrm -----END PGP SIGNATURE-----

FreeBSD Security Advisory FreeBSD-SA-26:57.unix

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-26:57.unix Security Advisory The FreeBSD Project Topic: Use-after-free in unix SOCK_STREAM message handling Category: core Module: unix Announced: 2026-08-25 Credits: Mark Johnston Affects: FreeBSD 15.0 and later Corrected: 2026-08-24 16:29:47 UTC (stable/15, 15.1-STABLE) 2026-08-25 16:01:22 UTC (releng/15.1, 15.1-RELEASE-p3) 2026-08-25 16:01:01 UTC (releng/15.0, 15.0-RELEASE-p13) CVE Name: CVE-2026-58090 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit <URL:https://security.FreeBSD.org/>. I. Background Unix domain sockets provide a mechanism for processes on the same host to communicate. Processes can use unix domain sockets to exchange file descriptors, using the SCM_RIGHTS control message type. II. Problem Description The SOCK_STREAM receive path in the unix socket implementation failed to fully detach control messages from the socket buffer before processing them. Some error paths would free those messages, leaving freed data mbufs in the receive socket buffer. III. Impact An unprivileged local user can exploit this use-after-free to escalate privileges. IV. Workaround No workaround is available. V. Solution Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date, and reboot the system. Perform one of the following: 1) To update your vulnerable system installed from base system packages: Systems running a 15.0-RELEASE or later version of FreeBSD on the amd64 or arm64 platforms, which were installed using base system packages, can be updated via the pkg(8) utility: # pkg upgrade -r FreeBSD-base # shutdown -r +10min "Rebooting for a security update" 2) To update your vulnerable system installed from binary distribution sets: Systems running a RELEASE version of FreeBSD on the amd64 or arm64 platforms which were not installed using base system packages can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install # shutdown -r +10min "Rebooting for a security update" 3) To update your vulnerable system via a source code patch: The following patches have been verified to apply to the applicable FreeBSD release branches. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch https://security.FreeBSD.org/patches/SA-26:57/unix.patch # fetch https://security.FreeBSD.org/patches/SA-26:57/unix.patch.asc # gpg --verify unix.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch -E -p0 < /path/to/patch c) Recompile your kernel as described in <URL:https://www.FreeBSD.org/handbook/kernelconfig.html> and reboot the system. VI. Correction details This issue is corrected as of the corresponding Git commit hash in the following stable and release branches: Branch/path Hash Revision - ------------------------------------------------------------------------- stable/15/ 06833c3e9813 stable/15-n285079 releng/15.1/ 0e4c26a82cb1 releng/15.1-n283602 releng/15.0/ 21de91422ca2 releng/15.0-n281105 - ------------------------------------------------------------------------- Run the following command to see which files were modified by a particular commit: # git show --stat <commit hash> Or visit the following URL, replacing NNNNNN with the hash: <URL:https://cgit.freebsd.org/src/commit/?id=NNNNNN> To determine the commit count in a working tree (for comparison against nNNNNNN in the table above), run: # git rev-list --count --first-parent HEAD VII. References <URL:https://www.cve.org/CVERecord?id=CVE-2026-58090> The latest revision of this advisory is available at <URL:https://security.FreeBSD.org/advisories/FreeBSD-SA-26:57.unix.asc> -----BEGIN PGP SIGNATURE----- iQJPBAEBCgA5FiEEthUnfoEIffdcgYM7bljekB8AGu8FAmqN3X0bFIAAAAAABAAO bWFudTIsMi41KzEuMTIsMCwzAAoJEG5Y3pAfABrvlAsP/1eqhZQS/YtepDbHml3h Cjuzc3eHFelAfDhMDaAn1/KJv6fUNHaJ3NQipdKL9hU78tXKIG287Ld3BpExBvp/ 7ODQiYENW94Nx07sm0HL9Qa0lznAQtUsniZ2mlua9+t00eYnEHd8qJkeL369IGhI qfpeIjbELLS6kkC8r6LVEI0ncDmeieXBcL20amwSASzWarw6HpWucF6zot/FOfUE S6hn8fLO+IQj+min9DzMGjNDq3r/dqDKXMXv68+En+5dhmO4HMOSibfTa1YdKfW4 SJziul0mOfaMWMCssd3b2HN5SHe9vx4vtf7TpBWfAvREbF3F95eelTzKrEkS+8Vx CvK6ApUukBG/866bATVri2bXnnnVuERXxi/1vMevd7dDcCZWrg/FKquoqzl/n1AD MM0U5PCn3PdCFJDNlNf8+ShYv9uFA6w7S2CJAkGW2oNdR9WKZcOHu4bwvxBod2hj xhk7xZ+hzv5Fb7ulf2bsi87BhDWrkOvRmCHh5oRKbGX/FrvUx3V1OCuFbnORxCJT g2MQOl7jBhhf0Gagy1bOIrqw/JH3m1Y2Lk6FgJLfNF6R1YJbWZg5oV3WIraUBr25 EruKOmOw4CTwL0hpUX2+wO1+/QaoW1JDb3GC7wSADRNNMCnTCtFJvNS+f+jcOchL usbogTLMhfpofgBignADKZsd =7aT1 -----END PGP SIGNATURE-----