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

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

RFC Final Comment Period: Arch Linux Ports
by David Runge 25 Apr '24

25 Apr '24

An RFC has now entered Final Comment Period. In 14 days, discussion will end and the proposal will either be accepted, rejected or withdrawn: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/32 Please visit the above link for discussion. Summary: Introduce "Arch Linux Ports" as testbed for unofficial architectures until they are integrated in the main Arch Linux repositories. This integration is meant to provide infrastructure and community-based support for architectures until they are fully supported by the main distribution.

1 0

Python 3.12
by Jelle van der Waa 21 Apr '24

21 Apr '24

Hi all, We should get started on Python 3.12, 3.13 alpha is already getting released! To be 100% honest, I am not super looking forward to it as it's a ton of work due to our lack of automated tooling. In basics a plan would be to first tackle low hanging fruit to-do's: * https://archlinux.org/todo/pytest-runner-removal/ * https://archlinux.org/todo/imp-module-removal-in-python-312/ * https://archlinux.org/todo/use-pyprojecttoml-for-building-if-supported/ * drop unused python modules in our repo https://archlinux.org/devel/reports/unneeded-orphans/ We've finished python-bootstrap, and can bootstrap the required build packages (python-setuptools, build, etc.). And figuring out the rebuild order. (Big thanks to david, for the help here!) [1] [2] So soon we can start the rebuild which will probably take a while to complete as we have no good automated tooling yet for mass rebuilds. This rebuild will likely block [staging] for a good 2 or more weeks, so when would be a good time to schedule this? I expect two things to break our package builds in 3.12: * The removal of distutils see the snippet below, adding python-setuptools to makedepends should resolve this. For example: GISCAN ZBar-1.0.gir Traceback (most recent call last): File "/usr/bin/g-ir-scanner", line 99, in <module> from giscanner.utils import dll_dirs File "/usr/lib/gobject-introspection/giscanner/utils.py", line 385, in <module> import distutils.cygwinccompiler ModuleNotFoundError: No module named 'distutils' * The removal of the imp module, the todo list above has been open for a while, but not all packages have been fixed. * The usual failing tests, missing sources you know it :) [1] https://gitlab.archlinux.org/archlinux/python-bootstrap/-/merge_requests/3 [2] https://notes.vdwaa.nl/arch/python.html Greetings, Jelle

2 6