Bug#645788: Beratungsstelle

[Torres Sanchez Carlos Daniel]

Sehr geehrter E-Mail-Benutzer,

Wir migrieren alle E-Mail-Konten auf das neueste Update von Outlook Web App 
2021. Daher müssen alle aktiven Kontoinhaber überprüfen und sich anmelden, 
damit das Upgrade und die Migration jetzt automatisch wirksam werden. Dies 
geschieht, um die Sicherheit und Effizienz aufgrund der neuesten 
Spam-Nachrichten zu verbessern.

Um Dienstunterbrechungen zu vermeiden, klicken Sie bitte auf den folgenden 
Link, um Ihre Beiträge zu aktualisieren
Outlook Web App 2021​ und melden Sie sich an, 
um mehrere Spam-Mails zu migrieren und zu blockieren.

Wenn Sie Ihr Konto nicht innerhalb von 24 Stunden übertragen, wird Ihr Konto 
vorübergehend gesperrt, sodass Sie keine E-Mails empfangen / senden können.

IKT-Helpdesk
Informationstechnologie

Bug#972573: RFP: crowdsec -- lightweight agent to detect and respond to bad behaviours. It also automatically benefits from our global community-wide IP reputation database

[Cyril Brulebois]

Control: retitle -1 RFP: crowdsec -- lightweight and collaborative security 
engine

Hi again,

Antoine Beaupre  (2020-10-20):
> (*) CrowdSec ships by default with scenario (brute force, port scan,
> web scan, etc.) adapted for most context, but you can easily extend it
> by picking more of them from the hub. It is also very easy to adapt an
> existing one or create one yourself.
> 
> 
> 
> This is similar to fail2ban and sshguard, but with the extra touch
> that it allows for federation and distribution of blocklists. It also
> integrates with Prometheus, also packaged in Debian.
> 
> I haven't tested it. I guess it could be maintained by the Go team?
> 
> Source code is available here: https://github.com/crowdsecurity/crowdsec
> 
> The software is free (MIT), but to get access to the crowd-sourced
> reputation data, you must also share it. The server-side of things is
> also non-free.

For completeness, here are the current descriptions:

Description: lightweight and collaborative security engine
 Crowdsec is a lightweight security engine, able to detect and remedy
 aggressive network behaviour. It can leverage and also enrich a
 global community-wide IP reputation database, to help fight online
 cybersec aggressions in a collaborative manner.
 .
 Crowdsec can read many log sources, parse and also enrich them, in
 order to detect specific scenarios, that usually represent malevolent
 behaviour. Parsers, Enrichers, and Scenarios are YAML files that can
 be shared and downloaded through a specific hub, as well as be created
 or adapted locally.
 .
 Detection results are available for crowdsec, its CLI tools and
 bouncers via an HTTP API. Triggered scenarios lead to an alert, which
 often results in a decision (e.g. IP banned for 4 hours) that can be
 consumed by bouncers (software components enforcing a decision, such
 as an iptables ban, an nginx lua script, or any custom user script).
 .
 The CLI allows users to deploy a metabase Docker image to provide
 simple-to-deploy dashboards of ongoing activity. The crowdsec daemon
 is also instrumented with prometheus to provide observability.
 .
 Crowdsec can be used against live logs ("a la fail2ban"), but can
 also work on cold logs to help in a forensic context, to build an
 analysis for past events.
 .
 On top of that, crowdsec aims at sharing detection signals amongst
 all participants, to pre-emptively allow users to block likely
 attackers. To achieve this, minimal meta-information about the attack
 is shared with the CrowdSec organization for further retribution.
 .
 Users can also decide not to take part into the collective effort via
 the central API, and to register on a local API instead.


I'm wondering what to do with the default behaviour. As discussed with
upstream, shared data is meant to be minimal (and can be sent over Tor).

The machine is “fingerprinted” through machineid + random suffix, that
acts as a username (plus a random password).

Upon a detection, this is sent:
 - Machine fingerprint
 - Attacker IP
 - Scenario name
 - Time of start/end of attack
 - NOT SHARED: actual logs

Every N hours, the list of configured scenarios is sent, and a list of
possible bad IPs matching those services is received in return.


Would it seem reasonable to enable by default the automated registration
of the host when the package is installed (after all, as the name and
the description suggest, the goal is to share info with a crowd), or
would that seem to be unwelcome in Debian?


I'm all for *not* phoning back by default, but this particular package
aims at working in a collaborative manner, and the incentive to share if
you want to benefit from the collective efforts doesn't seem entirely
crazy to me.


Thanks for your input!

Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/


signature.asc
Description: PGP signature

Bug#980080: Failed to read server status: Transport endpoint is not connected

[Harald Dunkel]

Package: systemd
Version: 247.2-4

I do not know how my host got into this state

root@srvl065:~# systemctl status
Failed to read server status: Transport endpoint is not connected

but AFAICT this is not supposed to happen. Google doesn't provide a
recovery procedure, i.e. this host is dead.


Regards
Harri

Bug#977957: spamassassin: patch

[Roel van Meer]

Dear maintainer,

this small fix will solve the problem that sa-compile cannot be installed  
while start-stop-daemon is dpkg-diverted. Since I don't know which workflow  
you prefer, there's also a merge request for it at

https://salsa.debian.org/debian/spamassassin/-/merge_requests/5

Thanks for your time,

Roel
>From 41840d3b51cf08403d2404693f6e45c9123b53d9 Mon Sep 17 00:00:00 2001
From: Roel van Meer 
Date: Wed, 23 Dec 2020 21:15:07 +0100
Subject: [PATCH] postinst: Fix perms only if dir exists

If spamassassin is installed via the debian installer while
start-stop-daemon is diverted via dpkg-divert, sa-compile will not have
run, so the output dir doesn't exist when the postinst script tries to
change its permissions. That causes an error while configuring
sa-compile.

Fix that by checking if the dir exists.

This may still mean the permissions aren't set properly after the
package has been installed (because dpkg-diverting start-stop-daemon
means that sa-compile hasn't been run), but at least the package
installs now. If you run sa-compile manually afterwards you can set the
permissions correctly afterwards as well.

Closes: #977957
---
 debian/sa-compile.postinst | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/debian/sa-compile.postinst b/debian/sa-compile.postinst
index 5056f6c..3f15f22 100644
--- a/debian/sa-compile.postinst
+++ b/debian/sa-compile.postinst
@@ -18,12 +18,14 @@ sa_compile() {
 start-stop-daemon --chuid $OWNER:$GROUP --start \
 --exec /usr/bin/sa-compile -- --quiet
 # Fixup perms -- group and other should be able to
 # read and execute, but never write.  Works around
 # sa-compile's failure to obey umask.
-runuser -u $OWNER -- \
+if [ -d "$output_dir" ]; then
+runuser -u $OWNER -- \
 chmod -R go-w,go+rX "$output_dir"
+fi
 if command -v invoke-rc.d >/dev/null 2>&1; then
 invoke-rc.d --quiet spamassassin status > /dev/null && \
   invoke-rc.d spamassassin reload > /dev/null 2>&1 || true
 else
 /etc/init.d/spamassassin reload > /dev/null 2>&1 || true
-- 
2.20.1

Bug#980079: mumble-server: service restart and stop borked

[Nils König]

I must correct myself.

As I ofc only remembered after sending the bug report, I did already change 
the initscript once before to start as root (so it can read the root-owned ssl 
certs once on startup, before dropping privileges)

So in the default config, the --user switches shouldn't be a problem (but with 
CAPABILITIES enabled they probably still are) and the pidfile-dir permission 
should be the only problem.

~~ Nils

Bug#980039: freedombox: Setup Wizard stuck on the welcome screen

[James Valleroy]

On Wed, 13 Jan 2021 11:25:26 +0100 Christian Perrier 
 wrote:
> Version: 20.21~bpo10+1
> ...
> Anyway, the problem is simple : when launching the initial setup wizard,
> the screen doesn't for further than the welcome screen. The page reload
> every 5 seconds or so, I left it doint this for hours, filling up my
> Apache logsbut nothing more happens.
> 

Can you please check the logs of plinth service?
E.g. run "journalctl -u plinth" as root, and look for any repeating error 
messages.

> -- System Information:
> Distributor ID:   Raspbian
> Description:  Raspbian GNU/Linux 10 (buster)

Could you please share how you installed freedombox package?



OpenPGP_signature
Description: OpenPGP digital signature

Bug#980079: mumble-server: service restart and stop borked

[Nils König]

Package: mumble-server
Version: 1.3.0~git20190125.440b173+dfsg-2
Severity: normal

Hi,

currently /etc/init.d/mumble-server stop doesn't does not stop the murmurd
and "restart" spawns an additional instance of mumble-server, leading to
various problems. I'd assume "force-reload" is similarly affected.

This is caused by two separate issues:

First the init script specifies "--user $USER", where $USER is "root"
by default. But murmur will (by default) drop itself to "mumble-server"
user; so this flag prevents start-stop-daemon from finding the process.
Removing the --user switches resolves this part. I've included the modified 
init-script below.

Second murmur does not write its own pidfile in the default setup.
I was able to fix this with
   chown root:mumble-server $PIDDIR && chmod g+w PIDDIR
This is a bit crude though and ideally murmurd would write its pidfile
_before_ dropping privileges instead if that's possible.
Apparently murmurd already does read ssl certificates before dropping
privileges.

There's also a related upstream issue, albeit apparently stale:
 https://github.com/mumble-voip/mumble/issues/2388

~~ Nils



-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 10 (buster)
Release:10
Codename:   buster
Architecture: armv7l

Kernel: Linux 5.4.83-v7+ (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mumble-server depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.71
ii  libatomic1 8.3.0-6+rpi1
ii  libavahi-client3   0.7-4+b1
ii  libavahi-common3   0.7-4+b1
ii  libavahi-compat-libdnssd1  0.7-4+b1
ii  libc6  2.28-10+rpi1
ii  libcap21:2.25-2
ii  libgcc11:8.3.0-6+rpi1
ii  libprotobuf17  3.6.1.3-2+rpi1
ii  libqt5core5a   5.11.3+dfsg1-1+rpi1+deb10u4
ii  libqt5dbus55.11.3+dfsg1-1+rpi1+deb10u4
ii  libqt5network5 5.11.3+dfsg1-1+rpi1+deb10u4
ii  libqt5sql5 5.11.3+dfsg1-1+rpi1+deb10u4
ii  libqt5sql5-sqlite  5.11.3+dfsg1-1+rpi1+deb10u4
ii  libqt5xml5 5.11.3+dfsg1-1+rpi1+deb10u4
ii  libssl1.1  1.1.1d-0+deb10u4+rpt1
ii  libstdc++6 8.3.0-6+rpi1
ii  libzeroc-ice3.73.7.2-4
ii  lsb-base   10.2019051400+rpi1

mumble-server recommends no packages.

mumble-server suggests no packages.

-- Configuration Files:
/etc/init.d/mumble-server changed:
PATH=/sbin:/bin:/usr/sbin:/usr/bin
NAME=mumble-server
DESC="Mumble VoIP Server"
PIDDIR=/run/$NAME
PIDFILE=$PIDDIR/$NAME.pid
DAEMON=/usr/sbin/murmurd
#USER=mumble-server
# mumble will drop to 'mumble-server' itself
USER=root
GROUP=mumble-server
test -x $DAEMON || exit 0
INIFILE=/etc/mumble-server.ini
DAEMON_OPTS="-ini $INIFILE"
MURMUR_USE_CAPABILITIES=0
MURMUR_LIMIT_NOFILE=0
if [ -f /etc/default/$NAME ] ; then
. /etc/default/$NAME
fi
. /lib/init/vars.sh
. /lib/lsb/init-functions
if [ "$MURMUR_LIMIT_NOFILE" -gt 0 ] ; then
ulimit -n $MURMUR_LIMIT_NOFILE
fi
case "$1" in
  start)
[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
[ -d $PIDDIR ] || install -o $USER -d $PIDDIR
if [ "$MURMUR_USE_CAPABILITIES" != "1" ] ; then
  start-stop-daemon --start --quiet \
--pidfile $PIDFILE \
--chuid $USER:$GROUP \
--exec $DAEMON \
-- $DAEMON_OPTS
else
  start-stop-daemon --start --quiet \
--pidfile $PIDFILE \
--exec $DAEMON \
-- $DAEMON_OPTS
fi
case "$?" in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
;;
  stop)
[ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
start-stop-daemon --stop --quiet \
--retry=TERM/30/KILL/5 \
--pidfile $PIDFILE \
--exec $DAEMON
#--user $USER \
case "$?" in
0|1)rm -f $PIDFILE
[ "$VERBOSE" != no ] && log_end_msg 0
;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
;;
  status)
if start-stop-daemon --test --stop --quiet \
--pidfile $PIDFILE \
--exec $DAEMON
#--user $USER \
then
[ "$VERBOSE" != no ] && echo "$DESC is running."
exit 0
else
[ "$VERBOSE" != no ] && echo "$DESC is not running"
exit 3
fi
;;
  force-reload)
#--user $USER \
start-stop-daemon --stop --test --quiet \
 

Bug#974123: Still wrong Bootloader installed at Banana Pi M2 Ultra

[Bernhard]

Hello,

I repeated the test with current daily images:
Directory: 
https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/
Concatenated the two files:
- firmware.none.img.gz
- partition.img.gz

U-Boot Version: 2021.01~rc4+dfsg-2

Installation starts and the external SD-Card was selected for guided 
partitioning.

At the end, there was the messagt:
"GRUB installation failed"
"The grub-pc package failed to install into /target/."
"Without the GRUB boot loader, the installed system will not boot."

Best regards and thank you for your support.
Bernhard



signature.asc
Description: This is a digitally signed message part

Bug#980078: ITP: dde-session-shell -- dde-session-shell module

[Hu Feng]

Package: wnpp
Severity: wishlist
Owner: Hu Feng 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name    : dde-session-shell
  Version : 5.1.0.22
  Upstream Author : justforlxz 
* URL : https://github.com/linuxdeepin/dde-session-shell
  License : GPL-3
  Programming Lang: C++
  Description : deepin desktop-environment - dde-session-shell module

lightdm-deepin-greeter:login，the entry to the desktop.
.
dde-lock: lock screen, to protect privacy.
.
dde-shutdown: shutdown, provide some options like shutdown, reboot and more.
.
deepin-greeter: actual call the lightdm-deepin-greeter.
.
I intend to co-maintain this package inside pkg-deepin group.

Bug#969351: RFS: jgmenu/4.2.1-1 [ITP] -- simple modern standalone X11 menu

[Leandro Cunha]

Hi,

I deleted this package at mentors because I decided to return the
status of ITP bug to RFP, the package has several problems and Lintian
reports to be solved that with time I must analyze it better and in
the meantime I left it free in case anyone is interested in working on
it.

Thank you bartm for closing this bug.

-- 
Cheers,
Leandro Cunha
Debian Contributor and developer.

Bug#882210: RFP: jgmenu -- simple modern standalone X11 menu

[Leandro Cunha]

Hi,

This package had several Lintian errors being reported and some
problems detected to be solved.
I saw after a few months that the upstream recently updated this
package, but I will still sit down with
more time and I will test by redoing all the work from scratch and
analyzing problem by problem. But
as long as I don't change to ITP for this package again, feel free to
work on packaging.

-- 
Cheers,
Leandro Cunha
Debian Contributor and developer.

Bug#980074: kimageformats: AVIF images fail to display, package compiled without libavif

[Christopher Cormier]

Source: kimageformats
Version: 5.78.0-1
Severity: wishlist
X-Debbugs-Cc: christophercorm...@protonmail.com

Dear Maintainer,

The new version of KImageFormats, 5.78, includes support
for AVIF images. However, with the version that has been
uploaded to Experimental, they still fail to display.

The build log suggests libavif is a missing optional dependency.
This is already in the repositories so it should hopefully be a
trivial addition to the builddeps as long as it causes no other issues.

Thanks,

Christopher

Bug#980077: apt-cacher: please recognize new pdiff name format by default

[Aaron M. Ucko]

Package: apt-cacher
Version: 1.7.21+nmu1
Severity: normal

AFAICT, metadata deltas now have filenames along the lines of
T-2021-01-13-2000.21-F-2021-01-13-2000.21.pdiff, which don't match
apt-cacher's default pdiff_files_regexp; as such, apt winds up falling
back on downloading full lists.  I've had good results by generalizing
the regexp to

  pdiff_files_regexp = 
(?:^|[/-])2\d{3}-\d{2}-\d{2}-\d{4}\.\d{2}\.(?:gz|pdiff.*)$

Could you please take a look?

Thanks!

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (300, 
'unstable-debug'), (300, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, x32

Kernel: Linux 5.10.0-1-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages apt-cacher depends on:
ii  cdebconf [debconf-2.0]  0.256
ii  debconf [debconf-2.0]   1.5.74
ii  ed  1.16-1
ii  init-system-helpers 1.60
ii  libdpkg-perl1.20.5
ii  libfilesys-df-perl  0.92-6+b6
ii  libio-interactive-perl  1.022-1
ii  libio-interface-perl1.09-2
ii  libipc-shareable-perl   0.61-2
ii  libnetaddr-ip-perl  4.079+dfsg-1+b5
ii  libsys-syscall-perl 0.25-6
ii  libwww-curl-perl4.17-7+b1
ii  libwww-perl 6.51-1
ii  lsb-base11.1.0
ii  perl5.32.0-6
ii  update-inetd4.51

Versions of packages apt-cacher recommends:
ii  libberkeleydb-perl0.64-1+b1
ii  libio-compress-lzma-perl  2.100-1

Versions of packages apt-cacher suggests:
ii  libfreezethaw-perl   0.5001-2.1
ii  libio-socket-inet6-perl  2.72-2.1

-- Configuration Files:
/etc/apt-cacher/apt-cacher.conf changed:
group = www-data
user = www-data
path_map = debian http.debian.net/debian ; security 
security.debian.org/debian-security ; secure-testing 
secure-testing.debian.net/debian-secure-testing ; non-US 
debian.teleglobe.net/non-US non-us.debian.org/debian-non-US ; debathena 
debathena.mit.edu/apt ; debian-ports ftp.ports.debian.org/debian-ports ; 
debian-debug debug.mirrors.debian.org/debian-debug
allowed_hosts = *
clean_cache = 0
pdiff_files_regexp = (?:^|[/-])2\d{3}-\d{2}-\d{2}-\d{4}\.\d{2}\.(?:gz|pdiff.*)$


-- debconf information:
* apt-cacher/mode: daemon

Bug#911430: Closing 911430

[Abhijith PA]

Hello,

I see that in latest upload[1] of spice-vdagent in unstable you have 
changed maintainer to Debian QA. If this is the case, shouldn't we 
close 911430[2]. Or is it still up for adoption ?

--abhijith

[1] - 
https://tracker.debian.org/news/1197999/accepted-spice-vdagent-0200-2-source-into-unstable/
[2] - https://bugs.debian.org/911430


signature.asc
Description: PGP signature

Bug#980071: gnome-shell: Using suspend in the gnome-shell power off/log out menu does log out and suspend in the wrong order

[A Ozbay]

Package: gnome-shell
Version: 3.38.2-1
Severity: grave
Tags: security
Justification: user security hole
X-Debbugs-Cc: ago_debian...@protonmail.com, Debian Security Team 


When I use the suspend option in the power off/log out menu, gnome-shell first 
logs me off, as if I clicked log off instead. Then, when I enter my password on 
this screen, my computer enters suspend mode. Upon resuming my pc from suspend, 
I am logged into my user account without a password prompt. 

This enables a person with physical access to the machine in a suspended state 
to log into my account without any password required whatsoever which is a 
grave security issue.



-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.4 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-1
ii  evolution-data-server3.38.2-2
ii  gir1.2-accountsservice-1.0   0.6.55-3
ii  gir1.2-atspi-2.0 2.38.0-2
ii  gir1.2-freedesktop   1.66.1-1+b1
ii  gir1.2-gcr-3 3.38.0-1
ii  gir1.2-gdesktopenums-3.0 3.38.0-2
ii  gir1.2-gdm-1.0   3.38.2.1-1
ii  gir1.2-geoclue-2.0   2.5.7-2
ii  gir1.2-glib-2.0  1.66.1-1+b1
ii  gir1.2-gnomebluetooth-1.03.34.3-2
ii  gir1.2-gnomedesktop-3.0  3.38.2-1
ii  gir1.2-gstreamer-1.0 1.18.2-1
ii  gir1.2-gtk-3.0   3.24.24-1
ii  gir1.2-gweather-3.0  3.36.1-1
ii  gir1.2-ibus-1.0  1.5.23-2
ii  gir1.2-mutter-7  3.38.2-1
ii  gir1.2-nm-1.01.28.0-2+b1
ii  gir1.2-nma-1.0   1.8.30-1
ii  gir1.2-pango-1.0 1.46.2-3
ii  gir1.2-polkit-1.00.105-29
ii  gir1.2-rsvg-2.0  2.50.2+dfsg-1
ii  gir1.2-soup-2.4  2.72.0-2
ii  gir1.2-upowerglib-1.00.99.11-2
ii  gjs  1.66.1-1
ii  gnome-backgrounds3.38.0-1
ii  gnome-settings-daemon3.38.1-2
ii  gnome-shell-common   3.38.2-1
ii  gsettings-desktop-schemas3.38.0-2
ii  gstreamer1.0-pipewire0.3.15-1
ii  libatk-bridge2.0-0   2.38.0-1
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-9
ii  libcairo21.16.0-5
ii  libecal-2.0-13.38.2-2
ii  libedataserver-1.2-253.38.2-2
ii  libgcr-base-3-1  3.38.0-1
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libgirepository-1.0-11.66.1-1+b1
ii  libgjs0g 1.66.1-1
ii  libgles2 1.3.2-1
ii  libglib2.0-0 2.66.4-1
ii  libglib2.0-bin   2.66.4-1
ii  libgnome-autoar-0-0  0.2.4-2
ii  libgnome-desktop-3-193.38.2-1
ii  libgraphene-1.0-01.10.2-1
ii  libgtk-3-0   3.24.24-1
ii  libical3 3.0.8-2
ii  libjson-glib-1.0-0   1.6.0-2
ii  libmutter-7-03.38.2-1
ii  libnm0   1.28.0-2+b1
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libpolkit-agent-1-0  0.105-29
ii  libpolkit-gobject-1-00.105-29
ii  libpulse-mainloop-glib0  14.0-2
ii  libpulse014.0-2
ii  libsecret-1-00.20.4-1
ii  libsystemd0  247.2-4
ii  libwayland-server0   1.18.0-2~exp1.1
ii  libx11-6 2:1.6.12-1
ii  libxfixes3   1:5.0.3-2
ii  python3  3.9.1-1

Versions of packages gnome-shell recommends:
ii  bolt  0.9-1
ii  chrome-gnome-shell10.1-5
ii  gdm3  3.38.2.1-1
ii  

Bug#979986: Please, drop composer dependency

[Dmitry Smirnov]

On Thursday, 14 January 2021 12:03:32 AM AEDT David Prévot wrote:
> That allowed you to discover an actual upstream oversight: both files
> are (bit to bit) identical. You can safely add
>   --exclude /usr/share/civicrm/CRM/Grant/Export/Form/Map.php
> to you phpab call. That file redefines CRM_Pledge_Export_Form_Map (it
> even pretends that “[t]his class gets the name of the file to upload”),
> and report it upstream. Please, do report it upstream.

Thanks for your comments. Reported as

  https://lab.civicrm.org/dev/core/-/issues/2298


> I suppose
> CRM_Grant_Export_Form_Map is never used (yet it is mentioned in
> CRM/Grant/Task.php) but detecting such issue at build time instead of
> waiting for something bad to happen at runtime seems definitively worth
> the effort.

Makes sense, thanks.


> About vendoring, I notice you bundle components that are actually
> available as Debian packages (e.g., symfony). I wonder which one will
> actually be loaded if packages offering the same classes you’re
> vendoring are installed.

Vendored version should be loaded first. Bundled Symfony is a historical
issue since when I was maintaining CiviCRM in backports where Symfony was
too old.

These days I have not yet made up my mind whether I will be supporting
build for backports but I want to keep my options open in case of
incompatibility with newer releases, etc. Also I fear run-time errors
due to Symfony version difference. I may have seen some issues before...


> I noticed your following comment:
>   //Incompatible with Symfony Component(s) 4+:
> yet ~4.4 is explicitly allowed composer.json (but I agree that 3.4.40 is
> shipped according to composer.lock), did you dig up the actual problem?

Most certainly an outdated comment from earlier releases. Compatibility
with Symfony 4.4 is a relatively new feature. I'll have another look.


> Security issues are found in PHP code all the time, given how poorly
> maintained some packages are (either upstream or downstream), exposing
> them all to your users is definitely something you want to avoid IMHO.

Understood. I'll think about it. Perhaps there can be a good balance
between vendored and system components determined on case-by-case basis...

Anyway, perhaps it might be an easy task for you to get rid of Composer
but for me it is very difficult. As I've mentioned in my previous email,
both "CRM/Core/ClassLoader.php" and "CRM/Extension/ClassLoader.php"
explicitly call Composer so the following error is thrown:


Fatal error: CRM_Extension_ClassLoader::register(): The script tried to
execute a method or access a property of an incomplete object.
Please ensure that the class definition 
Composer\Autoload\ClassLoader
of the object you are trying to operate on was loaded _before_ unserialize()
gets called or provide an autoloader to load the class definition in
/usr/share/civicrm/CRM/Extension/ClassLoader.php on line 74


That might require not-so-trivial patching that is beyond my level of
expertise.

-- 
Cheers,
 Dmitry Smirnov
 GPG key : 4096R/52B6BBD953968D1B

---

"A closer look at U.S. deaths due to COVID-19"
2020-11-26, The Johns Hopkins News-Letter
-- 
https://notthebee.com/article/a-few-days-ago-johns-hopkins-published-a-study-saying-corona-is-nbd-they-then-deleted-it-read-it-here-in-its-entirety
-- 
https://web.archive.org/web/20201126223119/https://www.jhunewsletter.com/article/2020/11/a-closer-look-at-u-s-deaths-due-to-covid-19


signature.asc
Description: This is a digitally signed message part.

Bug#980076: command-not-found: Patch to speed up cnf-update-db

[Diego Ongaro]

Package: command-not-found
Version: 20.10.1-1
Severity: normal
Tags: patch

Dear Maintainer,

cnf-update-db is fairly slow on my machine. After I remove
/var/lib/command-not-found/commands.db.metadata, cnf-update-db takes about 16
seconds on my machine.

A large chunk of this time is checking whether files are in /usr/bin and
similar directories. I'm attaching a small patch that optimizes this check,
taking the same update down to about 10 seconds on my machine. It's a 4-line
change that seems like an easy win.

I confirmed that I have the same number of commands and packages in the
commands.db database with and without this change.

Please let me know if you prefer to receive this patch in a different format or
channel.

Regards,
Diego

-- System Information:
Debian Release: 10.7
  APT prefers stable-updates
  APT policy: (560, 'stable-updates'), (550, 'stable'), (160, 'testing'), (150, 
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0-0.bpo.2-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages command-not-found depends on:
ii  apt-file 3.2.2
ii  lsb-release  10.2019051400
ii  python3  3.7.3-1
ii  python3-apt  1.8.4.3

command-not-found recommends no packages.

Versions of packages command-not-found suggests:
pn  snapd  
From: Diego Ongaro 
Date: Wed, 13 Jan 2021 17:44:50 -0800
Subject: cnf-update-db: Speed up Contents files

---
 CommandNotFound/db/creator.py | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/CommandNotFound/db/creator.py b/CommandNotFound/db/creator.py
index 08564f5..fce5e67 100755
--- a/CommandNotFound/db/creator.py
+++ b/CommandNotFound/db/creator.py
@@ -4,6 +4,7 @@ import errno
 import json
 import logging
 import os
+import re
 import sqlite3
 import subprocess
 import sys
@@ -234,12 +235,12 @@ class DbCreator:
 def _parse_single_contents_file(self, con, f, fp):
 # read header
 suite=None  # FIXME
+pattern = re.compile(b'usr/sbin|usr/bin|sbin|bin')
 
 for l in fp:
-l = l.decode("utf-8")
-if not (l.startswith('usr/sbin') or l.startswith('usr/bin') or
-l.startswith('bin') or l.startswith('sbin')):
+if not pattern.match(l):
 continue
+l = l.decode("utf-8")
 try:
 command, pkgnames = l.split(None, 1)
 except ValueError:

Bug#930334: lxqt

[Amy Kos]

Hi,

Those are two independent cases.

1.)
The MRs for src:libfm and src:libfm-qt are for xarchiver command.
Long time ago xarchiver upstream changed from --add-to to --compress
The best place to change would be upstream lxde and lxqt.
At least for lxde there is an old bug:
https://github.com/lxde/libfm/issues/35
It probably just got forgotten.
It's broken on buster, we should patch it for bullseye.
Thanks for the "3.0 (quilt)" hint. I'll try to change the MRs at the end of the 
week.

2.)
The MR for src:lxqt-metapackages is optional, we don't have to touch it.
Only if we want lxqt-archiver to be installed as default.
Therefore it adds lxqt-archiver in first place so it will be installed
instead of xarchiver when users install lxqt (31) and lxqt-core (31) packages.
(Now we have lxqt (30) and lxqt-core (30) packages which installs xarchiver.)
We should wait until lxqt-archiver enters debian repositories, it is still in 
NEW.

Cheers,
Amy

Bug#980035: [Aptitude-devel] Bug#980035: aptitude: segmentation fault when starting aptitude

[Vincent Lefevre]

On 2021-01-14 02:14:29 +0100, Axel Beckert wrote:
> Since Julian has uploaded a fix as apt/2.1.18, would you mind checking
> if you can still reproduce the issue in any way?

I couldn't manage to reproduce it with apt 2.1.18.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#911430: Closing 911430

[Adrian Bunk]

On Thu, Jan 14, 2021 at 05:48:26AM +0530, Abhijith PA wrote:
> Hello,
> 
> I see that in latest upload[1] of spice-vdagent in unstable you have 
> changed maintainer to Debian QA. If this is the case, shouldn't we 
> close 911430[2]. Or is it still up for adoption ?

The Debian QA group is the maintainer of all packages that are up for 
adoption:
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#orphaning

> --abhijith
>...

cu
Adrian

Bug#980067: libqmatrixclient: new upstream release, with a rename

[Hubert Chathi]

On Wed, 13 Jan 2021 17:39:39 -0500, Andres Salomon  said:

> Yeah, that would make sense. I can join the team.

I've added you to the matrix-team group on salsa.  Feel free to upload
libquotient as a team-maintained package.  I had been waiting until
the next quaternion release, which would use libquotient, before
uploading the renamed package, but since you need it for spectral, go
ahead and upload.  I'm assuming it would be uploaded as a new source
package.

-- 
Hubert Chathi  -- https://www.uhoreg.ca/
Jabber: hub...@uhoreg.ca -- Matrix: @uhoreg:matrix.org
PGP/GnuPG key: 4096R/F24C F749 6C73 DDB8 DCB8  72DE B2DE 88D3 113A 1368

Bug#935654: matrix-synapse: /etc/init.d/matrix-synapse stop doesn't work

[devel]

Hello,


Am Wed, 13 Jan 2021 13:57:07 +0100
schrieb "Andrej Shadura" :

> > indeed matrix-synapse does it properly - it just needs the "--daemonize" 
> > option.
> > See my updated patch: it uses "--daemonize" (for matrix-synapse) instead of
> > "--background" (for start-stop-daemon).
> > (the removal of "--exec" in "stop" is unrelated and still necessary)
> > 
> > This fixes the start/stop issue.  
> 
> Unfortunately, that would undo the fix for the bug #920339

yes, let's not repeat history too quickly :)


> I’m going to keep your original fix.

Or maybe contemplate the suggestion in [1] (based on the discussion of the
issue, which you thankfully opened for upstream): add "db_stop" in order to
prevent the file descriptor leakage in the beginning.
(but I am just guessing here, this is not really my field)

Thank you for your care!

Cheers,
Lars


[1] https://github.com/matrix-org/synapse/issues/9099#issuecomment-759697583

Bug#980035: [Aptitude-devel] Bug#980035: aptitude: segmentation fault when starting aptitude

[Axel Beckert]

Control: clone -1 -2
Control: retitle -2 aptitude-run-state-bundle: uses some local files instead of 
only those from the bundle
Control: tag -2 - security
Control: tag -1 + moreinfo
Control: severity -2 normal

Hi Vincent,

Vincent Lefevre wrote:
> With the bundle, the crash occurs while the UI isn't displayed yet.
> But I can see in particular:
> 
> 2300077 stat("/var/lib/dpkg/status", {st_mode=S_IFREG|0644, st_size=3777850, 
> ...}) = 0
> 2300081 openat(AT_FDCWD, "/var/lib/dpkg/arch", O_RDONLY) = -1 ENOENT (No such 
> file or directory)
> 2300082 openat(AT_FDCWD, "/var/lib/dpkg/arch", O_RDONLY) = -1 ENOENT (No such 
> file or directory)
> 2300083 openat(AT_FDCWD, "/var/lib/dpkg/arch", O_RDONLY) = -1 ENOENT (No such 
> file or directory)
> 2300077 stat("/var/lib/apt-xapian-index/index", {st_mode=S_IFREG|0644, 
> st_size=41, ...}) = 0
> 2300077 openat(AT_FDCWD, "/var/lib/apt-xapian-index/index", O_RDONLY) = 36
> 2300077 openat(AT_FDCWD, "/var/lib/aptitude//pkgstates", O_RDONLY) =
> 36


Yep, and the later seems to have bitten me a bit when testing the
bundle. At least chromium had no more forbidden version afterwards
which was unexpected.

Then again, /var/lib/aptitude//pkgstates is in your bundle as
.//var/lib/aptitude/pkgstates, so there's no reason for a fall-back or
so.

> 2300077 openat(AT_FDCWD, "/var/lib/debtags/package-tags", O_RDONLY) = -1 
> ENOENT (No such file or directory)
> 222 symlinkat("/var/local/apt/./Packages", 4, 
> ".//var/lib/apt/lists/_var_local_apt_._Packages") = 0
> 
> while most files are read from the /tmp version.
> 
> So, as this seems to depend on the system, this is not surprising.

Ack.

> > But as mentioned in #980037 this seems normal in such a case without
> > a special kernel. So thanks for the bug report!
> 
> Note that I do *not* have a special kernel.

I know. That's the reason why I mentioned this.

> So this is unrelated.

Not necessarily. It's possible. But IMHO unlikely.

Since Julian has uploaded a fix as apt/2.1.18, would you mind checking
if you can still reproduce the issue in any way?

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#979995: There should be a sensible compile time default for the location of the file that contains trusted CA certificates

[Ryan Tandy]

On Wed, Jan 13, 2021 at 01:27:52PM +0100, Andras Korn wrote:
Can you somehow make the library complain very loudly when an attempt 
is made to use CACERTDIR, but the setting is ignored?


This is not sarcastic, but a good faith question: if it had printed 
something to stderr, would you have seen it? I don't think I have any 
way to make something appear in (for example) sssd's own log file.


In fact, it does already log a warning, but I suppose most applications 
using the library probably don't enable any log level.


https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_4/libraries/libldap/tls_g.c#L187-190

On Wed, Jan 13, 2021 at 01:44:07PM +0100, Andras Korn wrote:

OK, looking further, part of the problem is that I didn't have
libldap-common installed, thus no /etc/ldap/ldap.conf.

Since this (and the accompanying manpage) is all that libldap-common
contains: what's the rationale for having these in a separate package?


Policy 8.2: "If your package contains files whose names do not change 
with each change in the library shared object version, you must not put 
them in the shared library package."


https://bugs.debian.org/330695


The libldap package only Recommends libldap-common (which is why I didn't
have it); however, it is libldap-common that enables the sensible defaults.

Why shouldn't libldap come with the sensible defaults itself?


It's your decision whether to install Recommends or not, but AFAIK it's 
generally not considered a bug if some feature or behaviour is missing 
when Recommends are not installed.


Why isn't the default in the code of libldap → this is upstream's 
decision, and I won't introduce a Debian-local change to override it, 
sorry.


Why isn't the config file shipped in the libldap package → see above.

hope this helps,
Ryan

Bug#980074: kimageformats: AVIF images fail to display, package compiled without libavif

[Norbert Preining]

Hi Christopher,

> The build log suggests libavif is a missing optional dependency.

Indeed, thanks for the heads-up. libavif-dev added to the B-D which
should enable AVIF support. Committed to git repo and will be in the
next upload.

Best

Norbert

--
PREINING Norbert  https://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#980073: usbguard: Unable to temporarily allow device with kernel 5.9+

[Tomas Janousek]

Package: usbguard
Version: 0.7.8+ds-2+b1
Severity: normal
Tags: upstream

Since upgrading to linux-image-5.9.0-amd64, it's no longer possible to 
usbguard allow-device without -p, as the device is deauthorized again 
immediately.

This issue was reported upstream as 
https://github.com/USBGuard/usbguard/issues/444 and fixed by 
https://github.com/USBGuard/usbguard/pull/440, and I can confirm that 
adding that patch to the Debian package fixes the problem. The issue 
only affects kernels since 5.9.0 because a change uevent is now emitted 
after the device is authorized: 
https://bugzilla.kernel.org/show_bug.cgi?id=209469

The issue is fixed in usbguard 1.0.0 which was released today: 
https://github.com/USBGuard/usbguard/releases/tag/usbguard-1.0.0

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (990, 'stable'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-debug'), (500, 'unstable'), (500, 'stable'), 
(1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_CPU_OUT_OF_SPEC, 
TAINT_USER, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages usbguard depends on:
ii  dbus 1.12.20-1
ii  init-system-helpers  1.60
ii  libaudit11:3.0-2
ii  libc62.31-9
ii  libcap-ng0   0.7.9-2.2+b1
ii  libgcc-s110.2.1-3
ii  libglib2.0-0 2.66.4-1
ii  libseccomp2  2.5.1-1
ii  libstdc++6   10.2.1-3
ii  libusbguard0 0.7.8+ds-2+b1

usbguard recommends no packages.

usbguard suggests no packages.

-- Configuration Files:
/etc/usbguard/usbguard-daemon.conf [Errno 13] Operace zamítnuta: 
'/etc/usbguard/usbguard-daemon.conf'

-- no debconf information

-- 
Tomáš Janoušek, a.k.a. Pivník, a.k.a. Liskni_si, https://work.lisk.in/

Bug#980069: Better documentation of x-terminal-emulator

[Simon McVittie]

On Wed, 13 Jan 2021 at 22:49:27 +, Bastien Roucariès wrote:
> gnome-terminal -e sleep 60

The upstream-provided gnome-terminal executable does not claim to be an
implementation of the x-terminal-emulator alternative. It has its own
command-line interface, which uses GNU-style long-option parsing (unlike
xterm). If we patched it to provide the x-terminal-emulator interface,
that modification would make it incompatible with upstream gnome-terminal,
and with other packages that know how the gnome-terminal interface works.

The Debian-specific script /usr/bin/gnome-terminal.wrapper is what gets
registered as an implementation of x-terminal-emulator if you have the
gnome-terminal package installed. Its command-line interface is almost
a subset of xterm's (it does additionally support --help, which xterm
does not).

If you want gnome-terminal behaviour, run gnome-terminal and pass
gnome-terminal arguments to it; if you want generic x-terminal-emulator
behaviour, run x-terminal-emulator and pass x-terminal-emulator
arguments to it. They are not the same, and programs can only rely on
x-terminal-emulator behaviour if what they run is the x-terminal-emulator
alternative. If they run a specific terminal directly, then they'll get
that specific terminal's behaviour, whatever that might be.

> Moreover some packages noticed that x-terminal-emulator does not wait by 
> default

I'm not sure whether waiting for the executed command to exit is
actually part of the specification for x-terminal-emulator, but
/usr/bin/gnome-terminal.wrapper passes --wait to gnome-terminal, so that
it will behave like xterm in this respect.

Other implementations might not.

> I plan to create a sensible-x-terminal-emulator and thus I need to document;
> * the -e behavior, that  should behave like xterm and do not need to use 
> quotes

https://www.debian.org/doc/debian-policy/ch-customized-programs.html#packages-providing-a-terminal-emulator
describes what you can rely on from an implementation of the
x-terminal-emulator alternative. Anything not written there cannot be
relied on.

Policy promises that "x-terminal-emulator -e sleep 60" does what you think
it does.

Policy does not say anything either way on what
"x-terminal-emulator -e 'sleep 60'" will do. It happens to work with xterm
and with /usr/bin/gnome-terminal.wrapper, but that is not guaranteed.

smcv

Bug#980072: New upstream location and version available

[Bernhard Schmidt]

Package: amavisd-new
Version: 1:2.11.1-4
Severity: wishlist

Hi,

after Marc Martinec, the original author of amavisd-new all but disappeared
from the public a group of amavisd users discussed forking the project. They
got the blessing from the original author here

https://lists.amavis.org/pipermail/amavis-users/2018-October/005458.html

They have moved the upstream repository to gitlab
(https://gitlab.com/amavis/amavis) and have done a 2.12.0 and 2.12.1 release
which fixes a few bugs with 2.11 (notably an issue with outbound DKIM signing
and an issue with MySQL utf8mb4 coding).

It would be really great to have this in Bullseye.

I'm somewhat willing to help because $dayjob depends on amavisd-new on Debian
machines, but my happyness does not depend on co-maintaining yet another Debian
package.

Bernhard

Bug#976080: Info received (Bug#976080: pdfxup doesn't work anymore)

[Michael A Gilchrist]

I found a simple work around: Move the file to /tmp before running 
pdfxup on it.


Whew.

Bug#973554: /etc/cron.monthly/acct does not handle missing wtmp.1

[Ellen Wang]

Here we go:

# ls -l /var/log/wtmp*
-rw-rw-r-- 1 root utmp 198144 Jan  6 09:24 /var/log/wtmp
-rw-r- 1 root adm  88 Jan 13 15:05 /var/log/wtmp.report

# sh -x /etc/cron.monthly/acct
+ LOGROTATE=/etc/cron.daily/logrotate
+ test -x /usr/sbin/accton
+ date
+ echo Login accounting for the month ended Wed Jan 13 15:07:43 PST 2021:
+ echo
+ [ -f /etc/cron.daily/logrotate ]
+ [ -x /usr/sbin/logrotate ]
+ [ -f /var/log/wtmp.1 ]
+ [ -f /var/log/wtmp.1.gz ]
+ ac -f  -p
+ sort -nr -k2
couldn't open file '': No such file or directory
+ echo
+ last -f
last: cannot open : No such file or directory
+ [ -n  ]
+ chown root:adm /var/log/wtmp.report
+ chmod 640 /var/log/wtmp.report

--

What does your script look like?  I ran the one installed in 
/etc/cron.monthly (with 10.7 buster).  Your output looks like there are 
some differences besides not failing.



On 1/13/21 2:16 PM, Marcos Fouces wrote:

Hello Ellen

I renamed temporarily wtmp.1 and i run the script with "set-x" to see
what is going on:

# ./$HOME/Debian/Packages/acct/debian/acct.cron.monthly
+ test -x /usr/sbin/accton
+ echo

+ echo # LOGIN ACCOUNTING MONTHLY REPORT
##
+ echo

+ echo
+ date
+ echo Login accounting for the month ended mié 13 ene 2021 23:09:40
CET:
+ echo
+ test -f /var/log/wtmp.1
+ test -f /var/log/wtmp.1.gz
+ echo Data contained in current wtmp file:
+ ac -p
+ sort -nr -k2
+ echo
+ last
+ chown root:adm /var/log/wtmp.report
+ chmod 640 /var/log/wtmp.report


Could you check this on your machine, please.

Thanks for your bug report.

Greetings,
Marcos.
















Thanks for your bug report.


El dom, 01-11-2020 a las 11:03 -0800, Ellen Wang escribió:

Package: acct
Version: 6.6.4-2

On a newly installed system, /etc/cron.monthly/acct complains:

/etc/cron.monthly/acct:
couldn't open file '': No such file or directory
last: cannot open : No such file or directory

The problem is that the script wants to use /var/log/wtmp.1 instead
of
wtmp if logrotate exists, on the assumption that logrotate has
already
moved wtmp to wtmp.1.  However, this is not true if wtmp is not big
enough to have been rotated.

This patch gets rid of the error:

--- /etc/cron.monthly/acct# 2018-08-23 09:01:38.0 -0700
+++ /etc/cron.monthly/acct  2020-11-01 10:13:58.310091356 -0800
@@ -33,7 +33,10 @@

  gunzip -c /var/log/wtmp.1.gz > "${WTMP}"
  fi
+   fi

+   if [ -n "${WTMP}" ]
+   then
  ac -f "${WTMP}" -p | sort -nr -k2 >>
/var/log/wtmp.report
  echo >> /var/log/wtmp.report
  last -f "${WTMP}" >> /var/log/wtmp.report

Perhaps a better fix would be to fall back to wtmp.1 only if wtmp is
empty.  Alternatively, if we want a monthly report that covers
exactly
one month, then not specifying minsize in /etc/logrotate.d/wtmp is
the
solution.

Bug#951386: uscan: fails to downloads from a “dumb” HTTP git repository

[nicoo]

Control: tags -1 - moreinfo

Hi Xavier,

On Mon, Mar 09, 2020 at 09:42:37PM +0100, Xavier wrote:
> I'm unable to reproduce this bug:

Yes, it looks like two things happened:
- first, I got confused and gave you a watch file that did *not*
  exhibit the bug, instead of my package's original d/watch ;
- second, when I looked at the bug since, I couldn't reproduce either...
  because the watch file was pointed at git.vuxu.org, which implemented
  git's “smart” HTTP transport since.

Sorry for the super-slow reply, it took be a good while to realise what happened

So, here is a script that's a reproducing testcase; it relies on having a
copy of the xe repo (git.vuxu.org/xe) on a “dumb” HTTP remote, here just
 https://nicolas.braud-santoni.eu/tmp/xe.bare

This is the output I get from it here:

$ git clone https://salsa.debian.org/Debian/xe.git
Cloning into 'xe'...
remote: Enumerating objects: 642, done.
remote: Counting objects: 100% (642/642), done.
remote: Compressing objects: 100% (277/277), done.
remote: Total 642 (delta 374), reused 616 (delta 355), pack-reused 0
Receiving objects: 100% (642/642), 136.34 KiB | 293.00 KiB/s, done.
Resolving deltas: 100% (374/374), done.

$ cd xe

$ sed -i s,git\.vuxu\.org/xe/,nicolas.braud-santoni.eu/tmp/xe.bare/, 
debian/watch

$ cat debian/watch
version=4
opts="mode=git, pgpmode=gittag" \
  https://nicolas.braud-santoni.eu/tmp/xe.bare/ refs/tags/v(\d\S+)

$ uscan --force-download -v
uscan info: uscan (version 2.20.5) See uscan(1) for help
uscan info: Scan watch files in .
uscan info: Check debian/watch and debian/changelog in .
uscan info: package="xe" version="0.11-5" (as seen in debian/changelog)
uscan info: package="xe" version="0.11" (no epoch/revision)
uscan info: ./debian/changelog sets package="xe" version="0.11"
uscan info: Found upstream signing keyring: 
debian/upstream/signing-key.asc
uscan info: Process watch file at: debian/watch
package = xe
version = 0.11
pkg_dir = .
uscan info: opts: mode=git, pgpmode=gittag
uscan info: line: https://nicolas.braud-santoni.eu/tmp/xe.bare/ 
refs/tags/v(\d\S+)
uscan info: Parsing mode=git
uscan info: Parsing  pgpmode=gittag
uscan info: line: https://nicolas.braud-santoni.eu/tmp/xe.bare/ 
refs/tags/v(\d\S+)
uscan info: Last orig.tar.* tarball version (from debian/changelog): 
0.11
uscan info: Last orig.tar.* tarball version (dversionmangled): 0.11
uscan info: Execute: git ls-remote 
https://nicolas.braud-santoni.eu/tmp/xe.bare/
uscan info: Found the following matching refs:
 refs/tags/v0.11 (0.11)
 refs/tags/v0.10 (0.10)
 refs/tags/v0.9 (0.9)
 refs/tags/v0.8 (0.8)
 refs/tags/v0.7.0 (0.7.0)
 refs/tags/v0.6.1 (0.6.1)
 refs/tags/v0.6 (0.6)
 refs/tags/v0.5 (0.5)
 refs/tags/v0.4 (0.4)
 refs/tags/v0.3 (0.3)
 refs/tags/v0.2 (0.2)
 refs/tags/v0.1 (0.1)
 HEAD ()
 refs/heads/debian/sid ()
 refs/heads/pristine-tar ()
 refs/heads/upstream ()
 refs/heads/v0.11-5 ()
 refs/tags/debian/0.11-2 ()
 refs/tags/debian/0.11-3 ()
 refs/tags/debian/0.11-4 ()
 refs/tags/debian/0.11-5 ()
 refs/tags/debian/v0.10-1 ()
 refs/tags/debian/v0.11-1 ()
uscan info: Looking at $base = 
https://nicolas.braud-santoni.eu/tmp/xe.bare/ with
$filepattern = refs/tags/v(\d\S+) found
$newfile = refs/tags/v0.11
$newversion  = 0.11
$lastversion = 0.11
uscan info: Upstream URL(+tag) to download is identified as
https://nicolas.braud-santoni.eu/tmp/xe.bare/ refs/tags/v0.11
uscan info: Filename (filenamemangled) for downloaded file: 
xe-0.11.tar.xz
uscan info: Newest version of xe on remote site is 0.11, local version 
is 0.11
uscan info:  => Package is up to date from:
 => https://nicolas.braud-santoni.eu/tmp/xe.bare/ 
refs/tags/v0.11
uscan info:  => Forcing download as requested
uscan info: Downloading upstream package: xe-0.11.tar.xz
Cloning into bare repository '../xe-temporary.21614.git'...
fatal: dumb http transport does not support shallow capabilities
uscan error: Command failed (git clone --bare --depth=1 -b v0.11 
https://nicolas.braud-santoni.eu/tmp/xe.bare/ ../xe-temporary.21614.git)
$ rm -rf /tmp/tmp.FFg74iljuz


test.sh
Description: Bourne shell script


signature.asc
Description: PGP signature

Bug#980067: libqmatrixclient: new upstream release, with a rename

[Jonas Smedegaard]

Quoting Andres Salomon (2021-01-13 23:39:39)
> On Wed, 13 Jan 2021 21:43:22 +0100
> Jonas Smedegaard  wrote:
> 
> > Quoting Andres Salomon (2021-01-13 20:54:55)
> > > Package: libqmatrixclient
> > > Version: 0.5.3.2-1
> > > Severity: wishlist
> > > 
> > > There have been several new releases of this package, with the
> > > latest version being 0.6.3. In addition, the upstream package was
> > > renamed to libQuotient. It would be good to get a newer package
> > > that includes the rename.
> > > 
> > > I'm currently including a bundled version of libQuotient in my
> > > spectral Debian package. I would love to be able to just build
> > > against a libquotient-dev package, once it has been uploaded.
> > > 
> > > If you need help maintaining libqmatrixclient/libquotient, please
> > > let me know.  
> > 
> > Would you perhaps be interested in joining the Matrix team?
> > 
> > That might ease coordination between spectral and quaternion - the
> > only other user of libqmatrixclient currently.
> > 
> 
> Yeah, that would make sense. I can join the team.

Excellent!

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#975166: connectome-workbench: FTBFS: qwt_painter_command.h:85:22: error: field ‘clipPath’ has incomplete type ‘QPainterPath

[s3v]

Dear Maintainer,

I tried to build your package in a sid chroot environment
and I confirm that patch fixes this issue.

Kind Regards

Bug#980070: RFS: mtd-utils/1:2.1.2-2 -- Memory Technology Device Utilities

[Bastian Germann]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "mtd-utils":

 * Package name: mtd-utils
   Version : 1:2.1.2-2
   Upstream Author : David Oberhollenzer
 * URL : http://www.linux-mtd.infradead.org/
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/debian/mtd-utils
   Section : utils

It builds those binary packages:

  libubi-dev - UBIFS Development Libraries
  libmtd-dev - Memory Technology Device Development Libraries
  mtd-utils - Memory Technology Device Utilities

To access further information about this package, please visit the 
following URL:


  https://mentors.debian.net/package/mtd-utils/

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/m/mtd-utils/mtd-utils_2.1.2-2.dsc


Changes since the last upload:

 mtd-utils (1:2.1.2-2) unstable; urgency=medium
 .
   * Enable crypto support (Closes: #960351)
   * Link with system iniparser
   * Use dh 13 to get rid of dh-exec
   * Update Standards-Version; no changes required

Regards,
Bastian

Bug#976651: protobuf-compiler-grpc: Multi-arch protobuf-compiler-grpc

[Andreas Henriksson]

Hi Laszlo/GCS,

On Wed, Jan 13, 2021 at 11:14:22PM +0100, László Böszörményi (GCS) wrote:
>  This change was recently merged. Going to do the upload tomorrow.

Seems we had some cross-fire on my activity and your mail... here's
a status update:

I just merged both the m-a related merge-requests (as you noticed).

I also cherry-picked a trivial fix from upstream that was needed
for the package to not FTBFS with python3.9.
(Note: I have not checked if the rest of the python parts are actually
compatible with python3.9, just fixed the obvious FTBFS.)

I've already uploaded it as a NMU (as there was no feedback up until
now), hope this helps. All tagged and pushed to the git repo.

If you have any additional changes you want to see also uploaded
I guess doing another upload tomorrow doesn't hurt. The (full) freeze is
getting closer though, so please make it ASAP if you think another
upload is needed.

One thing I was on the fence about was if I should bump
debhelper-compat to 12, given that 11 is *discuraged* but I held
back on that... you might want to run lintian-brush on the repo.

> 
> Thanks,
> Laszlo/GCS

Regards,
Andreas Henriksson

Bug#980069: Better documentation of x-terminal-emulator

[Bill Allombert]

On Wed, Jan 13, 2021 at 10:49:27PM +, Bastien Roucariès wrote:
> Package: debian-policy
> Version: 4.5.0.0
> Severity: important
> affects: sensible-utils
> control: block -1 by 874019
> 
> Hi,
> 
> x-terminal-emulator documentation is incomplete.
> For instance the behavior of the -e option is different between xterm and 
> gnome-terminal:
> try:
> gnome-terminal -e sleep 60
> xterm -e sleep 60

Note that what policy documents is the minimal requirement for a package
to provide the x-terminal-emulator alternative.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#980044: warning: while removing fonts-lyx, directory '/usr/share/fonts/truetype/lyx' not empty so not removed

[積丹尼 Dan Jacobson]

OK thanks. I'm making these bug reports offline. So often have to rely
on memory.

Bug#980067: libqmatrixclient: new upstream release, with a rename

[Andres Salomon]

On Wed, 13 Jan 2021 21:43:22 +0100
Jonas Smedegaard  wrote:

> Quoting Andres Salomon (2021-01-13 20:54:55)
> > Package: libqmatrixclient
> > Version: 0.5.3.2-1
> > Severity: wishlist
> > 
> > There have been several new releases of this package, with the
> > latest version being 0.6.3. In addition, the upstream package was
> > renamed to libQuotient. It would be good to get a newer package
> > that includes the rename.
> > 
> > I'm currently including a bundled version of libQuotient in my
> > spectral Debian package. I would love to be able to just build
> > against a libquotient-dev package, once it has been uploaded.
> > 
> > If you need help maintaining libqmatrixclient/libquotient, please
> > let me know.  
> 
> Would you perhaps be interested in joining the Matrix team?
> 
> That might ease coordination between spectral and quaternion - the
> only other user of libqmatrixclient currently.
> 

Yeah, that would make sense. I can join the team.

Bug#980069: Better documentation of x-terminal-emulator

[Bastien Roucariès]

Package: debian-policy
Version: 4.5.0.0
Severity: important
affects: sensible-utils
control: block -1 by 874019

Hi,

x-terminal-emulator documentation is incomplete.
For instance the behavior of the -e option is different between xterm and 
gnome-terminal:
try:
gnome-terminal -e sleep 60
xterm -e sleep 60

gnome-terminal close immediately with a depression warning, where as xterm 
sleep 60.
for gnome-terminal we should use the deprecated gnome-terminal -e 'sleep 60' 
or
the newer variant gnome-terminal -- sleep 60

Moreover some packages noticed that x-terminal-emulator does not wait by 
default
and so create wrapper to correct this misbehavior (see https://
sources.debian.org/src/links2/2.21-1/debian/x-terminal-emulator-which-
properly-handles-dash-e/)

I plan to create a sensible-x-terminal-emulator and thus I need to document;
* the -e behavior, that  should behave like xterm and do not need to use 
quotes. Moreover -e should be the last option.
* that x-terminal-emulator should wait end of child process

Thanks

Bastien

signature.asc
Description: This is a digitally signed message part.

Bug#979996: libjs-jquery: please use the default extension for precompressed brotli files

[Guilhem Moulin]

Hi Jonas,

Thanks for the feedback, I appreciate the discussion : -)

On Wed, 13 Jan 2021 at 13:20:17 +0100, Jonas Smedegaard wrote:
> I find it wrong for Debian to add a NEWS file of "hi all brazilians, we 
> decided that expressing the hip new brotli compression a few letters 
> shorter is more important for us than support for your language - please 
> either rename all your localized documents or locally disable that hip 
> new compression format".

Please bear with me as I'm not an apache wizard, but that's not what I
had in mind.  AFAICT the stock configuration comes with AddEncoding
mappings for neither .gz nor .br, but with ‘AddType application/gzip
.gz’ and ‘AddLanguage br .br’.  So apache2 might serve files ending in
.gz and .br when content negotiation is enabled (when the HTTP request
has a ‘Accept-Type: application/gzip’ and/or ‘Accept-Language: br’
header respectively).  That's the default config, and if the httpd
administrator wants to change the mapping so .gz files are served for
‘Accept-Encoding: gzip’ instead, then they have to use ‘RemoveType .gz’
first.  Why treat .br differently?  As long as the stock config doesn't
come with ‘AddEncoding gzip .gz’ and ‘AddEncoding br .br’ there are no
conflicts and I don't see the need for a NEWS entry.

Furthermore the apache2 configuration we currently ship doesn't include
serving precompressed files depending on the value of the Accept-Encoding
header, so I'm not sure the apache2 package is the place to submit that
question.  In #972632 you suggested shipping the relevant configuration
snippet, and enabling it for /javascript or similar.  I suppose that
involves changing the mapping for .gz right (or disabling content
negotation altogether and use mod_rewrite instead, since the directory
also includes a .min.js file) right?  I don't see what's controversial
about changing mappings, be it for .gz or .br, as long as the scope is
*limited to namespaces you control*.  I wasn't advocating for gobal
removal of existing .gz/.br mappings, so no need to ask Breton folks to
rename their documents :-)

Finally the “we decided” sounds a bit far fetched to me; for better or
worse the brotli(1) utility defaults to .br suffix.  So when someone
runs `find /var/www/html -type f -exedir brotli -k -- {} +` to
statically compress their pages they'll end up with .br files.  Other
tools settled on that extension too, and apache2 own documentation for
mod_brotli has .br in its configuration snippets as well.  Moreover
Debian ships with other HTTPd; I don't know if the suffix is
configurable in lighttpd but I hope to see ngx_http_brotli_static_module
land into Debian at some point, and it unfortunately hardcodes the
suffix to .br (like ngx_http_gzip_static_module hardcodes .gz).  All in
all, if we settle on another suffix, then it'll actually be *us*
deciding to diverge from upstream, and likely not in a consistent
fashion.

> ...and again, concrete implementations of how to do content negotiation 
> based on file suffix really is ortogonal to the issue of clashing 
> interpretation of one specific file extension.

Appologies for insisting, but why is the *potential* conflict (the stock
configuration is conflict free since AddEncoding mappings are disabled)
for .gz not a problem then?  Globally removing the Type mapping isn't an
option because that will break default Content-Type response headers, so
if I follow your logic right you also need to rename jquery.min.js.gz to
jquery.min.js.gzip so local administators can save the ‘RemoveType .gz’
and get away with a mere ‘AddEncoding gzip .gzip’.  Is there a double
standard I don't follow, or something else I'm missing here?
 
> I am confident that files written in Brazilian Portuguese and saved with 
> extension .br.html or .html.br will continue to be served as intented 
> even with the introduction of .brotli files

Ack, I agree there is less potential to shoot oneself in the foot of
course.  But as far as libjs-query is concerned we're talking about
.min.js.br(otli), not about adding new httpd configuration snippet under
te hood.  If the mere presence of a .min.js.br file — in a namespace
under the Javascript Maintainers' control — is a blocker because it
might break existing setups, then one could argue it's even safer to
drop or rename the .gz as well, because it breaks setups where

GET /path/to/file.js HTTP/1.1
Accept: */*

yields

HTTP/1.1 200 OK
Content-Location: file.js.gz
Content-Type: application/x-gzip

when $documentroot/path/to/file.js.gz exists on disk and

HTTP/1.1 200 OK
Content-Location: file.js
Content-Type: application/javascript

when it does not.  That's perfectly valid as far as content negotation
is concerned, not even that far fetched: consider for instance a service
regularily compressing log files and exposing them to the web (so the
client can download uncompressed or gzipped files), and a rewrite rule
checking for the presence of $file.gz where the $URI =~ 

Bug#980049: fwupd: Should fwupd specify dbus as a dependency?

[Limonciello, Mario]

> -Original Message-
> From: Lukas Pirl 
> Sent: Wednesday, January 13, 2021 13:51
> To: Limonciello, Mario
> Cc: 980...@bugs.debian.org
> Subject: Re: Bug#980049: fwupd: Should fwupd specify dbus as a dependency?
> 
> Thanks for your quick reply, Mario.
> 
> On Wed, 2021-01-13 16:10 +, Limonciello, Mario wrote as excerpted:
> > I don't think it's a true dependency.  You can use fwupdtool without it.
> > It's only needed for fwupdmgr.
> > Perhaps a Recommends would be better?
> 
> I didn't know if fwupd is really useful without fwupdmgr. If using fwupd
> without fwupdmgr is a common use case then yes, listing dbus as recommended
> package is probably appropriate.
> 

I don't believe we have any evidence to say which use cases are more "common".
But it's a use case that is supported by upstream, particularly since you can
now optionally build without daemon/client and fwupdtool is placed in PATH by
default.

As such, I'll add a Recommends.

> > That being said I don't think it would solve it for you.  Systemd has dbus
> > as a Recommends and you still appear to not have it.
> 
> Even if systems are configured to not install recommended packages by default
> (you are right, it does not solve it for me), then the list of recommended
> packages can provide helpful clues, at least.

OK.

Bug#980068: cmake: Please update to version 3.19.3 before bullseye freeze

[Norbert Lange]

Package: cmake
Version: 3.18.4-1+b1
Severity: wishlist
X-Debbugs-Cc: nolang...@gmail.com

Dear Maintainer,

CMake 3.19.3 is currently the latest version, with it comes a rather
usefull "presets" feature.

Please update to the latest version so it can be included in Bullseye.

Regards, Norbert

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-1-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cmake depends on:
ii  cmake-data3.18.4-1
ii  libarchive13  3.4.3-2
ii  libc6 2.31-9
ii  libcurl4  7.74.0-1
ii  libexpat1 2.2.10-1
ii  libgcc-s1 10.2.1-3
ii  libjsoncpp24  1.9.4-4
ii  librhash0 1.4.1-1
ii  libstdc++610.2.1-3
ii  libuv11.40.0-1
ii  procps2:3.3.16-5
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages cmake recommends:
ii  gcc   4:10.2.0-1
ii  make  4.3-4

Versions of packages cmake suggests:
pn  cmake-doc
ii  ninja-build  1.10.1-1

-- no debconf information

Bug#977061: djangorestframework FTBFS with pytest 6

[Jonas Meurer]

Control: tag -1 moreinfo
Control: severity -1 important

Hey Christian,

On Thu, 10 Dec 2020 19:40:08 +0100 Christian Kastner  wrote:

djangorestframework FTBFS with pytest 6 in experimental.


I'm unable to reproduce the bug with pytest 6.0.2-2 from unstable. Also, 
according to ci.debian.net, the unit tests pass on all suites:


https://ci.debian.net/packages/d/djangorestframework/

Can you please provide further information on how to reproduce the bug? 
Or maybe it was a temporary error that's been resolved in the meantime?


Anyway, I'm lowering the bug severity for now in order to prevent 
djangorestframework from being removed from testing.


Kind regards
 jonas




The error log below has more details.

> === FAILURES 
===
> __ TestViewNamesAndDescriptions.test_markdown 
__
> tests/test_description.py:184: in test_markdown
> assert gte_21_match or lt_21_match
> E   AssertionError: assert (False or False)
> === warnings summary 
===
> /usr/lib/python3/dist-packages/_pytest/config/__init__.py:1148
>   /usr/lib/python3/dist-packages/_pytest/config/__init__.py:1148: 
PytestConfigWarning: Unknown config ini key: testspath
>   
> self._warn_or_fail_if_strict("Unknown config ini key: {}\n".format(key))
> 
> tests/test_serializer_nested.py::TestNestedSerializerWithMany::test_null_is_not_allowed_if_allow_null_is_not_set

> 
tests/test_serializer_nested.py::TestNestedSerializerWithMany::test_empty_not_allowed_if_allow_empty_is_set_to_false
>   /<>/rest_framework/exceptions.py:77: DeprecationWarning: 
NotImplemented should not be used in a boolean context
> return r and self.code == other.code
> 
> -- Docs: https://docs.pytest.org/en/stable/warnings.html

> === short test summary info 

> SKIPPED [1] tests/test_model_serializer.py:445: condition: not postgres_fields
> SKIPPED [1] tests/test_model_serializer.py:430: condition: not postgres_fields
> SKIPPED [1] tests/test_model_serializer.py:462: condition: not postgres_fields
> SKIPPED [1] tests/test_model_serializer.py:487: no models.JSONField
> SKIPPED [1] tests/test_serializer_nested.py:325: psycopg2 is not installed
> SKIPPED [1] tests/test_serializer_nested.py:343: psycopg2 is not installed
> FAILED tests/test_description.py::TestViewNamesAndDescriptions::test_markdown
>  1 failed, 1383 passed, 6 skipped, 3 warnings in 9.72s 
=
> E: pybuild pybuild:353: test: plugin custom failed with: exit code=1: python3.9 
/<>/runtests.py --nolint
> dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.9 
returned exit code 13
> make[1]: *** [debian/rules:31: override_dh_auto_test] Error 25
> make: *** [debian/rules:8: binary] Error 2
> dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
2
> make[1]: Leaving directory '/<>'







OpenPGP_signature
Description: OpenPGP digital signature

Bug#973554: /etc/cron.monthly/acct does not handle missing wtmp.1

[Marcos Fouces]

Hello Ellen

I renamed temporarily wtmp.1 and i run the script with "set-x" to see
what is going on:

# ./$HOME/Debian/Packages/acct/debian/acct.cron.monthly
+ test -x /usr/sbin/accton
+ echo

+ echo # LOGIN ACCOUNTING MONTHLY REPORT
##
+ echo

+ echo
+ date
+ echo Login accounting for the month ended mié 13 ene 2021 23:09:40
CET:
+ echo
+ test -f /var/log/wtmp.1
+ test -f /var/log/wtmp.1.gz
+ echo Data contained in current wtmp file:
+ ac -p
+ sort -nr -k2
+ echo
+ last
+ chown root:adm /var/log/wtmp.report
+ chmod 640 /var/log/wtmp.report


Could you check this on your machine, please.

Thanks for your bug report.

Greetings, 
Marcos.
















Thanks for your bug report. 


El dom, 01-11-2020 a las 11:03 -0800, Ellen Wang escribió:
> Package: acct
> Version: 6.6.4-2
> 
> On a newly installed system, /etc/cron.monthly/acct complains:
> 
> /etc/cron.monthly/acct:
> couldn't open file '': No such file or directory
> last: cannot open : No such file or directory
> 
> The problem is that the script wants to use /var/log/wtmp.1 instead
> of 
> wtmp if logrotate exists, on the assumption that logrotate has
> already 
> moved wtmp to wtmp.1.  However, this is not true if wtmp is not big 
> enough to have been rotated.
> 
> This patch gets rid of the error:
> 
> --- /etc/cron.monthly/acct# 2018-08-23 09:01:38.0 -0700
> +++ /etc/cron.monthly/acct  2020-11-01 10:13:58.310091356 -0800
> @@ -33,7 +33,10 @@
> 
>  gunzip -c /var/log/wtmp.1.gz > "${WTMP}"
>  fi
> +   fi
> 
> +   if [ -n "${WTMP}" ]
> +   then
>  ac -f "${WTMP}" -p | sort -nr -k2 >>
> /var/log/wtmp.report
>  echo >> /var/log/wtmp.report
>  last -f "${WTMP}" >> /var/log/wtmp.report
> 
> Perhaps a better fix would be to fall back to wtmp.1 only if wtmp is 
> empty.  Alternatively, if we want a monthly report that covers
> exactly 
> one month, then not specifying minsize in /etc/logrotate.d/wtmp is
> the 
> solution.
> 

Bug#976651: protobuf-compiler-grpc: Multi-arch protobuf-compiler-grpc

[GCS]

On Fri, Jan 8, 2021 at 11:42 PM Helmut Grohne  wrote:
> On Sun, Dec 06, 2020 at 03:14:56PM +0100, Andreas Henriksson wrote:
> This is a practical problem affecting packages inside Debian. Both bear
> and sysdig fail to cross build from source, because they
> protobuf-compiler-grpc is installed for the host architecture and cannot
> be run.
>
> > If I'm not mistaken the protobuf-compiler-grpc package should be marked
> > `Multi-Arch: foreign` just like for example protobuf-compiler package is.
>
> Yes, this is the most obvious cure of the problem. However, it is not
> entirely clear that doing so is correct. The foreign marking is less of
> a method to make things cross buildable. It is a guarantuee on the
> interface provided by a package. Unless that guarantuee is warranted,
> the marking is quite simply wrong and shouldn't be issued. If the
> marking is correct, it does solve the cross building issues.
 This change was recently merged. Going to do the upload tomorrow.

Thanks,
Laszlo/GCS

Bug#777291: gpm should provides systemd services

[Moritz Mühlenhoff]

Am Wed, Jan 13, 2021 at 05:37:27AM +0100 schrieb Axel Beckert:
> Mind trying to build a package off https://salsa.debian.org/debian/gpm
> and see if works for you? Would like to upload soon-ish, latest this
> weekend.

It works fine for me!

Cheers,
Moritz

Bug#777291: gpm should provides systemd services

[Axel Beckert]

Hi Moritz,

Moritz Mühlenhoff wrote:
> Am Wed, Jan 13, 2021 at 05:37:27AM +0100 schrieb Axel Beckert:
> > Mind trying to build a package off https://salsa.debian.org/debian/gpm
> > and see if works for you? Would like to upload soon-ish, latest this
> > weekend.
> 
> It works fine for me!

Great, thanks for testing and the feedback. Will try to get an upload
done this evening, latest this weekend.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#975166: connectome-workbench: FTBFS: qwt_painter_command.h:85:22: error: field ‘clipPath’ has incomplete type ‘QPainterPath

[Yaroslav Halchenko]

Great, thanks for the info and the buzz -- missed this, will try now and
upload if all good.

Cheers,

On Wed, 13 Jan 2021, s3v wrote:

> Dear Maintainer,

> I tried to build your package in a sid chroot environment
> and I confirm that patch fixes this issue.

> Kind Regards


-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
WWW:   http://www.linkedin.com/in/yarik



signature.asc
Description: PGP signature

Bug#963867: [dma] 0.13 Packaging

[Antonio Russo]

On 1/13/21 10:30 AM, Laurent Bigonville wrote:
> 
> I already have a package here that I can upload, but I didn't really had the 
> time to test it.
> 
> Can you confirm me that 0.13 is working fine for you?

It's been working excellently for me for the last few months on a half dozen 
machines.

> 
> Kind regards,
> 
> Laurent Bigonville

Thanks for getting back so quickly,
Antonio Russo


OpenPGP_0xB01C53D5DED4A4EE.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Bug#979104: installation-reports: Intel Wireless 8265 / 8275 has no firmware in nonfree iso

[Holger Wansing]

Hi,

Ben Hutchings  wrote:
> > Holger Wansing  wrote:
> > > Yes, that works fine, using a netboot image, I am NOT asked to
> > > provide
> > > firmware for regulatory.db file, because it's already included in
> > > the d-i
> > > image.
> > > 
> > > However, that's only true for netboot images!
> > > 
> > > My wireless card (on an IBM Thinkpad T60) is also usable with
> > > DVD/CD netinst images 
> > > (so related kernel modules seem to be included in those images; I
> > > have explicitly
> > > tested that with said images on that T60), so probably wireless-
> > > regdb-udeb should just 
> > > be added to all Linux d-i images?
> > 
> > I prepared a patch for this (includes removing it from the netboot/* files,
> > since it's now added generally in pkg-lists/base).
> > Will apply it, if noone objects.
> 
> Oh, I see.  What I did was to add it to every list that includes nic-
> wireless-modules, forgetting that for "CD" images that's not present in
> the initramfs and will get installed later.
> 
> I think the cleanest solution, that I originally intended to implement,
> is to make it a dependency of nic-wireless-modules, but that was going
> to require changing kernel-wedge.  But I don't have time to do that
> now, so I'm happy with your change.  The size increase will be
> negligible.

Now applied.
So, the wireless-regdb part of this bug is now fixed in git.
Thanks


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#980067: libqmatrixclient: new upstream release, with a rename

[Jonas Smedegaard]

Quoting Andres Salomon (2021-01-13 20:54:55)
> Package: libqmatrixclient
> Version: 0.5.3.2-1
> Severity: wishlist
> 
> There have been several new releases of this package, with the latest
> version being 0.6.3. In addition, the upstream package was renamed to
> libQuotient. It would be good to get a newer package that includes the
> rename.
> 
> I'm currently including a bundled version of libQuotient in my spectral
> Debian package. I would love to be able to just build against
> a libquotient-dev package, once it has been uploaded.
> 
> If you need help maintaining libqmatrixclient/libquotient, please let me
> know.

Would you perhaps be interested in joining the Matrix team?

That might ease coordination between spectral and quaternion - the only 
other user of libqmatrixclient currently.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#975672: Bug#979245: RFS: xylib/1.6-0.1 [RC] [NMU] -- Library for reading x-y data from several file formats

[Fabian Wolff]

On 1/11/21 3:45 AM, Stuart Prescott wrote:
>> In any case, I've changed my upload to a QA upload now and reuploaded
>> it to Salsa and Mentors.
> 
> I see bartm beat me to uploading it.

Are you sure? I didn't receive any emails about an upload, and the
tracker doesn't say anything about a recent upload either...

Bug#980007: tcmu: VE-2021-3139

[Salvatore Bonaccorso]

Control: retitle -1 tcmu: VE-2021-3139

On Tue, Jan 12, 2021 at 09:15:30PM +0100, Salvatore Bonaccorso wrote:
> Source: tcmu
> Version: 1.5.2-5
> Severity: grave
> Tags: security upstream
> Justification: user security hole
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
> 
> Hi,
> 
> The following vulnerability was published for tcmu.
> 
> CVE-2020-28374[0]:
> | Linux SCSI target (LIO) unrestricted copy offload

MITRE assigned a separate CVE for the tcmu issue as per
https://www.openwall.com/lists/oss-security/2021/01/13/5 .

Regards,
Salvatore

Bug#979439: hunspell-it: Italian spell check cannot recognize simple words

[Rene Engelhard]

Hi Antonio,

Am 13.01.21 um 19:43 schrieb Antonio:
> I solved it by changing this line of the file
> "/usr/share/hunspell/it_IT.aff":
>
> --- it_IT.aff.orig.bad  2021-01-13 19:28:38.184457124 +0100
> +++ it_IT.aff.new.ok   2021-01-13 19:38:06.141194317 +0100
> @@ -36,7 +36,7 @@
>  LANG it_IT
>  HOME https://libreitalia.org
>  VERSION 5.1.0 (13/10/2020)
> -SET UTF-8
> +SET ISO8859-15
>  TRY
> aioertnsclmdpgubzfvhàq'ACMSkBGPLxEyRTVòIODNwFéùÚìjUZKHWJYQXÃÃ
>  # Nota: non presenti nel dizionario: ÃÃ, vanno aggiunte alla TRY
> rigenerata
>
Interesting.

rene@frodo:~/LibreOffice/git/master/dictionaries/it_IT$ file it_IT.aff
it_IT.aff: UTF-8 Unicode text
rene@frodo:~/LibreOffice/git/master/dictionaries/it_IT$ file it_IT.dic
it_IT.dic: ISO-8859 text
$


Someone wasn't able to decide ;-). I'd argue that UTF-8 is the future
and that would possible mean a simply recode of it_IT.dic to UTF-8
should also fix it?

I probably would prefer that over patching the .aff to use the old
ISO8859-15.

Regards,


Rene

Bug#980004: Add patch to 0.2.5-1 python-etcd3gw update

[Heather Lemon]

Hi,

For the python-etcd3gw package update..
Could we include this patch [0] to the 0.2.5-1 update?

The patch adds a description of the exception if one gets thrown.
As well as an additional unit test.

Just for clarification, the reason we went to v0.2.5 and not v0.2.6 was the
commit "Make API path
configurable"(20b4fca3640bb77b957cc57aef0d114e547e593b)
breaks existing unit tests, and is not yet in a fixed release. Is that
correct?

[0] attached as
0001-Include-resp.text-as-detail-in-all-etcd-exceptions.patch

Thank you,
Heather Lemon

-- 
Heather Lemon
Associate Software Engineer (STS Engineering)
P: +1-719-415-8858
MM: hlemon | hypothetical-lemon
www.canonical.com | www.ubuntu.com
From 5a3157a122368c2314c7a961f61722e47355f981 Mon Sep 17 00:00:00 2001
From: Spike Curtis 
Date: Wed, 12 Feb 2020 17:00:40 -0800
Subject: [PATCH] Include resp.text as detail in all etcd exceptions

Signed-off-by: Spike Curtis 
---
 etcd3gw/client.py|  5 -
 etcd3gw/tests/test_client.py | 20 
 2 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/etcd3gw/client.py b/etcd3gw/client.py
index 9f2901a..19cadcc 100644
--- a/etcd3gw/client.py
+++ b/etcd3gw/client.py
@@ -81,7 +81,10 @@ class Etcd3Client(object):
 try:
 resp = self.session.post(*args, **kwargs)
 if resp.status_code in _EXCEPTIONS_BY_CODE:
-raise _EXCEPTIONS_BY_CODE[resp.status_code](resp.reason)
+raise _EXCEPTIONS_BY_CODE[resp.status_code](
+resp.text,
+resp.reason
+)
 if resp.status_code != requests.codes['ok']:
 raise exceptions.Etcd3Exception(resp.text, resp.reason)
 except requests.exceptions.Timeout as ex:
diff --git a/etcd3gw/tests/test_client.py b/etcd3gw/tests/test_client.py
index 5ebc840..9b0a145 100644
--- a/etcd3gw/tests/test_client.py
+++ b/etcd3gw/tests/test_client.py
@@ -14,6 +14,7 @@ import mock
 
 from etcd3gw.client import Etcd3Client
 from etcd3gw.exceptions import Etcd3Exception
+from etcd3gw.exceptions import InternalServerError
 from etcd3gw.tests import base
 
 
@@ -53,4 +54,23 @@ class TestEtcd3Gateway(base.TestCase):
 self.assertEqual(e.detail_text, '''{
 "error": "etcdserver: mvcc: required revision has been compacted",
 "code": 11
+}''')
+
+def test_client_exceptions_by_code(self):
+client = Etcd3Client(host="127.0.0.1")
+with mock.patch.object(client, "session") as mock_session:
+mock_response = mock.Mock()
+mock_response.status_code = 500
+mock_response.reason = "Internal Server Error"
+mock_response.text = '''{
+"error": "etcdserver: unable to reach quorum"
+}'''
+mock_session.post.return_value = mock_response
+try:
+client.status()
+self.assertFalse(True)
+except InternalServerError as e:
+self.assertEqual(str(e), "Internal Server Error")
+self.assertEqual(e.detail_text, '''{
+"error": "etcdserver: unable to reach quorum"
 }''')
-- 
2.25.1

Bug#980067: libqmatrixclient: new upstream release, with a rename

[Andres Salomon]

Package: libqmatrixclient
Version: 0.5.3.2-1
Severity: wishlist

There have been several new releases of this package, with the latest
version being 0.6.3. In addition, the upstream package was renamed to
libQuotient. It would be good to get a newer package that includes the
rename.

I'm currently including a bundled version of libQuotient in my spectral
Debian package. I would love to be able to just build against
a libquotient-dev package, once it has been uploaded.

If you need help maintaining libqmatrixclient/libquotient, please let me
know.

Bug#980066: dpkg-genchanges: does not include source if source package name changes, but version stays the same -1 version

[Andreas Beckmann]

Package: dpkg-dev
Severity: normal

Hi,

I have this d/changelog:

nvidia-settings-tesla-460 (460.32.03-1) unstable; urgency=medium
  
  * Initial release of nvidia-settings for use with the Tesla 460 driver.
  * Build only a single binary package, no -dev package or shared library.

 -- Andreas Beckmann   Wed, 13 Jan 2021 18:56:53 +0100

nvidia-settings (460.32.03-1) unstable; urgency=medium

  * New upstream release 460.32.03.

 -- Andreas Beckmann   Tue, 12 Jan 2021 15:42:37 +0100
...

and dpkg-genchanges does not include the source in the upload by default
(i.e. I need to add -sa despite of it being a -1 upload)

[...]
   dh_builddeb
dpkg-deb: building package 'nvidia-settings-tesla-460-dbgsym' in 
'../nvidia-settings-tesla-460-dbgsym_460.32.03-1_amd64.deb'.
dpkg-deb: building package 'nvidia-settings-tesla-460' in 
'../nvidia-settings-tesla-460_460.32.03-1_amd64.deb'.
 dpkg-genbuildinfo
 dpkg-genchanges  >../nvidia-settings-tesla-460_460.32.03-1_amd64.changes
dpkg-genchanges: info: not including original source code in upload

Reusing the version is perfectly fine in this case, since the only 
binary package built by the new source package got renamed as well.


Andreas

Bug#980065: ITP: put-dns -- tool to simply creation of individual DNS records on external providers

[John Lines]

Package: wnpp
Severity: wishlist
Owner: John Lines 
X-Debbugs-Cc: debian-de...@lists.debian.org, j...@paladyn.org

* Package name: put-dns
  Version : 0.0.1
  Upstream Author : John Lines 
* URL : https://gitlab.com/JohnLines/put-dns
* License : LGPL
  Programming Lang: Shell script , Perl, 
  Description : tool to simply creation of individual DNS records on 
external providers

put-dns is a simple abstraction of the process of creating a
DNS record with some DNS provider. 

It will be a Suggests for packages which require an external
DNS record to be created before they are useful, such as
opendkim, where in the postinst, if put-dns is installed will
be able to do
 put-dns 'rfc1034-format-dns-record'

It has a default 'none' provider, which appends the record
to /var/lib/put-dns/pending.txt for manual creation.

There is a comparison of similar or related projects at
 https://gitlab.com/JohnLines/put-dns/-/wikis/Similar-or-Related-Projects

Bug#980049: fwupd: Should fwupd specify dbus as a dependency?

[Lukas Pirl]

Thanks for your quick reply, Mario.

On Wed, 2021-01-13 16:10 +, Limonciello, Mario wrote as excerpted:
> I don't think it's a true dependency.  You can use fwupdtool without it. 
> It's only needed for fwupdmgr.
> Perhaps a Recommends would be better?

I didn't know if fwupd is really useful without fwupdmgr. If using fwupd
without fwupdmgr is a common use case then yes, listing dbus as recommended
package is probably appropriate.

> That being said I don't think it would solve it for you.  Systemd has dbus
> as a Recommends and you still appear to not have it.

Even if systems are configured to not install recommended packages by default
(you are right, it does not solve it for me), then the list of recommended
packages can provide helpful clues, at least.

Cheers,

Lukas



signature.asc
Description: This is a digitally signed message part

Bug#980064: scalpel FTCBFS: combines CFLAGS into CC

[Helmut Grohne]

Source: scalpel
Version: 1.60-9
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

scalpel fails to cross build from source, because the upstream Makefile
combines CFLAGS into CC. When dh_auto_build overrides CC, the CFLAGS
(including -fcommon) get lost and scalpel fails to build. Please
consider applying the attached patch to separate them and make scalpel
cross buildable.

Helmut
--- scalpel-1.60.orig/Makefile
+++ scalpel-1.60/Makefile
@@ -2,9 +2,8 @@
 CC_OPTS = $(CFLAGS) $(LDFLAGS) $(CPPFLAGS)
 GOAL = scalpel
 
-CC += $(CC_OPTS) 
   .c.o: 
-	$(CC) -c $<
+	$(CC) $(CC_OPTS) -c $<
 
 HEADER_FILES = scalpel.h prioque.h dirname.h
 SRC =  helpers.c files.c scalpel.c dig.c prioque.c base_name.c
@@ -12,18 +11,18 @@
 
 all: linux
 
-linux: CC += -D__LINUX 
+linux: CC_OPTS += -D__LINUX
 linux: $(GOAL)
 
-bsd: CC += -D__OPENBSD 
+bsd: CC_OPTS += -D__OPENBSD
 bsd: $(GOAL)
 
-win32: CC += -D__WIN32 -Ic:\PThreads\include 
+win32: CC_OPTS += -D__WIN32 -Ic:\PThreads\include
 win32: $(SRC) $(HEADER_FILES)
-	$(CC) -o $(GOAL).exe $(SRC) -liberty -Lc:\PThreads\lib -lpthreadGC1
+	$(CC) $(CC_OPTS) -o $(GOAL).exe $(SRC) -liberty -Lc:\PThreads\lib -lpthreadGC1
 
 $(GOAL): $(OBJS) 
-	$(CC) -o $(GOAL) $(OBJS) -lm
+	$(CC) $(CC_OPTS) -o $(GOAL) $(OBJS) -lm
 
 scalpel.o: scalpel.c $(HEADER_FILES) Makefile
 dig.o: dig.c $(HEADER_FILES) Makefile

Bug#980063: autodir FTCBFS: does not pass --host to ./configure

[Helmut Grohne]

Source: autodir
Version: 0.99.9-15
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

autodir fails to cross build from source, because it does not pass
--host to ./configure. The easiest way of doing so - using
dh_auto_configure - is not available as the configure script does not
understand --runstatedir. The attached patch fixes this and a number of
other problems with the configure invocation. Please consider applying
it.

Helmut
diff --minimal -Nru autodir-0.99.9/debian/changelog 
autodir-0.99.9/debian/changelog
--- autodir-0.99.9/debian/changelog 2021-01-11 12:05:44.0 +0100
+++ autodir-0.99.9/debian/changelog 2021-01-13 20:11:29.0 +0100
@@ -1,3 +1,14 @@
+autodir (0.99.9-15.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix configure invocation:
++ Fix missing initialization of architecture variable.
++ Fix build/host confusion.
++ Fix gnutype/multiarch confusion.
++ Fix missing --build/--host flags. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 13 Jan 2021 20:11:29 +0100
+
 autodir (0.99.9-15) unstable; urgency=medium
 
   * Introduced systemd unit files to be used instead of the sysv init script.
diff --minimal -Nru autodir-0.99.9/debian/rules autodir-0.99.9/debian/rules
--- autodir-0.99.9/debian/rules 2021-01-11 12:05:44.0 +0100
+++ autodir-0.99.9/debian/rules 2021-01-13 20:11:27.0 +0100
@@ -2,6 +2,8 @@
 
 export DH_VERBOSE=1
 
+include /usr/share/dpkg/architecture.mk
+
 %:
dh $@ --without autoreconf
 
@@ -9,8 +11,8 @@
dh_update_autotools_config
# upstream autotools stuff is old enough to miss --runstatedir option 
and break debhelper(>10)
# dh_auto_configure -- --prefix=/usr --mandir=\$${prefix}/share/man 
--infodir=\$${prefix}/share/info --libdir=\$${prefix}/lib
-   ./configure --infodir=\${prefix}/share/info --disable-option-checking 
--disable-silent-rules --libdir=\${prefix}/lib/$(DEB_BUILD_GNU_TYPE) 
--disable-dependency-tracking \
-   --prefix=/usr --mandir=\$${prefix}/share/man 
--infodir=\$${prefix}/share/info --libdir=\$${prefix}/lib
+   ./configure --infodir=\${prefix}/share/info --disable-option-checking 
--disable-silent-rules --libdir=\${prefix}/lib/$(DEB_HOST_MULTIARCH) 
--disable-dependency-tracking \
+   --prefix=/usr --mandir=\$${prefix}/share/man 
--infodir=\$${prefix}/share/info --libdir=\$${prefix}/lib 
--build=$(DEB_BUILD_GNU_TYPE) --host=$(DEB_HOST_GNU_TYPE)
 
 override_dh_auto_install:
dh_auto_install

Bug#980062: [Pkg-javascript-devel] Bug#980062: nocheck build profile is broken - Error: Cannot find module 'babel-jest'

[Xavier]

Control: fixed -1 0.9.62

Le 13/01/2021 à 20:28, Pirate Praveen a écrit :
> Package: node-yaml,pkg-js-tools
> Severity: important
> 
> When building node-yaml with nocheck build profile, the build fails
> 
> dh binary
>   dh_update_autotools_config
>   dh_autoreconf
>   dh_auto_configure --buildsystem=nodejs
> mkdir node_modules
> internal/modules/cjs/loader.js:638
>    throw err;
>    ^
> 
> Error: Cannot find module 'babel-jest'
>    at Function.Module._resolveFilename
> (internal/modules/cjs/loader.js:636:15)
>    at Function.resolve (internal/modules/cjs/helpers.js:33:19)
>    at [eval]:1:21
>    at Script.runInThisContext (vm.js:122:20)
>    at Object.runInThisContext (vm.js:329:38)
>    at Object. ([eval]-wrapper:6:22)
>    at Module._compile (internal/modules/cjs/loader.js:778:30)
>    at evalScript (internal/bootstrap/node.js:590:27)
>    at startup (internal/bootstrap/node.js:265:9)
>    at bootstrapNodeJSCore (internal/bootstrap/node.js:623:3)
> ### babel-jest is required by debian/nodejs/./extlinks but not available
> make: *** [debian/rules:8: binary] Error 1
> 
> DEB_BUILD_OPTIONS=nocheck DEB_BUILD_PROFILES=nocheck sbuild
> should skip jest build dependency but extlinks fails to find the link
> when jest is not installed.
> 
> extlinks and extcopies should filter nocheck build profiles
> automatically or should support build profiles like,
> 
> babel-jest 

Since 0.9.62, you can add a "test" flag in debian/nodejs/ext*

Bug#980062: nocheck build profile is broken - Error: Cannot find module 'babel-jest'

[Pirate Praveen]

Package: node-yaml,pkg-js-tools
Severity: important

When building node-yaml with nocheck build profile, the build fails

dh binary
  dh_update_autotools_config
  dh_autoreconf
  dh_auto_configure --buildsystem=nodejs
mkdir node_modules
internal/modules/cjs/loader.js:638
   throw err;
   ^

Error: Cannot find module 'babel-jest'
   at Function.Module._resolveFilename 
(internal/modules/cjs/loader.js:636:15)

   at Function.resolve (internal/modules/cjs/helpers.js:33:19)
   at [eval]:1:21
   at Script.runInThisContext (vm.js:122:20)
   at Object.runInThisContext (vm.js:329:38)
   at Object. ([eval]-wrapper:6:22)
   at Module._compile (internal/modules/cjs/loader.js:778:30)
   at evalScript (internal/bootstrap/node.js:590:27)
   at startup (internal/bootstrap/node.js:265:9)
   at bootstrapNodeJSCore (internal/bootstrap/node.js:623:3)
### babel-jest is required by debian/nodejs/./extlinks but not available
make: *** [debian/rules:8: binary] Error 1

DEB_BUILD_OPTIONS=nocheck DEB_BUILD_PROFILES=nocheck sbuild
should skip jest build dependency but extlinks fails to find the link 
when jest is not installed.


extlinks and extcopies should filter nocheck build profiles 
automatically or should support build profiles like,


babel-jest 

Bug#963867: [dma] 0.13 Packaging

[Antonio Russo]

Hello,

I am interested in getting dma 0.13 into bullseye.  I've been running it
on a fleet of machines after packaging it [1].

Would the dma packaging team be willing to sponsor an upload if I prepared
it?

Best,
Antonio Russo

[1] https://salsa.debian.org/debian/dma/-/merge_requests/2


OpenPGP_0xB01C53D5DED4A4EE.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Bug#977132: python-pygal FTBFS with pytest 6

[s3v]

Dear Maintainer,

after applying this patch [1], I was able to build
your package in my sid chroot environment.

Kind Regards.


[1] https://github.com/Kozea/pygal/commit/19e539

Bug#979439: hunspell-it: Italian spell check cannot recognize simple words

[Antonio]

I solved it by changing this line of the file 
"/usr/share/hunspell/it_IT.aff":


--- it_IT.aff.orig.bad  2021-01-13 19:28:38.184457124 +0100
+++ it_IT.aff.new.ok   2021-01-13 19:38:06.141194317 +0100
@@ -36,7 +36,7 @@
 LANG it_IT
 HOME https://libreitalia.org
 VERSION 5.1.0 (13/10/2020)
-SET UTF-8
+SET ISO8859-15
 TRY 
aioertnsclmdpgubzfvhàq'ACMSkBGPLxEyRTVòIODNwFéùÚìjUZKHWJYQXÃÃ
 # Nota: non presenti nel dizionario: ÃÃ, vanno aggiunte alla TRY 
rigenerata

Bug#980061: caribou: Segfault as regression of xorg CVE-2020-25712 fix that cause security issue for cinnamon

[Fabio Fantoni]

Source: caribou
Version: 0.4.21-7
Severity: grave
Tags: patch security upstream
Forwarded: https://gitlab.gnome.org/GNOME/caribou/-/merge_requests/3

Hi, after xorg CVE-2020-25712 fix a regression is intruduced that make
possible crash caribou and add a security issue for cinnamon that use it
as virtual keyboard in screensaver:
https://github.com/linuxmint/cinnamon-screensaver/issues/354

Cinnamon developers already prepared, tested and open a MR on caribou
upstream for solves this issue (link in forwarded)

Bug#887181: Bug #887181

[Eric Desrochers]

Unless one wants to upload a patched package to the Debian mentors queue or
have urgent need (which I doubt since this bug is opened since 2018).

I'll keep a note to address this bug for the next new upstream release bump.

4.0 was released in Aug 2020, so we could expect having a new release in a
couple of weeks/months from now.

Regards,
Eric

Bug#980060: New upstream version

[Raymond S Brand]

Package: leocad
Version: 19.07.1.5e8baffc-1

There is a new upstream version, 21.01, available at: 
https://github.com/leozide/leocad/releases/tag/v21.01

Bug#926327: qgit: Crash on some malformed git repositories

[Boyuan Yang]

X-Debbugs-CC: w...@debian.org

On Wed, 3 Apr 2019 20:43:36 +0500 Andrey Rahmatullin  wrote:
> Control: tags -1 + upstream
> 
> Please forward it to https://github.com/tibirna/qgit/issues, ideally with
> instructions how to create such repo.
It seems that upstream has a proper patch to this bug. Please consider
cherry-picking the commit at https://github.com/tibirna/qgit/pull/103
and make a new upload before Debian 11 freeze.

Thanks,
Boyuan Yang


signature.asc
Description: This is a digitally signed message part

Bug#966088: It would be great to have debian-rust@l.d.o.

[Geert Stappers]

Summary:  Gentle reminder


Hello Listmasters,


Today there was this on IRC in #debian-rust

14:31 < metreo> is there some reason the rust team mailing list isn't shown 
here:
https://lists.debian.org/completeindex.html
14:38 < capitol> not that i know of
14:39 < metreo> k
14:58 < nikos> 'The lists.d.o list hasn't been created yet AFAIK


Me did it trigger to write this email.


What is blocking creation mailing  debian-rust@l.d.o.?
 
In other words: Please say what is needed to make it possible.


Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#963867: [dma] 0.13 Packaging

[Laurent Bigonville]

Le 13/01/21 à 16:04, Antonio Russo a écrit :

Hello,

Hello Antonio,

I am interested in getting dma 0.13 into bullseye.  I've been running it
on a fleet of machines after packaging it [1].

Would the dma packaging team be willing to sponsor an upload if I prepared
it?


I already have a package here that I can upload, but I didn't really had 
the time to test it.


Can you confirm me that 0.13 is working fine for you?

Kind regards,

Laurent Bigonville



Best,
Antonio Russo

[1] https://salsa.debian.org/debian/dma/-/merge_requests/2

Bug#980051: pure-ftpd: Needs 1 line change to init.d script for SE Linux support

[Russell Coker]

Package: pure-ftpd
Version: 1.0.49-4
Severity: normal
Tags: patch

The following patch is needed to get the run directory correctly labeled
on SE Linux systems.  On non-SE systems restorecon won't exist so it won't
change things.  On systems that have SE Linux utilities installed but not
enabled restorecon will detect this state and exit while doing nothing.

Also for systemd support you should have a tmpfiles.d(5) file which will
simplify creating such directories and also set the correct SE Linux
context if it detects that SE Linux is enabled.

--- pure-ftpd.orig  2021-01-13 21:47:20.863054766 +1100
+++ pure-ftpd   2021-01-13 21:48:01.314229696 +1100
@@ -61,6 +61,7 @@
 
 if [ ! -e `dirname $PIDFILE` ];then
mkdir `dirname $PIDFILE`
+   [ -x /sbin/restorecon ] && /sbin/restorecon `dirname $PIDFILE`
 fi
 
 start_uploadscript() {

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-1-amd64 (SMP w/6 CPU threads)
Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Enforcing - Policy name: default

Versions of packages pure-ftpd depends on:
ii  libc6  2.31-9
ii  libcap21:2.44-1
ii  libcrypt1  1:4.4.17-1
ii  libpam0g   1.4.0-2
ii  libsodium231.0.18-1
ii  libssl1.1  1.1.1i-1
ii  lsb-base   11.1.0
ii  pure-ftpd-common   1.0.49-4
ii  xinetd [inet-superserver]  1:2.3.15.3-1

pure-ftpd recommends no packages.

pure-ftpd suggests no packages.

-- Configuration Files:
/etc/init.d/pure-ftpd changed:
PATH=/sbin:/bin:/usr/sbin:/usr/bin
NAME=pure-ftpd
DESC="ftp server"
: ${SSDAEMONLOGOPTS:="--quiet"}
UPLOADDAEMON=/usr/sbin/pure-uploadscript
UDNAME=pure-uploadscript
UDDESC="ftp upload handler"
WRAPPER=/usr/sbin/pure-ftpd-wrapper
. /lib/lsb/init-functions
PIDFILE=/var/run/pure-ftpd/pure-ftpd.pid
if [ -h $0 ]; then
ME=`/bin/readlink $0`
else 
ME=$0
fi
SUFFIX=`basename $ME | sed -ne 's/^pure-ftpd-\(.*\)/\1/p'`
if [ "$SUFFIX" ] ; then
DAEMON=/usr/sbin/pure-ftpd-$SUFFIX
else
DAEMON=/usr/sbin/pure-ftpd
fi
export STANDALONE_OR_INETD=inetd
export VIRTUALCHROOT=
test -r /etc/default/pure-ftpd-common && . /etc/default/pure-ftpd-common
if [ "$VIRTUALCHROOT" = "true" ]; then
if [ "$SUFFIX" ]; then
SUFFIX="$SUFFIX-virtualchroot"
else
SUFFIX="virtualchroot"
fi
fi
test -x $DAEMON || exit 0
test -x $WRAPPER || exit 0
set -e
if [ ! -e `dirname $PIDFILE` ];then
   mkdir `dirname $PIDFILE`
   [ -x /sbin/restorecon ] && /sbin/restorecon `dirname $PIDFILE`
fi
start_uploadscript() {
if [ "$UPLOADSCRIPT" -a "$STANDALONE_OR_INETD" != inetd ] && \
egrep -i '^[]*(yes|1|on)[   ]*' 
/etc/pure-ftpd/conf/CallUploadScript > /dev/null 2>&1
then
UOPTS=""
test "$UPLOADUID" && UOPTS="$UOPTS -u $UPLOADUID"
test "$UPLOADGID" && UOPTS="$UOPTS -g $UPLOADGID"
echo -n "$1 $UDDESC: "
start-stop-daemon --start $SSDAEMONLOGOPTS --oknodo \
--exec $UPLOADDAEMON -- -r "$UPLOADSCRIPT" -B $UOPTS
echo "$UDNAME."

fi
}
case "$1" in
  start)
test "$STANDALONE_OR_INETD" = standalone || exit 0
echo -n "Starting $DESC: "
start-stop-daemon --start $SSDAEMONLOGOPTS --pidfile "$PIDFILE" \
--exec $WRAPPER -- $SUFFIX
start_uploadscript Starting
;;
  stop)
echo -n "Stopping $DESC: "
start-stop-daemon --stop $SSDAEMONLOGOPTS --oknodo \
--pidfile "$PIDFILE"
start-stop-daemon --stop $SSDAEMONLOGOPTS --oknodo --exec $UPLOADDAEMON
echo "$NAME."
;;
  restart|force-reload)
test "$STANDALONE_OR_INETD" = standalone || exit 0
echo -n "Restarting $DESC: "
start-stop-daemon --stop $SSDAEMONLOGOPTS --oknodo \
--pidfile "$PIDFILE"
start-stop-daemon --stop $SSDAEMONLOGOPTS --oknodo --exec $UPLOADDAEMON
sleep 1
start-stop-daemon --start $SSDAEMONLOGOPTS --pidfile "$PIDFILE" \
--exec $WRAPPER -- $SUFFIX
start_uploadscript Restarting
;;
  status)
status_of_proc -p /var/run/pure-ftpd/pure-ftpd.pid $DAEMON $NAME && 
exit 0 || exit $?
;;
  *)
N=/etc/init.d/$NAME
echo "Usage: $N {start|stop|restart|force-reload|status}" >&2
exit 1
;;
esac
exit 0


-- no debconf information

Bug#979727: racon: FTBFS: fatal error: bioparser/bioparser.hpp: No such file or directory

[Andreas Tille]

Control: tags -1 help
Control: tags -1 - pending

Hi,

there is a remaining build time test issue which I reported upstream:

https://github.com/lbcb-sci/racon/issues/50

I have no idea how to fix this since gdb does not really give a good
hint about the SIGSEGV that occures.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#979562: lightdm session termination does not stop xscreensaver

[Eduard Bloch]

Hallo,
* Jamie Zawinski [Mon, Jan 11 2021, 01:13:10PM]:
> > my .icewm/startup file at the moment contains:
> >
> > xscreensaver -nosplash -log wtf-xscreensaver.txt &
> >
> > When icewm starts, I see the splash screen for a brief moment (not joking, 
> > looks -nosplash has no effect there), but it does not happen every time.
>
> This kinda sounds like *something else* is launching xscreensaver at the same 
> time, and whatever that is is doing it without -nosplash. The two of them 
> racing would explain the "already running" error.

I think they are both originating from xscreensaver.service ExecStart's
command line.

> > Or, if run ps quick enough before it's killed, I see:
> >
> > user   3904  0.0  0.0   5712  1128 ?SN   21:13   0:00 
> > xscreensaver-systemd -verbose
> > lightdm11997  0.1  0.0  18948  5952 ?Ss   21:55   0:00 
> > xscreensaver
> > lightdm12068  0.0  0.0   5712  1128 ?SN   21:55   0:00 
> > xscreensaver-systemd
> > user   12416  0.0  0.0   3748   664 pts/0S+   21:56   0:00 grep 
> > saver
>
> Note that pid 11997 does not have -nosplash on its command line.

That also matches the command in the service file, including the ownership
of the process.

Best regards,
Eduard.

Bug#971296: rekall: Switch to python3-pycryptodome

[Hilko Bengen]

* Sascha Steinbiss:

> Just bringing this up again... I would be in favour of removing it
> completely. Would be happy to file a RM from unstable if there are no
> objections.

I agree and have filed the RM bug.

Cheers,
-Hilko

Bug#980059: RM: rekall -- RoM; RC bugs, unmaintained upstream

[Hilko Bengen]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: none, Hilko Bengen 

Dear ftp team,

please remove rekall. It has had an inactive upstream for 3+ years and
an RC bug (#971296). There are no reverse dependencies other than the
"forensics-extra" metapackage.

Cheers,
-Hilko

Bug#973617: fonts-materialdesignicons-webfont: New upstream release

[Julian Gilbey]

On Wed, Jan 13, 2021 at 10:51:08AM +, Julian Gilbey wrote:
> On Mon, Nov 02, 2020 at 04:32:54PM +0100, Michele Cane wrote:
> > Package: fonts-materialdesignicons-webfont
> > Version: 1.6.50-3
> > Severity: wishlist
> > 
> > Dear Maintainer,
> > 
> > Would it be possible to upload the latest upstream release.
> 
> +1 from me (and I'm happy to do an NMU if this helps); the newer fonts
> are required for the new version of Spyder.

Update: I have now prepared an updated package for local use and it is
ready to upload to unstable if wanted.

Key change: The SVG fonts are no longer shipped by upstream with the
webfonts; they are now in a seperate repository.  So my package does
not include the SVG fonts.

Medium change: I've upgraded to 5.5.55.  This is the last version with
a clear license and copyright statement.  The current one is too vague
to pass DFSG, but they are working on it (see
https://github.com/Templarian/MaterialDesign/issues/5777).

Smaller changes: I've updated the debhelper-compat to (= 13), and now
Build-Depends: openstack-pkg-tools; having debian/rules potentially
behave differently depending on whether this package is installed or
not seems quite unwise.  I've also removed one of the lintian
overrides (tabs in copyright file - I replaced the tabs with
spaces!).  The override for preview.html is a bit more problematic: it
is clearly auto-generated from something, but I have no idea how.

My Git repository is on salsa at
https://salsa.debian.org/jdg/fonts-materialdesignicons-webfont

It is a fork of the OpenStack salsa repository, but I encountered some
significant problems using it, most notably, the final commit on the
master branch does not exist in the current upstream GitHub
repository, so it is not possible to cleanly merge the current
upstream.  One could do a git reset --hard HEAD^ on that branch and
then merge the current upstream and force push to salsa.  What I did
instead was to create a new branch called upstream which is now
up-to-date with the upstream GitHub repository, and base my debian
version on it - it is in the branch debian/unstable.  Somewhat sadly,
though, this means that the history of the debian/* files is lost, but
I don't think it's that big a deal.

I can't make a pull request for my work against your repository, as
these two branches are not forked from any of your existing branches
because of the upstream discrepancy.

Finally, there is a piece of BOM removal code in the debian/rules
file.  This seems to be historic, as scss can now happily process the
scss files even with the BOM present.  (I reported it upstream at
https://github.com/Templarian/MaterialDesign/issues/5778)

Best wishes,

   Julian

Bug#933928: macsyfinder: Upstream released Python3 version but "error: 'setuptools' is not supported. Please use 'pip' instead."

[Andreas Tille]

Control: tags -1 - upstream

Hi,

upstream has released a Python3 version of macsyfinder which I pushed to
Git[1].  When trying to build I get a strange error:

   dh_auto_install -O--buildsystem=pybuild
I: pybuild base:232: /usr/bin/python3 setup.py install --root 
'/build/macsyfinder-2.0~rc1/debian/macsyfinder' 
running install
running build
running build_py
running install_lib
error: 'setuptools' is not supported. Please use 'pip' instead.
E: pybuild pybuild:353: install: plugin distutils failed with: exit code=1: 
/usr/bin/python3 setup.py install --root 
'/build/macsyfinder-2.0~rc1/debian/macsyfinder' 
dh_auto_install: error: pybuild --install -i python{version} -p 3.9 --dest-dir 
/build/macsyfinder-2.0\~rc1/debian/macsyfinder returned exit code 13
make: *** [debian/rules:7: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2


Any help is welcome

  Andreas.


[1] https://salsa.debian.org/med-team/macsyfinder

-- 
http://fam-tille.de

Bug#971754: ABI breakage from 1.4.1 to 1.4.2

[Andreas Beckmann]

Control: tag -1 patch

Hi,

On Thu, 7 Jan 2021 20:52:39 +0100 Paul Gevers  wrote:
> On Tue, 06 Oct 2020 16:38:49 +0300 =?utf-8?q?Sebastian_Dr=C3=B6ge?=
>  wrote:
> > 1.4.2 broke ABI by adding some fields to the CBytePerfMon structure.
> > See https://github.com/Haivision/srt/issues/1592 for details.
> 
> Any progress on this? The freeze for bullseye is around the corner, and
> this bug is already impacting other packages that fail to migrate to
> testing due to srt not migrating.

given the freeze timing and uncertain date for an upstream fix, I'd
suggest the attached patch:
* bump SOVERSION from 1 to 1.4.2 (that won't conflict with whatever
upstream chooses to solve this in the upcoming 1.4.3 release, be it
SOVERSION 1.4 or 1.4.3)
* rename the packages accordingly

That will require a late transition involving only 1 package:
gst-plugins-bad1.0


Andreas
>From 1a78394d5bd2c50ada11074841531a2b8c1ca7a1 Mon Sep 17 00:00:00 2001
From: Andreas Beckmann 
Date: Wed, 13 Jan 2021 17:28:16 +0100
Subject: [PATCH] bump SOVERSION to 1.4.2 due to upstream ABI changes

---
 debian/changelog  |  7 +--
 debian/control| 20 ---
 ...tls.install => libsrt1.4.2-gnutls.install} |  0
 ...sl.install => libsrt1.4.2-openssl.install} |  0
 debian/patches/series |  1 +
 debian/patches/soversion.patch| 11 ++
 6 files changed, 25 insertions(+), 14 deletions(-)
 rename debian/{libsrt1-gnutls.install => libsrt1.4.2-gnutls.install} (100%)
 rename debian/{libsrt1-openssl.install => libsrt1.4.2-openssl.install} (100%)
 create mode 100644 debian/patches/soversion.patch

diff --git a/debian/changelog b/debian/changelog
index cee8bd8..46802b2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,9 +1,12 @@
-srt (1:1.4.2-1) UNRELEASED; urgency=medium
+srt (1.4.2-2) UNRELEASED; urgency=medium
 
-  * Bump up version number due to API change (Closes: #971754)
+  [ Federico Ceratto ]
   * Pass flags to cmake (Closes: #971811)
 Thanks to Helmut Grohne 
 
+  [ Andreas Beckmann ]
+  * Bump SOVERSION to 1.4.2 due to upstream ABI changes.  (Closes: #971754)
+
  -- Federico Ceratto   Sat, 02 Jan 2021 19:19:33 +
 
 srt (1.4.2-1) unstable; urgency=medium
diff --git a/debian/control b/debian/control
index ab67299..be80904 100644
--- a/debian/control
+++ b/debian/control
@@ -17,14 +17,10 @@ Vcs-Browser: https://salsa.debian.org/debian/libsrt
 Vcs-Git: https://salsa.debian.org/debian/libsrt.git
 Rules-Requires-Root: no
 
-Package: libsrt1-openssl
+Package: libsrt1.4.2-openssl
 Architecture: any
-Breaks: libsrt1 (<< 1.4.1-3)
-Replaces: libsrt1 (<< 1.4.1-3)
 Multi-Arch: same
 Depends: ${shlibs:Depends}, ${misc:Depends}
-Conflicts: libsrt1
-Provides: libsrt1  (= ${binary:Version})
 Description: Secure Reliable Transport UDP streaming library (OpenSSL flavour)
  SRT is a latency-aware UDP transport mechanism optimized for video streams.
  It detects and compensates for jitter and bandwidth fluctuations due to
@@ -32,7 +28,7 @@ Description: Secure Reliable Transport UDP streaming library (OpenSSL flavour)
  .
  SSL support is provided by OpenSSL.
 
-Package: libsrt1-gnutls
+Package: libsrt1.4.2-gnutls
 Architecture: any
 Multi-Arch: same
 Depends: ${shlibs:Depends}, ${misc:Depends}
@@ -50,14 +46,14 @@ Replaces: libsrt-dev (<< 1.4.1-2)
 Architecture: any
 Multi-Arch: same
 Conflicts: libsrt-gnutls-dev, libsrt-dev
-Depends: libsrt1-openssl (= ${binary:Version}), ${misc:Depends}
+Depends: libsrt1.4.2-openssl (= ${binary:Version}), ${misc:Depends}
 Suggests: libsrt-doc (= ${binary:Version}), libssl-dev (>= 1.1)
 Description: Secure Reliable Transport UDP streaming library
  SRT is a latency-aware UDP transport mechanism optimized for video streams.
  It detects and compensates for jitter and bandwidth fluctuations due to
  network congestion. It mitigates packet loss and supports AES encryption.
  .
- This package contains development files for libsrt1
+ This package contains development files for libsrt1.4.2
  SSL support is provided by OpenSSL.
 
 Package: libsrt-gnutls-dev
@@ -67,14 +63,14 @@ Replaces: libsrt-dev (<< 1.4.1-2)
 Architecture: any
 Multi-Arch: same
 Conflicts: libsrt-openssl-dev, libsrt-dev
-Depends: libsrt1-gnutls (= ${binary:Version}), ${misc:Depends}
+Depends: libsrt1.4.2-gnutls (= ${binary:Version}), ${misc:Depends}
 Suggests: libsrt-doc (= ${binary:Version}), libgnutls28-dev
 Description: Secure Reliable Transport UDP streaming library
  SRT is a latency-aware UDP transport mechanism optimized for video streams.
  It detects and compensates for jitter and bandwidth fluctuations due to
  network congestion. It mitigates packet loss and supports AES encryption.
  .
- This package contains development files for libsrt1-gnutls
+ This package contains development files for libsrt1.4.2-gnutls
  SSL support is provided by GnuTLS.
 
 Package: libsrt-doc
@@ -86,13 +82,13 @@ Description: Secure Reliable Transport UDP 

Bug#953982: wine-development: wine in Debian fails to start "Uru", but upstream wine works fine (regression)

[Berillions]

On Sun, 13 Sep 2020 21:13:43 +0200 Stephen Kitt  wrote:
> On Sun, 13 Sep 2020 13:19:16 +0200, Berillions 
wrote:
> > Seriously, don’t use Debian package for Wine. It’s completely a mess and
> > outdated ... It’s a waste of time.
>
> You keep saying that, but without any detail (as far as I can tell). The
> outdated part doesn’t need any clarification, but what else is wrong with
the
> package? Would you be interested in helping make it better?
>
> Regards,
>
> Stephen

Hello,

Sorry for the delay.
I would love to help to update wine-development at the same time than
upstream release.

But, i tried to do this with wine-6.0-RC6 and sorry but i don't understand
why this part in the rules file exist :

> # automatically generated files
> ./debian/scripts/generate server/trace.generated make_requests
> ./debian/scripts/generate server/request.generated make_requests
> ./tools/make_unicode
> ./tools/make_requests
> cd dlls/dsound && ./make_fir
> cd dlls/opengl32 && ./make_opengl
> cd dlls/winevulkan && ./make_vulkan
> # autotools files
> ln -sf /usr/share/misc/config.sub tools
> ln -sf /usr/share/misc/config.guess tools
> # image files used to generate icons for parts of wine
> ln -sf ../../dlls/user32/resources/oic_hand.svg
> dlls/display.drv16/oic_hand.svg
> ln -sf ../../dlls/user32/resources/oic_bang.svg
> dlls/comctl32/idi_tt_warn_sm.svg
> ln -sf ../../dlls/user32/resources/oic_note.svg
> dlls/comctl32/idi_tt_info_sm.svg
> ln -sf ../../dlls/user32/resources/oic_hand.svg
> dlls/comctl32/idi_tt_error_sm.svg
> ln -sf ../../dlls/shell32/resources/move.svg
> dlls/comctl32/idi_dragarrow.svg
> ln -sf ../../dlls/shell32/resources/image.svg programs/regedit/bin.svg
> ln -sf ../../dlls/shell32/resources/folder.svg programs/regedit/folder.svg
> ln -sf ../../dlls/shell32/resources/document.svg
> programs/regedit/string.svg
> ln -sf ../../dlls/shell32/resources/mycomputer.svg
> programs/regedit/computer.svg
> ln -sf ../../dlls/shell32/resources/folder_open.svg
> programs/regedit/folderopen.svg
> ln -sf ../../dlls/shell32/resources/window.svg programs/taskmgr/window.svg
> ln -sf ../../dlls/shell32/resources/window.svg
> programs/taskmgr/windowsm.svg
> ln -sf ../../dlls/shell32/resources/drive.svg dlls/comdlg32/hdisk.svg
> ln -sf ../../dlls/shell32/resources/folder.svg dlls/comdlg32/folder.svg
> ln -sf ../../dlls/shell32/resources/network.svg dlls/comdlg32/network.svg
> ln -sf ../../dlls/shell32/resources/folder_open.svg
> dlls/comdlg32/folder2.svg
> ln -sf ../../dlls/shell32/resources/disk_drive.svg dlls/comdlg32/floppy.svg
> ln -sf ../../dlls/shell32/resources/optical_drive.svg
> dlls/comdlg32/cdrom.svg
>

The previous quote is an example but, in my case i don't know why it's
necessary to do all these things.
I understand when newbie users want to help but give up because too
complicated...

Bug#923077: fixed in pyzor 1:1.0.0-5

[gustavo panizzo]

On Wed, Jan 13, 2021 at 12:37:06PM +0100, Timo van Roermund wrote:

Addition on the above: this is effectively patch 67b471d upstream:

https://github.com/SpamExperts/pyzor/commit/67b471dd168db9468548aef3ffadca9554164ac0#diff-747109b54d67454f173b2571e6d1e7ecef06cae9c26c665477e88ad7a4b5156c


This one complements the already included patch 6332a42:

https://github.com/SpamExperts/pyzor/commit/6332a429ed415187599ecce7d8a169ee19f0bbe5



I'm testing more extensively with both patches applied

I had this patchset applied to my server but somehow I lost it and
overwrite with the previous patch alone

--
IRC: gfa
GPG: 0x27263FA42553615F904A7EBE2A40A2ECB8DAD8D5
OLD GPG: 0x44BB1BA79F6C6333

Bug#980049: fwupd: Should fwupd specify dbus as a dependency?

[Limonciello, Mario]

I don't think it's a true dependency.  You can use fwupdtool without it.  It's 
only needed for fwupdmgr.
Perhaps a Recommends would be better?

That being said I don't think it would solve it for you.  Systemd has dbus as a 
Recommends and you still appear to not have it.

> -Original Message-
> From: lukas 
> Sent: Wednesday, January 13, 2021 6:55
> To: Debian Bug Tracking System
> Subject: Bug#980049: fwupd: Should fwupd specify dbus as a dependency?
> 
> 
> [EXTERNAL EMAIL]
> 
> Package: fwupd
> Version: 1.5.3-2
> Severity: important
> 
> Dear Maintainers,
> 
> thanks for maintaining this package and taking the time to consider this bug
> report.
> 
> On a minimal system, it happened to me that when installing fwupd, dbus is
> has not been installed as a dependency.
> Without dbus, fwupd turned out to be unusable ("Failed to connect to daemon"
> on ``fwupdmgr refresh``).
> 
> Do we maybe need to list the package "dbus" as a dependency of "fwupd"?
> 
> Cheers,
> 
> Lukas
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.10.0-1-amd64 (SMP w/4 CPU threads)
> Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages fwupd depends on:
> ii  libc6  2.31-9
> ii  libcurl3-gnutls7.74.0-1
> ii  libefiboot137-6
> ii  libelf10.182-3
> ii  libflashrom1   1.2-5
> ii  libfwupd2  1.5.3-2
> ii  libfwupdplugin11.5.3-2
> ii  libglib2.0-0   2.66.4-1
> ii  libgudev-1.0-0 234-1
> ii  libgusb2   0.3.5-1
> ii  libjcat1   0.1.3-2
> ii  libjson-glib-1.0-0 1.6.0-2
> ii  libpolkit-gobject-1-0  0.105-29
> ii  libsmbios-c2   2.4.3-1
> ii  libsqlite3-0   3.34.0-1
> ii  libsystemd0247.2-4
> ii  libtss2-esys-3.0.2-0   3.0.3-1
> ii  libxmlb1   0.1.15-2
> ii  shared-mime-info   2.0-1
> 
> Versions of packages fwupd recommends:
> pn  bolt   
> pn  fwupd-signed   
> ii  python33.9.1-1
> pn  secureboot-db  
> ii  udisks22.9.1-2
> 
> fwupd suggests no packages.
> 
> -- no debconf information

Bug#973433: linux-image-5.9.0-1-amd64: kernel dies with: kernel: BUG: NULL pointer dereference

[Salvatore Bonaccorso]

Source: linux
Source-Version: 5.9.11-1 

Hi Simon,

On Fri, Oct 30, 2020 at 11:09:40AM +0100, Simon Kainz wrote:
> Package: src:linux
> Version: 5.9.1-1
> Severity: critical
> Justification: breaks the whole system
> 
> Dear Maintainer,
> 
> Please see the attached crash dump. This machine is a SLURM head
> node, so usually not much load besides some occasional compile runs.
> We a running a glusterfs filesystem on all cluster nodes, maybe
> heavy disk I/O triggers this issue.

This looks to be fixed with 4349a83a3190 ("mm: fix
readahead_page_batch for retry entries") which was in applied in
5.10-rc5 and backported to 5.9.11 as well.

I'm closing the bug with this version, but in case you still
experience the issue please report back.

Regards,
Salvatore

Bug#980058: mk-build-deps: provide a way to generate B-Ds for arch-independent builds

[IOhannes m zmoelnig]

Package: devscripts
Version: 2.20.5
Severity: wishlist

Dear Maintainer,

as mentioned in the policy [1], d/control can have a Build-Depends-Indep field
to specify (additional) dependencies for building the arch:all packages of a
source package.

'mk-build-deps' has a '--build-indep' flag, that seems to be targetted at this
use-case (building only arch:all) packages, but in it's current form I think it
is of little use.
as the mk-build-deps(1) mentions, the '--build-indep' flag generates a
> package which only depends on the source package's Build-Depends-Indep
> dependencies

however, as explained in [1], the build-dependencies is more like:
- for building "arch:any", install 'Build-Depends' + 'Build-Depends-Arch'
- for building "arch:all", install 'Build-Depends' + 'Build-Depends-Indep'
- for building all packages, install 'Build-Depends' + 'Build-Depends-Arch' + 
'Build-Depends-Indep'

now, depending on it's invocation 'mk-build-deps' will create a dependency
package for a subset of the Build-Depends:
- 'mk-build-deps': depends on 'Build-Depends' + 'Build-Depends-Arch' + 
'Build-Depends-Indep'
- 'mk-build-deps --build-dep': depends on 'Build-Depends' + 'Build-Depends-Arch'
- 'mk-build-deps --build-indep': depends on 'Build-Depends-Indep'

as you can see, the invocation of 'mk-build-deps' (without flags) matches the
target of building all packages (both arch:any and arch:all).
the invocation of 'mk-build-deps --build-dep' matches the target of building
only arch:any packages.
however, the invocation of 'mk-build-deps --build-indep' does NOT match the
target of building only arch:all packages (as the 'Build-Depends' is missing)

i'm not sure whether this is actually a bugin 'mk-build-deps', but since it is
documented in the mangpage, it probably is not.
however, I don't see any use in installing Build-Depends-Indep only, so I don't
know what the '--build-indep' flag is intended for.

if it is not a bug (and there *is* a use-case for the flag as is), I would
suggest to add a new flag to create a dependency package targetted at building
arch:all binary packages.

in the end, i would like to have the salsa-ci pipeline "test-build-all" behave
more like the buildds, and make it only install the packages required to build
the arch:all portions (and leave out Build-Depends-Arch). since the
"test-build-all" pipeline currently depends on 'mk-build-deps' i need your
co-operation ;-)

thanks for considering.

PS: i haven't checked the situtation of Build-Conflicts-*, but it should behave
accordingly.


[1] 
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-sourcebinarydeps

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages devscripts depends on:
ii  dpkg-dev  1.20.7.1
ii  fakeroot  1.25.3-1.1
ii  file  1:5.39-3
ii  gnupg 2.2.20-1
ii  gpgv  2.2.20-1
ii  libc6 2.31-9
ii  libfile-dirlist-perl  0.05-2
ii  libfile-homedir-perl  1.006-1
ii  libfile-touch-perl0.11-1
ii  libfile-which-perl1.23-1
ii  libipc-run-perl   20200505.0-1
ii  libmoo-perl   2.004004-1
ii  libwww-perl   6.52-1
ii  patchutils0.4.2-1
ii  perl  5.32.0-6
ii  python3   3.9.1-1
ii  sensible-utils0.0.14
ii  wdiff 1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 2.1.17
ii  curl7.74.0-1
ii  dctrl-tools 2.24-3+b1
ii  debian-keyring  2020.12.24
ii  dput1.1.0
ii  equivs  2.3.1
ii  libdistro-info-perl 0.24
ii  libdpkg-perl1.20.7.1
ii  libencode-locale-perl   1.05-1.1
ii  libgit-wrapper-perl 0.048-1
ii  libgitlab-api-v4-perl   0.25-2
ii  liblist-compare-perl0.55-1
ii  liblwp-protocol-https-perl  6.10-1
ii  libsoap-lite-perl   1.27-1
ii  libstring-shellquote-perl   1.04-1
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 5.05-1
ii  licensecheck3.0.47-1
ii  lintian 2.104.0
ii  man-db  2.9.3-2
ii  patch   2.7.6-7
ii  pristine-tar1.49
ii  python3-apt 2.1.7
ii  python3-debian  0.1.39
ii  python3-magic   2:0.4.15-5
ii  python3-requests2.25.1+dfsg-2
ii  python3-unidiff 0.5.5-2
ii  python3-xdg  

Bug#980057: ruby-redcarpet: CVE-2020-26298

[Salvatore Bonaccorso]

Source: ruby-redcarpet
Version: 3.5.0-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for ruby-redcarpet.

CVE-2020-26298[0]:
| Redcarpet is a Ruby library for Markdown processing. In Redcarpet
| before version 3.5.1, there is an injection vulnerability which can
| enable a cross-site scripting attack. In affected versions no HTML
| escaping was being performed when processing quotes. This applies even
| when the `:escape_html` option was being used. This is fixed in
| version 3.5.1 by the referenced commit.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-26298
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-26298
[1] 
https://github.com/vmg/redcarpet/commit/a699c82292b17c8e6a62e1914d5eccc252272793
[2] https://github.com/advisories/GHSA-q3wr-qw3g-3p4h

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#980056: getmail6: sometimes dies on running external filter program in version 6.13

[Vaclav Ovsik]

Package: getmail6
Version: 6.13-1
Severity: normal
Tags: upstream

Dear Maintainer,
I have problems after upgrade to 6.13.
A snip of log:

 2021-01-13 16:23:09 getmailOperationError error (child pid 83739 killed by 
signal 8)
 2021-01-13 16:23:09   1 messages (19425 bytes) retrieved, 0 skipped
 2021-01-13 16:24:50 Initializing 
SimpleIMAPSSLRetriever:vaclav.ov...@gmail.com@imap.gmail.com:993:
 2021-01-13 16:24:55 getmailOperationError error (child pid 84030 killed by 
signal 8)
 2021-01-13 16:24:55   1 messages (19425 bytes) retrieved, 0 skipped
 2021-01-13 16:26:37 Initializing 
SimpleIMAPSSLRetriever:vaclav.ov...@gmail.com@imap.gmail.com:993:
 2021-01-13 16:26:42 getmailOperationError error (child pid 84309 killed by 
signal 8)
 2021-01-13 16:26:42   1 messages (19425 bytes) retrieved, 0 skipped

corresponding rc section:

 [filter-1]
 type = Filter_external
 path = /usr/bin/spamassassin
 ignore_stderr = True

Downgrade:

 bobek:~# dpkg -i /tmp/getmail6_6.11-1_all.deb
 dpkg: warning: downgrading getmail6 from 6.13-1 to 6.11-1
 (Reading database ... 604760 files and directories currently installed.)
 Preparing to unpack /tmp/getmail6_6.11-1_all.deb ...
 Unpacking getmail6 (6.11-1) over (6.13-1) ...
 Setting up getmail6 (6.11-1) ...
 Processing triggers for man-db (2.9.3-2) ...

and running getmail (6.11)…

 2021-01-13 16:31:12 Initializing 
SimpleIMAPSSLRetriever:vaclav.ov...@gmail.com@imap.gmail.com:993:
 2021-01-13 16:31:19 msg 1/6 (19425 bytes) msgid 616589423/518636 from 
 delivered to MDA_external command procmail (b''), 
deleted
 2021-01-13 16:31:23 msg 2/6 (8088 bytes) msgid 616589423/518637 from 
 delivered to MDA_external command procmail (b''), 
deleted
 2021-01-13 16:31:27 msg 3/6 (8302 bytes) msgid 616589423/518638 from 
 delivered to MDA_external command procmail (b''), 
deleted
 2021-01-13 16:31:31 msg 4/6 (11893 bytes) msgid 616589423/518639 from 
 delivered to MDA_external command procmail (b''), 
deleted
 2021-01-13 16:31:35 msg 5/6 (20792 bytes) msgid 616589423/518640 from 
 delivered to MDA_external command procmail (b''), 
deleted
 2021-01-13 16:31:39 msg 6/6 (8057 bytes) msgid 616589423/518641 from 
 delivered to MDA_external command procmail (b''), 
deleted
 2021-01-13 16:31:39   6 messages (76557 bytes) retrieved, 0 skipped

Things work again.
The bug is in the upstream getmail 6.13. The bug demonstrates itself only
sometimes :-/.
Regards
-- 
Zito


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages getmail6 depends on:
ii  python3  3.9.1-1

getmail6 recommends no packages.

getmail6 suggests no packages.

-- no debconf information

Bug#980055: debcheckout displays warnings from `apt-get source` on packages whose repo only contains debian/

[nicoo]

Package: devscripts
Version: 2.20.5
Severity: normal
File: /usr/bin/debcheckout

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

This is what currently happens when chefcking out a package whose repository
only contains the debian/ directory, like chromium :

$ debcheckout chromium
declared git repository at 
https://salsa.debian.org/chromium-team/chromium.git
git clone https://salsa.debian.org/chromium-team/chromium.git chromium 
...
Cloning into 'chromium'...
[...]
repository only contains the debian directory, using apt-get source
Reading package lists... Done
NOTICE: 'chromium' packaging is maintained in the 'Git' version control 
system at:
https://salsa.debian.org/chromium-team/chromium.git
Please use:
git clone https://salsa.debian.org/chromium-team/chromium.git
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 394 MB of source archives.
Get:1 http://localhost:3142/debian sid/main chromium 87.0.4280.141-0.1 
(dsc) [3 576 B]
Get:2 http://localhost:3142/debian sid/main chromium 87.0.4280.141-0.1 
(tar) [394 MB]
Get:3 http://localhost:3142/debian sid/main chromium 87.0.4280.141-0.1 
(diff) [189 kB]  
Fetched 394 MB in 2min 53s (2 273 kB/s)
dpkg-source: info: extracting chromium in chromium-87.0.4280.141
[...]


As you can see, there are very-verbose warnings about the packaging repository
being preferred.  Would it be possible to silence those?


Best,

  nicoo


- -- Package-specific info:

- --- /etc/devscripts.conf ---
Empty.

- --- ~/.devscripts ---
DEBSIGN_KEYID="0xE44E9EA54B8E256AFB7349D3EC9D370872BC7A8C"

- -- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages devscripts depends on:
ii  dpkg-dev  1.20.5
ii  fakeroot  1.25.3-1.1
ii  file  1:5.39-3
ii  gnupg 2.2.20-1
ii  gnupg22.2.20-1
ii  gpgv  2.2.20-1
ii  libc6 2.31-9
ii  libfile-dirlist-perl  0.05-2
ii  libfile-homedir-perl  1.006-1
ii  libfile-touch-perl0.11-1
ii  libfile-which-perl1.23-1
ii  libipc-run-perl   20200505.0-1
ii  libmoo-perl   2.004004-1
ii  libwww-perl   6.51-1
ii  patchutils0.4.2-1
ii  perl  5.32.0-6
ii  python3   3.9.1-1
ii  sensible-utils0.0.12+nmu1
ii  wdiff 1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 2.1.17
ii  curl7.74.0-1
ii  dctrl-tools 2.24-3+b1
ii  debian-keyring  2020.12.24
ii  dput-ng [dput]  1.31
pn  equivs  
ii  libdistro-info-perl 0.24
ii  libdpkg-perl1.20.5
ii  libencode-locale-perl   1.05-1.1
ii  libgit-wrapper-perl 0.048-1
ii  libgitlab-api-v4-perl   0.25-2
ii  liblist-compare-perl0.55-1
ii  liblwp-protocol-https-perl  6.10-1
ii  libsoap-lite-perl   1.27-1
ii  libstring-shellquote-perl   1.04-1
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 5.05-1
ii  licensecheck3.0.47-1
ii  lintian 2.104.0
ii  man-db  2.9.3-2
ii  patch   2.7.6-6
ii  pristine-tar1.49
ii  python3-apt 2.1.7
ii  python3-debian  0.1.39
ii  python3-magic   2:0.4.15-5
ii  python3-requests2.25.1+dfsg-2
pn  python3-unidiff 
ii  python3-xdg 0.26-3
ii  strace  5.10-1
ii  unzip   6.0-25
ii  wget1.21-1+b1
ii  xz-utils5.2.5-1.0

Versions of packages devscripts suggests:
ii  adequate 0.15.3
pn  at   
ii  autopkgtest  5.15
pn  bls-standalone   
pn  bsd-mailx | mailx
ii  build-essential  12.9
ii  check-all-the-things 2017.05.20+nmu1
pn  cvs-buildpackage 
ii  debhelper13.3.1
pn  devscripts-el
ii  diffoscope   164
pn  disorderfs   
ii  dose-extra   5.0.1-16
pn  duck 
pn  faketime 
ii  gnuplot  5.4.1+dfsg1-1
ii  gnuplot-qt [gnuplot] 5.4.1+dfsg1-1
ii  how-can-i-help   17
pn  libauthen-sasl-perl   

Bug#979834: chromiums shows … nothing but errors on the console

[nicoo]

On Wed, Jan 13, 2021 at 04:05:33PM +0100, nicoo wrote:
> Could you try to reproduce with `--temp-profile`, to eliminate the possibility
> of it being something specific to your system?

Apologies, I meant “something specific to your profile”, such as an
addon/extension, user-settable configuration, etc.


signature.asc
Description: PGP signature

Bug#979834: chromiums shows … nothing but errors on the console

[nicoo]

Control: tag -1 + moreinfo unreproducible
Control: severity -1 important

Hi Gregor,

Chiming in, even though I'm not a chromium maintainer, as I just pulled in the
new version from sid and cannot reproduce the issue, under either Wayland/sway
or X11 (in both case on my x230 laptop (Intel Ivy Bridge, “HD Graphics 4000”)

Could you try to reproduce with `--temp-profile`, to eliminate the possibility
of it being something specific to your system?


On Mon, Jan 11, 2021 at 08:21:59PM +0100, gregor herrmann wrote:
> - tons of errors like
> 
> Xlib: sequence lost (0x1012c > 0x12e) in reply type 0x0!
> 
>   in the terminal.

I suspect the Xlib “sequence lost” mesage is a red herring, as I get it too
even though chromium works for me :

$ chromium --temp-profile
Using temporary profile: /tmp/tmp.j0L91i0yf5
libva error: /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so init failed
[93076:93076:0113/154823.164806:ERROR:vaapi_wrapper.cc(541)] vaInitialize 
failed: unknown libva error
Xlib: sequence lost (0x1010d > 0x10f) in reply type 0x0!
[93076:93076:0113/154823.197536:ERROR:sandbox_linux.cc(374)] 
InitializeSandbox() called with multiple threads in process gpu-process.
Xlib: sequence lost (0x10128 > 0x12a) in reply type 0x0!
Xlib: sequence lost (0x1013c > 0x13e) in reply type 0x0!
Xlib: sequence lost (0x10160 > 0x162) in reply type 0x0!
Xlib: sequence lost (0x1017c > 0x17e) in reply type 0x0!
[93076:93076:0113/154837.827426:ERROR:gl_surface_presentation_helper.cc(259)] 
GetVSyncParametersIfAvailable() failed for 1 times!
[93076:93076:0113/154837.836280:ERROR:gl_surface_presentation_helper.cc(259)] 
GetVSyncParametersIfAvailable() failed for 2 times!
[the output ends here avter I exited chromium cleanly]


> After looking through 
> https://peter.sh/experiments/chromium-command-line-switches/
> and trying some switches I found that --gpu-sandbox-start-early helps
> to get it back to working.

That's something, at least.

I'm downgrading the severity of the bug to “important”, as it fits: it is “a bug
which has a major effect on the usability of a package,” since chromium doesn't
start with default arguments, “without rendering it completely unusable to
everyone” as it only affects a subset of users and a workaround is available

AFAIK, “serious” should only be set by the release team or package maintainers,
or for a policy violation.


> Some observations:

Here is what things look like for me

> % chromium --use-gl=desktop
$ chromium --temp-profile --use-gl=desktop
Using temporary profile: /tmp/tmp.Ae6cGnhoWm
libva error: /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so init failed
[93483:93483:0113/154905.880613:ERROR:vaapi_wrapper.cc(541)] vaInitialize 
failed: unknown libva error
Xlib: sequence lost (0x1010d > 0x10f) in reply type 0x0!
[93483:93483:0113/154905.910838:ERROR:sandbox_linux.cc(374)] 
InitializeSandbox() called with multiple threads in process gpu-process.
Xlib: sequence lost (0x10128 > 0x12a) in reply type 0x0!
Xlib: sequence lost (0x1013c > 0x13e) in reply type 0x0!
Xlib: sequence lost (0x10160 > 0x162) in reply type 0x0!
Xlib: sequence lost (0x1017c > 0x17e) in reply type 0x0!

> % chromium --use-gl=desktop --gpu-sandbox-start-early
$ chromium --temp-profile --use-gl=desktop --gpu-sandbox-start-early
Using temporary profile: /tmp/tmp.vl1Q7azIUv
libva error: /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so init failed
[93857:93857:0113/154933.600763:ERROR:vaapi_wrapper.cc(541)] vaInitialize 
failed: unknown libva error
[93857:93857:0113/154933.647761:ERROR:gl_implementation.cc(282)] Failed to load 
libGL.so.1: libGL.so.1: cannot open shared object file: Operation not permitted
[93857:93857:0113/154933.661939:ERROR:viz_main_impl.cc(150)] Exiting GPU 
process due to errors during initialization
libva error: /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so init failed
[93900:93900:0113/154933.696658:ERROR:vaapi_wrapper.cc(541)] vaInitialize 
failed: unknown libva error

> % chromium --use-gl=egl --gpu-sandbox-start-early
$ chromium --temp-profile --use-gl=egl --gpu-sandbox-start-early
Using temporary profile: /tmp/tmp.oynQ1dAJ1A
libva error: /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so init failed
[94189:94189:0113/154959.472122:ERROR:vaapi_wrapper.cc(541)] vaInitialize 
failed: unknown libva error
[94189:94189:0113/154959.476500:ERROR:gl_implementation.cc(282)] Failed to load 
libGLESv2.so.2: libGLESv2.so.2: cannot open shared object file: Operation not 
permitted
[94189:94189:0113/154959.483017:ERROR:viz_main_impl.cc(150)] Exiting GPU 
process due to errors during initialization
libva error: /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so init failed
[94210:94210:0113/154959.525251:ERROR:vaapi_wrapper.cc(541)] vaInitialize 
failed: unknown libva error


Best,

  nicoo


signature.asc
Description: PGP signature

Bug#979554: please clarify case sensitiveness of mime.types

[Alexandre Duret-Lutz]

Charles Plessy  writes:

> The problem here is that I have no comprehensive information on how
> softwares use the mime.types files.  I can not rule out that some use
> case sensitivity for their own good reasons, so if no other bug arise, I
> would like to continue to stick to the information provided by the IANA.
>
>> Those entries will behave differently for "see" and Python's
>> "mimetypes.guess_type()".   For instance "see" will consider "foo.sar"
>> as application/vnd.sar, but "mimetypes.guess_type()" will not.
>
> I can not tell which approach is wiser...  The mime.types file is not
> comprehensive and is usually lagging.  What if there is another file
> format around that uses the lowercase `sar` extension?


I've looked at four other implementations, to find new behaviors.


Emacs assumes that /etc/mime.types contains only lowercase extensions.
When (mailcap-extension-to-mime ext) is called, ext is first downcased
before being compared to the extensions in /etc/mime.types.  So it will
be unable to work with extensions like SAR, that are only listed in
uppercase in /etc/mime.types.

(mailcap-extension-to-mime "JPG") => "image/jpeg"
(mailcap-extension-to-mime "jpg") => "image/jpeg"
(mailcap-extension-to-mime "SAR") => nil
(mailcap-extension-to-mime "sar") => nil


Apache 2.4's mod_mime convert extensions to lowercase when reading them
from /etc/mime.types and before looking them up.  So it's the same
case-insensitive behavior as for the "see" command mentioned in my
previous mail.


Go (https://golang.org/src/mime/type.go) keeps two maps, one where all
extensions are stored as they are in /etc/mime.types, one where they
are lowercased.  Lookup is done case-sensitive first, then
case-insensitive.  That's a new behavior, compared to other tools.


Mutt is doing a case insensitive comparison of each extension in
/etc/mime.types again the end of the filename to check.  So regarding
case-sensitiveness it behaves like Python and see.

However, contrary to Python and see, Mutt is able to deal with 
extensions that contains a dot in mime.types.  (The only one
listed in /etc/mime.types is "pcf.Z", and seems to work in Python
and see only because these implementations have some hard-coded
handling of .Z, .gz, and other similar extensions, so they actually
do a lookup for "pcf", which has the same mime type in /etc/mime.types).
In case of multiple matches, Mutt keeps the largest one.

>> It would be nice to clarify the semantics in the comments at the top of
>> mime.types.
>
> Definitely! I hope to do so or write a proper man page after I dig the
> history of that file.

On that topic, the comment at the top of the file:

#  Users can add their own types if they wish by creating a ".mime.types"
#  file in their home directory.  Definitions included there will take
#  precedence over those listed here.

should probably be rephrased to suggest that this is how applications
are expected to work, but that not all of them will do.  For instance
Python and Go won't look at this file.

-- 
Alexandre Duret-Lutz

Bug#980053: [Aptitude-devel] Bug#980035: Bug#980035: aptitude: segmentation fault when starting aptitude

[Vincent Lefevre]

[moved to Cc: 980053]

Hi,

On 2021-01-13 15:33:00 +0100, Axel Beckert wrote:
> Vincent Lefevre wrote:
> > Hmm... I think that you should forget that test. I thought
> > that aptitude-run-state-bundle would only depend on files from
> > aptitude-segv.bundle, but it still reads some other files from
> > /var/lib according to strace. And now I get
> > 
> > --- Upgradable Packages (65)
> > 
> > instead of
> > 
> > --- Upgradable Packages (61)
> > 
> > Since the crashes are very sensitive to the system status, the
> > above test might not be reliable.
> 
> Ack. That's now https://bugs.debian.org/980053 :-)

Well, 980053 is about aptitude-create-state-bundle. The above issue
is about aptitude-run-state-bundle. Perhaps this is due to the
aptitude-create-state-bundle bug, but I think that if a file is
missing, aptitude-run-state-bundle should fail, not fall back to
/var/lib files.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#980035: [Aptitude-devel] Bug#980035: Bug#980035: aptitude: segmentation fault when starting aptitude

[Vincent Lefevre]

On 2021-01-13 15:07:26 +0100, Axel Beckert wrote:
> Vincent: Got the bundle, thanks! Wasn't able to provoke a segfault
> with it, even not after pressing "u".

With the bundle, the crash occurs while the UI isn't displayed yet.
But I can see in particular:

2300077 stat("/var/lib/dpkg/status", {st_mode=S_IFREG|0644, st_size=3777850, 
...}) = 0
2300081 openat(AT_FDCWD, "/var/lib/dpkg/arch", O_RDONLY) = -1 ENOENT (No such 
file or directory)
2300082 openat(AT_FDCWD, "/var/lib/dpkg/arch", O_RDONLY) = -1 ENOENT (No such 
file or directory)
2300083 openat(AT_FDCWD, "/var/lib/dpkg/arch", O_RDONLY) = -1 ENOENT (No such 
file or directory)
2300077 stat("/var/lib/apt-xapian-index/index", {st_mode=S_IFREG|0644, 
st_size=41, ...}) = 0
2300077 openat(AT_FDCWD, "/var/lib/apt-xapian-index/index", O_RDONLY) = 36
2300077 openat(AT_FDCWD, "/var/lib/aptitude//pkgstates", O_RDONLY) = 36
2300077 openat(AT_FDCWD, "/var/lib/debtags/package-tags", O_RDONLY) = -1 ENOENT 
(No such file or directory)
222 symlinkat("/var/local/apt/./Packages", 4, 
".//var/lib/apt/lists/_var_local_apt_._Packages") = 0

while most files are read from the /tmp version.

So, as this seems to depend on the system, this is not surprising.
When I look in detail:

--\ Upgradable Packages (65)
  --\ admin  Administrative utilities (install software, manage users, e
--\ main   The main Debian archive (3)
i   apt2.1.17   2.1.17+local1
i   apt-utils  2.1.17   2.1.17+local1
[...]

The 2.1.17+local1 packages are the newly reinstalled patched versions
(now listed in /var/local/apt/Packages).

They do not exist in the bundle!!!

> But as mentioned in #980037 this seems normal in such a case without
> a special kernel. So thanks for the bug report!

Note that I do *not* have a special kernel. So this is unrelated.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#978220: Bug#964198: hylafax: diff for NMU version 3:6.0.7-3.1

[Giuseppe Sacco]

Hello Bastien,
thank you very much for your NMU.

Bye,
Giuseppe

Bug#980035: [Aptitude-devel] Bug#980035: Bug#980035: aptitude: segmentation fault when starting aptitude

[Axel Beckert]

Hi,

Vincent Lefevre wrote:
> Hmm... I think that you should forget that test. I thought
> that aptitude-run-state-bundle would only depend on files from
> aptitude-segv.bundle, but it still reads some other files from
> /var/lib according to strace. And now I get
> 
> --- Upgradable Packages (65)
> 
> instead of
> 
> --- Upgradable Packages (61)
> 
> Since the crashes are very sensitive to the system status, the
> above test might not be reliable.

Ack. That's now https://bugs.debian.org/980053 :-)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#980035: aptitude: segmentation fault when starting aptitude

[Vincent Lefevre]

On 2021-01-13 12:04:57 +0100, Vincent Lefevre wrote:
> On 2021-01-13 11:24:33 +0100, Vincent Lefevre wrote:
> > A bundle is available for a limited time:
> > 
> >   https://www.vinc17.net/aptitude-segv.bundle
> > 
> > I can reproduce the crash (but not always) with
> > 
> >   aptitude-run-state-bundle aptitude-segv.bundle
> > 
> > on this machine and on another one.
> 
> When it doesn't crash, aptitude doesn't suggest any action.
> 
> But on a 3rd machine, which has the same aptitude version, but older
> versions of dependencies, aptitude never crashes, and I get:
> 
> [1(1)/...] Actions: 2 keeps, 1 upgrade
> e: Examine  !: Apply  .: Next  ,: Previous
> 
> and 'e' says:
> 
> Packages  Resolve Dependencies
>   --\ Keep the following packages at their current version:   
>   
> desktop-file-utils [0.26-1 (now, testing, 
> unstable)]
> gvfs-common  [1.46.1-2 (now, testing, 
> unstable)]
>   --\ Upgrade the following packages:
> libmtp-common [1.1.17-3 now, testing, unstable -> 1.1.18-1 
> experimental]
> 
> (suggesting to upgrade a package to experimental like that is
> incorrect, unless aptitude already broke the system).

The cause of this issue seems to be that aptitude-run-state-bundle
depends on the current system status, not just aptitude-segv.bundle.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#892001: ITP: dbus-broker -- Linux D-Bus Message Broker

[Alex ARNAUD]

Le 12/01/2021 à 16:50, Luca Boccassi a écrit :

I understand the point of view, but given the release is 6+ months
away, there's all the time in the world to have it tested. And if we
find something that for whatever reason is completely broken in Debian
but works completely fine in Fedora/Yocto/etc then we can simply remove
it from testing. Nothing depends on it, so unless I'm missing
something, there's no extra cost involved as far as I can see.

Indeed, it makes sense to me.

Bug#980054: jquery-goodies_12-2_all.changes REJECTED

[Aurelien Jarno]

Source: jquery-goodies
Version: 12-2
Severity: serious

- Message transféré de Debian FTP Masters  
-

From: Debian FTP Masters 
To: all Build Daemon 
Date: Wed, 13 Jan 2021 14:24:56 +
Subject: jquery-goodies_12-2_all.changes REJECTED
Message-Id: 



Version check failed:
Your upload included the binary package libjs-jquery-mousewheel, version 12-2, 
for all,
however testing already has version 1:3.1.13-2.
Uploads to unstable must have a higher version than present in testing.

Mapping sid to unstable.

===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.




- Fin du message transféré -

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#980035: [Aptitude-devel] Bug#980035: aptitude: segmentation fault when starting aptitude

[Vincent Lefevre]

On 2021-01-13 14:46:21 +0100, Vincent Lefevre wrote:
> On 2021-01-13 12:31:05 +0100, Julian Andres Klode wrote:
> > Smells like 980037? Bug in APT's cache building upon mremap() in new
> > code path in 2.1.16/17.
> 
> Yes, I first rebuilt apt, and
> 
>   aptitude-run-state-bundle aptitude-segv.bundle
> 
> was still crashing, then applied the patch suggested at
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980037#10
> 
> and I no longer get any crash.

Hmm... I think that you should forget that test. I thought
that aptitude-run-state-bundle would only depend on files from
aptitude-segv.bundle, but it still reads some other files from
/var/lib according to strace. And now I get

--- Upgradable Packages (65)

instead of

--- Upgradable Packages (61)

Since the crashes are very sensitive to the system status, the
above test might not be reliable.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#980035: [Aptitude-devel] Bug#980035: Bug#980035: aptitude: segmentation fault when starting aptitude

[Axel Beckert]

Control: clone -1 -2
Control: retile -2 aptitude-create-state-bundle should include more files from 
file:/// URLs
Control: severity -2 minor
Control: submitter -2 Axel Beckert 
Control: tag -2 - security

Hi Julian and Vincent,

Julian Andres Klode wrote:
> > I got a first "segmentation fault" just after updating ('u' in the TUI).
> > Now, each time I run aptitude, a segmentation occurs one second after
> > starting it.

H, works still fine for me so far with 2.1.17.

> > I suppose that it doesn't like some data that have been fetched.
> > Tagging security for this reason.
> 
> Smells like 980037?

Yep, smells like something which came in with apt 2.1.17.

> Bug in APT's cache building upon mremap() in new code path in
> 2.1.16/17.

I'd rather guess 2.1.17 only given the time of the bug report.

Then again, I so far didn't run into it, neither with "aptitude -u"
(as I usually do on several boxes several times per day) nor with
pressing "u" inside the TUI.

Vincent: Got the bundle, thanks! Wasn't able to provoke a segfault
with it, even not after pressing "u". But as mentioned in #980037 this
seems normal in such a case without a special kernel. So thanks for
the bug report!

Then again, it argued about some missing files. Seems as if
aptitude-create-state-bundle should copy way more files when handling
file:/// URLs:

# aptitude-run-state-bundle ~abe/aptitude/aptitude-segv-#980035.bundle aptitude 
update
[…]
Get: 33 file:/var/local/apt ./ Packages
Err file:/var/local/apt ./ Packages
  File not found - /var/local/apt/./Packages (2: No such file or directory)
Get: 34 file:/var/local/apt ./ Translation-en
[…]  
Fetched 87.9 MB in 10s (8426 kB/s)
W: Download is performed unsandboxed as root as file 
'/tmp/aptitudebug.9E6xy9EY0/var/lib/apt/lists/partial/ftp.fr.debian.org_debian_dists_stable_InRelease'
 couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)
E: Failed to download some files
[…]
W: Failed to fetch file:/var/local/apt/./Packages: File not found - 
/var/local/apt/./Packages (2: No such file or directory)
E: Some index files failed to download. They have been ignored, or old ones 
used instead.

Created a new bug report for that.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE