Bug#962348: kig: boost1.67 is being removed from testing

2020-06-23 Thread Dimitri John Ledkov
Uploading attached to DELAYED/2

On Mon, 22 Jun 2020 at 20:59, Sebastian Ramacher  wrote:
>
> Hi Pino
>
> On 2020-06-08 14:47:13 +0200, Pino Toscano wrote:
> > 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.
>
> kig is now the only reverse dependency of boost1.67 in testing. Could
> you please take a look at this soon so that I can add a removal hint for
> boost1.67? Thanks in advance
>
> Cheers
> --
> Sebastian Ramacher



-- 
Regards,

Dimitri.
diff -Nru kig-20.04.1/debian/changelog kig-20.04.1/debian/changelog
--- kig-20.04.1/debian/changelog	2020-06-04 18:11:27.0 +0100
+++ kig-20.04.1/debian/changelog	2020-06-23 16:08:29.0 +0100
@@ -1,3 +1,11 @@
+kig (4:20.04.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python bindings to complete removal of boost1.67 from
+testing. Closes: #962348
+
+ -- Dimitri John Ledkov   Tue, 23 Jun 2020 16:08:29 +0100
+
 kig (4:20.04.1-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru kig-20.04.1/debian/control kig-20.04.1/debian/control
--- kig-20.04.1/debian/control	2020-06-04 17:58:28.0 +0100
+++ kig-20.04.1/debian/control	2020-06-23 16:08:29.0 +0100
@@ -11,7 +11,6 @@
extra-cmake-modules (>= 1.7~),
gettext,
kinit-dev,
-   libboost-python1.67-dev,
libkf5archive-dev,
libkf5configwidgets-dev,
libkf5coreaddons-dev,


Bug#962348: kig: boost1.67 is being removed from testing

2020-06-22 Thread Sebastian Ramacher
Hi Pino

On 2020-06-08 14:47:13 +0200, Pino Toscano wrote:
> 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.

kig is now the only reverse dependency of boost1.67 in testing. Could
you please take a look at this soon so that I can add a removal hint for
boost1.67? Thanks in advance

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature


Bug#962348: kig: boost1.67 is being removed from testing

2020-06-08 Thread Pino Toscano
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

signature.asc
Description: This is a digitally signed message part.


Bug#962348: kig: boost1.67 is being removed from testing

2020-06-08 Thread Dimitri John Ledkov
On Mon, 8 Jun 2020, 12:14 Pino Toscano,  wrote:

> 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  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 +
> >
> > 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 

Bug#962348: kig: boost1.67 is being removed from testing

2020-06-08 Thread Pino Toscano
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  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 +
> 
> 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.

Thanks,
-- 
Pino Toscano

signature.asc
Description: This is a digitally signed message part.


Bug#962348: kig: boost1.67 is being removed from testing

2020-06-08 Thread Dimitri John Ledkov
I have doublechecked that all other packages that still depend on
boost1.67 are all marked RC-buggy and pending autoremovals with
various dates.

kig is not an exception, and is treated the same way as all other
packages still using boost1.67.

since kig rebuilds against boost1.71 were successful prior to starting
the transition, it was unknown to boost maintainer that it is buggy.

But nonetheless kig alone, does not warrant for boost maintainers to
keep boost1.67 in the archive.

-- 
Regards,

Dimitri.



Bug#962348: kig: boost1.67 is being removed from testing

2020-06-08 Thread Dimitri John Ledkov
On Mon, 08 Jun 2020 08:38:44 +0200 Pino Toscano  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.

> > 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.

> > Since the package is broken in both testing and unstable, in different
> > ways, please request its removal.
>
> The package in unstable is *not* broken.
>

It build-depends & depends on an RC buggy package, and thus is RC too,
making kig subject to autoremoval.

> > 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 +

kig is a leaf package, itself not blocked by anything to migrate to
python3 or at least stop (temporarily) using python2.

leaf packages like kig are overdue to drop python2 support.

>
> > 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.

you can see progress of boost transition at
https://release.debian.org/transitions/html/boost1.71.html

mips builders are a bit slow, and there are lots of patches uploaded
to DELAYED/2 to fix outstanding packages.

boost1.67 is declared RC buggy by the release team, thus everything
outstanding will be removed as soon as practical.

-- 
Regards,

Dimitri.



Bug#962348: kig: boost1.67 is being removed from testing

2020-06-08 Thread Pino Toscano
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)

> 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)

> Since the package is broken in both testing and unstable, in different
> ways, please request its removal.

The package in unstable is *not* broken.

> 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.

> Would you like me to upload NMU to delayed/2 that disable python bindings?

Please not, and please rather answer the questions I asked.

Thanks,
-- 
Pino Toscano

signature.asc
Description: This is a digitally signed message part.


Bug#962348: kig: boost1.67 is being removed from testing

2020-06-08 Thread Dimitri John Ledkov
On Sat, 6 Jun 2020, 19:28 Pino Toscano,  wrote:

> severity 962348 important
> thanks
>
> In data sabato 6 giugno 2020 16:26:34 CEST, Dimitri John Ledkov ha scritto:
> > Package: kig
> > Version: 4:20.04.1-1
> > Severity: serious
> >
> > Hi,
> >
> > boost1.67 is being removed from testing and is transitioning to
> boost1.71.
>
> Yes, I know about the boost transition to 1.71.0, that the new boost
> does not provide Python 2 support, and that it is expected to not ship
> boost 1.67.0 in bullseye.
>
> > kig has just now switched from boost1.71 to boost1.67.
>
> Quoting what I wrote in the changelog entry of 4:20.04.1-1:
>
>   * Temporarily switch from libboost-python-dev to libboost-python1.67-dev,
> as boost 1.67 is the latest version of boost in Debian that supports
> Python 2: kig < 20.08 is not ready for Python 3, so stil with Python 2
> for now.
>
> As the version number hints, the new stable version will be released
> in (late) August; the development version already switched to Python 3
> only, and it contains few Python 3 fixes. The current version does
> *not* work properly with Python 3, that is why I had to rollback to
> boost 1.67.0 (since boost 1.71.0 has no Python 2 bindings, sigh).
>
> > Thus I am opening this bug report to prevent kig from migrating.
>
> First of all, please do not abuse severities for things that are not
> critical yet. There is a catch here: the version in testing is the
> binNMU for the boost 1.71.0 rebuild, and apparently (to my surprise)
> it was detected and switched to Python 3. This is buggy though, so
> not letting this version migrate means having a buggy version in
> testing.
>
> > boost1.71 does not offer python2 bindings, as python2 is being removed
> to.
>
> Sure, I know this too.
>
> > I understand that kig is using boost-python2. Either please disable
> > python bindings usage at build time, or try to port to boost-python3?
>
> As I said, in ~3 months there will be a new upstream release fully
> supporting Python 3, and I will switch it when it is released.
>
> In the meanwhile, please:
> a) open a RM bug for boost 1.67.0, so it is clear that it will be
> removed
> b) make this bug block the RM bug
>
> 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.

There are less than 25 packages remaining that have not rebuilt against
boos1.71.

boost1.67 will be shortly removed from both testing and unstable.

Three month delay is not ok.

Since the package is broken in both testing and unstable, in different
ways, please request its removal. Or upload it without python bindings
enabled, until they are working correctly with python3.

Please stop intentionally delaying completion of multiple archive
transitions.

Would you like me to upload NMU to delayed/2 that disable python bindings?

Regards,

Dimitri.


Bug#962348: kig: boost1.67 is being removed from testing

2020-06-06 Thread Pino Toscano
severity 962348 important
thanks

In data sabato 6 giugno 2020 16:26:34 CEST, Dimitri John Ledkov ha scritto:
> Package: kig
> Version: 4:20.04.1-1
> Severity: serious
> 
> Hi,
> 
> boost1.67 is being removed from testing and is transitioning to boost1.71.

Yes, I know about the boost transition to 1.71.0, that the new boost
does not provide Python 2 support, and that it is expected to not ship
boost 1.67.0 in bullseye.

> kig has just now switched from boost1.71 to boost1.67.

Quoting what I wrote in the changelog entry of 4:20.04.1-1:

  * Temporarily switch from libboost-python-dev to libboost-python1.67-dev,
as boost 1.67 is the latest version of boost in Debian that supports
Python 2: kig < 20.08 is not ready for Python 3, so stil with Python 2
for now.

As the version number hints, the new stable version will be released
in (late) August; the development version already switched to Python 3
only, and it contains few Python 3 fixes. The current version does
*not* work properly with Python 3, that is why I had to rollback to
boost 1.67.0 (since boost 1.71.0 has no Python 2 bindings, sigh).

> Thus I am opening this bug report to prevent kig from migrating.

First of all, please do not abuse severities for things that are not
critical yet. There is a catch here: the version in testing is the
binNMU for the boost 1.71.0 rebuild, and apparently (to my surprise)
it was detected and switched to Python 3. This is buggy though, so
not letting this version migrate means having a buggy version in
testing.

> boost1.71 does not offer python2 bindings, as python2 is being removed to.

Sure, I know this too.

> I understand that kig is using boost-python2. Either please disable
> python bindings usage at build time, or try to port to boost-python3?

As I said, in ~3 months there will be a new upstream release fully
supporting Python 3, and I will switch it when it is released.

In the meanwhile, please:
a) open a RM bug for boost 1.67.0, so it is clear that it will be
removed
b) make this bug block the RM bug

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.

-- 
Pino Toscano

signature.asc
Description: This is a digitally signed message part.


Processed: Re: Bug#962348: kig: boost1.67 is being removed from testing

2020-06-06 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> severity 962348 important
Bug #962348 [kig] kig: boost1.67 is being removed from testing
Severity set to 'important' from 'serious'
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
962348: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962348
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#962348: kig: boost1.67 is being removed from testing

2020-06-06 Thread Dimitri John Ledkov
Package: kig
Version: 4:20.04.1-1
Severity: serious

Hi,

boost1.67 is being removed from testing and is transitioning to boost1.71.
kig has just now switched from boost1.71 to boost1.67.
boost1.67 must not be shipped in testing.
Thus I am opening this bug report to prevent kig from migrating.

boost1.71 does not offer python2 bindings, as python2 is being removed to.

I understand that kig is using boost-python2. Either please disable python 
bindings usage at build time, or try to port to boost-python3?

Either way, introducing python2 & boost1.67 usage in testing is working against 
release goals of not shipping python2 or boost1.67.

Also in Ubuntu, kig is the only package using boost1.67

-- System Information:
Debian Release: bullseye/sid
  APT prefers groovy
  APT policy: (500, 'groovy'), (500, 'focal-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-33-generic (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kig depends on:
ii  libboost-python1.67.0 [libboost-python1.67.0-py27]  1.67.0-17ubuntu8
ii  libc6   2.31-0ubuntu9
ii  libgcc-s1   10.1.0-3ubuntu1
ii  libkf5archive5  5.70.0-0ubuntu1
pn  libkf5completion5   
ii  libkf5configcore5   5.70.0-0ubuntu1
ii  libkf5configwidgets55.70.0-0ubuntu1
ii  libkf5coreaddons5   5.70.0-0ubuntu1
ii  libkf5crash55.70.0-0ubuntu1
ii  libkf5i18n5 5.70.0-0ubuntu1
ii  libkf5iconthemes5   5.70.0-0ubuntu1
pn  libkf5parts5
pn  libkf5service-bin   
pn  libkf5service5  
pn  libkf5texteditor5   
ii  libkf5widgetsaddons55.70.0-0ubuntu1
pn  libkf5xmlgui-bin
pn  libkf5xmlgui5   
ii  libpython2.72.7.18-1
ii  libqt5core5a5.14.2+dfsg-2ubuntu1
ii  libqt5gui5  5.14.2+dfsg-2ubuntu1
ii  libqt5printsupport5 5.14.2+dfsg-2ubuntu1
ii  libqt5svg5  5.14.2-1
ii  libqt5widgets5  5.14.2+dfsg-2ubuntu1
ii  libqt5xml5  5.14.2+dfsg-2ubuntu1
ii  libqt5xmlpatterns5  5.14.2-1
ii  libstdc++6  10.1.0-3ubuntu1
ii  python3 3.8.2-0ubuntu2

kig recommends no packages.

Versions of packages kig suggests:
pn  khelpcenter