[Bug 1811296] Re: libc++ files version mismatch
Not sure about older released, but it's actually broken again already— currently in Sid, the versions of gcc-arm-none-eabi and libstdc++-arm- none-eabi are both 15:8-2019-q3-1: https://packages.debian.org/sid/devel/gcc-arm-none-eabi https://packages.debian.org/sid/devel/libstdc++-arm-none-eabi-newlib However in Focal, we now have gcc-arm-none-eabi bumped ahead to 15:9-2019-q4-0ubuntu1, per: http://changelogs.ubuntu.com/changelogs/pool/universe/g/gcc-arm-none- eabi/gcc-arm-none-eabi_9-2019-q4-0ubuntu1/changelog But libstdc++-arm-none-eabi-newlib is still lagging at 15:8-2019-q3-1. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1811296 Title: libc++ files version mismatch To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gcc-arm-none-eabi/+bug/1811296/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1865209] Re: Boost 1.71 missing python3/numpy3 symlinks
Upstream has now merged the change to support python3 as a component. This will release in Boost 1.73, but it's a small patch and should be possible to backport to 1.71: https://github.com/boostorg/boost_install/commit/7d2b3bf3a25ecce33e256370e47d776d75685f7e -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1865209 Title: Boost 1.71 missing python3/numpy3 symlinks To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/boost1.71/+bug/1865209/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1865209] Re: Boost 1.71 missing python3/numpy3 symlinks
** Description changed:
As of Boost 1.71, the exact version of python is coded into the library
name:
$ ls -1 /usr/lib/x86_64-linux-gnu/libboost_*py*.so
/usr/lib/x86_64-linux-gnu/libboost_numpy38.so
/usr/lib/x86_64-linux-gnu/libboost_python38.so
This is pretty inconvenient compared to previous releases where there
were generic symlinks, for example on Bionic with Boost 1.65:
$ ls -1 /usr/lib/x86_64-linux-gnu/libboost_*py*.so
/usr/lib/x86_64-linux-gnu/libboost_mpi_python3-py36.so
/usr/lib/x86_64-linux-gnu/libboost_mpi_python3.so
/usr/lib/x86_64-linux-gnu/libboost_mpi_python-py27.so
/usr/lib/x86_64-linux-gnu/libboost_mpi_python-py36.so
/usr/lib/x86_64-linux-gnu/libboost_mpi_python.so
/usr/lib/x86_64-linux-gnu/libboost_numpy3-py36.so
/usr/lib/x86_64-linux-gnu/libboost_numpy3.so
/usr/lib/x86_64-linux-gnu/libboost_numpy-py27.so
/usr/lib/x86_64-linux-gnu/libboost_numpy.so
/usr/lib/x86_64-linux-gnu/libboost_python3-py36.so
/usr/lib/x86_64-linux-gnu/libboost_python3.so
/usr/lib/x86_64-linux-gnu/libboost_python-py27.so
/usr/lib/x86_64-linux-gnu/libboost_python-py36.so
/usr/lib/x86_64-linux-gnu/libboost_python.so
So that you could just -lboost_python3 (or numpy3) and it would do the
right thing for the system's default versions.
Are there plans to fix this before release? I would expect that a lot of
software would have been relying on the previous behaviour, especially
CMake-using packages which were previously able to just:
find_package(Boost COMPONENTS python3)
But will now need to:
find_package(PythonInterp REQUIRED)
find_package(Boost COMPONENTS
python${PYTHON_VERSION_MAJOR}${PYTHON_VERSION_MINOR})
And the above logic doesn't even work with the naming scheme used with
Bionic, so the situation is even worse if you're trying to support
multiple Ubuntu LTSes from the same codebase!
+
+ Ticket/discussion about this with upstream:
+ https://github.com/boostorg/boost_install/issues/31
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865209
Title:
Boost 1.71 missing python3/numpy3 symlinks
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/boost1.71/+bug/1865209/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1865225] Re: Eigen 3.3.7 headers throw deprecated-copy warnings in GCC9
I'll give that a try, but my concern was basically that they wouldn't care because for them the problem only exists in unstable and will be resolved in a few months when Eigen 3.4 comes out. For Ubuntu, the problem is more urgent because an LTS commitment is about to happen. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1865225 Title: Eigen 3.3.7 headers throw deprecated-copy warnings in GCC9 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/eigen3/+bug/1865225/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1865225] [NEW] Eigen 3.3.7 headers throw deprecated-copy warnings in GCC9
Public bug reported: Under Ubuntu Focal / GCC9, packages which use the Eigen3 headers from the current newest version (released Dec 2018) will get compiler warnings which must be silenced or they may interfere with the use of the -Werror flag, for example. Upstream had patched this issue on their master branch (targeting Eigen 3.4), and was gracious enough to cherry-pick the changes over to their 3.3 support branch, see: https://gitlab.com/libeigen/eigen/-/merge_requests/29 https://gitlab.com/libeigen/eigen/-/commits/3.3 Thanks very much to Christoph Hertzberg for the quick turnaround on that. I have in turn imported these patches as-is to the current 3.3.7 package and released it to PPA here: https://launchpad.net/~mikepurvis/+archive/ubuntu/eigen/ When it's done building and published, I'll be installing it in order to confirm that it resolves the issues building my software that depends on Eigen. I'm hopeful that it would be possible to get this released as the version of eigen3 in Focal. ** Affects: eigen3 (Ubuntu) Importance: Undecided Status: New ** Description changed: - Under Ubuntu Focal, packages which use the Eigen3 headers from the - current newest version (released Dec 2018) will get compiler warnings - which must be silenced or they may interfere with the use of the -Werror - flag, for example. + Under Ubuntu Focal / GCC9, packages which use the Eigen3 headers from + the current newest version (released Dec 2018) will get compiler + warnings which must be silenced or they may interfere with the use of + the -Werror flag, for example. Upstream had patched this issue on their master branch (targeting Eigen - 3.4), and was gracious enough to patch the changes over to their 3.3 - support branch, see: + 3.4), and was gracious enough to cherry-pick the changes over to their + 3.3 support branch, see: https://gitlab.com/libeigen/eigen/-/merge_requests/29 https://gitlab.com/libeigen/eigen/-/commits/3.3 Thanks very much to Christoph Hertzberg for the quick turnaround on that. I have in turn imported these patches as-is to the current 3.3.7 package and released it to PPA here: https://launchpad.net/~mikepurvis/+archive/ubuntu/eigen/ When it's done building and published, I'll be installing it in order to confirm that it resolves the issues building my software that depends on Eigen. I'm hopeful that it would be possible to get this released as the version of eigen3 in Focal. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1865225 Title: Eigen 3.3.7 headers throw deprecated-copy warnings in GCC9 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/eigen3/+bug/1865225/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1865209] Re: Boost 1.71 missing python3/numpy3 symlinks
Having looked into this a bit further, it appears the new hotness is that this is actually being handled in the Boost-shipped CMake module: /usr/lib/x86_64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake >From my read of that, the expectation *now* is that you just do: find_package(Boost COMPONENTS python) And it does the right thing. But of course this approach breaks any package which was intentionally using "python3" in previous releases, or building libraries for both Python 2 and 3. In summary, these are how to link to boost_python over the past four years: 1. find_package(Boost COMPONENTS python) 2. find_package(Boost COMPONENTS python-pyXY) 3. find_package(Boost COMPONENTS pythonX) 4. find_package(Boost COMPONENTS pythonX-pyXY) 5. find_package(Boost COMPONENTS pythonXY) Xenial was 1 and 2. Bionic was 1, 2, 3, and 4. Focal is now 1 and 5, but 1 is now Python 3 instead of 2. This is insane. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1865209 Title: Boost 1.71 missing python3/numpy3 symlinks To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/boost1.71/+bug/1865209/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1865209] [NEW] Boost 1.71 missing python3/numpy3 symlinks
Public bug reported:
As of Boost 1.71, the exact version of python is coded into the library
name:
$ ls -1 /usr/lib/x86_64-linux-gnu/libboost_*py*.so
/usr/lib/x86_64-linux-gnu/libboost_numpy38.so
/usr/lib/x86_64-linux-gnu/libboost_python38.so
This is pretty inconvenient compared to previous releases where there
were generic symlinks, for example on Bionic with Boost 1.65:
$ ls -1 /usr/lib/x86_64-linux-gnu/libboost_*py*.so
/usr/lib/x86_64-linux-gnu/libboost_mpi_python3-py36.so
/usr/lib/x86_64-linux-gnu/libboost_mpi_python3.so
/usr/lib/x86_64-linux-gnu/libboost_mpi_python-py27.so
/usr/lib/x86_64-linux-gnu/libboost_mpi_python-py36.so
/usr/lib/x86_64-linux-gnu/libboost_mpi_python.so
/usr/lib/x86_64-linux-gnu/libboost_numpy3-py36.so
/usr/lib/x86_64-linux-gnu/libboost_numpy3.so
/usr/lib/x86_64-linux-gnu/libboost_numpy-py27.so
/usr/lib/x86_64-linux-gnu/libboost_numpy.so
/usr/lib/x86_64-linux-gnu/libboost_python3-py36.so
/usr/lib/x86_64-linux-gnu/libboost_python3.so
/usr/lib/x86_64-linux-gnu/libboost_python-py27.so
/usr/lib/x86_64-linux-gnu/libboost_python-py36.so
/usr/lib/x86_64-linux-gnu/libboost_python.so
So that you could just -lboost_python3 (or numpy3) and it would do the
right thing for the system's default versions.
Are there plans to fix this before release? I would expect that a lot of
software would have been relying on the previous behaviour, especially
CMake-using packages which were previously able to just:
find_package(Boost COMPONENTS python3)
But will now need to:
find_package(PythonInterp REQUIRED)
find_package(Boost COMPONENTS
python${PYTHON_VERSION_MAJOR}${PYTHON_VERSION_MINOR})
And the above logic doesn't even work with the naming scheme used with
Bionic, so the situation is even worse if you're trying to support
multiple Ubuntu LTSes from the same codebase!
** Affects: boost1.71 (Ubuntu)
Importance: Undecided
Status: New
** Description changed:
As of Boost 1.71, the exact version of python is coded into the library
name:
- $ ls -1 /usr/lib/x86_64-linux-gnu/libboost_*py*.so
- /usr/lib/x86_64-linux-gnu/libboost_numpy38.so
- /usr/lib/x86_64-linux-gnu/libboost_python38.so
+ $ ls -1 /usr/lib/x86_64-linux-gnu/libboost_*py*.so
+ /usr/lib/x86_64-linux-gnu/libboost_numpy38.so
+ /usr/lib/x86_64-linux-gnu/libboost_python38.so
This is pretty inconvenient compared to previous releases where there
were generic symlinks, for example on Bionic with Boost 1.65:
- $ ls -1 /usr/lib/x86_64-linux-gnu/libboost_*py*.so
- /usr/lib/x86_64-linux-gnu/libboost_mpi_python3-py36.so
- /usr/lib/x86_64-linux-gnu/libboost_mpi_python3.so
- /usr/lib/x86_64-linux-gnu/libboost_mpi_python-py27.so
- /usr/lib/x86_64-linux-gnu/libboost_mpi_python-py36.so
- /usr/lib/x86_64-linux-gnu/libboost_mpi_python.so
- /usr/lib/x86_64-linux-gnu/libboost_numpy3-py36.so
- /usr/lib/x86_64-linux-gnu/libboost_numpy3.so
- /usr/lib/x86_64-linux-gnu/libboost_numpy-py27.so
- /usr/lib/x86_64-linux-gnu/libboost_numpy.so
- /usr/lib/x86_64-linux-gnu/libboost_python3-py36.so
- /usr/lib/x86_64-linux-gnu/libboost_python3.so
- /usr/lib/x86_64-linux-gnu/libboost_python-py27.so
- /usr/lib/x86_64-linux-gnu/libboost_python-py36.so
- /usr/lib/x86_64-linux-gnu/libboost_python.so
+ $ ls -1 /usr/lib/x86_64-linux-gnu/libboost_*py*.so
+ /usr/lib/x86_64-linux-gnu/libboost_mpi_python3-py36.so
+ /usr/lib/x86_64-linux-gnu/libboost_mpi_python3.so
+ /usr/lib/x86_64-linux-gnu/libboost_mpi_python-py27.so
+ /usr/lib/x86_64-linux-gnu/libboost_mpi_python-py36.so
+ /usr/lib/x86_64-linux-gnu/libboost_mpi_python.so
+ /usr/lib/x86_64-linux-gnu/libboost_numpy3-py36.so
+ /usr/lib/x86_64-linux-gnu/libboost_numpy3.so
+ /usr/lib/x86_64-linux-gnu/libboost_numpy-py27.so
+ /usr/lib/x86_64-linux-gnu/libboost_numpy.so
+ /usr/lib/x86_64-linux-gnu/libboost_python3-py36.so
+ /usr/lib/x86_64-linux-gnu/libboost_python3.so
+ /usr/lib/x86_64-linux-gnu/libboost_python-py27.so
+ /usr/lib/x86_64-linux-gnu/libboost_python-py36.so
+ /usr/lib/x86_64-linux-gnu/libboost_python.so
So that you could just -lboost_python3 (or numpy3) and it would do the
right thing for the system's default versions.
Are there plans to fix this before release? I would expect that a lot of
software would have been relying on the previous behaviour, especially
CMake-using packages which were previously able to just:
- find_package(Boost COMPONENTS python3)
+ find_package(Boost COMPONENTS python3)
But will now need to:
- find_package(PythonInterp REQUIRED)
- find_package(Boost COMPONENTS
python${PYTHON_VERSION_MAJOR}${PYTHON_VERSION_MINOR})
+ find_package(PythonInterp REQUIRED)
+ find_package(Boost COMPONENTS
python${PYTHON_VERSION_MAJOR}${PYTHON_VERSION_MINOR})
+
+ And the above logic doesn't even work with the
[Bug 1811296] Re: libc++ files version mismatch
This was working correctly on Ubuntu Focal with gcc-arm-none-eabi (15:7-2018-q2-6) and libstdc++-arm-none-eabi-newlib (15:7-2018-q2-5+12). However, now that gcc-arm-none-eabi is at 15:8-2019-q3-1, it's broken again. Hopefully the newlib package will get a rebuild prior to release which should correct the issues. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1811296 Title: libc++ files version mismatch To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gcc-arm-none-eabi/+bug/1811296/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1847347] [NEW] 1.42.13-1ubuntu1.1 breaks debootstrap in Xenial
Public bug reported: At my company we prepare system disk images which start from deboostrap pointing at an internal mirror containing packages from xenial, xenial- updates, and elsewhere. As of September 30, our image preparation begun failing during the initial debootstrap. We narrowed it down to this update— when we remove version 1.42.13-1ubuntu1.1 of this package from our mirror, everything works as before. Apologies that I don't have more details at this time, as we're still digging. But just wanted to get the ball rolling on a discussion here. ** Affects: e2fsprogs (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1847347 Title: 1.42.13-1ubuntu1.1 breaks debootstrap in Xenial To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1847347/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1596296] Re: CeresConfig.cmake is not installed
This is affecting me too; it is a major packaging oversight to have excluded this file. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1596296 Title: CeresConfig.cmake is not installed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ceres-solver/+bug/1596296/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1313787] Re: Multistrap is broken in 14.04
Almost two full years! In the meantime, there are PPAs for this: https://launchpad.net/~keyz182/+archive/ubuntu/multistrap-forceyes-fix -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1313787 Title: Multistrap is broken in 14.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/multistrap/+bug/1313787/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1361902] Re: 14.04 /etc/network/interfaces is always overwritten by Preseed
I tried adding d-i netcfg/target_network_config string ifupdown to my preseed file, but I'm still getting /etc/network/interfaces being overwritten by the trusty netboot installer. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1361902 Title: 14.04 /etc/network/interfaces is always overwritten by Preseed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/netcfg/+bug/1361902/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1293024] Re: package doesn't provide c++ library
Yes, please bring libstdc++-arm-none-eabi-newlib into Trusty! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1293024 Title: package doesn't provide c++ library To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gcc-arm-none-eabi/+bug/1293024/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 944271] Re: iwlwifi: Microcode SW error detected. Restarting 0x2000000
I'm seeing this crash on 14.04, running 3.13.0-23-generic. Hardware is Centrino Advanced-N 6235. Log here: https://gist.github.com/f6ce150f833b2cef3f21 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/944271 Title: iwlwifi: Microcode SW error detected. Restarting 0x200 To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/944271/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1247905] [NEW] update-grub fails in the face of overlayroot
Public bug reported:
Info on overlayroot: http://blog.dustinkirkland.com/2012/08/introducing-
overlayroot-overlayfs.html
Mount configuration for an overlayroot-configured box:
$ mount
overlayroot on / type overlayfs (rw,errors=remount-ro)
/dev/sda5 on /media/root-ro type ext3
(ro,relatime,errors=continue,user_xattr,acl,barrier=1,data=ordered)
/dev/sda6 on /media/root-rw type ext3
(rw,relatime,errors=continue,user_xattr,acl,barrier=1,data=ordered)
/dev/sda1 on /boot type ext3 (rw)
When attempting to update-grub:
$ sudo update-grub
[sudo] password for administrator:
/usr/sbin/grub-probe: error: cannot find a device for / (is /dev mounted?).
The issue comes about in this line of the /usr/sbin/grub-mkconfig
script:
GRUB_DEVICE=`${grub_probe} --target=device /`
In the short term, I'm hacking that script to pass in a value for
GRUB_DEVICE, but the ideal would be to have the grub-probe binary detect
when an overlayfs is / and return the device which is the bottom of the
overlay.
** Affects: grub2 (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1247905
Title:
update-grub fails in the face of overlayroot
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1247905/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
