Package Todo Lists
Todo lists are used by the developers when a rebuild of a set of packages is needed. This is common when a library has a version bump, during a toolchain rebuild, or a general cleanup of packages in the repositories. The progress can be tracked here, and completed todo lists can be browsed as well.
| Name | Creation Date | Creator | Description | Package Count | Incomplete Count | Kind | Status |
|---|---|---|---|---|---|---|---|
| proj 9 + gdal 3.5 rebuild | 2022-06-27 | Bruno Pagani | Both packages have a soname bump and a lot of common reverse dependencies, so let’s do both at once. Packages go to [staging]. | 21 | 15 | Rebuild | Incomplete |
| Use system CA store | 2022-06-27 | Felix Yan | We have a long-standing issue of having multiple vendored CA stores across various packages. This makes customizing CA store not possible for a subset of packages, the additional copies are often out-of-date, and it's inconsistent in general. Some packages were made solely for providing another copy for a language ecosystem, for example python-certifi and perl-mozilla-ca, and some are vendoring the formers. This draft TODO is collecting packages following this pattern and providing a possible clean solution: - Make the language-specific CA store packages providing "/etc/ssl/certs/ca-certificates.crt" and depends on ca-certificates, possibly via making a symlink for maximum compatibility. - Try to devendor packages containing them with a system copy, thus our alternative packages could be used instead. - For not applicable packages (for example, vendoring CA store themselves without calling a third party provider), try to symlink or patch manually and make it depends on ca-certificates. The list may not be complete. Some packages are also added to the list for manually patching out calls to certifi.where(), etc, which should not be needed anymore after step 1 above was done. | 26 | 19 | Task | Incomplete |
| python-tzlocal 4.x blockers | 2022-06-07 | Daniel M. Capella | Projects need to support tzlocal 3.x+ or switch to just https://docs.python.org/3/library/zoneinfo.html https://github.com/regebro/tzlocal#api-change - [ ] jrnl: https://github.com/jrnl-org/jrnl/issues/1338 - [ ] python-dateparser: https://github.com/scrapinghub/dateparser/issues/1001 - [x] vit: No longer requires tzlocal (and pytz) but its dep tasklib still pulls them in until the next release anyways. https://github.com/vit-project/vit/commit/5534f81deee3f3df8d582c4ea220cc71a7496eea Unreleased: - [x] khal: https://github.com/pimutils/khal/commit/d39f2b438a6abc9b6e85ec579b67484192b7311c - [ ] python-tasklib: https://github.com/GothenburgBitFactory/tasklib/commit/0307266a6f1c53110f819064f8b79d00eb73c2d4 Unknown: - [ ] python-js2py - [ ] python-rpy2 - [x] py3status: Clock module supports at least tzlocal 3.0 https://github.com/ultrabug/py3status/commit/a874e053c4a6e995a98f58380a2854a55cecb56a - as far as I can tell it works fine with tzlocal 4.2 as well, the clock module displays as expected (and this is the only place in py3status where python-tzlocal is used) | 8 | 5 | Task | Incomplete |
| Packages with invalid .BUILDINFO | 2022-05-18 | David Runge | While working on package validation for repod, the following packages were found to have invalid .BUILDINFO files. The invalid values most often consist of long obsoleted option keywords (see options subsection in https://man.archlinux.org/man/makepkg.conf.5#OPTIONS). In case there are questions, please reach out via mail or IRC. As we would like to be able to have a consistent and reproducible set of packages in the official repositories, the below packages need to be rebuilt to have stricter validation that can even be run on a daily basis. Rebuilds go straight to the stable repositories | 58 | 25 | Rebuild | Incomplete |
| Packages with invalid buildtoolver in .BUILDINFO | 2022-05-17 | David Runge | While working on validation for repod, the below packages have been found to have an invalid buildtoolver in their .BUILDINFO file (see https://man.archlinux.org/man/BUILDINFO.5), while having devtools as their buildtool (which is likely caused by not using the canonical devtools). To be able to provide strict validation for ingoing packages in the future, we would like to be able to ensure, that packages built with devtools are valid and that they can be rebuilt using the same tooling. To circumvent issues such as these, please only use devtools for building packages for the official repositories. This is likely going to become a fixed input requirement in the future. Rebuilds go straight to the stable repositories. | 255 | 252 | Rebuild | Incomplete |
| go 1.18 | 2022-04-27 | Jelle van der Waa | Rebuild all golang packages to build with golang 1.18 to make our packages use the runtime improvements of the last X golang releases \o/ Packages go to the stable repositories directly. | 237 | 16 | Rebuild | Incomplete |
| Rebuild packages signed by 9437DD3815A7A9169E3D3946AFF5D95098BC6FF5 | 2022-03-06 | Evangelos Foutras | Access to the key was lost and a new key is in the process of being added to the keyring: https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/issues/147 | 33 | 7 | Rebuild | Incomplete |
| ffmpeg4.4 removal | 2022-02-18 | Maxime Gauduin | New todo to progressively phase out ffmpeg4.4, no rush, just something to keep in mind. Packages can go to extra/community directly. | 30 | 21 | Task | Incomplete |
| DRAFT: OpenSSL 3.0 | 2022-01-09 | Pierre Schmitz | **NOTE**: This is a draft and lists all packages linking to an openssl library. Check the mailing list about information when and how this massive rebuild starts. (openssl-3.0 was not yet pushed into [staging]) List was created like this: https://gist.github.com/pierres/6ed603a7934baec58d7742f1bc6362b6 Most packages should compile fine with OpenSSL 3. There might be deprecation warnings though. If packages still need openssl version 1.1: * Add a dependency to the new "openssl-1.1" package * Compile with e.g. CPPFLAGS+=" -I/usr/include/openssl-1.1" LDFLAGS+=" -L/usr/lib/openssl-1.1" Living documentation about packages that work and fail with OpenSSL 3: https://md.archlinux.org/s/t8HOyhNOi | 494 | 494 | Rebuild | Incomplete |
| OpenSSL 1.0 retirement | 2022-01-08 | Pierre Schmitz | OpenSSL 1.0 is not supported by the upstream project and does not receive any security fixes (at least not without a support contract). For obvious reasons is not advisable to use a security related library that has reach end if life. We should remove support for version 1.0 and any packages that depend on it. If possible these packages can be compiled against openssl-1.1 instead. | 5 | 4 | Task | Incomplete |
| PHP 7 retiredment | 2022-01-08 | Pierre Schmitz | php7 packages were introduced to ease the transition from 7 to 8 as PHP5-Code would throw warnings did not work with version 8 anymore: https://archlinux.org/news/php-80-and-php-7-legacy-packages-are-available/ php7 packages will be removed soon. This list contains packages that still depend on php7. Most actively maintained projects do support PHP 8 by now and we simply need to adjust dependencies. Packages that are no longer in active development should be removed from the repos; we might want to write a combined announcement for these. I did look into most of these packages; see https://lists.archlinux.org/pipermail/arch-dev-public/2022-January/030610.html for details. | 8 | 8 | Task | Incomplete |
| Remove python2 optdepends from package | 2021-12-20 | Morten Linderud | We are trying to remove python2, several packages has optional dependencies on python2 and they should be removed. If the script isn't ported to python yet, it might be an idea to drop the script completely. | 11 | 1 | Task | Incomplete |
| Cleanup of python-setuptools dependency for console scripts | 2021-01-13 | Felix Yan | In recent versions of setuptools and Python, console-script entry points are using stdlib importlib by default, thus python-setuptools (provider of the pkg_resource module) is no longer a runtime dependency. Please check your package. If python-setuptools is only listed as dependency or optional dependency because of its console scripts (not in install_requires for other reasons, for example), please consider moving it to makedepends or removed, respectively. Packages go to stable repos directly. | 250 | 49 | Task | Incomplete |
| GTK 2 EOL | 2020-12-20 | Alexander Rødseth | GTK 2 has reached its end of life: https://blog.gtk.org/2020/12/16/gtk-4-0/ Many of the listed packages can support GTK3 or 4 just by tweaking the build configuration. Please check if it is possible to upgrade packages to GTK3 or GTK4 (which are pretty similar to each other, in terms of API), or drop the dependency on the "gtk2" package, if it's an optional dependency. Just mark packages as complete if it's not feasible to patch, drop or upgrade them. A build-time gtk2 replacement that is a compatibility layer for using gtk3 is available as the "gtk2-compat" package. It may only work for some projects. Upgraded packages can be pushed directly to extra/community. Thank you! A list of notes about GTK2 packages can be found here https://md.archlinux.org/QfM91GeYSxeT6Y5VoJ5Hrw Feel free to expand. | 105 | 77 | Task | Incomplete |
| Conversion of programs that use Python 2 to Python 3 | 2019-12-23 | Chih-Hsuan Yen | Python 2.7 branch is going to be EOL'ed on 2020-01-01 [1]. A previous Todo [2] suggests to remove unused Python 2 libraries. In this Todo, I suggest to investigate programs that still use Python 2, either as runtime dependency or build/check dependencies, and see if it's possible to use Python 3 instead. Notes for some packages are available at https://wiki.archlinux.org/index.php/User:Yan12125/python3-conversion. Whenever you have changed a package to use Python 3, feel free to either move the corresponding row to the Done section or simply remove the row. Also, feel free to update notes if there are something new (e.g., a new Python 3-compatible version released, patches merged, new patches proposed, ...). Package can go directly into the repo; [staging] is not necessary. [1] https://devguide.python.org/ [2] https://www.archlinux.org/todo/die-python2-die/ | 203 | 4 | Task | Incomplete |
| LLVM 14 | 2022-06-22 | Evangelos Foutras | The usual soname bumps. :) Additionally, I have added experimental {llvm,clang,lld}13 packages for Zig. (Seems to find it fine with -DCMAKE_PREFIX_PATH=/usr/lib/llvm13). llvm13-libs can likely also be used to bootstrap rust and ldc (by temporarily adding it as a build dep). Packages go to staging; shout on IRC if you notice any issues. | 60 | 0 | Rebuild | Complete |
| srt 1.5.0 | 2022-06-15 | Jan Alexander Steffens | libsrt.so.1.4 -> libsrt.so.1.5 Packages go to staging. | 6 | 0 | Rebuild | Complete |
| glslang 11.10 rebuild | 2022-06-13 | Sven-Hendrik Haase | Right to staging | 4 | 0 | Rebuild | Complete |
| openvdb 9.1.0 | 2022-06-13 | Sven-Hendrik Haase | All to staging | 6 | 0 | Rebuild | Complete |
| Changed location for openmpi libraries | 2022-06-12 | David Runge | With openmpi >= 4.1.3 the shared object files are no longer private (as dependencies have been added to the build). To ensure that dependents can find the openmpi components properly, rebuild them. If the package in question has been rebuilt/ upgraded against openmpi >= 4.1.3 just mark the item as done. Rebuilds go straight to the stable repositories. | 20 | 0 | Rebuild | Complete |
| Conflict and replace python-jaraco | 2022-06-08 | David Runge | The newly added packages providing the components found in python-jaraco need to conflict and replace python-jaraco. Rebuilds got to [community-staging]. | 0 | 0 | Rebuild | Complete |
| Depend on specific python-jaraco package | 2022-06-07 | David Runge | The python-jaraco package bundles a few Python packages, which does not follow the Python package guidelines. To be able to split the package into its respective components, we need to first fix all packages plainly depending on python-jaraco (which is in fact only a virtual package). Each package should instead depend on one (or several of) python-jaraco.classes, python-jaraco.collections, python-jaraco.functools, python-jaraco.itertools, python-jaraco.logging, python-jaraco.stream, python-jaraco.text. Rebuilds go straight to the stable repositories. | 9 | 0 | Rebuild | Complete |
| capnproto 0.10.1 rebuild | 2022-06-07 | David Runge | Capnproto 0.10.1 introduced a soname bump. Rebuilds go to [community-staging]. | 4 | 0 | Rebuild | Complete |
| opencv 4.6 rebuild | 2022-06-05 | Antonio Rojas | Packages go to [staging] | 21 | 0 | Rebuild | Complete |
| Rebuild packages usinge whitespace characters in url field | 2022-06-03 | David Runge | Whitespace characters in a PKGBUILD's url field need to be circumvented, as (especially if not just trailing) they denote an invalid url (depending on software making use of it). Rebuilds go straight to the stable repositories. For reference: https://pkgbuild.vdwaa.nl/?q=%5Eurl%3D(%27%7C%22)%5Bhpst%3A%2F%5D%2B%5B%5Cw%2F_%5C-.%5D%2B%5Cs%2B(%5B%5Cw%2F_%5C-.%5D%2B%7C)(%27%7C%22)%24&i=nope&files=&excludeFiles=&repos= | 2 | 0 | Rebuild | Complete |
| Rebuild packages using ftp protocol in url field | 2022-06-02 | David Runge | Current browsers have abolished the support for `ftp://`, so let's remove it from the url fields of our PKGBUILDs. Rebuilds go straight to the stable repositories. For reference: https://pkgbuild.vdwaa.nl/?q=url%3D(%27%7C%22)ftp%3A%2F%2F&i=nope&files=&excludeFiles=&repos= | 59 | 0 | Rebuild | Complete |
| Poppler 22.06.0 update | 2022-06-02 | Andreas Radke | libpoppler.so.121 -> libpoppler.so.122 Please push packages to the staging repos. https://lists.freedesktop.org/archives/poppler/2022-June/015249.html | 12 | 0 | Rebuild | Complete |
| Remaining rebuilds for Perl 5.36.0 | 2022-05-29 | Florian Pritz | These are the last remaining packages that need a rebuild for Perl 5.36.0. They either fail to build or have test failures in check(). Please push the rebuilt packages to staging/community-staging. Changelog, if needed, is at https://perldoc.perl.org/5.36.0/perldelta | 7 | 0 | Rebuild | Complete |
| hdf5 1.12.2 | 2022-05-15 | Bruno Pagani | As always, hdf5 requires everything linking to it to be rebuild even for patch updates (https://bugs.archlinux.org/task/60567). So here we go, packages go to [staging]. | 24 | 0 | Rebuild | Complete |
| cuda 11.7 rebuild | 2022-05-12 | Sven-Hendrik Haase | Rebuilds to staging | 10 | 0 | Rebuild | Complete |
| jasper 3.0.3 rebuild | 2022-05-11 | Levente Polyak | packages go to staging. | 13 | 0 | Rebuild | Complete |
| Rebuild Todo List Poppler 22.05.0 update | 2022-05-05 | Andreas Radke | libpoppler.so.119 -> libpoppler.so.121 Please push packages to the staging repos. https://lists.freedesktop.org/archives/poppler/2022-April/015171.html https://lists.freedesktop.org/archives/poppler/2022-May/015227.html | 9 | 0 | Rebuild | Complete |
| libuhd 4.2.0 rebuild | 2022-05-05 | Antonio Rojas | Packages go to [staging] | 8 | 0 | Rebuild | Complete |
| podofo rebuild | 2022-05-04 | Jelle van der Waa | podofo rebuild | 5 | 0 | Rebuild | Complete |
| onednn 2.6 rebuild | 2022-04-29 | Sven-Hendrik Haase | Goes to staging, move directly to stable after last package built | 3 | 0 | Rebuild | Complete |
| Transmission DHT 0.27 rebuild | 2022-04-29 | Brett Cornwall | dht 0.27 has been released recently and addresses a minor bug [1]. Transmission upstream is en route to updating its included dep to 0.27 as well [2]. DHT 0.27 has been updated in [community], the transmission packages can be built from that. [1] https://github.com/jech/dht/commit/2b3a6364d0925b4e1eb14baa4f8f76a464fa331d [2] https://github.com/transmission/transmission/pull/3015/files | 1 | 0 | Rebuild | Complete |
| libglog 0.6.0 rebuild | 2022-04-27 | Antonio Rojas | Packages go to [staging] | 6 | 0 | Rebuild | Complete |
| dav1d 1.0.0 rebuild | 2022-04-25 | Levente Polyak | all packages go to [staging] | 11 | 0 | Rebuild | Complete |
| Rebuild packages signed by subkeys of 3DCE51D60930EBA47858BA4146F633CBB0EB4BF2 | 2022-04-22 | David Runge | The packages signed by (some) subkeys of 3DCE51D60930EBA47858BA4146F633CBB0EB4BF2 need to be rebuilt as they are expired. For reference see the related tickets [1][2]. Rebuilds go straight to the stable repositories. [1] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/issues/161 [2] https://bugs.archlinux.org/task/74538 | 0 | 0 | Rebuild | Complete |
| QEMU 7.0.0 packaging changes | 2022-04-21 | David Runge | With QEMU 7.0.0 the package has been turned into a split package. Previous functionality has been largely superseded by meta packages: * qemu -> qemu-desktop * qemu-headless -> qemu-base * qemu-headless-arch-extra/ qemu-arch-extra -> qemu-emulators-full The qemu package itself is now a virtual package, while qemu-common provides some shared functionality. The qemu-{base,desktop,full} meta packages provide qemu (in different feature richness) and also each provide all optdepends. The user mode and system emulators, as well as all hardware emulation and drivers, etc. can now be addressed granularly. Please adjust your packages according to the new setup (e.g. either by depending on specific system emulators or on one of the meta packages). Rebuilds go to [staging]/ [community-staging]. | 11 | 0 | Rebuild | Complete |
| quazip 1.3 | 2022-04-16 | Antonio Rojas | Pakages go to [staging] | 7 | 0 | Rebuild | Complete |
| Rebuild packages signed by 4B1DE545A801D4549BFD3FEF90CB3D62C13D4796 | 2022-04-08 | David Runge | As described in https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/issues/148 we are about to retire the main signing key AB19265E5D7D20687D303246BA1DFB64FFF979E7. For this to happen we need to rebuild all packages currently signed by packager keys which will be invalidated by that action. All package rebuilds go straight to the stable repositories. WARNING: No packager key addressed in this or any of the other rebuilds can be used for the rebuild! Affected packagers are hereby asked to refrain from using their packager key and create a new one instead: https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/wikis/workflows/add-a-new-packager-key | 18 | 0 | Rebuild | Complete |
| Rebuild packages signed by 48C3B1F30DDD0FE67E516D16396E3E25BAB142C1 | 2022-04-08 | David Runge | As described in https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/issues/148 we are about to retire the main signing key AB19265E5D7D20687D303246BA1DFB64FFF979E7. For this to happen we need to rebuild all packages currently signed by packager keys which will be invalidated by that action. All package rebuilds go straight to the stable repositories. WARNING: No packager key addressed in this or any of the other rebuilds can be used for the rebuild! Affected packagers are hereby asked to refrain from using their packager key and create a new one instead: https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/wikis/workflows/add-a-new-packager-key | 47 | 0 | Rebuild | Complete |
| Rebuild packages signed by CE0BDE71A759A87F23F0F7D8B61DBCE10901C163 | 2022-04-08 | David Runge | As described in https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/issues/148 we are about to retire the main signing key AB19265E5D7D20687D303246BA1DFB64FFF979E7. For this to happen we need to rebuild all packages currently signed by packager keys which will be invalidated by that action. All package rebuilds go straight to the stable repositories. WARNING: No packager key addressed in this or any of the other rebuilds can be used for the rebuild! Affected packagers are hereby asked to refrain from using their packager key and create a new one instead: https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/wikis/workflows/add-a-new-packager-key | 92 | 0 | Rebuild | Complete |
| Rebuild packages signed by 69DA34D78FE0EFD596AC6D049D893EC4DAAF9129 | 2022-04-08 | David Runge | As described in https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/issues/148 we are about to retire the main signing key AB19265E5D7D20687D303246BA1DFB64FFF979E7. For this to happen we need to rebuild all packages currently signed by packager keys which will be invalidated by that action. All package rebuilds go straight to the stable repositories. WARNING: No packager key addressed in this or any of the other rebuilds can be used for the rebuild! Affected packagers are hereby asked to refrain from using their packager key and create a new one instead: https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/wikis/workflows/add-a-new-packager-key EDIT: Withdrawed, see corresponding ticket. | 0 | 0 | Rebuild | Complete |
| Rebuild packages signed by 962855F072C7A01846405864FCF3C8CB5CF9C8D4 | 2022-04-08 | David Runge | As described in https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/issues/148 we are about to retire the main signing key AB19265E5D7D20687D303246BA1DFB64FFF979E7. For this to happen we need to rebuild all packages currently signed by packager keys which will be invalidated by that action. All package rebuilds go straight to the stable repositories. WARNING: No packager key addressed in this or any of the other rebuilds can be used for the rebuild! Affected packagers are hereby asked to refrain from using their packager key and create a new one instead: https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/wikis/workflows/add-a-new-packager-key | 123 | 0 | Rebuild | Complete |
| pdal 2.4 rebuild | 2022-04-02 | Sven-Hendrik Haase | Rebuild goes to staging | 7 | 0 | Rebuild | Complete |
| Electron 18 | 2022-04-02 | Nicola Squartini | Update packages to depend on explicit electron version, e.g. electron17. | 4 | 0 | Rebuild | Complete |
| CuDNN 8.3.3.40 rebuild | 2022-03-23 | Konstantin Gizdov | Rebuild CuDNN dependent packages. | 5 | 0 | Rebuild | Complete |
| Rebuild packages signed by C521846436D75A3294795B27B4360204B250F0D3 | 2022-02-24 | David Runge | The new packager key with the ID CAA1D2323A05219AA2F01AA4E642299183ED727E has been added to archlinux-keyring [1]. All packages still signed by the previous key (C521846436D75A3294795B27B4360204B250F0D3) need to be rebuilt, so that signatures on it can be revoked. Rebuilds go straight to the stable repositories. [1] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/issues/114 | 39 | 0 | Rebuild | Complete |