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

Mass bug filing: dependencies on GTK 2

[Simon McVittie]

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.

GTK 2 was superseded by GTK 3 in 2011 (see
). It no longer receives any significant
upstream maintenance, and in particular does not get feature development
for new features like UI scaling on high-pixel-density displays (HiDPI)
and native Wayland support. GTK 3 is in maintenance mode and GTK 4 is
approaching release, so it seems like a good time to be thinking about
minimizing the amount of GTK 2 in the archive.

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.

A porting guide is provided in the GTK 3 documentation:
https://developer.gnome.org/gtk3/stable/migrating.html

Some libraries (for example libgtkspell0) expose GTK as part of their
API/ABI, in which case removing the deprecated dependency requires
breaking API/ABI. For these libraries, in many cases there will already
be a corresponding GTK 3 version (for example libgtkspell3-3-0), in which
case the GTK 2-based library should probably be deprecated or removed
itself. If there is no GTK 3 equivalent, of a GTK 2-based library,
maintainers should talk to the dependent library's upstream developers
about whether the dependent library should break API/ABI and switch
to GTK 3, or whether the dependent library should itself be deprecated
or removed.

A few packages extend GTK 2 by providing plugins (theme engines, input
methods, etc.) or themes. If these packages deliberately support GTK 2
even though it is deprecated, and they also support GTK 3, then it is
appropriate to mark the mass-filed bug as wontfix.

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.

smcv
abgate
abx
acedb
adapta-gtk-theme
aeskulap
aewm
afterstep
aiksaurus
allegro5
alltray
alsa-tools
alsaplayer
amide
amoeba
amsynth
anypaper
appmenu-gtk-module
apwal
arc-theme
ardour
artha
asunder
ats-lang-anairiats
audacious
audacious-plugins
aumix
avw.lv2
aylet
baresip
basilisk2
bbrun
berusky
berusky2
bfm
birdfont
bitmeter
bitstormlite
bluebird-gtk-theme
breeze-gtk
brp-pacu
bygfoot
cadabra
cairocffi
cairodevice
calcoo
calf
carettah
caribou
castle-game-engine
cccd
cdebconf
cdebconf-entropy
cdebconf-terminal
cegui-mk2
cellwriter
chemtool
choosewm
claws-mail
coinst
compiz-boxmenu
cqrlog
crack-attack
crossfire-client
csmash
cwiid
dark-gtk-themes
darkcold-gtk-theme
darkmint-gtk-theme
darksnow
darnwdl
dbmix
dcl
ddccontrol
dde-qt5integration
ddrescueview
deb-gview
deepin-notifications
deskmenu
desktopnova
desmume
dfcgen-gtk
dhcpcd-ui
dia
distcc
dlume
dnssec-trigger
dopewars
doublecmd
dozzaqueux
driftnet
dvdisaster
dwarf-fortress
easychem
easyspice
eboard
ebview
efax-gtk
eiskaltdcpp
emu8051
etw
euler
exo
expeyes
exult
faumachine
fbpanel
fbreader
fbxkb
fceux
fcitx
fcitx5-gtk
fio
firefox
firefox-esr
flashplugin-nonfree
flowcanvas
fluidsynth-dssi
fluxbox
foo-yc20
foxtrotgps
fpc
fped
fprint-demo
free42-nologo
freebirth
freeciv
freetennis
freshplayerplugin
fyre
g3data
g3dviewer
gabedit
gadmin-bind
gadmin-openvpn-client
gadmin-openvpn-server
gadmin-proftpd
gadmin-rsync
gadmin-samba
gambas3
gamgi
ganv
garcon
gargoyle-free
gauche-gtk
gbase
gbdfed
gbemol
gbgoffice
gcin
gcx
gdis
gdmap
gdpc
geda-gaf
geeqie
geg
gegl
gelemental
geneweb
gerbv
gerstensaft
gexec
gfm
gfpoken
gfsview
gftp
ggobi
ghemical
ghostess
gimp
gimp-dcraw
gimp-dds
gimp-gap
gimp-plugin-registry
gimp-texturize
gimplensfun
ginkgocadx
gip
gjacktransport
gjiten
gkrellkam
gkrellm
gkrellm-gkrellmpc
gkrellm-leds
gkrellm-mailwatch
gkrellm-radio
gkrellm-reminder
gkrellm-thinkbat
gkrellm-tz
gkrellm-volume
gkrellm-x86info
gkrellm-xkb
gkrellm2-cpufreq
gkrellmitime
gkrellmoon
gkrellmwireless
gkrellshoot
gkrelltop
gkrelluim
gkrellweather
glfer
gliv
gluas
glurp
gman
gmanedit
gmerlin
gmidimonitor
gmlive
gmotionlive
gmpc
gmpc-plugins
gmrun
gnokii
gnome-paint
gnome-themes-extra
gnu-smalltalk
gnubg
gnubik
golang-github-mattn-go-gtk
gopchop
gpa
gpaint
gperiodic
gpick
gpicview
gplanarity
gpr
gpsim
granule
graphviz
grhino
grig
gringotts
gromit
groundhog
growl-for-linux
grpn
grsync
grun
gscan2pdf
gscanbus
gsetroot
gsmc
gst123
gtans
gtick
gtimer
gtk-chtheme
gtk-gnutella
gtk-im-libthai
gtk-nodoka-engine
gtk-sharp-beans
gtk-sharp2
gtk-theme-switch
gtk-vector-screenshot
gtk2-engines
gtk2-engines-aurora
gtk2-engines-cleanice
gtk2-engines-murrine
gtk2-engines-oxygen
gtkam
gtkballs
gtkboard
gtkextra
gtkgl2
gtkglext
gtkglextmm