Bug#1082789: RFS: qabc/1.12-1 -- minimal GUI for ABC music notation
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "qabc": * Package name : qabc Version : 1.12-1 Upstream contact : Benoît Rouits * URL : http://brouits.free.fr/qabc/ * License : GPL-3+, FSFAP * Vcs : https://github.com/be1/qabc/tree/debian Section : sound The source builds the following binary packages: qabc - minimal GUI for ABC music notation To access further information about this package, please visit the following URL: https://mentors.debian.net/package/qabc/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/q/qabc/qabc_1.12-1.dsc Changes since the last upload: qabc (1.12-1) unstable; urgency=medium . * New upstream release 1.12 * Debian patch to enable hardening on compilation Regards, Benoît
Bug#1068529: RFS: qabc/1.11-1 -- minimal GUI for ABC music notation
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "qabc": * Package name : qabc Version : 1.11-1 Upstream contact : Benoît Rouits * URL : http://brouits.free.fr/qabc/ * License : FSFAP, GPL-3+ * Vcs : https://github.com/be1/qabc Section : sound The source builds the following binary packages: qabc - minimal GUI for ABC music notation To access further information about this package, please visit the following URL: https://mentors.debian.net/package/qabc/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/q/qabc/qabc_1.11-1.dsc Changes since the last upload: qabc (1.11-1) unstable; urgency=medium . * New upstream release 1.11 * Bump standards version to 4.6.2 * Fix licences in debian/copyright Regards,
Bug#1027085: Still hapening on 5.10.0-26-amd64
On 05/01/2024 18:37, 陈 晟祺 wrote: Control: tags -1 + unreproducible Still hapening on 5.10.0-26-amd64 , but this fixed the system: update-initramfs -u ; update-grub Did your apt run finish normally? The update of initramfs and grub is commonly done by postinst hooks, which will be triggered when kernel / zfs is upgraded. So if running manually can solve the problem, I suspect some faulty packages might be preventing this process. Thanks, Shengqi Chen When I ran it to fix my system, I ran it manually, and it succeeded. My system broke "all by itself". Probably some weekly auto update. I would need to check system logs to see what the system did; but I am not sure logs will contain the return value or exit message. I put my laptop to sleep everyt night, so I may have uptime up to 60d easily, covering 3 to 8 weekly updates; that's why checking log is difficult : cron weekly may have run 6 or 8 times when I endure the bug !!! Did not have the issue recently ; my current kernel is vmlinuz-5.10.0-26-amd64 installed 29 sept. Today, "apt-get -f install" returns 0. -- >o_/ DEMAINE Benoît-Pierre (aka DoubleHP) http://benoit.demaine.info/ If computing were an exact science, IT engineers would'nt have work \_o< "So all that's left, Is the proof that love's not only blind but deaf." (FAKE TALES OF SAN FRANCISCO, Arctic Monkeys)
Bug#1027085: Still hapening on 5.10.0-26-amd64
: clamav-base:amd64 (0.103.8+dfsg-0+deb11u1, 0.103.10+dfsg-0+deb11u1), clamav-freshclam:amd64 (0.103.8+dfsg-0+deb11u1, 0.103.10+dfsg-0+deb11u1) Upgrade: libiperf0:amd64 (3.9-1, 3.9-1+deb11u1) Upgrade: libkpathsea6:amd64 (2020.20200327.54578-7, 2020.20200327.54578-7+deb11u1) Upgrade: libuno-salhelpergcc3-3:amd64 (1:7.0.4-4+deb11u6, 1:7.0.4-4+deb11u7) Upgrade: libreoffice-script-provider-js:amd64 (1:7.0.4-4+deb11u6, 1:7.0.4-4+deb11u7) Upgrade: libprotobuf-lite23:amd64 (3.12.4-1, 3.12.4-1+deb11u1) Upgrade: linux-headers-amd64:amd64 (5.10.178-3, 5.10.197-1) Upgrade: python3-flask:amd64 (1.1.2-2, 1.1.2-2+deb11u1) Upgrade: linux-compiler-gcc-10-x86:amd64 (5.10.178-3, 5.10.197-1) Upgrade: libjuh-java:amd64 (1:7.0.4-4+deb11u6, 1:7.0.4-4+deb11u7) Upgrade: logrotate:amd64 (3.18.0-2+deb11u1, 3.18.0-2+deb11u2) Upgrade: libreoffice-sdbc-hsqldb:amd64 (1:7.0.4-4+deb11u6, 1:7.0.4-4+deb11u7) Upgrade: rar:amd64 (2:5.5.0-1, 2:6.23-1~deb11u1) Upgrade: libxenhypfs1:amd64 (4.14.5+94-ge49571868d-1, 4.14.6-1) Upgrade: cups-ppdc:amd64 (2.3.3op2-3+deb11u2, 2.3.3op2-3+deb11u6) Upgrade: libc-ares2:amd64 (1.17.1-1+deb11u2, 1.17.1-1+deb11u3) Upgrade: ncurses-term:amd64 (6.2+20201114-2+deb11u1, 6.2+20201114-2+deb11u2) Upgrade: ca-certificates-java:amd64 (20190909, 20190909+deb11u1) Upgrade: libmariadb3:amd64 (1:10.5.19-0+deb11u2, 1:10.5.21-0+deb11u1) Upgrade: libraw20:amd64 (0.20.2-1, 0.20.2-1+deb11u1) Upgrade: python3-werkzeug:amd64 (1.0.1+dfsg1-2, 1.0.1+dfsg1-2+deb11u1) Upgrade: cryptmount:amd64 (5.3.3-1, 5.3.3-1+deb11u1) Upgrade: gstreamer1.0-gl:amd64 (1.18.4-2, 1.18.4-2+deb11u1) Upgrade: libreoffice-java-common:amd64 (1:7.0.4-4+deb11u6, 1:7.0.4-4+deb11u7) Upgrade: libreoffice-nlpsolver:amd64 (0.9+LibO7.0.4-4+deb11u6, 0.9+LibO7.0.4-4+deb11u7) Upgrade: base-files:amd64 (11.1+deb11u7, 11.1+deb11u8) Upgrade: libjson-c5:amd64 (0.15-2, 0.15-2+deb11u1) Upgrade: libuno-sal3:amd64 (1:7.0.4-4+deb11u6, 1:7.0.4-4+deb11u7) Upgrade: systemd-sysv:amd64 (247.3-7+deb11u2, 247.3-7+deb11u4) And here is the common list with a probable previous update what also broke my boot: $ comm -1 -2 06b 10b # Thanks GPT to give me the opposite of diff :) base-files bind9-dnsutils bind9-host chromium-sandbox clamav clamav-base dnsutils firefox-esr fonts-opensymbol ghostscript-x libc-ares2 libcpupower1 libcurl3-gnutls libcurl4 libjavascriptcoregtk-4.0-18 libjuh-java libjurt-java liblibreoffice-java libmariadb3 libpq5 libreoffice-calc libreoffice-common libreoffice-java-common libreoffice-nlpsolver libreoffice-report-builder libreoffice-report-builder-bin libreoffice-script-provider-bsh libreoffice-script-provider-js libreoffice-script-provider-python libreoffice-sdbc-firebird libreoffice-sdbc-hsqldb libreoffice-sdbc-mysql libreoffice-sdbc-postgresql libreoffice-style-colibre libreoffice-wiki-publisher libridl-java libssl1.1 libtinfo-dev libuno-cppu3 libunoil-java libunoloader-java libuno-purpenvhelpergcc3-3 libuno-sal3 libuno-salhelpergcc3-3 libxencall1 libxendevicemodel1 libxenevtchn1 libxenforeignmemory1 libxengnttab1 libxenhypfs1 libxenmisc4.14 libxenstore3.0 libxentoolcore1 libxentoollog1 linux-compiler-gcc-10-x86 linux-headers-amd64 linux-image-amd64 linux-kbuild-5.10 linux-libc-dev mariadb-common ncurses-base ncurses-bin ncurses-term openjdk-11-jre openjdk-17-jre openssl php7.4-readline systemd-sysv systemd-timesyncd thunderbird-l10n-en-gb udev uno-libs-private The only potential candidates I see here are systemd-sysv and udev. -- >o_/ DEMAINE Benoît-Pierre (aka DoubleHP) http://benoit.demaine.info/ If computing were an exact science, IT engineers would'nt have work \_o< "So all that's left, Is the proof that love's not only blind but deaf." (FAKE TALES OF SAN FRANCISCO, Arctic Monkeys)
Bug#1037122: Subject: libpam-ssh-agent-auth: Sudo with ECDSA key segfaults
Same problem with DSA key RSA and ED25519 works !begin:vcard fn;quoted-printable:Beno=C3=AEt PELISSIER n;quoted-printable:PELISSIER;Beno=C3=AEt org;quoted-printable:LAN2NET - l'informatique fiable sous Linux + logiciels libres;membre du r=C3=A9seau "Alliance-Libre" adr;quoted-printable;dom:12 avenue Jules Verne;;Les Espaces Jules Verne, b=C3=A2timent A;SAINT-SEBASTIEN SUR LOIRE;;44230 email;internet:bpeliss...@lan2net.fr title;quoted-printable:Technicien syst=C3=A8me & r=C3=A9seau tel;work:02 85 52 65 37 url:http://www.lan2net.fr version:2.1 end:vcard
Bug#1027085: linux-image-5.10.0-20-amd64: failed to load zfs modules - after automatic update
vmlinuz-5.10.0-16-amd64 has the same bug as before: https://drive.google.com/drive/u/0/folders/1pEDbtaTPYbpTuGAYWfYDWTysV6H-7Nt0 After installing apt-get install mdadm cryptsetup raidutils I have seen apt rebuild initrds, and now 5.10.0-20-amd64 works again, I don't know why. On 27/12/2022 17:58, DoubleHP wrote: Package: src:linux Version: 5.10.158-2 Severity: grave Justification: renders package unusable X-Debbugs-Cc: ben...@demaine.info Installed this machine 12 months ago, and never did any manual update. Obviously, there are background automatic updates, because these kernels are more recent than my install: -rw-r--r-- 1 root root 6.7M 2 sept. 15:54 vmlinuz-5.10.0-18-amd64 -rw-r--r-- 1 root root 6.7M 13 déc. 21:46 vmlinuz-5.10.0-20-amd64 which are not default for a machine installed in december 2021. I rarely reboot; but last week the computer refused to reboot with message: failed to load zfs modules I forgot to remove QUIET option; I will record screen with quiet removed. So: vmlinuz-5.10.0-20-amd64 bugs vmlinuz-5.10.0-18-amd64 works (now) vmlinuz-5.10.0-16-amd64 had been auto-removed; and when I reinstalled it, it did not work. This means the bug may not be in linux-image-5.10.0-20-amd64 but either in a dep, or an other system utility. When I will bring the bootlog, I will check deeper against #1015295 #1017399 #1019544 #1022202 Issue was discussed here, but no-one have a clue about ZFS specifics: https://forums.debian.net/viewtopic.php?p=764805 -- >o_/ DEMAINE Benoît-Pierre (aka DoubleHP) http://benoit.demaine.info/ If computing were an exact science, IT engineers would'nt have work \_o< "So all that's left, Is the proof that love's not only blind but deaf." (FAKE TALES OF SAN FRANCISCO, Arctic Monkeys)
Bug#1021355: RFS: csv2latex/0.23-1 -- command-line CSV to LaTeX file converter
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "csv2latex": * Package name : csv2latex Version : 0.23-1 Upstream contact : Benoît Rouits * URL : http://brouits.free.fr/csv2latex/ * License : GPL-2 * Vcs : https://git.noise.rocks/ben/csv2latex Section : tex The source builds the following binary packages: csv2latex - command-line CSV to LaTeX file converter To access further information about this package, please visit the following URL: https://mentors.debian.net/package/csv2latex/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/c/csv2latex/csv2latex_0.23-1.dsc Changes since the last upload: csv2latex (0.23-1) unstable; urgency=medium . * New upstream release 0.23 (improve stdin reading) * Update debian/watch (version=4) * Avoid usage of cdbs * Remove debian/compat * Update debian/control * Add debian/upstream/metadata * Set Standards-version to 4.6.1 Regards, Benoît
Bug#1021340: RFS: qabc/1.9.3-1 -- minimal GUI for ABC music notation
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "qabc": * Package name : qabc Version : 1.9.3-1 Upstream contact : Benoît Rouits * URL : http://brouits.free.fr/qabc/ * License : GPL-3+ * Vcs : https://github.com/be1/qabc Section : sound The source builds the following binary packages: qabc - minimal GUI for ABC music notation To access further information about this package, please visit the following URL: https://mentors.debian.net/package/qabc/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/q/qabc/qabc_1.9.3-1.dsc Changes since the last upload: qabc (1.9.3-1) unstable; urgency=medium . * New upstream release 1.9.3. Regards,
Bug#1020770: RFS: qabc/1.9.2-1 -- minimal GUI for ABC music notation
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "qabc": * Package name : qabc Version : 1.9.2-1 Upstream contact : Benoît Rouits * URL : http://brouits.free.fr/qabc/ * License : GPL-3+ * Vcs : https://github.com/be1/qabc Section : sound The source builds the following binary packages: qabc - minimal GUI for ABC music notation To access further information about this package, please visit the following URL: https://mentors.debian.net/package/qabc/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/q/qabc/qabc_1.9.2-1.dsc Changes since the last upload: qabc (1.9.2-1) unstable; urgency=medium . * New upstream release 1.9.2. Regards, Benoît
Bug#1017907: ffado-mixer-qt4 fails to start with python 3.10
Package: ffado-mixer-qt4 Version: 2.4.6-1 Severity: normal Tags: patch upstream Dear Maintainer, after python 3.10 transition ffado-mixer crashes on startup: ffado-mixer Traceback (most recent call last): File "/usr/share/ffado-mixer-qt4/ffado/panelmanager.py", line 460, in updatePanels self.addPanel(idx) File "/usr/share/ffado-mixer-qt4/ffado/panelmanager.py", line 339, in addPanel mixerwidget.initValues() File "/usr/share/ffado-mixer-qt4/ffado/mixer/maudio_bebob.py", line 601, in initValues ctl.setValue(vol) TypeError: setValue(self, int): argument 1 has unexpected type 'float' Abandon This is due to an implicit type cast that is not permitted anymore in pytho 3.10 The issue is fixed upstream: svn commit r2832 Could you update the package please? -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.18.14-rt11-poupou (SMP w/4 CPU threads; PREEMPT) 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) Versions of packages ffado-mixer-qt4 depends on: ii ffado-dbus-server2.4.6-1 ii ffado-tools 2.4.6-1 ii python3 3.10.5-3 ii python3-dbus 1.2.18-3+b2 ii python3-dbus.mainloop.pyqt5 5.15.7+dfsg-1 ii python3-pyqt55.15.7+dfsg-1 ffado-mixer-qt4 recommends no packages. ffado-mixer-qt4 suggests no packages. -- no debconf information
Bug#1013081: RFS: qabc/1.9.1-1 -- minimal GUI for ABC music notation
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "qabc": * Package name: qabc Version : 1.9.1-1 Upstream Author : Benoît Rouits * URL : http://brouits.free.fr/qabc/ * License : GPL-3+ * Vcs : https://github.com/be1/qabc Section : sound The source builds the following binary packages: qabc - minimal GUI for ABC music notation To access further information about this package, please visit the following URL: https://mentors.debian.net/package/qabc/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/q/qabc/qabc_1.9.1-1.dsc Changes since the last upload: qabc (1.9.1-1) unstable; urgency=medium . * New upstream release. * Bump to standards version 4.6.1. Regards,
Bug#1005808: chromium: ERR_SSL_VERSION_OR_CIPHER_MISMATCH after upgrade to 98.0.4758.80
Hi Andres > Thanks for the explanation. What happens if you run chromium with > --tls1 ? That sets the min SSL version to TLSv1.0, although I'm not > sure what changed within chromium to actually drop TLSv1 support; if > it's a third party library, then the code to support it might just be > gone. Unfortunately --tls1 does not solve the issue. I also found: https://chromestatus.com/feature/5759116003770368 which explains they removed tls1.0 all together with no way to bypass. So I guess I have to switch to a different browser to access devices with built-in ssl webserver which do not support anything else than tls1 and sslv3 -Benoit-
Bug#1005808: chromium: ERR_SSL_VERSION_OR_CIPHER_MISMATCH after upgrade to 98.0.4758.80
Hi Andres > I'm a bit confused by this bug report. Why do you need chromium > (presumably over https) talking to network hardware drivers? Or do > you mean you have older network hardware where the firmware exposes > an https port, and chromium no longer supports the older SSL > protocols that the network hardware web server is trying to > negotiate? What specific SSL versions are we talking about? Sorry for the confustion. I wrote the report from a user point of view, noticing that stuff was broken after the update and that it still worked on a machine I had not yet updated. I work for a telco. We have some equipment that is being used long past it's intended time. But also manufacturers often stick to old technologies like java web applets. So this is the ciphers supported by the affected webgui of one of our core telephony switches: PORTSTATE SERVICE 443/tcp open https | ssl-enum-ciphers: | SSLv3: | ciphers: | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C | compressors: | NULL | cipher preference: client | warnings: | Broken cipher RC4 is deprecated by RFC 7465 | CBC-mode cipher in SSLv3 (CVE-2014-3566) | Forward Secrecy not supported by any cipher | TLSv1.0: | ciphers: | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C | compressors: | NULL | cipher preference: client | warnings: | Broken cipher RC4 is deprecated by RFC 7465 | Forward Secrecy not supported by any cipher |_ least strength: C I suppose TLSv1.0 and SSLv3 was completely ditched with the most recent Chromium update. I am aware that the SSL implementation is very unsafe, but that equipment is in a corporate lan, not reachable from the internet protected by additional ACL. IMHO chromium should somehow provide an option to specify 'yes I know the risk, create an exception' to still access such sites. -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- I m p r o W a r e A G-Leiter Commerce Kunden __ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 PrattelnFax +41 61 826 93 01 Schweiz Web http://www.imp.ch __
Bug#1003585: RFS: qabc/1.8-1 -- minimal GUI for ABC music notation
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "qabc": * Package name: qabc Version : 1.8-1 Upstream Author : Benoît Rouits * URL : http://brouits.free.fr/qabc/ * License : GPL-3+ * Vcs : https://github.com/be1/qabc Section : sound It builds those binary packages: qabc - minimal GUI for ABC music notation To access further information about this package, please visit the following URL: https://mentors.debian.net/package/qabc/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/q/qabc/qabc_1.8-1.dsc Changes since the last upload: qabc (1.8-1) unstable; urgency=medium . * New upstream release. Regards, Benoît
Bug#990107: linux-image-4.19.0-17-amd64: lxc-attach Operation not permitted - Failed to set AppArmor label
Package: src:linux
Version: 4.19.194-1
Severity: normal
Since upgrading to linux-image-4.19.0-17-amd64 from
linux-image-4.19.0-16-amd64, I can no longer enter my lxc container with
the command 'lxc-attach'. It fails with the message:
lxc-attach: shire: lsm/lsm.c: lsm_process_label_set_at: 174 Operation
not permitted - Failed to set AppArmor label
"lxc-shire_//&:lxc-shire_<-var-lib-lxc>:
unconfined"
Reverting to linux-image-4.19.0-16-amd64 version 4.19.181-1 (the
previous kernel) fixes the issue.
The lxc config for this container is the following:
lxc.include = /usr/share/lxc/config/common.conf
lxc.include = /usr/share/lxc/config/userns.conf
lxc.arch = linux64
lxc.apparmor.profile = generated
lxc.apparmor.allow_nesting = 1
lxc.idmap = u 0 10 90
lxc.idmap = g 0 10 90
lxc.rootfs.path = dir:/var/lib/lxc/shire/rootfs
lxc.uts.name = shire
lxc.net.0.type = empty
lxc.mount.entry=/data/home home none bind 0 0
lxc.mount.entry=/data/mail var/mail none bind 0 0
And the auto-generated AppArmor profile:
#include
profile "lxc-shire_"
flags=(attach_disconnected,mediate_deleted) {
### Base profile
capability,
dbus,
file,
network,
umount,
# Allow us to receive signals from anywhere.
signal (receive),
# Allow us to send signals to ourselves
signal peer=@{profile_name},
# Allow other processes to read our /proc entries, futexes, perf
tracing and
# kcmp for now (they will need 'read' in the first place).
Administrators can
# override with:
# deny ptrace (readby) ...
ptrace (readby),
# Allow other processes to trace us by default (they will need 'trace' in
# the first place). Administrators can override with:
# deny ptrace (tracedby) ...
ptrace (tracedby),
# Allow us to ptrace ourselves
ptrace peer=@{profile_name},
# ignore DENIED message on / remount
deny mount options=(ro, remount) -> /,
deny mount options=(ro, remount, silent) -> /,
# allow tmpfs mounts everywhere
mount fstype=tmpfs,
# allow hugetlbfs mounts everywhere
mount fstype=hugetlbfs,
# allow mqueue mounts everywhere
mount fstype=mqueue,
# allow fuse mounts everywhere
mount fstype=fuse,
mount fstype=fuse.*,
# deny access under /proc/bus to avoid e.g. messing with pci devices
directly
deny @{PROC}/bus/** wklx,
# deny writes in /proc/sys/fs but allow binfmt_misc to be mounted
mount fstype=binfmt_misc -> /proc/sys/fs/binfmt_misc/,
deny @{PROC}/sys/fs/** wklx,
# allow efivars to be mounted, writing to it will be blocked though
mount fstype=efivarfs -> /sys/firmware/efi/efivars/,
# block some other dangerous paths
deny @{PROC}/kcore rwklx,
deny @{PROC}/sysrq-trigger rwklx,
# deny writes in /sys except for /sys/fs/cgroup, also allow
# fusectl, securityfs and debugfs to be mounted there (read-only)
mount fstype=fusectl -> /sys/fs/fuse/connections/,
mount fstype=securityfs -> /sys/kernel/security/,
mount fstype=debugfs -> /sys/kernel/debug/,
deny mount fstype=debugfs -> /var/lib/ureadahead/debugfs/,
mount fstype=proc -> /proc/,
mount fstype=sysfs -> /sys/,
mount options=(rw, nosuid, nodev, noexec, remount) -> /sys/,
deny /sys/firmware/efi/efivars/** rwklx,
# note, /sys/kernel/security/** handled below
mount options=(ro, nosuid, nodev, noexec, remount, strictatime) ->
/sys/fs/cgroup/,
# deny reads from debugfs
deny /sys/kernel/debug/{,**} rwklx,
# allow paths to be made slave, shared, private or unbindable
# FIXME: This currently doesn't work due to the apparmor parser
treating those as allowing all mounts.
# mount options=(rw,make-slave) -> **,
# mount options=(rw,make-rslave) -> **,
# mount options=(rw,make-shared) -> **,
# mount options=(rw,make-rshared) -> **,
# mount options=(rw,make-private) -> **,
# mount options=(rw,make-rprivate) -> **,
# mount options=(rw,make-unbindable) -> **,
# mount options=(rw,make-runbindable) -> **,
# allow bind-mounts of anything except /proc, /sys and /dev
mount options=(rw,bind) /[^spd]*{,/**},
mount options=(rw,bind) /d[^e]*{,/**},
mount options=(rw,bind) /de[^v]*{,/**},
mount options=(rw,bind) /dev/.[^l]*{,/**},
mount options=(rw,bind) /dev/.l[^x]*{,/**},
mount options=(rw,bind) /dev/.lx[^c]*{,/**},
mount options=(rw,bind) /dev/.lxc?*{,/**},
mount options=(rw,bind) /dev/[^.]*{,/**},
mount options=(rw,bind) /dev?*{,/**},
mount options=(rw,bind) /p[^r]*{,/**},
mount options=(rw,bind) /pr[^o]*{,/**},
mount options=(rw,bind) /pro[^c]*{,/**},
mount options=(rw,bind) /proc?*{,/**},
mount options=(rw,bind) /s[^y]*{,/**},
mount options=(rw,bind) /sy[^s]*{,/**},
mount options=(rw,bind) /sys?*{,/**},
# allow various ro-bind-*re*-mounts
mount options=(ro,remount,bind),
mount options=(ro,remount,bind,nosuid),
mount options=(ro,remount,bind,noexec),
mount options=(ro,remount,bind,nodev),
mount options=(ro,remount,bind,nosuid,noexec),
mount options=(ro,remount,bind,noexec,nodev),
mount options=(ro,remount,bin
Bug#987959: pev: peres affected by off-by-one error in libpe
Since it can corrupt adjacent heap chunk metadata, this definitely looks like a security issue to me. On Thu, May 6, 2021 at 9:29 AM Petter Reinholdtsen wrote: > > I asked for an unblock from the release team in > https://bugs.debian.org/988095 >. > > -- > Happy hacking > Petter Reinholdtsen >
Bug#983408: How to build the packages from sources
Hi, well that may not be the right/proper way to produce the packages, but in the mean time, some instructions if you ever want to produce your own packages https://linuxfr.org/users/oumph/journaux/compilation-de-0-a-d-alpha-24-pour-debian-buster (in French). Main changes I've noted: - libmozjs78 instead of libmozjs38 (part of the 0.A.D. release notes) - require nvtt >= 2.1.0 (only in Debian experimental for now), so I fallback to the non-system version (so extra libs to deploy, and maybe extra packages needed to build) Regards, -- Benoît Sibaud
Bug#980157: cavezofphear: executable not found in the description
Package: cavezofphear Version: 0.5.1-1.1 Severity: minor Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? I installed the package and spent 5 mn finding the binary, named phear, by resorting to: ls /usr/games * What was the outcome of this action? game launched fine on the console with the correct command line; man phear works too. This is a text game, there is no .desktop file. Regards, Benoît Delcour -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.4-rt20-poupou (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, 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) Versions of packages cavezofphear depends on: ii libc62.31-9 ii libncurses6 6.2+20201114-2 ii libtinfo66.2+20201114-2 cavezofphear recommends no packages. cavezofphear suggests no packages. -- no debconf information
Bug#976138: qmidiarp: died unexpectedly in non/new-session-manager(NSM)
Hello Rooz, Maybe you should try to use the upstream release of the same version and see if the same error occurs in qmidiarp. This would help a lot: If upstream has the same bug, please inform the upstream developer of that bug. If not, One, you, me, ... could investigate more. Thanks, Ben Le 30/11/2020 à 14:15, Benoît Rouits a écrit : Hello, I tried and can confirm with a bit more information: As a workadround, if we close qmidiarp before to quit, the bug is not there. The bug seems to be in qmidiarp when restored by nsm: [...] jack process callback registered Session callback registered [nsmd] ../src/nsmd.cpp:1995 osc_reply(): Client "QMidiArp" replied with: OK in 1044.477000ms [nsmd] ../src/nsmd.cpp:582 wait_for_replies(): Done waiting [nsmd] ../src/nsmd.cpp:1180 tell_all_clients_session_is_loaded(): Telling all clients that session is loaded... [nsmd] ../src/nsmd.cpp:1172 tell_client_session_is_loaded(): Telling client QMidiArp that session is loaded. [nsmd] ../src/nsmd.cpp:1342 load_session_file(): Loaded. [nsmd] ../src/nsmd.cpp:1635 osc_open(): Loaded [nsmd] ../src/nsmd.cpp:1666 osc_open(): Done ASSERT failure in QList::at: "index out of range", file /usr/include/x86_64-linux-gnu/qt5/QtCore/qlist.h, line 544 The assertion fails in QMidiArp (which is the sole Qt app). Sad I cannot know more in details. Le 30/11/2020 à 11:17, rooz a écrit : Package: qmidiarp Version: 0.6.5-3 Severity: normal X-Debbugs-Cc: rosea.grammost...@gmail.com Dear Maintainer, Start non-session-manager, add qmidiarp to session. Make a change. Save. Close. Restart session. Client QmidiArp died unexpectedly -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-3-rt-amd64 (SMP w/2 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 qmidiarp depends on: ii libasound2 1.2.3.2-1+b1 ii libc6 2.31-4 ii libgcc-s1 [libgcc1] 10.2.0-16 ii libjack-jackd2-0 [libjack-0.125] 1.9.16~dfsg-1 ii liblo7 0.31-1 ii libqt5core5a 5.15.1+dfsg-2 ii libqt5gui5 5.15.1+dfsg-2 ii libqt5widgets5 5.15.1+dfsg-2 ii libstdc++6 10.2.0-16 Versions of packages qmidiarp recommends: ii jackd 5+nmu1 qmidiarp suggests no packages. -- no debconf information
Bug#976120: finalizing qabc package (Bug#976120)
Dear mentors, Thanks to the comments from some of you on bug Bug#976120 (RFS: qabc/2.0-1 [ITP]), I finalized at last a neat packaging (i think) of QAbc: minimal GUI for ABC music notation. I am now looking for a mentor and I would be grateful, if some of you are interested, to let qabc be included into Debian repository. To access further information about this package, please visit the following URL: https://mentors.debian.net/package/qabc/ Alternatively, one can download the latest package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/q/qabc/qabc_2.0.1-2.dsc The source contains also a heavy modified code from abcm2ps source code as an embedded library wich won't be merged to upstream abcm2ps for some good reason ( see https://github.com/leesavide/abcm2ps/issues/80 ). As Paul Wise told me, I will get the embedded "copy" of abcm2ps code to be recorded in the security team's repository if it is included into Debian. I will also try to backport security fixes from abcm2ps to my library code, despite code divergence is growing with time. Thank you for your support, Benoît
Bug#976120: (QAbc packaging) debhelper version question
Thank you for your reply. I used to put this line: Build-Depends: debhelper-compat (= 12), ... Should I then remove "-compat" like this ? Build-Depends: debhelper (= 13), ... Le 04/12/2020 à 21:29, Andrey Rahmatullin a écrit : On Fri, Dec 04, 2020 at 08:39:26PM +0100, Benoît Rouits wrote: I use debhelper but I don't use specific features of debhelper 13. Anyway, should I set debhelper = 13 as build dependency Yes. or can I set debhelper >= 12 to be more flexible for transition from sid to testing and to stable ? It won't help "for transition from sid to testing" and there is no "transition to stable".
Bug#976120: (QAbc packaging) debhelper version question
Hello, About packaging QAbc I have an interrogation: I use debhelper but I don't use specific features of debhelper 13. Anyway, should I set debhelper = 13 as build dependency or can I set debhelper >= 12 to be more flexible for transition from sid to testing and to stable ? Thanks for your replies. Benoît
Bug#976138: qmidiarp: died unexpectedly in non/new-session-manager(NSM)
Hello, I tried and can confirm with a bit more information: As a workadround, if we close qmidiarp before to quit, the bug is not there. The bug seems to be in qmidiarp when restored by nsm: [...] jack process callback registered Session callback registered [nsmd] ../src/nsmd.cpp:1995 osc_reply(): Client "QMidiArp" replied with: OK in 1044.477000ms [nsmd] ../src/nsmd.cpp:582 wait_for_replies(): Done waiting [nsmd] ../src/nsmd.cpp:1180 tell_all_clients_session_is_loaded(): Telling all clients that session is loaded... [nsmd] ../src/nsmd.cpp:1172 tell_client_session_is_loaded(): Telling client QMidiArp that session is loaded. [nsmd] ../src/nsmd.cpp:1342 load_session_file(): Loaded. [nsmd] ../src/nsmd.cpp:1635 osc_open(): Loaded [nsmd] ../src/nsmd.cpp:1666 osc_open(): Done ASSERT failure in QList::at: "index out of range", file /usr/include/x86_64-linux-gnu/qt5/QtCore/qlist.h, line 544 The assertion fails in QMidiArp (which is the sole Qt app). Sad I cannot know more in details. Le 30/11/2020 à 11:17, rooz a écrit : Package: qmidiarp Version: 0.6.5-3 Severity: normal X-Debbugs-Cc: rosea.grammost...@gmail.com Dear Maintainer, Start non-session-manager, add qmidiarp to session. Make a change. Save. Close. Restart session. Client QmidiArp died unexpectedly -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-3-rt-amd64 (SMP w/2 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 qmidiarp depends on: ii libasound21.2.3.2-1+b1 ii libc6 2.31-4 ii libgcc-s1 [libgcc1] 10.2.0-16 ii libjack-jackd2-0 [libjack-0.125] 1.9.16~dfsg-1 ii liblo70.31-1 ii libqt5core5a 5.15.1+dfsg-2 ii libqt5gui55.15.1+dfsg-2 ii libqt5widgets55.15.1+dfsg-2 ii libstdc++610.2.0-16 Versions of packages qmidiarp recommends: ii jackd 5+nmu1 qmidiarp suggests no packages. -- no debconf information
Bug#976120: RFS: qabc/2.0-1 [ITP] -- minimal GUI for ABC music notation
Le 30/11/2020 à 05:17, Paul Wise a écrit : On Mon, Nov 30, 2020 at 3:21 AM Benoît Rouits wrote: Thank you for the note. Lilypond is a command-line sheet music engraver similar (but different) to MusiXTeX. QAbc is a desktop user interface with an editor view and an SVG preview. The approaches are very different, IMHO. QAbc allow to quickly notate tunes, listen to it and print it but is not appropriate for professional engraving. There are GUI frontends to lilypond though, for example denemo. It sounds like they have different purposes/audiences though. I understand. The original patch to abcm2ps have been refused upstream for some reasons I understand completely. I started to modify more heavily the code of abcm2ps in order to use it as a library. That modified abcm2ps code is useless alone, it's a part of QAbc. Thank you for the link you gave me. I'll contact the debian-security-tracker mailing list to add the qabc package as having, for now, a forked embedded copy of abcm2ps. It seems like separating abcm2ps into a library and command-line tools would be a valuable thing to have upstreamed, so that other programs can use the functionality too. Yes indeed. But the original maintainer of abcm2ps told me abcm2ps is at its end of life. Anyway, if I succeed to make good library code from abcm2ps (many tried, many failed told me the maintainer), I'll then release it as a separate package. PS: I forgot to mention in my initial mail that you might like to join the Debian multimedia team and help maintain other music related packages. The team might also be likely to sponsor Qabc. https://wiki.debian.org/DebianMultimedia Thank you, I subscribed and will introduce myself. Many thanks for your interest an indications, Paul, Benoît
Bug#976120: RFS: qabc/2.0-1 [ITP] -- minimal GUI for ABC music notation
Le 30/11/2020 à 03:39, Paul Wise a écrit : On Mon, Nov 30, 2020 at 12:48 AM Benoît Rouits wrote: QAbc has not yet an equivalent software in Debian. It's written in C++/Qt, uses libfluidsynth for synthesis, and makes use of abc2midi binary (from abcmidi package) to generate temporary midi files to be played. Thus, abcmidi has been placed in the "Recommends" section of the control file, but could be preferably placed in Depends... ? I note that Lilypond can import ABC format, so that would seem to be similar to QAbc. Thank you for the note. Lilypond is a command-line sheet music engraver similar (but different) to MusiXTeX. QAbc is a desktop user interface with an editor view and an SVG preview. The approaches are very different, IMHO. QAbc allow to quickly notate tunes, listen to it and print it but is not appropriate for professional engraving. Unless QAbc can also natively generate MIDI files or work without generating MIDI files, then Recommends sounds incorrect and Depends should be used instead. Okay, thank you for the precision. So it should, for now, use Depends. Moreover, I know no alternative to abc2midi to simply generate MIDI from ABC. I will upload a new version of the source package that takes this into account. QAbc also includes some modified source code from abcm2ps in a way to workaround Qt's poorness in SVG rendering (see QTBUG-88494 in qt.io). Debian packages should not use embedded code copies where possible, this seems like an exception for now though. Please get the copy recorded in the security team's repository and also make sure that the embedded copy is not used with versions of Qt where that bug is fixed, when that happens. https://wiki.debian.org/EmbeddedCopies I understand. The original patch to abcm2ps have been refused upstream for some reasons I understand completely. I started to modify more heavily the code of abcm2ps in order to use it as a library. That modified abcm2ps code is useless alone, it's a part of QAbc. Thank you for the link you gave me. I'll contact the debian-security-tracker mailing list to add the qabc package as having, for now, a forked embedded copy of abcm2ps. Have a good week, Benoît
Bug#976120: RFS: qabc/2.0-1 [ITP] -- minimal GUI for ABC music notation
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "qabc": * Package name: qabc Version : 2.0-1 Upstream Author : Benoît Rouits * URL : http://brouits.free.fr/qabc/ * License : GPL-3+ * Vcs : https://github.com/be1/qabc Section : misc It builds those binary packages: qabc - minimal GUI for ABC music notation To access further information about this package, please visit the following URL: https://mentors.debian.net/package/qabc/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/q/qabc/qabc_2.0-1.dsc Changes for the initial release: qabc (2.0-1) unstable; urgency=medium . * Initial release. (Closes: #975688) QAbc has not yet an equivalent software in Debian. It's written in C++/Qt, uses libfluidsynth for synthesis, and makes use of abc2midi binary (from abcmidi package) to generate temporary midi files to be played. Thus, abcmidi has been placed in the "Recommends" section of the control file, but could be preferably placed in Depends... ? QAbc also includes some modified source code from abcm2ps in a way to workaround Qt's poorness in SVG rendering (see QTBUG-88494 in qt.io). As sometimes a screenshot is worth better than a long explanation, you can see a picture on the upstream page: http://brouits.free.fr/qabc/ I hope this program will retain your attention and will be included into Debian. Have a nice week, Benoît OpenPGP_0x6A7532B8CEABEA53.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Bug#975688: ITP: qabc -- minimal GUI for ABC music notation
Package: wnpp Severity: wishlist Owner: Benoît Rouits X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: qabc Version : 2.0 Upstream Author : Benoît Rouits * URL : http://brouits.free.fr/qabc/ * License : GPL3+ Programming Lang: C++ Description : minimal GUI for ABC music notation QAbc is a simple graphical program that allow to write musical scores in the ABC notation. . This program allow to play the written music, preview the output score and print it. This program has no equivalent in Debian. The sole GUI ABC editor found on the web is EasyABC, written in python2. Qabc is simpler but yet has MIDI playback, preview and printing functionality. As i am also the upstream author and an ABC notation fan, I am willing to maintain it as long as possible. OpenPGP_0x6A7532B8CEABEA53.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Bug#964009: coturn cannot bind TLS/TCP listener socket to addr
Package: coturn Version: 4.5.1.1-1.1+deb10u1 Since the last update (from 4.5.1.1-1.1 to 4.5.1.1-1.1+deb10u1) coturn server does not work anymore. The file /var/log/syslog contains : Jun 29 18:25:08 rex turnserver: 0: Cannot bind TLS/TCP listener socket to addr W.X.Y.Z:443 Jun 29 18:25:08 rex turnserver: 0: Trying to bind TLS/TCP listener socket to addr W.X.Y.Z:443, again... I found out an issue on GitHub for this : https://github.com/coturn/coturn/issues/421 I modified the file /lib/systemd/system/coturn.service to include AmbientCapabilities=CAP_NET_BIND_SERVICE to the [Service] section and the coturn server is working again. I hope It can help people. Best regards Benoît
Bug#962262: Acknowledgement (opendmarc fails many emails without apparent reason)
Dear Maintainer I think I got it. Maybe updating the manpage would be very helpfull for other people who stumble over the same problem. DMARC needs to do an SPF check. Well I have milter-greylist already performing SPF check, so I configured what I tought would make opendmarc ignore the SPF check and assuming an email that went that far already passed SPF check (which is true in my case). Now I understand, opendmarc need to do SPF check itself. Only this way the result ever returns 'pass'. SPFSelfValidate true Problem solved. I wonder if I could make milter-greylist to create a header which would satisfy opendmarc but I could not find any documentation of the Authentication-Result: header. -Benoît-
Bug#962262: Acknowledgement (opendmarc fails many emails without apparent reason)
Additional Infos: History file entry of such an failing email: job 055AOEWZ026900 reporter magma.woody.ch received 1591352655 ipaddr 2a00:1450:4864:20::52c from gmail.com mfrom gmail.com spf -1 pdomain gmail.com policy 18 rua mailto:mailauth-repo...@google.com pct 100 adkim 114 aspf 114 p 110 sp 113 align_dkim 5 align_spf 5 action 2
Bug#959384: similarity-tester: Fix compilation warnings and enable reproductible builds.
Package: similarity-tester
Version: 3.0.2-1+b1
Severity: normal
Tags: patch
Dear Maintainer,
here's patch to fix compilation warnings and actually enable
reproductible builds.
Upstream seems totally dead but this software is really
important to me.
Thank you.
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500,
'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.4.0-4-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/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages similarity-tester depends on:
ii libc6 2.30-4
similarity-tester recommends no packages.
similarity-tester suggests no packages.
-- debconf-show failed
>From 613976535663abc254b5f48e2b22215fb55a675a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Dejean?=
Date: Fri, 1 May 2020 20:17:15 +0200
Subject: [PATCH] Enable and fix compilation warnings.
---
ForEachFile.c | 4 ++--
Makefile | 3 ++-
Malloc.c | 2 +-
compare.c | 4 ++--
debug.c | 3 ++-
options.c | 2 ++
pass3.c | 2 +-
7 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/ForEachFile.c b/ForEachFile.c
index a7b9166..991fe6d 100644
--- a/ForEachFile.c
+++ b/ForEachFile.c
@@ -122,8 +122,8 @@ do_dir(
Closedir(dir);
}
-static MSDOS_sep = (Fchar)'\\';
-static UNIX_sep = (Fchar)'/';
+static const char MSDOS_sep = (Fchar)'\\';
+static const char UNIX_sep = (Fchar)'/';
static void
clean_name(Fchar *Fn) {
diff --git a/Makefile b/Makefile
index 7bce7f6..6416dad 100644
--- a/Makefile
+++ b/Makefile
@@ -4,6 +4,7 @@
#
#VERSION="-DVERSION=\"3.0.2 of 2017-12-16\"" # uncomment for public version
+VERSION="-DVERSION=\"3.0.2-2 Debian\""
# E N T R Y P O I N T S
@@ -78,7 +79,7 @@ GROFF = man2pdf
export DEB_BUILD_MAINT_OPTIONS=hardening=+all
# Compiling
MEMORY = -DMEMCHECK -DMEMCLOBBER
-CFLAGS = $(VERSION) $(MEMORY) -O4 $(shell dpkg-buildflags --get
CPPFLAGS) $(shell dpkg-buildflags --get CFLAGS) -fPIC
+CFLAGS = $(VERSION) $(MEMORY) -Wall $(shell dpkg-buildflags --get
CPPFLAGS) $(shell dpkg-buildflags --get CFLAGS) -fPIC
LIBFLAGS = #
LINTFLAGS =-Dlint_test $(MEMORY) -h# -X
LOADFLAGS =-s $(shell dpkg-buildflags --get LDFLAGS) # strip symbol table
diff --git a/Malloc.c b/Malloc.c
index 39ed530..cde504f 100644
--- a/Malloc.c
+++ b/Malloc.c
@@ -57,7 +57,7 @@ struct alloc {/* corresponds to an allocated block */
#defineHASH_SIZE 16381 /* largest prime under 2^16 */
static struct alloc *alloc_bucket[HASH_SIZE];
-#definealloc_bucket_for(x) alloc_bucket[((unsigned
int)(x)%HASH_SIZE)]
+#definealloc_bucket_for(x) alloc_bucket[((size_t)(x)%HASH_SIZE)]
/* MEMORY STATUS */
diff --git a/compare.c b/compare.c
index 189f607..2feb340 100644
--- a/compare.c
+++ b/compare.c
@@ -33,8 +33,8 @@ in_range(size_t i, const struct range *rg) {
return (rg->rg_start <= i && i < rg->rg_limit);
} else {
/* looped-around range */
- return (rg->rg_start <= i && i < end_of_text
- || beginning_of_text <= i && i < rg->rg_limit);
+ return (rg->rg_start <= i && i < end_of_text)
+ || (beginning_of_text <= i && i < rg->rg_limit);
}
}
diff --git a/debug.c b/debug.c
index e27c335..3828007 100644
--- a/debug.c
+++ b/debug.c
@@ -3,6 +3,7 @@
$Id: debug.c,v 1.8 2017-12-08 18:07:16 Gebruiker Exp $
*/
+#include
#include
#include
#include
@@ -26,7 +27,7 @@
static void
wr_char(char ch) {
- write(2, &ch, 1);
+ fputc(ch, stderr);
}
static void
diff --git a/options.c b/options.c
index 0416f6e..59ccd78 100644
--- a/options.c
+++ b/options.c
@@ -121,6 +121,8 @@ opt_value(
case String:
*(const char **)op->op_value = string;
break;
+ default:
+ break;
}
return consumed;
diff --git a/pass3.c b/pass3.c
index 9c0be1b..7c4de66 100644
--- a/pass3.c
+++ b/pass3.c
@@ -185,7 +185,7 @@ print_line(FILE *f, pts max_line_length) {
utf8_box u; clear_utf8_box(&u);
int len;
- while (len = fill_ubox(f, &u)) {
+ while ((len = fill_ubox(f, &u))) {
/* take a critical look at what we've got */
char u0 = u.text[0];
if (u0 == '\n') break; /* stop on end of line*/
--
2.26.0
Bug#947653: csv2latex FTCBFS: strips with the wrong strip
Ok, thank you Helmut. As I am also the upstream dev of csv2latex. After reflection, I eventually found 'strip' being useless now. So, instead of making a patch in the debian/patches, I released csv2latex-0.22 (upstream) with Makefile fixed (no strip at all), so that it is simpler for everyone. I just uploaded the Debian source package on : https://mentors.debian.net/package/csv2latex Hopefully, I know a mentor that will almost certainly upload the package in unstable in a few hours or days. Thank you again for your bug report! I let you close bug #947653 when you want (reason: fixed upstream)... Benoît Le 02/01/2020 à 20:08, Helmut Grohne a écrit : > Hi Benoît, > > On Sun, Dec 29, 2019 at 05:57:51PM +0100, Benoît Rouits wrote: >> Unfortunately, i cannot sign the new source package due to your >> changelog entry. What is the best way to integrate your patch then ? >> May i change the debian changelog entry with my own message or is there >> a better way to integrate your patch (maybe you should sign the source >> package) ? > > Of course you should change the changelog entry. It is still unreleased. > You can use "dch -r" to update the release. Doing so will also change > the final email address to yours. Alternatively, you can edit the text > yourself or only apply the non-changelog portion of my patch and > manually add your changelog. Whatever fits your workflow. > > Helmut > signature.asc Description: OpenPGP digital signature
Bug#947653: csv2latex FTCBFS: strips with the wrong strip
Hello again Helmut, Unfortunately, i cannot sign the new source package due to your changelog entry. What is the best way to integrate your patch then ? May i change the debian changelog entry with my own message or is there a better way to integrate your patch (maybe you should sign the source package) ? Thank you for your reply. Benoît Le 29/12/2019 à 17:45, Benoît Rouits a écrit : > Thank you Helmut for your patch. > I am applying it. Then i will ask my deb mentor to upload the new source > package i will build with your patch included. > Benoît > > Le 28/12/2019 à 21:52, Helmut Grohne a écrit : >> Source: csv2latex >> Version: 0.21-1 >> Tags: patch >> User: debian-cr...@lists.debian.org >> Usertags: ftcbfs >> >> csv2latex fails to cross build from source, because it strips with the >> wrong strip at make install time. Beyond breaking cross compilation, >> this breaks DEB_BUILD_OPTION=nostrip as well as generation of -dbgsym >> packages. It is best to defer all stripping to dh_strip. The attached >> patch implements that. Please consider applying it. >> >> Helmut >>
Bug#947653: csv2latex FTCBFS: strips with the wrong strip
Thank you Helmut for your patch. I am applying it. Then i will ask my deb mentor to upload the new source package i will build with your patch included. Benoît Le 28/12/2019 à 21:52, Helmut Grohne a écrit : > Source: csv2latex > Version: 0.21-1 > Tags: patch > User: debian-cr...@lists.debian.org > Usertags: ftcbfs > > csv2latex fails to cross build from source, because it strips with the > wrong strip at make install time. Beyond breaking cross compilation, > this breaks DEB_BUILD_OPTION=nostrip as well as generation of -dbgsym > packages. It is best to defer all stripping to dh_strip. The attached > patch implements that. Please consider applying it. > > Helmut >
Bug#939929: terminator: crash when trying to start
Got it: it comes from the accent in my terminator profile name "Présentation". I rewrote it as "Presentation" and it all works… Thanks for the tip! On Thu, 14 Nov 2019 13:06:36 +0100 Egmont Koblinger wrote: > Hi, > > Could you please share your terminator config file > (/home/benoit/.config/terminator/config)? > > If you move that file away, does terminator 1.91-4 start up? > > thanks, > e. > >
Bug#939929: terminator: crash when trying to start
Indeed, if removing config file it now starts! I should have thought about it… In case you want to investigate deeper on this, my config file contains: [global_config] focus = mouse suppress_multiple_term_dialog = True title_hide_sizetext = True window_state = maximise [keybindings] [layouts] [[default]] [[[child0]]] fullscreen = False last_active_term = 126a60a1-1650-434b-b7a8-79bc4b5325a3 last_active_window = True maximised = True order = 0 parent = "" position = 0:30 size = 2560, 1373 title = bmasson@prunelle: /home/bmasson type = Window [[[child1]]] order = 0 parent = child0 position = 1285 ratio = 0.5 type = HPaned [[[terminal2]]] directory = "" order = 0 parent = child1 profile = default type = Terminal uuid = 126a60a1-1650-434b-b7a8-79bc4b5325a3 [[[terminal3]]] directory = /home/bmasson/svn order = 1 parent = child1 profile = default type = Terminal uuid = 5e9c69fe-9a25-4404-9b10-0678ad713d5c [[old_default]] [[[child1]]] directory = "" parent = window0 type = Terminal [[[window0]]] parent = "" type = Window [plugins] [profiles] [[default]] cursor_color = "#aa" foreground_color = "#ff" scrollback_lines = 1024 show_titlebar = False [[Présentation]] background_color = "#ff" cursor_color = "#aa" font = Monospace 16 foreground_color = "#00" show_titlebar = False use_system_font = False On Thu, 14 Nov 2019 13:06:36 +0100 Egmont Koblinger wrote: > Hi, > > Could you please share your terminator config file > (/home/benoit/.config/terminator/config)? > > If you move that file away, does terminator 1.91-4 start up? > > thanks, > e. > >
Bug#943504: firefox-esr: Firefox Wayland crashes at startup
Package: firefox-esr Version: 68.2.0esr-1~deb10u1 Severity: important Tags: newcomer Dear Maintainer, When setting MOZ_ENABLE_WAYLAND=1, Firefox crashes at startup. It seems the problem comes from DBUS: org.mozilla.firefox-esr is an invalid interface name. Debian package defines MOZ_APP_REMOTINGNAME as $(call uc_first,$($(PRODUCT))) so it ends up being Firefox-esr for this package. I fixed it using export MOZ_APP_REMOTINGNAME := $(subst -,_,$(call uc_first,$($(PRODUCT in debian/rules so the DBUS interface name is valid while being different from firefox (non ESR). Thank you. -- Package-specific info: -- Addons package information -- System Information: Debian Release: 10.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages firefox-esr depends on: ii debianutils 4.8.6.1 ii fontconfig2.13.1-2 ii libasound21.1.8-1 ii libatk1.0-0 2.30.0-2 ii libc6 2.28-10 ii libcairo-gobject2 1.16.0-4 ii libcairo2 1.16.0-4 ii libdbus-1-3 1.12.16-1 ii libdbus-glib-1-2 0.110-4 ii libevent-2.1-62.1.8-stable-4 ii libffi6 3.2.1-9 ii libfontconfig12.13.1-2 ii libfreetype6 2.9.1-3 ii libgcc1 1:8.3.0-6 ii libgdk-pixbuf2.0-02.38.1+dfsg-1 ii libglib2.0-0 2.58.3-2+deb10u1 ii libgtk-3-03.24.5-1 ii libjsoncpp1 1.7.4-3 ii libpango-1.0-01.42.4-7~deb10u1 ii libstartup-notification0 0.12-6 ii libstdc++68.3.0-6 ii libvpx5 1.7.0-3 ii libx11-6 2:1.6.7-1 ii libx11-xcb1 2:1.6.7-1 ii libxcb-shm0 1.13.1-2 ii libxcb1 1.13.1-2 ii libxcomposite11:0.4.4-2 ii libxdamage1 1:1.1.4-3+b3 ii libxext6 2:1.3.3-1+b2 ii libxfixes31:5.0.3-1 ii libxrender1 1:0.9.10-1 ii libxt61:1.1.5-1+b3 ii procps2:3.3.15-2 ii zlib1g1:1.2.11.dfsg-1 Versions of packages firefox-esr recommends: ii libavcodec58 7:4.1.4-1~deb10u1 Versions of packages firefox-esr suggests: ii fonts-lmodern 2.004.5-6 pn fonts-stix | otf-stix ii libcanberra0 0.30-7 ii libgssapi-krb5-2 1.17-3 ii libgtk2.0-02.24.32-3 ii pulseaudio 12.2-4+deb10u1 -- no debconf information
Bug#940672: Please add support for HP x2 210 PMIC and sound card
Package: linux-image-5.3.0-rc5-amd64 Version: 5.3~rc5-1~exp2 Severity: wishlist Tags: patch HP x2 210 has an AXP288 PMIC. Battery driver is already enabled but not the charger one. Moreover, the ADC driver is needed to make them work. Also, this device uses the (now landed) CX2072X codec. Here is a proposed patch (against current debian linux git branch) which enables the necessary drivers. Thanks for all your work ;) diff --git a/debian/config/kernelarch-x86/config b/debian/config/kernelarch-x86/config index cbf9193..e58a66b 100644 --- a/debian/config/kernelarch-x86/config +++ b/debian/config/kernelarch-x86/config @@ -454,6 +454,7 @@ CONFIG_EDAC_AMD8111=m ## file: drivers/extcon/Kconfig ## CONFIG_EXTCON=m +CONFIG_EXTCON_AXP288=m CONFIG_EXTCON_INTEL_CHT_WC=m ## @@ -703,6 +704,11 @@ CONFIG_KXCJK1013=m CONFIG_MMA9551=m CONFIG_MMA9553=m +## +## file: drivers/iio/adc/Kconfig +## +CONFIG_AXP288_ADC=m + ## ## file: drivers/iio/gyro/Kconfig ## @@ -1444,6 +1450,7 @@ CONFIG_PNP=y ## file: drivers/power/supply/Kconfig ## CONFIG_BATTERY_SBS=m +CONFIG_AXP288_CHARGER=m CONFIG_AXP288_FUEL_GAUGE=m CONFIG_BATTERY_MAX17042=m CONFIG_CHARGER_BQ24190=m @@ -2102,6 +2109,7 @@ CONFIG_SND_SOC_INTEL_CHT_BSW_RT5672_MACH=m CONFIG_SND_SOC_INTEL_CHT_BSW_RT5645_MACH=m CONFIG_SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH=m CONFIG_SND_SOC_INTEL_CHT_BSW_NAU8824_MACH=m +CONFIG_SND_SOC_INTEL_BYT_CHT_CX2072X_MACH=m CONFIG_SND_SOC_INTEL_BYT_CHT_DA7213_MACH=m CONFIG_SND_SOC_INTEL_BYT_CHT_ES8316_MACH=m # CONFIG_SND_SOC_INTEL_BYT_CHT_NOCODEC_MACH is not set
Bug#940558: webdis: cannot restart systemd service
Package: webdis Version: 0.1.4+dfsg-1+b1 Severity: important Hello, There seems to be a problem with the systemd unit included in the webdis package. The provided file uses the following configuration: ExecStartPre=mkdir /var/run/webdis ExecStartPre=chown webdis: /var/run/webdis ExecStart=/usr/bin/webdis /etc/webdis/webdis.json The problem is caused by the first line. When webdis is restarted, the directory already exists, causing the command to fail, which in turns causes systemd to abort. Using the following line: ExecStartPre=mkdir -p /var/run/webdis fixes the problem. Best regards, Emmanuel Benoît -- System Information: Debian Release: 10.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/1 CPU core) 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 webdis depends on: ii adduser 3.118 ii libb64-0d 1.2-5 ii libc6 2.28-10 ii libevent-2.1-6 2.1.8-stable-4 ii libhiredis0.14 0.14.0-3 ii libjansson4 2.12-1 ii libmsgpackc23.0.1-3 ii lsb-base10.2019051400 webdis recommends no packages. Versions of packages webdis suggests: ii redis-server 5:5.0.3-4+deb10u1 -- Configuration Files: /etc/webdis/webdis.json changed [not included] -- no debconf information
Bug#939929: terminator: crash when trying to start
Package: terminator
Version: 1.91-4
Severity: important
I am not able to start terminator v1.91, it crashes immediately.
Downgrading to 1.90 works.
Error report below, please let me know if you need any more information.
Traceback (most recent call last):
File "/usr/bin/terminator", line 117, in
TERMINATOR.reconfigure()
File "/usr/share/terminator/terminatorlib/terminator.py", line 504, in
reconfigure
style_provider.load_from_data(css.encode('utf-8'))
gi.repository.GLib.Error: gtk-css-provider-error-quark:
:24:34Expected a valid selector (1)
With --debug flag:
ConfigBase::__init__: Borg::__init__: Preparing borg state for ConfigBase
noclass::get_config_dir: Found config dir: /home/benoit/.config
ConfigBase::load: looking for config file:
/home/benoit/.config/terminator/config
ConfigBase::load: config validated successfully
ConfigBase::load: ConfigBase::load: Processing section: global_config
ConfigBase::load: ConfigBase::load: Processing section: keybindings
ConfigBase::load: ConfigBase::load: Processing keybindings: zoom_in
ConfigBase::load: ConfigBase::load: Processing keybindings: zoom_out
ConfigBase::load: ConfigBase::load: Processing keybindings: zoom_normal
ConfigBase::load: ConfigBase::load: Processing keybindings: new_tab
ConfigBase::load: ConfigBase::load: Processing keybindings: cycle_next
ConfigBase::load: ConfigBase::load: Processing keybindings: cycle_prev
ConfigBase::load: ConfigBase::load: Processing keybindings: go_next
ConfigBase::load: ConfigBase::load: Processing keybindings: go_prev
ConfigBase::load: ConfigBase::load: Processing keybindings: go_up
ConfigBase::load: ConfigBase::load: Processing keybindings: go_down
ConfigBase::load: ConfigBase::load: Processing keybindings: go_left
ConfigBase::load: ConfigBase::load: Processing keybindings: go_right
ConfigBase::load: ConfigBase::load: Processing keybindings: rotate_cw
ConfigBase::load: ConfigBase::load: Processing keybindings: rotate_ccw
ConfigBase::load: ConfigBase::load: Processing keybindings: split_horiz
ConfigBase::load: ConfigBase::load: Processing keybindings: split_vert
ConfigBase::load: ConfigBase::load: Processing keybindings: close_term
ConfigBase::load: ConfigBase::load: Processing keybindings: copy
ConfigBase::load: ConfigBase::load: Processing keybindings: paste
ConfigBase::load: ConfigBase::load: Processing keybindings: toggle_scrollbar
ConfigBase::load: ConfigBase::load: Processing keybindings: search
ConfigBase::load: ConfigBase::load: Processing keybindings: close_window
ConfigBase::load: ConfigBase::load: Processing keybindings: resize_up
ConfigBase::load: ConfigBase::load: Processing keybindings: resize_down
ConfigBase::load: ConfigBase::load: Processing keybindings: resize_left
ConfigBase::load: ConfigBase::load: Processing keybindings: resize_right
ConfigBase::load: ConfigBase::load: Processing keybindings: move_tab_right
ConfigBase::load: ConfigBase::load: Processing keybindings: move_tab_left
ConfigBase::load: ConfigBase::load: Processing keybindings: toggle_zoom
ConfigBase::load: ConfigBase::load: Processing keybindings: scaled_zoom
ConfigBase::load: ConfigBase::load: Processing keybindings: next_tab
ConfigBase::load: ConfigBase::load: Processing keybindings: prev_tab
ConfigBase::load: ConfigBase::load: Processing keybindings: full_screen
ConfigBase::load: ConfigBase::load: Processing keybindings: reset
ConfigBase::load: ConfigBase::load: Processing keybindings: reset_clear
ConfigBase::load: ConfigBase::load: Processing keybindings: hide_window
ConfigBase::load: ConfigBase::load: Processing keybindings: group_all
ConfigBase::load: ConfigBase::load: Processing keybindings: ungroup_all
ConfigBase::load: ConfigBase::load: Processing keybindings: group_tab
ConfigBase::load: ConfigBase::load: Processing keybindings: ungroup_tab
ConfigBase::load: ConfigBase::load: Processing keybindings: new_window
ConfigBase::load: ConfigBase::load: Processing keybindings: new_terminator
ConfigBase::load: ConfigBase::load: Processing keybindings: broadcast_off
ConfigBase::load: ConfigBase::load: Processing keybindings: broadcast_group
ConfigBase::load: ConfigBase::load: Processing keybindings: broadcast_all
ConfigBase::load: ConfigBase::load: Processing keybindings: insert_number
ConfigBase::load: ConfigBase::load: Processing keybindings: insert_padded
ConfigBase::load: ConfigBase::load: Processing keybindings:
edit_window_title
ConfigBase::load: ConfigBase::load: Processing keybindings: edit_tab_title
ConfigBase::load: ConfigBase::load: Processing keybindings:
edit_terminal_title
ConfigBase::load: ConfigBase::load: Processing keybindings: layout_launcher
ConfigBase::load: ConfigBase::load: Processing keybindings: help
ConfigBase::load: ConfigBase::load: Processing section: profiles
ConfigBase::load: ConfigBase::load: Processing profile: default
ConfigBase::load: ConfigBase::load: Processing profile: Présentation
ConfigBase::load: ConfigBase::load: Processing section: layouts
ConfigBase::load: ConfigBase::load: Proces
Bug#917478: popularity-contest: Improve performance (4x faster)
On Sun, Jan 27, 2019 at 01:19:26PM +0100, Bill Allombert wrote:
> On Thu, Dec 27, 2018 at 11:19:45PM +0100, Benoît wrote:
> > Package: popularity-contest
> > Version: 1.67
> > Severity: minor
> > Tags: patch
> >
> > Dear Maintainer,
> >
> > For each installed packages, popcon globs the complete list of files
> > in /var/lib/dpkg/info.
> > This is very slow as I noticed that popcon takes more than a minute of CPU
> > time on my modest laptop, which is enough to start the fan.
> >
> > I'm attaching a patch that lists only once /var/lib/dpkg/info and associates
> > each .list file with a package.
> >
> > I don't see any difference in /usr/sbin/popularity-contest output.
> > And the CPU time goes from 1min08s to 0min14s.
>
> Hello Benoît,
>
> Thanks for your patch!
>
> I tried it and it output warnings for multiarch packages which have both
> a amd64.list and a i386.list like
>
> /var/lib/dpkg/info/gcc-4.8-base:amd64.list
> /var/lib/dpkg/info/gcc-4.8-base:i386.list
>
> I get:
> Use of uninitialized value $_ in open at ./popularity-contest line 146,
> line 285.
>
> Do you understand what happen ?
>
Not really.
But I can see that multiarch packages are processed several times.
And the part i don't understand is that processing one deletes it's files
list, hence the undef.
Adding a simple check solves this.
> Cheers,
> --
> Bill.
>
> Imagine a large red swirl here.
--
Benoît Dejean
--- /usr/sbin/popularity-contest 2018-08-09 20:41:19.0 +0200
+++ ./popularity-contest 2019-02-10 10:25:14.353413546 +0100
@@ -119,6 +119,19 @@
close DIVERSIONS;
}
+my %pkgs_files = ();
+
+if (opendir(my $DPKG_DB, $dpkg_db))
+{
+for my $e (readdir($DPKG_DB)) {
+ if ($e =~ m/^([^:]+) .*? \. list$/x) {
+ $pkgs_files{$1} ||= [];
+ push @{$pkgs_files{$1}}, "$dpkg_db/$e";
+ }
+}
+closedir($DPKG_DB);
+}
+
# Read dpkg database of installed packages
open PACKAGES, "dpkg-query --show --showformat='\${status} \${package}\\n'|";
while ()
@@ -127,8 +140,10 @@
my $pkg=$1;
my $bestatime = undef;
my $list;
+ # dpkg-query reports multiple times the same package for diff archs
+ next if $popcon{$pkg};
$popcon{$pkg}=[0,0,$pkg,""];
- foreach ("$dpkg_db/$pkg.list", glob("$dpkg_db/$pkg:*.list"))
+ foreach (@{$pkgs_files{$pkg}})
{
open FILES, $_ or next;
while ()
Bug#919081: kio-gdrive: Unable to create io-slave. klauncher said: error loading gdrive.so
Hi again ! Would you please confirm the following: a) Have you tried logging out and logging back in? No, I did not, and I should have: error is now gone. I am sorry for the trouble. Thanks a lot, Benoît
Bug#919081: kio-gdrive: Unable to create io-slave. klauncher said: error loading gdrive.so
Package: kio-gdrive Version: 1.2.5-1 Severity: grave Justification: renders package unusable Dear Maintainer, After installing kio-gdrive and configuring a Google account in systemsettings5, I cannot connect to my Google Drive: $ LANG=C kioclient5 exec gdrive:/ kf5.kio.core: couldn't create slave: "klauncher said: Error loading « /usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/gdrive.so »." kf5.kio.widgets: KRun(0xa1c13a10) ERROR 173 "Unable to create io-slave. klauncher said: Error loading « /usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/gdrive.so »." I am not sure how to further debug the problem, but as you can see the package is quite unusable. Best regards, Benoît -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-3-amd64 (SMP w/4 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 kio-gdrive depends on: ii kaccounts-integration 4:17.08.3-1 ii kio5.51.0-1 ii libaccounts-qt5-1 1.15-2 ii libc6 2.28-2 ii libkaccounts1 4:17.08.3-1 ii libkf5coreaddons5 5.51.0-1 ii libkf5i18n55.51.0-1 ii libkf5kiocore5 5.51.0-1 ii libkf5kiowidgets5 5.51.0-1 ii libkf5notifications5 5.51.0-1 ii libkpimgapicore5abi1 18.08.1-1 ii libkpimgapidrive5 18.08.1-1 ii libqt5core5a 5.11.3+dfsg-2 ii libqt5widgets5 5.11.3+dfsg-2 ii libstdc++6 8.2.0-13 kio-gdrive recommends no packages. kio-gdrive suggests no packages. -- no debconf information
Bug#917478: popularity-contest: Improve performance (4x faster)
Package: popularity-contest
Version: 1.67
Severity: minor
Tags: patch
Dear Maintainer,
For each installed packages, popcon globs the complete list of files
in /var/lib/dpkg/info.
This is very slow as I noticed that popcon takes more than a minute of CPU
time on my modest laptop, which is enough to start the fan.
I'm attaching a patch that lists only once /var/lib/dpkg/info and associates
each .list file with a package.
I don't see any difference in /usr/sbin/popularity-contest output.
And the CPU time goes from 1min08s to 0min14s.
-- System Information:
Debian Release: buster/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.17.0-3-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/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages popularity-contest depends on:
ii debconf [debconf-2.0] 1.5.69
ii dpkg 1.19.2
Versions of packages popularity-contest recommends:
ii cron [cron-daemon] 3.0pl1-130
ii exim4-daemon-light [mail-transport-agent] 4.91-8+b1
ii gnupg 2.2.10-3
Versions of packages popularity-contest suggests:
ii anacron 2.3-27
pn tor
pn torsocks
-- debconf-show failed
--- /usr/sbin/popularity-contest2018-08-09 20:41:19.0 +0200
+++ popularity-contest 2018-12-27 22:51:27.710362640 +0100
@@ -119,6 +119,19 @@
close DIVERSIONS;
}
+my %pkgs_files = ();
+
+if (opendir(my $DPKG_DB, $dpkg_db))
+{
+for my $e (readdir($DPKG_DB)) {
+ if ($e =~ m/^([^:]+) .*? \. list$/x) {
+ $pkgs_files{$1} ||= [];
+ push @{$pkgs_files{$1}}, "$dpkg_db/$e";
+ }
+}
+closedir($DPKG_DB);
+}
+
# Read dpkg database of installed packages
open PACKAGES, "dpkg-query --show --showformat='\${status} \${package}\\n'|";
while ()
@@ -128,7 +141,7 @@
my $bestatime = undef;
my $list;
$popcon{$pkg}=[0,0,$pkg,""];
- foreach ("$dpkg_db/$pkg.list", glob("$dpkg_db/$pkg:*.list"))
+ foreach (@{$pkgs_files{$pkg}})
{
open FILES, $_ or next;
while ()
Bug#896561: munin: plugin apt-all generates load of emails
>> when the apt-all plugin is loaded (what is automatic on Debian because of >> the package install script), then two cron lines in /etc/cron.d/munin-node >> >> */5 * * * *root if [ -x /etc/munin/plugins/apt_all ]; then >> /etc/munin/plugins/apt_all update 7200 12 >/dev/null; elif [ -x >> /etc/munin/plugins/apt ]; then /etc/munin/plugins/apt update 7200 12 >>> /dev/null; fi >> */10 * * * * root lslocks -o PATH | grep -e "^/var/lib/dpkg/lock$" >>> /dev/null || if [ -x /etc/munin/plugins/apt_all ]; then >> /etc/munin/plugins/apt_all update 7200 12 >/dev/null; elif [ -x >> /etc/munin/plugins/apt ]; then /etc/munin/plugins/apt update 7200 12 >>> /dev/null; fi > just for the matter of correctness: only the first of the two cron jobs above > is part of the Debian package. The second one is probably a local addition. > But this detail is not relevant for the topic of your report. Yes, I have tried to partly fix the bug on some hosts, but in these lines, I can't see any code I write; or I forgot about it. >> In particular, the plugin has a small design flaw: it only produces warnings >> when updates are available. It should also provide critical state when >> security updates are available !!! This would be very usefull !!! > Maybe you want to propose a set of changes upstream. I barely have time to report half bugs I find; no time to fix any of them. > > >> What I am wondering is: should be remove this plugin from automatic >> installation ? (keep the plugin in the repo, but do not automatically enable >> it during package install). [..] > Are you sure, that the apt_all plugin was enabled automatically on your host? Yes; I did not even specifically ask this plugin; just asked for munin, and all plugins. The plugin is installed by default in /etc. Maybe ... maybe I have set env variables to guide dpkg for non interactive installation; but those settings are mostly set for locales and keyboard; I don't remember setting anything for munin; here is the code I run now /usr/bin/apt-get --no-remove --yes install munin-node munin-plugins-extra and my debconf-set-selections <<< "[...]" section does not contain any line about munin. > The munin-node.postinst script runs the following: > > munin-node-configure --shell > > This uses only the "family" named "auto". > The "apt_all" plugin is part of the "manual" family. Thus it should not be > enabled without manual intervention. It is. Or was. I don't have the bug on all machines, because very few machines are set with exim; most of my machines don't have exim (or not configured). > Regarding the scope of this bug report: > I can understand, that you are not happy about receiving one email per hour of > downtime for each of your disconnected servers. But I am uncertain how this > effect of a failure could be avoided without adding a lot of complexity to the > cron job (or whatever mode of update). Regarding the fact it's impossible to run two apt-get un parallele, I never had this under Gentoo; this issue is specific to Debian. Other package managers are able to handle parallel execution. So, it's from the base, probably a bad idea to implement this cron task anyway. This type of thing would not be an issue on other distros. But on Debian ... it should be disables as soon as any user is logged in. To avoid the email error: - start by pinging/wget/curl the server before performing the apt thing (I know, people with web proxy will be in trouble): curl mirror >/dev/null && apt - disable output completely: >/dev/null 2>&1 - add a filter in exim - grep -v "[our error]" > A possible alternative to the current cron-based approach could be to let the > user apply an apt configuration settings manually: > > APT::Periodic::Update-Package-Lists "1"; > > This would cause a daily run of "apt update" via crond or a systemd timer. > (less frequent than now, but probably still acceptable) > > But this would require a manual configuration setting of the user, which is > admittedly hard to communicate along the usual flow of enabling a munin > plugin. > > What do you think? > Or maybe you have a different suggestion? > I have not read the complete Debian guidelines, and never understood the deep concepts of the Debian spirit. So I never understood the "Debian way of things". What I know is that, even I install packages manually, I may receive some notifications in ncurses or "more/less" messages, and I need to aknoledge them. In full non interactive setups, some package specific communications are sent to me by email, when exim is configured. They usually talk about m
Bug#915954: inteldrmfb: screen black in 4.18.0-3 (works in 4.18.0-2)
Hi, same issue here. Deterministic (always fails at boot with -3, and works with -2). below, kernel log of 4.18.0-2 and 4.18.0-3 (with something wrong in i915_request_alloc) kernel log of 4.18.0-2 (the WORKING one) follows: [0.00] Linux version 4.18.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 7.3.0 (Debian 7.3.0-30)) #1 SMP Debian 4.18.10-2 (2018-11-02) [0.00] Command line: BOOT_IMAGE=/vmlinuz-4.18.0-2-amd64 root=/dev/mapper/anthra-root ro [0.00] Disabled fast string operations [0.00] x86/fpu: x87 FPU will use FXSAVE [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009fbff] usable [0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e4000-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xaf78] usable [0.00] BIOS-e820: [mem 0xaf79-0xaf79dfff] ACPI data [0.00] BIOS-e820: [mem 0xaf79e000-0xaf7d] ACPI NVS [0.00] BIOS-e820: [mem 0xaf7e-0xaf7f] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xffb0-0x] reserved [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.4 present. [0.00] DMI: System manufacturer System Product Name/P5B-VM, BIOS 0901 07/03/2007 [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] last_pfn = 0xaf790 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-D uncachable [0.00] E-E write-through [0.00] F-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 0BC00 mask FFC00 uncachable [0.00] 1 base 0C000 mask FC000 uncachable [0.00] 2 base 0 mask F write-back [0.00] 3 base 1 mask F8000 write-back [0.00] 4 base 0AF80 mask FFF80 uncachable [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT [0.00] e820: update [mem 0xaf80-0xafff] usable ==> reserved [0.00] e820: update [mem 0xbc00-0x] usable ==> reserved [0.00] found SMP MP-table at [mem 0x000ff780-0x000ff78f] mapped at [(ptrval)] [0.00] Base memory trampoline at [(ptrval)] 99000 size 24576 [0.00] BRK [0x5344b000, 0x5344bfff] PGTABLE [0.00] BRK [0x5344c000, 0x5344cfff] PGTABLE [0.00] BRK [0x5344d000, 0x5344dfff] PGTABLE [0.00] BRK [0x5344e000, 0x5344efff] PGTABLE [0.00] BRK [0x5344f000, 0x5344] PGTABLE [0.00] BRK [0x5345, 0x53450fff] PGTABLE [0.00] RAMDISK: [mem 0x34e27000-0x3670afff] [0.00] ACPI: Early table checksum verification disabled [0.00] ACPI: RSDP 0x000FA950 24 (v02 ACPIAM) [0.00] ACPI: XSDT 0xAF790100 54 (v01 MSTEST OEMXSDT 07000703 MSFT 0097) [0.00] ACPI: FACP 0xAF790290 F4 (v03 MSTEST OEMFACP 07000703 MSFT 0097) [0.00] ACPI: DSDT 0xAF7905C0 007C09 (v01 A0518 A0518000 INTL 20060113) [0.00] ACPI: FACS 0xAF79E000 40 [0.00] ACPI: FACS 0xAF79E000 40 [0.00] ACPI: APIC 0xAF790390 6C (v01 MSTEST OEMAPIC 07000703 MSFT 0097) [0.00] ACPI: MCFG 0xAF790400 3C (v01 MSTEST OEMMCFG 07000703 MSFT 0097) [0.00] ACPI: OEMB 0xAF79E040 7B (v01 MSTEST AMI_OEM 07000703 MSFT 0097) [0.00] ACPI: HPET 0xAF7981D0 38 (v01 MSTEST OEMHPET 07000703 MSFT 0097) [0.00] ACPI: GSCI 0xAF79E0C0 002024 (v01 MSTEST GMCHSCI 07000703 MSFT 0097) [0.00] ACPI: Local APIC address 0xfee0 [0.00] No NUMA configuration found [0.00] Faking a node at [mem 0x-0xaf78] [0.00] NODE_DATA(0) allocated [mem 0xaf78b000-0xaf78] [0.00] tsc: Fast TSC calibration using PIT [0.00] Zone ranges: [0.00] DMA [mem 0x1000-0x00ff] [0.00] DMA32[mem 0x0100-0xaf78] [0.00] Normal empty [0.00] Device empty [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x1000-0x0009efff] [0.00] node 0: [mem 0x0010-0xaf78] [0.00] Reserved but unavailable: 2258 pages [0.00] Initm
Bug#13389: another possibility (HPN SSH patches)
Hi,
Please find an attacher patch to get the none cipher for transport layer as
asked here. It works for openssh 7.9.
diff openssh-portable-master/cipher.c openssh-portable-master-moi/cipher.c
125c125
< if ((c->flags & CFLAG_INTERNAL) != 0)
---
> if ((c->flags & CFLAG_INTERNAL) != 0 && (c->flags & CFLAG_NONE)
> == 0)
217c217
< if (c == NULL || (c->flags & CFLAG_INTERNAL) != 0) {
---
> if (c == NULL || ((c->flags & CFLAG_INTERNAL) != 0 && (c->flags
> & CFLAG_NONE) == 0)) {
Regards,
Benoit
Bug#906140: arduino-mk: not compatible with ccache
Package: arduino-mk Version: 1.5.2-1 Severity: wishlist Dear Maintainer, /usr/share/arduino/Arduino.mk is not compatible with ccache. When compiling, we can see that the compiler is called with a complete path: /usr/share/arduino/hardware/tools/avr/bin/avr-g++ It would be nice if it could use the short name instead (if it's the same compiler) so that ccache could kick in. $ /usr/lib/ccache/avr-g++ --version avr-g++ (GCC) 5.4.0 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ /usr/share/arduino/hardware/tools/avr/bin/avr-g++ --version avr-g++ (GCC) 5.4.0 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.16.0-2-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/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages arduino-mk depends on: ii arduino-core 2:1.0.5+dfsg2-4.1 ii make 4.2.1-1.2 ii python 2.7.15-3 ii python-serial 3.4-4 Versions of packages arduino-mk recommends: ii screen 4.6.2-3 arduino-mk suggests no packages. -- debconf-show failed
Bug#905026: emacs: broken version
On Mon, Jul 30, 2018 at 11:49:09PM +0100, Colin Watson wrote: > On Mon, Jul 30, 2018 at 08:52:18PM +0200, Benoît wrote: > > Source: emacs > > Severity: normal > > > > Dear Maintainer, > > > > the move to version-free breaks many packages. > > Maybe this is because 1:25.2+1-8 < 47.0. > > But 1:25.2+1-8 is in fact > 47.0, by the standard Debian version > comparison algorithm: > > $ dpkg --compare-versions 1:25.2+1-8 gt 47.0 && echo yes > yes > > So I think you need to go into quite a lot more detail about exactly > what is failing ... Hello Colin, I'm not sure what happened, upgrading emacs actually removed emacs25 and half a dozen emacs elpa-* packages. Or more likely i made a mistake in aptitude. Sorry for wasting your time. Thanks. -- Benoît Dejean
Bug#905026: emacs: broken version
Source: emacs Severity: normal Dear Maintainer, the move to version-free breaks many packages. Maybe this is because 1:25.2+1-8 < 47.0. Would you consider using a different version scheme so that all deps recognise 1:25.2+1-8 being superior to 47.0 ? -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.16.0-2-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/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#903767: 4.9.110-1 Xen PV boot workaround
Hi Michael, Sorry for my mistake. Indeed, whith extra = 'elevator=noop pti=off' All xen guests boot without a problem. Thanks a lot for your help. Benoît Le mar. 17 juil. 2018 à 01:20, Michael J. Redd a écrit : > I've tested the workaround successfully. Added `pti=off` to my kernel's > boot arguments, updated GRUB, and it started as intended. > > Benoît, > > Just to be sure, since you're loading your guests' kernels directly > like that, you're passing pti=off via the `extra` config line in your > domU config files, right? I.e. > > extra = 'elevator=noop pti=off' > > > > On Tue, 2018-07-17 at 00:39 +0200, Benoît Tonnerre wrote: > > Hi, > > > > I tested this workaround : I confirm that it works on Xen host, but > > not on Xen guest. > > If you try to start a vm with latest kernel i.e. theses parameters in > > cfg file : > > > > # > > # Kernel + memory size > > # > > kernel = '/boot/vmlinuz-4.9.0-7-amd64' > > extra = 'elevator=noop' > > ramdisk = '/boot/initrd.img-4.9.0-7-amd64' > > > >
Bug#903767: 4.9.110-1 Xen PV boot workaround
c1 07 00 00 4c 89 e7 eb 11 e8 [0.124009] RIP [] ret_from_fork+0x2d/0x70 [0.124009] RSP [0.124009] ---[ end trace e2ff95a7e079b5b5 ]--- Did I miss something ? Thanks for your help. Best regards. Benoît Le lun. 16 juil. 2018 à 19:28, Hans van Kranenburg a écrit : > Reportedly, adding pti=off to the kernel boot parameters will work > around the issue for now. > > Turning off pti in the guest kernel is done in any case for PV. The > issue between 4.9.107 and 4.9.111 affects the detection and turning off > of pti, that's why forcing it off helps. > > In 4.9.112 it's fixed in commit 1adc34adc3447c34926994b87db5d929f5ab45b5 > "x86/cpu: Re-apply forced caps every time CPU caps are re-read" > > Hans >
Bug#903821: Re : xen-hypervisor-4.8-amd64: Kernel Panic after upgrading to stretch 9.5 (linux-image-4.9.0-7-amd64)
Hi, If you prefer, you can find a kernel panic screenshot from R720 Dell server's : https://s33.postimg.cc/b2t056y8f/S_lection_027.png Best regards Benoît
Bug#903821: xen-hypervisor-4.8-amd64: Kernel Panic after upgrading to stretch 9.5 (linux-image-4.9.0-7-amd64)
Package: xen-hypervisor-4.8-amd64 Version: 4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u9 Severity: critical Justification: breaks the whole system Dear Maintainer, After updating 3 Xen servers from stretch (9.4) to stretch (9.5), I notice a kernel panic on these 3 servers. If I boot xen hypervisor with advanced option in grub menu, and If i select linux-image-4.9.0-6-amd64 kernel, everything work. The 3 servers are from Dell : - 1 PowerEdge R720 - 2 PowerEdge R430 You can find the message displayed on IDRAC console when booting with 4.9.0-7-amd64 : Call Trace: Code: c7 e8 b8 fe a8 ff 48 85 db 75 2f 48 89 e7 e8 5b ed 9e ff 50 90 0f 20 d8 65 48 0b 04 25 e0 02 01 00 78 08 65 88 04 25 e7 02 01 00 <0f> 22 d8 58 66 90 66 66 90 e9 c1 07 00 00 4c 89 e7 eb 11 e8 RIP [] ret_form_fork+0x2d/0x70 RSP ---[ end trace 28169cf87e381c4e ]--- Kernel panci - not syncing: Attempted to kill init! exicode=0x000b Kernel Offset: disabled After this, the servers reboot in loop. If you need any others informations, please let me know. Best regards. Benoît -- System Information: Debian Release: 9.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-6-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) xen-hypervisor-4.8-amd64 depends on no packages. Versions of packages xen-hypervisor-4.8-amd64 recommends: ii xen-utils-4.8 4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u9 xen-hypervisor-4.8-amd64 suggests no packages. -- Configuration Files: /etc/default/grub.d/xen.cfg changed: XEN_OVERRIDE_GRUB_DEFAULT=1 echo "Including Xen overrides from /etc/default/grub.d/xen.cfg" GRUB_CMDLINE_XEN_DEFAULT="dom0_mem=2G,max:2G dom0_max_vcpus=2 dom0_vcpus_pin" if [ "$XEN_OVERRIDE_GRUB_DEFAULT" = "" ]; then echo "WARNING: GRUB_DEFAULT changed to boot into Xen by default!" echo " Edit /etc/default/grub.d/xen.cfg to avoid this warning." XEN_OVERRIDE_GRUB_DEFAULT=1 fi if [ "$XEN_OVERRIDE_GRUB_DEFAULT" = "1" ]; then GRUB_DEFAULT="Debian GNU/Linux, with Xen hypervisor" fi -- no debconf information
Bug#897451: pandoc: beamer output no longer works
On Wed, May 02, 2018 at 03:56:58PM -0700, John MacFarlane wrote:
>
> It may be that the default beamer template now includes a package
> that already loads geometry.
>
> See
> https://tex.stackexchange.com/questions/266995/latex-error-option-clash-for-package-geometry
>
> If so, you should be able to work around this by doing this instead:
>
> header-includes:
> - '\geometry{margin=1in}'
>
Good catch, thank you.
I think can simply drop the geometry for beamer output.
That problem is not linked with pandoc because reverting to the 1.19 still
gives the same issue. So it's more likely linked with one of the texlive
packages.
And I have another one:
Error producing PDF.
! Undefined control sequence.
\@@magyar@captionfix
l.145 \begin{document}
for which I've found
https://tex.stackexchange.com/questions/426088/texlive-pretest-2018-beamer-and-subfig-collide
Thank you for your help, please close this bug.
>
> Benoît writes:
>
> > Package: pandoc
> > Version: 2.2-1
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > Rendering into beamer no longer works (was ok this since 1.7):
> >
> >
> > ---
> > author: Benoît
> > institution: ABC
> > title: ABC D
> > date: 2018
> > theme: Hannover
> > toc: true
> > papersize: a4
> > geometry: margin=1.5cm
> > pagenumbering: true
> > ---
> >
> >
> > # Hello
> > Hello
> >
> >
> >
> > $ pandoc --slide-level 2 -t beamer a.md -o a.pdf
> > Error producing PDF.
> > ! LaTeX Error: Option clash for package geometry.
> >
> > See the LaTeX manual or LaTeX Companion for explanation.
> > Type H for immediate help.
> > ...
> >
> > l.44 \newif
> >
> >
> > -- System Information:
> > Debian Release: buster/sid
> > APT prefers unstable-debug
> > APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1,
> > 'experimental-debug'), (1, 'experimental')
> > Architecture: amd64 (x86_64)
> > Foreign Architectures: i386
> >
> > Kernel: Linux 4.15.0-1-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/bash
> > Init: systemd (via /run/systemd/system)
> > LSM: AppArmor: enabled
> >
> > Versions of packages pandoc depends on:
> > ii libc62.27-3
> > ii libffi6 3.2.1-8
> > ii libgmp10 2:6.1.2+dfsg-3
> > ii liblua5.1-0 5.1.5-8.1+b2
> > ii libpcre3 2:8.39-9
> > ii libyaml-0-2 0.1.7-2
> > ii pandoc-data 2.2-1
> > ii zlib1g 1:1.2.11.dfsg-1
> >
> > pandoc recommends no packages.
> >
> > Versions of packages pandoc suggests:
> > pn context
> > pn ghc
> > ii groff 1.22.3-10
> > ii librsvg2-bin 2.40.20-2
> > ii nodejs 8.9.3~dfsg-12
> > pn pandoc-citeproc
> > ii perl 5.26.2-2
> > pn php
> > ii python 2.7.15~rc1-1
> > ii r-base-core3.4.4-1
> > ii ruby 1:2.5.1
> > ii texlive-latex-extra2018.20180416-1
> > ii texlive-latex-recommended 2018.20180416-1
> > pn texlive-luatex
> > pn texlive-xetex
> > ii wkhtmltopdf0.12.4-1
> >
> > -- debconf-show failed
--
Benoît Dejean
Bug#897451: pandoc: beamer output no longer works
Package: pandoc Version: 2.2-1 Severity: normal Dear Maintainer, Rendering into beamer no longer works (was ok this since 1.7): --- author: Benoît institution: ABC title: ABC D date: 2018 theme: Hannover toc: true papersize: a4 geometry: margin=1.5cm pagenumbering: true --- # Hello Hello $ pandoc --slide-level 2 -t beamer a.md -o a.pdf Error producing PDF. ! LaTeX Error: Option clash for package geometry. See the LaTeX manual or LaTeX Companion for explanation. Type H for immediate help. ... l.44 \newif -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-1-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/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pandoc depends on: ii libc62.27-3 ii libffi6 3.2.1-8 ii libgmp10 2:6.1.2+dfsg-3 ii liblua5.1-0 5.1.5-8.1+b2 ii libpcre3 2:8.39-9 ii libyaml-0-2 0.1.7-2 ii pandoc-data 2.2-1 ii zlib1g 1:1.2.11.dfsg-1 pandoc recommends no packages. Versions of packages pandoc suggests: pn context pn ghc ii groff 1.22.3-10 ii librsvg2-bin 2.40.20-2 ii nodejs 8.9.3~dfsg-12 pn pandoc-citeproc ii perl 5.26.2-2 pn php ii python 2.7.15~rc1-1 ii r-base-core3.4.4-1 ii ruby 1:2.5.1 ii texlive-latex-extra2018.20180416-1 ii texlive-latex-recommended 2018.20180416-1 pn texlive-luatex pn texlive-xetex ii wkhtmltopdf0.12.4-1 -- debconf-show failed
Bug#896179: qspeakers FTBFS with Qt 5.10
Hello Georges, Great, thank you. Does the bug closes automagically thanks to changelog ? or is there an action i should do for closing it now ? P.S: i created ben-guest account on salsa.d.o can you add me as a member of qspeakers project ? Thank you for having uploaded to Debian so quickly. Benoît Le 22/04/2018 à 15:53, Georges Khaznadar a écrit : > Hello Benoît, > > I am making a few modifications : the VCS repository is changed to > https://salsa.debian.org/georgesk/qspeakers.git, in order to fix the > current error reported about it: > > Last scan: 2018-04-22 02:10:10+00 > Error: debian/changelog missing in > svn://svn.gtmp.org/qspeakers/branches/qtcharts/ > > I shall upload the package shortly. > Please create a guest account at https://signup.salsa.debian.org/, so > you can maintain the package there. Please use git branches and tags > consistently: there should be at least two branches, "master" and > "upstream", which are supposed to differ only by the debian/ > subdirectory in the "master" branch. Currently, tags are: > > debian/1.2.0-1 > upstream/1.2.0 > > New tags should use such a naming scheme. > > Best regards, Georges. > > > Benoît Rouits a écrit : >> Thank you for your report, >> >> This has been just fixed upstream, thanks to you. >> The package is waiting to be uploaded by my mentor. >> >> https://mentors.debian.net/package/qspeakers >> >> Benoît >> Le 20/04/2018 à 16:17, Adrian Bunk a écrit : >>> Source: qspeakers >>> Version: 1.1.0-1 >>> Severity: serious >>> Tags: buster sid >>> >>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/qspeakers.html >>> >>> ... >>> g++ -Wl,-z,relro -o qspeakers main.o mainwindow.o speakerdialog.o >>> speakerdb.o speaker.o importexport.o box.o sealedbox.o portedbox.o >>> bandpassbox.o plot.o listdialog.o searchdialog.o system.o moc_mainwindow.o >>> moc_speakerdialog.o moc_plot.o moc_listdialog.o moc_searchdialog.o >>> -lQt5PrintSupport -lQt5Widgets -lQt5Gui -lQt5Xml -lQt5Core -lGL -lpthread >>> plot.o: In function `Plot::~Plot()': >>> qspeakers_1.1.0-1/plot.cpp:34: undefined reference to >>> `QtCharts::QXYSeries::clear()' >>> plot.o: In function `Plot::initializeCurve()': >>> qspeakers_1.1.0-1/plot.cpp:67: undefined reference to >>> `QtCharts::QLineSeries::QLineSeries(QObject*)' >>> qspeakers_1.1.0-1/plot.cpp:68: undefined reference to >>> `QtCharts::QAbstractSeries::setUseOpenGL(bool)' >>> ... >>> >>> >>> Due to the following in qspeakers.pro: >>> greaterThan(QT_VERSION, 5.8): QT += charts >>> >>> This is interpreted as float, so 5.10 < 5.8 >>> > signature.asc Description: OpenPGP digital signature
Bug#896561: munin: plugin apt-all generates load of emails
Package: munin Version: 2.0.33-1 Severity: minor Dear Maintainer, when the apt-all plugin is loaded (what is automatic on Debian because of the package install script), then two cron lines in /etc/cron.d/munin-node */5 * * * *root if [ -x /etc/munin/plugins/apt_all ]; then /etc/munin/plugins/apt_all update 7200 12 >/dev/null; elif [ -x /etc/munin/plugins/apt ]; then /etc/munin/plugins/apt update 7200 12 >/dev/null; fi */10 * * * * root lslocks -o PATH | grep -e "^/var/lib/dpkg/lock$" >/dev/null || if [ -x /etc/munin/plugins/apt_all ]; then /etc/munin/plugins/apt_all update 7200 12 >/dev/null; elif [ -x /etc/munin/plugins/apt ]; then /etc/munin/plugins/apt update 7200 12 >/dev/null; fi They generate garbage email in two cases: when root is already runnin an installation or system update or when computer is offline. They have a third side effect: if user tries to start installing a package just after those lines started to run, then, root will receive the error message "lock already locked by an other process", what is a missleading message. The very first time I got this message, I checked all my consoles: "in which console am I already running apt ?" then, after founding none "am I being hacked ?". And when I restarted the same command, it worked => "why does it work now ? I did nothing to release the lock". And this may be very missleading for an experienced debian admin who is just starting to learn about munin. The case I had this weekend: a production server was offline because of a faulty cable. The server is a gateway for a full room of machines. Every single machine generated one email per hour, for two days ... those machines are designed to send only one message per week; so getting one message per hour blew up the SMTP. Here is a typical error email: W: Failed to fetch http://ftp.fr.debian.org/debian/dists/stretch/InRelease Temporary failure resolving 'ftp.fr.debian.org' W: Failed to fetch http://security.debian.org/dists/stretch/updates/InRelease Temporary failure resolving 'security.debian.org' W: Failed to fetch http://ftp.fr.debian.org/debian/dists/stretch-updates/InRelease Temporary failure resolving 'ftp.fr.debian.org' W: Failed to fetch http://www.ubnt.com/downloads/unifi/debian/dists/unifi5/InRelease Temporary failure resolving 'www.ubnt.com' W: Some index files failed to download. They have been ignored, or old ones used instead. 1: installation of package should inform admin about the fact these two cron lines may lock apt a few seconds per hour. 2: you need to find a way to EASILY let admin customise if he want to run those lines, or use an alternate way to update apt (I have seen some propositions in other bugs) 3: create a conf file that will let admin choose - if those lines should be completely silent (add 2>/dev/null) - at which frequency they should be run 4: ideally I would like those commands to not lock apt; but I know it's not possible in Debian. Gentoo is designed to minimise the time laps when the locks are created, and allows parallel execution of installation procedures. Debian locks every thing all the time; and this bug is not asking to change this behaviour. But this bug need to workaround the fact a random cron task may randomly prevent admin from working, or may randomly prevent correct execution of admin scripts/interfaces. An old working debian may suddenly break just after installing munin. The apt-all plugin may be interesting and helpfull; but that cron bit is toxic for me. In particular, the plugin has a small design flaw: it only produces warnings when updates are available. It should also provide critical state when security updates are available !!! This would be very usefull !!! While I am suggesting the creation of a conf file for apt-all and it's cron file, a conf file for this plugin would also help fixing several other bugs pending; like the one or two bugs about Debian Version. There are good ideas in this plugin; but poorly implemented. What I am wondering is: should be remove this plugin from automatic installation ? (keep the plugin in the repo, but do not automatically enable it during package install). I thinck it should be removed from automatic installation before we make it cleaner, more user friendly, and remove it's side effects. Or at the very least, rapidly add a warning during installation, or a curses pop-up question. -- System Information: Debian Release: 9.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores) 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: systemd (via /run/systemd/system) Versions of packages munin depends on: ii cron [cron-daemon]3.0pl1-128+deb9u1 ii fonts-dejavu-core 2.37-1 ii libdate-manip-perl6.57-1 pn libdi
Bug#896179: qspeakers FTBFS with Qt 5.10
Thank you for your report, This has been just fixed upstream, thanks to you. The package is waiting to be uploaded by my mentor. https://mentors.debian.net/package/qspeakers Benoît Le 20/04/2018 à 16:17, Adrian Bunk a écrit : > Source: qspeakers > Version: 1.1.0-1 > Severity: serious > Tags: buster sid > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/qspeakers.html > > ... > g++ -Wl,-z,relro -o qspeakers main.o mainwindow.o speakerdialog.o speakerdb.o > speaker.o importexport.o box.o sealedbox.o portedbox.o bandpassbox.o plot.o > listdialog.o searchdialog.o system.o moc_mainwindow.o moc_speakerdialog.o > moc_plot.o moc_listdialog.o moc_searchdialog.o -lQt5PrintSupport > -lQt5Widgets -lQt5Gui -lQt5Xml -lQt5Core -lGL -lpthread > plot.o: In function `Plot::~Plot()': > qspeakers_1.1.0-1/plot.cpp:34: undefined reference to > `QtCharts::QXYSeries::clear()' > plot.o: In function `Plot::initializeCurve()': > qspeakers_1.1.0-1/plot.cpp:67: undefined reference to > `QtCharts::QLineSeries::QLineSeries(QObject*)' > qspeakers_1.1.0-1/plot.cpp:68: undefined reference to > `QtCharts::QAbstractSeries::setUseOpenGL(bool)' > ... > > > Due to the following in qspeakers.pro: > greaterThan(QT_VERSION, 5.8): QT += charts > > This is interpreted as float, so 5.10 < 5.8 >
Bug#893234: fancontrol: pwmconfig produces a /etc/fancontrol which does not please fancontrol.service
Package: fancontrol Version: 1:3.4.0-4 Severity: minor http://forums.debian.net/viewtopic.php?f=10&t=136952&p=669344#p669344 After a large system update ... |# systemctl restart fancontrol.service Job for fancontrol.service failed because the control process exited with error code. See "systemctl status fancontrol.service" and "journalctl -xe" for details. # systemctl status fancontrol.service -l â fancontrol.service - fan speed regulator Loaded: loaded (/lib/systemd/system/fancontrol.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Sat 2018-03-17 12:15:49 CET; 3s ago Docs: man:fancontrol(8) man:pwmconfig(8) Process: 27786 ExecStartPre=/usr/sbin/fancontrol --check (code=exited, status=1/FAILURE) Mar 17 12:15:49 leon-host systemd[1]: Starting fan speed regulator... Mar 17 12:15:49 leon-host fancontrol[27786]: Loading configuration from /etc/fancontrol ... Mar 17 12:15:49 leon-host fancontrol[27786]: Some mandatory settings missing, please check your config file! Mar 17 12:15:49 leon-host systemd[1]: fancontrol.service: Control process exited, code=exited status=1 Mar 17 12:15:49 leon-host systemd[1]: Failed to start fan speed regulator. Mar 17 12:15:49 leon-host systemd[1]: fancontrol.service: Unit entered failed state. Mar 17 12:15:49 leon-host systemd[1]: fancontrol.service: Failed with result 'exit-code'. I have rerun |||pwmconfig, it regenerated a new |/etc/fancontrol , but it was not working better. So, ||pwmconfig generates config files which are not acceptable for the fancontrol.service . Obviously, either fancontrol.service is asking more than before, but ||pwmconfig was not updated to follow, or, |pwmconfig has a regression bug. The config file I had in the past year, working fine before update: || |||# Configuration file generated by pwmconfig, changes will be lost INTERVAL=300 DEVPATH=hwmon2=devices/platform/nct6775.656 DEVNAME=hwmon2=nct6776 FCTEMPS= FCFANS=hwmon2/pwm2=hwmon2/fan2_input hwmon2/pwm1=hwmon2/fan1_input MINTEMP= MAXTEMP= MINSTART= MINSTOP= The config file I am using now to get service accept to start: ||| # Configuration file generated by pwmconfig, changes will be lost INTERVAL=10 DEVPATH=hwmon2=devices/platform/nct6775.656 DEVNAME=hwmon2=nct6776 FCTEMPS=hwmon2/pwm1=hwmon1/device/temp1_input hwmon2/pwm2=hwmon1/device/temp1_input FCFANS=hwmon2/pwm2=hwmon2/fan2_input hwmon2/pwm1=hwmon2/fan1_input MINTEMP=hwmon2/pwm1=20 MAXTEMP=hwmon2/pwm1=30 MINSTART=hwmon2/pwm1=140 MINSTOP=hwmon2/pwm1=100 WARNING: these values are random, only to satisfy the syntax of the service; the above values are not customised to be efficient, or bring a good service to the user; they are ONLY piccked up to let the systemctl service start correctly. They will need customisation. More logs are given in the above forum link. -- System Information: Debian Release: 9.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores) 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: systemd (via /run/systemd/system) Versions of packages fancontrol depends on: ii init-system-helpers 1.48 ii lsb-base 9.20161125 fancontrol recommends no packages. fancontrol suggests no packages. -- no debconf information -- >o_/ DEMAINE Benoît-Pierre (aka DoubleHP) http://benoit.demaine.info/ If computing were an exact science, IT engineers would'nt have work \_o< "So all that's left, Is the proof that love's not only blind but deaf." (FAKE TALES OF SAN FRANCISCO, Arctic Monkeys)
Bug#893232: fancontrol: fancontrol.service error message is not helping
Package: fancontrol Version: 1:3.4.0-4 Severity: minor http://forums.debian.net/viewtopic.php?f=10&t=136952&p=669344#p669344 After a large system update ... |# systemctl restart fancontrol.service Job for fancontrol.service failed because the control process exited with error code. See "systemctl status fancontrol.service" and "journalctl -xe" for details. # systemctl status fancontrol.service -l â fancontrol.service - fan speed regulator Loaded: loaded (/lib/systemd/system/fancontrol.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Sat 2018-03-17 12:15:49 CET; 3s ago Docs: man:fancontrol(8) man:pwmconfig(8) Process: 27786 ExecStartPre=/usr/sbin/fancontrol --check (code=exited, status=1/FAILURE) Mar 17 12:15:49 leon-host systemd[1]: Starting fan speed regulator... Mar 17 12:15:49 leon-host fancontrol[27786]: Loading configuration from /etc/fancontrol ... Mar 17 12:15:49 leon-host fancontrol[27786]: Some mandatory settings missing, please check your config file! Mar 17 12:15:49 leon-host systemd[1]: fancontrol.service: Control process exited, code=exited status=1 Mar 17 12:15:49 leon-host systemd[1]: Failed to start fan speed regulator. Mar 17 12:15:49 leon-host systemd[1]: fancontrol.service: Unit entered failed state. Mar 17 12:15:49 leon-host systemd[1]: fancontrol.service: Failed with result 'exit-code'. telling exactly which "|||mandatory settings" would be very helpfull| !!! At least which variable, and, recommend in which conf file it should be set. |-- System Information: Debian Release: 9.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores) 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: systemd (via /run/systemd/system) Versions of packages fancontrol depends on: ii init-system-helpers 1.48 ii lsb-base 9.20161125 fancontrol recommends no packages. fancontrol suggests no packages. -- no debconf information -- >o_/ DEMAINE Benoît-Pierre (aka DoubleHP) http://benoit.demaine.info/ If computing were an exact science, IT engineers would'nt have work \_o< "So all that's left, Is the proof that love's not only blind but deaf." (FAKE TALES OF SAN FRANCISCO, Arctic Monkeys)
Bug#570529: dup of #552196 ?
This bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570529 looks to me to be dup of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=552196 -- >o_/ DEMAINE Benoît-Pierre (aka DoubleHP) http://benoit.demaine.info/ If computing were an exact science, IT engineers would'nt have work \_o< "So all that's left, Is the proof that love's not only blind but deaf." (FAKE TALES OF SAN FRANCISCO, Arctic Monkeys)
Bug#892028: unattended-upgrades: too slow to be unattended
Package: unattended-upgrades
Version: 1.0
Severity: important
Dear Maintainer,
on my modest laptop, I can definitely tell when unattended-upgrades is
running every morning because it causes my CPU's fan to go full speed
for at least an hour.
$ time unattended-upgrade --download-only
real15m40,254s
user14m35,468s
sys 0m50,685s
This seems unreasonable.
I'm attaching a cProfile output of the same command.
(Took 52min to run).
apt.systemd.daily calls it twice:
root 14038 13985 99 10:34 pts/400:15:35
/usr/bin/python3 /usr/bin/unattended-upgrade --download-only
root 14538 13985 99 10:50 pts/400:50:50
/usr/bin/python3 /usr/bin/unattended-upgrade
Yes, that's 65 minutes of full CPU time.
For the record, aptitude full-upgrade gives me a plan in 11 seconds.
-- System Information:
Debian Release: buster/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.14.0-3-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/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages unattended-upgrades depends on:
ii debconf 1.5.63
ii lsb-base 9.20170808
ii lsb-release 9.20170808
ii python3 3.6.4-1
ii python3-apt 1.4.0~beta3+b1
ii ucf 3.0036
ii xz-utils 5.2.2-1.3
Versions of packages unattended-upgrades recommends:
ii anacron 2.3-24
ii cron [cron-daemon] 3.0pl1-128.1
Versions of packages unattended-upgrades suggests:
ii bsd-mailx 8.1.2-0.20160123cvs-4
ii exim4-daemon-light [mail-transport-agent] 4.90.1-1
pn needrestart
-- Configuration Files:
/etc/apt/apt.conf.d/50unattended-upgrades changed:
// Unattended-Upgrade::Origins-Pattern controls which packages are
// upgraded.
//
// Lines below have the format format is "keyword=value,...". A
// package will be upgraded only if the values in its metadata match
// all the supplied keywords in a line. (In other words, omitted
// keywords are wild cards.) The keywords originate from the Release
// file, but several aliases are accepted. The accepted keywords are:
// a,archive,suite (eg, "stable")
// c,component (eg, "main", "contrib", "non-free")
// l,label (eg, "Debian", "Debian-Security")
// o,origin(eg, "Debian", "Unofficial Multimedia Packages")
// n,codename (eg, "jessie", "jessie-updates")
// site (eg, "http.debian.net")
// The available values on the system are printed by the command
// "apt-cache policy", and can be debugged by running
// "unattended-upgrades -d" and looking at the log file.
//
// Within lines unattended-upgrades allows 2 macros whose values are
// derived from /etc/debian_version:
// ${distro_id}Installed origin.
// ${distro_codename} Installed codename (eg, "buster")
Unattended-Upgrade::Origins-Pattern {
// Codename based matching:
// This will follow the migration of a release through different
// archives (e.g. from testing to stable and later oldstable).
// Software will be the latest available for the named release,
// but the Debian release itself will not be automatically upgraded.
// "origin=Debian,codename=${distro_codename}-updates";
// "origin=Debian,codename=${distro_codename}-proposed-updates";
"origin=Debian,codename=${distro_codename},label=Debian";
"origin=Debian,codename=${distro_codename},label=Debian-Security";
// Archive or Suite based matching:
// Note that this will silently match a different release after
// migration to the specified archive (e.g. testing becomes the
// new stable).
// "o=Debian,a=stable";
// "o=Debian,a=stable-updates";
// "o=Debian,a=proposed-updates";
// "o=Debian Backports,a=${distro_codename}-backports,l=Debian Backports";
};
// List of packages to not update (regexp are supported)
Unattended-Upgrade::Package-Blacklist {
// "vim";
// "libc6";
// "libc6-dev";
// "libc6-i686";
};
// This option allows you to control if on a unclean dpkg exit
// unattended-upgrades will automatically run
// dpkg --force-confold --configure -a
// The default is true, to ensure updates keep getting installed
//Unattended-Upgrade::AutoFixInterruptedDpkg "false";
// Split the upgrade into the smallest possible chunks so that
// they can be interrupted with SIGTERM. This makes the upgrade
// a bit slower but it has the benefit that shutdown while a upgrade
// is running is possible (with a small delay)
//Unattended-Upgrade::MinimalSteps "false";
// Install all unattended-upgrades when the machine is shutting down
// instead of doing it in the backgrou
Bug#888843: jackd2: jackd --version returns with non zero exit status
Package: jackd2 Version: 1.9.10+20150825git1ed50c92~dfsg-5 Severity: minor Tags: upstream Dear Maintainer, jackd --version returns with exit status 255. This may break some configure scripts.
Bug#887846: libffado: new upstream release, qt5 and python3 support
Source: libffado Version: 2.3.0-5 Severity: wishlist Dear Maintainer, A new upstram version is available; it supports Qt5 and Python3. I am working on it. It currently compiles, but is not tested yet. WIP: updating and checking the copyright file requires some work.
Bug#885858: Missing Turtle files
Package: lv2-dev Version: 1.14.0~dfsg1-1 The lv2-dev package is missing a pair of Turtle files from the original source code. The missing files are: lv2/lv2plug.in/ns/meta/manifest.ttl lv2/lv2plug.in/ns/meta/meta.ttl Because these files are missing, it is impossible to run sord_validate as recommended per [1] on a LV2 manifest, including LV2's own examples, without actually downloading the package's source code Here is the summary of the output using the files from the lv2-dev package: $ sord_validate $( find /usr/lib/lv2/ -name '*.ttl' | grep -v /eg- ) /usr/lib/lv2/eg-amp.lv2/manifest.ttl 2>&1 | tail -n 1 Found 39 errors among 82 files (checked 0 restrictions) And the same, using the files from the source package: $ sord_validate $( find /tmp/lv2-1.14*/ -name '*.ttl' | grep -v /plugins/ ) /usr/lib/lv2/eg-amp.lv2/manifest.ttl 2>&1 | tail -n 1 Found 0 errors among 84 files (checked 0 restrictions) [1] http://lv2plug.in/pages/validating-lv2-data.html
Bug#884624: openssh-server: serice fails with invalid argument to Match Address in sshd_config
Package: openssh-server Version: 1:7.4p1-10+deb9u2 Severity: normal Dear Maintainer, DO NOT TRY TO REPRO THIS BUG ON A MACHINE UNLESS YOU HAVE PHYSICAL ACCESS TO LOCAL CONSOLE echo "Match Address 10.0.0.8/8 PasswordAuthentication yes " >>/etc/ssh/sshd_config or echo "Match Address fdfd::1/64 PasswordAuthentication yes " >>/etc/ssh/sshd_config /etc/init.d/ssh restart ... it will restart service without any error you can even do sshd -t which will confirm that everything is fine but, try to initiate a new cession, you will get "Connection closed" I have been explained why such lines are invalid. I am not arguing about the fact those lines are invalid. I am complaining about the fact very small typo can render a server completely unreachable, while service restart and internal test both say the conf is fine. Ideally, I would expect sshd to accept such arguments, and not care about extra bits in the provided address. At the very least, restart, and -t should both complain about invalid conf. Change the line for 10.0.0.0/8 or fdfd::/64 ... restart daemon, you can connect. I have not tried, but, I expect similar bug may occur with many other invalid arguments: 192.168.2.1.3 or 192.168.2 or fdfd::1::/64 ... DO NOT TRY TO REPRO THIS BUG ON A MACHINE UNLESS YOU HAVE PHYSICAL ACCESS TO LOCAL CONSOLE -- System Information: Debian Release: 9.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages openssh-server depends on: ii adduser3.115 ii debconf [debconf-2.0] 1.5.60 ii dpkg 1.18.23 ii init-system-helpers1.47 ii libaudit1 1:2.6.7-1 ii libc6 2.24-9 ii libcomerr2 1.43.4-2 ii libgssapi-krb5-2 1.15-1 ii libkrb5-3 1.15-1 ii libpam-modules 1.1.8-3.5 ii libpam-runtime 1.1.8-3.5 ii libpam0g 1.1.8-3.5 ii libselinux12.6-3 ii libssl1.0.21.0.2k-1 ii libsystemd0232-19 ii libwrap0 7.6.q-26 ii lsb-base 9.20161125 ii openssh-client 1:7.4p1-10+deb9u2 ii openssh-sftp-server1:7.4p1-10+deb9u2 ii procps 2:3.3.12-3 ii ucf3.0036 ii zlib1g 1:1.2.8.dfsg-5 Versions of packages openssh-server recommends: ii libpam-systemd 232-19 ii ncurses-term6.0+20161126-1 ii xauth 1:1.0.9-1+b2 Versions of packages openssh-server suggests: pn molly-guard pn monkeysphere pn rssh pn ssh-askpass pn ufw -- debconf information excluded -- >o_/ DEMAINE Benoît-Pierre (aka DoubleHP) http://benoit.demaine.info/ If computing were an exact science, IT engineers would'nt have work \_o< "So all that's left, Is the proof that love's not only blind but deaf." (FAKE TALES OF SAN FRANCISCO, Arctic Monkeys)
Bug#842615: An easy repro
# /etc/init.d/ssh restart [] Restarting ssh (via systemctl): ssh.serviceConnection to leon-00 closed by remote host. Connection to leon-00 closed. Could it be a side effect of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751636 ? -- >o_/ DEMAINE Benoît-Pierre (aka DoubleHP) http://benoit.demaine.info/ If computing were an exact science, IT engineers would'nt have work \_o< "So all that's left, Is the proof that love's not only blind but deaf." (FAKE TALES OF SAN FRANCISCO, Arctic Monkeys)
Bug#881344: aptitude: Cannot initiate the connection to - while wget can grab the file
On 14/11/17 22:42, Manuel A. Fernandez Montecelo wrote: > Would you > be able to try, or are the packages/ABIs completely incompatible? Try what ? I had similar issue (but not identical) with several old Debian running under chroot. It really looks to me as a resolution issue, or a timeout; IPv6 may be involved. Fact is, wget makes it better than aptitude. -- >o_/ DEMAINE Benoît-Pierre (aka DoubleHP) http://benoit.demaine.info/ If computing were an exact science, IT engineers would'nt have work \_o< "So all that's left, Is the proof that love's not only blind but deaf." (FAKE TALES OF SAN FRANCISCO, Arctic Monkeys)
Bug#881346: f2fs-tools: mkfs.f2fs fails with inapropriate error message on small blocks
Package: f2fs-tools Version: 1.4.0-2 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** mkfs fails on 100MB, but works on 1GB. Really sounds like there is a minimal size. Even if my interpretation is wrong, Failed to prepare a super block ... is not an intructive error message. There exist FLASH devices down to 8MB; the DOC2000 was a very famous chip with 32MB. The goal of the day was only to check if my kernel supported F2FS (if I could mount a block); I guess some people may want to use F2FS on old and small devices. # dd if=/dev/zero of=fff bs=1024 count=102400 102400+0 records in 102400+0 records out 104857600 bytes (105 MB) copied, 2.95282 s, 35.5 MB/s # mkfs.f2fs fff F2FS-tools: mkfs.f2fs Ver: 1.4.0 (2014-09-18) Info: sector size = 512 Info: total sectors = 204800 (in 512bytes) Info: zone aligned segment0 blkaddr: 512 Error: Failed to prepare a super block!!! Error: Could not format the device!!! # dd if=/dev/zero of=fff bs=1024 count=1024000 1024000+0 records in 1024000+0 records out 1048576000 bytes (1.0 GB) copied, 48.8232 s, 21.5 MB/s # mkfs.f2fs fff F2FS-tools: mkfs.f2fs Ver: 1.4.0 (2014-09-18) Info: sector size = 512 Info: total sectors = 2048000 (in 512bytes) Info: zone aligned segment0 blkaddr: 512 Info: Discarding device Info: format successful *** End of the template - remove these template lines *** -- System Information: Distributor ID: Raspbian Description:Raspbian GNU/Linux 8.0 (jessie) Release:8.0 Codename: jessie Architecture: armv7l Kernel: Linux 4.4.48-v7+ (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages f2fs-tools depends on: ii libc6 2.19-18+deb8u7 ii libuuid1 2.25.2-6 f2fs-tools recommends no packages. f2fs-tools suggests no packages. -- no debconf information -- >o_/ DEMAINE Benoît-Pierre (aka DoubleHP) http://benoit.demaine.info/ If computing were an exact science, IT engineers would'nt have work \_o< "So all that's left, Is the proof that love's not only blind but deaf." (FAKE TALES OF SAN FRANCISCO, Arctic Monkeys)
Bug#881344: aptitude: Cannot initiate the connection to - while wget can grab the file
o.3 => /usr/lib/arm-linux-gnueabihf/libcwidget.so.3 (0x7694) libsqlite3.so.0 => /usr/lib/arm-linux-gnueabihf/libsqlite3.so.0 (0x76885000) libboost_iostreams.so.1.55.0 => /usr/lib/arm-linux-gnueabihf/libboost_iostreams.so.1.55.0 (0x7685f000) libxapian.so.22 => /usr/lib/libxapian.so.22 (0x76676000) libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0x7664e000) libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0x76572000) libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0x764f6000) libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0x764c9000) libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x76388000) /lib/ld-linux-armhf.so.3 (0x54b1) libutil.so.1 => /lib/arm-linux-gnueabihf/libutil.so.1 (0x76375000) libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0x76362000) libz.so.1 => /lib/arm-linux-gnueabihf/libz.so.1 (0x7633a000) libbz2.so.1.0 => /lib/arm-linux-gnueabihf/libbz2.so.1.0 (0x76322000) liblzma.so.5 => /lib/arm-linux-gnueabihf/liblzma.so.5 (0x762fb000) librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0x762e4000) libuuid.so.1 => /lib/arm-linux-gnueabihf/libuuid.so.1 (0x762d) -- System Information: Distributor ID: Raspbian Description:Raspbian GNU/Linux 8.0 (jessie) Release:8.0 Codename: jessie Architecture: armv7l Kernel: Linux 4.4.48-v7+ (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages aptitude depends on: ii aptitude-common 0.6.11-1 ii libapt-pkg4.121.0.9.8.4 ii libboost-iostreams1.55.0 1.55.0+dfsg-3 ii libc6 2.19-18+deb8u7 ii libcwidget3 0.5.17-2 ii libgcc1 1:4.9.2-10 ii libncursesw5 5.9+20140913-1 ii libsigc++-2.0-0c2a2.4.0-1 ii libsqlite3-0 3.8.7.1-1+deb8u2 ii libstdc++64.9.2-10 ii libtinfo5 5.9+20140913-1 ii libxapian22 1.2.19-1+deb8u1 Versions of packages aptitude recommends: pn aptitude-doc-en | aptitude-doc pn libparse-debianchangelog-perl ii sensible-utils 0.0.9 Versions of packages aptitude suggests: pn apt-xapian-index pn debtags ii tasksel 3.31+deb8u1 -- no debconf information -- >o_/ DEMAINE Benoît-Pierre (aka DoubleHP) http://benoit.demaine.info/ If computing were an exact science, IT engineers would'nt have work \_o< "So all that's left, Is the proof that love's not only blind but deaf." (FAKE TALES OF SAN FRANCISCO, Arctic Monkeys)
Bug#793675: hplip-gui: No system tray detected
Package: hplip-gui Version: 3.17.10+repack0-1 Followup-For: Bug #793675 Dear Maintainer, This bug occurs also on Gnome3 (in Buster). It seems, at least for Gnome3, that the systray is temporarly removed after an upgrade, or starts too late ? Indeed, other systray-aware applications also display errors (ownCloud client, for instance). Unfortunately i don't know which package concerns the gnome systray... Thank you for your consideration. -- Package-specific info: -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.13.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages hplip-gui depends on: ii dbus-user-session [default-dbus-session-bus] 1.12.0-1 ii dbus-x11 [dbus-session-bus] 1.12.0-1 ii gksu 2.0.2-9+b1 ii hplip 3.17.10+repack0-1 ii python3-dbus.mainloop.pyqt5 5.9+dfsg-2+b1 ii python3-pyqt5 5.9+dfsg-2+b1 Versions of packages hplip-gui recommends: ii python3-notify2 0.3-3 ii simple-scan 3.23.2-1 hplip-gui suggests no packages. -- no debconf information
Bug#871629: thunderbird UI unusable with many widgets not drawn
Package: thunderbird Version: 1:52.2.1-4+b1 Followup-For: Bug #871629 Dear Maintainer, I get the exact same issue in stock Debian's Gnome Desktop, Buster. Thank you for your consideration, Benoît -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.11.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages thunderbird depends on: ii debianutils 4.8.1.1 ii fontconfig2.12.3-0.2 ii libatk1.0-0 2.24.0-1 ii libc6 2.24-12 ii libcairo-gobject2 1.14.10-1 ii libcairo2 1.14.10-1 ii libdbus-1-3 1.11.16+really1.10.22-1 ii libdbus-glib-1-2 0.108-2 ii libevent-2.1-62.1.8-stable-4 ii libffi6 3.2.1-6 ii libfontconfig12.12.3-0.2 ii libfreetype6 2.8-0.2 ii libgcc1 1:7.1.0-10 ii libgdk-pixbuf2.0-02.36.5-2 ii libglib2.0-0 2.53.4-3 ii libgtk-3-03.22.17-1 ii libhunspell-1.6-0 1.6.1-2 ii libpango-1.0-01.40.6-1 ii libpangocairo-1.0-0 1.40.6-1 ii libpangoft2-1.0-0 1.40.6-1 ii libpixman-1-0 0.34.0-1 ii libstartup-notification0 0.12-4+b2 ii libstdc++67.1.0-10 ii libvpx4 1.6.1-3 ii libx11-6 2:1.6.4-3 ii libx11-xcb1 2:1.6.4-3 ii libxcb-shm0 1.12-1 ii libxcb1 1.12-1 ii libxcomposite11:0.4.4-2 ii libxdamage1 1:1.1.4-2+b3 ii libxext6 2:1.3.3-1+b2 ii libxfixes31:5.0.3-1 ii libxrender1 1:0.9.10-1 ii libxt61:1.1.5-1 ii psmisc23.1-1 ii x11-utils 7.7+3+b1 ii zlib1g1:1.2.8.dfsg-5 Versions of packages thunderbird recommends: ii hunspell-en-us [hunspell-dictionary] 20070829-7 ii hunspell-fr-classical [hunspell-dictionary] 1:6.1-1 ii lightning1:52.2.1-4+b1 Versions of packages thunderbird suggests: pn apparmor ii fonts-lyx 2.2.3-1 ii libgssapi-krb5-2 1.15.1-2 -- no debconf information
Bug#867024: Remove 'gzip_disable "msie6";' directive in nginx default config file
Package: nginx-common Version: 1.13.1-2 Dear Maintainer, In the default configuration file for nginx.conf, we still see: gzip_disable "msie6"; As MS IE6 is really deprecated[1], I propose to remove completely this directive for Debian Buster. Upstream example config file doesn't have it. [1]: http://caniuse.com/usage-table (0.02%) Regards, -- Benoît SÉRIE – GnuPG: 4096R/56C27D99 Evolix – Hébergement et Infogérance Open Source http://www.evolix.fr/
Bug#865626: python-wnck: Depends on transitional libpango1.0.0 and not libpango-1.0.0
Package: python-wnck Version: 2.32.0+dfsg-3 Severity: normal Dear Maintainer, After migrating from jessie to stretch, purging removed packages, deborphaning and cleaning transitional packages, I still have one transitional package I can't remove. ii libpango-1.0-0:i386 1.40.5-1 i386 Layout and rendering of internationalized text ii libpango1.0-0:i386 1.40.5-1 i386 Layout and rendering of internationalized text (transitional package) Package: python-wnck Source: gnome-python-desktop Version: 2.32.0+dfsg-3 Depends: libatk1.0-0 (>= 1.12.4), libc6 (>= 2.3.6-6~), libcairo2 (>= 1.2.4), libfontconfig1 (>= 2.9.0), libfreetype6 (>= 2.2.1), libgdk-pixbuf2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.12.0), libgtk2.0-0 (>= 2.8.0), libpango1.0-0 (>= 1.14.0), libwnck22 (>= 2.30.0-3), python (>= 2.7), python (<< 2.8), python-gtk2 # dpkg --purge libpango1.0-0:i386 dpkg: dependency problems prevent removal of libpango1.0-0:i386: python-wnck depends on libpango1.0-0 (>= 1.14.0). dpkg: error processing package libpango1.0-0:i386 (--purge): dependency problems - not removing Errors were encountered while processing: libpango1.0-0:i386 I suppose python-wnck should depend on libpango1.0.0 OR libpango-1.0.0, to be able to remove the transitional package. -- System Information: Debian Release: 9.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 4.9.0-3-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) Versions of packages python-wnck depends on: ii libatk1.0-0 2.22.0-1 ii libc6 2.24-11+deb9u1 ii libcairo2 1.14.8-1 ii libfontconfig1 2.11.0-6.7+b1 ii libfreetype62.6.3-3.2 ii libgdk-pixbuf2.0-0 2.36.5-2 ii libglib2.0-02.50.3-2 ii libgtk2.0-0 2.24.31-2 ii libpango1.0-0 1.40.5-1 ii libwnck22 2.30.7-5.1 ii python 2.7.13-2 ii python-gtk2 2.24.0-5.1 python-wnck recommends no packages. python-wnck suggests no packages. -- no debconf information -- Benoît Sibaud
Bug#863733: unattended-upgrades: no option to select priority updates
Package: unattended-upgrades
Version: 0.93.1+nmu1
Severity: wishlist
Dear Maintainer,
I'm trying to use this package to keep my unstable patched for security issues.
But there's no filter to match the priority of an upgrade.
So unattended-upgrades ignores updates like this:
ignoring ver 'vlc=2.2.6-1' with priority < 0
How can I make it select this for install instead of ignoring it ?
-- System Information:
Debian Release: 9.0
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64
(x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
Versions of packages unattended-upgrades depends on:
ii apt1.4.4
ii apt-utils 1.4.4
ii debconf [debconf-2.0] 1.5.61
ii init-system-helpers1.48
ii lsb-base 9.20161125
ii lsb-release9.20161125
ii python33.5.3-1
ii python3-apt1.4.0~beta3
ii ucf3.0036
ii xz-utils 5.2.2-1.2+b1
Versions of packages unattended-upgrades recommends:
ii anacron 2.3-23
ii cron [cron-daemon] 3.0pl1-128+b1
Versions of packages unattended-upgrades suggests:
ii bsd-mailx 8.1.2-0.20160123cvs-4
ii exim4-daemon-light [mail-transport-agent] 4.89-2
pn needrestart
-- Configuration Files:
/etc/apt/apt.conf.d/50unattended-upgrades changed:
// Unattended-Upgrade::Origins-Pattern controls which packages are
// upgraded.
//
// Lines below have the format format is "keyword=value,...". A
// package will be upgraded only if the values in its metadata match
// all the supplied keywords in a line. (In other words, omitted
// keywords are wild cards.) The keywords originate from the Release
// file, but several aliases are accepted. The accepted keywords are:
// a,archive,suite (eg, "stable")
// c,component (eg, "main", "contrib", "non-free")
// l,label (eg, "Debian", "Debian-Security")
// o,origin(eg, "Debian", "Unofficial Multimedia Packages")
// n,codename (eg, "jessie", "jessie-updates")
// site (eg, "http.debian.net")
// The available values on the system are printed by the command
// "apt-cache policy", and can be debugged by running
// "unattended-upgrades -d" and looking at the log file.
//
// Within lines unattended-upgrades allows 2 macros whose values are
// derived from /etc/debian_version:
// ${distro_id}Installed origin.
// ${distro_codename} Installed codename (eg, "jessie")
Unattended-Upgrade::Origins-Pattern {
// Codename based matching:
// This will follow the migration of a release through different
// archives (e.g. from testing to stable and later oldstable).
// "o=Debian,n=jessie";
// "o=Debian,n=jessie-updates";
// "o=Debian,n=jessie-proposed-updates";
// "o=Debian,n=jessie,l=Debian-Security";
// Archive or Suite based matching:
// Note that this will silently match a different release after
// migration to the specified archive (e.g. testing becomes the
// new stable).
// "o=Debian,a=stable";
// "o=Debian,a=stable-updates";
// "o=Debian,a=proposed-updates";
"origin=Debian,codename=${distro_codename},label=Debian-Security";
"origin=Debian,a=unstable,label=Debian-Security";
};
// List of packages to not update (regexp are supported)
Unattended-Upgrade::Package-Blacklist {
// "vim";
// "libc6";
// "libc6-dev";
// "libc6-i686";
};
// This option allows you to control if on a unclean dpkg exit
// unattended-upgrades will automatically run
// dpkg --force-confold --configure -a
// The default is true, to ensure updates keep getting installed
//Unattended-Upgrade::AutoFixInterruptedDpkg "false";
// Split the upgrade into the smallest possible chunks so that
// they can be interrupted with SIGUSR1. This makes the upgrade
// a bit slower but it has the benefit that shutdown while a upgrade
// is running is possible (with a small delay)
//Unattended-Upgrade::MinimalSteps "true";
// Install all unattended-upgrades when the machine is shuting down
// instead of doing it in the background while the machine is running
// This will (obviously) make shutdown slower
//Unattended-Upgrade::InstallOnShutdown "true";
// Send email to this address for problems or packages upgrades
// If empty or unset then no email is sent, make sure that you
// have a working mail setup on your system. A package that provides
// 'mailx' must be installed. E.g. "u...@example.com"
//Unattended-Upgrade::Mail "root";
// Set this value to "true" to get emails only on errors. Default
// is to always send a mail if Unattended-Upgrade::Mail is set
//Unatten
Bug#863103: An other plugin affected: proc
The proc plugin also seems to be affected the same way. I can not be 100% certain for complicated reason: Munin does not show me any line for proc[perl], but according to min-max-avg values reported in daily, weekly, monthly and yearly images ... I think this plugin is affected the same way. But, the source code of proc plugin does not mention any call to pgrep. What I know for sure is that, the proc plugin works almost fine for all other process names (ssh, apache ...) for I don't have any line for perl; and all images have max=0 on monthly, but non null max for yearly ... like for ps_perl. Except ps_perl shows me a colored line around january, but proc[perl] does not. -- >o_/ DEMAINE Benoît-Pierre (aka DoubleHP) http://benoit.demaine.info/ If computing were an exact science, IT engineers would'nt have work \_o< "So all that's left, Is the proof that love's not only blind but deaf." (FAKE TALES OF SAN FRANCISCO, Arctic Monkeys)
Bug#860982: dstat: net stats collects down interfaces
Package: dstat Version: 0.7.3-1 Severity: normal Dear Maintainer, I have a bug with my LAN card that makes its statistics in /proc increment by 2**32 continuously when not plugged at all. The issue here is that dstat collects statistics even for this interface. So it looks like this: -net/total- recv send 0 0 4096M 4096M So if i'm connected in wifi with my other interface, I'm unable to use dstat --net to read network usage. gnome-system-monitor isn't fooled like dstat because it skips interfaces with no addresses. Here's my crazy ifconfig output: eth0 Link encap:Ethernet HWaddr ... UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:18760417144560 errors:16415365001490 dropped:2345052143070 overruns:2345052143070 frame:7035156429210 TX packets:11725260715350 errors:9380208572280 dropped:0 overruns:2345052143070 carrier:4690104286140 collisions:9380208572280 lg file transmission:1000 RX bytes:2345052143070 (2.1 TiB) TX bytes:2345052143070 (2.1 TiB) -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages dstat depends on: pn python:any dstat recommends no packages. dstat suggests no packages. -- no debconf information
Bug#842615: Bug still happening again and again
# aptitude update [...] Setting up openssh-server (1:7.4p1-9) ... Replacing config file /etc/ssh/sshd_config with new version Connection to leon-00 closed by remote host. Connection to leon-00 closed. # dpkg --configure -a [...] Setting up openssh-server (1:7.4p1-9) ... Connection to leon-00 closed by remote host. Connection to leon-00 closed. ... and bug is now completely preventing update: # dpkg --configure -a Setting up openssh-server (1:7.4p1-9) ... Connection to leon-00 closed by remote host. Connection to leon-00 closed. $ dpkg --configure -a Setting up openssh-server (1:7.4p1-9) ... debconf: unable to initialize frontend: Dialog debconf: (TERM is not set, so the dialog frontend is not usable.) debconf: falling back to frontend: Readline debconf: unable to initialize frontend: Readline debconf: (This frontend requires a controlling tty.) debconf: falling back to frontend: Teletype Connection to leon-00 closed by remote host. If you don't know, or can not use screen, you are stuck. -- >o_/ DEMAINE Benoît-Pierre (aka DoubleHP) http://benoit.demaine.info/ If computing were an exact science, IT engineers would'nt have work \_o< "So all that's left, Is the proof that love's not only blind but deaf." (FAKE TALES OF SAN FRANCISCO, Arctic Monkeys)
Bug#837788: [Packaging] Bug#837788: munin: systemd control scripts are missing
Because in Unix most services are enabled or disabled via classic commands /etc/init.d/foo start, or handling links in rc3.d. messing cron files is counter intuitive. Systems replaces init.d and rc3.d with systemctl. Good. Init.d/munin never existed, and was never needed in the past, why did you even care creating a link from munin to /dev/null ? We run systemctl as habit like for ssh and apache. Creating a systemd file for munin is a good idea. Using systemctl to enable and start munin would be nice. Or : make the .service file show a messages to tell to edit cron files. Le 11 mars 2017 19:46:29 CET, Andreas Henriksson a écrit : >On Sat, Mar 11, 2017 at 11:04:25AM +, Holger Levsen wrote: >[...] >> however, all that /etc/init.d/munin really does, is "mkdir && chown >/var/run/munin". >> >> that's all we need as a service file to fix this bug. Pretty trivial. >Still, >> help welcome. >[...] > >No, there's no need for a service file since it's already implemented >in a much better way: > >https://sources.debian.net/src/munin/2.0.33-1/debian/munin-common.tmpfile/ > >What needs to happen is that people explain why they so desperately >is trying to run the init script! Or what's unclear about the "masked" >message they get when trying to start munin.service. > >(Likely this bug report should be closed as "not a bug". People here >just seem to be very confused. Nothing to see please move along?!) > >Regards, >Andreas Henriksson -- Benoît-Pierre Demaine. Typos sponsorisées par mon téléphone.
Bug#837788: munin: systemd control scripts are missing
On 11/03/17 02:33, Matthew Gabeler-Lee wrote: > On Fri, 10 Mar 2017, Simon McVittie wrote: > >> However, Matthew Gabeler-Lee's reply: >> >>> I argue this merits worse than "important" -- in a default install of >>> Stretch currently, munin doesn't work at all. >> >> suggests that there may be something else going on. >> >> Matthew, please could you describe what you did (before applying any >> workarounds), what you expected to happen, and what actually happened, >> including any syslog, Journal or web server log messages that look >> potentially relevant? > > On closer inspection, I think I need to retract my prior statement. > > I had a problem with munin "not working at all" -- i.e. not collecting > data / updating charts, which correlated with an upgrade of the munin > package. > > But on closer inspection, I realize two things happened that day, and it > was actually the other thing that "broke" munin, and it was a mistake > interpreting the munin status pages that made me thing the sysvinit > workaround "fixed" it. The sysvinit hack "fixing" things was a false > positive, and it was really fixing the other problem (a network issue > preventing data collection from most nodes) that made munin start > working for me. > > I think the suggestion that this in fact is not a bug and is just a > confusion with how munin works is correct. > > It is in fact /etc/cron.d/munin that does the "service" work of munin. > > Apologies for the confusion! > I have discussed similar issue here: http://forums.debian.net/viewtopic.php?f=5&t=130106 |# systemctl enable munin.service Synchronizing state of munin.service with SysV service script with /lib/systemd/systemd-sysv-install. Executing: /lib/systemd/systemd-sysv-install enable munin Failed to enable unit: Unit file /lib/systemd/system/munin.service is masked. In fact, things work because munin server relies on cron. Still, why has debian maint set an unusable | |munin.service ? In fact, before systemd, munin (server) did not need init script at all; so, writing a .service file for systemd may be useless. Unless you want to add features: a .service file could allow to start and stop munin. This could be an added value to recent Debian version. How to disable the server via a .service ? either add a dot in the name of the cron file, like |/etc/cron.d/munin.disabled (see man cron, it will refuse to run files with a dot), or, comment lines in that file. Yes, this could have been done in sysinit. But, if a .service is created (masked in our case, but still existing link to dev/null), please, make it usefull. Also, the .service file could clearly tell about it's dep upon cron (this is unclear for beginners; munin really does not work like other independant services: ssh, apache, samba ...). There is a .service file for the node; why not make the server one *usefull* ? -- >o_/ DEMAINE Benoît-Pierre (aka DoubleHP) http://benoit.demaine.info/ If computing were an exact science, IT engineers would'nt have work \_o< "So all that's left, Is the proof that love's not only blind but deaf." (FAKE TALES OF SAN FRANCISCO, Arctic Monkeys)
Bug#852172: dpkg: insecure use of temp file when upgrading conf file
Package: dpkg Version: 1.18.7 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: =?utf-8?q?Beno=C3=AEt?= To: Debian Bug Tracking System Subject: dpkg: Insecure use of temp file when upgrading conf file Message-ID: <148508137504.25923.4577376012946261907.reportbug@powerbook> X-Mailer: reportbug 7.1.3 Date: Sun, 22 Jan 2017 11:36:15 +0100 Package: dpkg Version: 1.18.7 Severity: normal Dear Maintainer, I'm upgrading openssh server and dpkg tells me about a new config file. I usually find a .dist-something file beside the current file. I couldn't. Then I read carefully dpkg's message. It's telling me to check a file with a hard-to-remember name in /tmp/. And that file is world readable, unlike my current config file. I don't know if it's safe to have a sshd_config world-readable, but some other package conf file may store secret information. So puting the new file world readable in a world-readable dir doesn't seem right to me. $ LANG=C ls -la /tmp/fileaURJMg /etc/ssh/sshd_config -rw--- 1 root root 2425 Jan 28 2016 /etc/ssh/sshd_config -rw-r--r-- 1 root root 3361 Jan 16 16:11 /tmp/fileaURJMg -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.7.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages dpkg depends on: ii libbz2-1.0 1.0.6-8 ii libc62.24-2 ii liblzma5 5.1.1alpha+20120614-2.1 ii libselinux1 2.3-2+b1 ii tar 1.29b-1.1 ii zlib1g 1:1.2.8.dfsg-2+b1 dpkg recommends no packages. Versions of packages dpkg suggests: ii apt 1.3.1 -- no debconf information -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.7.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages dpkg depends on: ii libbz2-1.0 1.0.6-8 ii libc62.24-2 ii liblzma5 5.1.1alpha+20120614-2.1 ii libselinux1 2.3-2+b1 ii tar 1.29b-1.1 ii zlib1g 1:1.2.8.dfsg-2+b1 dpkg recommends no packages. Versions of packages dpkg suggests: ii apt 1.3.1 -- no debconf information
Bug#845519: Re : kernel 4.8 can't boot on Dell Optiplex 7040
Dear Maintener, I can confirm that everything work now with latest kernel 4.8 updates. The optiplex 7040 is actually running kernel image : linux-image-4.8.0-2-amd64 ( version 4.8.15-2 ) Thanks a lot. Best regards Benoît Tonnerre
Bug#93200: PermitEmptyPasswords conflicts with nullok_secure
Just for clarity, I just ran into this (pretty old !) issue and found the culprit. Even though you can configure PermitEmptyPasswords in the sshd_config file, pam will not allow any passwordless authentication from a non secure tty (from /etc/securetty). "ssh" is per definition a non-secure tty. Hence no matter what you put in your sshd_config file, password less authentication via ssh is not possible unless you either - replace "nullok_secure" with "nullok" in /etc/pam.d/common-auth, or - add "ssh" to /etc/securetty. What was the point of the nullok_secure at the first place ? Having a second "line-of-defense" against configurations like mine who wish passwordless (keyless) ssh access ? Regards, Ben. PS: Just for the record, I don't allow world-access to my system, I have the following in my configuration: Match User omp PermitEmptyPasswords yes ForceCommand /usr/bin/socat UNIX-CONNECT:/path/to/the/socket.sock - pgpPFkujVb9Jh.pgp Description: OpenPGP digital signature
Bug#849948: workaround
I may have found a workaround. https://sourceforge.net/p/munin/mailman/message/35580589/ In short, state that the bug is in the sensor plugin, that is using numbers which rely on the order or lines (from output of sensors command), while other munin plugins use plain text names as internal field names (see loggrep). I will report here if the mailing list message is converted into a bugreport. -- >o_/ DEMAINE Benoît-Pierre (aka DoubleHP) http://benoit.demaine.info/ If computing were an exact science, IT engineers would'nt have work \_o< "So all that's left, Is the proof that love's not only blind but deaf." (FAKE TALES OF SAN FRANCISCO, Arctic Monkeys)
Bug#772448: Workaround
On Tue, 23 Feb 2016 13:55:08 + Richard Harris wrote: > There is no need to guess, you can run logrotate with the --verbose setting > and find out which log it was processing before the error occured. A good > way to do this is to modify the logrotate cron to add --verbose and sit and > wait for the logs to reach your inbox. Running a rotation manually may have bad side effects. Some daemons need a complete service restart (including complete interruption during a few seconds) via postrotate. Manually run daily rotationsmore than once a day can lead to conflictuous names. Finaly, a manual run may not trigger then "file size change" for various random reasons. I had that strange message for the first time, on machines working fine since over 3 months. So, happens once in 150 days. I would thus need to run it manually at least 150 times before getting it ? Cron reported me an issue, with an irrelevant message that can't contribute to any solution. => On Sun, 7 Dec 2014 16:59:07 + Paul Martin wrote: > To associate an error message with a particular script, logrotate > would have to capture stdout and stderr from its running of the > compressor and then prefix it with the name of the script or other > external program. YES. It will take what it will take, but that's the only way to provide usefull error reports. -- >o_/ DEMAINE Benoît-Pierre (aka DoubleHP) http://benoit.demaine.info/ If computing were an exact science, IT engineers would'nt have work \_o< "So all that's left, Is the proof that love's not only blind but deaf." (FAKE TALES OF SAN FRANCISCO, Arctic Monkeys)
Bug#849659: hd44780 driver linked with wrong sem_wait
Package: lcdproc Version: 0.5.7-2 Severity: grave Using the hd44780 driver with connectiontype=8bit consistently triggers a segmentation fault. The drivers of lcdproc define their own sem_get, sem_wait, sem_signal, ... (See server/drivers/lcd_sem.h). Unfortunately, the linux's version of sem_wait (3) is being used, leading to a segmentation fault. Program received signal SIGSEGV, Segmentation fault. sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:44 44 ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S: No such file or directory. (gdb) bt #0 sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:44 #1 0x774049d7 in lcdtime_HD44780_senddata (p=p@entry=0x631d00, displayID=displayID@entry=0 '\000', flags=flags@entry=1 '\001', ch=ch@entry=48 '0') at hd44780-ext8bit.c:153 #2 0x77404c7f in hd_init_ext8bit (drvthis=0x630810) at hd44780-ext8bit.c:112 #3 0x774022a1 in HD44780_init (drvthis=0x630810) at hd44780.c:373 #4 0x004109a0 in driver_load (name=name@entry=0x6220d0 "hd44780", filename=filename@entry=0x6307d0 "/usr/lib/x86_64-linux-gnu/lcdproc/hd44780.so") at driver.c:153 #5 0x0040fddf in drivers_load_driver (name=0x6220d0 "hd44780") at drivers.c:85 #6 0x00407df5 in init_drivers () at main.c:670 #7 0x0040635b in main (argc=, argv=) at main.c:2 Regards, Ben pgp9E9A6d_LLa.pgp Description: OpenPGP digital signature
Bug#842095: RFS: qspeakers/1.0-1 [ITP] -- new package of a loudspeaker design software
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "qspeakers" * Package name: qspeakers Version : 1.0-1 Upstream Author : Benoît Rouits * URL : http://brouits.free.fr/qspeakers/ * License : GPL-3+ Section : misc It builds those binary packages: qspeakers - loudspeaker design software To access further information about this package, please visit the following URL: https://mentors.debian.net/package/qspeakers Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/q/qspeakers/qspeakers_1.0-1.dsc More information: This package closes #842087 (wnpp). QSpeakers is a simple graphical program that simulates common acoustical enclosures behaviour to help designing loudspeaker systems, based on the loudspeaker driver's Thiele / Small parameters and the chosen enclosure type. . This software is mostly useful for do-it-yourself loudspeaker enthusiasts, acoustics teaching, and to a lesser extent, for loudspeaker engineering. I am also the upstream author of this program. There is no similar software in Debian, yet. But there are similar software on other operating systems (think of WinISD). This software depends on Qt5 (widgets) and Qwt6 (frequency response plot). I got a positive return from debian-science mailing-list on the idea of packaging that software for Debian. I hope the package is well done. Thank you for your review and possible sponsorship ! Regards, Benoît
Bug#842087: ITP: qspeakers -- loudspeaker design software
Package: wnpp Severity: wishlist Owner: "Benoît Rouits" * Package name: qspeakers Version : 1.0 Upstream Author : Benoît Rouits * URL : http://brouits.free.fr/qspeakers/ * License : GPL-3.0+ Programming Lang: C++ Description : loudspeaker design software QSpeakers is a simple graphical program that simulates common acoustical enclosures behaviour to help designing loudspeaker systems, based on the loudspeaker driver's Thiele / Small parameters and the chosen enclosure type. . This software is mostly useful for do-it-yourself loudspeaker enthusiasts, acoustics teaching, and to a lesser extent, for loudspeaker engineering. I am also the upstream author of this program. There is no similar software in Debian, yet. But there are similar software on other operating systems (think of WinISD). This software depends on Qt5 (widgets) and Qwt6 (frequency response plot).
Bug#841873: closed by Adam Borowski (Re: Bug#841873: RFS: csv2latex/0.19-1 ITP)
Sorry, "ITP" was too much in the subject line. I guess i should have not to mention anything special. Thanks for the upload into unstable. - Benoît Le 24/10/2016 à 02:45, Debian Bug Tracking System a écrit : This is an automatic notification regarding your Bug report which was filed against the sponsorship-requests package: #841873: RFS: csv2latex/0.19-1 ITP It has been closed by Adam Borowski .
Bug#841873: RFS: csv2latex/0.19-1 ITP
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "csv2latex" * Package name: csv2latex Version : 0.19-1 Upstream Author : Benoît Rouits * URL : http://brouits.free.fr/csv2latex/ * License : GPL-2 Section : tex It builds those binary packages: csv2latex - command-line CSV to LaTeX file converter To access further information about this package, please visit the following URL: https://mentors.debian.net/package/csv2latex Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/c/csv2latex/csv2latex_0.19-1.dsc More information about hello can be obtained from https://www.example.com. Changes since the last upload: * New upstream release, support read from stdin. * Bump to Standards-Version 3.9.8 * Minor fix on URIs * Use debhelper 10 Regards, Benoît Rouits
Bug#835866: Additional information
Hi all, I can confirm there is an issue with Google Authentication page not being rendered properly with icedove 1:45.2.0-4+b1. I'm having the issue with the following extension not working anymore: https://addons.mozilla.org/fr/thunderbird/addon/google-calendar-tab/ Cheers, Benoît
Bug#741628: Same issue between a fresh Debian unstable and an Ubuntu Server 14.04 LTS
Hi, next step, According to https://rsync.samba.org/FAQ.html#13 "inflate (token) returned -5 This error means that rsync failed to handle an expected error from the compression code for a file that happened to be transferred with a block size of 32816 bytes. You can avoid this issue for the affected file by transferring it with a manually-set block size (e.g. --block-size=33000), or by upgrading the receiving side to rsync 3.0.7. " Looks like rsync 3.0.7+ is not enough (currently using 3.1.1). New test with the backup of the day: Default blocksize 32816, read 7,657,969 bytes, failed inflate returned -3 (0 bytes) With --block-size=33000, read 7,690,797 bytes, failed inflate returned -3 (0 bytes) With --block-size=36000, read 8,018,923 bytes, failed inflate returned -3 (20 bytes) With --block-size=65536, success. So now we have an other workaround at least (instead of removing -z). I also have logs from rsync-debug on both sides (mentioned in https://rsync.samba.org/issues.html ), but it's huge (400 MB and 236 MB) and I'm not sure it's still useful with the two workarounds. -- Benoît Sibaud
Bug#741628: Same issue between a fresh Debian unstable and an Ubuntu Server 14.04 LTS
lib/x86_64-linux-gnu/libpopt.so.0.0.0) ==21134==by 0x524A5FE: poptGetNextOpt (in /lib/x86_64-linux-gnu/libpopt.so.0.0.0) ==21134==by 0x136F14: ??? (in /usr/bin/rsync) ==21134==by 0x1106D6: ??? (in /usr/bin/rsync) ==21134==by 0x547372F: (below main) (libc-start.c:291) ==21134== ==21134== 14,994 bytes in 232 blocks are possibly lost in loss record 21 of 30 ==21134==at 0x4C2BBCF: malloc (vg_replace_malloc.c:299) ==21134==by 0x113D4E: ??? (in /usr/bin/rsync) ==21134==by 0x1153BD: ??? (in /usr/bin/rsync) ==21134==by 0x116DCA: ??? (in /usr/bin/rsync) ==21134==by 0x119B16: ??? (in /usr/bin/rsync) ==21134==by 0x11BA63: ??? (in /usr/bin/rsync) ==21134==by 0x11BFF4: ??? (in /usr/bin/rsync) ==21134==by 0x121918: ??? (in /usr/bin/rsync) ==21134==by 0x12D8A7: ??? (in /usr/bin/rsync) ==21134==by 0x12E217: ??? (in /usr/bin/rsync) ==21134==by 0x110E60: ??? (in /usr/bin/rsync) ==21134==by 0x547372F: (below main) (libc-start.c:291) ==21134== ==21134== 9,343,062 bytes in 168,759 blocks are definitely lost in loss record 27 of 30 ==21134==at 0x4C2BBCF: malloc (vg_replace_malloc.c:299) ==21134==by 0x113D4E: ??? (in /usr/bin/rsync) ==21134==by 0x1153BD: ??? (in /usr/bin/rsync) ==21134==by 0x116DCA: ??? (in /usr/bin/rsync) ==21134==by 0x119B16: ??? (in /usr/bin/rsync) ==21134==by 0x11BA63: ??? (in /usr/bin/rsync) ==21134==by 0x11BFF4: ??? (in /usr/bin/rsync) ==21134==by 0x121918: ??? (in /usr/bin/rsync) ==21134==by 0x12D8A7: ??? (in /usr/bin/rsync) ==21134==by 0x12E217: ??? (in /usr/bin/rsync) ==21134==by 0x110E60: ??? (in /usr/bin/rsync) ==21134==by 0x547372F: (below main) (libc-start.c:291) ==21134== ==21134== LEAK SUMMARY: ==21134==definitely lost: 9,343,265 bytes in 168,769 blocks ==21134==indirectly lost: 0 bytes in 0 blocks ==21134== possibly lost: 15,016 bytes in 233 blocks ==21134==still reachable: 103,373,184 bytes in 169,355 blocks ==21134== suppressed: 0 bytes in 0 blocks ==21134== Reachable blocks (those to which a pointer was found) are not shown. ==21134== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==21134== ==21134== For counts of detected and suppressed errors, rerun with: -v ==21134== ERROR SUMMARY: 5 errors from 5 contexts (suppressed: 0 from 0) ### With remote valgrind ( --rsync-path=/root/myrsync , file containing valgrind --trace-children=yes --leak-check=full --log-file="/tmp/myrsync.%p" /usr/bin/rsync $@ ) receiving file list ... 1274360 files to consider data/prod/backup/ data/prod/backup/linuxfr-daily.dump.gz 31,862,527 2% 641.03kB/s0:27:17 inflate returned -3 (0 bytes) rsync error: error in rsync protocol data stream (code 12) at token.c(557) [receiver=3.1.1] rsync: [generator] write error: Broken pipe (32) rsync error: error in socket IO (code 10) at io.c(820) [generator=3.1.1] and on remote side: ==26229== Memcheck, a memory error detector ==26229== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==26229== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info ==26229== Command: /usr/bin/rsync --server --sender -vlHogDtprze.Lsfx --numeric-ids . / ==26229== Parent PID: 26228 ==26229== ==26229== ==26229== HEAP SUMMARY: ==26229== in use at exit: 108,102,459 bytes in 169,384 blocks ==26229== total heap usage: 349,613 allocs, 180,229 frees, 6,042,974,555 bytes allocated ==26229== ==26229== LEAK SUMMARY: ==26229==definitely lost: 0 bytes in 0 blocks ==26229==indirectly lost: 0 bytes in 0 blocks ==26229== possibly lost: 0 bytes in 0 blocks ==26229==still reachable: 108,102,459 bytes in 169,384 blocks ==26229== suppressed: 0 bytes in 0 blocks ==26229== Reachable blocks (those to which a pointer was found) are not shown. ==26229== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==26229== ==26229== For counts of detected and suppressed errors, rerun with: -v ==26229== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) -- Benoît Sibaud
Bug#829188: icedove SEGV backtrace
> LANG= /usr/lib/icedove/run-mozilla.sh -g /usr/lib/icedove/icedove-bin
> --safe-mode 2>&1 | tee /tmp/icedove-gdb-$(apt-cache show icedove | grep
> Version | awk '{ print $2 }')_$(date +%F_%T).log
I just reproduced the crash with the above command, please find the
logfile including backtrace (gzip'ed) attached.
Hope this help.
ben
icedove-gdb-1:45.2.0-1.gz
Description: GNU Zip compressed data
Bug#829188: icedove SEGV backtrace
>> please consider the note in the message #27 about making GDB logs. >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829188#27 > I restarted it with LANG= gdb -ex 'handle SIGPIPE nostop' -ex 'handle > SIGSTOP nostop' -ex 'run' --args /usr/lib/icedove/icedove --safe-mode > I'll post the result in a few days... Sorry for spamming but I am unsure about something: when using '/usr/lib/icedove/run-mozilla.sh -g /usr/lib/icedove/icedove-bin' etc. it does not disable the extensions (esp. iceowl). What would be the most valuable? Using the run-mozilla.sh etc. as per the wiki, or should I also disable extensions (--safe-mode)? Again, as it is long to reproduce, I'd like to give you the most useful information... Best, ben
Bug#829188: icedove SEGV backtrace
> please consider the note in the message #27 about making GDB logs. > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829188#27 I have seen this but I launched it under gbb prior to find the bug report (and the instructions). As it is hard (long) to reproduce, I think it might be helpful anyway. I restarted it with LANG= gdb -ex 'handle SIGPIPE nostop' -ex 'handle SIGSTOP nostop' -ex 'run' --args /usr/lib/icedove/icedove --safe-mode I'll post the result in a few days... ben
Bug#829188: icedove SEGV backtrace
Package: icedove Version: 1:45.2.0-1 Followup-For: Bug #829188 I have the same problem, it crashed every 2-3 days. Here is the backtrace for plain 'icedove' command (segfault in thread 1, the main() thread): Thread 1696 (Thread 0x7fffa56fe700 (LWP 20325)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225 #1 0x75ea27d8 in ?? () from /usr/lib/x86_64-linux-gnu/libnspr4.so #2 0x75ea2cee in PR_WaitCondVar () from /usr/lib/x86_64-linux- gnu/libnspr4.so #3 0x722962ab in mozilla::CondVar::Wait (aInterval=aInterval@entry=3, this=0x7fffd45b0080) at ../../dist/include/mozilla/CondVar.h:79 #4 0x7229e710 in nsEventQueue::Wait (aInterval=3, this=0x7fffd45b0068) at /build/icedove- JNT_9F/icedove-45.2.0/mozilla/xpcom/threads/nsEventQueue.h:104 #5 nsThreadPool::Run (this=0x7fffd45b0040) at /build/icedove- JNT_9F/icedove-45.2.0/mozilla/xpcom/threads/nsThreadPool.cpp:217 #6 0x7229bc8a in nsThread::ProcessNextEvent (this=0x7fffb1455fc0, aMayWait=, aResult=0x7fffa56fddd7) at /build/icedove- JNT_9F/icedove-45.2.0/mozilla/xpcom/threads/nsThread.cpp:972 #7 0x722b762d in NS_ProcessNextEvent (aThread=, aMayWait=aMayWait@entry=false) at /build/icedove- JNT_9F/icedove-45.2.0/mozilla/xpcom/glue/nsThreadUtils.cpp:297 #8 0x72496e5d in mozilla::ipc::MessagePumpForNonMainThreads::Run (this=0x7fffc0d069c0, aDelegate=0x7fffb78a20c0) at /build/icedove- JNT_9F/icedove-45.2.0/mozilla/ipc/glue/MessagePump.cpp:326 #9 0x724870fa in MessageLoop::RunHandler (this=) at /build/icedove- JNT_9F/icedove-45.2.0/mozilla/ipc/chromium/src/base/message_loop.cc:227 #10 MessageLoop::Run (this=this@entry=0x7fffb78a20c0) at /build/icedove- JNT_9F/icedove-45.2.0/mozilla/ipc/chromium/src/base/message_loop.cc:201 #11 0x7229eef6 in nsThread::ThreadFunc (aArg=0x7fffb1455fc0) at /build /icedove-JNT_9F/icedove-45.2.0/mozilla/xpcom/threads/nsThread.cpp:376 #12 0x75ea8758 in ?? () from /usr/lib/x86_64-linux-gnu/libnspr4.so #13 0x77bc3464 in start_thread (arg=0x7fffa56fe700) at pthread_create.c:333 #14 0x76e6330d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 1650 (Thread 0x7fffb217e700 (LWP 20119)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225 #1 0x75ea27d8 in ?? () from /usr/lib/x86_64-linux-gnu/libnspr4.so #2 0x75ea2cee in PR_WaitCondVar () from /usr/lib/x86_64-linux- gnu/libnspr4.so #3 0x72332a75 in mozilla::CondVar::Wait (this=0x7fffd93263f0, aInterval=30) at ../../dist/include/mozilla/CondVar.h:79 #4 nsHostResolver::GetHostToLookup (this=this@entry=0x7fffd93263d0, result=result@entry=0x7fffb217de70) at /build/icedove- JNT_9F/icedove-45.2.0/mozilla/netwerk/dns/nsHostResolver.cpp:1163 #5 0x72332fae in nsHostResolver::ThreadFunc (arg=0x7fffd93263d0) at /build/icedove- JNT_9F/icedove-45.2.0/mozilla/netwerk/dns/nsHostResolver.cpp:1391 #6 0x75ea8758 in ?? () from /usr/lib/x86_64-linux-gnu/libnspr4.so #7 0x77bc3464 in start_thread (arg=0x7fffb217e700) at pthread_create.c:333 #8 0x76e6330d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 1649 (Thread 0x7fffb4983700 (LWP 20118)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225 #1 0x75ea27d8 in ?? () from /usr/lib/x86_64-linux-gnu/libnspr4.so #2 0x75ea3192 in PR_Wait () from /usr/lib/x86_64-linux-gnu/libnspr4.so #3 0x72180ab1 in mozilla::ReentrantMonitor::Wait (this=0x7fffc5ab11e0, aInterval=aInterval@entry=6) at ../../../dist/include/mozilla/ReentrantMonitor.h:91 #4 0x7218cfa8 in mozilla::ReentrantMonitorAutoEnter::Wait (aInterval=6, this=0x7fffb4982cb0) at ../../../dist/include/mozilla/ReentrantMonitor.h:190 #5 nsImapProtocol::ImapThreadMainLoop (this=this@entry=0x7fffc5ab1000) at /build/icedove- JNT_9F/icedove-45.2.0/mailnews/imap/src/nsImapProtocol.cpp:1351 #6 0x7218d19c in nsImapProtocol::Run (this=0x7fffc5ab1000) at /build /icedove-JNT_9F/icedove-45.2.0/mailnews/imap/src/nsImapProtocol.cpp:1068 #7 0x7229bc8a in nsThread::ProcessNextEvent (this=0x7fffa79fef30, aMayWait=, aResult=0x7fffb4982dd7) at /build/icedove- JNT_9F/icedove-45.2.0/mozilla/xpcom/threads/nsThread.cpp:972 #8 0x722b762d in NS_ProcessNextEvent (aThread=, aMayWait=aMayWait@entry=false) at /build/icedove- JNT_9F/icedove-45.2.0/mozilla/xpcom/glue/nsThreadUtils.cpp:297 #9 0x72496e5d in mozilla::ipc::MessagePumpForNonMainThreads::Run (this=0x7fffc9aa2340, aDelegate=0x7fffbc9fb0b0) at /build/icedove- JNT_9F/icedove-45.2.0/mozilla/ipc/glue/MessagePump.cpp:326 #10 0x724870fa in MessageLoop::RunHandler (this=) at /build/icedove- JNT_9F/icedove-45.2.0/mozilla/ipc/chromium/src/base/message_loop.cc:227 #11 Messag
Bug#729287: linphone: No sound when using pulseaudio
Hi there, This bug is really annoying… If that could help, there is a really good analyze of the issue on pulseaudio ML [1]. Also, someone has proposed a patch on linphone ML [2]. Upstream developers seems not to care about this bug. Maybe the Debian Maintainer can use this patch? My 2 cts, [1]: https://lists.freedesktop.org/archives/pulseaudio-discuss/2015-December/024889.html [2]: https://lists.nongnu.org/archive/html/linphone-developers/2014-10/msg00044.html -- Benoît SÉRIE – GnuPG: 4096R/56C27D99 Evolix – Hébergement et Infogérance Open Source http://www.evolix.fr/
Bug#820061: linux-image-amd64: kernel hangs since debian 8.4
Package: linux-image-amd64 Version: 3.16.7-ckt25-1 Severity: normal Hi, Since yesterday (update to debian 8.4) some PC at work, hangs randomly. All the machines freeze when reading e-mails, searching things online, reading PDF, lauching PHP Storm, etc ... All the machines are from Dell (tested on Dell 990 and Dell 9010). They are all equiped with a SSD disk. Updating to linux-image-4.4.0-0.bpo.1-amd64 seems to resolve the issue. I found this in /var/log/syslog : Apr 4 18:52:55 pci003-01 kernel: [ 79.316412] BUG: unable to handle kernel NULL pointer dereference at 0008 Apr 4 18:52:55 pci003-01 kernel: [ 79.317910] IP: [] radeon_fence_ref+0xd/0x50 [radeon] Apr 4 18:52:55 pci003-01 kernel: [ 79.318687] PGD 0 Apr 4 18:52:55 pci003-01 kernel: [ 79.319445] Oops: 0002 [#1] SMP Apr 4 18:52:55 pci003-01 kernel: [ 79.320209] Modules linked in: md4 hmac nls_utf8 cifs dns_resolver pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) cpufreq_stats cpufreq_userspace cpufreq_conservative cpufreq_powersave nfsd auth_rpcgss oid_registry nfs_acl nfs lockd fscache sunrpc snd_pcm_oss snd_mixer_oss fuse joydev x86_pkg_temp_thermal intel_powerclamp intel_rapl coretemp kvm_intel kvm iTCO_wdt iTCO_vendor_support crc32_pclmul evdev snd_hda_codec_realtek snd_hda_codec_generic aesni_intel aes_x86_64 radeon lrw gf128mul glue_helper dcdbas ablk_helper cryptd ttm drm_kms_helper pcspkr serio_raw drm i2c_i801 i2c_algo_bit i2c_core lpc_ich snd_hda_intel mfd_core snd_hda_controller snd_hda_codec snd_hwdep snd_pcm snd_timer tpm_tis snd tpm soundcore mei_me mei button shpchp video processor thermal_sys parport_pc ppdev lp parport autofs4 hid_generic usbhid hid ext4 crc16 mbcache jbd2 raid1 md_mod sg sr_mod sd_mod cdrom crc_t10dif crct10dif_generic crct10dif_pclmul crct10dif_common crc32c_intel psmouse ahci libahci ehci_pci ehci_hcd libata scsi_mod e1000e usbcore ptp usb_common pps_core Apr 4 18:52:55 pci003-01 kernel: [ 79.326413] CPU: 3 PID: 1604 Comm: Xorg Tainted: G O 3.16.0-4-amd64 #1 Debian 3.16.7-ckt25-1 Apr 4 18:52:55 pci003-01 kernel: [ 79.327346] Hardware name: Dell Inc. OptiPlex 990/06D7TR, BIOS A19 08/26/2015 Apr 4 18:52:55 pci003-01 kernel: [ 79.328278] task: 8802216c0a20 ti: 88003639c000 task.ti: 88003639c000 Apr 4 18:52:55 pci003-01 kernel: [ 79.329223] RIP: 0010:[] [] radeon_fence_ref+0xd/0x50 [radeon] Apr 4 18:52:55 pci003-01 kernel: [ 79.330192] RSP: 0018:88003639fb18 EFLAGS: 00010292 Apr 4 18:52:55 pci003-01 kernel: [ 79.331154] RAX: RBX: 8802218f55f8 RCX: 8802218f4d08 Apr 4 18:52:55 pci003-01 kernel: [ 79.332125] RDX: 0001 RSI: RDI: Apr 4 18:52:55 pci003-01 kernel: [ 79.333110] RBP: 8802218f5550 R08: 8802218f4000 R09: Apr 4 18:52:55 pci003-01 kernel: [ 79.334119] R10: 0002 R11: 88003639fe08 R12: 0020 Apr 4 18:52:55 pci003-01 kernel: [ 79.335117] R13: 88003639fbe0 R14: 88003639fbb0 R15: 8802218f55f8 Apr 4 18:52:55 pci003-01 kernel: [ 79.336120] FS: 7fd8f5323980() GS:88022dc6() knlGS: Apr 4 18:52:55 pci003-01 kernel: [ 79.337143] CS: 0010 DS: ES: CR0: 80050033 Apr 4 18:52:55 pci003-01 kernel: [ 79.338142] CR2: 0008 CR3: 000223b3e000 CR4: 000407e0 Apr 4 18:52:55 pci003-01 kernel: [ 79.339125] Stack: Apr 4 18:52:55 pci003-01 kernel: [ 79.340065] a04900bc 0020 eea00100 88003639fcd0 Apr 4 18:52:55 pci003-01 kernel: [ 79.341006] 8802218f4000 8802216c0a20 8802216c0a20 0001 Apr 4 18:52:55 pci003-01 kernel: [ 79.341952] Apr 4 18:52:55 pci003-01 kernel: [ 79.342899] Call Trace: Apr 4 18:52:55 pci003-01 kernel: [ 79.343854] [] ? radeon_sa_bo_new+0x25c/0x460 [radeon] Apr 4 18:52:55 pci003-01 kernel: [ 79.344808] [] ? radeon_ib_get+0x2e/0xd0 [radeon] Apr 4 18:52:55 pci003-01 kernel: [ 79.345758] [] ? radeon_cs_ioctl+0x13c/0x730 [radeon] Apr 4 18:52:55 pci003-01 kernel: [ 79.346702] [] ? drm_ioctl+0x1c7/0x5b0 [drm] Apr 4 18:52:55 pci003-01 kernel: [ 79.347637] [] ? __do_page_fault+0x1d1/0x4f0 Apr 4 18:52:55 pci003-01 kernel: [ 79.348572] [] ? radeon_drm_ioctl+0x46/0x80 [radeon] Apr 4 18:52:55 pci003-01 kernel: [ 79.349500] [] ? do_vfs_ioctl+0x2cf/0x4b0 Apr 4 18:52:55 pci003-01 kernel: [ 79.350437] [] ? __sys_recvmsg+0x65/0x80 Apr 4 18:52:55 pci003-01 kernel: [ 79.351355] [] ? SyS_ioctl+0x81/0xa0 Apr 4 18:52:55 pci003-01 kernel: [ 79.352265] [] ? system_call_fast_compare_end+0x10/0x15 Apr 4 18:52:55 pci003-01 kernel: [ 79.353167] Code: e4 48 8b 3b 89 c1 89 ea 48 c7 c6 80 f6 51 a0 31 c0 e8 68 17 f7 e0 eb cb 66 0f 1f 44 00 00 66 66 66 66 90 48 89 f8 ba 01 00 00 00 0f c1 57 08 83 c2 01 83 fa 01 7e 01 c3 80 3d 0e 43 11 00 00 Apr 4 18:52:55 p
