Bug#1081183: Follow-up: power-profiles-daemon still hangs apt on upgrade with version 0.23-1
Dear Maintainer, I wanted to follow up on my previous report about the power-profiles-daemon hanging during upgrades. The issue is still occurring with the latest version, 0.23-1. This morning, I encountered the same behavior on two different machines when trying to upgrade to 0.23-1. Both systems experienced a hang during the apt upgrade process while configuring power-profiles-daemon, requiring a reboot to recover. As with the previous versions, this is preventing any new package installations or upgrades through apt without manual intervention. Let me know if any additional information is needed. Best regards, Fabrice Quenneville -- *Fabrice Quenneville* Entrepreneur
Bug#1081183: power-profiles-daemon
Just a mention that I tested this upgrade on a different machine with a completely different architecture and the update also hung apt on power-profiles-daemon out of 400 ish upgraded packages. Had to also force reboot and dpkg --configure -a Thanks -- *Fabrice Quenneville* Entrepreneur
Bug#1081183: power-profiles-daemon: Upgrade from 0.21-2 to 0.22-1 fails to configure, causing apt and dpkg hang
Package: power-profiles-daemon Version: 0.22-1 Severity: important X-Debbugs-Cc: fabquennevi...@gmail.com Dear Maintainer, I encountered an issue when upgrading the `power-profiles-daemon` package from version 0.21-2 to 0.22-1. The upgrade causes the package to hang while configuring, making both `apt` and `dpkg` unusable without manual intervention. Steps to reproduce: 1. Run `apt update && apt upgrade -y`. 2. The terminal hangs at "Setting up power-profiles-daemon", requiring a forced reboot. 3. After reboot, running `dpkg --configure -a` results in a hang at `power-profiles-daemon`, requiring a `ctrl+c` to skip it and proceed with configuring other packages. Expected behavior: - The package should configure successfully during the upgrade. Actual behavior: - The terminal hangs when configuring `power-profiles-daemon`. A reboot is necessary to recover, and subsequent attempts to use `apt` or `dpkg` fail until the package is skipped manually. Additional details: - `ctrl+c` does not work when `apt` hangs during configuration, only a reboot recovers the system. However, `ctrl+c` works with `dpkg`. - Every time I attempt to install a new/unrelated package with `apt`, it retries to configure `power-profiles-daemon`, forcing another reboot. - Running `dpkg-reconfigure power-profiles-daemon` also hangs. Error message seen after interrupting `dpkg --configure -a`: ``` Setting up power-profiles-daemon (0.22-1) ... Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 148. dpkg: error processing package power-profiles-daemon (--configure): installed power-profiles-daemon package post-installation script subprocess was interrupted ``` This issue makes it nearly impossible to use `apt` and `dpkg` without manual intervention after every system reboot. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.10.6-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages power-profiles-daemon depends on: ii libc6 2.40-2 ii libglib2.0-0t642.82.0-1 ii libgudev-1.0-0 238-5 ii libpolkit-gobject-1-0 125-2 ii python33.12.5-1 ii python3-gi 3.48.2-1+b1 power-profiles-daemon recommends no packages. power-profiles-daemon suggests no packages. -- no debconf information
Bug#1079598: Right-clicking 'New Style' in inactive Writer window opens menu in active window on another monitor.
libgpgmepp6t64 1.18.0-5 ii libgraphite2-3 1.3.14-2 ii libgstreamer-plugins-base1.0-0 1.24.6-1 ii libgstreamer1.0-0 1.24.6-1 ii libharfbuzz-icu08.3.0-2+b1 ii libharfbuzz0b 8.3.0-2+b1 ii libhunspell-1.7-0 1.7.2+really1.7.2-10+b2 ii libhyphen0 2.8.8-7+b1 ii libice6 2:1.0.10-1+b1 ii libicu7272.1-5 ii libjpeg62-turbo 1:2.1.5-3 ii liblcms2-2 2.14-2+b1 ii libldap-2.5-0 2.5.18+dfsg-2 ii libmythes-1.2-0 2:1.2.5-1+b1 ii libnspr42:4.35-1.1+b1 ii libnss3 2:3.102-1 ii libnumbertext-1.0-0 1.0.11-4+b1 ii libopenjp2-72.5.0-2+b3 ii liborcus-0.18-0 0.19.2-3+b3 ii liborcus-parser-0.18-0 0.19.2-3+b3 ii libpng16-16t64 1.6.43-5 ii libpoppler140 24.08.0-2 ii libraptor2-02.0.16-4 ii librdf0t64 1.0.17-4 ii libreoffice-common 4:24.2.5-3 ii librevenge-0.0-00.0.5-3+b1 ii libsm6 2:1.2.3-1+b1 ii libstdc++6 14.2.0-1 ii libtiff64.5.1+git230720-5 ii libuno-cppu3t64 4:24.2.5-3+b1 ii libuno-cppuhelpergcc3-3t64 4:24.2.5-3+b1 ii libuno-sal3t64 4:24.2.5-3+b1 ii libuno-salhelpergcc3-3t64 4:24.2.5-3+b1 ii libwebp71.4.0-0.1 ii libx11-62:1.8.7-1+b1 ii libx11-xcb1 2:1.8.7-1+b1 ii libxext62:1.3.4-1+b1 ii libxinerama12:1.1.4-3+b1 ii libxml2 2.9.14+dfsg-1.3+b3 ii libxmlsec1t64 1.2.41-1 ii libxmlsec1t64-nss 1.2.41-1 ii libxrandr2 2:1.5.4-1 ii libxrender1 1:0.9.10-1.1+b1 ii libxslt1.1 1.1.35-1.1 ii libzxcvbn0 2.5+dfsg-2 ii libzxing3 2.2.1-3+b1 ii uno-libs-private4:24.2.5-3+b1 ii ure 4:24.2.5-3+b1 ii zlib1g 1:1.3.dfsg+really1.3.1-1 Versions of packages libreoffice-core recommends: ii gstreamer1.0-libav 1.24.6-1 ii gstreamer1.0-plugins-bad 1.24.6-1 ii gstreamer1.0-plugins-base 1.24.6-1 ii gstreamer1.0-plugins-good 1.24.6-1 ii gstreamer1.0-plugins-ugly 1.24.6-1 ii libpaper-utils 1.1.29+b1 -- no debconf information -- *Fabrice Quenneville* Entrepreneur
Bug#1077075: mutter: Monitors not detected on Wayland after upgrade on Debian 13/testing
Done, here is the upstream bug report: https://gitlab.gnome.org/GNOME/mutter/-/issues/3605 Thanks On Sat, Jul 27, 2024 at 9:06 AM Jeremy Bícha wrote: > On Thu, Jul 25, 2024 at 3:39 PM Fabrice Quenneville > wrote: > > Package: mutter-common > > Version: 46.3.1-2 > > Severity: critical > > Justification: breaks the whole system > > I'm sorry that the upgrade has caused you problems, but I think this > is overstating the severity since there is a workaround (use the GNOME > on Xorg session) and you can still use 2 monitors on Wayland. > > > Today after the daily upgrades on Trixie/Testing I lost two of my > monitors on Wayland (I get all 4 on xorg.). > > Could you try reporting this issue upstream? > https://gitlab.gnome.org/GNOME/mutter/-/issues > > The Debian GNOME team has limited ability to help with complex mutter > issues. > > Notably, Debian Testing went straight from GNOME Shell/Mutter 44 to 46 > so there is a whole year of code changes in this week's upgrade. And > it's not practical to revert your computer to 44 or 45 now. > > Thank you, > Jeremy Bícha > -- *Fabrice Quenneville* Entrepreneur ca.linkedin.com/in/fabricequenneville/ Cell : 514.823.6678 Le contenu de ce courriel est réservé à son ou ses destinataires désignés et pourrait être confidentiel, non public, exclusif, protégé par le mandataire/client ou par tout autre privilège. La lecture, distribution, copie ou toute autre utilisation non autorisée de cette communication est interdite et pourrait être illégale. La réception de ce courriel par toute personne autre que le ou les destinataires désignés ne constitue aucune exonération de privilège ou de protection. Si vous n'êtes pas le destinataire désigné, ou si vous pensez avoir reçu ce courriel par erreur, veuillez prévenir l'expéditeur immédiatement et supprimer toute copie de votre ordinateur sans la lire, l'enregistrer ou l'utiliser de quelque manière que ce soit. Bien qu'elle ait fait l'objet d'une vérification contre les virus et tout autre logiciel malveillant (« maliciel »), nous ne sommes pas en mesure de garantir, de représenter ou d'assurer que cette communication est exempte de logiciels malveillants et ne comporte aucun risque de dommages. Toute responsabilité en cas de perte, de dommage ou de blessure, actuel ou présumé, provenant de la réception, de l'ouverture ou de l'utilisation de ce courriel est par la présente déclinée. This email is intended for the designated recipient(s) only, and may be confidential, non-public, proprietary, protected by the attorney/client or other privilege. Unauthorized reading, distribution, copying or other use of this communication is prohibited and may be unlawful. Receipt by anyone other than the intended recipient(s) should not be deemed a waiver of any privilege or protection. If you are not the intended recipient or if you believe that you have received this email in error, please notify the sender immediately and delete all copies from your computer system without reading, saving, or using it in any manner. Although it has been checked for viruses and other malicious software ("malware"), we do not warrant, represent or guarantee in any way that this communication is free of malware or potentially damaging defects. All liability for any actual or alleged loss, damage, or injury arising out of or resulting in any way from the receipt, opening or use of this email is expressly disclaimed.
Bug#1077075: mutter: Monitors not detected on Wayland after upgrade on Debian 13/testing
Package: mutter-common Version: 46.3.1-2 Severity: critical Justification: breaks the whole system X-Debbugs-Cc: fabquennevi...@gmail.com Dear Maintainer, Today after the daily upgrades on Trixie/Testing I lost two of my monitors on Wayland (I get all 4 on xorg.). * What led up to the situation? Today's daily upgrades: https://pastebin.com/RqVX9Bib * What exactly did you do (or not do) that was effective (or ineffective)? Loading the previous kernel was ineffective. Turning off extensions was ineffective. Logging-in on Gnome on xorg shows all my monitors. * What was the outcome of this action? Two of my 4 monitors still dont show on wayland but do on xorg. They are not listed in the> * What outcome did you expect instead? I normally have 4 monitors, two per GPU. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.9.10-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mutter-common depends on: ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4+b2 mutter-common recommends no packages. mutter-common suggests no packages. -- no debconf information Here are some relevent information: * journalctl -b | grep -i "drm\|gpu\|display\|wayland\|monitor" https://pastebin.com/Jv3gVsE8 * journalctl -b | grep -i "gnome-shell" https://pastebin.com/ch7UKwpq * lspci -k | grep -A 3 -E "(VGA|3D)" 27:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Turks GL [FirePro V4900] Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] Device 2b06 Kernel driver in use: radeon Kernel modules: radeon, amdgpu -- 28:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Redwood XT GL [FirePro V4800] Subsystem: Dell Device 240a Kernel driver in use: radeon Kernel modules: radeon, amdgpu * lsmod | grep -i "drm\|gpu\|nouveau\|amdgpu\|i915" amdgpu 12845056 0 amdxcp 12288 1 amdgpu drm_exec 12288 1 amdgpu gpu_sched 65536 1 amdgpu drm_buddy 20480 1 amdgpu video 73728 2 amdgpu,radeon i2c_algo_bit 12288 2 amdgpu,radeon drm_suballoc_helper12288 2 amdgpu,radeon drm_display_helper262144 2 amdgpu,radeon cec69632 1 drm_display_helper drm_ttm_helper 12288 2 amdgpu,radeon ttm 102400 3 amdgpu,radeon,drm_ttm_helper drm_kms_helper249856 3 drm_display_helper,amdgpu,radeon drm 737280 24 gpu_sched,drm_kms_helper,drm_exec,drm_suballoc_helper,drm_display_helper,drm_buddy,amdgpu,radeon,drm_ttm_helper,ttm,amdxcp * dpkg -l | grep wayland rc kwayland-data4:5.78.0-2 all Qt library wrapper for Wayland libraries - data files rc kwayland-integration:amd64 5.20.5-1 amd64kwayland runtime integration plugins ii libqt5waylandclient5:amd64 5.15.13-2 amd64QtWayland client library ii libqt5waylandcompositor5:amd64 5.15.13-2 amd64QtWayland compositor library ii libva-wayland2:amd64 2.22.0-1 amd64Video Acceleration (VA) API for Linux -- Wayland runtime ii libwayland-client0:amd64 1.22.0-2.1+b1 amd64wayland compositor infrastructure - client library ii libwayland-cursor0:amd64 1.22.0-2.1+b1 amd64wayland compositor infrastructure - cursor library ii libwayland-egl1:amd641.22.0-2.1+b1 amd64wayland compositor infrastructure - EGL library ii libwayland-server0:amd64 1.22.0-2.1+b1 amd64wayland compositor infrastructure - server library ii qtwayland5:amd64 5.15.13-2 amd64QtWayland platform plugin ii xwayland 2:24.1.0-1 amd64X server for running X clients under Wayland * journalctl -b | grep mutter https://pastebin.com/eTWJ5kJb
Bug#1068901: jupyter-core: upstream bug report and fix
Source: jupyter-core Version: 4.7.1-1+deb11u1 Followup-For: Bug #1068901 Dear Maintainer, The issue is discussed upstream https://github.com/jupyter/notebook/issues/7048 Recommendation is to update traitlets at least to 5.9.0. FYI, on my debian SID, traitlets is 5.14.3. Some comments of the issues also mention that this only hides the bug in notebook by making traitlets more tolerant So it seems that the real solution is this pull request https://github.com/jupyter/notebook/pull/7051/files fixing the default contents manager class name (and resorting to default warnings.warn) -- System Information: Debian Release: trixie/sid APT prefers oldstable-security APT policy: (500, 'oldstable-security'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.8.12-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#1001779: ITP: rust-hurl -- CLI that runs HTTP requests defined in simple plain text format
Yes, using Hurl as a library is a nice to have feature. But our main priority/focus is the CLI, installed with `apt install hurl`. On Thu, 16 May 2024 at 11:55, Maytham Alsudany wrote: > > Hi Fabrice, > > Is the hurl crate also intended to be used a library and imported by > other Rust code? > > Kind regards, > Maytham
Bug#1001779: ITP: rust-hurl -- CLI that runs HTTP requests defined in simple plain text format
Great! On Thu, 16 May 2024 at 05:31, Maytham Alsudany wrote: > > Hi Fabrice, > > On Wed, 2024-05-15 at 15:51 +0200, Fabrice Reix wrote: > > Hi Maytham, > > I'm one of the upstream maintainer of Hurl. Do not hesitate to ping us > > if we need to change something in the source. > > For the package name, would it be possible to use `hurl` rather than > > `rust-hurl` for the CLI? > > Only the source package is named 'rust-hurl'. All source packages in the > Rust team are prefixed with 'rust-' for consistency and to ensure there > are no conflicts with non-Rust packages. Don't worry, the binary package > will be named 'hurl' (i.e. users will run "sudo apt install hurl"). > > Kind regards, > Maytham
Bug#1001779: ITP: rust-hurl -- CLI that runs HTTP requests defined in simple plain text format
Hi Maytham, I'm one of the upstream maintainer of Hurl. Do not hesitate to ping us if we need to change something in the source. For the package name, would it be possible to use `hurl` rather than `rust-hurl` for the CLI? Thanks Fabrice On Wed, 15 May 2024 at 15:27, Maytham Alsudany wrote: > > Control: retitle -1 ITP: rust-hurl -- CLI that runs HTTP requests defined in > simple plain text format > Control: owner -1 ! > Control: severity -1 wishlist > > Hi, > > Proper package metadata is added here since the initial RFP was not formatted > correctly. > > * Package name: rust-hurl > Version : 4.3.0 > Upstream Contact: https://github.com/Orange-OpenSource/hurl/issues > * URL : https://hurl.dev > * License : Apache-2.0 > Programming Lang: Rust > Description : CLI that runs HTTP requests defined in simple plain text > format > > Hurl is a command line tool that runs HTTP requests defined in a simple plain > text format. > . > It can chain requests, capture values and evaluate queries on headers and > body > response. Hurl is very versatile: it can be used for both fetching data and > testing HTTP sessions. > . > Hurl makes it easy to work with HTML content, REST / SOAP / GraphQL APIs, or > any other XML / JSON based APIs. > > This looks like an interesting piece of software and I'm keen on packaging > this, as well as using it myself. Found out about this piece of software from > a > Mastodon post. > > This package will be maintained within the Debian Rust Team. > I will require a sponsor to upload this package. > > -- > Kind regards, > Maytham >
Bug#956454: gmsh: Seems to depend on "mouse selection"
Package: gmsh Version: 4.12.2+ds1-1 Followup-For: Bug #956454 Dear Maintainer, it seems that the spurious crash only occurs when "mouse selection" is enabled (using the esc keybinding). This may relate to the call to openglWindow::_select In the traceback provided previously #21 0x774bd136 in openglWindow::_select -- System Information: Debian Release: trixie/sid APT prefers oldstable-security APT policy: (500, 'oldstable-security'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.7.9-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages gmsh depends on: ii libc6 2.37-18 ii libgmsh4.12t64 4.12.2+ds1-1 Versions of packages gmsh recommends: pn gmsh-doc gmsh suggests no packages. -- no debconf information
Bug#1068901: jupyter-core: Second part of the bug related to #1068506
Source: jupyter-core Version: 4.7.1-1+deb11u1 Followup-For: Bug #1068901 Dear Maintainer, Seems that the current bug is twofold. First python does not find module 'jupyter_server.contents'. Then there is a second error while handling the exception. This second part has been reported in #1068506 (package python3- traitlets). This is a bug in the call of the traitlets.utils.warnings.warn function, with a missing required argument. best regards -- System Information: Debian Release: trixie/sid APT prefers oldstable-security APT policy: (500, 'oldstable-security'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.7.9-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#1068901: jupyter notebook fails to start: ModuleNotFoundError: No module named 'jupyter_server.contents'
Source: jupyter-core Version: 4.7.1-1+deb11u1 Followup-For: Bug #1068901 Dear Maintainer, I can confirm the bug. After a first error traceback mentioning the need of module jupyter_server, I installed the debian package jupyter-server (which was visibly not needed previously for a local Jupyter install to work and serve localhost notebooks Then the traceback now reports the lack of module jupyter_server.contents, which should be accessible once the debian package jupyter-server has been installed (according to apt-file). Any way to make jupyter work again ? Fabrice -- System Information: Debian Release: trixie/sid APT prefers oldstable-security APT policy: (500, 'oldstable-security'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.7.9-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#956454: gmsh: ... and also with nouveau_dri.so
Package: gmsh Version: 4.12.1+ds1-1 Followup-For: Bug #956454 Dear Maintainer, same bug (or a very similar one) is stil present in gmsh4.12. Opening a fresh gmsh window (without default untitled.geo file in HOME folder), I am able to navigate, zoom, rotate the view, etc... After adding points and lines seems OK too, but adding a 3D object (e.g., a sphere) makes the gmsh application crash. However the library appears usable using the Python API, as long as no graphical rendering is involved. Example of backtrace of crash: (gdb) bt #0 0x7fffe6f30f60 in ?? () from /lib/x86_64-linux-gnu/libLLVM-17.so.1 #1 0x7fffe6f735f7 in LLVMBuildBitCast () from /lib/x86_64-linux-gnu/libLLVM-17.so.1 #2 0x7fffee112402 in ?? () from /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #3 0x7fffee113ceb in ?? () from /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #4 0x7fffee11649b in ?? () from /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #5 0x7fffee0e754c in ?? () from /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #6 0x7fffee09810b in ?? () from /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #7 0x7fffee098bfb in ?? () from /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #8 0x7fffee09c358 in ?? () from /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #9 0x7fffee0324cb in ?? () from /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #10 0x7fffee02b386 in ?? () from /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #11 0x7fffee02b815 in ?? () from /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #12 0x7fffee02bcbd in ?? () from /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #13 0x7fffedde688d in ?? () from /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #14 0x7fffeddecc8b in ?? () from /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #15 0x7fffedcce552 in ?? () from /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #16 0x7fffedcfbeb9 in ?? () from /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #17 0x775bedef in drawContext::drawSphere(double, double, double, double, int) () from /lib/x86_64-linux-gnu/libgmsh.so.4.12 #18 0x775af5d2 in drawGRegion::operator()(GRegion*) () from /lib/x86_64-linux-gnu/libgmsh.so.4.12 #19 0x775ad6dc in drawContext::drawGeom() () from /lib/x86_64-linux-gnu/libgmsh.so.4.12 #20 0x775a297b in drawContext::select(int, bool, bool, bool, int, int, int, int, std::vector >&, std::vector >&, std::vector >&, std::vector >&, std::vector >&, std::vector >&, std::vector >&) () from /lib/x86_64-linux-gnu/libgmsh.so.4.12 #21 0x774bd136 in openglWindow::_select(int, bool, bool, bool, int, int, int, int, std::vector >&, std::vector >&, std::vector >&, std::vector >&, std::vector >&, std::vector >&, std::vector >&) () from /lib/x86_64-linux-gnu/libgmsh.so.4.12 #22 0x774bea3f in openglWindow::handle(int) () from /lib/x86_64-linux-gnu/libgmsh.so.4.12 #23 0x767454c9 in ?? () from /lib/x86_64-linux-gnu/libfltk.so.1.3 #24 0x7672d233 in ?? () from /lib/x86_64-linux-gnu/libfltk.so.1.3 #25 0x7672f47a in Fl::handle_(int, Fl_Window*) () from /lib/x86_64-linux-gnu/libfltk.so.1.3 #26 0x767917aa in fl_wait(double) () from /lib/x86_64-linux-gnu/libfltk.so.1.3 #27 0x7672eb66 in Fl::wait(double) () from /lib/x86_64-linux-gnu/libfltk.so.1.3 #28 0x7672ec25 in Fl::run() () from /lib/x86_64-linux-gnu/libfltk.so.1.3 #29 0x768456ca in __libc_start_call_main (main=main@entry=0x5050 , argc=argc@entry=1, argv=argv@entry=0x7fffdf68) at ../sysdeps/nptl/libc_start_call_main.h:58 #30 0x76845785 in __libc_start_main_impl (main=0x5050 , argc=1, argv=0x7fffdf68, init=, fini=, rtld_fini=, stack_end=0x7fffdf58) at ../csu/libc-start.c:360 #31 0x5081 in _start () -- System Information: Debian Release: trixie/sid APT prefers oldstable-security APT policy: (500, 'oldstable-security'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.6.13-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages gmsh depends on: ii libc6 2.37-15 ii libgmsh4.12 4.12.1+ds1-1 Versions of packages gmsh recommends: pn gmsh-doc gmsh suggests no packages. -- no debconf information
Bug#1055901: Acknowledgement (raspi-firmware: postinst fails, makes bad assumption about existence of /boot/firmware/)
I got this issue while upgrading from bullseye to bookworm I opened this PR https://salsa.debian.org/debian/raspi-firmware/-/merge_requests/33 on salsa. It might do the job. I just tested the small if I added, I'd be glad if someone is able to make test in condition of this. Regards, Fabrice
Bug#1024695: Merge request
Hello, At least a few of the warnings will be fixed by this merge request: https://salsa.debian.org/emacsen-team/debian-el/-/merge_requests/6 Can we consider merging it? Thanks! Best regards -- Fabrice Bauzac-Stehly PGP 01EEACF8244E9C14B551C5256ADA5F189BD322B6
Bug#1052047: libreoffice-calc: background color not (always) rendered
Package: libreoffice-calc Version: 4:7.4.7-1 Severity: normal X-Debbugs-Cc: fabrice.aeschbac...@gmail.com Dear Maintainer, Please note that I'm unsure whether the bug should be filled against xfce4 or libreoffice-calc. I'm running libreoffice-calc under XFCE4 with default theme (High Contrast) - If I set the cell background color to any color except white, say "yellow", the cell's background color stays white. - When clicking "File => Print Preview", the cell's background stays white. - Under "Tools => Options => Accessibility", if I unselect "Use system colors for page previews", the cell's background is rendered correctly (yellow) in Print Preview, but not in the sheet. - In XFCE Settings => Appearance, If I change the default style (High Contrast) to say Adwaita (which is another style installed by default), the cell's background is rendered correctly, in the sheet like in Print Preview. The bug happens in versions 4:7.4.7-1 (bookworm) and also with 4:7.5.6-1~bpo12+1 (bookworm-backports). It used to work fine with bullseye versions. -- Package-specific info: Configuration file Package Exists Changed /etc/libreoffice/registry/calc.xcd libreoffice-calc Yes No All deployed bundled extensions: All deployed shared extensions: All deployed user extensions: Experimental features enabled: Installed VCLplugs: 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) ||/ Name Version Architecture Description +++----=== ii libreoffice-gtk3 4:7.4.7-1 amd64 office productivity suite -- GTK+ 3 integration un libreoffice-kf5 (no description available) un libreoffice-qt5 (no description available) -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-11-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libreoffice-calc depends on: ii coinor-libcoinmp1v5 1.8.3-3 ii libc6 2.36-9+deb12u1 ii libetonyek-0.1-1 0.1.10-3+b1 ii libgcc-s1 12.2.0-14 ii libicu72 72.1-3 ii libmwaw-0.3-3 0.3.21-1 ii libodfgen-0.1-1 0.1.8-2 ii liborcus-0.17-0 0.17.2-2+b2 ii liborcus-parser-0.17-0 0.17.2-2+b2 ii libreoffice-base-core 4:7.4.7-1 ii libreoffice-common 4:7.4.7-1 ii libreoffice-core 4:7.4.7-1 ii librevenge-0.0-0 0.0.5-3 ii libstaroffice-0.0-0 0.0.7-1 ii libstdc++6 12.2.0-14 ii libuno-cppu3 4:7.4.7-1 ii libuno-cppuhelpergcc3-3 4:7.4.7-1 ii libuno-sal3 4:7.4.7-1 ii libuno-salhelpergcc3-3 4:7.4.7-1 ii libwps-0.4-4 0.4.13-1 ii libxml2 2.9.14+dfsg-1.3~deb12u1 ii lp-solve 5.5.2.5-2 ii ucf 3.0043+nmu1 ii uno-libs-private 4:7.4.7-1 libreoffice-calc recommends no packages. Versions of packages libreoffice-calc suggests: ii ocl-icd-libopencl1 2.3.1-1 Versions of packages libreoffice-core depends on: ii fontconfig 2.14.1-4 ii fonts-opensymbol 4:102.12+LibO7.4.7-1 ii libabsl20220623 20220623.1-1 ii libboost-locale1.74.0 1.74.0+ds1-21 ii libc6 2.36-9+deb12u1 ii libcairo2 1.16.0-7 ii libclucene-contribs1v5 2.3.3.4+dfsg-1.1 ii libclucene-core1v5 2.3.3.4+dfsg-1.1 ii libcups2 2.4.2-3+deb12u1 ii libcurl3-gnutls 7.88.1-10+deb12u1 ii libdbus-1-3 1.14.8-2~deb12u1 ii libdconf1 0.40.0-4 ii libeot0 0.01-5+b1 ii libepoxy0 1.5.10-1 ii libexpat1 2.5.0-1 ii libexttextcat-2.0-0 3.4.5-1 ii libfontconfig1 2.14.1-4 ii libfreetype6 2.12.1+dfsg-5 ii libgcc-s1 12.2.0-14 ii libglib2.0-0 2.74.6-2 ii libgpgmepp6 1.18.0-3+b1 ii libgraphite2-3 1.3.14-1 ii libgstreamer-plugins-base1.0-0 1.22.0-3+deb12u1 ii libgstreamer1.0-0 1.22.0-2 ii libharfbuzz-icu0 6.0.0+dfsg-3 ii libharfbuzz0b 6.0.0+dfsg-3 ii libhunspell-1.7-0 1.7.1-1 ii libhyphen0 2.8.8-7 ii libice6 2:1.0.10-1 ii libicu
Bug#1050793: python3-deepdiff: python3-clevercsv should be a Recommends, not a Depends
Package: python3-deepdiff Version: 6.2.2-1 Severity: normal Dear Maintainer, Debian package python3-deepdiff currently considers python3-clevercsv as a dependency. However that package is only considered as optional by the developers (see https://github.com/seperman/deepdiff). The deepdiff source code correctly handles the case where clevercsv is not installed (standard library csv module as a fallback): https://github.com/seperman/deepdiff/blob/master/deepdiff/serialization.py#L29 The trouble is that python3-clevercsv itself depends on python3-pandas which is quite a massive package (20Mb). Please remove the dependency on clevercsv and deprecate it as a Recommends. Best regards Fabrice -- System Information: Debian Release: trixie/sid APT prefers oldstable-security APT policy: (500, 'oldstable-security'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.4.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages python3-deepdiff depends on: ii python3 3.11.4-5+b1 pn python3-clevercsv pn python3-jsonpickle ii python3-numpy 1:1.24.2-1 pn python3-ordered-set ii python3-setuptools 68.0.0-2 python3-deepdiff recommends no packages. python3-deepdiff suggests no packages.
Bug#1022151: python3-pip: Trying to install a package gave me some errors I believe are from pip.
Package: python3-pip Version: 20.3.4-4+deb11u1 Severity: grave Justification: renders package unusable X-Debbugs-Cc: fabquennevi...@gmail.com Dear Maintainer, I was trying to install spotipy with: pip3 install spotipy and I got a wall of errors: --- Logging error --- Traceback (most recent call last): File "/home/fabrice/.local/lib/python3.9/site-packages/pip/_internal/utils/logging.py", line 177, in emit self.console.print(renderable, overflow="ignore", crop=False, style=style) File "/home/fabrice/.local/lib/python3.9/site-packages/pip/_vendor/rich/console.py", line 1673, in print extend(render(renderable, render_options)) File "/home/fabrice/.local/lib/python3.9/site-packages/pip/_vendor/rich/console.py", line 1305, in render for render_output in iter_render: File "/home/fabrice/.local/lib/python3.9/site-packages/pip/_internal/utils/logging.py", line 134, in __rich_console__ for line in lines: File "/home/fabrice/.local/lib/python3.9/site-packages/pip/_vendor/rich/segment.py", line 249, in split_lines for segment in segments: File "/home/fabrice/.local/lib/python3.9/site-packages/pip/_vendor/rich/console.py", line 1283, in render renderable = rich_cast(renderable) File "/home/fabrice/.local/lib/python3.9/site-packages/pip/_vendor/rich/protocol.py", line 36, in rich_cast renderable = cast_method() File "/home/fabrice/.local/lib/python3.9/site-packages/pip/_internal/self_outdated_check.py", line 130, in __rich__ pip_cmd = get_best_invocation_for_this_pip() File "/home/fabrice/.local/lib/python3.9/site-packages/pip/_internal/utils/entrypoints.py", line 58, in get_best_invocation_for_this_pip if found_executable and os.path.samefile( File "/usr/lib/python3.9/genericpath.py", line 101, in samefile s2 = os.stat(f2) FileNotFoundError: [Errno 2] No such file or directory: '/usr/bin/pip3.9' Call stack: File "/home/fabrice/.local/bin/pip3", line 8, in sys.exit(main()) File "/home/fabrice/.local/lib/python3.9/site-packages/pip/_internal/cli/main.py", line 70, in main return command.main(cmd_args) File "/home/fabrice/.local/lib/python3.9/site-packages/pip/_internal/cli/base_command.py", line 101, in main return self._main(args) File "/home/fabrice/.local/lib/python3.9/site-packages/pip/_internal/cli/base_command.py", line 223, in _main self.handle_pip_version_check(options) File "/home/fabrice/.local/lib/python3.9/site-packages/pip/_internal/cli/req_command.py", line 190, in handle_pip_version_check pip_self_version_check(session, options) File "/home/fabrice/.local/lib/python3.9/site-packages/pip/_internal/self_outdated_check.py", line 236, in pip_self_version_check logger.warning("[present-rich] %s", upgrade_prompt) File "/usr/lib/python3.9/logging/__init__.py", line 1454, in warning self._log(WARNING, msg, args, **kwargs) File "/usr/lib/python3.9/logging/__init__.py", line 1585, in _log self.handle(record) File "/usr/lib/python3.9/logging/__init__.py", line 1595, in handle self.callHandlers(record) File "/usr/lib/python3.9/logging/__init__.py", line 1657, in callHandlers hdlr.handle(record) File "/usr/lib/python3.9/logging/__init__.py", line 948, in handle self.emit(record) File "/home/fabrice/.local/lib/python3.9/site-packages/pip/_internal/utils/logging.py", line 179, in emit self.handleError(record) Message: '[present-rich] %s' Arguments: (UpgradePrompt(old='22.2.2', new='22.3'),) This seamed like a pip error so I tryed pip3 install pip-install-test And got a similar wall of errors: Defaulting to user installation because normal site-packages is not writeable Collecting pip-install-test Downloading pip_install_test-0.5-py3-none-any.whl (1.7 kB) Installing collected packages: pip-install-test Successfully installed pip-install-test-0.5 --- Logging error --- Traceback (most recent call last): File "/home/fabrice/.local/lib/python3.9/site-packages/pip/_internal/utils/logging.py", line 177, in emit self.console.print(renderable, overflow="ignore", crop=False, style=style) File "/home/fabrice/.local/lib/python3.9/site-packages/pip/_vendor/rich/console.py", line 1673, in print extend(render(renderable, render_options)) File "/home/fabrice/.local/lib/python3.9/site-packages/pip/_vendor/rich/console.py", line 1305, in render for render_output in iter_render: File "/home/fabrice/.local/lib/python3.9/site-packages/pip/_internal/utils/logging.py", line 134, in __rich_console__ for line in lines: File "/home/fabrice/.local/lib/python3.9/site-packages/pip/_vendor/rich/segment.
Bug#951559: pinot FTCBFS: uses the build architecture pkg-config
On Tue, 28 Sep 2021 12:57:41 +1300 Olly Betts wrote: > There's a 1.2.0 release planned for the near future, so packaging that > once it is out should address all the issues you reported. > Please note that 1.20 was released in October 2021 and 1.21 on February 2022. Best regards, Fabrice
Bug#953912: pinot: Switch from deprecated to
On Tue, 28 Sep 2021 12:59:21 +1300 Olly Betts wrote: > There's a 1.2.0 release planned for the near future, so packaging that > once it is out should address this. > Please note that 1.20 was released in October 2021 and 1.21 on February 2022. Best regards, Fabrice
Bug#1002675: re hubic/pyrax problem
Dear all, I'll be more than happy to solve this bug by myself, provided that I knew how to get the relevant informations, i.e. the file and the line number where the error comes from. Unfortunately, the duplicity -v9 command does not give me what I am expecting (see output below). What am I doing wrong ? Thanks in advance for your help. Output of duplicity -v9: GPG binary is gpg, version (2, 2, 27) Import of duplicity.backends.adbackend Succeeded Import of duplicity.backends.azurebackend Succeeded Import of duplicity.backends.b2backend Succeeded Import of duplicity.backends.boxbackend Succeeded Import of duplicity.backends.cfbackend Succeeded Import of duplicity.backends.dpbxbackend Succeeded Import of duplicity.backends.gdocsbackend Succeeded Import of duplicity.backends.gdrivebackend Succeeded Import of duplicity.backends.giobackend Succeeded Import of duplicity.backends.hsibackend Succeeded Import of duplicity.backends.hubicbackend Succeeded Import of duplicity.backends.idrivedbackend Succeeded Import of duplicity.backends.imapbackend Succeeded Import of duplicity.backends.jottacloudbackend Succeeded Import of duplicity.backends.lftpbackend Succeeded Import of duplicity.backends.localbackend Succeeded Import of duplicity.backends.mediafirebackend Succeeded Import of duplicity.backends.megabackend Succeeded Import of duplicity.backends.megav2backend Succeeded Import of duplicity.backends.megav3backend Succeeded Import of duplicity.backends.multibackend Succeeded Import of duplicity.backends.ncftpbackend Succeeded Import of duplicity.backends.onedrivebackend Succeeded Import of duplicity.backends.par2backend Succeeded Import of duplicity.backends.pcabackend Succeeded Import of duplicity.backends.pydrivebackend Succeeded Import of duplicity.backends.rclonebackend Succeeded Import of duplicity.backends.rsyncbackend Succeeded Import of duplicity.backends.s3_boto3_backend Succeeded Import of duplicity.backends.s3_boto_backend Succeeded Import of duplicity.backends.ssh_paramiko_backend Succeeded Import of duplicity.backends.ssh_pexpect_backend Succeeded Import of duplicity.backends.swiftbackend Succeeded Import of duplicity.backends.sxbackend Succeeded Import of duplicity.backends.tahoebackend Succeeded Import of duplicity.backends.webdavbackend Succeeded Connection failed, please check your credentials: TypeError a bytes-like object is required, not 'str' Le 30/12/2021 à 06:10, Alexander Zangerl a écrit : fabrice, upstream has reported that the problem you're encountering is pretty much certainly not coming from duplicity but pyrax - which is deprecated and no longer being maintained. upstream requests the log of a duplicity run with full -v9 logging/debugging on in order to track this down any further. if you can provide such a log the chances of getting this sorted out will rise a bit. regards az
Bug#974217: RFS: python-radexreader/1.2.1-1 [ITP] -- Reader for the RADEX RD1212 Geiger counter
I found, this is easy: in radexreader.manpages: debian/radexreader.1 debian/radexreader.fr.1 so I didn't say anything
Bug#1002675: re hubic/pyrax problem
Hello, Firstly, the type error can be solved by doing this: change in hubic.py in class HubicIdentity def __init__(self) by def __init__(self, **kwargs) However, the connection still fails with the following error: Connection failed, please check your credentials: TypeError a bytes-like object is required, not 'str' The full v9 log is not unfortunattly quite helpful ! Here is the output: $ duplicity -v9 status cf+hubic://owncloud Using archive dir: /data1/hubic/.cache/duplicity/ddc194b0289be77f5dd06ec911d17a78 Using backup name: ddc194b0289be77f5dd06ec911d17a78 GPG binary is gpg, version (2, 2, 27) Import of duplicity.backends.adbackend Succeeded Import of duplicity.backends.azurebackend Succeeded Import of duplicity.backends.b2backend Succeeded Import of duplicity.backends.boxbackend Succeeded Import of duplicity.backends.cfbackend Succeeded Import of duplicity.backends.dpbxbackend Succeeded Import of duplicity.backends.gdocsbackend Succeeded Import of duplicity.backends.gdrivebackend Succeeded Import of duplicity.backends.giobackend Succeeded Import of duplicity.backends.hsibackend Succeeded Import of duplicity.backends.hubicbackend Succeeded Import of duplicity.backends.idrivedbackend Succeeded Import of duplicity.backends.imapbackend Succeeded Import of duplicity.backends.jottacloudbackend Succeeded Import of duplicity.backends.lftpbackend Succeeded Import of duplicity.backends.localbackend Succeeded Import of duplicity.backends.mediafirebackend Succeeded Import of duplicity.backends.megabackend Succeeded Import of duplicity.backends.megav2backend Succeeded Import of duplicity.backends.megav3backend Succeeded Import of duplicity.backends.multibackend Succeeded Import of duplicity.backends.ncftpbackend Succeeded Import of duplicity.backends.onedrivebackend Succeeded Import of duplicity.backends.par2backend Succeeded Import of duplicity.backends.pcabackend Succeeded Import of duplicity.backends.pydrivebackend Succeeded Import of duplicity.backends.rclonebackend Succeeded Import of duplicity.backends.rsyncbackend Succeeded Import of duplicity.backends.s3_boto3_backend Succeeded Import of duplicity.backends.s3_boto_backend Succeeded Import of duplicity.backends.ssh_paramiko_backend Succeeded Import of duplicity.backends.ssh_pexpect_backend Succeeded Import of duplicity.backends.swiftbackend Succeeded Import of duplicity.backends.sxbackend Succeeded Import of duplicity.backends.tahoebackend Succeeded Import of duplicity.backends.webdavbackend Succeeded Connection failed, please check your credentials: TypeError a bytes-like object is required, not 'str' Using temporary directory /tmp/duplicity-xwljyau7-tempdir Do you know how to get a more useful debug output (i.e. with the detailed python error and line numbers) ? Thanks.
Bug#974217: RFS: python-radexreader/1.2.1-1 [ITP] -- Reader for the RADEX RD1212 Geiger counter
I updated the radexreader binary package with the man page (and with the right section). Not yet uploaded. I only created radexreader.manpages and radexreader.1 files. No other changes. Do you know if I can add a translation of the man page in the package? Also, do you know where I can submit translation of the package description? I found https://ddtp.debian.org/ddtss/index.cgi/xx but I don't know if this is the right place or not. Thanks
Bug#996577: fixed in duplicity 0.8.21-1
Hello, I've just installed duplicity (0.8.21-1) from unstable repository. This solves the 'BaseIdentity' bug. Unfortunately, the hubic backend does not seem to work yet. I now get the following error: Connection failed, please check your credentials: TypeError __init__() got an unexpected keyword argument 'username' Thanks. Fabrice. On Sat, 25 Dec 2021 07:33:42 + Debian FTP Masters wrote: > Source: duplicity > Source-Version: 0.8.21-1 > Done: Alexander Zangerl > > We believe that the bug you reported is fixed in the latest version of > duplicity, which is due to be installed in the Debian FTP archive. > > A summary of the changes between this version and the previous one is > attached. > > Thank you for reporting the bug, which will now be closed. If you > have further comments please address them to 996...@bugs.debian.org, > and the maintainer will reopen the bug report if appropriate. > > Debian distribution maintenance software > pp. > Alexander Zangerl (supplier of updated duplicity package) > > (This message was generated automatically at their request; if you > believe that there is a problem with it please contact the archive > administrators by mailing ftpmas...@ftp-master.debian.org) > > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Format: 1.8 > Date: Sat, 25 Dec 2021 16:04:16 +1000 > Source: duplicity > Architecture: source > Version: 0.8.21-1 > Distribution: unstable > Urgency: medium > Maintainer: Alexander Zangerl > Changed-By: Alexander Zangerl > Closes: 605878 677215 862005 996577 > Changes: > duplicity (0.8.21-1) unstable; urgency=medium > . > * new upstream release (closes: #996577, #677215, #605878, #862005) > debhelper compat updated, ditto standards version > Checksums-Sha1: > 61e99177789ff86337f7f6602b395ae1266d96f0 2085 duplicity_0.8.21-1.dsc > 2703806f1397a132b7de7eb365c7d79a32efd0f3 1375469 duplicity_0.8.21.orig.tar.gz > 9c1b3952d8bff5c2cf3d8fe2290ef1abf0e88dc0 15868 duplicity_0.8.21-1.debian.tar.xz > 420db366ba62e2e86f3e09dc598ebb0575ed602c 11003 duplicity_0.8.21-1_amd64.buildinfo > Checksums-Sha256: > 2b005e4f095fe8a9e9071157536c8ae64fb60ec72f7e745d2700c43695dbd2d6 2085 duplicity_0.8.21-1.dsc > 57fea6764674718cd6f6d499e6de92c973ba4f5e74dd94fc5e644713355ca451 1375469 duplicity_0.8.21.orig.tar.gz > 51dc04ba05c8606e53b73d76267ef7fefd626d667e0ca3f5beb9135014953a5d 15868 duplicity_0.8.21-1.debian.tar.xz > f746a43c0577462cad0c397da1c877c578aec7fd4079c40ab27c9f8ccef8d684 11003 duplicity_0.8.21-1_amd64.buildinfo > Files: > 43f29f44bb3c24ac970b1692bb6db4de 2085 utils optional duplicity_0.8.21-1.dsc > 5227dd503c251d8b678ea663b759cb98 1375469 utils optional duplicity_0.8.21.orig.tar.gz > 924d994ac387df69d6ed8cddc5b80519 15868 utils optional duplicity_0.8.21-1.debian.tar.xz > b010edab19b8a5e644635c710910f949 11003 utils optional duplicity_0.8.21-1_amd64.buildinfo > > -BEGIN PGP SIGNATURE- > > iQIcBAEBCgAGBQJhxsW8AAoJED06g4g30PqNu2QP/A0irnka8Ql19slOPimc0RDS
Bug#974217: RFS: python-radexreader/1.2.1-1 [ITP] -- Reader for the RADEX RD1212 Geiger counter
For the manual page, yes I have to take care of it. For the python section... I checked again the scour package, control file says "Section: graphics", but package appear in python section with Aptitude. So, I'm not sure what section to use. Thank you Le 26/11/2021 à 19:02, Bastian Germann a écrit : Control: tags -1 moreinfo Hi Fabrice, I will sponsor the package when you have fixed: radexreader: no-manual-page usr/bin/radexreader radexreader: application-in-library-section python usr/bin/radexreader Thanks, Bastian
Bug#974217: RFS: python-radexreader/1.0.0-5 [ITP] -- Reader for the RADEX RD1212 Geiger counter
I'm not sure what error you have encountered. When I trying the following commands, it works (for me). But perhaps it's not the good way. dget -x https://mentors.debian.net/debian/pool/main/p/python-radexreader/python-radexreader_1.2.1-1.dsc tar xzf python-radexreader_1.2.1.orig.tar.gz tar xf python-radexreader_1.2.1-1.debian.tar.xz cp -a debian/ python-radexreader-1.2.1/ cd python-radexreader-1.2.1/ debuild -b -uc -us ls ../*deb ../python3-radexreader_1.2.1-1_all.deb ../radexreader_1.2.1-1_all.deb Le 27/10/2021 à 22:28, Bastian Germann a écrit : Control: tags -1 moreinfo On Sun, 29 Nov 2020 13:08:01 +0100 Fabrice Creuzot wrote: I uploaded a new package release (1.0.0-5). I fixed lintian errors and I updated debian directory in source repository. Building from git is broken. Please reupload a source package and remove this bug's moreinfo tag after that.
Bug#994666: RFS: python-mockito/1.2.2-2 -- Spying framework for Python - documentation
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "python-mockito". It has already been uploaded with binary packages to unstable. To reach testing (bookworm), it needs this source-only upload, which is why I need a sponsor. * Package name: python-mockito Version : 1.2.2-2 Upstream Author : https://github.com/kaste/mockito-python/issues * URL : https://github.com/kaste/mockito-python * License : Expat * Vcs : https://salsa.debian.org/python-team/packages/python-mockito Section : python It builds those binary packages: python-mockito-doc - Spying framework for Python - documentation python3-mockito - Spying framework for Python To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-mockito/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-mockito/python-mockito_1.2.2-2.dsc Changes since the last upload: python-mockito (1.2.2-2) unstable; urgency=medium . * Source-only upload. Thanks in advance! Best regards -- Fabrice Bauzac-Stehly PGP 01EEACF8244E9C14B551C5256ADA5F189BD322B6
Bug#959892: RFS: awf-gtk/2.6.0-1 [ITP] -- A widget factory is a theme preview application for GTK
Hello, I uploaded a new version to mentors.debian.net. https://mentors.debian.net/package/awf-gtk/ I forgot to check the deletion of deb.sh :'( I'm not sure how to proceed with this new version. Thank you.
Bug#959892: RFS: awf-gtk/2.5.0-1 [ITP] -- A widget factory is a theme preview application for GTK
I have added GTK version in short description. I have removed the GTK 2 build, I'm sad :'(. I updated patch description. For the manpages, yes, it's in my futur todo list, but not yet done. Mentors package updated. Le 15/08/2021 à 12:20, Tobias Frost a écrit : On Sun, Aug 15, 2021 at 11:52:59AM +0200, Tobias Frost wrote: On Sun, Aug 15, 2021 at 11:21:21AM +0200, Fabrice Creuzot wrote: Hi, Thank you. I hope I have fixed the crash with GTK 4. I fixed the debian format. I changed unstable to testing, good? You want "experimental" :) -- tobi (I've merged the RFS and ITP bugs) - Beside "experimental", lintian has: I duplicate-short-description Possibly ammend the short description by the intended GTK version? - The patch has a "Bugs-Debian" entry, but the mentioned bug is the ITP. This is not the intended usage of the field: The field should be used if that patch fixes a specific Debian-Bug, with information the bug being fixed the mentioned bug. (The ITP is not fixin a bug) TL;DR: Remove that field. Though, you should add "Fowarded:" entries (possibly not-needed if Debian specific) (Please read https://dep-team.pages.debian.net/deps/dep3/ for all those details about the dep3 format.) - BTW, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959434#10 … Possibly you should drop the gtk-2 version from your package to be nice to the GTK maintainers (it will create extra work for them if you introduce new GTK2 packages) - (Wishlist) Would it be possible to have some manpages for the binaries? -- tobi
Bug#959892: RFS: awf-gtk/2.5.0-1 [ITP] -- A widget factory is a theme preview application for GTK
Hi, Thank you. I hope I have fixed the crash with GTK 4. I fixed the debian format. I changed unstable to testing, good? I'm not sure what to do with: the short desc shouldn't be capitalized. In my last email, I forgot that I have modified: >> awf-gtk2 - Theme preview application for GTK >> awf-gtk3 - Theme preview application for GTK >> awf-gtk4 - Theme preview application for GTK Package is up to date at mentors.net. For "patch-not-forwarded-upstream", I applied the pacth for the next release. Le 14/08/2021 à 20:40, Adam Borowski a écrit : On Fri, Aug 13, 2021 at 02:21:21PM +0200, Fabrice Creuzot wrote: Okay, so I tried to build all binary packages from one source package. Not sure if it's the good way. It builds those binary packages: awf-gtk2 - A widget factory is a theme preview application for GTK awf-gtk3 - A widget factory is a theme preview application for GTK awf-gtk4 - A widget factory is a theme preview application for GTK Generally, looks good to me. However, gtk-4 is available only in experimental. This will almost certainly change before your package leaves NEW (gtk4 maintainers are probably salivating at the thought of uploading to unstable ASAP, while NEW is very crowded), but let's have installable+buildable packages. There's no reason for a first upload of a package to go into unstable, too -- it needs a rebuild in any case. Nitpick: the short desc shouldn't be capitalized. Having no explicit debian/source/format is deprecated -- please declare the format. Also, while gtk2 and 3 binaries work for me, gtk4 crashes at start: Thread 1 "awf-gtk4" received signal SIGSEGV, Segmentation fault. create_treview (root=0x556a5780) at awf.c:1973 1973if (strcmp (config, "0") == 0) (gdb) bt full #0 create_treview (root=0x556a5780) at awf.c:1973 scrolled_window = 0x559704c0 store = 0x55909960 iter = {stamp = -1097518473, user_data = 0x558cc150, user_data2 = 0x556b7160, user_data3 = 0x0} config = 0x0 view = 0x5593c3c0 renderer = hbox_columns = vbox_column1 = vbox_combo_entry = hbox_spin = hbox_check_radio = vbox_check = vbox_radio = vbox_column2 = vbox_buttons = hbox_btns1 = hbox_btns2 = hbox_btns3 = hbox_btns4 = vbox_column3 = vbox_progressbar1 = vbox_progressbar2 = hbox_progressbar1 = hbox_progressbar2 = vbox_column4 = vbox_others = hbox_label = 0x556a5900 hbox_spinner = 0x556a5a80 vpane = 0x555cb3b0 hpane1 = 0x555cb590 hpane2 = 0x555cb770 hbox_frame1 = 0x556a5c00 hbox_frame2 = 0x556a5d80 hbox_notebook1 = 0x556a5f00 hbox_notebook2 = 0x556d21f0 #1 create_widgets (root=0x556b7760) at awf.c:818 hbox_columns = vbox_column1 = vbox_combo_entry = hbox_spin = hbox_check_radio = vbox_check = vbox_radio = vbox_column2 = vbox_buttons = hbox_btns1 = hbox_btns2 = hbox_btns3 = hbox_btns4 = vbox_column3 = vbox_progressbar1 = vbox_progressbar2 = hbox_progressbar1 = hbox_progressbar2 = vbox_column4 = vbox_others = hbox_label = 0x556a5900 hbox_spinner = 0x556a5a80 vpane = 0x555cb3b0 hpane1 = 0x555cb590 hpane2 = 0x555cb770 hbox_frame1 = 0x556a5c00 hbox_frame2 = 0x556a5d80 hbox_notebook1 = 0x556a5f00 hbox_notebook2 = 0x556d21f0 #2 0x55562e1c in create_window (app=, theme=) at awf.c:734 vbox_window = 0x556b7160 toolbar = 0x556b72e0 widgets = 0x556b7760 gmm = event = #3 0x774450a2 in g_closure_invoke () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #4 0x77457413 in () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #5 0x7745d6cf in g_signal_emit_valist () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #6 0x7745dc3f in g_signal_emit () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #7 0x7756a338 in () at /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 #8 0x7756a4ae in g_application_run () at /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 #9 0x77161d0a in __libc_start_main (main= 0xb060 , argc=1, argv=0x7fffe008, init=, fini=, rtld_fini=, stack_end=0x7fffdff8) at ../csu/libc-start.c:308 result = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, 3035993641122779325, 93824992261632, 0, 0, 0,
Bug#959892: RFS: awf-gtk/2.5.0-1 [ITP] -- A widget factory is a theme preview application for GTK
Okay, so I tried to build all binary packages from one source package. Not sure if it's the good way. It builds those binary packages: awf-gtk2 - A widget factory is a theme preview application for GTK awf-gtk3 - A widget factory is a theme preview application for GTK awf-gtk4 - A widget factory is a theme preview application for GTK To access further information about this package, please visit the following URL: https://mentors.debian.net/package/awf-gtk/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/a/awf-gtk/awf-gtk_2.5.0-1.dsc
Bug#990083: Further testing
Hello, I have done extensive testing and stress tested my setup and was not able to reproduce the bug again. I suggest you close this bug, sorry to have wasted your time. I suspect something wrong happened on my NAS and the client NFS didn't like it and crashed on transitions. And in the steps i took one must have corrected the issue as I can no longer reproduce the problem. I do get crashes sometimes opening menus but that is a whole different issue that I believe is already tracked from looking at the project on GitHub. Thanks On Tue, Jun 29, 2021, 12:13 PM Fabrice Quenneville wrote: > Hi, > > I have shut down my NAS as something strange is happening on it. But since > my NAS is off I have been watching YouTube through the KODI add-on and I > also get some similar crashes. > > I will try to generate meaningful logs in the next few days when I get > some time. > > Thank you > > On Tue, Jun 29, 2021, 12:09 PM Vasyl Gello wrote: > >> Hi Fabrice! >> >> Just curious: can you please use Kodi's built-in functionality to access >> NFS agare, not system mount and see if it helps? >> Maybe create a backup of Kodi profile & try mounting in userspace. >> -- >> Vasyl Gello >> -- >> Certified SolidWorks Expert >> >> Mob.:+380 (98) 465 66 77 >> >> E-Mail: vasek.ge...@gmail.com >> >> Skype: vasek.gello >> -- >> 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다 >> >
Bug#959875: RFS: redmine-plugin-apijs/6.5.0-1 [ITP] -- Redmine plugin to display, gallery from attachments
Hi tobi, I see your answer this morning... The woff fonts are generated with fontello.com (20 glyphs from 2 fonts). I updating the copyright file with font names. Now I will search how include and how to minify CSS and JS files during build time (with uglifyjs and cleancss). Thanks.
Bug#959897: RFS: awf-gtk/2.5.0-1 [ITP] -- A widget factory is a theme preview application for GTK
Hi tobi, Sorry, I haven't see your reply before today. You are right, awf-gtk(2|3|4) are using the same source. Yes, multiple major GTK versions can be coinstalled. I have created three packages because if I create only one source package that depends on libgtk-2|3|4-dev, I think I will get the following error: Missing build dependencies: libgtk-4-dev. So I prefered to create three independant packages. This has been accepted on Fedora and openSUSE (my Ubuntu PPA says also ok). Thanks
Bug#959892: RFS: awf-gtk2/2.5.0-1 [ITP] -- A widget factory is a theme preview application for GTK
Hi tobi, Sorry, I haven't see your reply before today. You are right, awf-gtk(2|3|4) are using the same source. Yes, multiple major GTK versions can be coinstalled. I have created three packages because if I create only one source package that depends on libgtk-2|3|4-dev, I think I will get the following error: Missing build dependencies: libgtk-4-dev. So I prefered to create three independant packages. This has been accepted on Fedora and openSUSE (my Ubuntu PPA says also ok). Thanks
Bug#990083: Further testing
Hi, I have shut down my NAS as something strange is happening on it. But since my NAS is off I have been watching YouTube through the KODI add-on and I also get some similar crashes. I will try to generate meaningful logs in the next few days when I get some time. Thank you On Tue, Jun 29, 2021, 12:09 PM Vasyl Gello wrote: > Hi Fabrice! > > Just curious: can you please use Kodi's built-in functionality to access > NFS agare, not system mount and see if it helps? > Maybe create a backup of Kodi profile & try mounting in userspace. > -- > Vasyl Gello > -- > Certified SolidWorks Expert > > Mob.:+380 (98) 465 66 77 > > E-Mail: vasek.ge...@gmail.com > > Skype: vasek.gello > -- > 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다 >
Bug#990083: Further testing
Hello So I've got my NAS back on and tested, everything is fine there and Kodi crashed again on a transition. I think rebooting the NAS when I suspected it was the source of the Kodi issues is what caused my NAS issues... But just a remount of the subvolumes after an errorless check and some btrfs diagnostics and no errors found... The only thing I could see is a few machines on my network saturating the NAS and simultaneous backups but it's never been an issue before with much more load than now. So I've had two events since: - The first one I was not ready so I only captured a regular log: 2021-06-20-04∶22∶27 PM-kodi.log <https://1drv.ms/u/s!AgvJkue9Pi7ug-rzBoW7lFZCTD9IedU?e=hKFx7v> - Just now, where It froze on a transition and exited userspace bringing the OS back to a gnome login screen. 2021-06-20-19∶30 PM-kodi2.log <https://1drv.ms/u/s!AgvJkue9Pi7ug-rzCVSuEOQueyzCRy8?e=5NN4rC> This time I was waiting for it and had a file explorer ready on the problematic PC and another PC on the same part of my network. While the problematic PC was temporarily frozen so I could not test opening a video on another app, I was able to open one on the other PC with no problem. (I opened a random video as I didn't remember what was next on kodi.) - As soon as I could get the log (sftp was also not responding on the kodi machine) I also tested the problematic video file and there's nothing wrong with the video file that had just crashed userspace. - And when I logged in there was no sound but that video file was working fine. (sorry for the two logs I opened two kodi instances for a few seconds by error.). 2021-06-20-19∶50 PM-kodi.log <https://1drv.ms/u/s!AgvJkue9Pi7ug-rzCo9DqHAn9w7MzDg?e=BevlCP> and 2021-06-20-19∶52 PM-kodi.log <https://1drv.ms/u/s!AgvJkue9Pi7ug-rzCx3EIUOpPHQ_IPY?e=4X7lJY> After a reboot everything is back to normal. Thanks -- *Fabrice Quenneville*
Bug#990105: Invalid icon name in mate-volume-control.desktop
Package: mate-media Version: 1.24.1-1 https://packages.debian.org/bullseye/mate-media There are translations for the "Icon". There is also a comment: "Do NOT translate or transliterate this text" But there is a line translated: "Icon[fr]=multimedia-volume-contrôle" Please remove all translated icons (it's useless no?) Or please fix this line to: "Icon[fr]=multimedia-volume-control" Thanks.
Bug#990083: kodi: Kodi hangs on transitions between playlist items with spinning wheel and no control
Hi Vasyl / maintainers I just got other errors from that NAS so I am starting to run diagnostics but it will take awhile to troubleshoot and it is quite late here. But everything is pointing to my NAS partially failing at the same time as I updated Kodi. I will update as soon as I can / have definitive information. Thanks On Sun, Jun 20, 2021 at 1:31 AM Vasyl Gello wrote: > Hi Fabrice! > > Does the file '/mnt/media/TV Shows (en)/Seinfeld (1989)/Season > 3/Seinfeld.S03E19.The.Limo.720p.WEBrip.AAC.EN-SUB.x264-[MULVAcoded].mkv' > play for you correctly every time you start it not via playlist? > > From the logs I see that VAAPI on Intel integrated video (I suppose it is > an integrated video) starts spewing 'COutput:StateMachine' errors. > > I am going to forward the bug to upstream and ask FernetMenta or ksooo > about that StateMachine state. In my experience, these errors originate > either from buffer jitter or from improperly-encoded mediafile. > -- > Vasyl Gello > -- > -- *Fabrice Quenneville*
Bug#990083: kodi: Kodi hangs on transitions between playlist items with spinning wheel and no control
Hi Vasyl, Here are the crash logs from when I updated a few hours ago and now. Very interesting since I started kodi with debug logs on... it hasn't crashed / froze on transitions yet... Before reporting it had crashed / froze a few times in a row. I am now running it in the background while I work with debug and separate selectors except for NFS which wasn't offered in Kodi settings. My nfs mount is managed by the nfs settings at OS level. Will update in the next few hours once I generate meaningful logs. Fabrice On Sat, Jun 19, 2021 at 4:49 PM Vasyl Gello wrote: > Hi Fabrice! > > Can you please attach the Kodi log with debug settings on? I need at least > FFmpeg, Windowing, cURL, and NFS logs in separare log selectors. > -- > Vasyl Gello > -- *Fabrice Quenneville* ## Kodi CRASH LOG ### SYSTEM INFO Date: Sat 19 Jun 2021 04:20:49 PM EDT Kodi Options: Arch: x86_64 Kernel: Linux 5.10.0-7-amd64 #1 SMP Debian 5.10.40-1 (2021-05-28) Release: Debian GNU/Linux 11 (bullseye) ## END SYSTEM INFO ## ### STACK TRACE # gdb not installed, can't get stack trace. # END STACK TRACE ### # LOG FILE ## 2021-06-19 16:20:49.331 T:6883 INFO : --- 2021-06-19 16:20:49.331 T:6883 INFO : Starting Kodi from Debian (19.1 Debian package version: 2:19.1+dfsg2-1). Platform: Linux x86 64-bit 2021-06-19 16:20:49.331 T:6883 INFO : Using Release Kodi from Debian x64 2021-06-19 16:20:49.331 T:6883 INFO : Kodi from Debian compiled 2021-06-07 by GCC 10.2.1 for Linux x86 64-bit version 5.10.40 (330280) 2021-06-19 16:20:49.331 T:6883 INFO : Running on Debian GNU/Linux 11 (bullseye), kernel: Linux x86 64-bit version 5.10.0-7-amd64 2021-06-19 16:20:49.332 T:6883 INFO : FFmpeg version/source: 4.3.2-0+deb11u2 2021-06-19 16:20:49.332 T:6883 INFO : Host CPU: Intel(R) Atom(TM) x5-Z8350 CPU @ 1.44GHz, 4 cores available 2021-06-19 16:20:49.332 T:6883 INFO : special://xbmc/ is mapped to: /usr/share/kodi 2021-06-19 16:20:49.332 T:6883 INFO : special://xbmcbin/ is mapped to: /usr/lib/x86_64-linux-gnu/kodi 2021-06-19 16:20:49.332 T:6883 INFO : special://xbmcbinaddons/ is mapped to: /usr/lib/x86_64-linux-gnu/kodi/addons 2021-06-19 16:20:49.332 T:6883 INFO : special://masterprofile/ is mapped to: /home/fabrice/.kodi/userdata 2021-06-19 16:20:49.332 T:6883 INFO : special://envhome/ is mapped to: /home/fabrice 2021-06-19 16:20:49.332 T:6883 INFO : special://home/ is mapped to: /home/fabrice/.kodi 2021-06-19 16:20:49.332 T:6883 INFO : special://temp/ is mapped to: /home/fabrice/.kodi/temp 2021-06-19 16:20:49.332 T:6883 INFO : special://logpath/ is mapped to: /home/fabrice/.kodi/temp 2021-06-19 16:20:49.332 T:6883 INFO : The executable running is: /usr/lib/x86_64-linux-gnu/kodi/kodi.bin 2021-06-19 16:20:49.332 T:6883 INFO : Local hostname: debtv.dirtynet.ca 2021-06-19 16:20:49.332 T:6883 INFO : Log File is located: /home/fabrice/.kodi/temp/kodi.log 2021-06-19 16:20:49.332 T:6883 INFO : --- 2021-06-19 16:20:49.337 T:6883 INFO : loading settings 2021-06-19 16:20:49.346 T:6883 INFO : special://profile/ is mapped to: special://masterprofile/ 2021-06-19 16:20:49.446 T:6979DEBUG : Sink changed 2021-06-19 16:20:49.446 T:6979DEBUG : Sink appeared ### END LOG FILE END Kodi CRASH LOG # ## Kodi CRASH LOG ### SYSTEM INFO Date: Sat 19 Jun 2021 04:38:55 PM EDT Kodi Options: Arch: x86_64 Kernel: Linux 5.10.0-7-amd64 #1 SMP Debian 5.10.40-1 (2021-05-28) Release: Debian GNU/Linux 11 (bullseye) ## END SYSTEM INFO ## ### STACK TRACE # gdb not installed, can't get stack trace. # END STACK TRACE ### # LOG FILE ## 2021-06-19 16:35:00.821 T:7580 INFO : --- 2021-06-19 16:35:00.821 T:7580 INFO : Starting Kodi from Debian (19.1 Debian package version: 2:19.1+dfsg2-1). Platform: Linux x86 64-bit 2021-06-19 16:35:00.821 T:7580 INFO : Using Release Kodi from Debian x64 2021-06-19 16:35:00.821 T:7580 INFO : Kodi from Debian compiled 2021-06-07 by GCC 10.2.1 for Linux x86 64-bit version 5.10.40 (330280) 2021-06-19 16:35:00.821 T:7580 INFO : Running on Debian GNU/Linux 11 (bullseye), kernel: Linux x86 64-bit version 5.10.0-7-amd64 2021-06-19 16:35:00.821 T:7580 INFO : FFmpeg version/source: 4.3.2-0+deb11u2 2021-06-19 16:35:00.821 T:7580 INFO : Host CPU: Intel(R) Atom(TM) x5-Z8350 CPU @ 1.44GHz, 4 cores availabl
Bug#990083: kodi: Kodi hangs on transitions between playlist items with spinning wheel and no control
Package: kodi Version: 2:19.1+dfsg2-1 Severity: important X-Debbugs-Cc: fabquennevi...@gmail.com Dear Maintainer, * What led up to the situation? Updated to version 2:19.1+dfsg2-1 and now kodi hangs with a spinning wheel after every playlist video, also starting any video is now slower to start since update * What exactly did you do (or not do) that was effective (or ineffective)? pkill kodi does nothing pkill -9 kodi works controls within kodi dont work while wheen is spinning indefinetely After waiting a while it goes to main menu, freezes and sometimes after a while kill gnome and return me to gnome login * What was the outcome of this action? If I kill kodi manualy I can just reopen it and play any video * What outcome did you expect instead? The next video playing Other info: My kodi starts on boot My videos are all on system mounted NFS share and the network / shares work while kodi goes awire I have the Extras, Youtube, WatchedList and BingBackground add-ons installed -- System Information: Debian Release: 11.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kodi depends on: ii kodi-bin 2:19.1+dfsg2-1 ii kodi-data 2:19.1+dfsg2-1 Versions of packages kodi recommends: ii kodi-repository-kodi [kodi-repository] 2:19.1+dfsg2-1 ii kodi-visualization-spectrum 3.4.0+ds1-2 kodi suggests no packages. -- no debconf information
Bug#989486: RFS: python-click-log/0.3.2-1 -- Logging integration for Click - Python 3.x
Nilesh Patra writes: > * The pristine tar contained .tar.gz.*, it should > instead contain .orig.tar.gz for origtargz both for the sake of > consistency and for origtargz to run fine Oops, OK, I have just re-run pristine-tar on the .orig file and committed. > * We are in freeze time, and a new version upload unless absolutely > necessary isn't appropriate[2]. This package does not seem to have any > (RC) bug or affecting any package that a version bump would be > desired. > > Hence, this should be uploaded after bullseye release. Feel free to > ping me then, and I'll happily sponsor. Also, please take a look at my > commits in salsa. > > [2]: https://release.debian.org/testing/freeze_policy.html I'm fine with waiting. After the freeze, I think it will be ready for uploading (I don't want to spam mentors.d.o during the freeze). Thanks a lot for your help! Best regards -- Fabrice Bauzac-Stehly PGP 01EEACF8244E9C14B551C5256ADA5F189BD322B6
Bug#989581:
Tags: patch I humbly propose this change: >From 4de312af857234e20b5e01b5b2fa61fa50496995 Mon Sep 17 00:00:00 2001 From: Fabrice Bauzac Date: Tue, 8 Jun 2021 00:00:38 +0200 Subject: [PATCH] autopkgtest: mark ADTTMP as obsolete, replaced with AUTOPKGTEST_TMP Closes: #989581. --- autopkgtest.md | 19 ++- debian/changelog | 4 2 files changed, 14 insertions(+), 9 deletions(-) diff --git a/autopkgtest.md b/autopkgtest.md index c984a23..1480ba7 100644 --- a/autopkgtest.md +++ b/autopkgtest.md @@ -30,10 +30,11 @@ If the file to be executed has no execute bits set, `chmod a+x` is applied to it (this means that tests can be added in patches without the need for additional chmod; contrast this with debian/rules). -During execution of the test, the environment variable `$ADTTMP` will +During execution of the test, the environment variable +`$AUTOPKGTEST_TMP` (previously named `$ADTTMP`, now obsolete) will point to a directory for the execution of this particular test, which -starts empty and will be deleted afterwards (so there is no need for the -test to clean up files left there). +starts empty and will be deleted afterwards (so there is no need for +the test to clean up files left there). If tests want to create artifacts which are useful to attach to test results, such as additional log files or screenshots, they can put them @@ -166,13 +167,13 @@ Defined restrictions running the tests. However, the tests are *not* entitled to assume that the source package's build dependencies will be installed when the test is run. - Please use this considerately, as for large builds it unnecessarily builds - the entire project when you only need a tiny subset (like the tests/ + Please use this considerately, as for large builds it unnecessarily builds the + entire project when you only need a tiny subset (like the tests/ subdirectory). It is often possible to run `make -C tests` instead, or copy - the test code to `$ADTTMP` and build it there with some custom commands. This - cuts down the load on the Continuous Integration servers and also makes tests - more robust as it prevents accidentally running them against the built source - tree instead of the installed packages. + the test code to `$AUTOPKGTEST_TMP` and build it there with some custom + commands. This cuts down the load on the Continuous Integration servers and + also makes tests more robust as it prevents accidentally running them against + the built source tree instead of the installed packages. - **allow-stderr** diff --git a/debian/changelog b/debian/changelog index c4cc189..426a931 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,9 +1,13 @@ debian-policy (4.5.1.1) UNRELEASED; urgency=medium + [ Sean Whitton ] * 4.4: Fix changelog format: needs an extra space before sign-off (Closes: #976301). Thanks to Anatoli Babenia for reporting the problem. + [ Fabrice Bauzac-Stehly ] + * autopkgtest: mark ADTTMP as obsolete, replaced with AUTOPKGTEST_TMP. +Closes: #989581. -- Sean Whitton Tue, 19 Jan 2021 13:47:45 -0700 -- 2.30.2
Bug#989581: autopkgtest: ADTTMP is now obsolete
Package: debian-policy Version: 4.5.1.0 Severity: normal Hello, autopkgtest.md only mentions the ADTTMP environment variable, while lintian marks ADTTMP usage as deprecated in favour of AUTOPKGTEST_TMP. See https://lintian.debian.org/tags/uses-deprecated-adttmp I think autopkgtest.md should at least mention the new variable... Thanks! -- System Information: Debian Release: 11.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-7-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled debian-policy depends on no packages. Versions of packages debian-policy recommends: ii libjs-sphinxdoc 3.4.3-2 Versions of packages debian-policy suggests: ii doc-base 0.11.1 -- no debconf information
Bug#989486: RFS: python-click-log/0.3.2-1 -- Logging integration for Click - Python 3.x
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "python-click-log": * Package name: python-click-log Version : 0.3.2-1 Upstream Author : [fill in name and email of upstream] * URL : https://github.com/click-contrib/click-log * License : Expat * Vcs : https://salsa.debian.org/python-team/packages/python-click-log Section : python It builds those binary packages: python3-click-log - Logging integration for Click - Python 3.x To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-click-log/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-click-log/python-click-log_0.3.2-1.dsc Changes since the last upload: python-click-log (0.3.2-1) unstable; urgency=medium . [ Debian Janitor ] * Bump debhelper from old 10 to 12. * Set upstream metadata fields: Bug-Database, Repository, Repository- Browse. * Remove constraints unnecessary since stretch: + Build-Depends: Drop versioned constraint on dh-python. . [ Ondřej Nový ] * d/control: Update Maintainer field with new Debian Python Team contact address. * d/control: Update Vcs-* fields with new Debian Python Team Salsa layout. . [ Fabrice Bauzac-Stehly ] * New upstream release. * Upgrade d/watch to version 4. * Upgrade the Standards-Version to 4.5.1. * Declare Rules-Requires-Root: no. Best regards -- Fabrice Bauzac-Stehly PGP 01EEACF8244E9C14B551C5256ADA5F189BD322B6
Bug#987264: git-el: fails to install with xemacs21
For what it's worth, here's a patch for git-el to have the directory created, after Agustin's suggestion. diff -Naur git-2.30.2/debian/git-el.dirs git_2.30.2-1.1/debian/git-el.dirs --- git-2.30.2/debian/git-el.dirs 1970-01-01 01:00:00.0 +0100 +++ git_2.30.2-1.1/debian/git-el.dirs 2021-05-22 23:52:16.409330369 +0200 @@ -0,0 +1 @@ +usr/share/emacs/site-lisp
Bug#793675: hplip-gui: No system tray detected
Hello, "Richard B. Kreckel" writes: > Running version 3.21.2+dfsg1-2 of package hplip-gui, the annoying > message still pops up after each login. Version 3.21.2+dfsg1-2 does not contain the change to /etc/xdg/autostart/hplip-systray.desktop, so I expect that you get the annoying message. The fixed version is 3.21.2+dfsg1-2+exp0. > I have checked that /etc/xdg/autostart/hplip-systray.desktop indeed > contains the line saying NoShowIn=GNOME; Have you modified it manually? > It does not seem to suppress the popup. There is no other > "hplip-systray.desktop". I wonder if anybody has tried if this works? > If so, please speak up. I use GNOME and I can confirm that the fix works for me: 3.21.2+dfsg1-2 shows the popup, 3.21.2+dfsg1-2+exp0 does not. The change only fixes GNOME users; if you use a different desktop environment, it will do nothing for you. Do you use GNOME? Cinnamon? Any other derivatives? KDE?... Thanks. Best regards -- Fabrice Bauzac-Stehly PGP 01EEACF8244E9C14B551C5256ADA5F189BD322B6 old PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D
Bug#973445: ITP: human-theme-gtk -- Human theme for GTK
Updated to 1.3.0-1.
Bug#973447: ITP: python3-radexreader -- Python library for the RADEX RD1212 and ONE Geiger counters
Updated to 1.2.0-1.
Bug#959436: ITP: awf-gtk3 -- A widget factory is a theme preview application for GTK
Updated to 2.4.0-1.
Bug#959434: ITP: awf-gtk2 -- A widget factory is a theme preview application for GTK
Updated to 2.4.0-1.
Bug#959433: ITP: awf-gtk4 -- A widget factory is a theme preview application for GTK
Updated to 2.4.0-1.
Bug#959434: ITP: awf-gtk2 -- A widget factory is a theme preview application
Updated to 2.3.0-1.
Bug#973445: ITP: human-theme-gtk -- Human theme for GTK
Updated to 1.2.0-1.
Bug#959436: ITP: awf-gtk3 -- A widget factory is a theme preview application
Updated to 2.3.0-1.
Bug#959433: ITP: awf-gtk4 -- A widget factory is a theme preview application
Updated to 2.3.0-1.
Bug#793675: hplip-gui: No system tray detected
This affects a number of operating system packages of hplip. See this upstream bug: https://bugs.launchpad.net/hplip/+bug/1714659 Concerning the idea of forcing a dependency on sni-qt, it looks like this package does not exist (anymore?). Concerning the need to add a "sleep" before starting hp-systray, this is not useful anymore as the program now does this sleep (for up to 60 seconds), waiting for a system tray to be available. About the idea of installing gnome-shell-extension-top-icons-plus, I can confirm that it does not solve the issue for my GNOME environment. To summarize, hplip provides several tools, among which there is hp-systray which handles a system tray functionality. However, system trays are now replaced with "Notifications" in GNOME, and the system tray functionality is simply absent nowadays in GNOME. The message from GNOME is that applications should stop relying on this (old) way of doing things. I'm not sure what functionality the hp-systray provides, but if it makes sense the hplip team would have to create a new tool based on "Notifications" that would provide the same functionality. I doubt we can remove hp-systray; it may be useful for users of desktop environments other than GNOME that still have a system tray. To fix this issue which, as far as I know, only hit GNOME users, I suggest to add this line to /etc/xdg/autostart/hplip-systray.desktop: NotShowIn=GNOME; So that the issue stops annoying GNOME users. -- Fabrice Bauzac-Stehly PGP 01EEACF8244E9C14B551C5256ADA5F189BD322B6 old PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D
Bug#959892: awf-gtk3/2.2.0-5 [ITP] -- A widget factory is a theme preview application for GTK
The current version (2.2.0) was added to Fedora 32/33/34/35. I working on the next release (2.3.0). I still needs a sponsor :)
Bug#959897: RFS awf-gtk2/2.2.0-5 [ITP] -- A widget factory is a theme preview, application for GTK
The current version (2.2.0) was added to Fedora 32/33/34/35. I working on the next release (2.3.0). I still needs a sponsor :)
Bug#985449: python2 virtualenv pip install: can't find '__main__' module in .../pep517/_in_process.py
Package: python3-virtualenv Version: 20.4.0+ds-1 Hello, Installing a PEP-517-compliant package within a Python2 virtualenv fails on bullseye. On buster, it works. With Python3, it works. I'm not sure whether this bug comes from python3-virtualenv or python or something else... Assigning to python3-virtualenv for starting the investigation. The error message is: Processing /tmp/test Installing build dependencies ... done Getting requirements to build wheel ... error ERROR: Command errored out with exit status 1: command: /tmp/tmp.OUKYNjB68J/bin/python /usr/share/python-wheels/pep517-0.9.1-py2.py3-none-any.whl/pep517/_in_process.py get_requires_for_build_wheel /tmp/tmpctQDX6 cwd: /tmp/pip-req-build-mhIcBE Complete output (1 lines): /tmp/tmp.OUKYNjB68J/bin/python: can't find '__main__' module in '/usr/share/python-wheels/pep517-0.9.1-py2.py3-none-any.whl/pep517/_in_process.py' ERROR: Command errored out with exit status 1: /tmp/tmp.OUKYNjB68J/bin/python /usr/share/python-wheels/pep517-0.9.1-py2.py3-none-any.whl/pep517/_in_process.py get_requires_for_build_wheel /tmp/tmpctQDX6 Check the logs for full command output. See the attached tarball for reproducing the issue. test.tar.gz Description: Tarball to reproduce the issue -- Fabrice Bauzac-Stehly PGP 01EEACF8244E9C14B551C5256ADA5F189BD322B6 old PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D
Bug#985236: RFS: python-mockito/1.2.2-1 [ITP] -- Spying framework for Python
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "python-mockito": * Package name: python-mockito Version : 1.2.2-1 Upstream Author : https://github.com/kaste/mockito-python/issues * URL : https://github.com/kaste/mockito-python * License : Expat * Vcs : https://salsa.debian.org/python-team/packages/python-mockito Section : python It builds these binary packages: python3-mockito - Spying framework for Python python-mockito-doc - Spying framework for Python - documentation To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-mockito/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-mockito/python-mockito_1.2.2-1.dsc Changes since the last upload: python-mockito (1.2.2-1) unstable; urgency=low . * Initial release. Closes: #981067 Thanks! Best regards -- Fabrice Bauzac-Stehly PGP 01EEACF8244E9C14B551C5256ADA5F189BD322B6 old PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D
Bug#983705: RFS: python-mockito/1.2.2-1 [ITP] -- Spying framework for Python - documentation
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "python-mockito": * Package name: python-mockito Version : 1.2.2-1 Upstream Author : https://github.com/kaste/mockito-python/issues * URL : https://github.com/kaste/mockito-python * License : Expat * Vcs : https://salsa.debian.org/python-team/packages/python-mockito Section : python It builds those binary packages: python-mockito-doc - Spying framework for Python - documentation python3-mockito - Spying framework for Python To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-mockito/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-mockito/python-mockito_1.2.2-1.dsc Changes since the last upload: python-mockito (1.2.2-1) unstable; urgency=low . * Initial release. Closes: #981067 Best regards -- Fabrice Bauzac-Stehly PGP 01EEACF8244E9C14B551C5256ADA5F189BD322B6 old PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D
Bug#921017: wireguard: doesn't always set all allowed-ips
Dear maintainer, I tried to set up a wireguard connection on wg0 interface using NetworkManager for testing purpose and then forgot about that. Let's say I used 192.168.16.233/32 ip and several routes (ex 10.0.3.0/24 10.0.5.0/24). Then, using wg-quick, I set up a connection on wg0 with different settings, let's say 192.168.26.3/32 ip and the same route (10.0.3.0/24 10.0.5.0/24) I run into similar issues. wg0 appeared with both 192.168.16.233/32 and 192.168.26.3/32 addresses and routes where randomly applying (most of the time it wouldn't work). Fixed my issue removing the NetworkManager config, maybe NetworkManager also does not handle correctly wireguard connection yet. Anyway it was clearly a mess but maybe this may help someone else. Thanks for maintaining this package, Fabrice On Mon, 09 Sep 2019 18:56:33 -0400 Daniel Kahn Gillmor wrote: > Control: retitle 921017 wireguard: wg setconf doesn't always set all allowed-ips > Control: reassign 921017 wireguard-tools > > Hi Piotr-- > > On Mon 2019-09-09 12:40:30 +0200, Piotr Ożarowski wrote: > > yes, I can still replicate it with 0.0.20190905-1 but I do it on stable > > (first Stretch now Buster) with packages from unstable (without > > rebuilding them). Every time different peer (I have 11 of them) gets a > > non complete AllowedIPs so I admit it's hard to reproduce… > > Thanks for testing again so promptly, and sorry for the delay on my > side. > > This is a delicate situation because i want to try to reproduce the > problem you're seeing but i don't want to leak any secret information > from your system (or any of your peers' public metadata either, unless > you're ok with that). > > If i can try to restate the problem, it sounds like "wg setconf" is not > reliably setting all the allowed-ips from a complex configuration file. > > But "wg set" itself always works fine to adjust it, right? That makes > it sound like a problem with the "wg setconf" subcommand itself. > > So can you help me figure out how i can replicate the problem without > leaking your secret information? For example, can you supply a > templated configuration file that fails sometimes (but with relevant > secrets and sensitive public metadata redacted)? For example, is this > something you can replicate intermittently by running the configuration > steps in a tight loop, and testing for the failure after each time? > > I've tried to do that briefly with some simple tests, but i still can't > seem to get it to happen, even from a debian buster installation (with > wireguard-dkms and wireguard-tools installed from unstable directly). > > > PS I have another problem that I didn't report yet on one (and only one) > > of my peers which I don't think is related, but in case it is: > > from time to time (sometimes few days apart sometimes weeks) > > wireguard freezes (as in it doesn't accept any in/out connections). > > Restarting (ip l set dev wg0 down and up again) doesn't help. What > > helps is to change listening port to something else. This peer has a > > non-public and dynamic IP (but I have another client using the same > > provider on my OpenWRT router and it seems to work fine there) > > hm, this is likely to be a different thing, so if you want to discuss > it, please open it as a separate ticket. > > --dkg --
Bug#981067: ITP: python-mockito -- Spying framework for Python
Package: wnpp Owner: Fabrice BAUZAC-STEHLY Severity: wishlist * Package name: python-mockito Version : 1.2.2 Upstream Author : Szczepan Faber, Serhiy Oplakanets, Herr Kaste, Justin Hopper * URL or Web page : https://github.com/kaste/mockito-python * License : Expat Description : Spying framework for Python -- Fabrice Bauzac-Stehly PGP 01EEACF8244E9C14B551C5256ADA5F189BD322B6 old PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D
Bug#971289: beaker: Switch to python3-pycryptodome
I think there are several issues: The first issue is the mere presence of tests. The source package has code to run the upstream tests (via "nose"); that is precisely one of the reasons for the Build-Depends on python3-crypto. However, these tests are not run (anymore) because upstream now strips the "tests/" subdirectory from their PyPI tarball. We should instead use the github tarball, which contains the tests: see merge request [1]. The alternative would be to give up trying to run tests, in which case we could already remove the test dependencies including the one on python3-crypto, fixing this bug. But it is preferable to continue running the tests and ensure the quality of the package. Then, to fix the current bug, we should migrate to python3-pycryptodome instead of using python3-crypto. Here is some context and information: The http://www.pycryptodome.org/ project is a fork of venerable PyCrypto (which provides "import Crypto"). pycryptodome.org provides two PyPI packages: cryptodome and cryptodomex. - cryptodome is a drop-in replacement for PyCrypto: it also provides "import Crypto". However, this also means that it cannot be installed at the same time as PyCrypto. - cryptodomex is a "clean" alternative to PyCrypto: it provides the same features but as "import Cryptodome", so it can be installed side-by-side with PyCrypto. The beaker upstream uses cryptodome, but there is no Debian package for that. There is only Debian package python3-pycryptodome, which provides cryptodomex. So there is some work involved to make a patch so that beaker switches to using "import Cryptodome" instead of "import Crypto". I propose this merge request [2]. [1] https://salsa.debian.org/python-team/packages/beaker/-/merge_requests/1 [2] https://salsa.debian.org/python-team/packages/beaker/-/merge_requests/2
Bug#972216: nmap: New NPSL 0.92 license likely non-free
FYI there is also a thread "nmap is non-free software" in: https://lists.defectivebydesign.org/archive/html/directory-discuss/2021-01/threads.html Apparently [1] the nmap author is listening to complaints and will change license terms: [...] I understand how the current license wording could give that interpretation, but it's not what we meant. Instead of mentioning the "software" of "proprietary software companies", it should probably mention the "proprietary software" of "software companies". Because as you noted, a "proprietary software company" might still make some free software too. And maybe a "free software company" could still have some non-free products. I'll try to fix this before the next Nmap release. [1] https://lists.defectivebydesign.org/archive/html/directory-discuss/2021-01/msg00012.html
Bug#972216: nmap: New NPSL 0.92 license likely non-free
FWIW, Fedora has just ruled out nmap: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/thread/GZIDC4DHXZP67LFU7P2OT2AQVDJRHZ2M/
Bug#979000: libasound2: [Raven/Raven2/FireFlight/Renoir AMD Ryzen] No Sound at all
Control: tags -1 - newcomer I think the "newcomer" tag has been added by mistake. Feel free to correct me if I'm wrong.
Bug#978484: gnu-standards: Should be marked Multi-Arch: foreign
Package: gnu-standards Version: 2010.03.11-1.1 Severity: minor Tags: patch Dear Maintainer, The tracker [1] reveals that the package should be marked Multi-Arch: foreign. [1] https://tracker.debian.org/pkg/gnu-standards Here is a patch to fix it: diff --git a/debian/control b/debian/control index 1b75648..c6539ba 100644 --- a/debian/control +++ b/debian/control @@ -11,6 +11,7 @@ Vcs-Browser: https://salsa.debian.org/debian/gnu-standards Package: gnu-standards Architecture: all +Multi-Arch: foreign Depends: ${misc:Depends} Description: GNU coding and package maintenance standards This package contains two pieces of documentation from the GNU Thanks! -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-4-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information
Bug#741151: gnu-standards: please update to 2013-12-17 version
Control: retitle -1 gnu-standards: please update from upstream Control: severity -1 normal This package is now over 10 years late compared to upstream, this is getting quite annoying, especially as the popcon is not ridiculous. Do you need help? -- Fabrice Bauzac-Stehly PGP 01EEACF8244E9C14B551C5256ADA5F189BD322B6 old PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D
Bug#965564: gnu-standards: Removal of obsolete debhelper compat 5 and 6 in bookworm
I confirm that debian/compat is currently 5.
Bug#959875: RFS: redmine-plugin-apijs/6.5.0-1 [ITP] -- Redmine plugin to display, gallery from attachments
I uploaded a new package release (6.5.0-1).
Bug#974217: RFS: python-radexreader/1.0.0-5 [ITP] -- Reader for the RADEX RD1212 Geiger counter
I uploaded a new package release (1.0.0-5). I fixed lintian errors and I updated debian directory in source repository.
Bug#974209: RFS: human-theme-gtk/1.1.0-5 [ITP] -- Human theme for GTK
I uploaded a new package release (1.1.0-5). I fixed lintian errors and I updated debian directories in source repository.
Bug#959897: RFS awf-gtk2_2.2.0-5 [ITP] -- A widget factory is a theme preview application for GTK
I uploaded a new package release (2.2.0-5). I fixed lintian errors and I updated debian directories in source repository.
Bug#959892: RFS: awf-gtk3/2.2.0-5 [ITP] -- A widget factory is a theme preview application for GTK
I uploaded a new package release (2.2.0-5). I fixed lintian errors and I updated debian directories in source repository.
Bug#959875: RFS: redmine-plugin-apijs/6.4.0-5 [ITP] -- Redmine plugin to display gallery from attachments
I uploaded a new package release (6.4.0-5). I fixed lintian errors and I updated debian directory in source repository. There is one lintian error (at line 13), I will fix for the next release (6.5).
Bug#975465: RFS: python-opentracing/2.4.0-1 -- opentracing interface for Python - documentation
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "python-opentracing": * Package name: python-opentracing Version : 2.4.0-1 Upstream Author : opentrac...@googlegroups.com * URL : https://github.com/opentracing/opentracing-python * License : Apache-2.0, Expat * Vcs : https://salsa.debian.org/python-team/packages/python-opentracing Section : python It builds those binary packages: python-opentracing-doc - opentracing interface for Python - documentation python3-opentracing - opentracing interface for Python To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-opentracing/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-opentracing/python-opentracing_2.4.0-1.dsc Changes since the last upload: python-opentracing (2.4.0-1) unstable; urgency=medium . [ Ondřej Nový ] * d/control: Update Maintainer field with new Debian Python Team contact address. * d/control: Update Vcs-* fields with new Debian Python Team Salsa layout. . [ Fabrice BAUZAC ] * Switch to debhelper 13. * New upstream version 2.4.0. * Disable the tests of the gevent scope manager until #974051 is fixed. Best regards -- Fabrice BAUZAC-STEHLY PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D
Bug#974217: RFS: python3-radexreader/1.0.0-2 [ITP] -- Reader for the RADEX RD1212 Geiger counter (Python module)
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "python3-radexreader": * Package name: python3-radexreader Version : 1.0.0-2 Upstream Author : Fabrice Creuzot * URL : https://github.com/luigifab/python-radexreader * License : GPL-2+ * Vcs : https://github.com/luigifab/python-radexreader Section : python It builds those binary packages: radexreader - Reader for the RADEX RD1212 Geiger counter (CLI) python3-radexreader - Reader for the RADEX RD1212 Geiger counter (Python module) Changes for the initial release: python3-radexreader (1.0.0-2) unstable; urgency=low . * Initial debian package release (Closes: #973447) Check https://mentors.debian.net/package/python3-radexreader/ and https://mentors.debian.net/debian/pool/main/p/python3-radexreader/python3-radexreader_1.0.0-2.dsc Why 1.0.0-2? because I'm stupid, I not fully read the control file of python3-scour and scour packages. For this release, I created RPM package (https://bugzilla.redhat.com/show_bug.cgi?id=1896742) and PPA repository (https://launchpad.net/~luigifab/+archive/ubuntu/packages/+packages). Thanks.
Bug#974209: RFS: human-theme-gtk/1.1.0-1 [ITP] -- Human theme for GTK
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "human-theme-gtk": * Package name: human-theme-gtk Version : 1.1.0-1 Upstream Author : Fabrice Creuzot * URL : https://github.com/luigifab/human-theme * License : CC-BY-SA-3.0+, GPL-3+, LGPL-2.1+ * Vcs : https://github.com/luigifab/human-theme Section : x11 It builds those binary packages: human-theme-gtk - Human theme for GTK Changes for the initial release: human-theme-gtk (1.1.0-1) unstable; urgency=low . * Initial debian package release (Closes: #973445) Check https://mentors.debian.net/package/human-theme-gtk/ and https://mentors.debian.net/debian/pool/main/h/human-theme-gtk/human-theme-gtk_1.1.0-1.dsc For this release, I created RPM package (https://bugzilla.redhat.com/show_bug.cgi?id=1893327) and PPA repository (https://launchpad.net/~luigifab/+archive/ubuntu/packages/+packages). Thanks.
Bug#959897: Acknowledgement (RFS: awf-gtk2/2.2.0-1 [ITP] -- A widget factory is a theme preview application for GTK)
Hi, I uploaded a new release. * Package name: awf-gtk2 Version : 2.2.0-1 Upstream Author : Fabrice Creuzot * URL : https://github.com/luigifab/awf-extended * License : GPL-3+ * Vcs : https://github.com/luigifab/awf-extended Section : x11 Check https://mentors.debian.net/package/awf-gtk2/ and https://mentors.debian.net/debian/pool/main/a/awf-gtk2/awf-gtk2_2.2.0-1.dsc I kept "A widget factory" as name because I'm not sure if I must rename it to "A Widget Factory" or not. For this release, I created RPM package (https://bugzilla.redhat.com/show_bug.cgi?id=1893321) and PPA repository (https://launchpad.net/~luigifab/+archive/ubuntu/packages/+packages). Thanks.
Bug#959892: Acknowledgement (RFS: awf-gtk3/2.2.0-1 [ITP] -- A widget factory is a theme preview application for GTK)
Hi, I uploaded a new release. * Package name: awf-gtk3 Version : 2.2.0-1 Upstream Author : Fabrice Creuzot * URL : https://github.com/luigifab/awf-extended * License : GPL-3+ * Vcs : https://github.com/luigifab/awf-extended Section : x11 Check https://mentors.debian.net/package/awf-gtk3/ and https://mentors.debian.net/debian/pool/main/a/awf-gtk3/awf-gtk3_2.2.0-1.dsc I kept "A widget factory" as name because I'm not sure if I must rename it to "A Widget Factory" or not. For this release, I created RPM package (https://bugzilla.redhat.com/show_bug.cgi?id=1893323) and PPA repository (https://launchpad.net/~luigifab/+archive/ubuntu/packages/+packages). Thanks.
Bug#974051: Checking for upstream fixed for #974051
check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '(cd "/home/noon/git/python-gevent-20.9.0/deps/c-ares" && if [ -r ares_build.h ]; then cp ares_build.h ares_build.h.orig; fi && sh ./configure --disable-dependency-tracking -C CFLAGS="-Wno-unused-result -Wsign-compare -g -Og -Wall -g -Og -fstack-protector-strong -Wformat -Werror=format-security -g -Og -fstack-protector-strong -Wformat -Werror=format-security -g -O2 -fdebug-prefix-map=/home/noon/git/python-gevent-20.9.0=. -fstack-protector-strong -Wformat -Werror=format-security" && cp ares_config.h ares_build.h "$OLDPWD" && cat ares_build.h && if [ -r ares_build.h.orig ]; then mv ares_build.h.orig ares_build.h; fi) > configure-output.txt' returned non-zero exit status 1. E: pybuild pybuild:353: build: plugin distutils failed with: exit code=1: /usr/bin/python3-dbg setup.py build dh_auto_build: error: pybuild --build -i python{version}-dbg -p "3.9 3.8" returned exit code 13 make[1]: *** [debian/rules:15: override_dh_auto_build] Error 13 Thanks! Best regards -- Fabrice BAUZAC-STEHLY PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D
Bug#973162: Cannot reproduce the 8 failures
I can reproduce the SEGV, but not the 8 failures. Was it transient?
Bug#973162: Info received (python-opentracing: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.9 3.8" returned exit code 13)
I have investigated the SEGV issue and it is not specific to python-opentracing. I have created a specific bugreport for it: 974051 https://bugs.debian.org/cgi-bin/bugreport.cgi?archive=yes&bug=974051 -- Fabrice BAUZAC-STEHLY PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D
Bug#974051: python3-gevent: gevent.spawn(thunk).get() SEGV
Package: python3-gevent Version: 1.4.0-1.2+b1 Severity: important Dear Maintainer, While investigating the FTBFS issue #973162, I have reduced the SEGV problem to this short file: import gevent def thunk(): return True gevent.spawn(thunk).get() It causes a segmentation fault with either Python 3.8 or 3.9: noon@asus:~/git/python-opentracing$ python3.9 test_gevent.py :228: RuntimeWarning: greenlet.greenlet size changed, may indicate binary incompatibility. Expected 144 from C header, got 152 from PyObject :228: RuntimeWarning: greenlet.greenlet size changed, may indicate binary incompatibility. Expected 144 from C header, got 152 from PyObject :228: RuntimeWarning: greenlet.greenlet size changed, may indicate binary incompatibility. Expected 144 from C header, got 152 from PyObject :228: RuntimeWarning: greenlet.greenlet size changed, may indicate binary incompatibility. Expected 144 from C header, got 152 from PyObject Segmentation fault I think gevent.spawn() is an essential part of python3-gevent, though I'm not so sure; therefore, I'm marking this issue as "important". Thanks! -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-gevent depends on: ii libc6 2.31-4 ii python3 3.8.2-3 ii python3-greenlet 0.4.17-1 python3-gevent recommends no packages. Versions of packages python3-gevent suggests: pn python-gevent-doc pn python3-gevent-dbg pn python3-openssl -- no debconf information import gevent def thunk(): return True gevent.spawn(thunk).get()
Bug#973162: python-opentracing: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.9 3.8" returned exit code 13
Tags: confirmed dh_auto_test -O--buildsystem=pybuild I: pybuild base:232: cd /build/python-opentracing-2.3.0/.pybuild/cpython3_3.9_opentracing/build; python3.9 -m pytest tests = test session starts == platform linux -- Python 3.9.0+, pytest-4.6.11, py-1.9.0, pluggy-0.13.0 rootdir: /build/python-opentracing-2.3.0 collected 122 items tests/mocktracer/test_tracer.py .. [ 65%] tests/scope_managers/test_asyncio.py . [ 72%] tests/scope_managers/test_contextvars.py . [ 80%] tests/scope_managers/test_gevent.py Segmentation fault E: pybuild pybuild:353: test: plugin distutils failed with: exit code=139: cd /build/python-opentracing-2.3.0/.pybuild/cpython3_3.9_opentracing/build; python3.9 -m pytest tests I can see two issues to fix: - The 8 test failures in test_asyncio.py - The segmentation fault in test_gevent.py -- Fabrice BAUZAC-STEHLY PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D
Bug#959875: Acknowledgement (RFS: redmine-plugin-apijs/6.4.0-1 [ITP] -- Redmine plugin to display gallery from attachments)
Hi, I uploaded a new release (okay with a litle error with the watch file). * Package name: redmine-plugin-apijs Version : 6.4.0-1 Upstream Author : Fabrice Creuzot * URL : https://github.com/luigifab/redmine-apijs * License : GPL-2+ * Vcs : https://github.com/luigifab/redmine-apijs Section : web Check https://mentors.debian.net/package/redmine-plugin-apijs/ dget -x https://mentors.debian.net/debian/pool/main/r/redmine-plugin-apijs/redmine-plugin-apijs_6.4.0-1.dsc Thanks.
Bug#968971: gitlab: Can't create new project: undefined method `set_attribute_was' for #
Package: gitlab Version: 13.2.6-1+fto10+1 Severity: important Tags: upstream Dear Maintainer, Since I upgraded from 12.2.9-1+fto10+2 to 13.1 and then to 13.2.6-1+fto10+1 I ran into several issue leading to the same error type: "undefined method `set_attribute_was'". When I try to create a new project, I end up with the following error inside production.log. I tried to disable jira itegration as it is obviously linked to the root cause but I also end up on a error 500 (following the first stacktrace) Finally I also experiment this kind of issue while trying to set Ci variables: "undefined method `set_attribute_was' for #" (last stacktrace) Hope this while help to fix these issues. Processing by Gitlab::RequestForgeryProtection::Controller#index as HTML Parameters: {"project"=>"florian.galati/ansible.git", "changes"=>"_any", "protocol"=>"ssh", "key_id"=>"99", "check_ip"=>"192.168.1.102", "request_forgery_protection"=>{"action"=>"git-receive-pack", "project"=>"florian.galati/ansible.git", "changes"=>"_any", "protocol"=>"ssh", "key_id"=>"99", "check_ip"=>"192.168.1.102"}} Can't verify CSRF token authenticity. This CSRF token verification failure is handled internally by `GitLab::RequestForgeryProtection` Unlike the logs may suggest, this does not result in an actual 422 response to the user For API requests, the only effect is that `current_user` will be `nil` for the duration of the request Completed 422 Unprocessable Entity in 1ms (ActiveRecord: 0.0ms | Elasticsearch: 0.0ms | Allocations: 212) Gitlab::GitAccessProject::CreationError (Could not create project: undefined method `set_attribute_was' for #): /usr/share/gitlab/lib/gitlab/git_access_project.rb:35:in `ensure_project_on_push!' /usr/share/gitlab/lib/gitlab/git_access_project.rb:13:in `check_project!' /usr/share/gitlab/lib/gitlab/git_access.rb:77:in `check' /usr/share/gitlab/lib/api/internal/base.rb:90:in `access_check!' /usr/share/gitlab/lib/api/internal/base.rb:44:in `check_allowed' /usr/share/gitlab/lib/api/internal/base.rb:116:in `block (2 levels) in ' /usr/lib/ruby/vendor_ruby/grape/endpoint.rb:59:in `call' /usr/lib/ruby/vendor_ruby/grape/endpoint.rb:59:in `block (2 levels) in generate_api_method' /usr/share/rubygems-integration/all/gems/activesupport-6.0.3.1/lib/active_support/notifications.rb:182:in `instrument' /usr/lib/ruby/vendor_ruby/grape/endpoint.rb:58:in `block in generate_api_method' /usr/lib/ruby/vendor_ruby/grape/endpoint.rb:341:in `execute' /usr/lib/ruby/vendor_ruby/grape/endpoint.rb:267:in `block in run' /usr/share/rubygems-integration/all/gems/activesupport-6.0.3.1/lib/active_support/notifications.rb:182:in `instrument' /usr/lib/ruby/vendor_ruby/grape/endpoint.rb:247:in `run' /usr/lib/ruby/vendor_ruby/grape/endpoint.rb:322:in `block in build_stack' /usr/lib/ruby/vendor_ruby/grape/middleware/base.rb:35:in `call!' /usr/lib/ruby/vendor_ruby/grape/middleware/base.rb:28:in `call' /usr/lib/ruby/vendor_ruby/grape/middleware/base.rb:35:in `call!' /usr/lib/ruby/vendor_ruby/grape/middleware/base.rb:28:in `call' /usr/lib/ruby/vendor_ruby/grape/middleware/base.rb:35:in `call!' /usr/lib/ruby/vendor_ruby/grape/middleware/base.rb:28:in `call' /usr/share/rubygems-integration/all/gems/rack-oauth2-1.11.0/lib/rack/oauth2/server/resource.rb:20:in `_call' /usr/share/rubygems-integration/all/gems/rack-oauth2-1.11.0/lib/rack/oauth2/server/resource/bearer.rb:8:in `_call' /usr/share/rubygems-integration/all/gems/rack-oauth2-1.11.0/lib/rack/oauth2/server/abstract/handler.rb:17:in `call' /usr/lib/ruby/vendor_ruby/grape/middleware/error.rb:39:in `block in call!' /usr/lib/ruby/vendor_ruby/grape/middleware/error.rb:38:in `catch' /usr/lib/ruby/vendor_ruby/grape/middleware/error.rb:38:in `call!' /usr/lib/ruby/vendor_ruby/grape/middleware/base.rb:28:in `call' /usr/lib/ruby/vendor_ruby/grape_logging/middleware/request_logger.rb:60:in `block in call!' /usr/lib/ruby/vendor_ruby/grape_logging/middleware/request_logger.rb:58:in `catch' /usr/lib/ruby/vendor_ruby/grape_logging/middleware/request_logger.rb:58:in `call!' /usr/lib/ruby/vendor_ruby/grape/middleware/base.rb:28:in `call' /usr/lib/ruby/vendor_ruby/rack/head.rb:14:in `call' /usr/lib/ruby/vendor_ruby/grape/endpoint.rb:231:in `call!' /usr/lib/ruby/vendor_ruby/grape/endpoint.rb:225:in `call' /usr/lib/ruby/vendor_ruby/grape/router/route.rb:58:in `exec' /usr/lib/ruby/vendor_ruby/grape/router.rb:116:in `process_route' /usr/lib/ruby/vendor_ruby/grape/router.rb:72:in `block in identity' /usr/lib/ruby/vendor_ruby/grape/router.rb:91:in `transaction' /usr/lib/ruby/vendor_ruby/grape/router.rb:70:in `identity' /usr/lib/ruby/vendor_ruby/grape/router.rb:55:in `block in call' /usr/lib/ruby/vendor_ruby/grape/router.rb:132:in `with_optimization' /usr/lib/ruby/vendor_ruby/grape/router.rb:54:in `call' /usr/lib/ruby/vendor_ruby/grape/api/instance.rb:167:in
Bug#968286: gitlab: adding log rotation
I didn't spot the bug report 839702 before opening this one: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839702 Looking closer to the security issue mentioned in 839702, a fix came out recently and the configuration suggested previously should be dropped. A log-rotate file is present in the gitlab repo here: https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/support/logrotate/gitlab That being said, the current user use by gitlab in debian package is gitlab. So I think "su git git" should be replace by "su gitlab gitlab". # GitLab logrotate settings # based on: http://stackoverflow.com/a/4883967 /home/git/gitlab/log/*.log { su git git daily missingok rotate 90 compress notifempty copytruncate } /home/git/gitlab-shell/gitlab-shell.log { su git git daily missingok rotate 90 compress notifempty copytruncate } Sorry for the noise, -- **Fabrice MEYER* Software and System Engineer* EDF Store & Forecast 13 Avenue Albert Einstein 69100 Villeurbanne France *fabrice.me...@edf-sf.co* *www.edf-sf.com*
Bug#968286: gitlab: adding log rotation
Package: gitlab Version: 13.1.6-1+fto10+1 Severity: wishlist Tags: patch Gitlab usage with tens of people specially with CI lead to huge log files which should be rotated. This feature does not exist for instance in 13.1.6-1+fto10+1 version. To achieve that I used the following configuration file located in /etc/logrotate.d/gitlab: /var/log/gitlab/*.log { daily rotate 15 copytruncate delaycompress compress notifempty missingok } As I don't know how to tell gitlab to stop writing logs during rotation, I choose to inspire myself on postgresql configuration which handle that using copytruncate and delaycompress options. This configuration should rotate log every day and purge logs older than 15 days. You may want to tweak these parameters. Hopefully this will be helpfull, *** End of the template - remove these template lines *** -- System Information: Debian Release: 10.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (100, 'buster-fasttrack'), (100, 'buster-backports') Architecture: amd64 (x86_64) Kernel: Linux 5.6.0-0.bpo.2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gitlab depends on: ii asciidoctor2.0.10-2~bpo10+1 ii bc 1.07.1-2+b1 ii bundler2.1.4-2~bpo10+1 ii bzip2 1.0.6-9.2~deb10u1 ii dbconfig-pgsql 2.0.11+deb10u1 ii debconf [debconf-2.0] 1.5.71 ii exim4-daemon-light [mail-transport-agent] 4.94-7~bpo10+1 ii gitlab-common 13.1.0+dfsg-1~bpo10+1 ii gitlab-workhorse 8.37.0+debian-1~bpo10+1 ii libjs-bootstrap4 [node-bootstrap] 4.3.1+dfsg2-1 ii libjs-codemirror [node-codemirror] 5.54.0-2~bpo10+1 ii libjs-popper.js [node-popper.js] 1.14.6+ds2-1 ii libjs-uglify 2.8.29-6 ii libruby2.7 [ruby-json] 2.7.1-3+fto10+2 ii lsb-base 10.2019051400 ii nginx 1.14.2-2+deb10u2 ii nginx-full [nginx] 1.14.2-2+deb10u2 ii node-autosize 4.0.2~dfsg1-3 ii node-axios 0.17.1+dfsg-2 ii node-babel-loader 8.1.0-3~bpo10+1 ii node-babel77.4.5+~cs7.3.8-1~bpo10+1 ii node-brace-expansion 1.1.8-1 ii node-cache-loader 4.1.0-1~bpo10+1 ii node-chart.js 2.7.3+dfsg-5 ii node-clipboard 2.0.6+ds-1~bpo10+1 ii node-compression-webpack-plugin3.0.1-1~bpo10+1 ii node-core-js 3.6.1-2~bpo10+2 ii node-css-loader2.1.1-1~bpo10+1 ii node-d35.16.0-1~bpo10+1 ii node-d3-scale 2.2.2-2~bpo10+1 ii node-d3-selection 1.4.0-3~bpo10+1 ii node-dateformat3.0.0-1 ii node-exports-loader0.7.0-2~bpo10+1 ii node-fuzzaldrin-plus 0.5.0+dfsg-1 ii node-glob 7.1.6-1~bpo10+1 ii node-imports-loader0.8.0-2~bpo10+1 ii node-jed 1.1.1-1 ii node-jquery3.4.0+dfsg-1~bpo10+1 ii node-jquery-ujs1.2.2-2 ii node-js-cookie 2.2.0-2 ii node-jszip 3.2.2+dfsg-1~bpo10+1 ii node-jszip-utils 0.0.2+dfsg-1 ii node-lodash4.17.15+dfsg-2~bpo10+1 ii node-marked0.5.1+dfsg-1 ii node-mousetrap 1.6.1+ds-1 ii node-prismjs 1.11.0+dfsg-3~bpo10+1 ii node-prosemirror-model 1.9.0-3~bpo10+1 ii node-raven-js 3.22.1+dfsg-2 ii node-three-orbit-controls 82.1.0-2 ii node-three-stl-loader 1.0.6-2 ii node-timeago.js4.0.2-2~bpo10+1 ii node-underscore1.9.1~dfsg-1 ii node-url-loader3.0.0-1~bpo10+1 ii node-vue 2.6.11+dfsg-1~bpo10+1 ii node-vue-reso
Bug#959875: Acknowledgement (RFS: redmine-plugin-apijs/6.1.0-4 [ITP] -- Redmine plugin to display gallery from attachments)
Hi, I uploaded a new release.
Bug#919525: race condition between sshguard and ufw on startup
Looks like this one is fixed: here is the service file of 2.3.1-1 realease [Unit]Description=SSHGuard Documentation=man:sshguard(8) After=network.target Before=sshd.service You may consider to close this bug On Wed, 16 Jan 2019 22:53:58 +0100 Simon Vetter wrote: > Package: sshguard > Version: 1.7.1-1 > > On systems with ufw (uncomplicated firewall, a popular firewall manager/frontend) *and* sshguard installed, a race condition exists between sshguard's firewall setup script and ufw. > > As I understand it, ufw calls iptables-restore on multiple files on startup to create and populate its various chains. > If, during one of those calls, /usr/lib/sshguard/firewall is called to add the sshguard chain, the iptable-restore call fails and ufw cracks open. > This has bitten me a few times, leaving remote boxes unreachable over the network after a reboot since ufw was unable to restore all of its rules. > > sshguard's systemd service file seems to have an After= directive which should prevent this, as ufw specifies a Before=network.target directive. > > [Unit] > Description=SSHGuard > Documentation=man:sshguard(8) > After=network.service > Before=sshd.service > > Since none of my Debian systems have a network.service file, I tried changing "After=network.service" to "After=network.target", which did the trick: sshguard is now started well after ufw, and after tens of reboots I haven't seen the issue come up again. > > Given my limited systemd knowledge, this may or may not be the best fix, but I believe something along these lines should be changed and a new package published. > > This is on Debian 9.6 (latest at the time of this writing), all packages up to date. > > Cheers, > -Simon > > -- > -- > Simon Vetter > Embedded Software Engineer - EDF store & forecast > Phone: +33 7 83 40 26 11 > -- **Fabrice MEYER* Software and System Engineer* EDF Store & Forecast 13 Avenue Albert Einstein 69100 Villeurbanne France *fabrice.me...@edf-sf.com* *www.edf-sf.com*
Bug#928525: Confirming
This issue is still present, I opened a merge request on salsa with the fix you suggested which seems to work well on my side: https://salsa.debian.org/debian/sshguard/-/merge_requests/2 Thanks mate ! On Tue, 29 Oct 2019 17:43:56 -0400 gi1242+debianb...@gmail.com wrote: > Confirming I have this problem too. My /etc/sshguard/sshguard.conf has > > LOGREADER="LANG=C /bin/journalctl -afb -p info -n1 -o cat SYSLOG_FACILITY=4 SYSLOG_FACILITY=10" > > The example provided by upstream has > > LOGREADER="LANG=C journalctl -afb -p info -n1 -t sshd -t sendmail -o cat" > > Changing it to this makes the problem go away. (Since I use postfix, I > used "-t postfix/smtpd" instead of sendmail.) > > GI > > -- > My wife told me I had to stop acting like a flamingo. So I had to put my > foot down. > > -- **Fabrice MEYER* Software and System Engineer* EDF Store & Forecast 13 Avenue Albert Einstein 69100 Villeurbanne France *fabrice.me...@edf-sf.com* *www.edf-sf.com*
Bug#959875: Acknowledgement (RFS: redmine-plugin-apijs/6.2.0-1 [ITP] -- Redmine plugin to display gallery from attachments)
Hi, I uploaded a new release. Hope it's good. Le 06/05/2020 à 13:57, Debian Bug Tracking System a écrit : Thank you for filing a new Bug report with Debian. You can follow progress on this Bug here: 959875: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959875. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): Debian Mentors If you wish to submit further information on this problem, please send it to 959...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system.
Bug#959897: Acknowledgement (RFS: awf-gtk2/2.1.0-1 [ITP] -- A widget factory is a theme preview application for GTK)
Hi, I uploaded a new release. Hope it's good.
Bug#959892: Acknowledgement (RFS: awf-gtk3/2.1.0-1 [ITP] -- A widget factory is a theme preview application for GTK)
Hi, I uploaded a new release. Hope it's good.
Bug#964177: (no subject)
Stacktrace from my workstation : [26721:26726:0703/154351.655503:ERROR:ssl_client_socket_impl.cc(959)] handshake failed; returned -1, SSL error code 1, net_error -101 [26677:30883:0703/154702.244151:ERROR:nss_util.cc(283)] After loading Root Certs, loaded==false: NSS error code: -8018 free(): double free detected in tcache 2 Received signal 6 #0 0x55a1b69dbf61 (/usr/lib/chromium/chromium+0x83a5f60) #1 0x55a1b68e6ecd (/usr/lib/chromium/chromium+0x82b0ecc) #2 0x55a1b68e6e75 (/usr/lib/chromium/chromium+0x82b0e74) #3 0x55a1b69dbae1 (/usr/lib/chromium/chromium+0x83a5ae0) #4 0x7f0b56939730 (/usr/lib/x86_64-linux-gnu/libpthread-2.28.so+0x1272f) #5 0x7f0b507fd7bb gsignal #6 0x7f0b507e8535 abort #7 0x7f0b5083f508 (/usr/lib/x86_64-linux-gnu/libc-2.28.so+0x79507) #8 0x7f0b50845c1a (/usr/lib/x86_64-linux-gnu/libc-2.28.so+0x7fc19) #9 0x7f0b508476fd (/usr/lib/x86_64-linux-gnu/libc-2.28.so+0x816fc) #10 0x55a1b69fedad (/usr/lib/chromium/chromium+0x83c8dac) #11 0x55a1b69fe48b operator delete() #12 0x55a1b20c3f90 (/usr/lib/chromium/chromium+0x3a8df8f) #13 0x55a1b20c3f60 (/usr/lib/chromium/chromium+0x3a8df5f) #14 0x55a1b20c451c (/usr/lib/chromium/chromium+0x3a8e51b) #15 0x55a1b2eb341c (/usr/lib/chromium/chromium+0x487d41b) #16 0x55a1b2eb33c8 (/usr/lib/chromium/chromium+0x487d3c7) #17 0x55a1b2eb3355 (/usr/lib/chromium/chromium+0x487d354) #18 0x55a1b2eb3325 (/usr/lib/chromium/chromium+0x487d324) #19 0x55a1b2eb2cc3 (/usr/lib/chromium/chromium+0x487ccc2) #20 0x55a1b3bf1175 (/usr/lib/chromium/chromium+0x55bb174) #21 0x55a1b3bf1219 (/usr/lib/chromium/chromium+0x55bb218) #22 0x55a1b208e57f (/usr/lib/chromium/chromium+0x3a5857e) #23 0x55a1b208c673 (/usr/lib/chromium/chromium+0x3a56672) #24 0x55a1b24a1589 (/usr/lib/chromium/chromium+0x3e6b588) #25 0x55a1b24a1739 (/usr/lib/chromium/chromium+0x3e6b738) #26 0x55a1b24a1718 (/usr/lib/chromium/chromium+0x3e6b717) #27 0x55a1b2c84432 (/usr/lib/chromium/chromium+0x464e431) #28 0x55a1b2c843df (/usr/lib/chromium/chromium+0x464e3de) #29 0x55a1b2c84398 (/usr/lib/chromium/chromium+0x464e397) #30 0x55a1b2c84325 (/usr/lib/chromium/chromium+0x464e324) #31 0x55a1b2c83e65 (/usr/lib/chromium/chromium+0x464de64) #32 0x55a1b3b6a760 (/usr/lib/chromium/chromium+0x553475f) #33 0x55a1b3b6ab99 (/usr/lib/chromium/chromium+0x5534b98) #34 0x55a1b208e57f (/usr/lib/chromium/chromium+0x3a5857e) #35 0x55a1b208ea1c (/usr/lib/chromium/chromium+0x3a58a1b) #36 0x55a1b3bf8bea (/usr/lib/chromium/chromium+0x55c2be9) #37 0x55a1b3c4ec0b (/usr/lib/chromium/chromium+0x5618c0a) #38 0x55a1b3c419d3 (/usr/lib/chromium/chromium+0x560b9d2) #39 0x55a1b3c417ff (/usr/lib/chromium/chromium+0x560b7fe) #40 0x55a1b3c41a69 (/usr/lib/chromium/chromium+0x560ba68) #41 0x55a1b22b5d7b (/usr/lib/chromium/chromium+0x3c7fd7a) #42 0x55a1b232c4c5 (/usr/lib/chromium/chromium+0x3cf64c4) #43 0x55a1b3003fac (/usr/lib/chromium/chromium+0x49cdfab) #44 0x55a1b3003f69 (/usr/lib/chromium/chromium+0x49cdf68) #45 0x55a1b2ffeeda (/usr/lib/chromium/chromium+0x49c8ed9) #46 0x55a1b3bf1199 (/usr/lib/chromium/chromium+0x55bb198) #47 0x55a1b3bf1219 (/usr/lib/chromium/chromium+0x55bb218) #48 0x55a1b208e57f (/usr/lib/chromium/chromium+0x3a5857e) #49 0x55a1b208c673 (/usr/lib/chromium/chromium+0x3a56672) #50 0x55a1b24a1589 (/usr/lib/chromium/chromium+0x3e6b588) #51 0x55a1b24a1739 (/usr/lib/chromium/chromium+0x3e6b738) #52 0x55a1b24a1718 (/usr/lib/chromium/chromium+0x3e6b717) #53 0x55a1b2c84432 (/usr/lib/chromium/chromium+0x464e431) #54 0x55a1b2c843df (/usr/lib/chromium/chromium+0x464e3de) #55 0x55a1b2c84398 (/usr/lib/chromium/chromium+0x464e397) #56 0x55a1b3134d95 (/usr/lib/chromium/chromium+0x4afed94) #57 0x55a1b3134d1b (/usr/lib/chromium/chromium+0x4afed1a) #58 0x55a1b3b770d6 (/usr/lib/chromium/chromium+0x55410d5) #59 0x55a1b3b7041d (/usr/lib/chromium/chromium+0x553a41c) #60 0x55a1b3b70647 (/usr/lib/chromium/chromium+0x553a646) #61 0x55a1b3bf10f0 (/usr/lib/chromium/chromium+0x55bb0ef) #62 0x55a1b2329bfd (/usr/lib/chromium/chromium+0x3cf3bfc) #63 0x55a1b2329b41 (/usr/lib/chromium/chromium+0x3cf3b40) #64 0x55a1b2c0def7 (/usr/lib/chromium/chromium+0x45d7ef6) #65 0x55a1b2c0de9c (/usr/lib/chromium/chromium+0x45d7e9b) #66 0x55a1b2330b2d (/usr/lib/chromium/chromium+0x3cfab2c) #67 0x55a1b3642c09 (/usr/lib/chromium/chromium+0x500cc08) #68 0x55a1b364286b (/usr/lib/chromium/chromium+0x500c86a) #69 0x55a1b2aa031a (/usr/lib/chromium/chromium+0x446a319) #70 0x55a1b2aa025b (/usr/lib/chromium/chromium+0x446a25a) #71 0x55a1b2aa01cc (/usr/lib/chromium/chromium+0x446a1cb) #72 0x55a1b2aa014d (/usr/lib/chromium/chromium+0x446a14c) #73 0x55a1b23611e7 (/usr/lib/chromium/chromium+0x3d2b1e6) #74 0x55a1b6b4f10d (/usr/lib/chromium/chromium+0x851910c) #75 0x55a1b6b57c19 (/usr/lib/chromium/chromium+0x8521c18) #76 0x55a1b6b55b58 (/usr/lib/chromium/chromium+0x851fb57) #77 0x55a1b6b5491e (/usr/lib/chromium/chromium+0x851e91d) #78 0x55a1b2387b7a (/usr/lib/chromium/chromium+0x3d51b79) #79 0x55a1b2387ad6 (/usr/lib/chromium/chromium+0x3d51ad5) #80 0x55a1b38504d3 (/usr/lib/chromium/chromium+0x521a4d2)