Fixed in upstream release 1.4.5. Now we only need to wait for it to sync :)
** Description changed: [Impact] If the last alternative(s) of an Or group is ignored, because it does not match an architecture list, we would end up keeping the or flag, effectively making the next AND an OR. For example, when parsing (on amd64): debhelper (>= 9), libnacl-dev [amd64] | libnacl-dev [i386] => debhelper (>= 9), libnacl-dev | Which can cause python-apt to crash. Even worse: debhelper (>= 9), libnacl-dev [amd64] | libnacl-dev [i386], foobar => debhelper (>= 9), libnacl-dev [amd64] | foobar [Test case] - TODO + On amd64: + + cat > segv.dsc << EOF + Format: 3.0 (native) + Source: foobar + Binary: foobar + Architecture: all + Version: 1 + Maintainer: Joe Sixpack <j...@example.org> + Build-Depends: build-essential [amd64] | build-essential [fancy] + Standards-Version: 3.9.8 + EOF + cat > failure.dsc << EOF + Format: 3.0 (native) + Source: foobar + Binary: foobar + Architecture: all + Version: 1 + Maintainer: Joe Sixpack <j...@example.org> + Build-Depends: build-essential [amd64] | build-essential [fancy], a-non-existing-package + Standards-Version: 3.9.8 + EOF + + + (1) apt-get build-dep -s ./segv.dsc should succeed instead of crash + (2) apt-get build-dep -s ./failure.dsc should complain about "Depends: a-non-existing-package but it is not installable" instead of succeeding. [Regression Potential] apt-get build-dep and friends can now fail where they succeeded previously for packages that employ architecture-limited alternatives in their build depends, as in the second example given above, because now additional packages need to be installed (which is correct, though). [Other info] By setting the previous alternatives Or flag to the current Or flag if the current alternative is ignored, we solve the issue. ** Description changed: [Impact] If the last alternative(s) of an Or group is ignored, because it does not match an architecture list, we would end up keeping the or flag, effectively making the next AND an OR. For example, when parsing (on amd64): debhelper (>= 9), libnacl-dev [amd64] | libnacl-dev [i386] => debhelper (>= 9), libnacl-dev | Which can cause python-apt to crash. Even worse: debhelper (>= 9), libnacl-dev [amd64] | libnacl-dev [i386], foobar => debhelper (>= 9), libnacl-dev [amd64] | foobar [Test case] On amd64: cat > segv.dsc << EOF Format: 3.0 (native) Source: foobar Binary: foobar Architecture: all Version: 1 Maintainer: Joe Sixpack <j...@example.org> Build-Depends: build-essential [amd64] | build-essential [fancy] Standards-Version: 3.9.8 EOF cat > failure.dsc << EOF Format: 3.0 (native) Source: foobar Binary: foobar Architecture: all Version: 1 Maintainer: Joe Sixpack <j...@example.org> Build-Depends: build-essential [amd64] | build-essential [fancy], a-non-existing-package Standards-Version: 3.9.8 EOF - (1) apt-get build-dep -s ./segv.dsc should succeed instead of crash (2) apt-get build-dep -s ./failure.dsc should complain about "Depends: a-non-existing-package but it is not installable" instead of succeeding. + + This is the same test as run by CI and autopkgtests, so if they pass the + tests passed. You can also run apt-get build-dep -s dq for a real life + example that should not segfault. [Regression Potential] apt-get build-dep and friends can now fail where they succeeded previously for packages that employ architecture-limited alternatives in their build depends, as in the second example given above, because now additional packages need to be installed (which is correct, though). [Other info] By setting the previous alternatives Or flag to the current Or flag if the current alternative is ignored, we solve the issue. ** Description changed: [Impact] If the last alternative(s) of an Or group is ignored, because it does not match an architecture list, we would end up keeping the or flag, effectively making the next AND an OR. For example, when parsing (on amd64): debhelper (>= 9), libnacl-dev [amd64] | libnacl-dev [i386] => debhelper (>= 9), libnacl-dev | - Which can cause python-apt to crash. + Which can cause python-apt and apt-get build-dep to crash. Even worse: debhelper (>= 9), libnacl-dev [amd64] | libnacl-dev [i386], foobar => debhelper (>= 9), libnacl-dev [amd64] | foobar [Test case] On amd64: cat > segv.dsc << EOF Format: 3.0 (native) Source: foobar Binary: foobar Architecture: all Version: 1 Maintainer: Joe Sixpack <j...@example.org> Build-Depends: build-essential [amd64] | build-essential [fancy] Standards-Version: 3.9.8 EOF cat > failure.dsc << EOF Format: 3.0 (native) Source: foobar Binary: foobar Architecture: all Version: 1 Maintainer: Joe Sixpack <j...@example.org> Build-Depends: build-essential [amd64] | build-essential [fancy], a-non-existing-package Standards-Version: 3.9.8 EOF (1) apt-get build-dep -s ./segv.dsc should succeed instead of crash (2) apt-get build-dep -s ./failure.dsc should complain about "Depends: a-non-existing-package but it is not installable" instead of succeeding. This is the same test as run by CI and autopkgtests, so if they pass the tests passed. You can also run apt-get build-dep -s dq for a real life example that should not segfault. [Regression Potential] apt-get build-dep and friends can now fail where they succeeded previously for packages that employ architecture-limited alternatives in their build depends, as in the second example given above, because now additional packages need to be installed (which is correct, though). [Other info] By setting the previous alternatives Or flag to the current Or flag if the current alternative is ignored, we solve the issue. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1694697 Title: build-depends keeps OR flag if end of or group is ignored To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1694697/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
