Bug#1080361: wfrench: update d/watch file
Hi, commited as : https://salsa.debian.org/gpernot/wfrench/-/commit/2d1d4580e6fa8e9cf6e3f47b07046c7cd96460b9 thanks, guillaume
Bug#1076163: librapidcheck-dev: Missing pkgconfig files for rapidcheck
Package: librapidcheck-dev Version: 0~1048-a5724ea-1 Severity: normal X-Debbugs-Cc: guillaume.yziq...@mailfence.com Dear Maintainer, I'm on ubuntu mantic (apologies) and noticed, while building nix from source, that the pkgconfig files for rapidcheck were not packaged. Would be nice if they were. -- System Information: Debian Release: trixie/sid APT prefers mantic-updates APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500, 'mantic'), (100, 'mantic-backports') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-41-generic (SMP w/32 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 -- no debconf information
Bug#1071994: git-buildpackage: Please document the --no-sign option in man pages or gbp buildpackage --help
Package: git-buildpackage Version: 0.9.32 Severity: wishlist X-Debbugs-Cc: guillaume.yziq...@mailfence.com Dear Maintainer, Hi. Context: toying around with packaging for tasksh package upstream fix. The --no-sign option that allows me to build my package without access to the Debian maintainer's private key is not documented in the documentation of git-buildpackage. Anywhere I've looked around. If it is, it is well hidden. This is confusing for the following reason: people trying to hack off a quick and dirty package have to disable signing the package; but the only thing the documentation talks about is signing tags. That confusion has held me back in the past. Documenting --no-sign would make things much easier. Lower the entry bar. Please consider. Best regards. G.
Bug#1071939: taskwarrior: Naming conflict with go-task task tool
Package: taskwarrior Version: 2.6.2+dfsg-1 Severity: wishlist X-Debbugs-Cc: guillaume.yziq...@mailfence.com Dear Maintainer, For various development reaons on my machine, I had to install the go-task task tool. It is a task runner in the go ecosystem that has named its executable... task. https://github.com/go-task/task.git This very obviously conflicts with the name of taskwarrior's executable. Which saddens me a lot. That naming choice from go-task is most unfortunate. But I do not expect this name conflict to be of major importance to them. But I need both taskwarrior and go-task's task. Because I use go-task's task in a git repository, and use custom taskwarrior configuration to handle a local bug-tracker local to the same git repository. I would therefore appreciate, even if I do not have much hope on that front, that debian packaging and the go-task team could come up with an agreement on the name used here. As to myself, I'll be looking at a way to rename the task taskwarrior executable on my system, possibly by modifying the debian packaging. Best regards. Guillaume Yziquel. P.S.: using ubuntu (for the moment), but I believe debian is the right place to report this bug. -- System Information: Debian Release: trixie/sid APT prefers mantic-updates APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500, 'mantic'), (100, 'mantic-backports') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-28-generic (SMP w/32 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 taskwarrior depends on: ii libc62.38-1ubuntu6.2 ii libgcc-s113.2.0-4ubuntu3 ii libgnutls30 3.8.1-4ubuntu1.3 ii libstdc++6 13.2.0-4ubuntu3 ii libuuid1 2.39.1-4ubuntu2.2 taskwarrior recommends no packages. taskwarrior suggests no packages. -- no debconf information
Bug#1064123: libgl1-mesa-dri: latest version crashes X, can't use mouse/keyboard
On Mon, 19 Feb 2024 23:16:44 +0100 "Xavier G." wrote: > Dear Maintainer, > > I confirm this issue. > I experienced it with an AMD R7 240 graphics card[1] on a regular Debian > Sid host running kernel 6.6.15. > Booting with the previous kernel (6.6.13) did not change the situation > but I confirm "Accel" "no", as suggested by Grégory, is a suitable > workaround. > > The machine that experiences this issue idles most of the time, so let > me know if I can do/provide anything that would help solving this. > > Cheers, > -- > Xavier G. > > [1] lspci: Advanced Micro Devices, Inc. [AMD/ATI] Oland PRO [Radeon R7 240/340 / Radeon 520] > > Hi, I can also confirm this issue, on an AMD R7 240 GPU, regular Debian Sid, Accel workaround is working fine. I'm having a slightly different behavior : with gdm, I cannot start at all a X session, and the crash log is a bit different : [24.518] (EE) Backtrace: [24.519] (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x14d) [0x562f130d0f9d] [24.520] (EE) 1: /lib/x86_64-linux-gnu/libc.so.6 (__sigaction+0x40) [0x7de0e4f31510] [24.523] (EE) 2: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (radeon_drm_winsys_create+0x275d) [0x7de0e27c586d] [24.524] (EE) 3: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (radeon_drm_winsys_create+0x4841) [0x7de0e27c7951] [24.525] (EE) 4: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (_ZNSt6vectorIjSaIjEE17_M_default_appendEm+0xa77e6) [0x7de0e2cc9476] [24.525] (EE) 5: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (_ZNSt6vectorIjSaIjEE17_M_default_appendEm+0xa7989) [0x7de0e2cc9619] [24.525] (EE) 6: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (radeon_drm_winsys_create+0x3aba) [0x7de0e27c6bca] [24.527] (EE) 7: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (radeon_drm_winsys_create+0x137795) [0x7de0e28fa8a5] [24.527] (EE) 8: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (radeon_drm_winsys_create+0x1021d5) [0x7de0e28c52e5] [24.527] (EE) 9: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (radeon_drm_winsys_create+0x102ffa) [0x7de0e28c610a] [24.528] (EE) 10: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (__driDriverGetExtensions_d3d12+0xe6f3c) [0x7de0e21982cc] [24.528] (EE) 11: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (__driDriverGetExtensions_d3d12+0xb9020) [0x7de0e216a3b0] [24.529] (EE) 12: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (__driDriverGetExtensions_d3d12+0xba6fc) [0x7de0e216ba8c] [24.529] (EE) 13: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (__driDriverGetExtensions_d3d12+0xbc463) [0x7de0e216d7f3] [24.529] (EE) 14: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (__driDriverGetExtensions_d3d12+0x93972) [0x7de0e2144d02] [24.529] (EE) 15: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (__driDriverGetExtensions_d3d12+0x95c75) [0x7de0e2147005] [24.530] (EE) 16: /usr/lib/xorg/modules/libglamoregl.so (glamor_change_window_attributes+0x177) [0x7de0da39c317] [24.530] (EE) 17: /usr/lib/xorg/modules/libglamoregl.so (glamor_change_window_attributes+0x520) [0x7de0da39c6c0] [24.530] (EE) 18: /usr/lib/xorg/modules/libglamoregl.so (glamor_create_pixmap+0x27d) [0x7de0da3814ed] [24.530] (EE) unw_get_proc_name failed: no unwind info found [-10] [24.530] (EE) 19: /usr/lib/xorg/modules/drivers/radeon_drv.so (?+0x0) [0x7de0e4357da3] [24.530] (EE) 20: /usr/lib/xorg/Xorg (dixDestroyPixmap+0x11e) [0x562f12f5632e] [24.530] (EE) 21: /usr/lib/xorg/Xorg (SendErrorToClient+0x3d4) [0x562f12f5b354] [24.531] (EE) 22: /usr/lib/xorg/Xorg (InitFonts+0x3bc) [0x562f12f5f3bc] [24.531] (EE) 23: /lib/x86_64-linux-gnu/libc.so.6 (__libc_init_first+0x8a) [0x7de0e4f1c6ca] [24.531] (EE) 24: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0x85) [0x7de0e4f1c785] [24.532] (EE) 25: /usr/lib/xorg/Xorg (_start+0x21) [0x562f12f48281] [24.532] (EE) [24.532] (EE) Segmentation fault at address 0x40 [24.532] (EE) Fatal server error: [24.532] (EE) Caught signal 11 (Segmentation fault). Server aborting Cheers,
Bug#1061442: plymouth: unable to boot with the message : "begin : running /scripts/init-premount ...."
Package: plymouth Version: 24.004.60-1 Severity: important Tags: a11y X-Debbugs-Cc: miste...@hotmail.com Dear Maintainer, since these new update version, the pc is not booting. with a downgrade to the previous version, the pc is booting and everything is ok. when i have this error message : "begin : running /scripts/init-premount ", i just can reboot. no escape, no console log, nothing. to resolve that, i remove the splash option in the boot and everything is ok. regards Guillaume -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.6.13-amd64 (SMP w/24 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 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 plymouth depends on: ii init-system-helpers 1.66 ii initramfs-tools 0.142 ii libc62.37-14 ii libdrm2 2.4.120-1 ii libplymouth5 24.004.60-1 ii systemd 255.2-4 ii udev 255.2-4 plymouth recommends no packages. Versions of packages plymouth suggests: ii desktop-base 12.0.6+nmu1 pn plymouth-themes -- no debconf information
Bug#1057009: consider updating crash to 8.0.4
Package: hello Version: 8.0.3+ds1 Severity: wishlist Hello, crash 8.0.4 has fixes for Linux 6.4+. Considering Linux 6.5 is availabe in sid, it would be useful to have it packaged. Thank you Guillaume. -- Guillaume Morin
Bug#1038110: jupyterhub: config.yaml config file that comes in package is never read
Package: jupyterhub
Version: 3.0.0+ds1-1
Severity: important
X-Debbugs-Cc: xi...@australdx.fr
Dear Maintainer,
The jupyterhub Debian package comes with a
/etc/jupyterhub/config/jupyterhub_config.d/config.yaml configuration
file (that is an empty valid YAML file).
The package also includes a /usr/lib/systemd/system/jupyterhub.service
which passes that YAML configuration file path to the command to launch
JupyterHub:
ExecStart=/usr/bin/python3 -m jupyterhub.app -f
/etc/jupyterhub/config/jupyterhub_config.d/config.yaml --upgrade-db
The config.yaml was added by commit:
> commit d95b38e175f746b26992ccae18f61cecde5c3479
> Author: Roland Mas
> Date: Wed Jun 2 16:06:51 2021 +0200
>
> Add empty config file
The jupyterhub.service was added by commit:
> commit 306c215c07f978bf7292c06c50c02fa7a383
> Author: Roland Mas
> Date: Wed Jun 2 16:13:16 2021 +0200
>
> Add systemd service file
and the command line hasn't changed since then.
However, a source code analysis, an strace, and actually trying to put
configuration options in this file show that it is never read.
This is because only Python (with a .py extension) or JSON (with a
.json extension) files are supported, as you can check in method
_load_config_files() of
/usr/lib/python3/dist-packages/traitlets/config/application.py
Dynamically, launching:
/var/lib/jupyterhub# strace -tt -ff -o jupyterhub.strace /usr/bin/python3 -m
jupyterhub.app -f /etc/jupyterhub/config/jupyterhub_config.d/config.yaml
--upgrade-db
confirms that the file is not read by analysis of the resulting straces.
Another way to check is to simply modify the config.yaml file and see
that no option we put in there have any effect.
Due to how _load_config_files() works, i.e. ignoring the extension and trying
to load .py and .json files on the basename, we can however create a new file
/etc/jupyterhub/config/jupyterhub_config.d/config.json, and its content
is taken into account (without even changing the command line). See examples
at the end.
I suggest to remove the config.yaml file from the package, and
to modify the command line used to launch JupyterHub to:
/usr/bin/python3 -m jupyterhub.app -f /etc/jupyterhub/jupyterhub_config.py
--upgrade-db
I'm also unsure about the effect of
/etc/jupyterhub/config/jupyterhub_config.d/50-use-configurable-http-proxy.py
I suspect it has no effect. In any case it does not appear in the
straces. The whole /etc/jupyterhub/config subtree should maybe be removed.
-- System Information:
Debian Release: 12.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-0.deb11.7-amd64 (SMP w/62 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages jupyterhub depends on:
ii fonts-font-awesome5.0.10+really4.7.0~dfsg-4.1
ii libjs-bootstrap 3.4.1+dfsg-3
ii libjs-jquery 3.6.1+dfsg+~3.5.14-1
ii libjs-prototype 1.7.3-1
ii libjs-requirejs 2.3.6+ds+~2.1.34-2
ii node-configurable-http-proxy 4.5.3+~cs15.2.4-3
ii python3 3.11.2-1+b1
ii python3-alembic 1.8.1-2
ii python3-async-generator 1.10-4
ii python3-bcrypt3.2.2-1
ii python3-certipy 0.1.3-4
ii python3-dateutil 2.8.2-2
ii python3-jinja23.1.2-1
ii python3-jupyter-telemetry 0.1.0-4
ii python3-notebook 6.4.12-2.2
ii python3-oauthlib 3.2.2-1
ii python3-packaging 23.0-1
ii python3-pamela1.0.0-3
ii python3-prometheus-client 0.16.0-0.1
ii python3-requests 2.28.1+dfsg-1
ii python3-sqlalchemy1.4.46+ds1-1
ii python3-tornado 6.2.0-3
ii python3-traitlets 5.5.0-1
jupyterhub recommends no packages.
jupyterhub suggests no packages.
-- Configuration Files:
/etc/jupyterhub/config/jupyterhub_config.d/config.yaml changed:
---
Application:
show_config_json: true
JupyterHub:
port:
-- no debconf information
*** /etc/jupyterhub/config/jupyterhub_config.d/config.json
{
"Application": {
"show_config_json": true
},
"JupyterHub": {
"port":
}
}
Bug#1033671: MD5File() goes into an unconditional infinite loop on bullseye
Package: libbsd0
Version: 0.11.3-1
Tags: patch,upstream,fixed-upstream,bullseye
MD5File in bullseye is essentially an infinite loop. It just calls
itself.
The simplest fix is
--- a/src/md5.c
+++ b/src/md5.c
@@ -105,7 +105,7 @@
MD5File(const char *filename, char *buf)
{
libmd_wrapper(MD5File);
- return MD5File(filename, buf);
+ return libmd_MD5File(filename, buf);
}
char *
This was fixed upstream by
https://gitlab.freedesktop.org/libbsd/libbsd/-/commit/e7cf8c5785b14fc8fbd37bb665a5f9a4f28c7888
--
Guillaume Morin
Bug#1032020: [pkg-apparmor] Bug#1032020: chromium: Missing character after Chromium AppArmor profile update opens up unrestricted system browsing.
Hi, Thanks for clearing it up. I might just take time and find that faulty profile if it ever existed. Thanks for clearing everything up. Cheers On Wed, Mar 1, 2023, 09:48 intrigeri wrote: > Control: tag -1 + unreproducible > Control: severity -1 minor > > Hi, > > Guillaume B. (2023-02-28): > > Installing fresh sid profiles with both previously stated packages > (version > > 3.0.8-3 and 1.35 respectively), I have not seen that specific mistake > made. > > > > It may have come from a loose AppArmor profile but, just to be sure, no > > such open "/** r," found in latest sid-provided > > apparmor-profiles/apparmor-profiles-extra Chromium AppArmor profile. > > I've looked at the Git history of the relevant apparmor* packages and > found no trace of them having ever distributed a Chromium profile > with a "/** r," rule. > > > dpkg-query: no path found matching pattern > /etc/apparmor.d/usr.bin.chromium > > This shows that no Debian package is currently maintaining that file. > > Frankly, I have no idea how this rule landed on your filesystem, but > I really don't see how this problem could have been directly caused by > a Debian package or upgrade. > > Cheers, > -- > intrigeri >
Bug#1032020: chromium: Missing character after Chromium AppArmor profile update opens up unrestricted system browsing.
Start quote -> " You mean Debian maintenance team, right? If you pulled in an Ubuntu apparmor package, that's a different story (and we should close this bug). If you're using Debian's apparmor-profiles package, then the bug and fix should go there. Although, if you're pulling in an Ubuntu package to get some kind of apparmor protection that Debian doesn't have, you also might want to open a wishlist bug on the Debian package asking for the feature so you don't have to mix-and-match packages across different distributions." /// I am, honestly, as confused as you. I've had profiles from the apparmor-profiles and apparmor-profiles-extra packages for a long time. This time around, though, I did not have either packages installed all the while having active apparmor.d profiles. Installing fresh sid profiles with both previously stated packages (version 3.0.8-3 and 1.35 respectively), I have not seen that specific mistake made. It may have come from a loose AppArmor profile but, just to be sure, no such open "/** r," found in latest sid-provided apparmor-profiles/apparmor-profiles-extra Chromium AppArmor profile. Cheers On Mon, Feb 27, 2023, 20:45 Andres Salomon wrote: > Control: reassign -1 apparmor-profiles > > > > On Mon, Feb 27 2023 at 08:15:37 PM +0100, Guillaume B. > wrote: > > Hi, > > > > It seems that the previous emails in our exchange got nuked out my > > account so apologies for not being able to reply using the usual > > channels. > > > > The command 'find /etc/apparmor* -name "*hromium*" | xargs dpkg -S' > > returns the following -> "dpkg-query: no path found matching pattern > > /etc/apparmor.d/usr.bin.chromium > > lightdm: /etc/apparmor.d/abstractions/lightdm_chromium-browser" > > > > /// > > > > I'm using AppArmor profiles found in the "apparmor-profiles" package. > > Having recently updated from stable, I was able to keep the profiles > > without the package being installed; i.e., the update couldn't have > > come from an apparmor-profile package update. > > > Ah, okay, that makes more sense. Reassigning to the apparmor-profiles > package, then. > > > > > > Dealing with the issue, I have not made a backup of the updated > > Chromium AppArmor profile but simply did some file comparison and > > reverted to a previous profile, nuking the updated profile in the > > copying process. > > > > The "updated" AppArmor profile was dated either january or february > > of this year and had been modified by an Ubuntu email. > > > > TLDR; There was an update to the Chromium AppArmor profile, not sure > > how, but it happened. > > > > I might just take it up with the Ubuntu Chromium AppArmor profile > > maintenance team, in which case, sorry to have wasted your time. > > > > Regards > > > > You mean Debian maintenance team, right? If you pulled in an Ubuntu > apparmor package, that's a different story (and we should close this > bug). If you're using Debian's apparmor-profiles package, then the bug > and fix should go there. Although, if you're pulling in an Ubuntu > package to get some kind of apparmor protection that Debian doesn't > have, you also might want to open a wishlist bug on the Debian package > asking for the feature so you don't have to mix-and-match packages > across different distributions. > > > >
Bug#1032020: chromium: Missing character after Chromium AppArmor profile update opens up unrestricted system browsing.
Hi Andres, Will take care of it tonight. Regards On Sun, Feb 26, 2023, 22:58 Andres Salomon wrote: > Hi, > > I'm a bit confused by this bug report, as chromium doesn't include any > apparmor profiles. > > Please run the following commands to hopefully figure out what package > is actually providing the profile: > > find /etc/apparmor* -name "*hromium*" | xargs dpkg -S > > Thanks, > Andres > > On Sun, Feb 26 2023 at 05:48:38 PM +0100, Will B. > wrote: > > Package: chromium > > Version: 110.0.5481.177-1 > > Severity: important > > Tags: upstream > > X-Debbugs-Cc: ksu...@gmail.com > > > > Dear Maintainer, > > > > Before I begin, the Chromium AppArmor profile in Sid was updated > > after apt-get > > update && apt-get upgrade. > > Please redirect to relevant authority if Chromium reportbug is not > > the right > > source. > > > >/// > > > > * What led up to the situation? -> Chromium AppArmor profile update > > after apt- > > get update && apt-get upgrade. > > * What exactly did you do (or not do) that was effective (or > > ineffective)? -> > > fixed the issue by adding a missing "/" to the profile. > > * What was the outcome of this action? -> The Chromium AppArmor > > profile > > restricted access as it should have done. > > * What outcome did you expect instead? -> None, fix fixed it. > > > > /// > > > > Hi, > > > > After a Chromium Sid update in which the AppArmor profile was updated > > (last > > date -> 02/07/2023), > > a missing "/" opened up browsing to the whole system i.e. -> "/** r," > > instead > > of "/**/ r,". > > Switching to the "enclosed" stars symbol fixes the issue. > > > > Regards > > > > > > -- System Information: > > Debian Release: bookworm/sid > > APT prefers testing > > APT policy: (990, 'testing'), (50, 'unstable') > > Architecture: amd64 (x86_64) > > Foreign Architectures: i386 > > > > Kernel: Linux 6.1.0-3-amd64 (SMP w/12 CPU threads; PREEMPT) > > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > > LANGUAGE=en_US:en > > Shell: /bin/sh linked to /usr/bin/dash > > Init: systemd (via /run/systemd/system) > > LSM: AppArmor: enabled > > > > Versions of packages chromium depends on: > > ii chromium-common > > 110.0.5481.177-1 > > ii libasound2 1.2.8-1+b1 > > ii libatk-bridge2.0-0 2.46.0-5 > > ii libatk1.0-0 2.46.0-5 > > ii libatomic1 12.2.0-14 > > ii libatspi2.0-02.46.0-5 > > ii libbrotli1 1.0.9-2+b6 > > ii libc62.36-8 > > ii libcairo21.16.0-7 > > ii libcups2 2.4.2-1+b2 > > ii libdbus-1-3 1.14.6-1 > > ii libdouble-conversion33.2.1-1 > > ii libdrm2 2.4.114-1 > > ii libevent-2.1-7 > > 2.1.12-stable-5+b1 > > ii libexpat12.5.0-1 > > ii libflac121.4.2+ds-2 > > ii libfontconfig1 2.14.1-4 > > ii libfreetype6 2.12.1+dfsg-4 > > ii libgbm1 22.3.3-1 > > ii libgcc-s112.2.0-14 > > ii libglib2.0-0 2.74.5-1 > > ii libgtk-3-0 3.24.36-4 > > ii libjpeg62-turbo 1:2.1.5-2 > > ii libjsoncpp25 1.9.5-4 > > ii liblcms2-2 2.14-1+b1 > > ii libminizip1 1.1-8+b1 > > ii libnspr4 2:4.35-1 > > ii libnss3 2:3.87.1-1 > > ii libopenjp2-7 2.5.0-1+b1 > > ii libopus0 1.3.1-3 > > ii libpango-1.0-0 1.50.12+ds-1 > > ii libpng16-16 1.6.39-2 > > ii libpulse0 > > 16.1+dfsg1-2+b1 > > ii libre2-9 > > 20220601+dfsg-1+b1 > > ii libsnappy1v5 1.1.9-2 > > ii libstdc++6 12.2.0-14 > > ii libwebp7 1.2.4-0.1 > > ii libwebpdemux21.2.4-0.1 > > ii libwebpmux3 1.2.4-0.1 > > ii libwoff1 1.0.2-2 > > ii libx11-6 2:1.8.3-3 > > ii libxcb1
Bug#1028496: nvidia-driver: Geforce RTX 4070 Ti not supported with driver before 525.78.01
Package: nvidia-driver Version: 470.161.03-1 Severity: wishlist Dear maintainer, A new graphic card has been released (RTX 4070 Ti) but it requires the lastest version of driver (v525.78.01). Please consider packaging this version. Thanks. Best regards -- Package-specific info: uname -a: Linux amaterasu 5.10.0-20-amd64 #1 SMP Debian 5.10.158-2 (2022-12-13) x86_64 GNU/Linux /proc/version: Linux version 5.10.0-20-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.158-2 (2022-12-13) /proc/driver/nvidia/version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 470.161.03 Wed Oct 19 00:10:36 UTC 2022 GCC version: gcc version 10.2.1 20210110 (Debian 10.2.1-6) lspci 'display controller [030?]': 26:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU104 [GeForce RTX 2070 SUPER] [10de:1e84] (rev a1) (prog-if 00 [VGA controller]) Subsystem: Micro-Star International Co., Ltd. [MSI] TU104 [GeForce RTX 2070 SUPER] [1462:c726] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: nvidia Kernel modules: nvidia dmesg: Device node permissions: crw-rw+ 1 root video 226, 0 Jan 11 20:11 /dev/dri/card0 crw-rw+ 1 root render 226, 128 Jan 11 20:11 /dev/dri/renderD128 crw-rw-rw- 1 root root 195, 254 Jan 11 20:11 /dev/nvidia-modeset crw-rw-rw- 1 root root 195, 0 Jan 11 20:11 /dev/nvidia0 crw-rw-rw- 1 root root 195, 255 Jan 11 20:11 /dev/nvidiactl /dev/dri/by-path: total 0 lrwxrwxrwx 1 root root 8 Jan 11 20:11 pci-:26:00.0-card -> ../card0 lrwxrwxrwx 1 root root 13 Jan 11 20:11 pci-:26:00.0-render -> ../renderD128 video:x:44:guillaume Alternative 'nvidia': nvidia - auto mode link best version is /usr/lib/nvidia/current link currently points to /usr/lib/nvidia/current link nvidia is /usr/lib/nvidia/nvidia slave nvidia--libEGL_nvidia.so.0-i386-linux-gnu is /usr/lib/i386-linux-gnu/libEGL_nvidia.so.0 slave nvidia--libEGL_nvidia.so.0-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libEGL_nvidia.so.0 slave nvidia--libGLESv1_CM_nvidia.so.1-i386-linux-gnu is /usr/lib/i386-linux-gnu/libGLESv1_CM_nvidia.so.1 slave nvidia--libGLESv1_CM_nvidia.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libGLESv1_CM_nvidia.so.1 slave nvidia--libGLESv2_nvidia.so.2-i386-linux-gnu is /usr/lib/i386-linux-gnu/libGLESv2_nvidia.so.2 slave nvidia--libGLESv2_nvidia.so.2-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libGLESv2_nvidia.so.2 slave nvidia--libGLX_nvidia.so.0-i386-linux-gnu is /usr/lib/i386-linux-gnu/libGLX_nvidia.so.0 slave nvidia--libGLX_nvidia.so.0-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0 slave nvidia--libcuda.so-i386-linux-gnu is /usr/lib/i386-linux-gnu/libcuda.so slave nvidia--libcuda.so-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libcuda.so slave nvidia--libcuda.so.1-i386-linux-gnu is /usr/lib/i386-linux-gnu/libcuda.so.1 slave nvidia--libcuda.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libcuda.so.1 slave nvidia--libglxserver_nvidia.so is /usr/lib/nvidia/libglxserver_nvidia.so slave nvidia--libnvcuvid.so-i386-linux-gnu is /usr/lib/i386-linux-gnu/libnvcuvid.so slave nvidia--libnvcuvid.so-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libnvcuvid.so slave nvidia--libnvcuvid.so.1-i386-linux-gnu is /usr/lib/i386-linux-gnu/libnvcuvid.so.1 slave nvidia--libnvcuvid.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libnvcuvid.so.1 slave nvidia--libnvidia-allocator.so.1-i386-linux-gnu is /usr/lib/i386-linux-gnu/libnvidia-allocator.so.1 slave nvidia--libnvidia-allocator.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libnvidia-allocator.so.1 slave nvidia--libnvidia-cfg.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1 slave nvidia--libnvidia-encode.so.1-i386-linux-gnu is /usr/lib/i386-linux-gnu/libnvidia-encode.so.1 slave nvidia--libnvidia-encode.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libnvidia-encode.so.1 slave nvidia--libnvidia-fbc.so.1-i386-linux-gnu is /usr/lib/i386-linux-gnu/libnvidia-fbc.so.1 slave nvidia--libnvidia-fbc.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libnvidia-fbc.so.1 slave nvidia--libnvidia-ifr.so.1-i386-linux-gnu is /usr/lib/i386-linux-gnu/libnvidia-ifr.so.1 slave nvidia--libnvidia-ifr.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libnvidia-ifr.so.1 slave nvidia--libnvidia-ml.so.1-i386-linux-gnu is /usr/lib/i386-linux-gnu/libnvidia-ml.so.1 slave nvidia--libnvidia-ml.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libnvidia-ml.so.1 slave nvidia--libnvidia-ngx.so.1-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libnvidia-ngx.so.1 slave nvidia--libnvidia-opencl.so.1-x86_64-linux-gnu is /usr/lib/x86_64-li
Bug#1025618: cloud-init and firewalld systemd unit files have ordering cycles
Hi Ross, > Should we consider adding "Conflicts: firewalld" to cloud-init before > the freeze? That's not optimal of course, but it'd prevent a user from > ending up in this situation for now. Is there a way to bypass "Conflicts" and install such packages anyway, in case the user finds a way to customize the configuration in a way that fits their needs? For example, on one of my systems I kept cloud-init installed for now, but I disabled and masked cloud-init.service. Cheers! Guillaume
Bug#1025618: cloud-init and firewalld systemd unit files have ordering cycles
ne.service -> systemd-networkd.service systemd-networkd.service -> network-pre.target -> firewalld.service -> basic.target -> sockets.target -> cloud-init-hotplugd.socket -> sysinit.target -> cloud-init.service -> systemd-networkd-wait-online.service -> systemd-networkd.service systemd-networkd.service -> network-pre.target -> firewalld.service -> basic.target -> sockets.target -> dbus.socket -> sysinit.target -> cloud-init.service -> systemd-networkd-wait-online.service -> systemd-networkd.service systemd-networkd.service -> network-pre.target -> firewalld.service -> basic.target -> systemd-pcrphase-sysinit.service -> sysinit.target -> cloud-init.service -> systemd-networkd-wait-online.service -> systemd-networkd.service systemd-networkd.service -> network-pre.target -> firewalld.service -> dbus.socket -> sysinit.target -> cloud-init.service -> systemd-networkd-wait-online.service -> systemd-networkd.service systemd-networkd.service -> network-pre.target -> firewalld.service -> dbus.service -> basic.target -> sysinit.target -> cloud-init.service -> systemd-networkd-wait-online.service -> systemd-networkd.service systemd-networkd.service -> network-pre.target -> firewalld.service -> dbus.service -> basic.target -> sockets.target -> cloud-init-hotplugd.socket -> sysinit.target -> cloud-init.service -> systemd-networkd-wait-online.service -> systemd-networkd.service systemd-networkd.service -> network-pre.target -> firewalld.service -> dbus.service -> basic.target -> sockets.target -> dbus.socket -> sysinit.target -> cloud-init.service -> systemd-networkd-wait-online.service -> systemd-networkd.service systemd-networkd.service -> network-pre.target -> firewalld.service -> dbus.service -> basic.target -> systemd-pcrphase-sysinit.service -> sysinit.target -> cloud-init.service -> systemd-networkd-wait-online.service -> systemd-networkd.service systemd-networkd.service -> network-pre.target -> firewalld.service -> dbus.service -> sysinit.target -> cloud-init.service -> systemd-networkd-wait-online.service -> systemd-networkd.service systemd-networkd.service -> network-pre.target -> firewalld.service -> dbus.service -> dbus.socket -> sysinit.target -> cloud-init.service -> systemd-networkd-wait-online.service -> systemd-networkd.service systemd-networkd.service -> network-pre.target -> firewalld.service -> polkit.service -> dbus.socket -> sysinit.target -> cloud-init.service -> systemd-networkd-wait-online.service -> systemd-networkd.service systemd-networkd.service -> network-pre.target -> firewalld.service -> polkit.service -> basic.target -> sysinit.target -> cloud-init.service -> systemd-networkd-wait-online.service -> systemd-networkd.service systemd-networkd.service -> network-pre.target -> firewalld.service -> polkit.service -> basic.target -> sockets.target -> cloud-init-hotplugd.socket -> sysinit.target -> cloud-init.service -> systemd-networkd-wait-online.service -> systemd-networkd.service systemd-networkd.service -> network-pre.target -> firewalld.service -> polkit.service -> basic.target -> sockets.target -> dbus.socket -> sysinit.target -> cloud-init.service -> systemd-networkd-wait-online.service -> systemd-networkd.service systemd-networkd.service -> network-pre.target -> firewalld.service -> polkit.service -> basic.target -> systemd-pcrphase-sysinit.service -> sysinit.target -> cloud-init.service -> systemd-networkd-wait-online.service -> systemd-networkd.service systemd-networkd.service -> network-pre.target -> firewalld.service -> polkit.service -> sysinit.target -> cloud-init.service -> systemd-networkd-wait-online.service -> systemd-networkd.service Best regards, Guillaume Knispel -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-19-amd64 (SMP w/64 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 cloud-init depends on: ii fdisk 2.36.1-8+deb11u1 ii gdisk 1.0.6-1.1 ii ifupdown0.8.36 ii locales 2.31-13+deb11u5 ii lsb-base11.1.0 ii lsb-release 11.1.0 ii net-tools 1.60+git20181103.0eebece-1 ii procps 2:3.3.17-5 ii python3 3.9.2-3 ii python3-configobj 5.0.6-4 ii python3-jinja2 2.11.3-1 ii python3-jsonpatch 1.25-3 ii python3-jsonschema 3.2.0-3 ii python3-oauthlib3.1.0-2 ii python3-requests2.25.1+dfsg-2 ii python3-yaml5.3.1-5 ii util-linux 2.36.1-8+deb11u1 Versions of packages cloud-init recommends: ii cloud-guest-utils 0.31-2 ii eatmydata 105-9 ii sudo 1.9.5p2-3 Versions of packages cloud-init suggests: pn btrfs-progs ii e2fsprogs1.46.2-2 pn xfsprogs -- no debconf information
Bug#1025616: firewalld and cloud-init systemd unit files have ordering cycles
; systemd-networkd.service systemd-networkd.service -> network-pre.target -> firewalld.service -> basic.target -> sockets.target -> cloud-init-hotplugd.socket -> sysinit.target -> cloud-init.service -> systemd-networkd-wait-online.service -> systemd-networkd.service systemd-networkd.service -> network-pre.target -> firewalld.service -> basic.target -> sockets.target -> dbus.socket -> sysinit.target -> cloud-init.service -> systemd-networkd-wait-online.service -> systemd-networkd.service systemd-networkd.service -> network-pre.target -> firewalld.service -> basic.target -> systemd-pcrphase-sysinit.service -> sysinit.target -> cloud-init.service -> systemd-networkd-wait-online.service -> systemd-networkd.service systemd-networkd.service -> network-pre.target -> firewalld.service -> dbus.socket -> sysinit.target -> cloud-init.service -> systemd-networkd-wait-online.service -> systemd-networkd.service systemd-networkd.service -> network-pre.target -> firewalld.service -> dbus.service -> basic.target -> sysinit.target -> cloud-init.service -> systemd-networkd-wait-online.service -> systemd-networkd.service systemd-networkd.service -> network-pre.target -> firewalld.service -> dbus.service -> basic.target -> sockets.target -> cloud-init-hotplugd.socket -> sysinit.target -> cloud-init.service -> systemd-networkd-wait-online.service -> systemd-networkd.service systemd-networkd.service -> network-pre.target -> firewalld.service -> dbus.service -> basic.target -> sockets.target -> dbus.socket -> sysinit.target -> cloud-init.service -> systemd-networkd-wait-online.service -> systemd-networkd.service systemd-networkd.service -> network-pre.target -> firewalld.service -> dbus.service -> basic.target -> systemd-pcrphase-sysinit.service -> sysinit.target -> cloud-init.service -> systemd-networkd-wait-online.service -> systemd-networkd.service systemd-networkd.service -> network-pre.target -> firewalld.service -> dbus.service -> sysinit.target -> cloud-init.service -> systemd-networkd-wait-online.service -> systemd-networkd.service systemd-networkd.service -> network-pre.target -> firewalld.service -> dbus.service -> dbus.socket -> sysinit.target -> cloud-init.service -> systemd-networkd-wait-online.service -> systemd-networkd.service systemd-networkd.service -> network-pre.target -> firewalld.service -> polkit.service -> dbus.socket -> sysinit.target -> cloud-init.service -> systemd-networkd-wait-online.service -> systemd-networkd.service systemd-networkd.service -> network-pre.target -> firewalld.service -> polkit.service -> basic.target -> sysinit.target -> cloud-init.service -> systemd-networkd-wait-online.service -> systemd-networkd.service systemd-networkd.service -> network-pre.target -> firewalld.service -> polkit.service -> basic.target -> sockets.target -> cloud-init-hotplugd.socket -> sysinit.target -> cloud-init.service -> systemd-networkd-wait-online.service -> systemd-networkd.service systemd-networkd.service -> network-pre.target -> firewalld.service -> polkit.service -> basic.target -> sockets.target -> dbus.socket -> sysinit.target -> cloud-init.service -> systemd-networkd-wait-online.service -> systemd-networkd.service systemd-networkd.service -> network-pre.target -> firewalld.service -> polkit.service -> basic.target -> systemd-pcrphase-sysinit.service -> sysinit.target -> cloud-init.service -> systemd-networkd-wait-online.service -> systemd-networkd.service systemd-networkd.service -> network-pre.target -> firewalld.service -> polkit.service -> sysinit.target -> cloud-init.service -> systemd-networkd-wait-online.service -> systemd-networkd.service Best regards, Guillaume Knispel -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-19-amd64 (SMP w/64 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 firewalld depends on: ii dbus 1.12.24-0+deb11u1 ii gir1.2-glib-2.0 1.66.1-1+b1 ii gir1.2-nm-1.0 1.30.6-1+deb11u1 ii iptables 1.8.7-1 ii policykit-1 0.105-31+deb11u1 ii python3 3.9.2-3 ii python3-dbus 1.2.16-5 ii python3-firewall 0.9.3-2 ii python3-gi3.38.0-2 ii python3-nftables 0.9.8-3.1 Versions of packages firewalld recommends: ii ipset 7.10-1 firewalld suggests no packages. -- Configuration Files: /etc/firewalld/firewalld.conf [Errno 13] Permission denied: '/etc/firewalld/firewalld.conf' /etc/firewalld/lockdown-whitelist.xml [Errno 13] Permission denied: '/etc/firewalld/lockdown-whitelist.xml' -- no debconf information
Bug#1021973: iconv: undefined symbol after upgrade
I think it was when a libc6 update broke NSS sometime in 2017, though I can
find only a reference to it in the Ubuntu bug tracker.
https://launchpad.net/ubuntu/+source/glibc/2.23-0ubuntu6
We could certainly unblacklist libc6 or blacklist both. I personally think
libc-bin should depend on an equivalent libc6 version but if you don't want
to make the change it's understandable as well
Regards
Guillaume
On Tue, 18 Oct 2022 at 12:11, Emilio Pozuelo Monfort
wrote:
> On 18/10/2022 11:59, Guillaume Lefranc wrote:
> > Yes.
> > The upgrade was automatically done by unattended-upgrades, but we have
> > libc6 blacklisted due to issues we encountered previously
>
> What kind of issues? Are they still relevant? Is there a bug report we
> could
> look at?
>
> In this case, I suggest you also block/pin libc-bin to the same version as
> libc6.
>
> Helmut, libc-bin could have a depends on libcX (>= ${binary:Version}),
> although
> this is such a corner case that I don't think an update is necessary just
> for this.
>
> Cheers,
> Emilio
>
> >
> > Unattended-Upgrade::Origins-Pattern {
> >
> "origin=Debian,codename=${distro_codename},label=Debian-Security";
> > };
> >
> > Unattended-Upgrade::Package-Blacklist {
> >"libc6";
> > };
> >
> > On Tue, 18 Oct 2022 at 09:23, Emilio Pozuelo Monfort
> > wrote:
> >
> >> On 18/10/2022 09:13, Guillaume Lefranc wrote:
> >>> Package: libc-bin
> >>> Version: 2.28-10+deb10u2
> >>> Severity: normal
> >>>
> >>> Dear Maintainer,
> >>>
> >>> after upgrading libc-bin from 2.28-10+deb10u1 to 2.28-10+deb10u2, the
> >> following error appeared after running iconv the following way:
> >>>
> >>> iconv -cs -f 'UTF-8' -t 'UTF-8' /tmp/510754/import/import.1
> >>>
> >>> iconv: relocation error: iconv: symbol __gconv_create_spec version
> >> GLIBC_PRIVATE not defined in file libc.so.6 with link time reference
> >>
> >> Any particular reason you upgraded libc-bin but not libc6?
> >>
> >> Cheers,
> >> Emilio
> >>
> >
> >
>
>
Bug#1021973: iconv: undefined symbol after upgrade
Yes.
The upgrade was automatically done by unattended-upgrades, but we have
libc6 blacklisted due to issues we encountered previously
Unattended-Upgrade::Origins-Pattern {
"origin=Debian,codename=${distro_codename},label=Debian-Security";
};
Unattended-Upgrade::Package-Blacklist {
"libc6";
};
On Tue, 18 Oct 2022 at 09:23, Emilio Pozuelo Monfort
wrote:
> On 18/10/2022 09:13, Guillaume Lefranc wrote:
> > Package: libc-bin
> > Version: 2.28-10+deb10u2
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > after upgrading libc-bin from 2.28-10+deb10u1 to 2.28-10+deb10u2, the
> following error appeared after running iconv the following way:
> >
> > iconv -cs -f 'UTF-8' -t 'UTF-8' /tmp/510754/import/import.1
> >
> > iconv: relocation error: iconv: symbol __gconv_create_spec version
> GLIBC_PRIVATE not defined in file libc.so.6 with link time reference
>
> Any particular reason you upgraded libc-bin but not libc6?
>
> Cheers,
> Emilio
>
--
*Guillaume Lefranc* | Director of Engineering - Technical Operations
g...@productsup.com | +33 6 82 42 58 93 <+4930609858366>
www.productsup.com
*Products Up GmbH*
A globally operative company - *office locations*
<https://www.productsup.com/home/#contact-form__container>
HQ: Alex-Wedding-Str. 5, 10178 Berlin, Germany
HRB 214376 B Berlin Charlottenburg; VAT ID DE270578435; Tax No. 30/479/35480
Bug#1021973: iconv: undefined symbol after upgrade
Package: libc-bin Version: 2.28-10+deb10u2 Severity: normal Dear Maintainer, after upgrading libc-bin from 2.28-10+deb10u1 to 2.28-10+deb10u2, the following error appeared after running iconv the following way: iconv -cs -f 'UTF-8' -t 'UTF-8' /tmp/510754/import/import.1 iconv: relocation error: iconv: symbol __gconv_create_spec version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference -- System Information: Debian Release: 10.2 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/12 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 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 libc-bin depends on: ii libc6 2.28-10 Versions of packages libc-bin recommends: ii manpages 4.16-2 libc-bin suggests no packages. -- no debconf information
Bug#1020669: O: geneweb -- genealogy software with web interface
Package: wnpp Severity: normal I intend to orphan the geneweb source package, a 24 year old genealogy software with web interface. I don't have the time to make the required major changes to the package, but I would be pleased to help the new maintainer to ease the transition. Also, Debian developer Sébastien Villemot , which was my sponsor for the uploads over the years, told me that he would accept to continue in his role if the new maintainer is not a Debian developer. Package info : https://tracker.debian.org/pkg/geneweb Upstream repo : https://github.com/geneweb/geneweb Package repo : https://salsa.debian.org/GuillaumeBrochu-guest/geneweb The current geneweb package (6.08+git20181019+dfsg-3) is no longer buildable (FTBFS) with the current camlp5 version in testing (see bug #1002979). Therefore the first task of the new maintainer will be to migrate to geneweb 7 (latest formal release : https://github.com/geneweb/geneweb/releases/tag/v7.0.0, see #986285). Since the database format is changing with major version 7 (with the addition of personal and family "events"), all user databases would have to be saved in .gw format first, ideally with a maintainer script. Also : - The sub-folder structure of geneweb 7 is totally different. All the scripts and patches must be reworked or rethinked accordingly. - The daemon scripts for geneweb and gwsetup would probably need to be rewritten or rethinked for systemd. - The binary package geneweb-gui which is no longer available upstream will have to be removed (#953367, #967383) Do not hesitate to contact me if you need additional information. With best regards, Guillaume Brochu guillaume.bro...@gmail.com
Bug#1020647: jupyterhub: 'info jupyterhub' displays the manpage although it suggests 'info' to get the full doc
Package: jupyterhub Version: 2.0.0+ds1-2 Severity: normal X-Debbugs-Cc: gknis...@australdx.fr Dear Maintainer, 'man jupyterhub' ends with: > The full documentation for jupyterhub is maintained as a Texinfo manual. If > the info and jupyterhub programs are properly installed at your site, the > command > info jupyterhub > should give you access to the complete manual. although when I then installed 'info' and tried 'info jupyterhub', I got the same manpage, whereas I expected a more extensive documentation. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.19.0-1-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages jupyterhub depends on: ii fonts-font-awesome5.0.10+really4.7.0~dfsg-4.1 ii libjs-bootstrap 3.4.1+dfsg-2 ii libjs-jquery 3.6.1+dfsg+~3.5.14-1 ii libjs-prototype 1.7.3-1 ii libjs-requirejs 2.3.6+ds+~2.1.34-1 ii node-configurable-http-proxy 4.5.3+~cs15.2.4-1 ii python3 3.10.6-1 ii python3-alembic 1.7.6-1 ii python3-async-generator 1.10-3 ii python3-bcrypt3.2.0-1+b2 ii python3-certipy 0.1.3-3 ii python3-dateutil 2.8.1-6 ii python3-entrypoints 0.4-1 ii python3-jinja23.0.3-2 ii python3-jupyter-telemetry 0.1.0-4 ii python3-notebook 6.4.8-2 ii python3-oauthlib 3.2.1-1 ii python3-packaging 21.3-1.1 ii python3-pamela1.0.0-2 ii python3-prometheus-client 0.9.0-1 ii python3-requests 2.27.1+dfsg-1 ii python3-sqlalchemy1.4.31+ds1-1 ii python3-tornado 6.2.0-1 ii python3-traitlets 5.4.0-1 jupyterhub recommends no packages. jupyterhub suggests no packages. -- no debconf information
Bug#1015016: reportbug: wfuzz should "Depends: python3-distutils"
Package: wfuzz Version: 3.1.0-1 Severity: important X-Debbugs-Cc: debian.fm...@guillaume-d.info Dear maintainer(s), wfuzz seems to needs python3-distutils. However the dependency is missing from "Depends:". It probably only work for people who have python3-full and/or python3-all installed, but both are optional packages, and lots of other Python packages work without them installed. The Pycurl warning below maybe also needs addressing, but that would be another bug. See below for some logs: $ sudo apt remove python3-distutils Reading package lists... Done Building dependency tree... Done Reading state information... Done Package 'python3-distutils' is not installed, so not removed 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. $ wfuzz -dry-run -w /usr/share/wfuzz/wordlist/general/test.txt -u http://127.0.0.1/FUZZ /usr/lib/python3/dist-packages/wfuzz/__init__.py:34: UserWarning:Pycurl is not compiled against Openssl. Wfuzz might not work correctly when fuzzing SSL sites. Check Wfuzz's documentation for more information. libraries.FileLoader: CRITICAL __load_py_from_file. Filename: /usr/lib/python3/dist-packages/wfuzz/helpers/../plugins/payloads/hexrand.py Exception, msg=cannot import name 'util' from 'distutils' (/usr/lib/python3.9/distutils/__init__.py) [...just more of the same with all other payload plugins...] libraries.FileLoader: CRITICAL __load_py_from_file. Filename: /usr/lib/python3/dist-packages/wfuzz/helpers/../plugins/payloads/shodanp.py Exception, msg=cannot import name 'util' from 'distutils' (/usr/lib/python3.9/distutils/__init__.py) /usr/lib/python3/dist-packages/wfuzz/wfuzz.py:78: UserWarning:Fatal exception: Requested plugin file. Error: 'No plugins found!' $ sudo apt install python3-distutils Reading package lists... Done Building dependency tree... Done Reading state information... Done The following additional packages will be installed: python3-lib2to3 The following NEW packages will be installed: python3-distutils python3-lib2to3 0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded. [...] Setting up python3-lib2to3 (3.9.2-1) ... Setting up python3-distutils (3.9.2-1) ... $ wfuzz -dry-run -w /usr/share/wfuzz/wordlist/general/test.txt -u http://127.0.0.1/FUZZ /usr/lib/python3/dist-packages/wfuzz/__init__.py:34: UserWarning:Pycurl is not compiled against Openssl. Wfuzz might not work correctly when fuzzing SSL sites. Check Wfuzz's documentation for more information. * Wfuzz 3.1.0 - The Web Fuzzer * Target: http://127.0.0.1/FUZZ Total requests: 10 = ID Response LinesWord Chars Payload = 9: 4049 L 31 W 271 Ch "scripts" 6: 4049 L 31 W 271 Ch "includes" 2: 4049 L 31 W 271 Ch "css" 00010: 4049 L 31 W 271 Ch "test" 3: 4049 L 31 W 271 Ch "docs" 7: 4049 L 31 W 271 Ch "master" 5: 4049 L 31 W 271 Ch "images" 1: 4049 L 31 W 271 Ch "classes" 8: 4049 L 31 W 271 Ch "prueba" 4: 4049 L 31 W 271 Ch "environment" Total time: 0.040024 Processed Requests: 10 Filtered Requests: 0
Bug#706927: lintian: doc-base-file-lacks-required-field or doc-base-file-no-index
Control: tags -1 - moreinfo On Sat, 9 Jul 2022 15:20:57 +0200 =?UTF-8?Q?Guillaume_D=c3=a9flache?= wrote: tags 706927 - moreinfo [...] Also I think no more info is needed here, so removing that bug tag. Let's try that again!
Bug#706927: lintian: doc-base-file-lacks-required-field or doc-base-file-no-index
tags 706927 - moreinfo See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682436#10 for an example of a possible syntax (only "Files", "Index" forbidden) which could also help fixing that other bug. Also I think no more info is needed here, so removing that bug tag.
Bug#682436: does not address the case where a HTML document exists in both single file and multiple file versions
On Sun, 22 Jul 2012 23:50:47 +0530 Faheem Mitha wrote: [...] I can't see any reason why this is not allowed. Regardless, what is the best thing to do in this situation? Register one version and not the other? Suppose that some package contained two completely different html documents. What would one do then? See example below. [...] ## ccl.doc-base ## Document: ccl-manual Title: Debian CCL Manual Author: CCL Developers Abstract: The CCL manual, describing what how to install and use CCL Section: Programming/Common Lisp Format: HTML Index: /usr/share/doc/ccl/ccl-documentation.html Format: HTML Index: /usr/share/doc/ccl/manual/index.html One can at least define two doc-base files with two distinct document IDs, arguably with some duplication. Say: ## ccl.doc-base ## Document: ccl-manual Title: Debian CCL Manual [the rest of the metadata must be duplicated in both files] Format: HTML Index: /usr/share/doc/ccl/manual/index.html Files: /usr/share/doc/ccl/manual/*.html [other non-HTML formats can be left here] ## ccl-html-single.doc-base ## Document: ccl-manual-single-html Title: Debian CCL Manual (single HTML file) [the rest of the metadata must be duplicated in both files] Format: HTML Files: /usr/share/doc/ccl/ccl-documentation.html > Index: /usr/share/doc/ccl/ccl-documentation.html Note than the last Index line in case of a single file documentation is completely redundant but has to be there, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706927 Maybe the following syntax should be allowed for single-page HTML documents, and Index should only be allowed for multiple-page ones, fixing both problems: > Format: HTML > Files: /usr/share/doc/ccl/ccl-documentation.html As the above currently does not work anyway, using that syntax should not cause problems for unmodified existing files.
Bug#1014640: dwww "Depends: apache2 | httpd-cgi" but really only works out-of-the-box with Apache
Package: dwww Version: 1.14 Severity: important X-Debbugs-Cc: debian.fm...@guillaume-d.info Dear Maintainer, dwww seems to really only support automatic configuration for Apache. Installing dwww alone after a non-Apache web server has been installed -- I tried mini-httpd and nginx-light: both provide httpd-cgi -- will not work without further manual HTTP server configuration. IMHO dwww should at least have: Recommends: apache2 ...instead of: Recommends: apache2 | httpd ...so that users get a working dwww at least by default.
Bug#1014637: doc-base: install-docs breaks on spaces in paths of documents' Index and Files
Package: doc-base Version: 0.11.1 Severity: normal X-Debbugs-Cc: debian.fm...@guillaume-d.info Dear Maintainer, Paths with spaces for documents may be not that important for Debian package maintainers, but for system administrators, it would be nicer for such paths to: - either just work (at least as far as doc-base is concerned, dwww and friends being another matter) - or be documented as not supported and/or checked against by `install-docs --check` As the following example shows (I also made other tests with existing files), only the HTML format seems to support spaces but only in the last component of paths! Also it looks like Files patterns that do not match trigger no warning whatsoever, which could be another bug IMHO. $ $ cat test.doc-base Document: doc-base-spaces-in-paths-test Title: whatever Section: Help Format: HTML Index: /usr/local/share/doc/my non-existing path with spaces.html Files: /usr/local/share/doc/my non-existing path with spaces/*.html Format: PDF FIles: /usr/local/share/doc/my-non-existing-path with spaces.pdf Format: Text FIles: /usr/local/share/doc/my-non-existing-path with spaces.txt $ $ sudo LANG= install-docs -i test.doc-base Error in `test.doc-base', line 13: all `Format' sections are invalid. $ $ LANG=C /usr/sbin/install-docs --verbose --check test.doc-base Warning in `test.doc-base', line 8: file `/usr/local/share/doc/my non-existing path with spaces.html' does not exist. Warning in `test.doc-base', line 11: `Files' value has to be specified with absolute path: with spaces.pdf. Warning in `test.doc-base', line 13: `Files' value has to be specified with absolute path: with spaces.txt. Error in `test.doc-base', line 13: all `Format' sections are invalid. test.doc-base: Fatal error found, the file won't be registered. $
Bug#1011146: upgrade-system is marked for autoremoval from testing
Hi all, As other dev/maintainers, I got a the autoremoval notification for package resource-agents-paf, which has nothing to do with nvidia things. Maybe what maintainers should do might be clarified here? Should we just sit & wait for the next notification about the false positive bug being fixed? Regards, On Thu, 26 May 2022 09:31:00 +0300 =?UTF-8?Q?Martin=2D=C3=89ric_Racine?= wrote: > I'd really like to know how anyone could ever come to the conclusion > that a package that has nothing to do with graphic drivers needs to be > auto-removed. > > Martin-Éric > > On Thu, May 26, 2022 at 9:01 AM Debian testing autoremoval watch > wrote: > > > > upgrade-system 1.9.1.0 is marked for autoremoval from testing on 2022-06-30 > > > > It (build-)depends on packages with these RC bugs: > > 1011146: nvidia-graphics-drivers-tesla-470: CVE-2022-28181, CVE-2022-28183, > > CVE-2022-28184, CVE-2022-28185, CVE-2022-28191, CVE-2022-28192 > > https://bugs.debian.org/1011146 > > > > > > > > This mail is generated by: > > https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl > > > > Autoremoval data is generated by: > > https://salsa.debian.org/qa/udd/-/blob/master/udd/testing_autoremovals_gatherer.pl > >
Bug#1006884: libseccomp-dev: Cannot install libseccomp-dev using apt
Package: libseccomp-dev Version: 2.5.1-1 Severity: important Tags: a11y X-Debbugs-Cc: bougui...@gmail.com Dear Maintainer, I tried to install libseccomp-dev using apt with the following command: sudo apt install libseccomp-dev The output is the following: Reading package lists... Done Building dependency tree... Done Reading state information... Done Suggested packages: seccomp The following NEW packages will be installed: libseccomp-dev 0 upgraded, 1 newly installed, 0 to remove and 84 not upgraded. Need to get 92.1 kB of archives. After this operation, 439 kB of additional disk space will be used. Err:1 http://ftp.fr.debian.org/debian bullseye/main amd64 libseccomp-dev amd64 2.5.1-1 404 Not Found [IP: 212.27.32.66 80] E: Failed to fetch http://ftp.fr.debian.org/debian/pool/main/libs/libseccomp/libseccomp-dev_2.5.1-1_amd64.deb 404 Not Found [IP: 212.27.32.66 80] E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? I ran apt-get update before without and with the --fix-missing option, but it didn't solve the problem. Looking at http://ftp.fr.debian.org/debian/pool/main/libs/libseccomp/, it seems that libseccomp-dev_2.5.1-1_amd64.deb is not present. Thanks for the help, Best regards, Guillaume -- System Information: Debian Release: 11.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 libseccomp-dev depends on: ii libseccomp2 2.5.1-1 libseccomp-dev recommends no packages. Versions of packages libseccomp-dev suggests: pn seccomp
Bug#1002979: FTBFS with camlp5 8.00.02
Dear Stéphane, Many thanks for this report. This link gives more details about this specific problem with the old geneweb 6.08: https://issueexplorer.com/issue/camlp5/camlp5/82 The solution would be to migrate to geneweb 7 (see also bug #986285 about the expected migration to geneweb 7). However, this will require a lot of time to implement & test, since geneweb 7 is very different from geneweb 6. As a result, geneweb might be removed from testing for some weeks or months following the landing of the new ocaml/camlp5 in unstable. With best regards, Guillaume Brochu Le dim. 2 janv. 2022 à 00:12, Stéphane Glondu a écrit : > Source: geneweb > Version: 6.08+git20181019+dfsg-3 > Severity: important > Tags: ftbfs > > Dear Maintainer, > > Your package FTBFS with camlp5 8.00.02 with the following error: > > camlp5r pa_extend.cmo q_MLast.cmo -o pa_macro5.ppo pa_macro5.ml > > File "pa_macro5.ml", line 162, characters 51-52: > > While expanding quotation "patt": > > Parse error: end of input expected after [patt] (in [patt_eoi]) > > This was discovered while preparing the transition to OCaml 4.13.1. > > Packages rebuilt with OCaml 4.13.1 are available at: > > https://ocaml.debian.net/transitions/ocaml-4.13.1/ > > > Cheers, > > -- > Stéphane > > -- System Information: > Debian Release: bookworm/sid > APT prefers testing > APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads) > 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 >
Bug#995101: ImportError: cannot import name SharedDataMiddleware
Package: isso Version: 0.12.2-4 Severity: important Dear Maintainer, Since I upgraded my server to bullseye, I'm unable to run Isso. Apparently, it's related to the upgrade of python3-werkzeug to a version > 1.0.0. According to the upstream issue #611, the issue is fixed since release 0.12.3. At the moment, the package in unstable is unusable. -- System Information: Debian Release: 11.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable'), (1, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages isso depends on: ii init-system-helpers 1.60 ii lsb-base 11.1.0 ii python3 3.9.2-3 ii python3-bleach3.2.1-2.1 ii python3-html5lib 1.1-3 ii python3-itsdangerous 1.1.0-3 ii python3-jinja22.11.3-1 ii python3-misaka1.0.2-7+b4 ii python3-werkzeug 1.0.1+dfsg1-2 Versions of packages isso recommends: ii gunicorn [gunicorn3] 20.1.0-1 ii libjs-jquery 3.5.1+dfsg+~3.5.5-7 ii libjs-underscore 1.9.1~dfsg-3 isso suggests no packages. -- no debconf information
Bug#989887: /lib/systemd/system/netdata.service: systemd request to update out of date service file
Package: netdata-core Version: 1.29.3-4 Severity: normal File: /lib/systemd/system/netdata.service Dear Maintainer, systemd reports an obsolete value used in /lib/systemd/system/netdata.service. # journalctl -b -u netdata [...] juin 04 13:10:17 kazoo systemd[1]: /lib/systemd/system/netdata.service:55: Standard output type syslog+console is obsolete, automatically updating to journal+console. Please update your unit file, and consider removing the setting altogether. juin 04 13:10:17 kazoo systemd[1]: /lib/systemd/system/netdata.service:56: Standard output type syslog+console is obsolete, automatically updating to journal+console. Please update your unit file, and consider removing the setting altogether. [...] Best regards, Guillaume -- System Information: Debian Release: 11.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US:ja Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages netdata-core depends on: ii init-system-helpers 1.60 ii libc62.31-12 ii libcap2 1:2.44-1 ii libcap2-bin 1:2.44-1 ii libgcc-s110.2.1-6 ii libjson-c5 0.15-2 ii libjudydebian1 1.0.5-5+b2 ii liblz4-1 1.9.3-2 ii libmnl0 1.0.4-3 ii libnetfilter-acct1 1.0.3-3 ii libprotobuf233.12.4-1 ii libsnappy1v5 1.1.8-1 ii libssl1.11.1.1k-1 ii libstdc++6 10.2.1-6 ii libuuid1 2.36.1-7 ii libuv1 1.40.0-1 ii lsb-base 11.1.0 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages netdata-core recommends: ii curl 7.74.0-1.2 Versions of packages netdata-core suggests: pn apcupsd pn hddtemp ii iproute25.10.0-4 ii iw 5.9-3 ii lm-sensors 1:3.6.0-7 pn nc -- no debconf information
Bug#988126: linux-image-4.9.0-15-amd64: kernel crash in update_group_capacity
Package: src:linux Version: 4.9.258-1 Severity: important Dear Maintainer, We have about 40 servers running the same operating system and this is the first time we see this crash in the kerneli (it happened the 05/04/2021, and never happened again, although the machine on which it appeared has only been running for two effective days since the crash). I have no idea what chain of actions lead to this crash, as our servers are either idle, either executing user jobs. Here are the last logs that I could see before the reboot: avril 05 07:05:05 physix99 kernel: divide error: [#1] SMP avril 05 07:05:05 physix99 kernel: Modules linked in: tcp_diag udp_diag inet_diag fuse rpcsec_gss_krb5 auth_rpcgss oid_registry nfsv4 dns_resolver nfs lockd grace fscache mpt3sas raid_class scsi_transpor avril 05 07:05:05 physix99 kernel: mfd_core wmi acpi_power_meter button ipmi_devintf sunrpc ipmi_si ipmi_msghandler ip_tables x_tables autofs4 ext4 crc16 jbd2 crc32c_generic fscrypto ecb mbcache dm_mod avril 05 07:05:05 physix99 kernel: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.0-15-amd64 #1 Debian 4.9.258-1 avril 05 07:05:05 physix99 kernel: Hardware name: Dell Inc. PowerEdge R640/0H28RR, BIOS 2.10.0 11/12/2020 avril 05 07:05:05 physix99 kernel: task: a4611500 task.stack: a460 avril 05 07:05:05 physix99 kernel: RIP: 0010:[] [] update_group_capacity+0x170/0x1c0 avril 05 07:05:05 physix99 kernel: RSP: 0018:a1000ea03c40 EFLAGS: 00010246 avril 05 07:05:05 physix99 kernel: RAX: 0088468b RBX: RCX: 024d avril 05 07:05:05 physix99 kernel: RDX: RSI: RDI: 00018a00 avril 05 07:05:05 physix99 kernel: RBP: a10004036200 R08: a10004740500 R09: a1000ea0 avril 05 07:05:05 physix99 kernel: R10: R11: R12: a10004740500 avril 05 07:05:05 physix99 kernel: R13: R14: R15: a10004740500 avril 05 07:05:05 physix99 kernel: FS: () GS:a1000ea0() knlGS: avril 05 07:05:05 physix99 kernel: CS: 0010 DS: ES: CR0: 80050033 avril 05 07:05:05 physix99 kernel: CR2: 7f675e0a7730 CR3: 0014eb608000 CR4: 00760670 avril 05 07:05:05 physix99 kernel: DR0: DR1: DR2: avril 05 07:05:05 physix99 kernel: DR3: DR6: fffe0ff0 DR7: 0400 avril 05 07:05:05 physix99 kernel: PKRU: 5554 avril 05 07:05:05 physix99 kernel: Stack: avril 05 07:05:05 physix99 kernel: a1000ea03e70 a10004740501 a1000ea03d90 avril 05 07:05:05 physix99 kernel: a3ab7205 a10004740518 a1000ea03d18 0008 avril 05 07:05:05 physix99 kernel: 00ffa1000ea03e10 a10c038d9180 a10c038d9980 005f avril 05 07:05:05 physix99 kernel: Call Trace: avril 05 07:05:05 physix99 kernel: avril 05 07:05:05 physix99 kernel: [] ? update_sd_lb_stats+0xc5/0x4b0 avril 05 07:05:05 physix99 kernel: [] ? find_busiest_group+0x3e/0x4d0 avril 05 07:05:05 physix99 kernel: [] ? find_busiest_group+0x3e/0x4d0 avril 05 07:05:05 physix99 kernel: [] ? load_balance+0x1c6/0x9f0 avril 05 07:05:05 physix99 kernel: [] ? rebalance_domains+0x234/0x2c0 avril 05 07:05:05 physix99 kernel: [] ? __do_softirq+0x10d/0x2b0 avril 05 07:05:05 physix99 kernel: [] ? irq_exit+0xc2/0xd0 avril 05 07:05:05 physix99 kernel: [] ? smp_reschedule_interrupt+0x35/0x40 avril 05 07:05:05 physix99 kernel: [] ? reschedule_interrupt+0x9e/0xb0 avril 05 07:05:05 physix99 kernel: avril 05 07:05:05 physix99 kernel: [] ? cpuidle_enter_state+0xa2/0x2d0 avril 05 07:05:05 physix99 kernel: [] ? cpu_startup_entry+0x154/0x240 avril 05 07:05:05 physix99 kernel: [] ? start_kernel+0x449/0x46c avril 05 07:05:05 physix99 kernel: [] ? early_idt_handler_array+0x120/0x120 avril 05 07:05:05 physix99 kernel: [] ? x86_64_start_kernel+0x14c/0x170 avril 05 07:05:05 physix99 kernel: Code: 0f 00 4c 8b 96 70 09 00 00 48 8b 86 68 09 00 00 48 8b b6 d8 08 00 00 48 d1 ea 4c 29 d6 41 ba 00 00 00 00 49 0f 48 f2 01 d6 31 d2 <48> f7 f6 ba 00 04 00 00 48 29 c avril 05 07:05:05 physix99 kernel: RIP [] update_group_capacity+0x170/0x1c0 Best regards, Guillaume Raffy -- Package-specific info: ** Version: Linux version 4.9.0-15-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.258-1 (2021-03-08) ** Command line: BOOT_IMAGE=/vmlinuz-4.9.0-15-amd64 root=/dev/mapper/sys-lv_root ro quiet ** Not tainted ** Kernel log: [64870.232080] CPU3: Package temperature above threshold, cpu clock throttled (total events = 27) [64870.232082] CPU13: Package temperature above threshold, cpu clock throttled (total events = 27) [64870.232084] CPU15: Package temperature above threshold, cpu clock throttled (total events = 27) [64870.232085] CPU23: P
Bug#988125: linux-image-4.9.0-15-amd64: kernel crash in update_group_capacity
Package: src:linux Version: 4.9.258-1 Severity: important Tags: upstream Dear Maintainer, We have about 40 servers running the same operating system and this is the first time we see this crash in the kerneli (it happened the 05/04/2021, and never happened again, although the machine on which it appeared has only been running for two effective days since the crash). I have no idea what chain of actions lead to this crash, as our servers are either idle, either executing user jobs. Here are the last logs that I could see before the reboot: avril 05 07:05:05 physix99 kernel: divide error: [#1] SMP avril 05 07:05:05 physix99 kernel: Modules linked in: tcp_diag udp_diag inet_diag fuse rpcsec_gss_krb5 auth_rpcgss oid_registry nfsv4 dns_resolver nfs lockd grace fscache mpt3sas raid_class scsi_transpor avril 05 07:05:05 physix99 kernel: mfd_core wmi acpi_power_meter button ipmi_devintf sunrpc ipmi_si ipmi_msghandler ip_tables x_tables autofs4 ext4 crc16 jbd2 crc32c_generic fscrypto ecb mbcache dm_mod avril 05 07:05:05 physix99 kernel: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.0-15-amd64 #1 Debian 4.9.258-1 avril 05 07:05:05 physix99 kernel: Hardware name: Dell Inc. PowerEdge R640/0H28RR, BIOS 2.10.0 11/12/2020 avril 05 07:05:05 physix99 kernel: task: a4611500 task.stack: a460 avril 05 07:05:05 physix99 kernel: RIP: 0010:[] [] update_group_capacity+0x170/0x1c0 avril 05 07:05:05 physix99 kernel: RSP: 0018:a1000ea03c40 EFLAGS: 00010246 avril 05 07:05:05 physix99 kernel: RAX: 0088468b RBX: RCX: 024d avril 05 07:05:05 physix99 kernel: RDX: RSI: RDI: 00018a00 avril 05 07:05:05 physix99 kernel: RBP: a10004036200 R08: a10004740500 R09: a1000ea0 avril 05 07:05:05 physix99 kernel: R10: R11: R12: a10004740500 avril 05 07:05:05 physix99 kernel: R13: R14: R15: a10004740500 avril 05 07:05:05 physix99 kernel: FS: () GS:a1000ea0() knlGS: avril 05 07:05:05 physix99 kernel: CS: 0010 DS: ES: CR0: 80050033 avril 05 07:05:05 physix99 kernel: CR2: 7f675e0a7730 CR3: 0014eb608000 CR4: 00760670 avril 05 07:05:05 physix99 kernel: DR0: DR1: DR2: avril 05 07:05:05 physix99 kernel: DR3: DR6: fffe0ff0 DR7: 0400 avril 05 07:05:05 physix99 kernel: PKRU: 5554 avril 05 07:05:05 physix99 kernel: Stack: avril 05 07:05:05 physix99 kernel: a1000ea03e70 a10004740501 a1000ea03d90 avril 05 07:05:05 physix99 kernel: a3ab7205 a10004740518 a1000ea03d18 0008 avril 05 07:05:05 physix99 kernel: 00ffa1000ea03e10 a10c038d9180 a10c038d9980 005f avril 05 07:05:05 physix99 kernel: Call Trace: avril 05 07:05:05 physix99 kernel: avril 05 07:05:05 physix99 kernel: [] ? update_sd_lb_stats+0xc5/0x4b0 avril 05 07:05:05 physix99 kernel: [] ? find_busiest_group+0x3e/0x4d0 avril 05 07:05:05 physix99 kernel: [] ? find_busiest_group+0x3e/0x4d0 avril 05 07:05:05 physix99 kernel: [] ? load_balance+0x1c6/0x9f0 avril 05 07:05:05 physix99 kernel: [] ? rebalance_domains+0x234/0x2c0 avril 05 07:05:05 physix99 kernel: [] ? __do_softirq+0x10d/0x2b0 avril 05 07:05:05 physix99 kernel: [] ? irq_exit+0xc2/0xd0 avril 05 07:05:05 physix99 kernel: [] ? smp_reschedule_interrupt+0x35/0x40 avril 05 07:05:05 physix99 kernel: [] ? reschedule_interrupt+0x9e/0xb0 avril 05 07:05:05 physix99 kernel: avril 05 07:05:05 physix99 kernel: [] ? cpuidle_enter_state+0xa2/0x2d0 avril 05 07:05:05 physix99 kernel: [] ? cpu_startup_entry+0x154/0x240 avril 05 07:05:05 physix99 kernel: [] ? start_kernel+0x449/0x46c avril 05 07:05:05 physix99 kernel: [] ? early_idt_handler_array+0x120/0x120 avril 05 07:05:05 physix99 kernel: [] ? x86_64_start_kernel+0x14c/0x170 avril 05 07:05:05 physix99 kernel: Code: 0f 00 4c 8b 96 70 09 00 00 48 8b 86 68 09 00 00 48 8b b6 d8 08 00 00 48 d1 ea 4c 29 d6 41 ba 00 00 00 00 49 0f 48 f2 01 d6 31 d2 <48> f7 f6 ba 00 04 00 00 48 29 c avril 05 07:05:05 physix99 kernel: RIP [] update_group_capacity+0x170/0x1c0 Best regards, Guillaume Raffy -- Package-specific info: ** Version: Linux version 4.9.0-15-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.258-1 (2021-03-08) ** Command line: BOOT_IMAGE=/vmlinuz-4.9.0-15-amd64 root=/dev/mapper/sys-lv_root ro quiet ** Not tainted ** Kernel log: [64870.232080] CPU3: Package temperature above threshold, cpu clock throttled (total events = 27) [64870.232082] CPU13: Package temperature above threshold, cpu clock throttled (total events = 27) [64870.232084] CPU15: Package temperature above threshold, cpu clock throttled (total events = 27) [64870.232085]
Bug#986285: RE : geneweb: new version 7.0.0 available since Oct 2020
Hi, Thanks for reporting. I know that Geneweb 7.0.0 has been available since last October. However, there are so many changes in 7.0.0 from 6.08 that it will require a complete rewrite of the Debian package. I felt the deadline was too short for Bullseye, but this job needs to be completed for Bookworm of course. With best regards, Guillaume Brochu
Bug#985966: pcp: pmda postgresql not installed
Package: pcp Version: 4.3.2+really4.3.1-0.1 Severity: normal Dear Maintainer, Using version "4.3.2+really4.3.1" from stable, the postgresql pmda and pmlogconf files are not installed. The only postgresql related file included in the package is the pmdapostgresql manpage. According to the configure.ac, postgresql pmda is only build/installed if psycopg2 is detected on the system, but it does not appear in Build-Depends. Note that the package for pcp 5.2.6 in testing is not affected and has python3-psycopg2 as build dependency. Rebuilding the package after installing psycopg2 fixes the issue. Regards, -- System Information: Debian Release: 10.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-12-amd64 (SMP w/4 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 pcp depends on: ii gawk 1:4.2.1+dfsg-1 ii libc6 2.28-10 ii libncurses6 6.1+20181013-2+deb10u2 ii libpapi5.75.7.0+dfsg-2 ii libpcp-gui2 4.3.2+really4.3.1-0.1 ii libpcp-mmv1 4.3.2+really4.3.1-0.1 ii libpcp-pmda-perl 4.3.2+really4.3.1-0.1 ii libpcp-pmda3 4.3.2+really4.3.1-0.1 ii libpcp-trace2 4.3.2+really4.3.1-0.1 ii libpcp-web1 4.3.2+really4.3.1-0.1 ii libpcp3 4.3.2+really4.3.1-0.1 ii libpfm4 4.10.1+git10-gd2a5b56-1 ii libreadline7 7.0-5 ii libtinfo6 6.1+20181013-2+deb10u2 ii procps2:3.3.15-2 ii python3 3.7.3-1 ii python3-pcp 4.3.2+really4.3.1-0.1 pcp recommends no packages. Versions of packages pcp suggests: ii libpcp-import-perl 4.3.2+really4.3.1-0.1 ii pcp-gui 4.3.2+really4.3.1-0.1 -- Configuration Files: /etc/pcp/pmcd/pmcd.conf changed: root1 pipebinary /var/lib/pcp/pmdas/root/pmdaroot pmcd2 dso pmcd_init /var/lib/pcp/pmdas/pmcd/pmda_pmcd.so proc3 pipebinary /var/lib/pcp/pmdas/proc/pmdaproc -d 3 pmproxy 4 dso pmproxy_init/var/lib/pcp/pmdas/mmv/pmda_mmv.so xfs 11 pipebinary /var/lib/pcp/pmdas/xfs/pmdaxfs -d 11 linux 60 pipebinary /var/lib/pcp/pmdas/linux/pmdalinux mmv 70 dso mmv_init/var/lib/pcp/pmdas/mmv/pmda_mmv.so kvm 95 pipebinary /var/lib/pcp/pmdas/kvm/pmdakvm -d 95 postgresql 110 pipebinary python3 /var/lib/pcp/pmdas/postgresql/pmdapostgresql.python jbd2122 dso jbd2_init /var/lib/pcp/pmdas/jbd2/pmda_jbd2.so [access] disallow ".*" : store; disallow ":*" : store; allow "local:*" : all; -- no debconf information
Bug#984971: RFS: wfrench/1.2.7-1 -- French dictionary words for /usr/share/dict
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "wfrench": * Package name: wfrench Version : 1.2.7-1 Upstream Author : Paul Leyland * URL : https://salsa.debian.org/gpernot-guest/wfrench * License : GPL-2+ * Vcs : https://salsa.debian.org/gpernot-guest/wfrench Section : text It builds those binary packages: wfrench - French dictionary words for /usr/share/dict To access further information about this package, please visit the following URL: https://mentors.debian.net/package/wfrench/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/w/wfrench/wfrench_1.2.7-1.dsc Changes since the last upload: wfrench (1.2.7-1) unstable; urgency=medium . * new upstream release * Christoph Berg fixes : - Use Rules-Requires-Root: no; install file using dh_install. - Don't call dh_installman from override_dh_auto_install, it's called later anyway. Regards,
Bug#978713: libreoffice-wiki-publisher: Wrong homepage for the project
Package: libreoffice-wiki-publisher
Version: 1.2.0+LibO6.1.5-3+deb10u6
Severity: minor
Dear Maintainer,
On https://packages.debian.org/unstable/libreoffice-wiki-publisher the homepage
for the project is reported as:
http://extensions.services.openoffice.org/project/wikipublisher .
However this is not a link to the proper code, and the
https://extensions.libreoffice.org/
doesn't list the extension, as it is a part of core. I'd link to:
https://github.com/LibreOffice/core/tree/master/swext/mediawiki
which is at least linked to the right software.
Thanks, I just thought it would help knowing the package isn't a
13 year old plugin :D.
G
-- Package-specific info:
Identifier: com.sun.wiki-publisher
Version: 1.2.0
URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher
is registered: yes
Media-Type: application/vnd.sun.star.package-bundle
Description: The Wiki Publisher enables you to create Wiki articles on
MediaWiki servers without having to know the syntax of the MediaWiki markup
language. Publish your new and existing documents transparently with the Writer
to a wiki page.
bundled Packages: {
URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/help
is registered: yes
Media-Type: application/vnd.sun.star.help
Description:
URL:
vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/WikiExtension.xcs
is registered: yes
Media-Type: application/vnd.sun.star.configuration-schema
Description:
URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/WikiEditor/
is registered: yes
Media-Type: application/vnd.sun.star.basic-library
Description:
URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/components.rdb
is registered: yes
Media-Type: application/vnd.sun.star.uno-components
Description:
URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/Addons.xcu
is registered: yes
Media-Type: application/vnd.sun.star.configuration-data
Description:
URL:
vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/ProtocolHandler.xcu
is registered: yes
Media-Type: application/vnd.sun.star.configuration-data
Description:
URL:
vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/WikiExtension.xcu
is registered: yes
Media-Type: application/vnd.sun.star.configuration-data
Description:
URL:
vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/OptionsDialog.xcu
is registered: yes
Media-Type: application/vnd.sun.star.configuration-data
Description:
URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/Filter.xcu
is registered: yes
Media-Type: application/vnd.sun.star.configuration-data
Description:
URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/Types.xcu
is registered: yes
Media-Type: application/vnd.sun.star.configuration-data
Description:
URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/Paths.xcu
is registered: yes
Media-Type: application/vnd.sun.star.configuration-data
Description:
}
-- System Information:
Debian Release: 10.6
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-11-amd64 (SMP w/4 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 libreoffice-wiki-publisher depends on:
ii default-jre [java6-runtime] 2:1.11-71
ii libreoffice-core1:6.1.5-3+deb10u6
ii libreoffice-java-common 1:6.1.5-3+deb10u6
ii openjdk-11-jre [java6-runtime] 11.0.8+10-1~deb10u1
ii openjdk-8-jre [java6-runtime] 8u212-b01-1~deb9u1
libreoffice-wiki-publisher recommends no packages.
Versions of packages libreoffice-wiki-publisher suggests:
pn mediawiki
-- debconf-show failed
Bug#976659: Kernel panic while upgrading systemd
Although all upgrade attempts fail, I agree to close this bug. The system was installed for more than 15 years now, and is running and regulary upgraded since. So I guess there must be a kind of old thing in my computer's file system that leeds to this bug. I think I will have to reinstall the system... Thanks for the help. Guillaume Le 11/12/2020 à 20:21, Michael Biebl a écrit : Ok, thanks anyway. Are you ok if we close this bug report and if you run into it, we reopen it? Without a backtrace or instructions how to reproduce the issue, there is basically nothing we can do about it. Regards, Michael
Bug#976659: Kernel panic while upgrading systemd
So I restored the systemd to the version running on my system, I installed the packages you mentionned. I did the upgrade again, but no coredump was generated after the crash. Sorry... Le 06/12/2020 à 19:32, Michael Biebl a écrit : Unfortunately, this screenshot is not too helpful. To be able to diagnose the problem, we at least need a full backtrace. For that install the dbgsym packages for systemd and a program which gathers the coredump. You can use systemd-coredump for that. After that, you can get the coredump with coredumpctl.
Bug#976659: Kernel panic while upgrading systemd
Package: systemd Version: 246.6-4 Dear maintainer, I'm trying to upgrade systemd (along with libnss-systemd libpam-systemd libsystemd0 libudev1 systemd systemd-sysv systemd-timesyncd udev) from version 246-2 to version 246.6-4, but I'm encountering a kernel panic during systemd's package configuration. Please find as attchment the secreenshot with logs. Regards, Guillaume -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 5.9.0-4-686-pae (SMP w/2 CPU threads) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages systemd depends on: ii adduser 3.118 ii libacl1 2.2.53-8 ii libapparmor1 2.13.5-1+b1 ii libaudit1 1:2.8.5-3.1 ii libblkid1 2.36.1-2 ii libc6 2.31-5 ii libcap2 1:2.44-1 ii libcrypt1 1:4.4.17-1 ii libcryptsetup12 2:2.3.4-1 ii libgcrypt20 1.8.7-2 ii libgnutls30 3.6.15-4 ii libgpg-error0 1.38-2 ii libidn2-0 2.3.0-4 ii libip4tc2 1.8.6-1 ii libkmod2 27+20200310-2 ii liblz4-1 1.9.2-2 ii liblzma5 5.2.4-1+b1 ii libmount1 2.36.1-2 ii libpam0g 1.3.1-5 ii libpcre2-8-0 10.34-7 ii libseccomp2 2.5.0-3 ii libselinux1 3.1-2+b1 ii libsystemd0 246-2 ii libzstd1 1.4.5+dfsg-4 ii mount 2.36.1-2 ii systemd-timesyncd [time-daemon] 246-2 ii util-linux 2.36.1-2 Versions of packages systemd recommends: ii dbus 1.12.20-1 Versions of packages systemd suggests: pn policykit-1 pn systemd-container Versions of packages systemd is related to: pn dracut ii initramfs-tools 0.139 ii libnss-systemd 246-2 ii libpam-systemd 246-2 ii udev 246-2
Bug#975491: mozc: New upstream release available: 2.26
Source: mozc Version: 2.23.2815.102+dfsg-10 Severity: wishlist Dear Maintainer, The upstream repository has recently become active again, according to https://github.com/google/mozc/commits/master the lastest release is 2.26, it would be nice to upgrade the Debian package to that release. It's not clear exactly what changed compared to the release currently i Debian since there was a huge code dump in https://github.com/google/mozc/commit/a1dcadabd3a1c604e8beff1e45830c1d9adfce84 Thank you, Guillaume -- System Information: Debian Release: bullseye/sid APT prefers groovy-updates APT policy: (500, 'groovy-updates'), (500, 'groovy-security'), (500, 'groovy'), (100, 'groovy-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.0-29-generic (SMP w/16 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#973190: geneweb: FTBFS: ocamlc.opt: OCaml has been configured with -force-safe-string: -unsafe-string is not available.
Dear Lucas, Thank you for the report! This is most likely related to the recent migration to OCAML 4.11 in unstable: [2020-10-12] Accepted ocaml 4.11.1-3 (source) into unstable And I think I know what to do to fix it. See the commit messages in : https://salsa.debian.org/GuillaumeBrochu-guest/geneweb/-/blob/master/debian/patches/0001-Makefile.debian.patch https://github.com/geneweb/geneweb/commit/5fe0e0bccb33befd56471dd40eaf44ead2f6fb8a I will try to fix this as soon as possible. With best regards, Guillaume Le mar. 27 oct. 2020 à 13:51, Lucas Nussbaum a écrit : > Source: geneweb > Version: 6.08+git20181019+dfsg-2 > Severity: serious > Justification: FTBFS on amd64 > Tags: bullseye sid ftbfs > Usertags: ftbfs-20201027 ftbfs-bullseye > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > Relevant part (hopefully): > > make[3]: Entering directory '/<>/wserver' > > camlp5r pa_extend.cmo q_MLast.cmo -o pa_macro5.ppo pa_macro5.ml > > ocamlc -c -I "`camlp5 -where`" -impl pa_macro5.ppo > > camlp5r ../wserver/pa_macro5.cmo -DUNIX -o wserver.ppi wserver.mli > > ocamlc.opt -unsafe-string -I /usr/lib/ocaml/camlp5/ -c -intf wserver.ppi > > ocamlc.opt: OCaml has been configured with -force-safe-string: > -unsafe-string is not available. > > [...] > > The full build log is available from: > > http://qa-logs.debian.net/2020/10/27/geneweb_6.08+git20181019+dfsg-2_unstable.log > > A list of current common problems and possible solutions is available at > http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! > > About the archive rebuild: The rebuild was done on EC2 VM instances from > Amazon Web Services, using a clean, minimal and up-to-date chroot. Every > failed build was retried once to eliminate random failures. >
Bug#972962: openjdk-8-jre : unable to establish a TLS connection since version 8u272-b10-0+deb9u1
Package: openjdk-8-jre Version: 8u272-b10-0+deb9u1 On a Debian Stretch, we use the software lsc (https://lsc-project.org/doku.php) to synchronize a Samba 4 AD DC database with a OpenLDAP database. This sotfware use Java. This morning, we updated our servers, including openjdk-8-jre and openjdk-8-jre-headless to the version 8u272-b10-0+deb9u1). Since, lsc couldn't connect anymore to our Samba 4 AD DC : oct. 26 12:15:38 - INFO - Connecting to LDAP server ldap://
Bug#972248: please support postgresql 13
Hello, On Thu, 15 Oct 2020 11:37:08 +0200 David Kunz wrote: > Package: resource-agents-paf > Version: 2.3.0-1 > Severity: normal > > Hallo > > Thank you, for maintaining resource-agents-paf. > We are using postgresql 13 with paf. > It would be nice if you could update this package for using with > postgresql 13. I hadn't time yet to do extensive tests with PostgreSQL 13. Did you test and experienced incompatibles? Could you report them? Thanks,
Bug#949035: blender: crashes when opening certain files
Dear Maintainer, Works fine with version 2.83.4+dfsg-1 of blender. I thinks this bug can be closed. Cheers, -- Guillaume Clercin signature.asc Description: This is a digitally signed message part.
Bug#964571: Languages are installed in a directory which is not expected by "bygfoot"
Package: bygfoot Version: 2.3.2-2+b1 Hi, - Bygfoot Football Manager game is only in English and does not offer the possibility to change the language. - I saw with "strace" that bygfoot searches for languages in "/usr/local/share/locale" - While dpkg indicates that they are installed in "/usr/share/games/locale" - So i tested a : "cp -R /usr/share/games/locale /usr/local/share/" - Manual copying of languages to the directory expected by bygfoot successfully bypasses the anomaly but I guess there must be a better solution. I using Debian GNU/Linux 10, kernel 4.19.0-9-amd64, locale fr_FR.UTF-8, MATE desktop Best regards, Guillaume GÉANT
Bug#963022: quagga-core: zebra static routes tags not sent to clients
quagga-core: zebra static routes tags not sent to clients Package: quagga-core Version: 1.2.4-3 Severity: normal Dear Maintainer, While testing a route-map in bgpd redistributing static routes with tags, matching tags did not work. Running "debug bgp zebra" revealed that whatever tag is set with the static routes set in zebra, client daemon receives a null tag Syslog debug excerpt : Jun 17 21:33:12 jck bgpd[330852]: Zebra rcvd: IPv4 route add static 172.17.56.16/29 nexthop 192.168.39.39 metric 0 tag 0 route in zebra is configured with ip route 172.17.56.16/29 192.168.39.39 tag 349346 244 RIB check : # sh ip ro 172.17.56.16 Routing entry for 172.17.56.16/29 Known via "static", distance 244, metric 0, tag 349346, vrf 0, best, fib, blackhole >* 192.168.39.39, via eth0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-9-amd64 (SMP w/2 CPU cores) 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) Versions of packages quagga-core depends on: ii adduser 3.118 ii dpkg 1.19.7 ii iproute2 4.20.0-2 ii libc6 2.29-7 ii libcap2 1:2.25-2 ii libpam0g 1.3.1-5 ii libreadline7 7.0-5 ii libtinfo6 6.1+20181013-2+deb10u2 quagga-core recommends no packages. Versions of packages quagga-core suggests: ii quagga-bgpd1.2.4-3 pn quagga-isisd pn quagga-ospf6d pn quagga-ospfd pn quagga-pimd pn quagga-ripd pn quagga-ripngd pn snmpd -- no debconf information Rgds Guillaume
Bug#400681:
Oo
Bug#961892: ifupdown-extra: reject must be replace by blackhole
Package: ifupdown-extra
Version: 0.27
Severity: normal
Dear Maintainer,
* What led up to the situation?
Playing with blackhole and how to set it "a standard way".
* What exactly did you do (or not do) that was effective (or
ineffective)?
I added a 'reject' line in /etc/network/routes
* What was the outcome of this action?
Nothing happened
* What outcome did you expect instead?
Get a null route.
All this because iproute2 take over old route.
The keyword and syntax has changed from
route add reject
to
ip route add blackhole
I checked 0.28 version, it has the same problem.
-- System Information:
Debian Release: 9.12
APT prefers oldstable-updates
APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-12-amd64 (SMP w/1 CPU core)
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)
Versions of packages ifupdown-extra depends on:
ii bind9-host [host]1:9.10.3.dfsg.P4-12.3+deb9u6
ii curl 7.52.1-5+deb9u10
ii dpkg 1.18.25
ii host 1:9.10.3.dfsg.P4-12.3+deb9u6
ii iproute2 4.9.0-1+deb9u1
ii iputils-arping 3:20161105-1
ii iputils-ping [ping] 3:20161105-1
ii net-tools1.60+git20161116.90da8a0-1
ii netcat-traditional [netcat] 1.10-41+b1
Versions of packages ifupdown-extra recommends:
ii ethtool 1:4.8-1+b1
ii ndisc6 1.0.3-3
ifupdown-extra suggests no packages.
-- Configuration Files:
/etc/init.d/networking-routes changed:
[ -x /sbin/ip ] || exit 0
ROUTEFILE="/etc/network/routes"
[ ! -r "$ROUTEFILE" ] && exit 0
. /lib/lsb/init-functions
VERBOSITY=${VERBOSITY:-0}
run_route() {
local COMMAND="ip route $*"
export LC_MESSAGES=C # We need the return messages to be in english
RETMESSAGE="$($COMMAND 2>&1)"
RETVALUE=$?
if test $RETVALUE -ne 0 ; then
[ "$VERBOSITY" -eq 1 ] && echo "DEBUG: calling: '$COMMAND'
FAILED"
# Process the messages and omits those that are not
# relevant.
case "$RETMESSAGE" in
# Omit 'File exists' since the route is already there..
*File*exists) return ;;
# 'No such process' is only omitted if the route is being
# deleted. If the route is being created, this error message
# might appear if the gateway is not reachable.
*No*such*process) [ "$1" = "del" ] && return ;;
*)
esac
log_failure_msg "Error while executing:" \
" Command '$COMMAND' returned:
${RETMESSAGE%%Usage:*}"\
" Configuration line: $LINE"
else
[ "$VERBOSITY" -eq 1 ] && echo "DEBUG: calling: '$COMMAND'
SUCCEEDED"
fi
}
del_global_routes() {
ret=0
cat $ROUTEFILE | egrep "^[^#].*$" |
while read network netmask gateway interface ; do
if [ -n "$interface" ] && [ -n "$network" ] && [ -n "$netmask" ] &&
[ -n "$gateway" ] ; then
if [ "$gateway" != "blackhole" ] ; then
[ "$VERBOSITY" -eq 1 ] && echo "DEBUG: Deleting global
route for $network / $netmask through gateway $gateway"
if [ "$interface" != "any" ] ; then
run_route del $network/$netmask via $gateway dev
$interface
else
run_route del $network/$netmask via $gateway
fi
[ $? -ne 0 ] && ret=$?
else
[ "$VERBOSITY" -eq 1 ] && echo "DEBUG: Deleting blackhole
route for $network / $netmask"
run_route del blackhole $network/$netmask
[ $? -ne 0 ] && ret=$?
fi
else
echo "ERROR: Incorrect line for global network routes in
$ROUTEFILE: '$network $netmask $gateway $interface'"
ret=1
fi
done
return $ret
}
add_global_routes() {
ret=0
cat $ROUTEFILE | egrep "^[^#].*$" |
while read network netmask gateway interface ; do
if [ -n "$interface" ] && [ -n "$network" ] && [ -n "$netmask" ] &&
[ -n "$gateway" ] ; then
if [ "$gateway" != "blackhole" ] ; then
[ "$VERBOSITY" -eq 1 ] && echo "DEBUG: Adding global route
for $network / $netmask through gateway $gateway"
if [ "$interface" != "any" ] ; then
run_route add $network/$netmask via $gateway dev
$interface
else
run_route add $network/$netmask via $gateway
fi
[ $? -ne 0 ] && ret=$?
Bug#958514: mkgmap-splitter: Running mkgmap-spitter fails with java exception
Package: mkgmap-splitter Version: 0.0.0+svn597-1 Severity: grave Justification: renders package unusable Dear Maintainer, I run mkgmap splitter on some OpenStreetMap data extract, and it failed with the following java exception : Exception in thread "main" java.lang.NoSuchMethodError: 'com.google.protobuf.GeneratedMessageLite crosby.binary.Osmformat$HeaderBlock$Builder.build()' at uk.me.parabola.splitter.writer.BinaryMapWriter.finishHeader(BinaryMapWriter.java:490) at uk.me.parabola.splitter.writer.BinaryMapWriter.writeHeader(BinaryMapWriter.java:475) at uk.me.parabola.splitter.writer.BinaryMapWriter.initForWrite(BinaryMapWriter.java:458) at uk.me.parabola.splitter.SplitProcessor.(SplitProcessor.java:82) at uk.me.parabola.splitter.Main.writeTiles(Main.java:537) at uk.me.parabola.splitter.Main.start(Main.java:132) at uk.me.parabola.splitter.Main.main(Main.java:81) The OpenStreetMap data in question can be found at : https://download.geofabrik.de/europe/france/alsace-latest.osm.pbf But running mkgmap-splitter on other OpenStreeMap data extract fails in the same way. Thank's for your help ! Best regards, Guillaume -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 5.5.0-2-686-pae (SMP w/2 CPU cores) 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 mkgmap-splitter depends on: ii libfastutil-java 8.3.1-1 ii libosmpbf-java1.3.3-14 ii libprotobuf-java 3.11.4-4 ii libxpp3-java 1.1.4c-3 ii openjdk-13-jre-headless [java8-runtime-headless] 13.0.3+3-1 Versions of packages mkgmap-splitter recommends: ii mkgmap 0.0.0+svn4475-1 ii osmctools 0.9-2 mkgmap-splitter suggests no packages. -- no debconf information
Bug#953367: geneweb-gui binary package might need to be removed for Bullseye
Bonjour Sébastien, This new auto-removal warning triggered by gtksourceview2 was expected. It was the reason why I opened this bug (953367). The removal date was initially 2020-03-15, and it was postponed a few times, now it is 2020-05-09. geneweb does not depend directly on gtksourceview2 (syntax highlighting widget), but through lablgtk2 (OCaml bindings for GTK+ version 2). The dependency chain is : geneweb > geneweb-gui > lablgtk2 > gtksourceview2 To my best understanding, geneweb-gui is not using gtksourceview2, but only the other components of lablgtk2. The maintainer of lablgtk2 have recently (2020-04-03) proposed a solution to fix lablgtk2 : to provide it without gtksourceview2. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885677#95 Therefore, I propose to wait for this solution to lablgtk2, but I'm ready to drop geneweb-gui if there is another problem with lablgtk2. Cordialement, Guillaume Le sam. 11 avr. 2020 à 05:45, Sébastien Villemot a écrit : > Dear Guillaume, > > geneweb has migrated back to testing, however… > > Le mercredi 08 avril 2020 à 08:10 -0400, Guillaume Brochu a écrit : > > As I can see, lablgtk2 should be repaired soon: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885677#95 > > > > My understanding is that geneweb-gui does not depend on the > > problematic component (gtksourceview2) of lablgtk2. > > According to #911166, the whole gtksourceview2 package is going to be > removed from Debian, and this is transitively going to remove lablgtk2 > and geneweb from testing on 2020-05-09 (see > https://tracker.debian.org/pkg/geneweb) > > My understanding is therefore that, to prevent another removal from > testing, the geneweb-gui package must either be dropped or ported to > GTK 3. > > Best, > > -- > ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot > ⣾⠁⢠⠒⠀⣿⡁ Debian Developer > ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name > ⠈⠳⣄ https://www.debian.org > >
Bug#953367: geneweb-gui binary package might need to be removed for Bullseye
Bonjour Sébastien, As I can see, lablgtk2 should be repaired soon: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885677#95 My understanding is that geneweb-gui does not depend on the problematic component (gtksourceview2) of lablgtk2. So I propose to wait for this fix. Then, I might need your help if there are some manual operations to do in order to bring back geneweb in testing. As I can also see, this bug (953367) is now tagged as an "issues preventing migration", which was not my intent. https://tracker.debian.org/pkg/geneweb With best regards, Guillaume Le mer. 8 avr. 2020 à 04:33, Sébastien Villemot a écrit : > Dear Guillaume, > > Le dimanche 08 mars 2020 à 11:54 -0400, Guillaume Brochu a écrit : > > Package: geneweb-gui > > Version: 6.08+git20181019+dfsg-2 > > Severity: serious > > X-Debbugs-CC: sebast...@debian.org > > > > geneweb-gui binary package might need to be removed for Bullseye, for > > the two following reasons: > > As you may have seen, geneweb has been removed from testing because of > this bug. > > Isn’t it the time for dropping the geneweb-gui package, so that geneweb > can get back into testing? > > Best, > > -- > ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot > ⣾⠁⢠⠒⠀⣿⡁ Debian Developer > ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name > ⠈⠳⣄ https://www.debian.org > >
Bug#955833: please describe your "invalid data"
Well, I've just been doing some more testings using nginx and I have got
the same error. Files sent by the server contain broken data.
Indeed, I was also surprised that even static files couldn't be served.
Sorry for all of that, it looks not to be like a bug related to
lighttpd... I must investigate further.
--
Guillaume
What do you mean by "invalid data"? Please be more specific.
What kind of requests? Please be more specific.
It would be hightly unlikely that lighttpd would pass its unit tests and
yet be unable to server a static file.
Your minimal configuration is missing a basic mimetypes config which
would inform your browser of the Content-Type of the responses.
> include_shell "/usr/share/lighttpd/create-mime.conf.pl"
or, for testing purposes:
> mimetype.assign = (".html" => "text/html", ".png => "image/png" )
Bug#956109: libcsound not installable with multi arch
Package: csound Version: 1:6.12.2~dfsg-3.1 Trying to install libcsound64-6.0:armhf on an amd64 system: # apt-get install --no-install-recommends libcsound64-6.0:armhf Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libcsound64-6.0:armhf : Depends: csound-data:armhf but it is not installable I think csound-data should have 'Multi-Arch: allowed'
Bug#955833: Minimalistic server configuration file
Here is the minimalistic configuration file I've used to do my testings.
--
/etc/lighttpd/test.conf
server.document-root = "/var/www/html/"
server.modules += ( "mod_openssl" )
$SERVER["socket"] == "0.0.0.0:443" {
ssl.engine = "enable"
ssl.pemfile = "/etc/lighttpd/cert.pem"
ssl.privkey = "/etc/lighttpd/privkey.pem"
ssl.cipher-list = "HIGH"
}
Bug#955833: lighttpd: Get requests send invalid data for files above 30kB
Package: lighttpd
Version: 1.4.55-1
Severity: important
Dear Maintainer,
Here is a very wired bug. I'll try to explain...
GET requests send invalid data for files above 30kB when connecting to the
server over http. But GET requests send good data when connecing over https.
I've done my investigations using png image files, having different sizes. I've
also tested with different client softawares : firefox 74.0, gnome-web 3.34.4,
and wget 1.20.3. ANd I used a minimalistic server configuration file that can
be found as attachment.
Thank's for your help !
Guillaume
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 5.4.0-4-686-pae (SMP w/2 CPU cores)
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 lighttpd depends on:
ii libattr1 1:2.4.48-5
ii libbz2-1.01.0.8-2
ii libc6 2.30-4
ii libcrypt1 1:4.4.15-1
ii libfam0 2.7.0-17.3
ii libpcre3 2:8.39-12+b1
ii libssl1.1 1.1.1d-2
ii lsb-base 11.1.0
ii mime-support 3.64
ii zlib1g1:1.2.11.dfsg-2
Versions of packages lighttpd recommends:
ii perl5.30.0-9
pn spawn-fcgi
Versions of packages lighttpd suggests:
pn apache2-utils
pn lighttpd-doc
pn lighttpd-mod-authn-gssapi
pn lighttpd-mod-authn-pam
pn lighttpd-mod-authn-sasl
pn lighttpd-mod-cml
pn lighttpd-mod-geoip
pn lighttpd-mod-magnet
pn lighttpd-mod-maxminddb
pn lighttpd-mod-trigger-b4-dl
pn lighttpd-mod-vhostdb-dbi
pn lighttpd-mod-vhostdb-pgsql
pn lighttpd-mod-webdav
pn lighttpd-modules-ldap
pn lighttpd-modules-mysql
ii openssl 1.1.1d-2
ii php-cgi 2:7.3+69
ii php7.0-cgi [php-cgi]7.0.31-1
ii php7.3-cgi [php-cgi]7.3.15-3
pn rrdtool
-- Configuration Files:
/etc/lighttpd/conf-available/10-ssl.conf changed:
server.modules += ( "mod_openssl" )
$SERVER["socket"] == "0.0.0.0:443" {
ssl.engine = "enable"
ssl.pemfile = "/etc/lighttpd/cert.pem"
ssl.privkey = "/etc/lighttpd/privkey.pem"
ssl.cipher-list = "HIGH"
}
/etc/lighttpd/conf-available/90-debian-doc.conf changed:
$HTTP["remoteip"] =~ "^127\.0\.0\.1$|^::1$" {
alias.url += (
# "/cgi-bin/" => "/usr/lib/cgi-bin/",
"/doc/" => "/usr/share/doc/",
"/images/" => "/usr/share/images/"
)
$HTTP["url"] =~ "^/doc/|^/images/" {
dir-listing.activate = "enable"
}
$HTTP["url"] =~ "^/cgi-bin/" {
cgi.assign = ( "" => "" )
}
}
/etc/lighttpd/lighttpd.conf changed:
server.modules = (
"mod_indexfile",
"mod_access",
"mod_alias",
"mod_redirect",
)
server.document-root= "/var/www/html"
server.upload-dirs = ( "/var/cache/lighttpd/uploads" )
server.errorlog = "/var/log/lighttpd/error.log"
server.pid-file = "/run/lighttpd.pid"
server.username = "www-data"
server.groupname= "www-data"
server.port = 80
server.http-parseopts = (
"header-strict" => "enable",# default
"host-strict" => "enable",# default
"host-normalize" => "enable",# default
"url-normalize-unreserved"=> "enable",# recommended highly
"url-normalize-required" => "enable",# recommended
"url-ctrls-reject"=> "enable",# recommended
"url-path-2f-decode" => "enable",# recommended highly (unless breaks app)
#"url-path-2f-reject" => "enable",
"url-path-dotseg-remove" => "enable",# recommended highly (unless breaks app)
#"url-path-dotseg-reject" => "enable",
#"url-query-20-plus" => "enable",# consistency in query string
)
index-file.names= ( "index.php", "index.html" )
url.access-deny = ( "~", ".inc" )
static-file.exclude-extensions = ( ".php", ".pl", ".fcgi" )
compress.cache-dir = "/var/cache/lighttpd/compress/"
compress.filetype = ( "application/javascript", "text/css",
"text/html", "text/plain" )
include_shell "/usr/share/lighttpd/use-ipv6.pl " + server.port
include_shell "/usr/share/lighttpd/create-mime.conf.pl"
include "/etc/lighttpd/conf-enabled/*.conf"
server.compat-module-load = "disable"
server.modules += (
"mod_compress",
"mod_dirlisting",
"mod_staticfile",
)
-- no debconf information
Bug#953560: Missing manpages in otb-cli 7.0
Source: otb Severity: serious Manpages for otbcli_* are not available anymore from otb 7.0 onwards.
Bug#953367: geneweb-gui binary package might need to be removed for Bullseye
Package: geneweb-gui Version: 6.08+git20181019+dfsg-2 Severity: serious X-Debbugs-CC: sebast...@debian.org geneweb-gui binary package might need to be removed for Bullseye, for the two following reasons: 1. It depends on gtksourceview2 (through lablgtk2), which is marked for autoremoval on April 4th (#911166, #885677). The removal was initially discussed in 2018, but was delayed to Bullseye. I will wait to see what will happen with lablgtk2 before taking action. 2. The geneweb gui is no longer supported by the upstream development team for the future release of geneweb 7 (as of July 2019) Commit : "Moved bin/contrib in another repo and fixed 'make distrib'" https://github.com/geneweb/geneweb/commit/ba622ae54956aef561ad2a9df83847f363d2691c Commit : "Suprpess gui from contrib" https://github.com/geneweb/geneweb-contrib/commit/f68027570248e3d598f81ad2f67373f7a9cea243 However, as long as geneweb 7 is not officially released, there is no need to remove the geneweb-gui from the geneweb package.
Bug#953242: RFS: wfrench/1.2.6-1 -- French dictionary words for /usr/share/dict
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "wfrench" * Package name: wfrench Version : 1.2.6-1 Upstream Author : Paul Leyland * URL : https://salsa.debian.org/gpernot-guest/wfrench * License : GPL-2+ * Vcs : https://salsa.debian.org/gpernot-guest/wfrench Section : text It builds those binary packages: wfrench - French dictionary words for /usr/share/dict To access further information about this package, please visit the following URL: https://mentors.debian.net/package/wfrench Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/w/wfrench/wfrench_1.2.6-1.dsc Changes since the last upload: * new upstream release : - Removed duplicates - Reorder according to LC_COLLATE * debian/control: - Bumped Standards-Version to 4.5.0. Regards,
Bug#950741: dosen't work with postgresql 12
Hello, v2.3~rc2 has been released yesterday. We plan for a release in about one month. Debian package is available on the github release page[1]. Not sure when/if it can hit sid. Regards, [1] https://github.com/ClusterLabs/PAF/releases/tag/v2.3_rc2
Bug#948318: openssh-server: Unable to restart sshd restart after upgrade to version 8.1p1-2
Well, libxcrypt1 is not installed on my system. Only libcrypt1 is. Le 18/01/2020 à 23:55, Marco d'Itri a écrit : On Jan 07, Guillaume Brocker wrote: janv. 06 11:10:46 sigismund sshd[27148]: /usr/sbin/sshd: /lib/i386-linux-gnu/libcrypt.so.1: version `XCRYPT_2.0' not found (required by /usr/sbin/sshd) Does purging libxcrypt1 make it work? If you can confirm this then I will make the next libcrypt1 conflict with it. I did not expect for libxcrypt1 to be still around since it was not shipped in buster and nobody really ever used it.
Bug#949035: blender: crashes when opening certain files
libgeos_c.so.1 => /lib/x86_64-linux-gnu/libgeos_c.so.1
(0x7f294620a000)
libepsilon.so.1 => /lib/x86_64-linux-gnu/libepsilon.so.1
(0x7f29461f)
libodbc.so.2 => /lib/x86_64-linux-gnu/libodbc.so.2 (0x7f294617e000)
libodbcinst.so.2 => /lib/x86_64-linux-gnu/libodbcinst.so.2
(0x7f2946164000)
libkmlbase.so.1 => /lib/x86_64-linux-gnu/libkmlbase.so.1
(0x7f2946146000)
libkmldom.so.1 => /lib/x86_64-linux-gnu/libkmldom.so.1
(0x7f294608c000)
libkmlengine.so.1 => /lib/x86_64-linux-gnu/libkmlengine.so.1
(0x7f2946051000)
libxerces-c-3.2.so => /lib/x86_64-linux-gnu/libxerces-c-3.2.so
(0x7f2945ca6000)
libnetcdf.so.13 => /lib/x86_64-linux-gnu/libnetcdf.so.13
(0x7f2945b65000)
libhdf5_serial.so.103 => /lib/x86_64-linux-gnu/libhdf5_serial.so.103
(0x7f29457de000)
libmfhdfalt.so.0 => /lib/libmfhdfalt.so.0 (0x7f29457b4000)
libdfalt.so.0 => /lib/libdfalt.so.0 (0x7f294570b000)
libogdi.so.4.1 => /lib/libogdi.so.4.1 (0x7f29456ed000)
libgeotiff.so.5 => /lib/x86_64-linux-gnu/libgeotiff.so.5
(0x7f29456b8000)
libcfitsio.so.8 => /lib/x86_64-linux-gnu/libcfitsio.so.8
(0x7f29453b1000)
libpq.so.5 => /lib/x86_64-linux-gnu/libpq.so.5 (0x7f2945354000)
libproj.so.15 => /lib/x86_64-linux-gnu/libproj.so.15
(0x7f2945067000)
libdapclient.so.6 => /lib/x86_64-linux-gnu/libdapclient.so.6
(0x7f294501e000)
libdap.so.25 => /lib/x86_64-linux-gnu/libdap.so.25 (0x7f2944e78000)
libspatialite.so.7 => /lib/x86_64-linux-gnu/libspatialite.so.7
(0x7f29448e5000)
libcurl-gnutls.so.4 => /lib/x86_64-linux-gnu/libcurl-gnutls.so.4
(0x7f2944857000)
libfyba.so.0 => /lib/x86_64-linux-gnu/libfyba.so.0 (0x7f29447fb000)
libmariadb.so.3 => /lib/x86_64-linux-gnu/libmariadb.so.3
(0x7f29447a4000)
libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1
(0x7f294474e000)
libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0
(0x7f29446be000)
libdatrie.so.1 => /lib/x86_64-linux-gnu/libdatrie.so.1
(0x7f29446b2000)
libgraphite2.so.3 => /lib/x86_64-linux-gnu/libgraphite2.so.3
(0x7f2944686000)
libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x7f294466c000)
libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1
(0x7f2944381000)
libblas.so.3 => /lib/x86_64-linux-gnu/libblas.so.3 (0x7f2944312000)
liblapack.so.3 => /lib/x86_64-linux-gnu/liblapack.so.3
(0x7f2943c6d000)
libarpack.so.2 => /lib/x86_64-linux-gnu/libarpack.so.2
(0x7f2943c24000)
libsuperlu.so.5 => /lib/x86_64-linux-gnu/libsuperlu.so.5
(0x7f2943bb1000)
libnss3.so => /lib/x86_64-linux-gnu/libnss3.so (0x7f2943a61000)
libsmime3.so => /lib/x86_64-linux-gnu/libsmime3.so (0x7f2943a32000)
libnspr4.so => /lib/x86_64-linux-gnu/libnspr4.so (0x7f29439ef000)
libgeos-3.8.0.so => /lib/x86_64-linux-gnu/libgeos-3.8.0.so
(0x7f2943814000)
libpopt.so.0 => /lib/x86_64-linux-gnu/libpopt.so.0 (0x7f2943806000)
libltdl.so.7 => /lib/x86_64-linux-gnu/libltdl.so.7 (0x7f29437fb000)
libminizip.so.1 => /lib/x86_64-linux-gnu/libminizip.so.1
(0x7f29435ef000)
liburiparser.so.1 => /lib/x86_64-linux-gnu/liburiparser.so.1
(0x7f29435ce000)
libhdf5_serial_hl.so.100 =>
/lib/x86_64-linux-gnu/libhdf5_serial_hl.so.100 (0x7f29435a8000)
libsz.so.2 => /lib/x86_64-linux-gnu/libsz.so.2 (0x7f29435a3000)
libssl.so.1.1 => /lib/x86_64-linux-gnu/libssl.so.1.1
(0x7f2943511000)
libldap_r-2.4.so.2 => /lib/x86_64-linux-gnu/libldap_r-2.4.so.2
(0x7f29434bc000)
libsqlite3.so.0 => /lib/x86_64-linux-gnu/libsqlite3.so.0
(0x7f2943391000)
libnghttp2.so.14 => /lib/x86_64-linux-gnu/libnghttp2.so.14
(0x7f2943368000)
librtmp.so.1 => /lib/x86_64-linux-gnu/librtmp.so.1 (0x7f2943349000)
libssh2.so.1 => /lib/x86_64-linux-gnu/libssh2.so.1 (0x7f294331b000)
libpsl.so.5 => /lib/x86_64-linux-gnu/libpsl.so.5 (0x7f2943308000)
liblber-2.4.so.2 => /lib/x86_64-linux-gnu/liblber-2.4.so.2
(0x7f29432f5000)
libbrotlidec.so.1 => /lib/x86_64-linux-gnu/libbrotlidec.so.1
(0x7f29432e7000)
libfyut.so.0 => /lib/x86_64-linux-gnu/libfyut.so.0 (0x7f29432db000)
libfygm.so.0 => /lib/x86_64-linux-gnu/libfygm.so.0 (0x7f29432d2000)
libgfortran.so.5 => /lib/x86_64-linux-gnu/libgfortran.so.5
(0x7f2943043000)
libnssutil3.so => /lib/x86_64-linux-gnu/libnssutil3.so
(0x7f294300e000)
libplc4.so => /lib/x86_64-linux-gnu/libplc4.so (0x7f2943007000)
libplds4.so => /lib/x86_64-linux-gnu/libplds4.so (0x7f2943002000)
libaec.so.0 => /lib/x86_64-linux-gnu/libaec.so.0 (0x7f2942ff9000)
libsasl2.so.2 => /lib/x86_64-linux-gnu/libsasl2.so.2
(0x7f2942fdd000)
libbrotlicommon.so.1 => /lib/x86_64-linux-gnu/libbrotlicommon.so.1
(0x7f2942fb8000)
libquadmath.so.0 => /lib/x86_64-linux-gnu/libquadmath.so.0
(0x7f2942f6f000)
>
> So I guess this report can be closed. Will leave that up to the Debian
> team though, I don't know their policies :)
>
> Cheers,
> - Julian -
Cheers,
--
Guillaume Clercin
signature.asc
Description: This is a digitally signed message part.
Bug#949035: blender: crashes when opening certain files
Package: blender Version: 2.81.a+dfsg-3 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Updating to the latest version. * What was the outcome of this action? Blender crashes like this: % blender -b de2.blend Blender 2.81 (sub 16) Read prefs: /home/guillaume/.config/blender/2.81/config/userpref.blend Read blend: /home/guillaume/Image/blender/de2.blend blender(BLI_system_backtrace+0x33) [0x559481933df3] blender(blo_do_versions_280+0x588f) [0x55948170cd7f] blender(+0x1282925) [0x5594816e1925] blender(blo_read_file_internal+0xb2e) [0x5594816f636e] blender(BLO_read_from_file+0x3d) [0x55948171657d] blender(BKE_blendfile_read+0x30) [0x559482146550] blender(WM_file_read+0x146) [0x559481b291d6] blender(+0x127e737) [0x5594816dd737] blender(BLI_argsParse+0xd7) [0x5594818e5a67] blender(main+0x26f) [0x5594816a4e8f] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7f846566ebbb] blender(_start+0x2a) [0x5594816dc8ba] BLI_assert failed: /build/blender-WIjrmw/blender-2.81.a+dfsg/source/blender/blenloader/intern/versioning_280.c:2577, blo_do_versions_280(), at 'ar_header' * What outcome did you expect instead? As previous version of blender, open the file. *** End of the template - remove these template lines *** -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages blender depends on: ii blender-data 2.81.a+dfsg-3 ii fonts-dejavu 2.37-1 ii libavcodec58 7:4.2.1-2+b1 ii libavdevice58 7:4.2.1-2+b1 ii libavformat58 7:4.2.1-2+b1 ii libavutil56 7:4.2.1-2+b1 ii libboost-locale1.67.0 1.67.0-17 ii libc6 2.29-8 ii libfftw3-double3 3.3.8-2 ii libfreetype6 2.10.1-2 ii libgcc1 1:9.2.1-22 ii libgl11.3.0-7 ii libglew2.12.1.0-4+b1 ii libgomp1 9.2.1-22 ii libilmbase24 2.3.0-6 ii libjack-jackd2-0 [libjack-0.125] 1.9.12~dfsg-2+b1 ii libjemalloc2 5.2.1-1 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libopenal11:1.19.1-1+b1 ii libopencolorio1v5 1.1.1~dfsg0-5 ii libopenexr24 2.3.0-6 ii libopenimageio2.0 2.0.12~dfsg0-1 ii libopenjp2-7 2.3.1-1 ii libopenvdb5.2 5.2.0-7 ii libosdcpu3.4.03.4.0-6 ii libosdgpu3.4.03.4.0-6 ii libpcre3 2:8.39-12+b1 ii libpng16-16 1.6.37-1 ii libpython3.7 3.7.6-1 ii libsndfile1 1.0.28-6 ii libspnav0 0.2.3-1+b2 ii libstdc++69.2.1-22 ii libswscale5 7:4.2.1-2+b1 ii libtbb2 2020.0-2 ii libtiff5 4.1.0+git191117-2 ii libx11-6 2:1.6.8-1 ii libxfixes31:5.0.3-1 ii libxi62:1.7.9-1 ii libxml2 2.9.4+dfsg1-8 ii libxrender1 1:0.9.10-1 ii libxxf86vm1 1:1.1.4-1+b2 ii zlib1g1:1.2.11.dfsg-1+b1 blender recommends no packages. blender suggests no packages. -- no debconf information de2.blend.gz Description: application/gzip
Bug#948318: openssh-server: Unable to restart sshd restart after upgrade to version 8.1p1-2
Package: openssh-server Version: 1:8.1p1-2 Severity: grave Justification: renders package unusable Dear Maintainer, After upgrading openssh-server from version 8.1p1-1 to version 8.1p1-2, using the apt command line tool, the sshd service failed on restart. Please see below the corresponding log entries : janv. 06 11:10:46 sigismund systemd[1]: Starting OpenBSD Secure Shell server... janv. 06 11:10:46 sigismund sshd[27148]: /usr/sbin/sshd: /lib/i386-linux-gnu/libcrypt.so.1: version `XCRYPT_2.0' not found (required by /usr/sbin/sshd) janv. 06 11:10:46 sigismund systemd[1]: ssh.service: Control process exited, code=exited, status=1/FAILURE janv. 06 11:10:46 sigismund systemd[1]: ssh.service: Failed with result 'exit-code'. janv. 06 11:10:46 sigismund systemd[1]: Failed to start OpenBSD Secure Shell server. janv. 06 11:10:46 sigismund systemd[1]: ssh.service: Scheduled restart job, restart counter is at 1. janv. 06 11:10:46 sigismund systemd[1]: Stopped OpenBSD Secure Shell server. Manual installation of the previous version brought sshd functionnal again. Best regards, Guillaume -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 5.3.0-2-686-pae (SMP w/2 CPU cores) 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 openssh-server depends on: ii adduser3.118 ii debconf [debconf-2.0] 1.5.73 ii dpkg 1.19.7 ii libaudit1 1:2.8.5-2+b1 ii libc6 2.29-7 ii libcom-err21.45.4-1 ii libcrypt1 1:4.4.10-10 ii libgssapi-krb5-2 1.17-6 ii libkrb5-3 1.17-6 ii libpam-modules 1.3.1-5 ii libpam-runtime 1.3.1-5 ii libpam0g 1.3.1-5 ii libselinux13.0-1 ii libssl1.1 1.1.1d-2 ii libsystemd0244-3 ii libwrap0 7.6.q-30 ii lsb-base 11.1.0 ii openssh-client 1:8.1p1-2 ii openssh-sftp-server1:8.1p1-2 ii procps 2:3.3.15-2+b1 ii runit-helper 2.8.14 ii ucf3.0038+nmu1 ii zlib1g 1:1.2.11.dfsg-1+b1 Versions of packages openssh-server recommends: ii libpam-systemd [logind] 244-3 ii ncurses-term 6.1+20191019-1 ii xauth1:1.0.10-1 Versions of packages openssh-server suggests: pn molly-guard pn monkeysphere pn rssh pn ssh-askpass pn ufw -- Configuration Files: /etc/ufw/applications.d/openssh-server [Errno 2] Aucun fichier ou dossier de ce type: '/etc/ufw/applications.d/openssh-server' -- debconf information: * ssh/use_old_init_script: true openssh-server/permit-root-login: true ssh/vulnerable_host_keys: ssh/disable_cr_auth: false ssh/new_config: true ssh/encrypted_host_key_but_no_keygen: openssh-server/password-authentication: true
Bug#947003: network-manager: Incorrect update of /etc/resolv.conf, bad search field
Package: network-manager Version: 1.22.0-1 Severity: important Dear Maintainer, * What led up to the situation? After upgrading network-manager from 1.20.8-1 to 1.22.0-1. * What exactly did you do (or not do) that was effective (or ineffective)? DNS works if I fix /etc/resolv.conf until network-manager restart. * What was the outcome of this action? The file "/etc/resolv.conf" was incorrectly updated. Dot in search field are removed. Example: intellique.com => intelliquecom. * What outcome did you expect instead? As version 1.20.8-1, network-manager update correctly /etc/resolv.conf -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-3-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages network-manager depends on: ii adduser3.118 ii dbus 1.12.16-2 ii init-system-helpers1.57 ii libaudit1 1:2.8.5-2+b1 ii libbluetooth3 5.50-1+b1 ii libc6 2.29-6 ii libcurl3-gnutls7.67.0-2 ii libglib2.0-0 2.62.3-2 ii libgnutls303.6.11.1-2 ii libjansson42.12-1 ii libmm-glib01.10.4-0.1 ii libndp01.6-1+b1 ii libnewt0.520.52.21-4 ii libnm0 1.22.0-1 ii libpam-systemd 244-3 ii libpolkit-agent-1-00.105-26 ii libpolkit-gobject-1-0 0.105-26 ii libpsl50.20.2-2 ii libreadline8 8.0-3 ii libselinux13.0-1 ii libsystemd0244-3 ii libteamdctl0 1.29-1 ii libudev1 244-3 ii libuuid1 2.34-0.1 ii policykit-10.105-26 ii udev 244-3 ii wpasupplicant 2:2.9-3+b1 Versions of packages network-manager recommends: ii crda 3.18-1 ii dnsmasq-base [dnsmasq-base] 2.80-1+b1 ii iptables 1.8.4-1 ii modemmanager 1.10.4-0.1 ii ppp 2.4.7-2+4.1+b1 Versions of packages network-manager suggests: ii isc-dhcp-client 4.4.1-2 pn libteam-utils -- no debconf information
Bug#936071: /usr/share/pam-configs/unix: nullok_secure tries to read /etc/securetty and generates a warning
Hi, This warning also appear on my system when login is attempted through various programs (login, su, gdm-password, ..). Oct 06 12:37:30 XXX login[9367]: pam_unix(login:auth): Couldn't open /etc/securetty: No such file or directory Oct 06 12:37:40 XXX su[9383]: pam_unix(su:auth): Couldn't open /etc/securetty: No such file or directory Oct 06 12:37:56 XXX gdm-password][9612]: pam_unix(gdm-password:auth): Couldn't open /etc/securetty: No such file or directory Note someone also reported this as a login bug. This was closed since this seems to originate from libpam so "there is nothing login can do about that". https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931899 So it would be good to address this within libpam-runtime. A quick look at the implementation shows the file is written by perl script /usr/sbin/pam-auth-update, using a template from /usr/share/pam-configs/unix ii debconf1.5.73 ii libpam-runtime 1.3.1-5 ii login 1:4.7-2 Guillaume
Bug#794410: debian-installer: Installer hangs during 'select and install software'
thank you. i had the same problem (installer always hangs during "select and install software" - around 10% of the progress) my laptop: LENOVO ideapad 100 i install in legacy mode (mbr, not UEFI). i tried with debian 8, 9 and 10: same problem. so i read the comments, and in the BIOS i put: Boot priority: "UEFI first" OS Optimized Defaults: "Win8" then i installed debian 9 (with mbr partitioning, as i always do), and it works.
Bug#932725: Acknowledgement (libunwind8: segfault on MIPS, fix needs backporting)
Hi Adrian, On 22/07/2019 12:09, Debian Bug Tracking System wrote: > Thank you for filing a new Bug report with Debian. > > You can follow progress on this Bug here: 932725: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932725. > > 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): > Adrian Bunk > > If you wish to submit further information on this problem, please > send it to 932...@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. Could you please take a look and see if the fix attached to the bug report can be added to the libunwind package in Buster? This is blocking the i-g-t automated testing from upgrading their Docker images to Buster as i-g-t is run with MIPS and uses libunwind. Best wishes, Guillaume
Bug#932134: libossim1: Segmentation fault in ossimTiffProjectionFactory
Some updates: the problem was a missing 'return true' in a Ossim source file, it has been fixed upstream, after 2.9.0 : https://github.com/ossimlabs/ossim/commit/3505f182e9cd7c836be29f93a23c3c9b1842fc24 Maybe you can backport it to 2.8.2. On OTB side, a patch is needed to fix several missing 'std::', a merge request is opened on develop: https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/merge_requests/575. Regards, On 7/16/19 4:25 PM, Guillaume Pasero wrote: Unfortunately, the bug is still present in 2.8.2, same backtrace. I'll see if there is a workaround for OTB. Regards, On 7/15/19 9:01 PM, Sebastiaan Couwenberg wrote: We could try upgrading ossim to 2.8.2. maybe that contains a fix. -- Guillaume PASERO Responsable technique Business Unit ESPACE & GeoInformation - Département Payload Data & Applications CS Systèmes d'Information Parc de la Grande Plaine - 5, Rue Brindejonc des Moulinais - BP 15872 31506 Toulouse Cedex 05 - FRANCE +33 561 17 64 21 - guillaume.pas...@c-s.fr -- Guillaume PASERO Responsable technique Business Unit ESPACE & GeoInformation - Département Payload Data & Applications CS Systèmes d'Information Parc de la Grande Plaine - 5, Rue Brindejonc des Moulinais - BP 15872 31506 Toulouse Cedex 05 - FRANCE +33 561 17 64 21 - guillaume.pas...@c-s.fr
Bug#932725: libunwind8: segfault on MIPS, fix needs backporting
Source: libunwind
Version: 1.2.1-9
Severity: grave
Tags: patch
Justification: renders package unusable
Dear Maintainer,
* What led up to the situation?
I was running i-g-t on MIPS and hit a segfault during a stack
trace dump.
I then built the package from source to reproduce it, and found a
fix upstream for it (patch attached).
Discussion on the igt-dev mailing list:
https://lists.freedesktop.org/archives/igt-dev/2019-July/015029.html
-- System Information:
Debian Release: 10.0
APT prefers stable
APT policy: (500, 'stable'), (500, 'oldstable')
Architecture: mips
Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
>From 23ed1a35645e9e83beb2d4de0bd682c18d9fd58f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=9A=D0=BE=D1=80=D0=BE=D0=BB=D0=B5=D0=B2=20=D0=A1=D0=B5?=
=?UTF-8?q?=D1=80=D0=B3=D0=B5=D0=B9?=
Date: Wed, 22 Jun 2016 19:53:02 +0300
Subject: [PATCH] tdep_uc_addr: use +4 offset for UNW_MIPS_PC on MIPS (be)
According to mcontext_t definition its "pc" field
is also 64 bit wide and thus requires 4 byte offset
on MIPS32 (be).
---
src/mips/Ginit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mips/Ginit.c b/src/mips/Ginit.c
index 8290c408..83b100fb 100644
--- a/src/mips/Ginit.c
+++ b/src/mips/Ginit.c
@@ -59,7 +59,7 @@ tdep_uc_addr (ucontext_t *uc, int reg)
{
char *addr = uc_addr (uc, reg);
- if (reg >= UNW_MIPS_R0 && reg <= UNW_MIPS_R31
+ if (((reg >= UNW_MIPS_R0 && reg <= UNW_MIPS_R31) || reg == UNW_MIPS_PC)
&& tdep_big_endian (unw_local_addr_space)
&& unw_local_addr_space->abi == UNW_MIPS_ABI_O32)
addr += 4;
--
2.20.1
Bug#932134: libossim1: Segmentation fault in ossimTiffProjectionFactory
Unfortunately, the bug is still present in 2.8.2, same backtrace. I'll see if there is a workaround for OTB. Regards, On 7/15/19 9:01 PM, Sebastiaan Couwenberg wrote: We could try upgrading ossim to 2.8.2. maybe that contains a fix. -- Guillaume PASERO Responsable technique Business Unit ESPACE & GeoInformation - Département Payload Data & Applications CS Systèmes d'Information Parc de la Grande Plaine - 5, Rue Brindejonc des Moulinais - BP 15872 31506 Toulouse Cedex 05 - FRANCE +33 561 17 64 21 - guillaume.pas...@c-s.fr
Bug#932134: libossim1: Segmentation fault in ossimTiffProjectionFactory
Package: libossim1 Version: 2.7.2-1 Severity: important Dear Maintainer, I am using libossim1 through Orfeo ToolBox and I noticed a crash when upgrading Ossim from 2.6.2 to 2.7.2. There is a segmentation fault when using the ossimImageHandler::getImageGeometry() on a TIFF file. The steps to reproduce are: * Get a docker image ready to build OTB : registry.orfeo-toolbox.org/orfeotoolbox/otb-build-env/otb-debian-native:unstable * run the docker container as root * Upgrade Ossim to 2.7.2 * make sure LFS is installed: git lfs install * clone OTB sources (develop branch) : git clone https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb * in OTB sources, run : ctest -VV -S CI/main_ci.cmake -DIMAGE_NAME=debian-unstable-gcc * after the test fails you can re-run a test manually, for instance: ctest -VV -R ioTvMultiResolutionReadingInfo_TIFF Here is a backtrace I got on this test: (gdb) r Starting program: /opt/build/bin/otbImageIOTestDriver --compare-ascii 0.0 /opt/src/Data/Baseline/OTB/Files/ioTvMultiResolutionReadingInfoOut_tiff.txt /opt/build/Testing/Temporary/ioTvMultiResolutionReadingInfoOut_tiff.txt otbMultiResolutionReadingInfo /opt/src/Data/Input/maur_rgb.tif /opt/build/Testing/Temporary/ioTvMultiResolutionReadingInfoOut_tiff.txt [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". 2019-07-15 16:09:05 (INFO): Default RAM limit for OTB is 256 MB 2019-07-15 16:09:05 (INFO): GDAL maximum cache size is 798 MB 2019-07-15 16:09:05 (INFO): OTB will use at most 4 threads Program received signal SIGSEGV, Segmentation fault. 0x7658dbf7 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() () from /usr/lib/libossim.so.1 (gdb) bt #0 0x7658dbf7 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() () from /usr/lib/libossim.so.1 #1 0x765332cf in ?? () from /usr/lib/libossim.so.1 #2 0x7fffda40 in ?? () #3 0x7fffd9c0 in ?? () #4 0x000c in ?? () #5 0x61665f656c616373 in ?? () #6 0x6700726f7463 in ?? () #7 0x5581ce70 in ?? () #8 0x167ef0d427ecc700 in ?? () #9 0x0016 in ?? () #10 0x557d8320 in ?? () #11 0x5581ce60 in ?? () #12 0x5581ce60 in ?? () #13 0x7fffdac0 in ?? () #14 0x7fffda40 in ?? () #15 0x5581ce70 in ?? () #16 0x76c1a9dc in ossimTiffProjectionFactory::createProjection(ossimImageHandler*) const () from /usr/lib/libossim.so.1 #17 0x76bc02a5 in ossimProjectionFactoryRegistry::createProjection(ossimImageHandler*) const () from /usr/lib/libossim.so.1 #18 0x768c7d7f in ossimImageGeometryFactory::extendGeometry(ossimImageHandler*) const () from /usr/lib/libossim.so.1 #19 0x768c8754 in ossimImageGeometryRegistry::extendGeometry(ossimImageHandler*) const () from /usr/lib/libossim.so.1 #20 0x768cc54b in ossimImageHandler::getImageGeometry() () from /usr/lib/libossim.so.1 #21 0x7759e7d2 in otb::ReadGeometryFromImage(std::__cxx11::basic_string, std::allocator > const&, bool) () from /opt/build/lib/libOTBOSSIMAdapters-6.7.so.1 #22 0x77d07db2 in otb::ImageFileReader, otb::DefaultConvertPixelTraits >::GenerateOutputInformation() () from /opt/build/lib/libOTBImageIO-6.7.so.1 #23 0x756e5c9d in itk::ProcessObject::UpdateOutputInformation() () from /usr/lib/libITKCommon-4.12.so.1 #24 0x55685472 in otbMultiResolutionReadingInfo(int, char**) () #25 0x555d39d3 in main () -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.13.0-170-generic (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages libossim1 depends on: ii libc62.28-10 ii libfreetype6 2.9.1-3 ii libgcc1 1:9.1.0-8 ii libgeos-3.7.13.7.1-1 ii libgeos-c1v5 3.7.1-1 ii libgeotiff2 1.4.3-1 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libjsoncpp1 1.7.4-3 ii libstdc++6 9.1.0-8 ii libtiff5 4.0.10-4 ii zlib1g 1:1.2.11.dfsg-1 libossim1 recommends no packages. libossim1 suggests no packages. -- no debconf information
Bug#928352: nvidia-kernel-dkms: dkms did not automatically rebuild nvidia module for newly installed kernel
On Fri, 3 May 2019 01:22:37 +0200 Andreas Beckmann wrote: > On 2019-05-02 18:41, guillaume raffy wrote: > > Indeed, on our server, "linux-headers-4.9.0-8-all-amd64" was installed but not "linux-headers-amd64". I believe that if the package "linux-headers-amd64" was installed in the first place, then aptitude full-upgrade would have brought "linux-headers-4.9.0-9-all-amd64" along with the kernel, and the rebuild of the nvidia module would have then succeeded. But that's merely an hypothesis, as I'm not an expert. > > Exactly, if the linux-headers-amd64 metapackage had been installed, > everything would have worked as expected. > Since it it out of our realm to guess which kernel you want to run (and > therefore which kernel headers you need), I'm closing this bug. > > But feel free to point us to the places in the documentation where you > would have expected to find this information. > > The description of the nvidia-kernel-dkms package currently contains: > ... > Provided that you have the kernel header packages installed, the kernel > module will be built for your running kernel and automatically rebuilt for > any new kernel headers that are installed. > ... > > The dkms package itself has > Recommends: fakeroot, sudo, linux-headers-686-pae | linux-headers-amd64 > | linux-headers-generic | linux-headers, lsb-release > > > Andreas Hi Andreas, Thank you very much for your clear answer. It helped me realize that the problem comes from the fact that we tweaked Debian's default settings (for some yet unknown reason, our configuration system had set Install-Recommends to false). This problem wouldn't happen for a basic user, which is good! Thanks again and sorry for the trouble. Guillaume
Bug#928352: nvidia-kernel-dkms: dkms did not automatically rebuild nvidia module for newly installed kernel
Package: nvidia-kernel-dkms Version: 390.116-1 Severity: serious Justification: Policy 3.5 Dear Maintainer, An upgrade from kernel 4.9.0-8 to kernel 4.9.0-9 broke nvidia-kernel-dkms on our server, which has 2 gpus for gpgpu computing: although nvidia-kernel-dkms was upgraded too in the process (as it was part of debian 9 upgrade 7 release), the modules weren't rebuilt, as shown with the following command : root@physix58:~# lsmod | grep nvidia root@physix58:~# find /lib/modules/ -name "nvidia*" /lib/modules/4.9.0-9-amd64/kernel/drivers/net/ethernet/nvidia /lib/modules/4.9.0-8-amd64/kernel/drivers/net/ethernet/nvidia /lib/modules/4.9.0-8-amd64/updates/dkms/nvidia-current-modeset.ko /lib/modules/4.9.0-8-amd64/updates/dkms/nvidia-current-uvm.ko /lib/modules/4.9.0-8-amd64/updates/dkms/nvidia-current.ko /lib/modules/4.9.0-8-amd64/updates/dkms/nvidia-current-drm.ko I managed to get the nvidia modules rebuilt for kernel 4.9.0-9 by using "dpkg-reconfigure nvidia-kernel-dkms", but only after I installed linux-headers-4.9.0-9-all-amd64 (linux-headers-4.9.0-8-all-amd64 was installed but not linux-headers-4.9.0-9-all-amd64). I suspect that "dpkg-reconfigure nvidia-kernel-dkms" failed because of missing headers when invoked by "aptitude full-upgrade", but I can't be sure... This problem seems to be the same as a very old bug report : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=585862 By looking at this issue on internet, it seems that this problem is quite common, and people usually get on with it just by rebuilding the modules as I did. However, I have the impression that the intended behaviour is that nvidia module be automatically rebuilt whenever there is a kernel upgrade, which is indeed what the user wants. So, I suspect that this automatic mechanism fails to work in some cases. On https://www.reddit.com/r/linuxquestions/comments/6mqudq/ran_aptget_distupgrade_which_updated_kernel_now/, debian_miner says "I just did some testing with this, and I believe the reason some people are seeing this behavior is because they didn't install the linux-headers- metapackage" Indeed, on our server, "linux-headers-4.9.0-8-all-amd64" was installed but not "linux-headers-amd64". I believe that if the package "linux-headers-amd64" was installed in the first place, then aptitude full-upgrade would have brought "linux-headers-4.9.0-9-all-amd64" along with the kernel, and the rebuild of the nvidia module would have then succeeded. But that's merely an hypothesis, as I'm not an expert. Some things that might be worth noting : 1. the command that upgraded the kernel is "UCF_FORCE_CONFFNEW=1 DEBIAN_FRONTEND=noninteractive APT_LISTCHANGES_FRONTEND=none yes '' | aptitude -y -o Dpkg::Options::="--force-confnew" -o Aptitude::Cmdline::ignore-trust-violations=true full-upgrade". It upgraded the following packages : root@physix58:~# grep -B 1 linux-image /var/log/apt/history.log-20190501 Start-Date: 2019-04-30 08:40:22 Install: linux-image-4.9.0-9-amd64:amd64 (4.9.168-1, automatic) Upgrade: ca-certificates-java:amd64 (20170929~deb9u1, 20170929~deb9u3), postfix:amd64 (3.1.9-0+deb9u2, 3.1.12-0+deb9u1), libglx0-glvnd-nvidia:amd64 (390.87-8~deb9u1, 390.116-1), postfix-pcre:amd64 (3.1.9-0+deb9u2, 3.1.12-0+deb9u1), linux-libc-dev:amd64 (4.9.144-3.1, 4.9.168-1), libnvidia-ml1:amd64 (390.87-8~deb9u1, 390.116-1), nvidia-egl-icd:amd64 (390.87-8~deb9u1, 390.116-1), nvidia-driver:amd64 (390.87-8~deb9u1, 390.116-1), libpng-dev:amd64 (1.6.28-1, 1.6.28-1+deb9u1), postfix-sqlite:amd64 (3.1.9-0+deb9u2, 3.1.12-0+deb9u1), libmagickwand-6.q16-3:amd64 (8:6.9.7.4+dfsg-11+deb9u6, 8:6.9.7.4+dfsg-11+deb9u7), python3-pip:amd64 (9.0.1-2, 9.0.1-2+deb9u1), libjs-jquery:amd64 (3.1.1-2, 3.1.1-2+deb9u1), nvidia-vdpau-driver:amd64 (390.87-8~deb9u1, 390.116-1), libgl1-nvidia-glvnd-glx:amd64 (390.87-8~deb9u1, 390.116-1), libglx-nvidia0:amd64 (390.87-8~deb9u1, 390.116-1), linux-compiler-gcc-6-x86:amd64 (4.9.144-3.1, 4.9.168-1), libpq5:amd64 (9.6.11-0+deb9u1, 9.6.12-0+deb9u1), nvidia-kern el-dkms: amd64 (390.87-8~deb9u1, 390.116-1), libegl-nvidia0:amd64 (390.87-8~deb9u1, 390.116-1), nvidia-egl-common:amd64 (390.87-8~deb9u1, 390.116-1), python-cryptography:amd64 (1.7.1-3, 1.7.1-3+deb9u1), libnvidia-ptxjitcompiler1:amd64 (390.87-8~deb9u1, 390.116-1), nvidia-legacy-check:amd64 (390.87-8~deb9u1, 390.116-1), libzzip-0-13:amd64 (0.13.62-3.1, 0.13.62-3.2~deb9u1), libnvidia-fatbinaryloader:amd64 (390.87-8~deb9u1, 390.116-1), linux-image-amd64:amd64 (4.9+80+deb9u6, 4.9+80+deb9u7), nvidia-kernel-support:amd64 (390.87-8~deb9u1, 390.116-1), libgstreamer-plugins-base1.0-0:amd64 (1.10.4-1, 1.10.4-1+deb9u1), linux-kbuild-4.9:amd64 (4.9.144-3.1, 4.9.168-1), nvidia-driver-libs:amd64 (390.87-8~deb9u1, 390.116-1), nvidia-driver-bin:amd64 (390.87-8~deb9u1, 390.116-1), libjs-bootstrap:amd64 (3.3.7+dfsg-2+deb9u1, 3.3.7+dfsg-2+deb9u2), libmagickcore-6.q16-3:amd64 (8:6.9.7.4+dfsg-11+deb9u6, 8:6.9.7.4
Bug#927994: neomutt: bdb and lmdb hcache backends are not available
Package: neomutt
Version: 20180716+dfsg.1-1
Severity: normal
Dear Maintainer,
I have some large maildirs (>50k emails), so I am trying to use neomutt
with bdb or lmdb hcache backend, because according to benchmarks they
should be a lot faster than tokyocabinet to handle to the header cache:
https://neomutt.org/contrib/hcache-bench
The neomutt package in Debian doesn't seem to be built with theses
options enabled, because when lauching neomutt I get an error : lmdb:
`invalid backend`
`mutt -v` confirms it : `hcache backends: tokyocabinet`
I recompiled neomutt with lmdb and bdb support, and I can really confirm
the benchmark, they are 3 times faster than tokyocabinet.
So I am wondering, why bdb and lmdb are not enabled in your package, and
could you add them?
Thank you.
-- Package-specific info:
NeoMutt 20180716
Copyright (C) 1996-2016 Michael R. Elkins and others.
NeoMutt comes with ABSOLUTELY NO WARRANTY; for details type 'neomutt -vv'.
NeoMutt is free software, and you are welcome to redistribute it
under certain conditions; type 'neomutt -vv' for details.
System: Linux 4.19.0-3-amd64 (x86_64)
ncurses: ncurses 6.1.20181013 (compiled with 6.1.20180714)
libidn: 1.33 (compiled with 1.33)
hcache backends: tokyocabinet
Compiler:
Using built-in specs.
COLLECT_GCC=cc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 7.3.0-25'
--with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.3.0 (Debian 7.3.0-25)
Configure options: --build=x86_64-linux-gnu --prefix=/usr
{--includedir=${prefix}/include} {--mandir=${prefix}/share/man}
{--infodir=${prefix}/share/info} --sysconfdir=/etc --localstatedir=/var
--disable-silent-rules {--libdir=${prefix}/lib/x86_64-linux-gnu}
{--libexecdir=${prefix}/lib/x86_64-linux-gnu} --disable-maintainer-mode
--disable-dependency-tracking --mandir=/usr/share/man --libexecdir=/usr/lib
--with-mailpath=/var/mail --gpgme --lua --notmuch --with-ui --gnutls --gss
--idn --mixmaster --sasl --tokyocabinet
Compilation CFLAGS: -g -O2
-fdebug-prefix-map=/build/neomutt-oDMtzm/neomutt-20180716+dfsg.1=.
-fstack-protector-strong -Wformat -Werror=format-security -std=c99
-D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D__EXTENSIONS__ -I/usr/include
-I/usr/include/lua5.3 -DNCURSES_WIDECHAR -isystem /usr/include/mit-krb5
Default options:
+attach_headers_color +compose_to_sender +compress +cond_date +debug
+encrypt_to_self +forgotten_attachments +forwref +ifdef +imap +index_color
+initials +limit_current_thread +multiple_fcc +nested_if +new_mail +nntp +pop
+progress +quasi_delete +regcomp +reply_with_xorig +sensible_browser +sidebar
+skip_quoted +smtp +status_color +timeout +tls_sni +trash
Compile options:
+bkgdset +color +curs_set +fcntl -flock -fmemopen +futimens +getaddrinfo
+gnutls +gpgme +gss +hcache -homespool +idn -locales_hack +lua +meta
+mixmaster +nls +notmuch -openssl +pgp +sasl +smime +start_color
+sun_attachment +typeahead
MAILPATH="/var/mail"
MIXMASTER="mixmaster"
PKGDATADIR="/usr/share/neomutt"
SENDMAIL="/usr/sbin/sendmail"
SYSCONFDIR="/etc"
To learn more about NeoMutt, visit: https://neomutt.org
If you find a bug in NeoMutt, please raise an issue at:
https://github.com/neomutt/neomutt/issues
or send an email to:
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
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 neomutt depends on:
ii libc6 2.28-8
ii libcom-err2 1.45.0-1
ii libgnutls30 3.6.7-2
ii libgpgme111.12.0-6
ii libgssapi-krb5-2 1.17-2
ii libidn11 1.33-2.2
ii libk5cr
Bug#924296: check_ping: check_ping -4 does an IPv6 check
Package: nagios-plugins Version: 2.2-3 If the remote host has an IPv6 address configured, the check_ping plugin seems to do an ICMPv6 check, even when we use -4 to force IPv4. You can reproduce by doing a check_ping -4 $ /usr/lib/nagios/plugins/check_ping -4 -H www.sysnove.net -w 1000,100% -c 2000,100% -p 1 PING OK - Paquets perdus = 0%, RTA = 1.36 ms|rta=1.364000ms;1000.00;2000.00;0.00 pl=0%;100;100;0 while monitoring the network with tcpdump. $ sudo tcpdump -i any dst 2001:bc8:3977:802::1 and icmp6 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes 09:58:34.772859 IP6 infra-mon04.sysnove.net > sysnove-www01.sysnove.net: ICMP6, echo request, seq 1, length 64 I'm using an up to date Debian 9.6 with nagios-plugins 2.2-3. This problem is not present on 8.11 with nagios-plugins 2.1.1-1. -- Guillaume Subiron Mail - maet...@subiron.org GPG - 5BC2 EADB MSTDN - @maet...@mstdn.fr IRC - maethor@(freenode|geeknode)
Bug#912631: liblwjgl-java-jni: Missing symbols in liblwjgl.so, stretch-sid, 386, amd64, mips
Hello,
and thank you very much for your answer.
First, about OpenJDK 11, and "debian/patches/javah.patch". You are
absolutely right to point that out. Actually, I had missed that the
"javah" tool was removed since OpenJDK 10. Sorry for that.
I was able to reproduce the same error as the one you showed with
OpenJDK 11.
If we take care of a few more C headers include and constant export, it
works. At least for me.
Maybe just a thing to note: the path to "libjawt.so" has changed between
8 and 11, and we need to remove the "${os.arch}" part when giving that
path to GCC, in "platform_build/linux_ant/build.xml".
Please find attached a new version of the patch I proposed, including
those modifications specific to OpenJDK 11.
Should you want to try it, please apply after everything else, including
"javah.patch". (but not the previous version I sent).
Please let me know if this works for you, or maybe what you think about it.
Then, about "OpenGL" and "OpenGL ES": from what I understand they are
two versions of the same thing.
From Wikipedia: "OpenGL for Embedded Systems (OpenGL ES) is a subset of
the OpenGL computer graphics rendering application programming interface
(API)" <https://en.wikipedia.org/wiki/OpenGL_ES>.
About the technical details: in the "build.xml" file, in the root
folder, there is a "compile_native" and "compile_native_es". When we
look at "debian/rules", the "override_dh_auto_build" calls
"compile_native", but never "compile_native_es". And it seems to me that
"compile_native_es" is the only target to call Ant with
"platform_build/linux_ant/build_es.xml" (which is the only build file to
include C files in the sub folders named "opengles"). Also, when looking
at "platform_build/linux_ant/build.xml", the targets that were defined
by upstream (or at least in
<https://github.com/LWJGL/lwjgl/blob/master/platform_build/linux_ant/build.xml>)
do not include the C files in the "opengles" folders. And finally, if I
remember correctly, at first I tried to include C files from every sub
folders, but ended up with conflicting redefinitions of the same C
functions.
So, I am not sure whether we need "OpenGL ES" support or not. And if we
do, I don't know how it should be packaged. But personally I would
simply leave it out, at least for now.
Regards,
Guillaume
Description: Compile and add to library missing object files
Some C files present in "src/native/common", and "src/native/linux"
were not included in the native library build. This patch should include them
back.
.
Also, when building the Debian package, the library "jawt", which is a
dependency, was missing as well when building the native library.
.
This patch should allow building the Debian package with OpenJDK 11.
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912631#5
Last-Update: 2018-12-31
--- lwjgl-2.9.3+dfsg.orig/platform_build/linux_ant/build.xml
+++ lwjgl-2.9.3+dfsg/platform_build/linux_ant/build.xml
@@ -6,7 +6,7 @@
-
+
@@ -148,8 +148,12 @@
+
-
+
+
+
+
--- lwjgl-2.9.3+dfsg.orig/src/java/org/lwjgl/opengl/Pbuffer.java
+++ lwjgl-2.9.3+dfsg/src/java/org/lwjgl/opengl/Pbuffer.java
@@ -52,6 +52,7 @@ public final class Pbuffer extends Drawa
/**
* Indicates that Pbuffers can be created.
*/
+ @java.lang.annotation.Native
public static final int PBUFFER_SUPPORTED = 1 << 0;
/**
--- lwjgl-2.9.3+dfsg.orig/src/native/linux/opengl/org_lwjgl_opengl_Pbuffer.c
+++ lwjgl-2.9.3+dfsg/src/native/linux/opengl/org_lwjgl_opengl_Pbuffer.c
@@ -42,6 +42,7 @@
#include
#include "org_lwjgl_opengl_LinuxPbufferPeerInfo.h"
#include "org_lwjgl_opengl_Pbuffer.h"
+#include "org_lwjgl_opengl_LinuxDisplay.h"
#include "extgl.h"
#include "context.h"
#include "common_tools.h"
Bug#913493: RFS: geneweb/6.08+git20181019+dfsg-1
Dear Sébastien, Following your review, the package has been updated on: https://mentors.debian.net/package/geneweb https://salsa.debian.org/GuillaumeBrochu-guest/geneweb I have also tested it with a fresh pbuilder image and with lintian. Here is the new changelog: geneweb (6.08+git20181019+dfsg-1) unstable; urgency=medium * New upstream release: https://github.com/geneweb/geneweb/archive/9641e494cd85fb1b7baba32412d120da38234ba2.tar.gz https://github.com/geneweb/geneweb/commits/distrib-6-08-ocaml-4-xx (Last commit : 2018-10-19) Fixes a bug in /hd/etc/templ502/updfam.txt: https://github.com/geneweb/geneweb/issues/642 Fixes ocaml warnings and correct English errors * New maintainer (Guillaume Brochu), Christian Perrier now in uploaders * New git repository to replace Alioth: https://salsa.debian.org/GuillaumeBrochu-guest/geneweb * Fix debian/copyright * Build and add connex to geneweb package (renamed geneweb-connex) Closes: #912915 * Use upstream a.gwf as default.gwf for gwtp Also put default.gwf in var/lib/geneweb * Patches updated using gbp pq, cleaning of compile-gui patch * Remove duplicate entries in changelog (that were there since May 2007) * Add override_dh_auto_configure to fix a problem that appeared with debhelper 11.5 * Standards-Version: 4.3.0 * Debhelper Build-Depends 9 -> 11, use debhelper-compat * Remove Pre-Depends on dpkg (>= 1.15.6~) * Build-Depends: Replace ocaml-best-compilers and ocaml by ocaml-nox * Remove lynx in Suggests of geneweb * Remove adduser in Pre-Depends of geneweb-gui * Add Keywords entry to .desktop files, correct translation mistake * Put icons in usr/share/pixmaps * Update isoquery standard : use 639-2 instead of 639 * Add Documentation.desktop in usr/share/doc/geneweb * Use https for homepage https://geneweb.org * Cleaning of .docs, .dirs, .links, .prerm, and rules * Other minor changes (lintian warnings, gbp.conf, etc.) -- Guillaume Brochu Thu, 27 Dec 2018 12:25:00 -0500 With best regards, Guillaume Brochu
Bug#912631: liblwjgl-java-jni: Missing symbols in liblwjgl.so, stretch-sid, 386, amd64, mips
Dear package maintainer and Petr Cvek,
I have the same issue. And it seems to me the provided description is
correct: some of the C files do not get compiled and included into the
LWJGL native library.
I think the problematic file is "platform_build/linux_ant/build.xml". It
has a "compiledeb" target (after applying all patches, and especially
"allarchs.patch"), but this target forgets to include in the build some
of the files in subdirectories of "src/native/common" and
"src/native/linux". I believe the thing to do here is to add them back
into the native library while still leaving aside the "opengles" subfolders.
Please see the attached patch file for more details about the proposed
solution. Please also note that "debian/patches/javah.patch" conflicts
with what I propose, as some of the C headers do not get generated
anymore. So you should disable it if you want to try what I suggest.
Also, this "compiledeb" target (still in the
"platform_build/linux_ant/build.xml" file) has another issue, I think.
It does not ask gcc to link against the "jawt" library, while targets
from upstream rules do. However it gives a nice library path to
"libjawt.so", with "-L${java.home}/lib/${os.arch}". So you can see in
the patch I propose I also added back the "-ljawt" argument to the gcc
command line.
After doing these two changes to this file, I have a usable LWJGL. But
my test application (something I could share, if needed) still had
issues, because "libjawt.so" is not accessible to ld. After building the
package, from root folder:
$ ldd libs/linux/liblwjgl.so | grep libjawt.so
libjawt.so => not found
So the folder "/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64" (on my
machine, expanded from "${java.home}/lib/${os.arch}") should be
accessible to the linker. Either by being in the LD_LIBRARY_PATH
environment variable, or better, by being in a file in
"/etc/ld.so.conf.d/". But I am not sure which package should do that.
Hope this helps, and let me know if I can help with this issue.
Regards,
Guillaume
-
Versions used:
LWJGL: liblwjgl-java-jni_2.9.3+dfsg-4
Archithecture: amd64
OpenJDK 8: 8u181-b13-2~deb9u1
Ant: 1.10.5-2
-
On Thu, 01 Nov 2018 19:28:15 -0500 Petr Cvek wrote:
> Package: liblwjgl-java-jni
> Version: 2.9.3+dfsg-1
> Severity: important
>
> Hello,
>
> I was trying to set up my debian for a vintage minecraft test play
and I had to use not bundled
> lwjgl library for it (unsupported architecture). After a quick setup
the java failed with unsatisfied
> link error because of missing symbols in native library. A look into
liblwjgl.so and a compare with
> the bundled version revealed a big differences in library size. The
debian one is about 37kB and
> the bundled one is over 300kB. Some of the missing symbols are:
getJNIVersion, nLockAWT and many
> openGL wrappers. The symbols/native methods calls are present in java
classes.
>
> The problem doesn't depend on system architecture (verified on 386,
amd64 and mipsel) and exists
> on actual stretch and sid (probably doesn't depend on this too).
>
> I've tried to compile my local version, but the problem doesn't get
resolved. I suppose the problem
> is in original build system. I've tried to fix the problem with
copying all .c and .h files into
> a single directory at src/native/linux, which resulted in the working
version of the library.
>
> It seems the build system ignores the (sub)directories other than
src/native/linux. I'm not familiar
> with java development (and ant) nor patching in debian build system
so I'm not able to make a fix.
>
>
> Petr Cvek
>
> -- System Information:
> Debian Release: 9.5
> APT prefers stable-updates
> APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: mipsel
>
> Kernel: Linux 4.9.0-7-amd64 (SMP w/2 CPU cores)
> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8),
LANGUAGE=en_US.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages liblwjgl-java-jni depends on:
> ii libc6 2.24-11+deb9u3
> ii libx11-6 2:1.6.4-3
> ii libxcursor1 1:1.1.14-1+deb9u1
> ii libxrandr2 2:1.5.1-1
> ii libxxf86vm1 1:1.1.4-1+b2
>
> liblwjgl-java-jni recommends no packages.
>
> liblwjgl-java-jni suggests no packages.
>
> -- no debconf information
>
>
Description: Compile and add to library missing object files
Some C files present in "src/native/common", and "src/native/linux"
were not included in the native library build. T
Bug#916038: dash: preinst script failure
Package: dash Version: 0.5.8-2.10 Severity: important Tags: patch upstream Dear Maintainer, Dash installation fails if the copy destination does not exist. Patch here: https://salsa.debian.org/debian/dash/merge_requests/1 -- System Information: Debian Release: buster/sid APT prefers cosmic-updates APT policy: (500, 'cosmic-updates'), (500, 'cosmic-security'), (500, 'cosmic-proposed'), (500, 'cosmic') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.2-041902-generic (SMP w/16 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR:fr_CA:fr_CA (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dash depends on: ii debianutils 4.8.6 ii dpkg 1.19.0.5ubuntu5 ii libc62.28-0ubuntu1 dash recommends no packages. dash suggests no packages. -- debconf information: * dash/sh: true
Bug#915699: phppgadmin is not compatible with php 7
It seems the main project leader came back to maintain the project. See: https://xzilla.net//blog/2018/Nov/The-Ghost-of-phpPgAdmin.html According to this blog post, support for PHP 7 is expected soon or later. On Thu, 06 Dec 2018 09:45:09 +0100 Ladislav Wartha wrote: > Package: phppgadmin > Severity: grave > Tags: patch > Justification: renders package unusable > > Dear Maintainer, > > >* What led up to the situation? > Simply PHP 7.0 stopped accepting old syntax of php 5, and php 7 is > now default >* What exactly did you do (or not do) that was effective (or > ineffective)? > simply downloaded php7 compatible version from git: > https://github.com/halojoy/phppgadmin-for-PHP7 > > However its not from original developer and didn't have time to > check differences between new and old source and if there were some > security holes. > >* What was the outcome of this action? > was working, but seems like nobody is maintaining phppgadmin :-( > > According one note I found on the internet, PostgreSQL 10 is no > longer compatible with phppgadmin 5.1, hope somebody will takeover > over development. > > I would expect at least to set dependency to old php release not to > php7, best case scenario, you will implement the version from > github. > > > -- System Information: > Debian Release: 9.6 > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) > 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 /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages phppgadmin depends on: > ii dpkg 1.18.25 > ii libjs-jquery 3.1.1-2 > ii libphp-adodb 5.20.9-1 > ii php 1:7.0+49 > ii php-cgi 1:7.0+49 > ii php-pgsql 1:7.0+49 > ii php7.0 [php] 7.0.30-0+deb9u1 > ii php7.0-cgi [php-cgi] 7.0.30-0+deb9u1 > ii php7.0-pgsql [php-pgsql] 7.0.30-0+deb9u1 > > Versions of packages phppgadmin recommends: > ii apache2 [httpd] 2.4.25-3+deb9u6 > > Versions of packages phppgadmin suggests: > ii postgresql 9.6+181+deb9u2 > pn postgresql-doc > pn slony1-bin
Bug#913493: RFS: geneweb/6.08+git20181019+dfsg-1
Package: sponsorship-requests Severity: normal X-Debbugs-CC: 073p...@gmail.com, bubu...@debian.org Dear mentors, Dear Boyuan Yang, Dear Christian Perrier, I am looking for a sponsor for the package "geneweb", that is in Debian since July 2000. Actually, I have worked with Christian Perrier since 2 1/2 years to maintain this package. In a recent private communication with Christian, he informed me that he is no longer available to continue package maintenance and sponsorship, and referred me to debian-mentors. Following closure of #908850 and a e-mail communication with Boyuan Yang, here is a new upload for the geneweb package. * Package name: geneweb Version : 6.08+git20181019+dfsg-1 Upstream Author : Daniel de Rauglaudre et al. * URL : https://github.com/geneweb/geneweb * License : GPL-2 Section : misc It builds those binary packages: geneweb- genealogy software with web interface geneweb-gui - graphical user interface to Geneweb genealogy software gwsetup- utilities to configure and manipulate Geneweb databases gwtp - web interface interacting with Geneweb databases To access further information about this package, please visit the following URL: https://mentors.debian.net/package/geneweb https://salsa.debian.org/GuillaumeBrochu-guest/geneweb https://tracker.debian.org/pkg/geneweb Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/geneweb/geneweb_6.08+git20181019+dfsg-1.dsc More information about geneweb can be obtained from: https://geneweb.org https://github.com/geneweb/geneweb Changes since the last upload: * New upstream release: https://github.com/geneweb/geneweb/archive/9641e494cd85fb1b7baba32412d120da38234ba2.tar.gz https://github.com/geneweb/geneweb/commits/distrib-6-08-ocaml-4-xx (Last commit : 2018-10-19) Fixes a bug in /hd/etc/templ502/updfam.txt: https://github.com/geneweb/geneweb/issues/642 Fixes ocaml warnings and correct English errors * New maintainer (Guillaume Brochu), Christian Perrier now in uploaders * New git repository to replace Alioth: https://salsa.debian.org/GuillaumeBrochu-guest/geneweb * Build and add connex to geneweb package (renamed geneweb-connex) Closes: #912915 * Use upstream a.gwf as default.gwf for gwtp Also put default.gwf in var/lib/geneweb * Patches updated using gbp pq, cleaning of compile-gui patch * Remove duplicate entries in changelog (that were there since May 2007) * Add override_dh_auto_configure to fix a problem that appeared with debhelper 11.5 * Standards-Version: 4.2.1 * Debhelper Build-Depends 9 -> 10 * Build-Depends: Replace ocaml-best-compilers and ocaml by ocaml-nox * Remove lynx in Suggests of geneweb * Add Keywords entry to .desktop files, correct translation mistake * Put icons in usr/share/pixmaps * Update isoquery standard : use 639-2 instead of 639 * Add Documentation.desktop in usr/share/doc/geneweb * Use https for homepage https://geneweb.org * Cleaning of .docs, .dirs, .links, .prerm, and rules * Other minor changes (lintian warnings, gbp.conf, etc.) I tested this package with gbp buildpackage, pbuilder, and lintian. With best regards, Guillaume Brochu
Bug#912915: please package the connex utility
Dear Sébastien, Thank you for your feedback. Indeed it's a great idea to add connex to the package. I'm currently working on a new release, so I will add connex to it. This new release (6.08+git20181019+dfsg-1) should be available in a few weeks. With best regards, Guillaume Brochu Le dim. 4 nov. 2018 à 16:39, Sébastien Villemot a écrit : > Package: geneweb > Version: 6.08+git20161106+dfsg-2 > Severity: wishlist > > Dear Maintainers, > > I recently needed the "connex" utility to cleanup a Geneweb database, as > documented on this page: > > https://geneweb.tuxfamily.org/wiki/connectivity > > It is a very useful tool, and it would be nice to have it packaged (I had > to > compile it by hand). > > Best, > > -- > ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot > ⣾⠁⢠⠒⠀⣿⡁ Debian Developer > ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name > ⠈⠳⣄ http://www.debian.org >
Bug#908850: [sponsorship-requests] Need sponsor and maintainer status for geneweb package
Package: sponsorship-requests Severity: normal --- Hi, For the last two years, I have worked on the maintenance of the geneweb package with the help & sponsorship of Christian Perrier (which is still the official maintainer of the package). https://tracker.debian.org/pkg/geneweb https://salsa.debian.org/GuillaumeBrochu-guest/geneweb-package-test I would like to continue the work on the package, including the migration of the git repository to Salsa. However, in a recent private communication with Christian, he informed me that he is no longer available to continue the sponsorship and package maintenance, and referred me to debian-mentors. Therefore, I need a new sponsor to continue the work. My objectives are : - migration of the git repository to Salsa (which was previously here : https://anonscm.debian.org/cgit/collab-maint/geneweb.git/) - fix an old bug with the import of a new upstream release and perhaps push it into the stretch-backports, if possible; - prepare for Buster; - start to test the packaging of the next geneweb release (geneweb 7), and perhaps push it into experimental, if possible. For this, I need (1) a new sponsor from the Debian developers team and (2) the transfer of the maintainer status of the geneweb package to me and/or to the new sponsor. Thank you and best regards, Guillaume Brochu
Bug#908163: RFS: wfrench/1.2.4
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "wfrench" * Package name: wfrench Version : 1.2.4 Upstream Author : (none) * URL : (none) * License : GPL2+ Section : text It builds this package: wfrench- French dictionary words for /usr/share/dict To access further information about this package, please visit the following URL: https://mentors.debian.net/package/wfrench Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/w/wfrench/wfrench_1.2.4.dsc Changes since the last upload: * New maintainer (Closes: #858663) * Added verbs from verbiste (Closes: #329474) * debian/control: - Bumped Standards-Version to 4.2.1. Regards, guillaume pernot
Bug#901254: gnome-terminal: unable to init server, failed with result 'signal', segfault at 8
I am experiencing the same issue. Fwiw the workaround listed in https://bugzilla.redhat.com/show_bug.cgi?id=1353953 (for a similar problem) allows me to start gnome-terminal in a shell: DBUS_SESSION_BUS_ADDRESS="" eval `dbus-launch --sh-syntax --exit-with-session` Also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868461 seems to be the same bug. -- Guillaume Morin
Bug#792205: closed by Guillaume Bougard (Re: fusioninventory-agent: modifies conffiles (policy 10.7.3): /etc/fusioninventory/agent.cfg)
Hi, in fact, and regarding the package history, the bug should have been opened with 2.3.10 and closed with not releases 2.3.15... How to avoid this case becomes blocking for the migration to testing planned in 8 days now ? Kind regards, Guillaume Bougard Ingénieur R&D gboug...@teclib.com TECLIB' Montpellier 3 rue Doria, 34000 Montpellier, France - Mail original - De: "gregor herrmann" À: 792...@bugs.debian.org, "Andreas Beckmann" Cc: "Guillaume Bougard" Envoyé: Samedi 30 Juin 2018 19:26:29 Objet: Re: Bug#792205 closed by Guillaume Bougard (Re: fusioninventory-agent: modifies conffiles (policy 10.7.3): /etc/fusioninventory/agent.cfg) On Tue, 26 Jun 2018 08:45:05 +, Debian Bug Tracking System wrote: > Version: 1:2.3.16-1 > > Hi, > > I'm the upstream maintainer. > > As I said before, ucf is used since 2.3.10. So the problem shouldn't occur in > later releases. > > So this bug should be closed. > From: Andreas Beckmann > To: Debian Bug Tracking System > Subject: fusioninventory-agent: modifies conffiles (policy 10.7.3): > /etc/fusioninventory/agent.cfg > Date: Sun, 12 Jul 2015 18:23:06 +0200 > X-Spam-Level: > X-Spam-Status: No, score=-11.9 required=4.0 tests=BAYES_00,FOURLA, > FROMDEVELOPER,HAS_PACKAGE autolearn=ham autolearn_force=no > version=3.4.0-bugs.debian.org_2005_01_02 > > Package: fusioninventory-agent > Version: 1:2.3.16-1 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts Looks like we have a BTS issue here. The bug was reported against 1:2.3.16-1 and closed in the same 1:2.3.16-1 version which confused the BTS (cf. the version graph in the web interface). As I don't know enough about the bug itself, I'm not changing anything; but something needs to be done as this will block the migration of the new upload to testing. Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Neil Young: Oh, Lonesome Me
Bug#804580: cereal: work with /dev/serial/by-id/ symlinks
Nice to see work on this ! We've fixed that one on our side by doing mkdir -p '/var/lock/LCK..serial/by-id/' G
Bug#876541: [PATCH] Patch for bug 876541
On Thu, 1 Feb 2018 00:22:37 +0100 Thomas Kremer wrote: > Questions: > - This exact version of xul-ext-sieve actually once worked for me. Has > there been a feature reduction in the underlying javascript engine? Yes, as the following commit states : " Fix Broken Code - mozilla dropped support for legacy array definitions. " https://github.com/thsmi/sieve/commit/cdf54a49fe50641dac73e657346e8c2249fbb63f > - Will this patch be implemented? In stable? > That'd be nice. The package's base functionality is broken due do this. Guillaume
Bug#896576: closed by Ben Hutchings (Re: Bug#896576: Reading from /proc/[pid]/environ returns garbage)
Le 23/04/2018 à 02:27, Debian Bug Tracking System a écrit : > The kernel only knows where it stored the environment for a process > when it started. If the process manipulates its environment after > that, the kernel doesn't know about it. This means that the "environ" > file is not reliable, and this can't be fixed. Sorry. Thanks for the clarification, I now understand this isn't a kernel bug. -- Jabber : guilla...@atto.be PGP : 2054C46F0019B937
Bug#896576: Reading from /proc/[pid]/environ returns garbage
Package: linux-image-4.9.0-6-amd64 Version: 4.9.82-1+deb9u3 When I attempt to get the environment of a process by reading /proc/[pid]/environ, it sometimes returns garbage. The same garbage is seen when reading this magic 'environ' file using cat, hexdump, or python. So I believe the tool reading it is not at fault. I am filling this against a linux image package, because my understanding is that /proc is a virtual file system managed by the linux kernel. Reproducing: In my case I observed this with a couple sshd and dovecot processes, I suggest you start by looking at theses when reproducing. # cat /proc/10230/cmdline && echo dovecot/imap-login # cat /proc/10230/environ && echo ��[TRUNCATED] # hexdump -C /proc/10230/environ ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab || * 01fd # cat /proc/7590/cmdline && echo sshd: guillaume [priv] # cat /proc/7590/environ && echo riv]2 # hexdump -C /proc/7590/environ 72 69 76 5d 00 00 00 00 00 00 00 00 00 00 00 00 |riv]| 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0730 00 00 00 00 00 00 00 00 00 00 00 32 00 |...2.|
Bug#873758: stretch-pu: package memcached/1.4.33-1
Hi,
I'm sorry i haven't find a sponsor to upload the security fix for CVE-2017-9951
yet.
There is another fix that need to be uploaded to security: CVE-2018-1000115:
$ dpkg --list memcached
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
ArchitectureDescription
+++-=-===-===-===
ii memcached 1.4.33-1
amd64 high-performance memory object caching system
$ sudo netstat -ltunp | grep memcached
tcp0 0 0.0.0.0:11211 0.0.0.0:* LISTEN
31885/memcached
tcp6 0 0 :::11211:::*LISTEN
31885/memcached
udp0 0 0.0.0.0:11211 0.0.0.0:*
31885/memcached
udp6 0 0 :::11211:::*
31885/memcached
Versus:
$ dpkg --list memcached
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
ArchitectureDescription
+++-=-===-===-===
ii memcached 1.4.33-1+deb9u1
amd64 high-performance memory object caching system
$ sudo netstat -ltunp | grep memcached
tcp0 0 0.0.0.0:11211 0.0.0.0:* LISTEN
478/memcached
tcp6 0 0 :::11211:::*LISTEN
478/memcached
Please find attached the following debdiff.
--
Guillaume Delacour
diff -Nru memcached-1.4.33/debian/changelog memcached-1.4.33/debian/changelog
--- memcached-1.4.33/debian/changelog 2016-11-03 01:50:27.0 +0100
+++ memcached-1.4.33/debian/changelog 2018-03-08 13:46:07.0 +0100
@@ -1,3 +1,15 @@
+memcached (1.4.33-1+deb9u1) stretch; urgency=high
+
+ * Fix CVE-2017-9951 by checking the integer length of commands that adds or
+replaces key/value pair
+ * Fix CVE-2018-1000115
++ debian/patches/10_CVE-2018-1000115.patch disable listening on UDP port by
+ default (from Ubuntu)
++ debian/NEWS add explanation and document how to re-enable UDP if
+ necessary.
+
+ -- Guillaume Delacour Thu, 08 Mar 2018 13:46:07 +0100
+
memcached (1.4.33-1) unstable; urgency=medium
* New upstream release, fix CVE-2016-8704, CVE-2016-8705, CVE-2016-8706
diff -Nru memcached-1.4.33/debian/NEWS memcached-1.4.33/debian/NEWS
--- memcached-1.4.33/debian/NEWS 2016-07-02 10:24:46.0 +0200
+++ memcached-1.4.33/debian/NEWS 2018-03-08 13:46:07.0 +0100
@@ -1,3 +1,11 @@
+memcached (1.4.33-1+deb9u1) stretch; urgency=high
+
+ * memcached is now configured to disable its UDP port by default, to
+prevent its use as a DDoS amplifier. To re-enable UDP service, add
+'-U 11211' to /etc/memcached.conf and restart the memcached service.
+
+ -- Steve Beattie Fri, 02 Mar 2018 12:52:44 -0800
+
memcached (1.4.20-1) unstable; urgency=medium
Starting with this release, a system user "memcache" will be created.
diff -Nru memcached-1.4.33/debian/patches/09_CVE-2017-9951.patch memcached-1.4.33/debian/patches/09_CVE-2017-9951.patch
--- memcached-1.4.33/debian/patches/09_CVE-2017-9951.patch 1970-01-01 01:00:00.0 +0100
+++ memcached-1.4.33/debian/patches/09_CVE-2017-9951.patch 2018-03-06 21:44:06.0 +0100
@@ -0,0 +1,36 @@
+From: dormando
+Date: Tue, 4 Jul 2017 00:32:39 -0700
+Subject: [PATCH] sanity check (CVE-2017-9951)
+Origin: upstream, https://github.com/memcached/memcached/commit/328629445c71e6c17074f6e9e0e3ef585b58f167
+
+---
+ items.c | 2 ++
+ memcached.c | 2 +-
+ 2 files changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/items.c b/items.c
+index 637e5e745..83a2ea37d 100644
+--- a/items.c
b/items.c
+@@ -368,6 +368,8 @@ void item_free(item *it) {
+ bool item_size_ok(const size_t nkey, const int flags, const int nbytes) {
+ char prefix[40];
+ uint8_t nsuffix;
++if (nbytes < 2)
++return false;
+
+ size_t ntotal = item_make_header(nkey + 1, flags, nbytes,
+ prefix, &nsuffix);
+diff --git a/memcached.c b/memcached.c
+index 0f0335795..a89df965d 100644
+--- a/memcached.c
b/memcached
Bug#891907: memcached should disable UDP by default
Hi, Le 02/03/2018 à 12:39, Hanno Böck a écrit : > Package: memcached > Version: 1.4.33-1 > > Memcached is currently involved in some massive ddos attacks, see e.g.: > https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/ > > The UDP protocol of memcached can be abused for very effective DDoS > amplification attacks and should therefore be considered dangerous. > Upstream memcached has reacted to this by disabling UDP by default: > https://github.com/memcached/memcached/wiki/ReleaseNotes156 > > In Debian memcached by default only listens to 127.0.0.1, but enables > UDP. While the localhost-only protects default settings, it's still > only a minor change away from creating an effective DDoS tool for a > protocol that is hardly in use today. I recommend that you backport > the upstream change and disable UDP by default. > The version 1.5.6 will be uploaded in the archive in a few days. I'll try to propose a backport patch at least for versions in stretch and jessie (with upstream review, if possible). -- Guillaume Delacour signature.asc Description: OpenPGP digital signature
Bug#863517: sslh systemd service file doesn't honor /etc/default/sslh
Hi, Le 28/05/2017 à 00:09, Cord Beermann a écrit : > Package: sslh > Version: 1.18-1 > Severity: normal > > Hello, > > I want to use sslh.service with the sslh-select option, but in > /lib/systemd/system/sslh.service is /usr/sbin/sslh hardcoded. > > It should user the information in /etc/default/sslh instead (or switch over > to update-alternatives?) systemd does not support a variable into ExecStart: # service sslh status ● sslh.service - SSL/SSH multiplexer Loaded: error (Reason: Invalid argument) [...] [/lib/systemd/system/sslh.service:8] Executable path is not absolute, ignoring: $DAEMON --foreground $DAEMON_OPTS One other way is to wrapp the startup, or use alternative. I'll look to this. > > Cord > > -- System Information: > Debian Release: 8.8 > APT prefers stable > APT policy: (999, 'stable'), (799, 'stable-updates'), (798, > 'proposed-updates'), (500, 'oldstable'), (299, 'testing'), (199, 'unstable'), > (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.9.0-0.bpo.3-amd64 (SMP w/2 CPU cores) > Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages sslh depends on: > ii adduser 3.113+nmu3 > ii debconf 1.5.56 > ii init-system-helpers 1.22 > ii libc62.19-18+deb8u9 > ii libcap2 1:2.24-8 > ii libconfig9 1.4.9-2 > ii libwrap0 7.6.q-25 > ii lsb-base 4.1+Debian13+nmu1 > ii update-inetd 4.43 > > Versions of packages sslh recommends: > ii apache2 [httpd] 2.4.10-10+deb8u8 > ii openssh-server [ssh-server] 1:6.7p1-5+deb8u3 > > Versions of packages sslh suggests: > ii openbsd-inetd [inet-superserver] 0.20140418-2 > > -- debconf information: > * sslh/inetd_or_standalone: standalone > -- Guillaume Delacour signature.asc Description: OpenPGP digital signature
Bug#888529: memcached: Systemd private tmp breaks unix socket access to memcached
tags 888529 + moreinfo thanks Hi, Le 26/01/2018 à 19:57, Dennis Boone a écrit : > Package: memcached > Version: 1.5.4-1 > Severity: important > > After applying this version the other night, our application was no > longer able to connect to memcached via its unix socket. (Since the > systemd private tmp functionality is a damned rootkit, it too a while to > diagnose this problem.) The distributed configuration file appears to > place the unix socket in /tmp. The distributed configuration file does not provide a socket file enabled; where is the socket you've defined with options "-s, --unix-socket=" ? Provided config files: https://anonscm.debian.org/cgit/collab-maint/memcached.git/tree/debian/memcached.conf && https://github.com/memcached/memcached/blob/master/scripts/memcached.service && https://anonscm.debian.org/cgit/collab-maint/memcached.git/tree/debian/patches/02_service_wrapper.patch > > If systemd private tmp is to be enabled for memcached, the distributed > configuration should place the unix socket elsewhere. Alternately, > private tmp could be disabled for memached. > > > -- System Information: > Debian Release: buster/sid > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.14.0-3-amd64 (SMP w/8 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=es_US.UTF-8 (charmap=UTF-8) (ignored: > LC_ALL set to es_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: > LC_ALL set to es_US.UTF-8) > Shell: /bin/sh linked to /bin/bash > Init: systemd (via /run/systemd/system) > > Versions of packages memcached depends on: > ii adduser 3.116 > ii libc6 2.26-5 > ii libevent-2.1-6 2.1.8-stable-4 > ii libsasl2-2 2.1.27~101-g0780600+dfsg-3 > ii lsb-base9.20170808 > ii perl5.26.1-4 > > memcached recommends no packages. > > Versions of packages memcached suggests: > pn libanyevent-perl > pn libcache-memcached-perl > pn libmemcached > ii libterm-readkey-perl 2.37-1+b2 > pn libyaml-perl > > -- no debconf information > -- Guillaume Delacour signature.asc Description: OpenPGP digital signature
Bug#887276: About fusioninventory-agent should depend on e2fsprogs explicitly
Hi there, I'm the upstream maintainer of fusioninventory-agent. Sorry to have missed that bug. As the agent purpose is to do system inventory and report the result to a central server, it tries to run some well-known commands. As such, it definitively not depends on tools provided by e2fsprogs. Then I would be nice to put the e2fsprogs dependency as Recommends. Best regards, Guillaume Bougard Ingénieur R&D gboug...@teclib.com TECLIB' Montpellier 3 rue Doria, 34000 Montpellier, France Tél.: 01 79 97 02 78 Facebook | Twitter | www.teclib.com
Bug#889653: netdata: missing python module 'pyyaml2'
Hi, Finally, after copying "pyyam2" and "pyyaml3" from "python.d/python_modules" from git repository of netdata to "/usr/lib/x86_64-linux-gnu/netdata/python.d/ python_modules". Netdata's python modules works. Regards, Le mercredi 7 février 2018, 12:13:51 CET Guillaume Clercin a écrit : > With user netdata, if I want to test a python module, I run: > netdata@kazoo:/usr/lib/x86_64-linux-gnu/netdata$ ./plugins.d/python.d.plugin > 1 debug trace mdstat Traceback (most recent call last): > File "./plugins.d/python.d.plugin", line 31, in > from bases.loaders import ModuleAndConfigLoader > File > "/usr/lib/x86_64-linux-gnu/netdata/python.d/python_modules/bases/loaders.py > ", line 15, in from pyyaml2 import SafeLoader as YamlSafeLoader > ImportError: No module named pyyaml2 > > According the file > "/usr/lib/x86_64-linux-gnu/netdata/python.d/python_modules/bases/loaders.py > ", python2 module require pyyaml2 and python3 module require pyyaml3. > > Import thing, I modified > "/usr/lib/x86_64-linux-gnu/netdata/plugins.d/python.d.plugin" in order to > fix the path of "PLUGIN_CONFIG_DIR". > > Le mardi 6 février 2018, 17:41:24 CET Lennart Weller a écrit : > > It does depend on pyyaml3. > > > > Quote from your submitted bugreport: > > > Versions of packages netdata depends on: > > > ii python3-yaml 3.12-1+b1 > > > > On 05/02/2018 11:53, Guillaume Clercin wrote: > > > Package: netdata > > > Version: 1.9.0+dfsg-1 > > > Severity: important > > > > > > Dear Maintainer, > > > > > > After upgrading netdata, no python modules were enabled. Python modules > > > required pyyaml2 or (pyyaml3 maybe) in order to run. These packages > > > should be provided by netdata. They are available here: > > > https://github.com/firehol/netdata/tree/v1.9.0/python.d/python_modules > > > > > > Please, package them into netdata packages. > > > > > > > > > -- System Information: > > > Debian Release: buster/sid > > > > > >APT prefers testing > > >APT policy: (500, 'testing'), (500, 'stable') > > > > > > Architecture: amd64 (x86_64) > > > > > > Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) > > > Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), > > > LANGUAGE= > > > (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash > > > Init: systemd (via /run/systemd/system) > > > > > > Versions of packages netdata depends on: > > > ii adduser 3.117 > > > ii libc62.26-6 > > > ii libcap2-bin 1:2.25-1.2 > > > ii libuuid1 2.30.2-0.3 > > > ii lsb-base 9.20170808 > > > ii netdata-data 1.9.0+dfsg-1 > > > ii python3 3.6.4-1 > > > ii python3-urllib3 1.22-1 > > > ii python3-yaml 3.12-1+b1 > > > ii zlib1g 1:1.2.8.dfsg-5 > > > > > > Versions of packages netdata recommends: > > > ii curl7.58.0-2 > > > pn fping > > > ii nodejs 4.8.4~dfsg-1 > > > > > > netdata suggests no packages. > > > > > > -- Configuration Files: > > > /etc/netdata/health_alarm_notify.conf changed [not included] > > > /etc/netdata/netdata.conf changed [not included] > > > /etc/netdata/python.d/postgres.conf changed [not included] > > > > > > -- no debconf information -- Guillaume Clercin Intellique www.intellique.com Tél: 01 78 94 84 06 signature.asc Description: This is a digitally signed message part.
Bug#889653: netdata: missing python module 'pyyaml2'
With user netdata, if I want to test a python module, I run:
netdata@kazoo:/usr/lib/x86_64-linux-gnu/netdata$ ./plugins.d/python.d.plugin 1
debug trace mdstat
Traceback (most recent call last):
File "./plugins.d/python.d.plugin", line 31, in
from bases.loaders import ModuleAndConfigLoader
File
"/usr/lib/x86_64-linux-gnu/netdata/python.d/python_modules/bases/loaders.py",
line 15, in
from pyyaml2 import SafeLoader as YamlSafeLoader
ImportError: No module named pyyaml2
According the file
"/usr/lib/x86_64-linux-gnu/netdata/python.d/python_modules/bases/loaders.py",
python2 module require pyyaml2 and python3 module require pyyaml3.
Import thing, I modified
"/usr/lib/x86_64-linux-gnu/netdata/plugins.d/python.d.plugin"
in order to fix the path of "PLUGIN_CONFIG_DIR".
Le mardi 6 février 2018, 17:41:24 CET Lennart Weller a écrit :
> It does depend on pyyaml3.
>
> Quote from your submitted bugreport:
> > Versions of packages netdata depends on:
> > ii python3-yaml 3.12-1+b1
>
> On 05/02/2018 11:53, Guillaume Clercin wrote:
> > Package: netdata
> > Version: 1.9.0+dfsg-1
> > Severity: important
> >
> > Dear Maintainer,
> >
> > After upgrading netdata, no python modules were enabled. Python modules
> > required pyyaml2 or (pyyaml3 maybe) in order to run. These packages
> > should be provided by netdata. They are available here:
> > https://github.com/firehol/netdata/tree/v1.9.0/python.d/python_modules
> >
> > Please, package them into netdata packages.
> >
> >
> > -- System Information:
> > Debian Release: buster/sid
> >
> >APT prefers testing
> >APT policy: (500, 'testing'), (500, 'stable')
> >
> > Architecture: amd64 (x86_64)
> >
> > Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
> > Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=
> > (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash
> > Init: systemd (via /run/systemd/system)
> >
> > Versions of packages netdata depends on:
> > ii adduser 3.117
> > ii libc62.26-6
> > ii libcap2-bin 1:2.25-1.2
> > ii libuuid1 2.30.2-0.3
> > ii lsb-base 9.20170808
> > ii netdata-data 1.9.0+dfsg-1
> > ii python3 3.6.4-1
> > ii python3-urllib3 1.22-1
> > ii python3-yaml 3.12-1+b1
> > ii zlib1g 1:1.2.8.dfsg-5
> >
> > Versions of packages netdata recommends:
> > ii curl7.58.0-2
> > pn fping
> > ii nodejs 4.8.4~dfsg-1
> >
> > netdata suggests no packages.
> >
> > -- Configuration Files:
> > /etc/netdata/health_alarm_notify.conf changed [not included]
> > /etc/netdata/netdata.conf changed [not included]
> > /etc/netdata/python.d/postgres.conf changed [not included]
> >
> > -- no debconf information--- /usr/lib/x86_64-linux-gnu/netdata/plugins.d/python.d.plugin 2018-02-07 12:08:20.280526465 +0100
+++ /usr/lib/x86_64-linux-gnu/netdata/plugins.d/python.d.plugin 2018-01-27 22:30:16.630789251 +0100
@@ -21,7 +21,7 @@
from time import time
PY_VERSION = version_info[:2]
-PLUGIN_CONFIG_DIR = os.getenv('NETDATA_CONFIG_DIR', os.path.dirname(__file__) + '/../../../../etc/netdata') + '/'
+PLUGIN_CONFIG_DIR = os.getenv('NETDATA_CONFIG_DIR', os.path.dirname(__file__) + '/../../../../../etc/netdata') + '/'
CHARTS_PY_DIR = os.path.abspath(os.getenv('NETDATA_PLUGINS_DIR', os.path.dirname(__file__)) + '/../python.d') + '/'
CHARTS_PY_CONFIG_DIR = PLUGIN_CONFIG_DIR + 'python.d/'
PYTHON_MODULES_DIR = CHARTS_PY_DIR + 'python_modules'
signature.asc
Description: This is a digitally signed message part.
Bug#889653: netdata: missing python module 'pyyaml2'
Package: netdata Version: 1.9.0+dfsg-1 Severity: important Dear Maintainer, After upgrading netdata, no python modules were enabled. Python modules required pyyaml2 or (pyyaml3 maybe) in order to run. These packages should be provided by netdata. They are available here: https://github.com/firehol/netdata/tree/v1.9.0/python.d/python_modules Please, package them into netdata packages. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages netdata depends on: ii adduser 3.117 ii libc62.26-6 ii libcap2-bin 1:2.25-1.2 ii libuuid1 2.30.2-0.3 ii lsb-base 9.20170808 ii netdata-data 1.9.0+dfsg-1 ii python3 3.6.4-1 ii python3-urllib3 1.22-1 ii python3-yaml 3.12-1+b1 ii zlib1g 1:1.2.8.dfsg-5 Versions of packages netdata recommends: ii curl7.58.0-2 pn fping ii nodejs 4.8.4~dfsg-1 netdata suggests no packages. -- Configuration Files: /etc/netdata/health_alarm_notify.conf changed [not included] /etc/netdata/netdata.conf changed [not included] /etc/netdata/python.d/postgres.conf changed [not included] -- no debconf information
