- Arch-dev-public - lists.archlinux.org

Adding Emil Velikov as maintainer of libudev0-shim
by Morten Linderud 05 Jun '24

05 Jun '24

Yo, `libudev0-shim` is a udev compat shim that some of our packages, most notably stream, and a few other downstreams utilize. It was written 8 years ago by Dave Reisner and has seen no development since then, but Valve/Steam has sent a couple of changes to this project. I originally asked on IRC if anyone wanted to maintain this, but after no response Emil replied on a PR that he would gladly take over maintainership of this project. Emil has been around for a few years on bugreports and misc patches to upstream projects, and generally is a nice guy. I can't see anyone objecting to this so I've asked devops to add them to the Github repository. This emailserves as a headsup that Emil is now the maintainer of the project. https://github.com/archlinux/libudev0-shim -- Morten Linderud PGP: 9C02FF419FECBE16

1 0

Stepping down
by Maxim Baz 27 May '24

27 May '24

Hi everyone Life got busier than ever, and I find myself unable to give nearly as much attention to packaging that it deserves. As such, I believe the most respectful course of action would be for me to step down as package maintainer now, and re-apply in the future if this makes sense. There's no immediate action needed for any of my packages, I have updated them all today. But here's the list of packages where I'm the sole maintainer, it would be awesome if some of them would earn your interest to adopt them: aspell-da browserpass browserpass-chromium browserpass-firefox curlie gocryptfs goimapnotify grub-btrfs kitty libu2f-server pam-u2f python-black python-i3ipc rebuild-detector swappy ttf-joypixels wire-desktop wldash yubikey-touch-detector Best wishes Maxim Baz

6 5

Cleaning up some of my packages
by Filipe Laíns 24 May '24

24 May '24

Hi everyone, A while ago I wrote to the staff mailing list about my lack of activity. Thankfully, I think I am finally now slowly getting back up to speed with life and my open source commitments. If someone wants more details, I wrote a bigger explanation on [1] (tw: mental health). To help with this, I think I should do some cleaning up of my packages, I have disowned a bunch of them. Several of them, such as the Deepin, Budgie, and D packages, had a co-maintainer, so they should be alright. The ones that didn't are listed below. I tried to list the maintainers of the dependents to make it easier to identify. Packages with dependents: pyannotate (check dependency for python-py7zr, cc Caleb) python-dill (dependency for python-pylint, cc Caleb) python-future (dependency for a bunch of Felix's packages, and more) python-multipart (dependency for python-moto, cc Chih-Hsuan) python-py (dependency for python-pytest-forked, cc Felix) python-pypng (dependency for python-qrcode, cc Felix, Levente, Caleb) python-zc.lockfile (dependency for python-cherrypy and python-pytest-services, cc Thore and David) (check/optional dependencis for python-fastapi) python-aiomysql python-aiopg python-aiosqlite (also hard dependency for python-ypy-websocket, cc Antonio) python-asyncpg (also hard dependency for nominatim, cc Justin) python-databases D ecosystem packages without dependents: adrdox d-containers d-mir-core d-stdx-allocator gir-to-d glibd mustache-d General packages without dependents: bluefish budgie-extras dbxtool (deprecated — archived on Github, and replaced by fwupd) flterm fusesoc grub-theme-vimix log4cpp netcf pulseaudio-equalizer-ladspa python-biopython python-bitcoinlib python-edalize python-euclid3 python-ipyxact python-litevideo python-litedram python-liteeth python-liteiclink python-litejesd204b python-litepcie python-litesata python-litescope python-litesdcard python-litevideo python-litex python-litex-boards python-livereload python-kikit python-markdown2 python-migen python-occ-core python-okonomiyaki python-pybars3 python-pymeta3 python-pypubsub python-pyvcd python-simplesat python-solidpython python-sphinx-typlog-theme python-svgwrite python-watchgod thefuck This lists includes flatenned dependency trees, so if you adopt any of the packages listed as without dependents, please be keep in mind they might depend on other packages on the list. You might want to pick up those too. [1] https://ffy00.github.io/blog/03-state-of-things-2024-04/ Cheers, Filipe Laíns

1 0

Re: pre-releases (for systemd & co) in core-testing
by Christian Hesse 23 May '24

23 May '24

Genes Lists <lists(a)sapience.com> on Thu, 2024/05/23 06:27: > On Thu, 2024-05-23 at 09:16 +0200, Christian Hesse wrote: > > Christian Hesse <list(a)eworm.de> on Wed, 2024/05/15 11:08: > > > .. > > > Feedback welcome! > > > > Pushed systemd 256rc3-1 last night. All the same applies... > > Please keep testing! > > Hi Christian > > For feedback do you plan to make this visible in the package > signoffs page [1] or do you want a quick email with ack/nack? > > For now: > > mkinitcpio-39.1-1.1 - all good > systemd-256rc3-1 - all good > > gene > > [1] https://archlinux.org/packages/signoffs/ Good point! I would have to push to core-testing repository for the packages to be visible for signoffs. That's what I tend to avoid now with pre-releases. So short notice via mail or messaging is fine. Thanks! -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}

1 0

Re: pre-releases (for systemd & co) in core-testing
by Christian Hesse 15 May '24

15 May '24

Randy DuCharme <radio.ad5gb(a)gmail.com> on Wed, 2024/05/15 05:06: > Suggestion (s). This is open source real life comes first, always. > > People that volunteer to help are genuinely real but being ignored wins > ZERO.... even if they have 27 years of C C++ No idea what you want to tell me... Really. Please try again if this is a serious suggestion related to the topic. -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}

1 0

Mesa pulled from testing
by Jan Alexander Steffens (heftig) 08 May '24

08 May '24

I've removed Mesa 1:24.0.7-1 from testing as the radeonsi driver crashes immediately, somewhere deep in LLVM. This concerns the following packages: • libva-mesa-driver • mesa • mesa-vdpau • opencl-clover-mesa • opencl-rusticl-mesa • vulkan-intel • vulkan-mesa-layers • vulkan-nouveau • vulkan-radeon • vulkan-swrast • vulkan-virtio • lib32-libva-mesa-driver • lib32-mesa • lib32-mesa-vdpau • lib32-opencl-clover-mesa • lib32-opencl-rusticl-mesa • lib32-vulkan-intel • lib32-vulkan-mesa-layers • lib32-vulkan-nouveau • lib32-vulkan-radeon • lib32-vulkan-swrast • lib32-vulkan-virtio

1 0

Orphaning some packages
by Chih-Hsuan Yen 04 May '24

04 May '24

Hi all, I'm going to orphan some packages that I no longer need or depend on, so that I can better focus on my other packages. Here is the package list: * fcitx-chewing * nextcloud-client * python-nbdime * python-nbval * python-openpyxl * python-pg8000 * python-prctl * python-scramp * python-sure * python-testing.postgresql (may be dropped - depends on python-nose, no upstream commits since 2017) * scim-chewing * web-ext Please adopt packages you need, thanks! Best Regards, Chih-Hsuan Yen (yan12125)

1 0

time64 ABI fix coming to upstream glibc
by Florian Weimer 02 May '24

02 May '24

The <utmp.h> and <utmp.h> headers had a bug that the on-disk structures defined there could change size on some targets when _TIME_BITS was set to 64. This is obviously wrong because the files are not going to magically change their layout because the application accessing them was built in a specific way. We're going to fix this in glibc upstream on the stable release branches, going all the way back to glibc 3.34 (the first release with this kind of time64 support). After the fix, the _TIME_BITS definition will no longer impact struct layout. Usually, that means epoch fields are 32-bits wide, to match co-installable architectures. To extend the usable life-time of these interfaces somewhat, glibc 2.40 changes epoch fields to unsigned types in these structures. This change is specific to the upcoming glibc 2.40 release, I do not plan to backport it. Thanks, Florian

1 0

Archweb ToDo Notes
by Jelle van der Waa 28 Apr '24

28 Apr '24

Hi all, Archweb ToDo's now have a link called "Todo Notes" this links to an md.archlinux.org pad based on the todo slug (prefixed with archweb) to avoid conflicts. Hopefully this helps collaboration on todo's which are a bit more complicated or require additional information. So for example for: https://archlinux.org/todo/drop-python-exceptiongroup/ There is now automatically: https://md.archlinux.org/archweb-drop-python-exceptiongroup Hopefully this helps with sharing why something is not rebuild/finished in a todo with links to issues. Archweb cannot detect if soemone has written to the pad, so maybe the body should have a *note* about it :-) Greetings, Jelle

1 0

Python 3.13 specific packaging issues
by Jelle van der Waa 27 Apr '24

27 Apr '24

Hi all, We are almost ready to drop Python 3.12 in testing, hopefully tensorflow can be pursued-ed to recompile against [staging] soon. This Python release dropped the `imp` module, but the next release (3.13) which is slated for October this year will drop more Python batteries, some methods and some unittest invocations. [1] I already scanned a part of the Python packages and the mailcap and cgi deprecation will be a bit painful. (And logger.warn usage but that is easy to patch to logger.warning) I want to propose to open issues per package for Python 3.13 compatibility, it would point out what is not compatible and ideally link to an upstream issue or let the package maintainer create this issue. Once we are ready to start thinking about a Python 3.13 rebuild we can go through the list of issues with a `python-3.13` label. [2] Finding issues now will hopefully: a) convince packages we maintain to get a new release b) a happier rebuild c) find packages which are issues and should likely not be maintained in the repos There is one caveat, the changelog is draft. I am not sure if Python has a history of reverting breaking changes in an alpha release. But as far as I know these things have been deprecated for quite a while. We have a history of not opening upstream issues in our packaging repository, but I think for this scenario it would make sense and actually help us deliver Python sooner in the repos. [1] https://docs.python.org/3.13/whatsnew/3.13.html [2] https://gitlab.archlinux.org/groups/archlinux/packaging/packages/-/issues Greetings, Jelle van der Waa

4 6