December 2024 - Arch-general - lists.archlinux.org

Postgresql 17
by IS 18 Apr '25

18 Apr '25

Does anyone know why Postgresql 17 is not yet available on Archlinux? Thanks

6 7

Hello
by Mats Svensson 28 Dec '24

28 Dec '24

Hello everyone! Thanks for letting me in here

1 0

Formal Request to review moderation decision [Fwd: What is the policy/thoughts on embedding icons/emojis/unicode glyphs in package descriptions in PKGbUILD]
by David C. Rankin 22 Dec '24

22 Dec '24

Dear Archlinux Governing Board, I formally request a review of how and why I am moderated on AUR. I have been given no explanation, and my posts (including the one below) simply do no make it to the list and I receive no determination on them. After being a member for more than 15 years, I feel this action was unprofessional, uncalled for and completely arbitrary and the result of an "I'll show you" abuse of position rather than a legitimate use of moderation authority. I strongly suspect this was the result of an off-list reply explaining to Jelle that I didn't appreciate him jumping into a thread and claiming to be able to read my mind. That was uncalled for, inappropriate and to suggest he knew my thoughts was utter speculation. This has been going on for months, and apparently the moderation is permanent as I've been given no information on when the sentence will end. I've always been respectful and mindful of my posts and this was no different. I formally appeal the determination and request a review and full determination on the merits. There was no justification for this and we should have all grown beyond kindergarten and wanting to show who is top-dog on the playground. That has no place in open-source. -------- Forwarded Message -------- Subject: What is the policy/thoughts on embedding icons/emojis/unicode glyphs in package descriptions in PKGbUILD Date: Thu, 19 Dec 2024 06:13:21 +0000 From: aur-general-owner(a)lists.archlinux.org To: drankinatty(a)gmail.com Your message to the Aur-general mailing-list was rejected for the following reasons: The message comes from a moderated member The original message as received by Mailman is attached. -- David C. Rankin, J.D.,P.E.

1 0

Solaar Pair Touble
by Silvio Siefke 18 Dec '24

18 Dec '24

Hello, I have a Logitech MK850 set which actually worked well. The mouse was causing problems, so I found Solaar and it works. Unfortunately, I once clicked on unpair and since then the mouse cannot be used via USB. The search for new devices is ended with "Device Block". I have deleted the configuration, I have deleted the UDEV rules, but the mouse still no longer works via USB. Does anyone have any ideas what I could do? Thanks Silvio

1 0

Request for review of two merge requests (Fcitx5-Mozc, Fcitx-Mozc)
by Masato TOYOSHIMA 16 Dec '24

16 Dec '24

Hello everyone I've been using Arch Linux in containers and have tried several Arch-based desktops. I'd like to discuss two Japanese input packages that haven't been updated for about two years. I've created merge requests for major upgrades for both packages. Among Japanese input packages, Mozc likely has the most users currently. There are two Mozc packages in the Arch Linux repository: Fcitx5-Mozc and Fcitx-Mozc. While Fcitx5 has become the main development focus, Fcitx-mozc is still packaged in newer distributions. These two packages haven't been updated for about two years. I created merge requests for major upgrades about two weeks ago. I've tried contacting the previous package maintainers and those assigned by bots, but there's been no response. I'm posting here hoping to catch the attention of those with merge permissions. I'd appreciate if you could review the merge requests for these two packages when you have time. As additional information, the original google/mozc has moved to Bazel build for the Linux version. Fcitx5 already supported Bazel build, and Fcitx (fcitx4) has recently added support for it as well. Therefore, both packages can now be built with Bazel without additional patches or PRs. I've been updating the merge requests to keep them aligned with the latest commits. Now that Fcitx(4)'s Bazel support is complete, it seems like a good time for review. Please review the merge requests when possible. I apologize for the long message. Thank you for your consideration. https://gitlab.archlinux.org/archlinux/packaging/packages/fcitx5-mozc/-/mer… https://gitlab.archlinux.org/archlinux/packaging/packages/fcitx-mozc/-/merg…

1 1

Request For Insights On Kernel Security Hardening Practices In Arch Linux
by Yinhao Hu 13 Dec '24

13 Dec '24

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-NN…. Given Arch Linux’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 huyinhaodd(a)gmail.com Huazhong University of Science and Technology

1 0