In data lunedì 8 giugno 2020 12:49:19 CEST, Dimitri John Ledkov ha scritto:
> On Mon, 08 Jun 2020 08:38:44 +0200 Pino Toscano <pino@debian.org> wrote:
> > In data lunedì 8 giugno 2020 08:06:42 CEST, Dimitri John Ledkov ha scritto:
> > > > I'm pretty sure boost 1.67.0 can stay 3 months more around, especially
> > > > since I see it is still not the only package using the old boost.
> > > >
> > >
> > > No, it cannot as it entangles too many other transitions.
> >
> > Which ones exactly, other than the ICU one? (And the ICU one could be
> > easily done by rebuilding boost1.67.0 too)
> >
>
> No, boost1.67 will not be rebuilt against new ICU as that will break
> upgrades from stable.
>
> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962040 from
> release team & the discussion on the boost1.71 transition bug.
OK, and this is useful information. It would have been nicer to have
it at the beginning instead of poking after a useless initial bug
report.
> > > boost1.67 will be shortly removed from both testing and unstable.
> >
> > Again, please open bugs about this. Also, where is this info coming
> > from? I don't see anything in
> > https://bugs.debian.org/961995 (boost-defaults transitions)
> > https://bugs.debian.org/ftp.debian.org (ftp-masters bugs)
> >
>
> boost1.67 is RC buggy in both testing & unstable. I'm not sure what
> else i need to open? And those bugs already blocked by kig's bug
> RE:python2 removal.
Like, a classic RM bug for ftp-masters? How else do you expect to
remove a package from Debian?
> > > Please stop intentionally delaying completion of multiple archive
> > > transitions.
> >
> > This is definitely way too harsh and untrue, especially when you are
> > providing literally no references to blocked things or schedules for
> > removals.
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=936794 was filed on
> Date: Fri, 30 Aug 2019 07:22:06 +0000
>
> kig is a leaf package, itself not blocked by anything to migrate to
> python3 or at least stop (temporarily) using python2.
I don't see what Python 2 has anything to do here, and mixing up
issues. I also explained in previous email in this bug report that
the current stable version does not have all the changes needed for
full Python 3 support, so your "not blocked by anything to migrate to
python3" statement is false.
> leaf packages like kig are overdue to drop python2 support.
Your patches are welcome!
> > > Would you like me to upload NMU to delayed/2 that disable python bindings?
> >
> > Please not, and please rather answer the questions I asked.
>
> kig had 9 months notice that it is blocking removal of python2 from unstable.
Again, Python 2 is unrelated to this bug.
> you can see progress of boost transition at
> https://release.debian.org/transitions/html/boost1.71.html
Yes, I know how transitions work, no need to lecture me about them.
And TBH this transition has been badly handled, with no prior
notifications to involved packages about them (like test rebuilds with
bugs filed in advance about the lack of compatibility with boost 1.71).
Also, with all the respect possible: please do not play with severity,
especially when you have lacking to provide useful information for two
emails so far. I'm monitoring these bugs, I can make a maintainer
decision/choice once I have enough information, which finally you
decided to provide _just now_. IOW, if you want maintainers'
cooperation, please learn to provide information _in advance_, rather
than just useless "everything is broken! remove! remove!" panic bug
reports.
You are not being reasonable either.
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.
boost-defaults gets uploaded.
kig gets binNMUed successfully.
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. Without opening any bug reports. 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.
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.
You then downgrade the bug report to force broken stuff into testing and anchor it there.
From my point of view, it is best to drop boost-python buildepedencie from kig. This way it builds, and migrates, and does not use any RC buggy components. If and when kig upstream supports python3 properly, reintroduce boost-python build dep and build the optional python scripting component. This way kig always remains in the archive, without hindering anybody elses work.
Isn't it better to temporarily drop python support from kig?