Re: [gentoo-dev] New tool for updating Bug summaries after package moves: bugsed
On 12/11/24 15:08, Michał Górny wrote: you can quickly update hundreds of bugs filed against it Does it need to be added to the list of exceptions [1] or is it considered as a manual, i.e. non-automated, script? Cheers, APN [1] https://bugs.gentoo.org/bots.html
Re: [gentoo-dev] New tool for updating Bug summaries after package moves: bugsed
On Thu, 2024-12-12 at 04:55 +, Sam James wrote: > Could you run it over historical updates (at least from the last year)? > I can do it if you give me whatever recipe you used as well (or if not, > can get to it later again when bored). It's literally: ./bugsed old/pkg new/pkg old/pkg2 new/pkg2... Check the output, then the same with `-u`. I've listed all replacement pairs for LLVM packages there, to avoid multiple updates on bugs listing multiple LLVM packages. For other moves, where it is unlikely for different packages to be listed together, this shouldn't be necessary. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New tool for updating Bug summaries after package moves: bugsed
On Thu, 2024-12-12 at 10:28 +0100, Alexander Neuwirth wrote: > On 12/11/24 15:08, Michał Górny wrote: > > you can quickly update > > hundreds of bugs filed against it > > Does it need to be added to the list of exceptions [1] or is it > considered as a manual, i.e. non-automated, script? Well, I don't think it should really be considered a "bot", since it's just a frontend script that does operations on your request. It's not that different from "change multiple bugs" function in Bugzilla. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] New global USE flag: io-uring
On 08/11/2024 18.20, Filip Kobierski wrote: Hello everyone, lately I have been looking into the io_uring functionality in the kernel and apps that I use -- what could be a non-generic USE flag shared by mpd and qemu? I have noticed that currently 9 packages[1] have an io-uring USE flag. All of them use it for enabling the use of io_uring system calls. The feature was introduced in 5.1 and the oldest we ship is 5.10 so I think there will be no compatibility issues. Introducing a new io-uring global USE flag would encourage users to enable it globally and simplify the configuration. The USE description that I propose is "Enable the use of io_uring system calls for efficient async IO". Of course if there is something more fitting it should be chosen, I have no hard opinions here. What do you think about it? I also think io-uring is a good candidate for a global use flag. Given that there where no objections, please feel encouraged to propose a tree-wide patch. - Flow OpenPGP_0x8CAC2A9678548E35.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Request For Insights On Kernel Security Hardening Practices In Gentoo
Dear All, We are academic researchers from Huazhong University of Science and Technology, China. To foster a healthier Linux kernel community and enhance the overall security of Linux distributions, we are conducting a study on kernel security hardening deployments across various Linux distributions. In our research, we analyzed kernel config files and the /proc filesystem by installing and running multiple distribution ISO images. This allowed us to enumerate the default deployment of kernel defense mechanisms at runtime. So far, we have cataloged over 50 kernel security hardening features and documented inconsistencies in their deployment across different distributions. The results of our analysis are accessible via the following link: https://docs.google.com/spreadsheets/d/17QRr04pqK1K4-VoHXW2-9KgPd4uV8Q4I-NNkV9CN8nM/edit?usp=sharing. Given Gentoo's reputation for exceptional performance and rich features, we conducted a detailed investigation into its kernel security hardening strategies. To further deepen our understanding, we would greatly appreciate your input on the following questions: 1. Effectiveness of Kernel Security Hardening 1.1 Do you consider deploying kernel security hardening features to be an effective strategy for ensuring operating system security? 2. Configuration Strategy for Default Kernel Security Hardening Options 2.1 What are the primary criteria for selecting kernel security hardening options in your distribution? 2.2 How are configurable security hardening features (e.g., unprivileged_bpf_disabled) typically set (e.g., 0, 1, or 2), and what are the main considerations involved? 2.3 How do you balance the trade-off between side-effects (e.g., performance overhead) and the enhanced security introduced by kernel security hardening? 2.4 Does the tolerance for performance overhead vary across different application scenarios? 2.5 Are there other negative factors, such as compatibility issues, that are considered when enabling security hardening features? 3. Customized Configurations 3.1 Do you provide different kernel security hardening configurations tailored to specific user groups? 4. Best Practices and Recommendations 4.1 Are there any best practices or recommendations you can share regarding kernel security hardening? 4.2 Are there relevant documents or materials available for reference? The purpose of these questions is to gain a deeper understanding of your security protection strategies. Your insights would be immensely valuable to our study. Thank you for taking the time to review our questions. We look forward to your response. Best regards, Yinhao Hu, PhD candidate huyinha...@gmail.com Huazhong University of Science and Technology
Re: [gentoo-dev] [RFC] Unmessing mod/tracker music file flags (mikmod, modplug, openmpt)
On Wed, 2024-12-11 at 11:20 +0100, Michał Górny wrote: > Hello, > > Right now we have three flags that do pretty much the same thing, via > different libraries: > > global[mikmod] Add libmikmod support to allow playing of SoundTracker-style > music files > > global[modplug] Add libmodplug support for playing SoundTracker-style music > files > media-sound/mixxx[modplug] Add libmodplug support > > media-libs/sdl_audiolib[openmpt] OpenMPT decoder via media-libs/libopenmpt > media-plugins/audacious-plugins[openmpt] Add support for OpenMPT > media-sound/mpd[openmpt] OpenMPT decoder plugin > media-sound/fooyin[openmpt] Build the OpenMPT input plugin using > media-libs/libopenmpt > media-sound/musikcube[libopenmpt] Build plugin to support playing MOD music > aka tracker music through libopenmpt > > Given that they are roughly used in the same way, and only a small > subset of packages (e.g. mpv) support more than one library, how about > settling on a single feature flag instead? While they probably differ > in fine details like the exact list of supported file formats, > the overlap is wide enough to justify it. > > Such as: > > mod - Enable support for a variety of tracker module (.it, .mod, .s3m, .xm, > and more) music files As the maintainer for OpenMPT, that works for me. signature.asc Description: This is a digitally signed message part
