In data lunedì 8 giugno 2020 14:19:39 CEST, Dimitri John Ledkov ha scritto: > You are not being reasonable either. I am being reasonable as your unreasonable attitude. > Boost1.71 transition was prepared since February. > > kig, like majority of packages, succeeded to build in all test rebuilds & > passed autopkgtest if any. Packages that successfully binNMU are not > notified about upcoming transitions. > Packages that ftbfs have patches developed and bugs opened. Again, I know how transitions works, no need for lecturing things that I've done for more than a decade. > kig gets binNMUed successfully. That is the unexpected part: the new boost ships cmake config files that make the cmake search for the "python" component of the Boost cmake package refer to the shipped boost-python, which is the Python 3 one. boost 1.67.0 does not have cmake config files, and thus the FindBoost.cmake provided by cmake detects the Python2-based boost-python as "python" component. This is why... > Then two days later you upload a uncoordinated downgrade to reintroduce > dependency on old python2 and old boost, in full knowledge that you are > hindering other people's work. ... I uploaded kig to switch it back to Python 2, because the automatic switch was not supposed to happen. More than "hindering other people's work", I restored a broken functionality that was switched because of the new boost. > Without opening any bug reports. I explained the reason in the changelog message, please do read it. > And during > that time tracker.d.o should have had a message that kig should not be > uploaded as it is part of an ongoing transition. There was no message in pts/tracker back then, and still there is nothing as of right now. Also, boost transitions works slightly different than other library transitions: the old and the new libraries are provided by different sources and they are co-installable (not their -dev, though). It's enough that the new boost is available in testing, so the switch of boost-default is not a blocker transition but a a gradual rebuild/fix that can generally happen side by side with other changes. This is similar to what happens when the default Python version is switched: both the old and the new are co-installable, and already in testing. > I notice regression in transition counts, and open a bug report to prevent > regressions entering testing and making it harder to remove boost1.67 & > python2. I explained already that the boost rebuild already created a buggy functionality, and because of the transition it already migrated to testing. > You then downgrade the bug report to force broken stuff into testing and > anchor it there. Sigh. > >From my point of view, [...] ... you ought to provide the information as they were asked, and leave the judgement the maintainer, especially if you clearly have NO IDEA about the sitation of kig. Now, I need the current version in unstable to migrate to testing, because as I said the boost binNMU created issues (and I got a private email by an user reporting that). In a couple of days I will check this again, and decide what to do. -- Pino Toscano
Attachment:
signature.asc
Description: This is a digitally signed message part.