Bug#1031956: ausweisapp2: App starts hidden in the background on gnome-shell + appindicator
Am Mi., 17. Jan. 2024 um 17:08 Uhr schrieb John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de>: > > This is exactly what it's supposed to mean. Packages distributed by > Debian are obviously required > > to not be broken when they hit stable. Otherwise an update wouldn't be > accepted to be sent to stable. > > The package is not broken. It works as intended by the upstream > developers. It does not say anywhere > that AusweisApp is supposed to work on a non-Qt system. > This is just not how anything works. Besides the fact that after Gnome was made because people didn't like Qt's licensing and after a while they both added compatibility for each others software - there basically isn't such thing as a "non-Qt system". A non-Qt system would be a system with no Qt dependencies available. But you'll probably never find any distro where this is the case. That's why any package will always work with any DE, no matter if it was build with GTK, Qt or something else. Sure, with Wayland needing to be supported by the DEs instead of a generic server, it can happen that some minor things need to be harmonized, e.g. communicating a sensible cursor size to Qt apps in a Gnome DE, but that's it. There's absolutely nothing that makes Qt apps Plasma only or GTK apps Gnome only. > > > And since neither Debian with KDE nor Debian with Gnome is a separate > distribution, obviously a > > package is supposed to work with both. > > Sorry, but that's just non-sense. If an upstream project does not support > GNOME, it will not > support GNOME on Debian either. Again, you are barking up the wrong tree > here. > Again, not how anything works. > > > That's why all KDE packages will pull in all necessary dependencies > required to run in Gnome (or > > any other DE offered by Debian) and vice versa. If any package would be > allowed in stable in a > > theoretical future where it only supports Wayland and not X while not > all available DEs would > > be supporting Wayland would be very questionable. And that's just > another version of this exact problem. > > It's simply not possible to support every possible use cases. You just > have to accept that. > Obviously not. But every use case supported by Debian itself must be supported by the packages. With DEs it's not like with CPU architectures where you can simply choose not to compile a package for a specific architecture. Besides the fact that even that's not relevant. Even AusweisApp is being compiled for pretty much any architecture supported by debian, simply because there's nothing preventing it. That's at least true for anything in the main repo. The only exception I know of is Steam, but that's only shipped in contrib (and used to be non-free). So yes, every use case supported by Debian stable in the main repo must be supported by every package in that branch. Everything else wouldn't make any sense after all. The real software world is not perfect. > > > > The limitations around GNOME support are an upstream issue and not > related to packaging which > > > is what I am doing. Claiming that a particular issue that is not a > serious bug must be fixed > > > before the next release is something that I would call entitlement. If > you have figured out > > > how to fix this particular problem, you are free to send a patch to me > or upstream. That's > > > how it works with community-maintained software. > > > > It's obviously serious since it literally renders the software unusable > for some users. If you > > have a different opinion, you should really re-read the severity levels' > definitions: > > https://www.debian.org/Bugs/Developer#severities > > important: a bug which has a major effect on the usability of a package, > without rendering it > > completely unusable to everyone. > > This is literally what this is. > > And you're still missing the point that the issue you are seeing here is > not a limitation of Debian > but of the upstream software you are using. You are blaming me for > something that I am not responsible > for. > > I am neither the upstream developer of GNOME nor of Qt or the AusweisApp. > I am the person who is > maintaining AusweisApp in Debian. And I am shipping the software as it is > provided by upstream. > > If upstream doesn't support usecase X, I am not the person to be blamed. > You really should look up how "Maintainer" was defined when the concept was introduced: https://www.debian.org/vote/2007/vote_003 One of the points: unfixed bugs may lead to the Maintainers key removal from the Debian Maintainers keyring, effectively revoking their status of being a Maintainer. > > > Neither me nor the upstream maintainer are actually getting paid to > provide this application > > > on Linux or on Debian, so it's perfectly fine that we get to decide > how we spend our free > > > time. > > > > Nobody said otherwise. But literally with a bug this severe v2 can't and > shouldn't be accepted > > into stable with Trixie. And if nobody fixes it, it's
Bug#1031956: ausweisapp2: App starts hidden in the background on gnome-shell + appindicator
Hello, On Wed, 2024-01-17 at 16:24 +0100, Richard wrote: > > There is no version 2.0.x in Debian stable nor stable-backports yet, so > > unless you built the > > package yourself from the unstable sources or installed the Flatpak > > version, you created a > > "FrankenDebian". > > > > To be quoting myself: I am running testing. AKA Trixie. So no, there's no > FrankenDebian at work. Ah, I misread that. That doesn't change any of what I said though. > > And, no, the wiki page regarding "FrankenDebian" is not contradicting > > itself because security > > updates are provided through debian-security. These updates are built to > > target Debian stable, > > so it's perfectly fine to install them without risking to break anything. > > > > It is not contradicting itself page-wide, but wiki-wide. This is the Wiki > entry for Debian Testing, > where it literally recommends to do what the "FrankenDebian" Wiki page > recommends not to do: > > https://wiki.debian.org/DebianTesting I was talking about stable because the original bug was reported against the stable package. > It is a good idea to install security updates from unstable since they take > extra time to reach > testing and the security team only releases updates to unstable. You're free to do that, of course. However, relevant security updates are migrating to testing with a higher priority anyway. So, unless a maintainer forgot to set the proper urgency of a security update, there is no need to pull stuff from unstable. > > > Entitled? Well that's rich. The point of the whole bug reporting system > > > is exactly what we > > > are doing here. So yes, if you are unwilling to maintain the package, > > > which will always > > > include getting bug reports if things don't behave as intended, then > > > don't do it. > > > > Not really. If someone steps up to maintain something, it doesn't > > automatically mean they > > are responsible for supporting all possible configurations that exist > > within Debian which > > is what you are asking for. The package works perfectly fine on KDE which > > is what I am using > > myself. > > > > This is exactly what it's supposed to mean. Packages distributed by Debian > are obviously required > to not be broken when they hit stable. Otherwise an update wouldn't be > accepted to be sent to stable. The package is not broken. It works as intended by the upstream developers. It does not say anywhere that AusweisApp is supposed to work on a non-Qt system. > And since neither Debian with KDE nor Debian with Gnome is a separate > distribution, obviously a > package is supposed to work with both. Sorry, but that's just non-sense. If an upstream project does not support GNOME, it will not support GNOME on Debian either. Again, you are barking up the wrong tree here. > That's why all KDE packages will pull in all necessary dependencies required > to run in Gnome (or > any other DE offered by Debian) and vice versa. If any package would be > allowed in stable in a > theoretical future where it only supports Wayland and not X while not all > available DEs would > be supporting Wayland would be very questionable. And that's just another > version of this exact problem. It's simply not possible to support every possible use cases. You just have to accept that. The real software world is not perfect. > > The limitations around GNOME support are an upstream issue and not related > > to packaging which > > is what I am doing. Claiming that a particular issue that is not a serious > > bug must be fixed > > before the next release is something that I would call entitlement. If you > > have figured out > > how to fix this particular problem, you are free to send a patch to me or > > upstream. That's > > how it works with community-maintained software. > > It's obviously serious since it literally renders the software unusable for > some users. If you > have a different opinion, you should really re-read the severity levels' > definitions: > https://www.debian.org/Bugs/Developer#severities > important: a bug which has a major effect on the usability of a package, > without rendering it > completely unusable to everyone. > This is literally what this is. And you're still missing the point that the issue you are seeing here is not a limitation of Debian but of the upstream software you are using. You are blaming me for something that I am not responsible for. I am neither the upstream developer of GNOME nor of Qt or the AusweisApp. I am the person who is maintaining AusweisApp in Debian. And I am shipping the software as it is provided by upstream. If upstream doesn't support usecase X, I am not the person to be blamed. > > Neither me nor the upstream maintainer are actually getting paid to provide > > this application > > on Linux or on Debian, so it's perfectly fine that we get to decide how we > > spend our free > > time. > > Nobody said otherwise. But literally with a bug
Bug#1031956: ausweisapp2: App starts hidden in the background on gnome-shell + appindicator
Am Di., 16. Jan. 2024 um 20:41 Uhr schrieb John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de>: > > Who says I am? I am running testing. Also, getting security updates > from unstable is actually > > recommended behavior, so the stuff around "FrankenDebian" is > contradicting itself. > > There is no version 2.0.x in Debian stable nor stable-backports yet, so > unless you built the > package yourself from the unstable sources or installed the Flatpak > version, you created a > "FrankenDebian". > To be quoting myself: *I am running testing**. AKA Trixie. *So no, there's no FrankenDebian at work. > > And, no, the wiki page regarding "FrankenDebian" is not contradicting > itself because security > updates are provided through debian-security. These updates are built to > target Debian stable, > so it's perfectly fine to install them without risking to break anything. > It is not contradicting itself page-wide, but wiki-wide. This is the Wiki entry for Debian Testing, where it literally recommends to do what the "FrankenDebian" Wiki page recommends not to do: https://wiki.debian.org/DebianTesting *It is a good idea to install security updates from unstable since they take extra time to reach testing and the security team only releases updates to unstable.* > > Entitled? Well that's rich. The point of the whole bug reporting system > is exactly what we > > are doing here. So yes, if you are unwilling to maintain the > package, which will always > > include getting bug reports if things don't behave as intended, then > don't do it. > > Not really. If someone steps up to maintain something, it doesn't > automatically mean they > are responsible for supporting all possible configurations that exist > within Debian which > is what you are asking for. The package works perfectly fine on KDE which > is what I am using > myself. > This is exactly what it's supposed to mean. Packages distributed by Debian are obviously required to not be broken when they hit stable. Otherwise an update wouldn't be accepted to be sent to stable. And since neither Debian with KDE nor Debian with Gnome is a separate distribution, obviously a package is supposed to work with both. That's why all KDE packages will pull in all necessary dependencies required to run in Gnome (or any other DE offered by Debian) and vice versa. If any package would be allowed in stable in a theoretical future where it only supports Wayland and not X while not all available DEs would be supporting Wayland would be very questionable. And that's just another version of this exact problem. > > The limitations around GNOME support are an upstream issue and not related > to packaging which > is what I am doing. Claiming that a particular issue that is not a serious > bug must be fixed > before the next release is something that I would call entitlement. If you > have figured out > how to fix this particular problem, you are free to send a patch to me or > upstream. That's > how it works with community-maintained software. > It's obviously serious since it literally renders the software unusable for some users. If you have a different opinion, you should really re-read the severity levels' definitions: https://www.debian.org/Bugs/Developer#severities *important: a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone.* This is literally what this is. > > Neither me nor the upstream maintainer are actually getting paid to > provide this application > on Linux or on Debian, so it's perfectly fine that we get to decide how we > spend our free > time. > Nobody said otherwise. But literally with a bug this severe v2 can't and shouldn't be accepted into stable with Trixie. And if nobody fixes it, it's questionable how long this package will be accepted to stay in the repos at all.
Bug#1031956: ausweisapp2: App starts hidden in the background on gnome-shell + appindicator
Hello, On Tue, 2024-01-16 at 15:53 +0100, Richard wrote: > Am Mo., 15. Jan. 2024 um 21:38 Uhr schrieb John Paul Adrian Glaubitz > : > > On Mon, 2024-01-15 at 19:29 +0100, Richard wrote: > > > I second this report. The app did use to work actually, but recently - > > > not sure with > > > transitioning to ausweisapp with v2.0 or later, this breaks for me too. > > > > What breaks? Please be more specific! > > > > I mean the exact same behavior. App starts, it has an entry in the tray, but > no icon, > also none in the Gnome dock and no window is opening, OK, it wasn't clear from your initial message. In any case, upstream is aware of the problem. > > > This renders the app completely unusable, at least using Gnome, which > > > should justify a > > > severity of important. It's quite irrelevant if the app is a Gnome, Gt or > > > whatever app. > > > > It is actually quite relevant because it is up to the upstream developer > > which configurations > > they support and which not. There is an endless number of Linux > > distributions and desktop > > environments, so it's naturally impossible to support all of them. > > > Sure, but it's part of Debian's repository. And if it's supposed to stay that > way, something > needs to be fixed. And for all I know this app doesn't have an official Linux > version. The > website calls it a community version. So whoever feels responsible, the > person maintaining it > in the Debian repositories and keeping it there or the person that ported the > app (not even > sure if the official app uses Qt). But the current state needs to be resolved > at least by the > time Trixie hits stable. Sure, it wouldn't be the best solution to dropp the > app altogether, > but having the app only on paper for many users isn't one either. As I said in my previous mail, this is not a packaging issue but an issue with the upstream source code itself. I am not really in the position to fix this as I am not familiar with the code. > > > > > Sure, the newer version right now is only available in testing and sid > > > (tested both, same > > > result). > > > > Errm, you shouldn't be installing packages from unstable on a stable system > > [1]. > > > > Who says I am? I am running testing. Also, getting security updates from > unstable is actually > recommended behavior, so the stuff around "FrankenDebian" is contradicting > itself. There is no version 2.0.x in Debian stable nor stable-backports yet, so unless you built the package yourself from the unstable sources or installed the Flatpak version, you created a "FrankenDebian". And, no, the wiki page regarding "FrankenDebian" is not contradicting itself because security updates are provided through debian-security. These updates are built to target Debian stable, so it's perfectly fine to install them without risking to break anything. > > > But that just makes it more important that this is sorted out before this > > > package is made > > > available in stable or stable-backports. Especially since running it as > > > Flatpak would > > > probably render half the app unusable since the communication with the > > > browser would > > > probably not work. > > > > FWIW, I am merely packaging the software for Debian. I am not the upstream > > developer. If > > you have problems with the software itself which is not related to > > packaging, you should > > direct your bug reports upstream. > > > > Unfortunately though, upstream actually does not officially support Linux, > > so they don't > > really care if it breaks. Thus, if you are really so annoyed by the > > software not working > > on your particular system, I am happy to request a removal of the package > > from the Debian > > archive mirrors so that I don't have to bother with such entitled bug > > reports anymore. > > > > Entitled? Well that's rich. The point of the whole bug reporting system is > exactly what we > are doing here. So yes, if you are unwilling to maintain the package, which > will always > include getting bug reports if things don't behave as intended, then don't do > it. Not really. If someone steps up to maintain something, it doesn't automatically mean they are responsible for supporting all possible configurations that exist within Debian which is what you are asking for. The package works perfectly fine on KDE which is what I am using myself. The limitations around GNOME support are an upstream issue and not related to packaging which is what I am doing. Claiming that a particular issue that is not a serious bug must be fixed before the next release is something that I would call entitlement. If you have figured out how to fix this particular problem, you are free to send a patch to me or upstream. That's how it works with community-maintained software. Neither me nor the upstream maintainer are actually getting paid to provide this application on Linux or on Debian, so it's perfectly fine that we get to
Bug#1031956: ausweisapp2: App starts hidden in the background on gnome-shell + appindicator
Am Mo., 15. Jan. 2024 um 21:38 Uhr schrieb John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de>: > On Mon, 2024-01-15 at 19:29 +0100, Richard wrote: > > I second this report. The app did use to work actually, but recently - > not sure with > > transitioning to ausweisapp with v2.0 or later, this breaks for me too. > > What breaks? Please be more specific! > I mean the exact same behavior. App starts, it has an entry in the tray, but no icon, also none in the Gnome dock and no window is opening, > > > This renders the app completely unusable, at least using Gnome, which > should justify a > > severity of important. It's quite irrelevant if the app is a Gnome, Gt > or whatever app. > > It is actually quite relevant because it is up to the upstream developer > which configurations > they support and which not. There is an endless number of Linux > distributions and desktop > environments, so it's naturally impossible to support all of them. > Sure, but it's part of Debian's repository. And if it's supposed to stay that way, something needs to be fixed. And for all I know this app doesn't have an official Linux version. The website calls it a community version. So whoever feels responsible, the person maintaining it in the Debian repositories and keeping it there or the person that ported the app (not even sure if the official app uses Qt). But the current state needs to be resolved at least by the time Trixie hits stable. Sure, it wouldn't be the best solution to dropp the app altogether, but having the app only on paper for many users isn't one either. > > > Sure, the newer version right now is only available in testing and sid > (tested both, same > > result). > > Errm, you shouldn't be installing packages from unstable on a stable > system [1]. > Who says I am? I am running testing. Also, getting security updates from unstable is actually recommended behavior, so the stuff around "FrankenDebian" is contradicting itself. > > > But that just makes it more important that this is sorted out before > this package is made > > available in stable or stable-backports. Especially since running it as > Flatpak would > > probably render half the app unusable since the communication with the > browser would > > probably not work. > > FWIW, I am merely packaging the software for Debian. I am not the upstream > developer. If > you have problems with the software itself which is not related to > packaging, you should > direct your bug reports upstream. > > Unfortunately though, upstream actually does not officially support Linux, > so they don't > really care if it breaks. Thus, if you are really so annoyed by the > software not working > on your particular system, I am happy to request a removal of the package > from the Debian > archive mirrors so that I don't have to bother with such entitled bug > reports anymore. > Entitled? Well that's rich. The point of the whole bug reporting system is exactly what we are doing here. So yes, if you are unwilling to maintain the package, which will always include getting bug reports if things don't behave as intended, then don't do it.
Bug#1031956: ausweisapp2: App starts hidden in the background on gnome-shell + appindicator
On Mon, 2024-01-15 at 19:29 +0100, Richard wrote: > I second this report. The app did use to work actually, but recently - not > sure with > transitioning to ausweisapp with v2.0 or later, this breaks for me too. What breaks? Please be more specific! > This renders the app completely unusable, at least using Gnome, which should > justify a > severity of important. It's quite irrelevant if the app is a Gnome, Gt or > whatever app. It is actually quite relevant because it is up to the upstream developer which configurations they support and which not. There is an endless number of Linux distributions and desktop environments, so it's naturally impossible to support all of them. > Like any app, if it's included in Debian it should not be broken beyond > usability. It's not broken beyond usability. It works for me perfectly fine. There is no guarantee you though that it will work in your particular configuration. And, as you can read from the license, Debian comes with absolutely no warranty whatsoever, so I am not sure what you are expecting. > Sure, the newer version right now is only available in testing and sid > (tested both, same > result). Errm, you shouldn't be installing packages from unstable on a stable system [1]. > But that just makes it more important that this is sorted out before this > package is made > available in stable or stable-backports. Especially since running it as > Flatpak would > probably render half the app unusable since the communication with the > browser would > probably not work. FWIW, I am merely packaging the software for Debian. I am not the upstream developer. If you have problems with the software itself which is not related to packaging, you should direct your bug reports upstream. Unfortunately though, upstream actually does not officially support Linux, so they don't really care if it breaks. Thus, if you are really so annoyed by the software not working on your particular system, I am happy to request a removal of the package from the Debian archive mirrors so that I don't have to bother with such entitled bug reports anymore. Thanks, Adrian > [1] https://wiki.debian.org/DontBreakDebian#Don.27t_make_a_FrankenDebian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1031956: ausweisapp2: App starts hidden in the background on gnome-shell + appindicator
I second this report. The app did use to work actually, but recently - not sure with transitioning to ausweisapp with v2.0 or later, this breaks for me too. This renders the app completely unusable, at least using Gnome, which should justify a severity of important. It's quite irrelevant if the app is a Gnome, Gt or whatever app. Like any app, if it's included in Debian it should not be broken beyond usability. Sure, the newer version right now is only available in testing and sid (tested both, same result). But that just makes it more important that this is sorted out before this package is made available in stable or stable-backports. Especially since running it as Flatpak would probably render half the app unusable since the communication with the browser would probably not work.
Bug#1031956: ausweisapp2: App starts hidden in the background on gnome-shell + appindicator
Hallo, Am 25.02.23 um 23:46 schrieb John Paul Adrian Glaubitz: AusweisApp2 is not a GNOME application but a Qt application and therefore I don't think you can expect the application to show GNOME-specific behavior. Unless upstream (CC'ed) wants to change this behavior in any way, I don't see any chance for this to be changed. Thanks, Adrian, for the quick reply! I don't really think it matters whether the app is a Qt or a GTK/GNOME app. A Qt app is just built with the Qt framework. All other Qt apps that I have installed behave normally as they should. And the app starting in the foreground is not GNOME-specific, I believe that is sane behaviour across desktop environments. Best, Amr
Bug#1031956: ausweisapp2: App starts hidden in the background on gnome-shell + appindicator
Hello! On Sat, 2023-02-25 at 23:31 +0100, Amr Ibrahim wrote: > On gnome-shell with gnome-shell-extension-appindicator installed, the app > starts hidden in the background without any window or an icon on the dash. > > Its appindicator (tray icon) in the top panel only offers to quit the > application, however, double-clicking on the appindicator brings the app to > the > foreground. > > The correct behaviour should be that the app normally starts in the > foreground, > and its appindicator offers to show/hide the app in the foreground/background. AusweisApp2 is not a GNOME application but a Qt application and therefore I don't think you can expect the application to show GNOME-specific behavior. Unless upstream (CC'ed) wants to change this behavior in any way, I don't see any chance for this to be changed. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1031956: ausweisapp2: App starts hidden in the background on gnome-shell + appindicator
Package: ausweisapp2 Version: 1.26.2-1 Severity: normal Tags: upstream Dear Maintainer, On gnome-shell with gnome-shell-extension-appindicator installed, the app starts hidden in the background without any window or an icon on the dash. Its appindicator (tray icon) in the top panel only offers to quit the application, however, double-clicking on the appindicator brings the app to the foreground. The correct behaviour should be that the app normally starts in the foreground, and its appindicator offers to show/hide the app in the foreground/background. Best, Amr -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing'), (100, 'unstable'), (50, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ausweisapp2 depends on: ii libc6 2.36-8 ii libhttp-parser2.9 2.9.4-5 ii libpcsclite11.9.9-1 ii libqt6core6 6.4.2+dfsg-3 ii libqt6gui6 6.4.2+dfsg-3 ii libqt6network6 6.4.2+dfsg-3 ii libqt6qml6 6.4.2+dfsg-1 ii libqt6quick66.4.2+dfsg-1 ii libqt6quickcontrols2-6 6.4.2+dfsg-1 ii libqt6statemachine6 6.4.2-1 ii libqt6svg6 6.4.2-1 ii libqt6websockets6 [qt6-websockets-abi] 6.4.2-1 ii libqt6widgets6 6.4.2+dfsg-3 ii libssl3 3.0.8-1 ii libstdc++6 12.2.0-14 ii libudev1252.5-2 ii qml6-module-qt-labs-platform6.4.2+dfsg-1 ii qml6-module-qtqml 6.4.2+dfsg-1 ii qml6-module-qtqml-models6.4.2+dfsg-1 ii qml6-module-qtqml-statemachine 6.4.2-1 ii qml6-module-qtqml-workerscript 6.4.2+dfsg-1 ii qml6-module-qtquick-controls6.4.2+dfsg-1 ii qml6-module-qtquick-layouts 6.4.2+dfsg-1 ii qml6-module-qtquick-templates 6.4.2+dfsg-1 ii qml6-module-qtquick-window 6.4.2+dfsg-1 Versions of packages ausweisapp2 recommends: pn pcsc-tools pn pcscd ausweisapp2 suggests no packages. -- no debconf information
