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
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.py",
line 249, in split_lines
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, 9184899517099004093, 91848810
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 available 2021-06-19 16:35:0
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
t;/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=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'
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
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)
Bug#959897: RFS: awf-gtk2/2.0.0-3 [ITP] -- A widget factory is a theme preview application for GTK
Hi! Thank you. The version is -3 because I uploaded some test versions on mentors.debian.net. I tried to upload 2.0.0-1 many times, but it was refused, so I changed version number. I'm confused about the lintian override (description-synopsis-starts-with-article) and "A Widget Factory". I use the lintian ovevride for initial "A"... Does I change the name to "A Widget Factory" anyway? You say "Also: despite GTK2 being deprecated, having the gtk2 package would be great.", I agree x10. I have updated this tool to port a gtk2 theme to gtk3. Le 11/05/2020 à 22:54, Adam Borowski a écrit : On Wed, May 06, 2020 at 07:51:53PM +0200, Fabrice Creuzot wrote: * Package name: awf-gtk2 Version : 2.0.0-3 Changes since the last upload: * Initial debian package release (Closes: #959434) Hi! The package looks almost good to go: * Debian revision: how come it's -3 on an initial upload? Especially with nothing in the changelog? We don't bump a version just because you've tested it at home -- it often takes many, many test builds to get things right. An exception is if a version of the package has been released to an audience, be they users of some Debian-based distribution, your team at works, etc -- having two different versions with the same number would give them a hardship. * the real name (according to a Lintian override) is "A Widget Factory", yet you capitalize only the article. For an English speaking person, that's for sure some common thing. Could you please put it into title case (Ie, Starting Every Word with a Cap Letter)? Both of these are common to either variant (gtk2 and gtk3). Also: despite GTK2 being deprecated, having the gtk2 package would be great. It already proven useful in finding out regressions in a theme I maintain -- a bunch of functionality is wrong in gtk3, having both side-to-side made that immediately visible. Meow!
Bug#959897: RFS: awf-gtk2/2.0.0-3 [ITP] -- A widget factory is a theme preview application for GTK
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "awf-gtk2" * Package name: awf-gtk2 Version : 2.0.0-3 Upstream Author : Fabrice Creuzot * URL : https://github.com/luigifab/awf-extended * License : GPL-3+ * Vcs : https://github.com/luigifab/awf-extended Section : x11 A widget factory is a theme preview application for GTK. It displays the various widget types provided by GTK in a single window allowing to see the visual effect of the applied theme. It builds those binary packages: awf-gtk2 - 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-gtk2 Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/a/awf-gtk2/awf-gtk2_2.0.0-3.dsc Changes since the last upload: * Initial debian package release (Closes: #959434) Regards, Thank you
Bug#959892: RFS: awf-gtk3/2.0.0-3 [ITP] -- A widget factory is a theme preview application for GTK
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "awf-gtk3" * Package name: awf-gtk3 Version : 2.0.0-3 Upstream Author : Fabrice Creuzot * URL : https://github.com/luigifab/awf-extended * License : GPL-3+ * Vcs : https://github.com/luigifab/awf-extended Section : x11 A widget factory is a theme preview application for GTK. It displays the various widget types provided by GTK in a single window allowing to see the visual effect of the applied theme. It builds those binary packages: awf-gtk3 - 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-gtk3 Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/a/awf-gtk3/awf-gtk3_2.0.0-3.dsc Changes since the last upload: * Initial debian package release (Closes: #959436) Regards, Thank you
Bug#959875: RFS: redmine-plugin-apijs/6.1.0-4 [ITP] -- Redmine plugin to display gallery from attachments
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "redmine-plugin-apijs" * Package name: redmine-plugin-apijs Version : 6.1.0-4 Upstream Author : Fabrice Creuzot * URL : https://github.com/luigifab/apijs * License : GPL-2+ * Vcs : https://github.com/luigifab/apijs Section : web I created this package in the same way of the redmine-plugin-custom-css package. This is my first package, I hope it is good. On mentors.debian.net, package has lintian errors: source-is-missing and source-contains-prebuilt-javascript-object, yes it's intentional. Also, I'm not sure about my lintian overrides font-in-non-font-package/font-outside-font-dir. It builds those binary packages: redmine-plugin-apijs - Redmine plugin to display gallery from attachments To access further information about this package, please visit the following URL: https://mentors.debian.net/package/redmine-plugin-apijs Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/r/redmine-plugin-apijs/redmine-plugin-apijs_6.1.0-4.dsc Changes since the last upload: * Initial debian package release (Closes: #959426) Regards, Thank you
Bug#959434: ITP: awf-gtk2 -- A widget factory is a theme preview application
That's a good news, but I'm also sad. Perhpas I can push my package with a "tag" like yes remove me when Debian drop gtk2? Le 03/05/2020 à 02:17, Paul Wise a écrit : On Sat, 02 May 2020 12:47:42 +0200 luigifab wrote: This package include the gtk2 version. Debian is attempting to remove GTK 2, so it would be best to not introduce new packages that require GTK 2. https://lists.debian.org/msgid-search/20200429093827.ga770...@espresso.pseudorandom.co.uk
Bug#955015: python3-xarray: Backend api engine grib broken
I just miss type, I wanted to say cfgrib instead of cfdisk. The goal
here was to try makes _get_default_engine_grib returning cfgrib to see
what happen but it ended with a key error as cfgrib isn't in the
writeable_store.
Best regards,
Fabrice
On Fri, 27 Mar 2020 13:13:32 + Alastair McKinstry
wrote:
> Hi,
>
> I shall forward to upstream. It does appear that setting engine=cfgrib
> should not be necessary if the file is a grib file (by extension) and
> cfgrib is present.
>
> I Agree with your point on writable_stores / cfdisk.
>
> Best regards
>
> Alastair
>
>
> On 27/03/2020 12:44, Fabrice Meyer wrote:
> > Just adding a detail, to avoid messing with xarray code, you just need
> > to call to_netcdf with an engine define in your parameters. It is just
> > the default engine selection which appears to be broken on this version
> > of xarray (and also in stable).
> >
> > Regards
> >
> >
> > Le 26/03/2020 à 21:07, Fabrice Meyer a écrit :
> >> Package: python3-xarray
> >> Version: 0.15.0-3
> >> Severity: important
> >>
> >> Dear Maintainer,
> >>
> >> I was trying to use to_netcdf() located in
/usr/lib/python3/dist-packages/xarray/backends/api.py on a grib file
without specifying the engine and it appears that the default engine
selection end up on grib engine.
> >>
> >> So _get_default_engine calls _get_default_engine_grib as we have a
grib file but this function always raise a ValueError even if cfgrib
import succeed but anyway, there is a real issue with this function as
it is returning nothing while _get_default_engine is expecting an engine.
> >> If we try to, somehow, makes _get_default_engine_grib return cfdisk
as engine, it will still fail as cfgrib is absent of the
WRITEABLE_STORES bellow but even if it would have been present, cfgrib
does not implement a writeable store.
> >>
> >> WRITEABLE_STORES: Dict[str, Callable] = {
> >> "netcdf4": backends.NetCDF4DataStore.open,
> >> "scipy": backends.ScipyDataStore,
> >> "h5netcdf": backends.H5NetCDFStore.open,
> >> }
> >>
> >> I'm quite new dealing with xarray but I think grib engine seems to
be on work in progress or something and doesn't look ready yet.
> >>
> >> In order to get the job done, I tryed to make
_get_default_engine_grib returning "netcdf4" based on observation on an
older implementation of xarray (0.10.2-1). This "hack" worked but it is
really dirty.
> >>
> >> Could you please dig a bit more and fix this issue?
> >>
> >> Best regards, and thank you for all job done maintaining theses
packages.
> >>
> >>
> >> -- System Information:
> >> Debian Release: bullseye/sid
> >> APT prefers stable-updates
> >> APT policy: (500, 'stable-updates'), (500, 'unstable'), (500,
'testing'), (500, 'stable')
> >> Architecture: amd64 (x86_64)
> >>
> >> Kernel: Linux 4.19.0-8-amd64 (SMP w/1 CPU core)
> >> Kernel taint flags: TAINT_CRAP
> >> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
> >> Shell: /bin/sh linked to /bin/dash
> >> Init: systemd (via /run/systemd/system)
Bug#955015: python3-xarray: Backend api engine grib broken
Just adding a detail, to avoid messing with xarray code, you just need
to call to_netcdf with an engine define in your parameters. It is just
the default engine selection which appears to be broken on this version
of xarray (and also in stable).
Regards
Le 26/03/2020 à 21:07, Fabrice Meyer a écrit :
> Package: python3-xarray
> Version: 0.15.0-3
> Severity: important
>
> Dear Maintainer,
>
> I was trying to use to_netcdf() located in
> /usr/lib/python3/dist-packages/xarray/backends/api.py on a grib file without
> specifying the engine and it appears that the default engine selection end up
> on grib engine.
>
> So _get_default_engine calls _get_default_engine_grib as we have a grib file
> but this function always raise a ValueError even if cfgrib import succeed but
> anyway, there is a real issue with this function as it is returning nothing
> while _get_default_engine is expecting an engine.
> If we try to, somehow, makes _get_default_engine_grib return cfdisk as
> engine, it will still fail as cfgrib is absent of the WRITEABLE_STORES bellow
> but even if it would have been present, cfgrib does not implement a writeable
> store.
>
> WRITEABLE_STORES: Dict[str, Callable] = {
> "netcdf4": backends.NetCDF4DataStore.open,
> "scipy": backends.ScipyDataStore,
> "h5netcdf": backends.H5NetCDFStore.open,
> }
>
> I'm quite new dealing with xarray but I think grib engine seems to be on work
> in progress or something and doesn't look ready yet.
>
> In order to get the job done, I tryed to make _get_default_engine_grib
> returning "netcdf4" based on observation on an older implementation of xarray
> (0.10.2-1). This "hack" worked but it is really dirty.
>
> Could you please dig a bit more and fix this issue?
>
> Best regards, and thank you for all job done maintaining theses packages.
>
>
> -- System Information:
> Debian Release: bullseye/sid
> APT prefers stable-updates
> APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'),
> (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.19.0-8-amd64 (SMP w/1 CPU core)
> Kernel taint flags: TAINT_CRAP
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
> LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages python3-xarray depends on:
> ii python3 3.8.2-2
> ii python3-numpy 1:1.17.4-5
> ii python3-pandas 0.25.3+dfsg-7
>
> Versions of packages python3-xarray recommends:
> ii python3-bottleneck 1.2.1+ds1-2+b1
> ii python3-dask2.11.0+dfsg-1
> ii python3-h5netcdf0.7.1-1
> ii python3-netcdf4 1.5.3-1+b2
> ii python3-zarr2.4.0+ds-1
>
> Versions of packages python3-xarray suggests:
> pn python-xarray-doc
> pn python3-cartopy
> ii python3-matplotlib 3.2.1-1
> pn python3-pydap
> pn python3-rasterio
> ii python3-scipy 1.3.3-3
> pn python3-seaborn
> ii python3-toolz 0.9.0-1
>
> -- no debconf information
Bug#955015: python3-xarray: Backend api engine grib broken
Package: python3-xarray
Version: 0.15.0-3
Severity: important
Dear Maintainer,
I was trying to use to_netcdf() located in
/usr/lib/python3/dist-packages/xarray/backends/api.py on a grib file without
specifying the engine and it appears that the default engine selection end up
on grib engine.
So _get_default_engine calls _get_default_engine_grib as we have a grib file
but this function always raise a ValueError even if cfgrib import succeed but
anyway, there is a real issue with this function as it is returning nothing
while _get_default_engine is expecting an engine.
If we try to, somehow, makes _get_default_engine_grib return cfdisk as engine,
it will still fail as cfgrib is absent of the WRITEABLE_STORES bellow but even
if it would have been present, cfgrib does not implement a writeable store.
WRITEABLE_STORES: Dict[str, Callable] = {
"netcdf4": backends.NetCDF4DataStore.open,
"scipy": backends.ScipyDataStore,
"h5netcdf": backends.H5NetCDFStore.open,
}
I'm quite new dealing with xarray but I think grib engine seems to be on work
in progress or something and doesn't look ready yet.
In order to get the job done, I tryed to make _get_default_engine_grib
returning "netcdf4" based on observation on an older implementation of xarray
(0.10.2-1). This "hack" worked but it is really dirty.
Could you please dig a bit more and fix this issue?
Best regards, and thank you for all job done maintaining theses packages.
-- System Information:
Debian Release: bullseye/sid
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'),
(500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-8-amd64 (SMP w/1 CPU core)
Kernel taint flags: TAINT_CRAP
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages python3-xarray depends on:
ii python3 3.8.2-2
ii python3-numpy 1:1.17.4-5
ii python3-pandas 0.25.3+dfsg-7
Versions of packages python3-xarray recommends:
ii python3-bottleneck 1.2.1+ds1-2+b1
ii python3-dask2.11.0+dfsg-1
ii python3-h5netcdf0.7.1-1
ii python3-netcdf4 1.5.3-1+b2
ii python3-zarr2.4.0+ds-1
Versions of packages python3-xarray suggests:
pn python-xarray-doc
pn python3-cartopy
ii python3-matplotlib 3.2.1-1
pn python3-pydap
pn python3-rasterio
ii python3-scipy 1.3.3-3
pn python3-seaborn
ii python3-toolz 0.9.0-1
-- no debconf information
Bug#955010: python3-cfgrib: cfgrib, import fail "No module named 'cffi"
Package: python3-cfgrib Version: 0.9.5.1-1 Severity: important Tags: d-i Dear Maintainer, I was installing cfgrib on a fresh debian install and it appears that cfgrib have missing dependency : cffi Just installing python3-cffi fix the problem. However, I think this issue should be reported even if it is fixed on unstable (cffi appear on librairie and import doesn't failed). It would be great if you could add/backport this dependency to have this package well packed :) Thank you for adding this package to debian ! -- System Information: Debian Release: 10.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-8-amd64 (SMP w/1 CPU core) Kernel taint flags: TAINT_CRAP Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-cfgrib depends on: ii libeccodes-data 2.12.0-1 ii libeccodes0 2.12.0-1 ii python3 3.7.3-1 ii python3-attr 18.2.0-1 ii python3-cffi-backend [python3-cffi-backend-api-min] 1.12.2-1 pn python3-cffi-backend-api-max ii python3-click7.0-1 ii python3-future 0.16.0-1 ii python3-numpy1:1.16.2-1 ii python3-xarray 0.11.3-2 python3-cfgrib recommends no packages. python3-cfgrib suggests no packages. -- no debconf information
Bug#953333: RFS: python-opentracing/2.3.0-1 [ITP] -- opentracing interface for Python
Note that 2.2.0-1 is still in the NEW queue: https://ftp-master.debian.org/new/python-opentracing_2.2.0-1.html
