Patching Boost 1.71 for Focal
Hey all, I'm back with another question about patching a package for the Focal release. My concern is about Boost 1.71, which now ships its own native CMake config. Previously, FindBoost.cmake was a module supplied by cmake-data, but now the one from Boost itself takes precedence (as it should). Unfortunately, the switchover has meant a change in behaviour for code that was previously using Boost with Python 3. In Bionic, if you wanted the Boost Python 3 bindings, you did: find_package(Boost COMPONENTS python3) But now, in Focal, this is broken and you have to do one of these two: find_package(Boost COMPONENTS python38) find_package(Boost COMPONENTS python) Neither of which would have worked to get you Python 3 bindings in Bionic— the first would have just failed (the component name to use was "python3-py35", now unsupported), and the second would have got you Python 2 bindings. I took this up with the upsteam maintainer and they have patched Boost to support the python3 component, but the change won't land until Boost 1.73 is released: https://github.com/boostorg/boost_install/issues/31 I've also filed a ticket against boost1.71 on launchpad: https://bugs.launchpad.net/ubuntu/+source/boost1.71/+bug/1865209 What is the best path forward to getting Ubuntu Focal's Boost 1.71 version patched so that the python3 component continues to work into Focal? As there have already been several Ubuntu-specific patch releases (authors cc'd), it doesn't seem like it makes sense to go back to Debian with this one. Thanks for any thoughts. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
~/.profile patching issue
I've met the problem with ~/profile.d patching and want to suggest a solution. There is a lot of scripts that requires manual patching of the profile file. Some of such tools like go requires manual patching to add GOPATH, others provide scripts for this (like nvm). This is dangerous and not controllable with user or package managers. There is /etc/profile.d/ directory for whole system. But there is no such directory for user itself. I suggest to add ~/.profile.d directory into ubuntu profile skeleton in the future version. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Conditional patching in mod-wsgi
On Tuesday, April 19, 2011 06:23:28 AM James Page wrote: Help/guidance/opinion much appreciated. Debian has got the same problem since python3.2 is now the default there too. I would recommend contacting the debian mod-wsgi maintainers and asking their advice. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Patching
Am 13.01.2008 um 02:45 schrieb Bryan Quigley: I don't believe either is implemented yet: Torrents check files in pieces so if some of the pieces have not changed they won't need to be redownloaded. While this sounds good in theory, it rarely works in practice: Remove a byte from the first chunk and all other chunks will point to a different range of the remaining file, resulting in a different hash and re-download of all chunks. Am 12.01.2008 um 21:41 schrieb Evan: Cons: - The method I described can't handle updates to non-binary files (help files, icons, etc.) This would have to be integrated somehow. I can't follow you here as _any_ file can be handled as binary. Like Subversion does, for example. IMHO, a successful patch mechanism would store the complete package on both ends. Just for downloading, a server could offer a patch against an already downloaded, similar package to make the download faster/using less bandwidth. A good patching algorithm isn't trivial and could include extracting and re-assembling the package on the client side. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Patching
On 13/01/2008, Evan [EMAIL PROTECTED] wrote: Any change in this area is far too complex for a LTS, however for 8.10 we have the opportunity to be innovative and create a new patching system better than that being used by the competition: An interesting discussion of these kinds of changes can be found here: https://launchpad.net/ubuntu/+spec/succinct https://wiki.ubuntu.com/apt-sync (the summary section contains links to other patching ideas and outlines problems with taking a patch approach) https://blueprints.launchpad.net/ubuntu/+spec/apt-sync And somebody has made the delta suggestion here: https://blueprints.launchpad.net/ubuntu/+spec/apt-deltas For me (with several Ubuntu machines on the same network), the work being undertaken under this head - https://blueprints.launchpad.net/ubuntu/+spec/apt-avahi - would have a bigger impact on my bandwidth. Aaron -- FSF Associate Member: 5632 http://www.fsf.org -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Patching
I believe the best solution to these problems is the use of debtorrent ( http://debtorrent.alioth.debian.org/) Which is currently in hardy (although might not actually fully work yet). Both solutions mentioned can be implemented eventually through the use of torrents. I don't believe either is implemented yet: Torrents check files in pieces so if some of the pieces have not changed they won't need to be redownloaded. Some torrent programs are currently trying to find local network hosts first, before getting files from outside. In my opinion it makes more sense to let the protocol worry about these things then include them in apt. Thanks, Bryan On Jan 12, 2008 6:16 PM, Aaron Whitehouse [EMAIL PROTECTED] wrote: On 13/01/2008, Evan [EMAIL PROTECTED] wrote: Any change in this area is far too complex for a LTS, however for 8.10we have the opportunity to be innovative and create a new patching system better than that being used by the competition: An interesting discussion of these kinds of changes can be found here: https://launchpad.net/ubuntu/+spec/succinct https://wiki.ubuntu.com/apt-sync (the summary section contains links to other patching ideas and outlines problems with taking a patch approach) https://blueprints.launchpad.net/ubuntu/+spec/apt-sync And somebody has made the delta suggestion here: https://blueprints.launchpad.net/ubuntu/+spec/apt-deltas For me (with several Ubuntu machines on the same network), the work being undertaken under this head - https://blueprints.launchpad.net/ubuntu/+spec/apt-avahi - would have a bigger impact on my bandwidth. Aaron -- FSF Associate Member: 5632 http://www.fsf.org -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
