Skip to main content

FTBFS fixes and other patches available for your package!

Wheeze is planned to release very soon! There is still a fair amount of work to push the release out, but it does mean that a lot of fun can begin for jessie.

Over the past cycle in Ubuntu, many packages where synced from experimental, many fixes were applied and many packages were upgraded ahead of debian version strings.

If one goes to your package PTS page at:

packages.qa.debian.org/$SCRPACKAGENAME

One can find the following box titled "ubuntu" in it:


Please click on "patches for VERSION STRING" to find:
  • Useless irrelevant changes =) oh well, it happens
  • FTBFS fixes due to GCC 4.8 (*)
  • FTBFS fixes due to new GlibC
  • FTBFS fixes due to multiarched Python2.7 and Python3.3
  • FTBFS fixes due to multiarched Tcl/Tk
  • FTBFS fixes due to Python hash randomisation enabled
  • FTBFS fixes due to Boost 1.53 (*)
  • Fixes to minimise dependencies when bootstrapping packages
  • Fixes to multiarch more and more libraries
  • Fixes to enable package cross-building
  • Updates to new upstream releases
  • Usage of pybuild
  • Completed migration away from guile1.6
(*) more of those will be available after S-series opens in ubuntu, from April the 29th onwards

Some of the above patches were submitted to debian, with majority of submitted patches have not been applied, simply because none of them were appropriate during freeze and could have been disruptive to Wheezy release.

Please check useful patches available on your PTS!

Please take those patches!

Not taking Ubuntu patches results in more duplicate work in Ubuntu (i.e. rebasing those patches), thus reducing total dev-time available to work to fix other issues.

I myself uploaded a few of those patches into Ubuntu. And in the beginning I was filing BTS bugs with a patch against relevant packages in Debian. Very quickly I realised that since Debian is frozen a lot of those patches would just bitrot in BTS. I of course wished that they would all be instantly applied and uploaded into Experimental, but that did not happen. At the moment there are still 8 bugs open with patches I submitted, with oldest one opened on 6th of July 2012. So that's the reason why I stopped pushing patches to BTS, because well they are not reviewed nor applied in a timely manner =) where my expectation of timely manner is less than 6 months to be uploaded into Experimental or reviewed/rejected/commented on. Not uploading patches because they don't apply to Debian yet, is silly as they will apply to Debian eventually. Unapplied patches continue to generate more work on a more universal scope (e.g. requiring those patches to be rebased in ubuntu, thus many developers spending their time doing that, instead of writting fixes for new issues).

Comments

Popular posts from this blog

How to disable TLS 1.0 and TLS 1.1 on Ubuntu

Example of website that only supports TLS v1.0, which is rejected by the client Overivew TLS v1.3 is the latest standard for secure communication over the internet. It is widely supported by desktops, servers and mobile phones. Recently Ubuntu 18.04 LTS received OpenSSL 1.1.1 update bringing the ability to potentially establish TLS v1.3 connections on the latest Ubuntu LTS release. Qualys SSL Labs Pulse report shows more than 15% adoption of TLS v1.3. It really is time to migrate from TLS v1.0 and TLS v1.1. As announced on the 15th of October 2018 Apple , Google , and Microsoft will disable TLS v1.0 and TLS v1.1 support by default and thus require TLS v1.2 to be supported by all clients and servers. Similarly, Ubuntu 20.04 LTS will also require TLS v1.2 as the minimum TLS version as well. To prepare for the move to TLS v1.2, it is a good idea to disable TLS v1.0 and TLS v1.1 on your local systems and start observing and reporting any websites, systems and applications that...

Ubuntu Livepatch service now supports over 60 different kernels

Linux kernel getting a livepatch whilst running a marathon. Generated with AI. Livepatch service eliminates the need for unplanned maintenance windows for high and critical severity kernel vulnerabilities by patching the Linux kernel while the system runs. Originally the service launched in 2016 with just a single kernel flavour supported. Over the years, additional kernels were added: new LTS releases, ESM kernels, Public Cloud kernels, and most recently HWE kernels too. Recently livepatch support was expanded for FIPS compliant kernels, Public cloud FIPS compliant kernels, and as well IBM Z (mainframe) kernels. Bringing the total of kernel flavours support to over 60 distinct kernel flavours supported in parallel. The table of supported kernels in the documentation lists the supported kernel flavours ABIs, the duration of individual build's support window, supported architectures, and the Ubuntu release. This work was only possible thanks to the collaboration with the Ubuntu C...

Ubuntu 23.10 significantly reduces the installed kernel footprint

Photo by Pixabay Ubuntu systems typically have up to 3 kernels installed, before they are auto-removed by apt on classic installs. Historically the installation was optimized for metered download size only. However, kernel size growth and usage no longer warrant such optimizations. During the 23.10 Mantic Minatour cycle, I led a coordinated effort across multiple teams to implement lots of optimizations that together achieved unprecedented install footprint improvements. Given a typical install of 3 generic kernel ABIs in the default configuration on a regular-sized VM (2 CPU cores 8GB of RAM) the following metrics are achieved in Ubuntu 23.10 versus Ubuntu 22.04 LTS: 2x less disk space used (1,417MB vs 2,940MB, including initrd) 3x less peak RAM usage for the initrd boot (68MB vs 204MB) 0.5x increase in download size (949MB vs 600MB) 2.5x faster initrd generation (4.5s vs 11.3s) approximately the same total time (103s vs 98s, hardware dependent) For minimal cloud images that do not in...