Bug#971233: Please build r-cran-rstan on more powerful hardware for mipsel

[Andreas Tille]

Hi,

the build on mipsel[1] failed with


g++ -std=gnu++14 -I"/usr/share/R/include" -DNDEBUG -I"../inst/include" 
-I"../inst/include/boost_not_in_BH" -I"." -DBOOST_DISABLE_ASSERTS 
-DBOOST_PHOENIX_NO_VARIADIC_EXPRESSION -DBOOST_NO_AUTO_PTR -D_REENTRANT 
-DSTAN_THREADS   -I'/usr/lib/R/site-library/Rcpp/include' 
-I'/usr/lib/R/site-library/RcppEigen/include' 
-I'/usr/lib/R/site-library/BH/include' 
-I'/usr/lib/R/site-library/StanHeaders/include' 
-I'/usr/lib/R/site-library/RcppParallel/include'-fpic  -g -O2 
-fdebug-prefix-map=/build/r-base-dGwTCJ/r-base-4.0.2=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g  -c 
stan/lang/grammars/block_var_decls_grammar_inst.cpp -o 
stan/lang/grammars/block_var_decls_grammar_inst.o
virtual memory exhausted: Cannot allocate memory
make[1]: *** [/usr/lib/R/etc/Makeconf:176: 
stan/lang/grammars/block_var_decls_grammar_inst.o] Error 1


Is it possible to build this package on a more powerful machine?  If not
we should probably exclude mipsel from the set of target architectures.

Kind regards

Andreas.


[1] 
https://buildd.debian.org/status/fetch.php?pkg=r-cran-rstan=mipsel=2.21.2-2=1601481233=0

-- 
http://fam-tille.de

Bug#971732: lintian: font-in-non-font-package triggers on non-font files

[Ross Vandegrift]

Package: lintian
Version: 2.97.0
Severity: minor

Hello,

Lintian misidentifies the output of eolioan_gen as font files.  This causes
font-in-non-font-package false positives.  Example case from libefl-all-dev is
attached.

Thanks,
Ross


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

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

Versions of packages lintian depends on:
ii  binutils2.35.1-1
ii  bzip2   1.0.8-4
ii  diffstat1.63-1
ii  dpkg1.20.5
ii  dpkg-dev1.20.5
ii  file1:5.38-5
ii  gettext 0.19.8.1-10
ii  gpg 2.2.20-1
ii  intltool-debian 0.35.0+20060710.5
ii  libapt-pkg-perl 0.1.36+b3
ii  libarchive-zip-perl 1.68-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b5
ii  libclone-perl   0.45-1
ii  libconfig-tiny-perl 2.24-1
ii  libcpanel-json-xs-perl  4.23-1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1
ii  libdevel-size-perl  0.83-1+b1
ii  libdpkg-perl1.20.5
ii  libemail-address-xs-perl1.04-1+b2
ii  libfile-basedir-perl0.08-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1
ii  libhtml-html5-entities-perl 0.004-1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004002-1
ii  liblist-compare-perl0.55-1
ii  liblist-moreutils-perl  0.416-1+b5
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.004000-1
ii  libmoox-aliases-perl0.001006-1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.114-1
ii  libperlio-gzip-perl 0.19-1+b6
ii  libproc-processtable-perl   0.59-2
ii  libsereal-decoder-perl  4.018+ds-1
ii  libsereal-encoder-perl  4.018+ds-1
ii  libtext-glob-perl   0.11-1
ii  libtext-levenshteinxs-perl  0.03-4+b7
ii  libtext-markdown-discount-perl  0.12-1
ii  libtext-xslate-perl 3.5.8-1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-1+b2
ii  libtimedate-perl2.3300-1
ii  libtry-tiny-perl0.30-1
ii  libtype-tiny-perl   1.010006-1
ii  libunicode-utf8-perl0.62-1+b1
ii  liburi-perl 1.76-2
ii  libxml-libxml-perl  2.0134+dfsg-2
ii  libyaml-libyaml-perl0.82+repack-1
ii  lzip1.21-8
ii  lzop1.04-1
ii  man-db  2.9.3-2
ii  patchutils  0.4.2-1
ii  perl [libdigest-sha-perl]   5.30.3-4
ii  t1utils 1.41-4
ii  unzip   6.0-25
ii  xz-utils5.2.4-1+b1

lintian recommends no packages.

Versions of packages lintian suggests:
ii  binutils-multiarch 2.35.1-1
ii  libtext-template-perl  1.59-1

-- no debconf information

struct @extern Efl.Time
{
   [[This type is a alias for struct tm.
 It is intended to be a standard way to reference
 it in .eo files.

 @since 1.22
   ]]

   tm_sec: int;   [[Seconds.[0-60] (1 leap second)]]
   tm_min: int;   [[Minutes.[0-59] ]]
   tm_hour: int;  [[Hours.  [0-23] ]]
   tm_mday: int;  [[Day.[1-31] ]]
   tm_mon: int;   [[Month.  [0-11] ]]
   tm_year: int;  [[Year- 1900.]]
   tm_wday: int;  [[Day of week.[0-6] ]]
   tm_yday: int;  [[Days in year.[0-365] ]]
   tm_isdst: int; [[DST. [-1/0/1] ]]
}

struct Efl.Version
{
   [[This type describes the version of EFL with an optional variant.

 This may be used to query the current running version of EFL. Or it can
 be passed by applications at startup time to inform EFL of the version
 a certain application was built for.

 @since 1.22
   ]]

   major: int; [[Major component of the version (>= 1).]]
   minor: int; [[Minor component of the version (>= 0).]]
   micro: int; [[Micro component of the version (>= 0).]]
   revision: int; [[Revision component of the version (>= 0).]]
   flavor: string; [[Special version string for this build of EFL, $null for
 vanilla (upstream) EFL. Contains $EFL_VERSION_FLAVOR.]]
   build_id: string; 

Bug#960769: swt4-gtk FTBFS on 32bit

[tony mancill]

It turns out there was already an RM bug filed:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969975 

I will merge the duplicate I created into it:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971730

Bug#971730: RM: openjfx [armel armhf i386 mipsel] -- ROM; removal of libswt-gtk-4-java on 32bit (#960769, #962915, #967185)

[tony mancill]

Package: ftp.debian.org
Severity: normal

Hello,

As per the discussion in #960769 and initiated by #962915 (and also
referenced in #971619), please remove the non-arch:all  openjfx packages
for the armel, armhf, i386 and mipsel architectures:

 * openjfx
 * libopenjfx-jni

Thank you,
tony mancill

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960769
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962915
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971619


signature.asc
Description: PGP signature

Bug#968415: [susv4] File size / SHA512

[Christoph Franzen]

Hello,

I see something similar here:

-8<
Package: susv4
Version: 7.20180621
--- Package information. ---
Depends  (Version) | Installed
==-+-===
wget   | 1.18-5+deb9u3
bzip2  | 1.0.6-9.2~deb10u1
-8<
# dpkg --configure -a
susv4 (7.20180621) wird eingerichtet ...
Fetching file...
--2020-10-06 05:46:56--
http://pubs.opengroup.org/onlinepubs/9699919799/download/susv4-2018.tar.bz2
Auflösen des Hostnamens »pubs.opengroup.org (pubs.opengroup.org)« …
54.218.18.100, 52.32.134.144, 54.202.59.160 Verbindungsaufbau zu
pubs.opengroup.org (pubs.opengroup.org)|54.218.18.100|:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 301 Moved
Permanently Platz:
https://pubs.opengroup.org/onlinepubs/9699919799/download/susv4-2018.tar.bz2
[folgend] --2020-10-06 05:46:57--
https://pubs.opengroup.org/onlinepubs/9699919799/download/susv4-2018.tar.bz2
Verbindungsaufbau zu pubs.opengroup.org
(pubs.opengroup.org)|54.218.18.100|:443 … verbunden. HTTP-Anforderung
gesendet, auf Antwort wird gewartet … 200 OK Länge: 3352824 (3,2M)
[application/x-bzip2] Wird in
»»/tmp/tmp.hV95rtBofj/susv4-2018.tar.bz2«« gespeichert.

susv4-2018.tar.bz2
100%[>]
3,20M   315KB/sin 11s 

2020-10-06 05:47:08 (312 KB/s) -
»»/tmp/tmp.hV95rtBofj/susv4-2018.tar.bz2«« gespeichert [3352824/3352824]

Verifying SHA512 checksum...
dpkg: Fehler beim Bearbeiten des Paketes susv4 (--configure):
 »installiertes susv4-Skript des Paketes
post-installation«-Unterprozess gab den Fehlerwert 1 zurück Fehler
traten auf beim Bearbeiten von: susv4
-8<

Note that the files' sizes are different:
Original bug report: 3730770 bytes
My failed attempt above: 3352824 bytes

Probably they've reformatted/repacked/broken it, so the SHA512 sum
has changed and differs now from the value the package expects.

-- 
Christoph Franzen


pgppxxTRLmA87.pgp
Description: Digitale Signatur von OpenPGP

Bug#971671: gnome-shell-extension-autohidetopbar: error loading extension after gnome-shell upgrade

[Gabriel Filion]

On 2020-10-05 9:58 a.m., Tobias Frost wrote:

On Sun, Oct 04, 2020 at 01:59:33PM -0400, Gabriel Filion wrote:

Package: gnome-shell-extension-autohidetopbar
Version: 20200921-1
Severity: normal

Hello,

I've run upgrades today on debian sid, and gnome-shell was upgraded from
3.36.6-1 to 3.38.0-2. The autohidetopbar is not working, and in gnome-tweaks I
see a message on the add-on that says "Error loading extension".



I currently don't know how to find out more information about the error, but
I'm willing to dig for more.


This could be https://github.com/mlutfy/hidetopbar/issues/255.

Can you try a "journalctl --user" and see if you can find something in the
logs?


nice, I've just upgraded and reloaded gnome and the problem is fixed. 
thanks for the quick response!

Bug#960769: swt4-gtk FTBFS on 32bit

[tony mancill]

On Mon, Oct 05, 2020 at 06:30:51AM +0200, Sebastiaan Couwenberg wrote:
> On 10/5/20 6:04 AM, tony mancill wrote:
> > On Sun, Oct 04, 2020 at 04:34:17PM +0200, Sebastiaan Couwenberg wrote:
> >> Control: severity -1 serious
> >> Control: affects -1 src:openjfx
> >>
> >> This issue is preventing testing migration of swt4-gtk, it also blocks
> >> openjfx builds on the architectures where swt4-gtk FTBFS preventing the
> >> fix for #967185 from migrating to testing.
> >>
> >> Either fix the build or request removal of swt4-gtk and its rdeps from
> >> these architectures.
> > 
> > The binaries for the 32-bit architectures were removed in #962915 [1],
> > but only for version 4.13.0-1 in unstable. 
> 
> This was not sufficient to let it migrate to testing.
> 
> The britney output logs a bunch of packages on i386.
> 
> i386 & amd64 are the NOBREAKALL_ARCHES in britney.conf, see:
> 
>  https://release.debian.org/britney/britney.conf
> 
> > bullseye still contains the
> > binaries [2].  From the RM email:
> > 
> >> Packages are usually not removed from testing by hand. Testing tracks
> >> unstable and will automatically remove packages which were removed
> >> from unstable when removing them from testing causes no dependency
> >> problems. The release team can force a removal from testing if it is
> >> really needed, please contact them if this should be the case.
> > 
> > Is the problem here that we need to RM all of the rdeps on those
> > architectures from unstable as well? 
> 
> At least in the case of openjfx (and its non-arch:all rdeps).

I see.  It sounds like the RM should remove the set of transitive
(non-arch:all) rdeps.

> > If that's sufficient, I can put
> > together that RM request.
> > 
> > Also, shouldn't we explicitly enumerate the supported Architectures in
> > the next upload of swt4-gtk instead of specifying "Architecture: all" ?
> 
> You mean "Architecture: any" I presume? If so, you could do that, but
> maintaining the list of architectures over time is a PITA from my
> experience, I wouldn't recommend it unless swt4-gtk only sometimes fails
> to build on these architectures. If it's persistent removing the
> packages from those architectures should suffice. Once its rdeps are
> removed as well they will be in BD-Uninstallable state on those archs.
> But because of the RM the missing binaries won't block testing migration.

Oops - yes, I meant "Architecture: any" and thank you for the guidance
here.  It sounds like the arch-specific RM acts like a mask that will
prevent the auto builders on the RM'd arches from attempting to rebuild
subsequent source uploads.  (As I type that, I realize that I should
know that already.  But arch-specific RMs don't occur that often for the
Java Team packages.)

Thank you again,
tony

Bug#971729: RFS: pekka-kana-2/1.2.7-1 -- 2D Oldschool platform game where you control a rooster

[Carlos Donizete Froes]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "pekka-kana-2":

 * Package name: pekka-kana-2
   Version : 1.2.7-1
   Upstream Author : Janne Kivilahti (Piste Gamez) 
 * URL : https://pistegamez.net/game_pk2.html
 * License : BSD-2-Clause
 * Vcs : https://salsa.debian.org/games-team/pekka-kana-2
   Section : games

It builds those binary packages:

  pekka-kana-2-data - 2D Oldschool platform game where you control a rooster 
(data file)
  pekka-kana-2 - 2D Oldschool platform game where you control a rooster

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

  https://mentors.debian.net/package/pekka-kana-2/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/pekka-kana-2/pekka-kana-2_1.2.7-1.dsc

Changes since the last upload:

 pekka-kana-2 (1.2.7-1) unstable; urgency=medium
 .
   * New upstream release. FTCBFS bug fix. (Closes: #933080)
 + Integrated support fixed for pkg-config.
   * debian/control:
 + Bump debhelper compat to version 13.
   * Added debian/docs.

Regards,
--
  Carlos Donizete Froes [a.k.a coringao]

Bug#971728: malcontent-gui: Missing .policy file prevents service from working

[Diego Escalante Urrelo]

Package: malcontent-gui
Version: 0.9.0-1
Severity: grave
Tags: patch
Justification: renders package unusable
X-Debbugs-Cc: die...@gnome.org

Hi, it seems that there's a missing .policy file in the .install file
for `malcontent-gui`, specifically:
  `usr/share/polkit-1/actions/org.freedesktop.MalcontentControl.policy`

I opened a MR a few weeks ago for that:
  https://salsa.debian.org/freedesktop-team/malcontent/-/merge_requests/2

Since gnome-control-center now depends on malcontent, the broken
functionality (no ability to _use_ malcontent-gui) is now exposed to all
users.

You'll notice this issue when you open `malcontent-control`, which will
warn you that there's no data for users, and you should fix your
accountsservice. The message is somewhat confusing, because the reason
for the failure is that the .policy file is missing.

Thanks!

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

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

Versions of packages malcontent-gui depends on:
ii  libaccountsservice00.6.55-3
ii  libc6  2.31-3
ii  libcairo2  1.16.0-4
ii  libgdk-pixbuf2.0-0 2.40.0+dfsg-5
ii  libglib2.0-0   2.66.0-2
ii  libgtk-3-0 3.24.23-1
ii  libmalcontent-ui-0-0   0.9.0-1
ii  libpolkit-gobject-1-0  0.117-1
ii  malcontent 0.9.0-1

malcontent-gui recommends no packages.

malcontent-gui suggests no packages.

-- no debconf information

Bug#971725: libsane1: Brightness and contrast settings are ignored by scanner (CanoScan LiDE 60)

[Alexander Kernozhitsky]

Package: libsane1
Version: 1.0.31-2.0.1
Severity: normal
Tags: patch upstream
X-Debbugs-Cc: sh200...@mail.ru

After upgrade to libsane 1.0.31-2 my scanner started to ignore brightness and
contrast settings.

The upstream issue is https://gitlab.com/sane-project/backends/-/issues/271. I
can confirm that the patch proposed there fixes the bug for me.

Attaching a patch that fixes the bug.

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

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

Versions of packages libsane1 depends on:
ii  acl2.2.53-8
ii  adduser3.118
ii  libavahi-client3   0.8-3
ii  libavahi-common3   0.8-3
ii  libc6  2.31-3
ii  libcairo2  1.16.0-4
ii  libcurl3-gnutls7.72.0-1
ii  libgcc-s1  10.2.0-9
ii  libglib2.0-0   2.66.0-2
ii  libgphoto2-6   2.5.25-3
ii  libgphoto2-port12  2.5.25-3
ii  libieee1284-3  0.2.11-14
ii  libjpeg62-turbo1:2.0.5-1.1
ii  libpng16-161.6.37-3
ii  libpoppler-glib8   20.09.0-2
ii  libsane-common 1.0.31-2
ii  libsnmp40  5.9+dfsg-3
ii  libstdc++6 10.2.0-9
ii  libtiff5   4.1.0+git191117-2
ii  libusb-1.0-0   2:1.0.23-2
ii  libxml22.9.10+dfsg-6
ii  udev   246.6-1

Versions of packages libsane1 recommends:
ii  ipp-usb 0.9.13-1
ii  sane-utils  1.0.31-2

Versions of packages libsane1 suggests:
ii  avahi-daemon  0.8-3
ii  hplip 3.20.5+dfsg0-3+b1

-- 
Alexander KernozhitskyDescription: Disable the gamma only if the flags say so

The previous behavior made my scanner ignore brightness and contrast settings.
The patch is tested to work with Canon CanoScan LiDE 60, though it may fix
the issue for another scanners (issues with CanoScan LiDE 35 were also reported)

Author: Alexander Kernozhitsky 
Last-Update: 2020-10-05

--- sane-backends-1.0.31.orig/backend/genesys/low.cpp
+++ sane-backends-1.0.31/backend/genesys/low.cpp
@@ -640,11 +640,6 @@ bool should_enable_gamma(const ScanSessi
 if ((session.params.flags & ScanFlag::DISABLE_GAMMA) != ScanFlag::NONE) {
 return false;
 }
-if (sensor.gamma[0] == 1.0f || sensor.gamma[1] == 1.0f || sensor.gamma[2] == 1.0f) {
-return false;
-}
-if (session.params.depth == 16)
-return false;
 
 return true;
 }

Bug#933151: mariadb-10.3: FTBFS on riscv64

[Daniel Black]

https://jira.mariadb.org/browse/MDEV-23892 created for this issue.

https://github.com/MariaDB/server/pull/979 modified to be more minimal
https://github.com/MariaDB/server/commit/970984e9f9b385d7a64d896baa437a40d65d3f2f
is now in testing.

Comments welcome.

Testing on riscv64 is also very welcome.

On Mon, Oct 5, 2020 at 7:14 AM Otto Kekäläinen  wrote:
>
> Hello!
>
> I plan to upload mariadb-10.5 1:10.5.5-2 in a couple of days and I
> would be happy to receive merge requests regarding getting riscv64 to
> build properly on Debian.
>
> http://bugs.debian.org/933151
> https://wiki.debian.org/Teams/MySQL/patches
>
>
> ti 29. syysk. 2020 klo 16.48 Otto Kekäläinen (o...@debian.org) kirjoitti:
> >
> > Hello!
> >
> > Adding Christian and Dimitri to the recipients, since I think it was
> > Dimitri who patched the Ubuntu version of cmake for this.
> >
> >
> > ti 29. syysk. 2020 klo 0.22 Aurelien Jarno (aurel...@aurel32.net) kirjoitti:
> > >
> > > On 2020-09-28 15:12, Otto Kekäläinen wrote:
> > > > After uploading mariadb-10.5 1:10.5.5-1 to Debian the build still
> > > > fails with these:
> > > >
> > > > /usr/bin/ld: /usr/include/c++/10/bits/atomic_base.h:464: undefined
> > > > reference to `__atomic_compare_exchange_1'
> > > >
> > > > The odd thing is that an identical build on Ubuntu Groovy passes OK:
> > > > https://launchpadlibrarian.net/499652421/buildlog_ubuntu-groovy-riscv64.mariadb-10.5_1%3A10.5.5-1~ubuntu20.10.1~1601274184.7ad164279+master_BUILDING.txt.gz
> > >
> > > Ubuntu has patched their version of cmake to link with -latomic on
> > > riscv64. While patching cmake is a really good idea, the fix is wrong,
> > > the correct think to do is to link with -pthread instead of -lpthread,
> > > and do that for all architectures.
> > >
> > > This is the strategy followed for mariadb-10.5 in the attached patch. I
> > > have tested it and it builds fine on Debian.
>
>
>
> --
> - Otto

Bug#971727: api.ftp-master.debian.org: add an API for looking up why packages were removed

[Paul Wise]

Package: ftp.debian.org
Severity: wishlist
Control: block 960636 by -1

It would be useful to have an API for looking up why packages were
removed. This would speed up (#960636) deb-why-removed greatly since it
wouldn't have to download the large removals files, process them to
remove the junk (#877902) and then search through them.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#199392: ✉ : LAWSON

[Hast du meine vorherige E-Mail erhalten? ..antwort an: Rechtsanwalt Lawson]

Bug#971726: RFP: just -- command runner

[Casey Rodarmor]

Package: wnpp
Severity: wishlist

Just is a command runner, written in Rust. Commands are saved in a
file with a similar syntax as Make. Unlike Make, Just has no build
system functionality, produces extremely good error messages, adds a
bunch of convenient features, and avoids Make's idiosyncrasies.

Just is free software, released under the CC0, and developed on GitHub:
https://github.com/casey/just

I'm the author of Just, would very much like it to be available in
Debian. Someone started packaging Just for Debian, and I fixed a few
issues which blocked packaging, but I don't think the package was ever
submitted. I'm not sure if there are any issues remaining, but if
there are, I'm very eager to fix them!

You can see the previous conversation and a few of the issues that
were resolved here:
https://github.com/casey/just/issues/429

Thanks for reading!

Bug#956970: 4g8: diff for NMU version 1.0-3.3

[mwhudson]

Control: tags 956970 + patch
Control: tags 956970 + pending


Dear maintainer,

I've prepared an NMU for 4g8 (versioned as 1.0-3.3) and
uploaded it to DELAYED/15. Please feel free to tell me if I
should delay it longer.

Regards.

diff -u 4g8-1.0/debian/changelog 4g8-1.0/debian/changelog
--- 4g8-1.0/debian/changelog
+++ 4g8-1.0/debian/changelog
@@ -1,3 +1,11 @@
+4g8 (1.0-3.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with GCC 10 by ensuring global variables only have one
+definition. (Closes: #956970)
+
+ -- Michael Hudson-Doyle   Tue, 06 Oct 2020 13:51:30 +1300
+
 4g8 (1.0-3.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u 4g8-1.0/src/globals.h 4g8-1.0/src/globals.h
--- 4g8-1.0/src/globals.h
+++ 4g8-1.0/src/globals.h
@@ -128,20 +128,20 @@
 #define P_UINT640x
 
-char w_file[OPT_MAXLEN];
+extern char w_file[OPT_MAXLEN];
 
-pcap_t *pkt;
-libnet_t *pkt_d;
-u_int8_t *device;
-u_int8_t display;
-u_int8_t dump_pkt;
-u_int16_t payload_len;
-u_int16_t hdr_len;
-u_int16_t ip_hdrlen;
-u_int8_t *gw_ip;
-u_int8_t *gw_mac;
-u_int8_t *host_ip;
-u_int8_t *host_mac;
-u_int8_t outbound;
-u_int8_t poison_cache;
+extern pcap_t *pkt;
+extern libnet_t *pkt_d;
+extern u_int8_t *device;
+extern u_int8_t display;
+extern u_int8_t dump_pkt;
+extern u_int16_t payload_len;
+extern u_int16_t hdr_len;
+extern u_int16_t ip_hdrlen;
+extern u_int8_t *gw_ip;
+extern u_int8_t *gw_mac;
+extern u_int8_t *host_ip;
+extern u_int8_t *host_mac;
+extern u_int8_t outbound;
+extern u_int8_t poison_cache;
 
 #endif /* __GLOBALS_H */
only in patch2:
unchanged:
--- 4g8-1.0.orig/src/error.h
+++ 4g8-1.0/src/error.h
@@ -29,7 +29,7 @@
 #define SUCCESS1
 #define FAILURE-1
 
-char error_buf[ERRBUF_MAXLEN];
+extern char error_buf[ERRBUF_MAXLEN];
 
 void fatal_error(u_int8_t *,...);
 
only in patch2:
unchanged:
--- 4g8-1.0.orig/src/main.c
+++ 4g8-1.0/src/main.c
@@ -22,6 +22,25 @@
 
 #include "main.h"
 
+char w_file[OPT_MAXLEN];
+
+pcap_t *pkt;
+libnet_t *pkt_d;
+u_int8_t *device;
+u_int8_t display;
+u_int8_t dump_pkt;
+u_int16_t payload_len;
+u_int16_t hdr_len;
+u_int16_t ip_hdrlen;
+u_int8_t *gw_ip;
+u_int8_t *gw_mac;
+u_int8_t *host_ip;
+u_int8_t *host_mac;
+u_int8_t outbound;
+u_int8_t poison_cache;
+
+char error_buf[ERRBUF_MAXLEN];
+
 int
 main(int argc, char *argv[])
 {

Bug#957999: xsd: diff for NMU version 4.0.0-8.1

[mwhudson]

Control: tags 957999 + patch
Control: tags 957999 + pending


Dear maintainer,

I've prepared an NMU for xsd (versioned as 4.0.0-8.1) and
uploaded it to DELAYED/15. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru xsd-4.0.0/debian/changelog xsd-4.0.0/debian/changelog
--- xsd-4.0.0/debian/changelog  2018-05-06 05:42:32.0 +1200
+++ xsd-4.0.0/debian/changelog  2020-10-06 14:03:20.0 +1300
@@ -1,3 +1,10 @@
+xsd (4.0.0-8.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply patch from upstream to fix build with gcc 10. (Closes: #957999)
+
+ -- Michael Hudson-Doyle   Tue, 06 Oct 2020 14:03:20 +1300
+
 xsd (4.0.0-8) unstable; urgency=medium
 
   * Team upload.
diff -Nru xsd-4.0.0/debian/patches/0002-missing-include.patch 
xsd-4.0.0/debian/patches/0002-missing-include.patch
--- xsd-4.0.0/debian/patches/0002-missing-include.patch 1970-01-01 
12:00:00.0 +1200
+++ xsd-4.0.0/debian/patches/0002-missing-include.patch 2020-10-06 
09:38:15.0 +1300
@@ -0,0 +1,19 @@
+From 5029f8665190879285787a9dcdaf5f997cadd2e2 Mon Sep 17 00:00:00 2001
+From: Boris Kolpackov 
+Date: Fri, 23 Oct 2015 15:40:35 +0200
+Subject: Add missing #include
+
+---
+ xsd-frontend/semantic-graph/elements.cxx | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/libxsd-frontend/xsd-frontend/semantic-graph/elements.cxx
 b/libxsd-frontend/xsd-frontend/semantic-graph/elements.cxx
+@@ -3,6 +3,7 @@
+ // license   : GNU GPL v2 + exceptions; see accompanying LICENSE file
+ 
+ #include 
++#include 
+ 
+ #include 
+ 
diff -Nru xsd-4.0.0/debian/patches/series xsd-4.0.0/debian/patches/series
--- xsd-4.0.0/debian/patches/series 2018-05-06 05:42:32.0 +1200
+++ xsd-4.0.0/debian/patches/series 2020-10-06 09:37:19.0 +1300
@@ -3,3 +3,4 @@
 0700_hurd_PATH_MAX.patch
 0105-Fix_path_handling_bug.patch
 0110-xerces-c3.2.patch
+0002-missing-include.patch

Bug#944382: bug still exists in xscreensaver-data 5.42+dfsg1-1 amd64

[Daniel Warner]

The following patch to
/usr/share/applications/screensavers/glitchpeg.desktop fixes this bug

6,7c6
< Comment=Loads an image, corrupts it, and then displays the corrupted
version,
< several times a second.  After a while, finds a new image to corrupt.
Written by Jamie Zawinski; 2018.
---
> Comment=Loads an image, corrupts it, and then displays the corrupted
version, several times a second.  After a while, finds a new image to
corrupt. Written by Jamie Zawinski; 2018.

Bug#958004: xtron: diff for NMU version 1.1a-14.1

[mwhudson]

Control: tags 958004 + patch
Control: tags 958004 + pending


Dear maintainer,

I've prepared an NMU for xtron (versioned as 1.1a-14.1) and
uploaded it to DELAYED/15. Please feel free to tell me if I
should delay it longer.

Regards.

diff -u xtron-1.1a/debian/changelog xtron-1.1a/debian/changelog
--- xtron-1.1a/debian/changelog
+++ xtron-1.1a/debian/changelog
@@ -1,3 +1,11 @@
+xtron (1.1a-14.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply patch from Reiner Herrmann to fix ftbfs with gcc 10.
+(Closes: #958004)
+
+ -- Michael Hudson-Doyle   Tue, 06 Oct 2020 13:59:40 +1300
+
 xtron (1.1a-14) unstable; urgency=low
 
   * Standards-Version: 3.8.0.
only in patch2:
unchanged:
--- xtron-1.1a.orig/xtron.c
+++ xtron-1.1a/xtron.c
@@ -21,6 +21,9 @@
 
 #include "xtron.h"
 
+struct Player p[2];
+struct Board b;
+
 void plr_setup(void)
 {
   int i;
only in patch2:
unchanged:
--- xtron-1.1a.orig/xtron.h
+++ xtron-1.1a/xtron.h
@@ -40,11 +40,15 @@
   int alive;
   enum directions plr_dir;
   enum play_types plr_type; 
-} p[2];
+};
+
+extern struct Player p[2];
 
 struct Board {
   short int contents[200][200];
-} b;
+};
+
+extern struct Board b;
  
 void plr_setup(void);
 int plr_checkmove(int p_num, int new_val, int axis_type, enum directions dir);

Bug#958012: ziproxy: diff for NMU version 3.3.1-2.2

[mwhudson]

Control: tags 958012 + patch
Control: tags 958012 + pending


Dear maintainer,

I've prepared an NMU for ziproxy (versioned as 3.3.1-2.2) and
uploaded it to DELAYED/15. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru ziproxy-3.3.1/debian/changelog ziproxy-3.3.1/debian/changelog
--- ziproxy-3.3.1/debian/changelog  2016-06-27 22:06:07.0 +1200
+++ ziproxy-3.3.1/debian/changelog  2020-10-06 13:54:59.0 +1300
@@ -1,3 +1,10 @@
+ziproxy (3.3.1-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with gcc 10. (Closes: 958012)
+
+ -- Michael Hudson-Doyle   Tue, 06 Oct 2020 13:54:59 +1300
+
 ziproxy (3.3.1-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru ziproxy-3.3.1/debian/patches/04_gcc10.diff 
ziproxy-3.3.1/debian/patches/04_gcc10.diff
--- ziproxy-3.3.1/debian/patches/04_gcc10.diff  1970-01-01 12:00:00.0 
+1200
+++ ziproxy-3.3.1/debian/patches/04_gcc10.diff  2020-10-05 13:55:19.0 
+1300
@@ -0,0 +1,26 @@
+Description: fix multiple defintions which causes an error with gcc 10
+Author: Michael Hudson-Doyle 
+Origin: vendor
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958012
+Last-Update: 2020-10-05
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/src/tosmarking.c
 b/src/tosmarking.c
+@@ -32,15 +32,11 @@
+ #include "urltables.h"
+ #include "cttables.h"
+ #include "log.h"
++#include "cfgfile.h"
+ 
+ /* private, local. those are not the same as the vars with the same name */
+ int tosmarking_enabled;
+ SOCKET sock_child_out;
+-int TOSFlagsDefault;
+-int TOSFlagsDiff;
+-const t_ut_urltable *tos_markasdiff_url;
+-const t_ct_cttable *tos_maskasdiff_ct;
+-ZP_DATASIZE_TYPE TOSMarkAsDiffSizeBT;
+ 
+ int current_tos;
+ ZP_DATASIZE_TYPE tos_bytecount;   /* counter used by TOSMarkAsDiffSizeBT 
*/
diff -Nru ziproxy-3.3.1/debian/patches/series 
ziproxy-3.3.1/debian/patches/series
--- ziproxy-3.3.1/debian/patches/series 2016-06-27 22:01:35.0 +1200
+++ ziproxy-3.3.1/debian/patches/series 2020-10-05 13:49:42.0 +1300
@@ -1,3 +1,4 @@
 01_ziproxyconf.diff
 02_small_spelling.diff
 03_giflib5.diff
+04_gcc10.diff

Bug#958011: yersinia: diff for NMU version 0.8.2-2.1

[mwhudson]

Control: tags 958011 + patch
Control: tags 958011 + pending


Dear maintainer,

I've prepared an NMU for yersinia (versioned as 0.8.2-2.1) and
uploaded it to DELAYED/15. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru yersinia-0.8.2/debian/changelog yersinia-0.8.2/debian/changelog
--- yersinia-0.8.2/debian/changelog 2017-09-18 07:00:46.0 +1200
+++ yersinia-0.8.2/debian/changelog 2020-10-06 12:42:32.0 +1300
@@ -1,3 +1,11 @@
+yersinia (0.8.2-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix build failure with gcc-10 now that -fno-common is the default.
+(Closes: 958011) 
+
+ -- Michael Hudson-Doyle   Tue, 06 Oct 2020 12:42:32 +1300
+
 yersinia (0.8.2-2) unstable; urgency=medium
 
   * added fix from Frédéric Bonnard 
diff -Nru yersinia-0.8.2/debian/control yersinia-0.8.2/debian/control
--- yersinia-0.8.2/debian/control   2017-09-18 07:00:46.0 +1200
+++ yersinia-0.8.2/debian/control   2020-10-05 16:17:28.0 +1300
@@ -1,7 +1,8 @@
 Source: yersinia
 Section: admin
 Priority: optional
-Maintainer: Noël Köthe 
+Maintainer: Ubuntu Developers 
+XSBC-Original-Maintainer: Noël Köthe 
 Build-Depends: debhelper (>= 9.0.0), dh-autoreconf, libncurses5-dev (>=5.4), 
libnet1-dev (>=1.1.2), libpcap0.8-dev, libgtk2.0-dev, lsb-release
 Standards-Version: 4.1.0
 Homepage: http://www.yersinia.net/
diff -Nru yersinia-0.8.2/debian/patches/gcc10.patch 
yersinia-0.8.2/debian/patches/gcc10.patch
--- yersinia-0.8.2/debian/patches/gcc10.patch   1970-01-01 12:00:00.0 
+1200
+++ yersinia-0.8.2/debian/patches/gcc10.patch   2020-10-05 16:26:28.0 
+1300
@@ -0,0 +1,133 @@
+--- a/src/gtk-gui.h
 b/src/gtk-gui.h
+@@ -47,7 +47,7 @@
+ #define MAX_PAD_HEIGHT 40 
+ #define MAX_PAD_WIDTH  70
+ 
+-u_int8_t pointer[MAX_PROTOCOLS];
++extern u_int8_t pointer[MAX_PROTOCOLS];
+ 
+ void gtk_gui(void *);
+ void gtk_gui_th_exit(struct term_node *);
+--- a/src/interfaces.h
 b/src/interfaces.h
+@@ -67,7 +67,7 @@
+ 
+ #define NO_TIMEOUT  0
+ 
+-list_t *interfaces;
++extern list_t *interfaces;
+ 
+ struct interface_data {
+int8_t   up;  /* is it active? */
+--- a/src/ncurses-interface.h
 b/src/ncurses-interface.h
+@@ -80,8 +80,8 @@
+ #define CAN_RESIZE 1
+ #endif
+ 
+-u_int8_t pointer[MAX_PROTOCOLS];
+-WINDOW *info_window;
++extern u_int8_t pointer[MAX_PROTOCOLS];
++extern WINDOW *info_window;
+ 
+ int8_t  ncurses_i_init(WINDOW *[], PANEL *[], struct term_node *);
+ voidncurses_i_add_node(void);
+--- a/src/protocols.h
 b/src/protocols.h
+@@ -207,7 +207,7 @@
+end_t end;
+ };
+ 
+-struct protocol_def protocols[MAX_PROTOCOLS];
++extern struct protocol_def protocols[MAX_PROTOCOLS];
+ 
+ void   protocol_init(void);
+ int8_t protocol_register(u_int8_t, const char *, const char *, const char *,
+--- a/src/gtk-gui.c
 b/src/gtk-gui.c
+@@ -70,6 +70,9 @@
+ #include "gtk-interface.h"
+ #include "gtk-support.h"
+ 
++u_int8_t pointer[MAX_PROTOCOLS];
++
++
+ void
+ gtk_gui (void *args)
+ {
+--- a/src/interfaces.c
 b/src/interfaces.c
+@@ -102,7 +102,7 @@
+ 
+ #include "interfaces.h"
+ 
+-
++list_t *interfaces;
+ 
+ 
+ 

+--- a/src/ncurses-interface.c
 b/src/ncurses-interface.c
+@@ -92,6 +92,8 @@
+ #include "ncurses-interface.h"
+ #include "ncurses-callbacks.h"
+ 
++WINDOW *info_window;
++
+ 
+ /*
+  * Ncurses init
+--- a/src/protocols.c
 b/src/protocols.c
+@@ -61,6 +61,9 @@
+ 
+ #include "protocols.h"
+ 
++struct protocol_def protocols[MAX_PROTOCOLS];
++
++
+ void
+ protocol_init(void)
+ {
+--- a/src/gtk-interface.c
 b/src/gtk-interface.c
+@@ -36,7 +36,11 @@
+ 
+ #include "gtk-interface.h"
+ 
+-#define GLADE_HOOKUP_OBJECT(component,widget,name) \
++GtkWidget *protocols_tree[MAX_PROTOCOLS + 1];
++GtkListStore *protocols_tree_model[MAX_PROTOCOLS + 1];
++
++
++#define GLADE_HOOKUP_OBJECT(component,widget,name)\
+   g_object_set_data_full (G_OBJECT (component), name, \
+ gtk_widget_ref (widget), (GDestroyNotify) gtk_widget_unref)
+ 
+--- a/src/gtk-interface.h
 b/src/gtk-interface.h
+@@ -26,8 +26,8 @@
+ #include "gtk-callbacks.h"
+ #include "gtk-support.h"
+ 
+-GtkWidget *protocols_tree[MAX_PROTOCOLS + 1];
+-GtkListStore *protocols_tree_model[MAX_PROTOCOLS + 1];
++extern GtkWidget *protocols_tree[MAX_PROTOCOLS + 1];
++extern GtkListStore *protocols_tree_model[MAX_PROTOCOLS + 1];
+ 
+ GtkWidget* gtk_i_create_Main (struct gtk_s_helper *);
+ GtkWidget* gtk_i_create_opendialog (struct gtk_s_helper *);
+--- a/src/ncurses-callbacks.h
 b/src/ncurses-callbacks.h
+@@ -77,8 +77,8 @@
+ #define CAN_RESIZE 1
+ #endif
+ 
+-u_int8_t pointer[MAX_PROTOCOLS];
+-WINDOW *info_window;
++extern u_int8_t pointer[MAX_PROTOCOLS];
++extern WINDOW *info_window;
+ 
+ voidncurses_c_refresh_mwindow(u_int8_t, WINDOW *, u_int8_t, struct 
term_node *);
+ voidncurses_c_refresh_bwindow(u_int8_t, WINDOW 

Bug#924418: libvirt-daemon-system: apparmor prevents libvirtd from spawning VMs

[Zrin]

Package: libvirt-daemon-system
Version: 6.6.0-2
Followup-For: Bug #924418

Dear Maintainer,

I've just hit the bug with a similar cause:
virt-aa-helper fails to create a parasble apparmor profile due to regex
meta characters in the path.

How to reproduce:
Try to, in the VM definition, attach an .iso file that contains e.g. {}
charaters in the name to the virtual CDROM.
apparmor_parser will fail to parse the profile because {} are regex
meta-characters.

Anyway, virt-aa-helper needs better error message propagation.

Best regards,
Zrin

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

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

Versions of packages libvirt-daemon-system depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.74
ii  gettext-base   0.19.8.1-10
ii  iptables   1.8.5-3
ii  libc6  2.31-3
ii  libgcc-s1  10.2.0-9
ii  libglib2.0-0   2.66.0-2
ii  libvirt-clients6.6.0-2
ii  libvirt-daemon 6.6.0-2
ii  libvirt-daemon-system-systemd  6.6.0-2
ii  libvirt0   6.6.0-2
ii  libxml22.9.10+dfsg-6
ii  logrotate  3.16.0-3
ii  policykit-10.105-29

Versions of packages libvirt-daemon-system recommends:
ii  dmidecode3.2-4
ii  dnsmasq-base [dnsmasq-base]  2.82-1
ii  iproute2 5.8.0-1
ii  mdevctl  0.69-1
ii  parted   3.3-4

Versions of packages libvirt-daemon-system suggests:
ii  apparmor2.13.4-3
pn  auditd  
pn  nfs-common  
pn  open-iscsi  
pn  pm-utils
pn  radvd   
ii  systemd 246.6-1
pn  systemtap   
pn  zfsutils

-- Configuration Files:
/etc/apparmor.d/usr.lib.libvirt.virt-aa-helper changed [not included]
[Access to other files that would be listed here was not possible -
permision denied]

-- debconf information:
  libvirt-daemon-system/id_warning: true

Bug#908681: libsane1: pointless package rename

[Vincent Lefevre]

On 2020-10-05 15:35:23 +0200, Gianfranco Costamagna wrote:
> In this case, the symbols were private, and incorrectly exposed
> outside, so removing them is "safe" as long as nobody uses them.

I've looked at the repository, and in more details, they were
incorrectly exposed outside via the symbol table, but not via
a header file.[*] Thus I agree that there is no chance that
anyone uses them via the API.

[*] as the issue was fixed only by adding "static":

commit 62614a46609d85f03d9b73a826f8c94a3554e2b1
Author: Povilas Kanapickas 
Date:   2020-03-28 21:08:39 +0100

sanei_usb: Use internal linkage for private static variables

diff --git a/sanei/sanei_usb.c b/sanei/sanei_usb.c
index db0f452ae..291a48024 100644
--- a/sanei/sanei_usb.c
+++ b/sanei/sanei_usb.c
@@ -195,15 +195,15 @@ static sanei_usb_testing_mode testing_mode = 
sanei_usb_testing_mode_disabled;
 
 #if WITH_USB_RECORD_REPLAY
 static int testing_development_mode = 0;
-int testing_known_commands_input_failed = 0;
-unsigned testing_last_known_seq = 0;
-SANE_String testing_record_backend = NULL;
-xmlNode* testing_append_commands_node = NULL;
+static int testing_known_commands_input_failed = 0;
+static unsigned testing_last_known_seq = 0;
+static SANE_String testing_record_backend = NULL;
+static xmlNode* testing_append_commands_node = NULL;
 
 // XML file from which we read testing data
-SANE_String testing_xml_path = NULL;
-xmlDoc* testing_xml_doc = NULL;
-xmlNode* testing_xml_next_tx_node = NULL;
+static SANE_String testing_xml_path = NULL;
+static xmlDoc* testing_xml_doc = NULL;
+static xmlNode* testing_xml_next_tx_node = NULL;
 #endif // WITH_USB_RECORD_REPLAY
 
 #if defined(HAVE_LIBUSB_LEGACY) || defined(HAVE_LIBUSB)

> So, yes, the ABI changed, but the change was not reflected into
> a real issue for any Debian application, or any custom-built
> application.

Actually, though the symbol table changed, the ABI didn't.

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

Bug#971680: /usr/share/gcc-10/python/ should go in a dev package

[Josh Triplett]

On Mon, Oct 05, 2020 at 10:22:49PM +0200, Matthias Klose wrote:
> On 10/5/20 8:35 PM, Josh Triplett wrote:
> > On Mon, Oct 05, 2020 at 12:08:28PM +0200, Matthias Klose wrote:
> >> On 10/5/20 10:39 AM, Josh Triplett wrote:
> >>> On Mon, Oct 05, 2020 at 09:32:28AM +0200, Matthias Klose wrote:
>  On 10/4/20 11:09 PM, Josh Triplett wrote:
> > libstdc++6, installed on every system due to dependencies, contains
> > various Python scripts for GDB under /usr/share/gcc-10/python/ . These
> > scripts should go in a dev package, not in a library package.
> 
>  There's no part in the policy that requires debugging scripts to be part 
>  of the
>  development package, and I think it's not very intuitive.  There's also 
>  no
>  advocated policy if these scripts should be part of a dbgsym package, and
>  there's no debhelper support to add these files to a dbgsym package.  So 
>  yes, I
>  think the library package is the correct package to have these files.  
>  It makes
>  the library package a little bit bigger, but these don't hurt there.
> >>>
> >>> There's precedent for things related to debugging a particular library
> >>> going into the -dev package for that library. For example,
> >>> /usr/share/gdb/auto-load/lib/x86_64-linux-gnu/libpthread-2.31.so-gdb.py
> >>> lives in libc6-dev, not in libc6.
> >>
> >> these were only added later than the libstdc++6 ones, so no precedence.
> > 
> > I mean that it's precedent for putting debug-related things in -dev
> > packages, not that it came before libstdc++6 specifically. Would it be a
> > *problem* to put these files in the -dev package?
> 
> usually people are used to to install the -dbg packages for debugging.  How
> would you tell people when to install all corresponding -dev packages?

That's fair.

If you think it makes sense for library-specific gdb extensions to go in
-dbgsym packages, I think that'd be perfectly reasonable; then, when you
install all the dbgsym packages for the libraries a program links to (or
for installed libraries), you'd get all the debugging extensions as
well.

And it doesn't seem like it'd be all that hard for debhelper to
learn to put /usr/share/gdb/auto-load/$library_path files into -dbgsym
packages. (You'd still have to give debhelper a hint for the additional module
libstdc++6 wants.)

I'll file a bug on debhelper asking for a feature to put
/usr/share/gdb/auto-load/$library_path into -dbgsym packages, along with
an extension point to add more files there, and then I'll block this bug
with that one.

- Josh Triplett

Bug#971724: Please support putting /usr/share/gdb/auto-load/$lib_path files into -dbgsym packages

[Josh Triplett]

Package: debhelper
Version: 13.2.1
Severity: wishlist
X-Debbugs-Cc: j...@joshtriplett.org

Packages can ship Python scripts in
/usr/share/gdb/auto-load/${lib_path}-gdb.py to provide extensions for
gdb to help debug programs that use that library. For instance,
/usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28-gdb.py
gets loaded when debugging a program using
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28 .

These files are needed only when debugging programs using those
libraries. Thus, it makes sense to put them in -dbgsym packages, because
they're desirable on exactly the systems that want the -dbgsym packages:
a system that wants to debug a program using the corresponding library.

Could (a new compat level of) debhelper install files named
/usr/share/gdb/auto-load/${some_library_path}-gdb.py into the -dbgsym
package corresponding to the package that installs ${some_library_path}?


In addition, some packages want to import additional scripts from that
auto-load file, so it'd be helpful to be able to provide a list of
additional files to put in the -dbgsym package.

Thanks,
Josh Triplett

Bug#933264: gradle: Nearly 3-year-old version almost useless

[Markus Koschany]

Hi,

Am 05.10.20 um 23:07 schrieb Nick Jacobs:
> Package: gradle
> Version: 4.4.1-12
> Followup-For: Bug #933264
> X-Debbugs-Cc: halbtaxabo-...@yahoo.com
> 
> Dear Maintainer,
> 
> I tried to use gradle to build an application called keenwrite.
> Build failed with the error message that the build requires at
> least version 5.1 of gradle. (The current version is 6.6).
> The version installed (even in sid) is 4.4.1.

Short version is: We are fully aware gradle in Debian is not up-to-date
but it is much more complicated. Did you know that Gradle, a Java build
tool, now requires Kotlin to build Java packages? Did you know that in
Debian every piece of software is self-contained and we package every
dependency independently, so that you don't have to rely on random
binary packages from the internet? We need gradle to build packages from
source but it is not feasible for us to support all use cases outside of
Debian. We encourage you to get involved in Debian. Otherwise there are
 alternatives like Maven that provide a similar experience for most Java
developers but are far easier to maintain. And yes, "we" are a handful
of contributors.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#971722: thunderbird: fails to import GPG private key with only subkeys

[Carsten Schoenert]

Control: forward -1 https://bugzilla.mozilla.org/show_bug.cgi?id=1654893
Control: tags -1 upstream

Hello Baptiste,

Am 05.10.20 um 22:45 schrieb Baptiste Beauplat:
> Thunderbird 78.3.1 fails to import GPG private keys that have their
> primary secret key striped.
> 
> The import wizard gets stuck in a loop asking for the passphrase (even
> if the key isn't protected).
> 
> To reproduce:
> 
> 1. create a gpg key
> 2. add a signing subkey
> 3. export the key with: gpg --armor --export-secret-keys 0x123456789 >
> full-key.gpg
> 4. export the key with: gpg --armor --export-secret-subkeys 0x123456789
>> striped-key.gpg
> 
> The first one imports correctly, not the second one.

this issue is grounded in missing support within the used RNP library.
But also probably some needed extra option for configuration how TB
should behave here.

Mor information can be found in the linked upstream issue.

---
Regards
Carsten Schoenert

Bug#971707: lintian: breakout-link has lots of false positives, in particular for non-FHS trees below /usr/lib

[Bill Allombert]

On Mon, Oct 05, 2020 at 04:22:17PM +0100, Simon McVittie wrote:
> Package: lintian
> Version: 2.97.0
> Severity: normal
> 
> The new breakout-link tag (warning about symlinks escaping from /usr/lib)
> seems to have a lot of false positives.
> 
> In particular, the pattern I'm interested in for this bug report
> is that some upstream packages expect to be installed in a non-FHS
> layout where a single directory mixes executables with libraries,
> or mixes architecture-dependent executables and libraries with
> architecture-independent data, or mixes configuration with static
> files. This is very, very common in games, which are typically designed
> to installed in an arbitrary relocatable directory of the user's choice.
> It's also done in larger packages like OpenJDK and LibreOffice, in
> GNUstep apps (each of which is designed to be self-contained directory),
> and in many other packages.
> 
> The long-standing convention for dealing with these packages in Debian has
> been to put their non-FHS tree in a subdirectory of /usr/lib. Files that
> would ordinarily be valid to appear in /usr/lib are shipped there as
> regular files, while files that would not be valid in /usr/lib are shipped
> as symlinks to a regular file in another location. For example:
> 
>  usr/lib/openarena-server/baseoa/etc/openarena-server -> 
> etc/openarena-server
>  usr/lib/openarena-server/baseoa/pak0.pk3 -> 
> usr/share/games/openarena/baseoa/pak0.pk3
> 
> Meanwhile, system integration (for example making the application appear
> in /usr/share/applications and in /usr/bin) is done either via wrapper
> scripts, or by moving or symlinking individual integration files.
> 
> I don't think it's a good idea to encourage maintainers to patch these
> packages to use a FHS layout if their upstream would not accept that change.
> Unnecessary delta from upstream increases the number of bugs that exist
> only in Debian, leading to strained relations between upstreams and
> downstreams; and changing the layout has no real benefit for our users in
> cases like this, because we're installing the real files (such as
> /etc/openarena-server/server.cfg and .../baseoa/pak0.pk3) in the locations
> they should normally have.
> 
> The tag description says:
> 
> At least for /usr/lib, it is usually an error and may confuse
> some tools.
> 
> [citation needed]? Which tools does it confuse, and which bugs does this
> check catch? I don't think setting the level to warning is justified
> unless a check genuinely prevents identifiable bugs.

I fully agree with Simon. The rationale for this warning 
is lacking and there is no consensus in Debian this is a problem. Indeed
I would expect the consensus is that it is correct in a lot of common
situation.

Tools that are still confused by symlinks in 2020 need
to be fixed, not the other way around.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#971666: mkdocs-bootstrap: broken with mkdocs 1.0

[Brian May]

Dmitry Shachnev  writes:

> I would be happy to update the packaging to the latest upstream
> release (1.1) and upload it, if the maintainer (Brian) wants so.

That is good with me.

Thanks.
-- 
Brian May 

Bug#971723: RFS: mp3report/1.0.3-1 -- Script to create an HTML report of MP3 files in a directory

[François Mazen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "mp3report":

 * Package name: mp3report
   Version : 1.0.3-1
   Upstream Author : David Parker 
 * URL : http://mp3report.sourceforge.net
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/mzf/mp3report
   Section : utils

It builds those binary packages:

  mp3report - Script to create an HTML report of MP3 files in a
directory

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

  https://mentors.debian.net/package/mp3report/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/m/mp3report/mp3report_1.0.3-1.dsc

Changes since the last upload:

 mp3report (1.0.3-1) unstable; urgency=medium
 .
   * New upstream version.
   * Update watch file to new GitHub repository.
   * Remove patches applied upstream:
   - check_folder_read_permission.patch
   - fix_typo_in_manual_page.patch
   - fix_uninitialized_variables.diff
   * Generate documentation in debian/tmp instead of in source folder.
   * Add autopkgtests.

Regards,

Bug#971722: thunderbird: fails to import GPG private key with only subkeys

[Baptiste Beauplat]

Package: thunderbird
Severity: normal

Dear maintainer,

Thunderbird 78.3.1 fails to import GPG private keys that have their
primary secret key striped.

The import wizard gets stuck in a loop asking for the passphrase (even
if the key isn't protected).

To reproduce:

1. create a gpg key
2. add a signing subkey
3. export the key with: gpg --armor --export-secret-keys 0x123456789 >
full-key.gpg
4. export the key with: gpg --armor --export-secret-subkeys 0x123456789
> striped-key.gpg

The first one imports correctly, not the second one.
-- 
Baptiste BEAUPLAT - lyknode

Bug#971680: /usr/share/gcc-10/python/ should go in a dev package

[Matthias Klose]

On 10/5/20 8:35 PM, Josh Triplett wrote:
> On Mon, Oct 05, 2020 at 12:08:28PM +0200, Matthias Klose wrote:
>> On 10/5/20 10:39 AM, Josh Triplett wrote:
>>> On Mon, Oct 05, 2020 at 09:32:28AM +0200, Matthias Klose wrote:
 On 10/4/20 11:09 PM, Josh Triplett wrote:
> libstdc++6, installed on every system due to dependencies, contains
> various Python scripts for GDB under /usr/share/gcc-10/python/ . These
> scripts should go in a dev package, not in a library package.

 There's no part in the policy that requires debugging scripts to be part 
 of the
 development package, and I think it's not very intuitive.  There's also no
 advocated policy if these scripts should be part of a dbgsym package, and
 there's no debhelper support to add these files to a dbgsym package.  So 
 yes, I
 think the library package is the correct package to have these files.  It 
 makes
 the library package a little bit bigger, but these don't hurt there.
>>>
>>> There's precedent for things related to debugging a particular library
>>> going into the -dev package for that library. For example,
>>> /usr/share/gdb/auto-load/lib/x86_64-linux-gnu/libpthread-2.31.so-gdb.py
>>> lives in libc6-dev, not in libc6.
>>
>> these were only added later than the libstdc++6 ones, so no precedence.
> 
> I mean that it's precedent for putting debug-related things in -dev
> packages, not that it came before libstdc++6 specifically. Would it be a
> *problem* to put these files in the -dev package?

usually people are used to to install the -dbg packages for debugging.  How
would you tell people when to install all corresponding -dev packages?

>>> There may be a better place for them, but this seems like a reasonable
>>> approach.
>>>
>>> My concern is that I'm trying to build a minimal Debian-based system,
>>> libstdc++6 is hard-required because among other things apt depends on
>>> it, and it's shipping ~132k of Python scripts.
>>
>> if that's a minimal system, you probably could use the same technique like
>> probably removing files in /usr/share/doc.
> 
> That's a workaround, and it'd be nice if it just needed to cover a few
> general locations shared among many packages, not individual files
> from one package.

agreed for that case.  However usually all these pretty printer files are
installed in the autoload location.

Bug#948706: Polite ping

[Julian Gilbey]

On Mon, Oct 05, 2020 at 07:53:05AM +0100, Julian Gilbey wrote:
> On Mon, Oct 05, 2020 at 12:57:59AM +0100, Julian Gilbey wrote:
> > 4) The output of "greylist list" is now somewhat mangled: the "Data"
> > field shows something like:
> > [ ' 1 . 2 . 3 . 4 / 2 4 ' ,   ' i n f o @ e x a m p l e . c o m ' ,   ' j d 
> > g @ d e b i a n . o r g ' ]
> > rather than
> > 1.2.3.4/24  i...@example.com  j...@debian.org
> > I guess this should be easy to fix?
> 
> Oh, it turns out that this is not so straightforward: the command
> greylist add 1.2.3.4/24  i...@example.com  j...@debian.org
> yields the following line in /var/lib/greylistd/triplets, which will
> probably break things:
> 4921632547390726349 = 1.2.3.4/24 i...@example.com j...@debian.org
> 
> So it seems the triplets need turning into simple strings before they
> are stored in the triplets file / triplets hash, rather than being
> stored as Python literals with lots of excess spaces.

Hi Benedikt and Thorsten,

I've found the cause of this and made a pull request on your GitHub
repository.

If you're happy with it or a week or so passes and I don't hear from
you or the maintainer (Thorsten), I'll upload an NMU to the delayed
queue.

Thorsten: there are many more changes here than would usually be
permitted in an NMU.  But the package is currently completely broken
and won't get into testing.  This set of patches fixes the critical
issues and several other lintian warnings (as well as Benedikt's other
cleaning-up).  The big remaining lintian warning is that there is no
systemd service file.  This will take some effort to do, as systemd
will happily look after the socket creation, but then the Python code
will need adapting to accept the systemd socket rather than creating
one itself.  I've never done this and don't really have time right now
to do so.

Best wishes,

   Julian

Bug#969095: RM: mysql-5.7 -- ROM; superseded by mysql-8.0

[Robie Basak]

On Sat, Oct 03, 2020 at 11:59:26AM -0700, Sean Whitton wrote:
> Looks like there is still a rdep on pytest-services.

Sorry. It looks like I missed searching for reverse build dependencies.
I filed a blocking bug
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971670 against
src:pytest-services for this.

Robie


signature.asc
Description: PGP signature

Bug#971721: mime-support: missing dependency on perl

[Niko Tyni]

Package: mime-support
Version: 3.64
Severity: serious

On Mon, Oct 05, 2020 at 09:09:01AM +0200, Adam Borowski wrote:
> On Mon, Oct 05, 2020 at 01:52:19PM +1000, Jai Flack wrote:
> > Forgive me if this is an ignorant question but isn't mailcap missing
> > dependencies? If I build, then install all three and then ask apt about
> > mailcap's dependencies it gives:
> 
> [...]
> 
> > But the script it installs clearly depends on Perl:
> > 
> > #! /usr/bin/perl
> 
> > Is this an exception because Perl is part of the base system and assumed
> > to always be installed?
> 
> perl-base is essential.

Indeed.

However, the script in question (/usr/bin/run-mailcap) uses modules not
shipped in perl-base.

  use Encode qw(decode);
  use I18N::Langinfo qw(langinfo CODESET);

So yes, the mime-support package in sid is missing a dependency on perl.
This seems to have regressed in 3.55 with the fix for #682900.

Filing a bug about this, thanks for noticing.
-- 
Niko Tyni   nt...@debian.org

Bug#971718: dvdtape FTCBFS: builds for the build architecture

[Helmut Grohne]

Source: dvdtape
Version: 1.6-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

dvdtape fails to cross build from source, because it does not pass cross
tools to make. The easiest way of doing so - using dh_auto_build - makes
dvdtape cross buildable. Please consider applying the attached patch.

Helmut
diff -u dvdtape-1.6/debian/changelog dvdtape-1.6/debian/changelog
--- dvdtape-1.6/debian/changelog
+++ dvdtape-1.6/debian/changelog
@@ -1,3 +1,10 @@
+dvdtape (1.6-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 04 Oct 2020 20:51:01 +0200
+
 dvdtape (1.6-2) unstable; urgency=medium
 
   * Update debhelper compat level. Closes: #800175
diff -u dvdtape-1.6/debian/rules dvdtape-1.6/debian/rules
--- dvdtape-1.6/debian/rules
+++ dvdtape-1.6/debian/rules
@@ -9,7 +9,7 @@
 
 build-stamp:
dh_testdir
-   make
+   dh_auto_build
touch build-stamp
 
 clean:

Bug#971720: tumbler FTCBFS: gtk-doc runs host code

[Helmut Grohne]

Source: tumbler
Version: 0.2.7-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

tumbler fails to cross build from source, because it runs host code via
gtk-doc. Practically, gtk-doc doesn't work at all in cross builds.
Fortunately, the generated documentation is separated into an arch:all
package here, so we can just disable gtk-doc in arch-only builds (such
as cross builds) and make tumbler cross buildable. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru tumbler-0.2.8/debian/changelog 
tumbler-0.2.8/debian/changelog
--- tumbler-0.2.8/debian/changelog  2020-04-30 09:00:38.0 +0200
+++ tumbler-0.2.8/debian/changelog  2020-10-05 20:20:04.0 +0200
@@ -1,3 +1,10 @@
+tumbler (0.2.8-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: disable gtk-doc for arch-only builds. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 05 Oct 2020 20:20:04 +0200
+
 tumbler (0.2.8-2) unstable; urgency=medium
 
   [ Debian Janitor ]
diff --minimal -Nru tumbler-0.2.8/debian/rules tumbler-0.2.8/debian/rules
--- tumbler-0.2.8/debian/rules  2020-04-30 09:00:38.0 +0200
+++ tumbler-0.2.8/debian/rules  2020-10-05 20:19:49.0 +0200
@@ -14,7 +14,7 @@
dh_missing --list-missing -X .la
 
 override_dh_auto_configure:
-   dh_auto_configure -- --enable-gtk-doc
+   dh_auto_configure -- --$(if $(filter tumbler-common,$(shell 
dh_listpackages)),en,dis)able-gtk-doc
 
 %:
dh $@

Bug#971719: stress-ng: please build verbosely

[Helmut Grohne]

Source: stress-ng
Version: 0.11.21-1
Tags: patch

I looked into why stress-ng would fail cross building and found that the
build log missed all the compiler invocations. The Debian policy
recommends building verbosely by default. I'm attaching a patch to
implement that for your convenience. The upstream build keeps building
quietly by default. The Debian build is verbose unless you pass
DEB_BUILD_OPTIONS=terse as recommended by the policy.

Helmut
diff --minimal -Nru stress-ng-0.11.21/debian/changelog 
stress-ng-0.11.21/debian/changelog
--- stress-ng-0.11.21/debian/changelog  2020-09-16 23:58:21.0 +0200
+++ stress-ng-0.11.21/debian/changelog  2020-10-05 06:53:49.0 +0200
@@ -1,3 +1,10 @@
+stress-ng (0.11.21-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Enable verbose build logs. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 05 Oct 2020 06:53:49 +0200
+
 stress-ng (0.11.21-1) unstable; urgency=medium
 
   [Colin Ian King]
diff --minimal -Nru stress-ng-0.11.21/debian/patches/series 
stress-ng-0.11.21/debian/patches/series
--- stress-ng-0.11.21/debian/patches/series 1970-01-01 01:00:00.0 
+0100
+++ stress-ng-0.11.21/debian/patches/series 2020-10-05 06:15:45.0 
+0200
@@ -0,0 +1 @@
+verbose.patch
diff --minimal -Nru stress-ng-0.11.21/debian/patches/verbose.patch 
stress-ng-0.11.21/debian/patches/verbose.patch
--- stress-ng-0.11.21/debian/patches/verbose.patch  1970-01-01 
01:00:00.0 +0100
+++ stress-ng-0.11.21/debian/patches/verbose.patch  2020-10-05 
06:53:49.0 +0200
@@ -0,0 +1,133 @@
+--- stress-ng-0.11.21.orig/Makefile
 stress-ng-0.11.21/Makefile
+@@ -33,6 +33,15 @@
+   -Wno-missing-braces -Wno-sign-compare -Wno-multichar
+ endif
+ 
++# Verbosity
++ifeq ($(VERBOSE),)
++V=@
++Q=@
++else
++V=
++Q=@#
++endif
++
+ GREP = grep
+ #
+ # SunOS requires special grep for -e support
+@@ -361,16 +370,16 @@
+ .o: stress-ng.h Makefile
+ 
+ .c.o:
+-  @echo "CC $<"
+-  @$(CC) $(CFLAGS) -c -o $@ $<
++  $(Q)echo "CC $<"
++  $(V)$(CC) $(CFLAGS) -c -o $@ $<
+ 
+ stress-ng: $(OBJS)
+-  @echo "LD $@"
+-  @$(CC) $(CPPFLAGS) $(CFLAGS) $(OBJS) -lm $(LDFLAGS) -o $@
+-  @sync
++  $(Q)echo "LD $@"
++  $(V)$(CC) $(CPPFLAGS) $(CFLAGS) $(OBJS) -lm $(LDFLAGS) -o $@
++  $(V)sync
+ 
+ makeconfig:
+-  @if [ ! -e config ]; then \
++  $(V)if [ ! -e config ]; then \
+   STATIC=$(STATIC) $(MAKE) -f Makefile.config; \
+   fi
+ 
+@@ -379,25 +388,25 @@
+ #  parser output
+ #
+ apparmor-data.o: usr.bin.pulseaudio.eg
+-  @$(APPARMOR_PARSER) -Q usr.bin.pulseaudio.eg  -o apparmor-data.bin
+-  @echo "#include " > apparmor-data.c
+-  @echo "char g_apparmor_data[]= { " >> apparmor-data.c
+-  @od -tx1 -An -v < apparmor-data.bin | \
++  $(V)$(APPARMOR_PARSER) -Q usr.bin.pulseaudio.eg  -o apparmor-data.bin
++  $(V)echo "#include " > apparmor-data.c
++  $(V)echo "char g_apparmor_data[]= { " >> apparmor-data.c
++  $(V)od -tx1 -An -v < apparmor-data.bin | \
+   sed 's/[0-9a-f][0-9a-f]/0x&,/g' | \
+   sed '$$ s/.$$//' >> apparmor-data.c
+-  @echo "};" >> apparmor-data.c
+-  @echo "const size_t g_apparmor_data_len = sizeof(g_apparmor_data);" >> 
apparmor-data.c
+-  @echo "CC $<"
+-  @$(CC) -c apparmor-data.c -o apparmor-data.o
+-  @rm -rf apparmor-data.c apparmor-data.bin
++  $(V)echo "};" >> apparmor-data.c
++  $(V)echo "const size_t g_apparmor_data_len = sizeof(g_apparmor_data);" 
>> apparmor-data.c
++  $(Q)echo "CC $<"
++  $(V)$(CC) -c apparmor-data.c -o apparmor-data.o
++  $(V)rm -rf apparmor-data.c apparmor-data.bin
+ 
+ #
+ #  extract the PER_* personality enums
+ #
+ personality.h:
+-  @$(CPP) $(CONFIG_CFLAGS) core-personality.c | $(GREP) -e "PER_[A-Z0-9]* 
=.*," | cut -d "=" -f 1 \
++  $(V)$(CPP) $(CONFIG_CFLAGS) core-personality.c | $(GREP) -e 
"PER_[A-Z0-9]* =.*," | cut -d "=" -f 1 \
+   | sed "s/.$$/,/" > personality.h
+-  @echo "MK personality.h"
++  $(Q)echo "MK personality.h"
+ 
+ stress-personality.c: personality.h
+ 
+@@ -406,23 +415,23 @@
+ #  so we can check if these enums exist
+ #
+ io-uring.h:
+-  @$(CPP) $(CONFIG_CLFAGS) core-io-uring.c  | grep IORING_OP | sed 
's/,//' | \
++  $(V)$(CPP) $(CONFIG_CLFAGS) core-io-uring.c  | grep IORING_OP | sed 
's/,//' | \
+   sed 's/IORING_OP_/#define HAVE_IORING_OP_/' > io-uring.h
+-  @echo "MK io-uring.h"
++  $(Q)echo "MK io-uring.h"
+ 
+ stress-io-uring.c: io-uring.h
+ 
+ core-perf.o: core-perf.c core-perf-event.c
+-  @$(CC) $(CFLAGS) -E core-perf-event.c | grep "PERF_COUNT" | \
++  $(V)$(CC) $(CFLAGS) -E core-perf-event.c | grep "PERF_COUNT" | \
+   sed 's/,/ /' | sed s/'^ *//' | \
+   awk {'print "#define _SNG_" $$1 " (1)"'} > core-perf-event.h
+-  @echo CC $<
+-  @$(CC) $(CFLAGS) -c -o $@ $<
++  $(Q)echo CC $<
++  $(V)$(CC) $(CFLAGS) -c -o $@ $<
+ 
+ stress-vecmath.o: stress-vecmath.c
+- 

Bug#971717: src:rust-sequoia-openpgp: fails to migrate to testing for too long: unsatisfied B-D

[Paul Gevers]

Source: rust-sequoia-openpgp
Version: 0.17.0-5
Severity: serious
Control: close -1 0.18.0-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 971099

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package
src:rust-sequoia-openpgp in its current version in unstable has been
trying to migrate for 60 days [2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=rust-sequoia-openpgp




signature.asc
Description: OpenPGP digital signature

Bug#971715: src:rust-sequoia-sqv: fails to migrate to testing for too long: unsatisfied B-D

[Paul Gevers]

Source: rust-sequoia-sqv
Version: 0.17.0-1
Severity: serious
Control: close -1 0.18.0-2
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 971103

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package
src:rust-sequoia-sqv in its current version in unstable has been trying
to migrate for 60 days [2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=rust-sequoia-sqv




signature.asc
Description: OpenPGP digital signature

Bug#971714: src:libiscsi: fails to migrate to testing for too long: FTBFS

[Paul Gevers]

Source: libiscsi
Version: 1.19.0-1
Severity: serious
Control: close -1 1.19.0-2
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 969074

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:libiscsi in
its current version in unstable has been trying to migrate for 61 days
[2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=libiscsi




signature.asc
Description: OpenPGP digital signature

Bug#971716: src:rust-sequoia-sop: fails to migrate to testing for too long: unsatisfied B-D

[Paul Gevers]

Source: rust-sequoia-sop
Version: 0.17.0-2
Severity: serious
Control: close -1 0.18.0-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 971105

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package
src:rust-sequoia-sop in its current version in unstable has been trying
to migrate for 60 days [2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=rust-sequoia-sop




signature.asc
Description: OpenPGP digital signature

Bug#971693: webext-ublock-origin-firefox not compatible with non-empty user.js file

[Markus Koschany]

Hello,

On Mon, 05 Oct 2020 09:58:26 +0200 pdorm...@free.fr wrote:
> Package: webext-ublock-origin-firefox
> Version: 1.30.0+dfsg-1
> Severity: normal
> 
> Dear Maintainer,
> 
> The bug is similar to #969123: ublock-origin is not started unless disabling
> and re-enabling the addon or creating a new profile. But the latter fails as
> soon as a user.js is filled with some preference properties (I tested all kind
> of properties, it fails as soon as user.js is non empty).

I have searched for a solution for this kind of problem but the more I
dig into it the more I come to the conclusion that this kind of behavior
is intentional. If you normally install addons via Firefox' addon
feature, Firefox will tell you to restart the browser when you make an
upgrade. It is comparable to Debian upgrades, some of them may require a
restart and it can't be avoided.

Regarding the user.js file: I have just created one in my profile
directory with a single line to change a setting, but I couldn't
reproduce this problem on Firefox 78.3 with uBo 1.30.0 in stable. My
workaround would be: save all your uBo settings (if you have made any
changes, better safe than sorry), shut down Firefox, then remove
user.js. Then restart Firefox and try to enable/disable the addon again.
Afterwards you can readd your custom user.js file.

If you send me your user.js file I can try to reproduce the problem in
unstable tomorrow.

There is also an addon debug mode for Firefox. This one allows you to
skip restarts and you can make modifications to Firefox and your addon
which get instantly applied.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#971666: mkdocs-bootstrap: broken with mkdocs 1.0

[Dmitry Shachnev]

Hi,

On Sun, Oct 04, 2020 at 11:56:56AM -0300, Antonio Terceiro wrote:
> Dear Maintainer,
>
> the current version of mkdocs-bootstrap in the archive is broken and
> does not work with the version of mkdocs that we have.

Yes, unfortunately it is probably also broken in stable. Let's fix it at least
for Bullseye.

> [...]
>
> I see that the git repository has a new upstream version that would
> work, but hasn't been uploaded for almost 2 years. I'm copying Dmitry,
> who did that work, in this bug report.

I would be happy to update the packaging to the latest upstream release (1.1)
and upload it, if the maintainer (Brian) wants so.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#971027: gcc-10: regression in 10.2.0-9 causes segmentation fault in vlc

[Sebastian Ramacher]

On 2020-10-05 11:51:59 +0200, Matthias Klose wrote:
> On 9/30/20 12:38 AM, Sebastian Ramacher wrote:
> > On 2020-09-30 00:01:52 +0200, Ahzo wrote:
> >>
> >> Sep 29, 2020, 07:14 by rguent...@suse.de:
> >>
> >>> I've filed > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97236
> >>>
> >>> Someone needs to create a testcase or provide instructions how to
> >>> reproduce the bug.
> >>>
> >>
> >> Thanks for taking care of this issue upstream.
> >>
> >> Sep 29, 2020, 15:18 by d...@debian.org:
> >>
> >>> On 9/29/20 12:30 PM, Matthias Klose wrote:
> >>> upstream now has a reduced test case.
> >>>
> >>> 10.2.0-12 is uploaded, reverting that commit for now.
> >>>
> >> Thanks for the quick upload. This should prevent further fallout, until 
> >> upstream finds a better solution.
> > 
> > I've confirmed that vlc works again after rebuilding it with gcc-10
> > 10.2.0-12 and scheduled binNMUs of vlc which should hit the archive
> > soon.
> 
> please could also recheck with 10.2.0-14 from experimental, with the two
> reversions undone, and the new fix backported to the gcc-10 branch?

Local builds with -14 also work correctly. Thanks

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#971680: /usr/share/gcc-10/python/ should go in a dev package

[Josh Triplett]

On Mon, Oct 05, 2020 at 12:08:28PM +0200, Matthias Klose wrote:
> On 10/5/20 10:39 AM, Josh Triplett wrote:
> > On Mon, Oct 05, 2020 at 09:32:28AM +0200, Matthias Klose wrote:
> >> On 10/4/20 11:09 PM, Josh Triplett wrote:
> >>> libstdc++6, installed on every system due to dependencies, contains
> >>> various Python scripts for GDB under /usr/share/gcc-10/python/ . These
> >>> scripts should go in a dev package, not in a library package.
> >>
> >> There's no part in the policy that requires debugging scripts to be part 
> >> of the
> >> development package, and I think it's not very intuitive.  There's also no
> >> advocated policy if these scripts should be part of a dbgsym package, and
> >> there's no debhelper support to add these files to a dbgsym package.  So 
> >> yes, I
> >> think the library package is the correct package to have these files.  It 
> >> makes
> >> the library package a little bit bigger, but these don't hurt there.
> > 
> > There's precedent for things related to debugging a particular library
> > going into the -dev package for that library. For example,
> > /usr/share/gdb/auto-load/lib/x86_64-linux-gnu/libpthread-2.31.so-gdb.py
> > lives in libc6-dev, not in libc6.
> 
> these were only added later than the libstdc++6 ones, so no precedence.

I mean that it's precedent for putting debug-related things in -dev
packages, not that it came before libstdc++6 specifically. Would it be a
*problem* to put these files in the -dev package?

> > There may be a better place for them, but this seems like a reasonable
> > approach.
> > 
> > My concern is that I'm trying to build a minimal Debian-based system,
> > libstdc++6 is hard-required because among other things apt depends on
> > it, and it's shipping ~132k of Python scripts.
> 
> if that's a minimal system, you probably could use the same technique like
> probably removing files in /usr/share/doc.

That's a workaround, and it'd be nice if it just needed to cover a few
general locations shared among many packages, not individual files
from one package.

Bug#971642: logidee-tools: Fails to build w/ latest TeX Live checkout

[Hilmar Preuße]

Am 05.10.2020 um 10:31 teilte Raphael Hertzog mit:

On Sun, 04 Oct 2020, Hilmar Preusse wrote:


Hi Raphael,

I'm able to reproduce the issue here in a Debian unstable 
installation and I could fix it by loading the longtable LaTeX

package in the cls file.


Care to share the patch?

Attached is the updated LaTeX class file an the updated topmost 
Makefile.generic .


- the class file needs to be updated to get the longtable package loaded.
- the Makefile needs to be modified; pdf2pdf needs to be called w/ an 
additional option.


I'm able to build the new source package in an sbuilder, however I did 
not test if the resulting pdf looks as expected.


Hilmar
--
#206401 http://counter.li.org
%% This file is part of logidee-tools
%% http://www.logidee.com/
%%
%% $Id$
%%
%% See the LICENSE file for the copyright notice
%%
%% If you change this file, please keep the acknowledgement
%% of the work of Logidee and the other persons involved

\NeedsTeXFormat{LaTeX2e}[1995/12/01]
\ProvidesClass{logidoc}
  [2000/19/04 v1.0
 Standard Default logidee-tools document class]
\usepackage{color}
\usepackage{ifthen}
\usepackage{fancyhdr}
\usepackage{fancybox}
\usepackage{graphicx}
\usepackage{pstricks}
\usepackage{alltt}
\usepackage{verbatim}
\usepackage{pifont}
\usepackage{everyshi}
\usepackage{float}
\usepackage{eurosym}
\usepackage{longtable}

\usepackage[english,french,german]{babel}

\usepackage{ucs}
\usepackage[utf8x]{inputenc}
\usepackage[T1]{fontenc}

\usepackage{courier}

%\newrgbcolor{MyBlue}{0 0 0.54}
%\definecolor{MyBlue}{rgb}{0,0,0.54}
\newrgbcolor{LogideeBlue}{0.043 0.212 0.710 }
\definecolor{LogideeBlue}{rgb}{0.043,0.212,0.710}

% Include localized messages
\input messages.inc

\newboolean{presentation}
\newlength{\largeurtitre}
\newlength{\hauteurtitre}
\newlength{\hauteurlogo}
\newlength{\hauteurdiapototale}
\newlength{\hauteurdiapoclip}
\newlength{\hauteurdiapotitre}
\newlength{\hauteurdiapo}
\newlength{\hauteurimage}
\newlength{\hauteurimagedia}
\newlength{\footeroffset}
\newlength{\tmp}

\newcommand\@ptsize{}
\if@compatibility
  \renewcommand\@ptsize{0}
  \input{size10.clo}
\else
\DeclareOption{10pt}{\renewcommand\@ptsize{0}\input{size10.clo}}
\fi
\DeclareOption{11pt}{\renewcommand\@ptsize{1}\input{size11.clo}}
\DeclareOption{12pt}{\renewcommand\@ptsize{2}\input{size12.clo}}
\DeclareOption{leqno}{\input{leqno.clo}}
\DeclareOption{fleqn}{\input{fleqn.clo}}
\DeclareOption{twoside}{\@twosidetrue  \@mparswitchtrue}

\DeclareOption{cours}{%
\newgray{couleurfond}{0.9}
\setboolean{presentation}{false}%
%
\setlength\paperheight{297mm}
\setlength\paperwidth{210mm}
%
\setlength{\textwidth}{165mm}%
\setlength{\oddsidemargin}{4.6mm}%
\setlength{\evensidemargin}{-10.4mm}%
\setlength{\textheight}{260mm}%
\setlength{\headheight}{0mm}%
\setlength{\topmargin}{-15.4mm}%
\setlength{\headsep}{0mm}%
\setlength{\topskip}{0mm}%
\setlength{\footskip}{5mm}%
\setlength{\footeroffset}{10mm}%
%
\setlength{\parindent}{0mm}%
\setlength{\parskip}{3mm}%
\parskip 3mm%
%
\setlength{\largeurtitre}{165mm}%
\setlength{\hauteurtitre}{65mm}%
\setlength{\hauteurlogo}{50mm}%
\setlength{\hauteurdiapotitre}{5mm}%
\setlength{\hauteurdiapoclip}{87mm}%
\setlength{\hauteurdiapototale}{90mm}%
\setlength{\hauteurdiapo}{75mm}%
\setlength{\hauteurimage}{80mm}%
\setlength{\hauteurimagedia}{65mm}%
\DeclareFixedFont{\FonteCode}{\encodingdefault}{pcr}{b}{n}{12pt}%
}% cours

\DeclareOption{presentation}{%
\setboolean{presentation}{true}%
\newgray{couleurfond}{1}
%
\setlength\paperwidth{297mm}%
\setlength\paperheight{210mm}%
%
\setlength{\textwidth}{277mm}%
\setlength{\oddsidemargin}{-15.4mm}%
\setlength{\evensidemargin}{-15.4mm}%
\setlength{\textheight}{170mm}%
\setlength{\headheight}{0mm}%
\setlength{\topmargin}{-15.4mm}%
\setlength{\headsep}{0mm}%
\setlength{\topskip}{0mm}%
\setlength{\footskip}{5mm}%
\setlength{\footeroffset}{0mm}%
%
\setlength{\parindent}{0mm}%
\setlength{\parskip}{3mm}%
\parskip 3mm%
%
\setlength{\largeurtitre}{230mm}%
\setlength{\hauteurtitre}{100mm}%
\setlength{\hauteurlogo}{50mm}%
\setlength{\hauteurdiapotitre}{10mm}%
\setlength{\hauteurdiapoclip}{167mm}%
\setlength{\hauteurdiapototale}{170mm}%
\setlength{\hauteurdiapo}{155mm}%
\setlength{\hauteurimage}{160mm}%
\setlength{\hauteurimagedia}{140mm}%
\DeclareFixedFont{\FonteCode}{\encodingdefault}{pcr}{b}{n}{24pt}%
}%presentation


\ExecuteOptions{fr}
\ProcessOptions

%\input{size1\@ptsize.clo}
\setlength\lineskip{1\p@}
\setlength\normallineskip{1\p@}
\renewcommand\baselinestretch{}
\@lowpenalty   51
\@medpenalty  151
\@highpenalty 301

\newlength{\largeur}
\setlength{\largeur}{\textwidth}
\addtolength{\largeur}{-4mm}

\newlength{\largeurd}
\setlength{\largeurd}{\textwidth}
\addtolength{\largeurd}{-10mm}

\newlength{\hauteur}
\newlength{\titi}

%\usepackage[cam,axes,a4center]{crop}
%\setlength\paperheight{297mm}
%\setlength\paperwidth{210mm}

\newcommand{\modulename}{}
\newcommand{\themename}{}
\newcommand{\formationname}{}
\renewcommand{\pagename}{}

Bug#971713: sysstat: init or systemd file has overlapping runlevels

[Julian Gilbey]

Package: sysstat
Version: 12.4.0-1
Severity: normal

When installing any package that has an init.d file, I get the
following warning message about sysstat:

insserv: Script sysstat has overlapping Default-Start and Default-Stop
runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.

Best wishes,

   Julian

Bug#971687: Bug#971668: libsane: broke ABI

[Gianfranco Costamagna]

Hello,


>Don't shoot the messanger. It was Jörg who claimed there was an ABI
>break. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908681#177

*thanks* for the followup!
I think and hope we are ok now? :)

as discussed via irc, better keep the bug related to the useless soname change 
open, and close all the unrelated bugs

G.


> 
> 
> Please find a single reference of something in the archive, or outside the 
> archive, that ever used
> part of such (not meant to be exported) API.
> 
> The *bug* was to export them in the previous version, not to remove them, 
> because meant to be internal symbols.
> 
> We had other references in the archive history, where symbols incorrectly 
> exposed were dropped without
> the need to change the ABI.
> 
> We discussed many times already, few people (including I guess the sponsor 
> for that particular upload), and at least
> 3 other DDs agreeded that there was no need to change the SONAME just because 
> of something that was not really
> used anywhere in the world, included self-compiled stuff.
> 
> All the RFS bugs for sane-backends are public, you can find lots of 
> discussion about the topic, and help
> in better developing the package.
> 
> I think this is a non-issue, I would like to have some real bugs before 
> talking about the Sex Of Angels... [1]
> 
> I also think its better have one single bug, instead of having two of them, 
> for the very same source package.
> 
> 
> (sorry for the Italian reference :) )
> [1] https://www.englishforums.com/English/SexOfAngels/kxpgm/post.htm
> 
> just my .02$
> 
> Gianfranco
> 
> > -- 
> > Vincent Lefèvre  - Web: 
> > 100% accessible validated (X)HTML - Blog: 
> > Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

> > 
> > 

-- 
Sebastian Ramacher

Bug#712451: [pkg-apparmor] Bug#712451: Bug#712451: Please support AppArmor network rules

[Jamie Strandboge]

On Fri, 02 Oct 2020, Andrew Savchenko wrote:

> Greetings,
> 
> As AppArmor v3.0 is now released[1], is there a chance that network, dbus and
> sockets will be supported in Bullseye?
> 
> [1] https://lists.ubuntu.com/archives/apparmor/2020-October/012183.html

AppArmor 3 allows use of networkv8 rules (ie, what is in the upstream
kernel) so apparmor 3 in Debian would allow for this to work.

The upstream kernel does not yet support AF_UNIX rules, so anonymous
sockets, abstract sockets and dbus won't be available. Work has picked
up to get this into the upstream kernel (perhaps 5.11).

-- 
Jamie Strandboge | http://www.canonical.com

Bug#971635: gnome-shell-extension-autohidetopbar: Not hiding on wayland window in gnome 3.38

[Tobias Frost]

Am 5. Oktober 2020 19:16:54 MESZ schrieb debian-edid :
>Why closed if package gnome-shell-extension-autohidetopbar is still in 
>version 20200921-1 in sid and bullseye so it is not working. When there
>
>will be an updated version?

the Upload closed the bug automatically. though it takes a dinstall cycle until 
the new package is in the archive.

testing migration to bullseye will of course take longer.

tl;dr: business as usual. 
https://tracker.debian.org/gnome-shell-extension-autohidetopbar has all the 
details on archive and migration status.

Bug#971712: python3-docker: packaging python-docker-doc

[Salman Mohammadi]

Package: python3-docker
Version: 3.4.1-4
Severity: wishlist

Dear Maintainer,

I was wondering if it possible to package python-docker-doc which 
resides here:

https://github.com/docker/docker-py/tree/master/docs

Cheers,
Salman

-- System Information:
Debian Release: 10.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-11-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-docker depends on:
ii python3 3.7.3-1
ii python3-dockerpycreds 0.3.0-1
ii python3-requests 2.21.0-1
ii python3-six 1.12.0-1
ii python3-websocket 0.53.0-1

python3-docker recommends no packages.

python3-docker suggests no packages.

-- no debconf information

Bug#971635: gnome-shell-extension-autohidetopbar: Not hiding on wayland window in gnome 3.38

[debian-edid]

Why closed if package gnome-shell-extension-autohidetopbar is still in 
version 20200921-1 in sid and bullseye so it is not working. When there 
will be an updated version?

Bug#971282: ABI breakage: paths changed for sysusers.d/sysctl.d/binfmt/modules-load.d

[Felipe Sateler]

On Mon, Oct 5, 2020 at 1:02 PM Michael Biebl  wrote:

> Am 05.10.20 um 17:25 schrieb Felipe Sateler:
> > I think the plan should be:
> >
> > 1. Change debhelper and i-s-h to install to /usr
>
> I assume you mean, that dh_installsystemd/dh_systemd should install
> debian/foo.service and debian/foo.udev to /usr/lib?
>

Correct, that's what I mean.


>
> Should debhelper also actively move files from /lib to /usr/lib when
> they are installed to /lib by the upstream build system?
>

Hmm, interesting idea. On the one hand, we didn't do it for /lib. On the
other hand, it would probably save a lot of churn.


>
> We need to decide whether to tie that to a compat bump (in which case it
> would be a very slow process) or whether to do that unconditionally.
>

I think the lintian maintainers would have a preference here. If we do it,
I would prefer unconditionally, but they might prefer a new compat level.

I'm not sure if debhelper does look in /usr/lib/systemd/system. If not,
that needs to be fixed.


>
> > 2. Change the lintian warnings to point to /usr
> > 3. Drop the /lib mangling from all the manpages
> > 4. Wait a lot :(. At least a full release cycle, I think.
> > 5. Drop the split and install fully to /usr, with some compat links for
> > non-merged-/usr.
>
> I guess we only need compat symlinks for binaries in /bin. We need to
> determine if we create symlinks for all of them or only for a select few
> ones, which would have a high impact and would cause unnecessary churn.
>
> A few more bullet points
> - Add support to udev to run udev helper binaries from both paths (see
> the patch in my MR).
>

Right. Ideally, only for the transition period.


>
> - Change systemd.pc and udev.pc and point udevdir to /usr/lib/udev and
> let the various systemd paths point to /usr/lib/.
> This will likely break a few packages, so it would probably be good to
> do a archive wide rebuild of packages build-depending on systemd or udev.
>

I believe doing systemd first is easier (it already has the logic for
multi-path search).

Do you think doing both udev and systemd at the same time is better?

-- 

Saludos,
Felipe Sateler

Bug#962561: Duplicated bug-report?

[riveravaldez]

This bug seems to be this other, previous one:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917522

Best regards.

Bug#933948: systemd forces stop and garbage in coureir again

[PICCORO McKAY Lenz]

i checked this in devuan (it lacks of systemd) and does work..but not on debian

root@venenux:~# service courier-imap-ssl status
● courier-imap-ssl.service - LSB: Courier IMAP server (TLS)
   Loaded: loaded (/etc/init.d/courier-imap-ssl; generated)
   Active: active (exited) since Mon 2020-10-05 15:28:47 VET; 34s ago

it said "active" but (exited) seems, premature received success of
lauch .. i guess cos there's no such good control of pid file if
process broke:

based on https://sourceforge.net/p/courier/mailman/message/35056163/

seems systemd cannot handle that! maybe that's why by the sysv script
does work! again systemd problem related


Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

Bug#971282: ABI breakage: paths changed for sysusers.d/sysctl.d/binfmt/modules-load.d

[Michael Biebl]

Am 05.10.20 um 17:25 schrieb Felipe Sateler:
> I think the plan should be:
> 
> 1. Change debhelper and i-s-h to install to /usr

I assume you mean, that dh_installsystemd/dh_systemd should install
debian/foo.service and debian/foo.udev to /usr/lib?

Should debhelper also actively move files from /lib to /usr/lib when
they are installed to /lib by the upstream build system?

We need to decide whether to tie that to a compat bump (in which case it
would be a very slow process) or whether to do that unconditionally.

> 2. Change the lintian warnings to point to /usr
> 3. Drop the /lib mangling from all the manpages
> 4. Wait a lot :(. At least a full release cycle, I think.
> 5. Drop the split and install fully to /usr, with some compat links for
> non-merged-/usr.

I guess we only need compat symlinks for binaries in /bin. We need to
determine if we create symlinks for all of them or only for a select few
ones, which would have a high impact and would cause unnecessary churn.

A few more bullet points
- Add support to udev to run udev helper binaries from both paths (see
the patch in my MR).

- Change systemd.pc and udev.pc and point udevdir to /usr/lib/udev and
let the various systemd paths point to /usr/lib/.
This will likely break a few packages, so it would probably be good to
do a archive wide rebuild of packages build-depending on systemd or udev.






signature.asc
Description: OpenPGP digital signature

Bug#969173: RM: openvas openvas-libraries openvas-cli openvas-manager -- ROM; replaced by gvm

[Raphael Hertzog]

Control: tag -1 - moreinfo
Control: clone -1 -2 -3 -4
Control: retitle -1 RM: openvas -- ROM; replaced by gvm
Control: retitle -2 RM: openvas-libraries -- ROM; replaced by gvm-libs
Control: retitle -3 RM: openvas-cli -- ROM; obsolete
Control: retitle -2 RM: openvas-manager -- ROM; replaced by gvmd

On sam., 03 oct. 2020, Sean Whitton wrote:
> > Please remove the following source packages from unstable:
> > * openvas(replaced by gvm)
> > * openvas-libraries  (replaced by gvm-libs)
> > * openvas-cli(obsolete)
> > * openvas-manager(replaced by gvmd)
> 
> We need one bug per source package for the sake of our scripts, please.

Done.

Cheers,
-- 
Raphaël Hertzog ◈ Offensive Security ◈ Kali Linux Developer

Bug#971708: ITP: purple-xmpp-carbons -- XMPP XEP-0280: Message Carbons plugin for libpurple

[Henry-Nicolas Tourneur]

Package: wnpp
Severity: wishlist
Owner: Henry-Nicolas Tourneur 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: purple-xmpp-carbons
  Version : 0.2.2
  Upstream Author : Richard Bayerle 
* URL : https://github.com/gkdr/carbons
* License : GPL-2+
  Programming Lang: C
  Description : XMPP XEP-0280: Message Carbons plugin for libpurple

 Carbons is a plugin for libpurple that implements message carbons as
 documented in XEP-0280. This allows one to have consistent history across
 multiple devices.

 This package will be maintained with the DebianOnMobile team.

Bug#971282: ABI breakage: paths changed for sysusers.d/sysctl.d/binfmt/modules-load.d

[Felipe Sateler]

On Thu, Oct 1, 2020 at 4:09 PM Michael Biebl  wrote:

> On Mon, 28 Sep 2020 20:43:30 -0300 Felipe Sateler 
> wrote:
> > On Mon, Sep 28, 2020 at 4:03 PM Michael Biebl  wrote:
> >
> > > Package: systemd
> > > Version: 246.6-1
> > > Severity: important
> > >
> > > Upstream changed the paths in systemd.pc from prefix to rootprefix in
> > > v246 for sysusers_dir, sysctl_dir, binfmt_dir and modules-load_dir:
> > >
> > >
> https://github.com/systemd/systemd/commit/4a56315a990b802860170ecd1bbd3eb68e14a38b
> > >
> > > This breaks packages which use pkg-config to determine those paths and
> > > where .install files reference /usr/. An example is mandos.
> > >
> > > I think we should revert this change. I don't see a compelling reason
> to
> > > move those files from /usr to /lib given that we require /usr to be
> > > pre-mounted by initramfs, if it's separate.
> > > Moving files from /usr to /lib files kinda backwards nowadays.
> > >
> > > I intend to apply a patch like the attached one in Debian.
> > > That said, I hope I can convince Lennart to revert this change upstream
> > > as well.
> > >
> >
> > Looks good to me.
>
> Ok, thanks for the review. Will apply it to Debian then.
> It doesn't look like upstream is interested in changing this back
>
>
> https://github.com/systemd/systemd/commit/4a56315a990b802860170ecd1bbd3eb68e14a38b#commitcomment-42793750
>
> >
> > >
> > > Thoughts, Comments?
> > >
> >
> > I wonder if systemd can be fully installed into `/usr` now that we
> require
> > premounting. Maybe we should start changing lintian and other tools to
> > install into /usr instead of /lib for the tools that currently used
> > rootprefix (I believe systemd searches in /usr anyway).
>
> I gave this a try. It can.
> See https://salsa.debian.org/systemd-team/systemd/-/merge_requests/104
> Still very rough, but the package is usable and able to boot a system,
> reading udev rules and systemd services from both /lib and /usr/lib.
> We probably need quite a few more compat symlinks though.



>
> This is only the systemd/udev side, though.
> The i-s-h/debhelper side is still missing and we'd need to hash out a
> plan for this. I'd need help with doing that.
> Anyone interested?
>

I think this is where we should start (i-s-h/debhelper/lintian). I'll try
to take a look over the weekend. It's a long weekend over here so I might
have some time to take a look.

I think the plan should be:

1. Change debhelper and i-s-h to install to /usr
2. Change the lintian warnings to point to /usr
3. Drop the /lib mangling from all the manpages
4. Wait a lot :(. At least a full release cycle, I think.
5. Drop the split and install fully to /usr, with some compat links for
non-merged-/usr.

What do you think?

-- 

Saludos,
Felipe Sateler

Bug#971707: lintian: breakout-link has lots of false positives, in particular for non-FHS trees below /usr/lib

[Simon McVittie]

Package: lintian
Version: 2.97.0
Severity: normal

The new breakout-link tag (warning about symlinks escaping from /usr/lib)
seems to have a lot of false positives.

In particular, the pattern I'm interested in for this bug report
is that some upstream packages expect to be installed in a non-FHS
layout where a single directory mixes executables with libraries,
or mixes architecture-dependent executables and libraries with
architecture-independent data, or mixes configuration with static
files. This is very, very common in games, which are typically designed
to installed in an arbitrary relocatable directory of the user's choice.
It's also done in larger packages like OpenJDK and LibreOffice, in
GNUstep apps (each of which is designed to be self-contained directory),
and in many other packages.

The long-standing convention for dealing with these packages in Debian has
been to put their non-FHS tree in a subdirectory of /usr/lib. Files that
would ordinarily be valid to appear in /usr/lib are shipped there as
regular files, while files that would not be valid in /usr/lib are shipped
as symlinks to a regular file in another location. For example:

 usr/lib/openarena-server/baseoa/etc/openarena-server -> 
etc/openarena-server
 usr/lib/openarena-server/baseoa/pak0.pk3 -> 
usr/share/games/openarena/baseoa/pak0.pk3

Meanwhile, system integration (for example making the application appear
in /usr/share/applications and in /usr/bin) is done either via wrapper
scripts, or by moving or symlinking individual integration files.

I don't think it's a good idea to encourage maintainers to patch these
packages to use a FHS layout if their upstream would not accept that change.
Unnecessary delta from upstream increases the number of bugs that exist
only in Debian, leading to strained relations between upstreams and
downstreams; and changing the layout has no real benefit for our users in
cases like this, because we're installing the real files (such as
/etc/openarena-server/server.cfg and .../baseoa/pak0.pk3) in the locations
they should normally have.

The tag description says:

At least for /usr/lib, it is usually an error and may confuse
some tools.

[citation needed]? Which tools does it confuse, and which bugs does this
check catch? I don't think setting the level to warning is justified
unless a check genuinely prevents identifiable bugs.

The original bug #243158, back in 2003 (!), was specifically about
/usr/lib's role as the place where shared libraries are stored, which
has mostly been replaced by /usr/lib/ these days anyway. For
example, the original bug report seems to have been about having a
pattern something like this:

/usr/lib/libbigloo.so.123 -> bigloo-1.2/libbigloo.so.123

I don't think the uses of /usr/lib in OpenArena, OpenJDK and LibreOffice
have anything to do with that pattern.

If there are concrete bugs that this tag is intended to detect, then I
suspect that would be better done by more narrowly-targeted tags.

Thanks,
smcv

Bug#971658: libsane1: Please consider making sane-airscan a recommended package

[Brian Potkin]

On Sun 04 Oct 2020 at 22:28:23 +0200, Jörg Frings-Fürst wrote:


> Hello Brian,
> 
> 
> thanks for your hint.
> 
> Like Olaf Meeuwissen I am of the opinion that sane-airscan is best integrated
> into sane. This has been communicated to the upstream author on 11.07.2020. 
> 
> Unfortunately this is not yet done and, what is even more important for me, 
> the
> mentioned bugs are not yet solved.
> 
> I refer to [1].
> 
> So I think that I do not set sane-airscan as recommended package at the 
> moment.
> 
> 
> [1] https://gitlab.com/sane-project/backends/-/issues/202
 
Hello Jörg,

I have read through the posts at Issue 202 a couple of times. What I
take away from what Olaf Meeuwissen said is that adding sane-airscan
as a separate project rather than including it in sane-backends would
be acceptable. Both he and Alexander Pevzner also seem to agree that
managing sane-airscan on GitHub and setting up a repository read-only
SANE mirror is an appropriate approach.

I am neither a coder nor a packager, but having sane-airscan as a
recommended package doesn't appear to be too dissimilar to both the
ideas above. I was also taken by Olaf Meeuwissen's comment that users
typically don't care about what backend is used as long as it works.

Yes, I am disappointed with the decision, but take heart when you say
"...at the moment." There is still time to get it in before the freeze :).

Thank you for your consideration and the explanations.

Regards,

Brian.

Bug#971706: gnome-shell-extensions: windowNavigator -- Workspace.WindowOverlay is not an object or null

[Tobias Frost]

Package: gnome-shell-extensions
Version: 3.38.0-2
Severity: normal

Gnome.Extensions says that the plugin fails to load,
Journactl says:

Okt 05 16:03:31 isildor gnome-shell[2147]: JS ERROR: Extension 
windowsnaviga...@gnome-shell-extensions.gcampax.github.com: TypeError: class 
heritage Workspace.WindowOverlay is not an o>
   
@/usr/share/gnome-shell/extensions/windowsnaviga...@gnome-shell-extensions.gcampax.github.com/extension.js:9:1
   
_callExtensionInit@resource:///org/gnome/shell/ui/extensionSystem.js:420:13
   
loadExtension@resource:///org/gnome/shell/ui/extensionSystem.js:345:27
   
_loadExtensions/<@resource:///org/gnome/shell/ui/extensionSystem.js:586:18
   
collectFromDatadirs@resource:///org/gnome/shell/misc/fileUtils.js:27:28
   
_loadExtensions@resource:///org/gnome/shell/ui/extensionSystem.js:565:19
   
_enableAllExtensions@resource:///org/gnome/shell/ui/extensionSystem.js:595:18
   
_sessionUpdated@resource:///org/gnome/shell/ui/extensionSystem.js:626:18
   
init@resource:///org/gnome/shell/ui/extensionSystem.js:56:14
   
_initializeUI@resource:///org/gnome/shell/ui/main.js:269:22
   
start@resource:///org/gnome/shell/ui/main.js:159:5
   @:1:47

This is possibly 
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/issues/259


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

Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 gnome-shell-extensions depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-1
ii  gir1.2-atk-1.0   2.36.0-2
ii  gir1.2-gdkpixbuf-2.0 2.40.0+dfsg-5
ii  gir1.2-glib-2.0  1.66.0-1
ii  gir1.2-gmenu-3.0 3.36.0-1
ii  gir1.2-gtk-3.0   3.24.23-1
ii  gir1.2-pango-1.0 1.46.2-1
ii  gnome-session-bin3.38.0-2
ii  gnome-settings-daemon3.38.0-2
ii  gnome-shell  3.38.0-2
ii  gvfs 1.46.0-2

Versions of packages gnome-shell-extensions recommends:
ii  gnome-tweaks  3.34.0-4

gnome-shell-extensions suggests no packages.

-- no debconf information

Bug#955798: Fixed upstream

[Russell Coker]

https://github.com/jetmore/swaks/commit/
434f494abcc3558c73efc0e57a4338adeb402253

Here's the upstream fix, which is quite different from my patch.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#971705: RFS: diodon/1.11.0-1 -- GTK+ Clipboard manager

[Oliver Sauder]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "diodon":

 * Package name: diodon
   Version : 1.11.0-1
   Upstream Author : Oliver Sauder 
 * URL : https://launchpad.net/diodon
 * License : LGPL-2.1+, LGPL-3+, GPL-2+
 * Vcs :
https://git.launchpad.net/~diodon-team/+git/debian-packaging
   Section : utils

It builds those binary packages:

  diodon-dev - GTK+ Clipboard manager (development files)
  gir1.2-diodon-1.0 - GTK+ Clipboard manager (GObject introspection data)
  libdiodon0 - GTK+ Clipboard manager (main library)
  diodon - GTK+ Clipboard manager

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

  https://mentors.debian.net/package/diodon/

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

  dget -x
https://mentors.debian.net/debian/pool/main/d/diodon/diodon_1.11.0-1.dsc

Changes since the last upload:

 diodon (1.11.0-1) unstable; urgency=medium
 .
   * New upstream release.
   * Bump debhelper from old 11 to 12.
   * Set debhelper-compat version in Build-Depends.
   * Add Vcs-Browser link
   * Set Multi-Arch of package diodon-dev to same

Regards,

Bug#969372: uwsgi-emperor: SysV init script does nothing

[Vlastimil Zima]

Package: uwsgi-emperor
Version: 2.0.19.1-3
Followup-For: Bug #969372

Dear Maintainer,

it seems this bug still exists in 2.0.19.1-3.

I've upgraded from 2.0.19.1-1 this morning and since then the
uwsgi-emperor can't be started using systemd or
/etc/init.d/uwsgi-emperor script. I tried to purge and install the
uwsgi-emperor package.

The /etc/init.d/uwsgi-emperor still seems to be broken.

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

Kernel: Linux 5.8.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages uwsgi-emperor depends on:
ii  uwsgi-core  2.0.19.1-3

uwsgi-emperor recommends no packages.

uwsgi-emperor suggests no packages.

-- no debconf information

Bug#971704: gnome-shell-pomodoro: No JS module 'tweener' found in search path

[Tobias Frost]

Package: gnome-shell-pomodoro
Followup-For: Bug #971704
Control: tags -1 fixed-upstream

I can confirm that my quick-and-dirty packaging of 0.18 fixes the problem.

Joseph, as you have "RFA"ed the package, should I do an NMU for it or do
you want to take care yourself?
I'm not planning to become sole maintainer, but if you agree to be around
I'll offer co-maintainership. Let me know.

--
tobi

Bug#971704: gnome-shell-pomodoro: No JS module 'tweener' found in search path

[Tobias Frost]

Package: gnome-shell-pomodoro
Version: 0.17.0-1
Severity: normal

(This could be a Gnome 3.38 issue)

I've just saw that Pomodoro stoped working for me,
Gnome.Extensions says
"No JS module 'tweener' found in search path"

Currently trying to compile 0.18 (released yesterday) to see if
that works.

-- 
tobi

Bug#887167: ITP: node-es-abstract -- ECMAScript spec abstract operations

[Xavier]

Hi,

this package is required by most of JS test framework. AT least it is
needed to update mocha, jest, node-webassemblyjs and npm. Both
node-webassemblyjs and npm currently embeds a copy of it, which is a bad
thing: this is not a "little package".

Cheers,
Xavier

Bug#941038: sane: /lib/udev/rules.d/60-libsane.rules seems incomplete

[Gianfranco Costamagna]

control: forcemerge -1 918358
On Mon, 23 Sep 2019 22:29:25 +0200 Guenter Zoechbauer  
wrote:
> Package: sane
> Version: 1.0.14-13+b1
> Severity: important
> 
> 
> 
> -- System Information:
> Debian Release: 10.1
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US:en (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages sane depends on:
> ii  libc6 2.28-10
> ii  libgimp2.02.10.8-2
> ii  libglib2.0-0  2.58.3-2+deb10u1
> ii  libgtk2.0-0   2.24.32-3
> ii  libsane   1.0.27-3.2
> 
> sane recommends no packages.
> 
> Versions of packages sane suggests:
> pn  gimp  
> 
> -- no debconf information
> 
> 
> 
> getfacl: Removing leading '/' from absolute path names
> # file: dev/bus/usb/003/009
> # owner: root
> # group: root
> user::rw-
> user:zoechi:rw-
> group::rw-
> mask::rw-
> other::r--
> 
> When I copy the content of 
> https://gemfury.com/malept/deb:libsane/-/content/lib/udev/rules.d/60-libsane.rules
>  to /etc/udev/rules.d/60-libsane.rules
> the output is
> 
> getfacl: Removing leading '/' from absolute path names
> # file: dev/bus/usb/003/010
> # owner: root
> # group: root
> user::rw-
> user:zoechi:rw-
> group::rw-
> group:scanner:rw-
> mask::rw-
> other::r--
>  
> which contains "scanner" as required.

Bug#941571: buster-pu: package sane-backends/1.0.27-3.2

[Gianfranco Costamagna]

control: tags -1 -moreinfo
On Wed, 02 Oct 2019 08:54:06 +0100 "Adam D. Barratt"  
wrote:
> Control: tags -1 + moreinfo
> 
> On 2019-10-02 08:02, Jörg Frings-Fürst wrote:
> > the udev rules missing the group scanner.
> > The new file debian/99-libsane.rules add them.
> 
> This needs to be resolved in unstable first. (The package currently has 
> the same version in stable and unstable, so it cannot be fixed there 
> already.)
> 

now the fix should be in testing.

G.

> Regards,
> 
> Adam
> 
> 

Bug#971671: gnome-shell-extension-autohidetopbar: error loading extension after gnome-shell upgrade

[Tobias Frost]

> This could be https://github.com/mlutfy/hidetopbar/issues/255.

I'm assuming this issue and made an upload with the new upstream git snapshot;
this will close this bug. If you see this issue with the updated package
(version 20201005-1), please reopen the bug!

Thanks!

-- 
tobi

Bug#971635: gnome-shell-extension-autohidetopbar: Not hiding on wayland window in gnome 3.38

[Tobias Frost]

> Autohiding is working as expected with X window

This part confuses me, because the allocation-changed error should happen
there too, regardless if Wayland of X11…

Regardless, I'll update the package in a few minutes (and with the upload the
bug will be closed). If you still see the error with the version 20201005-1,
please reopen the bug and run 

journalctl --user /usr/bin/gnome-shell

with some luck, there are any hints in the journal.

Thanks!

-- 
tobi

Bug#971635: gnome-shell-extension-autohidetopbar: Not hiding on wayland window in gnome 3.38

[Tobias Frost]

Control: tags -1 upstream fixed-upstream pending

On Sun, 4 Oct 2020 13:25:06 +0200 debian-edid  wrote:
> Also produced error like this:
>  No signal 'allocation-changed' on object 'StBoxLayout'

https://github.com/mlutfy/hidetopbar/issues/255

Bug#967896: Maybe this is related to this upstream kernel bug

[Lennart Sorensen]

https://bugzilla.kernel.org/show_bug.cgi?id=201813 looks pretty much
the same.  It sounds like it has been fixed in a newer kernel and/or
firmware for the card, but I don't know what the chances of such changes
being backported to the stable kernels are.

-- 
Len Sorensen

Bug#971671: gnome-shell-extension-autohidetopbar: error loading extension after gnome-shell upgrade

[Tobias Frost]

On Sun, Oct 04, 2020 at 01:59:33PM -0400, Gabriel Filion wrote:
> Package: gnome-shell-extension-autohidetopbar
> Version: 20200921-1
> Severity: normal
> 
> Hello,
> 
> I've run upgrades today on debian sid, and gnome-shell was upgraded from
> 3.36.6-1 to 3.38.0-2. The autohidetopbar is not working, and in gnome-tweaks I
> see a message on the add-on that says "Error loading extension".

> I currently don't know how to find out more information about the error, but
> I'm willing to dig for more.

This could be https://github.com/mlutfy/hidetopbar/issues/255.

Can you try a "journalctl --user" and see if you can find something in the
logs?

-- 
Cheers,
tobi

Bug#971687: Bug#971668: libsane: broke ABI

[Sebastian Ramacher]

On 2020-10-05 15:18:41, Gianfranco Costamagna wrote:
> control: severity -1 important
> control: reassign -1 src:sane-backends
> control: retitle -1 sane-backends: dropped unused symbols without changing 
> SONAME 
> 
> 
> Hello Vincent and Sebastian
> 
> On Mon, 5 Oct 2020 03:48:26 +0200 Vincent Lefevre  wrote:
> > Control: clone -1 -2
> > Control: reassign -2 libsane1 1.0.31-2
> > Control: retitle -2 libsane1: broke ABI
> > 
> > On 2020-10-04 18:03:30 +0200, Sebastian Ramacher wrote:
> > > Package: libsane
> > > Version: 1.0.31-2
> > > Severity: grave
> > > 
> > > From 1.0.31-1~experimental1:
> > > 
> > >* debian/libsane1.symbols:
> > > - Remove 7 not longer available symbols.
> > > 
> > > Hence provinding libsane that depends on libsane1 with a different ABI
> > > is wrong.
> > 
> > Not just libsane is wrong, but libsane1 (which contains the library
> > itself) too (at least for programs compiled by users).
> > 
> 
> Seriously?
> 
> this is the list of "dropped symbols"
> 
> - testing_append_commands_node@Base 1.0.29
> - testing_known_commands_input_failed@Base 1.0.29
> - testing_last_known_seq@Base 1.0.29
> - testing_record_backend@Base 1.0.29
> - testing_xml_doc@Base 1.0.29
> - testing_xml_next_tx_node@Base 1.0.29
> - testing_xml_path@Base 1.0.29

Don't shoot the messanger. It was Jörg who claimed there was an ABI
break. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908681#177

Cheers

> 
> 
> Please find a single reference of something in the archive, or outside the 
> archive, that ever used
> part of such (not meant to be exported) API.
> 
> The *bug* was to export them in the previous version, not to remove them, 
> because meant to be internal symbols.
> 
> We had other references in the archive history, where symbols incorrectly 
> exposed were dropped without
> the need to change the ABI.
> 
> We discussed many times already, few people (including I guess the sponsor 
> for that particular upload), and at least
> 3 other DDs agreeded that there was no need to change the SONAME just because 
> of something that was not really
> used anywhere in the world, included self-compiled stuff.
> 
> All the RFS bugs for sane-backends are public, you can find lots of 
> discussion about the topic, and help
> in better developing the package.
> 
> I think this is a non-issue, I would like to have some real bugs before 
> talking about the Sex Of Angels... [1]
> 
> I also think its better have one single bug, instead of having two of them, 
> for the very same source package.
> 
> 
> (sorry for the Italian reference :) )
> [1] https://www.englishforums.com/English/SexOfAngels/kxpgm/post.htm
> 
> just my .02$
> 
> Gianfranco
> 
> > -- 
> > Vincent Lefèvre  - Web: 
> > 100% accessible validated (X)HTML - Blog: 
> > Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
> > 
> > 

-- 
Sebastian Ramacher

Bug#971703: golang-github-knadh-koanf: not buildable from source in Debian

[Steve Langasek]

Source: golang-github-knadh-koanf
Version: 0.10.0-1
Severity: serious
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu groovy

Dear maintainers,

The golang-github-knadh-koanf package cannot be built in Debian due to
missing build-dependency, golang-github-rhnvrm-simples3-dev:

$ sudo apt build-dep golang-github-knadh-koanf
[sudo] password for vorlon: 
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 builddeps:golang-github-knadh-koanf : Depends: 
golang-github-rhnvrm-simples3-dev but it is not installable
E: Unable to correct problems, you have held broken packages.
$

This package is not in the Debian NEW queue, and does not have an open ITP
bug.

Please take care of the missing build-dependency.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#925882: new results shown

[Thomas Lange]

The search now shows results from 2020, but it seems that no results
from 2018 and 2019 are shown.
-- 
regards Thomas

Bug#970589: tracker-extract: Crashes due to statx SIGABRT causes disk full ( need update to 2.3.5 )

[Simon McVittie]

Control: severity -1 serious
Control: tags -1 + fixed-upstream patch bullseye sid

On Sat, 19 Sep 2020 at 18:01:51 +0530, crvi wrote:
> Please refer to the following bug:
> 
> https://gitlab.gnome.org/GNOME/tracker-miners/-/issues/138
> 
> This causes the disk space to get full due to repeated service restarts

I think this should be treated as RC for bullseye.

Here is a WIP update to 2.3.5:
https://salsa.debian.org/gnome-team/tracker-miners/-/merge_requests/11

I don't know Tracker well, so I'd prefer it if someone else could test,
review and upload.

Thanks,
smcv

Bug#908681: libsane1: pointless package rename

[Gianfranco Costamagna]

Hello Joerg,

> We are not back.

to be honest, yes we are :)

> 
> Between 1.0.30 and 1.0.31 are the following 7 symbols are not longer 
> available:
> 
> #MISSING: 1.0.31# testing_append_commands_node@Base 1.0.29
> #MISSING: 1.0.31# testing_known_commands_input_failed@Base 1.0.29
> #MISSING: 1.0.31# testing_last_known_seq@Base 1.0.29
> #MISSING: 1.0.31# testing_record_backend@Base 1.0.29
> #MISSING: 1.0.31# testing_xml_doc@Base 1.0.29
> #MISSING: 1.0.31# testing_xml_next_tx_node@Base 1.0.29
> #MISSING: 1.0.31# testing_xml_path@Base 1.0.29
> 
> This ABI changes are not backward-compatible. And so the change are required. 
> 

So, to explain:

If you think they are not backward-compatible, you should rename the package, 
but not provide the old SONAME
as transitional package, otherwise you are doing a mistake

In this case, the symbols were private, and incorrectly exposed outside, so 
removing them is "safe"
as long as nobody uses them.

When I sponsored the package for you, even if I forgot to write that on the RFS 
bug, I had a discussion about this
with some other DDs, and we agreeded that this wasn't worth a SONAME change, 
because the end user applications
were still ABI-safe.

So, this is why I asked you to restore the old package name, and make it 
transitional, to avoid people being forced
to upgrade to a new library SONAME without a real SONAME change.

This way, we made almost "everybody" happy, or at least improved the status quo 
for some bits.

(the real world fix was to ignore lintian, or to not start with a wrong soname, 
but this history now)

So, yes, the ABI changed, but the change was not reflected into a real issue 
for any Debian application, or any custom-built application.

I honestly think we should just move forward, and change the soname again if a 
the library changes in the future.

G.

Bug#970905: thunderbird: self signed certificate don't open, TB says connect problem

[Laurent Stella]

Hi ;

I just tested with linux tar.bz2 version from their website, it works : 
the popup warning you from unknown cert nd allowing you to add and trust 
it shows immediaterly. TB v 78.3.1


seems to work great with pinning TB from unstable (78.3.1-2).

what can we do to make it go faster to testing ?

Le 26/09/2020 à 07:50, Carsten Schoenert a écrit :

Control: tags -1 upstream

Hello olaulau,

Am 25.09.20 um 10:10 schrieb olaulau:

when using email account assistant, nd want to use an IMAP server with self
signed certificate
you normally show a warning red popup to accept it
- on TB 68 (testing),  we must pass through manual settings window to add this
   certificate
- on TB 78 (experimental) there is no way to force it. can only connect with
   unencrypted connection to the server

no problem with TB 78 on windows 10.

of course I've tried deleting ~/.thunderbird to use a fresh TB profile.

this look like a clearly upstream related issue.
I'd kindly request that you please open up a upstream bug report about
this problem. Afterwards we link together the two bug reports and we get
informed here once upstream is doing any action on the report on the
Mozilla bugtracker.

Please visit

   https://bugzilla.mozilla.org/home

Thanks!

---
Regards
Carsten Schoenert

Bug#920545: [RFS] python-intervaltree-bio

[Nilesh Patra]

Hi,
I've attempted to fix: #920545 which is about failing autopkgtests for
python-intervaltree-bio. It seems to pass on my chroot and I've pushed the
corresponding changes to the team repo here[1].
It'd be great if someone could try testing my changes once - and either
sponsor or grant me access to do so.

[1]: https://salsa.debian.org/med-team/python-intervaltree-bio

Kind regards
Nilesh

Bug#794534:

[emilia hunt]

Привіт, мене звуть Емілія, я хочу бути вашим другом, ви говорите
англійською?

Bug#971299: onionshare: Switch to python3-pycryptodome

[Clément Hermann]

Hi,

Control: block 971299 with 886291
thanks

On 28/09/2020 23:29, Sebastian Ramacher wrote:
> Source: onionshare
> Version: 2.2-2
> Severity: important
> Tags: sid bullseye
> Usertags: pycrypto
> 
> Dear maintainer,
> 
> onionshare currently Build-Depends or Depends on python3-crypto from
> PyCrypto. This project is no longer maintained and PyCryptodome
> (https://www.pycryptodome.org/en/latest/) provides a drop in
> replacement. Please switch to python3-pycryptodome. I'd like to
> remove python-crypto before the release of bullseye.


As far as I understand it, pycryptodome *can* be a drop-in replacement
usually, but not currently in Debian since it doesn't install in Crypto
but Cryptodomex namespace (#886291).

Are there any plan to change it when python3-crypto is removed or before ?

Of course, we can patch onionshare to import cryptodomex, but that patch
would be debian-only then… Upstream already expect pycryptodome as
Crypto module.

Take care,

-- 
nodens

Bug#971687: Bug#971668: libsane: broke ABI

[Gianfranco Costamagna]

control: severity -1 important
control: reassign -1 src:sane-backends
control: retitle -1 sane-backends: dropped unused symbols without changing 
SONAME 


Hello Vincent and Sebastian

On Mon, 5 Oct 2020 03:48:26 +0200 Vincent Lefevre  wrote:
> Control: clone -1 -2
> Control: reassign -2 libsane1 1.0.31-2
> Control: retitle -2 libsane1: broke ABI
> 
> On 2020-10-04 18:03:30 +0200, Sebastian Ramacher wrote:
> > Package: libsane
> > Version: 1.0.31-2
> > Severity: grave
> > 
> > From 1.0.31-1~experimental1:
> > 
> >* debian/libsane1.symbols:
> > - Remove 7 not longer available symbols.
> > 
> > Hence provinding libsane that depends on libsane1 with a different ABI
> > is wrong.
> 
> Not just libsane is wrong, but libsane1 (which contains the library
> itself) too (at least for programs compiled by users).
> 

Seriously?

this is the list of "dropped symbols"

- testing_append_commands_node@Base 1.0.29
- testing_known_commands_input_failed@Base 1.0.29
- testing_last_known_seq@Base 1.0.29
- testing_record_backend@Base 1.0.29
- testing_xml_doc@Base 1.0.29
- testing_xml_next_tx_node@Base 1.0.29
- testing_xml_path@Base 1.0.29


Please find a single reference of something in the archive, or outside the 
archive, that ever used
part of such (not meant to be exported) API.

The *bug* was to export them in the previous version, not to remove them, 
because meant to be internal symbols.

We had other references in the archive history, where symbols incorrectly 
exposed were dropped without
the need to change the ABI.

We discussed many times already, few people (including I guess the sponsor for 
that particular upload), and at least
3 other DDs agreeded that there was no need to change the SONAME just because 
of something that was not really
used anywhere in the world, included self-compiled stuff.

All the RFS bugs for sane-backends are public, you can find lots of discussion 
about the topic, and help
in better developing the package.

I think this is a non-issue, I would like to have some real bugs before talking 
about the Sex Of Angels... [1]

I also think its better have one single bug, instead of having two of them, for 
the very same source package.


(sorry for the Italian reference :) )
[1] https://www.englishforums.com/English/SexOfAngels/kxpgm/post.htm

just my .02$

Gianfranco

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

Bug#971702: Please package httpx >= 0.14.2

[Thomas Goirand]

Package: python3-httpx
Version: 0.12.1-2
Severity: normal

Hi,

OpenStack, and more specifically octavia-tempest-plugin, needs httpx >= 0.14.2.
Please upgrade the package to that version.

Cheers,

Thomas Goirand (zigo)

Bug#964737: mpd: Single mode not working the first time

[kaliko]

Hi Ian, MPD team

Le 10/07/2020 à 12:45, kaliko a écrit :
> Le 09/07/2020 à 19:51, Ian Zimmerman a écrit :
>> Package: mpd
>> Version: 0.21.5-3
>> Severity: normal
>>
>> When mpd restarts and the single mode flag is on, the first song transition 
>> happens anyway.
>> (That is, when it finishes playing the first song it goes on to the second 
>> one in the queue.)
>> When the second song is finished mpd pauses as expected and then continues 
>> to work correctly.
>>
>> This sounds somewhat similar to upstream github issue #556, but it is 
>> completely reproducible
>> for me.
> 
> According to #556 [0] a fix was shipped in 0.21.9 (someone still report the 
> issue
> against 0.21.9 though).
> 
> Can you try installing a more recent version of MPD and check if this is 
> reproducible?
> 
> You can use my onw repo : https://www.musicpd.org/download-unoff-debian/
> 
> Or manually download/install latest buster backport/build :
> 
> wget 
> https://deb.kaliko.me/debian-backports/pool/main/m/mpd/mpd_0.21.22-1~bpo10+1_amd64.deb
> apt install ./mpd_0.21.22-1~bpo10+1_amd64.deb
> […]
> [0] https://github.com/MusicPlayerDaemon/MPD/issues/556

Could you try the latest release of 0.21 branch ?

The latest buster backport/build :

https://deb.kaliko.me/debian-backports/pool/main/m/mpd/mpd_0.21.26-1~bpo10+1_amd64.deb

Cheers
k



signature.asc
Description: OpenPGP digital signature

Bug#971678: ghostscript: FTBFS: ERROR: cidfmap not virtually empty as expected

[Simon McVittie]

Control: tags -1 + patch

On Mon, 05 Oct 2020 at 12:23:19 +0100, Simon McVittie wrote:
> > > | grep: 
> > > debian/libgs9-common/usr/share/ghostscript/9.53.3/Resource/Init/cidfmap: 
> > > No such file or directory
> > > | rm: cannot remove 
> > > 'debian/libgs9-common/usr/share/ghostscript/9.53.3/Resource/Init/cidfmap':
> > >  No such file or directory
> > 
> > I think this is the real problem. Testing a patch now.
> 
> See attached.
> 
> However, when testing that, I get a different (unrelated?) FTBFS when
> *only* building the Architecture: all package (i.e. with -A)

I retried the build and it succeeded, so I think that might be an unrelated
issue - perhaps a race condition in the presence of parallel builds?

DDs can give-back failed builds now, so an intermittent build failure,
while unwelcome, is not necessarily the showstopper that it used to be.

smcv

Bug#971698: Spatialite GUI and unicode

[Sebastiaan Couwenberg]

Control: tags -1 upstream
Control: forwarded -1
https://www.gaia-gis.it/fossil/spatialite_gui/tktview/4fe74419ba5367c1e835749a6599fd7c545ca23d

Hi Michel,

Thanks for reporting this issue, I've forwarded it upstream.

Please follow up there and/or on the spatialite-users list:

 https://groups.google.com/forum/#!forum/spatialite-users

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#955798: patch to fix this

[Russell Coker]

The attached patch fixes swaks for daylight savings time.

 -> Date: Sun, 04 Oct 2020 10:24:09 +1000

Above is from the output of swaks in Debian/Buster showing a wrong timezone 
for Australian Eastern time (Melbourne or Sydney if you want to test).  Below 
is from the output of the patched version.

 -> Subject: test Sun, 04 Oct 2020 10:24:09 +1100

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/
Index: swaks-20181104.0/swaks
===
--- swaks-20181104.0.orig/swaks
+++ swaks-20181104.0/swaks
@@ -3170,9 +3170,16 @@ sub get_date_string {
 		@l = gmtime($et);
 	} else {
 		my @g = gmtime($et);
-		$o = (timelocal(@l) - timelocal(@g)) / 60;
-		# Adjust to hours and minutes and not hours and hour-hundreths
-		# See debian bug 646084
+		my $hour_diff;
+		# if the year is different then we are 1 day off
+		if($l[5] != $g[5]) {
+			$hour_diff = ($l[5] - $g[5])*24 + $l[2] - $g[2];
+		} else {
+			$hour_diff = ($l[7] - $g[7])*24 + $l[2] - $g[2];
+		}
+		my $min_diff  = $l[1] - $g[1];
+		# NB min_diff may be negative for timezone that is not an integer number of hours
+		$o = $hour_diff * 60 + $min_diff;
 		$o = int($o / 60)*100 + ($o%60)*($o > 0 ? 1 : -1);
 	}
 	$G::date_string = sprintf("%s, %02d %s %d %02d:%02d:%02d %+05d",

Bug#971255: [Pkg-giraffe-maintainers] Bug#971255: Acknowledgement (kopanocore: autopkgtest fails on assuming /etc/init.d/mysql exists)

[Otto Kekäläinen]

Yes, please change to 'service mariadb start' or 'systemctl start mariadb'
(works also without systemd is systemctl-shim is installed).

Systemd supports aliases while init.d not, so that is why the other works
with both names and the other does not.

Bug#971700: debootstrap: Please add option to get full log on stderr

[Sven Mueller]

Package: debootstrap
Version: 1.0.123
Tags: patch

Attached is a minimalistic patch to implement what I would need for better
logging when automatically creating chroot environments. It preserves the
behavior of other output options to have the I:/W:/etc. info on stdout and
puts everything else on stderr.
I only did relatively limited testing, but this seems to achieve exactly
what I want.
A better solution would be to _also_ log everything to debootstrap.log, I
think, but I found no reasonable way to do that.

Regards,
Sven
Description: Allow stderr to be passed to the caller
 This change allows the caller of debootstrap to request that stderr is passed
 to it instead of being swallowed into debootstrap.log
Author: Sven Mueller 
Forwarded: no
Last-Update: 2020-10-02
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
Index: debootstrap-1.0.123/debootstrap
===
--- debootstrap-1.0.123.orig/debootstrap
+++ debootstrap-1.0.123/debootstrap
@@ -42,6 +42,7 @@ UNPACK_TARBALL=""
 ADDITIONAL=""
 EXCLUDE=""
 VERBOSE=""
+FULL_OUTPUT=""
 CERTIFICATE=""
 CHECKCERTIF=""
 PRIVATEKEY=""
@@ -91,6 +92,8 @@ usage()
   --help display this help and exit
   --version  display version information and exit
   --verbose  don't turn off the output of wget
+  --full-output  show full process output on stderr, I:/W: info
+ on stdout.
 
   --download-onlydownload packages, but don't perform installation
   --print-debs   print the packages to be installed, and exit
@@ -310,6 +313,11 @@ if [ $# != 0 ] ; then
 		VERBOSE=true
 		export VERBOSE
 		shift 1
+;;
+--full-output)
+FULL_OUTPUT="yes"
+export FULL_OUTPUT
+shift 1
 		;;
 	--extra-suites|--extra-suites=?*)
 		if [ "$1" = "--extra-suites" ] && [ -n "$2" ]; then
@@ -618,6 +626,11 @@ elif am_doing_phase printdebs; then
 	#stderr: I:/W:/etc information
 	#stdout: debs needed
 	exec 4>&2
+elif [ "$FULL_OUTPUT" = yes ]; then
+	# stdout: I:/W:/etc information
+	# stderr: full log of debootstrap run (stdout/stderr combined)
+	exec 4>&1
+	exec >&2
 else
 	#stderr: used in exceptional circumstances only
 	#stdout: I:/W:/etc information

Bug#971699: ITP: r-cran-circular -- GNU R Circular Statistics

[Shayan Doust]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-circular -- GNU R Circular Statistics
Package: wnpp
Owner: Shayan Doust 
Severity: wishlist

* Package name: r-cran-circular
  Version : 0.4
  Upstream Author : Ulric Lund ,
* URL : https://cran.r-project.org/package=circular
* License : GPL-2
  Programming Lang: GNU R
  Description : GNU R Circular Statistics
 Circular Statistics, from "Topics in circular Statistics" (2001) S. Rao
 Jammalamadaka and A. SenGupta, World Scientific.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-circular

Bug#908137: luajit: lightuserdata problem with > 47 bit address space on arm64

[Santiago Ruano Rincón]

Control: tags -1 fixed-upstream

On Thu, 06 Sep 2018 16:54:30 +0300 Adrian Bunk  wrote:
> Source: luajit
> Version: 2.0.4+dfsg-1
> Severity: serious
> Forwarded: https://github.com/LuaJIT/LuaJIT/pull/230#issuecomment-260205661
> 
> This is an RFC regarding what to do for avoiding runtime
> problems on arm64 like e.g. #907729.
> 
> The big hammer would be to drop luajit on arm64,
> reverse dependencies are already able to cope
> with luajit not available on s390x.
> 
> 

From the latest comment by upstream on the same PR
https://github.com/LuaJIT/LuaJIT/pull/230#issuecomment-701054121
it seems this has been fixed now. This is the relevant commit:
https://github.com/LuaJIT/LuaJIT/commit/e9af1abec542e6f9851ff2368e7f196b6382a44c


signature.asc
Description: PGP signature

Bug#971698: Spatialite GUI and unicode

[jedei]

Package: spatialite-gui
Version: 2.1.0~beta1-1
Severity: normal‌

Hi,

In spatialite_gui the following query causes a bug as soon as the "è" character 
is typed even before having executed the query : SELECT code_insee, nom_com, 
FROM communes_bdp WHERE nom_com = 'Anè
[Error message]
An assertion failed!
../src/common/unichar.cpp(65):assert "Assert failure" failed in ToHi8bit(): 
character cannot be converted to single byte

The same query with sqlite3 and mod_spatialite works fine.

I am using Linux debian 5.6.0-2-amd64 #1 SMP Debian 5.6.14-2 (2020-06-09) 
x86_64 GNU/Linux (Bullseye testing 20200622 with partial update (sqlite3, 
spatialite) 20201003)

Best regards

Michel

Bug#964850: Splitting mime-support into mailcap and media-types (Re: Bug#964850: ITP: mailcap -- Debian's mailcap system, and support programs)

[Jai Flack]

Adam Borowski  writes:

[...]

> perl-base is essential.

Thanks,

My apologies, I couldn't find it on the wiki.

-- 
Thanks,
Jai

Bug#971678: ghostscript: FTBFS: ERROR: cidfmap not virtually empty as expected

[Simon McVittie]

On Mon, 05 Oct 2020 at 10:56:17 +0100, Simon McVittie wrote:
> Control: retitle 971678 ghostscript: FTBFS when not building Arch:all: 
> debian/libgs9-common/usr/share/ghostscript/9.53.3/Resource/Init/cidfmap: No 
> such file or directory
> 
> On Sun, 04 Oct 2020 at 22:55:24 +0200, Sebastian Ramacher wrote:
> > ghostscript currently FTBFS on the buildds:
> > | grep: 
> > debian/libgs9-common/usr/share/ghostscript/9.53.3/Resource/Init/cidfmap: No 
> > such file or directory
> > | rm: cannot remove 
> > 'debian/libgs9-common/usr/share/ghostscript/9.53.3/Resource/Init/cidfmap': 
> > No such file or directory
> 
> I think this is the real problem. Testing a patch now.

See attached.

However, when testing that, I get a different (unrelated?) FTBFS when
*only* building the Architecture: all package (i.e. with -A):

8<
make -f Makefile DISPLAY_DEV=./soobj/display.dev BUILDDIRPREFIX=so GENOPT='' 
LDFLAGS='-Wl,-z,relro  '\
 CFLAGS='-fPIC   -O2 -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2  -Wall 
-Wstrict-prototypes -Wundef -Wmissing-declarations -Wmissing-prototypes 
-Wwrite-strings -fno-strict-aliasing -Werror=declaration-after-statement 
-fno-builtin -fno-common -Werror=return-type -DHAVE_STDINT_H=1 
-DHAVE_DIRENT_H=1 -DHAVE_SYS_DIR_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1 
-DHAVE_INTTYPES_H=1 -DHAVE_LIBDL=1 -DGX_COLOR_INDEX_TYPE="unsigned long long" 
-D__USE_UNIX98=1  -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -DHAVE_RESTRICT=1 
-DUSE_LIBPAPER -I/usr/include/x86_64-linux-gnu  -fno-strict-aliasing 
-DHAVE_POPEN_PROTO=1 -DGS_DEVS_SHARED 
-DGS_DEVS_SHARED_DIR=\"/usr/lib/x86_64-linux-gnu/ghostscript/9.53.3\" ' 
prefix=/usr\
 ./sobin/gsc ./sobin/gsx -so-loader -so-loader -so-loader
make[4]: Entering directory '/<>'
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/Scrt1.o: in function 
`_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status
make[4]: *** [base/unix-dll.mak:174: sobin/gsc] Error 1
make[4]: *** Waiting for unfinished jobs
make[4]: Leaving directory '/<>'
make[3]: *** [base/unix-dll.mak:294: so-subtarget] Error 2
make[3]: Leaving directory '/<>'
make[2]: *** [base/unix-dll.mak:243: so] Error 2
make[2]: Leaving directory '/<>'
dh_auto_build: error: make -j2 so SHARE_JPEG=1 SHARE_LIBPNG=1 SHARE_LIBTIFF=1 
SHARE_ZLIB=1 SHARE_JBIG2=1 SHARE_IJS=1 SHARE_EXPAT=1 WHICH_CMS=lcms2 
SHARE_LCMS=1 LCMS2DIR=/usr SHARE_JPX=1 SHARE_FT=1 SHARE_LCUPS=1 SHARE_LCUPSI=1 
returned exit code 2
make[1]: *** [debian/rules:78: override_dh_auto_build] Error 25
make[1]: Leaving directory '/<>'
make: *** [debian/rules:165: binary-indep] Error 2
8<

So this presumably can't be a complete solution. I don't know why my patch
would make this happen; perhaps it's coincidence.

Again, I'd recommend testing the -A and -B build modes before uploading.

smcv
>From 199e129841d1da4a6a7a41cc46fcc50bd8a96c79 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Mon, 5 Oct 2020 10:57:03 +0100
Subject: [PATCH] Don't check/remove cidfmap when not building libgs9-common

This fixes FTBFS when libgs9-common is not built, in particular on the
official Debian buildd for each architecture.

Closes: #971678
---
 debian/rules | 4 
 1 file changed, 4 insertions(+)

diff --git a/debian/rules b/debian/rules
index f02e98dd..e33927c5 100755
--- a/debian/rules
+++ b/debian/rules
@@ -15,6 +15,8 @@ pkg-lib = $(libname)$(GS_VERSION_MAJOR)
 pkg-dev = $(libname)-dev
 pkg-data = $(libname)$(GS_VERSION_MAJOR)-common
 
+binaries := $(shell dh_listpackages)
+
 # use upstream bootstrapping script
 override_dh_autoreconf:
 	dh_autoreconf ./autogen.sh
@@ -132,6 +134,7 @@ override_dh_install:
 
 	dh_link --package=$(pkg-data) -- $(DEB_DH_LINK_$(pkg-data))
 	dh_link --no-package=$(pkg-data)
+ifneq ($(filter $(pkg-data),$(binaries)),)
 	file='debian/$(pkg-data)/usr/share/ghostscript/$(GS_DOT_VERSION)/Resource/Init/cidfmap'; \
 	  ! egrep -v '^(%([^%].*)?)?$$' "$$file" && rm "$$file" || ( \
 		echo; \
@@ -146,6 +149,7 @@ override_dh_install:
 		usr/share/ghostscript/$(GS_DOT_VERSION)/Resource/Font
 	rename 's/\.t1$$//' \
 		debian/$(pkg-data)/usr/share/ghostscript/$(GS_DOT_VERSION)/Resource/Font/*
+endif
 
 # check that tracked issues are solved
 override_dh_auto_test:
-- 
2.28.0

Bug#971584: libsane1: Scanner no more identified after upgrade to 1.0.31 version

[mes op tafel]

I have exactly the same  problem
os: debian testing kde
scanner: canon lide 25

Bug#967896:

[Tom Larédo]

Same issue on this laptop: ASUS Vivobook S S413FQ-EB029T
This is a blocking issue as Debian Buster can't be installed without a
RJ45-USB adapter.

Tom LAREDO

Bug#971680: /usr/share/gcc-10/python/ should go in a dev package

[Matthias Klose]

On 10/5/20 10:39 AM, Josh Triplett wrote:
> On Mon, Oct 05, 2020 at 09:32:28AM +0200, Matthias Klose wrote:
>> On 10/4/20 11:09 PM, Josh Triplett wrote:
>>> libstdc++6, installed on every system due to dependencies, contains
>>> various Python scripts for GDB under /usr/share/gcc-10/python/ . These
>>> scripts should go in a dev package, not in a library package.
>>
>> There's no part in the policy that requires debugging scripts to be part of 
>> the
>> development package, and I think it's not very intuitive.  There's also no
>> advocated policy if these scripts should be part of a dbgsym package, and
>> there's no debhelper support to add these files to a dbgsym package.  So 
>> yes, I
>> think the library package is the correct package to have these files.  It 
>> makes
>> the library package a little bit bigger, but these don't hurt there.
> 
> There's precedent for things related to debugging a particular library
> going into the -dev package for that library. For example,
> /usr/share/gdb/auto-load/lib/x86_64-linux-gnu/libpthread-2.31.so-gdb.py
> lives in libc6-dev, not in libc6.

these were only added later than the libstdc++6 ones, so no precedence.

> There may be a better place for them, but this seems like a reasonable
> approach.
> 
> My concern is that I'm trying to build a minimal Debian-based system,
> libstdc++6 is hard-required because among other things apt depends on
> it, and it's shipping ~132k of Python scripts.

if that's a minimal system, you probably could use the same technique like
probably removing files in /usr/share/doc.