- Arch-general - lists.archlinux.org

Hello
by Mats Svensson 29 Dec '24

29 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

include in mailing list
by HARRY JAIN 26 Nov '24

26 Nov '24

1 0

Archinstall in ISO 2024.11.01 some kind of broken
by Dan TechGameGeek 18 Nov '24

18 Nov '24

Hi, it seems like the archinstall script in the 2024.11.01 Archiso is broken. It runs for a while and then quits with the error: failed to connect to user scope bus via local transport: No media found Pulling the script of the archinstall-script from git and running the downloades script for installation solves it. git clone https://github.com/archlinux/archinstall.git I assume you fix it in the next ISOs ;-) ? Thanks for the great work! BR Daniel

1 0

x265.h
by Mark E. Mallett 17 Nov '24

17 Nov '24

I'm confused(*) I was compiling something that uses /usr/include/x265.h and it failed. It hasn't failed like this before and it hasn't changed lately. The thing it was having trouble with was this member of x265_api (wrapped for this posting): int (*encoder_encode)(x265_encoder*, x265_nal**, uint32_t*, x265_picture*, x265_picture**); The last element is different than it used to be, it used to be * not **. And ** doesn't really make sense. In the hope that the underlying library wasn't using this definition, I did a typecast where it was used and the compilation succeeded and the program worked. But: I wondered if this was some typo ocurring weirdly. I compared x265.h with the one from a prior version (which I still had in the pacman cache) and there were lots of changes, some probably just for internal purposes, but some with changes to calling sequences that surely must break things that use them. I asked pacman where the code came from (pacman -Qi) and looked there: https://bitbucket.org/multicoreware/x265_git/src/master/source/x265.h and that file does not have this change. (It has others, including at least one that seems problematic). The version of /usr/include/x265 on my system is dated Oct 3 2024 and that matches the "build date" reported by pacman. The modification history in the bitbucket link above has an entry signficantly dated October 4 that says "Reverted the api changes." I infer that the change that affected me was, for lack of a better word, corrected. But evidently Arch hasn't picked it up. (I did a system update today.) Maybe Oct 3 is the last released date, I dunno. That would be odd if so. I don't know what answer I'm looking for here, maybe none, but thought I would mention it. At length ;) -mm- (*)always

1 1

What could cause RSS Recent Package Feed to Hang in Thunderbird?
by David C. Rankin 12 Nov '24

12 Nov '24

All, In Thunderbird 128.3.3esr if I check the RSS Recent Package feed from Arch, Thunderbird hangs showing the check is continually ongoing and never finishes. This takes a continual 143% CPU (about 1/3 of the 4-core i-7) It gets the Recent Packages just fine, but never stops. Checking with tcpdump the connection to 95.217.163.246 initializes just fine with the QUIC protocol and then continues with the data transferred. The last message from 95.217.163.246 is a TCP ACK and then nothing else. Thunderbird just shown the little icon next to the feed as busy (little ball going back and forth) and the CPU is pegged at about 150%. (other than just looking at the tcpdump data in Wireshark - it's pretty much Greek to me) There is no way to cancel the check except to "Pause" the RSS feed and then shutdown thunderbird and restart it. If I then "unPause" the RSS feed after restarting tbird, the same thing happened. I've been subscribed to the RSS feed for years. This just started a couple of days ago. What should I check or look for to try and figure out why the RSS feed check never finishes and shuts down? -- David C. Rankin, J.D.,P.E.

3 4

mail.archlinux.org (95.216.189.61) reverse lookup down earlier today?
by David C. Rankin 09 Nov '24

09 Nov '24

Arch Leaders, Was there a reverse lookup problem with the mail delivery from gitlab(a)archlinux.org earlier today. It looks like reverse lookup for 95.216.189.61 was failing this morning, and the IP got banned by fail2ban in the postfix jail. One of the log entries was: 2024-11-08T09:24:43.204447-05:00 valkyrie postfix/smtpd[490171]: NOQUEUE: reject: RCPT from unknown[95.216.189.61]: 450 4.7.25 Client host rejected: cannot find your hostname, [95.216.189.61]; from=<gitlab(a)archlinux.org> I had to unban the IP manually after whatever was going on this morning. Was there a temporary issue with DNS reverse lookups earlier?. I can look it up with a reverse lookup now just fine, e.g. $ dig -x 95.216.189.61 ; <<>> DiG 9.20.3 <<>> -x 95.216.189.61 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42701 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 405df5f3dae627dd01000000672e9d65152c46ac67e9ae9e (good) ;; QUESTION SECTION: ;61.189.216.95.in-addr.arpa. IN PTR ;; ANSWER SECTION: 61.189.216.95.in-addr.arpa. 54097 IN PTR mail.archlinux.org. ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP) ;; WHEN: Fri Nov 08 17:23:17 CST 2024 ;; MSG SIZE rcvd: 115 Thought I would pass it along in case there was an issue that needed looking into. -- David C. Rankin, J.D.,P.E.

1 0