[Pkg-kde-extras] Bug#874928: [kalternatives] Future Qt4 removal from Buster
在 2017年12月9日星期六 CST 上午6:44:09，Pino Toscano 写道： > In data sabato 9 dicembre 2017 11:48:41 CET, Boyuan Yang ha scritto: > > X-Debbugs-CC: p...@kde.org debian-qt-...@lists.debian.org > > > > 在 2017年11月28日星期二 CST 上午9:55:54，Boyuan Yang 写道： > > > > > X-Debbugs-CC: p...@kde.org debian-qt-...@lists.debian.org > > > > > > Hello all, > > > > > > I'm wondering about the future of package "kalternatives" in Debian. It > > > has > > > not been updated for 7 years, now affected by Qt4 removal and I cannot > > > find > > > the upstream VCS for it. > > Did you try looking at cgit.kde.org? Sorry I didn't notice that; I thought the repo in Debian should be the upstream since no "Homepage" field was found in the source package and d/watch file became defunct. > > > > Will there be any porting efforts? If yes, please let me know; if not, > > > we > > > could consider submitting removal request to get this out of Debian > > > unstable. > > > > > > PS: I'm the current maintainer of package "galternatives" in Debian. > > I honestly do not see how the status of kalternatives is any concern on > your side. > > > Since there's no response, I'm going to file an RM bug for package > > kalternatives within one month. > > > > Please let me know if anyone is willing to work on it and port it to Qt5. > > Please do not, since I'm working on porting it. That's great! Looking forward to seeing the new implementation. Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part. ___ pkg-kde-extras mailing list pkg-kde-extras@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-extras
[Pkg-kde-extras] Bug#874928: Bug#874928: [kalternatives] Future Qt4 removal from Buster
In data sabato 9 dicembre 2017 11:48:41 CET, Boyuan Yang ha scritto: > X-Debbugs-CC: p...@kde.org debian-qt-...@lists.debian.org > > 在 2017年11月28日星期二 CST 上午9:55:54，Boyuan Yang 写道： > > X-Debbugs-CC: p...@kde.org debian-qt-...@lists.debian.org > > > > Hello all, > > > > I'm wondering about the future of package "kalternatives" in Debian. It has > > not been updated for 7 years, now affected by Qt4 removal and I cannot find > > the upstream VCS for it. Did you try looking at cgit.kde.org? > > Will there be any porting efforts? If yes, please let me know; if not, we > > could consider submitting removal request to get this out of Debian > > unstable. > > > > PS: I'm the current maintainer of package "galternatives" in Debian. I honestly do not see how the status of kalternatives is any concern on your side. > Since there's no response, I'm going to file an RM bug for package > kalternatives within one month. > > Please let me know if anyone is willing to work on it and port it to Qt5. Please do not, since I'm working on porting it. -- Pino Toscano signature.asc Description: This is a digitally signed message part. ___ pkg-kde-extras mailing list pkg-kde-extras@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-extras
[Pkg-kde-extras] Bug#874928: [kalternatives] Future Qt4 removal from Buster
X-Debbugs-CC: p...@kde.org debian-qt-...@lists.debian.org 在 2017年11月28日星期二 CST 上午9:55:54，Boyuan Yang 写道： > X-Debbugs-CC: p...@kde.org debian-qt-...@lists.debian.org > > Hello all, > > I'm wondering about the future of package "kalternatives" in Debian. It has > not been updated for 7 years, now affected by Qt4 removal and I cannot find > the upstream VCS for it. > > Will there be any porting efforts? If yes, please let me know; if not, we > could consider submitting removal request to get this out of Debian > unstable. > > PS: I'm the current maintainer of package "galternatives" in Debian. > > Thanks, > Boyuan Yang Hello, Since there's no response, I'm going to file an RM bug for package kalternatives within one month. Please let me know if anyone is willing to work on it and port it to Qt5. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part. ___ pkg-kde-extras mailing list pkg-kde-extras@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-extras
[Pkg-kde-extras] Bug#883893: digikam: freezing when using geolocation editor
Package: digikam Version: 4:5.7.0-2 Severity: normal Dear Maintainer, I experienced that any attempt to drag a picture from digikam's geolocation editor causes digikam to freeze, which makes it impossible to geolocate pictures using "drag and drop". This problem appeared after an upgrade from stretch to buster. Reverting to digikam 5.3 didn't help. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (950, 'testing'), (900, 'stable'), (700, 'unstable'), (600, 'experimental'), (500, 'stable-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages digikam depends on: ii digikam-data 4:5.7.0-2 ii digikam-private-libs 4:5.7.0-2 ii kipi-plugins 4:5.7.0-2 ii libc6 2.25-3 ii libexpat1 2.2.3-2 ii libgcc1 1:7.2.0-16 ii libkf5configcore5 5.37.0-2 ii libkf5coreaddons5 5.37.0-2 ii libkf5filemetadata3 5.37.0-2 ii libkf5i18n5 5.37.0-2 ii libqt5core5a 5.9.2+dfsg-4 ii libqt5gui55.9.2+dfsg-4 ii libqt5sql55.9.2+dfsg-4 ii libqt5sql5-mysql 5.9.2+dfsg-4 ii libqt5sql5-sqlite 5.9.2+dfsg-4 ii libqt5widgets55.9.2+dfsg-4 ii libstdc++67.2.0-16 ii perl 5.26.1-3 Versions of packages digikam recommends: ii chromium [www-browser] 62.0.3202.89-1 ii ffmpegthumbs 4:17.08.3-1 ii firefox [www-browser] 57.0.1-1 ii firefox-esr [www-browser] 52.5.0esr-1 ii konqueror [www-browser]4:16.08.3-1 Versions of packages digikam suggests: pn digikam-doc ii systemsettings 4:5.10.5-2 -- no debconf information ___ pkg-kde-extras mailing list pkg-kde-extras@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-extras
[Pkg-kde-extras] Bug#883737: gtk2-engines-oxygen: Please don't depend on gtk2
On Fri, Dec 8, 2017 at 3:45 PM, Pino Toscano wrote: > To be honest, I do not see this as wrong case: while it is not something > clear for users, OTOH I do not think it is good to install themes and > plugins for libraries and frameworks, even if they are not installed by > default (and possibly not going to be used). This is also for the case > mentioned above: I would not like that users have plugins for gtk2, > gtk3, qt4, qt5, ibus, scim, uim, etc, just because they might be used > at some point. This IMHO is just a way to clutter the users' systems. The "clutter" for numix-gtk-theme to provide gtk2 support is 25k, plus 324k for the Murrine gtk2 engine. (The rest of the Numix theme is about 2.3 MB.) The "clutter" required to install gtk2 is about 6.5 MB here. A good way to irritate users is to force them to manually install a gtk2 version of their theme if they want their gtk2 apps to not look bad. > Here we disagree. IMHO this is a workaround to the situation, not a > real solution. I think the "real solution" is conditional depends in apt. If libgtk2.0-0 is installed and numix-gtk-theme is installed, then install numix-gtk2-theme. But that feature doesn't exist so we need a workaround. I think my proposal is the best workaround we have. Thanks, Jeremy Bicha ___ pkg-kde-extras mailing list pkg-kde-extras@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-extras
[Pkg-kde-extras] Bug#883737: Bug#883737: Bug#883737: Bug#883737: gtk2-engines-oxygen: Please don't depend on gtk2
In data venerdì 8 dicembre 2017 14:46:57 CET, Jeremy Bicha ha scritto: > On Fri, Dec 8, 2017 at 1:31 PM, Pino Toscano wrote: > > In general, I do not see the point in allowing "plugins for Foo" as > > installable/installed when "Foo" is not. > > I am also making a similar change for input methods. If a user is > using ibus, they should not have to manually install ibus-gtk (the > gtk2 version) if they later install a gtk2 app. I'll reply later on on this. > And I don't think it's a good idea to have gtk2 recommend every gtk2 > theme engine and input method. Indeed, this is not feasible. > > I see two possibilities in this case (feel free to add more, of course): > > The problem here is a bit theoretical since there doesn't seem to be > any gtk3 version of Oxygen (at least not in Debian) and therefore, the > package is not very useful since most maintained gtk apps use gtk3 > now. A gtk3 version of oxygen most probably would get its own package. > So let me substitute with a better example: > > c) In the near future, it will be possible to install Debian GNOME > without gtk2 pre-installed. A Debian GNOME user installs the Numix > theme and makes it their default theme. A few weeks later, the user > decides to install a gtk2 app like Inkscape. I think it's wrong to > require the user to manually install a theoretical numix-gtk2-theme > package to fix their theming. I also think it's wrong to force a user > to have gtk2 installed just because a theme they want to use happens > to support gtk2. To be honest, I do not see this as wrong case: while it is not something clear for users, OTOH I do not think it is good to install themes and plugins for libraries and frameworks, even if they are not installed by default (and possibly not going to be used). This is also for the case mentioned above: I would not like that users have plugins for gtk2, gtk3, qt4, qt5, ibus, scim, uim, etc, just because they might be used at some point. This IMHO is just a way to clutter the users' systems. > Keeping gtk2 installed by default is a subtle suggestion to developers > that it's ok for their app to use gtk2. But like qt4, it's not ok. No (non-developer) users will install gtk2 directly, but they will get it installed because they installed via an application written as gtk2. > My proposal is a simple fix for these problems. While it looks a bit > strange at first, it's a harmless change that fixes actual problems. Here we disagree. IMHO this is a workaround to the situation, not a real solution. > > There are various things that kubuntu does wrong, and that I needed to > > fix in the past and in recent times. "kubuntu did it" is not a magical > > sentence to bring the same mistakes also in Debian. > > Ok, well the developer who made that change is Scott Kitterman who is > a Debian Developer and not a Kubuntu developer any more. Not relevant to the discussion. I judge an idea from a technical POV, not who made it. -- Pino Toscano signature.asc Description: This is a digitally signed message part. ___ pkg-kde-extras mailing list pkg-kde-extras@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-extras
[Pkg-kde-extras] Bug#883737: Bug#883737: Bug#883737: gtk2-engines-oxygen: Please don't depend on gtk2
On Fri, Dec 8, 2017 at 1:31 PM, Pino Toscano wrote: > In general, I do not see the point in allowing "plugins for Foo" as > installable/installed when "Foo" is not. I am also making a similar change for input methods. If a user is using ibus, they should not have to manually install ibus-gtk (the gtk2 version) if they later install a gtk2 app. And I don't think it's a good idea to have gtk2 recommend every gtk2 theme engine and input method. > I see two possibilities in this case (feel free to add more, of course): The problem here is a bit theoretical since there doesn't seem to be any gtk3 version of Oxygen (at least not in Debian) and therefore, the package is not very useful since most maintained gtk apps use gtk3 now. So let me substitute with a better example: c) In the near future, it will be possible to install Debian GNOME without gtk2 pre-installed. A Debian GNOME user installs the Numix theme and makes it their default theme. A few weeks later, the user decides to install a gtk2 app like Inkscape. I think it's wrong to require the user to manually install a theoretical numix-gtk2-theme package to fix their theming. I also think it's wrong to force a user to have gtk2 installed just because a theme they want to use happens to support gtk2. Keeping gtk2 installed by default is a subtle suggestion to developers that it's ok for their app to use gtk2. But like qt4, it's not ok. My proposal is a simple fix for these problems. While it looks a bit strange at first, it's a harmless change that fixes actual problems. This certainly isn't the only use of the shlibdeps override in Debian. > There are various things that kubuntu does wrong, and that I needed to > fix in the past and in recent times. "kubuntu did it" is not a magical > sentence to bring the same mistakes also in Debian. Ok, well the developer who made that change is Scott Kitterman who is a Debian Developer and not a Kubuntu developer any more. Thanks, Jeremy Bicha ___ pkg-kde-extras mailing list pkg-kde-extras@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-extras
[Pkg-kde-extras] Bug#883737: Bug#883737: Bug#883737: gtk2-engines-oxygen: Please don't depend on gtk2
In data venerdì 8 dicembre 2017 12:55:13 CET, Jeremy Bicha ha scritto: > On Thu, Dec 7, 2017 at 1:20 AM, Pino Toscano wrote: > > It looks to me this allows users to install gtk2-engine-oxygen without > > actually pulling gtk2, which IMHO is the thing that needs to be fixed > > instead. > > gtk3 uses CSS theming instead of engines that have to be compiled > against the gtk library so I consider the gtk side of this theme issue > to already be fixed. (The theming overhaul is definitely not > backportable to gtk2.) > > Someone shouldn't need to have gtk2 installed just because they > install a theme that happens to provide gtk2 support. I see two possibilities in this case (feel free to add more, of course): a) gtk2-engines-oxygen is installed via some desktop environment metapackage b) it is installed manually by the user, because they use gtk2-based applications (b) is not something this "solution" would solve, since gtk2 is installed already because of the application Regarding (a), this is exactly what I mentioned above in the part you quoted. If we install it automatically somehow, then we should do it only in case some gtk2 application is installed because of the same reason (i.e. the metapackage). Otherwise, recommending (or just suggesting) this theme could partially solve this. In general, I do not see the point in allowing "plugins for Foo" as installable/installed when "Foo" is not. > Let me point out that since 2011 Kubuntu has been making basically the > same change I've proposed here. There are various things that kubuntu does wrong, and that I needed to fix in the past and in recent times. "kubuntu did it" is not a magical sentence to bring the same mistakes also in Debian. > > Control: tag -1 - patch > > That seems like an unusual way to manage bugs. This bug definitely > does have a patch attached. Sadly, the Debian BTS does not have other ways to indicate when there is an *useful* patch in a bug. Since, so far, I do not see the provided patch as such, then I do not consider this bug as "has a patch". As side note: this way of managing tags is not something I made up from day to night, but something DDs were doing already when I joined. -- Pino Toscano signature.asc Description: This is a digitally signed message part. ___ pkg-kde-extras mailing list pkg-kde-extras@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-extras
[Pkg-kde-extras] Bug#883737: Bug#883737: gtk2-engines-oxygen: Please don't depend on gtk2
On Thu, Dec 7, 2017 at 1:20 AM, Pino Toscano wrote: > It looks to me this allows users to install gtk2-engine-oxygen without > actually pulling gtk2, which IMHO is the thing that needs to be fixed > instead. gtk3 uses CSS theming instead of engines that have to be compiled against the gtk library so I consider the gtk side of this theme issue to already be fixed. (The theming overhaul is definitely not backportable to gtk2.) Someone shouldn't need to have gtk2 installed just because they install a theme that happens to provide gtk2 support. Let me point out that since 2011 Kubuntu has been making basically the same change I've proposed here. > Control: tag -1 - patch That seems like an unusual way to manage bugs. This bug definitely does have a patch attached. Thanks, Jeremy Bicha ___ pkg-kde-extras mailing list pkg-kde-extras@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-extras
