Bug#1071059: mousepad: segfaults at each launch !
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 control: severity -1 important control: tag - unreproducible moreinfo On Mon, 2024-05-13 at 18:28 +0200, Philippe Caillaud wrote: > Dear Maintainer, > > I use mousepad almost each day for small text editing ; since a few days > (maybe > 2 or 3), mousepad > stopped working : at each run, it crashes (segmentation fault) : > Hey Philippe, I can't reproduce here, mousepad seems to run just fine. Some ideas you might try: - - open a new file from the command line instead of just running mousepad - - try with a different user - - try with mousepad --preferences and try to tune the preferences Also try with gdb with debugging symbols installed maybe? Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmZCaMcACgkQ3rYcyPpX RFtBuwf9HO5l36+n8GawA4mvDAwah4ui8C4R27Ed7ly1e3GbMMp4a8RoZJlMoWUv 1S6VrbL4kaePF3PvLWeCY66oQ4WJxLGssa9+R1ciX59fjukUP64ToA3uy7pi5qg/ OUj79rmHLbzE8m+uFDd2JQe5xtvSDjTuXnXUdiUcb2dv4BFDoCh/CSpJ8ppFD5Nq 59W1R8fQ0+Ya3GoGy5lPcLypsC/hxoRPWPUdR83W51naNsKOTL/P7R6TJNl+kLFd BlgblvGtDlGxfwid721KvLaGuoniwBFbXHMTz9/TZ6u3DK0ZuKMGtSde4pfNfiyL fvmsm3wzzt1Qw6czO7jtWqQftS55Hg== =PTrV -END PGP SIGNATURE-
Bug#1071059: mousepad: segfaults at each launch !
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 control: severity -1 important control: tag - unreproducible moreinfo On Mon, 2024-05-13 at 18:28 +0200, Philippe Caillaud wrote: > Dear Maintainer, > > I use mousepad almost each day for small text editing ; since a few days > (maybe > 2 or 3), mousepad > stopped working : at each run, it crashes (segmentation fault) : > Hey Philippe, I can't reproduce here, mousepad seems to run just fine. Some ideas you might try: - - open a new file from the command line instead of just running mousepad - - try with a different user - - try with mousepad --preferences and try to tune the preferences Also try with gdb with debugging symbols installed maybe? Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmZCaMcACgkQ3rYcyPpX RFtBuwf9HO5l36+n8GawA4mvDAwah4ui8C4R27Ed7ly1e3GbMMp4a8RoZJlMoWUv 1S6VrbL4kaePF3PvLWeCY66oQ4WJxLGssa9+R1ciX59fjukUP64ToA3uy7pi5qg/ OUj79rmHLbzE8m+uFDd2JQe5xtvSDjTuXnXUdiUcb2dv4BFDoCh/CSpJ8ppFD5Nq 59W1R8fQ0+Ya3GoGy5lPcLypsC/hxoRPWPUdR83W51naNsKOTL/P7R6TJNl+kLFd BlgblvGtDlGxfwid721KvLaGuoniwBFbXHMTz9/TZ6u3DK0ZuKMGtSde4pfNfiyL fvmsm3wzzt1Qw6czO7jtWqQftS55Hg== =PTrV -END PGP SIGNATURE-
Bug#1071059: mousepad: segfaults at each launch !
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 control: severity -1 important control: tag - unreproducible moreinfo On Mon, 2024-05-13 at 18:28 +0200, Philippe Caillaud wrote: > Dear Maintainer, > > I use mousepad almost each day for small text editing ; since a few days > (maybe > 2 or 3), mousepad > stopped working : at each run, it crashes (segmentation fault) : > Hey Philippe, I can't reproduce here, mousepad seems to run just fine. Some ideas you might try: - - open a new file from the command line instead of just running mousepad - - try with a different user - - try with mousepad --preferences and try to tune the preferences Also try with gdb with debugging symbols installed maybe? Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmZCaMcACgkQ3rYcyPpX RFtBuwf9HO5l36+n8GawA4mvDAwah4ui8C4R27Ed7ly1e3GbMMp4a8RoZJlMoWUv 1S6VrbL4kaePF3PvLWeCY66oQ4WJxLGssa9+R1ciX59fjukUP64ToA3uy7pi5qg/ OUj79rmHLbzE8m+uFDd2JQe5xtvSDjTuXnXUdiUcb2dv4BFDoCh/CSpJ8ppFD5Nq 59W1R8fQ0+Ya3GoGy5lPcLypsC/hxoRPWPUdR83W51naNsKOTL/P7R6TJNl+kLFd BlgblvGtDlGxfwid721KvLaGuoniwBFbXHMTz9/TZ6u3DK0ZuKMGtSde4pfNfiyL fvmsm3wzzt1Qw6czO7jtWqQftS55Hg== =PTrV -END PGP SIGNATURE-
Bug#1037084: bookworm: When using gdm3 to start non-GNOME wayland sessions, PATH may be set differently
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, 2024-05-07 at 01:28 +0200, Santiago Vila wrote: > My plan for base-files is to stop overriding the PATH in /etc/profile. Note that /etc/profile is a configuration file for bourne shells. While it's a common path, it's not especially for other shells (I think zsh still uses it but not all I think) and not graphical sessions. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmY7YGgACgkQ3rYcyPpX RFvbsAf/dKuiRbySXE4iYEONIt3Exw4ZqeECQGovA/cCq7fSVpPN/qAtAM4oBFLD oKXhS+UjePwkpST2JusYsWWwlaHgNOLixC+GbNEj8eNkylQve5SM+I+VMeWly63+ Zki3Lvfvr/JasaCzWBKLcsGcb/XdRfAOvco0D7YKZuHotTOI2/XaLgyjvCcnxXqT Sp6z6/QzzbVSQYO1SL7MaghUGGpCqUuP5oHXqHjsR9bIOytg7rZoZfz/3dOmt/JI gmktQjMppVED10He/h5TtsVpOOoatHmLkD9F0DqmfssEW2HPlPgK3OLcQnoWcPH1 G5m8rjNDZtt3+87L5wewE1Cc9bLz3A== =Ravt -END PGP SIGNATURE-
Bug#1037084: bookworm: When using gdm3 to start non-GNOME wayland sessions, PATH may be set differently
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, 2024-05-07 at 01:28 +0200, Santiago Vila wrote: > My plan for base-files is to stop overriding the PATH in /etc/profile. Note that /etc/profile is a configuration file for bourne shells. While it's a common path, it's not especially for other shells (I think zsh still uses it but not all I think) and not graphical sessions. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmY7YGgACgkQ3rYcyPpX RFvbsAf/dKuiRbySXE4iYEONIt3Exw4ZqeECQGovA/cCq7fSVpPN/qAtAM4oBFLD oKXhS+UjePwkpST2JusYsWWwlaHgNOLixC+GbNEj8eNkylQve5SM+I+VMeWly63+ Zki3Lvfvr/JasaCzWBKLcsGcb/XdRfAOvco0D7YKZuHotTOI2/XaLgyjvCcnxXqT Sp6z6/QzzbVSQYO1SL7MaghUGGpCqUuP5oHXqHjsR9bIOytg7rZoZfz/3dOmt/JI gmktQjMppVED10He/h5TtsVpOOoatHmLkD9F0DqmfssEW2HPlPgK3OLcQnoWcPH1 G5m8rjNDZtt3+87L5wewE1Cc9bLz3A== =Ravt -END PGP SIGNATURE-
Re: bookworm: When using gdm3 to start non-GNOME wayland sessions, PATH may be set differently
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, 2024-05-07 at 01:28 +0200, Santiago Vila wrote: > My plan for base-files is to stop overriding the PATH in /etc/profile. Note that /etc/profile is a configuration file for bourne shells. While it's a common path, it's not especially for other shells (I think zsh still uses it but not all I think) and not graphical sessions. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmY7YGgACgkQ3rYcyPpX RFvbsAf/dKuiRbySXE4iYEONIt3Exw4ZqeECQGovA/cCq7fSVpPN/qAtAM4oBFLD oKXhS+UjePwkpST2JusYsWWwlaHgNOLixC+GbNEj8eNkylQve5SM+I+VMeWly63+ Zki3Lvfvr/JasaCzWBKLcsGcb/XdRfAOvco0D7YKZuHotTOI2/XaLgyjvCcnxXqT Sp6z6/QzzbVSQYO1SL7MaghUGGpCqUuP5oHXqHjsR9bIOytg7rZoZfz/3dOmt/JI gmktQjMppVED10He/h5TtsVpOOoatHmLkD9F0DqmfssEW2HPlPgK3OLcQnoWcPH1 G5m8rjNDZtt3+87L5wewE1Cc9bLz3A== =Ravt -END PGP SIGNATURE-
Re: Joining Xfce effort
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 2024-04-22 at 19:01 +0200, William Bonnet wrote: > Hi all, > > I am a long time Xfce user and experienced with packaging even if i am > not (yet) a DM. I would be very happy to join the xfce effort and help > with the various activities (packaging, bug fixing, documentation etc.). > > I am not sure of the best way to get in touch. Sending this email to the > list seems to make sense to me. Please don't hesitate to point me out > the right procedure to apply and prerequisite documentation to read. > > my salsa username is wbonnet It's Still 'empty' since i am only now > starting to apply to a few projects i'd like to contribute to. > Hi William, reaching out on the list is a good way, we can also be found on #debian-xfce on Libera chat. We don't really have a beginners guide, and the best would be to do stuff that you find fun/rewarding. On more *needed* stuff, something not always fun but really useful: check the Debian BTS to for old bugs and maybe check if they're still reproducible, check on upstream trackers to see if it's already reported etc. And maybe dig patches and submit them as PR on the various repositories. Regards. - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmYpLOcACgkQ3rYcyPpX RFujGQgAw5ziVAyE5nOE7PtFMDmTmSWYaMGgq6mugxWj31zaAUdLO9/c5wW7PkPq +rgFe4cB20BhfLwG4ddnfIAcJITx4x+EYbjnFRhI9+DJ7wzwbrB7c8OEX8/AVOxj ebzxgW642npje/5o4DmQOJIvE4EZbLPYie8Sic5QxVPc5oO+qkTYMgcypIlQnX6a z3BYclh/JM9F5Ymifyo/nn2lpTPGG0s9TvIV7pmTz+LW1vzVD2gNIUeqVfhw/Os8 nqHU98VoUGVnIl8+pMmfyqwnk9wgKNm8RF0UlChWKdFzmAv3FuCyZOKRK+g1ZCH5 lyfjWzMCmCzIOUVrg3Szwo0EgEZPPg== =NZNp -END PGP SIGNATURE-
Bug#1067561: FTBFS: Error: symbol `open64' is already defined
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 2024-04-19 at 00:01 +0100, Peter Green wrote: > Thanks, upstream has now accepted a patch that takes a slightly different > approach to fixing the issue. > > https://github.com/canonical/lightdm/issues/352 Yes I saw. That's why I think this should have been reported and talked directly with upstream, before the NMU, but eh... > > Could we get this uploaded to sid, so that the lightweight desktops > are installable on armel/armhf again? Yes I'll look into it. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmYiRuIACgkQ3rYcyPpX RFsQkQgA1h8bIbWp0Sj6VqgcdG/dkwKEQ6Xrcuh6gpL7Gy2BiT2d1tY4HFN94bhG FJVz9E9QOqlZt2Mo7JQ6EBYyvcTspO0T09ZU/22VjA2NdP0eSRHTiyiFXq4hyoYf OBnPpKTxq0Wp9L7Tefta7uNPIBX+lsVlw9cdwv6PIEy6jlF3xjX+B8FoK/K/fIeY FuQh5qOw/k/nnPAM4pHxYGAfRw+BNBEnI3ADFCCWDvpQSgZ9uJ9UB3wnEo50aXub dsNsXAZx3UIX2CfDBs1jXsPc/B37csOr9sJIqDn1xJKaT/Q6Yk1A/LV8uTa38wGh MykmdfDqWLT0nK4atbVH5fxjkTNdDg== =Fysh -END PGP SIGNATURE-
Bug#1067561: FTBFS: Error: symbol `open64' is already defined
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 2024-04-19 at 00:01 +0100, Peter Green wrote: > Thanks, upstream has now accepted a patch that takes a slightly different > approach to fixing the issue. > > https://github.com/canonical/lightdm/issues/352 Yes I saw. That's why I think this should have been reported and talked directly with upstream, before the NMU, but eh... > > Could we get this uploaded to sid, so that the lightweight desktops > are installable on armel/armhf again? Yes I'll look into it. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmYiRuIACgkQ3rYcyPpX RFsQkQgA1h8bIbWp0Sj6VqgcdG/dkwKEQ6Xrcuh6gpL7Gy2BiT2d1tY4HFN94bhG FJVz9E9QOqlZt2Mo7JQ6EBYyvcTspO0T09ZU/22VjA2NdP0eSRHTiyiFXq4hyoYf OBnPpKTxq0Wp9L7Tefta7uNPIBX+lsVlw9cdwv6PIEy6jlF3xjX+B8FoK/K/fIeY FuQh5qOw/k/nnPAM4pHxYGAfRw+BNBEnI3ADFCCWDvpQSgZ9uJ9UB3wnEo50aXub dsNsXAZx3UIX2CfDBs1jXsPc/B37csOr9sJIqDn1xJKaT/Q6Yk1A/LV8uTa38wGh MykmdfDqWLT0nK4atbVH5fxjkTNdDg== =Fysh -END PGP SIGNATURE-
Bug#1067561: FTBFS: Error: symbol `open64' is already defined
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 2024-04-19 at 00:01 +0100, Peter Green wrote: > Thanks, upstream has now accepted a patch that takes a slightly different > approach to fixing the issue. > > https://github.com/canonical/lightdm/issues/352 Yes I saw. That's why I think this should have been reported and talked directly with upstream, before the NMU, but eh... > > Could we get this uploaded to sid, so that the lightweight desktops > are installable on armel/armhf again? Yes I'll look into it. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmYiRuIACgkQ3rYcyPpX RFsQkQgA1h8bIbWp0Sj6VqgcdG/dkwKEQ6Xrcuh6gpL7Gy2BiT2d1tY4HFN94bhG FJVz9E9QOqlZt2Mo7JQ6EBYyvcTspO0T09ZU/22VjA2NdP0eSRHTiyiFXq4hyoYf OBnPpKTxq0Wp9L7Tefta7uNPIBX+lsVlw9cdwv6PIEy6jlF3xjX+B8FoK/K/fIeY FuQh5qOw/k/nnPAM4pHxYGAfRw+BNBEnI3ADFCCWDvpQSgZ9uJ9UB3wnEo50aXub dsNsXAZx3UIX2CfDBs1jXsPc/B37csOr9sJIqDn1xJKaT/Q6Yk1A/LV8uTa38wGh MykmdfDqWLT0nK4atbVH5fxjkTNdDg== =Fysh -END PGP SIGNATURE-
Bug#1067561: FTBFS: Error: symbol `open64' is already defined
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, 2024-04-13 at 16:11 +0100, Peter Green wrote: > > Hi, thanks for the patch. It looks a bit strong though, undefining stuff > > like > > that unconditionally. Do you have pointers to the Ubuntu bug or something? > > I've looked at upstream commits and issues and couldn't see anything > > there. > > My understanding of the issue. Hi Peter, thanks for the details. They really should be transmitted to the upstream maintainer so I took the liberty to copy/paste it to the upstream bug at https://github.com/canonical/lightdm/issues/352 Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmYcLKoACgkQ3rYcyPpX RFvszggAuBC/jVutExKct2P2GNDoxIG8UHEkD0q0nZwzY3ojcVYF4Za4+g5i9HyJ khWQgqXzwxA5aWvOn4/lxo0CUd3LyzvKf4c1bP5wEX6LO3WZmOOAwDMQSdGfF5/k jZ2tDP212sS7WRhc8cUqTagKww90WJ8O9MfhusOSzhjimArxeM5XkO2CTmKZI7/0 eU+VTahJxaqyOp8LNNVrqyJHgdkr1LdWL67crixf4sPrkIKfcibYleoaiG0pK/Oq hcm7iV956GEFTa0VIYhuskTjB2TopA85UsGNTLYMGWtS7+XZbLirpuE8ToUqVeQ2 lm5douVLT78wjf4ZBbUq58wn499Q4g== =AAyB -END PGP SIGNATURE-
Bug#1067561: FTBFS: Error: symbol `open64' is already defined
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, 2024-04-13 at 16:11 +0100, Peter Green wrote: > > Hi, thanks for the patch. It looks a bit strong though, undefining stuff > > like > > that unconditionally. Do you have pointers to the Ubuntu bug or something? > > I've looked at upstream commits and issues and couldn't see anything > > there. > > My understanding of the issue. Hi Peter, thanks for the details. They really should be transmitted to the upstream maintainer so I took the liberty to copy/paste it to the upstream bug at https://github.com/canonical/lightdm/issues/352 Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmYcLKoACgkQ3rYcyPpX RFvszggAuBC/jVutExKct2P2GNDoxIG8UHEkD0q0nZwzY3ojcVYF4Za4+g5i9HyJ khWQgqXzwxA5aWvOn4/lxo0CUd3LyzvKf4c1bP5wEX6LO3WZmOOAwDMQSdGfF5/k jZ2tDP212sS7WRhc8cUqTagKww90WJ8O9MfhusOSzhjimArxeM5XkO2CTmKZI7/0 eU+VTahJxaqyOp8LNNVrqyJHgdkr1LdWL67crixf4sPrkIKfcibYleoaiG0pK/Oq hcm7iV956GEFTa0VIYhuskTjB2TopA85UsGNTLYMGWtS7+XZbLirpuE8ToUqVeQ2 lm5douVLT78wjf4ZBbUq58wn499Q4g== =AAyB -END PGP SIGNATURE-
Bug#1067561: FTBFS: Error: symbol `open64' is already defined
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, 2024-04-13 at 16:11 +0100, Peter Green wrote: > > Hi, thanks for the patch. It looks a bit strong though, undefining stuff > > like > > that unconditionally. Do you have pointers to the Ubuntu bug or something? > > I've looked at upstream commits and issues and couldn't see anything > > there. > > My understanding of the issue. Hi Peter, thanks for the details. They really should be transmitted to the upstream maintainer so I took the liberty to copy/paste it to the upstream bug at https://github.com/canonical/lightdm/issues/352 Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmYcLKoACgkQ3rYcyPpX RFvszggAuBC/jVutExKct2P2GNDoxIG8UHEkD0q0nZwzY3ojcVYF4Za4+g5i9HyJ khWQgqXzwxA5aWvOn4/lxo0CUd3LyzvKf4c1bP5wEX6LO3WZmOOAwDMQSdGfF5/k jZ2tDP212sS7WRhc8cUqTagKww90WJ8O9MfhusOSzhjimArxeM5XkO2CTmKZI7/0 eU+VTahJxaqyOp8LNNVrqyJHgdkr1LdWL67crixf4sPrkIKfcibYleoaiG0pK/Oq hcm7iV956GEFTa0VIYhuskTjB2TopA85UsGNTLYMGWtS7+XZbLirpuE8ToUqVeQ2 lm5douVLT78wjf4ZBbUq58wn499Q4g== =AAyB -END PGP SIGNATURE-
Bug#1068543: [Pkg-swan-devel] Bug#1068543: strongswan: isolation-machine autopkgtest fails: starter IS NOT RUNNING
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, 2024-04-07 at 10:39 +0200, Paul Gevers wrote: > Your package has an autopkgtest, great. I recently added support for > isolation-machine tests on ci.debian.net for amd64 and added your > package to the list to use that. However, it fails. Can you please > investigate the situation and fix it? I copied some of the output at the > bottom of this report. Hi Paul, thanks for the report. I might try to investigate a bit but at that point honestly I don't have much clue what happens. Could you please provide a bit more context in the bug report so we have a bit more data? Because at that point I didn't really ask for anything and you're making your problem my problem, which doesn't feel really fair, to be honest. And if enabling isolation-machine breaks the test, then maybe isolation- machine needs to be fixed, or just not enabled? I cant say for sure but it looks like the easiest way for me. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmYTpxEACgkQ3rYcyPpX RFubwAf7BLanLdiDs0ERBersGiLzc0+SF2Fxid7d2k4hfANYpBNvGYuM4PHwP4Up Pizj69Ayh8tjyB0lwb0v5cnX83BLPHCVyTvIuql+HazdbnZL9/rvntPocZ9T8fr/ ecJA1X+kE3Y2Q9xhI1Q1eiCJwpkoiam3Uz4IleazoWCl/2+/cOcqRApYK7y5HGpt Jl2CD3gCNtxiY+R2ExyrzQHvdXlSPkn92gVwcrrF4G+vsiS75fKIDaPA5KQTIPHl zHNgX2Maw+kqKpc/2hQM5Hx5rMNsnU5ugFLSVov8jmgt3vXz4AuKgHQwiSfZbS2+ VBCgM/oAOtChVK3S/v8uxn4srKdfbg== =CEmc -END PGP SIGNATURE-
Bug#1067561: FTBFS: Error: symbol `open64' is already defined
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 2024-04-05 at 11:25 +0500, Andrey Rakhmatullin wrote: > > Hi, thanks for the patch. It looks a bit strong though, undefining stuff > > like > > that unconditionally. Do you have pointers to the Ubuntu bug or something? > I haven't checked their bugs manually but the changelog entry doesn't > close any: > > lightdm (1.30.0-0ubuntu12) noble; urgency=medium > > * Undefine _FILE_OFFSET_BITS and _TIME_BITS when building preload gadget > to > allow interposition of open and open64 to work. > > -- Michael Hudson-Doyle Fri, 22 Mar 2024 > 15:08:46 +1300 Thanks, I've forwarded upstream, hoping to get their insight on this. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmYPobQACgkQ3rYcyPpX RFuS/wf9GL2qVFHO2p9o7RusyuTFQYUxUQL/GsGCRXirSGPAV7p3n84NgZuLP7s0 exqt/MLArwQcKKejkKHWZE/BppUX72UUdCzIKM31PSZTsmfNvaZyomfO4NIYTzrM UBTCGdp/xA0nIjzHNjAyABLFsCunxVCodGIF3w2fnvcc6t0/RZKh8clsAUMgKKGx yfRhyuW+YyapuWAx1gXLOn1uL8C2K/MFnyGYilvv/8Fe10tt+HsOmRQygXKDOzHG NVHpcIL8beIR4yeLBzCu2/U255955I2RGTIcNP1mLkPfzGt9IiVbP9HdsXt/ZXTD OeePyswwLEdntKNJcjnn20MPpKPTHA== =s7QG -END PGP SIGNATURE-
Bug#1067561: FTBFS: Error: symbol `open64' is already defined
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 2024-04-05 at 11:25 +0500, Andrey Rakhmatullin wrote: > > Hi, thanks for the patch. It looks a bit strong though, undefining stuff > > like > > that unconditionally. Do you have pointers to the Ubuntu bug or something? > I haven't checked their bugs manually but the changelog entry doesn't > close any: > > lightdm (1.30.0-0ubuntu12) noble; urgency=medium > > * Undefine _FILE_OFFSET_BITS and _TIME_BITS when building preload gadget > to > allow interposition of open and open64 to work. > > -- Michael Hudson-Doyle Fri, 22 Mar 2024 > 15:08:46 +1300 Thanks, I've forwarded upstream, hoping to get their insight on this. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmYPobQACgkQ3rYcyPpX RFuS/wf9GL2qVFHO2p9o7RusyuTFQYUxUQL/GsGCRXirSGPAV7p3n84NgZuLP7s0 exqt/MLArwQcKKejkKHWZE/BppUX72UUdCzIKM31PSZTsmfNvaZyomfO4NIYTzrM UBTCGdp/xA0nIjzHNjAyABLFsCunxVCodGIF3w2fnvcc6t0/RZKh8clsAUMgKKGx yfRhyuW+YyapuWAx1gXLOn1uL8C2K/MFnyGYilvv/8Fe10tt+HsOmRQygXKDOzHG NVHpcIL8beIR4yeLBzCu2/U255955I2RGTIcNP1mLkPfzGt9IiVbP9HdsXt/ZXTD OeePyswwLEdntKNJcjnn20MPpKPTHA== =s7QG -END PGP SIGNATURE-
Bug#1067561: FTBFS: Error: symbol `open64' is already defined
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 2024-04-05 at 11:25 +0500, Andrey Rakhmatullin wrote: > > Hi, thanks for the patch. It looks a bit strong though, undefining stuff > > like > > that unconditionally. Do you have pointers to the Ubuntu bug or something? > I haven't checked their bugs manually but the changelog entry doesn't > close any: > > lightdm (1.30.0-0ubuntu12) noble; urgency=medium > > * Undefine _FILE_OFFSET_BITS and _TIME_BITS when building preload gadget > to > allow interposition of open and open64 to work. > > -- Michael Hudson-Doyle Fri, 22 Mar 2024 > 15:08:46 +1300 Thanks, I've forwarded upstream, hoping to get their insight on this. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmYPobQACgkQ3rYcyPpX RFuS/wf9GL2qVFHO2p9o7RusyuTFQYUxUQL/GsGCRXirSGPAV7p3n84NgZuLP7s0 exqt/MLArwQcKKejkKHWZE/BppUX72UUdCzIKM31PSZTsmfNvaZyomfO4NIYTzrM UBTCGdp/xA0nIjzHNjAyABLFsCunxVCodGIF3w2fnvcc6t0/RZKh8clsAUMgKKGx yfRhyuW+YyapuWAx1gXLOn1uL8C2K/MFnyGYilvv/8Fe10tt+HsOmRQygXKDOzHG NVHpcIL8beIR4yeLBzCu2/U255955I2RGTIcNP1mLkPfzGt9IiVbP9HdsXt/ZXTD OeePyswwLEdntKNJcjnn20MPpKPTHA== =s7QG -END PGP SIGNATURE-
Bug#1067561: FTBFS: Error: symbol `open64' is already defined
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 2024-04-01 at 00:37 +0500, Andrey Rakhmatullin wrote: > I assume the following patch from Ubuntu fixes this: > > --- a/tests/src/libsystem.c > +++ b/tests/src/libsystem.c > @@ -1,6 +1,9 @@ > #define _GNU_SOURCE > #define __USE_GNU > > +#undef _FILE_OFFSET_BITS > +#undef _TIME_BITS > + > #include > > #include Hi, thanks for the patch. It looks a bit strong though, undefining stuff like that unconditionally. Do you have pointers to the Ubuntu bug or something? I've looked at upstream commits and issues and couldn't see anything there. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmYPlZEACgkQ3rYcyPpX RFtkIwf/QZUtuSvH9DPGorTFJ/RybRfdEYONU8kLD8dOFGTXiNRcQYmSCTU/fH5B 4h0VxRWFXlF8TfBN0LmvgM+Rqzx9bT+5ZR+h8SGXL4UvH/W1qPeKIEOYYCmTtFMo nI9TBJhc501maa4PolJXSJ/OYO4AAQPmKvo+kAq0X7eTCaZcN5q1AleRDY5dBmru lHoQXy+L7T2+5N+L8wo7I7rAjLbrTEKH6CkYjNNTZx23Tp/Q6bLRELUg0f4XUusb xfAjR53aav/jCXJ8pYKKYWp60N2uRGPQcw05npjM314YlZlDXPyGn3xHQuEmQfkZ jRYE5mAmrHbtOplP9P49XX4W6cjZBQ== =9cvf -END PGP SIGNATURE-
Bug#1067561: FTBFS: Error: symbol `open64' is already defined
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 2024-04-01 at 00:37 +0500, Andrey Rakhmatullin wrote: > I assume the following patch from Ubuntu fixes this: > > --- a/tests/src/libsystem.c > +++ b/tests/src/libsystem.c > @@ -1,6 +1,9 @@ > #define _GNU_SOURCE > #define __USE_GNU > > +#undef _FILE_OFFSET_BITS > +#undef _TIME_BITS > + > #include > > #include Hi, thanks for the patch. It looks a bit strong though, undefining stuff like that unconditionally. Do you have pointers to the Ubuntu bug or something? I've looked at upstream commits and issues and couldn't see anything there. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmYPlZEACgkQ3rYcyPpX RFtkIwf/QZUtuSvH9DPGorTFJ/RybRfdEYONU8kLD8dOFGTXiNRcQYmSCTU/fH5B 4h0VxRWFXlF8TfBN0LmvgM+Rqzx9bT+5ZR+h8SGXL4UvH/W1qPeKIEOYYCmTtFMo nI9TBJhc501maa4PolJXSJ/OYO4AAQPmKvo+kAq0X7eTCaZcN5q1AleRDY5dBmru lHoQXy+L7T2+5N+L8wo7I7rAjLbrTEKH6CkYjNNTZx23Tp/Q6bLRELUg0f4XUusb xfAjR53aav/jCXJ8pYKKYWp60N2uRGPQcw05npjM314YlZlDXPyGn3xHQuEmQfkZ jRYE5mAmrHbtOplP9P49XX4W6cjZBQ== =9cvf -END PGP SIGNATURE-
Bug#1067561: FTBFS: Error: symbol `open64' is already defined
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 2024-04-01 at 00:37 +0500, Andrey Rakhmatullin wrote: > I assume the following patch from Ubuntu fixes this: > > --- a/tests/src/libsystem.c > +++ b/tests/src/libsystem.c > @@ -1,6 +1,9 @@ > #define _GNU_SOURCE > #define __USE_GNU > > +#undef _FILE_OFFSET_BITS > +#undef _TIME_BITS > + > #include > > #include Hi, thanks for the patch. It looks a bit strong though, undefining stuff like that unconditionally. Do you have pointers to the Ubuntu bug or something? I've looked at upstream commits and issues and couldn't see anything there. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmYPlZEACgkQ3rYcyPpX RFtkIwf/QZUtuSvH9DPGorTFJ/RybRfdEYONU8kLD8dOFGTXiNRcQYmSCTU/fH5B 4h0VxRWFXlF8TfBN0LmvgM+Rqzx9bT+5ZR+h8SGXL4UvH/W1qPeKIEOYYCmTtFMo nI9TBJhc501maa4PolJXSJ/OYO4AAQPmKvo+kAq0X7eTCaZcN5q1AleRDY5dBmru lHoQXy+L7T2+5N+L8wo7I7rAjLbrTEKH6CkYjNNTZx23Tp/Q6bLRELUg0f4XUusb xfAjR53aav/jCXJ8pYKKYWp60N2uRGPQcw05npjM314YlZlDXPyGn3xHQuEmQfkZ jRYE5mAmrHbtOplP9P49XX4W6cjZBQ== =9cvf -END PGP SIGNATURE-
Bug#1067755: [Pkg-gtkpod-devel] Bug#1067755: ifuse ftbfs from source, not finding the libplist configuration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Control: severity -1 important On Tue, 2024-03-26 at 12:25 +0100, Matthias Klose wrote: > Package: src:ifuse > Version: 1.1.4~git20181007.3b00243-1 > Severity: serious > Tags: sid trixie ftbfs patch > > ifuse ftbfs from source, not finding the libplist configuration. Hi Doko, ifuse doesn't seem to FTBFS in unstable or testing *yet*. We still have the old plist there, plist-2.0 is in experimental. I'm downgrading the severity then but we'll upload a similar patch when possible. Thanks for the help! Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmYORBQACgkQ3rYcyPpX RFvTzgf/Tq9Nmspfuft4z/Ie4lqgqWHupV3AyJQdjWUG5OFjiTben/cP8Uj7nVtX 1UBUlduKKMbtNmzMfoTZWajO6TJPSlY8qcQkTDhWC+4XIDf2UbtMwObHn6+90eUK 2V1c8bhvDBTWRHJjZ+ORWaHLZJxxkaghIxIGuGHNbvAuG5D+byosAPIMeu1wvySD s/n8RHKHxaCHyMmWnhw+3ZTm2bkA8AqwFbubl6CFfk36goKGf1jL6zm/Bqg5Q16/ J02esfPSPI6uXLShiRCH9xyDzKv7F5yEW3EjjFbM3sn0Nt+E7KeBR5q7rqr3fs+I uKMtsvyRYVtB1qwSql7v43eFarEGaQ== =hlEr -END PGP SIGNATURE-
Bug#1067755: [Pkg-gtkpod-devel] Bug#1067755: ifuse ftbfs from source, not finding the libplist configuration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Control: severity -1 important On Tue, 2024-03-26 at 12:25 +0100, Matthias Klose wrote: > Package: src:ifuse > Version: 1.1.4~git20181007.3b00243-1 > Severity: serious > Tags: sid trixie ftbfs patch > > ifuse ftbfs from source, not finding the libplist configuration. Hi Doko, ifuse doesn't seem to FTBFS in unstable or testing *yet*. We still have the old plist there, plist-2.0 is in experimental. I'm downgrading the severity then but we'll upload a similar patch when possible. Thanks for the help! Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmYORBQACgkQ3rYcyPpX RFvTzgf/Tq9Nmspfuft4z/Ie4lqgqWHupV3AyJQdjWUG5OFjiTben/cP8Uj7nVtX 1UBUlduKKMbtNmzMfoTZWajO6TJPSlY8qcQkTDhWC+4XIDf2UbtMwObHn6+90eUK 2V1c8bhvDBTWRHJjZ+ORWaHLZJxxkaghIxIGuGHNbvAuG5D+byosAPIMeu1wvySD s/n8RHKHxaCHyMmWnhw+3ZTm2bkA8AqwFbubl6CFfk36goKGf1jL6zm/Bqg5Q16/ J02esfPSPI6uXLShiRCH9xyDzKv7F5yEW3EjjFbM3sn0Nt+E7KeBR5q7rqr3fs+I uKMtsvyRYVtB1qwSql7v43eFarEGaQ== =hlEr -END PGP SIGNATURE-
Bug#1040417: docker-compose V1 is depreciated
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, 16 Aug 2023 20:39:25 -0300 Leandro Cunha wrote: > Hi, > > I've been talking to one of them these days and he's been busy lately. > But he said next month he should work on it. I should see if I can > help with something too. > Hi Leandro, what's the status on this? As Michael noted below, compose V1 isn't maintained upstream anymore and it'd be nice to switch to V2 in Debian. I know V2 is in Go and might bring some challenges, but having some kind of status update would be nice. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmYM+NsACgkQ3rYcyPpX RFueuAgAngIzIDQXahEH0cCH5dFNQ6UoOG/+T6SnjISECLgw7QEHdQIu/5sYn2ne B+HpMF8jvTr/JVqYhoS4k1m/cpMs7C8FPN8LFypNleQmyHBq5FWDiyYTmQsjmuwh ShmvFATRDVErVJln1OF4rUIRkJ1hUPk6dJwF3xMiN4ha/JcmpH3IUgH+qSmfgTFm WKo4/JOctknw5amrsEcpC6Li/4qJEvqjYBsTUKqtVU8bja1UHVB6YXMSUmYxwavf snd7tbV57r2CJ9jmTC3n9uDdVKIz1VHpmHrA2eboFQ5CVq+a+iavTMmuL7E6v6dZ A4ia3PEezIrsQVQfPU/uoFfmOG37iA== =Y8D4 -END PGP SIGNATURE-
Re: Bug#1056704: Major Dependency Bug in xfce4-panel-profiles
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 2024-02-19 at 17:25 +, Faulk Johnny wrote: > Has anyone taken a look at this fix by Phil Wyett? It seems straightforward > enough, I just question what stops it from being merged... Hi Johnny, xfce4-panel-profiles is under the Xfce team umbrella but maintained by Leandro Ramos . I'm adding him to the CC: in case it helps. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmXTqa0ACgkQ3rYcyPpX RFsx9AgAlHhM4dyNoDIGND70ZDMqrzAXcYNtRTQKjDfYo6/NYbxbd5kLKzeLk5cD IYBBpk0V37fsc+M9ujzLKZ1VuCAMkHpeN+RFbiAXENsIHsA1QdsFzjl24Lcn6PQk weczMxOr7tOv8u6a+7Q5rMxtgnswFQEOdl+IdpRBjYQ7E7e7BH5vw9RXfR3ircMC KKVZf2WhlPo7F7cCVF1FjxOkS9cR7+YLpjbGZ0bDTEgGCkXtvGWVjuckKgThOdvf WTHbRNrbz1i4E8nmsQ4LUKZdoWMakP+jy+HfSqIyRuvJ5LGwxbfcCjnRDQz8Wsm2 gGb0atvmx7Lb2nqN1LL8GU1M5RwBOw== =Hy7N -END PGP SIGNATURE-
Bug#1063661: xfce4: "IBus Notification: Keymap changes do not work in Plasma Wayland" but this is not Plasma Wayland
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Control: reassign -1 ibus On Sun, 2024-02-11 at 14:42 +, Simon McVittie wrote: > > Yes indeed, that's really weird. I'll try a live 12.5 cd at some point but > > if > > you have one handy can you run a dpkg -l |grep '^ibus' or something? > > No need for dpkg -l, > https://cdimage.debian.org/images/release/current-live/amd64/iso-hybrid/debian-live-12.5.0-amd64-xfce.iso.packages > says, among other things: > > ibus 1.5.27-5 > ibus-data 1.5.27-5 > ibus-gtk:amd641.5.27-5 > ibus-gtk3:amd64 1.5.27-5 > ibus-gtk4:amd64 1.5.27-5 > ibus-hangul 1.5.4-2 > ibus-m17n 1.4.19-1 A good, indeed. I'm reassigning to ibus because the message is at least misleading. Ibus maintainers: on Debian (Xfce) live images for 12.5 it seems that at startup ibus outputs an error message which shouldn't be there (no idea if it should work or not, but at least there's no Wayland or Plasma involved). > > At a guess, this is probably here because task-korean-desktop pulls in > ibus-hangul? But that has been the case since at least Debian 11... Maybe. > > > I don't really know why it would suddenly get installed but maybe some > > dependencies changed in 12.5. > > I don't remember noticing this when I helped to test XFCE live images > during the 12.0 release, but I also can't say for sure that 12.0 wasn't > affected. Ok. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmXI+x8ACgkQ3rYcyPpX RFt6lgf+JTSF38jWL8y+Rd6qZVs9fIQ+dMQHGTFJwfN36oNNRxjJqlRIp31HOdkM nEPQa7iisCK4vMjmCJ9OHIuaLr/peCR0HuJm6rbxi8CWlJQ0z2GHjJjtBU6mdYPR E2BjmC/grMf6psIk6h4eoLqcuHQWTxHikaRXIiy4xBLZcSQaA2/KdIOHDnaqyhJ4 TY2P+qsHwoDKidfXI6QcKVkzd/T/A6OG2NuMYPsojb/LI/MUz/OTiIFQRi9N8Iq0 eHNJUPz29VxeegaQjUCIWjHXxH8Jyoc5tK1PjlfkoIgeeok6A6Ek9ywb1Flogp+E lr1AthvYLeFws21deXJ2EgiWJuI6kQ== =qQew -END PGP SIGNATURE-
Bug#1063661: xfce4: "IBus Notification: Keymap changes do not work in Plasma Wayland" but this is not Plasma Wayland
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Control: reassign -1 ibus On Sun, 2024-02-11 at 14:42 +, Simon McVittie wrote: > > Yes indeed, that's really weird. I'll try a live 12.5 cd at some point but > > if > > you have one handy can you run a dpkg -l |grep '^ibus' or something? > > No need for dpkg -l, > https://cdimage.debian.org/images/release/current-live/amd64/iso-hybrid/debian-live-12.5.0-amd64-xfce.iso.packages > says, among other things: > > ibus 1.5.27-5 > ibus-data 1.5.27-5 > ibus-gtk:amd641.5.27-5 > ibus-gtk3:amd64 1.5.27-5 > ibus-gtk4:amd64 1.5.27-5 > ibus-hangul 1.5.4-2 > ibus-m17n 1.4.19-1 A good, indeed. I'm reassigning to ibus because the message is at least misleading. Ibus maintainers: on Debian (Xfce) live images for 12.5 it seems that at startup ibus outputs an error message which shouldn't be there (no idea if it should work or not, but at least there's no Wayland or Plasma involved). > > At a guess, this is probably here because task-korean-desktop pulls in > ibus-hangul? But that has been the case since at least Debian 11... Maybe. > > > I don't really know why it would suddenly get installed but maybe some > > dependencies changed in 12.5. > > I don't remember noticing this when I helped to test XFCE live images > during the 12.0 release, but I also can't say for sure that 12.0 wasn't > affected. Ok. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmXI+x8ACgkQ3rYcyPpX RFt6lgf+JTSF38jWL8y+Rd6qZVs9fIQ+dMQHGTFJwfN36oNNRxjJqlRIp31HOdkM nEPQa7iisCK4vMjmCJ9OHIuaLr/peCR0HuJm6rbxi8CWlJQ0z2GHjJjtBU6mdYPR E2BjmC/grMf6psIk6h4eoLqcuHQWTxHikaRXIiy4xBLZcSQaA2/KdIOHDnaqyhJ4 TY2P+qsHwoDKidfXI6QcKVkzd/T/A6OG2NuMYPsojb/LI/MUz/OTiIFQRi9N8Iq0 eHNJUPz29VxeegaQjUCIWjHXxH8Jyoc5tK1PjlfkoIgeeok6A6Ek9ywb1Flogp+E lr1AthvYLeFws21deXJ2EgiWJuI6kQ== =qQew -END PGP SIGNATURE-
Bug#1063661: xfce4: "IBus Notification: Keymap changes do not work in Plasma Wayland" but this is not Plasma Wayland
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, 2024-02-10 at 17:22 +, Simon McVittie wrote: > Actual result > = > > I got this notification popping up (screenshot attached, transcribed here): > > IBus Notification > - > Keymap changes do not work in Plasma Wayland at present. Please use > systemsettings5 instead. > > It seems odd to get this message when I'm running a non-Plasma, X11 desktop. Yes indeed, that's really weird. I'll try a live 12.5 cd at some point but if you have one handy can you run a dpkg -l |grep '^ibus' or something? I don't really know why it would suddenly get installed but maybe some dependencies changed in 12.5. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmXI1cEACgkQ3rYcyPpX RFukPAf+OKNnShjvh0I7idVmtNEZXKe5GEEgAGH//rxhbgKqR7g4kMmg29upevkS TGG/EjJb5Q/wDzeHUlYtJimhusNz5/HDVyGFDD44zogRkmbG9XwxrE4QlfT6EFV8 MxrglS1YXV1pGOwi6DpyTzuh6UUhbsO/9FnMFABL1NlvkkqqR6JD3bdnjq+kHTph n9viydvZjTwAQBHHF51DzauoeBwAHBRjObzp9lv5XUBx0Lcht9I3KxjzluA1V6MQ yzmQRVB+FE7xs5LVV414zsS7Q3ob2ysSCtZfPcC4K9tKx2tkWTXwhNaMKO9qNdb3 NF3YwNUfHGdOF5pWLBlIskODv096pw== =Gc5X -END PGP SIGNATURE-
Bug#1063661: xfce4: "IBus Notification: Keymap changes do not work in Plasma Wayland" but this is not Plasma Wayland
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, 2024-02-10 at 17:22 +, Simon McVittie wrote: > Actual result > = > > I got this notification popping up (screenshot attached, transcribed here): > > IBus Notification > - > Keymap changes do not work in Plasma Wayland at present. Please use > systemsettings5 instead. > > It seems odd to get this message when I'm running a non-Plasma, X11 desktop. Yes indeed, that's really weird. I'll try a live 12.5 cd at some point but if you have one handy can you run a dpkg -l |grep '^ibus' or something? I don't really know why it would suddenly get installed but maybe some dependencies changed in 12.5. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmXI1cEACgkQ3rYcyPpX RFukPAf+OKNnShjvh0I7idVmtNEZXKe5GEEgAGH//rxhbgKqR7g4kMmg29upevkS TGG/EjJb5Q/wDzeHUlYtJimhusNz5/HDVyGFDD44zogRkmbG9XwxrE4QlfT6EFV8 MxrglS1YXV1pGOwi6DpyTzuh6UUhbsO/9FnMFABL1NlvkkqqR6JD3bdnjq+kHTph n9viydvZjTwAQBHHF51DzauoeBwAHBRjObzp9lv5XUBx0Lcht9I3KxjzluA1V6MQ yzmQRVB+FE7xs5LVV414zsS7Q3ob2ysSCtZfPcC4K9tKx2tkWTXwhNaMKO9qNdb3 NF3YwNUfHGdOF5pWLBlIskODv096pw== =Gc5X -END PGP SIGNATURE-
Bug#1062783: libxfce4ui FTCBFS: fails running gtk-doc scanner
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 2024-02-05 at 20:38 +0100, Helmut Grohne wrote: > Is this line of reasoning convincing to you? Yes indeed, thanks for the explanation then. I'll import the diff to our repository. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmXCi3YACgkQ3rYcyPpX RFt4dwf/bXtVCuA9JN+o5DvMscBqVph819yDX7yz3FJJHmDxGOEJpm8qexb/buP1 I0KDPA5AVrEtMpDkJUzRfggg9wIjG1vEo//pIhEPrSZZdTnBA59aQe/2tKnfItX8 7JRORtZQ8AG3wvHg5ZfUXDlSqXgQyGFjD7doNpVpgGvUXEHcGJH5jO07OXI6UgYK OgnGsMCPxhjYlOOhZHubfzVra59i2/8B0QZicNqsA0PtTFsw7hsLbXO/jGa+dRft tbET8DzwYCuO8sjAqEMQY6z6+k0uWp3JwjjVGhaaRtDYbg4xaiD3J8Z2C7Lj5s9h uiLFEE3RHiFcIGcHR1ehXpBOm6DlVA== =f4R0 -END PGP SIGNATURE-
Bug#1062783: libxfce4ui FTCBFS: fails running gtk-doc scanner
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 2024-02-05 at 20:38 +0100, Helmut Grohne wrote: > Is this line of reasoning convincing to you? Yes indeed, thanks for the explanation then. I'll import the diff to our repository. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmXCi3YACgkQ3rYcyPpX RFt4dwf/bXtVCuA9JN+o5DvMscBqVph819yDX7yz3FJJHmDxGOEJpm8qexb/buP1 I0KDPA5AVrEtMpDkJUzRfggg9wIjG1vEo//pIhEPrSZZdTnBA59aQe/2tKnfItX8 7JRORtZQ8AG3wvHg5ZfUXDlSqXgQyGFjD7doNpVpgGvUXEHcGJH5jO07OXI6UgYK OgnGsMCPxhjYlOOhZHubfzVra59i2/8B0QZicNqsA0PtTFsw7hsLbXO/jGa+dRft tbET8DzwYCuO8sjAqEMQY6z6+k0uWp3JwjjVGhaaRtDYbg4xaiD3J8Z2C7Lj5s9h uiLFEE3RHiFcIGcHR1ehXpBOm6DlVA== =f4R0 -END PGP SIGNATURE-
Bug#1062783: libxfce4ui FTCBFS: fails running gtk-doc scanner
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, 2024-02-03 at 10:34 +0100, Helmut Grohne wrote: > libxfce4ui fails to cross build from source, because it fails running > the gtk-doc scanner with an Exec format error. This is fairly usual. > Fortunately, it also splits out its documentation to an Arch:all > package. Hence, we can disable gtk-doc in arch-only builds and thus > side-step this problem making the cross build succeed. I'm attaching a > patch for your convenience. Hi Helmut, thanks for the report and the patch. The patch looks small, and I don't know a lot about cross-building, but would it be better to use something like: ifneq (,$(filter cross,$(DEB_BUILD_PROFILES)) inside override_dh_auto_configure to only add gtk-doc when not cross-building? Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmXBAXYACgkQ3rYcyPpX RFsBbwgA6yOREFfPDlNddwz6VZIYSF0IfxZ5/A5R5QB3xu+Nxx/ZYDl5XcSxALvQ 32BRjN1+cpubRj4R1h5yJ8RN3ac+ykz0PI7TmPw7zmYodJ0fYP/aCiONJZbIbuP5 4PAR9VLfI0EZ9Du7ArYuhN/bz//MXEO1ruHHl2nEigWzzPJinu3FUWIp42U5vI76 VfYSNz3mH1gFk0rshwMqsOx3Uokb5r1L+egGV7AwL79qJqXabMGolyMwjEzEWC23 +SmyY0NWaPwJBOSDTQ2Ren3lMeRE13FlowwQ0KzclDqEHNcZqlcBalC5d3iKzfLm ng5eQv8ht3WwkwW6vVDPyqc2VE0Wag== =h+YT -END PGP SIGNATURE-
Bug#1062783: libxfce4ui FTCBFS: fails running gtk-doc scanner
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, 2024-02-03 at 10:34 +0100, Helmut Grohne wrote: > libxfce4ui fails to cross build from source, because it fails running > the gtk-doc scanner with an Exec format error. This is fairly usual. > Fortunately, it also splits out its documentation to an Arch:all > package. Hence, we can disable gtk-doc in arch-only builds and thus > side-step this problem making the cross build succeed. I'm attaching a > patch for your convenience. Hi Helmut, thanks for the report and the patch. The patch looks small, and I don't know a lot about cross-building, but would it be better to use something like: ifneq (,$(filter cross,$(DEB_BUILD_PROFILES)) inside override_dh_auto_configure to only add gtk-doc when not cross-building? Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmXBAXYACgkQ3rYcyPpX RFsBbwgA6yOREFfPDlNddwz6VZIYSF0IfxZ5/A5R5QB3xu+Nxx/ZYDl5XcSxALvQ 32BRjN1+cpubRj4R1h5yJ8RN3ac+ykz0PI7TmPw7zmYodJ0fYP/aCiONJZbIbuP5 4PAR9VLfI0EZ9Du7ArYuhN/bz//MXEO1ruHHl2nEigWzzPJinu3FUWIp42U5vI76 VfYSNz3mH1gFk0rshwMqsOx3Uokb5r1L+egGV7AwL79qJqXabMGolyMwjEzEWC23 +SmyY0NWaPwJBOSDTQ2Ren3lMeRE13FlowwQ0KzclDqEHNcZqlcBalC5d3iKzfLm ng5eQv8ht3WwkwW6vVDPyqc2VE0Wag== =h+YT -END PGP SIGNATURE-
Bug#1062998: tumbler: NMU diff for 64-bit time_t transition
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 2024-02-05 at 00:28 -0800, Steve Langasek wrote: > Well, to clarify, the patch I sent was against 4.18 in unstable; but it > applied cleanly to 4.19 in experimental (no new sonames in experimental vs > unstable), so it's been uploaded there. Ah ok. > > When the unstable uploads happen, they will be based on the version that's > current in unstable at the time. Perfect then. Thanks again! Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmXAne4ACgkQ3rYcyPpX RFs90QgA6yqQzb/h/MoSrQIPHxjPi+eU/LdgYfQlwvdXTeCWzoMmke8QHp0f2jQE 00j9LuD2TvnSPzcvBR0ZH7GYScJt+LQabIjmehCC8FmmgB+hrXwNEZussHNVl56i D+JFG5AHXohP2G+c+0LBB0u78Y+c10oweq8INh9/t2ZZO5jp366jiLTbKe1C6jq7 NRwioJa1tNIRlm3sebqJW59VdRdbybG0Q5WRZEYXg/+EmS34MZykZYyOhjpOBJ/E HzWyA48Itc0uj4juX8j/9nYu4mDPpFMUCQgNA4eY5V4b2HuNxN5j/T66YpsSw9nM XCImXWgkiGn+UMeFrqqSoX1EmatArQ== =Apdm -END PGP SIGNATURE-
Bug#1062998: tumbler: NMU diff for 64-bit time_t transition
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 2024-02-05 at 00:28 -0800, Steve Langasek wrote: > Well, to clarify, the patch I sent was against 4.18 in unstable; but it > applied cleanly to 4.19 in experimental (no new sonames in experimental vs > unstable), so it's been uploaded there. Ah ok. > > When the unstable uploads happen, they will be based on the version that's > current in unstable at the time. Perfect then. Thanks again! Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmXAne4ACgkQ3rYcyPpX RFs90QgA6yqQzb/h/MoSrQIPHxjPi+eU/LdgYfQlwvdXTeCWzoMmke8QHp0f2jQE 00j9LuD2TvnSPzcvBR0ZH7GYScJt+LQabIjmehCC8FmmgB+hrXwNEZussHNVl56i D+JFG5AHXohP2G+c+0LBB0u78Y+c10oweq8INh9/t2ZZO5jp366jiLTbKe1C6jq7 NRwioJa1tNIRlm3sebqJW59VdRdbybG0Q5WRZEYXg/+EmS34MZykZYyOhjpOBJ/E HzWyA48Itc0uj4juX8j/9nYu4mDPpFMUCQgNA4eY5V4b2HuNxN5j/T66YpsSw9nM XCImXWgkiGn+UMeFrqqSoX1EmatArQ== =Apdm -END PGP SIGNATURE-
Bug#1062998: tumbler: NMU diff for 64-bit time_t transition
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 2024-02-05 at 00:28 -0800, Steve Langasek wrote: > Well, to clarify, the patch I sent was against 4.18 in unstable; but it > applied cleanly to 4.19 in experimental (no new sonames in experimental vs > unstable), so it's been uploaded there. Ah ok. > > When the unstable uploads happen, they will be based on the version that's > current in unstable at the time. Perfect then. Thanks again! Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmXAne4ACgkQ3rYcyPpX RFs90QgA6yqQzb/h/MoSrQIPHxjPi+eU/LdgYfQlwvdXTeCWzoMmke8QHp0f2jQE 00j9LuD2TvnSPzcvBR0ZH7GYScJt+LQabIjmehCC8FmmgB+hrXwNEZussHNVl56i D+JFG5AHXohP2G+c+0LBB0u78Y+c10oweq8INh9/t2ZZO5jp366jiLTbKe1C6jq7 NRwioJa1tNIRlm3sebqJW59VdRdbybG0Q5WRZEYXg/+EmS34MZykZYyOhjpOBJ/E HzWyA48Itc0uj4juX8j/9nYu4mDPpFMUCQgNA4eY5V4b2HuNxN5j/T66YpsSw9nM XCImXWgkiGn+UMeFrqqSoX1EmatArQ== =Apdm -END PGP SIGNATURE-
Bug#1062998: tumbler: NMU diff for 64-bit time_t transition
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, 2024-02-04 at 11:14 +, Steve Langasek wrote: > > If you have any concerns about this patch, please reach out ASAP. Although > this package will be uploaded to experimental immediately, there will be a > period of several days before we begin uploads to unstable; so if information > becomes available that your package should not be included in the transition, > there is time for us to amend the planned uploads. Hi Steve, thanks for the work on the time_t migration, and thanks for the diff. I'll import it to our repository, but one thing worth noting is that the diff is for the 4.19 in experimental, which will be part of Xfce 4.20 in the future. We don't intend to upload 4.19 to unstable at all, so tumbler will stay at 4.18 (4.18.1-1+b1 precisely) for now. We surely hope that 4.20 will be released before any freeze happens, but if you need a coordinated upload to unstable it'll need to happen on 4.18. I guess we can “backport” your changes to 4.18 and upload to unstable once the go is given? Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmXAm0sACgkQ3rYcyPpX RFtKcwgAtoccvc0XqV4QhpEJdoSvXE9v4hpAlDI2h0eA9fkwr0eWJFNullmSKHZZ iQeNSU3EVwcrG0vDJD6LadB2NQqyEYne4m/UmFqGvn3194aTBo2+0f+pIA0GV/2q wW6Vjj9ObMSJGIeSRGmaiyttofsqlLM/ElbosJf8pQvxmdwpKbAm9ocqAPc4tDGo Zp0gZnCNYsEGgjF3nG/t/PyFIwh5QBfyJhUD3/yw62vp8kFVX9/77UWWjUgpUpA5 QSGR4MQDPAiEK0JVhVlkedl+Bf8G7Qh+gLUTdAJSsMMD8BKuX+xcFASISHpEW0t4 iackjFr5lq9XZ+hZOVIGXDVCETZO9g== =+nIU -END PGP SIGNATURE-
Bug#1062998: tumbler: NMU diff for 64-bit time_t transition
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, 2024-02-04 at 11:14 +, Steve Langasek wrote: > > If you have any concerns about this patch, please reach out ASAP. Although > this package will be uploaded to experimental immediately, there will be a > period of several days before we begin uploads to unstable; so if information > becomes available that your package should not be included in the transition, > there is time for us to amend the planned uploads. Hi Steve, thanks for the work on the time_t migration, and thanks for the diff. I'll import it to our repository, but one thing worth noting is that the diff is for the 4.19 in experimental, which will be part of Xfce 4.20 in the future. We don't intend to upload 4.19 to unstable at all, so tumbler will stay at 4.18 (4.18.1-1+b1 precisely) for now. We surely hope that 4.20 will be released before any freeze happens, but if you need a coordinated upload to unstable it'll need to happen on 4.18. I guess we can “backport” your changes to 4.18 and upload to unstable once the go is given? Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmXAm0sACgkQ3rYcyPpX RFtKcwgAtoccvc0XqV4QhpEJdoSvXE9v4hpAlDI2h0eA9fkwr0eWJFNullmSKHZZ iQeNSU3EVwcrG0vDJD6LadB2NQqyEYne4m/UmFqGvn3194aTBo2+0f+pIA0GV/2q wW6Vjj9ObMSJGIeSRGmaiyttofsqlLM/ElbosJf8pQvxmdwpKbAm9ocqAPc4tDGo Zp0gZnCNYsEGgjF3nG/t/PyFIwh5QBfyJhUD3/yw62vp8kFVX9/77UWWjUgpUpA5 QSGR4MQDPAiEK0JVhVlkedl+Bf8G7Qh+gLUTdAJSsMMD8BKuX+xcFASISHpEW0t4 iackjFr5lq9XZ+hZOVIGXDVCETZO9g== =+nIU -END PGP SIGNATURE-
Bug#1062998: tumbler: NMU diff for 64-bit time_t transition
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, 2024-02-04 at 11:14 +, Steve Langasek wrote: > > If you have any concerns about this patch, please reach out ASAP. Although > this package will be uploaded to experimental immediately, there will be a > period of several days before we begin uploads to unstable; so if information > becomes available that your package should not be included in the transition, > there is time for us to amend the planned uploads. Hi Steve, thanks for the work on the time_t migration, and thanks for the diff. I'll import it to our repository, but one thing worth noting is that the diff is for the 4.19 in experimental, which will be part of Xfce 4.20 in the future. We don't intend to upload 4.19 to unstable at all, so tumbler will stay at 4.18 (4.18.1-1+b1 precisely) for now. We surely hope that 4.20 will be released before any freeze happens, but if you need a coordinated upload to unstable it'll need to happen on 4.18. I guess we can “backport” your changes to 4.18 and upload to unstable once the go is given? Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmXAm0sACgkQ3rYcyPpX RFtKcwgAtoccvc0XqV4QhpEJdoSvXE9v4hpAlDI2h0eA9fkwr0eWJFNullmSKHZZ iQeNSU3EVwcrG0vDJD6LadB2NQqyEYne4m/UmFqGvn3194aTBo2+0f+pIA0GV/2q wW6Vjj9ObMSJGIeSRGmaiyttofsqlLM/ElbosJf8pQvxmdwpKbAm9ocqAPc4tDGo Zp0gZnCNYsEGgjF3nG/t/PyFIwh5QBfyJhUD3/yw62vp8kFVX9/77UWWjUgpUpA5 QSGR4MQDPAiEK0JVhVlkedl+Bf8G7Qh+gLUTdAJSsMMD8BKuX+xcFASISHpEW0t4 iackjFr5lq9XZ+hZOVIGXDVCETZO9g== =+nIU -END PGP SIGNATURE-
Bug#1024830: ERROR: Unable to connect to servers to test latency.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Control: severity -1 serious On Sat, 26 Nov 2022 08:35:40 +0100 cuboid_06_wavers wrote: > Package: speedtest-cli > Version: 2.1.3-2 > Severity: important > X-Debbugs-Cc: doczipe...@debian.home > > Dear Maintainer, > > * What led up to the situation? > > running speedtest > > * What exactly did you do (or not do) that was effective (or > ineffective)? > > running speedtest > > * What was the outcome of this action? > > ERROR: Unable to connect to servers to test latency. > > * What outcome did you expect instead? > > successful run Same thing happens here. As far as I can tell that makes the package pretty unusable so I guess the severity could be raised. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmWzjXcACgkQ3rYcyPpX RFvFUAf+LSUsnQOlBtCARMMdLQy34Ajy0LhfteH2wMYHsZhkH0hsikfYGXDMWGe7 qBlhKrjHnzqfQHwN1TCKnavNiBovyqyt0r6I+lCc/N6SqX16HcGxHNfdakdq58xr qqt+AzGrxy9HjBkPmW3Dsp9p/AM6MJifH4v/qEwrgzHEY6XbxoHibfY1aLS4msV6 9kSyiOheDct/5ySdnbNzm8O4u6FssHtTjV8YEe1i+fwojsGt8L/U+mliJU58tvpW 9U9lCIPsHVeHko+m5l/PXSYZNzPQ2a2irQ6LEqs5AxZJAkFpRelB4C0MCOxEAwPU qHPUxEaEp7YUwCdWV/xIqGBxERO/nQ== =4omU -END PGP SIGNATURE-
Bug#1059787: src:xfce4-power-manager: fails to migrate to testing for too long: uploader built arch:all binaries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 1 Jan 2024 11:31:38 +0100 Paul Gevers wrote: > Source: xfce4-power-manager > Version: 4.18.2-1 > Severity: serious > Control: close -1 4.18.3-1 > Tags: sid trixie > User: release.debian@packages.debian.org > Usertags: out-of-sync > > Dear maintainer(s), > > The Release Team considers packages that are out-of-sync between testing > and unstable for more than 30 days as having a Release Critical bug in > testing [1]. Your package src:xfce4-power-manager has been trying to > migrate for 31 days [2]. Hence, I am filing this bug. The version in > unstable has arch:all binaries built by the uploader. Unfortunately the > binNMU infrastructure doesn't support binNMU'ing arch:all (and DAK still > doesn't throw away uploaded binaries). Hence, a source-only upload is > required. Normally I do that (a no-change source-only NMU) for packages > in this state, but given the large amount of open bugs, I don't feel > comfortable taking that responsibility. > > If a package is out of sync between unstable and testing for a longer > period, this usually means that bugs in the package in testing cannot be > fixed via unstable. Additionally, blocked packages can have impact on > other packages, which makes preparing for the release more difficult. > Finally, it often exposes issues with the package and/or > its (reverse-)dependencies. We expect maintainers to fix issues that > hamper the migration of their package in a timely manner. > > This bug will trigger auto-removal when appropriate. As with all new > bugs, there will be at least 30 days before the package is auto-removed. > > I have immediately closed this bug with the version in unstable, so if > that version or a later version migrates, this bug will no longer affect > testing. I have also tagged this bug to only affect sid and trixie, so > it doesn't affect (old-)stable. > > If you believe your package is unable to migrate to testing due to > issues beyond your control, don't hesitate to contact the Release Team. > Hi Paul, thanks for the report, I didn't spot the error earlier. I mistakenly uploaded the _amd64.changes instead of the _sources.changes. I'm ready to upload a non-changes -2 rebuild, unfortunately it's apparently part of the ongoing perl transition (through libxml-parser-perl), so for now it won't build. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmWeU8cACgkQ3rYcyPpX RFvcsgf+L7nOC9HmekQJxfTGLuIs6J/8TkO8c2sFZBhpDuTTEgJq6Fqvpx3+YdJ3 w0e5kBiXSM7Q1LzB4GG6GA8SHGhqqqkh84J1XXgQy6X1YoT+L9WlKG6PK4BigNK2 GsddQvbkOM8BvmuRnxkun7mlUKWR1vi65PtHfcHQu3NXswhNCiehkgIkwZ3FrDpt JLM1RzKmP1k4MnyX/cUFT/eKoJvpjkBP5Bmk9Xt9nDca9AQwnnLcXRlRiF2/rI3N i4xGDQUGgVd5QkSGlsWoAfDFkfnxKGMgsDIlwA3wtrjG0ZjKFOsFAKmwIwxpMAEW t/N6JloFRuIihK+amWmhI0N0IXin/A== =XMyS -END PGP SIGNATURE-
Bug#1059787: src:xfce4-power-manager: fails to migrate to testing for too long: uploader built arch:all binaries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 1 Jan 2024 11:31:38 +0100 Paul Gevers wrote: > Source: xfce4-power-manager > Version: 4.18.2-1 > Severity: serious > Control: close -1 4.18.3-1 > Tags: sid trixie > User: release.debian@packages.debian.org > Usertags: out-of-sync > > Dear maintainer(s), > > The Release Team considers packages that are out-of-sync between testing > and unstable for more than 30 days as having a Release Critical bug in > testing [1]. Your package src:xfce4-power-manager has been trying to > migrate for 31 days [2]. Hence, I am filing this bug. The version in > unstable has arch:all binaries built by the uploader. Unfortunately the > binNMU infrastructure doesn't support binNMU'ing arch:all (and DAK still > doesn't throw away uploaded binaries). Hence, a source-only upload is > required. Normally I do that (a no-change source-only NMU) for packages > in this state, but given the large amount of open bugs, I don't feel > comfortable taking that responsibility. > > If a package is out of sync between unstable and testing for a longer > period, this usually means that bugs in the package in testing cannot be > fixed via unstable. Additionally, blocked packages can have impact on > other packages, which makes preparing for the release more difficult. > Finally, it often exposes issues with the package and/or > its (reverse-)dependencies. We expect maintainers to fix issues that > hamper the migration of their package in a timely manner. > > This bug will trigger auto-removal when appropriate. As with all new > bugs, there will be at least 30 days before the package is auto-removed. > > I have immediately closed this bug with the version in unstable, so if > that version or a later version migrates, this bug will no longer affect > testing. I have also tagged this bug to only affect sid and trixie, so > it doesn't affect (old-)stable. > > If you believe your package is unable to migrate to testing due to > issues beyond your control, don't hesitate to contact the Release Team. > Hi Paul, thanks for the report, I didn't spot the error earlier. I mistakenly uploaded the _amd64.changes instead of the _sources.changes. I'm ready to upload a non-changes -2 rebuild, unfortunately it's apparently part of the ongoing perl transition (through libxml-parser-perl), so for now it won't build. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmWeU8cACgkQ3rYcyPpX RFvcsgf+L7nOC9HmekQJxfTGLuIs6J/8TkO8c2sFZBhpDuTTEgJq6Fqvpx3+YdJ3 w0e5kBiXSM7Q1LzB4GG6GA8SHGhqqqkh84J1XXgQy6X1YoT+L9WlKG6PK4BigNK2 GsddQvbkOM8BvmuRnxkun7mlUKWR1vi65PtHfcHQu3NXswhNCiehkgIkwZ3FrDpt JLM1RzKmP1k4MnyX/cUFT/eKoJvpjkBP5Bmk9Xt9nDca9AQwnnLcXRlRiF2/rI3N i4xGDQUGgVd5QkSGlsWoAfDFkfnxKGMgsDIlwA3wtrjG0ZjKFOsFAKmwIwxpMAEW t/N6JloFRuIihK+amWmhI0N0IXin/A== =XMyS -END PGP SIGNATURE-
Bug#1059787: src:xfce4-power-manager: fails to migrate to testing for too long: uploader built arch:all binaries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 1 Jan 2024 11:31:38 +0100 Paul Gevers wrote: > Source: xfce4-power-manager > Version: 4.18.2-1 > Severity: serious > Control: close -1 4.18.3-1 > Tags: sid trixie > User: release.debian@packages.debian.org > Usertags: out-of-sync > > Dear maintainer(s), > > The Release Team considers packages that are out-of-sync between testing > and unstable for more than 30 days as having a Release Critical bug in > testing [1]. Your package src:xfce4-power-manager has been trying to > migrate for 31 days [2]. Hence, I am filing this bug. The version in > unstable has arch:all binaries built by the uploader. Unfortunately the > binNMU infrastructure doesn't support binNMU'ing arch:all (and DAK still > doesn't throw away uploaded binaries). Hence, a source-only upload is > required. Normally I do that (a no-change source-only NMU) for packages > in this state, but given the large amount of open bugs, I don't feel > comfortable taking that responsibility. > > If a package is out of sync between unstable and testing for a longer > period, this usually means that bugs in the package in testing cannot be > fixed via unstable. Additionally, blocked packages can have impact on > other packages, which makes preparing for the release more difficult. > Finally, it often exposes issues with the package and/or > its (reverse-)dependencies. We expect maintainers to fix issues that > hamper the migration of their package in a timely manner. > > This bug will trigger auto-removal when appropriate. As with all new > bugs, there will be at least 30 days before the package is auto-removed. > > I have immediately closed this bug with the version in unstable, so if > that version or a later version migrates, this bug will no longer affect > testing. I have also tagged this bug to only affect sid and trixie, so > it doesn't affect (old-)stable. > > If you believe your package is unable to migrate to testing due to > issues beyond your control, don't hesitate to contact the Release Team. > Hi Paul, thanks for the report, I didn't spot the error earlier. I mistakenly uploaded the _amd64.changes instead of the _sources.changes. I'm ready to upload a non-changes -2 rebuild, unfortunately it's apparently part of the ongoing perl transition (through libxml-parser-perl), so for now it won't build. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmWeU8cACgkQ3rYcyPpX RFvcsgf+L7nOC9HmekQJxfTGLuIs6J/8TkO8c2sFZBhpDuTTEgJq6Fqvpx3+YdJ3 w0e5kBiXSM7Q1LzB4GG6GA8SHGhqqqkh84J1XXgQy6X1YoT+L9WlKG6PK4BigNK2 GsddQvbkOM8BvmuRnxkun7mlUKWR1vi65PtHfcHQu3NXswhNCiehkgIkwZ3FrDpt JLM1RzKmP1k4MnyX/cUFT/eKoJvpjkBP5Bmk9Xt9nDca9AQwnnLcXRlRiF2/rI3N i4xGDQUGgVd5QkSGlsWoAfDFkfnxKGMgsDIlwA3wtrjG0ZjKFOsFAKmwIwxpMAEW t/N6JloFRuIihK+amWmhI0N0IXin/A== =XMyS -END PGP SIGNATURE-
Bug#899245: kgb-bot: support for password-protected channels
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Wed, 2023-12-13 at 09:06 -0500, Antoine Beaupré wrote:
> What I would love is some review of my perl-fu, just visually, without
> running anything. I made some comments on the MR that expand on that;
> I'm particularly wondering about the map { $_ => 1 } structure and the
> test suite.
Unfortunately I'm not fluent at all in perl :)
- --
Yves-Alexis
-BEGIN PGP SIGNATURE-
iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmV6DU8ACgkQ3rYcyPpX
RFvYeAf+P9NRJc1n3Y4RQ9ZspdD+QeMnnCSLT/a8Ay3qzJSMeyu7HcDqEyfScDkp
j48WcK0rgpJ3gwfQ/ena3Fna8p1KxxQP6l9dMz0d+CHuntQKViNaddd8YFf2FBH5
TLgo5t1nn1dwusAvm+W1Tkp8I2EYyLb7mypiAPc5OGkOLSeuDLcto5Bvd124Sc7r
N6GXmLSJOal6zOIEsWG8EfZR98hc/ME4pwMCiFM9+KsPfh4NrLKVTFgvXzOJrmJQ
zhjTrPK/obc/9gGEt2FeVBQ4V4KBnkOQ/HYEO9TyDtsoVk0MN3oE8VzmWPffUgpz
21iy+ZnU0mCUUGi13+6pTfxAjl88JA==
=+uWw
-END PGP SIGNATURE-
Bug#899245: kgb-bot: support for password-protected channels
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, 2023-12-12 at 17:18 -0500, Antoine Beaupré wrote: > On 2018-05-21 16:01:59, Yves-Alexis Perez wrote: > > subject mostly says it all, but it'd be nice if KGB could support > > password-protected IRC channels for notifications. > > The library backing KGB does support it, so it seems it's only a matter > of a few lines patch: > > https://salsa.debian.org/kgb-team/kgb/-/merge_requests/8 > > Also attached. > > Please test and report back here or, preferably, in the above merge request. Hi Antoine, since the bug is from 2018, I have to admit I don't really remember why I opened it and what channel was the target. I don't have a way to test the patch these days, but thanks for the work anyway. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmV5XmoACgkQ3rYcyPpX RFsWBQf+MggG6hvPz3hDO75MItVfsSVgrLQR+OfYiwSwCnuceSWOfLzxsaAUgA6r 7Ooo2YsqKt9Ga3qCTH96BRxTvimJHUKBhH16pG2gJP36u/OwUafMmAN0Mt+p1Ofg MSjYY8SN6zuOiwBhBk2WdAeQTL17ZEGP4lQJeH83AzYGjuUdUqAzc/z/UJWXBocd px6g9aBWNTB7IfZ1kuB1BxB7GAEAeTA14j8r6CqJewLShZoeUTBVEEddwwlGWExx IsBw8nH1Zxd7WOTfciPREkuKXWmtp5fI1Luz34P3+unbsWaZiYzlfJNjiT+ZgJs1 qEv7usw8sGqd0yzEz585gdQ2uzbXaA== =4cab -END PGP SIGNATURE-
Re: How to customize vendor-logo and vendor-emblem in derivative distro's
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, 2023-12-12 at 09:22 +, anantha...@siemens.com wrote: > CC to maintainers, > > Yves-Alexis Perez cor...@debian.org, > > Aurélien COUDERC > couc...@debian.org, > Jonathan Carter > j...@debian.org > Hi Anantha, could you please not do that? I don't think it really warrants a direct ping and, speaking for myself, didn't really motivate me to take the time do craft a reply. > I’m customizing wallpapers and logos on derivative distro based on Debian. > How to make use of vendor-logo and emblem-vendor as > Reffred here in > read.mehttps://salsa.debian.org/debian-desktop-team/desktop-base/-/blob/mast > er/debian/README.Debian#L58 > > I’m trying to understand where to place the vendor logos and emblems in the > desktop-base source so that after building the package and installing it on > the target system it get reflected instead of default Debian themes. Please > elaborate the steps to do in source before building it. Honestly I think you really should read the whole README because it explains at length how to ship a theme, providing links etc. You can look at the package content, or maybe check how other derivatives do that. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmV4vfoACgkQ3rYcyPpX RFsSyggA7N5vIEBEsT/AZqPtBgxzde+5/XcrYh8Dw99l+2XnYwaE1D9tIKU5pvML 1q7If43/W6fwHqv2UTLg3f/RVeOgolmWNG3qp0A5aRCARitGzVBFIM+guaoy9GDm 4lgIX5/Q1rI4o+5aRN8hi6F5REe4dgJAySp4XDAvwD2CsbjfE6bhEwb1fkfNF4PG +InOth5NpnCTP5wNwQmdy1IxPrDax+aYSL47Cq3JnSj+gLBMaE+WAw66kjZXHezO t+wYMnUo/ZX/J9T6v5gpqHb4TqPa1GGhTDFj3M0JLonMU5AzwSdV6n8lYgtJ4s+L Oij9x6Bu480kVirKajaUAqxiS+Af0Q== =oNR2 -END PGP SIGNATURE-
Bug#636342: release.debian.org: provide a dd-list in the transition tracker
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, 2023-11-30 at 17:06 +0100, Sebastiaan Couwenberg wrote: > The attached script can be used to generate a dd-list from the URL to > the transition tracker. > > Kind Regards, > > Hi Bas, I have to admit I was surprised to see a reply to my bug submission from more than 12 years ago. But thanks, I guess? Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmVo4X8ACgkQ3rYcyPpX RFsXMAf/WrUsLPQw958f9kNcn9D/1yXc/ekH3d+Hi9CpJxNKLWVuqIX1UDHvredQ yaMrYW4nlFP+/9LAgip8IlbC0rrTCQG0cQrQWouJ5NOpMciTFqnDzCP7HeqBH+l5 /acC3qEn8T6jhApHsaxp+p7J4/YL2l+aHZLFAcH79ZYFcaCaWsHEMm7DmLTRWU6s YIhsq9iTXRobKJ+xEuCGz05/yz+mfn/kVVJBgYn7HCPjGxiYGvjHkdY4wzjyFadi Yh+T2TF7kw14sMHvO9twFRtIscXo0mtHnjLhgZzWuRoB8bflKxxDdBscgxcx0w8Y sd/B6wvV43AptRr31bzetMc8j5kMfg== =nC7I -END PGP SIGNATURE-
Bug#636342: release.debian.org: provide a dd-list in the transition tracker
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, 2023-11-30 at 17:06 +0100, Sebastiaan Couwenberg wrote: > The attached script can be used to generate a dd-list from the URL to > the transition tracker. > > Kind Regards, > > Hi Bas, I have to admit I was surprised to see a reply to my bug submission from more than 12 years ago. But thanks, I guess? Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmVo4X8ACgkQ3rYcyPpX RFsXMAf/WrUsLPQw958f9kNcn9D/1yXc/ekH3d+Hi9CpJxNKLWVuqIX1UDHvredQ yaMrYW4nlFP+/9LAgip8IlbC0rrTCQG0cQrQWouJ5NOpMciTFqnDzCP7HeqBH+l5 /acC3qEn8T6jhApHsaxp+p7J4/YL2l+aHZLFAcH79ZYFcaCaWsHEMm7DmLTRWU6s YIhsq9iTXRobKJ+xEuCGz05/yz+mfn/kVVJBgYn7HCPjGxiYGvjHkdY4wzjyFadi Yh+T2TF7kw14sMHvO9twFRtIscXo0mtHnjLhgZzWuRoB8bflKxxDdBscgxcx0w8Y sd/B6wvV43AptRr31bzetMc8j5kMfg== =nC7I -END PGP SIGNATURE-
[SECURITY] [DSA 5560-1] strongswan security update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 - -- Debian Security Advisory DSA-5560-1 secur...@debian.org https://www.debian.org/security/Yves-Alexis Perez November 20, 2023 https://www.debian.org/security/faq - -- Package: strongswan CVE ID : CVE-2023-41913 Florian Picca reported a bug the charon-tkm daemon in strongSwan an IKE/IPsec suite. The TKM-backed version of the charon IKE daemon (charon-tkm) doesn't check the length of received Diffie-Hellman public values before copying them to a fixed-size buffer on the stack, causing a buffer overflow that could potentially be exploited for remote code execution by sending a specially crafted and unauthenticated IKE_SA_INIT message. For the oldstable distribution (bullseye), this problem has been fixed in version 5.9.1-1+deb11u4. For the stable distribution (bookworm), this problem has been fixed in version 5.9.8-5+deb12u1. We recommend that you upgrade your strongswan packages. For the detailed security status of strongswan please refer to its security tracker page at: https://security-tracker.debian.org/tracker/strongswan Further information about Debian Security Advisories, how to apply these updates to your system and frequently asked questions can be found at: https://www.debian.org/security/ Mailing list: debian-security-announce@lists.debian.org -BEGIN PGP SIGNATURE- iQKTBAEBCgB9FiEERkRAmAjBceBVMd3uBUy48xNDz0QFAmVbyg9fFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDQ2 NDQ0MDk4MDhDMTcxRTA1NTMxRERFRTA1NENCOEYzMTM0M0NGNDQACgkQBUy48xND z0QjhA//dfNonaZKJnldK6N+2CkHz6Z8JUwTGIugk57QdFc3MJcH+tjreZZmB6VJ aGJK4726bt6/1hh6N2AnQUy7jSxi/3h6FI2om4jK9QdAx/zyMQOXAmXt4Aexzm75 Pz7/ldiG7/ZAxIS8ua1GA6GTOFdQllJ5P4HdBunO5VL9m0Jd9qGZkVOVMkTu7l/j NyZgQ3RZyiqWbH1iFEvTjw6N/FrSXRr+GeHWsebdx/xNEXhKS7Hjwbw7ROZEXRno +ZRDtUrBe+QNpMx7BE+mmOF3eIZtmlgxHlR4AKtVITKAuEdkQqxminhaaZse9nOX u8sju25jJ82WUItkdNSCVqeAjlT/+ru2NoE3ZFpRs6LpRxalvMmXA6R5Eh4agoOG OpAWFt8yq0q8Ba347zm+1WCNOr30ZJRLJ8IcOlyShOJv2v5wqMg2VedwgEXOPftZ 5+vSDN+gHYr5KWS7KFxDx57Tsl6PORdla4rNie3CpEVr4aQnVnKp2mJsuPn6Ax3g Sxbh4YDGXBLA5tgKrM0kJsaFPFLk2h4UtA8nLg91HoaxIFsDyO1kdR6uIVBNpJed CsYSe9F++jqSlZl4XMKXuxDTjtNoXLm9OTsvkezhN2vTWtLYeHVY5++ckL6guSpK dC9Sd7F+SIp3O+XYilsggqMaBJCKUA8l2LJtuWls5skMUvAN4C8= =xq5Y -END PGP SIGNATURE-
Bug#1050417: lightdm-guest-session support (via Arctica Greeter) takes a long time to startup X11 guest sessions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, 2023-11-19 at 10:07 +, Mike Gabriel wrote: > I just tested this once more: It needs to be > > /run/user/*/ICEauthority-l l, > > Without that line, guest login to a MATE desktop is slloo > (with error dialog about /run/user/*/ICEauthority, without "-l"). > > With that line, login is smooth, no error dialog anymore. Ok, that's confusing (unless there's a specific syntax weirdness?). I assume you tested with: /run/user/*/ICEauthority l, and it didn't work? Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmVbxBsACgkQ3rYcyPpX RFtyIQgA235A9IBEsi1H1NRl9VROuJSPFM8k4KTXrkbNMQ28pz+e24tnnfnbFXRa 55WnPtSzP96+420dKiUuYQgoL+BmZf4zQXT9o2YQDzdXVbFhtDpy+NW8B4rOQk0j EuaSwNcAXrE/QJsGMt0JfX9vIm+X8cHorYupHEy61kIAyzpRgU5K8fAUclV6vs2L RHbxja0HAXHCsoURKbVkEPJWo6LGX+fB7N1uJSGhFNfKJcYx1CDPJGgsGnuge7MV JrjyFFrCeHyCK/zqxQZUvBKH5roI+EEoo+eHuADhCJAwqc4L/+aHa90e+on1Z8il QEajGSWgyo3HGrymx2hCEHRVxolD9w== =omCC -END PGP SIGNATURE-
Bug#1050417: lightdm-guest-session support (via Arctica Greeter) takes a long time to startup X11 guest sessions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, 2023-11-19 at 10:07 +, Mike Gabriel wrote: > I just tested this once more: It needs to be > > /run/user/*/ICEauthority-l l, > > Without that line, guest login to a MATE desktop is slloo > (with error dialog about /run/user/*/ICEauthority, without "-l"). > > With that line, login is smooth, no error dialog anymore. Ok, that's confusing (unless there's a specific syntax weirdness?). I assume you tested with: /run/user/*/ICEauthority l, and it didn't work? Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmVbxBsACgkQ3rYcyPpX RFtyIQgA235A9IBEsi1H1NRl9VROuJSPFM8k4KTXrkbNMQ28pz+e24tnnfnbFXRa 55WnPtSzP96+420dKiUuYQgoL+BmZf4zQXT9o2YQDzdXVbFhtDpy+NW8B4rOQk0j EuaSwNcAXrE/QJsGMt0JfX9vIm+X8cHorYupHEy61kIAyzpRgU5K8fAUclV6vs2L RHbxja0HAXHCsoURKbVkEPJWo6LGX+fB7N1uJSGhFNfKJcYx1CDPJGgsGnuge7MV JrjyFFrCeHyCK/zqxQZUvBKH5roI+EEoo+eHuADhCJAwqc4L/+aHa90e+on1Z8il QEajGSWgyo3HGrymx2hCEHRVxolD9w== =omCC -END PGP SIGNATURE-
[Git][security-tracker-team/security-tracker][master] allocate dsa for strongSwan
Yves-Alexis Perez pushed to branch master at Debian Security Tracker /
security-tracker
Commits:
aaf72b70 by Yves-Alexis Perez at 2023-11-20T21:30:49+01:00
allocate dsa for strongSwan
- - - - -
1 changed file:
- data/DSA/list
Changes:
=
data/DSA/list
=
@@ -1,3 +1,7 @@
+[20 Nov 2023] DSA-5560-1 strongswan - security update
+ {CVE-2023-41913}
+ [bullseye] - strongswan 5.9.1-1+deb11u4
+ [bookworm] - strongswan 5.9.8-5+deb12u1
[19 Nov 2023] DSA-5559-1 wireshark - security update
{CVE-2023-3648 CVE-2023-3649 CVE-2023-4511 CVE-2023-4512 CVE-2023-4513
CVE-2023-2906 CVE-2023-5371 CVE-2023-6174 CVE-2023-6175}
[bookworm] - wireshark 4.0.11-1~deb12u1
View it on GitLab:
https://salsa.debian.org/security-tracker-team/security-tracker/-/commit/aaf72b70f43e15cd7ce53224e96b403233f6aec5
--
View it on GitLab:
https://salsa.debian.org/security-tracker-team/security-tracker/-/commit/aaf72b70f43e15cd7ce53224e96b403233f6aec5
You're receiving this email because of your account on salsa.debian.org.
___
debian-security-tracker-commits mailing list
debian-security-tracker-commits@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-security-tracker-commits
Bug#1050417: lightdm-guest-session support (via Arctica Greeter) takes a long time to startup X11 guest sessions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, 2023-08-24 at 10:25 +, Mike Gabriel wrote: > + /run/user/*/ICEauthority-l l, Hi Mike, are you sure about the `ICEauthority-l' filename (especially the -l part)? On my system it's just ICEauthority apparently. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEyBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmVVIIoACgkQ3rYcyPpX RFvRNQf4nVUolt6huD76ZT4EcpvIDVyX4VJjZ3v5tMIxdnzWZMmSQpxsAQcgfljm zUzweJw0HczdKAbiP/0f9qDKWTEDUZ7IG7ORYz4S7V7ZCFz5IWt5x6V1styNWnlp wXFXTm7BG7tzM8efXIaW3OANyWg3ewBnLzeqW4hSjOccB14VHqioP++sHOXG9w0b ChWxCmR5jfd+wIPpluxvOVTcmMWZlirfTnc/nbUtUTa3LeBlBG+0butRQS+DrDjz ZYFVPpo0rT37WoX+Ll49kyXGDMg2J22yQS4obdS1D/7ltcVZYtcec/w9gf+5B89s 1pC8mvbWE4zYhA94YmqzYarjb9Pa =S4WQ -END PGP SIGNATURE-
Bug#1050417: lightdm-guest-session support (via Arctica Greeter) takes a long time to startup X11 guest sessions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, 2023-08-24 at 10:25 +, Mike Gabriel wrote: > + /run/user/*/ICEauthority-l l, Hi Mike, are you sure about the `ICEauthority-l' filename (especially the -l part)? On my system it's just ICEauthority apparently. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEyBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmVVIIoACgkQ3rYcyPpX RFvRNQf4nVUolt6huD76ZT4EcpvIDVyX4VJjZ3v5tMIxdnzWZMmSQpxsAQcgfljm zUzweJw0HczdKAbiP/0f9qDKWTEDUZ7IG7ORYz4S7V7ZCFz5IWt5x6V1styNWnlp wXFXTm7BG7tzM8efXIaW3OANyWg3ewBnLzeqW4hSjOccB14VHqioP++sHOXG9w0b ChWxCmR5jfd+wIPpluxvOVTcmMWZlirfTnc/nbUtUTa3LeBlBG+0butRQS+DrDjz ZYFVPpo0rT37WoX+Ll49kyXGDMg2J22yQS4obdS1D/7ltcVZYtcec/w9gf+5B89s 1pC8mvbWE4zYhA94YmqzYarjb9Pa =S4WQ -END PGP SIGNATURE-
Re: ANNOUNCE: xfce4-terminal 1.1.1 released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, 2023-10-15 at 18:51 -0700, Brian Tarricone wrote: > 1) We can put the new m4 macros in a .m4 file, prefix them with something > else so they don't conflict, and copy it into each project that uses them > and wants to do stable releases for now. Then those modules can run against > xfce4-dev-tools 4.18 again. > > 2) We can backport the new macros to the 4.18 branch of xfce4-dev-tools. > Since they're just additions, I don't think there's much risk of problems. - From my window both options would work but 2) might be more sustainable for upstream teams. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmUtgBoACgkQ3rYcyPpX RFtooQgAo+5WVYSEgbcnXC2AhtqooXXHhVoOeqoYIjR3FXfJgIuaGGepUgyeqlU4 gZQqkX4waIwZMefZk6SN7RuyKZP/+3gi89JxsH70oV1D2PdtQ1D+pGjMzFryD+++ L1pRP7SPze+mUAngo5V19XJVr2JLC6jWNa9jR7eDMzHKNWoABolHDd1RrqD93ZfH VBWbCNH4aohDSM7vBfyAmIBmqpizc555LySmQAWkWMyTkE6vRVelQht4bemAnXSw 5mwtqi/3NtiWHWhO/JSziD51QTWbD4+DudUtGnwHx53oyuO+4H3l25sdMHmeqS9b TpES4mZtbA72Ji6UOKAbGhvCVeIeig== =5L5q -END PGP SIGNATURE-
Re: ANNOUNCE: xfce4-terminal 1.1.1 released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, 2023-10-15 at 21:08 +, Gaël Bonithon wrote: > > We have the same issue for xfce4-notifyd but then I assumed 0.9 was the > > development branch leading to a 0.10 release for Xfce 4.20. So we pushed > > it to > > experimental without too much fuss. > > Xfce4-notifyd 0.9.x are not dev versions as far as I know. Well that doesn't change the fact that we can't upload it to unstable now :) > > > Well, if you have it and it's sensible, yes sure. > > See the attached patch. Not all XDT_CHECK_OPTIONAL_FEATURE features are > reproduced, but it should be enough. And since it has a limited impact, it > should continue to apply until Xfce 4.20. Thanks, I'll try that and report back (also, no need to encrypt direct mail, since it's sent in cleartext to a mailing list anyway). Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmUsY4cACgkQ3rYcyPpX RFsCbgf8DZyS9lodlomYD9TmhfdHO+cEJ0t/kyza1kEiCfAvZY8EKyKPgbT1Uqch Sw5C9KM4Cx2wwIK7rH4FxaG+cdu1XzWy7kwRfWiy7Z5MtXGHKRK3SVgfTkh86pEE ht1RTid6An2QhaFTWEjhjH+FB/KKB+hERiVE7tAtoBHeR2Dv5GLI+48DcAnFkWQN n10uShfl6vMWdDQF3vJKvX6SEAGZY/+W+mZ1WoliqLfMUoZeMHUmQ6sA0QRHpuW5 tqOoSG2BAUY5gZ4qMq4o3+4viWOs3y4VjTnZktrOWxjP5b5O95loe1fsbd6WCcS0 LR+IVnv6GWxO6BfM823a2TEw8o2ang== =QZ8z -END PGP SIGNATURE-
Re: ANNOUNCE: xfce4-terminal 1.1.1 released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, 2023-10-15 at 15:39 +, Gaël Bonithon wrote: > Hi Yves-Alexis, > Hi Gael, > It's definitely not something I was expecting, but I have to admit I'm a > little embarrassed to revert this commit. As said on IRC, I saw that Brian > had also used xdt 4.19 for xfce4-notifyd 0.9.x without anyone complaining, > so I thought it was fine (after hesitating to use xdt 4.19 right away, it's > true). We have the same issue for xfce4-notifyd but then I assumed 0.9 was the development branch leading to a 0.10 release for Xfce 4.20. So we pushed it to experimental without too much fuss. For xfce4-terminal it looks (to me) like a stable point release so I was surprised. > > Note that this is only a build dependency, which is only bumped to be able > to use XDT_CHECK_OPTIONAL_FEATURE(). This doesn't pose a problem on Arch > Linux, for example, which doesn't package any of the development versions of > Xfce. Even though I know Arch isn't Debian :) I have no idea how packaging works on Arch, and specifically Xfce. But in Debian we basically run the autoreconf thing so we need xfce4-dev-tools at build time. And we can't build-dep on an experimental package in unstable (or testing), so that's why xfce4-terminal would have to go to experimental as well. > > Would it be possible to apply a minimal patch (which I can provide) on your > side to bring xdt down to a stable version? Well, if you have it and it's sensible, yes sure. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmUsNSAACgkQ3rYcyPpX RFuXcAgA5XvQO1161PDYxbhO9EaTz1zeljUXDewNAFUtWudpo6bKR/NpdSN1Bnay 5rh4lZSzjVWizcQcSGjFNvkltdz21HBljbnpy91DJvfbZgTDaZcW+yv2kCsEF7lL UnQzMNRotpdxHPoyEgfMwpdWlSmBhNyVhfUh+MEJi5S+hGIwsWu+/daCKsyiH7yS HR4VCAIf7asJ1L0poeiN2s3Bk83txaJehsftELHLO91XxsVQa5x/Zr3j2I0B8xBJ RSwSG20SfAmw60+JREspMbe7C8M9mCqcCAixm4JbFE90JzI86XBy/oDZvVPMLWt6 bQkCbSnhFTOBtkxtCK/hblye6BsVZw== =Zsvh -END PGP SIGNATURE-
Re: ANNOUNCE: xfce4-terminal 1.1.1 released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, 2023-10-14 at 13:08 +0200, Gaël Bonithon wrote: > - build: Simplify and clarify X11/Wayland distinction Hi Gael, just so you know: it seems with that change to xfce4-terminal, it's no longer buildable with stable xfce4-dev-tools, and it will require x-d-t 4.19, so development release. For Debian, that means 1.1.1 and later will be restricted to experimental and thus have way less exposure. It'll be uploaded to unstable once 4.20 lands. I'm not sure if that's something you expected, and preferred to let you know in case it matters. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmUr+koACgkQ3rYcyPpX RFsyIwgAyMDlped/UN6weAigyX9yw4k32sTPgg1DH8jE7A/KJx0iY8A/uFB2+2dm xonmXmHtjpguLKMX7l9+Ok/fuJIOU4MDUiUOFV6ozCphs37M3yCbxcdQInaWJsGU E2d6+F95pWbYKWSrr4sOe8HZBh6YenpEZ3IOD1dZRSKfyEcayBYB766KxQDTPg0e Nlpi6fMpZ5XTVtCJw4cqGhB/EveUCroYR6G1cQuLCwCSMRShPxYBhdnQbEJZjBXr L8c85/jPyAlEes6Bad/1DV1PFtD/lX6UDbYzlYMfEeI6SH1KQ5agXn1rA18qLjZq SmYkq56HsLgs9v9E9fd89XIML92dlA== =/A2J -END PGP SIGNATURE-
Bug#1038611: Help with investigating a bug in the LightDM/logind/DDX stack
On Thu, Oct 05, 2023 at 01:06:43AM +0200, Michael Biebl wrote: > have you checked if the graphics device is properly tagged by > > /lib/udev/rules.d/71-seat.rules > > udevadm info /sys/class/drm/card0 > → E: TAGS=:seat:master-of-seat:uaccess: > Hi Michael, thanks for the tip. I'm not the one experiencing the bug, I'm handling this as LightDM maintainer. So I'm adding back the bug and the two people who were experiencing it so they can test (especially Adilson). Regards, -- Yves-Alexis Perez
Bug#1038611: Help with investigating a bug in the LightDM/logind/DDX stack
On Thu, Oct 05, 2023 at 01:06:43AM +0200, Michael Biebl wrote: > have you checked if the graphics device is properly tagged by > > /lib/udev/rules.d/71-seat.rules > > udevadm info /sys/class/drm/card0 > → E: TAGS=:seat:master-of-seat:uaccess: > Hi Michael, thanks for the tip. I'm not the one experiencing the bug, I'm handling this as LightDM maintainer. So I'm adding back the bug and the two people who were experiencing it so they can test (especially Adilson). Regards, -- Yves-Alexis Perez
Bug#1038611: lightdm: Lightdm fails to start X after upgrade to 1.32.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 2023-10-02 at 16:09 -0300, Adilson dos Santos Dantas wrote: > Ok. Running the command "loginctl show-seat seat0" with lightdm 1.26.0-8 and > this option above: > Id=seat0 > CanTTY=yes > CanGraphical=no > Sessions= > IdleHint=yes > IdleSinceHint=0 > IdleSinceHintMonotonic=0 And does LightDM starts correctly with the greeter? - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmUbGlIACgkQ3rYcyPpX RFsO8QgAtbR7v03OgNuubCD1/IK8s/quSCltCg9ctR2vWLwK8sPIUkQjx6PFv7mV nrrS/OpCU5O2ihj/7qdARhHEulLDsYwg6eosOvRccjoxYtwSdSkNR5pBU9WqWQKR 2kZqunQfcsOlMPcDbULy1QMR636f2U+oA836tUulvjBj1KS9nVoIL1yBjHdC78jY ln1xv4x3nx+/KWbISeHfSVfNnxAXhnEH7jKyoLJ6MR6xwgon48GGpLuFqhgQpz4T UbZ12PA0t9zC/YJn2MxFP7Z3HJlXTW5NNhzrBbDmT6F2vciWNdghePq1FGY7yMWV xz7Us8AyE3flcZWNmHCesqr4L36O8w== =U+h1 -END PGP SIGNATURE-
Bug#1038611: lightdm: Lightdm fails to start X after upgrade to 1.32.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 2023-10-02 at 16:09 -0300, Adilson dos Santos Dantas wrote: > Ok. Running the command "loginctl show-seat seat0" with lightdm 1.26.0-8 and > this option above: > Id=seat0 > CanTTY=yes > CanGraphical=no > Sessions= > IdleHint=yes > IdleSinceHint=0 > IdleSinceHintMonotonic=0 And does LightDM starts correctly with the greeter? - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmUbGlIACgkQ3rYcyPpX RFsO8QgAtbR7v03OgNuubCD1/IK8s/quSCltCg9ctR2vWLwK8sPIUkQjx6PFv7mV nrrS/OpCU5O2ihj/7qdARhHEulLDsYwg6eosOvRccjoxYtwSdSkNR5pBU9WqWQKR 2kZqunQfcsOlMPcDbULy1QMR636f2U+oA836tUulvjBj1KS9nVoIL1yBjHdC78jY ln1xv4x3nx+/KWbISeHfSVfNnxAXhnEH7jKyoLJ6MR6xwgon48GGpLuFqhgQpz4T UbZ12PA0t9zC/YJn2MxFP7Z3HJlXTW5NNhzrBbDmT6F2vciWNdghePq1FGY7yMWV xz7Us8AyE3flcZWNmHCesqr4L36O8w== =U+h1 -END PGP SIGNATURE-
Bug#1038611: Help with investigating a bug in the LightDM/logind/DDX stack
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi systemd/logind maintainers. I'm reaching out to you about a bug (#1038611) reported in LightDM which is likely somewhere else in the stack (maybe in logind or maybe in Xorg or the DDX). With the update to 1.32 some people experienced an issue where LightDM wouldn't start. At first it seemed linked to people using NVidia binary driver, but we also had one user on a RaspberryPi 4. Some investigation linked that to a option in lightdm.conf whose default value changed with 1.32. That option is `login-check-graphical` and seems to check if the seat (reported by logind) is marked as graphical or not. Adilson checked and indeed on their installation seat0 is not marked as graphical: > logind-check-graphical=true > loginctl show-seat seat0 > Id=seat0 > CanTTY=yes > CanGraphical=no > Sessions= > IdleHint=yes > IdleSinceHint=0 > IdleSinceHintMonotonic=0 I'm not sure why and I guess it's a bad interaction between logind and the graphical system or something, but I'm not too sure how to investigate more, so I'm adding you to the loop in case you can shine some light. At this point I don't think it's a bug in LightDM but since I'm not sure where the bug is, let's not reassign just yet. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmUbEUcACgkQ3rYcyPpX RFuqdwgAkPorc8enxSgGWMBQI+kbX+RX76fQQSxgjN/UHdfkToHFcvZxjUi8uryv J/t6cCUrH9hrs1lcxZDLcoHy5wclbhJ0f2TroUOvtrN5Hstb8dJsr4+uPKGs1Xnz nxfCR3GBl52+6TgPRjqq8/f09L9tOcOmRAjOtpXsnvnAABNZXOx6QWs7gzZ/IVza P4kq+UQBT4ECicySD7cEH0y7zpcEJaLFt7Blf2SrBHo79qMb5lRfheFsJ45lunLs uJ/ATODBMgec9DFAGyzuUbKwbRnkKYSldVlLpgA9KNxzzagUlEDCkfoBXpFE01F2 60yyKJ3I9p0f8duCDKJpY4WneKsMGQ== =Di8i -END PGP SIGNATURE-
Bug#1038611: Help with investigating a bug in the LightDM/logind/DDX stack
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi systemd/logind maintainers. I'm reaching out to you about a bug (#1038611) reported in LightDM which is likely somewhere else in the stack (maybe in logind or maybe in Xorg or the DDX). With the update to 1.32 some people experienced an issue where LightDM wouldn't start. At first it seemed linked to people using NVidia binary driver, but we also had one user on a RaspberryPi 4. Some investigation linked that to a option in lightdm.conf whose default value changed with 1.32. That option is `login-check-graphical` and seems to check if the seat (reported by logind) is marked as graphical or not. Adilson checked and indeed on their installation seat0 is not marked as graphical: > logind-check-graphical=true > loginctl show-seat seat0 > Id=seat0 > CanTTY=yes > CanGraphical=no > Sessions= > IdleHint=yes > IdleSinceHint=0 > IdleSinceHintMonotonic=0 I'm not sure why and I guess it's a bad interaction between logind and the graphical system or something, but I'm not too sure how to investigate more, so I'm adding you to the loop in case you can shine some light. At this point I don't think it's a bug in LightDM but since I'm not sure where the bug is, let's not reassign just yet. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmUbEUcACgkQ3rYcyPpX RFuqdwgAkPorc8enxSgGWMBQI+kbX+RX76fQQSxgjN/UHdfkToHFcvZxjUi8uryv J/t6cCUrH9hrs1lcxZDLcoHy5wclbhJ0f2TroUOvtrN5Hstb8dJsr4+uPKGs1Xnz nxfCR3GBl52+6TgPRjqq8/f09L9tOcOmRAjOtpXsnvnAABNZXOx6QWs7gzZ/IVza P4kq+UQBT4ECicySD7cEH0y7zpcEJaLFt7Blf2SrBHo79qMb5lRfheFsJ45lunLs uJ/ATODBMgec9DFAGyzuUbKwbRnkKYSldVlLpgA9KNxzzagUlEDCkfoBXpFE01F2 60yyKJ3I9p0f8duCDKJpY4WneKsMGQ== =Di8i -END PGP SIGNATURE-
Help with investigating a bug in the LightDM/logind/DDX stack
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi systemd/logind maintainers. I'm reaching out to you about a bug (#1038611) reported in LightDM which is likely somewhere else in the stack (maybe in logind or maybe in Xorg or the DDX). With the update to 1.32 some people experienced an issue where LightDM wouldn't start. At first it seemed linked to people using NVidia binary driver, but we also had one user on a RaspberryPi 4. Some investigation linked that to a option in lightdm.conf whose default value changed with 1.32. That option is `login-check-graphical` and seems to check if the seat (reported by logind) is marked as graphical or not. Adilson checked and indeed on their installation seat0 is not marked as graphical: > logind-check-graphical=true > loginctl show-seat seat0 > Id=seat0 > CanTTY=yes > CanGraphical=no > Sessions= > IdleHint=yes > IdleSinceHint=0 > IdleSinceHintMonotonic=0 I'm not sure why and I guess it's a bad interaction between logind and the graphical system or something, but I'm not too sure how to investigate more, so I'm adding you to the loop in case you can shine some light. At this point I don't think it's a bug in LightDM but since I'm not sure where the bug is, let's not reassign just yet. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmUbEUcACgkQ3rYcyPpX RFuqdwgAkPorc8enxSgGWMBQI+kbX+RX76fQQSxgjN/UHdfkToHFcvZxjUi8uryv J/t6cCUrH9hrs1lcxZDLcoHy5wclbhJ0f2TroUOvtrN5Hstb8dJsr4+uPKGs1Xnz nxfCR3GBl52+6TgPRjqq8/f09L9tOcOmRAjOtpXsnvnAABNZXOx6QWs7gzZ/IVza P4kq+UQBT4ECicySD7cEH0y7zpcEJaLFt7Blf2SrBHo79qMb5lRfheFsJ45lunLs uJ/ATODBMgec9DFAGyzuUbKwbRnkKYSldVlLpgA9KNxzzagUlEDCkfoBXpFE01F2 60yyKJ3I9p0f8duCDKJpY4WneKsMGQ== =Di8i -END PGP SIGNATURE-
Bug#1038611: lightdm: Lightdm fails to start X after upgrade to 1.32.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 2023-10-02 at 15:33 +0200, Yves-Alexis Perez wrote: > At that point I don't think it's a problem in LightDM and I don't really > think it's a good idea to generalize the workaround (and divert from > upstream). Just to be sure, can you test with: - - LightDM 1.26 - - login-check-graphical=true Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmUbEHAACgkQ3rYcyPpX RFv38AgA5qxC4JCT1rzmu8ibemyV21C+VQIY+W+TIXw/IOBnWOmZskFeBY7VXdvY 4+simhXUdijgULROQKSHmhefO+AXSBbLXU8CPM0n89O3FIr1Fjyraff/bj+NEZUZ FoNeSBdYI8jQ0PK5BE9zXEWgseMrCDXy3w9YmoZcliIB/gvjr2cdoeKo/9V7+1lA jTvILl5MoaHRywdLVi7F3VAKGrhVJzUJU+CzNFFG7gFEhfQIWb9vlZ9gfO+Os7bC +jsK91J5+hg8tPWBUGnVNNv8JjQusMUy2XBw6m0SzuUl8UhuaCZ+wmYYklryd0Hq h7YKEzgKNsM3Bo3kQMIqS8snTCt6/w== =MFQU -END PGP SIGNATURE-
Bug#1038611: lightdm: Lightdm fails to start X after upgrade to 1.32.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 2023-10-02 at 15:33 +0200, Yves-Alexis Perez wrote: > At that point I don't think it's a problem in LightDM and I don't really > think it's a good idea to generalize the workaround (and divert from > upstream). Just to be sure, can you test with: - - LightDM 1.26 - - login-check-graphical=true Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmUbEHAACgkQ3rYcyPpX RFv38AgA5qxC4JCT1rzmu8ibemyV21C+VQIY+W+TIXw/IOBnWOmZskFeBY7VXdvY 4+simhXUdijgULROQKSHmhefO+AXSBbLXU8CPM0n89O3FIr1Fjyraff/bj+NEZUZ FoNeSBdYI8jQ0PK5BE9zXEWgseMrCDXy3w9YmoZcliIB/gvjr2cdoeKo/9V7+1lA jTvILl5MoaHRywdLVi7F3VAKGrhVJzUJU+CzNFFG7gFEhfQIWb9vlZ9gfO+Os7bC +jsK91J5+hg8tPWBUGnVNNv8JjQusMUy2XBw6m0SzuUl8UhuaCZ+wmYYklryd0Hq h7YKEzgKNsM3Bo3kQMIqS8snTCt6/w== =MFQU -END PGP SIGNATURE-
Bug#1038611: lightdm: Lightdm fails to start X after upgrade to 1.32.0
On Mon, Oct 02, 2023 at 09:47:38AM -0300, Adilson dos Santos Dantas wrote: > Here are the results of 'loginctl show-seat seat0' from both > 'login-check-grafical' options. > > logind-check-graphical=true > loginctl show-seat seat0 > Id=seat0 > CanTTY=yes > CanGraphical=no > Sessions= > IdleHint=yes > IdleSinceHint=0 > IdleSinceHintMonotonic=0 > > logind-check-graphical=false > loginctl show-seat seat0 > Id=seat0 > ActiveSession=c1 > CanTTY=yes > CanGraphical=no > Sessions=c1 > IdleHint=no > IdleSinceHint=0 > IdleSinceHintMonotonic=0 > Thanks, so that confirm the issue on your installation: the seat is marked as non graphical for some reason (likely related to the graphics drivers but honestly I'm not too sure). At that point I don't think it's a problem in LightDM and I don't really think it's a good idea to generalize the workaround (and divert from upstream). I'll ping the logind/systemd people with a summary, in case they have an idea here. Regards, -- Yves-Alexis Perez
Bug#1038611: lightdm: Lightdm fails to start X after upgrade to 1.32.0
On Mon, Oct 02, 2023 at 09:47:38AM -0300, Adilson dos Santos Dantas wrote: > Here are the results of 'loginctl show-seat seat0' from both > 'login-check-grafical' options. > > logind-check-graphical=true > loginctl show-seat seat0 > Id=seat0 > CanTTY=yes > CanGraphical=no > Sessions= > IdleHint=yes > IdleSinceHint=0 > IdleSinceHintMonotonic=0 > > logind-check-graphical=false > loginctl show-seat seat0 > Id=seat0 > ActiveSession=c1 > CanTTY=yes > CanGraphical=no > Sessions=c1 > IdleHint=no > IdleSinceHint=0 > IdleSinceHintMonotonic=0 > Thanks, so that confirm the issue on your installation: the seat is marked as non graphical for some reason (likely related to the graphics drivers but honestly I'm not too sure). At that point I don't think it's a problem in LightDM and I don't really think it's a good idea to generalize the workaround (and divert from upstream). I'll ping the logind/systemd people with a summary, in case they have an idea here. Regards, -- Yves-Alexis Perez
Bug#1038611: lightdm: Lightdm fails to start X after upgrade to 1.32.0
On Sun, Oct 01, 2023 at 08:58:32PM -0300, Adilson dos Santos Dantas wrote: > Hi. > > Here are the logs with and without the "logind-check-graphical=false" > option. > > With this opinion, a new seat is added and no seat is added when this > option is commented. Thanks for the log. I'm unsure if there's no seat at all or if the seat is marked as "non graphical" in logind. In both cases and before logging in as an user, so when lightdm is started and a greeter is displayed (with =false) or you get the black screen (with =true), could you check the loginctl output (as root)? I'm not too sure where to look, but at least: - loginctl - loginctl list-seats - loginctl show-seat seat0 Regards, -- Yves-Alexis
Bug#1038611: lightdm: Lightdm fails to start X after upgrade to 1.32.0
On Sun, Oct 01, 2023 at 08:58:32PM -0300, Adilson dos Santos Dantas wrote: > Hi. > > Here are the logs with and without the "logind-check-graphical=false" > option. > > With this opinion, a new seat is added and no seat is added when this > option is commented. Thanks for the log. I'm unsure if there's no seat at all or if the seat is marked as "non graphical" in logind. In both cases and before logging in as an user, so when lightdm is started and a greeter is displayed (with =false) or you get the black screen (with =true), could you check the loginctl output (as root)? I'm not too sure where to look, but at least: - loginctl - loginctl list-seats - loginctl show-seat seat0 Regards, -- Yves-Alexis
Bug#1038611: lightdm: Lightdm fails to start X after upgrade to 1.32.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, 2023-08-08 at 01:25 -0500, Steev Klimaszewski wrote: > I'm running into a very similar issue as the original submitter, > however, when I'm running into it, I am *not* using the nVidia binary > driver, but I am using a custom 5.15.44 kernel for a Raspberry Pi. > What I found after digging for quite a while, was that, yes, > downgrading to 1.26 would start Xorg, and upgrading to 1.32 would > cause it to not start Xorg. After diffing the contents between 1.26 > and 1.32, it seems that the option "logind-check-graphical" has > changed from the default of false, to a default of true. > > Simply adding in > > logind-check-graphical=false > > under the [LightDM] heading in /etc/lightdm/lightdm.conf shows it as > starting again. This happened for me on both Pi3 and Pi4, armhf and > arm64. I'm not entirely sure why this is the case, and the kernel > hasn't changed on these devices since 2022-07-03 when we last built > the kernel for them. Perhaps the original submitter could also see if > changing that option works for them with the nVidia binary driver? Hi Steev and Adilson, so it might be linked to https://github.com/canonical/lightdm/issues/263 Looking at a bug linked from above (https://github.com/canonical/lightdm/issues/165) it looks like the default was changed in order to fix a race condition or something. The documentation says: # logind-check-graphical = True to on start seats that are marked as graphical by logind Could you check the lightdm.log and check if you have messages about seats beeing added and whether it's graphical or not (you can add logs here). With both value for the logind-check-graphical option. It looks to me that there's an issue deeper in the stacks (in the NVIDIA stuff or in the RPi graphical stuff) and maybe the seats arent't marked as graphical or something. So it's ok to tune the option locally as a workaround, but I'm not sure about reverting it globally. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmUZgJIACgkQ3rYcyPpX RFtkzAgAvSJE1yDFRCZrdI/1zGTW/SWH2KUXuxpYw8b+LrwcvkLBVwSzQhkxKkS4 rd8VUjRRXVcaPXTrPJxeKqObAAYN2iUhiFCKdYAYUxdvlIPWxOkQEf8CeLm/AG6f rCaHMmQNZY5SFkTCQ5AGUzH38IAp3a4Sdn3E+x1xVMsiYGn6h5I/z0eDcx5135mP omuBRUYZGnoTfsApetBOQCK7pMzUJX1QRxdaiMjLZCUEsKjwoJc/6ZaLSHB4goYQ AXAYcrc4jOhYfv6KFqbaxEBWxR/gbdG8+YBh2u8a44KEniJgXl+T4FEKfTA1poxc muyLJuBzqpHqGyfOvZS73TjWPVZcHw== =Lrpk -END PGP SIGNATURE-
Bug#1038611: lightdm: Lightdm fails to start X after upgrade to 1.32.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, 2023-08-08 at 01:25 -0500, Steev Klimaszewski wrote: > I'm running into a very similar issue as the original submitter, > however, when I'm running into it, I am *not* using the nVidia binary > driver, but I am using a custom 5.15.44 kernel for a Raspberry Pi. > What I found after digging for quite a while, was that, yes, > downgrading to 1.26 would start Xorg, and upgrading to 1.32 would > cause it to not start Xorg. After diffing the contents between 1.26 > and 1.32, it seems that the option "logind-check-graphical" has > changed from the default of false, to a default of true. > > Simply adding in > > logind-check-graphical=false > > under the [LightDM] heading in /etc/lightdm/lightdm.conf shows it as > starting again. This happened for me on both Pi3 and Pi4, armhf and > arm64. I'm not entirely sure why this is the case, and the kernel > hasn't changed on these devices since 2022-07-03 when we last built > the kernel for them. Perhaps the original submitter could also see if > changing that option works for them with the nVidia binary driver? Hi Steev and Adilson, so it might be linked to https://github.com/canonical/lightdm/issues/263 Looking at a bug linked from above (https://github.com/canonical/lightdm/issues/165) it looks like the default was changed in order to fix a race condition or something. The documentation says: # logind-check-graphical = True to on start seats that are marked as graphical by logind Could you check the lightdm.log and check if you have messages about seats beeing added and whether it's graphical or not (you can add logs here). With both value for the logind-check-graphical option. It looks to me that there's an issue deeper in the stacks (in the NVIDIA stuff or in the RPi graphical stuff) and maybe the seats arent't marked as graphical or something. So it's ok to tune the option locally as a workaround, but I'm not sure about reverting it globally. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmUZgJIACgkQ3rYcyPpX RFtkzAgAvSJE1yDFRCZrdI/1zGTW/SWH2KUXuxpYw8b+LrwcvkLBVwSzQhkxKkS4 rd8VUjRRXVcaPXTrPJxeKqObAAYN2iUhiFCKdYAYUxdvlIPWxOkQEf8CeLm/AG6f rCaHMmQNZY5SFkTCQ5AGUzH38IAp3a4Sdn3E+x1xVMsiYGn6h5I/z0eDcx5135mP omuBRUYZGnoTfsApetBOQCK7pMzUJX1QRxdaiMjLZCUEsKjwoJc/6ZaLSHB4goYQ AXAYcrc4jOhYfv6KFqbaxEBWxR/gbdG8+YBh2u8a44KEniJgXl+T4FEKfTA1poxc muyLJuBzqpHqGyfOvZS73TjWPVZcHw== =Lrpk -END PGP SIGNATURE-
Bug#1052718: [Pkg-swan-devel] Bug#1052718: strongswan FTBFS when systemd.pc changes systemdsystemunitdir
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, 2023-09-26 at 12:54 +0200, Helmut Grohne wrote: > We want to change the value of systemdsystemunitdir in systemd.pc to > point below /usr. strongswan's upstream build system consumes this > variable while the packaging hard codes its current value. As we change > it, strongswan will FTBFS. Consider applying the attached patch to avoid > this failure. Hey Helmut, thanks for the patch, it'll be part of the next upload. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmUV06UACgkQ3rYcyPpX RFsoGQf/UwyBWg+w+lcxdCzqYyzAAPRHDmqJGMHoXHs1U/oMAh0wOojvKBBZp4IF eyejYo2BUT4Kl5023IbYeTSliXK1NiM6/eUY09yiLbCFyqBbUi8End/lKwex4r8U i6qKxVZc18PnAVdYj8RgIx9LZ/anti/6ntSrXOSotynqM4JO1vZ4dzOVggbDaAbO Kk1on2EbYxm7wgCWG52uyC5p8WIOVKOBUXrC8S9Ti4qZ05Jg6S+P5vU/9HovwqsH vKE3IukiEZzrhTGx1w9SmrYac+BjaVwlXLP6oUVPWWTHCbmTewnTvpIE+GXnvjic GAzcKiPBlyzoZQiLzoxm737At4mbgw== =Sp2r -END PGP SIGNATURE-
Bug#1049418: xfce4-pulseaudio-plugin: Please loosen Recommends, and allow pipewire-pulse as an alternative to pulseaudio
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 2023-09-08 at 10:53 +0700, Arnaud Rebillout wrote: > Hope that it answers all your questions! Hi Arnaud, thanks for the very detailed information, that's much helpful. And it does make sense to use alternate dependencies indeed. But here there might be some differences. In your initial mail you say: > A minor issue, in Kali, is that we still have to install pulseaudio, due > to the fact that xfce4-pulseaudio-plugin depends on pulseaudio. So > pulseaudio must be installed, even though it's not running. > > On the same line, we also can't install the metapackage pipewire-audio, > since it Conflicts with pulseaudio, hence breaks the xfce4 metapackage. > > Changing the Recommends field of xfce4-pulseaudio-plugin to > 'pulseaudio|pipewire-pulse' would solve those two issues, and more > generally it would make life easier for people who want to switch to > pipewire and remove pulseaudio. I don't think that's completely true. Recommends: can (and are, on Debian at least) installed by default (when doing apt install or apt-get install) but you can totally remove it afterwards. So I guess the only relevant use case is when a user - - has pipewire-pulse installed - - has *not* pulseaudio installed - - runs apt install xfce4-pulseaudio-plugin (or xfce4-plugins) In that case, with the alternate recommends I'd assume it would consider the recommends already satisfied and won't try to install pulseaudio. I don't think that's really what Kali is concerned about, but rather the default installation. I'm not sure how Kali does it but afair on Debian the initial installation (using d-i but also I think when using debootstrap or other tools) doesn't install recommends by default (because it still uses tasksel). In any case, the recommends shouldn't hurt us so I'll add it at some point. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmT6yY8ACgkQ3rYcyPpX RFunCAgArhnM9JAKh/I0yj/sbGjuMPVTd3nZzjp66ldqMLDi726oWIsgeQ6/8iQ+ h+kXpQPJ9z/4+X3J/in7uc1nTHSh0NpJBSbN72jgpLvvHyKJn+OxWGyuqpCgchhE Iq3go4yUE4+dWUQfqpLk5P1j4QmtYuHtMr6F5XxWzY29yFKIv8nxBPBnVanihsYj mbIRed3DlDiKPTn/ExBqAHbmCf2vJk078hqmtRwrqGhmDnuoyLxe/6GGdwQxey1z SmGhIbpoaFVCdp8yJmSKEwDkR5qOqWK7yf4RUbsAxcvvt6ZE0aUlfHCqVU1U0iUn 0zTrbPa/72fLOe4CQmKKaMoFXtewEA== =cy9F -END PGP SIGNATURE-
Bug#1049418: xfce4-pulseaudio-plugin: Please loosen Recommends, and allow pipewire-pulse as an alternative to pulseaudio
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 2023-09-08 at 10:53 +0700, Arnaud Rebillout wrote: > Hope that it answers all your questions! Hi Arnaud, thanks for the very detailed information, that's much helpful. And it does make sense to use alternate dependencies indeed. But here there might be some differences. In your initial mail you say: > A minor issue, in Kali, is that we still have to install pulseaudio, due > to the fact that xfce4-pulseaudio-plugin depends on pulseaudio. So > pulseaudio must be installed, even though it's not running. > > On the same line, we also can't install the metapackage pipewire-audio, > since it Conflicts with pulseaudio, hence breaks the xfce4 metapackage. > > Changing the Recommends field of xfce4-pulseaudio-plugin to > 'pulseaudio|pipewire-pulse' would solve those two issues, and more > generally it would make life easier for people who want to switch to > pipewire and remove pulseaudio. I don't think that's completely true. Recommends: can (and are, on Debian at least) installed by default (when doing apt install or apt-get install) but you can totally remove it afterwards. So I guess the only relevant use case is when a user - - has pipewire-pulse installed - - has *not* pulseaudio installed - - runs apt install xfce4-pulseaudio-plugin (or xfce4-plugins) In that case, with the alternate recommends I'd assume it would consider the recommends already satisfied and won't try to install pulseaudio. I don't think that's really what Kali is concerned about, but rather the default installation. I'm not sure how Kali does it but afair on Debian the initial installation (using d-i but also I think when using debootstrap or other tools) doesn't install recommends by default (because it still uses tasksel). In any case, the recommends shouldn't hurt us so I'll add it at some point. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmT6yY8ACgkQ3rYcyPpX RFunCAgArhnM9JAKh/I0yj/sbGjuMPVTd3nZzjp66ldqMLDi726oWIsgeQ6/8iQ+ h+kXpQPJ9z/4+X3J/in7uc1nTHSh0NpJBSbN72jgpLvvHyKJn+OxWGyuqpCgchhE Iq3go4yUE4+dWUQfqpLk5P1j4QmtYuHtMr6F5XxWzY29yFKIv8nxBPBnVanihsYj mbIRed3DlDiKPTn/ExBqAHbmCf2vJk078hqmtRwrqGhmDnuoyLxe/6GGdwQxey1z SmGhIbpoaFVCdp8yJmSKEwDkR5qOqWK7yf4RUbsAxcvvt6ZE0aUlfHCqVU1U0iUn 0zTrbPa/72fLOe4CQmKKaMoFXtewEA== =cy9F -END PGP SIGNATURE-
Bug#1049418: xfce4-pulseaudio-plugin: Please loosen Recommends, and allow pipewire-pulse as an alternative to pulseaudio
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, 2023-08-15 at 20:09 +0700, Arnaud Rebillout wrote: > Changing the Recommends field of xfce4-pulseaudio-plugin to > 'pulseaudio|pipewire-pulse' would solve those two issues, and more > generally it would make life easier for people who want to switch to > pipewire and remove pulseaudio. Hi Arnaud, I have no idea what pipewire is, could you explain a bit here what it is? Is it a drop-in for pulseaudio or something? Because xfce4-pulseaudio-plugin is (by definition) really linked to pulseaudio. And if we have a drop-in replacement, does it really make sense to have every pulseaudio depending package to use alternate dependencies? Isn't there a way to centralize this change? Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmT6JLkACgkQ3rYcyPpX RFuLXggAsSGLse5tsY/463r+nLS6t5RVkIgIr3XLQHltMn5TINpXJIONAS38XXmT wqBAkj6oQcOJhj+5qjWtG8eH+eTtpPXhEb/l/1Sl2/7/Xi4QGtQ92ZiKF2lmKwfi uOZos/w9rPyotUb/2bXnFlXVlOoc2KCWfRRYHMwj5XwgnXsmm9WcKmUJw8LIH091 WC0tjIPmm4pT2DkrwZQ/vPgUNOt+2OCPooqmzfuJvucE37iW8tLA8EEJZjyKlduA PFIlT0czS30Y7C/kJrRzmcryqnyDKmPCtULR5LndiGx2hZojYrLfsiuXD/sbJkT+ VEdAF3NwYJ+lR2VCL83plPjiQ0HAig== =83EC -END PGP SIGNATURE-
Bug#1049418: xfce4-pulseaudio-plugin: Please loosen Recommends, and allow pipewire-pulse as an alternative to pulseaudio
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, 2023-08-15 at 20:09 +0700, Arnaud Rebillout wrote: > Changing the Recommends field of xfce4-pulseaudio-plugin to > 'pulseaudio|pipewire-pulse' would solve those two issues, and more > generally it would make life easier for people who want to switch to > pipewire and remove pulseaudio. Hi Arnaud, I have no idea what pipewire is, could you explain a bit here what it is? Is it a drop-in for pulseaudio or something? Because xfce4-pulseaudio-plugin is (by definition) really linked to pulseaudio. And if we have a drop-in replacement, does it really make sense to have every pulseaudio depending package to use alternate dependencies? Isn't there a way to centralize this change? Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmT6JLkACgkQ3rYcyPpX RFuLXggAsSGLse5tsY/463r+nLS6t5RVkIgIr3XLQHltMn5TINpXJIONAS38XXmT wqBAkj6oQcOJhj+5qjWtG8eH+eTtpPXhEb/l/1Sl2/7/Xi4QGtQ92ZiKF2lmKwfi uOZos/w9rPyotUb/2bXnFlXVlOoc2KCWfRRYHMwj5XwgnXsmm9WcKmUJw8LIH091 WC0tjIPmm4pT2DkrwZQ/vPgUNOt+2OCPooqmzfuJvucE37iW8tLA8EEJZjyKlduA PFIlT0czS30Y7C/kJrRzmcryqnyDKmPCtULR5LndiGx2hZojYrLfsiuXD/sbJkT+ VEdAF3NwYJ+lR2VCL83plPjiQ0HAig== =83EC -END PGP SIGNATURE-
Bug#1050802: xfce4-session: please provide an xfce-portals.conf for xdg-desktop-portal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, 2023-08-29 at 11:51 +0100, Simon McVittie wrote: > xdg-desktop-portal 1.17.x introduces a new way to select which portals will > be used for which desktop environments, modelled on mimeapps.list: Hi Simon, thanks for the report but I have no idea what a “portal” is. So feel free to provide a patch for that, I think it's unlikely we'll look at this soon. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmT6I8MACgkQ3rYcyPpX RFuC+wf/YhTUai4ctNVzUJC7zPo9F2mgtmGLtOl3IFlD+YaTGtDztZuUIlFrNJL4 J9vIxLjYGtSsxpImkoHnj1lxnn0kX//Msj3cgmn8uyqRmoC0NIQr+Dz2bo8aD2C/ 0CsFeflqw20Q9Q2UEKdORppTtbmmosFCyfiyadhL94uSqYhFVC98HnVo7jc+qZoq 2DON8WKNgB4KGe+L4gNbEIV4t8SwhRXsjBx8FVSsE6xWrOjRwBL2MVf/krhxMryr eCxbC5/Zkb3+u3S5JPEyqhxctD1M3ulanTM42GUT1FUbL96c8YOLq9JwumpLYaBo QydscbTWY079TGnEH4oTWOI/MRF0Lw== =qTvF -END PGP SIGNATURE-
Bug#1050802: xfce4-session: please provide an xfce-portals.conf for xdg-desktop-portal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, 2023-08-29 at 11:51 +0100, Simon McVittie wrote: > xdg-desktop-portal 1.17.x introduces a new way to select which portals will > be used for which desktop environments, modelled on mimeapps.list: Hi Simon, thanks for the report but I have no idea what a “portal” is. So feel free to provide a patch for that, I think it's unlikely we'll look at this soon. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmT6I8MACgkQ3rYcyPpX RFuC+wf/YhTUai4ctNVzUJC7zPo9F2mgtmGLtOl3IFlD+YaTGtDztZuUIlFrNJL4 J9vIxLjYGtSsxpImkoHnj1lxnn0kX//Msj3cgmn8uyqRmoC0NIQr+Dz2bo8aD2C/ 0CsFeflqw20Q9Q2UEKdORppTtbmmosFCyfiyadhL94uSqYhFVC98HnVo7jc+qZoq 2DON8WKNgB4KGe+L4gNbEIV4t8SwhRXsjBx8FVSsE6xWrOjRwBL2MVf/krhxMryr eCxbC5/Zkb3+u3S5JPEyqhxctD1M3ulanTM42GUT1FUbL96c8YOLq9JwumpLYaBo QydscbTWY079TGnEH4oTWOI/MRF0Lw== =qTvF -END PGP SIGNATURE-
Bug#1039957: light-locker: Bug 1039957: light-locker: coredump from light-locker
On Mon, Jul 24, 2023 at 05:00:36PM +0200, Paul Gevers wrote: > Hi, > > On 24-07-2023 15:27, Yves-Alexis Perez wrote: > > so what you're saying is that you're a KDE user (not Xfce) > > Indeed. > > > but you're > > still using LightDM (not KDM), and light-locker is still started as part > > of your desktop session. > > I'm not aware that I ever did that actively. It seems that also nothing > obvious changed for me since I deinstalled light-locker. So everything > *looks* like before. Yeah I meant before removing it. > > > In any case, if you don't use it on your box it's quite ok to remove it. > > I tried to say in my previous message that I already did that. > Yes indeed, I was just saying that it was ok. -- Yves-Alexis Perez
Bug#1039957: light-locker: Bug 1039957: light-locker: coredump from light-locker
On Mon, Jul 24, 2023 at 05:00:36PM +0200, Paul Gevers wrote: > Hi, > > On 24-07-2023 15:27, Yves-Alexis Perez wrote: > > so what you're saying is that you're a KDE user (not Xfce) > > Indeed. > > > but you're > > still using LightDM (not KDM), and light-locker is still started as part > > of your desktop session. > > I'm not aware that I ever did that actively. It seems that also nothing > obvious changed for me since I deinstalled light-locker. So everything > *looks* like before. Yeah I meant before removing it. > > > In any case, if you don't use it on your box it's quite ok to remove it. > > I tried to say in my previous message that I already did that. > Yes indeed, I was just saying that it was ok. -- Yves-Alexis Perez
Bug#1041825: libopenraw: new upstream release 0.3.6
On Mon, Jul 24, 2023 at 02:37:50PM +0100, Simon McVittie wrote: > On Mon, 24 Jul 2023 at 14:57:23 +0200, Yves-Alexis Perez wrote: > > If libopenraw Debian package isn't maintained in practice, maybe it > > makes sense to drop it completely. For tumbler we can just remove the > > dependency (and lose the hability to generate thumbnails for them) or > > maybe investigate a way to uses a different library. > > For what it's worth, gegl switched from libopenraw to libraw (libraw-dev) > a while ago. libraw seems to be somewhat widely used: it's also what > gthumb, shotwell, geeqie, kimageformat-plugins, etc. use. Thanks for the pointer, I'll transfer that to upstream! Regards, -- Yves-Alexis
Bug#1039957: light-locker: Bug 1039957: light-locker: coredump from light-locker
On Sun, Jul 23, 2023 at 09:22:41PM +0200, Paul Gevers wrote: > Package: light-locker > Version: 1.8.0-3 > Followup-For: Bug #1039957 > > Hi, > > I just found this coredump in my journal. Like the original reporter, > I'm a user of KDE (on trixie). I removed light-locker to see if I spotted any > change and I'm not seeing it yet. > Hi Paul, so what you're saying is that you're a KDE user (not Xfce) but you're still using LightDM (not KDM), and light-locker is still started as part of your desktop session. light-locker is autostarted using the XDG/Freedesktop.org specifications so you should be able to prevent it to startup if you have a KDE screen locker (not sure how to do that on KDE though). Right now light-locker autostart ignores GNOME and Unity desktop environment, maybe it'd make sense to ignore KDE as well. In any case, if you don't use it on your box it's quite ok to remove it. Regards, -- Yves-Alexis Perez
Bug#1039957: light-locker: Bug 1039957: light-locker: coredump from light-locker
On Sun, Jul 23, 2023 at 09:22:41PM +0200, Paul Gevers wrote: > Package: light-locker > Version: 1.8.0-3 > Followup-For: Bug #1039957 > > Hi, > > I just found this coredump in my journal. Like the original reporter, > I'm a user of KDE (on trixie). I removed light-locker to see if I spotted any > change and I'm not seeing it yet. > Hi Paul, so what you're saying is that you're a KDE user (not Xfce) but you're still using LightDM (not KDM), and light-locker is still started as part of your desktop session. light-locker is autostarted using the XDG/Freedesktop.org specifications so you should be able to prevent it to startup if you have a KDE screen locker (not sure how to do that on KDE though). Right now light-locker autostart ignores GNOME and Unity desktop environment, maybe it'd make sense to ignore KDE as well. In any case, if you don't use it on your box it's quite ok to remove it. Regards, -- Yves-Alexis Perez
Bug#1041825: libopenraw: new upstream release 0.3.6
On Mon, Jul 24, 2023 at 12:02:15AM +0100, Simon McVittie wrote: > Source: libopenraw > Version: 0.1.2-0.2 > Severity: wishlist > X-Debbugs-Cc: tumb...@packages.debian.org > Control: affects -1 + tumbler-plugins-extra > > While investigating whether libopenraw's dependency on GTK 2 can be > removed (which it can, see #967585), I noticed that the version of > libopenraw in Debian is from 2018 and there have been 12 new upstream > releases since then. > > With this being file parsing code, I'm concerned that this might mean > unfixed security issues (although I don't see any obvious security fixes > in the upstream NEWS). > > tumbler-plugins-extra seems to be the only package in Debian that makes > use of libopenraw (gegl also has a Build-Depends on it, but it seems to > be unused there) so the maintainers of tumbler might be interested in > salvaging libopenraw to have a high-quality version to depend on if its > current Debian maintainer is no longer active? Hi Simon, thanks for the heads-up. Tumbler is a thumbnailing application used in Xfce so it uses libopenraw just for generating thumbnails for RAW files, not for manipulating them or something. I'm surprised tumbler is the only user, and I'm definitely not keen on adding another package to maintain to our large base. I share your concern about an outdated library parsing complex files. If libopenraw Debian package isn't maintained in practice, maybe it makes sense to drop it completely. For tumbler we can just remove the dependency (and lose the hability to generate thumbnails for them) or maybe investigate a way to uses a different library. Regards, -- Yves-Alexis
Bug#1037020: xfce4-panel: workspace switcher extremely wide after bookworm upgrade
control: tag -1 unreproducible morinfo On Thu, Jun 01, 2023 at 09:47:23PM +0200, Marc Lehmann wrote: > Package: xfce4-panel > Version: 4.18.2-1 > Severity: normal > > Dear Maintainer, > > after upgrading to xfce4-panel from bookworm, the workspace switcher has > become unusably large (wider than my screen). > > after realising this is not configurable, I dug a bit into the code and > found that plugin->ratio is set to 7.1, which explains why the switcher > displays extremely elongated miniature views - it apparently assumes my > display has an aspect ratio of 7.1, when it actually has a ratio of 1.78 > (standard full hd). > > I found that the ratio is calculated differently in bookworm's panel: > before, it was screen width / screen height (which is 1.777.. on > my system). Now it takes the workspace width divided by workspace > height. Since my workspace is 8x2 screens in size, this results in 15360 / > 2160, > or 7.1. > > So it seems to apply the full workspace aspect ratio as if it were a > single screen inside the workspace. > > I think either the ratio calculation is wrong, or some other code uses > this in the wrong way (workspace vs. single screen). Hi Marc, thank you for your report, but I'm not sure I understand and/or can reproduce it. Using a fairly standard Bookworm install with Xfce, the workspace switch seems just fine for me. I tried to configure the plugin to display using two rows, then added 16 workspaces (to get a 8x2 layout like you) but it seems to display just fine. Could you take a screenshot or something to help us investigate? Regards, -- Yves-Alexis Perez
Bug#1037020: xfce4-panel: workspace switcher extremely wide after bookworm upgrade
control: tag -1 unreproducible morinfo On Thu, Jun 01, 2023 at 09:47:23PM +0200, Marc Lehmann wrote: > Package: xfce4-panel > Version: 4.18.2-1 > Severity: normal > > Dear Maintainer, > > after upgrading to xfce4-panel from bookworm, the workspace switcher has > become unusably large (wider than my screen). > > after realising this is not configurable, I dug a bit into the code and > found that plugin->ratio is set to 7.1, which explains why the switcher > displays extremely elongated miniature views - it apparently assumes my > display has an aspect ratio of 7.1, when it actually has a ratio of 1.78 > (standard full hd). > > I found that the ratio is calculated differently in bookworm's panel: > before, it was screen width / screen height (which is 1.777.. on > my system). Now it takes the workspace width divided by workspace > height. Since my workspace is 8x2 screens in size, this results in 15360 / > 2160, > or 7.1. > > So it seems to apply the full workspace aspect ratio as if it were a > single screen inside the workspace. > > I think either the ratio calculation is wrong, or some other code uses > this in the wrong way (workspace vs. single screen). Hi Marc, thank you for your report, but I'm not sure I understand and/or can reproduce it. Using a fairly standard Bookworm install with Xfce, the workspace switch seems just fine for me. I tried to configure the plugin to display using two rows, then added 16 workspaces (to get a 8x2 layout like you) but it seems to display just fine. Could you take a screenshot or something to help us investigate? Regards, -- Yves-Alexis Perez
Bug#1041353: xfce4: option to make week start on Monday not Sunday
control: reassign -1 xfce4-panel On Mon, Jul 17, 2023 at 09:13:37PM +, sr2f2c+b00m5anxhcd3k@cs.email wrote: > Package: xfce4 > Severity: wishlist > > Dear Maintainer, > > I am running my system with LC_ALL=C.UTF-8 locale. > > When clicking the clock on the taskbar, a calendar is displayed with the week > starting on Sunday. Reassigning to the xfce4-panel package which contains the clock plugin. > > I'd like the week to start on Monday instead, as ISO8601 defines it. > > Currently, the only way to change that is to install another locale on my > system, that has Monday as first day of week. I do not wish to have to > install another locale and run my system with LC_TIME just for the xfce4 > calendar to show week starting on Monday. That'd be the correct way to do that though. > > Please provide a new option to make the week start on Monday, independent of > any currently used locale. Since it's an upstream bug, could you please open directly a wishlist issue on their tracker? It's much more likely to be acted on that way. Regards, -- Yves-Alexis Perez
Bug#1041353: xfce4: option to make week start on Monday not Sunday
control: reassign -1 xfce4-panel On Mon, Jul 17, 2023 at 09:13:37PM +, sr2f2c+b00m5anxhcd3k@cs.email wrote: > Package: xfce4 > Severity: wishlist > > Dear Maintainer, > > I am running my system with LC_ALL=C.UTF-8 locale. > > When clicking the clock on the taskbar, a calendar is displayed with the week > starting on Sunday. Reassigning to the xfce4-panel package which contains the clock plugin. > > I'd like the week to start on Monday instead, as ISO8601 defines it. > > Currently, the only way to change that is to install another locale on my > system, that has Monday as first day of week. I do not wish to have to > install another locale and run my system with LC_TIME just for the xfce4 > calendar to show week starting on Monday. That'd be the correct way to do that though. > > Please provide a new option to make the week start on Monday, independent of > any currently used locale. Since it's an upstream bug, could you please open directly a wishlist issue on their tracker? It's much more likely to be acted on that way. Regards, -- Yves-Alexis Perez
Bug#1040912: lightdm-gtk-greeter: greeter always uses Gnome (Standard) as default Xsession
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 control: reassign -1 arctica-greeter On Wed, 2023-07-12 at 20:49 +0200, Dieter Scheinkönig wrote: > find attached my .xsession-errors. > > My issue, regarding the login screen (See login-shot.png). I have to > change/select _always_ from "Gnome (Standard)" to "Default Xsession" in > order start my XFCE-session. > It changes always after login off from my session. In the past (Debian > 11), the selection, which session would be used stayed as selected before > login. > > Sorry, if I confused you. > Yes indeed, this is very confusing. Sorry I misunderstood from the start. And in the end, yes it looks like a bug in the greeter, so I'm reassigning there. Sorry for the lengthy process. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmSu/nQACgkQ3rYcyPpX RFsWAQgA7dYT7OU7iqAheGHflI/l4awdYJ8zgavpEXEZmViX0kgDNsE0NX1cjfuf UkgvKxKfeCZDeocRMBYiH5Y+y0s5aOWDL03xiEkWraTWb8N0FIYhIU7d3UGBaDn3 xtcW4It6LWmvBoQaeiTTy6glbKBiehusLd9+jQV0pzidU4iWmjqLYX+h8s3RAY0p 0hWqPcITUgaN2aUWO6Lskc0kIxGijuxpk17rOYG6i6rMgD+b02xbtW+RdhLmy2Zi NYuYSKR/kgin0gIW8vzTG3UZ/QbJX/fl5ixrqi+41+r9uSb0g9MD1QUTcSGCVDHp OHWsR1lVG6kllmEzlTuHpEw4BX9CFw== =7rLP -END PGP SIGNATURE-
Bug#1040912: lightdm-gtk-greeter: greeter always uses Gnome (Standard) as default Xsession
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 control: reassign -1 arctica-greeter On Wed, 2023-07-12 at 20:49 +0200, Dieter Scheinkönig wrote: > find attached my .xsession-errors. > > My issue, regarding the login screen (See login-shot.png). I have to > change/select _always_ from "Gnome (Standard)" to "Default Xsession" in > order start my XFCE-session. > It changes always after login off from my session. In the past (Debian > 11), the selection, which session would be used stayed as selected before > login. > > Sorry, if I confused you. > Yes indeed, this is very confusing. Sorry I misunderstood from the start. And in the end, yes it looks like a bug in the greeter, so I'm reassigning there. Sorry for the lengthy process. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmSu/nQACgkQ3rYcyPpX RFsWAQgA7dYT7OU7iqAheGHflI/l4awdYJ8zgavpEXEZmViX0kgDNsE0NX1cjfuf UkgvKxKfeCZDeocRMBYiH5Y+y0s5aOWDL03xiEkWraTWb8N0FIYhIU7d3UGBaDn3 xtcW4It6LWmvBoQaeiTTy6glbKBiehusLd9+jQV0pzidU4iWmjqLYX+h8s3RAY0p 0hWqPcITUgaN2aUWO6Lskc0kIxGijuxpk17rOYG6i6rMgD+b02xbtW+RdhLmy2Zi NYuYSKR/kgin0gIW8vzTG3UZ/QbJX/fl5ixrqi+41+r9uSb0g9MD1QUTcSGCVDHp OHWsR1lVG6kllmEzlTuHpEw4BX9CFw== =7rLP -END PGP SIGNATURE-
Bug#1040912: lightdm-gtk-greeter: greeter always uses Gnome (Standard) as default Xsession
On Wed, Jul 12, 2023 at 03:30:06PM +, Dieter Scheinkönig wrote: > Hi Yves-Alexis, > > I do not have a .xsession or .Xsession in my home directory. Ok > So, I’m using the default. I’m not in front of my computer right now, so I > would send it later from /etc/X11. Please especially send the .xsession-errors log (check for personal information first though). /etc/X11/Xsession sources various files from /etc/X11/Xsession.d and the session selection (if not selected in the greeter) should be done from /etc/X11/Xsession.d/50x11-common_determine-startup > > As mentioned, the difference between using the login between Debian 11 and 12 > is, before the selection of respective xsession (xfce, kde, gnome) did stay > after restart. Now it’s not the case anymore. Sorry but it's not at all clear what you mean here: are you using the *default* session, or are you choosing a session in the greeter and it's not actually selected? In the lightdm log you sent, you were using the default session. > > I’m happy to do the necessary configuration, however I do not know where to > search for. A “find” in /etc did not give me any result. > > In case it would be a bug, you would transfer to the artic maintainer? I don't think so, again it doesn't look like a but in the greeter. Regards, -- Yves-Alexis Perez
Bug#1040912: lightdm-gtk-greeter: greeter always uses Gnome (Standard) as default Xsession
On Wed, Jul 12, 2023 at 03:30:06PM +, Dieter Scheinkönig wrote: > Hi Yves-Alexis, > > I do not have a .xsession or .Xsession in my home directory. Ok > So, I’m using the default. I’m not in front of my computer right now, so I > would send it later from /etc/X11. Please especially send the .xsession-errors log (check for personal information first though). /etc/X11/Xsession sources various files from /etc/X11/Xsession.d and the session selection (if not selected in the greeter) should be done from /etc/X11/Xsession.d/50x11-common_determine-startup > > As mentioned, the difference between using the login between Debian 11 and 12 > is, before the selection of respective xsession (xfce, kde, gnome) did stay > after restart. Now it’s not the case anymore. Sorry but it's not at all clear what you mean here: are you using the *default* session, or are you choosing a session in the greeter and it's not actually selected? In the lightdm log you sent, you were using the default session. > > I’m happy to do the necessary configuration, however I do not know where to > search for. A “find” in /etc did not give me any result. > > In case it would be a bug, you would transfer to the artic maintainer? I don't think so, again it doesn't look like a but in the greeter. Regards, -- Yves-Alexis Perez
Bug#1040912: lightdm-gtk-greeter: greeter always uses Gnome (Standard) as default Xsession
On Wed, Jul 12, 2023 at 01:06:10PM +0200, Dieter Scheinkönig wrote: > Dear Yves-Alexis, > > thanks for the fast response. > > I'm talking about the lightdm logon screen (as on the screenshot of > https://de.wikipedia.org/wiki/LightDM#/media/Datei:Lightdm-screenshot.jpg) > Next to the users you have the possibility to select your session. This is > always defaulted to Gnome (Standard) since I upgraded to Debian 12. Hi, that screenshot is not lightdm-gtk-greeter > > I attached the last 150 lines from lightdm.log. > And the log confirm you're using arctica-greeter, so it's definitely unrelated to lightdm-gtk-greeter. But in any case, as I said before, you can select the session in the greeter but in the end it's handled by Lightdm itself. Looking at the log you provided, we can see: [+264.18s] DEBUG: Session pid=5587: Running command /etc/X11/Xsession default [+264.18s] DEBUG: Creating shared data directory /var/lib/lightdm/data/scheini72 [+264.18s] DEBUG: Session pid=5587: Logging to .xsession-errors So you're definitely using /etc/X11/Xsession with the 'default' parameter. You should be able to select a specific session if the desktop environment you use has it (for example Xfce). In any case, could you provide your .xsession-errors as well as your .xsession or .Xsession just in case? It looks to me like an configuration issue rather than a bug though. Regards, -- Yves-Alexis Perez
Bug#1040912: lightdm-gtk-greeter: greeter always uses Gnome (Standard) as default Xsession
On Wed, Jul 12, 2023 at 01:06:10PM +0200, Dieter Scheinkönig wrote: > Dear Yves-Alexis, > > thanks for the fast response. > > I'm talking about the lightdm logon screen (as on the screenshot of > https://de.wikipedia.org/wiki/LightDM#/media/Datei:Lightdm-screenshot.jpg) > Next to the users you have the possibility to select your session. This is > always defaulted to Gnome (Standard) since I upgraded to Debian 12. Hi, that screenshot is not lightdm-gtk-greeter > > I attached the last 150 lines from lightdm.log. > And the log confirm you're using arctica-greeter, so it's definitely unrelated to lightdm-gtk-greeter. But in any case, as I said before, you can select the session in the greeter but in the end it's handled by Lightdm itself. Looking at the log you provided, we can see: [+264.18s] DEBUG: Session pid=5587: Running command /etc/X11/Xsession default [+264.18s] DEBUG: Creating shared data directory /var/lib/lightdm/data/scheini72 [+264.18s] DEBUG: Session pid=5587: Logging to .xsession-errors So you're definitely using /etc/X11/Xsession with the 'default' parameter. You should be able to select a specific session if the desktop environment you use has it (for example Xfce). In any case, could you provide your .xsession-errors as well as your .xsession or .Xsession just in case? It looks to me like an configuration issue rather than a bug though. Regards, -- Yves-Alexis Perez
Bug#1040912: lightdm-gtk-greeter: greeter always uses Gnome (Standard) as default Xsession
Control: tags -1 moreinfo On Wed, Jul 12, 2023 at 12:05:01PM +0200, Dieter Scheinkönig wrote: > Package: lightdm-gtk-greeter > Version: 2.0.8-2+b1 > Severity: normal > X-Debbugs-Cc: die...@scheinkoenig.com > > Although update-alternatives --config x-session-manager is sset to start xfce. > the lightdm-greeter always set the defualt session to Gnome (Standard) > > Auswahl Pfad Priorität Status > > * 0/usr/bin/startxfce450automatischer Modus > 1/usr/bin/gnome-session 50manueller Modus > 2/usr/bin/i330manueller Modus > 3/usr/bin/lxsession 49manueller Modus > 4/usr/bin/openbox-session 40manueller Modus > 5/usr/bin/startlxqt 50manueller Modus > 6/usr/bin/startplasma-x11 40manueller Modus > 7/usr/bin/startxfce450manueller Modus > 8/usr/bin/xfce4-session 40manueller Modus > > I did not find any configuration, where I saw the this settings nor where I > was > able to change it. Hi Dieter, when you say "default session", do you mean in the top-right menu? If so, the LightDM (not the greeter) should run /etc/X11/Xsession, which in turn might run different stuff depending on your local configuration (check in ~/.xsession and ~/.Xsession). Could you provide logs from /var/log/lightdm and ~/.xsession-errors ? In any case, it's likely not a but in the greeter (whose role is minimal), but let's wait for more info before reassigning. Regards, -- Yves-Alexis Perez
Bug#1040912: lightdm-gtk-greeter: greeter always uses Gnome (Standard) as default Xsession
Control: tags -1 moreinfo On Wed, Jul 12, 2023 at 12:05:01PM +0200, Dieter Scheinkönig wrote: > Package: lightdm-gtk-greeter > Version: 2.0.8-2+b1 > Severity: normal > X-Debbugs-Cc: die...@scheinkoenig.com > > Although update-alternatives --config x-session-manager is sset to start xfce. > the lightdm-greeter always set the defualt session to Gnome (Standard) > > Auswahl Pfad Priorität Status > > * 0/usr/bin/startxfce450automatischer Modus > 1/usr/bin/gnome-session 50manueller Modus > 2/usr/bin/i330manueller Modus > 3/usr/bin/lxsession 49manueller Modus > 4/usr/bin/openbox-session 40manueller Modus > 5/usr/bin/startlxqt 50manueller Modus > 6/usr/bin/startplasma-x11 40manueller Modus > 7/usr/bin/startxfce450manueller Modus > 8/usr/bin/xfce4-session 40manueller Modus > > I did not find any configuration, where I saw the this settings nor where I > was > able to change it. Hi Dieter, when you say "default session", do you mean in the top-right menu? If so, the LightDM (not the greeter) should run /etc/X11/Xsession, which in turn might run different stuff depending on your local configuration (check in ~/.xsession and ~/.Xsession). Could you provide logs from /var/log/lightdm and ~/.xsession-errors ? In any case, it's likely not a but in the greeter (whose role is minimal), but let's wait for more info before reassigning. Regards, -- Yves-Alexis Perez
Bug#910273: severity of 910273 is important
On Fri, Oct 05, 2018 at 04:14:41PM +0200, Olivier Berger wrote: > severity 910273 important > thanks > > I wasn't quite sure, but the impact is quite nasty, so raising severity > in the hope someone more knowledgable has hints on the likeliness it may > happen to anyone else in the next stable... Hey Olivier, it seems this one went under my radar for a *long time*. Did it get solved in the end? I never experienced this one myself. Regards, -- Yves-Alexis Perez
Bug#910273: severity of 910273 is important
On Fri, Oct 05, 2018 at 04:14:41PM +0200, Olivier Berger wrote: > severity 910273 important > thanks > > I wasn't quite sure, but the impact is quite nasty, so raising severity > in the hope someone more knowledgable has hints on the likeliness it may > happen to anyone else in the next stable... Hey Olivier, it seems this one went under my radar for a *long time*. Did it get solved in the end? I never experienced this one myself. Regards, -- Yves-Alexis Perez
Bug#1039559: lightdm does not start Xorg
On Tue, Jul 04, 2023 at 09:39:56AM +0200, Christophe Lohr wrote: > Le 03/07/2023 à 21:54, Yves-Alexis Perez a écrit : > > On Wed, 2023-06-28 at 09:06 +0200, Christophe Lohr wrote: > How to know more about it? Honestly at that point I'm not sure. > I have outputs by strace and ltrace if needed. > I expected to see any errors, or attempts for execve( Xorg ...) or similar. > But there's nothing. Maybe share them so I can take a look just in case, but I'm not sure I can identify anything if you didn't > Are there any dependencies between lightdm and other components? (eg. dbus > plymouth etc.) There are but I don't think it should matter. Is xserver-xorg-video-nouveau package installed? If not, can you install it just to check if it does fix the problem (by not using fbdev)? Regards, -- Yves-Alexis Perez
