Bug#945840: /usr/bin/ledger: error while loading shared libraries: libboost_python27.so.1.67.0: cannot open shared object file: No such file or directory
Il 05/12/19 22:37, Dimitri John Ledkov ha scritto: > All python2 bugs for leaf packages have been made RC on like 30th of > november, causing a tonne of packages to be scheduled for autoremoval. > Most of them are on 18th/19th December. See tracker.d.o for various > leaf packages. That's only from testing. I still believe that unstable should not be broken if it can be avoided at nearly zero cost. However, I see your point now. I think disabling Python 2 should have been handled differently (i.e., not disabling it in Boost before all the rev deps in unstable wouldn't use it any more), but let's call it a day and avoid uselessly escalating this. I will not re-enable Python 2 in boost1.67. Thanks for working on this anyway. Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#945840: /usr/bin/ledger: error while loading shared libraries: libboost_python27.so.1.67.0: cannot open shared object file: No such file or directory
On Thu, 5 Dec 2019 at 21:33, Giovanni Mascellani wrote: > > Il 05/12/19 22:15, Dimitri John Ledkov ha scritto:>> Also, I hope to > finish working on 1.71 as soon as possible, so that we > >> can start that migration. > > > > But 1.71 for sure will not have python2 bindings enabled. Thus > > re-enabling python2 in boost is a stopgap until December 18th when > > those reverse-deps will be removed from testing anyway. > > Wait, where does this date (December 18th) come from? Will all Python 2 > packages get deleted on that date? Is this documented anywhere? > > If it is already decided that Python 2 is going away very soon anyway (I > didn't know this and I cannot find it written anywhere), then I agree > there is no reason to re-enable Python 2. All python2 bugs for leaf packages have been made RC on like 30th of november, causing a tonne of packages to be scheduled for autoremoval. Most of them are on 18th/19th December. See tracker.d.o for various leaf packages. And mirage itself, has already been removed from testing, has no reverse deps, and is ready to be removed from unstable too. Not quite sure why it hasn't already been removed from unstable. -- Regards, Dimitri.
Bug#945840: /usr/bin/ledger: error while loading shared libraries: libboost_python27.so.1.67.0: cannot open shared object file: No such file or directory
On Thu, 5 Dec 2019 at 21:15, Joachim Reichel wrote: > > Hi, > > it seems to me that other packages are also affected: > > - k3d FTBFS (bug #946225) > - yade FTBFS (apparently fixed in experimental, see bug #938859) > > Even though these packages needs to be fixed, it might be a good idea not to > break them right way and make e.g. the cgal_5.0 transition more difficult than > necessary. cgal transition is not made hard at all. Yade is scheduled for autoremoval and so is pprepair. pygalmesh is the last one that FTBFS during binNMU and I don't see any actions on it -> I guess an RC bug is needed against it, to cause autoremoval, and then cgal_5.0 transition will migrate. Based on https://release.debian.org/transitions/html/cgal_5.0.html with filter on bad, ignoring packages not in testing. -- Regards, Dimitri.
Bug#945840: /usr/bin/ledger: error while loading shared libraries: libboost_python27.so.1.67.0: cannot open shared object file: No such file or directory
Il 05/12/19 22:15, Dimitri John Ledkov ha scritto:>> Also, I hope to finish working on 1.71 as soon as possible, so that we >> can start that migration. > > But 1.71 for sure will not have python2 bindings enabled. Thus > re-enabling python2 in boost is a stopgap until December 18th when > those reverse-deps will be removed from testing anyway. Wait, where does this date (December 18th) come from? Will all Python 2 packages get deleted on that date? Is this documented anywhere? If it is already decided that Python 2 is going away very soon anyway (I didn't know this and I cannot find it written anywhere), then I agree there is no reason to re-enable Python 2. Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#945840: /usr/bin/ledger: error while loading shared libraries: libboost_python27.so.1.67.0: cannot open shared object file: No such file or directory
On Thu, 5 Dec 2019 at 21:15, Joachim Reichel wrote: > > Hi, > > it seems to me that other packages are also affected: > > - k3d FTBFS (bug #946225) > - yade FTBFS (apparently fixed in experimental, see bug #938859) > > Even though these packages needs to be fixed, it might be a good idea not to > break them right way and make e.g. the cgal_5.0 transition more difficult than > necessary. Please do not conflate different issues. FTBFS is most likely caused by the change in -dev package soname symlinks with historic deprecated ones removed, and only cross-distro/os/upstream ones remaining. I.e. one must link explicitly against boost_pythonXY from now on. -- Regards, Dimitri.
Bug#945840: /usr/bin/ledger: error while loading shared libraries: libboost_python27.so.1.67.0: cannot open shared object file: No such file or directory
On Thu, 5 Dec 2019 at 20:57, Giovanni Mascellani wrote: > > Hi, > > Il 05/12/19 17:55, Dimitri John Ledkov ha scritto: > > In principal I agree, in practice the only broken app today is ledger, > > which should have by now uploaded without a python bridge enabled; or > > build with python3 bridge as now available from upstream master (ported > > by me after this issue was filed / escalated). > > Thanks for working on ledger, but it is not the only affected > application. At least mirage is affected too. Are you sure there are not > others? How? > mirage is RC buggy, not in testing, and should also be removed from unstable too. Are you seriously suggesting to keep RC buggy app working in unstable for extra couple of weeks? It's to be slaughtered with the rest of python2 apps and modules from unstable. The only way to keep mirage available is to port it to python3 and python3-gir. > > And no, unstable is not supported and frequently has uninstallable > > packages, multiple known regressions, RC bugs, and automated autopkgtest > > regressions. One should only dist-upgrade unstable packages they use, if > > they are ok with the RC bugs and autopkgtest regressions automatically > > identified in the builds anyway. Thus no, I will not be making > > incremental uploads, to temporarily unbreak unstable users, using hacks > > which are not the way we intend to ship in testing later as that is > > added churn and drag on the development (ie. port/rebuild ledger in this > > case). > > I don't agree. I ordinarily use unstable and usually everything runs > fine. There are breakages every now and then, and I know that if > unstable breaks I keep the pieces. But this does not mean that one > should do that on purpose. There can be situations in which this is > unavoidable, but clearly this is not one of those: there is not harm in > keeping Python 2 enabled as long as users are still using it. > Huh, no. The whole purpose of python2 removal is to remove all python2 apps and modules from unstable. They will not continue to work. We will only ship python2.7 itself for one more stable cycle, without any apps or modules, and then it too will be removed from unstable. > Therefore I will upload a new version of boost1.67 temporarily reverting > your patch. By the way, I don't think that boost1.67 will go in bullseye > anyway: I hope to get rid of it well before that. So the point here is > not getting the package in shape for the release; it is just avoid > making the life of unstable's users unnecessarily complicated. > Go for it, it is not uncommon for us to ship multiple boost releases. And e.g. boost1.62 is still in unstable, but I did file removal bug for it. Also why does one need to upload boost1.67 to unstable, if the one from testing still works with ledger/mirage/etc? > Also, I hope to finish working on 1.71 as soon as possible, so that we > can start that migration. But 1.71 for sure will not have python2 bindings enabled. Thus re-enabling python2 in boost is a stopgap until December 18th when those reverse-deps will be removed from testing anyway. -- Regards, Dimitri.
Bug#945840: /usr/bin/ledger: error while loading shared libraries: libboost_python27.so.1.67.0: cannot open shared object file: No such file or directory
Hi, it seems to me that other packages are also affected: - k3d FTBFS (bug #946225) - yade FTBFS (apparently fixed in experimental, see bug #938859) Even though these packages needs to be fixed, it might be a good idea not to break them right way and make e.g. the cgal_5.0 transition more difficult than necessary. Joachim
Bug#945840: /usr/bin/ledger: error while loading shared libraries: libboost_python27.so.1.67.0: cannot open shared object file: No such file or directory
Hi, Il 05/12/19 17:55, Dimitri John Ledkov ha scritto: > In principal I agree, in practice the only broken app today is ledger, > which should have by now uploaded without a python bridge enabled; or > build with python3 bridge as now available from upstream master (ported > by me after this issue was filed / escalated). Thanks for working on ledger, but it is not the only affected application. At least mirage is affected too. Are you sure there are not others? How? > And no, unstable is not supported and frequently has uninstallable > packages, multiple known regressions, RC bugs, and automated autopkgtest > regressions. One should only dist-upgrade unstable packages they use, if > they are ok with the RC bugs and autopkgtest regressions automatically > identified in the builds anyway. Thus no, I will not be making > incremental uploads, to temporarily unbreak unstable users, using hacks > which are not the way we intend to ship in testing later as that is > added churn and drag on the development (ie. port/rebuild ledger in this > case). I don't agree. I ordinarily use unstable and usually everything runs fine. There are breakages every now and then, and I know that if unstable breaks I keep the pieces. But this does not mean that one should do that on purpose. There can be situations in which this is unavoidable, but clearly this is not one of those: there is not harm in keeping Python 2 enabled as long as users are still using it. Therefore I will upload a new version of boost1.67 temporarily reverting your patch. By the way, I don't think that boost1.67 will go in bullseye anyway: I hope to get rid of it well before that. So the point here is not getting the package in shape for the release; it is just avoid making the life of unstable's users unnecessarily complicated. Also, I hope to finish working on 1.71 as soon as possible, so that we can start that migration. Thanks, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#945840: /usr/bin/ledger: error while loading shared libraries: libboost_python27.so.1.67.0: cannot open shared object file: No such file or directory
On Tue, 3 Dec 2019 22:03:29 +0100 Giovanni Mascellani wrote: > Hi, > > Il 01/12/19 23:33, Dimitri John Ledkov ha scritto: > > All the broken packages, are RC buggy themselves already. Anything that > > is using py2 is RC buggy. > > I'm sorry, but this does not look like the way Python maintainers asked > to deal with reverse dependencies: from [1] it is clear that you should > not remove Python 2 support if you have reverse dependencies using it. > The right way is to keep Python 2 and make the rev dep's bug affect #936227. > > [1] https://wiki.debian.org/Python/2Removal > > People are using unstable. I agree with the principle that Python 2 > applications should disappear as soon as possible, but breaking things > randomly is not going to do any good. > > Please, if you see a mistake in my reasoning explain me, otherwise I > will re-enable Python 2 support for 1.67.0 in Debian (I have no idea > about policies in Ubuntu) until reverse dependencies are clean. > > Incidentally, it seems that ledger does not have any Python 2 removal > related bug. I would file one. > In principal I agree, in practice the only broken app today is ledger, which should have by now uploaded without a python bridge enabled; or build with python3 bridge as now available from upstream master (ported by me after this issue was filed / escalated). It is unfortunate that python2 bridge is built and linked into ledger by default, even when unused. (i.e. people who don't care about python-bridge are broken) There is no class issue of any other debs. And ledger upload is pending, as discussed with ledger maintainer. Ledger needs to be fixed regardless, and is getting fixed shortly. I don't think it's worthwhile rebuilding boost with reintroduced python2 at this point. And no, unstable is not supported and frequently has uninstallable packages, multiple known regressions, RC bugs, and automated autopkgtest regressions. One should only dist-upgrade unstable packages they use, if they are ok with the RC bugs and autopkgtest regressions automatically identified in the builds anyway. Thus no, I will not be making incremental uploads, to temporarily unbreak unstable users, using hacks which are not the way we intend to ship in testing later as that is added churn and drag on the development (ie. port/rebuild ledger in this case). Regards, Dimitri.
Bug#945840: /usr/bin/ledger: error while loading shared libraries: libboost_python27.so.1.67.0: cannot open shared object file: No such file or directory
Hi, I agree with Giovanni, I think we need to re-enable python2 for a while. Regards Anton
Bug#945840: /usr/bin/ledger: error while loading shared libraries: libboost_python27.so.1.67.0: cannot open shared object file: No such file or directory
Hi, Il 01/12/19 23:33, Dimitri John Ledkov ha scritto: > All the broken packages, are RC buggy themselves already. Anything that > is using py2 is RC buggy. I'm sorry, but this does not look like the way Python maintainers asked to deal with reverse dependencies: from [1] it is clear that you should not remove Python 2 support if you have reverse dependencies using it. The right way is to keep Python 2 and make the rev dep's bug affect #936227. [1] https://wiki.debian.org/Python/2Removal People are using unstable. I agree with the principle that Python 2 applications should disappear as soon as possible, but breaking things randomly is not going to do any good. Please, if you see a mistake in my reasoning explain me, otherwise I will re-enable Python 2 support for 1.67.0 in Debian (I have no idea about policies in Ubuntu) until reverse dependencies are clean. Incidentally, it seems that ledger does not have any Python 2 removal related bug. I would file one. Thanks, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#945840: /usr/bin/ledger: error while loading shared libraries: libboost_python27.so.1.67.0: cannot open shared object file: No such file or directory
I guess I should have created a list of breaks, and uploaded with it, as indeed a soname is dropped. On Sun, 1 Dec 2019, 23:36 Dimitri John Ledkov, wrote: > No, > > All packages that use python have removal blocks already filed, and those > bugs should be marked as blocking migration of boost. > > It will take a while for boost to migrate. There are only a few > applications, a few dual py2/py3 packages, and majority already scheduled > to be removed from the archive with RC bugs. > > All the broken packages, are RC buggy themselves already. Anything that is > using py2 is RC buggy. > > And e.g. ledger, I started porting it locally. The buggy app here is ledger
Bug#945840: /usr/bin/ledger: error while loading shared libraries: libboost_python27.so.1.67.0: cannot open shared object file: No such file or directory
No, All packages that use python have removal blocks already filed, and those bugs should be marked as blocking migration of boost. It will take a while for boost to migrate. There are only a few applications, a few dual py2/py3 packages, and majority already scheduled to be removed from the archive with RC bugs. All the broken packages, are RC buggy themselves already. Anything that is using py2 is RC buggy. And e.g. ledger, I started porting it locally. The buggy app here is ledger. On Sun, 1 Dec 2019, 18:57 Giovanni Mascellani, wrote: > Hi, > > On Fri, 29 Nov 2019 16:42:58 +0100 Kiko Piris > wrote:> /usr/bin/ledger: error while loading > shared libraries: libboost_python27.so.1.67.0: cannot open shared object > file: No such file or directory > > Dimitri, it seems that removing Python 2 support for Boost 1.67 was a > bit too quick. Apparently some packages are still using it, so this is > causing breakages. Therefore I will upload a new version that re-enables > Python 2. Of course Python 2 should never be enabled from Boost 1.71 on. > > Also, could you please check that you pushed 1.67.0-15 to the git > repository? I cannot see it. > > Of course, reverse dependencies of Boost 1.67 be aware that you will > break when 1.71 will be made the default Boost version, which hopefully > will be relatively soon. > > Giovanni. > -- > Giovanni Mascellani > Postdoc researcher - Université Libre de Bruxelles > >
Bug#945840: /usr/bin/ledger: error while loading shared libraries: libboost_python27.so.1.67.0: cannot open shared object file: No such file or directory
Hi, On Fri, 29 Nov 2019 16:42:58 +0100 Kiko Piris wrote:> /usr/bin/ledger: error while loading shared libraries: libboost_python27.so.1.67.0: cannot open shared object file: No such file or directory Dimitri, it seems that removing Python 2 support for Boost 1.67 was a bit too quick. Apparently some packages are still using it, so this is causing breakages. Therefore I will upload a new version that re-enables Python 2. Of course Python 2 should never be enabled from Boost 1.71 on. Also, could you please check that you pushed 1.67.0-15 to the git repository? I cannot see it. Of course, reverse dependencies of Boost 1.67 be aware that you will break when 1.71 will be made the default Boost version, which hopefully will be relatively soon. Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#945840: /usr/bin/ledger: error while loading shared libraries: libboost_python27.so.1.67.0: cannot open shared object file: No such file or directory
affects 945840 + mirage -- Best Regards Joerg Schuetter
Bug#945840: /usr/bin/ledger: error while loading shared libraries: libboost_python27.so.1.67.0: cannot open shared object file: No such file or directory
Package: ledger Version: 3.1.2+dfsg1-1 Severity: grave Justification: renders package unusable The subject really says it all. Invoking ledger fails with the mentioned error: /usr/bin/ledger: error while loading shared libraries: libboost_python27.so.1.67.0: cannot open shared object file: No such file or directory ldd shows the missing library: $ ldd /usr/bin/ledger linux-vdso.so.1 (0x7fffa1958000) libledger.so.3 => /usr/lib/ledger/libledger.so.3 (0x7f745af4) libboost_filesystem.so.1.67.0 => /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.67.0 (0x7f745af08000) libboost_system.so.1.67.0 => /usr/lib/x86_64-linux-gnu/libboost_system.so.1.67.0 (0x7f745af01000) libpython2.7.so.1.0 => /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0 (0x7f745ab95000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7f745a9bc000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f745a9a2000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f745a7e) libmpfr.so.6 => /usr/lib/x86_64-linux-gnu/libmpfr.so.6 (0x7f745a75e000) libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x7f745a6db000) libboost_iostreams.so.1.67.0 => /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.67.0 (0x7f745a6bd000) libboost_regex.so.1.67.0 => /usr/lib/x86_64-linux-gnu/libboost_regex.so.1.67.0 (0x7f745a587000) libboost_python27.so.1.67.0 => not found libicuuc.so.63 => /usr/lib/x86_64-linux-gnu/libicuuc.so.63 (0x7f745a3b5000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f745a27) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f745a24f000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f745a232000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f745a22d000) libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7f745a228000) /lib64/ld-linux-x86-64.so.2 (0x7f745b54) libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x7f745a213000) libicui18n.so.63 => /usr/lib/x86_64-linux-gnu/libicui18n.so.63 (0x7f7459f38000) libicudata.so.63 => /usr/lib/x86_64-linux-gnu/libicudata.so.63 (0x7f7458547000) Please, reassign the bug to whatever package it belongs (if it’s not ledger). Thanks. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_USER Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages ledger depends on: ii libboost-filesystem1.67.0 1.67.0-15 ii libboost-iostreams1.67.0 1.67.0-15 ii libboost-python1.67.0 1.67.0-15 ii libboost-regex1.67.0 1.67.0-15 ii libboost-system1.67.0 1.67.0-15 ii libc6 2.29-3 ii libgcc11:9.2.1-20 ii libgmp10 2:6.1.2+dfsg-4 ii libicu63 63.2-2 ii libmpfr6 4.0.2-1 ii libpython2.7 2.7.17-1 ii libstdc++6 9.2.1-20 ledger recommends no packages. Versions of packages ledger suggests: pn elpa-ledger pn python-ledger -- no debconf information
