On 8 August 2015 at 01:01, jnqnfe <jnq...@gmail.com> wrote: > Further searching has indeed suggested that boost 1.55 is still broken > and will remain so (e.g. the bug #793222 discussion), and thus I can > see that 1.57/1.58 is needed as you say. In fact 1.58 is available and > it's actually just a couple of libreoffice dependencies specifically > targeting 1.55 that are causing the hold up in upgrade installation > currently (at least here on my systems). > > It is indeed unfortunate that packages for the gcc5 transition were > pushed to unstable before libreoffice was made ready for it, and worse > that this has resulted in security implications for Sid users. I must > request that those responsible please tread more carefully in future > (no disrespect intended, and do I really appreciate the free time and > effort put into these projects). > > While there may sadly be no specific commitment for keeping unstable > secure, it has been my impression that the record for pushing security > fixes there is pretty strong. I am sure that many Debian users run Sid > in order to have a much more up to date collection of application > packages than you get from stable (testing does not seem suitable for > normal use, since security updates are frequently delayed due to > unstable->testing transitions). It would be very much appreciated if > devs/maintainers would please keep this in mind in order to not cause > problems like this for such users. >
there is no easy way to do 4k source package transition, without breaking anything, in near instant time... we did stage many of the large abi transitions in experimental, but not all maintainers co-ordinated to do so. Waiting on such a high-level package as libreoffice, falls somewhere between impractical and impossible, as a lot of things have to transition before one can even attempt to validate libreoffice compatibility with the new world order. Debian is not the first one to do this transition, and libreoffice upstream and/or other distributions surely have addressed any /libreoffice/ specific issues that would prevent libreoffice from transitioning by now. As a boost maintainer, I requested said breaks to be put in place. Placing such a breaks is the only sensible way to prevent broken partial upgrades leading to complete runtime breakage. (i.e. runtime exceptions thrown across abi boundaries) Preventing ABI incompatible installations in sid, is higher priority for me, then publishing security fixes of leaf/high-order packages, especially since e.g. release team set the #debian-devel irc channel topic to: "Broken: <insert your favorite libstdc++6 related breakage>" Please help with binNMU / transitioning packages in the chain, that lead up to your package, if you want your package to be buildable/installable as soon as possible. libreoffice will not get any preferential treatment in transitions like this, and demanding for such treatment in this or future transitions is counter-productive. Ultimately release team can remove anything from testing to keep transitions flowing, and that may as well be libreoffice as much as any other package, based on release team criteria for e.g. rc bugs and auto-removals. Ditto security uploads to sid, do not trump ongoing transitions. If what you care about is testing, rather than sid, you might be able to file request with release team to use e.g. testing-proposed-updates for a security fix targeting testing, bypassing britney migration & unstable. But I do still want to emphasise, that help with the current mass transition would be preferred, as that would be the collaborative least net-effort to get things done. Do you see what I mean? Regards, Dimitri. > On Sat, 2015-08-08 at 00:35 +0200, Matthias Klose wrote: >> Control: severity -1 important >> >> On 08/07/2015 09:11 PM, jnqnfe wrote: >> > Control: severity -1 critical >> > Control: tag -1 + security >> > >> > This dependency issue is now blocking installation of security >> > updates >> > on Sid (which many people use instead of stable, whether they >> > should or >> > not), specifically the emergency patch to iceweasel (CVE-2015-4495) >> > in >> > version 38.1.1esr-1. >> >> this is unfortunate, however there never was and is any commitment of >> unstable >> getting security fixes. The issue is not fixed by any upload of >> boost1.55 built >> with GCC 4.9, and it won't build with GCC 5. An update to 1.57 or >> 1.58 is >> required. If you need to have such an update in testing, then you >> should ask >> for an upload to testing. >> >> -- Regards, Dimitri.
