Re: Mass bug filing: dependencies on GTK 2

[Paul Wise]

On Thu, May 14, 2020 at 9:28 AM Jonathan Dowland wrote:

> Thanks for expressing this so well! For folks interested in working with
> historical software, historical toolkits are vital. It was for this
> reason I am sad at the glee with which people removed Qt4 from the
> archive, and similar such things. But at the same time you are
> right that packaged F/OSS software really should migrate
> toolkits eventually. Or at least the vast majority of it should.

I wonder if flatpak/snap would be a good way to preserve historical
software. At least some folks are thinking that way:

https://ubuntu.com/blog/how-to-preserve-old-software-with-snaps

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Mass bug filing: dependencies on GTK 2

[Jonathan Dowland]

On Wed, Apr 29, 2020 at 11:40:01AM +0200, Simon McVittie wrote:

GTK 2 is used by some important productivity applications like GIMP,
and has also historically been a popular UI toolkit for proprietary
software that we can't change, so perhaps removing GTK 2 from Debian
will never be feasible. However, it has definitely reached the point
where a dependency on it is a bug - not a release-critical bug, and not
a bug that can necessarily be fixed quickly, but a piece of technical
debt that maintainers should be aware of.


Thanks for expressing this so well! For folks interested in working with
historical software, historical toolkits are vital. It was for this
reason I am sad at the glee with which people removed Qt4 from the
archive, and similar such things. But at the same time you are
right that packaged F/OSS software really should migrate
toolkits eventually. Or at least the vast majority of it should.

--
  Jonathan Dowland
✎   j...@dow.land
   https://jmtd.net

Re: Mass bug filing: dependencies on GTK 2

[Vincent Lefevre]

On 2020-04-29 18:37:50 +0100, Simon McVittie wrote:
> Given GTK 2's lack of feature development (for things like HiDPI) it
> seems higher-severity than "a problem which doesn't affect the package's
> usefulness", and it's certainly not "presumably trivial to fix" in
> many cases.

Note that missing HiDPI support is not necessarily an issue on
a HiDPI screen. I use gkrellm on a HiDPI screen, and did not
even notice that it was based on GTK 2 until now. Things look
fine with it, and I don't see what could be missing in the UI.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Mass bug filing: dependencies on GTK 2

[Jeremy Bicha]

On Wed, Apr 29, 2020 at 5:58 PM Adam Borowski  wrote:
> I wonder, perhaps it'd be better to use "normal" for packages that _use_
> GTK2, and no bug at all for those that provide an input method/theme/etc
> for GTK2+3?  A bug that's not supposed to be actioned upon is no good.
>
> And probably an immediate ITR for GTK2-only inputs/themes.

Actually, for themes (and input methods, etc.), I recommend using a
hack to avoid the GTK2 dependency. It's safe because the only thing
that will use a GTK2 theme is GTK2 so it's unnecessary for the theme
itself to depend on GTK2. It's useful because we don't have a good way
to provide a user with the GTK2 version of an installed theme at the
time they install GTK2 unless we just install the GTK2 theme at the
same time as the GTK3 theme. Sort of a Just-In-Time apt dependency
resolution would be nice.

https://salsa.debian.org/gnome-team/gnome-themes-extra/-/commit/4c5691edd

Thanks,
Jeremy Bicha

Re: Mass bug filing: dependencies on GTK 2

[Simon McVittie]

On Wed, 29 Apr 2020 at 23:58:01 +0200, Adam Borowski wrote:
> I wonder, perhaps it'd be better to use "normal" for packages that _use_
> GTK2, and no bug at all for those that provide an input method/theme/etc
> for GTK2+3?

If I can immediately identify a package as providing one of those, I'll
skip it; but I don't know what all of those 645 packages do, and their
maintainers would know better than I do. If there's any doubt, I'd prefer
to open the bug, so that maintainers won't get a nasty surprise in however
many years' time when we actually try to remove GTK 2.

I'm trying to make sure that maintainers of packages that depend on
something deprecated have plenty of warning, by opening low-severity bugs
far in advance of a library actually being in any danger of removal,
rather than waiting until the library is a serious problem and opening
bugs that immediately have important or RC severity. However, the
higher we raise the bar for the amount of work involved in announcing a
deprecation, the less likely it is that members of the team maintaining
the deprecated library will have the necessary time to do it (in addition
to maintaining what they already maintain).

smcv

Re: Mass bug filing: dependencies on GTK 2

[Adam Borowski]

On Wed, Apr 29, 2020 at 06:37:50PM +0100, Simon McVittie wrote:
> On Wed, 29 Apr 2020 at 18:04:41 +0200, Mattia Rizzolo wrote:
> > I think you should
> > file the bugs at severity:minor, given the amount of involved packages,
> > and the fact that you state we might not be able to remove gtk2 in many
> > many years.
> 
> If you say so. I was going to use normal, like I did for the analogous
> dbus-glib MBF; the practical difference between minor and normal doesn't
> seem significant.
> 
> Given GTK 2's lack of feature development (for things like HiDPI) it
> seems higher-severity than "a problem which doesn't affect the package's
> usefulness", and it's certainly not "presumably trivial to fix" in
> many cases.

I wonder, perhaps it'd be better to use "normal" for packages that _use_
GTK2, and no bug at all for those that provide an input method/theme/etc
for GTK2+3?  A bug that's not supposed to be actioned upon is no good.

And probably an immediate ITR for GTK2-only inputs/themes.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀   --  on #linux-sunxi
⠈⠳⣄

Re: Mass bug filing: dependencies on GTK 2

[Simon McVittie]

On Wed, 29 Apr 2020 at 21:48:55 +0200, Johannes Schauer wrote:
> I wasn't able to figure out what code is generating this but usually the right
> tool to analyze transitive dependency relationships is dose3 or tools using it
> like build-rdeps from devscripts.

I generated the MBF list by using dak, on the DD-accessible mirror of the
Debian ftp archive, to ask "if I removed gtk+2.0, what would it break?":

dak rm -R -n gtk+2.0

This is probably the best tool to use when your goal is to remove a
package, because it's literally the same code that the ftp team would run
(although on a different machine and without -n) to do the removal. It
can also be run with "-b" to ask what would happen if you removed one or
more binary packages, for example to see whether a transitional package
can be dropped.

In the case of gtk+2.0 I think we're a long way away from being able to
consider removing it, but dak is still a useful tool to see what would
happen if we did.

smcv

Re: Mass bug filing: dependencies on GTK 2

[Mattia Rizzolo]

On Wed, 29 Apr 2020, 9:29 pm Michael Biebl,  wrote:

> Am 29.04.20 um 19:37 schrieb Simon McVittie:
> > On Wed, 29 Apr 2020 at 18:04:41 +0200, Mattia Rizzolo wrote:
>
> >> I think you should
> >> file the bugs at severity:minor, given the amount of involved packages,
> >> and the fact that you state we might not be able to remove gtk2 in many
> >> many years.
> >
> > If you say so. I was going to use normal, like I did for the analogous
> > dbus-glib MBF; the practical difference between minor and normal doesn't
> > seem significant.
> >
>
> fwiw, I think normal seems about right.
>

I'm not fussy either way, that was mostly my 2¢ given you didn't specify in
the OP.
As you mention, the practical differences are next to non-existent.


>

Re: Mass bug filing: dependencies on GTK 2

[Johannes Schauer]

Quoting Andreas Henriksson (2020-04-29 12:11:32)
> On Wed, Apr 29, 2020 at 11:58:53AM +0200, Jeff wrote:
> > Hi Simon,
> > 
> > I don't understand why gscan2pdf is in the list, as the versions in
> > stable, testing and unstable are Perl packages which use libgtk3-perl.
> > 
> > Can you explain?
> 
> reverse-depends -r testing -b src:gtk+2.0 2>&1 | grep gscan2pdf
> * gscan2pdf (for libgail-common)
> * gscan2pdf (for libgail-common)

that tool relies on a remote server to operate (could this be made explicit in
the man page of the tool?), specifically it queries:

http://qa.ubuntuwire.org/rdepends/v1/bullseye/source/src:gtk+2.0

I wasn't able to figure out what code is generating this but usually the right
tool to analyze transitive dependency relationships is dose3 or tools using it
like build-rdeps from devscripts. In this case you would run for each binary
package produced by src:gtk+2.0:

$ build-rdeps libgail-common
[...]
gscan2pdf

The disadvantage of build-rdeps is, that you have to run it for every binary
package produced by src:gtk+2.0 one-by-one as it does not yet automatically
turn a src:foo argument into the binary packages produced by foo. Another
disadvantage is, that it's often non-intuitive how non-direct dependencies are
pulled in. In this case it's a direct dependency so that's easy but in the
general case you can obtain the full dependency path by running dose-ceve
manually like this:

packages=$(apt-get indextargets 'Created-By: Packages' 'Architecture: 
amd64' 'Component: main' 'Suite: unstable' --format '$(FILENAME)')
sources=$(apt-get indextargets 'Created-By: Sources' 'Component: main' 
'Suite: unstable' --format '$(FILENAME)')

$ dose-ceve -T grml --deb-builds-from --deb-native-arch=amd64 
debsrc://"$sources" deb://"$packages" > /tmp/graph.xml
$ botch-graph-shortest-path /tmp/graph.xml /tmp/out.xml --source 
realpackage:src:gscan2pdf --target realpackage:src:gtk+2.0

The file /tmp/out.xml will then contain one of the paths from src:gscan2pdf to
src:gtk+2.0, which in this case (as we already knew) goes via libgail-common.

Thanks!

cheers, josch

signature.asc
Description: signature

Re: Mass bug filing: dependencies on GTK 2

[Michael Biebl]

Am 29.04.20 um 19:37 schrieb Simon McVittie:
> On Wed, 29 Apr 2020 at 18:04:41 +0200, Mattia Rizzolo wrote:

>> I think you should
>> file the bugs at severity:minor, given the amount of involved packages,
>> and the fact that you state we might not be able to remove gtk2 in many
>> many years.
> 
> If you say so. I was going to use normal, like I did for the analogous
> dbus-glib MBF; the practical difference between minor and normal doesn't
> seem significant.
> 

fwiw, I think normal seems about right.




signature.asc
Description: OpenPGP digital signature

Re: Mass bug filing: dependencies on GTK 2

[Simon McVittie]

On Wed, 29 Apr 2020 at 18:04:41 +0200, Mattia Rizzolo wrote:
> You haven't included a copy of the proposed text

My intention was for it to be very similar to this MBF announcement
(apart from adding a few references to "this package" etc.), except
in cases where I can tell the dependency is likely to be unnecessary
(I already filed bugs for a few of those).

> I think you should
> file the bugs at severity:minor, given the amount of involved packages,
> and the fact that you state we might not be able to remove gtk2 in many
> many years.

If you say so. I was going to use normal, like I did for the analogous
dbus-glib MBF; the practical difference between minor and normal doesn't
seem significant.

Given GTK 2's lack of feature development (for things like HiDPI) it
seems higher-severity than "a problem which doesn't affect the package's
usefulness", and it's certainly not "presumably trivial to fix" in
many cases.

smcv

Re: Mass bug filing: dependencies on GTK 2

[Jeff]

Hi Andreas,

On 29/04/2020 12:11, Andreas Henriksson wrote:
> reverse-depends -r testing -b src:gtk+2.0 2>&1 | grep gscan2pdf
> * gscan2pdf (for libgail-common)
> * gscan2pdf (for libgail-common)

Thanks!

Regards

Jeff



signature.asc
Description: OpenPGP digital signature

Re: Mass bug filing: dependencies on GTK 2

[Mattia Rizzolo]

On Wed, Apr 29, 2020 at 10:38:27AM +0100, Simon McVittie wrote:
> Quite a lot of source packages (see attached list and dd-list) have
> Build-Depends on GTK 2 (libgtk2.0-dev), or produce binary packages with
> a Depends on it.
> 
> Mass-filed bugs for this will be usertagged to appear in
> https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=pkg-gnome-maintainers%40lists.alioth.debian.org=gtk2
> and will be marked as blocking #947713.

It is a huge list, but I think it's fine and you should start filing the
bugs.

You haven't included a copy of the proposed text, but I think you should
file the bugs at severity:minor, given the amount of involved packages,
and the fact that you state we might not be able to remove gtk2 in many
many years.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Mass bug filing: dependencies on GTK 2

[Andreas Henriksson]

Hi Jeff,

On Wed, Apr 29, 2020 at 11:58:53AM +0200, Jeff wrote:
> Hi Simon,
> 
> I don't understand why gscan2pdf is in the list, as the versions in
> stable, testing and unstable are Perl packages which use libgtk3-perl.
> 
> Can you explain?

reverse-depends -r testing -b src:gtk+2.0 2>&1 | grep gscan2pdf
* gscan2pdf (for libgail-common)
* gscan2pdf (for libgail-common)


Regards,
Andreas Henriksson

Re: Mass bug filing: dependencies on GTK 2

[Jeff]

Hi Simon,

On 29/04/2020 11:38, Simon McVittie wrote:
> Quite a lot of source packages (see attached list and dd-list) have
> Build-Depends on GTK 2 (libgtk2.0-dev), or produce binary packages with
> a Depends on it.

I don't understand why gscan2pdf is in the list, as the versions in
stable, testing and unstable are Perl packages which use libgtk3-perl.

Can you explain?

Regards

Jeff



signature.asc
Description: OpenPGP digital signature