Arch Linux software projects: Request for participation
Hi all, we have recently cleaned up parts of the developer wiki a bit and moved the list of internal projects to a more prominent location: https://wiki.archlinux.org/title/Getting_involved#Software_projects As you can see, we have quite a few projects and some of them would be happy about more participation from members of the Arch Linux staff as well as users. Help in fixing and extending the software is much appreciated, but testing and opening tickets that describe flaws or usability problems are equally important! If you are familiar with writing documentation, Ash, Bash, C, JavaScript, Python, or Rust and always wanted to get involved with one of the Arch Linux projects: Look no further! :) As mentioned in the wiki, we have a central mailing list [1] and IRC channel [2] for discussing most of the projects (unless they provide other means of communication). We hope to spark people's enthusiasm, as healthy projects ensure a flexible distribution and allow us to tackle larger goals (e.g. move to a git based workflow for packaging, effortlessly providing several architectures, automating our infrastructure and releases, etc.). Best, David [1] https://lists.archlinux.org/mailman3/lists/arch-projects.lists.archlinux.org/ [2] ircs://irc.libera.chat/archlinux-projects -- https://sleepmap.de signature.asc Description: PGP signature
Public release: updlockfiles 0.1.0
ohai! I released a new tool called updlockfiles that attempts to help manage dependency lockfiles like Cargo.lock, composer.lock, go.mod and friends. Hopefully this helps with reproducible builds in Arch Linux, but also if you want to manage your own downstream lockfile to override vulnerable dependencies. Announcement blog post: https://vulns.xyz/2022/10/updlockfiles/ Repository: https://github.com/kpcyrd/updlockfiles cheers, kpcyrd
git 2.38.0: Change in `git archive` output
hello, multiple people in Arch Linux noticed the output of our `git archive` command doesn't match the tarball served by github anymore. First I suspected an update in our gzip package until I found this line in the git 2.38.0 release notes: > * Teach "git archive" to (optionally and then by default) avoid > spawning an external "gzip" process when creating ".tar.gz" (and > ".tgz") archives. I've then found this commit that could be considered a breaking change in `git archive`: https://github.com/git/git/commit/4f4be00d302bc52d0d9d5a3d4738bb525066c710 I don't know if there's some kind of gzip standard that could be used to align the git internal gzip implementation with gnu gzip. I'm not saying this is necessarily a bug or regression but it makes it harder to reproduce github tar balls from a git repository. Just sharing what I've debugged. :) cheers, kpcyrd
