Bug#503566: severity of 503566 is important
# Automatically generated email from bts, devscripts version 2.10.13~bpo40+1 # splashy is not present in etch so upgrades will behave nicely when 5.0.2 will be in testing severity 503566 important -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#898950: Processed: severity of 898950 is serious
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 control: severity -1 important control: retitle -1 "verve-focus program missing from package" On Mon, 2018-09-17 at 20:33 +, Debian Bug Tracking System wrote: > Processing commands for cont...@bugs.debian.org: > > > severity 898950 serious > > Bug #898950 [xfce4-verve-plugin] xfce4-verve-plugin: the essential `verve- > focus` program is missing in this version, which makes it useless > Severity set to 'serious' from 'important' > > thanks Hi Adrian, I'm unsure why you think this bug is release critical, and there is no content in your mail which help. I disagree with this, so I'm lowering the severity again, but feel free to comment on this. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAluiTkYACgkQ3rYcyPpX RFtITwf/RR0cKilDOjhshcXqa3SfE/UbrkD/1dRpnSOlrfFN8CB34QHwIM91rE1S U4mIjAMbkBstv0J0hr1wdjJ1ynpMbXZJhwNeUvyhBO1t6YBQnhn2jC8/OkYfJWxr GZWhlB6z4cx+Vsm24Zc2elhUeYj6bTbaxAL82M6APtMHj8umPzdIBlOCzsgpqTHy N4jpDmEp1iUkcSB6hleKmkMK0hDCUthPvgVaIffn6RJHoFngYd3hLXQ+v1V2gLPP 6uYtq4vlCIbi+cxnh47JenzR18Fy3O/eLBM9uSio4RRl2EaZvPfLaSf/QXuR2hgg WcJUJYnFl60cwkhClzcm9VkV4KsYoQ== =EubS -END PGP SIGNATURE-
Bug#842675: [Pkg-xfce-devel] Bug#842675: Bug#842675: lightdm FTBFS on mips, mipsel and mips64el: error: symbols mismatch
On Mon, 2016-10-31 at 14:00 +0100, Yves-Alexis Perez wrote: > On Mon, 2016-10-31 at 10:34 +, Radovan Birdic wrote: > > The problem is in liblightdm-qt-3-0.symbols where these symbols are > > missing. > > > > I have created and attached a patch that adds missing symbols into this > > file > > and resolves this issue. > > With this patch package builds successfully on mips*, i386 and amd64 > > architectures. > > I have to admit I'm not really comfortable *removing* symbols from a file > just > for some architectures. It looks weird to me that it would only happen on > those arches. Maybe something changed in Qt but I'm highly puzzled here. > Well, as assumed, the build fails on i386/amd64 with the updated symbols file. I might be able to provide multiple symbols file but it does look weird in any case. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#842675: [Pkg-xfce-devel] Bug#842675: Bug#842675: Bug#842675: lightdm FTBFS on mips, mipsel and mips64el: error: symbols mismatch
control: tag -1 help On Sat, 2016-11-19 at 15:15 +0100, Yves-Alexis Perez wrote: > On Mon, 2016-10-31 at 14:00 +0100, Yves-Alexis Perez wrote: > > On Mon, 2016-10-31 at 10:34 +, Radovan Birdic wrote: > > > The problem is in liblightdm-qt-3-0.symbols where these symbols are > > > missing. > > > > > > I have created and attached a patch that adds missing symbols into this > > > file > > > and resolves this issue. > > > With this patch package builds successfully on mips*, i386 and amd64 > > > architectures. > > > > I have to admit I'm not really comfortable *removing* symbols from a file > > just > > for some architectures. It looks weird to me that it would only happen on > > those arches. Maybe something changed in Qt but I'm highly puzzled here. > > > > Well, as assumed, the build fails on i386/amd64 with the updated symbols > file. > I might be able to provide multiple symbols file but it does look weird in > any > case. So, I've tried to build 1.18.2-2 on arm64 (which suceeded in the past), and it now fails, indicating it's indeed a problem somewhere else. I've tried to build using g++5 and it now works fine. So the symbol changes is due to the upgrade to gcc/g++6. I'm not sure it's really expected, so any help appreciated. I'm adding Matthias to CC: in case he has any idea. Matthias: I'm experiencing a build failure in lightdm due to symbol changes in a C++ library only on non intel arches, following upgrade to gcc6. Does that ring you a bell or something? The changed symbols are only destructors: QDBusError::~QDBusError() QByteArray::~QByteArray() QHash::~QHash() QString::~QString() Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#846026: [Pkg-swan-devel] Bug#846026: strongswan: FTBFS randomly (failing tests)
On Sun, 2016-11-27 at 23:13 +0100, Santiago Vila wrote: > The failure happens randomly. Sometimes it fails, sometimes it does not. Check exactly where the testsuite fails, it might be lack of entropy. I'd rather not disable the testsuite altogether, we already limit it to few architectures to prevent that from happening too much. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#845785: Apt pinning to keep chromium from testing installed
On Wed, 2016-11-30 at 21:28 +0100, Martin Steigerwald wrote: > > As Michael downgraded the bug, there is apt-pinning for keeping the version > from testing installed: In case you missed, the downgrade was because of the merge, Michael actually raised the severity to grave again. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#892290: [Pkg-xfce-devel] Bug#892290: Bug#892290: light-locker: at unlock, crash with: arguments to dbus_message_new_method_call() were incorrect
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, 2018-03-10 at 10:20 +0100, Stuart Pook wrote: > On 10/03/18 10:10, Yves-Alexis Perez wrote: > > In any case, I really can't reproduce here, and you still didn't indicate > > what > > you changed to make it crash reliably, so I'm afraid I can't help. > > light-locker crashes at unlock every time I run it from the command line. > > What happens when you run light-locker from the command line? > > I agree that it should not normally be run from the command line. I wanted > to run lightlocker with different options and the running it from the > command line was faster than logging on and off. Just a quick update on this. For you it always crash at unlock when running from the command line. Does it also crash when running normally as part of the session? Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAltpgyIACgkQ3rYcyPpX RFvEYwgAsUOjdAW2bI+95oDW+tIXUcBYCokYwvzj3Ttrisqen5ldUfu6L8ISoHtU JcktG8FmtWv4w+iieHbBVvMl+MLstb7/L2um09S/GntxvNW81byiy28mGP77v/jh 8sEM36RfQLyIEWUj9U4POIB5KD2odePi247pbUZhJGKdA0yNs0g94Yqh46v84U7V ci54xfTpXO285b86VXxP5IdBLg/z6tsuRua5bpcnoepHqlXyPoT0R/icwgA9hgfL IJCUsT1TrpN08G8eVgiT9BydMDWi6LsZOCgJ+LMkJdRK9VWiAvmDImSua3nSjHoK gxBVFgL3keg1zyZastgul266GSol0Q== =6rUx -END PGP SIGNATURE-
Bug#862436: closing 862436
close 862436 thanks
Bug#898633: evolution-data-server: efail attack against S/MIME
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, 2018-08-12 at 16:38 -0400, Jeremy Bicha wrote: > Yvez, the Evolution bug was closed upstream. Should we close the bug > in Debian too? > > https://bugzilla.gnome.org/796135 Yeah I guess so, it only adds noise. The status is not entirely clear but keeping this bug open doesn't help that. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAltxqVUACgkQ3rYcyPpX RFs1Ngf8Cskmy5Ezy8idol6V291nfGtGmaGR80FjyZjDg4KDwWmq8MbsnCd2WJ4l k/foSaTi9YBjVezRoYyCj5hQb24BWbMcSA2KjsJdcDUSmp+EXZrLLHwhe19Wlcwp b2MY5C5ZicojxW+OknpXRHa29rCIUn6bMgxnwdR5Vhup5dkq2iJWkFNSlJQjpTpd oojtD9lqZ/6rPmLGLXLpfRb/iQMShfI07uhYveOCGYxek3zVK6nDBj6PsNIAtCxo atYeCnJ6uAkzNh0qHurt4ZKcRWV7FiX5jVWldsfhZvbmHQGdCF+VJd4L7F/h+VLR CaCJdmbKRlZV/+sickvtPxaTCJUb9A== =oExr -END PGP SIGNATURE-
Bug#906489: closing 906489
close 906489 1.26.0-1 thanks
Bug#899595: Invalid maintainer address pkg-xfce-de...@lists.alioth.debian.org
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 2019-01-04 at 08:39 +0900, Hideki Yamane wrote: > Hi, > > With Bugs search "Cleaner view", I've found those bugs are not closed > in unstable but are done in experimental. Hi, I am well aware of these, thanks. > Do you have a plan to put them > into unstable, or just apply only those fixes to current unstable packages? Not right now. > > I know xfce4.13 series are development release, but some projects like > Fedora > and Xubuntu have released 4.13 series as discussed at > https://mail.xfce.org/pipermail/xfce4-dev/2018-July/032143.html > We already shipped Xfce development release in stable previously, and I don't want to do that again, so no, I'm waiting for stable releases. If it happens before freeze, fine, if not then it'll be for Bullseye. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlwvGVkACgkQ3rYcyPpX RFux+Af+LhC020PuKdWr6uwIl4uJtR6WintK2RXrL0xTMXaU/hjFjRP0MpxJlkmR DfDlA0tYCsUueNaJl5WkGUbsAepyIW77mr6yLOgikL2mveIRAMI4XGMHjj0nzu03 QEDGlk7BeAMn7DIuHg4W/pwnlSCb//CoTNoJmb4CqdU7JNolMuoBgBRk4vk6Z73i JZi53w1corx5Bq3juv+ETkb4UoJBKCoRSdq87l2bX5klqyOFxn0Rz8K+Vo1lqmry /gGdplBGFDh1EP3fyD98Bb8pjkemmm+VN9taBnEvXCAnVSQfEI48ltK6GHXVATMp bOJu2ZnzOCCiYIOdeIELCFq2q1REmg== =793v -END PGP SIGNATURE-
Bug#920876: xfce4-notes: Not functioning
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 control: severity -1 important control: tag -1 unreproducible On Wed, 2019-01-30 at 15:37 +1100, Dmitry Smirnov wrote: > In Cinnamon xfce4-notes does not work any more: it starts without showing > its > window or tray icon and uses ~55% CPU continuously. The following is > printed > to console: > > > /usr/share/themes/Breeze/gtk-2.0/widgets/styles:1: error: invalid string > constant "default", expected valid string constant > > > Also it is too easy to run it more than once and have multiple `xfce4- > notes` > consuming even more CPU in the background... I'm sorry but it seems that xfce4-notes works just fine (even with Breeze theme) here. I'm unsure if it's an issue in Breeze or in GTK, but it looks unrelated to notes (besides the fact that it's GTK-2 and use that bit of style). Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlxcZ9QACgkQ3rYcyPpX RFtgXwgAir4epTezPtHv3JdCARC3FWJGmdPS4dLFNHMYe0XH7K04hKVfH0LCqK2w DXBWTKn+SSxFsMmLPd3pfgJFBKOwu3j96AHyuVKo8NYVBYqGFQQjzz/j821cTWrH zMyMPEDQRUQ8zeQq5yKtg0xlDb9wtJZ/ozji6okC/AdEFtl+Gm8eJDw7OXyyDhxt 7M8OhtHrK/eVMROP66/zDMEPUIpYmc9ebdLnwempxBysslQoOByyO7ZiZJmegiyk wMlFyPzhRQ2FpmbeteWusFSMKp/NcruGPsH1FqhXXA/hJzIQbAJe/XQiJ02sUeq+ 3JZwB5YVl/oiROiT9QjUhKodbYfCCQ== =iPju -END PGP SIGNATURE-
Bug#777981: lightdm: ftbfs with GCC-5
On Sat, Aug 22, 2015 at 11:48:47AM +0300, Dmitry Shachnev wrote: > Hi Yves-Alexis, > > On Sat, 08 Aug 2015 19:04:21 +0200, Yves-Alexis Perez wrote: > > I somehow missed this bug. I'm a bit unsure what to do with those > > symbols updates. I guess it's related to some libstdc++ change but I'm > > unsure what that really means for me. Should I just update the symbols > > files here? (I'm really not fluent in Qt or C++ so really any help > > appreciated here). > > All symbols that are removed in the diff are destructors for Qt classes that > are not part of Qt's own ABI (i.e. declared inline or template > instantiations). > > These symbols are not exposed to users of your library and can be safely > removed from the symbols file. > > You usually only need to worry if the symbols diff contains "__cxx11", in this > case there are no symbols containing this so you are safe. Thank you for the help. I'll upload the package and make an upload then. Regards, -- Yves-Alexis Perez signature.asc Description: Digital signature
Bug#851971: linux-grsec: linux-headers-4.8.0-2-grsec-* depend on NBS linux-compiler* and linux-headers-4.8.0* packages
On Fri, 2017-01-20 at 08:12 -0500, Scott Kitterman wrote: > Package: linux-grsec > Version: 4.8.15-2+grsec201701031913+1 > Severity: grave > Justification: renders package unusable > > linux-compiler-gcc-5-x86 and linux-headers-4.8.0-2-common-rt are NBS and to > be > removed shortly. Once that is done, linux-headers-4.8.0-2-grsec-686-pae and > linux-headers-4.8.0-2-grsec-amd64 will no longer be installable (which is > definitely unusable). That'll be fixed when grsec is released for 4.9 and we pull changes from src:linux. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#1035452: libmousepad-dev: missing Depends: libmousepad0 (= ${binary:Version})
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, 2023-05-03 at 16:10 +0200, Andreas Beckmann wrote: > during a test with piuparts I noticed your package ships (or creates) > a broken symlink. > > 0m9.1s ERROR: FAIL: Broken symlinks: > /usr/lib/x86_64-linux-gnu/libmousepad.so -> libmousepad.so.0.0.0 > (libmousepad-dev) Indeed, for some reason that depend is missing, we'll fix it for the next upload. Not sure about the severity though (especially at freeze time). Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmRT+kEACgkQ3rYcyPpX RFs/YAf9EdzJoXD2doBL26HIb1Lzfeli0uI3ZhvgdiwB+9mYuUzI2S+sYGM1v/X3 ZQ0BGkJhClQmnLdeNjRUbbRjNr6p3m4TCFb9o1oHXBVwvv7mTTK61ODgwjkMUqVw SGkWlxUQfwAsZxR3gnLAUw+pWkOXh1rm3fstZz2Q+FEkEJHDqnqJqilwOOwKDC3G Wx5Q40+ZOe2JDc8eCE3B2shpZtbOQL5eNkjIwlxQIoyeilrrJ6tl3WieKtQ2YeEZ bj3ldm2tl9QZpOLQLppR6zLx5VN8R+tJwDI69+T3UYkSsDF8jCc6BBLgpq5oOdvC Usx94Q39HLvxKvWjoWfI+StoVEGk6w== =o9iA -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-06-20 at 12:45 +0200, Carlos Laviola wrote: > Package: lightdm > Followup-For: Bug #1038611 > > Can't reproduce, starts up just fine for me. > > Could you perhaps include the logs from `/var/log/lightdm/´? Hi Adilson, I'm running 1.32 just fine since it was uploaded to experimental so I can't reproduce either. Logs would help indeed, and if you can investigate a bit more on your side (the info about downgrading helps identifying lightdm but besides that...) Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmSSFncACgkQ3rYcyPpX RFuFvwgAlSLsGtGtw8gWLSKh9j53R90TnQFXO815eCtpu4v332YxbTEc8ZyqUPVF zndG+48/CWRtlhSi6PHlAorg3rMk7NgTSB29Oi1XD9Re3UX7z7Xvu/P92XbipzVg D0TqCHN34PkPqoImgoNoHVjdgzaJukgGcTMoTZqbU/EguAHudkDqnHdXKbps6JUA Pq1fXi2P6BP9nqDSpWjPmO4aA/o59Evb+D1q5MRHm43sZS3z9Vwj5zalLl2MiPG3 0EcBg/STIOV8Om+GBPYAsvQau4/3gWqyziVQw1/v4A8LYnH4BTLB+W6rVbHk/Fj6 PKbmA5VO3GjJfl4LABIPkpAwkB+gwg== =SArv -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-06-20 at 20:37 -0300, Adilson dos Santos Dantas wrote: > I tried to use 1.32 again and it only > generates /var/log/lightdm/lightdm.log. It doesn't generate seat0- > greeter.log and x-0.lo. From the log attached below, one difference is that > 1.26 starts seat0 and 1.32 does not start it. I got an X session from 1.26 > and X does not even start from 1.32. In the log there's definitely a bad sign: [+69.14s] DEBUG: Got signal 15 from process 1 [+69.14s] DEBUG: Caught Terminated signal, shutting down [+69.14s] DEBUG: Stopping display manager [+69.14s] DEBUG: Display manager stopped [+69.14s] DEBUG: Stopping daemon [+69.14s] DEBUG: Exiting with return value 0 Can you check also the system logs (/var/log/syslog, /var/log/daemon.log, the journal, dmesg...) so we have more information? Also is there something peculiar about your hardware (Nvidia/AMD GPU for example?) or software (specific configuration or something). Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmSSmacACgkQ3rYcyPpX RFu3MQf9Hpnj5rWRK71USdZCS9Gx4vQZ+octjX/3TZWtlB8vb3eDbLAj4ZAEkZzZ YjyFBCOx2zSV7HbY2l7fgb9/q7njngHuFr/ux+Z8nxRsyWy4fkhdQKh/4mfOt7sy wDa7WH5y+z96f9ekBLtauWe7YBFocEiEFPsgQ6WApvLmNzMwl2oXFP/bTKBv6BWi NWe5//R4gdt2yDKHIlZrBWGQfItg4KzG6wUuBfkrz/53PicafeFxcrOcZILoYzJK PU6uWij2Imebdzq+02rgYWz0Qq7fqI3PxNNfiWq6fMMa+rWXM5cTEGs7XC//Vqe1 hHbM8JXrzsc2ZcMaYCQyJ0PaqnS18w== =4Egr -END PGP SIGNATURE-
Bug#1038611: lightdm: Lightdm fails to start X after upgrade to 1.32.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, 2023-06-21 at 01:59 +, solneman33 wrote: > I downgraded to xkb-data=2.35.1-1 lightdm=1.26.0-8 from testing repo and > reinstalled xserver-xorg and xinit. That resolved the issue for me on both > machines. > > I've never reported a bug before, my apologies if this is incorrect > procedure. Well, can you check by reinstalling lightdm 1.32 but making sure you have xserver-xorg? Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmSSnMIACgkQ3rYcyPpX RFs1Hwf9HgLiSwVwW4gMRS2ajXiUXmTRcgNe/jF5libmZllhhKXrMGlq2W/Whf7q 9oIjZ8BYq2x5M3y/VVCH9vYihxFRT6D9Fpg2yw9ojFmJDt0shJuYf2ErJ/2Ymbpy n5JO/1MXtEKbczhmu1ngc23Z9LzOxeuEiZwGJWZoFmhQDlkitD6uOWYByYA4LdA1 W+OsL7tVdE6rUMX9WPJ75mcIgp5+U8mC05Y/pH5+m40/55ZvD1mJotkt4ME6V6f7 fKggPqz8rVZukvXEiTp4oW5CGy/C4zqC5nWiPF8hY8rhZrwpEo9/VFBneEi5Ouze vzSQCUzeQvxMbA1VdXB4EL03t3rt2w== =Fg2s -END PGP SIGNATURE-
Bug#1038611: lightdm: Lightdm fails to start X after upgrade to 1.32.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, 2023-06-21 at 09:40 -0300, Adilson dos Santos Dantas wrote: > These messages are when I stop lightdm. Ah ok. > > > > > > Also is there something peculiar about your hardware (Nvidia/AMD GPU for > > example?) or software (specific configuration or something). > > > I'm using Nvidia GPU: > > 01:00.0 VGA compatible controller: NVIDIA Corporation TU117 [GeForce GTX > 1650] (rev a1) > > And it is using its official drivers: > > dpkg -l xserver-xorg > Desired=Unknown/Install/Remove/Purge/Hold > | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig- > pend > |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) > ||/ Nome Versão Arquitectura Descrição > +++-==--- > = > ii xserver-xorg 1:7.7+23 amd64 X.Org X server > > dpkg -l xserver-xorg-video-nvidia > Desired=Unknown/Install/Remove/Purge/Hold > | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig- > pend > |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) > ||/ Nome Versão Arquitectura Descrição > +++-=--- > = > ii xserver-xorg-video-nvidia 530.41.03-1 amd64 NVIDIA binary Xorg > driver Yup, that's likely related. Honestly we (I) don't really support binary/proprietary drivers. It'd help if you could test with free drivers (nouveau or something maybe). Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmSTQAAACgkQ3rYcyPpX RFu7Ggf9FCsjsiXteQ+xDSolGEtK2a9eBlnCnI9MY3wY2OdOHJlNCpbEjamWVbw3 CwEn4//IWPgFmLcKBD1A9ySYein2tY3CDdNH5fii7ZZ/MNAlL1vuKAVuV30ayQtU V/4xxQXgJ+1JUCPzzKNGMdLs/yumAiLGAs3XzhjUmjVPQWMRWanCOf8dFavDyFG3 4sPS6niMeFUWqM17K0ja7VPVj2QbQQSe34jec93W+zcbnxbWZZuJY9nQ2PsQjRDd /FY0fBQtzopnZMBgRUdYNj09QGuI8kn6dZdD93+/MS2uP95ES7v1nG0bKARrGor7 pNaWlBMeMGI/+bL89SFEQdR52n/uFw== =tTX8 -END PGP SIGNATURE-
Bug#1038611: lightdm: Lightdm fails to start X after upgrade to 1.32.0
control: severity -1 important control: retitle -1 lightdm 1.32 fails to start X on nvidia binary driver On Thu, Jun 22, 2023 at 01:10:41AM -0300, Adilson dos Santos Dantas wrote: > I tested with the nouveau driver and it worked. > > Maybe there is something between 1.26 and 1.32 that conflicts with nvidia > driver. Yes it's likely. > > And it is also similar to #996503 which affects sddm and it worked too with > nouveau. Ack. As I understand it, X doesn't even start at all so it's likely unrelated to LightDM or sddm actually. Could you try in a terminal to just start X (with the `X` command), with NVidia and with Nouveau drivers, and report back? > > I tried to fix this by removing some module options from > https://forums.developer.nvidia.com/t/display-manager-sddm-lightdm-not-starting-with-nvidia-driver/243992 > but it had no effect. > > Maybe forwarding this to nvidia-driver should get some hints about this Yes, feel free to do it and report back any progress. I'm lowering the bug severity as well so it does migrate. Regards, -- Yves-Alexis Perez
Bug#1031968: libxfconf-0-dev fails to build with valac installed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, 2023-02-26 at 05:11 +0300, Arthur Demchenkov wrote: > Package: libxfconf-0-dev > Version: 4.18.0-1 > Severity: serious > Tags: ftbfs patch > Justification: fails to build from source (but built successfully in the > past) > > Dear Maintainer, > > To reproduce the problem please follow these steps: > > $ sudo apt install valac > $ apt-get source libxfconf-0-dev > $ cd xfconf-4.18.0 > $ dpkg-buildpackage -j`nproc` Hi, while I agree it'd be nice to fix that so all files can be successfully regenerated, I don't think I agree with the severity. As far as I can tell, the package built and still builds fine with a clean chroot? Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmP7HG4ACgkQ3rYcyPpX RFuWwQf/QmWPTQjD7r7AyTmhU6/p8ualRZKxOT/uW21mHQQ2wE/omxPwYqZ8nFZn 55uo7//u2ZKW2te5WX0FZDP1yTHtX5DtQABB7yiWbxVjlj7N2Mp1/NbGLgewGnj0 R330UOnC0vt7rB81AMT/QkP9Z9MxQnpCeF+KP1KIEUdPOebkC0oDyhUX8N0blRNU riCtzgYoe+o6jfz5LhMBEOGAOxakj3RxVLj/+niHhHini8PkhsoMLVKGS7lnx91E WJQnlcXbeinzP2P86HpV+3M91ZV65erB1tHD4dDtZnuyii5XtFvL58MSQqS6pmbb dsIQiVXtaTzQbpkPvMyXR4WMtn8SKg== =M4wl -END PGP SIGNATURE-
Bug#1027900: parole 4.16.0-2 does not start
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, 2023-01-04 at 15:12 +0300, Сергей Фёдоров wrote: > parole 4.16.0-2 when running in the terminal emulator outputs : > free(): invalid pointer > Emergency stop > > parole 4.16.0-1 is up and running. Yes indeed, so we have an issue with -1 which doesn't build, and -2 which doesn't run... We'll try to investigate when possible. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmPHo6QACgkQ3rYcyPpX RFso8wf/a4WKNKwWJ0klpyxStGxtoGL2TVFU1JdB8I+iMsVdIjC+4DoZleLs55Tx fMas2p0AdP7YrO7xcpHrdBLU4fcqHdmAGe3p5nda6oFhew2JfBVal5CCaZR74n80 kxUg3SIMiA8TGBiOk68x7dO6ukyYmWlzlcBVGnnoDLJbhNv71ZSsQDQ7UEYAllCx 9ZoIej0Yvev7eYomcRQQUiwehosBY+D/efaeQYNnZhnTaLkacWl6rzNZUYaSLoX3 H0xPBh/L2h9aGNYVR6aOdxj3juYeICVlFi876rcPLftVidtmoUgbcdgFx13fQzTW AEYqe9m+qCFzE+ofdiViAa/ksRSKFQ== =jQTc -END PGP SIGNATURE-
Bug#1026648: parole: FTBFS: make[1]: *** [debian/rules:22: override_dh_missing] Error 25
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, 2022-12-20 at 18:38 +0100, Lucas Nussbaum wrote: > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): > > make[1]: Entering directory '/<>' > > dh_missing --fail-missing -X .la > > dh_missing: warning: usr/parole/pixmaps/no-cover.png exists in debian/tmp > > but is not installed to anywhere > > dh_missing: warning: usr/parole/pixmaps/play.png exists in debian/tmp but > > is not installed to anywhere > > dh_missing: warning: usr/parole/pixmaps/replay.png exists in debian/tmp > > but is not installed to anywhere > > dh_missing: error: missing files, aborting > > The following debhelper tools have reported what they installed > > (with files per package) > > * dh_install: parole (5), parole-dev (1) > > * dh_installdocs: parole (0), parole-dev (0) > > * dh_installman: parole (1), parole-dev (0) > > If the missing files are installed by another tool, please file a > > bug against it. > > When filing the report, if the tool is not part of debhelper > > itself, please reference the > > "Logging helpers and dh_missing" section from the "PROGRAMMING" > > guide for debhelper (10.6.3+). > > (in the debhelper package: > > /usr/share/doc/debhelper/PROGRAMMING.gz) > > Be sure to test with dpkg-buildpackage -A/-B as the results may > > vary when only a subset is built > > If the omission is intentional or no other helper can take care of > > this consider adding the > > paths to debian/not-installed. > > make[1]: *** [debian/rules:22: override_dh_missing] Error 25 Hi Lucas, thanks for the report. It seems that the pixmaps aren't installed to the correct path, because pixmapsdir isn't defined to the correct place, in turn because DATADIRNAME isn't defined anymore. I'm unsure what changed in Debian since the initial upload in 2021, maybe some autoconf macros or something. It *seems* that DATADIRNAME might be obsolete (since a long time), it's not in /usr/share/aclocal/gettext.m4 but I can see a lot of embedded copies with https://codesearch.debian.net/search?q=DATADIRNAME (I looked at the gettext changelog but couldn't find a reference). It's likely an upstream issue but still I'm unsure where to point them. Apparently there's datadir/datarootdir but as I'm not an autoconf expert I'm not sure if it'd work in place. Any pointer appreciated here. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmOjJl8ACgkQ3rYcyPpX RFv/XwgA4Ly4KInLEQ2j60tBvndrsJ7B4RIRyJH8Lb1nxwdP/XAWq93o3p/6bgTR SCdYYhret3y2M2jbZiJLY51/9EpOzKc2Ut8K2+mtm3sHpT+mMWLs3qbufOTE2MpL VMPtWg0dMHT9/eOjXbrcKCrNFhJLm/oxsIgdSXzsNL/5z70ARCo7MYi97bt22KjW uEFXrctxqDRdG6srwtj3cfYGufMAtYFWGwLcj+zvR730IZcjdscXrhbb4yHGKF/R p9hrzKS6l/smBfRJyf9h1lSxH8Pw1AKV+qBO4n5sX7GJ6rdDHpsc3kuZlivvpgSM UmL9nyEmuhOyrhdL1VgZr+9FfEE76w== =kpYg -END PGP SIGNATURE-
Bug#929834: Buster/XFCE unlock screen is blank
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 control: affects -1 xserver-xorg-core On Sat, 2019-06-22 at 17:34 -0400, John Franklin wrote: > I've been suffering from this bug in a clean Buster system, too. A > solution noted in another bug tracker is to explicitly tell X.org to > use the intel driver. Apparently, it uses the fbdev driver by default. > (Sorry, I don't have a reference to other bug handy.) Hi John, it uses the modesetting DDX driver by default, not fbdev, but it's good to know that changing to the intel DDX workarounds the issue. Regards - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl0Rzk4ACgkQ3rYcyPpX RFsKGggAgv9hw7Cen7bEiCpPU87DniXPvJ+5NsszICoQXal7YBet/RMBpyYSoujo 7G32lLpazDO1s+f8TGReCx/JopjLsZgLVxtL6tOCBLFFBzfRTG8HnoQpwJrITwWU pPbp3e+shd5I6yKPqdv+ZoBG8Eq58poPgrzJbJXLRN3vMAafChl0C+b/N4NYUBuJ HIaz1qkKuoU3ZDtnMdNrIbsfHr/baO9B1Dht5/0TO3WHgd5UIRIuOqNgi4LnJxVF QOQJEYtJSWSZdJGVBGhP9/qxAPI69j/NgEYL1L4ITYb5YrDbPNJUbxBBw3G3nG2Z 4cbF9eOmWAqn4iD8EfoWA4p/i3fuCQ== =XzOA -END PGP SIGNATURE-
Bug#929834: Buster/XFCE unlock screen is blank
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Control: forcemerge -1 868087 On Thu, 2019-06-27 at 12:02 -0400, Onyuksel, Cem wrote: > I'd like to point out that this bug has a similar effect on nvidia graphics > as well, as pointed out in the bug report > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868087 > > And their solution was also to generate an xorg.conf file, so I'd guess > it's the same bug. Thanks for the pointer. nodiscc, could you tell us which devices drivers is used in both cases (working, after nvidia-config, and not working). The information should be available in /var/log/Xorg.0.log Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl0VFkIACgkQ3rYcyPpX RFtcoAf9HAtqK+rtLDCVVsSOaH/PxKG4ieZIubZg2jpSkbx15D1Alr09lHQ/EWpk /VwIIo+qh5Y+LvRn10b/K+HR5YXFwRAhsb2q0gMPvQioHDq2eG2292j8PhaDGGPQ XjjcY0Dot7+mnRs2TxtNfScbAYXHatpQRxDVVmrVzrbOQ07mp8+zPWE47yzvrlhQ /9yoB9eptzjJdA9RXZyqCAALB7Spi3OFjCSqa2Hn7IVJMj1R198RiqnO8CHvAcj8 XeoOTQf9ygwZqwMWcRMCQHMoovTMRHNeD6ciTwiiDyZhG+m5kwCXcbteQrlXvTA7 WwKI0xp2qVUBt0t/j0N0Phw+rSE4YQ== =Mdnh -END PGP SIGNATURE-
Bug#919348: is it still unfit for Bullseye?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, 2019-07-11 at 10:34 +0200, Adam Borowski wrote: > So... is there any reason to not let xfce4-screensaver go to Bullseye? > Any day that a human being suffers from light-locker is a bad day. Hi Adam, could you please refrain from such statements? Some people, volunteers mostly, have taken time to actual write that software, package it etc. I find this rude, to be honest. > > If you're afraid about yet-unknown bugs, more exposure to users early > in the release cycle would be a good idea. For a locker screen, I'd really like someone to take a look at the code (even if only the differences with gnome-screensaver). The light-locker code in the process which does the locking is actually quite simple (no complicated UI, no screensaver at all etc.) > On the other hand, > light-locker suffers from a multitude of known problems (see the recent > debian-devel thread), and you hate the third alternative, xscreensaver Actually no-one seems to know which package(s) is buggy. My gut feeling is that the drivers handle vt-switches and backlight off badly, not a bug in light-locker. But again no-one seems interested to find out. If you volunteer, I welcome any help on this, whether by finding the issues with the light-locker/lightdm/DDX stack or actually making sure there's no security issue in xfce4-screensaver. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl0p7V8ACgkQ3rYcyPpX RFukHgf/ZnnS9kS/YG0jO2hB1ztalDxZ6UeQqgCGBiJXnlha228HtDD5Xku2noUZ 1Ke/pGAzULmugjbbhHGc8AmbgIJGgRP+WdjCy9aaVghLvVPdW3y31hh2GSQgUOTV aqFT9t0PqoLH/71UwmON0WT4/6BUlcm8dcmpZ80lv2Z1nd1nCuVJ/52sM8NY342m DwBU7NB4d17liKTmLp4opH5+JVA77DbJkXx7SsJBI5Lkkp/71sv8FLQv+nNSGSH5 7rf8xg1JLaMflVdcmk2IPYgYlkZT4pfJWgnma6onz7cQURjco8sZ0Iinzei4E5xC K3Ay7gY7+aYNAewN2AgT04euMHwWOg== =holV -END PGP SIGNATURE-
Bug#919348: is it still unfit for Bullseye?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 control: reopen -1 On Sun, 2019-07-14 at 00:44 +0200, Adam Borowski wrote: > But, in this case, I am very excited that you have a replacement for > something I find to be hopelessly buggy -- and the replacement seems > near-perfect. Thus, if you switch, you save a lot of time, and any bit of > time you save is a bit of time you can spend catering to my other whims. :) I've done a bit of testing of xfce4-screensaver and *twice* today it segfaulted on me: [1544037.932910] xfce4-screensav[4272]: segfault at 20016 ip 7819061b801c sp 7fff9b07d7c8 error 4 in libgobject-2.0.so.0.5800.3 (deleted)[78190618e000+32000] [1604078.180051] xfce4-screensav[22182]: segfault at 20016 ip 79321bc2201c sp 7ffeac850768 error 4 in libgobject-2.0.so.0.5800.3[79321bbf8000+32000] I didn't investigated those crashes yet but that doesn't look that good. When the locker crashes,the session is wide open. When that happen at lid close, for example, you don't have any feedback. So I wouldn't push xfce4-screensaver in a stable release right now. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl0uFi8ACgkQ3rYcyPpX RFtsnAgAhZlWoV+Y4l+V5l0XBO2V8MBb/PkINU+I1WiwhlTMYpj6y6zF8L3Fe4SU K4TPnLOVy6jPYEI4PnSikjL30UzemROoEY6kXLb30H5Myyr5LGgmc0vcGcKLgNs0 CFEJkxIbnVAweRGcTG4n0oVA4Wku87KrTVesyLwXU+KZ2UARvUE0cTk002GEYJ+B 6mIyNb58FDqQ5W33PeGeH+awDsNl+JRI99Gh464rRddFngbkiw8pMSNgaCegs0jh f6B7S7uSiHktsqurW4Mg8lYlx/apqqyWuU1Xnj5DG1cthBlk51cn6Nqn9BUk5Mob JGS37cCfWZbBJ6Yj9KdN7YdigmcvKw== =XjcB -END PGP SIGNATURE-
Bug#988394: thunar: CVE-2021-32563
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, 2021-05-11 at 21:45 +0200, Salvatore Bonaccorso wrote: > The following vulnerability was published for thunar. > > CVE-2021-32563[0]: > > An issue was discovered in Thunar before 4.16.7 and 4.17.x before > > 4.17.2. When called with a regular file as a command-line argument, it > > delegates to a different program (based on the file type) without user > > confirmation. This could be used to achieve code execution. > > > If you fix the vulnerability please also make sure to include the > CVE (Common Vulnerabilities & Exposures) id in your changelog entry. Hi Salvatore, thanks for the heads up. We have Thunar 4.16.3 in testing and 4.16.4 in sid. It'd be best to update everything to 4.16.8 but I'm unsure the release team will like that, so I'll also look at isolating the fix. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmCdXGEACgkQ3rYcyPpX RFsjPAgA7FaKksal1xCLD/k/Y5I2Q4RkH3X/kxpObKguWPLAU+1Q/hzTbY9GTsla BpXhqp0JBo/s++5d5IMWtegF2M2DPmfe0yGV86sxFLJj4bKweIG62otjUuxr8dAI yJY9mLzypHR9ywcbOZsD1U2wzaSkJkOj7b+SXLQyowTuwda+LwPNAJNDbo8ishYh wUSodVcbxeZIeKF7dIn2tWpxQ69LRYYVaJm5u2ZZpGWfe0oJlYzFEha6XLc+CAsv SAWB+MwXTQ9INdImN8BlPUHdxK61AUD6UkxYN+hIPhwC2nIrG1d/IZDC8B7Gw/8m rFpkfO1jXgIV1wddJxdFl1YlL5ITWw== =W5K2 -END PGP SIGNATURE-
Bug#988394: thunar: CVE-2021-32563
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, 2021-05-13 at 20:58 +0200, Salvatore Bonaccorso wrote: > Thank you! Btw, I sitll would try to check if release team would > accept 4.16.8 itself. Note I'm as well not sure about if this will > need a DSA or can be fixed via point release, but given your double > hat on I will leave that decision to you :) Yeah I reached out to the release team, and will follow up with a bug at their request. For stable I'm unsure. I'm not sure it warrants a DSA indeed, but in any case stable has 1.8.4 and I'm unsure how hard it is to backport the fixes, I'll investigate. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmCeQ5gACgkQ3rYcyPpX RFua1Qf7BItMSf215l3koGvolA6w/nRsdCSkPOoFQDf7VFsxdZyofJoVH+lYwU8/ N7FciTdOMkGfcGVPH0IrYEBPVPDgbgyMcVwgbroeaC4d3bHD33+k8LZS7WWDa+Ky XCk6dFrKaFRv/vHK/BrjuJq4J4MBfkjPoyyDB24o67qIQsDUUgw9inxkYqe1SmUw ml5GwYe9Moojtz5Ydvy0c1A+I6dWvgMeXCAQIkMQVTzDouPL5obf3iGD/coHczQO 6elhaw1wCTPl7zDhy1yrtjGX5w7m2fqtCOeEcuA+3/IViDDDcJYrK7H9fBcykkZ4 EDQ3Ts4RS1lsc7EbvljKGzAkKau8hA== =6pz1 -END PGP SIGNATURE-
Bug#978232: orage: FTBFS: build-dependency not installable: xfce4-panel (= 4.14.4-1)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 2021-01-08 at 14:10 +0200, Juhani Numminen wrote: > Thank you Yves-Alexis for implementing this in orage/4.12.1-8. > > I noticed that the removal request still stands ( > https://bugs.debian.org/977628 ). > Do you still intend to remove orage from Debian or are you happy to keep it > for now? I don't really think it's sustainable if upstream is gone. I think it's better if the “last state” doesn't FTBFS, but I don't think we can ship it in Bullseye since the last upstream version is so old. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl/4ktMACgkQ3rYcyPpX RFsGmAgA0QIwFK+q4h59CKfUxtctOlb1fxmK3wT8795VeePesR/zAFZOqta8BeUI nQ7W6/RoCSMvfkvVogjB8A2sFrT/lD6OlwlsI+AxzfAaNUcqbiMaixlutGobIojd wOATph21h908/pmPv9OGGb4JC+/xOP7myw50TzU6DQs2j0hu7FzsoOA5iEjIpfMe D6QAe5wYATyLL/E5VuEdgqKvejm7ja0TAZEVqMLzYw7myGBg13xiTsJ6SYxKGNRS eL9i8QHorYDLPzy6c/1/+vl9K6XiChqh73VOzzYq4qjGqXm7/ez7iG9r0wu/Xs2l isupbJDgsg+kZuJGWR9CEpn6LroCug== =Nu2L -END PGP SIGNATURE-
Bug#972417: xfce4-power-manager: System left idle => 'display power management' auto-locks session => no X session or lightdm greeter
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 control: forcemerge 870641 -1 On Sun, 2020-10-18 at 10:23 +0200, franck wrote: > Package: xfce4-power-manager > Version: 1.6.1-1 > Severity: grave > > Dear Maintainer, > > [ Bug description ] > Bug happens when the screen auto-locks due to user inactivity. Then the > screen switches off. > To easily test that, set following to 1 min or so > Xfce menu Applications -> Settings -> Power Manager -> Display -> 'Switch > off after' > > After such auto-lock, it appears not possible to get back the X session > anymore. > Because > - by moving mouse or typing on keyboard the screen does not wake up. It > stays off, black. > - with Ctrl+Alt-F7 one gets > This session is locked > You’ll be redirected to the unlock > dialog automatically in a few seconds > but after waiting a few seconds the screen switches off again. > => no way to get to the lightdm greeter. > In both cases: not possible to get back the running X session anymore. The lightdm greeter is on tty8, so try with Ctrl-Alt-F8. > > => I filled this bug against xfce4-power-manager > But I have no clue whether xfce4-power-manager > - processes the locking completely by itself ? > - just prepares locking, like deactivating keyboard/mouse? and then trigger > like light-locker-command --lock... > - only asks another package to do the full locking procedure. > > > > Bug occurred under (at least) both kernels: > linux-image-4.19.0-11-amd64-unsigned 4.19.146-1 > linux-image-5.8.0-0.bpo.2-amd64 5.8.10-1~bpo10+1 > > > > Also this bug gives a bad image to the user: > - 'system crashed' > - wondering what is the cause: > - is my graphic card not properly waking up ? > - or a bug in kernel ? > - or Xorg ? > - or light-locker ? > ... > Thus they are probably numerous of open bugs that could be closed by fixing > this bug. Actually it's (or should be) already fixed in stable. > > > [ Bugs reported against other packages, & that seem linked to this bug ] > Bugs in source package light-locker > #906902 System left idle makes system freeze > #870641 light-locker, lightdm: screen stays off after resume > and all the merged one: > 805711, 846278, 868087, 908329, 922095, 929461, 929834, 931555 > #835461 light-locker breaks suspend/resume with nvidia legacy 340 drivers > Bugs in source package lightdm > #867620 lightdm unlock screen randomly doesn't appear With all those bugs already opened and the mess we're already in, why opening *yet another one*? Honestly it adds more confusion than anything at that point. As indicated in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870641#218 the bug *should* be fixed in 10.5 with kernel 4.19.0-10. You indicated that you tested with linux-image-4.19.0-11-amd64-unsigned 4.19.146-1 Can you retry with that kernel and check you have the “atomic” message in the kernel log: broken atomic modeset userspace detected, disabling atomic Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl+gRRsACgkQ3rYcyPpX RFvT2Qf+K/oere1FxlQi2jg+f/iL6ejQLL/jowc5R3pg34Jp3jJMPvWe6HYz7c2L +88W5GqwhI88Qk5oiGMdEf+3s8eKwoJi2kBp92g6HFyk6Xjbe7vzs7FOhUeeHadE 9ezgXfKzrDlhM4Knm3JtTEgKbgnEeOSop78hfzkaTrH94sbR75taK8yMo7Yuec3i gIezlzkkOTuT37oDzrG2hyD9A/mEnQTWw3pw97kqHZo3meEtTjwZ9/vutd2MuzQM zJG5qpCLH7G8fywBWzW6SZSDhChAo44Phz2fHDmlPLKtHUTAn03nHPwkdgUgg0Kw 3iaNBwgSZaPfZrPRh4yIhhN9rUodhQ== =SWS6 -END PGP SIGNATURE-
Bug#973652: xfce4-helpers: missing Breaks+Replaces: libexo-common (<< 4.15)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 control: tag -1 pending On Mon, 2020-11-02 at 21:07 +0100, Andreas Beckmann wrote: > during a test with piuparts I noticed your package fails to upgrade from > 'sid' to 'experimental'. > It installed fine in 'sid', then the upgrade to 'experimental' fails > because it tries to overwrite other packages files without declaring a > Breaks+Replaces relation. Hi, thanks for the report, I've updated the package in our repository and will do an upload soon. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl+hEOkACgkQ3rYcyPpX RFttfggAkBS8fer1daX2jzDWJGJDdEQlOBkaA+WL3YGxnQOS/9amcdE5EaUxeMSd mv2Xmurk0+j2hPoCkg46Ax9WKh6htD8S1S43UqIM9jLkA/mLhPunbwEXiTzcozHx QZsfOQnfp8yvwoY+xFklOkMMZdc7jZPvQU1LjUSUJ/vXJamhiJLV/FEomTgloGJX DI0OCVy9ExamYZCKWk+MCi/arlJW7YaaDzWNNvWd7hA7qwPa6xbnlGKZZ/RHWFTO YvK5hZcTLeMikPhpDFjnWWmxmmHTMtSrDy/I8bjGaVTZqRTA7uLLxf5KVpMhHG7H 873vFYgB3JJPWTJbdUs3HDbt0Sqcgw== =S2FG -END PGP SIGNATURE-
Bug#919348: many new releases since -- still "too buggy"?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, 2021-02-04 at 14:43 +0200, Adrian Bunk wrote: > Yves-Alexis, do you have any objections to closing this bug now? Yes. I have xfce4-screensaver (4.16) running on a Debian sid install and it still happens every once in a while that the desktop of the locked box appears (for example at resume). I'm still not confident it should actually be used on a production install it's just not robust enough, but I don't have the time or motivation to investigate and fix it myself. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmAcRBUACgkQ3rYcyPpX RFugAAgA3B0u6cT682/Ks+TPVPy4eW7z9YsrtNz0MS2aMhxsDNbgu4iI2IKviGd2 4z4Pai+0MxlwDA0r5/jFAmyqrsqJ/ze7B0SdoizaDG976/62qQ1+KH8pPeP/h+zJ 1qYxr/8tRubTOaUBEdPoTkPNuzWWpQzKtggsV/J/HpRa7Lr94rsiie+Buig474hS Wl7oqw1CkCHnBFf8n+ZA9Y9DByqdXS0tNHu3fMeDWDdzl7/pL5J6amJY+sXkYuVo f0FoFth7GmbKKZKBNhPhjtgyo8Q8kG6A3kSlq8WDqlUeIFbYP/ScmfsjiLhCw4fb 8TjW7HaWaprxaJlAJlrSEmwQHpEqKA== =JzSz -END PGP SIGNATURE-
Bug#977231: libusb-1.0-0: upgrading to 2:1.0.24-1 breaks iPhone/iPad detection and communication
On Sat, 2020-12-12 at 21:31 +0100, Aurelien Jarno wrote: > > Indeed, I do not have such a device. As a first step, it would be nice > if you can set the environment variable LIBUSB_DEBUG=99 and run lsusb. > That should give us an idea why the device is ignored. Here are two logs (with .22 an .24). Not much differences that I can see, besides the max iso packet length. Regards, -- Yves-Alexis [timestamp] [threadID] facility level [function call] [ 0.05] [3e62] libusb: debug [libusb_init] created default context [ 0.65] [3e62] libusb: debug [libusb_init] libusb v1.0.22.11312 [ 0.000100] [3e62] libusb: debug [find_usbfs_path] found usbfs at /dev/bus/usb [ 0.000122] [3e62] libusb: debug [get_kernel_version] reported kernel version is 5.9.0-4-amd64 [ 0.000130] [3e62] libusb: debug [op_init] bulk continuation flag supported [ 0.000137] [3e62] libusb: debug [op_init] zero length packet flag supported [ 0.000144] [3e62] libusb: debug [op_init] max iso packet length is (likely) 49152 bytes [ 0.000162] [3e62] libusb: debug [op_init] sysfs can relate devices [ 0.000170] [3e62] libusb: debug [op_init] sysfs has complete descriptors [ 0.000484] [3e63] libusb: debug [linux_udev_event_thread_main] udev event thread entering. [ 0.008973] [3e62] libusb: debug [linux_get_device_address] getting address for device: usb1 detached: 0 [ 0.008997] [3e62] libusb: debug [linux_get_device_address] scan usb1 [ 0.009080] [3e62] libusb: debug [linux_get_device_address] bus=1 dev=1 [ 0.009088] [3e62] libusb: debug [linux_enumerate_device] busnum 1 devaddr 1 session_id 257 [ 0.009095] [3e62] libusb: debug [linux_enumerate_device] allocating new device for 1/1 (session 257) [ 0.009284] [3e62] libusb: debug [linux_get_device_address] getting address for device: 1-1 detached: 0 [ 0.009295] [3e62] libusb: debug [linux_get_device_address] scan 1-1 [ 0.009364] [3e62] libusb: debug [linux_get_device_address] bus=1 dev=11 [ 0.009372] [3e62] libusb: debug [linux_enumerate_device] busnum 1 devaddr 11 session_id 267 [ 0.009378] [3e62] libusb: debug [linux_enumerate_device] allocating new device for 1/11 (session 267) [ 0.009449] [3e62] libusb: debug [linux_get_parent_info] Dev 0x62f5a7d478d0 (1-1) has parent 0x62f5a7d47060 (usb1) port 1 [ 0.009572] [3e62] libusb: debug [linux_get_device_address] getting address for device: 1-3 detached: 0 [ 0.009581] [3e62] libusb: debug [linux_get_device_address] scan 1-3 [ 0.009643] [3e62] libusb: debug [linux_get_device_address] bus=1 dev=2 [ 0.009650] [3e62] libusb: debug [linux_enumerate_device] busnum 1 devaddr 2 session_id 258 [ 0.009656] [3e62] libusb: debug [linux_enumerate_device] allocating new device for 1/2 (session 258) [ 0.009712] [3e62] libusb: debug [linux_get_parent_info] Dev 0x62f5a7d474e0 (1-3) has parent 0x62f5a7d47060 (usb1) port 3 [ 0.009843] [3e62] libusb: debug [linux_get_device_address] getting address for device: 1-3.4 detached: 0 [ 0.009851] [3e62] libusb: debug [linux_get_device_address] scan 1-3.4 [ 0.009916] [3e62] libusb: debug [linux_get_device_address] bus=1 dev=4 [ 0.009923] [3e62] libusb: debug [linux_enumerate_device] busnum 1 devaddr 4 session_id 260 [ 0.009929] [3e62] libusb: debug [linux_enumerate_device] allocating new device for 1/4 (session 260) [ 0.009984] [3e62] libusb: debug [linux_get_parent_info] Dev 0x62f5a7d47650 (1-3.4) has parent 0x62f5a7d474e0 (1-3) port 4 [ 0.010115] [3e62] libusb: debug [linux_get_device_address] getting address for device: 1-3.4.2 detached: 0 [ 0.010123] [3e62] libusb: debug [linux_get_device_address] scan 1-3.4.2 [ 0.010187] [3e62] libusb: debug [linux_get_device_address] bus=1 dev=6 [ 0.010194] [3e62] libusb: debug [linux_enumerate_device] busnum 1 devaddr 6 session_id 262 [ 0.010200] [3e62] libusb: debug [linux_enumerate_device] allocating new device for 1/6 (session 262) [ 0.010257] [3e62] libusb: debug [linux_get_parent_info] Dev 0x62f5a7d46f20 (1-3.4.2) has parent 0x62f5a7d47650 (1-3.4) port 2 [ 0.010395] [3e62] libusb: debug [linux_get_device_address] getting address for device: 1-3.4.2.3 detached: 0 [ 0.010402] [3e62] libusb: debug [linux_get_device_address] scan 1-3.4.2.3 [ 0.010468] [3e62] libusb: debug [linux_get_device_address] bus=1 dev=7 [ 0.010475] [3e62] libusb: debug [linux_enumerate_device] busnum 1 devaddr 7 session_id 263 [ 0.010498] [3e62] libusb: debug [linux_enumerate_device] allocating new device for 1/7 (session 263) [ 0.010558] [3e62] libusb: debug [linux_get_parent_info] Dev 0x62f5a7d28c10 (1-3.4.2.3) has parent 0x62f5a7d46f20 (1-3.4.2) port 3 [ 0.010724] [3e62] libusb: debug [linux_get_device_address] getting address for device: 1-3.4.2.4 detached: 0 [ 0.010733] [3e62] libusb: debug [linux_get_de
Bug#977231: libusb-1.0-0: upgrading to 2:1.0.24-1 breaks iPhone/iPad detection and communication
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, 2020-12-12 at 21:31 +0100, Aurelien Jarno wrote: > > If you need more information don't hesitate to ask (I guess you don't > > have an iDevice to plug for testing). > > Indeed, I do not have such a device. As a first step, it would be nice > if you can set the environment variable LIBUSB_DEBUG=99 and run lsusb. > That should give us an idea why the device is ignored. I also did a bisect run between v1.0.22 and HEAD (upstream repository) and here's the result: e2be556bd262cd260bebe3fc724509692537eba3 is the first bad commit commit e2be556bd262cd260bebe3fc724509692537eba3 Author: Chris Dickens Date: Wed Apr 29 12:39:35 2020 -0700 linux_usbfs: Parse config descriptors during device initialization Do the work ahead of time and cache the results so that fetching config descriptors becomes a trivial operation. Signed-off-by: Chris Dickens libusb/os/linux_usbfs.c | 263 ++- - - libusb/version_nano.h | 2 +- 2 files changed, 145 insertions(+), 120 deletions(-) bisect run success With the following bisect log: git bisect start # bad: [c6a35c56016ea2ab2f19115d2ea1e85e0edae155] libusb 1.0.24 git bisect bad c6a35c56016ea2ab2f19115d2ea1e85e0edae155 # good: [0034b2afdcdb1614e78edaa2a9e22d5936aeae5d] libusb 1.0.22 git bisect good 0034b2afdcdb1614e78edaa2a9e22d5936aeae5d # good: [48200f2cc23633899270e7c666ac7e948ead8df1] core: Fix build on linux git bisect good 48200f2cc23633899270e7c666ac7e948ead8df1 # bad: [26611eaa494ed9e077b5b0e1f999f5ae377de958] Windows: Translate ERROR_NO_SUCH_DEVICE to LIBUSB_TRANSFER_NO_DEVICE git bisect bad 26611eaa494ed9e077b5b0e1f999f5ae377de958 # good: [09d0312fbb466ce2457df94e314ba1348039138d] Xcode: Update project file git bisect good 09d0312fbb466ce2457df94e314ba1348039138d # good: [71a3fb3faadb79c2ccff8f23f0520e4015f547f3] Android: fixes unknown warning option from ndk build git bisect good 71a3fb3faadb79c2ccff8f23f0520e4015f547f3 # good: [e873677b9196b191d6cdbdf9783c6d6a18379249] descriptor: Minor improvements to the parse_descriptor() function git bisect good e873677b9196b191d6cdbdf9783c6d6a18379249 # good: [8476804b283cfed82aec5e45301b51be3ad68e99] descriptor: Remove usbi_get_config_index_by_value() git bisect good 8476804b283cfed82aec5e45301b51be3ad68e99 # good: [14a302a2f55cb2e619158854f94845f2ca2c8214] sunos: Fix a number of compiler warnings git bisect good 14a302a2f55cb2e619158854f94845f2ca2c8214 # bad: [e2be556bd262cd260bebe3fc724509692537eba3] linux_usbfs: Parse config descriptors during device initialization git bisect bad e2be556bd262cd260bebe3fc724509692537eba3 # good: [e9eec3a680cad3b2c9c5213fb7d60148cf6900da] core: Narrow the types passed to certain backend functions git bisect good e9eec3a680cad3b2c9c5213fb7d60148cf6900da # first bad commit: [e2be556bd262cd260bebe3fc724509692537eba3] linux_usbfs: Parse config descriptors during device initialization I can't just git revert the bad commit on top of master (there are conflicts), but it's worth looking at it. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl/V7SwACgkQ3rYcyPpX RFvvowf7BoqO00heSNbxsg9mUSAIfadHNhDEbT9wHHK383SVYUeFO7XYvqsuH5La WZGKYoL1FGVNm4d6xUpmiCo44FOzoVgFK1n9Oh91YPt3guPCQFb/eWXk/szafpwl yRZ8N7ceFDcGdimVozkOIM6WQXHi3q3sH2IxzUWCzSmlpzPu/J6qkKb+6aEcBoC7 21Nq+7NhJsmtQog7Nwue2egcLucfP5VhGrz0cr5ySGY81o0tASi4ItnWzNNckKhu Otj2IB5Oz7VbK90DAbAv9qSXmHqYu7iu6wLmI1HuvqGFKwN96Zdkfc/You8wfq1I aaQzV26TTSFmiWniCckgK60B6MWlmw== =4/+F -END PGP SIGNATURE-
Bug#862436: [Pkg-xfce-devel] Bug#862436: xfce4-weather-plugin: weather API 404
On Fri, 2017-05-12 at 11:53 -0500, Nathaniel Beaver wrote: > Package: xfce4-weather-plugin > Version: 0.8.3-2 > Severity: grave > Justification: renders package unusable > > Dear Maintainer, > > The met.no Web API is deprecated: > > http://api.met.no/weatherapi/sunrise/1.0/?lat=0;lon=0;date=2017-05-12 > > The bug was reported in 2014 here: > > https://bugzilla.xfce.org/show_bug.cgi?id=10916 > > It is already fixed in version 0.8.9-1, which is available in testing > and unstable. > > https://tracker.debian.org/pkg/xfce4-weather-plugin > > Is it possible the fix will be backported? I've packaged a backport and requested permission to do a stable upload (#862481). You can find an amd64 package at https://perso.corsac.net/~corsac/d ebian/xfce4/xfce4-weather-plugin_0.8.3-3_amd64.deb along with the .dsc. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#843727: fix inside
On Sun, 2016-12-18 at 12:33 +0100, Holger Levsen wrote: > what's stalling the uploads? (either to experimental or unstable even…) See <1481014791.20278.9.ca...@debian.org> but nothing is really preventing an upload, just time. > > can I help? I should be able to push an upload to experimental later today, unless someone really wants it in unstable. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#843727: fix inside
On Sun, 2016-12-18 at 12:17 +, Holger Levsen wrote: > justification: testing should always be in a releasable state, and even more > so now the freeze is getting closer… Well, that won't really change with an upload right now, depending on what you consider “releasable state“: - the current package in stretch and unstable works just fine but doesn't has the Stretch theme (at all); - the current package in experimental seems to works just fine but doesn't has the (complete) Stretch theme. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#842675: [Pkg-xfce-devel] Bug#842675: Fix, NMU to DELAYED/5
On Fri, 2016-12-16 at 08:05 +0100, Hilko Bengen wrote: > here is a set of patches that I intend to NMU to DELAYED/5 later. I have > changed the .symbols file to use C++ name demangling and added some > optional symbols that seem to come directly from the Qt library. > > I have also taken the liberty to add a missing dependency on lsb-base > which was flagged as an error by Lintian. Hi, can you confirm it works on both Intel and non Intel arches? Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#843727: fix inside
On Sun, 2016-12-18 at 12:38 +, Holger Levsen wrote: > Even incomplete, I consider having it in to be better than having the > totally wrong jessie artwork in stretch for these two reasons: I understand that, it's just not my opinion (as expressed earlier). I won't oppose an upload, I was just expressing the reason I didn't make the upload myself yet. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#827304: [Pkg-xfce-devel] Bug#827304: unable to reproduce the issue on three AMD64 systems
control: severity -1 important On Tue, 2016-09-20 at 14:10 +0200, Daniel Lange wrote: > Control: tags -1 unreproducible > > I've tried to reproduce the issue for 48h on three AMD64 systems I've > happened to have around here temporarily with fresh Debian testing > installs. Got to use the opportunity. One of the systems was used for > heavy editing, the two other for occasional editing with lots of idle > times. The theme was set to oblivion on mousepad invocation as > instructed by the bug submitter. > There were no crashes and no uninstructed switch of themes. > The memory consumption was also bound and only changed when editing and > saving. > > So this look like an issue that may have been specific to the affected > system. As there have been no confirmations in three months either, > I suggest reducing the bug severity. > Done. Without any news from the reporter I'm even inclined to just close the bug. -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#842675: [Pkg-xfce-devel] Bug#842675: Bug#842675: Fix, NMU to DELAYED/5
On Sun, 2016-12-18 at 13:28 +0100, Yves-Alexis Perez wrote: > On Fri, 2016-12-16 at 08:05 +0100, Hilko Bengen wrote: > > here is a set of patches that I intend to NMU to DELAYED/5 later. I have > > changed the .symbols file to use C++ name demangling and added some > > optional symbols that seem to come directly from the Qt library. > > > > I have also taken the liberty to add a missing dependency on lsb-base > > which was flagged as an error by Lintian. > > Hi, > > can you confirm it works on both Intel and non Intel arches? I'd prefer to do the upload myself, but in any case please don't upload with the package revisions in the symbols file. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#842675: [Pkg-xfce-devel] Bug#842675: Fix, NMU to DELAYED/5
On Sun, 2016-12-18 at 15:51 +0100, Hilko Bengen wrote: > Yes, I have done successful builds on amd64, mipsel, mips64el, armhf, > arm64. > Please do the upload yourself. > > Since the Qt symbols that somehow got into the library are not really > part of the ABI, you may want to change them like this: > > (c++|optional)"QByteArray::~QByteArray()@Base" 0 > (c++|optional)"QDBusError::~QDBusError()@Base" 0 > (c++|optional)"QHash::~QHash()@Base" 0 > (c++|optional)"QString::~QString()@Base" 0 Thanks, I didn't know about the |optional syntax. I'll include your patch and upload. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#846026: [Pkg-swan-devel] Bug#846026: Bug#846026: strongswan: FTBFS randomly (failing tests)
control: severity -1 important control: tag -1 moreinfo On Mon, 2016-11-28 at 10:05 +0100, Yves-Alexis Perez wrote: > On Sun, 2016-11-27 at 23:13 +0100, Santiago Vila wrote: > > The failure happens randomly. Sometimes it fails, sometimes it does not. > > Check exactly where the testsuite fails, it might be lack of entropy. I'd > rather not disable the testsuite altogether, we already limit it to few > architectures to prevent that from happening too much. > So, did you investigate? I'm lowering the severity for the reason above, we had no issues that I could in autobuilders with the current setup Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#848022: linux-image-4.7.0-1-grsec-amd64: fails to use hp-health. hpasmlited segfault
control: severity -1 important control; tag -1 moreinfo On Tue, 2016-12-13 at 11:18 +0100, Network Services wrote: > * What led up to the situation? : service hp-health won't start anymore. Did it ever start on a grsec kernel? > * What exactly did you do (or not do) that was effective (or > ineffective)? : package work on 3.16.0-4-amd64 kernel but crash on this > one. Error in kern.log > > 2016-12-13T11:02:28+01:00 taal kernel: : [ 543.675893] x86/PAT: > hpasmlited:32223 map pfn expected mapping type uncached-minus for [mem > 0xdf7fe000-0xdf7fefff], got write-back > 2016-12-13T11:02:28+01:00 taal kernel: : [ 543.676037] hpasmlited[32223]: > segfault at 0 ip 00422afb sp 03fc131c6b50 error 4 in > hpasmlited[20+238000] I'm not familiar with hpasmlited and how it works so you might want to explain that. Also it's apparently not in Debian so I won't be able to provide any help. In any case, my guess would be that it tries to map some page RWX and PaX won't allow that. It doesn't expect mmap or mprotect to fail and thus crashes like that (it's a bug in hpasmlited in any case). You might want to look at the sources if you have them, and you might want to run it under strace just to check if that's a mmap/mprotect call failing. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#865678: knot: Improper TSIG validity period check can allow TSIG forgery
On Fri, 2017-06-23 at 19:01 +0200, Salvatore Bonaccorso wrote: > Source: knot > Version: 2.4.3-1 > Severity: grave > Tags: security upstream patch > Control: found -1 2.5.1-1 > > Hi > > See > https://lists.nic.cz/pipermail/knot-dns-users/2017-June/001144.html > and > http://www.synacktiv.ninja/ressources/Knot_DNS_TSIG_Signature_Forgery.pdf > and filling a bug in BTS to have a reference, afaik there is no CVE > yet assigned. > > [16:19] < KGB-1> Yves-Alexis Perez 52846 /data/CVE/list add temporary entry > for knot > [16:21] < Corsac> ondrej: I guess you know about it? I went ahead and uploaded fixes to jessie and stretch. I've also pushed my branches to https://anonscm.debian.org/cgit/users/corsac/security/knot.git/ in case you want to reimport them. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#868626: [Pkg-xfce-devel] Bug#868626: libgarcon-1-0-dev is not installable
On Mon, 2017-07-17 at 04:13 +0300, Adrian Bunk wrote: > Package: libgarcon-1-0-dev > Version: 0.6.1-1 > Severity: serious > > Package: libgarcon-1-0-dev > Version: 0.6.1-1 > Depends: libgarcon-1-dev > > Package: libgarcon-1-dev > Version: 0.6.1-1 > Breaks: libgarcon-1-0-dev Hi could you transform that into a readable bug report, please? Thanks in advance, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#870207: [Pkg-xfce-devel] Bug#870207: light-locker-command --lock returns 0 without locking (breaks slock)
control: severity -1 important On Sun, 2017-07-30 at 22:54 +, Daniel Shahaf wrote: > Package: light-locker > Version: 1.7.0-3 > Severity: serious > Justification: breaks unrelated software > > Dear Maintainer, > > On my system, 'light-locker-command --lock' returns 0 without doing > anything. I presume that is because there no 'light-locker' process is > running (due to #858445). In case it's relevant, I don't use lightdm > either; I login by running 'startx' in a vt. > > That breaks the Ctrl+Alt+Del (lock screen) combination in xfce4, which > defaults to running xflock4. xflock4 invokes a number of screen lockers > and exits whenever any one of them returns true: > > % sh -x /usr/bin/xflock4 > + PATH=/bin:/usr/bin > + export PATH > + xscreensaver-command -lock > + light-locker-command --lock > + exit > (the screen did not lock) > > Could the --lock option please learn to return non-zero when it did not > lock the screen. This way, xflock4 would start working again. > > Thanks, > > Daniel > > P.S. My /usr/bin/xflock4 comes from xfce4-session/4.12.1-5. Hi, it should be fixed in light-locker 1.8.0 which I intend to upload soon to unstable. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#870666: [Pkg-xfce-devel] Bug#870666: libxfcegui4 FTBFS: ./configure: line 13746: syntax error near unexpected token `am'
On Fri, 2017-08-04 at 00:01 +0200, Helmut Grohne wrote: > > checking whether environ is declared... yes > > ./configure: line 13746: syntax error near unexpected token `am' > > ./configure: line 13746: `XDT_I18N(am ar ast be bn_IN ca cs cy da de dz el > > en_GB eo es et eu fa fi fr gl gu he hr hu hy id is it ja ka kk ko ku lt lv > > mk mr nb nl nn pa pl pt_BR pt ro ru si sk sq sv ta te tl_PH tr ug uk ur_PK > > ur zh_CN zh_TW )' > > tail -v -n \+0 config.log > > ==> config.log <== I just did a successful build using pbuilder, then upgraded the pbuilder chroot and the build started to fail with the same error so I guess something changed in the toolchain (gah.). For future reference for myself, here and the changed packages: The following packages will be upgraded: binutils gcc-7-base libatomic1 libc-bin libc-dev-bin libc6 libc6-dev libcc1-0 libcilkrts5 libgcc1 libgomp1 libitm1 liblsan0 libmpx2 libperl5.26 libquadmath0 libstdc++6 libtsan0 libubsan0 multiarch-support perl perl-base perl-modules-5.26 23 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Not sure if the problem lies in libxfcegui4 or in the toolchain but I'm unlikely to find a fix right now. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#870666: [Pkg-xfce-devel] Bug#870666: Bug#870666: libxfcegui4 FTBFS: ./configure: line 13746: syntax error near unexpected token `am'
On Fri, 2017-08-04 at 10:55 +0200, Yves-Alexis Perez wrote:
> Not sure if the problem lies in libxfcegui4 or in the toolchain but I'm
> unlikely to find a fix right now.
I take that back. It seems that using autotools-dev addon to update
config.{guess,sub}, fixes the FTBFS. Since they're quite old and it's
recommended by policy 4.0.0 I'm doing that and pushing this to unstable.
Regards,
--
Yves-Alexis
signature.asc
Description: This is a digitally signed message part
Bug#836862: [Pkg-swan-devel] Bug#836862: libreswan: /etc/ipsec.conf is already shipped by strongswan-starter
On Fri, 2017-02-03 at 12:34 -0500, Daniel Kahn Gillmor wrote: > > I'm suprised to see that strongswan-charon is the package providing > ike-server, if stronswan-starter is the package that contains the system > integration. src:strongswan actually provides multiple IKE daemon (charon) in different binary packages: - strongswan-charon (the historical one, with configuration from /etc/ipsec.conf) - strongswan-nm (integrated with network-manager) - charon-cmd (standalone/commandline one) - charon-systemd (configured through systemd) All of them have a daemon binding to port 500/4500 and configure IPsec SA in the kernel, so all of them could Provide: ike-server in my opinion. ipsec-starter is only the tools used to start/stop strongswan-charon. Regards. -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#835949: linux-grsec: non-standard gcc/g++ used for build (gcc-5)
On Tue, 2017-02-14 at 15:32 +0900, Hideki Yamane wrote: > > On Mon, 29 Aug 2016 16:15:34 +0200 Yves-Alexis Perez > > wrote: > > I follow src:linux package on this, so I'll do the switch when they do it > > (and > > will close this bug at that point). > > It seems that src:linux was fixed > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835957 Yes I know. I'm waiting for the src:linux 4.9.9 upload to upload linux-grsec. -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#843727: desktop-base: experimental version does not install
control: tag -1 moreinfo On Wed, 2016-11-09 at 09:06 +0100, Eric Valette wrote: > > I have installed this version on two computers and in both cases it fails to > install. It runs the postinstall command correctly (as far as I tested by > executing scripts manually) but still fails. I have no clue why. > > I removed the set -e in post* no chnage... Can you give use the stdout/stderr from the install run, and some details on your install? Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#843727: desktop-base: experimental version does not install
On Wed, 2016-11-09 at 15:52 +0100, Eric Valette wrote: > On 11/09/2016 03:39 PM, Yves-Alexis Perez wrote: > > control: tag -1 moreinfo > > > > On Wed, 2016-11-09 at 09:06 +0100, Eric Valette wrote: > > > > > > I have installed this version on two computers and in both cases it > > > fails to > > > install. It runs the postinstall command correctly (as far as I tested > > > by > > > executing scripts manually) but still fails. I have no clue why. > > > > > > I removed the set -e in post* no chnage... > > > > Can you give use the stdout/stderr from the install run, and some details > > on > > your install? > > > Nothing specific, I see it updating grub for the possible new images, > have no further out put than this and just the error. Just not checked > what postrm does. > > NB: with same install on the two computers the sid version works, > downgrading works. In postrm there is a diffrernce: > > if dpkg-maintscript-helper supports rm_conffile 2>/dev/null; then > <== not present in your version > dpkg-maintscript-helper rm_conffile /etc/kde3/kdeglobals 6.0.1 -- "$@" > fi Can you add set -x to the postinst file? What is you dpkg version? Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#843727: desktop-base: experimental version does not install
On Wed, 2016-11-09 at 16:45 +0100, Eric Valette wrote: > On 11/09/2016 04:16 PM, Yves-Alexis Perez wrote: > > On Wed, 2016-11-09 at 15:52 +0100, Eric Valette wrote: > > Can you add set -x to the postinst file? > > I did a "sh -x ...dektop-base.postinst configure" and saw no error Can you retry with what I asked? Add set -x to the postinst file then re-run the install process (dpkg --configure -a for example). > > > What is you dpkg version? > > 1.18.13 THanks -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#879521: irssi: multiple vulnerabilities fixed in irssi 1.0.5
Source: irssi Severity: grave Tags: security Justification: user security hole Hi, irssi 1.0.5 has been released, fixing multiple vulnerabilities (a) When installing themes with unterminated colour formatting sequences, Irssi may access data beyond the end of the string. (CWE-126) Found by Hanno Böck. CVE-2017-15228 was assigned to this issue. (b) While waiting for the channel synchronisation, Irssi may incorrectly fail to remove destroyed channels from the query list, resulting in use after free conditions when updating the state later on. Found by Joseph Bisch. (CWE-416 caused by CWE-672) CVE-2017-15227 was assigned to this issue. (c) Certain incorrectly formatted DCC CTCP messages could cause NULL pointer dereference. Found by Joseph Bisch. This is a separate, but similar issue to CVE-2017-9468. (CWE-690) CVE-2017-15721 was assigned to this issue. (d) Overlong nicks or targets may result in a NULL pointer dereference while splitting the message. Found by Joseph Bisch. (CWE-690) CVE-2017-15723 was assigned to this issue. (e) In certain cases Irssi may fail to verify that a Safe channel ID is long enough, causing reads beyond the end of the string. Found by Joseph Bisch. (CWE-126) CVE-2017-15722 was assigned to this issue. Can you prepare updates for sid, stretch and jessie (please coordinate with security team at t...@security.debian.org for the latter two)? Please add CVE numbers to the changelog so we can track them easily. Regards, -- Yves-Alexis Debian security team -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (450, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#879521: irssi: multiple vulnerabilities fixed in irssi 1.0.5
On Sun, 2017-10-22 at 17:22 +0200, Yves-Alexis Perez wrote: > Can you prepare updates for sid, stretch and jessie (please coordinate with > security team at t...@security.debian.org for the latter two)? Please add > CVE numbers to the changelog so we can track them easily. By the way, fixes against master are here: https://github.com/irssi/irssi/commit/43e44d553d44e313003cee87e6ea5e24d68b84a1 Regards, -- Yves-Alexis Perez - Debian Security signature.asc Description: This is a digitally signed message part
Bug#867166: Future of linux-grec in Debian
On Fri, 2017-10-27 at 05:58 -0400, Jordan Glover wrote: > linux-grsec-base[1] is missing from stable-backports and I don't see it > being prepared for upload there[2]. Other than that this bug can be closed. > Thanks for your work. > > [1] https://tracker.debian.org/pkg/linux-grsec-base > [2] https://anonscm.debian.org/git/collab-maint/linux-grsec-base.git I was waiting for the image itself to be accepted, I'll prepare the linux- grsec-base backport next. Regards, -- Yves-Alexis
Bug#926801: src:wpa: multiples vulnerabilities in SAE and EAP-pwd code in wpa
Package: src:wpa Severity: grave Tags: security Justification: user security hole Hi, multiple vulnerabilities were discovered in wpa: CVE-2019-9494 [cache attack against SAE] CVE-2019-9495 [cache attack against EAP-pwd] CVE-2019-9496 [SAE confirm missing state validation in hostapd/AP] CVE-2019-9497 [EAP-pwd server not checking for reflection attack] CVE-2019-9498 [EAP-pwd server missing commit validation for scalar/element] CVE-2019-9499 [EAP-pwd peer missing commit validation for scalar/element] When you fix them, please include references to those CVE in the changelog. Regards, -- Yves-Alexis -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (450, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#929834: Buster/XFCE unlock screen is blank
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 2019-05-31 at 18:32 -0700, Russ Allbery wrote: > This appears to be a bug in light-locker specifically, which is the > default screen lock program with XFCE with lightdm. See, for instance: > > https://github.com/the-cavalry/light-locker/issues/114 Actually it seems to me that the bug is a bad interaction with light- locker/lightdm locking system (which relies on vt switch) and the Intel driver. It only seems to happens on this driver, and I think it's also been reproduced just by doing vt-switches (but can't remember where it was reported). > > Switching to another greeter from the default gtk-greeter appears to help > according to that bug, which may mean that the bug is actually in > lightdm-gtk-greeter. There doesn't appear to be a Debian bug for this; it > might be a good idea to open one against light-locker (or, if you confirm > switching to slick-greeter per that bug, lightdm-gtk-greeter). There are at least a gazillion bugs against light-locker and lightdm, or xfce. I tried to at least merge some of them (like #846278) but clearly failed to identify all of them. And people are still reporting new ones (or posting to -devel) so clearly they are hard to spot. Maybe locking through vt-switch is a bad idea, I noted Andreas raised the severity, but I hope someone has an idea how to fix that because I don't. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlz1eyAACgkQ3rYcyPpX RFvkhQf8Dqj0s6569PTiyxfczeA2PV83LWFdBOaCU3FDHv3I3Gdk2E+CR8UpunwI n+YsAEIU/bixAGVhH8yiPKSJiZg4Zjv7pCLVKNHSeg9vigAIWzjag+dArFQciZkP 4JdqtmJRxPwKyK4v7Fp2u3/DK8kjHvUKr0AafkhVGxo0qSuvTUxqBhiy5CeBX4NP 2lnZ5JE+zUsuweEFomy/FAXMMC8E34eWCWtQ/w4iJlwlUghPLR0YbRANN1sbqz73 MHT/fCF+xCKoSRDQT+UZWNGs9hCEDOpoAydXIuwiMzXxsKG83SFGuCFku4ZGZ0vK d4nzUUNx7UhpwcGWSKAXOq1TbtfnJA== =lmZk -END PGP SIGNATURE-
Bug#929834: Buster/XFCE unlock screen is blank
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 2019-06-03 at 21:55 +0200, Yves-Alexis Perez wrote: > I noted Andreas raised the severity, but I hope someone has an idea how to fix > that because I don't. Also, since it was posted on -devel, I guess there's a bit of exposure: if some people care about Xfce, by all mean please join the team and give a help, because right now it's basically on my shoulders, with bits of help here and there from other (mostly on the packaging side, not really on bug triaging). It's been like that since years, and it's not really working fine, especially when I'm not around. And at that point I'm not comfortable anymore with that because it more likely that I might be “not around” now than before. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlz1e+oACgkQ3rYcyPpX RFtp6gf/SeqjvtvV/3TZg5DX327r4oJcLku0EggZJWfiyFYM73Erq81YZMNbOTsL /9xcg6wri9gHZO4+tkzjhdrv0Meuh9+cXHDeBgdg0I9b6HKl1T4Xo6CE7fFvrexn KgQGqy5Tc1yttQVrPFTI9s+WEhxrByEB70rYHuOQW0TvgKIYaAdpfG1gRV14gw23 vvgeBwNpYSlfiD1Od/lVjkYuyPRcmwi2FNC6sbhSIui3Ll2UppOeFoqA4Y962vnM XP1cMux8BOEwfHZnjL9bzV7x+tWGFz7l2mbV/Xyew5hHBIstYkFk6VDIJHLxeMd1 nMXCY+neAYb7gzfXQlCNVAg+w63a/w== =E2SN -END PGP SIGNATURE-
Bug#929834: Buster/XFCE unlock screen is blank
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 2019-06-03 at 12:59 -0700, Russ Allbery wrote: > Ah, good call. I was also seeing other problems with the Intel driver in > combination with light-locker where the monitor resolution would be set to > some incorrect value after restore from lock. This would come with kernel > errors like: > > [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* uncleared fifo > underrun on pipe B > [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO > underrun > > and then lots and lots of: > > [drm:intel_dp_start_link_train [i915]] *ERROR* Timed out waiting for DP idle > patterns My gut feeling is that light-locker just uses codepaths not really used otherwise, like vt-switch at the same time as suspend/resume or screen off/on. Unfortunately debugging i915 is completely out of my league (and I already tried multiple time on other issues). Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlz1fv0ACgkQ3rYcyPpX RFuTTQf+ITXxUm6DnBRNuGwsKbKCFoeXUAiP+v5GdIJDDifEWG91inoF1tf6GswS l1RRJHYczv9WtjL+6e1522vzAp0h6jw5WuAcQfXcAZZR4n/GU25VVa6gsIqbGIv9 XvsoN+Y/MGdJueg0xYfBTuiInoySchJ4cv2oh56MkcndjgDiPtiH8bAXCcxwBflj OXkCEUj8LLoOACdTYBWA02vA66daEMRk7Y6gkO+BwbvS/ZeVL1T2xQV0W47obtF5 AaBhx/AwM59Bzk5RUD8EBi5cOWuXB7KIYcuXLzaFjNzk6yXXTAx26740dR8q3CoD JHld4HjQRllFUxsDiZvz5+1q5+nShw== =ho8d -END PGP SIGNATURE-
Bug#991788: Disabling Upower support in xfce4-settings
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Control: severity -1 normal On Tue, 2021-08-17 at 22:05 +0200, truetec...@tutanota.com wrote: > Hello, > > When compiled with --enable-upower-glib, xfce4-power-manager doesn't seem to > re-enable laptop displays after suspending the system. And, for that reason, > this is disabled by default upstream... but it was explicitly re-enabled in > Debian for some reason. I reported this issue as a critical bug under > #991788 in xfce4-settings and was told that xfce4 maintainers in Debian > would have to decide whether or not to change this. However, it has been a > while and I want to bring attention to it further, especially as an update > without attention to this feature has already been pushed to unstable. > > Upstream bug report: > https://gitlab.xfce.org/xfce/xfce4-settings/-/issues/222 > Debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991788 > Hi Elliot, thanks for the message, but it's usually best to directly send messages to the bug report, that way it's archived on the bug tracker (sorry we didn't reply earlier on it). That's definitely not a “critical” bug though (thus adjusting the severity). And unfortunately the “upstream” fix isn't really good because that actually means just not listening to the lid events, and that's a behavior which I think we do want. As far as I can tell it does work fine on other configurations, but maybe there's an issue with the proprietary NVidia driver (if you can try with nouveau or something like that, it'd be an interesting data point). Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmElQ6kACgkQ3rYcyPpX RFsP2Qf/aaipVYYhL8CdBZ3oL6xF72n3JNhCPOIvCggH+5BAKHG/xdgROsalKJLd l0mI8kHqqotc7SBWd6Rlndz26SvxTMgcIZ5rxrevkq05e8zzhystfCtqK8kIGs1+ LzHA+yS1kPrGqx170I4Dkw/EtdLovXOvJFQwGcGZDvqFq1IEAtvwg3m7OaN06xWj WTYnVPF2ByzC6g3t5VAUglKG8AwKS65fmAJzauv/iCF28QApYcUchQhDu4mLy/Rm TmdWjT/n0Fv2IZiB6HMbGzB8o0p86niUb4+RgKZ58RV1a89exRG6i7vuVt/BAPpF BohukQsr4iVsA5+GyWF0gnY3IZR9Pg== =1nfL -END PGP SIGNATURE-
Bug#996028: InnoDB: corrupted TRX_NO after upgrading to 10.3.31
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 control: subscribe -1 On Sun, 10 Oct 2021 16:13:29 +0200 Ondrej Zary wrote: > Package: mariadb-server > Version: 1:10.3.31-0+deb10u1 > Severity: grave > Justification: causes non-serious data loss > > Dear Maintainer, > upgrading mariadb-server from 1:10.3.29-0+deb10u1 to 1:10.3.31-0+deb10u1 failed > because mariadb failed to start. /var/log/mysql/error.log: > > 2021-10-10 15:12:49 0 [ERROR] InnoDB: corrupted TRX_NO 10002001c6986c3 > 2021-10-10 15:12:49 0 [ERROR] InnoDB: Plugin initialization aborted with error Data structure corruption > 2021-10-10 15:12:50 0 [ERROR] Plugin 'InnoDB' init function returned error. > 2021-10-10 15:12:50 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. > 2021-10-10 15:12:50 0 [ERROR] Unknown/unsupported storage engine: InnoDB > 2021-10-10 15:12:50 0 [ERROR] Aborting > > Fortunately, it works after downgrading back to 10.3.29. > Data does not seem to be corrupted. > For what's it's worth I'm experiencing the same issue on my installation. I took me some time to find that bug (and I started to dig how to repair innodb stuff. Good to know downgrading should help, thanks. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmFjNSIACgkQ3rYcyPpX RFsxlQgAo0eUU9T8XaIsYIw/jx4dmbRf9DO8/IxPvFuMw0zkn7JO2LxL61IRIcAa SDljx7UjnJpTpJ6Nc6XXQ8sU3EIb4qUen1dRME383jcUEAN0Yh3F2cvBmNkjV7bN rDdRf74leH76uYo9sPIgWnZwy2U2I9HVKhlD3uo2MF53ksem1yVJh3Jvll5w0ZsM SsMCO2wTjq3RFbc38bqKASSh/+UvXAxxY/6R6bxc+YIWqsim9z8XQ9TKZXdnjPS+ aOcJblZarGOjdC2AwbeT9GVaBoaCx9V9RlQDn3WoMvVhHvjfI32j+tEG1uWnicC/ q1tnUp/9oBnvt8eYDbRY3ny3oC6ylA== =oOyd -END PGP SIGNATURE-
Bug#996028: #996028 InnoDB: corrupted TRX_NO after upgrading to 10.3.31
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 2021-10-11 at 11:27 +0200, Jan Korbel wrote: > Maybe this: https://bugs.freebsd.org/bugzilla//show_bug.cgi?id=257728 If I read the bug correctly, it points to https://jira.mariadb.org/projects/MDEV/issues/MDEV-26537 and the commit https://github.com/MariaDB/server/commit/d09426f9e60fd93296464ec9eb5f9d85566437d3 I'm not sure I can rebuild the mariadb package myselve but I can surely test a package if someone builds it. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmFlde4ACgkQ3rYcyPpX RFut1wf+JIBYQysCmw7jbZ3dgTCWaNw7E+A/15mJJX+h5ThVkVQtd3/iZ9brTO8t s7X6EzPrZpVHnUqfiwvyLuP/yyiEUocuuRQUGwOgOYRxX6w7D8aYrDMzHQYgezwg myleMw7ncB0lpi3uAn7RMmWSwShbKRVb+ikqELc/TZ+SiPb8fBtVIxwfZO3UCHXg wirCXdk2Yo28hbcvs7hQTt5bbOiKGiJ6Lv5tYnDigOep7aViofuay8SC/nR08oAU bRCoENRzDnNrYdVqYIloJYNBkYVCpJPKZaATPe55jsnNhMXkCCAS53DUOHWLg8gd LbZFH8Dtw7ntRq1UFrPJdxSyPPzKcg== =6ogP -END PGP SIGNATURE-
Bug#996028: [debian-mysql] Bug#996028: InnoDB: corrupted TRX_NO after upgrading to 10.3.31
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, 2021-10-12 at 21:58 +0200, Ondrej Zary wrote: > > One thing you could also try is to start the server with 10.3.29 and > > ensure that you have a clean shutdown (SET GLOBAL > > innodb_fast_shutdown=0; SHUTDOWN) and only after that start with the > > new 10.3.31 binary. > > With fast shutdown disabled, mysqld (10.3.29) seems to be stuck in an infinite > loop. 100% CPU usage, no I/O for an hour until I killed it. > Even dropping all the databases did not help - killed it after it has been > running for 5 minutes. I tried that as well and for now the shutdown process seems a bit stuck: 2021-10-13 8:50:01 0 [Note] /usr/sbin/mysqld (initiated by: unknown): Normal shutdown 2021-10-13 8:50:01 0 [Note] Event Scheduler: Purging the queue. 0 events 2021-10-13 8:50:01 0 [Note] InnoDB: FTS optimize thread exiting. 2021-10-13 8:50:01 4 [Note] InnoDB: to purge 5 transactions 2021-10-13 8:50:01 0 [Note] InnoDB: Starting shutdown... 2021-10-13 8:50:01 0 [Note] InnoDB: Dumping buffer pool(s) to /var/lib/mysql/ib_buffer_pool 2021-10-13 8:50:01 0 [Note] InnoDB: Buffer pool(s) dump completed at 211013 8:50:01 2021-10-13 8:51:02 0 [Note] InnoDB: Waiting for master thread to exit 2021-10-13 8:51:03 0 [Note] InnoDB: Waiting for change buffer merge to complete number of bytes of change buffer just merged: 1251 2021-10-13 8:52:02 0 [Note] InnoDB: Waiting for master thread to exit [...] 2021-10-13 9:02:05 0 [Note] InnoDB: Waiting for master thread to exit 2021-10-13 9:02:14 0 [Note] InnoDB: Waiting for change buffer merge to complete number of bytes of change buffer just merged: 746 2021-10-13 9:03:05 0 [Note] InnoDB: Waiting for master thread to exit 2021-10-13 9:03:15 0 [Note] InnoDB: Waiting for change buffer merge to complete number of bytes of change buffer just merged: 1040 I don't think anything still uses MySQL/MariaDB (I've stopped apache2 just in case). I'll let it run a bit but I'm not really confident with that shutdown process. I've tried to rebuild mariadb-10.3 with the patch upstream committed, but it doesn't apply to 10.3.31 directly so I stalled a bit. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmFmhToACgkQ3rYcyPpX RFuQFwf/Y7hPWdNmI//ZVnT3k2H1Jn47kOKttff4cg+RDc4LzbQX/NoQkrDaOwJJ Yef7ne3a4FhTnkL4+L1yq8/53L22zaVvAxrXEmSgcqSvVPap0v4x6S5MXXvPhSsN 961LWuTQwdY3qSiXTRqUtKh3fgQBxBdqoWK9zT2AE0zGh04/XhaoauZ1MmH4s+T/ uX5IGtu4a8DhPQ2bno/mu421bsIndn8rkTBzaXPEh9QAd0wexMJyul6kLe4rJ2ym zvRvYeIO4Bx8YzGV1+CuN2rtAEOGrplf3qRmBFkb1Jo7nNX8SdjaK4NqgZHAaDx9 WdEsaa6cGtoKLvNbadUJaoQ+r922cA== =4Lb3 -END PGP SIGNATURE-
Bug#996028: [debian-mysql] Bug#996028: #996028 InnoDB: corrupted TRX_NO after upgrading to 10.3.31
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, 2021-10-13 at 19:06 -0700, Otto Kekäläinen wrote: > I added this patch to the packaging in > https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/2a8f83531a2ff22a31c61b8bef28dabf77b25b78 > and once the CI completes (if it runs without errors) you will be able > to download the packages from the build artifacts published at > https://salsa.debian.org/mariadb-team/mariadb-10.5/-/pipelines/302326 > in step "build". Thanks! Unfortunately I'm rather looking for 10.3 packages since I'm still on Buster at the moment… Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmFn0iMACgkQ3rYcyPpX RFvy+Af/eNK42v0kyygB4+LDf+ayBQ/sYNnFMRUiG3xDHil+Pi7r8tszrEgn1vl4 1jz7vHfMxDu/kzrOtetR9sVdJebocIigO8Wn6/NLWqq+Ut7bTQK1fOOYeXcowLeb Bc1lG6thlGVxKa+qTXSSivM/nGbl6JvunCg2HN0tauzy8nMnlNisUcssauvpvdun /nSPnsKUyLHwyU20FtruGowSxv2rVtAVTiA8cRF8aymm2kYe9NrmOSyJ+E6mrJQy onRmpQQqQNaGVr3bt7oakf2lNqjsb5j+cURblTNBhITriPv0vDIBeMXJHb3EokUk ZdTR3eeEV+qQxzyvHZ2TUadLpVGSHA== =69F+ -END PGP SIGNATURE-
Bug#996028: [debian-mysql] Bug#996028: #996028 InnoDB: corrupted TRX_NO after upgrading to 10.3.31
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, 2021-10-14 at 00:03 -0700, Otto Kekäläinen wrote: > Right. Here is for Buster: > > https://salsa.debian.org/mariadb-team/mariadb-10.3/-/commit/8ccf2240960cbb609cedfeb269df22d43ccbba21 > https://salsa.debian.org/mariadb-team/mariadb-10.3/-/pipelines/302376 Unfortunately, with: ii libmariadb3:amd64 1:10.3.31-0+deb10u1+salsaci amd64 MariaDB database client library ii mariadb-client 1:10.3.31-0+deb10u1+salsaci all MariaDB database client (metapackage depending on the latest version) ii mariadb-client-10.31:10.3.31-0+deb10u1+salsaci amd64 MariaDB database client binaries ii mariadb-client-core-10.3 1:10.3.31-0+deb10u1+salsaci amd64 MariaDB database core client binaries ii mariadb-common 1:10.3.31-0+deb10u1+salsaci all MariaDB common metapackage ii mariadb-server 1:10.3.31-0+deb10u1+salsaci all MariaDB database server (metapackage depending on the latest version) ii mariadb-server-10.31:10.3.31-0+deb10u1+salsaci amd64 MariaDB database server binaries ii mariadb-server-core-10.3 1:10.3.31-0+deb10u1+salsaci amd64 MariaDB database core server files I still get: 2021-10-14 9:38:48 0 [Note] InnoDB: Using Linux native AIO 2021-10-14 9:38:48 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 2021-10-14 9:38:48 0 [Note] InnoDB: Uses event mutexes 2021-10-14 9:38:48 0 [Note] InnoDB: Compressed tables use zlib 1.2.11 2021-10-14 9:38:48 0 [Note] InnoDB: Number of pools: 1 2021-10-14 9:38:48 0 [Note] InnoDB: Using SSE2 crc32 instructions 2021-10-14 9:38:48 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M 2021-10-14 9:38:48 0 [Note] InnoDB: Completed initialization of buffer pool 2021-10-14 9:38:48 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority(). 2021-10-14 9:38:48 0 [ERROR] InnoDB: corrupted TRX_NO 10002001a6990af 2021-10-14 9:38:48 0 [Note] InnoDB: Retry with innodb_force_recovery=5 2021-10-14 9:38:48 0 [ERROR] InnoDB: Plugin initialization aborted with error Data structure corruption 2021-10-14 9:38:49 0 [Note] InnoDB: Starting shutdown... 2021-10-14 9:38:49 0 [ERROR] Plugin 'InnoDB' init function returned error. 2021-10-14 9:38:49 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. 2021-10-14 9:38:49 0 [Note] Plugin 'FEEDBACK' is disabled. 2021-10-14 9:38:49 0 [ERROR] Unknown/unsupported storage engine: InnoDB 2021-10-14 9:38:49 0 [ERROR] Aborting So maybe I do have a corrupted database or something but I'm unsure what to do next (I don't think I have an older backups of the database). Also it still works just fine with 10.3.25. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmFn33MACgkQ3rYcyPpX RFvQ/AgA0ijpQynfY/h6UsBhBKIpfDKUFB+Ti1xJY01RHU0ZxqjvxjYKeCH8CD8U +JEhFwTurzxS64tGGyS7jyT+9JUi4tcodtOWEk9I/hKKP4nC31IT7Ov9BQfDeJ7E wL82cA5/c92r3IZYs8AfKG8KWjVCrSCMMzjkVaPIuKvf9UYY9WlioPW7X55MihkE lIOXGk3jWp6LtT6QG8OOmoM5w/QmUKaOR5soPaFaQm/Km5KibvtY8nPEhhaIYe6x sSdJDqIo7uOt3DEXUujT8uRf3sd2O15G2DMv0A/6DX7Yb6zO03zQHfuCeZURm2p2 H7j+0p6DQWUOyKHuaMaAvtpM9hcbGQ== =BU6z -END PGP SIGNATURE-
Bug#947319: missing directory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 control: severity -1 important On Tue, 2019-12-24 at 16:16 +0100, Jérôme Bouat wrote: > It seems a directory is missing : > --- > Could not enumerate user data directory /var/lib/lightdm/data: Error opening > directory '/var/lib/lightdm/data': No such file or directory > --- > > I attached the last lines of my /var/log/syslog Hi Jérơme, that directory should be created created by lightdm (see https://sources.debian.org/src/lightdm/1.26.0-4/src/shared-data-manager.c/#L75 ) so there's something fishy on your installation which doesn't happen anywhere else. Could you try to investigate why lightdm can't create it? Can you create it yourself and see what happens? Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl4F4kgACgkQ3rYcyPpX RFsanwf+NSyqUTTqSHSq63w+ogyRzgaR98n3reL2K7xvJGIr8dG2N5GA4siRwxW4 3EgSFW15bJ+t+R5T85J5lSWvXQcUzxMF9TI9xN63o3N0x8tEk1griFcfHCuY4I6E vP5k4v+2bxed8wtLB23f1sA9XrFr/KFy50CVbflbQfNO4zyd2n/toZs/C//gXOSe /mWfJi0c9fWLsALefJvx1QcZxD9+oHcPnXPRKy1dGqUma+6Ju4eVZOgHcmfL+pyH 0Ta7K5TjVlo5KTQNHWwjK3m2XeEkwIQ/mcR0g9OkPebf9fBmD1uNtOX4tfFHalY2 N7a/qwMJrIYncvYRK8NKkLWCxhwN9A== =ER63 -END PGP SIGNATURE-
Bug#875029: [lightdm] Future Qt4 removal from Buster
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, 2019-09-15 at 23:26 +0200, Moritz Mühlenhoff wrote: > > Attached is a patch which drops Qt4 support. It's only used by src:razorqt, > > which is already RC-buggy anyway and which will be removed soon along with > > Qt4. > > razorqt also got removed in the mean time, so there's no reverse dependencies > left. Yes, thanks, I'll try to take a look at it rather sooner than later in the release cycle. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl1/J7sACgkQ3rYcyPpX RFvIhgf9FVrthH1uSRMkMOAdFtNCum0kYVJNwFSJdLUwcntJMI6diUlz24cgcDX/ OXgpqPDw07SzJnsbdvKyRJQ8FmH58fjsPUh3o3IwU2TDEef2nkHkJHSpbdzom88r l4REsBXcxa3D3FfxNUQGwA2HLdRGolD3cQ5T55eWMYbGWiH7BkM8VQ3z3XEoYo6y tGUlKvl5SY95zF6J5URE200xIyGuQX8vB2gROFzJ7c931JCsjx94SYsE4dHHByJi B8cDbAzzSbIdfpF9VY7DFMU4HZzXnjLbYTwtGNkKGGYlaBbkFUG9RIBI48U4FmE4 qL68FXQ8pGsutVVPdU7g2FIR8JsLiw== =vFV3 -END PGP SIGNATURE-
Bug#875029: Ping!
Please don’t, I already told Moritz I’ll handle it when I have time. — Yves-Alexis > On 17 Sep 2019, at 16:46, Lisandro Damián Nicanor Pérez Meyer > wrote: > > Hi Yves-Alexis! > > lightdm is now one of the three packages holding qt4 in testing. Would > it be possible for you to apply the patch Moritz sent? If you can't > I'll be happy to NMU it. > > Cheers, Lisandro. > > -- > Lisandro Damián Nicanor Pérez Meyer > http://perezmeyer.com.ar/ > http://perezmeyer.blogspot.com/
Bug#875029: Ping!
Yes I mind. I’m sorry my schedule doesn’t align with yours, but I honestly don’t see the urgency here. I’m not asking you to wait for months, I’m just trying to find some time to properly review and integrate Moritz patch. And the way you push is a bit annoying right now. I’m sure it’s not intended, but could you please slow down a bit? — Yves-Alexis > On 17 Sep 2019, at 18:05, Lisandro Damián Nicanor Pérez Meyer > wrote: > > Hi! > >> On Tue, 17 Sep 2019 at 12:49, Yves-Alexis Perez wrote: >> >> Please don’t, I already told Moritz I’ll handle it when I have time. > > That's just great! Do you mind if, once we get out of testing the two > other blockers, we ask the RT to remove lightdm from testing? It will > still re enter testing as soons as you do your next upload+normal > time. > > Thanks!!
Bug#875029: Ping!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, 2019-09-17 at 13:29 -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > I'm terribly sorry if we are being pushy here, it is indeed with no > bad faith and we definitely don't want to annoy anyone. And yes, we > are targeting at removing qt4 from testing as soon as possible. Don't > worry, we will leave this package until it's the only blocker left. > > Again, sorry if it annoyed you, no bad faith here :-) There's no big deal, but I already replied to Moritz and on this bug *yesterday* that I'll take a look at it. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl2BJPEACgkQ3rYcyPpX RFsgnggAlK2hzacRyd//Zpfv8cnEfjax3tt2PFCXa3AnzOEzRmWrvCphhW5uc5GQ gayj0XGAxDOY2Ve/Cr11Ius9K75KTTe44gb7tNt1M4IsFwxHiJ2wOlnhA46J16wK xSAkuvnpyZcobPnecV00cjsIieZBBnHDvVdvOM6a8wJRQ31pTw+G1G4pc6zPlgat cmAia+egrletB1lpYUKfIZRlI4pGvPk55HU6gHMijAzbjSxk6o55Ww0ROe1vsYVp 513LAo1IaQbW7MgmmrCAYYwGji9Xrx9LPEBG0L+B4p/hkN1zy/WpbwdtrbP9DkOy ZDu12/pzUIzSOqSHLLvSRN6Z3vGyYQ== =546A -END PGP SIGNATURE-
Bug#832422: albatross-gtk-theme: broken with GTK3.20
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, 2019-09-29 at 07:10 -0400, Jeremy Bicha wrote: > Control: severity -1 serious > > I propose that we remove albatross-gtk-theme from Unstable & Bullseye. > A GTK theme that doesn't work with GTK3 isn't very helpful any more. > > https://github.com/shimmerproject/Albatross > That'd be ok with me. I don't really have time or interest for this as a maintainer, unfortunately. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl2QmowACgkQ3rYcyPpX RFso3Qf6AmuxPvSVSuJzeM0iILrKNq4w4QrSloGkWZkk8QKkJdamfaH0v+ZylokZ KpGnQXVUJTNHyPmxNuPU7AVo1t42xo3cUk/UbzYvjpQIMVV8QHaU7+umi4wNRONN IRuvAWSku8IojA69TrmsRqwHtsyd13p51jJtfZizeiCUHfSkcD3YRd9aGkapR5bD /3e356phzFYU0zsGmbkNKQrSiKAyMnPuZwq7X2flxHW6nxYdSnUfIXeakrwj+DcV Bl/ND5+pVcttWdX6tUzO7Xgy/4t1BlCHIyV9DZezFc3HjtY8ykSFSAsuv3oMfvO2 pcPv/S+OFyrrncKTOxsdWrUXs+TBKA== =hCB/ -END PGP SIGNATURE-
Bug#885813: bumping severity of xfce4-notes-plugin's use of libunique to Serious
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, 2019-10-06 at 07:08 -0400, Jeremy Bicha wrote: > Control: severity -1 serious > > The Debian GNOME team would like to remove libunique from Debian. > Therefore, I'm bumping the severity of this bug to serious. > > Please see the master bug https://bugs.debian.org/895520 for > documentation on moving away from libunique. It looks like it requires > finishing the port to gtk3. > > Because xfce4-notes-plugin is a "key package", it won't be > automatically removed from Testing. But note that this package is one > of the last 2 or 3 keeping libunique in Debian. > Hi, thanks for the update. It seems that the GTK3 port isn't really complete. And it seems notes isn't really maintained upstream anymore. I'm adding Mike to the CC but we might end up completely dropping xfce4-notes-plugin from Debian in the end. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl2d/fgACgkQ3rYcyPpX RFs55Qf+JxcS3s1GjkDy4+TzN6+ZuB9RJ4Kx98wXE4fnYYAzDE+sMo+O8RUcbcf9 uEn14PFzQiOXqMcGL6NOXwjE+Hg71MEuwmHbnI2/JWb/QTBv1Bu0yFo3Em6dOFBn nUtBa3a7UrxBU7fjh2RDyU5/S4EmZaZIRXZs1sPQRN79Fu3h/oM1WRabvAD6Zn2G A1dR9DaaUpKsaKZpiIUsYQ3m3V2R6sAuT2evuVTbe/RvXFIGC+9CCgeMwkXHDqMn PlbtOMirYoGd1o90pgSn6WScDNfHNSVUI7E/Q75vSwlqKdARDNT3m523tW9miIAO 598tOZfMnG8MgQUejyikOzoe0gvK+g== =mAmx -END PGP SIGNATURE-
Bug#838994: unresolved gtk2-engines-murrine situation (was: numix-gtk-theme: Undocumented and very likely also broken Breaks against murrine-themes since 2.6.7-2)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, 2019-11-12 at 12:09 +0100, Mike Gabriel wrote: > > As I haven't had any reply nor statement nor veto nor anything from any > of you on the above, here is what is going to happen, if noone interacts... Hi Mike, I'm unfortunately quite busy these days with a lot of stuff, and clearly the various murrine themes are low priority for me. So I'll let you go ahead with your plans, don't count on me for anything on this… Thanks for the work anyway. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl3MIMoACgkQ3rYcyPpX RFvnjgf+OfjpnOdQXqv1QG0PCGz1ksaDqNG8g6elU1VlkFxP83ueo8xTkSoOSOtj r3YoRbvLI1WSu62Dhl+szTtmKHwQG9jF4/Yy4WVAYiK9tzQNMt0bxJ40RFFebuNI r9wOnLWUEISlaROtxRU86LMhgCzNTCUyjTmy+XKP7tZsZ9TOwy7ZymxsUpb6xlii Nb4T0oRuBsQmcXizONDCe3yWjuy1JRwr9xZ60d+FGVW6sgqVLrkk0aoGZ1lBikKH ddXNblZ46vtH3Y2f70eDRsxmJHNDE1yCcTtotFVNApPytVw8Tgsr8GvyRqliSFMh xxSFGjAhXVxz24ReIEnOQ5Kpw5tD3A== =E08z -END PGP SIGNATURE-
Bug#838994: Bug#891493: unresolved gtk2-engines-murrine situation (was: numix-gtk-theme: Undocumented and very likely also broken Breaks against murrine-themes since 2.6.7-2)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, 2019-11-13 at 20:58 +, Mike Gabriel wrote: > One last question: For the themes you maintain, is it ok if I provide > the "Provides: any-murrine-theme" patches (as MRs or pushed commits) > and possibly even NMU them for those murrine-like themes that need them? > > Like in numix-gtk-theme [1]. > > Alternative option is me filing wishlist bugs against all related packages. Go ahead with NMU, and yes I guess you can directly commit/push to the repository. At that point I think I should just remove myself from maintainers/uploaders of the theme packages, I'm unlikely to have time for them in the near future. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl3M/F0ACgkQ3rYcyPpX RFvtLggAtPb/BMDo5FtGG1Z51pEqRbrfijD0ad16ymSR5PUoxReL5aVL5Ygt3zFX b1Pgn3fH9FFAsE6guzo59WfK51+erWSGI52t3AEWOCdenAU4GKfBUSs6HyU9WmAk Bii5Hre2Cu/hsyOWcm28pXhtvK3SwLqA7GKxK2r1xIOV1rhIFcziLFF7KohcO66i /EV/xkK+pVv1JYY/hMx+wvGIaKVIhurHyusj0AaUx5b5QgQ6aWYcWw7PsBRcv+Fr FHjyxLLM6WePaFBjdBCoKy3bXpVJG54r8Shtj3L4d+zK42r8GcUf2qt8pGH9dYk0 6KbO+P+VHKoALQLyNRlxdvglnmsZBg== =ZlSB -END PGP SIGNATURE-
Bug#838994: Bug#891493: Bug#838994: Bug#891493: unresolved gtk2-engines-murrine situation (was: numix-gtk-theme: Undocumented and very likely also broken Breaks against murrine-themes since 2.6.7-2)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, 2019-11-17 at 11:00 +, Mike Gabriel wrote: > If you plan to drop maintenance sooner or later anyway, then please > state that asap (packages are in deferred-15 from today again), so > that I can change the uploads and make these bugs go away without > introducing a virtual package. Let's be realistic, I won't have time / priority for those themes, so I'm ok with dropping maintenance even right now. So go ahead with your preferred plan. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl3RouwACgkQ3rYcyPpX RFvuoggAzbl9QuKIg6U3z3qUK1cEn9486QAsCFFqyEkCpU2SdbvN0jQKsU+zlk/P YeBh80ungay/7cRp3mHX9/HDlJ550PhoiqE3Laj++OOYGC0yzUT+s7ARhwmztpOY nk3Y3BJ7xZ7zgOgR1JdMO81FbDEx7Qa49epCLjZ+Nmjci4Bwk5CuEIbIn5ujOpqR zmeyaUSYursxSV0GMNBz5bCMBOjdGbqLUNA/IzlaPCRusdjlUpwJH6NWwdAQbXJ/ XWC9fQiegEIe+9+4fEOZXWPNu4AUQb4gV5fVAh7RWh5y08Va723RqzB11iBBJ247 r4A6B66fyUWKvWOXGyGULm4pHnDRZA== =vLjy -END PGP SIGNATURE-
Bug#936877: [Pkg-gtkpod-devel] Bug#936902: Bug#936902: libplist: Python2 removal in sid/bullseye
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, 2019-09-22 at 11:04 +0200, Yves-Alexis Perez wrote: > Obviously there might be people using python-plist and python-imobiledevice > directly in python scripts and they'll have to migrate them to python3, > which > is not perfect, but I don't have other ideas for now. > > I'll try to update the whole istuff stack at once in the following > days/weeks. Package with (hopefully) python3 support are currently sitting in NEW, so this is in the hand of the ftpmasters. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl3gF40ACgkQ3rYcyPpX RFuvXAgAuwC/9meDd+Wxq6c+Pfn6BsA0ppqctdODrg2oC2tzrRy6SERmud3QJFZy UmmbsRuUFTfq9NXJzNuTFolWRwdKW95G2V/oKtRCWXA0td7JMkGFe13gJMVMa9D/ RmyLq/nb4lxcwS5tFuJpCufnksyH+2HR38PANWsMhOwqXM1tCHrvL1x2i/IrMVfA 08MyZYuar31Wi9+CI+O9RPFejq2goiSVsXq2+ThV3WdDJ4wSAEIdQmfHCk94RbNf Qyu2xmbX2MWefJRvc8aqcYoUrmiod9qQ0iOW0eB+0ThT+dU9qeam7UcIgwdpsQlu wmsWXdk/bFpws0VwlI1CudYtOFFEqw== =wQFE -END PGP SIGNATURE-
Bug#910631: lightdm: first login hangs waiting for user-generated entropy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 control: severity -1 normal On Tue, 2018-10-09 at 03:04 +0200, Jules Bernable wrote: > Package: lightdm > Version: 1.26.0-3 > Severity: grave > Justification: renders package unusable This is not a correct severity, the system is not unusable. > > Dear Maintainer, > > On my buster/sid system, LightDM hangs indefinitely on first login until > entropy is generated via mouse or keyboard input. > The login process seems to be delayed by the kernel itself, until the > following > lines appear in journalctl: > > kernel: random: crng init done > kernel: random: 7 urandom warning(s) missed due to ratelimiting To be honest, it's unlikely to be a problem in LightDM itself, I'd say it's rather in generating the Xorg cookie. > > > This issue also seems related to bug #897572 Inded I'd say it's the same cause (your system doesn't have enough entropy). I'll try to find the Xorg bug. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlu8R34ACgkQ3rYcyPpX RFsPuwgAsF0BhCU1YP5180cxZC4fajeinrtQN3aExbPVazXk2ENzcJ8CQjKQ8mi2 ePF4ALahVVEKSV6MdlY+mzlwEUJ5VvMKkP/sw0TxRh5Jq290hN7v14WzNtOda74e klcmY8MPUN2dfHsd9UelXpgNrNacKFTaQ1obHfI5uTAZAbBCDzRX2EbaEa5vofc9 lG4IXcON1Mby9mI7cXtys2EMAQFeTodFwIi9WVxZB+8BDyUWgL3NGntU5jrx8Jg6 pNvVMTUw9FSNVbjMZO39cnlS9FEo9DgnG2viXdK3ThCAfsIio5DTJ7D1NEqVPdHE n3rtp3XOEmIkHnGkTsfsd3q6cPtdgA== =6NyN -END PGP SIGNATURE-
Bug#916582: parl-desktop depends on the removed xfce4-linelight-plugin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, 2018-12-16 at 12:06 +0200, Adrian Bunk wrote: > Package: parl-desktop > Version: 1.9.16 > Severity: serious > > The following packages have unmet dependencies: > parl-desktop : Depends: xfce4-linelight-plugin but it is not installable Ouch, sorry for that. I've requested removal of linelight plugin recently because it's unmaintained upstream and didn't see a release in ages (and I'm doing some pre-freeze cleaning). Somehow I managed to miss the dependency from parl-desktop. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlwWuYMACgkQ3rYcyPpX RFuYXQgAsbJ64UkyvLQ+xqg6WAFPTmGF/hgHPskY66Pp3eEEct5o9mrt/lJ0IkTA H8kc8nAm/aNtz13yM7ZNo7yEXBkI+JUiAtrQc1J2RYTJ3ehXR6r4nta7KO/sTe9I 13Bc/ctOYQHkwilfNeTqrcTXmnAEW/J48wyrecQ287MNMugT1Lq6cgRltoMSlIyM KjMs3PQNqUtxkOsUkgSWOVmSGhIVAR6byQlvozb2CWOxHGutK2yAxRTRbAYRR+D6 cqQxhbhdlc2atONDVqs+Nh7CWdirrHgfNiLYMCG1eeJEGWZUknMUVQdQRkLdl3dF +GyNeT/83Nj3+OVx4I3GdCeHPqR/zA== =cTUI -END PGP SIGNATURE-
Bug#912977: iptables: nftables layer breaks ipsec/policy keyword
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Mon, 2018-11-05 at 13:08 +0100, Pierre Chifflier wrote:
> Package: iptables
> Version: 1.8.1-2
> Severity: grave
> Tags: security
> Justification: breaks rules, inserts pass-all rules
> X-Debbugs-Cc: t...@security.debian.org,
> secure-testing-t...@lists.alioth.debian.org
>
> Hi,
>
> The debian package for iptables now transparently converts inserted
> rules to nftables, which is great.
>
> However, some keywords are not supported (like the 'policy' keyword for
> IPsec transforms). The bad part is, these rules are inserted
> *without* the matches, which makes in some cases your firewall useless.
>
> For ex:
> # iptables -F
> # iptables -A OUTPUT -m policy --dir out --pol ipsec --strict --mode tunnel
> -o eth0 -j ACCEPT
> # echo $?
> 0
> # nft list ruleset
>
> chain OUTPUT {
> type filter hook output priority 0; policy accept;
> oifname "eth0" counter packets 90 bytes 26085 accept
> }
> }
>
> As you can see, the inserted rule allows everything, while the expected
> behavior would be 'only if going through an IPsec tunnel'.
> Even worse: inserting the rule did not fail.
>
> Until the 'ipsec' (or 'secpath') keyword works properly (and supports
> all options), an acceptable behavior would be to reject the rule if one
> or more keywords are not supported by nftables.
Hi all,
actually, I think it would make sense to actually bail out early with and
error if any rule or keyword is unsupported by the nftable backend. I've
noticed the behavior because it was announced in NEWS.Debian (and I have apt-
listchanges) and I assume it'll be put in the Buster release notes, but I
think the executable itself (or maybe the kernel part) shouldn't silently
ignore stuff, because indeed it can open holes in the firewall and break
user/admin expectations.
Regards,
- --
Yves-Alexis
-BEGIN PGP SIGNATURE-
iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlvhgm8ACgkQ3rYcyPpX
RFvd8AgA61EMEQiHhYmV+5I8DvUCuOaHQkW23pQQeN5jYMc8qE3QW3BX7NDhvOFc
xeKSeft4zc5uzGV4K3UvaD0g3F1rq1FqaSLpUYWxO27B59y5etvMz8x9k+GZn2gh
3ZHOb2PmnwTl3sj99F5gdzTI6aDU/50ceHPC1C+Z0fBL5aXElAcO9tzvxP1oGMr/
u1t3teLPNPuuuM4s32s8IUaiiUvJ3IBAuv4J/h3qzMixWyki+XNq3slrxHGARLL3
KY78QAfu7MkvJ6B3iiMuDzgfRYyYy/PZJl9B4aqX+rmRE4mFKAftGCvFix+0EGBB
EPzws0ExVehsLkOBCgTAj0OQeuVXNA==
=XxmO
-END PGP SIGNATURE-
Bug#934969: xfce4-power-manager FTBFS: undefined reference to `xfce_titled_dialog_new_with_mixed_buttons'
On Sat, 2019-08-17 at 07:53 +0200, Helmut Grohne wrote: > xfce4-power-manager fails to build from source for every architecture on > the buildds. A typical failure is: Hi Helmut, thanks for the report. It seems that xfpm requires libxfe4ui 4.13 although that's not in configure.ac. Xfce 4.14 upload should happen soon, we're waiting for the RT feedback on xfconf/xfce4-panel transitions first. We can upload a new version with the build-deps updated but that won't change much until libxfce4ui 4.14 is uploaded anyway. Regards, -- Yves-Alexis
Bug#902362: xfce4-session: 'debian/rules clean' after build causes removal of xfce4-session/*.[hc]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Control: severity -1 important On Mon, 25 Jun 2018 16:16:49 +0200 Andreas Beckmann wrote: > Source: xfce4-session > Version: 4.13.0-1 > Severity: serious > Justification: fails to build from source (but built successfully in the past) > > Hi, > > xfce4-session fails to build twice in a row. The first build succeeds, > but during subsequent debian/rules clean the following files disappear: > > xfce4-session/xfsm-client-dbus.h > xfce4-session/xfsm-manager-dbus.c > xfce4-session/xfsm-marshal.h > xfce4-session/xfsm-manager-dbus.h > xfce4-session/xfsm-chooser-icon.h > xfce4-session/xfsm-client-dbus.c > xfce4-session/xfsm-marshal.c > > causing the second build to fail. Thanks, I did noticed that too, unsure where it comes from. In any case, that doesn't look RC to me, since it does build the first time. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl1e4mwACgkQ3rYcyPpX RFvCrggAqx2YSlaHLO1D4To2uW4uDHweKGg8AbIT+Nw+HsWpqvepnn60TeRLrVfR g72kz2uvxfy2cbwra+RiwtaZICVtddrzgMfahsrYXjOtDE0yKd1/WYPJ0EDHyuhR vQK5VmX4l9f1U+rghD44/uZMJpnmxk67OnDxCLDYqT3xzCpZ8CJPUAoIhUPGQIs9 0Xs5IxZ09BB/zZpsw8NWeWDzAKGqFEqx11YMjAswsfYtRHoMXH2dGzvaTrXU0JGs 9IuRlvP/caUA1b9vdxqoFbuWsQ3hD3taqQvl1/e6dqbHpwDQg3Lr+RN/8P1W+T6+ qnRvCnh6wXlOQ4V62vAcFQC5bTovow== =mRVo -END PGP SIGNATURE-
Bug#935794: xfce4-sntray-plugin FTBFS
Source: xfce4-sntray-plugin Version: 0.4.11-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Hi, xfce4-sntray-plugin doesn't seem to build from source anymore. We noticed that as part of the xfconf transition (part of the Xfce 4.14 relase) but it looks unrelated at first sight: cd /<>/obj-x86_64-linux-gnu/src && /usr/bin/valac -C -b /<>/src -d /<>/obj-x86_64-linux-gnu/src --pkg=gtk+-3.0 --pkg=vala-panel-sntray --pkg=budgie-1.0 --vapidir=/<>/src/vapi --vapidir=/<>/obj-x86_64-linux-gnu/src --target-glib=2.44 --gresources=/<>/src/.gresource.xml --thread -g /<>/src/sntray-applet-budgie.vala /<>/src/vala-panel-sntray-applet.vala:24.25-24.36: error: The type name `AppletPlugin' could not be found public class SNApplet : AppletPlugin A full build log can be found here: https://buildd.debian.org/status/fetch.php?pkg=xfce4-sntray-plugin&arch=amd64&ver=0.4.11-1%2Bb1&stamp=1566740069&raw=0 Could you fix the FTBFS so Xfce 4.14 can migrate to testing in time? Regards, -- Yves-Alexis -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (450, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#936035: xfwm4: fails to load due to missing libxfconf-0.so.2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, 2019-08-29 at 17:31 +0700, Theppitak Karoonboonyanan wrote: > Package: xfwm4 > Version: 4.14.0-1 > Severity: serious > Justification: Policy 3.5 > > Dear Maintainer, > > xfwm4 fails to start: > > $ xfwm4 > xfwm4: error while loading shared libraries: libxfconf-0.so.2: cannot > open shared object file: No such file or directory > $ ldd /usr/bin/xfwm4 | grep libxfconf > libxfconf-0.so.3 => /usr/lib/x86_64-linux-gnu/libxfconf-0.so.3 > (0x7f74ba2f5000) > libxfconf-0.so.2 => not found > $ > > Fortunately, installing libxfconf-0-2 does make it load successfully, > but it's not listed as a dependency. > > Actually, this bug can be grave (rendering the package unusable) > when libxfconf-0-2 is faded out. Hi, xfwm4 4.14.0-1 (in sid and unstable) is only linked against libxfconf-0.3, not libxfconf-0.2, so it's definitely not where the problem lies. Xfce 4.14 just migrated to testing so that could explain your issue (which is likely transient), but it shouldn't have happened anyway. Can you install the pax-utils package (and only that package, please try not to upgrade anything else) and give us the output of lddtree (so we have an idea from where exactly the link comes from). My guess would be libxfce4ui, so if you could give us the output of dpkg -l |grep libxfce4ui in the same reply it'd be nice. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl1nthwACgkQ3rYcyPpX RFtJdggAwHZABAc+x8sq0L8u6uihUu74OJZkJkqZMNbImDBrpc/e8hrvDFwJBOrN uU/o83cFnsG+gUzyZCGJEuID8QbY+GsTmHCPzTGBScK2sSV7igpJgkBDH7JR7GQd SOGloR8ui4tkWXAxYHVs640FGMmnc6wDmuLfewWtF85unSUJKY/hILEO3S4Ew32o g5E2fsyPeJ3Rxbv01IQmDg3OwMW/MkdWOOaCZxWSbfTD7BGHayFXVdZacGJrSMVW ao3qC6XoGHjR9rc0thHRTNORcEidcnHP8fjWa+AVnCDPv2WX2EomiCPTqy1pBoRk eE47hTHBrZEjujPBwWJJZFvJxfRhZg== =xCEb -END PGP SIGNATURE-
Bug#1023224: [Pkg-swan-devel] Bug#1023224: strongswan: autopkgtest regression: depends on no longer built strongswan-scepclient
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 2022-10-31 at 21:01 +0100, Paul Gevers wrote: > With a recent upload of strongswan the autopkgtest of strongswan fails > in testing when that autopkgtest is run with the binary packages of > strongswan from unstable. It passes when run with only packages from > testing. In tabular form: > > pass fail > strongswan from testing 5.9.8-1 > all others from testing from testing > > I copied some of the output at the bottom of this report. The > autopkgtest d/t/control files says the first test depends on > strongswan-scepclient, but src:strongswan no long build it. Hi Paul, thanks for the report but I'm not sure I totally understand it. The strongswan-scepclient has indeed been removed in the 5.9.8 upload, so it's definitely gone. I'm not sure why the test is failing then and what I should have done differently. Could you give me some pointers here? Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmNimmoACgkQ3rYcyPpX RFtBzQf9H4dH0IMrBRuVBPPuYYm7l+61bvbp/+dtmqkw2dKGJFKTEKkH1+pEb8jl 0uWNXEONd1CjiwcNigt5/O+qhhsrX5t08RlQ3QdALuOyb8vpFmAX/mlI2peakRyF daAuXvyyYRxa1827X894dsuKA/YZMe6UtlvraxyJsJTjZCTOI9LpeMDaMnXv5hwO GXt/Dyg399FY9IZCgotIwY/8VbTLxPSCNE72vNyx9djJRBk5s+jtyMcc51jzwf+4 wm0TSpShtuw8odPWzkNYSMAPKAPn6wqYlx6D66YPLIAxNACTSBPz2iPRoYE5dRN4 IFOMmvN/z96Mz5rQPguANT4SURuaiA== =6Bds -END PGP SIGNATURE-
Bug#1023224: [Pkg-swan-devel] Bug#1023224: Bug#1023224: strongswan: autopkgtest regression: depends on no longer built strongswan-scepclient
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, 2022-11-02 at 19:14 +0100, Paul Gevers wrote: > Hi Yves-Alexis, > > On 02-11-2022 17:27, Yves-Alexis Perez wrote: > > I'm not sure why the test is failing then and what I should have done > > differently. Could you give me some pointers here? > > https://sources.debian.org/src/strongswan/5.9.8-1/debian/tests/control/ > > line 2 says that the *first* two tests Depends on strongswan-scepclient. > That means that autopkgtests tries to install that binary package, which > fails because it's no longer available. Either remove the tests (if they > need that binary), or adapt the Depends line to what is required for the > test. I did a -2 upload but it's likely to fail again because I noticed afterwards that the _copyright test will fail as well since the util has been removed. I'll do a -3 upload when possible. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmNj7gwACgkQ3rYcyPpX RFugOwf9FZWN9C368efVEJVid7Bau6PQcocSRRCUO9dmfHbh99tzczX80FD2ob7v OcW7CD/2HWM0wdXzpFv9wG+9jwWJWZgL1NhHY+DY0YsltvMlaM/iS1Q6CTfPa+w+ Z1h70shIkgRFLKVxrYBry/Y2tqOyU+PII/jof7ySY8NHe44o1OXQhb4kqQLKcWAE i5Llcl174sx2lgRcLiEMhNIrANptYr4Sedz+sLo05MOZsvUSdhC3xf6af0DAodrK 1WG9R64TxVTJM5JHPX85vZOl4yci8m7EmUK7wqkIRDwvtKYr/v7ZbCV4mZrFYwGp 15mAJsc/5Zlmz5lDVyxBVij/T1p0nA== =SQsI -END PGP SIGNATURE-
Bug#1023224: [Pkg-swan-devel] Bug#1023224: Bug#1023224: strongswan: autopkgtest regression: depends on no longer built strongswan-scepclient
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, 2022-11-02 at 19:14 +0100, Paul Gevers wrote: > https://sources.debian.org/src/strongswan/5.9.8-1/debian/tests/control/ > > line 2 says that the *first* two tests Depends on strongswan-scepclient. > That means that autopkgtests tries to install that binary package, which > fails because it's no longer available. Either remove the tests (if they > need that binary), or adapt the Depends line to what is required for the > test. Ah, thanks! Now that's obvious. I'll fix that and reupload asap. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmNjrnIACgkQ3rYcyPpX RFsqjwf+N1mrNsivZ/Uo2fkq125UD6yWQA4r4SsRvEtAbWNH0/snGuxhk+V4v06I Rg4m+iJ9nP8GI9yA3jDR+sISuPknv1JWaYjIeUldwLsFHuKp8IZhBHR2LuXbuzFk XpoWID5KOPJEi3/MXrxk6vi2sxEqboVLXatomzZEk8nRFRYMTNySH0wQDq299plg d05Sguz0e5X+nV0PZe2xv9hCKznqSpgc14m0+Zot8hn+6QVdQvMkuC8QncDwsIv7 Jf3LFMkUa8QBdR1EjE/Hd0ji2ZSOIssjt9GrbW+Ltmk0TZOP9Q3oB8LL+e+dpyKE K5EmBTYx/bYLMRvFeNSRiEJ2fIT8Zw== =XytO -END PGP SIGNATURE-
Bug#1013129: exo: CVE-2022-32278
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 2022-06-17 at 17:08 +0200, Moritz Mühlenhoff wrote: > The following vulnerability was published for exo. > > CVE-2022-32278[0]: > > XFCE 4.16 allows attackers to execute arbitrary code because xdg-open > > can execute a .desktop file on an attacker-controlled FTP server. > > https://gitlab.xfce.org/xfce/exo/-/commit/c71c04ff5882b2866a0d8506fb460d4ef796de9f > > If you fix the vulnerability please also make sure to include the > CVE (Common Vulnerabilities & Exposures) id in your changelog entry. > > For further information see: > > [0] https://security-tracker.debian.org/tracker/CVE-2022-32278 > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-32278 > > Please adjust the affected versions in the BTS as needed. Hi Moritz thanks for the heads-up, I'll take care of the upload to sid and stable-security. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmKtu9kACgkQ3rYcyPpX RFsDjQf+NFhYi6pCz7G+2Ce9Byhpoi94b0CN8t2+4ILY2/NJq8wOv6IRgy4TrYz/ tvff1vCiK+OwnSymWnIiUNuslhqZxvJjTGuD1ZvgTd6UCxUhH1nEoE2mjR/LOnIL UePIkyJ3aWAZV1mr/Ez+f+YCZfuxuJKFIhjwX28p6qDvwK+F3oNUdlLJf670v8nz jROrgnIOZ2tVw6+Z3+Bd67VcW9zoHN87/hWIxxM7Hs6qrROGd27YauxTiXHdcDRQ 3fNicUiEB0E8FPhvJ5Dq+iXhHnqef7/WlKp15ci69dDv1RcBBfP1VsAh9OZn5tPE 6nGqseCIwTcPb6ACU1rIJuPoqkxv0w== =552N -END PGP SIGNATURE-
Bug#1021779: orage: eats events
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Control: reassign -1 libical3 Control: affects -1 orage On Fri, 14 Oct 2022 16:07:45 +0200 Slavko wrote: > Hi, > > On Fri, 14 Oct 2022 15:50:29 +0200 Slavko wrote: > > > upgrade libical3:amd64 3.0.14-1+b1 3.0.15-2 > > after i submit initial report, i tried to downgrade the libical3 to > previous version (from https://snapshot.debian.org/ ) and now all my > events are preserved, thus libical3 upgrade is related to it. > > To be sure, i start/stop orage multiple times, and events are still > here ;-) > > I am not able to decide if it is orage or libical3 problem (or both). > Hi Slavko, for some reason your reports never reached us so I've just seen this bug and your investigation. My feeling is that this is actually https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021698 so it might be interesting to check if it's fixed with 3.0.16-1. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmNVD2wACgkQ3rYcyPpX RFvdswf/XUwqXMlktP06VWu04Gh+w1TuLkNx85qF3ZUxfozcHaqoEzma48lLCLxx bkdZTZ9SrT54hCYq+gbEux9AIfjam+2OUCf5X/9EedVZ77VNCX8qFZ7Qe3VCZt7W 1zrKwXmfvEU/llnzxdh7Sh9tZgo5ny3v9+q0D3Dkv/9dXPEIeQC9qZpt1tS06zuf LrLsejJMfQNAlX9s/8+d84hx0WbgqN66F67RwzSPe0mD4t0HBLTjOdRKMNQ97epL GgV9K9qKMoaURgpcOk5vjyHsyDXFENFmFguMi6VjyrYkL1zKjvcG/XIBnc6i8dlQ W4FZWjlWfYL6mI/7zWFDXXBR+InFjQ== =4Fom -END PGP SIGNATURE-
Bug#996028: InnoDB: corrupted TRX_NO after upgrading to 10.3.31
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 2021-10-22 at 02:13 +0800, Marc Gallet wrote: > > Am I correct to assume this issue is still relevant for buster and that > for now, I should simply defer the upgrade (marking the packages to be > held back) and simply wait for this bug to be resolved? Hi Marc, as far as I can tell, yes the bug is still present. The fix attempt didn't work for me, maybe because my database is already corrupted, or maybe because it's actually not fixed at all. I have yet to try to dump my database under 10.3.25 and import it under 10.3.31 to check if it fixes the issue. Another possibility would be to rebuild with e46f76c9749d7758765ba274a212cfc2dcf3eeb8 (which Ondrej identified as the first bad commit) reverted. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmFynPYACgkQ3rYcyPpX RFvOoAgAwWYdiSdkN/Wau7jUf68hUVgcy6hIp1Wo5IbKIZcizs0KyEguOA6gjff2 Zv7VnTJ3Fv+y3i98FgV2f2rYbLkNw+PDmrdWjyYIzXIDS7jb05CZ1CwaAb0ni/qm rkYKm2vQIPl9sajvgWhbXkVgMcFDP9E25tELjHb3SX3YhhoTKQliTD+JUbSEr5Pw 6N16Z9mUFHuNYhDw99OUKbWxhJpAPa/VYu5ZzqR5gfYjYUQrQ3VXWxlJKsfhCBv+ +a3+GFR2pHVGWB6JUPzWj0wdwq5D2zp04uP1ZLtL40PrqwpH2Wd8rWIHbTHMszVY MjWAgfmlJnaU/eqIjtSqVVjDPIm+Jg== =91rF -END PGP SIGNATURE-
Bug#996028: [debian-mysql] Bug#996028: #996028 InnoDB: corrupted TRX_NO after upgrading to 10.3.31
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, 2021-10-14 at 19:38 +0200, Ondrej Zary wrote: > MDEV-15912: Remove traces of insert_undo > > Let us simply refuse an upgrade from earlier versions if the > upgrade procedure was not followed. This simplifies the purge, > commit, and rollback of transactions. > > Before upgrading to MariaDB 10.3 or later, a clean shutdown > of the server (with innodb_fast_shutdown=1 or 0) is necessary, > to ensure that any incomplete transactions are rolled back. > The undo log format was changed in MDEV-12288. There is only > one persistent undo log for each transaction. Hi Ondrej, it might be worth trying with that patch reverted, but I'm a bit confused at the commit message. That seems to imply my server didn't have a clean shutdown before upgrading to 10.3, which is possible but that upgrade is quite old by now (afaict it's between Stretch and Buster), so I'm unsure what to do now. innodb_fast_shutdown=0 doesn't terminate on 10.3.25, and I'm not sure if there are other ways to ensure a “clean shutdown”. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmFynjAACgkQ3rYcyPpX RFtw9Qf/WcV91Ea5ltjqC4rzuNn877t0sjbdYx/4gESfevP+OY8lBboAckXQfejK FAMZIrRtQ6vmLiTDpYEZgBEqVuyPICFJ2kuK6ejxzYT3zpUqoXMTi21fUd2pivKF IVVHdMlFEgHfErGxN66Rv8m/OZUknfDAmkdAgKO0+WS+HuD/wuN7Y2zRCQBZ5PJg 8GJUZK+9O/7UdfHtxJvEja4U7B8G+bwQhKBNtgolOIrfapakB9b63KasJ18PVpQm TpkL8XdolAG/cvqxp6UYjVdatOTmceH/tME0xzbnad/hNxzR4MZKjUlCrZ8T0zgW WvXUZt1YsEivScpY15T32FELKPQeDQ== =92/m -END PGP SIGNATURE-
Bug#996028: [debian-mysql] Bug#996028: #996028 InnoDB: corrupted TRX_NO after upgrading to 10.3.31
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 2021-10-22 at 15:22 +0200, Ondrej Zary wrote: > With 10.3.29 running, I've dumped all databases (mysqldump --all-databases - > p >mysql.dump), then dropped all databases, stopped mariadb and deleted > /var/lib/mysql/ib*. > Then restarted mariadb, restored databases (source mysql.dump) and finally > upgraded to 10.3.31. Thanks, I did the same, and it seemed to work. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmFy2ToACgkQ3rYcyPpX RFsnKggA7XFwEwfLwE/paI4ThRlsP6GbXSUT193ivkC//qVQCMdHc6HJPFkuMFEa 7DhLkyE+QfNhzPQad2XRhEoQklpp98392q1QztWt+z5lgopuw8PgHQXeyXLB4in0 dfUcbCCylIWf/HV0qzt5lMOn8aIgZ0pQrEDjC4hYolkl2lyhq8N8zyu5DnXAlSXL L90/VZUmuM48YOMZ40W5OTs/LYNB7O+dmMAhM6J4gM3xyQ+//Nn33f89v86BFemD DtqGtsCr+7ZIOHeZmf/OAHLudZ8z0wvVGeO80OCxc95K8Vo503L+CmZI4h/QGA6J KRm6Pv1tpwHIe4tuE+327DHAo1Z3YQ== =+ZaT -END PGP SIGNATURE-
Bug#996028: InnoDB: corrupted TRX_NO after upgrading to 10.3.31
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, 2021-10-24 at 00:51 +0800, Marc Gallet wrote: > Am I to understand that the expected path forward with what is supposed to be > a minor update offered on oldstable is that everyone shall dump their > databases, > delete the data folder, restore, then upgrade??? > > Sure I can do that, not happy to, but I can. > > However, that's an awful upgrade path and user experience for what would have > normally been a mere and uneventful "apt-get upgrade". I do hope not everyone > still on buster will have to do that after learning about it from a bug > report. To be fair, I think we might actually have an issue with our databases and the way they are stored: it's likely they do have some corruption in it that doesn't show before 10.3.31 but doesn't mean they're ok. So all in all even if the bug is fixed, it might be a good idea to do that backup/restore dance. > > Seems to me it would be better to not have pushed this update to oldstable in > the first place. (I'm not familiar with process, but could it be possibly > undone, > such that users stay on 10.3.29 and are not proposed the broken upgrade?). Well, 10.3.31 actually fixes security issues so you don't really want to stay behind in any case. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmF1SFUACgkQ3rYcyPpX RFtQjgf/ckSNysleNW7oW6QWOrlJrG5DKxw9LhhJYD/0zIMlDUKL3YSJM7VqCUS+ EFrUB2N/r7/p1d7/aispWKWuk3O6LvYmkoqv3V/GddverxZwfsaCCOnBkJXeEWgv dNKw2rv4Vt1xbhFtcISWnxNA3ES48cM1Vfdt7tUL7Qn21RreLYMNvtzez6d9f8mC p1Oan7JHQyPj9Ad50DR0IrnIAc+YAz1RaqQ9Dc98wfW5CkUXqLMk6kXWNImUYNiW zxEtuzDN8jAD1gOAwKLrfKNAIFLwdS0dO0aM6q/ILwSWwgHBdlTn8wkOXgZ8NsEI 2Jlw4arlq2dpPJGjfu912CuLtmmGRw== =PtQ4 -END PGP SIGNATURE-
Bug#884216: [Pkg-xfce-devel] Bug#884216: libxfce4ui: FTBFS: dh_install: libxfce4ui-common missing files: usr/share/gtk-doc/*
control: tag -1 moreinfo unreproducible On Tue, 2017-12-12 at 19:34 +0100, Andreas Beckmann wrote: > Hi, > > libxfce4ui/experimental recently started to FTBFS, probably due to > debhelper getting more strict w.r.t. missing files: > >debian/rules override_dh_install > make[1]: Entering directory '/build/libxfce4ui-4.13.3' > dh_install --sourcedir=/build/libxfce4ui-4.13.3 -plibxfce4ui-utils > debian/vendorinfo usr/share/xfce4 > dh_install -X .la > dh_install: Cannot find (any matches for) "usr/share/gtk-doc/*" (tried in ., > debian/tmp) > > dh_install: libxfce4ui-common missing files: usr/share/gtk-doc/* > dh_install: missing files, aborting > debian/rules:21: recipe for target 'override_dh_install' failed > make[1]: *** [override_dh_install] Error 25 > make[1]: Leaving directory '/build/libxfce4ui-4.13.3' I just tried a build (in pbuilder/amd64) and it worked just fine. Can you be more specific about your test? Is it an arch-indep build for example? Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#884358: Gajim: problem with latest python-openssl
On Fri, 15 Dec 2017 14:01:55 +0100 "W. Martin Borgert" wrote: > Dear Bjoern, dear Dimitris, > > thank you for your bug reports! I ask you for a favour: > > Could you please try Gajim from Debian experimental? > The plugins for the new Gajim are in experimental, too, > if you need them. > > I'm not yet sure, whether I will fix this bug in a new > Gajim 0.16.8-something, because IMHO Gajim > 0.16.11-somethingelse already works very fine for me. > > If the new Gajim works for you as well, I would do the > next upload to unstable instead of experimental. > I tried it after experiencing the openssl error, but I got message saying that my logs.db was corrupted. Console logs also shows: sqlite3.OperationalError: table logs has no column named account_id I can confirm after taking a dump that there is no column account_id in the table logs. If this column has appeared, in a new release, maybe gajim should convert the database itself? Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#884216: libxfce4ui: FTBFS: dh_install: libxfce4ui-common missing files: usr/share/gtk-doc/*
control: severity -1 important On Tue, 2017-12-19 at 23:42 +0100, Andreas Beckmann wrote: > > I just tried a build (in pbuilder/amd64) and it worked just fine. Can you > > be > > more specific about your test? Is it an arch-indep build for example? > > This was a regular (arch+indep) build with pbuilder --twice (but the log > was not labeled accordingly at that time) and only the second build failed. Ah ok, thanks for the precision (and I didn't know about --twice, thanks for that). I'm lowering the severity accordingly. > > I just filed a similar bug with more analysis as #884813 against > xfce-panel, it's probably the same underlying problem here, too. Ok, thanks. I'll take a look when I can. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#884799: [Pkg-xfce-devel] Bug#884799: thunar: Shredding a file causes Thunar to block permanently. (USB)
control: severity -1 important control: tag -1 unreproducible moreinfo On Tue, 2017-12-19 at 20:58 +0100, Lorenzo Ancora wrote: > Dear Maintainer, > shredding a file in a mounted USB key causes `Thunar 1.6.11 (Xfce 4.12)` to > block permanently. > The window with the key won't close and Thunar must be killed manually; it can > be restarted (must wait 2 minutes on a Intel Core i5) but is very slow and you > can just eject the USB device. After ejecting the USB device the problem does > not disappear and gets even worse. > Logging out causes `lightdm 1.18.3` to restart... and it keeps restarting > forever, in a loop. > From `lightdm` it becames impossible to reboot, shutdown etc. and it must be > done from a VT. > Activating the rescue mode (single user mode) from `systemctl` and going back > does not fix the problem. > Apparently the only way to fix the problem is to stop lightdm.service and > reboot the system. Hi, I'm sorry to hear that, but I don't think I can reproduce that (also it's unclear what “shredding” exactly means here). Also it's quite likely that you actually removed the USB key while the thunar process was still having open fd on the usb key, which is definitely the wrong thing to do. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#899744: closing 899744
close 899744 4.13.3-1 thanks
