Bug#956118: pianobar FTCBFS: uses the build architecture pkg-config

[Lars-Dominik Braun]

Hello Helmut,

I just came across your patch and applied it upstream as commit
4b45e043aa6371edc2808bb52f6c86910fa0ea47.

Cheers,
Lars

Bug#980902: rmatrix: which reverse dependencies need rebuilds?

[Graham Inggs]

Hi

On Sun, 24 Jan 2021 at 18:06, Graham Inggs  wrote:
> I'm awaiting autopkgtest results on the binNMU'd r-cran-tmb.  I will
> update this bug and #980809 when they are in.

The autopkgtests for r-cran-tmb [1] and r-cran-glmmtmb [2] have
completed on all architectures except for s390x, which are still
queued.  So no definitive answer for #980809 yet.  The latest results
no longer have the "Package version inconsistency detected" warning.

On Sun, 24 Jan 2021 at 06:12, Graham Inggs  wrote:
> The actual warning message is generated by r-base,

This is not true, I was confused by a similar error I had seen in
another package (where the warning does come from r-base):

Error: package or namespace load failed for ‘DropletUtils’ in
loadNamespace(j <- imp[[1L]], c(lib.loc, .libPaths()), versionCheck =
vI[[j]]):
 namespace ‘Matrix’ 1.2-18 is already loaded, but >= 1.3.2 is required

The warning in r-cran-tmb comes from r-cran-tmb itself [3].  I had a
look on codesearch.debian.net and found the only other occurrences of
packageVersion("Matrix") were in r-cran-rcpparmadillo and
r-cran-igraph, and that code seems to be catering for different
versions of Matrix, not warning against them.  In my opinion, there's
nothing to be done in rmatrix, and I will reassign this bug to
r-cran-tmb, affecting r-cran-glmmtmb.  I think the solution there is
to simply upgrade the warning to an error and then it should be caught
by autopkgtest whenever it wants rebuilding.

Regards
Graham


[1] https://ci.debian.net/packages/r/r-cran-tmb/
[2] https://ci.debian.net/packages/r/r-cran-glmmtmb/
[3] https://salsa.debian.org/r-pkg-team/r-cran-tmb/-/blob/master/R/zzz.R#L8

Bug#980995: weston-info recommends wayland-info that does not exist in Debian

[Ryutaroh Matsumoto]

Package: weston
Version: 9.0.0-2
Severity: minor

Dear Maintainer,

When weston-info is started, it says:


$ weston-info

*** Please use wayland-info instead
*** weston-info is deprecated and will be removed in a future version

But "weston-info" does not exist in the Debian packages.
Best regards, Ryutaroh Matsumoto

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

Kernel: Linux 5.10.10raspi4usb (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP, 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 weston depends on:
ii  adduser  3.118
ii  libc62.31-9
ii  libcairo21.16.0-5
ii  libcolord2   1.4.5-3
ii  libdrm2  2.4.103-2
ii  libegl1  1.3.2-1
ii  libegl1-mesa 20.3.3-1
ii  libevdev21.10.1+dfsg-1
ii  libgbm1  20.3.3-1
ii  libgles2 1.3.2-1
ii  libglib2.0-0 2.66.4-1
ii  libinput10   1.16.4-3
ii  libjpeg62-turbo  1:2.0.5-2
ii  liblcms2-2   2.12~rc1-2
ii  libpam0g 1.4.0-2
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libpixman-1-00.40.0-1
ii  libpng16-16  1.6.37-3
ii  libsystemd0  247.2-5
ii  libwayland-client0   1.18.0-2~exp1.1
ii  libwayland-cursor0   1.18.0-2~exp1.1
ii  libwayland-egl1  1.18.0-2~exp1.1
ii  libwayland-server0   1.18.0-2~exp1.1
ii  libwebp6 0.6.1-2+b1
ii  libweston-9-09.0.0-2
ii  libxkbcommon01.0.3-2

Versions of packages weston recommends:
ii  libgl1-mesa-dri  20.3.3-1

weston suggests no packages.

-- no debconf information

Bug#980994: openhpi: reduce Build-Depends

[Helmut Grohne]

Source: openhpi
Version: 3.8.0-2.1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

openhpi participates in dependency loops relevant to architecture
bootstrap. Instead of working on such a difficult problem, I looked into
easily droppable dependencies. It turns out that openhpi migrated from
libltld to glib. Therefore, the libltdl-dev dependency has become
obsolete. openipmi is actually used, but the openipmi package containing
tools is unused during a nocheck build. It can be annotated .
And since linking -lncurses was patched out of the ipmi plugin, the
dependency on libncurses5-dev has also become obsolete. Please consider
applying the attached patch.

Helmut
--- openhpi-3.8.0/debian/changelog
+++ openhpi-3.8.0/debian/changelog
@@ -1,3 +1,14 @@
+openhpi (3.8.0-2.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Reduce Build-Depends: (Closes: #-1)
++ Drop unused libltdl-dev. openhpi migrated to glib.
++ Annotate openipmi . Not used during nocheck build.
++ Drop unused libncurses5-dev as plugins/ipmi no longer links -lncurses
+  due to makefile_3.8.0.patch.
+
+ -- Helmut Grohne   Sun, 24 Jan 2021 13:24:46 +0100
+
 openhpi (3.8.0-2.1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
--- openhpi-3.8.0/debian/control
+++ openhpi-3.8.0/debian/control
@@ -4,7 +4,7 @@
 Maintainer: Mohan Devarajulu 
 Uploaders: Khalid Aziz 
 Homepage: http://openhpi.org
-Build-Depends: debhelper (>= 10), dpkg-dev (>= 1.16.1~), autoconf (>= 2.57), 
automake(>= 1.9), uuid-dev, libglib2.0-dev (>= 2.2), pkg-config, libltdl-dev, 
openipmi (>= 2.0.7), libopenipmi-dev (>=2.0.7), libsnmp-dev, libssl-dev, 
libsysfs-dev (>= 0.3), libncurses5-dev, libxml2-dev, librabbitmq-dev, 
libcurl4-openssl-dev, libjson-c-dev
+Build-Depends: debhelper (>= 10), dpkg-dev (>= 1.16.1~), autoconf (>= 2.57), 
automake(>= 1.9), uuid-dev, libglib2.0-dev (>= 2.2), pkg-config, openipmi (>= 
2.0.7) , libopenipmi-dev (>=2.0.7), libsnmp-dev, libssl-dev, 
libsysfs-dev (>= 0.3), libxml2-dev, librabbitmq-dev, libcurl4-openssl-dev, 
libjson-c-dev
 Standards-Version: 4.0.0
 
 Package: libopenhpi3

Bug#980993: mark golang-golang-x-net-dev Multi-Arch: foreign

[Helmut Grohne]

Package: golang-golang-x-net-dev
Version: 1:0.0+git20201031.ff519b6+dfsg-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:acbuild src:acmetool src:aerc src:age 
src:alertmanager-irc-relay src:amazon-ecr-credential-helper src:aptly 
src:badger src:balboa src:burrow src:cadvisor src:certspotter src:cfrpki 
src:chasquid src:cloudsql-proxy src:consul src:consulfs src:containerd 
src:coyim src:debiman src:deck src:delve src:dh-make-golang src:dnscrypt-proxy 
src:dnss src:docker-registry src:docker.io src:etcd src:fever src:flannel 
src:fscrypt src:fzf src:g10k src:garagemq src:git-lfs src:gitaly src:gitbatch 
src:gitlab-ci-multi-runner src:gitlab-shell src:gitlab-workhorse 
src:go-cve-dictionary src:go-dep src:go-exploitdb src:go-mmproxy src:gobgp 
src:gobuster src:gocryptfs src:goiardi src:gokey src:golang-ginkgo 
src:golang-github-ajstarks-svgo src:golang-github-anacrolix-dms 
src:golang-github-anacrolix-missinggo src:golang-github-appc-docker2aci 
src:golang-github-appc-spec src:golang-github-bmatsuo-lmdb-go 
src:golang-github-canonical-go-dqlite src:golang-github-cheekybits-genny 
src:golang-github-cloudflare-cfssl src:golang-github-cloudflare-redoctober 
src:golang-github-containernetworking-plugins 
src:golang-github-containers-buildah src:golang-github-containers-dnsname 
src:golang-github-containers-storage src:golang-github-coreos-discovery-etcd-io 
src:golang-github-dnstap-golang-dnstap src:golang-github-francoispqt-gojay 
src:golang-github-golang-mock src:golang-github-google-wire 
src:golang-github-grpc-ecosystem-grpc-gateway src:golang-github-hashicorp-serf 
src:golang-github-mmcloughlin-avo src:golang-github-niklasfasching-go-org 
src:golang-github-openshift-imagebuilder src:golang-github-rubenv-sql-migrate 
src:golang-github-spf13-cobra src:golang-github-sylabs-sif 
src:golang-github-tinylib-msgp src:golang-github-ugorji-go-codec 
src:golang-github-xenolf-lego src:golang-github-xordataexchange-crypt 
src:golang-github-yosssi-ace src:golang-gogottrpc src:golang-golang-x-tools 
src:golang-pault-go-ykpiv src:golang-v2ray-core src:golint src:gopass src:gortr 
src:gost src:gotestsum src:goval-dictionary src:govendor src:hcloud-cli src:hey 
src:hub src:hugo src:influxdb src:irtt src:kcptun src:libpod src:mender-cli 
src:mender-client src:micro src:minica src:mockery src:mongo-tools src:morty 
src:mtail src:nomad src:nomad-driver-lxc src:nomad-driver-podman src:notary 
src:obfs4proxy src:packer src:pebble src:pk4 src:pluginhook src:prometheus 
src:prometheus-alertmanager src:prometheus-apache-exporter 
src:prometheus-bind-exporter src:prometheus-bird-exporter 
src:prometheus-blackbox-exporter src:prometheus-exporter-exporter 
src:prometheus-hacluster-exporter src:prometheus-haproxy-exporter 
src:prometheus-homeplug-exporter src:prometheus-ipmi-exporter 
src:prometheus-libvirt-exporter src:prometheus-mailexporter 
src:prometheus-mongodb-exporter src:prometheus-mqtt-exporter 
src:prometheus-mysqld-exporter src:prometheus-nginx-exporter 
src:prometheus-nginx-vts-exporter src:prometheus-node-exporter 
src:prometheus-postfix-exporter src:prometheus-postgres-exporter 
src:prometheus-process-exporter src:prometheus-pushgateway 
src:prometheus-redis-exporter src:prometheus-snmp-exporter 
src:prometheus-sql-exporter src:prometheus-squid-exporter 
src:prometheus-tplink-plug-exporter src:prometheus-varnish-exporter 
src:pt-websocket src:pup src:ratt src:rawdns src:rclone src:reposurgeon 
src:restic src:rkt src:rootlesskit src:seqkit src:shadowsocks-v2ray-plugin 
src:shoelaces src:sia src:singularity-container src:skopeo src:slinkwatch 
src:snapd src:sshesame src:stenographer src:syncthing src:termshark src:textql 
src:thrift src:tty-share src:umoci src:vcfanno src:victoriametrics 
src:vip-manager src:vuls src:winrmcp src:wuzz

The affected packages cannot be cross built from source, because their
transitive dependency on golang-golang-x-net-dev is not satisfiable. In
general, Architecture: all packages can never satisfy cross
Build-Depends unless marked Multi-Arch: foreign or annotated :native. In
this case, the foreign marking seems reasonable as
golang-golang-x-net-dev ships only go sources, completely lacks
maintainer scripts and all of its dependencies are already thus marked.
Please consider applying the attached patch.

Helmut
diff --minimal -Nru 
golang-golang-x-net-0.0+git20201031.ff519b6+dfsg/debian/changelog 
golang-golang-x-net-0.0+git20201031.ff519b6+dfsg/debian/changelog
--- golang-golang-x-net-0.0+git20201031.ff519b6+dfsg/debian/changelog   
2020-11-05 11:03:07.0 +0100
+++ golang-golang-x-net-0.0+git20201031.ff519b6+dfsg/debian/changelog   
2021-01-25 07:03:46.0 +0100
@@ -1,3 +1,10 @@
+golang-golang-x-net (1:0.0+git20201031.ff519b6+dfsg-1.1) UNRELEASED; 
urgency=medium
+
+  * Non-maintainer upload.
+  * Mark golang-golang-x-net-dev Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 25 Jan 2021 07:03:46 +0100
+
 

Bug#980992: cairo: drop unused Build-Depends

[Helmut Grohne]

Source: cairo
Version: 1.16.0-5
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

cairo participates in a number of dependency loops relevant to
architecture bootstrap. Instead of looking into such a difficult
problem, I looked into easily droppable Build-Depends. It turns out that
the dependencies on libsm-dev, xutils-dev and libxt-dev can be dropped
without changing output artifacts (in a reproducibility sense). A
cursory look as to where these would be used yielded nothing. Please
consider dropping them. I'm attaching a patch for your convenience.

Helmut
diff --minimal -Nru cairo-1.16.0/debian/changelog cairo-1.16.0/debian/changelog
--- cairo-1.16.0/debian/changelog   2020-12-31 22:39:40.0 +0100
+++ cairo-1.16.0/debian/changelog   2021-01-25 06:42:14.0 +0100
@@ -1,3 +1,10 @@
+cairo (1.16.0-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop unused Build-Depends: libxsm-dev, xutils-dev, libxt-dev. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 25 Jan 2021 06:42:14 +0100
+
 cairo (1.16.0-5) unstable; urgency=medium
 
   * Team upload
diff --minimal -Nru cairo-1.16.0/debian/control cairo-1.16.0/debian/control
--- cairo-1.16.0/debian/control 2020-12-31 22:39:40.0 +0100
+++ cairo-1.16.0/debian/control 2021-01-25 06:42:13.0 +0100
@@ -17,9 +17,6 @@
libx11-dev (>= 2:1.3.3-2),
libxext-dev,
libpng-dev,
-   libsm-dev,
-   xutils-dev,
-   libxt-dev,
libpixman-1-dev (>= 0.30.0),
libxcb1-dev (>= 1.6),
libxcb-render0-dev (>= 1.6),

Bug#980991: tesseract: reduce Build-Depends

[Helmut Grohne]

Source: tesseract
Version: 4.1.1-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

tesseract participates in dependency loops relevant to architecture
bootstrap. Rather than look into such a difficult problem, I looked for
easily droppable dependencies. It turns out that tesseract does not
actually use libtiff-dev nor libjpeg-dev directly. In only uses them via
leptonica. Thus these dependencies can be dropped. git is only used to
discover the version from the git history in configure. Since the git
history is not included, git can be dropped. Please consider applying
the attached patch.

Helmut
diff --minimal -Nru tesseract-4.1.1/debian/changelog 
tesseract-4.1.1/debian/changelog
--- tesseract-4.1.1/debian/changelog2020-01-19 06:48:59.0 +0100
+++ tesseract-4.1.1/debian/changelog2021-01-25 06:39:45.0 +0100
@@ -1,3 +1,13 @@
+tesseract (4.1.1-3) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Reduce Build-Depends: (Closes: #-1)
++ Drop unused libjpeg-dev and libtiff-dev dependencies. tesseract does not
+  uses these directly. It only uses them via leptonica.
++ Drop dependency on git. The source does not include git history.
+
+ -- Helmut Grohne   Mon, 25 Jan 2021 06:39:45 +0100
+
 tesseract (4.1.1-2) unstable; urgency=medium
 
   * Update debian/control:
diff --minimal -Nru tesseract-4.1.1/debian/control 
tesseract-4.1.1/debian/control
--- tesseract-4.1.1/debian/control  2020-01-19 06:47:02.0 +0100
+++ tesseract-4.1.1/debian/control  2021-01-25 06:39:43.0 +0100
@@ -4,8 +4,8 @@
 Maintainer: Alexander Pozdnyakov 
 Build-Depends: debhelper (>= 9), libleptonica-dev (>= 1.75.3),
automake, libtool, libarchive-dev, libpango1.0-dev, 
libcairo2-dev, libicu-dev,
-   libpng-dev, libjpeg-dev, libtiff-dev, zlib1g-dev, git, 
autoconf-archive, asciidoc,
-   xsltproc, docbook-xsl, docbook-xml, tesseract-ocr-eng (>= 4.00~)
+   libpng-dev, zlib1g-dev, autoconf-archive, asciidoc,
+   xsltproc, docbook-xsl, docbook-xml, tesseract-ocr-eng (>= 
4.00~) 
 Standards-Version: 4.4.1
 Homepage: https://github.com/tesseract-ocr/
 Vcs-Git: https://github.com/AlexanderP/tesseract-debian.git

Bug#980990: mark golang-github-danverbraganza-varcaser-dev Multi-Arch: foreign

[Helmut Grohne]

Package: golang-github-danverbraganza-varcaser-dev
Version: 0.0~git20190207.e3fb03e-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:easygen

easygen cannot be cross built from source, because its dependency on
golang-github-danverbraganza-varcaser-dev is not satisfiable. In
general, Architecture: all packages can never satisfy cross
Build-Depends unless marked Multi-Arch: foreign or annotated :native. In
this case, the foreign marking seems reasonable as
golang-github-danverbraganza-varcaser-dev does not have any maintainer
scripts and all of its dependencies are already marked Multi-Arch:
foreign. Please consider applying the attached patch.

Helmut
diff --minimal -Nru 
golang-github-danverbraganza-varcaser-0.0~git20190207.e3fb03e/debian/changelog 
golang-github-danverbraganza-varcaser-0.0~git20190207.e3fb03e/debian/changelog
--- 
golang-github-danverbraganza-varcaser-0.0~git20190207.e3fb03e/debian/changelog  
2020-07-12 11:21:16.0 +0200
+++ 
golang-github-danverbraganza-varcaser-0.0~git20190207.e3fb03e/debian/changelog  
2021-01-25 06:15:44.0 +0100
@@ -1,3 +1,11 @@
+golang-github-danverbraganza-varcaser (0.0~git20190207.e3fb03e-1.1) 
UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark golang-github-danverbraganza-varcaser-dev Multi-Arch: foreign.
+(Closes: #-1)
+
+ -- Helmut Grohne   Mon, 25 Jan 2021 06:15:44 +0100
+
 golang-github-danverbraganza-varcaser (0.0~git20190207.e3fb03e-1) unstable; 
urgency=medium
 
   * Team upload.
diff --minimal -Nru 
golang-github-danverbraganza-varcaser-0.0~git20190207.e3fb03e/debian/control 
golang-github-danverbraganza-varcaser-0.0~git20190207.e3fb03e/debian/control
--- 
golang-github-danverbraganza-varcaser-0.0~git20190207.e3fb03e/debian/control
2020-07-12 11:21:16.0 +0200
+++ 
golang-github-danverbraganza-varcaser-0.0~git20190207.e3fb03e/debian/control
2021-01-25 06:15:42.0 +0100
@@ -17,6 +17,7 @@
 
 Package: golang-github-danverbraganza-varcaser-dev
 Architecture: all
+Multi-Arch: foreign
 Depends: golang-golang-x-text-dev,
  ${misc:Depends},
 Description: Go lib to transform between common variable casing conventions

Bug#980989: corosync: reduce Build-Depends

[Helmut Grohne]

Source: corosync
Version: 3.1.0-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

corosync participates in dependency loops relevant to architecture
bootstrap. Instead of working on such a difficult problem, I looked into
easily droppable dependencies. It turns out that while corosync installs
an augeas lens, it does not actually call anything from augeas-tools to
do so. And while it does support an xml based configuration format, it
doesn't parse it using libxml2, but uses xsltproc instead. Therefore,
both augeas-tools and libxml2-dev can be dropped from Build-Depends with
no replacement. Please consider applying the attached patch.

Helmut
diff --minimal -Nru corosync-3.1.0/debian/changelog 
corosync-3.1.0/debian/changelog
--- corosync-3.1.0/debian/changelog 2021-01-01 09:11:36.0 +0100
+++ corosync-3.1.0/debian/changelog 2021-01-25 06:23:08.0 +0100
@@ -1,3 +1,13 @@
+corosync (3.1.0-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Reduce Build-Depends: (Closes: #-1)
++ Drop unused libxml2-dev dependency. It deals with xml via xsltproc.
++ Drop unused augeas-tools dependency. While it ships a lens, it does not
+  further integrate with augeas.
+
+ -- Helmut Grohne   Mon, 25 Jan 2021 06:23:08 +0100
+
 corosync (3.1.0-2) unstable; urgency=medium
 
   * [d92f1d8] Drop the log directory placeholder file.
diff --minimal -Nru corosync-3.1.0/debian/control corosync-3.1.0/debian/control
--- corosync-3.1.0/debian/control   2021-01-01 09:11:12.0 +0100
+++ corosync-3.1.0/debian/control   2021-01-25 06:23:08.0 +0100
@@ -7,7 +7,6 @@
  Ferenc Wágner ,
 Standards-Version: 4.5.1
 Build-Depends:
- augeas-tools,
  debhelper-compat (= 12),
  dctrl-tools,
 # maybe too strict, but the buster dwz failed:
@@ -23,7 +22,6 @@
 # libstatgrab is Linux-only until #823899 and #823900 gets fixed:
  libstatgrab-dev [linux-any],
  libsystemd-dev [linux-any],
- libxml2-dev,
  pkg-config,
  zlib1g-dev
 Build-Depends-Indep:

Bug#980988: 980988: cannot be packaged due to unsatisfied dependencies

[Andrius Merkys]

Hello,

New release of georegression (v0.23 as of now) is reported correctly by
uscan, which points to upstream's GitHub site. However, this release
cannot be packaged without ddogleg v0.19, which in turn depends on other
non-updated packages, finally arriving at dependency on newer gradle.

Best,
Andrius

Bug#664141: fancontrol: service needs restarting after sleep

[Emilian Nowak]

On 25-01-2021 (Mon), at 00:12:17 Aurelien Jarno napisał(a):

> > Now upgrade came and fans are spinning like a crazy after suspend.   
> 
> I don't get how an upgrade do that, the package doesn't actively remove
> the file /lib/systemd/system-sleep/fancontrol added by the patch.
Just the usual thing what packages system does: It was part of
mine (handy-crafted package). Now it is not. So it gets removed.

> > Is it deprecated project, and something else should be used nowdays?  
> 
> Yes, fancontrol is not really maintained upstream anymore, and has never
> been more than a quick hack (hence the bash language) than a real tool.
> It was probably a big mistake to include it as a package initially. It
> works on a very limited number of configurations. The real replacement
> is to use the features provided by the hardware. Only the lm-sensors
> tool and the corresponding libsensors are really well maintained
> upstream.
Aha. Makes sense. I wonder If I should send more bugreports or leave it as it
is.


-- 
Best Regards

Bug#980987: lintian: check for duplicates in debian/py3dist-overrides

[Paul Wise]

Package: lintian
Version: 2.104.0
Severity: wishlist

dh_python3 has an override mechanism (debian/py3dist-overrides) that
lets you specify different dependencies for particular Python imports.

debian/py3dist-overrides is mainly used for Python programs that use
GObject introspection, since dh_python3 cannot yet detect that the
packages gir1.2-*-* map to Python imports, so overrides are needed.

When the same import appears twice in the file, the dependency from the
first one is used and the dependency from the second one is discarded,
which can lead to missing dependencies if the maintainer didn't notice.

An example of a second dependency that gets ignored:

   gi.repository.Gst gir1.2-gst-plugins-base-1.0
   gi.repository.Gst gir1.2-gstreamer-1.0

An example of a double dependency that gets kept:

   gi.repository.Gst gir1.2-gst-plugins-base-1.0, gir1.2-gstreamer-1.0

Please mark this check as error severity.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#980986: mirror submission for mirror.misakamikoto.network

[Kwabang]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.misakamikoto.network
Type: leaf
Archive-architecture: amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el 
s390x
Archive-http: /debian/
Maintainer: Kwabang 
Country: KR Korea, Republic of
Location: YeongCheon




Trace Url: http://mirror.misakamikoto.network/debian/project/trace/
Trace Url: 
http://mirror.misakamikoto.network/debian/project/trace/ftp-master.debian.org
Trace Url: 
http://mirror.misakamikoto.network/debian/project/trace/mirror.misakamikoto.network

Bug#948346: [PATCH] Ensure graceful signal handling when the pid file exists

[Adrian Bunk]

On Sun, Jan 10, 2021 at 12:10:16PM +0100, Eduard Bloch wrote:
>...
> I am setting this to RC severity because it's just NOT ok and obvious to
> fix. Going to change mentioned things and NMU this in a couple of weeks
> if there is no further reaction from maintainers.

Could you make an upload to DELAYED instead of further waiting?

> Best regards,
> Eduard.

Thanks
Adrian

Bug#980985: libqalculate: new upstream release 3.16.1

[Damir R. Islamov]

Package: qalc
Version: 3.16.1-0.1
Severity: wishlist

Dear Maintainer,

libqalculate and qalculate-gtk have new upstream release 3.16.1.
They have a lot of improvements and fixes that will be interesting for Debian 
users.
Also new release will close some bugs in the Debian bagtracker.

-- 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/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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 qalc depends on:
ii  libc6   2.31-9
ii  libgcc-s1   10.2.1-6
ii  libqalculate21  3.16.1-0.1
ii  libreadline88.1-1
ii  libstdc++6  10.2.1-6

Versions of packages qalc recommends:
ii  wget  1.21-1+b1

qalc suggests no packages.

-- no debconf information


libqalculate_3.16.1-0.1.debian.tar.xz
Description: application/xz


qalculate-gtk_3.16.0-0.1.debian.tar.xz
Description: application/xz

Bug#978079: heads up: rapid-photo-downloader might not make it to bullseye

[Damon Lynch]

On Sun, Jan 24, 2021 at 8:44 PM Antoine Beaupré  wrote:

>  Maybe then there is an easy fix to keep RPD in Debian if
> rawkit disappears.
>
>
There is no need for any kind of fix in the code itself. Just remove the
mention of rawkit from the Rapid Photo Downloader Debian package. Rapid
Photo Downloader will run without rawkit, without any changes to its code.
If rawkit is present and working, Rapid Photo Downloader will use it. If
rawkit is either not working or not present, Rapid Photo Downloader won't
use it.
-- 
https://damonlynch.net

Bug#859342: Florence: segfault when clicking on size changing keys

[Kai-Martin Knaak]

Unfortunately, florence still crashes if I hit the zoom keys with
current Debian/bullseye just before freeze.  

There is a message on stdout:

--
$ dbus[105330]: arguments to dbus_connection_unref() were incorrect,
assertion "connection->generation == _dbus_current_generation" failed in
file ../../../dbus/dbus-connection.c line 2823. This is normally a bug
in some application using the D-Bus library.

  D-Bus not built with -rdynamic so unable to print a backtrace
--

Hope, this helps to fix the bug,

---<)kaimartin(>---


pgp4wwCVBqz3c.pgp
Description: OpenPGP digital signature

Bug#980984: roger-router: Please update Homepage field

[Bruno Kleinert]

Package: roger-router
Version: 2.1.6-4
Severity: minor
X-Debbugs-Cc: fu...@debian.org

Hi,

the URL in the Homepage field in debian/control leads to a 404 page. The new
URL seems to be https://www.tabos.org/project/rogerrouter/.

Cheers,
Bruno



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

Kernel: Linux 5.10.0-2-amd64 (SMP w/8 CPU threads)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.utf-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages roger-router depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-1
ii  libayatana-appindicator3-1   0.5.5-2
ii  libc62.31-9
ii  libcairo21.16.0-5
ii  libebook-1.2-20  3.38.2-2+b1
ii  libebook-contacts-1.2-3  3.38.2-2+b1
ii  libedataserver-1.2-253.38.2-2+b1
ii  libgdata22   0.17.13-3
ii  libgdk-pixbuf2.0-0   2.40.2-2
ii  libglib2.0-0 2.66.4-1
ii  libgs9   9.53.3~dfsg-6
ii  libgtk-3-0   3.24.24-1
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libpoppler-glib8 20.09.0-3.1
pn  librm0   
ii  libsoup2.4-1 2.72.0-2
ii  libtiff5 4.2.0-1

roger-router recommends no packages.

roger-router suggests no packages.

Bug#963790: [Aptitude-devel] Bug#963790: Bug#963790: aptitude: crashes on arm64

[Axel Beckert]

Control: tags -1 + moreinfo unreproducible

Hi Mikulas,

Axel Beckert wrote:
> Will also try to setup an arm64 unstable on a Raspberry Pi and see if
> I can reproduce this.

Used aptitude on a Raspberry Pi 4 with arm64 for several weeks now
without a single crash.

Do you still experience this issue? If so, can you provide a state
bundle created with aptitude-create-state-bundle so that I can try to
see if I can reproduce it that way on my Raspberry Pi?

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#980670: pantalaimon: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.9 returned exit code 13

[s3v]

Dear Maintainer,

Your package builds fine in a sid chroot environment after
applying this commit [1].

Kind Regards

[1] https://github.com/matrix-org/pantalaimon/commit/726e969

Bug#904098: Timidity is blocking alsa plughw

[ael]

I have also found that timidity is blocking access to
the alsa plughw device.

This may perhaps be the underlying problem with pulseaudio although
as I only use alsa I cannot comment on that.

Trying to open the alsa device returns a "Device or resource busy"
error.

It is possible that an asoundrc configuration 
https://www.alsa-project.org/wiki/Asoundrc
might help.

Bug#980983: RFP: filmulator -- Simplified raw editing with the power of film

[Antoine Beaupre]

Package: wnpp
Severity: wishlist

* Package name: filmulator
  Version : 0.11.0
  Upstream Author : CarVac
* URL : https://filmulator.org/
* License : GPL-3+
  Programming Lang: C++, Qt
  Description : Simplified raw editing with the power of film

Filmulator accepts raw files from cameras and simulates the
development of film as if exposed to the same light as the camera's
sensor. For various reasons, this inherently brings about several
benefits:

 * Large bright regions become darker, compressing the output dynamic
   range.
 * Small bright regions make their surroundings darker, enhancing
   local contrast.
 * In bright regions, saturation is enhanced, helping retain color in
   blue skies, brighter skin tones, and sunsets.
 * In extremely saturated regions, the brightness is attenuated,
   helping retain detail e.g. in flowers.

The program's design ideology is to have the best tool for any job,
and only that one tool. The tradeoff here is a slight decrease in
flexibility, but gaining a greatly simplified and streamlined user
interface.

==

I currently use Darktable, Rapid-photo-downloader, geequie, thunar,
and git-annex, and sometimes other stuff in my RAW workflow. It's a
mess. This looks much simpler and solves a problem I have so much
trouble fixing in Darktable (highlights). And I have less and less
time dealing with complicated software, so I like this one.

It might also be compared to RawTherapee.

It looks like all the dependencies are already in Debian, so it's a
fairly straightforward package to ship. It should probably be kept out
of stable for now, as it's in its early development stages.

See also:

https://github.com/CarVac/filmulator-gui
https://discuss.pixls.us/c/software/filmulator/

I do not plan to maintain this package, and merely open this to see if
someone will, or at least avoid duplication of work.

Bug#978079: heads up: rapid-photo-downloader might not make it to bullseye

[Antoine Beaupré]

On 2021-01-24 20:18:27, Damon Lynch wrote:
>> Otherwise I'm afraid we won't be able to ship
>> RPD with Debian starting with bullseye, which would really be a shame...
>
> I am the developer of Rapid Photo Downloader. I am not impressed by this
> suggestion. Rapid Photo Downloader has an optional, soft dependency on
> rawkit. Rapid Photo Downloader will install and run perfectly well without
> rawkit, which has been the case for some years now.
>
> If you have any packaging questions about Rapid Photo Downloader you can
> ask me, instead of
> simply removing the package from Debian. To be as polite as possible, I am
> somewhat taken aback by a suggestion to remove it without any communication
> with me.

I was merely stating the current situation, which is that there is
currently a hard dependency between RPD and rawkit right now, and rawkit
will be removed. This means that RPD, without change, will also be
removed.

I was not suggesting that RPD *must* be removed from Debian. I use it
regularly, and I would hate to see it go...

> FWIW, the latest version of Rapid Photo Downloader  is 0.9.26. The Debian
> package is somewhat out of date these days.

... and in fact, I would love if the package was more up to date to. :)
But this is the hand we're given right now.

I'm glad to hear that the rawkit dependency is not as "hard" as I first
understood it. Maybe then there is an easy fix to keep RPD in Debian if
rawkit disappears.

But I figured I would share my concerns rather than stay silent, because
otherwise this would have all happened automatically and you probably
would have noticed too late.

I'm sorry if it sounded a bit cavalier, I wasn't expecting you to read
this thread directly, and I did suggest the maintainer contact you
directly as well.

I unfortunately do not have time to deal with this problem myself (other
than raising this red flag) so I hope that others will be able to.

A.
-- 
>From the age of uniformity, from the age of solitude, from the age of
Big Brother, from the age of doublethink - greetings!
- Winston Smith, 1984

Bug#980982: New upstream version 2.0.15

[林上智]

Package: flawfinder
Severity: wishlist

Hi,

Thank you for your effort in maintaining flawfinder package in Debian.

Currently, the newest version of flawfinder is 2.0.15, it would be great if you
can update the package. I'm willing to be of assistance if you're lack time.

SZ

Bug#978079: heads up: rapid-photo-downloader might not make it to bullseye

[Damon Lynch]

> Otherwise I'm afraid we won't be able to ship
> RPD with Debian starting with bullseye, which would really be a shame...

I am the developer of Rapid Photo Downloader. I am not impressed by this
suggestion. Rapid Photo Downloader has an optional, soft dependency on
rawkit. Rapid Photo Downloader will install and run perfectly well without
rawkit, which has been the case for some years now.

If you have any packaging questions about Rapid Photo Downloader you can
ask me, instead of
simply removing the package from Debian. To be as polite as possible, I am
somewhat taken aback by a suggestion to remove it without any communication
with me.

FWIW, the latest version of Rapid Photo Downloader  is 0.9.26. The Debian
package is somewhat out of date these days.

Damon
-- 
https://damonlynch.net

Bug#980449: vim: Change in default vim config causes obnoxious behaviour.

[James McCoy]

On Wed, Jan 20, 2021 at 08:47:42AM +0100, Rens Houben wrote:
> In other news for Tue, Jan 19, 2021 at 09:14:59PM -0500, James McCoy has been 
> seen typing:
> > On Tue, Jan 19, 2021 at 10:22:35AM +0100, Rens Houben wrote:
> 
> > The terminal sends [I when focus comes back, which is what makes
> > you leave insert mode () and show that popup ([I).
>  
> > If this were working correctly, you wouldn't have noticed a difference
> > (as is the case in xterm), but there's something going on with the other
> > terminals.
>  
> > Can you provide the package names and versions for the terminals that
> > aren't working right?
>  gnome-terminal 3.38.1-2, mate-terminal 1.24.1-1 and xfce4-terminal
>  0.8.10-1 all exhibit this behaviour;

They're all based on libvte, so it makes sense that they exhibit the
same behavior.  However, I can't reproduce the behavior myself in those
terminals.

If you run "vim -u DEFAULTS --noplugin", are you able to reproduce the
issue?

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#980909: dpkg-dev: dpkg-buildpackage : gpg command uses expired key

[Guillem Jover]

Hi!

On Sun, 2021-01-24 at 10:39:20 +0100, A Mennucc wrote:
> Package: dpkg-dev
> Version: 1.20.7.1
> Severity: minor

> I just stumbled in this annoying situation. I do not know
> if this may be classified as a bug in dpkg-buildpackage or in gpg.
> 
> If I call dpkg-buildpackage to build my package , at a certain point
> it calls (as seen in a strace output)
> 
> execve("/usr/bin/gpg", ["gpg", "--utf8-strings", "--textmode", "--armor", 
> "--local-user", "A Mennucc1 ", "--clearsign", 
> "--output", "dpkg-sign.jze_WfLt/debdelta_0.67.dsc.asc", 
> "dpkg-sign.jze_WfLt/debdelta_0.67.dsc"], 0x5593f918e990 /* 95 vars */) = 0
> 
> Now, I have two keys with that username, an older DSA key, disabled,
> and a newer RSA key, that is
> $ gpg --list-sec "A Mennucc1 "
> sec   dsa1024/0xF41FED8E33FC40A4 2000-03-14 [SCA]
> sec   rsa4096/0x57CCF4596A1353C2 2014-09-28 [SC]
> 
> For some weird reason, gpg selects the first one.

Yeah, I guess it chooses either the first or the last found matching.

> Let me stress that in ~/.gnupg/gpg.conf I have:
>  default-key 0x57CCF4596A1353C2!
> so that I am usually signing everything with the correct key.

Right, but the --local-user override --default-key.

> But here comes the funny part: if I use `debuild -S`, it instead
> uses the correct key (!)
> According to `strace`, it does
> "/usr/bin/gpg", ["gpg", "--local-user", "0x57CCF4596A1353C2", "--clearsign", 
> "--list-options", "no-show-policy-
> urls", "--armor", "--textmode", "--output", 
> "/tmp/debsign.XyM6Vi4v/debdelta_0.67.dsc.asc", 
> "/tmp/debsign.XyM6Vi4v/debdelta_0
> .67.dsc"

I'm assuming you have this configured in ~/.devscripts with
DEBSIGN_KEYID. You should be able to get similar results for
dpkg-buildpackage by either setting the DEB_SIGN_KEYID environment
variable or the sign-key option in ~/.config/dpkg/buildpackage.conf
to the key fingerprint. (I personally use the former as I can change
it dynamically depending on the context from bash PROMP_COMMAND. :)

> How could we fix this? 

I'm not sure whether there's a way to tell gpg to prefer one of the
secret keys when presented with just «Name ». But otherwise see
above. So I'm inclined to close this, otherwise you could request a
way to mark as secret key as preferred in the GnuPG secret keyring?

Thanks,
Guillem

Bug#663255: Nous avons mis à jour notre webmail zimbra pour mieux vous servir.

[MAHE Jean-Marc]

Nous avons mis à jour notre webmail zimbra pour mieux vous servir. Pour 
profiter de ce service et continuer à utiliser votre compte zimbra, il vous est 
demandé de vérifier votre compte.Cliquez ici et vérifiez votre compte.

Bug#980981: mirror listing update for debian.ccns.ncku.edu.tw

[Sean Ho]

Package: mirrors
Severity: minor
User: mirr...@packages.debian.org
Usertags: mirror-list

Submission-Type: new
Site: debian.ccns.ncku.edu.tw
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf mips mips64el mipsel
ppc64el s390x
Archive-http: /debian/
Maintainer: Campus Computer & Network Society, National Cheng Kung
University 
Country: TW Taiwan
Location: Tainan, Taiwan
Sponsor: The Department of Computer Science and Information Engineering,
National Cheng Kung University 
Comment:
We are Software Engineers, Developers, Hackers, Adventurers ... @NCKU,
Taiwan.

Bug#980980: linux-image-5.10.0-2-arm64-unsigned: flood of false udev messages make udisks2 eat CPU usage on usb-booted raspi4

[Ryutaroh Matsumoto]

Package: src:linux
Version: 5.10.9-1
Severity: important
Tags: upstream bullseye
Control: block -1 by 977694

Dear Maintainer,

After booting raspi 4b from USB MSDand installation of
udisks2 2.9.1-3 by
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977694#56

udev starts giving flood of false messages like below,
and the udisks2, udev and dbus daemons eat nearly 100% of CPU
in total. The flood of false messages disappears by removing udisks2
package.

This symptom is also observed with the vanilla upstream kernel.

Best regards, Ryutaroh Matsumoto


monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[1532.887313] change   
/devices/platform/emmc2bus/fe34.emmc2/mmc_host/mmc1/mmc1:0007/block/mmcblk1 
(block)
KERNEL[1532.887432] change   
/devices/platform/emmc2bus/fe34.emmc2/mmc_host/mmc1/mmc1:0007/block/mmcblk1/mmcblk1p1
 (block)
KERNEL[1532.887485] change   
/devices/platform/scb/fd50.pcie/pci:00/:00:00.0/:01:00.0/usb2/2-2/2-2:1.0/host0/target0:0:0/0:0:0:0/block/sda
 (block)
KERNEL[1532.887537] change   
/devices/platform/scb/fd50.pcie/pci:00/:00:00.0/:01:00.0/usb2/2-2/2-2:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda1
 (block)
KERNEL[1532.887588] change   
/devices/platform/scb/fd50.pcie/pci:00/:00:00.0/:01:00.0/usb2/2-2/2-2:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda2
 (block)
KERNEL[1532.887640] change   
/devices/platform/scb/fd50.pcie/pci:00/:00:00.0/:01:00.0/usb2/2-2/2-2:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda3
 (block)
UDEV  [1532.929456] change   
/devices/platform/scb/fd50.pcie/pci:00/:00:00.0/:01:00.0/usb2/2-2/2-2:1.0/host0/target0:0:0/0:0:0:0/block/sda
 (block)
UDEV  [1532.938261] change   
/devices/platform/emmc2bus/fe34.emmc2/mmc_host/mmc1/mmc1:0007/block/mmcblk1 
(block)
UDEV  [1532.945960] change   
/devices/platform/scb/fd50.pcie/pci:00/:00:00.0/:01:00.0/usb2/2-2/2-2:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda1
 (block)
UDEV  [1532.961346] change   
/devices/platform/scb/fd50.pcie/pci:00/:00:00.0/:01:00.0/usb2/2-2/2-2:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda2
 (block)
UDEV  [1532.966981] change   
/devices/platform/scb/fd50.pcie/pci:00/:00:00.0/:01:00.0/usb2/2-2/2-2:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda3
 (block)
UDEV  [1532.999693] change   
/devices/platform/emmc2bus/fe34.emmc2/mmc_host/mmc1/mmc1:0007/block/mmcblk1/mmcblk1p1
 (block)
KERNEL[1535.645238] change   
/devices/platform/scb/fd50.pcie/pci:00/:00:00.0/:01:00.0/usb2/2-2/2-2:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda2
 (block)
UDEV  [1535.656113] change   
/devices/platform/scb/fd50.pcie/pci:00/:00:00.0/:01:00.0/usb2/2-2/2-2:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda2
 (block)
KERNEL[1535.667023] change   
/devices/platform/scb/fd50.pcie/pci:00/:00:00.0/:01:00.0/usb2/2-2/2-2:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda2
 (block)
UDEV  [1535.677595] change   
/devices/platform/scb/fd50.pcie/pci:00/:00:00.0/:01:00.0/usb2/2-2/2-2:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda2
 (block)
KERNEL[1535.699075] change   
/devices/platform/scb/fd50.pcie/pci:00/:00:00.0/:01:00.0/usb2/2-2/2-2:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda2
 (block)
UDEV  [1535.711964] change   
/devices/platform/scb/fd50.pcie/pci:00/:00:00.0/:01:00.0/usb2/2-2/2-2:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda2
 (block)
KERNEL[1535.750938] change   
/devices/platform/scb/fd50.pcie/pci:00/:00:00.0/:01:00.0/usb2/2-2/2-2:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda2
 (block)
UDEV  [1535.762856] change   
/devices/platform/scb/fd50.pcie/pci:00/:00:00.0/:01:00.0/usb2/2-2/2-2:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda2
 (block)
KERNEL[1535.807667] change   
/devices/platform/scb/fd50.pcie/pci:00/:00:00.0/:01:00.0/usb2/2-2/2-2:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda2
 (block)
UDEV  [1535.822477] change   
/devices/platform/scb/fd50.pcie/pci:00/:00:00.0/:01:00.0/usb2/2-2/2-2:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda2
 (block)
KERNEL[1535.857299] change   
/devices/platform/scb/fd50.pcie/pci:00/:00:00.0/:01:00.0/usb2/2-2/2-2:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda2
 (block)
UDEV  [1535.871682] change   
/devices/platform/scb/fd50.pcie/pci:00/:00:00.0/:01:00.0/usb2/2-2/2-2:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda2
 (block)
KERNEL[1535.897123] change   
/devices/platform/scb/fd50.pcie/pci:00/:00:00.0/:01:00.0/usb2/2-2/2-2:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda2
 (block)
UDEV  [1535.911569] change   
/devices/platform/scb/fd50.pcie/pci:00/:00:00.0/:01:00.0/usb2/2-2/2-2:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda2
 (block)




-- Package-specific info:
** Version:
Linux version 5.10.0-2-arm64 

Bug#980777: FIT-PC: Fails to find driver for Ethernet, Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI

[Charles Curley]

On Sun, 24 Jan 2021 21:28:26 +0100
John Paul Adrian Glaubitz  wrote:

> Hi!
> 
> On 1/24/21 4:50 PM, Andrew M.A. Cater wrote:
> > OK. This might be a bug in the i386 iso - as you've seen, we can't
> > test all i386 easily. This might just be a regression. Given that
> > we're about to release 10.8 on Feb 6th, can I suggest that you send
> > a mail into debian-boot (or debian cd) referencing the bug number
> > and including the syslog entries above.  
> 
> FWIW, I recently installed the 10.7 i386 non-free netinst ISO on an
> old JVC sub-notebook with a Pentium M CPU and Realtek 8139 ethernet
> card and had no issues with that card during installation.
> 
> What actually caused problems was establishing a WiFi connection
> during installation with the Intel 2200BG wireless adapter - which is
> why I used the ethernet network connection during install.
> 
> After installation, everything worked correctly out of the box,
> however (lspci below).

Thanks for the report.

I hit a similar situation with a Thinkpad R51. Same WiFi, different
Ethernet NIC. See below. Even with the firmware-ipw2x00 package, I
could not get a connection during installation either.

We seem to have the same version of the Realtek (rev 10).

Did you end up using firmware for the Realtek? There has been some
question on that in the course of this bug.


02:02.0 Network controller: Intel Corporation PRO/Wireless 2200BG [Calexico2] 
Network Connection (rev 05)
02:08.0 Ethernet controller: Intel Corporation 82801DB PRO/100 VE (MOB) 
Ethernet Controller (rev 81)


Your report and some other things I have seen lead me to wonder if I am
simply running out of memory on the FIT-PC and d-i is not telling me. A
quick search of two syslogs didn't turn anything up.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Bug#977450: closed by Raphael Hertzog (Re: RM: radare2-cutter -- ROM; Removal of critical dependency (radare2))

[Robert Haist]

Hi,

I understand. If radare2 is regularly updated I am happy to take further care 
of cutter as part of the pkg-security team.

Thanks for clarifying this.


Robert Haist


> Debian Bug Tracking System  hat am 24.01.2021 20:45 
> geschrieben:
> 
>  
> This is an automatic notification regarding your Bug report
> which was filed against the ftp.debian.org package:
> 
> #977450: RM: radare2-cutter -- ROM; Removal of critical dependency (radare2)
> 
> It has been closed by Raphael Hertzog .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Raphael Hertzog 
>  by
> replying to this email.
> 
> 
> -- 
> 977450: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977450
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
> Hi,
> 
> On Tue, 05 Jan 2021, Sebastian Reichel wrote:
> > It is true, that radare2 has been removed from Debian stable. It has
> > not been removed from Debian, though. In fact I uploaded version
> > 5.0 to unstable yesterday and it got accepted by an FTP master today.
> > But I do plan to keep #950372 open, so that r2 will not transition to
> > testing/stable anymore.
> 
> I'd like to keep radare2-cutter in the pkg-security team, so closing
> this removal request. If anyone wants to help maintain it, you are welcome
> in the pkg-security team.
> 
> Regards,
> -- 
>   ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
>   ⣾⠁⢠⠒⠀⣿⡁
>   ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
>   ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS
> Package: ftp.debian.org
> Severity: normal
> X-Debbugs-Cc: r...@debian.org
> 
> Hello,
> 
> as radare2 has been discontinued in Debian due to packaging problems
> radare2-cutter should also be removed from Debian.
> 
> There are no other reverse dependencies to take care of AFAIC.
> 
> Kind regards,
> 
> Robert

Bug#979641: src:kboot-utils: invalid maintainer address

[Antonio Ospite]

On Sun, 24 Jan 2021 21:12:54 +0100
Baptiste Beauplat  wrote:

> Hi Antonio,
> 
> kboot-utils, one of the packages you maintain in Debian has an old, 
> unreachable
> Maitainer address. Could you please update it to prevent it from getting
> removed?
> 
> See below the original bug report.
>

Thank you for reporting this Baptiste.

I am actually not sure how useful kboot-utils is nowadays, it was mainly
developed to make it easier to boot kernels on the Sony PS3, but I don't
think the PS3 is supported by Debian directly anymore.

However I would be happy to update the package anyway if there was
someone interested to sponsor it, since I cannot upload packages
myself and the I doubt my usual sponsor would be interested in it.

Ciao,
   Antonio 

> Best,
> 
> On 2021/01/09 06:04 PM, Ansgar wrote:
> > Source: kboot-utils
> > Version: 0.4-1
> > Severity: serious
> > Tags: bullseye sid
> > X-Debbugs-Cc: Holger Levsen 
> > 
> > The maintainer address is invalid, see below.
> > 
> > Ansgar
> > 
> >  Start of forwarded message 
> > From: Mail Delivery System 
> > Subject: Mail delivery failed: returning message to sender
> > Date: Sat, 09 Jan 2021 16:49:56 +
> > 
> 
> > This message was created automatically by mail delivery software.
> > 
> > A message that you sent could not be delivered to one or more of its
> > recipients. This is a permanent error. The following address(es) failed:
> > 
> >   osp...@studenti.unina.it
> > host fmvip.unina.it [192.132.34.7]
> > SMTP error from remote mail server after RCPT 
> > TO::
> > 550 5.1.1 ... User unknown
> 
> > Reporting-MTA: dns; muffat.debian.org
> > 
> > Action: failed
> > Final-Recipient: rfc822;osp...@studenti.unina.it
> > Status: 5.0.0
> > Remote-MTA: dns; fmvip.unina.it
> > Diagnostic-Code: smtp; 550 5.1.1 ... User unknown
> 
> 
> 
> -- 
> Baptiste Beauplat - lyknode


-- 
Antonio Ospite
https://ao2.it
https://twitter.com/ao2it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

Bug#882307: gnome-sound-recorder: any recording named 'Clip 2' gets overwritten

[Yuri Schaeffer]

Hi Simon,

On 24/01/21 12:13, Simon McVittie wrote:
> Does ths still happen? I couldn't reproduce it in version 3.38.0-2. The
> naming convention is now "Recording 1", "Recording 2", ... and it seems
> the automatically-chosen name always avoids duplicating the name of an
> existing recording.

I has been so long I can hardly remember filing this bug report. That
said I cannot reproduce it either on 3.38.0.
But I have failed to actually name the recording 'Clip 2'! In fact I can
not get a space in the name directly after recording because that will
trigger the record button. Which then goes inactive and I can only
record again after application restart.

Relevant maybe: Wayland + Sway

//Yuri

Bug#980979: xdesktopwaves: Please package the new release (1.4)

[Boyuan Yang]

Source: xdesktopwaves
Severity: normal
Version: 1.3-4
Tags: sid

Dear Debian xdesktopwaves package maintainer,

The xdesktopwaves upstream has released a new version v1.4 and it is
available at
https://sourceforge.net/projects/xdesktopwaves/files/xdesktopwaves/ .
Please consider packaging it. Thanks!

Regards,
Boyuan Yang


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

Bug#980978: update xkb-data to match upstream

[Greg Meyer]

Package: xkb-data
Version: 2.29-2

xkeyboard-config has since released both 2.30 and 2.31, it would be greatly
appreciated if the Debian package could be updated to include the changes.

Bug#980977: ITP: golang-github-cli-oauth -- library for performing OAuth Device flow and Web application

[Joao Paulo Lima de Oliveira]

Package: wnpp
Severity: wishlist
Owner: Joao Paulo Lima de Oliveira 
X-Debbugs-Cc: debian-de...@lists.debian.org, jlima.oliveir...@gmail.com

* Package name: golang-github-cli-oauth
  Version : 0.8.0-1
  Upstream Author : GitHub CLI
* URL : https://github.com/cli/oauth
* License : MIT
  Programming Lang: Go
  Description : library for performing OAuth Device flow and Web application

 A library for Go client applications that need to perform OAuth authorization
 against a server, typically GitHub.com.
 Traditionally, OAuth for web applications involves redirecting to a URI after
 the user authorizes an app. While web apps (and some native client apps) can
 receive a browser redirect, client apps such as CLI applications do not have
 such an option.
 To accommodate client apps, this library implements the OAuth Device
 Authorization Grant which GitHub.com now supports. With Device flow, the user
 is presented with a one-time code that they will have to enter in a web browser
 while authorizing the app on the server. Device flow is suitable for cases
 where the web browser may be running on a separate device than the client
 app itself; for example a CLI application could run within a headless,
 containerized instance, but the user may complete authorization using a
 browser on their phone.

Bug#806861: libidl: upgrade libidl-2-0_0.8.14-3_amd64.deb and "Errors were encountered while processing"

[Boyuan Yang]

Version: 0.8.14-4
Control: found -1 0.8.14-3
Control: fixed -1 0.8.14-4

This bug is fixed in the latest upload. See also #806204, #806253.

Thanks,
Boyuan Yang

On Wed, 02 Dec 2015 15:03:51 +0330 Mohsen Pahlevanzadeh 
 wrote:
> Package: libidl
> Severity: important
> 
> Dear Maintainer,
> 
> When I dist-upgrade my distro, I got the following error :
> /
> dpkg: error processing archive 
> /var/cache/apt/archives/libidl-2-0_0.8.14-3_amd64.deb (--unpack):
>  trying to overwrite '/usr/lib/x86_64-linux-gnu/libIDL-2.so.0.0.0', which is 
>also in package libidl0:amd64 0.8.14-1
> Processing triggers for libc-bin (2.19-22) ...
> Errors were encountered while processing:
>  /var/cache/apt/archives/libidl-2-0_0.8.14-3_amd64.deb
> E: Sub-process /usr/bin/dpkg returned an error code (1)




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

Bug#664141: fancontrol: service needs restarting after sleep

[Aurelien Jarno]

On 2021-01-23 09:52, Emilian Nowak wrote:
> Why this patch wasn't included ?

Technically there should not be any need to restart the daemon after
suspend, the sensors kernel drivers are supposed to restart the devices
in the same state they were before suspend. Now if people insist, I can
include it. I can't test it by myself and the only risk is breaking
working systems.

> I did it by myself locally few versions ago. 
> 
> Now upgrade came and fans are spinning like a crazy after suspend. 

I don't get how an upgrade do that, the package doesn't actively remove
the file /lib/systemd/system-sleep/fancontrol added by the patch.

> Is it deprecated project, and something else should be used nowdays?

Yes, fancontrol is not really maintained upstream anymore, and has never
been more than a quick hack (hence the bash language) than a real tool.
It was probably a big mistake to include it as a package initially. It
works on a very limited number of configurations. The real replacement
is to use the features provided by the hardware. Only the lm-sensors
tool and the corresponding libsensors are really well maintained
upstream.

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

Bug#978389: easyh10: diff for NMU version 1.5-4.1

[Adrian Bunk]

Control: tags 978389 + patch
Control: tags 978389 + pending

Dear maintainer,

I've prepared an NMU for easyh10 (versioned as 1.5-4.1) and uploaded
it to DELAYED/14. Please feel free to tell me if I should cancel it.

cu
Adrian
diff -Nru easyh10-1.5/debian/changelog easyh10-1.5/debian/changelog
--- easyh10-1.5/debian/changelog	2016-10-09 23:43:46.0 +0300
+++ easyh10-1.5/debian/changelog	2021-01-25 01:08:02.0 +0200
@@ -1,3 +1,10 @@
+easyh10 (1.5-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove usage of obsolete AM_LANGINFO_CODESET. (Closes: #978389)
+
+ -- Adrian Bunk   Mon, 25 Jan 2021 01:08:02 +0200
+
 easyh10 (1.5-4) unstable; urgency=medium
 
   * Fix the 40-fix-FTBFS-Hurd.patch.
diff -Nru easyh10-1.5/debian/patches/50-no-am-langinfo-codeset.patch easyh10-1.5/debian/patches/50-no-am-langinfo-codeset.patch
--- easyh10-1.5/debian/patches/50-no-am-langinfo-codeset.patch	1970-01-01 02:00:00.0 +0200
+++ easyh10-1.5/debian/patches/50-no-am-langinfo-codeset.patch	2021-01-25 01:08:02.0 +0200
@@ -0,0 +1,38 @@
+Description: Remove usage of obsolete AM_LANGINFO_CODESET
+Author: Adrian Bunk 
+Bug-Debian: https://bugs.debian.org/978389
+
+--- easyh10-1.5.orig/configure.in
 easyh10-1.5/configure.in
+@@ -181,7 +181,6 @@ case $with_libiconv in
+ AC_DEFINE(USE_LIBICONV_NATIVE, 1, [Using a native implementation of iconv in a separate library])
+ ;;
+ esac
+-AM_LANGINFO_CODESET
+ 
+ 
+ dnl Checks for id3tag
+--- easyh10-1.5.orig/cui/main.c
 easyh10-1.5/cui/main.c
+@@ -41,9 +41,7 @@
+ #include 
+ #include 
+ 
+-#ifdef HAVE_LANGINFO_CODESET
+ #include 
+-#endif
+ 
+ #ifdef	HAVE_GETOPT_H
+ #include 
+@@ -889,11 +887,9 @@ int main(int argc, char *argv[])
+ 	if (!encoding_specified) {
+ 		const char *encoding = getenv("CHARSET");
+ 
+-#ifdef	HAVE_LANGINFO_CODESET
+ 		if (!encoding) {
+ 			encoding = nl_langinfo(CODESET);
+ 		}
+-#endif/*HAVE_LANGINFO_CODESET*/
+ 
+ 		if (encoding) {
+ 			/* EasyH10 could detect the character encoding. */
diff -Nru easyh10-1.5/debian/patches/series easyh10-1.5/debian/patches/series
--- easyh10-1.5/debian/patches/series	2016-10-09 23:43:46.0 +0300
+++ easyh10-1.5/debian/patches/series	2021-01-25 01:08:02.0 +0200
@@ -2,3 +2,4 @@
 20-dont-install-docs.patch
 30-fix-spelling.patch
 40-fix-FTBFS-Hurd.patch
+50-no-am-langinfo-codeset.patch

Bug#980975: cups error: Failed to create /var/spool/cups/tmp/.hplip

[Chris Bainbridge]

Package: cups
Version: 2.3.3op1-7

"Failed to create /var/spool/cups/tmp/.hplip" appears in the journal on
bullseye. I am not using hplip, and have never installed it.

Bug#980974: apparmor blocks cups backend outgoing network connections

[Chris Bainbridge]

Package: cups
Version: 2.3.3op1-7

After upgrading to bullseye, TCP connections from cupsd to localhost
appeared to be blocked:

Jan 23 23:39:29 debian audit[2172]: AVC apparmor="DENIED"
operation="capable" profile="/usr/sbin/cupsd" pid=2172 comm="cupsd"
capability=12  capname="net_admin"
Jan 23 23:39:29 debian systemd[1]: Started CUPS Scheduler.
Jan 23 23:39:29 debian kernel: kauditd_printk_skb: 10 callbacks suppressed
Jan 23 23:39:29 debian kernel: audit: type=1400 audit(1611445169.589:22):
apparmor="DENIED" operation="capable" profile="/usr/sbin/cupsd" pid=2172
comm="cupsd" capability=12>
Jan 23 23:39:29 debian systemd[1]: Started Make remote CUPS printers
available locally.
Jan 23 23:39:29 debian audit[2174]: AVC apparmor="DENIED"
operation="capable" profile="/usr/sbin/cups-browsed" pid=2174
comm="cups-browsed" capability=23  capname="sys_nice"

I worked around this with `aa-complain cupsd`, `aa-complain cups-browsed`,
but I would guess that this should work without modifications, unless this
(TCP connections from cupsd to backend driver) is considered non-standard
usage?

Bug#980973: Cups attempts to probe, configure unsupported Canon USB printers

[Chris Bainbridge]

Package: cups
Version: 2.3.3op1-7

Cups does not support Canon CAPT USB printers (this requires a proprietary
driver which uses /dev/usb/lp0), but these printers are not blacklisted, so
when one is plugged in, cups sets up a new, non-functional printer, and
probes the USB device, the kernel logs as a USB disconnect, and disrupts
operation of the Canon driver. Running lpstat also seems to do some probe
and cause a USB device disconnect. The kernel logs:

Jan 23 23:45:29 debian kernel: usblp0: removed

It appears the fix would be to add CAPT printers to
/usr/share/cups/usb/org.cups.usb-quirks as so:

# Canon, Inc. LBP3010/LBP3018/LBP3050 Printer
0x04a9 0x26da blacklist

etc.

Bug#980946: qemu-system-x86: qemu VM with vga virtio fails spice assertion at reboot, sometimes

[Bernhard Übelacker]

Package: qemu-system-x86
Version: 1:5.2+dfsg-3
Severity: normal
X-Debbugs-Cc: bernha...@mailbox.org

Dear Maintainer,
I was playing around with a qemu VM with a virtio vga to see
how far I could get with accelerated graphics inside a VM.
I was watching the VM via remote-viewer.

But on several reboots of the VM I received this message:

qemu-system-x86_64: Spice: red-qxl.c:706:spice_qxl_gl_scanout: condition 
`qxl_state->gl_draw_cookie == GL_DRAW_COOKIE_INVALID' failed

Then the VM aborts in spice_logv.

I attached then a debugger before that point and got the
following stack where we reach that assert.
(The spice_backtrace function did output nothing.)

Below is the used command of qemu and remote-viewer.

When I tried to reboot without a remote-viewer attached I
did not receive that assert on a few reboots.

Kind regards,
Bernhard






(gdb) bt
#0  spice_backtrace () at backtrace.c:126
#1  0x7fc8b87d2653 in spice_logv (log_domain=0x7fc8b8838291 "Spice", args=0x7f080ba0, format=0x7fc8b8839160 
"condition `%s' failed", function=0x7fc8b8842010 <__FUNCTION__.6> "spice_qxl_gl_scanout", 
strloc=0x7fc8b8841eaf "red-qxl.c:706", log_level=G_LOG_LEVEL_CRITICAL, log_domain=0x7fc8b8838291 "Spice") at 
log.c:55
#2  spice_log (log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, strloc=strloc@entry=0x7fc8b8841eaf 
"red-qxl.c:706", function=function@entry=0x7fc8b8842010 <__FUNCTION__.6> 
"spice_qxl_gl_scanout", format=format@entry=0x7fc8b8839160 "condition `%s' failed") at log.c:69
#3  0x7fc8b87a0861 in spice_qxl_gl_scanout (qxl=qxl@entry=0x55aed2cbf0e8, 
fd=fd@entry=-1, width=width@entry=0, height=height@entry=0, 
stride=stride@entry=0, format=format@entry=0, y_0_top=0) at red-qxl.c:706
#4  0x55aed05643ac in qemu_spice_gl_scanout_disable (dcl=0x55aed2cbf0a8) at 
../../ui/spice-display.c:919
#5  0x55aed04ea4d1 in virtio_gpu_virgl_reset (g=g@entry=0x55aed25eee40) at 
../../hw/display/virtio-gpu-3d.c:601
#6  0x55aed063cac8 in virtio_gpu_reset (vdev=0x55aed25eee40) at 
../../hw/display/virtio-gpu.c:1154
#7  0x55aed07ddcf2 in virtio_reset (opaque=0x55aed25eee40) at 
../../hw/virtio/virtio.c:2001
#8  0x55aed05dafa7 in virtio_bus_reset (bus=bus@entry=0x55aed25de108) at 
../../hw/virtio/virtio-bus.c:95
#9  0x55aed06b1b50 in virtio_pci_reset (qdev=) at 
../../hw/virtio/virtio-pci.c:1870
#10 0x55aed05e5a1f in virtio_vga_base_reset (dev=0x55aed25d6000) at 
../../hw/display/virtio-vga.c:164
#11 0x55aed0934be2 in resettable_phase_hold (obj=0x55aed25d6000, opaque=, type=) at ../../hw/core/resettable.c:182
#12 0x55aed092faa4 in bus_reset_child_foreach (obj=, 
cb=0x55aed0934b00 , opaque=0x0, type=RESET_TYPE_COLD) at 
../../hw/core/bus.c:97
#13 0x55aed0934b9c in resettable_child_foreach (type=RESET_TYPE_COLD, opaque=0x0, 
cb=0x55aed0934b00 , obj=0x55aed2199e40, 
rc=0x55aed17343f0) at ../../hw/core/resettable.c:96
#14 resettable_phase_hold (obj=0x55aed2199e40, opaque=, 
type=RESET_TYPE_COLD) at ../../hw/core/resettable.c:173
#15 0x55aed093215b in device_reset_child_foreach (obj=, 
cb=0x55aed0934b00 , opaque=0x0, type=RESET_TYPE_COLD) at 
../../hw/core/qdev.c:376
#16 0x55aed0934b9c in resettable_child_foreach (type=RESET_TYPE_COLD, opaque=0x0, 
cb=0x55aed0934b00 , obj=0x55aed2198dd0, 
rc=0x55aed16f3db0) at ../../hw/core/resettable.c:96
#17 resettable_phase_hold (obj=0x55aed2198dd0, opaque=, 
type=RESET_TYPE_COLD) at ../../hw/core/resettable.c:173
#18 0x55aed092faa4 in bus_reset_child_foreach (obj=, 
cb=0x55aed0934b00 , opaque=0x0, type=RESET_TYPE_COLD) at 
../../hw/core/bus.c:97
#19 0x55aed0934b9c in resettable_child_foreach (type=RESET_TYPE_COLD, opaque=0x0, 
cb=0x55aed0934b00 , obj=0x55aed189a720, 
rc=0x55aed17f1710) at ../../hw/core/resettable.c:96
#20 resettable_phase_hold (obj=obj@entry=0x55aed189a720, 
opaque=opaque@entry=0x0, type=type@entry=RESET_TYPE_COLD) at 
../../hw/core/resettable.c:173
#21 0x55aed0934f21 in resettable_assert_reset 
(obj=obj@entry=0x55aed189a720, type=type@entry=RESET_TYPE_COLD) at 
../../hw/core/resettable.c:60
#22 0x55aed09354d0 in resettable_reset (type=RESET_TYPE_COLD, 
obj=0x55aed189a720) at ../../hw/core/resettable.c:45
#23 resettable_cold_reset_fn (opaque=0x55aed189a720) at 
../../hw/core/resettable.c:269
#24 0x55aed093450d in qemu_devices_reset () at ../../hw/core/reset.c:69
#25 0x55aed06edf8b in pc_machine_reset (machine=) at 
../../hw/i386/pc.c:1615
#26 0x55aed0864e4d in qemu_system_reset 
(reason=reason@entry=SHUTDOWN_CAUSE_GUEST_RESET) at ../../softmmu/vl.c:1405
#27 0x55aed0865039 in main_loop_should_exit () at ../../softmmu/vl.c:1640
#28 0x55aed086574c in qemu_main_loop () at ../../softmmu/vl.c:1674
#29 0x55aed04bf29e in main (argc=, argv=, 
envp=) at ../../softmmu/main.c:50
(gdb)

(gdb) print qxl_state
$1 = (QXLState *) 0x55aed34b96f0
(gdb) print *qxl_state
$2 = {qxl_worker = {minor_version = 3, major_version = 3, wakeup = 0x7fc8b879fb00 , oom = 0x7fc8b879fb60 , start = 0x7fc8b879fce0 
, stop 

Bug#980972: xxsds-dynamic: Changelog entry missing trailer line

[Logan Rosen]

Source: xxsds-dynamic
Version: 1.0~alpha.1+2020072524git5390b6c-2
Severity: serious
Justification: Policy 4.4

Hi,

The changelog entry for 1.0~alpha.1+2020072524git5390b6c-2 is missing a
trailer line with maintainer and date information, which violates Debian
policy and caused the package to fail to upload to the Ubuntu archive.

Can you please add a trailer line accordingly? I added one in Ubuntu
based on the information I could garner about the upload. [1]

Thanks,
Logan

[1] 
http://launchpadlibrarian.net/519371489/xxsds-dynamic_1.0~alpha.1+2020072524git5390b6c-2_1.0~alpha.1+2020072524git5390b6c-2ubuntu1.diff.gz

Bug#980971: ghostscript lacks opvp support, breaks some printer backends

[Chris Bainbridge]

Package: ghostscript
Version: 9.53.3~dfsg-6

As reported at https://bugzilla.redhat.com/show_bug.cgi?id=1899885
ghostscript upstream temporarily disabled opvp support, breaking Canon
CAPT/UFR printer driver support in cups. This change has since been
reverted upstream. I can confirm that the patch at
https://git.ghostscript.com/?p=ghostpdl.git;a=patch;h=c6ce09aa5c9e does
restore Canon printer functionality in bullseye.

Bug#979037: python-pgpy: Missing build dependency on python3-wheel

[Logan Rosen]

Control: tags -1 patch

Hi,

In Ubuntu, the attached patch was applied to achieve the following:

  * Add missing build dependency on python3-wheel to fix FTBFS.

Thanks for considering the patch.

Logan
diff -Nru python-pgpy-0.5.3/debian/control python-pgpy-0.5.3/debian/control
--- python-pgpy-0.5.3/debian/control2021-01-01 20:15:55.0 -0500
+++ python-pgpy-0.5.3/debian/control2021-01-24 17:02:05.0 -0500
@@ -22,6 +22,7 @@
  python3-setuptools,
  python3-six (>= 1.9.0),
  python3-sphinx ,
+ python3-wheel
 Standards-Version: 4.5.1
 Vcs-Git: https://github.com/SecurityInnovation/PGPy.git -b debian/master
 Vcs-Browser: https://github.com/SecurityInnovation/PGPy

Bug#978032: python-cobra: autopkgtest regression in testing

[Adrian Bunk]

On Thu, Dec 24, 2020 at 09:58:57PM +0200, Graham Inggs wrote:
> Source: python-cobra
> Version: 0.19.0-1
> Severity: serious
> Tags: sid bullseye
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: regression
> 
> Hi Maintainer
> 
> The autopkgtests of python-cobra recently started to fail in testing [1].
> I've copied what I hope is the relevant part of the log below.
> 
> Regards
> Graham
> 
> 
> [1] https://ci.debian.net/packages/p/python-cobra/testing/amd64/
> 
> 
>  ERRORS 
> 
> __ ERROR at setup of TestManipulation.test_escape_ids 
> __
> 
> filename = '/usr/lib/python3/dist-packages/cobra/test/data/textbook.xml.gz'
> number = 
> f_replace = {'F_GENE': ,
> 'F_GENE_REV': , 'F_GROUP':
> , 'F_GROUP_REV':  _f_group_rev at 0x7f75f8531040>, ...}
> kwargs = {}
> doc =  'SBMLDocument *' at 0x7f75f402cc60> >
> cobra_error = CobraSBMLError('Something went wrong reading the SBML
> model. Most likely the SBML model is not valid. Please check
> tha...ame)`\nIf the model is valid and cannot be read please open an
> issue at https://github.com/opencobra/cobrapy/issues .')

This is also a FTBFS.

Trying to upgrade to 0.20.0 for checking whether that would help:
After some minor adjustments the first blocker is missing
diskcache (#940625).

cu
Adrian

Bug#977674: Corrupt changes file when built with --source-only-changes

[Johannes Schauer Marin Rodrigues]

Control: tag -1 + help newcomer

Hi,

sorry for the late reply.

Quoting Mathias Behrle (2020-12-18 16:39:44)
> I am running a builder for the Tryton packages that is configured to provide
> a changes as well as a source.changes file. The first used for the upload to
> the reprepro mirror, the latter used to upload to Debian.
> 
> The results of the last builder run caused mismatches of checksums when
> importing to reprepro. Indeed the control of the checksums prooved to be
> wrong. I suspect the following lines in the build logs to be the
> culprit:
> 
> """
> Signature with key 'mathi...@m9s.biz' requested:
>  signfile dsc 
> /home/mathiasb/bin/tryton/debian_builder/results/sid/tryton-server_5.0.30-1.dsc
>  mathi...@m9s.biz
> 
>  fixup_buildinfo 
> /home/mathiasb/bin/tryton/debian_builder/results/sid/tryton-server_5.0.30-1.dsc
>  
> /home/mathiasb/bin/tryton/debian_builder/results/sid/tryton-server_5.0.30-1_amd64.buildinfo
>  signfile buildinfo 
> /home/mathiasb/bin/tryton/debian_builder/results/sid/tryton-server_5.0.30-1_amd64.buildinfo
>  mathi...@m9s.biz
> 
>  fixup_changes dsc 
> /home/mathiasb/bin/tryton/debian_builder/results/sid/tryton-server_5.0.30-1.dsc
>  
> /home/mathiasb/bin/tryton/debian_builder/results/sid/tryton-server_5.0.30-1_amd64.changes
>  fixup_changes buildinfo 
> /home/mathiasb/bin/tryton/debian_builder/results/sid/tryton-server_5.0.30-1_amd64.buildinfo
>  
> /home/mathiasb/bin/tryton/debian_builder/results/sid/tryton-server_5.0.30-1_amd64.changes
>  signfile changes 
> /home/mathiasb/bin/tryton/debian_builder/results/sid/tryton-server_5.0.30-1_amd64.changes
>  mathi...@m9s.biz
> 
> Successfully signed dsc, buildinfo, changes files
> 
> ---> from here comes the problematic part from --source-only-changes
> 
>  unsignfile 
> /home/mathiasb/bin/tryton/debian_builder/results/sid/tryton-server_5.0.30-1_amd64.buildinfo
>  unsignfile 
> /home/mathiasb/bin/tryton/debian_builder/results/sid/tryton-server_5.0.30-1.dsc
>  signfile dsc 
> /home/mathiasb/bin/tryton/debian_builder/results/sid/tryton-server_5.0.30-1.dsc
>  mathi...@m9s.biz
> 
>  fixup_buildinfo 
> /home/mathiasb/bin/tryton/debian_builder/results/sid/tryton-server_5.0.30-1.dsc
>  
> /home/mathiasb/bin/tryton/debian_builder/results/sid/tryton-server_5.0.30-1_amd64.buildinfo
>  signfile buildinfo 
> /home/mathiasb/bin/tryton/debian_builder/results/sid/tryton-server_5.0.30-1_amd64.buildinfo
>  mathi...@m9s.biz
> 
>  fixup_changes dsc 
> /home/mathiasb/bin/tryton/debian_builder/results/sid/tryton-server_5.0.30-1.dsc
>  
> /home/mathiasb/bin/tryton/debian_builder/results/sid/tryton-server_5.0.30-1_source.changes
>  fixup_changes buildinfo 
> /home/mathiasb/bin/tryton/debian_builder/results/sid/tryton-server_5.0.30-1_amd64.buildinfo
>  
> /home/mathiasb/bin/tryton/debian_builder/results/sid/tryton-server_5.0.30-1_source.changes
>  signfile changes 
> /home/mathiasb/bin/tryton/debian_builder/results/sid/tryton-server_5.0.30-1_source.changes
>  mathi...@m9s.biz
> 
> Successfully signed dsc, buildinfo, changes files
> """
> 
> 
> Indeed running without --sourice-only-changes produced correct changes files.
> 
> The options used for the sbuild run are
> ['sbuild', '--quiet', '--chroot=sid-amd64-sbuild', 
> '--keyid=mathi...@m9s.biz', '--source', '--mailfrom="Debian Autobuilder 
> "', '--mail-log-to=mathi...@m9s.biz', '--sbuild-mode=user', 
> '--no-apt-update', '--no-apt-upgrade', '--no-apt-distupgrade', 
> '--lintian-opts=-i -v -I -E --pedantic', '--bd-uninstallable-explainer=apt', 
> '--source-only-changes', 
> '/home/mathiasb/bin/tryton/debian_builder/build/tryton-server']
> 
> I am attaching for reference two changes files, one with
> --source-only-changes, one without.

I'm not surprised that this bug exists. The codepath you are using doesn't get
any testing. The official buildds are not using source-only-changes and those
who do, do not sign the build result with sbuild.

I'm tagging this with "help" and "newcomer". The fix is is likely to modify the
function close_build_log() in lib/Sbuild/Build.pm. There is a part that calls
debsign differently if SOURCE_ONLY_CHANGES is active and that part is probably
broken somehow. A merge request against https://salsa.debian.org/debian/sbuild
is greatly appreciated.

Since you are using sbuild in a buildd context I think you can work around this
bug for now by either manually signing or manually mangling your changes files?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#978170: gdb-avr: diff for NMU version 7.7-4.1

[Adrian Bunk]

Control: tags 978170 + patch
Control: tags 978170 + pending

Dear maintainer,

I've prepared an NMU for gdb-avr (versioned as 7.7-4.1) and uploaded
it to DELAYED/14. Please feel free to tell me if I should cancel it.

cu
Adrian
diff -Nru gdb-avr-7.7/debian/changelog gdb-avr-7.7/debian/changelog
--- gdb-avr-7.7/debian/changelog	2016-07-14 21:21:43.0 +0300
+++ gdb-avr-7.7/debian/changelog	2021-01-24 23:30:28.0 +0200
@@ -1,3 +1,10 @@
+gdb-avr (7.7-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Adjust to gdb-source changes. (Closes: #978170)
+
+ -- Adrian Bunk   Sun, 24 Jan 2021 23:30:28 +0200
+
 gdb-avr (7.7-4) unstable; urgency=medium
 
   * Removed non-free manpage (closes: #828894)
diff -Nru gdb-avr-7.7/debian/rules gdb-avr-7.7/debian/rules
--- gdb-avr-7.7/debian/rules	2016-07-14 20:24:15.0 +0300
+++ gdb-avr-7.7/debian/rules	2021-01-24 23:30:28.0 +0200
@@ -29,7 +29,7 @@
 
 unpack: unpack-stamp
 unpack-stamp:
-	tar xjf /usr/src/gdb.tar.bz2
+	tar xf /usr/src/gdb.tar.*
 	mv gdb* src
 	mkdir build
 	touch unpack-stamp

Bug#980970: nginx: Owner for /var/log/nginx/*.log should be root and not www-data

[Samuel Bizien Filippi]

Package: nginx
Version: 1.18.0-6
Severity: minor
Tags: patch
X-Debbugs-Cc: sam...@bizien.info

Dear maintainers,

By default, log files for nginx (acces.log and error.log) are owned by 
www-data:adm with mode 640.

They should be owned by root, as nginx open these files before dropping 
privileges. I tried to
confine nginx with systemd options in 
/etc/systemd/system/nginx.service.d/hardening.conf :

> [Service]
> CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_SETUID CAP_SETGID

When doing that, nginx fails to start :

> janv. 24 21:28:38 sid nginx[1157]: nginx: [alert] could not open error log 
> file: open() "/var/log/nginx/error.log" failed (13: Permission denied)
> janv. 24 21:28:38 sid nginx[1157]: 2021/01/24 21:28:38 [emerg] 1157#1157: 
> open() "/var/log/nginx/access.log" failed (13: Permission denied)
> janv. 24 21:28:38 sid nginx[1157]: nginx: configuration file 
> /etc/nginx/nginx.conf test failed
> janv. 24 21:28:38 sid systemd[1]: nginx.service: Control process exited, 
> code=exited, status=1/FAILURE

To make it work, I have either to chown /var/log/nginx/{error,access}.log to 
root, or to add 
CAP_DAC_OVERRIDE to CapabilityBoundingSet (which I'd rather avoid, that's the 
point of "confinement")

Root-owned nginx log files :
- works as expected (hits & errors show up)
- makes your system more secure (logs are not readable by nginx workers anymore)

I tried to write a patch (attached), but it does not work as expected.

Best regards,

Samuel Bizien Filippi.


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

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

Versions of packages nginx depends on:
ii  nginx-core  1.18.0-6+b1

nginx recommends no packages.

nginx suggests no packages.

-- no debconf information
Index: nginx-1.18.0/debian/nginx-common/DEBIAN/postinst
===
--- nginx-1.18.0.orig/debian/nginx-common/DEBIAN/postinst
+++ nginx-1.18.0/debian/nginx-common/DEBIAN/postinst
@@ -21,13 +21,13 @@ case "$1" in
   if [ ! -e "$access_log" ]; then
 touch "$access_log"
 chmod 640 "$access_log"
-chown www-data:adm "$access_log"
+chown root:adm "$access_log"
   fi
 
   if [ ! -e "$error_log" ]; then
 touch "$error_log"
 chmod 640 "$error_log"
-chown www-data:adm "$error_log"
+chown root:adm "$error_log"
   fi
 fi
 
Index: nginx-1.18.0/debian/nginx-common/usr/share/doc/nginx-common/README.Debian
===
--- 
nginx-1.18.0.orig/debian/nginx-common/usr/share/doc/nginx-common/README.Debian
+++ nginx-1.18.0/debian/nginx-common/usr/share/doc/nginx-common/README.Debian
@@ -7,7 +7,7 @@ Noteworthy Changes Wheezy => Jessie
 
 * /var/log/nginx permissions
 
-  /var/log/nginx/ is now not readable by default (www-data:adm 750),
+  /var/log/nginx/* is now not readable by default (root:adm 640),
   If you depend on that you can add a manual override with dpkg-statoverride.
 
 * New upgrade & rotate initscript commands

Bug#977542: golang-github-revel-revel: Depends on network in tests

[Logan Rosen]

Control: tags -1 patch

Hi,

In Ubuntu, the attached patch was applied to achieve the following:

  * d/p/0002-skip-test-requiring-network-access.patch: Skip TestGetCustom,
which requires network access and thus fails on Ubuntu buildds.

Thanks for considering the patch.

Logan
diff -Nru 
golang-github-revel-revel-1.0.0/debian/patches/0002-skip-test-requiring-network-access.patch
 
golang-github-revel-revel-1.0.0/debian/patches/0002-skip-test-requiring-network-access.patch
--- 
golang-github-revel-revel-1.0.0/debian/patches/0002-skip-test-requiring-network-access.patch
1969-12-31 19:00:00.0 -0500
+++ 
golang-github-revel-revel-1.0.0/debian/patches/0002-skip-test-requiring-network-access.patch
2021-01-24 16:37:50.0 -0500
@@ -0,0 +1,10 @@
+--- a/testing/testsuite_test.go
 b/testing/testsuite_test.go
+@@ -73,6 +73,7 @@
+ 
+ // This test is known to fail
+ func TestGetCustom(t *testing.T) {
++  t.Skip("Requires network access")
+   testSuite := createNewTestSuite(t)
+   for x := 0; x < 5; x++ {
+   testSuite.GetCustom("http://httpbin.org/get;).Send()
diff -Nru golang-github-revel-revel-1.0.0/debian/patches/series 
golang-github-revel-revel-1.0.0/debian/patches/series
--- golang-github-revel-revel-1.0.0/debian/patches/series   2020-11-20 
22:16:55.0 -0500
+++ golang-github-revel-revel-1.0.0/debian/patches/series   2021-01-24 
16:37:22.0 -0500
@@ -1 +1,2 @@
 0001-skip-memcached-and-redis-tests.patch
+0002-skip-test-requiring-network-access.patch

Bug#980969: mimedefang: reduce Build-Depends

[Helmut Grohne]

Source: mimedefang
Version: 2.84-4
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

mimedefang cannot be cross built from source, because its Build-Depends
are not satisfiable. Instead of looking into such a difficult problem, I
looked into easily droppable dependencies. It turns out that the
sanitizer dependency is entirely unused. There is no mention of it or
its contained modules or tools in the entire source. libunix-syslog-perl
is used to provide Unix::Syslog, which can be used by mimedefang if
Sys::Syslog is not available. The latter is part of perl itself, so the
former is unused. Please consider applying the attached patch.

Helmut
diff --minimal -Nru mimedefang-2.84/debian/changelog 
mimedefang-2.84/debian/changelog
--- mimedefang-2.84/debian/changelog2020-09-14 13:40:19.0 +0200
+++ mimedefang-2.84/debian/changelog2021-01-24 12:22:26.0 +0100
@@ -1,3 +1,13 @@
+mimedefang (2.84-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Reduce Build-Depends: (Closes: #-1)
++ libunix-syslog-perl is unneeded as mimedefang can use either Sys::Syslog
+  or Unix::Syslog and the former is part of perl itself.
++ sanitizer is unused. There is no mention of it beyond debian/control.
+
+ -- Helmut Grohne   Sun, 24 Jan 2021 12:22:26 +0100
+
 mimedefang (2.84-4) unstable; urgency=medium
 
   [ Debian Janitor ]
diff --minimal -Nru mimedefang-2.84/debian/control 
mimedefang-2.84/debian/control
--- mimedefang-2.84/debian/control  2020-09-14 13:40:19.0 +0200
+++ mimedefang-2.84/debian/control  2021-01-24 12:20:49.0 +0100
@@ -2,7 +2,7 @@
 Section: mail
 Priority: optional
 Maintainer: Christoph Martin 
-Build-Depends: debhelper-compat (= 12), po-debconf, libmilter-dev, bsd-mailx, 
libunix-syslog-perl, libperl-dev, libmime-tools-perl, 
libmail-spamassassin-perl, sanitizer, libhtml-parser-perl, libarchive-zip-perl
+Build-Depends: debhelper-compat (= 12), po-debconf, libmilter-dev, bsd-mailx, 
libperl-dev, libmime-tools-perl, libmail-spamassassin-perl, 
libhtml-parser-perl, libarchive-zip-perl
 Standards-Version: 3.9.8
 Homepage: https://www.mimedefang.org/
 Vcs-Git: https://salsa.debian.org/debian/mimedefang.git

Bug#848055: golang-github-go-chef-chef: FTBFS randomly (failing tests)

[Logan Rosen]

Control: tags -1 patch fixed-upstream
Control: forwarded -1 https://github.com/go-chef/chef/issues/87

Hi,

In Ubuntu, the attached patch was applied to achieve the following:

  * d/p/fix_intermittent_test_failures.patch: Cherrypick upstream Git commit
to fix intermittent test failures causing FTBFS.

Thanks for considering the patch.

Logan
diff -Nru 
golang-github-go-chef-chef-0.0.1+git20161023.60.deb8c38/debian/patches/fix_intermittent_test_failures.patch
 
golang-github-go-chef-chef-0.0.1+git20161023.60.deb8c38/debian/patches/fix_intermittent_test_failures.patch
--- 
golang-github-go-chef-chef-0.0.1+git20161023.60.deb8c38/debian/patches/fix_intermittent_test_failures.patch
 1969-12-31 19:00:00.0 -0500
+++ 
golang-github-go-chef-chef-0.0.1+git20161023.60.deb8c38/debian/patches/fix_intermittent_test_failures.patch
 2021-01-24 16:27:19.0 -0500
@@ -0,0 +1,104 @@
+From b8a5b9cbb7b472eba5c1e2759aa6c288b8251de1 Mon Sep 17 00:00:00 2001
+From: markgibbons 
+Date: Sat, 7 Dec 2019 07:10:13 -0800
+Subject: [PATCH] Fix the intermittent failures in the String tests
+
+---
+ .circleci/config.yml |  2 +-
+ client_test.go   |  8 +---
+ databag_test.go  |  7 +--
+ environment_test.go  | 11 +++
+ role_test.go | 10 ++
+ 5 files changed, 24 insertions(+), 14 deletions(-)
+
+--- a/client_test.go
 b/client_test.go
+@@ -36,15 +36,17 @@
+   mux.HandleFunc("/clients", func(w http.ResponseWriter, r *http.Request) 
{
+   fmt.Fprintf(w, `{"client1": "http://localhost/clients/client1;, 
"client2": "http://localhost/clients/client2"}`)
+   })
+-
+   response, err := client.Clients.List()
+   if err != nil {
+   t.Errorf("Clients.List returned error: %v", err)
+   }
+ 
++  // The order printed by the String function is not defined
+   want := "client1 => http://localhost/clients/client1\nclient2 => 
http://localhost/clients/client2\n;
+-  if response.String() != want {
+-  t.Errorf("Clients.List returned:\n%+v\nwant:\n%+v\n", 
response.String(), want)
++  want2 := "client2 => http://localhost/clients/client2\nclient1 => 
http://localhost/clients/client1\n;
++  rstr := response.String()
++  if rstr != want && rstr != want2 {
++  t.Errorf("Clients.List returned:\n%+v\nwant:\n%+v\n", rstr, 
want)
+   }
+ }
+ 
+--- a/databag_test.go
 b/databag_test.go
+@@ -157,8 +157,11 @@
+ 
+ func TestDataBagsService_DataBagListResultString(t *testing.T) {
+   e := {"bag1": "http://localhost/data/bag1;, "bag2": 
"http://localhost/data/bag2"}
++  // The output order is not guarenteed by the String function, check for 
either order
+   want := "bag1 => http://localhost/data/bag1\nbag2 => 
http://localhost/data/bag2\n;
+-  if e.String() != want {
+-  t.Errorf("DataBagListResult.String 
returned:\n%+v\nwant:\n%+v\n", e.String(), want)
++  want2 := "bag2 => http://localhost/data/bag2\nbag1 => 
http://localhost/data/bag1\n;
++  ebag := e.String()
++  if ebag != want && ebag != want2 {
++  t.Errorf("DataBagListResult.String 
returned:\n%+v\nwant:\n%+v\n", ebag, want)
+   }
+ }
+--- a/environment_test.go
 b/environment_test.go
+@@ -143,16 +143,19 @@
+ 
+ func TestEnvironmentsService_EnvironmentListResultString(t *testing.T) {
+   e := {"_default": 
"https://api.opscode.com/organizations/org_name/environments/_default;, 
"webserver": 
"https://api.opscode.com/organizations/org_name/environments/webserver"}
++  estr := e.String()
+   want := "_default => 
https://api.opscode.com/organizations/org_name/environments/_default\nwebserver 
=> https://api.opscode.com/organizations/org_name/environments/webserver\n;
+-  if e.String() != want {
+-  t.Errorf("EnvironmentResult.String 
returned:\n%+v\nwant:\n%+v\n", e.String(), want)
++  want2 := "webserver => 
https://api.opscode.com/organizations/org_name/environments/webserver\n_default 
=> https://api.opscode.com/organizations/org_name/environments/_default\n;
++  if estr != want && estr != want2 {
++  t.Errorf("EnvironmentResult.String 
returned:\n%+v\nwant:\n%+v\n", estr, want)
+   }
+ }
+ 
+ func TestEnvironmentsService_EnvironmentCreateResultString(t *testing.T) {
+   e := {"uri": "http://localhost:4000/environments/dev"}
++  estr := e.String()
+   want := "uri => http://localhost:4000/environments/dev\n;
+-  if e.String() != want {
+-  t.Errorf("EnvironmentResult.String returned %+v, want %+v", 
e.String(), want)
++  if estr != want {
++  t.Errorf("EnvironmentResult.String returned %+v, want %+v", 
estr, want)
+   }
+ }
+--- a/role_test.go
 b/role_test.go
+@@ -178,17 +178,19 @@
+ 
+ func TestRolesService_RoleListResultString(t *testing.T) {
+   r := {"foo": "http://localhost:4000/roles/foo"}
++  rstr := r.String()
+   want := "foo => http://localhost:4000/roles/foo\n;
+-  

Bug#980965: pdns-recursor: flaky autopkgtest on ppc64el

[Chris Hofstaedtler]

I've uploaded a new revision showing journal output on restart.
Maybe that will help debugging this.

Also: it would be great if I could get email for test failures.

Chris

Bug#980968: doc-base could suggest dochelp

[Mehdi Dogguy]

Package: doc-base
Version: 0.11
Severity: wishlist

Hi,

I created dochelp some years ago to have simple yet effective tool to
browse doc-base registered documentation installed on one's system.

dochelp doesn't require any webserver or heavy tool. It generates a
static web page which allows searching with some JS. The static web
page is updated by a dpkg trigger (each time a new doc-base file
appears).

Can you please suggest dochelp? (next to dhelp, etc...)

Thanks,

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

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

Versions of packages doc-base depends on:
pn  libuuid-perl   
ii  libyaml-tiny-perl  1.73-1

doc-base recommends no packages.

Versions of packages doc-base suggests:
ii  yelp  3.38.2-1

Bug#980964: pdns: flaky autopkgtest on s390x

[Chris Hofstaedtler]

Hi,

* Paul Gevers  [210124 21:51]:
> Please do get in touch if we need to dive into this together. Or if you
> want to discuss this issue.
[..]

> + service pdns restart
> Job for pdns.service failed because the control process exited with
> error code.
> See "systemctl status pdns.service" and "journalctl -xe" for details.
> + kill -TERM 1986
> autopkgtest [19:05:43]: test smoke-mysql: ---]

Yeah, I think we need to look into this (and #980965) together.

I don't see why this would "just fail randomly". I don't think its a
timing thing. Maybe this worker is weird in a different way.

Chris

Bug#980967: bats breaks ruby-build autopkgtest: /usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command not found

[Paul Gevers]

Source: bats
Control: found -1 bats/1.2.1-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks
Control: affects -1 ruby-build

Dear maintainer(s),

With a recent upload of bats the autopkgtest of ruby-build fails in
testing when that autopkgtest is run with the binary packages of bats
from unstable. It passes when run with only packages from testing. In
tabular form:

   passfail
bats   from testing1.2.1-1
ruby-build from testing20200401-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. It really
looks like bats functionality is broken.

Currently this regression is blocking the migration of bats to testing
[1]. Can you please investigate the situation and fix the problem?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=bats

https://ci.debian.net/data/autopkgtest/testing/amd64/r/ruby-build/9965546/log.gz

autopkgtest [06:12:14]: test command1: bats test/
autopkgtest [06:12:14]: test command1: [---
1..100
/usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command
not found
/usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command
not found
/usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command
not found
/usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command
not found
/usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command
not found
/usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command
not found
/usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command
not found
/usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command
not found
/usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command
not found
/usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command
not found
/usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command
not found
/usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command
not found
/usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command
not found
/usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command
not found
/usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command
not found
/usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command
not found
/usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command
not found
/usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command
not found
/usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command
not found
/usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command
not found
/usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command
not found
/usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command
not found
/usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command
not found
/usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command
not found
/usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command
not found
/usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command
not found
/usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command
not found
/usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command
not found
/usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command
not found
/usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command
not found
/usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command
not found
/usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command
not found
/usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command
not found
/usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command
not found
/usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command
not found
/usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command
not found
/usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command
not found
/usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command
not found
/usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command
not found
/usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command
not found
/usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command
not found
/usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command
not found
/usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command
not found
/usr/libexec/bats-core/bats-exec-file: line 194: bats-exec-test: command
not found
/usr/libexec/bats-core/bats-exec-file: line 

Bug#979865: m2crypto FTBFS on IPV6-only buildds

[Adrian Bunk]

On Sun, Jan 24, 2021 at 07:48:55PM +0100, Sebastian Andrzej Siewior wrote:
> On 2021-01-12 08:22:05 [+0200], Adrian Bunk wrote:
> > Source: m2crypto
> > Version: 0.37.1-1
> > Severity: serious
> > Tags: ftbfs
> 
> I suggest to lower the severity to important

The release team considers these bugs release critical.

> and let it migrate to
> testing. After all this bug did not first appear in 0.37.1-1,
>...

If this is true, then the proper action would be a found indicating the 
first broken version.

> Sebastian

cu
Adrian

Bug#967686: Bug#967686: pcmanfm: depends on deprecated GTK 2

[Andriy Grytsenko]

Hello!

>It is not solution for Debian. Lxde just needs rebuild with gtk3 libs, 
>it'senough for fix this bug. I will do NMU after bullseye release if 
>maintainer won't do it.

I'm against just rebuilding everything against GTK+ 3.0 and abandoning
GTK+ 2.0. While version 3.0 still have some advanced features, it doesn't
just take much more resources (which may be a big issue for devices like
Raspberri Pi) but it also have some extra dependencies, and some people
still prefer look and feel of GTK+ 2.0 and highly dislike GTK+ 3.0 one.

So to solve this I believe it's much more appropriate to create parallel
packages - one against GTK+ 2.0 (for tight, old platforms and people who
dislike GTK+ 3.0) and another against GTK+ 3.0. I plan to do it all after
coming release of Debian.

Thank you for a suggestion, in any case.

Bug#980966: RM: golang-github-howeyc-fsnotify -- RoQA; FTBFS, superseded by golang-github-fsnotify-fsnotify

[Shengjing Zhu]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: z...@debian.org


Hi, upstream of golang-github-howeyc-fsnotify is no longer active since 2015,
and is superseded by golang-github-fsnotify-fsnotify.

Bug#980965: pdns-recursor: flaky autopkgtest on ppc64el

[Paul Gevers]

Source: pdns-recursor
Version: 4.4.2-2
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

Your package has an autopkgtest, great. However, I looked into
the history of your autopkgtest [1] on ppc64el (because it is blocking
boost1.74) and I noticed it fails regularly, while a rerun passes. I
copied some of the output at the bottom of this report.

Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

Please do get in touch if we need to dive into this together. Or if you
want to discuss this issue. I noticed that all the failed runs I checked
were done on the same worker. Could the problem be a timing issue? (The
worker has a spinning disk and is slower than our other workers).

Paul

https://ci.debian.net/data/autopkgtest/testing/ppc64el/p/pdns-recursor/9755158/log.gz

autopkgtest [06:22:39]: test smoke: [---
+ cat
+ cat
+ service pdns-recursor restart
Job for pdns-recursor.service failed because the control process exited
with error code.
See "systemctl status pdns-recursor.service" and "journalctl -xe" for
details.
autopkgtest [06:23:05]: test smoke: ---]



OpenPGP_signature
Description: OpenPGP digital signature

Bug#980964: pdns: flaky autopkgtest on s390x

[Paul Gevers]

Control: retitle -1 pdns: flaky autopkgtest on ppc64el

Hi,

On 24-01-2021 21:50, Paul Gevers wrote:
> Your package has an autopkgtest, great. However, I looked into
> the history of your autopkgtest [1] on s390x (because it is blocking

Should read ppc64el.

> https://ci.debian.net/data/autopkgtest/testing/ppc64el/p/pdns/9891909/log.gz

As mentioned here.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#980964: pdns: flaky autopkgtest on s390x

[Paul Gevers]

Source: pdns
Version: 4.4.0-3
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

Your package has an autopkgtest, great. However, I looked into
the history of your autopkgtest [1] on s390x (because it is blocking
boost1.74) and I noticed it fails regularly, while a rerun passes. I
copied some of the output at the bottom of this report.

Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

Please do get in touch if we need to dive into this together. Or if you
want to discuss this issue.

Paul

https://ci.debian.net/data/autopkgtest/testing/ppc64el/p/pdns/9891909/log.gz

autopkgtest [19:02:43]: test smoke-bind: [---
+ ZONE=bind.example.org
+ cat
+ cat
+ service pdns restart
Job for pdns.service failed because the control process exited with
error code.
See "systemctl status pdns.service" and "journalctl -xe" for details.
autopkgtest [19:03:09]: test smoke-bind: ---]

autopkgtest [19:04:56]: test smoke-mysql: [---
+ service mysql stop
+ trap 'kill -TERM $DB_SERVER_PID' EXIT TERM INT
+ DB_SERVER_PID=1986
+ mysqladmin ping
+ /usr/bin/mysqld_safe
mysqladmin: connect to server at 'localhost' failed
error: 'Can't connect to local MySQL server through socket
'/run/mysqld/mysqld.sock' (2)'
Check that mysqld is running and that the socket:
'/run/mysqld/mysqld.sock' exists!
+ sleep 0.5
210122 19:05:22 mysqld_safe Logging to syslog.
210122 19:05:22 mysqld_safe Starting mariadbd daemon with databases from
/var/lib/mysql
+ mysqladmin ping
mysqladmin: connect to server at 'localhost' failed
error: 'Can't connect to local MySQL server through socket
'/run/mysqld/mysqld.sock' (2)'
Check that mysqld is running and that the socket:
'/run/mysqld/mysqld.sock' exists!
+ sleep 0.5
+ mysqladmin ping
mysqladmin: connect to server at 'localhost' failed
error: 'Can't connect to local MySQL server through socket
'/run/mysqld/mysqld.sock' (2)'
Check that mysqld is running and that the socket:
'/run/mysqld/mysqld.sock' exists!
+ sleep 0.5
+ mysqladmin ping
mysqladmin: connect to server at 'localhost' failed
error: 'Can't connect to local MySQL server through socket
'/run/mysqld/mysqld.sock' (2)'
Check that mysqld is running and that the socket:
'/run/mysqld/mysqld.sock' exists!
+ sleep 0.5
+ mysqladmin ping
mysqladmin: connect to server at 'localhost' failed
error: 'Can't connect to local MySQL server through socket
'/run/mysqld/mysqld.sock' (2)'
Check that mysqld is running and that the socket:
'/run/mysqld/mysqld.sock' exists!
+ sleep 0.5
+ mysqladmin ping
mysqladmin: connect to server at 'localhost' failed
error: 'Can't connect to local MySQL server through socket
'/run/mysqld/mysqld.sock' (2)'
Check that mysqld is running and that the socket:
'/run/mysqld/mysqld.sock' exists!
+ sleep 0.5
+ mysqladmin ping
mysqladmin: connect to server at 'localhost' failed
error: 'Can't connect to local MySQL server through socket
'/run/mysqld/mysqld.sock' (2)'
Check that mysqld is running and that the socket:
'/run/mysqld/mysqld.sock' exists!
+ sleep 0.5
+ mysqladmin ping
mysqladmin: connect to server at 'localhost' failed
error: 'Can't connect to local MySQL server through socket
'/run/mysqld/mysqld.sock' (2)'
Check that mysqld is running and that the socket:
'/run/mysqld/mysqld.sock' exists!
+ sleep 0.5
+ mysqladmin ping
mysqld is alive
+ DBNAME=pdns
+ DBUSER=pdns
+ ZONE=mysql.example.org
+ cat
+ mysql --user=root mysql
+ mysql -uroot pdns
+ find /etc/powerdns/pdns.d/ -type f -delete
+ cat /usr/share/doc/pdns-backend-mysql/examples/gmysql.conf
+ sed -e '
s/_DBSERVER_/127.0.0.1/;
s/_DBPORT_/3306/;
s/_DBNAME_/pdns/;
s/_DBUSER_/pdns/;
s/_DBPASS_/password/;
'
+ chmod 0640 /etc/powerdns/pdns.d/gmysql.conf
+ chgrp pdns /etc/powerdns/pdns.d/gmysql.conf
+ cat /etc/powerdns/pdns.d/gmysql.conf
# See https://doc.powerdns.com/authoritative/backends/generic-mysql.html
launch+=gmysql

#
# gmysql-dbname Database name to connect to
#
# gmysql-dbname=powerdns
gmysql-dbname=pdns

#
# gmysql-dnssec Enable DNSSEC processing
#
# gmysql-dnssec=no
gmysql-dnssec=yes

#
# gmysql-group  Database backend MySQL 'group' to connect as
#
# gmysql-group=client

#
# gmysql-host   Database backend host to connect to
#
# gmysql-host=
gmysql-host=127.0.0.1

#
# gmysql-innodb-read-committed  Use InnoDB READ-COMMITTED transaction
isolation level
#
# gmysql-innodb-read-committed=yes

#
# gmysql-password   Database backend password to connect with
#
# gmysql-password=

Bug#980963: dpkg: Please add ARC architecture

[Alexey Brodkin]

Package: dpkg
Version: 1.19.7ubuntu3-1~202101232134~ubuntu20.04.1
Severity: wishlist
Tags: patch

Dear Maintainer,

ARC architecture seem to match requirements for being added to the dpkg
(https://wiki.debian.org/Teams/Dpkg/FAQ#Q._Can_we_add_support_for_new_dpkg_architectures.3F):

 * GNU triplet is there since 2013,
   see: 
https://git.savannah.gnu.org/cgit/config.git/commit/?id=986360de6e412cbed27dbe2dbfb64ddbd18e7370
 * Binutils, GCC & uClibc support ARC for many years now,
   glibc 2.32 finally gained ARC support, see 
https://lists.gnu.org/archive/html/info-gnu/2020-08/msg2.html 

Please see attached patch which implements reqested change.

-Alexey
>From 96523e18473b56743bf2f7d308c2d786f337e52e Mon Sep 17 00:00:00 2001
From: Alexey Brodkin 
Date: Sun, 24 Jan 2021 00:34:52 +0300
Subject: [PATCH] Add ARC architecture

---
 data/cputable | 2 ++
 scripts/t/Dpkg_Arch.t | 4 ++--
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/data/cputable b/data/cputable
index 9f2a8e0e4..114a66ecb 100644
--- a/data/cputable
+++ b/data/cputable
@@ -20,6 +20,8 @@ i386  i686(i[34567]86|pentium)32  
little
 ia64   ia64ia6464  little
 alpha  alpha   alpha.* 64  little
 amd64  x86_64  (amd64|x86_64)  64  little
+arcarc arc.*   32  little
+arceb  arc arceb.* 32  big
 armeb  armeb   arm.*b  32  big
 armarm arm.*   32  little
 arm64  aarch64 aarch64 64  little
diff --git a/scripts/t/Dpkg_Arch.t b/scripts/t/Dpkg_Arch.t
index a3a9e6fee..aa0d97a21 100644
--- a/scripts/t/Dpkg_Arch.t
+++ b/scripts/t/Dpkg_Arch.t
@@ -16,7 +16,7 @@
 use strict;
 use warnings;
 
-use Test::More tests => 16836;
+use Test::More tests => 17762;
 
 use_ok('Dpkg::Arch', qw(debarch_to_debtuple debarch_to_multiarch
 debarch_eq debarch_is debarch_is_wildcard
@@ -174,7 +174,7 @@ is(gnutriplet_to_debarch(undef), undef, 'undef gnutriplet');
 is(gnutriplet_to_debarch('unknown-unknown-unknown'), undef, 'unknown 
gnutriplet');
 is(gnutriplet_to_debarch('x86_64-linux-gnu'), 'amd64', 'known gnutriplet');
 
-is(scalar get_valid_arches(), 539, 'expected amount of known architectures');
+is(scalar get_valid_arches(), 569, 'expected amount of known architectures');
 
 {
 local $ENV{CC} = 'false';
-- 
2.25.1

Bug#980962: buster-pu: package intel-microcode/3.20201118.1~deb10u1

[Henrique de Moraes Holschuh]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

I'd like to update the intel-microcode package in Debian Buster.

This is a security-related update, but since it had a larger potential
for regressions, I coordinated with the security team and we agreed that
it would be best done in a slow pace, through a stable update.

Regressions were indeed reported (as expected).  A few days ago, Intel
published relevant information pinpointing the regression on Skylake D0
and Skylake R0 processors to specific conditions (detailed below for
completeness).

The 3.20201118.1~deb10u1 version of the package (the one I am proposing
for the stable update) contains changes not (yet?) in unstable to
address the Skylake D0/R0 issue: they had their updates frozen
to the same revision currently in Debian stable.

For the record, that does mean these two Skylake processor models are
_NOT_ receiving security updates in Debian stable at this time, and
still lack SRBDS mitigations as well as newer mitigations that require
newer microcode.

Here's the full details about the Skylake D0/R0 microcode update
regression, as disclosed by Intel.

Problem Statement:
  Intel has identified an issue when performing OS patch loading of
  MCU version 0xE2 on SKL R0 (506e3) and SKL D0 (406e3) systems when
  the existing Microcode Update (MCU) version is earlier than 0x80

Issue description:
  When an OS loads the latest MCU patches on SKL R0 (506e3) and SKL
  D0 (406e3), may lead to unexpected failures in the following
  conditions:

  * The system has a BIOS containing MCU version earlier than 0x80
(MCU < 0x80)
  * The user tries to load via OS load mechanism a new MCU version
0xD8 or greater

Workaround:
  Update affected systems to a BIOS containing MCU version 0x80 or
  greater.

A few other regressions might exist, but the situation there is either
unclear thus far, or appear to be restricted to specific systems where
the vendor likely did something unconvencional in their firmware.

Debdiff does not work well with intel-microcode due to symlinks, so I
used git diff (attached).

Diffstat (from git diff):
 b/README.md|  106 +++
 b/changelog|   60 
 b/debian/changelog |   87 ++
 b/debian/intel-microcode.docs  |3 
 b/intel-ucode/06-3f-02 |binary
 b/intel-ucode/06-4e-03 |binary
 b/intel-ucode/06-55-03 |binary
 b/intel-ucode/06-55-04 |binary
 b/intel-ucode/06-55-06 |binary
 b/intel-ucode/06-55-07 |binary
 b/intel-ucode/06-55-0b |binary
 b/intel-ucode/06-5c-09 |binary
 b/intel-ucode/06-5c-0a |binary
 b/intel-ucode/06-5e-03 |binary
 b/intel-ucode/06-7a-01 |binary
 b/intel-ucode/06-7a-08 |binary
 b/intel-ucode/06-7e-05 |binary
 b/intel-ucode/06-8a-01 |binary
 b/intel-ucode/06-8e-09 |binary
 b/intel-ucode/06-8e-0a |binary
 b/intel-ucode/06-8e-0b |binary
 b/intel-ucode/06-8e-0c |binary
 b/intel-ucode/06-9e-09 |binary
 b/intel-ucode/06-9e-0a |binary
 b/intel-ucode/06-9e-0b |binary
 b/intel-ucode/06-9e-0c |binary
 b/intel-ucode/06-9e-0d |binary
 b/intel-ucode/06-a5-02 |binary
 b/intel-ucode/06-a5-03 |binary
 b/intel-ucode/06-a5-05 |binary
 b/intel-ucode/06-a6-00 |binary
 b/intel-ucode/06-a6-01 |binary
 b/releasenote.md   |  536 +
 b/s000406E3_m00C0_r00D6.fw |binary
 b/s000506E3_m0036_r00D6.fw |binary
 releasenote|   96 --
 36 files changed, 791 insertions(+), 97 deletions(-)

Thank you!

-- 
  Henrique Holschuh
diff --git a/README.md b/README.md
new file mode 100644
index 000..47e49c4
--- /dev/null
+++ b/README.md
@@ -0,0 +1,106 @@
+# Intel Processor Microcode Package for Linux
+
+## About
+
+The Intel Processor Microcode Update (MCU) Package provides a mechanism to release updates for security advisories and functional issues, including errata. In addition, MCUs are responsible for starting the SGX enclave (on processors that support the SGX feature), implementing complex behaviors (such as assists), and more. The preferred method to apply MCUs is using the system BIOS. For a subset of Intel's processors, the MCU can also be updated at runtime using the operating system. The Intel Microcode Package shared here contains updates for those processors that support OS loading of MCUs.
+
+## Why update the microcode?
+Updating your microcode can help to mitigate certain potential security vulnerabilities in CPUs as well as address certain functional issues that could, for example, result in 

Bug#980777: FIT-PC: Fails to find driver for Ethernet, Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI

[John Paul Adrian Glaubitz]

Hi!

On 1/24/21 4:50 PM, Andrew M.A. Cater wrote:
> OK. This might be a bug in the i386 iso - as you've seen, we can't test all
> i386 easily. This might just be a regression. Given that we're about to 
> release
> 10.8 on Feb 6th, can I suggest that you send a mail into debian-boot
> (or debian cd) referencing the bug number and including the syslog entries 
> above.

FWIW, I recently installed the 10.7 i386 non-free netinst ISO on an old JVC
sub-notebook with a Pentium M CPU and Realtek 8139 ethernet card and had no
issues with that card during installation.

What actually caused problems was establishing a WiFi connection during 
installation
with the Intel 2200BG wireless adapter - which is why I used the ethernet 
network
connection during install.

After installation, everything worked correctly out of the box, however (lspci 
below).

Adrian

root@jvc-mini:~# lspci
00:00.0 Host bridge: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to 
I/O Controller (rev 02)
00:00.1 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV 
Processor to I/O Controller (rev 02)
00:00.3 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV 
Processor to I/O Controller (rev 02)
00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated 
Graphics Device (rev 02)
00:02.1 Display controller: Intel Corporation 82852/855GM Integrated Graphics 
Device (rev 02)
00:1d.0 USB controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) 
USB UHCI Controller #1 (rev 03)
00:1d.1 USB controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) 
USB UHCI Controller #2 (rev 03)
00:1d.2 USB controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) 
USB UHCI Controller #3 (rev 03)
00:1d.7 USB controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI 
Controller (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 83)
00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge 
(rev 03)
00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 
03)
00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM 
(ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 03)
00:1f.6 Modem: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 
Modem Controller (rev 03)
01:03.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ac)
01:03.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ac)
01:03.2 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller (rev 04)
01:04.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL-8100/8101L/8139 PCI Fast Ethernet Adapter (rev 10)
01:05.0 Network controller: Intel Corporation PRO/Wireless 2200BG [Calexico2] 
Network Connection (rev 05)
root@jvc-mini:~#

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#980961: O: fbxkb -- X11 keyboard indicator and switcher

[Baptiste Beauplat]

Package: wnpp

The current maintainer of fbxkb, Dmitry Borisyuk ,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: fbxkb
Binary: fbxkb
Version: 0.6-2.1
Maintainer: Dmitry Borisyuk 
Build-Depends: debhelper (>= 9), libgtk2.0-dev, libxmu-dev, 
libgdk-pixbuf-xlib-2.0-dev
Architecture: any
Standards-Version: 3.9.6
Format: 3.0 (quilt)
Files:
 1112ab3c0a2ebb6ca1ac2b8f8c42ac1b 1719 fbxkb_0.6-2.1.dsc
 fa768bbb07aac8a4ae590633499cce15 42319 fbxkb_0.6.orig.tar.gz
 55b0267deaeb4893cd53e5db56e84194 6612 fbxkb_0.6-2.1.debian.tar.xz
Checksums-Sha256:
 5ebeea2e2f49a0c65a5265f98daf03487e6acd3d50441bbed956fcb3dd77f135 1719 
fbxkb_0.6-2.1.dsc
 fcbaf4ed9a70f58ea1316b19da74e2ca8b3fb0e2de5a73c849317589ce840ef2 42319 
fbxkb_0.6.orig.tar.gz
 018dd5694ce33cd31a31dc1906ad54996540bdae13b73cc02c10769e7e3ad70b 6612 
fbxkb_0.6-2.1.debian.tar.xz
Homepage: http://fbxkb.sourceforge.net
Package-List: 
 fbxkb deb x11 optional arch=any
Directory: pool/main/f/fbxkb
Priority: source
Section: x11

Package: fbxkb
Version: 0.6-2.1
Installed-Size: 135
Maintainer: Dmitry Borisyuk 
Architecture: amd64
Depends: libc6 (>= 2.7), libgdk-pixbuf-2.0-0 (>= 2.22.0), libglib2.0-0 (>= 
2.16.0), libgtk2.0-0 (>= 2.24.0), libx11-6
Description: X11 keyboard indicator and switcher
Description-md5: 515aa5f18720d9ead876c644891e941f
Homepage: http://fbxkb.sourceforge.net
Tag: uitoolkit::gtk
Section: x11
Priority: optional
Filename: pool/main/f/fbxkb/fbxkb_0.6-2.1_amd64.deb
Size: 40252
MD5sum: 17940ec468bf9781d68076b736f48e97
SHA256: 253e3c8090385a37e1095e847e958b6fc60dd0bfae0a3344b2a7d97d917ebf59


-- 
Baptiste Beauplat - lyknode


signature.asc
Description: PGP signature

Bug#980960: O: wsl -- Wsman Shell Command Line "whistle"

[Baptiste Beauplat]

Package: wnpp

The current maintainer of wsl, Daniel Jared Dominguez 
,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: wsl
Binary: wsl
Version: 0.2.1-1.1
Maintainer: Daniel Jared Dominguez 
Build-Depends: debhelper (>= 8.0.0)
Architecture: all
Standards-Version: 3.9.2
Format: 3.0 (quilt)
Files:
 31158a220a88b37bf6e35f637268f966 1685 wsl_0.2.1-1.1.dsc
 b48dd06820f3a0999fecdb2e53da4f9b 16973 wsl_0.2.1.orig.tar.gz
 c75592d65dfeeade0517c20bd039c11d 3916 wsl_0.2.1-1.1.debian.tar.xz
Checksums-Sha256:
 64c3eff47d2f957054af6c141104acb80d5b7c55718e6c6ebd31ef628b626898 1685 
wsl_0.2.1-1.1.dsc
 45fc8f9fde277508eab3cf0d1270abdb08e45b4f517c5fb40bb86a93433518a5 16973 
wsl_0.2.1.orig.tar.gz
 9b83317a65dc2247506935341158063af618fc8d1af4f8bf68bb7be07a742f26 3916 
wsl_0.2.1-1.1.debian.tar.xz
Homepage: http://linux.dell.com/files/wsl/
Package-List: 
 wsl deb admin optional arch=all
Directory: pool/main/w/wsl
Priority: source
Section: misc

Package: wsl
Version: 0.2.1-1.1
Installed-Size: 105
Maintainer: Daniel Jared Dominguez 
Architecture: all
Depends: wget (>= 1.13) | curl, libxml2-utils
Recommends: xsltproc, gnupg, curl
Description: Wsman Shell Command Line "whistle"
Description-md5: 9b0a82cf07de44ae3fa1380f1b14f273
Homepage: http://linux.dell.com/files/wsl/
Section: admin
Priority: optional
Filename: pool/main/w/wsl/wsl_0.2.1-1.1_all.deb
Size: 18020
MD5sum: b48a2381dff06f9666f4b86adad22deb
SHA256: 3e7dc04a98d503154f3f46a5cdc7049cc03e659ac163c4ca741818fe7392a724


-- 
Baptiste Beauplat - lyknode


signature.asc
Description: PGP signature

Bug#979422: Proposed step-by-step logic

[Adam Lackorzynski]

Hi,

I improved the handling in minicom upstream to consider this case.
Still, minicom creates the lockfile such that it is readable by
everyone. In your case, has the lockfile been created by minicom or
someone else?



Adam

Bug#980959: O: maildirsync -- simple and efficient Maildir synchronisation utility

[Baptiste Beauplat]

Package: wnpp

The current maintainer of maildirsync, Carlos Alberto Silombria Ibarra 
,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: maildirsync
Binary: maildirsync
Version: 1.2-2.3
Maintainer: Carlos Alberto Silombria Ibarra 
Build-Depends: debhelper (>= 9), perl, quilt
Architecture: all
Standards-Version: 3.9.5
Format: 3.0 (quilt)
Files:
 ff13c02bb234c18855755fceeeca9ed4 1755 maildirsync_1.2-2.3.dsc
 02b70cfb94c0086d663d5e7d20de38bc 18077 maildirsync_1.2.orig.tar.gz
 2e193fc3115d96c693946038a3ed5c1f 4940 maildirsync_1.2-2.3.debian.tar.xz
Checksums-Sha256:
 85f981622ef2fbe13e6ae790cbc37f86df85396ed039be3364003810051cda57 1755 
maildirsync_1.2-2.3.dsc
 0cf81df1b0cb0f531bc69bd09a3ab9b5e88f572163c9ce5cdf3cd98d2ff0027f 18077 
maildirsync_1.2.orig.tar.gz
 fe0b516a39da0021ea76a7b419ab94bc6ef4e66164713367107fac97ad329bdd 4940 
maildirsync_1.2-2.3.debian.tar.xz
Homepage: http://code.google.com/p/maildirsync/
Package-List: 
 maildirsync deb mail optional arch=all
Directory: pool/main/m/maildirsync
Priority: source
Section: mail

Package: maildirsync
Version: 1.2-2.3
Installed-Size: 54
Maintainer: Carlos Alberto Silombria Ibarra 
Architecture: all
Depends: perl (>= 5.006)
Recommends: ssh | rsh-client
Suggests: bzip2
Description: simple and efficient Maildir synchronisation utility
Description-md5: c580e55f172ea03ecabf7a462710ac8c
Homepage: http://code.google.com/p/maildirsync/
Tag: implemented-in::perl, interface::commandline, role::program,
 scope::utility, use::synchronizing, works-with::mail
Section: mail
Priority: optional
Filename: pool/main/m/maildirsync/maildirsync_1.2-2.3_all.deb
Size: 23828
MD5sum: de00725c4c15b8ce7a84607b56ce6fd6
SHA256: 972e9db9dff83c3ecaf934add5b0fea400c99660d10fa208f603e5fa91e90b5e


-- 
Baptiste Beauplat - lyknode


signature.asc
Description: PGP signature

Bug#979641: src:kboot-utils: invalid maintainer address

[Baptiste Beauplat]

Hi Antonio,

kboot-utils, one of the packages you maintain in Debian has an old, unreachable
Maitainer address. Could you please update it to prevent it from getting
removed?

See below the original bug report.

Best,

On 2021/01/09 06:04 PM, Ansgar wrote:
> Source: kboot-utils
> Version: 0.4-1
> Severity: serious
> Tags: bullseye sid
> X-Debbugs-Cc: Holger Levsen 
> 
> The maintainer address is invalid, see below.
> 
> Ansgar
> 
>  Start of forwarded message 
> From: Mail Delivery System 
> Subject: Mail delivery failed: returning message to sender
> Date: Sat, 09 Jan 2021 16:49:56 +
> 

> This message was created automatically by mail delivery software.
> 
> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es) failed:
> 
>   osp...@studenti.unina.it
> host fmvip.unina.it [192.132.34.7]
> SMTP error from remote mail server after RCPT 
> TO::
> 550 5.1.1 ... User unknown

> Reporting-MTA: dns; muffat.debian.org
> 
> Action: failed
> Final-Recipient: rfc822;osp...@studenti.unina.it
> Status: 5.0.0
> Remote-MTA: dns; fmvip.unina.it
> Diagnostic-Code: smtp; 550 5.1.1 ... User unknown



-- 
Baptiste Beauplat - lyknode


signature.asc
Description: PGP signature

Bug#978079: heads up: rapid-photo-downloader might not make it to bullseye

[Antoine Beaupré]

On 2021-01-24 14:59:03, Antoine Beaupré wrote:
> Hi,
>
> It seems like rapid-photo-downloader will not make it into the next
> Debian stable release (bullseye). It depends on "rawkit" (which I happen
> to maintain for some reason), and *that* package fails with newer libraw
> versions:
>
> https://bugs.debian.org/978079
>
> I'm not sure how to fix this, and I don't have the cycles to do so right
> now. But since you're the RPD maintainer, I figured you might have extra
> motivation to fix this... Otherwise I'm afraid we won't be able to ship
> RPD with Debian starting with bullseye, which would really be a shame...
>
> It might be worth bringing this up with upstream as well, if you can
> find the time...

Actually, I just found out that there's an active fork which fixes those
problems, called rawpy:

https://discuss.pixls.us/t/rawkit-unmaintained-path-forward-for-rapid-photo-downloader/14299

There's a patch in Arch to port rawkit to libraw19, but I feel it would
be ill-advised to carry such a hack through a stable Debian release.

So I think the way forward for RPD is to package rawpy, remove rawkit,
and have RPD depend on rawpy. I don't have time to do this work myself
and, since RPD is the only thing that needs rawkit in Debian, I would
suggest you take on the dependency as well.

Unfortunately, this would need to happen in the coming week, otherwise
we'll miss the NEW window before the soft freeze (2021-02-12). Do you
have time to deal with this until then?

Thanks,

a.

-- 
The flesh you so fancifully fry
Is not succulent, tasty or kind
It's death for no reason
And death for no reason is murder
- Morrissey

Bug#978650: podman: please provide a default container registry for looking up short image names

[Reinhard Tartler]

On Sun, Jan 24, 2021 at 9:12 AM Reinhard Tartler  wrote:

>
>
> On Sun, Jan 24, 2021 at 7:54 AM Shengjing Zhu  wrote:
>
>> On Sun, Jan 24, 2021 at 8:44 PM Reinhard Tartler 
>> wrote:
>> >
>> > Context is what version of podman to ship in Debian bullseye
>> [...]
>> >
>> > One could be to let's go straight for podman 3.0. Since Debian is going
>> to have a
>> > hard-freeze on 2021-03-12, that's kind of tight, but if doable if we
>> collaborate.
>> > There are a couple of dependencies that we need to update in
>> experimental and I would
>> > really appreciate help with it.
>>
>> If I read the freeze policy correctly, the new version should be in
>> time before soft-freeze(aka 2021-2-12)?
>> It seems upstream has released 3.0.0-rc1 already. So if you want 3.0
>> to be in bullseye, a good start might be uploading 3.0.0~rc1 to
>> experimental first, then talk to the release team?
>>
>
> That sounds like a good plan. It also looks like the required
> updates to containers/* isn't as bad as I thought, I'm updating buildah
> right now, and see how much is missing for 3.0.0~rc1. If it is not, I'll
> upload to experimental and start that conversation.
>
>
ok, I managed to build 3.0.0~rc1 and even managed to use docker-compose
with it.
Things look promising! I've pushed my local branch to salsa at
https://salsa.debian.org/debian/libpod/-/tree/experimental and plan to
upload
to experimental later today.

-- 
regards,
Reinhard

Bug#978079: heads up: rapid-photo-downloader might not make it to bullseye

[Antoine Beaupré]

Hi,

It seems like rapid-photo-downloader will not make it into the next
Debian stable release (bullseye). It depends on "rawkit" (which I happen
to maintain for some reason), and *that* package fails with newer libraw
versions:

https://bugs.debian.org/978079

I'm not sure how to fix this, and I don't have the cycles to do so right
now. But since you're the RPD maintainer, I figured you might have extra
motivation to fix this... Otherwise I'm afraid we won't be able to ship
RPD with Debian starting with bullseye, which would really be a shame...

It might be worth bringing this up with upstream as well, if you can
find the time...

a.
-- 
Advertisers, not governments, are the primary censors of media content 
in the United States today.
- C. Edwin Baker

Bug#967170: markupsafe: Unversioned Python removal in sid/bullseye

[Stephen Kitt]

Control: fixed -1 1.1.1-1
Control: close -1

On Sun, Jan 24, 2021 at 09:12:04AM +0100, Jann Haber wrote:
> fixed -1 1.1.1-1
> close -1
> thanks
> 
> Looking at the package, it seems like this bug has been fixed in version 
> 1.1.1-1 - I can find no more references to unversioned python in that 
> version. I marked the bug as fixed. Please re-open if I am mistaken.
> 
> Best,
> Jann
> 
> On Tue, 04 Aug 2020 09:28:33 + Matthias Klose  wrote:
> > Package: src:markupsafe
> > Version: 1.1.1-1
> > Severity: serious
> > Tags: sid bullseye
> > User: debian-pyt...@lists.debian.org
> > Usertags: py2unversioned
> > 
> > Python2 becomes end-of-live upstream, and Debian aims to remove
> > Python2 from the distribution, as discussed in
> > https://lists.debian.org/debian-python/2019/07/msg00080.html
> > 
> > We will keep some Python2 package as discussed in
> > https://lists.debian.org/debian-python/2020/07/msg00039.html
> > but removing the unversioned python packages python-minimal, python,
> > python-dev, python-dbg, python-doc.
> > 
> > Your package either build-depends, depends on one of those packages.
> > Please either convert these packages to Python3, or if that is not
> > possible, replaces the dependencies on the unversioned Python
> > packages with one of the python2 dependencies (python2, python2-dev,
> > python2-dbg, python2-doc).
> > 
> > Please check for dependencies, build dependencies AND autopkg tests.
> > 
> > If there are questions, please refer to the wiki page for the removal:
> > https://wiki.debian.org/Python/2Removal, or ask for help on IRC
> > #debian-python, or the debian-pyt...@lists.debian.org mailing list.
> > 
> > 


signature.asc
Description: PGP signature

Bug#980777: FIT-PC: Fails to find driver for Ethernet, Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI

[Charles Curley]

On Sun, 24 Jan 2021 15:50:54 +
"Andrew M.A. Cater"  wrote:

> These are the machines with Geode but limited to 256M memory? As a
> matter of interest, what are you using them for - what's the use case
> - because 256M is marginal now, I think.

It's actually 223M, the remainder used for the video memory.

Use case is that I have four of them. Two, grissom and white, are for
testing. I have a SOHO network here, with three computers that get
daily use, and a few others, older ones, as spares.

chaffee: apcupsd server for several computers, local mail collector for
logwatch and other admin emails, gitolite server, apt-cacher-ng for
ubuntu, dns (bind9) and dhcp server.

freeman: firewall/router, apt-cacher-ng for debian, ntp server, openvpn
server, failover DNS and DHCP servers.

The gitolite server could be faster, otherwise they do just fine, and
have been since 2007 or so.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Bug#980726: Seeing this too

[Helge Kreutzmann]

Hello Axel,
On Sun, Jan 24, 2021 at 08:44:11PM +0100, Axel Beckert wrote:
> Helge Kreutzmann wrote:
> > And on this day gpm was updated in Testing (which I run).
> 
> I uploaded the fix with urgency=high so that it should migrate quickly
> to testing. It's tested on a easy to reboot Debian Sid installation on
> Raspberry Pi which I switched between systemd and sysvinit several
> times while testing.

Didn't know that sysvinit was still possible to use, but probably a
rather stripped down systen.

Thanks for fixing!

Greetings

 Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#968857: marked as pending in prometheus-blackbox-exporter

[Helge Kreutzmann]

Hello Daniel,
On Sun, Jan 24, 2021 at 07:25:34PM +0100, Daniel Swarbrick wrote:
> On 24.01.21 18:30, Helge Kreutzmann wrote:
> > 
> > And you removed the fuzzy mark as well? The grammar fix only applies
> > to the original.
> > 
> > If you feel uncomfortable editing po files you can provide them to me
> > and I can do it for you.
> 
> I'm not sure exactly which fuzzy mark you are referring to. Can you be more
> specific? Maybe check the source in salsa yourself, if open a merge request
> if something is still outstanding -
> https://salsa.debian.org/go-team/packages/prometheus-blackbox-exporter
> 
> I applied the grammar fix to the English strings in the German / French /
> Dutch translations, since downstream translations should obviously match the
> upstream original (usually English) text.

Ok, you have an usual work flow, but the result is fine.

The ordinary workflow is to update the templates, then run
debconf-updatepo. In the result, all changed strings become "fuzzy",
i.e. the word "fuzzy" is printed in the file and the translation won't
be used.

Then the translator(s) would check the changes and align the
translation. However, since you knew that the change in the original
template does not affect the translation, your approach is equally
valid.

Thanks for taking care and excuse my insistance, I've seen maintainers
do strange things and the freeze is rapidly approaching.

Greetings

Helge


-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#978079: python3-rawkit: Support for libraw20 missing

[Antoine Beaupré]

Control: forward -1 https://github.com/photoshell/rawkit/issues/155
Control: tags -1 +confirmed

On 2020-12-25 16:58:42, Kendy Kutzner wrote:
> sudo aptitude install libraw20 python3-rawkit
> python3
 from rawkit.raw import Raw
 r=Raw(filename='1608680820.cr2')
> [...]
> ImportError: Unsupported Libraw version: 0.20.2.
>
> I'm using bullseye/sid.

Unfortunately, not only does it look like an upstream issue with no fix,
but worse, it seems like upstream is dead. Or at least, the git
repository is "archived":

https://github.com/photoshell/rawkit/

... not sure what to make of this :(

a.

-- 
By now the computer has moved out of the den and into the rest of your
life. It will consume all of your spare time, and even your vacation,
if you let it. It will empty your wallet and tie up your thoughts. It
will drive away your family. Your friends will start to think of you
as a bore. And what for?
   - The True Computerist by Tom Pittman

Bug#980958: O: renrot -- Rename and rotate files according to EXIF tags

[Baptiste Beauplat]

Package: wnpp

The current maintainer of renrot, Andy Shevchenko ,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: renrot
Binary: renrot
Version: 1.2.0-0.3
Maintainer: Andy Shevchenko 
Build-Depends: debhelper (>= 5), libimage-exiftool-perl (>= 5.72)
Architecture: all
Standards-Version: 3.7.2
Format: 1.0
Files:
 8d86cf3f18e3002e47f4adfac5926789 1662 renrot_1.2.0-0.3.dsc
 0d0da175e4e7ef209322ad303ad217b9 52817 renrot_1.2.0.orig.tar.gz
 19e669be3b71d793a12826db5fa7390a 5733 renrot_1.2.0-0.3.diff.gz
Checksums-Sha256:
 03cc00172466e28ce6a13653db7c0e553c9b2eeb8324819119acf1efc7b2efd8 1662 
renrot_1.2.0-0.3.dsc
 a3f711787422292693238579a2c139e8ac6367e099ada0815b6b050385f886ae 52817 
renrot_1.2.0.orig.tar.gz
 eac4d783a40cc5054d893d3082d1088dffcfa26907e8c1857a566b48fe489943 5733 
renrot_1.2.0-0.3.diff.gz
Package-List: 
 renrot deb graphics optional arch=all
Directory: pool/main/r/renrot
Priority: source
Section: graphics

Package: renrot
Version: 1.2.0-0.3
Installed-Size: 178
Maintainer: Andy Shevchenko 
Architecture: all
Depends: perl:any, libimage-exiftool-perl (>= 5.72), libjpeg-progs
Suggests: libimage-magick-perl
Description: Rename and rotate files according to EXIF tags
Description-md5: 94ef78f3791efeb8aa581de9cc25aada
Tag: hardware::camera, implemented-in::perl, interface::commandline,
 role::program, scope::utility, use::converting, use::organizing,
 works-with-format::jpg, works-with::image, works-with::image:raster
Section: graphics
Priority: optional
Filename: pool/main/r/renrot/renrot_1.2.0-0.3_all.deb
Size: 61476
MD5sum: ed06eb5bd7411602e6bcd3b617e8c743
SHA256: 419b0002cf7e6ba1babdde6bc05243ad9c1323ad04210d9483dfdeb8bc8eb96e


-- 
Baptiste Beauplat - lyknode


signature.asc
Description: PGP signature

Bug#980726: Seeing this too

[Axel Beckert]

Hi Helge,

Helge Kreutzmann wrote:
> And on this day gpm was updated in Testing (which I run).

I uploaded the fix with urgency=high so that it should migrate quickly
to testing. It's tested on a easy to reboot Debian Sid installation on
Raspberry Pi which I switched between systemd and sysvinit several
times while testing.

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#980957: llvm-toolchain-11 autopkgtest segfaults on armhf

[Paul Gevers]

Source: llvm-toolchain-11
Version: 1:11.0.0-2
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainers,

You package has an autopkgtest, great. However, it fails on armhf with a
segfault.

The error code is unfortunate as autopkgtest interprets it as a tmpfail,
so the test is tried over and over again. I'll put the failure on the
ci.d.n blocklist, to avoid that, and will lift the block when this bug
is closed.

Paul

https://ci.debian.net/data/autopkgtest/testing/armhf/l/llvm-toolchain-11/9960854/log.gz

echo '#include 
int main() {
if (1==1) {
  printf("true");
}else{
  printf("false");
  return 42;
}
return 0;}' > foo.c
Testing linking ...
rm foo bar.cc

clang-$VERSION -flto foo.c -o foo
clang: error: unable to execute command: Segmentation fault
clang: error: linker command failed due to signal (use -v to see invocation)
autopkgtest [02:17:39]: ERROR: testbed failure: testbed auxverb failed
with exit code 254



OpenPGP_signature
Description: OpenPGP digital signature

Bug#975389: Review of dpf-plugins RFS

[Dennis Braun]

Hi Ross,

thanks a lot for the review.

I uploaded a new version, and i think i fixed all problems, hopefully.

Best regards,
Dennis

Am 23.01.21 um 18:22 schrieb Ross Gammon:

tag 975389 + moreinfo
owner 975389 !
thanks

Hi Dennis,

Thanks for packaging dpf-plugins for Debian. Here is a review:

Need fixing:
d/changelog:
1. This is the initial release in Debian, so the the changelog should be
empty except for the "Initial debian release (Closes: #953129)" entry.
The earlier packaging work for KXStudio & Ubuntu is at least credited in
d/copyright.

d/copyright:
2. The distrho/extra plugins seem to be using the ISC license (not
GPL2+), or at least that is the case for Thread.hpp.
3. dpf/distrho/extra/String.hpp has "Copyright (C) 2004-2008 René
Nyffenegger", and Rene is not listed at all in d/copyright.
4. I stopped checking the d/copyright file here. I recommend a thorough
check of d/copyright to ensure the package passes smoothly through the
ftp-master review.

Minor/optional stuff:
5. d/dpf-plugins-vst.lintian-overrides (and for the lv2, ladspa & dssi
packages):
"splitted" is not grammatically correct, and the lintian output should
not be overriden, but a patch sent upstream. "3 Band Equalizer, split
output version" would be better.
6. dpf-plugins-common emits a lintian warning about "no-manual-page" for
the binaries. I tried a couple of them and they seem to open gui's and
the normal -h & -v options do nothing. Maybe we could check the others
and override the warning?

Other comments:
7. I see version 1.4 is now available upstream. If you prefer, we could
update to a full release rather than the "1.3 plus git commit" we have
at the moment.

I would be happy to upload with at least the first four comments fixed!

Regards,

Ross
FBEE 0190 904F 1EA0 BA6A  300E 53FE 7BBD A689 10FC

Bug#969361: error installing 'clevis-decrypt-http'

[Christoph Biedl]

Control: tags 969361 confirmed
Control: fixed 969361 12-1
Control: severity 969361 important

Anton Lundin wrote...

> dracut: Generating /boot/initrd.img-4.19.0-10-amd64
> dracut-install: ERROR: installing 'clevis-decrypt-http'
(...)

Thanks for catching this, also for your patience. I have no idea how
that passed through all checks back then during the buster freeze, but
it happened.

Now I'd like to fix this in the upcoming stable point release, just one
question: In my test setup I needed to add "--install /sbin/cryptsetup"
to the dracut invocation to make automatic unlocking pass. Did you need
that on your side as well, on can you think of other explanations? FWIW,
my test setup is already migrated to usrmerge.

Christoph


signature.asc
Description: PGP signature

Bug#967686: [Pkg-lxde-maintainers] Bug#967686: pcmanfm: depends on deprecated GTK 2

[Mateusz Łukasik]

On 24.01.2021 at 12:05 +0100, Alexis PM wrote:

Associated bug that could provide a solution:

https://bugs.debian.org/839013

It is not solution for Debian. Lxde just needs rebuild with gtk3 libs, it'senough for fix this bug. I will do NMU after bullseye release if 
maintainer won't do it.   
--

.''`.  Mateusz Łukasik
: :' :  l0calh0st.pl
`. `'   Debian Member - mat...@linuxmint.pl
  `-GPG: D93B 0C12 C8D0 4D7A AFBC  FA27 CCD9 1D61 11A0 6851

Bug#980956: r-cran-magrittr breaks r-cran-dbplyr autopkgtest: could not find function "split_chain"

[Paul Gevers]

Source: r-cran-magrittr, r-cran-dbplyr
Control: found -1 r-cran-magrittr/2.0.1-1
Control: found -1 r-cran-dbplyr/1.4.4-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update
Control: block 980851 by -1

Dear maintainer(s),

With a recent upload (62 days ago) of r-cran-magrittr the autopkgtest of
r-cran-dbplyr fails in testing when that autopkgtest is run with the
binary packages of r-cran-magrittr from unstable. It passes when run
with only packages from testing. In tabular form:

   passfail
r-cran-magrittrfrom testing2.0.1-1
r-cran-dbplyr  from testing2.0.0-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of r-cran-magrittr
to testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=r-cran-magrittr

https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-dbplyr/9966925/log.gz
autopkgtest [08:12:46]: test run-unit-test: [---
BEGIN TEST testthat.R

R version 4.0.3 (2020-10-10) -- "Bunny-Wunnies Freak Out"
Copyright (C) 2020 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

> library(testthat)
> library(dbplyr)
>
> test_check("dbplyr")
Registering testing src: sqlite OK
══ Skipped tests
═══
● identical(Sys.getenv("GITHUB_POSTGRES"), "true") is not TRUE (1)
● Need at least two srcs to compare (6)
● No MariaDB (3)
● No mssql (2)
● No postgres (2)
● On CRAN (60)

══ Failed tests

── Error (test-translate-sql.R:75:3): magrittr pipe is translated
──
Error: could not find function "split_chain"
Backtrace:
 █
  1. ├─testthat::expect_identical(translate_sql(1 %>% is.na()),
translate_sql(is.na(1))) test-translate-sql.R:75:2
  2. │ └─testthat::quasi_label(enquo(object), label, arg = "object")
  3. │   └─rlang::eval_bare(expr, quo_get_env(quo))
  4. ├─dbplyr::translate_sql(1 %>% is.na())
  5. │ └─dbplyr::translate_sql_(...)
  6. │   └─base::lapply(...)
  7. │ └─dbplyr:::FUN(X[[i]], ...)
  8. │   ├─dbplyr::escape(eval_tidy(x, mask), con = con)
  9. │   └─rlang::eval_tidy(x, mask)
 10. └─1 %>% is.na()

[ FAIL 1 | WARN 0 | SKIP 74 | PASS 662 ]
Error: Test failures
Execution halted
autopkgtest [08:13:01]: test run-unit-test: ---]






OpenPGP_signature
Description: OpenPGP digital signature

Bug#980954: O: microdc2 -- command-line based Direct Connect client

[Baptiste Beauplat]

Package: wnpp

The current maintainer of microdc2, Al Nikolov ,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: microdc2
Binary: microdc2
Version: 0.15.6-4
Maintainer: Al Nikolov 
Build-Depends: debhelper (>= 9), dh-autoreconf, libreadline-dev, libxml2-dev 
(>= 2.6.16), libbz2-dev
Architecture: any
Standards-Version: 3.9.8
Format: 3.0 (quilt)
Files:
 455b429aee09d7703b7040e33f831fe3 1763 microdc2_0.15.6-4.dsc
 9175a7463936fe89e2e22c8ae2f5e020 639392 microdc2_0.15.6.orig.tar.gz
 761eb37fe6df561c1a41b999a095f8c1 11348 microdc2_0.15.6-4.debian.tar.xz
Checksums-Sha256:
 5af34d0defbf7f210125f79946f432dcbcc3e7654e3ca53beae20e9a793b0ce6 1763 
microdc2_0.15.6-4.dsc
 d1990eb1aa52115c649466011c8163e454272250b041e480f0a521212c04bc49 639392 
microdc2_0.15.6.orig.tar.gz
 dddf0b948af2b4abec56efc85bec5de94c2aa6aeb8a007a61f0b5a5560f44a0f 11348 
microdc2_0.15.6-4.debian.tar.xz
Homepage: http://corsair626.no-ip.org/microdc/
Package-List: 
 microdc2 deb net extra arch=any
Directory: pool/main/m/microdc2
Priority: source
Section: net

Package: microdc2
Source: microdc2 (0.15.6-4)
Version: 0.15.6-4+b2
Installed-Size: 366
Maintainer: Al Nikolov 
Architecture: amd64
Depends: libbz2-1.0, libc6 (>= 2.15), libreadline8 (>= 6.0), libxml2 (>= 2.7.4)
Description: command-line based Direct Connect client
Description-md5: 454b3f84a166af636585c3bbf95f4a30
Homepage: http://corsair626.no-ip.org/microdc/
Tag: implemented-in::c++, interface::text-mode, network::client,
 network::server, protocol::dcc, role::program, scope::application,
 use::chatting, use::downloading, use::searching
Section: net
Priority: optional
Filename: pool/main/m/microdc2/microdc2_0.15.6-4+b2_amd64.deb
Size: 139404
MD5sum: 0f45a791574e060198a9f3ad0c915d3d
SHA256: 889bbf0ffadec40a10f6205fd62527d05f285e332bda33ff9d6da15745fd4ae5


-- 
Baptiste Beauplat - lyknode


signature.asc
Description: PGP signature

Bug#980955: O: proxycheck -- checks existence of open proxy

[Baptiste Beauplat]

Package: wnpp

The current maintainer of proxycheck, Al Nikolov ,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: proxycheck
Binary: proxycheck
Version: 0.49a-5
Maintainer: Al Nikolov 
Build-Depends: debhelper (>= 9)
Architecture: any
Standards-Version: 3.9.8
Format: 3.0 (quilt)
Files:
 54cc8cab2737ed9796773c3e523b93cd 1703 proxycheck_0.49a-5.dsc
 5121f100ca36c7afbb7e3f48eafdf0d5 38879 proxycheck_0.49a.orig.tar.gz
 dff4afa70038af5020b85c67357a60b8 4284 proxycheck_0.49a-5.debian.tar.xz
Checksums-Sha256:
 15f92b297a1b32a9f0ea19193bc138243072c23cea154c1a5b3bc1006439dbac 1703 
proxycheck_0.49a-5.dsc
 68dfcf9edc5d83625cead9ed643c75cfee502cc846d3cc2c1089e947f47bca81 38879 
proxycheck_0.49a.orig.tar.gz
 ffc5bd677c95f32fd721c51973a74fe04ea1fd7abf4b08fcc13141b36fbb465e 4284 
proxycheck_0.49a-5.debian.tar.xz
Homepage: http://www.corpit.ru/mjt/proxycheck.html
Package-List: 
 proxycheck deb net extra arch=any
Directory: pool/main/p/proxycheck
Priority: source
Section: net

Package: proxycheck
Source: proxycheck (0.49a-5)
Version: 0.49a-5+b1
Installed-Size: 76
Maintainer: Al Nikolov 
Architecture: amd64
Depends: libc6 (>= 2.15)
Description: checks existence of open proxy
Description-md5: b19705e1ce3bcf742de2e15ff63ad17a
Homepage: http://www.corpit.ru/mjt/proxycheck.html
Tag: implemented-in::c, interface::commandline, mail::TODO, role::program,
 scope::utility, security::TODO, use::checking
Section: net
Priority: optional
Filename: pool/main/p/proxycheck/proxycheck_0.49a-5+b1_amd64.deb
Size: 31312
MD5sum: b48697ed264cae08e87d7ea0cfb06e12
SHA256: e7bfc8ef074a6ba2328554f3d735578dea309635aa9cd3cd4cfdfefe5c52106a


-- 
Baptiste Beauplat - lyknode


signature.asc
Description: PGP signature

Bug#980953: O: libdbix-class-htmlwidget-perl -- DBIx::Class::HTMLWidget perl module

[Baptiste Beauplat]

Package: wnpp

The current maintainer of libdbix-class-htmlwidget-perl, Al Nikolov 
,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: libdbix-class-htmlwidget-perl
Binary: libdbix-class-htmlwidget-perl
Version: 0.16-5.1
Maintainer: Al Nikolov 
Build-Depends: debhelper (>= 10)
Build-Depends-Indep: perl (>= 5.8.8-7etch1)
Architecture: all
Standards-Version: 3.9.8
Format: 3.0 (quilt)
Files:
 e0a60951cf2ea95d4314c9a9304c7205 1952 
libdbix-class-htmlwidget-perl_0.16-5.1.dsc
 424fe83cd01c74456fb9804144051609 4223 
libdbix-class-htmlwidget-perl_0.16.orig.tar.gz
 3705ab047b11d55fa6c13afb216de053 3104 
libdbix-class-htmlwidget-perl_0.16-5.1.debian.tar.xz
Checksums-Sha256:
 d08b82606ad817d5ec4eb436e3b0de97db838455895666371332c67f3d8b3e0c 1952 
libdbix-class-htmlwidget-perl_0.16-5.1.dsc
 41427563216edf5a93965090ae0e1c85a95d37a81d720f02c1360cfa7db4f017 4223 
libdbix-class-htmlwidget-perl_0.16.orig.tar.gz
 f8ef69c88f422245bbb122deb87272be2bfb72886fc8b81f1e6fc933d8283be0 3104 
libdbix-class-htmlwidget-perl_0.16-5.1.debian.tar.xz
Homepage: http://search.cpan.org/~andremar/DBIx-Class-HTMLWidget/
Package-List: 
 libdbix-class-htmlwidget-perl deb perl optional arch=all
Directory: pool/main/libd/libdbix-class-htmlwidget-perl
Priority: source
Section: perl

Package: libdbix-class-htmlwidget-perl
Version: 0.16-5.1
Installed-Size: 26
Maintainer: Al Nikolov 
Architecture: all
Depends: libhtml-widget-perl (>= 1.10), libdbix-class-perl (>= 0.05), perl:any
Description: DBIx::Class::HTMLWidget perl module
Description-md5: 8fbf02f43f52fd95f81ae3d08be22d9a
Homepage: http://search.cpan.org/~andremar/DBIx-Class-HTMLWidget/
Tag: devel::lang:perl, devel::library, implemented-in::perl, role::devel-lib,
 web::cgi, works-with::db
Section: perl
Priority: optional
Filename: 
pool/main/libd/libdbix-class-htmlwidget-perl/libdbix-class-htmlwidget-perl_0.16-5.1_all.deb
Size: 9376
MD5sum: 27f68a7430bdbba4d725f43322f5
SHA256: c3cff25959fc5787670836793dfe68e8103e63cdb1859bfc7eda1aadad4e2a6f


-- 
Baptiste Beauplat - lyknode


signature.asc
Description: PGP signature

Bug#980952: O: goban -- Goban screensaver

[Baptiste Beauplat]

Package: wnpp

The current maintainer of goban, Al Nikolov ,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: goban
Binary: goban-ss, goban-original-games
Version: 1.1-5.1
Maintainer: Al Nikolov 
Build-Depends: debhelper (>= 9), autotools-dev, dh-autoreconf, libx11-dev
Architecture: any all
Standards-Version: 3.9.8
Format: 3.0 (quilt)
Files:
 f0c6e5a346134ec518dbd00c9882eb1a 1774 goban_1.1-5.1.dsc
 82b733b47a8ee5f3e8ab8cb78ea5d879 693480 goban_1.1.orig.tar.gz
 f5c67f22fe324df73ae02d77c3d75f39 6188 goban_1.1-5.1.debian.tar.xz
Checksums-Sha256:
 2463d75e0dd97203cf3874563f19a7179d1444a61347ce242f98502cb73a3391 1774 
goban_1.1-5.1.dsc
 0d8f35cdc075e79921c45f39a814c9d66f7cca26cc6ad6fcc7b75e7f5502 693480 
goban_1.1.orig.tar.gz
 65ac94309e15b865aa5ca3e91f8a065325aed807505b9102bf5fcdb2762e7fc7 6188 
goban_1.1-5.1.debian.tar.xz
Homepage: http://draves.org/goban/
Package-List: 
 goban-original-games deb x11 extra arch=all
 goban-ss deb x11 extra arch=any
Directory: pool/main/g/goban
Priority: source
Section: x11

Package: goban-ss
Source: goban
Version: 1.1-5.1
Installed-Size: 542
Maintainer: Al Nikolov 
Architecture: amd64
Depends: libc6 (>= 2.29), libx11-6
Recommends: goban-original-games, xscreensaver
Enhances: kscreensaver-xsavers
Description: Goban screensaver
Description-md5: 13cf305b448027d1b7f015a9686c19a3
Homepage: http://draves.org/goban/
Section: x11
Priority: optional
Filename: pool/main/g/goban/goban-ss_1.1-5.1_amd64.deb
Size: 209720
MD5sum: afa9d7c7c23bdaee2fc77b52da4d9f5e
SHA256: cad019ba92cfc00dc57d9f8e0d5ccca87d5d4aac334f5bc5bc64057fcb7019a7

Package: goban-original-games
Source: goban
Version: 1.1-5.1
Installed-Size: 1157
Maintainer: Al Nikolov 
Architecture: all
Recommends: goban-ss
Description: Original games set for the Goban screensaver
Description-md5: f30b11df760ad3c418fafdde2d56cafe
Homepage: http://draves.org/goban/
Section: x11
Priority: optional
Filename: pool/main/g/goban/goban-original-games_1.1-5.1_all.deb
Size: 197356
MD5sum: bd0f82d1a65f2becca5a9a0f4ed57bc7
SHA256: 73435aaf0edf85ccf90452859b446cb5063f014266723fc9effdda95ba4b44a2


-- 
Baptiste Beauplat - lyknode


signature.asc
Description: PGP signature

Bug#980951: erlang-ranch: FTBFS: ssl:cipher_suites/0 is deprecated

[Boyuan Yang]

Source: erlang-ranch
Severity: serious
Version: 1.3.0-2
X-Debbugs-CC: iwama...@debian.org t...@debian.org

Dear Debian erlang-ranch package maintainers,

Current erlang-ranch/1.3.0-2 fails to build from source. The main error
is as follows:


dh build
   dh_update_autotools_config
   dh_autoreconf
   dh_auto_configure
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
make SKIP_DEPS=yes
make[2]: Entering directory '/<>'
 DEPEND ranch.d
 ERLC   ranch.erl ranch_acceptor.erl ranch_acceptors_sup.erl
ranch_app.erl ranch_conns_sup.erl ranch_listener_sup.erl
ranch_protocol.erl ranch_server.erl ranch_ssl.erl ranch_sup.erl
ranch_tcp.erl ranch_transport.erl
compile: warnings being treated as errors
src/ranch_ssl.erl:237: ssl:cipher_suites/0 is deprecated and will be
removed in OTP 24; use use cipher_suites/2,3 instead
src/ranch_ssl.erl:239: ssl:cipher_suites/0 is deprecated and will be
removed in OTP 24; use use cipher_suites/2,3 instead
make[3]: *** [erlang.mk:5069: ebin/ranch.app] Error 1
make[2]: *** [erlang.mk:4872: app] Error 2
make[2]: Leaving directory '/<>'
make[1]: *** [debian/rules:10: override_dh_auto_build] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:7: build] Error 2
=


The full buildlog is provided in the attachment.

-- 
Thanks,
Boyuan Yang
sbuild (Debian sbuild) 0.80.1 (05 December 2020) on hosiet-vm-home

+==+
| erlang-ranch 1.3.0-2 (amd64) Sun, 24 Jan 2021 19:08:48 + |
+==+

Package: erlang-ranch
Version: 1.3.0-2
Source Version: 1.3.0-2
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: full

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/unstable-amd64-sbuild-a5d3c470-2e25-4528-a683-b7ddc3aaf012'
 with '<>'
I: NOTICE: Log filtering will replace 
'build/erlang-ranch-SNSq4k/resolver-4ZEvPD' with '<>'

+--+
| Update chroot|
+--+

Hit:1 https://incoming.debian.org/debian-buildd buildd-unstable InRelease
Hit:2 https://deb.debian.org/debian unstable InRelease
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

+--+
| Fetch source files   |
+--+


Local sources
-

/dev/shm/build-area/erlang-ranch_1.3.0-2.dsc exists in /dev/shm/build-area; 
copying to chroot
I: NOTICE: Log filtering will replace 
'build/erlang-ranch-SNSq4k/erlang-ranch-1.3.0' with '<>'
I: NOTICE: Log filtering will replace 'build/erlang-ranch-SNSq4k' with 
'<>'

+--+
| Install package build dependencies   |
+--+


Setup apt archive
-

Merged Build-Depends: debhelper (>= 11), dpkg-dev (>= 1.16.1~), erlang-dev (>= 
1:15.b), erlang-eunit (>= 1:15.b), erlang-edoc (>= 1:15.b), libxml2-utils, 
asciidoc, asciidoc-dblatex, docbook-xml, dblatex, docbook-xsl, 
erlang-asciideck, build-essential, fakeroot
Filtered Build-Depends: debhelper (>= 11), dpkg-dev (>= 1.16.1~), erlang-dev 
(>= 1:15.b), erlang-eunit (>= 1:15.b), erlang-edoc (>= 1:15.b), libxml2-utils, 
asciidoc, asciidoc-dblatex, docbook-xml, dblatex, docbook-xsl, 
erlang-asciideck, build-essential, fakeroot
dpkg-deb: building package 'sbuild-build-depends-main-dummy' in 
'/<>/apt_archive/sbuild-build-depends-main-dummy.deb'.
Ign:1 copy:/<>/apt_archive ./ InRelease
Get:2 copy:/<>/apt_archive ./ Release [957 B]
Ign:3 copy:/<>/apt_archive ./ Release.gpg
Get:4 copy:/<>/apt_archive ./ Sources [444 B]
Get:5 copy:/<>/apt_archive ./ Packages [531 B]
Fetched 1932 B in 0s (0 B/s)
Reading package lists...
Reading package lists...

Install main build dependencies (apt-based resolver)


Installing build dependencies
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
  asciidoc asciidoc-base asciidoc-common asciidoc-dblatex autoconf automake
  autopoint autotools-dev bsdextrautils dblatex debhelper dh-autoreconf
  dh-strip-nondeterminism distro-info-data docbook-dsssl docbook-utils
  docbook-xml docbook-xsl dwz erlang-asciideck erlang-asn1 erlang-base
  

Bug#978650: podman: please provide a default container registry for looking up short image names

[Antoine Beaupré]

On 2021-01-24 13:57:48, Reinhard Tartler wrote:
> On Sun, Jan 24, 2021 at 1:44 PM Antoine Beaupré  wrote:
>
>>
>> Could we still upload 2.1 or 2.2 to unstable in the meantime to have at
>> least an update on that front that's solid?
>>
>>
> Debian testing (bullseye)/unstable currently ship with version 2.1.1.
> cf. https://packages.qa.debian.org/libp/libpod.html

My bad.

-- 
How inappropriate to call this planet 'Earth' when it is quite clearly
'Ocean'.
- Arthur C. Clarke

Bug#980950: erlang-ranch: A source only upload is needed for testing migration

[Boyuan Yang]

Source: erlang-ranch
Version: 1.3.0-2
Severity: important
X-Debbugs-CC: iwama...@debian.org t...@debian.org

Dear Debian erlang-ranch package maintainers,

According to https://tracker.debian.org/pkg/erlang-ranch , the latest
upload of erlang-ranch was not a source-only upload. As a result,
package erlang-ranch is missing in Debian Testing. If it is not solved,
this package will miss the upcoming Debian 11 release.

Please make another source-only upload as indicated by
https://wiki.debian.org/SourceOnlyUpload . Please let me know if you
have any questions.

Thanks,
Boyuan Yang


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

Bug#978650: podman: please provide a default container registry for looking up short image names

[Reinhard Tartler]

On Sun, Jan 24, 2021 at 1:44 PM Antoine Beaupré  wrote:

>
> Could we still upload 2.1 or 2.2 to unstable in the meantime to have at
> least an update on that front that's solid?
>
>
Debian testing (bullseye)/unstable currently ship with version 2.1.1.
cf. https://packages.qa.debian.org/libp/libpod.html

Best,
-rt

Bug#980949: O: wbox -- HTTP testing tool and configuration-less HTTP server

[Baptiste Beauplat]

Package: wnpp

The current maintainer of wbox, Alberto Furia ,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: wbox
Binary: wbox
Version: 5-1
Maintainer: Alberto Furia 
Build-Depends: debhelper (>= 7), dpatch
Architecture: any
Standards-Version: 3.8.3
Format: 1.0
Files:
 39212ed0d6f433f9a7557250f9c34b70 932 wbox_5-1.dsc
 a95ca2c69982db10704b5ed482c9c722 16465 wbox_5.orig.tar.gz
 04852a510d31c699bf5fc9b47beed653 6080 wbox_5-1.diff.gz
Checksums-Sha256:
 d9ce54c32b3cdbaa6e7c15f6f86416e1c28ce7a5d8be915eb65fb8fd61ce246e 932 
wbox_5-1.dsc
 1589d85e83c8ee78383a491d89e768ab9aab9f433c5f5e035cfb5eed17efaa19 16465 
wbox_5.orig.tar.gz
 69cbea56623ddd744923c6f1fa1b304749747d4207b1656b3de87ab57d592efc 6080 
wbox_5-1.diff.gz
Homepage: http://www.hping.org/wbox/
Directory: pool/main/w/wbox
Priority: source
Section: web

Package: wbox
Source: wbox (5-1)
Version: 5-1+b2
Installed-Size: 54
Maintainer: Alberto Furia 
Architecture: amd64
Depends: libc6 (>= 2.14)
Description: HTTP testing tool and configuration-less HTTP server
Description-md5: d4e227ddc208e8ac7a1306a287a6eeb8
Homepage: http://www.hping.org/wbox/
Tag: implemented-in::c, role::program
Section: web
Priority: optional
Filename: pool/main/w/wbox/wbox_5-1+b2_amd64.deb
Size: 21452
MD5sum: 0837ee534c0279262dc8ce5f2e93fdf1
SHA256: 15ac083b4573582848dc168651871129a9e8709131181d9cae5afb1c3118f783


-- 
Baptiste Beauplat - lyknode


signature.asc
Description: PGP signature

Bug#980948: O: archmbox -- a simple email archiver written in perl

[Baptiste Beauplat]

Package: wnpp

The current maintainer of archmbox, Alberto Furia ,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: archmbox
Binary: archmbox
Version: 4.10.0-2.1
Maintainer: Alberto Furia 
Build-Depends: debhelper (>= 5.0.0)
Build-Depends-Indep: perl, psmisc, bzip2, uw-mailutils
Architecture: all
Standards-Version: 3.8.3
Format: 1.0
Files:
 bdd442520e9317007ccb3d3f733bbb6f 1756 archmbox_4.10.0-2.1.dsc
 44f9f155d45d2eae4b9de33314adf841 82370 archmbox_4.10.0.orig.tar.gz
 e27302880e3d9669201ae89d94cd5986 25788 archmbox_4.10.0-2.1.diff.gz
Checksums-Sha256:
 4def4a5146aca01bb6ee3df18f29e4141cf1b9a6c6aee8c5044c85001a5cf17f 1756 
archmbox_4.10.0-2.1.dsc
 0c0ec8bf6340dbb625306e5c129abe50c070abb3d84e00ab2559cdfbc366f329 82370 
archmbox_4.10.0.orig.tar.gz
 2346ece15b2b4c6bb0b4795eb8b72bedccaa3e3e3c80fb377a0f02a2d84bde51 25788 
archmbox_4.10.0-2.1.diff.gz
Homepage: http://adc-archmbox.sourceforge.net/
Package-List: 
 archmbox deb mail optional arch=all
Directory: pool/main/a/archmbox
Priority: source
Section: mail

Package: archmbox
Version: 4.10.0-2.1
Installed-Size: 83
Maintainer: Alberto Furia 
Architecture: all
Depends: perl, psmisc, bzip2, uw-mailutils
Description: a simple email archiver written in perl
Description-md5: aea0792059a321f0195e8aaee4d7d4c2
Homepage: http://adc-archmbox.sourceforge.net/
Tag: admin::backup, implemented-in::perl, interface::commandline,
 role::program, scope::utility, use::compressing, use::storing,
 works-with::mail
Section: mail
Priority: optional
Filename: pool/main/a/archmbox/archmbox_4.10.0-2.1_all.deb
Size: 35228
MD5sum: e3742ac03ae28d24a575ff794366e352
SHA256: ea6d8b1b051809a63b21bd98734382a51a8c5196d620fb4e0906990ce43ca09d


-- 
Baptiste Beauplat - lyknode


signature.asc
Description: PGP signature

Bug#980947: golang-github-hjfreyer-taglib-go: A source-only upload is needed for testing migration

[Boyuan Yang]

Source: golang-github-hjfreyer-taglib-go
Version: 0.0~git20201229.d150ea9-2
Severity: important
X-Debbugs-CC: av...@debian.org

Dear Debian golang-github-hjfreyer-taglib-go package maintainer,

According to
https://tracker.debian.org/pkg/golang-github-hjfreyer-taglib-go ,
package golang-github-hjfreyer-taglib-go did not receive any source-
only upload. As a result, it did not migrate to Debian Testing. If this
issue is not solved, this package will miss the upcoming Debian 11
release.

Please make another source-only upload as described in
https://wiki.debian.org/SourceOnlyUpload . Let me know if you have
other questions.

Regards,
Boyuan Yang


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

Bug#979865: m2crypto FTBFS on IPV6-only buildds

[Sebastian Andrzej Siewior]

On 2021-01-12 08:22:05 [+0200], Adrian Bunk wrote:
> Source: m2crypto
> Version: 0.37.1-1
> Severity: serious
> Tags: ftbfs

I suggest to lower the severity to important and let it migrate to
testing. After all this bug did not first appear in 0.37.1-1, it has
been exposed after it hit buildd that is IPv6 only.

The package built on all release architectures by now.

Sebastian

Bug#978650: podman: please provide a default container registry for looking up short image names

[Antoine Beaupré]

On 2021-01-24 09:12:13, Reinhard Tartler wrote:
> On Sun, Jan 24, 2021 at 7:54 AM Shengjing Zhu  wrote:
>
>> On Sun, Jan 24, 2021 at 8:44 PM Reinhard Tartler 
>> wrote:
>> >
>> > Context is what version of podman to ship in Debian bullseye
>> [...]
>> >
>> > One could be to let's go straight for podman 3.0. Since Debian is going
>> to have a
>> > hard-freeze on 2021-03-12, that's kind of tight, but if doable if we
>> collaborate.
>> > There are a couple of dependencies that we need to update in
>> experimental and I would
>> > really appreciate help with it.
>>
>> If I read the freeze policy correctly, the new version should be in
>> time before soft-freeze(aka 2021-2-12)?
>> It seems upstream has released 3.0.0-rc1 already. So if you want 3.0
>> to be in bullseye, a good start might be uploading 3.0.0~rc1 to
>> experimental first, then talk to the release team?
>>
>
> That sounds like a good plan. It also looks like the required
> updates to containers/* isn't as bad as I thought, I'm updating buildah
> right now, and see how much is missing for 3.0.0~rc1. If it is not, I'll
> upload to experimental and start that conversation.

Could we still upload 2.1 or 2.2 to unstable in the meantime to have at
least an update on that front that's solid?

Thanks!

a.

-- 
The illusion of freedom will continue as long as it's profitable to
continue the illusion. At the point where the illusion becomes too
expensive to maintain, they will just take down the scenery, they will
pull back the curtains, they will move the tables and chairs out of
the way and you will see the brick wall at the back of the theater.
 - Frank Zappa