(Dropping the CCs, also use X-Debbugs-Cc otherwise the thread splits in two)
On Mon, Nov 25, 2024 at 06:59:49PM -0800, Otto Kekäläinen wrote: > Source: python-apt > Version: 2.9.1 > Severity: serious > > Seems the latest version of python-apt has some serious regressions as > https://tracker.debian.org/pkg/python-apt shows wide-spread > autopkgtest failures. > > In a clean Debian unstable container a simple installation is failing with: > > Hit:1 http://deb.debian.org/debian sid InRelease > Get:2 http://deb.debian.org/debian sid/main all Contents (deb) [43.5 MB] > Get:3 http://deb.debian.org/debian sid/main amd64 Contents (deb) [15.8 MB] > Traceback (most recent call last): > File "/usr/lib/cnf-update-db", line 3, in <module> > import apt_pkg > ImportError: > /usr/lib/python3/dist-packages/apt_pkg.cpython-312-x86_64-linux-gnu.so: > undefined symbol: > _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceEmmPKcm, > version APTPKG_6.0 This is highly awkward, that is a C++ standard library symbol: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_replace(unsigned long, unsigned long, char const*, unsigned long) It's in a template, and we build all inline functions with hidden visibility in APT; so it's in a sense expected, but also unexpected, as everything that uses the function keeps its own copy of it. But I suppose this is an issue because other versions don't have the versioning tag and the linker accidentally picked a symbol that I don't know, doesn't really exist? I don't know how this happens. > Fetched 59.3 MB in 13s (4620 kB/s) > Reading package lists... > E: Problem executing scripts APT::Update::Post-Invoke-Success 'if > /usr/bin/test -w /var/lib/command-not-found/ -a -e > /usr/lib/cnf-update-db; then /usr/lib/cnf-update-db > /dev/null; fi' > E: Sub-process returned an error code > Error: error building at STEP "RUN apt-get install -q --yes > command-not-found && apt-get update -q": error while running > runtime: exit status 100 > > Please take a look what is going on. > > > > > > > Please also consider using better CI before uploads. So the tests run at build-time and I also ran a full build and installed test suite run in autopkgtest, and they of course all import that module, so I don't know how we can get into that spot, but I can reproduce it. Clean container (your example is from a system with command-not-found), install python3-apt, and then root@fecbc40d24e5:/# python3 -c "import apt_pkg" Traceback (most recent call last): File "<string>", line 1, in <module> ImportError: /usr/lib/python3/dist-packages/apt_pkg.cpython-312-x86_64-linux-gnu.so: undefined symbol: _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceEmmPKcm, version APTPKG_6.0 > > I don't know if the root cause of these are the same, but a simple > Salsa CI test run at > https://salsa.debian.org/otto/python-apt/-/pipelines/769109 errors on: > > dpkg-buildpackage: info: source package python-apt > dpkg-buildpackage: info: source version 2.9.1+salsaci+20241126+1 > dpkg-buildpackage: info: source distribution unstable > dpkg-buildpackage: info: source changed by Julian Andres Klode > <j...@debian.org> > dpkg-source --before-build . > dpkg-buildpackage: info: host architecture amd64 > debian/rules clean > dh clean --with python3,sphinxdoc --buildsystem=pybuild > dh_auto_clean -O--buildsystem=pybuild > I: pybuild base:311: python3.13 setup.py clean > Traceback (most recent call last): > File "/builds/otto/python-apt/debian/output/source_dir/setup.py", > line 141, in <module> > setup( > ~~~~~^ > name="python-apt", > ^^^^^^^^^^^^^^^^^^ > ...<15 lines>... > platforms="posix", > ^^^^^^^^^^^^^^^^^^ > ) > ^ > File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line > 117, in setup > return distutils.core.setup(**attrs) > ~~~~~~~~~~~~~~~~~~~~^^^^^^^^^ > File "/usr/lib/python3/dist-packages/setuptools/_distutils/core.py", > line 145, in setup > _setup_distribution = dist = klass(attrs) > ~~~~~^^^^^^^ > File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 333, > in __init__ > self.metadata.version = self._normalize_version(self.metadata.version) > ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^ > File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 369, > in _normalize_version > normalized = str(Version(version)) > ~~~~~~~^^^^^^^^^ > File "/usr/lib/python3/dist-packages/packaging/version.py", line > 202, in __init__ > raise InvalidVersion(f"Invalid version: {version!r}") > packaging.version.InvalidVersion: Invalid version: '2.9.1+salsaci+20241126+1' > E: pybuild pybuild:389: clean: plugin distutils failed with: exit > code=1: python3.13 setup.py clean > dh_auto_clean: error: pybuild --clean -i python{version} -p "3.13 > 3.12" returned exit code 13 > make: *** [debian/rules:17: clean] Error 25 > dpkg-buildpackage: error: debian/rules clean subprocess returned exit status 2 That's to be expected, yes, package versions need to conform not just to Debian's version format but also the Python one, so the version picked by salsa-ci is wrong. So I think we need some editing there to tell salsa-ci to use a version format that works. > > > If you want, I can submit a MR for you to enable Salsa CI in > apt-python. However I wanted to check first if you want help, as in my > previous submissions you have been rather dismissive to getting > assistance and bug fixes > (https://salsa.debian.org/jak/command-not-found/-/merge_requests/8, > https://salsa.debian.org/apt-team/apt/-/merge_requests/348). I am making progress on the apt merge request, but I need to put my thoughts into words. I was doing research on that yesterday. But you can see there is _a lot_ happening and it's not the hugest priority - We can improve the CI after a freeze but we can't land or remove features after it. Specifically the points to consider right now are "enable this without other gitlabs failing" and "enable it for any commit that touches debian/ or CMakeLists.txt". The command-not-found one was an absurd confusion on my side when I was rushing to fix command-not-found and didn't find an email and forgot to look at merge requests. I'd be happy to accept patches to add a debian/salsa-ci.yml for python-apt. I thought about doing it myself yesterday. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
