Bug#968200: missing files for bblxml features

[Hilmar Preuße]

Am 12.08.2020 um 02:48 teilte Norbert Preining mit:

Hi,

>>> No, I am using the releas tarballs from sourceforge.
>>>
>> ...which is identical to that on CTAN.
> 
> Which both seem to be bugged, the config says BETA VERSION ...
> and the release tarball on github is definitely more complete.
> 
> Hilmar, I have locally imported the github tarball as
>   2.14+1.orig.tar.gz
> and updated the package. I think we could go with that, and include
> much of the documentation that is added in the github tarball.
> 
> WDYT? Should I push that to the repo or do you prefer your work to be
> uploaded first, and then superseeded by 2.14+1?
> 
Go ahead and upload w/ the new tar ball. One must assume that there are
more files missing in the broken orig.tar.gz.

Hilnar
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#968262: lintian: spare-manual-page misses .so targets

[Felix Lechner]

Hi Ross,

On Tue, Aug 11, 2020 at 10:39 PM Ross Vandegrift  wrote:
>
> I: terminology-data: spare-manual-page 
> usr/share/man/man1/terminology-helpers.1.gz

The links are fine, but I could not find an executable named
terminology-helpers in your installation packages. Do you ship one?

Kind regards

Felix Lechner

Bug#943167: Python2 removal bug resurfaced in madness

[merkys]

Hi Stuart,

I saw you have fixed Python2 removal related issue (#943167) in madness
0.10.1~gite4aa500e-11 upload to experimental. However, unstable still
has 0.10.1~gite4aa500e-10.1 with the same issue now reported as #967172.
Is there a reason for not uploading your fix to unstable?

Best,
Andrius

Bug#968263: Broken symlinks /usr/bin/afl-clang(++)

[Jakub Wilk]

Package: afl++-clang
Version: 2.66c-1
User: debian...@lists.debian.org
Usertags: adequate broken-symlink

afl++-clang ships broken symlinks:

   $ dpkg -L afl++-clang | xargs -n1 file | grep -w broken
   /usr/bin/afl-clang: broken symbolic link to ../afl-clang-fast
   /usr/bin/afl-clang++: broken symbolic link to ../afl-clang-fast


This bug was found using adequate:
https://packages.debian.org/unstable/main/adequate

-- System Information:
Architecture: i386

Versions of packages afl++-clang depends on:
ii  afl++   2.66c-1
ii  clang-111:11.0.0~+rc1-2
ii  libc6   2.31-3
ii  libgcc-s1   10.2.0-5
ii  libstdc++6  10.2.0-5

Versions of packages afl++-clang recommends:
un  afl++-doc  

--
Jakub Wilk

Bug#968194: Depends on non-existent python version?

[積丹尼 Dan Jacobson]

Problem solved:
https://github.com/getmail6/getmail6

Bug#968262: lintian: spare-manual-page misses .so targets

[Ross Vandegrift]

Package: lintian
Version: 2.89.0
Severity: normal

terminology-data installs terminology-helpers.1 for a number of small binaries
from terminology.  Each helper binary has a corresponding man file consisting
just of a .so line.  But lintian reports:

I: terminology-data: spare-manual-page 
usr/share/man/man1/terminology-helpers.1.gz
N:
N:Each manual page in /usr/share/man should have a reason to be there.
N:This manual page does not appear to have a valid reason to be shipped.
N:
N:For manual pages in sections 1 and 8, an executable (or a link to one)
N:should exist. This check currently considers all installation packages
N:created by the same sources, as long as they are present.
N:
N:Refer to Debian Policy Manual section 12.1 (Manual pages) and
N:https://bugs.debian.org/583125 for details.
N:
N:Severity: info
N:
N:Check: documentation/manual

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.7.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  binutils  2.35-1
ii  bzip2 1.0.8-4
ii  diffstat  1.63-1
ii  dpkg  1.20.5
ii  dpkg-dev  1.20.5
ii  file  1: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-perl  0.48-1
ii  libclass-xsaccessor-perl  1.19-3+b5
ii  libclone-perl 0.45-1
ii  libconfig-tiny-perl   2.24-1
ii  libcpanel-json-xs-perl4.19-1
ii  libdata-dpath-perl0.58-1
ii  libdata-validate-domain-perl  0.10-1
ii  libdevel-size-perl0.83-1+b1
ii  libdpkg-perl  1.20.5
ii  libemail-address-xs-perl  1.04-1+b2
ii  libfile-basedir-perl  0.08-1
ii  libfile-find-rule-perl0.34-1
ii  libfont-ttf-perl  1.06-1
ii  libhtml-parser-perl   3.72-5
ii  libio-async-loop-epoll-perl   0.21-1
ii  libio-async-perl  0.77-3
ii  libipc-run3-perl  0.048-2
ii  libjson-maybexs-perl  1.004002-1
ii  liblist-compare-perl  0.53-1
ii  liblist-moreutils-perl0.416-1+b5
ii  liblist-utilsby-perl  0.11-1
ii  libmoo-perl   2.004000-1
ii  libmoox-aliases-perl  0.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  libsereal-decoder-perl4.018+ds-1
ii  libsereal-encoder-perl4.018+ds-1
ii  libtext-levenshteinxs-perl0.03-4+b7
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-perl  2.3300-1
ii  libtry-tiny-perl  0.30-1
ii  libtype-tiny-perl 1.010002-1
ii  libunicode-utf8-perl  0.62-1+b1
ii  liburi-perl   1.76-2
ii  libxml-libxml-perl2.0134+dfsg-2
ii  libxml-writer-perl0.625-1
ii  libyaml-libyaml-perl  0.82+repack-1
ii  lzip  1.21-7
ii  lzop  1.04-1
ii  man-db2.9.3-2
ii  patchutils0.4.2-1
ii  perl [libdigest-sha-perl] 5.30.3-4
ii  t1utils   1.41-4
ii  unzip 6.0-25
ii  xz-utils  5.2.4-1+b1

lintian recommends no packages.

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

-- no debconf information

Bug#968194: Depends on non-existent python version?

[積丹尼 Dan Jacobson]

Yup, not installable.

Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (990, 'unstable')

# aptitude install getmail
The following NEW packages will be installed:
  getmail{b} (D: python:any)
0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/182 kB of archives. After unpacking 677 kB will be used.
The following packages have unmet dependencies:
 getmail : Depends: python:any (< 2.8) which is a virtual package, provided by:
- python (2.7.17-2), but it is not installable

   Depends: python:any (>= 2.7~) which is a virtual package, provided 
by:
- python (2.7.17-2), but it is not installable

The following actions will resolve these dependencies:

 Keep the following packages at their current version:
1) getmail [Not Installed]


Accept this solution? [Y/n/q/?] n

*** No more solutions available ***

Bug#968153: RFS: tinymux/2.12.0.10-1 -- text-based multi-user virtual world server

[Stephen Dennis]

Current status:

It builds and rebuilds for me on two different clean Debian environments. I
have never gotten the '/usr/bin/ld: cannot find -lmux' error. Adam hasn't
responded in two days and is probably waiting for me to fix an error I
cannot reproduce. Can anyone else build it? Am I building this a wrong way?

dpkg-buildpackage -k<...>
lintian
dput

On Mon, Aug 10, 2020 at 5:01 AM Adam Borowski  wrote:

>
> Alas, still fails:
> g++ -std=c++14 -g -O2 -fdebug-prefix-map=/<>=.
> -fstack-protector-strong -Wformat -Werror=format-security -g -O
>  -DSTUB_SLAVE   -o stubslave stubslave.o -L. -lm -lcrypt   -lmux -lpcre
> /usr/bin/ld: cannot find -lmux

Bug#960047: darktable: Superfluous dependencies

[astian]

Control: found -1 3.2.1-2

What's the problem with fixing this? It's a one-liner FFS.

Bug#968261: sane-airscan: Copyright fails to mention Expat license of http_parser.{c,h} or copyright holders thereof

[Christopher James Halse Rogers]

Package: sane-airscan
Version: 0.99.12-1
Severity: important

Dear Maintainer,

While reviewing an upload of sane-airscan to the Ubuntu NEW queue I
discovered the http_parser.{c,h} files are (C) Joylent, Inc under the
Expat licence, and neither Joylent nor the Expat licence are mentioned
in debian/copyright.

I've verified that this also applies to the current source package in 
Salsa.


-- System Information:
Debian Release: bullseye/sid
 APT prefers focal-updates
 APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 
'focal'), (100, 'focal-backports')

Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm-linux-gnueabihf

Kernel: Linux 5.7.0+bcachefs.git20200728.6288f1b6-1-generic (SMP w/8 
CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en (charmap=UTF-8)

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

Bug#968112: Drop Down Menu In Xiphos Not Working Correctly

[Catsartpics]

This bug with Xiphos also occurs with Linux Mint Debian 4 as well.
Xiphos was installed using Synaptic Package Manager.

Any help would be greatly appreciated.

Bug#968260: libc6: breaks translations when changing the charset to ...//TRANSLIT

[Vincent Lefevre]

Package: libc6
Version: 2.31-3
Severity: important

Since the upgrade to 2.31-3, the translations are no longer working
in Mutt.

In my config, the charset gets automatically set to UTF-8//TRANSLIT
(possibly with something else instead of UTF-8). There is the same
issue with ISO-8859-1//TRANSLIT, but not with UTF-8 or ISO-8859-1.

Reverting to 2.31-2 solves the issue (at least with UTF-8//TRANSLIT).

I can reproduce the issue with:

  LC_MESSAGES=fr_FR /usr/bin/mutt -F muttrc foo

where the muttrc file contains:

set charset=UTF-8//TRANSLIT

or

set charset=ISO-8859-1//TRANSLIT

I get "To: foo@..." instead of "À : foo@...".

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

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

Versions of packages libc6 depends on:
ii  libcrypt1  1:4.4.16-1
ii  libgcc-s1  10.2.0-5

Versions of packages libc6 recommends:
ii  libidn2-0  2.3.0-1

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.74
ii  glibc-doc  2.31-3
ii  libc-l10n  2.31-3
ii  locales2.31-3

-- debconf information:
  glibc/kernel-not-supported:
  glibc/disable-screensaver:
* glibc/restart-services: postfix cups cron atd
  glibc/kernel-too-old:
  glibc/upgrade: true
* libraries/restart-without-asking: false
  glibc/restart-failed:

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

Bug#967487: libubootenv: Cannot build libubootenv with dpkg-buildpackage

[Nobuhiro Iwamatsu]

Hi,

Thanks for your report.

2020年8月4日(火) 19:50 Gylstorff Quirin :
>
> Package: libubootenv-tool
> Version: 0.2-1
> Severity: serious
> Tags: patch ftbfs
> Justification: fails to build from source
>
> Dear Maintainer,
>
> I tried to  build libubootenv-tool with dpkg-buildpackage and the following 
> error
> did occur:
> ```
> -- Detecting C compile features - done
> CMake Error at src/CMakeLists.txt:29 (install):
>   install TARGETS given no RUNTIME DESTINATION for executable target
>   "fw_printenv".
>
>
> CMake Error at src/CMakeLists.txt:30 (install):
>   install TARGETS given no RUNTIME DESTINATION for executable target
>   "fw_setenv".
> ```

Hmm, I checked this on unstable but didn't reproduce it.
I attached a build log.
Could you tell me the environment you have confirmed?

>
> I fix the build error by moving the
> ```
> include("GNUInstallDirs")
> ```
> from Subject: [PATCH 2/4] Add support GNUInstallDirs
> before
> ```
>  add_subdirectory (src)
> ```
>

I see.
Indeed, this will fix your issue.

> Best regards,
> Quirin
>
Best regards,
  Nobuhiro

> -- System Information:
> Debian Release: 10.5
>   APT prefers stable
>   APT policy: (800, 'stable'), (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.19.0-10-amd64 (SMP w/8 CPU cores)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US, LC_CTYPE=en_US (charmap=UTF-8) (ignored: LC_ALL set to 
> en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
> en_US.UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled



-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6


libubootenv-0.2.buildlog.nocolor.gz
Description: application/gzip

Bug#965002: mumble: New upstream version available (1.3.2)

[Chris Knadle]

Jonathan Rubenstein:
> On Wed, 15 Jul 2020 04:27:16 + Chris Knadle  
> wrote:
> Are there any blockers in updating to the new version?

I did an upload of 1.3.2 this evening, so it's just pending acceptance.

   -- Chris

-- 
Chris Knadle
chris.kna...@coredump.us

Bug#968258: caja-dropbox: obnoxious advertising

[Marc Lehmann]

Package: caja-dropbox
Version: 1.20.0-4
Severity: minor

Dear Maintainer,

when installing the package, it currently displays the following advertising:

   Dropbox is the easiest way to share and store your files online. Want to 
learn more? Head to https://www.dropbox.com/

I find this very questionable - why does debian make (likely false) claims like 
this? On what base is dropbox
advertised as the "easiest way to share and store your files online"?

I think this should simply be removed, especially as it is likely not even true.

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

Kernel: Linux 5.6.19-050619-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages caja-dropbox depends on:
ii  dbus-x11  1.12.20-0+deb10u1
ii  gir1.2-gdkpixbuf-2.0  2.38.1+dfsg-1
ii  gir1.2-glib-2.0   1.58.3-2
ii  gir1.2-gtk-3.03.24.5-1
ii  gir1.2-pango-1.0  1.42.4-8~deb10u1
ii  libatk1.0-0   2.30.0-2
ii  libc6 2.30-4
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
pn  libcaja-extension1
ii  libgdk-pixbuf2.0-02.38.1+dfsg-1
ii  libglib2.0-0  2.58.3-2+deb10u2
ii  libgtk-3-03.24.5-1
ii  libpango-1.0-01.42.4-8~deb10u1
ii  libpangocairo-1.0-0   1.42.4-8~deb10u1
ii  policykit-1   0.105-25
ii  procps2:3.3.15-2
ii  python2.7.16-1
ii  python-gpg1.12.0-6
ii  python-gtk2   2.24.0-5.1+b1
ii  python3   3.7.3-1
ii  python3-gi3.30.4-1
ii  python3-gpg   1.12.0-6

caja-dropbox recommends no packages.

Versions of packages caja-dropbox suggests:
pn  caja  

Bug#964358: libedit2: Pasting a very large line crashes libedit

[Ángel]

severity 964358 grave
affects 964358 php-cli

Package: libedit2
Version: 3.1-20181209-1

#964358 crash is also affecting packaged programs that link to libedit,
such as php-cli.



Steps to reproduce:
 php -r 'echo str_repeat("a", 2000);'
 Copy the output

 Run php -a
 Paste the above

It seems to differ based on the terminal size, with 100 columns it seems to be 
about 1500 characters. Enlarging a few columns it may move to 1800, etc.
Running under gdb, the limit seems to increase, too, but it's nevertheless 
reproducible.

Using the symbols from php7.3-cli-dbgsym and libedit2-dbgsym:
(...)
Program received signal SIGSEGV, Segmentation fault.
re__copy_and_pad (width=100, src=, 
dst=0x4 ) at refresh.c:1018
1018refresh.c: No such file or directory.
(gdb) bt
#0  re__copy_and_pad (width=100, src=, 
dst=0x4 ) at refresh.c:1018
#1  re_fastputc (el=el@entry=0x55b1a210, c=c@entry=97) at refresh.c:1129
#2  0x74aac353 in re_fastaddc (el=el@entry=0x55b1a210) at 
refresh.c:1171
#3  0x74aa3d02 in ed_insert (el=0x55b1a210, c=97) at common.c:96
#4  0x74aaa792 in el_wgets (el=el@entry=0x55b1a210, 
nread=nread@entry=0x7fffcbc4)
at read.c:538
#5  0x74aa5dc3 in el_gets (el=0x55b1a210, 
nread=nread@entry=0x7fffcbc4) at eln.c:75
#6  0x74ab84f6 in readline (p=0x7507b018 "php > ") at readline.c:453
#7  0x7523481a in ?? () from /usr/lib/php/20180731/readline.so
#8  0x55885916 in do_cli (argc=2, argv=0x55a12c90) at 
./sapi/cli/php_cli.c:995
#9  0x55661b1b in main (argc=2, argv=0x55a12c90) at 
./sapi/cli/php_cli.c:1393


There is a similar (more related to autocompletion) libedit crash
mentioned in openbsd-tech:
https://marc.info/?l=openbsd-tech=156463894328592=2
which points to NetBSD
https://github.com/NetBSD/src/commit/b91b3c48e0edb116bd797586430cb426b575d717
initializating a number of buffers using calloc. That one references
https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=54399
However, PR54399 is a crash on history functions, unrelated to the
above. The other calloc() could be fixing this problem, though.

Updating libedit2 from 3.1-20181209-1 (buster) to 3.1-20191231-1 (bullseye) I 
can no longer reproduce the crash.

Bug#968200: missing files for bblxml features

[Norbert Preining]

On Wed, 12 Aug 2020, Norbert Preining wrote:
> much of the documentation that is added in the github tarball.

Here is the diffstat, most are dist/* files irrelevant for us

 META.json|  177
 META.yml |  124
 b/.gitignore |   18
 b/Changes|   10
 b/MANIFEST.SKIP  |   18
 b/RELEASE|   24
 b/data/gen_latin.pl  |   54
 b/dist/MSWIN32/build.bat |   89
 b/dist/MSWIN64/build.bat |   89
 b/dist/build-env-local.sh|   77
 b/dist/build_master-local.sh |  220
 b/dist/cygwin32/build.sh |   89
 b/dist/cygwin64/build.sh |   89
 b/dist/darwin_x86_64/build.sh|   90
 b/dist/darwinlegacy_x86_64/build.sh  |   86
 b/dist/empty_tree.sh |   22
 b/dist/freebsd_amd64/biber.files |   15
 b/dist/freebsd_amd64/build.sh|   56
 b/dist/freebsd_i386/biber.files  |   15
 b/dist/freebsd_i386/build.sh |   56
 b/dist/linux_armel/biber.files   |   18
 b/dist/linux_armel/build.sh  |   39
 b/dist/linux_x86_32/build.sh |   95
 b/dist/linux_x86_32/striprpath.sh|   26
 b/dist/linux_x86_64-musl/build.sh|   99
 b/dist/linux_x86_64/build.sh |   98
 b/dist/obsolete/darwin_x86_i386/build.sh |   88
 b/dist/re-package.sh |  120
 b/dist/solaris_i386/biber.files  |   16
 b/dist/solaris_i386/build.sh |   41
 b/dist/solaris_x86_64/biber.files|   16
 b/dist/solaris_x86_64/build.sh   |   41
 b/dist/xsl-transform.pl  |   23
 b/doc/biber.tex  |1
 b/etc/TUG-10-2019.pdf|binary
 b/etc/TUG-10-2019.tex|  164
 b/etc/biber-tb-final.tex |  275
 b/etc/bibtex.g   |  413
 b/etc/btparse.notes  |8
 b/etc/definitions.bib|  690
 b/etc/papers.bib |15133 +
 b/etc/parser.dlg |  215
 b/etc/test.tex   |9
 b/etc/tugboat.bib|73993 
++
 b/etc/tugboat.def| 3611 
 b/etc/tugtest.tex|8
 b/htdocs/biber.css   |   72
 b/htdocs/castor.png  |binary
 b/htdocs/index.html  |  139
 b/lib/Biber/Config.pm|2
 b/lib/Biber/Output/bblxml.pm |  820
 51 files changed, 97388 insertions(+), 303 deletions(-)

Best

Norbert

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

Bug#968047: closed by Debian FTP Masters (reply to Norbert Preining ) (Bug#968047: fixed in texlive-extra 2020.20200804-2)

[Norbert Preining]

> That change did not make it into the package, the B+R still contain the
> old version:

Uggh, ACKed ... sometimes one cannot see the forest between all the trees ...

 # CharisSIL-*.ttf moved from texlive-fonts-extra to texlive-fonts-extra-links
-filemove;texlive-fonts-extra;texlive-fonts-extra;2020.20200804
+filemove;texlive-fonts-extra;texlive-fonts-extra-links;2020.20200804
 # scripts/cloze/cloze.lua moved from texlive-latex-extra to texlive-luatex

Thanks

Norbert

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

Bug#968200: missing files for bblxml features

[Norbert Preining]

Hi Hilmar,

> > No, I am using the releas tarballs from sourceforge.
> > 
> ...which is identical to that on CTAN.

Which both seem to be bugged, the config says BETA VERSION ...
and the release tarball on github is definitely more complete.

Hilmar, I have locally imported the github tarball as
2.14+1.orig.tar.gz
and updated the package. I think we could go with that, and include
much of the documentation that is added in the github tarball.

WDYT? Should I push that to the repo or do you prefer your work to be
uploaded first, and then superseeded by 2.14+1?

Best

Norbert

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

Bug#968255:

[allan]

Apologies for multiple uploads of same file and for inline conky.conf
- reportbug wasn't making me happy this afternoon  :)

-- 
we see things not as they are, but as we are.
 -- anais nin

Bug#968047: closed by Debian FTP Masters (reply to Norbert Preining ) (Bug#968047: fixed in texlive-extra 2020.20200804-2)

[Andreas Beckmann]

Control: found -1 2020.20200804-2

That change did not make it into the package, the B+R still contain the
old version:

Package: texlive-fonts-extra-links
Source: texlive-extra
Version: 2020.20200804-2
Replaces: texlive-fonts-extra (<< 2019.20191208)
Breaks: texlive-fonts-extra (<< 2019.20191208)


Andreas

Bug#968200: missing files for bblxml features

[Norbert Preining]

Dear John

Sorry, I mixed up to items (working in both at the same time) due to 
insufficient coffee supply..

Sorry for the noise, and thanks for your work

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

Aug 12, 2020 08:57:35 John Bowman :

> Hi Norbert,Are we talking about the Asymptote project? I don't know anything 
> about Biber and don't recognize the filename bblxml. Neither does my 
> development computer:
> 
> locate bblxml
> 
> returns nothing and, in the git code, git releases, and sf releases,
> 
> find . -name 'bbl*'
> 
> also returns nothing. My apologies if I am misunderstanding.
> 
> Cheers,
> 
> -- John
> 
> On Tue, Aug 11, 2020 at 6:39 AM Norbert Preining  
> wrote:
> 
>> Hi John,
>> 
>> (please if possible keep Cc)
>> 
>> Norbert from the TeX Live and the Debian/TeX Live team here.
>> 
>> It was reported to us that the release tar balls (on CTAN and on 
>> sf.net[http://sf.net])
>> seem to miss the file
>> bblxml.p[lm]
>> while this file is present in the github tar balls.
>> 
>> This leads to errors like
>> 
>>> $ biber --help | grep output-format
>>>     --output-format=dot|bibtex|biblatexml|bbl|bblxml
>>> $ biber --output-format=bblxml main
>>> INFO - This is Biber 2.14 (beta)
>>> INFO - Logfile is 'main.blg'
>>> ERROR - Error loading data source package 'Biber::Output::bblxml': Can't 
>>> locate Biber/Output/bblxml.pm[http://bblxml.pm] in @INC (you may need to 
>>> install the Biber::Output::bblxml module) (@INC contains: /etc/perl 
>>> /usr/local/lib/x86_64-linux-gnu/perl/5.30.3 /usr/local/share/perl/5.30.3 
>>> /usr/lib/x86_64-linux-gnu/perl5/5.30 /usr/share/perl5 
>>> /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.30 
>>> /usr/share/perl/5.30 /usr/local/lib/site_perl) at (eval 393) line 1.
>> 
>> (This is from Debian)
>> 
>> Is this a simple hiccup and the file should be included, or is there
>> something we are missing?
>> 
>> Thanks a lot and all the best
>> 
>> Norbert
>> 
>> --
>> PREINING Norbert https://www.preining.info
>> Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
>> GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
> 

Bug#968256: src:zfs-linux: x32 support

[наб]

Source: zfs-linux
Version: 0.8.4-2
Severity: wishlist
Tags: patch

Hi!

I'd recently ported the SPL to x32 [1], but didn't post it here because
the mailing list setup confused me a bit at the time and thought 0.9.0
would come sooner rather than later.

However, I've now found the list, failed to post to it twice, so I'm
opening this bug and attaching my patches, up/downdated for 0.8.4-2;
they're plug-and-play and I've been running them like this since early
May, but I'm not sure if there's anything more to be done on the
packaging side.

Best,
наб

[1]: https://github.com/openzfs/zfs/pull/10357
From 478e589977e6137dca88eefe3e8114a200163021 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=BD=D0=B0=D0=B1?= 
Date: Mon, 18 May 2020 00:00:49 +0200
Subject: [PATCH 1/2] Correctly handle the x32 ABI

__x86_64__ && _ILP32 => don't forcibly define _LP64

Closes #844
---
 include/spl/sys/isa_defs.h| 6 +-
 lib/libspl/include/sys/isa_defs.h | 6 +-
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/include/spl/sys/isa_defs.h b/include/spl/sys/isa_defs.h
index b62a021ee..61072da33 100644
--- a/include/spl/sys/isa_defs.h
+++ b/include/spl/sys/isa_defs.h
@@ -40,9 +40,13 @@
 #define	__x86
 #endif
 
+#if defined(_ILP32)
+/* x32-specific defines; careful to *not* define _LP64 here */
+#else
 #if !defined(_LP64)
 #define	_LP64
 #endif
+#endif
 
 #define	_ALIGNMENT_REQUIRED	1
 
@@ -209,7 +213,7 @@
 #else
 /*
  * Currently supported:
- * x86_64, i386, arm, powerpc, s390, sparc, mips and risc-v
+ * x86_64, x32, i386, arm, powerpc, s390, sparc, mips and risc-v
  */
 #error "Unsupported ISA type"
 #endif
diff --git a/lib/libspl/include/sys/isa_defs.h b/lib/libspl/include/sys/isa_defs.h
index 35f500f71..b2ad2a1f4 100644
--- a/lib/libspl/include/sys/isa_defs.h
+++ b/lib/libspl/include/sys/isa_defs.h
@@ -46,9 +46,13 @@ extern "C" {
 #define	__x86
 #endif
 
+#if defined(_ILP32)
+/* x32-specific defines; careful to *not* define _LP64 here */
+#else
 #if !defined(_LP64)
 #define	_LP64
 #endif
+#endif
 
 #if !defined(_LITTLE_ENDIAN)
 #define	_LITTLE_ENDIAN
@@ -204,7 +208,7 @@ extern "C" {
 #else
 /*
  * Currently supported:
- * x86_64, i386, arm, powerpc, s390, sparc, and mips, riscv64
+ * x86_64, x32, i386, arm, powerpc, s390, sparc, and mips, riscv64
  */
 #error "Unsupported ISA type"
 #endif
-- 
2.28.0.rc1

From ade28f70e0098e4f58b194c07da80881763803ac Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=BD=D0=B0=D0=B1?= 
Date: Thu, 21 May 2020 21:53:13 +0200
Subject: [PATCH 2/2] Always use "%lld" for formatting time_ts

Given the following test program:
  #include 
  #include 
  #include 
  int main() {
printf("time_t:%d\n", sizeof(time_t));
printf("long:  %d\n", sizeof(long));
printf("long long: %d\n", sizeof(long long));
  }

These are output on various x86 architectures:
  x32$   time_t:8
  x32$   long:  4
  x32$   long long: 8

  amd64$ time_t:8
  amd64$ long:  8
  amd64$ long long: 8

  i386$  time_t:4
  i386$  long:  4
  i386$  long long: 8

Therefore code using "%l[du]" to format time_ts produced warnings on x32
---
 lib/libspl/timestamp.c   | 2 +-
 lib/libzfs/libzfs_sendrecv.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/lib/libspl/timestamp.c b/lib/libspl/timestamp.c
index eab15f3f1..22ecb3940 100644
--- a/lib/libspl/timestamp.c
+++ b/lib/libspl/timestamp.c
@@ -51,7 +51,7 @@ print_timestamp(uint_t timestamp_fmt)
 		fmt = nl_langinfo(_DATE_FMT);
 
 	if (timestamp_fmt == UDATE) {
-		(void) printf("%ld\n", t);
+		(void) printf("%lld\n", (longlong_t)t);
 	} else if (timestamp_fmt == DDATE) {
 		char dstr[64];
 		int len;
diff --git a/lib/libzfs/libzfs_sendrecv.c b/lib/libzfs/libzfs_sendrecv.c
index 10241f530..21e5c7d85 100644
--- a/lib/libzfs/libzfs_sendrecv.c
+++ b/lib/libzfs/libzfs_sendrecv.c
@@ -4606,8 +4606,8 @@ zfs_receive_one(libzfs_handle_t *hdl, int infd, const char *tosnap,
 		zfs_nicebytes(bytes, buf1, sizeof (buf1));
 		zfs_nicebytes(bytes/delta, buf2, sizeof (buf1));
 
-		(void) printf("received %s stream in %lu seconds (%s/sec)\n",
-		buf1, delta, buf2);
+		(void) printf("received %s stream in %lld seconds (%s/sec)\n",
+		buf1, (longlong_t)delta, buf2);
 	}
 
 	err = 0;
-- 
2.28.0.rc1



signature.asc
Description: PGP signature

Bug#968257: release-notes: UpgradingToBuster: apt doesn't report how much space is needed, apt-get does

[Braiam]

Package: release-notes
Severity: normal

Dear Maintainer,

In "4.4.3. Make sure you have sufficient space for the upgrade" the first
code bloc shows using apt with Trivial-Only option to show how much space
is needed for the operation; but buster apt command does not show this string.
Using apt-get here would be correct.

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

Kernel: Linux 5.7.0-1-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash

Bug#968200: missing files for bblxml features

[John Bowman]

Hi Norbert,
Are we talking about the Asymptote project? I don't know anything about
Biber and don't recognize the filename bblxml. Neither does my
development computer:

locate bblxml

returns nothing and, in the git code, git releases, and sf releases,

find . -name 'bbl*'

also returns nothing. My apologies if I am misunderstanding.
Cheers,

-- John


On Tue, Aug 11, 2020 at 6:39 AM Norbert Preining 
wrote:

> Hi John,
>
> (please if possible keep Cc)
>
> Norbert from the TeX Live and the Debian/TeX Live team here.
>
> It was reported to us that the release tar balls (on CTAN and on sf.net)
> seem to miss the file
> bblxml.p[lm]
> while this file is present in the github tar balls.
>
> This leads to errors like
>
> > $ biber --help | grep output-format
> > --output-format=dot|bibtex|biblatexml|bbl|bblxml
> > $ biber --output-format=bblxml main
> > INFO - This is Biber 2.14 (beta)
> > INFO - Logfile is 'main.blg'
> > ERROR - Error loading data source package 'Biber::Output::bblxml': Can't
> locate Biber/Output/bblxml.pm in @INC (you may need to install the
> Biber::Output::bblxml module) (@INC contains: /etc/perl
> /usr/local/lib/x86_64-linux-gnu/perl/5.30.3 /usr/local/share/perl/5.30.3
> /usr/lib/x86_64-linux-gnu/perl5/5.30 /usr/share/perl5
> /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.30
> /usr/share/perl/5.30 /usr/local/lib/site_perl) at (eval 393) line 1.
>
> (This is from Debian)
>
> Is this a simple hiccup and the file should be included, or is there
> something we are missing?
>
> Thanks a lot and all the best
>
> Norbert
>
> --
> PREINING Norbert  https://www.preining.info
> Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
> GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
>

Bug#932385: Bug still exists

[Felicia P]

Just did a fresh install of Buster and can confirm that this bug is very 
annoying and still exists.  I try to create custom shortcuts for Okular 
similar to single-key shortcuts in Acrobat DC:

h - hand tool
v - text selection tool
F8 - toggle toolbar
F9 - toggle menu bar

Multiple times I edit the shortcuts and save, but they are not saved.  
Please fix this!



ii  okular 4:17.12.2-2.2   amd64    universal 
document viewer

Distributor ID: Debian
Description:    Debian GNU/Linux 10 (buster)
Release:    10
Codename:   buster

Bug#968190: gnome-terminal is not listed by firefox when it wants to share a screen

[Marcin Szamotulski]

Thanks, that's indeed the case.

On Mon, 10 Aug 2020 19:19:29 +0100 Simon McVittie  wrote:
> On Mon, 10 Aug 2020 at 11:20:33 +, Marcin Szamotulski wrote:
> >Trying to share a gnome-terminal window in firefox (firefox-79.0, but
> >also in previous versions of firefox).
> 
> If you're in the default (Wayland) GNOME session, gnome-terminal doesn't
> have any X11 windows. I suspect Firefox can only share X11 windows.
> 
> Please try this workaround (this assumes you are using gdm, other display
> managers will probably have a similar flow):
> 
> - save documents, etc.
> - log out
> - choose/enter your username
> - before typing your password, click the gear-wheel icon and select
>   session type "GNOME on Xorg"
> - finish logging back in
> 
> If that is successful, then my guess about the cause was probably correct.
> 
> The long-term solution to window and desktop sharing in GNOME Wayland
> sessions is to use Pipewire, but the version of Pipewire currently in
> Debian is too old (#954022) and Firefox doesn't support it yet anyway
> (https://bugzilla.mozilla.org/show_bug.cgi?id=1430775).
> 
> smcv
> 
> 


signature.asc
Description: PGP signature


signature.asc
Description: OpenPGP digital signature

Bug#968246: dnstwist: Autopkgtest failure due to depgrecation warning with dnspython 2.0.0

[Scott Kitterman]

On Tuesday, August 11, 2020 1:38:52 PM EDT Peter Wienemann wrote:
> Hi Scott,
> 
> On 11.08.20 17:54, Scott Kitterman wrote:
> > Unless you object, I'll probably do an NMU to do that since this will
> > block dnspython testing migration.  I'll post a diff to the bug before I
> > do.
> 
> that is fine with me.
> 
> @Security tools team: I requested a review/upload of a new version of
> dnstwist last week [0]. Given Scott's planned NMU it might be good to
> hold off the upload of the new version until the NMU is acknowledged.
> 
> Best regards,
> 
> Peter
> 
> [0] https://lists.debian.org/debian-security-tools/2020/08/msg0.html

Now that you can upload it yourself, how do you want to handle this?

Scott K

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

Bug#968231: global: does not index definitions with pygments anymore

[Punit Agrawal]

Hi Gregory,

On Tue, Aug 11, 2020 at 11:48 PM Gregory Heytings  wrote:

[...]

> The bug is a modification in gtags.conf:
>
>   pygments-parser|Pygments plug-in parser:\
> :tc=common:\
> -   :ctagscom=/usr/bin/ctags:\
> +   :ctagscom=/usr/bin/ctags-exuberant:\
> :pygmentslib=$libdir/gtags/pygments-parser.la:\
> :langmap=ABAP\:.abap:\
> :langmap=ANTLR\:.G.g:\
>
> When exuberant-ctags (which is not a dependency of global) is not
> installed, definitions are not indexed.

Thanks for digging into this. After uninstalling exuberant-ctags,
"main" is no longer in the database.

% gtags -d GTAGS
 __.COMPNAME __.COMPNAME
 __.COMPRESS __.COMPRESS ddefine ttypedef
 __.VERSION  __.VERSION 6

I will look into this (hopefully later today) and look for a way to
fix the regression.

In the meantime, a temporary workaround is to drop the
":ctagscom=/usr/bin/ctags-exuberant" as in your previous post.

Thanks,
Punit

Bug#967885: Forwarded to upstream authors

[Marcos Fouces]

tags 967885 forwarded
thanks

Bug#963760: new upstream release (1.4.10)

[Daniel Baumann]

retitle 963760 new upstream release (1.4.11)
thanks

...and now there's 1.4.11.

Regards,
Daniel

Bug#966935: libpandoc-wrapper-perl: FTBFS: dh_auto_test: error: perl Build test --verbose 1 returned exit code 1

[itd]

Hi,

Lucas Nussbaum  writes:

>> #   at t/methods.t line 86.
>> #  got: '> class="header-section-number">1 x
>> # '
>> # expected: '1 
>> x
>> # '
>> # Looks like you failed 1 test of 36.

my best guess is that this is caused by changes in pandoc or its
dependencies.  (And the duplicate 'data-number' attribute did not appear
in pandoc newer than 2.9.2.)

In case that's an option: require pandoc 2.9.1 and patch the test.

>> #   Failed test 'parse->to_html'
>> #   at t/parse.t line 35.
>> # Looks like you failed 1 test of 5.

Above test does something along the following lines and expects output
(but none is produced):

#!/usr/bin/env perl
# libpandoc-elements-perl 0.38-1
# libpandoc-wrapper-perl 0.9.0-1
use Pandoc;
print(pandoc->parse( 'markdown' => '# A *section*' )->to_html);
# EOF

'to_html' is declared around line 461 in lib/Pandoc/Elements.pm of
libpandoc-elements-perl (in a 'foreach' loop).  In parts it does
something similar ('"blocks"' value simplified) to:

#!/bin/bash
# pandoc 2.9.1.1-3
pandoc -f json -t html<<<'{"blocks":[],"pandoc-api-version":[1,17],"meta":{}}'
# EOF

which produces the following output:

> JSON parse error: Error in $: Incompatible API versions: encoded with
> [1,17] but attempted to decode with [1,20].

After bumping 1,17 to 1,20 in above command pandoc produces an empty
HTML document.  libpandoc-wrapper-perl's test succeeds with the
following libpandoc-elements-perl hack (I'm not convinced it is
correct):

--- libpandoc-elements-perl-0.38.orig/lib/Pandoc/Elements.pm
+++ libpandoc-elements-perl-0.38/lib/Pandoc/Elements.pm
@@ -23,6 +23,7 @@ my $PANDOC_BIN_MIN = Pandoc::Version->ne
 
 # release version => minimal required api version
 my @REQUIRED_API = map { Pandoc::Version->new($_) }
+'2.9.1'  => '1.20',  # TODO this is a blindtext; please remove this FIXME
 '1.19'   => '1.17',  # pandoc 1.19 has api 1.17.0.4, compatible with api 
1.17
 '1.18'   => '1.17',  # pandoc 1.18 has api 1.17.0.4, compatible with api 
1.17
 '1.16'   => '1.16',  # pandoc 1.16 has api 1.16


Regards
itd

Bug#968214: ultracopier FTCBFS: missing Build-Depends: qt5-qmake:native for lrelease

[Thomas Preud'homme]

On 2020-08-10 22:06, Helmut Grohne wrote:

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

ultracopier fails to cross build from source, because it runs lrelease
on a .pro file without the relevant build dependency on
qt5-qmake:native. Please consider applying the attached patch.


tag 968214 + moreinfo
thanks


Hi Helmut,

It seems from #920878 that all I need would be to actually build-depend 
on dpkg >= 1.20.0 and export QMAKE or did I misunderstand? BTW what's 
the error message when nonnative lrelease is run? I only saw on the bug 
what happens when it's called without qmake altogether.


Best regards,

Thomas

Bug#968246: dnstwist: Autopkgtest failure due to depgrecation warning with dnspython 2.0.0

[Samuel Henrique]

Hello,

> On Tuesday, August 11, 2020 1:38:52 PM EDT Peter Wienemann wrote:
> > @Security tools team: I requested a review/upload of a new version of
> > dnstwist last week [0]. Given Scott's planned NMU it might be good to
> > hold off the upload of the new version until the NMU is acknowledged.

I'm sorry for that, your request skipped my TODO list, please feel
free to ping me directly on the future:

dcut ftp-master dm --uid "foss...@posteo.de>"  --allow dnstwist
Uploading commands file to ftp.upload.debian.org (incoming: /pub/UploadQueue/)
Picking DM Peter Wienemann  with fingerprint
7F44F1E078290D700045BC275D5F6C020398A60A
Uploading samueloph-1597179981.dak-commands to ftp-master

You should be good to perform the uploads for dnstwist now :)

Regards,

-- 
Samuel Henrique 

Bug#967022: mes: FTBFS: checking for cc is Mes C....config.c:2:2: error: #error no mesc

[Vagrant Cascadian]

Control: retitle 967022 mes: FTBFS: test failure on amd64: 
lib/tests/scaffold/63-struct-cell.c
Control: forwarded 967022 
https://lists.gnu.org/archive/html/bug-mes/2020-07/msg4.html

Thanks for the report!

On 2020-08-03, Lucas Nussbaum wrote:
>> [0;31mFAIL[m: lib/tests/scaffold/63-struct-cell.c

I believe it is this test suite failure that failed the build, which
passes on i386, and used to pass before gcc 10. Supporting non-i386
architectures for mes is ongoing work upstream...


I'm wondering if you might consider adding a size limit check to your
reporting scripts; the initial "short" log was nearly 3MB and caused
issues for my mail client (on an admittedly slow machine).

Thanks!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#957189: f-irc: diff for NMU version 1.36-1.1

[Sudip Mukherjee]

Control: tags 957189 + patch
Control: tags 957189 + pending

Dear maintainer,

I've prepared an NMU for f-irc (versioned as 1.36-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should cancel it.

--
Regards
Sudip

diff -Nru f-irc-1.36/debian/changelog f-irc-1.36/debian/changelog
--- f-irc-1.36/debian/changelog 2014-02-23 12:31:13.0 +
+++ f-irc-1.36/debian/changelog 2020-08-11 20:50:06.0 +0100
@@ -1,3 +1,10 @@
+f-irc (1.36-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix ftbfs with GCC-10. (Closes: #957189)
+
+ -- Sudip Mukherjee   Tue, 11 Aug 2020 20:50:06 
+0100
+
 f-irc (1.36-1) unstable; urgency=low
 
   * New upstream release.
diff -Nru f-irc-1.36/debian/patches/fix_ftbfs.patch 
f-irc-1.36/debian/patches/fix_ftbfs.patch
--- f-irc-1.36/debian/patches/fix_ftbfs.patch   1970-01-01 01:00:00.0 
+0100
+++ f-irc-1.36/debian/patches/fix_ftbfs.patch   2020-08-11 20:49:01.0 
+0100
@@ -0,0 +1,18 @@
+Description: Fix ftbfs with GCC-10
+
+Author: Sudip Mukherjee 
+Bug-Debian: https://bugs.debian.org/957189
+Forwarded: no
+
+---
+
+--- f-irc-1.36.orig/theme.c
 f-irc-1.36/theme.c
+@@ -17,7 +17,6 @@
+ #include "theme.h"
+ #include "utils.h"
+ 
+-layout_theme theme;
+ const char *theme_file = NULL;
+ 
+ theme_parsing theme_parser[] =
diff -Nru f-irc-1.36/debian/patches/series f-irc-1.36/debian/patches/series
--- f-irc-1.36/debian/patches/series1970-01-01 01:00:00.0 +0100
+++ f-irc-1.36/debian/patches/series2020-08-11 20:42:56.0 +0100
@@ -0,0 +1 @@
+fix_ftbfs.patch

Bug#968254: ddclient: "my" variable $use masks earlier declaration in same scope at /usr/sbin/ddclient line 986.

[pada]

Package: ddclient
Version: 3.9.1-5
Severity: normal

Dear Maintainer,

   * What led up to the situation?

[UPGRADE] ddclient:amd64 3.8.3-1.1 -> 3.9.1-5

   * What exactly did you do (or not do) that was effective (or ineffective)?

cat > .ddclient.conf 

Bug#968253: linux-image-armmp: Enable NVMEM_IMX_OCOTP

[Walter Lozano]

Package: linux-image-armmp
Version: 5.7.10-1
Severity: normal

Dear Maintainer,

Please take a look to Merge Request

https://salsa.debian.org/kernel-team/linux/-/merge_requests/254

On iMX6Q boards, when probing cpufreq, it tries to read efuse settings,
however, as NVMEM_IMX_OCOTP is not enabled this can't be done. In this
situation the probe fails with -EPROBE_DEFER, and cpufreq is not available.

To avoid all the mentioned issues, while these issues are fixed in the upstream
kernel (patch already sent), enable NVMEM_IMX_OCOTP as builtin driver.



-- System Information:
Debian Release: buster/sid
  APT prefers eoan-updates
  APT policy: (500, 'eoan-updates'), (500, 'eoan-security'), (500, 'eoan'), 
(100, 'eoan-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#968252: gai.conf should mention ip addrlabel

[Marc Haber]

Package: libc-bin
Version: 2.31-3
Severity: normal
Tags: ipv6

Hi,

it looks like the label values set in the gai.conf file are ignored.
Instead, the values configured in the live kernel via ip addrlabel are
used.


It might be possible that there is some magic at bootup reading gai.conf
and poking the content in the kernel, but in the running system it looks
like ip addrlabel is the way to do configuration.

This should be properly reflected in the comments inside the gai.conf
file that comes with libc-bin.

Greetings
Marc

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

Kernel: Linux 5.8.0-zgws1 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libc-bin depends on:
ii  libc6  2.31-3

Versions of packages libc-bin recommends:
ii  manpages  5.07-1

libc-bin suggests no packages.

-- no debconf information

Bug#928738: closed by Brian Potkin (Re: Bug#928738: printer-driver-cups-pdf Still Produces PDF Files that Lack Searchable Text and are Unusable with pdftotext)

[193]

Just want to point out that the solution on removing and reinstalling
printer-driver-cups-pdf didnt worked for me on my buster system which i
upgraded from stretch. i have this issue since then and was happy to
find this solution which unluckily didnt work for me.

i managed to find a very old print job in the pdf qeue which maybe the
cause for this failure in the update process. "cancel" this old job and
repeting the solution didnt work either.

so i followed the advice in the debian wiki
https://wiki.debian.org/CUPSDebugging and issued "lpadmin -p
 -o pdftops-renderer-default=pdftocairo" to the (in my case
named) queue "PDF"

that solves the problem. lpoptions -d PDF shows the correct output and
the printing is as expected.

thanks to neil and brian who directed me in the right direction :-)

kind regards

steve

Bug#966825: transition: libcdio

[Sebastian Ramacher]

Control: tags -1 + confirmed

On 2020-08-02 17:36:00 -0300, Gabriel F. T. Gomes wrote:
> Package: release.debian.org
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: gabr...@debian.org, sergi...@debian.org, vasek.ge...@gmail.com
> Severity: normal
> 
> Hi,
> 
> libcdio needs a transition (upstream bumped the SONAME without ABI break).
> 
> I built all the packages reported at:
> 
>   https://release.debian.org/transitions/html/auto-libcdio.html
> 
> using the following approach (on an up-to-date debian unstable machine):
> 
>   1. Fetch with: apt source 
>   2. Build with sbuild on a sid chroot with libcdio-dev from experimental:
>sbuild \
>  --extra-repository='deb http://deb.debian.org/debian experimental 
> main' \
>  --build-dep-resolver=aptitude \
>  --add-depends="libcdio-dev (= 2.1.0-1)" \
>  .dsc
> 
> These are the packages:
> 
>   audacious-plugins_4.0.4-1
>   audiotools_3.1.1-1.1
>   cdw_0.8.1-1
>   clementine_1.4.0~rc1+git174-gcb64d9705+dfsg-2
>   cmus_2.8.0-2
>   daisy-player_11.7.3-1
>   fuse-umfuse-iso9660_0.3-1.3
>   gmerlin_1.2.0~dfsg+1-6.1
>   gmerlin-avdecoder_1.2.0~dfsg-10
>   gst-plugins-ugly1.0_1.16.2-2
>   gvfs_1.44.1-1
>   kodi_18.7+dfsg1-1
>   libcddb_1.3.2-6
>   libcdio_2.0.0-2
>   libcdio-paranoia_10.2+2.0.0-1
>   libdevice-cdio-perl_2.0.0-1
>   mpd_0.21.22-1
>   mplayer_1.3.0-8
>   mpv_0.32.0-2
>   pragha_1.3.4-2
>   pycdio_2.1.0-1
>   qmmp_1.3.1-1.1
>   simpleburn_1.8.0-1
>   tellico_3.3.1-1
>   vcdimager_2.0.1+dfsg-3
>   virtualjaguar_2.1.3-2
>   xine-lib-1.2_1.2.10-4
>   xmms2_0.8+dfsg-20
> 
> All built OK, except for:
> 
>   gst-plugins-ugly1.0
>   mplayer
>   kodi
> 
> The problem with them is not related to libcdio:
> 
>   * gst-plugins-ugly1.0:
> - currently FTBFS (https://bugs.debian.org/963347).

This was fixed.

> - building from experimental (version 1.17.2-1) works OK.
> 
>   * mplayer:
> - builds OK but hangs on lintian (troff process using 100% cpu).
> - killing the troff process lets the build finish successfully.

lintian isn't run on the buildds, so that isn't a problem.

So please feel free to go ahead with the upload to unstable.

Cheers

> 
>   * kodi:
> - not in testing.
> 
> According to
> 
>   grep-dctrl -FBuild-Depends libcdio-dev -w -sPackage 
> /var/lib/apt/lists/*Sources
> 
> libcddb also build-depends on libcdio-dev, so I tested it using the
> same approach and it builds OK, but the generated binary is not
> actually linked against libcdio.
> 
> 
> Ben file:
> 
> title = "libcdio";
> is_affected = .depends ~ "libcdio18" | .depends ~ "libcdio19";
> is_good = .depends ~ "libcdio19";
> is_bad = .depends ~ "libcdio18";
> 
> 
> Cheers,
> Gabriel



-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#966703: linux-image-4.19.0-10-amd64: kworker process with permanent high CPU load

[Salvatore Bonaccorso]

Hi Dirk,

On Tue, Aug 11, 2020 at 12:58:15PM +0200, Dirk Kostrewa wrote:
> Hi Salavatore,
> 
> as an additional control, I have completely uninstalled the nvidia graphics
> driver and repeated the kworker observations using the nouveau graphics
> driver with the kernel 4.19.0-10-amd64. This time, there are even two
> kworker processes constantly running with high CPU load:
> 
> $ top
> top - 12:37:20 up 10 min,  4 users,  load average: 2.79, 2.54, 1.56
> Tasks: 197 total,   3 running, 194 sleeping,   0 stopped,   0 zombie
> %Cpu(s):  0.0 us, 24.2 sy,  0.0 ni, 74.2 id,  0.0 wa, 0.0 hi,  1.6 si,  0.0
> st
> MiB Mem :  15889.4 total,  13964.7 free,    626.8 used, 1297.9 buff/cache
> MiB Swap:  0.0 total,  0.0 free,  0.0 used. 14849.1 avail Mem
> 
>   PID USER  PR  NI    VIRT    RES    SHR S  %CPU %MEM TIME+ COMMAND
>   164 root  20   0   0  0  0 R  80.0 0.0   8:41.67
> kworker/6:2+pm
>   455 root  20   0   0  0  0 R  80.0 0.0   8:28.23
> kworker/2:2+pm
>    22 root  20   0   0  0  0 S  20.0 0.0   2:14.82
> ksoftirqd/2
>    42 root  20   0   0  0  0 S  20.0 0.0   2:08.67
> ksoftirqd/6
>     1 root  20   0  169644  10212   7796 S   0.0 0.1   0:01.52 systemd
>     2 root  20   0   0  0  0 S   0.0 0.0   0:00.00 kthreadd
>     3 root   0 -20   0  0  0 I   0.0 0.0   0:00.00 rcu_gp
>     4 root   0 -20   0  0  0 I   0.0 0.0   0:00.00
> rcu_par_gp
>     6 root   0 -20   0  0  0 I   0.0 0.0   0:00.00
> kworker/0:0H-kblockd
>     7 root  20   0   0  0  0 I   0.0 0.0   0:00.05
> kworker/u16:0-event+
> 
> The stacks of the two kworker processes show the same output:
> 
> [<0>] 0x
> 
> I have appended the top 5000 lines tracing as a compressed ascii file
> out-cut.txt,gz and the dmesg output as compressed ascii file dmesg.txt.gz.
> 
> I hope, this helps to find out where the problem with the high CPU load of
> the kworker processes come from.

Thanks this is very helpful.

I suspect what you are seeing is an issue with the usb hubport present
before but now uncovered due to the upstream change e9fb08d617bf
("xhci: prevent bus suspend if a roothub port detected a over-current
condition")[1], which was as well backported to v4.19.y in 4.19.119.

Can you add some dynamic debugging on the 'drivers/usb/'[2] ideally at
boot time. On runtime it is 

# echo 'file drivers/usb/* +p;' > /sys/kernel/debug/dynamic_debug/control

or as kernel parameter to have enable the debug messages at boot time
already:

dyndbg="file drivers/usb/* +p;"

Can you attach the dmesg with the enabled debugging?

Regards,
Salvatore

 [1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e9fb08d617bfae5471d902112667d0eeb9dee3c4
 [2] https://www.kernel.org/doc/html/latest/admin-guide/dynamic-debug-howto.html

Bug#968244: mailman3-web: Crash with: /usr/share/mailman3-web/manage.py runjobs daily

[Athanasius]

Package: mailman3-web
Version: 0+20180916-8
Severity: normal

Dear Maintainer,

After installing mailman3 I used migrated old Mailman 2.1 lists in using
'import21' and then their archives using 'python manage.py
hyperkitty_import -l ...'.

All seems to have gone OK, but the daily mailman3-web job in
/etc/cron.d/mailman3-web:

@daily www-data [ -f /usr/bin/django-admin ] && flock -n 
/var/run/mailman3-web/cron.daily /usr/share/mailman3-web/manage.py runjobs daily

is throwing errors:

Traceback (most recent call last):
  File 
"/usr/lib/python3/dist-packages/django_extensions/management/commands/runjobs.py",
 line 36, in runjobs
job().execute()
  File "/usr/lib/python3/dist-packages/hyperkitty/jobs/sync_mailman.py", line 
35, in execute
sync_with_mailman()
  File "/usr/lib/python3/dist-packages/hyperkitty/lib/mailman.py", line 145, in 
sync_with_mailman
sender.set_mailman_id()
  File "/usr/lib/python3/dist-packages/hyperkitty/models/sender.py", line 54, 
in set_mailman_id
mm_user = client.get_user(self.address)
  File "/usr/lib/python3/dist-packages/mailmanclient/client.py", line 322, in 
get_user
return User(self._connection, content['self_link'], content)
KeyError: 'self_link'
ERROR OCCURED IN DAILY JOB: sync_mailman (APP: hyperkitty)
START TRACEBACK:
END TRACEBACK

Adding a little debug output:

Address: #.pleasegivegenerou...@hotmail.com
Response: {'date': 'Tue, 11 Aug 2020 14:35:42 GMT', 'server': 'WSGIServer/0.2 
CPython/3.7.3', 'content-length': '712742', 'content-type': 'application/json; 
charset=UTF-8', 'status': '200', 'content-location': 
'http://river-nat:8001/3.0/users/#.pleasegivegenerou...@hotmail.com'}

And the 'content' at that point is *huge* (693KiB), indeed without a
'self_link' key at its top level, although it contains an 'entries'
array in which each member has a 'self_link' key.

This appears to be code to sync up hyperkitty's idea of senders with
actual members of the list, so is probably relatively harmless, but I
don't know if *subsequent* more important code is being prevented from
running.

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

Kernel: Linux 4.19.138-fysh-kvmguest (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mailman3-web depends on:
ii  dbconfig-sqlite3   2.0.11+deb10u1
ii  debconf [debconf-2.0]  1.5.71
ii  lsb-base   10.2019051400
ii  node-less  1.6.3~dfsg-3
ii  python33.7.3-1
ii  python3-django-hyperkitty  1.2.2-1
ii  python3-django-postorius   1.2.4-1
ii  python3-psycopg2   2.7.7-1
ii  python3-whoosh 2.7.4+git6-g9134ad92-4
ii  sassc  3.5.0-1
ii  ucf3.0038+nmu1
ii  uwsgi  2.0.18-1
ii  uwsgi-plugin-python3   2.0.18-1

Versions of packages mailman3-web recommends:
pn  libapache2-mod-proxy-uwsgi | nginx  

Versions of packages mailman3-web suggests:
ii  mariadb-server-10.3 [virtual-mysql-server]  1:10.3.23-0+deb10u1

-- debconf information:
  mailman3-web/upgrade-error: abort
  mailman3-web/superuser-name: admin
  mailman3-web/pgsql/authmethod-user: password
  mailman3-web/restart-webserver: true
  mailman3-web/nginx-choice:
  mailman3-web/missing-db-package-error: abort
  mailman3-web/mysql/method: Unix socket
  mailman3-web/configure-webserver: none
  mailman3-web/dbconfig-upgrade: true
  mailman3-web/install-error: abort
  mailman3-web/pgsql/admin-user: postgres
  mailman3-web/dbconfig-remove: true
  mailman3-web/pgsql/changeconf: false
  mailman3-web/upgrade-backup: true
  mailman3-web/db/dbname: mailman3web
  mailman3-web/internal/skip-preseed: false
  mailman3-web/purge: false
  mailman3-web/remote/port:
  mailman3-web/superuser-mail: root@localhost
  mailman3-web/db/app-user: mailman3web@localhost
* mailman3-web/dbconfig-install: false
  mailman3-web/remove-error: abort
  mailman3-web/pgsql/manualconf:
  mailman3-web/pgsql/method: TCP/IP
  mailman3-web/remote/host: localhost
  mailman3-web/emailname: fysh.org
  mailman3-web/mysql/admin-user:
  mailman3-web/remote/newhost:
  mailman3-web/dbconfig-reinstall: false
  mailman3-web/passwords-do-not-match:
  mailman3-web/db/basepath: /var/lib/mailman3/web
  mailman3-web/pgsql/authmethod-admin: ident
  mailman3-web/internal/reconfiguring: false
  mailman3-web/pgsql/no-empty-passwords:
  mailman3-web/database-type:

Bug#968251: nfs-kernel-server fails to start at boot

[fireba11]

Package: nfs-kernel-server
Version: 1:1.3.4-2.5+deb10u1
Severity: important

Dear Maintainer,

after the last update(s) nfs-kernel-server fails to start since the path to 
export isn't available yet.
adding a sleep 30 to the unit file works as a workaround ...
naturally starting the service manually after boot works too

it's probably an edge case since i got a large raid 5 with luks on a rather 
slow CPU so onlocking it takes quite a bit, my guess is the dependencies in the 
unit file don't work for that case


-- Package-specific info:
-- rpcinfo --
   program vers proto   port  service
104   tcp111  portmapper
103   tcp111  portmapper
102   tcp111  portmapper
104   udp111  portmapper
103   udp111  portmapper
102   udp111  portmapper
-- /etc/default/nfs-kernel-server --
RPCNFSDCOUNT=8
RPCNFSDPRIORITY=0
RPCMOUNTDOPTS="--manage-gids"
NEED_SVCGSSD=""
RPCSVCGSSDOPTS=""
-- /etc/exports --
/srv/path1   1.2.3.4(rw,async,no_subtree_check) 
2.3.4.5(rw,async,no_subtree_check) 3.4.5.6(rw,async,no_subtree_check)
/srv/path2   1.2.3.4(rw,async,no_subtree_check) 
2.3.4.5(rw,async,no_subtree_check) 3.4.5.6(rw,async,no_subtree_check)
-- /proc/fs/nfs/exports --
# Version 1.1
# Path Client(Flags) # IPs

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

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

Versions of packages nfs-kernel-server depends on:
ii  keyutils  1.6-6
ii  libblkid1 2.33.1-0.1
ii  libc6 2.28-10
ii  libcap2   1:2.25-2
ii  libsqlite3-0  3.27.2-3
ii  libtirpc3 1.1.4-0.4
ii  libwrap0  7.6.q-28
ii  lsb-base  10.2019051400
ii  netbase   5.6
ii  nfs-common1:1.3.4-2.5+deb10u1
ii  ucf   3.0038+nmu1

nfs-kernel-server recommends no packages.

nfs-kernel-server suggests no packages.

-- no debconf information

Bug#966483: iptables-netflow: sourcing of external scripts in dkms file?

[Gianfranco Costamagna]

Hello Axel,

> Yeah, and the version.sh call itself can be removed, too. Will do.
> 
> Thanks for bringing this up despite the initially differing opinions.
> :-)
> 

thanks to you!

And forgive me if I wasn't clear enough, I wrote the email after a somewhat
deep analysis of the issue, and my initial effort was to have something like a 
"dkms.in" evaulated during build into a "dkms" file, after doing the 
substitutions.

Unfortunately, it became a little difficult to implement, due to the version.sh 
file
not being easy to convert into a "sed s/FOO/foo/g < dkms.in > dkms"

This is what I did before thinking it was not easily upstreamable:

diff -Nru iptables-netflow-2.5/debian/patches/patch 
iptables-netflow-2.5/debian/patches/patch
--- iptables-netflow-2.5/debian/patches/patch   1970-01-01 01:00:00.0 
+0100
+++ iptables-netflow-2.5/debian/patches/patch   2020-08-11 21:00:13.0 
+0200
@@ -0,0 +1,30 @@
+--- iptables-netflow-2.5.orig/Makefile.in
 iptables-netflow-2.5/Makefile.in
+@@ -43,7 +43,7 @@ mclean:
+ lclean:
+   -rm -f *.so *_sh.o
+ clean: mclean lclean
+-  -rm -f *.so *.o modules.order version.h compat_def.h
++  -rm -f *.so *.o modules.order version.h compat_def.h dkms.conf
+ 
+ snmp_NETFLOW.so: snmp_NETFLOW.c
+   $(CC) -fPIC -shared -o $@ $< -lnetsnmp
+@@ -76,6 +76,7 @@ version.h: ipt_NETFLOW.c ipt_NETFLOW.h c
+ 
+ linstall: | libipt_NETFLOW.so libip6t_NETFLOW.so
+   @echo " *"
++  sed s/@VERSION@/$(shell ./version.sh)/g < dkms.conf.in > dkms.conf
+   install -D libipt_NETFLOW.so 
$(DESTDIR)$(IPTABLES_MODULES)/libipt_NETFLOW.so
+   install -D libip6t_NETFLOW.so 
$(DESTDIR)$(IPTABLES_MODULES)/libip6t_NETFLOW.so
+ 
+--- /dev/null
 iptables-netflow-2.5/dkms.conf.in
+@@ -0,0 +1,8 @@
++PACKAGE_NAME="ipt-netflow"
++PACKAGE_VERSION=@VERSION@
++BUILT_MODULE_NAME[0]=ipt_NETFLOW
++DEST_MODULE_LOCATION[0]=/kernel/extra
++STRIP[0]=no
++MAKE[0]="make ipt_NETFLOW.ko"
++PRE_BUILD="./configure --from-dkms-conf=$kernel_source_dir"
++AUTOINSTALL=yes


and then I simplified rules file, to drop the VERSION sed.

--- iptables-netflow-2.5/debian/rules   2020-05-20 17:20:43.0 +0200
+++ iptables-netflow-2.5/debian/rules   2020-08-11 21:01:54.0 +0200
@@ -42,5 +42,5 @@
[ ! -e Makefile ] || $(MAKE) lclean
 
 override_dh_dkms:
-   sed -e 
's#`\./version.sh`#$(DEB_VERSION_UPSTREAM)#;s#^PRE_BUILD="\(.*\)"#PRE_BUILD="\1 
$(DKMS_CONFIGURE_OPTIONS)"#' dkms.conf > debian/dkms
+   sed -e 's#^PRE_BUILD="\(.*\)"#PRE_BUILD="\1 
$(DKMS_CONFIGURE_OPTIONS)"#' dkms.conf > debian/dkms
dh_dkms


this looks somewhat upstreamable, and also Debian friendly (I'm not sure if 
having a .git directory makes the script fail to provide the correct output, 
this is one reason for me not giving the patch before)

Feel free to send it upstream if you like it!

thanks a lot!

G.

Bug#950198: restinio

[Petter Reinholdtsen]

[Alexandre Viau]
> I have just uploaded a new version of opendht.
>
> For the next step I will attempt to build Jami to see if there is
> anything missing.

Hi.  Is there any progress on this?

I see there is a new version of restino available, perhaps time to
update it?  I doubt it will solve the atomic issue, but might be a good
idea to get the latest fixes into Debian.

-- 
Alexandre Viau
av...@debian.org

Bug#968231: global: does not index definitions with pygments anymore

[Gregory Heytings]

Hi Punit,

The bug is a modification in gtags.conf:

 pygments-parser|Pygments plug-in parser:\
:tc=common:\
-   :ctagscom=/usr/bin/ctags:\
+   :ctagscom=/usr/bin/ctags-exuberant:\
:pygmentslib=$libdir/gtags/pygments-parser.la:\
:langmap=ABAP\:.abap:\
:langmap=ANTLR\:.G.g:\

When exuberant-ctags (which is not a dependency of global) is not 
installed, definitions are not indexed.


Gregory

Bug#968246: dnstwist: Autopkgtest failure due to depgrecation warning with dnspython 2.0.0

[Scott Kitterman]

On Tuesday, August 11, 2020 1:38:52 PM EDT Peter Wienemann wrote:
> Hi Scott,
> 
> On 11.08.20 17:54, Scott Kitterman wrote:
> > Unless you object, I'll probably do an NMU to do that since this will
> > block dnspython testing migration.  I'll post a diff to the bug before I
> > do.
> 
> that is fine with me.
> 
> @Security tools team: I requested a review/upload of a new version of
> dnstwist last week [0]. Given Scott's planned NMU it might be good to
> hold off the upload of the new version until the NMU is acknowledged.
> 
> Best regards,
> 
> Peter
> 
> [0] https://lists.debian.org/debian-security-tools/2020/08/msg0.html

That or you could just add:

Restrictions: allow-stderr

to debian/tests/control in your upload and close the bug in debian/changelog.  
No real need for two uploads.

Scott K

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

Bug#968250: cryptsetup: FTBFS with systemd installed

[Daniel Schepler]

Source: cryptsetup
Version: 2.3.3-1
Severity: normal

>From my sbuild log:

...
checking for systemd tmpfiles config directory... /usr/lib/tmpfiles.d
...
   dh_missing -a
dh_missing: warning: usr/lib/tmpfiles.d/cryptsetup.conf exists in
debian/tmp but is not installed to anywhere (related file:
"scripts/cryptsetup.conf")
dh_missing: error: missing files, aborting

Some of the files had a file that looked similar to a missing
counter part. Perhaps
one of the debhelper tools should installed the missing file
instead of its related
file assuming the content is identical.

As an example, perhaps you want to replace:
 * scripts/cryptsetup.conf
with:
 * usr/lib/tmpfiles.d/cryptsetup.conf
in a file in debian/ or as argument to one of the dh_* tools
called from debian/rules.
(Note it is possible the paths are not used verbatim but
instead directories
containing or globs matching them are used instead)

Alternatively, add the missing file to debian/not-installed if
it cannot and should not
be used.

The following debhelper tools have reported what they
installed (with files per package)
 * dh_install: cryptsetup (19), cryptsetup-bin (27),
cryptsetup-initramfs (15), cryptsetup-run (0), cryptsetup-udeb (16),
libcryptsetup-dev (3), libcryptsetup12 (2), libcryptsetup12-udeb (2)
 * dh_installdocs: cryptsetup (53), cryptsetup-bin (0),
cryptsetup-initramfs (1), cryptsetup-run (0), libcryptsetup-dev (1),
libcryptsetup12 (0)
 * dh_installexamples: cryptsetup (1), cryptsetup-bin (0),
cryptsetup-initramfs (0), cryptsetup-run (0), libcryptsetup-dev (0),
libcryptsetup12 (0)
 * dh_installman: cryptsetup (4), cryptsetup-bin (0),
cryptsetup-initramfs (0), cryptsetup-run (0), libcryptsetup-dev (0),
libcryptsetup12 (0)
If the missing files are installed by another tool, please
file a bug against it.
When filing the report, if the tool is not part of debhelper
itself, please reference the
"Logging helpers and dh_missing" section from the
"PROGRAMMING" guide for debhelper (10.6.3+).
  (in the debhelper package: /usr/share/doc/debhelper/PROGRAMMING.gz)
Be sure to test with dpkg-buildpackage -A/-B as the results
may vary when only a subset is built
For a short-term work-around: Add the files to debian/not-installed
make: *** [debian/rules:19: binary-arch] Error 25
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned
exit status 2

I do have systemd installed in my chroot image, since I'm using a
custom version of sbuild with a backend using systemd-nspawn to start
up a container to build in.
-- 
Daniel Schepler

Bug#968237: auctex-12

[Barak A. Pearlmutter]

Dear Itaï,

Thanks for trying to contribute to Debian.

> I am not a Debian developper, but am able to package (in fact I have packaged 
> auctex v12 for personal use).

If you have auctex-12 packaged, I would very much encourage you to
share your work, even if the debian maintainer doesn't seem very
active. The easiest way is probably to just fork

https://salsa.debian.org//salve/auctex.git

into your own salsa account and push your changes there. This makes a
bunch of things easier.

(I note that right now upstream is at 12.2, and the current version
not only has functionality issues but also fails to build. So the
package could use a little love. Maybe the maintainer would welcome a
co-maintainer?)

Cheers,

--Barak.

Bug#966998: patch

[Harald Dunkel]

Attached you can find the diff.
commit 15d82dfe4f7900be54e06b6ca0a79321ee2a9b34
Author: Christian Brauner 
Date:   Sat Jul 25 11:36:46 2020 +0200

selinux: remove security_context_t usage as it's deprecated

Link: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1888705
Signed-off-by: Christian Brauner 

diff --git a/src/lxc/lsm/selinux.c b/src/lxc/lsm/selinux.c
index dba0ab584..e28731e8f 100644
--- a/src/lxc/lsm/selinux.c
+++ b/src/lxc/lsm/selinux.c
@@ -32,15 +32,11 @@ lxc_log_define(selinux, lsm);
  */
 static char *selinux_process_label_get(pid_t pid)
 {
-	security_context_t ctx;
 	char *label;
 
-	if (getpidcon_raw(pid, ) < 0) {
-		SYSERROR("failed to get SELinux context for pid %d", pid);
-		return NULL;
-	}
-	label = strdup((char *)ctx);
-	freecon(ctx);
+	if (getpidcon_raw(pid, ) < 0)
+		return log_error_errno(NULL, errno, "failed to get SELinux context for pid %d", pid);
+
 	return label;
 }
 
@@ -63,10 +59,8 @@ static int selinux_process_label_set(const char *inlabel, struct lxc_conf *conf,
 	const char *label;
 
 	label = inlabel ? inlabel : conf->lsm_se_context;
-	if (!label) {
-
+	if (!label)
 		label = DEFAULT_LABEL;
-	}
 
 	if (strcmp(label, "unconfined_t") == 0)
 		return 0;
@@ -75,11 +69,9 @@ static int selinux_process_label_set(const char *inlabel, struct lxc_conf *conf,
 		ret = setexeccon_raw((char *)label);
 	else
 		ret = setcon_raw((char *)label);
-	if (ret < 0) {
-		SYSERROR("Failed to set SELinux%s context to \"%s\"",
-			 on_exec ? " exec" : "", label);
-		return -1;
-	}
+	if (ret < 0)
+		return log_error_errno(-1, errno, "Failed to set SELinux%s context to \"%s\"",
+   on_exec ? " exec" : "", label);
 
 	INFO("Changed SELinux%s context to \"%s\"", on_exec ? " exec" : "", label);
 	return 0;
@@ -98,16 +90,17 @@ static int selinux_keyring_label_set(char *label)
 };
 
 static struct lsm_drv selinux_drv = {
-	.name = "SELinux",
-	.enabled   = is_selinux_enabled,
-	.process_label_get = selinux_process_label_get,
-	.process_label_set = selinux_process_label_set,
-	.keyring_label_set = selinux_keyring_label_set,
+	.name			= "SELinux",
+	.enabled		= is_selinux_enabled,
+	.process_label_get	= selinux_process_label_get,
+	.process_label_set	= selinux_process_label_set,
+	.keyring_label_set	= selinux_keyring_label_set,
 };
 
 struct lsm_drv *lsm_selinux_drv_init(void)
 {
 	if (!is_selinux_enabled())
 		return NULL;
+
 	return _drv;
 }

Bug#907496: libcurlpp0: Always fails with "No URL set!"

[Aloïs Micard]

This bug has been finally reproduced on a refresh VM.

It happens when the NSS flavour of libcurl4-dev is installed.
Otherwise with both GnuTLS / OpenSSL it works without problem.

I will write a patch to fix that.

Cheers

--
Aloïs Micard (creekorful) 

GPG: DA4A A436 9BFA E299 67CD E85B F733 E871 0859 FCD2

Bug#968246: dnstwist: Autopkgtest failure due to depgrecation warning with dnspython 2.0.0

[Peter Wienemann]

Hi Scott,

On 11.08.20 17:54, Scott Kitterman wrote:
> Unless you object, I'll probably do an NMU to do that since this will block 
> dnspython testing migration.  I'll
> post a diff to the bug before I do.

that is fine with me.

@Security tools team: I requested a review/upload of a new version of
dnstwist last week [0]. Given Scott's planned NMU it might be good to
hold off the upload of the new version until the NMU is acknowledged.

Best regards,

Peter

[0] https://lists.debian.org/debian-security-tools/2020/08/msg0.html

Bug#968249: okular: Can't see correctly same icons

[Teo]

Package: okular
Version: 4:20.04.3-1
Severity: minor
Tags: patch
X-Debbugs-Cc: teodoro777.coluc...@live.com

I can't see the side icons correctly on "thumbnails", "reviews", "bookmarks". I
installed okular in debian with gnome and i'm using the default adwaita theme.



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

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

Versions of packages okular depends on:
ii  kinit 5.70.0-1
ii  kio   5.70.1-1
ii  libc6 2.31-2
ii  libfreetype6  2.10.2+dfsg-3
ii  libjpeg62-turbo   1:1.5.2-2+b1
ii  libkf5activities5 5.70.0-1
ii  libkf5archive55.70.0-1
ii  libkf5bookmarks5  5.70.0-1
ii  libkf5codecs5 5.70.0-1
ii  libkf5completion5 5.70.0-1
ii  libkf5configcore5 5.70.0-1
ii  libkf5configgui5  5.70.0-1
ii  libkf5configwidgets5  5.70.0-2
ii  libkf5coreaddons5 5.70.0-1
ii  libkf5crash5  5.70.0-1
ii  libkf5i18n5   5.70.0-1
ii  libkf5iconthemes5 5.70.0-1
ii  libkf5itemviews5  5.70.0-1
ii  libkf5jobwidgets5 5.70.0-1
ii  libkf5kexiv2-15.0.0   20.04.3-1
ii  libkf5kiocore55.70.1-1
ii  libkf5kiowidgets5 5.70.1-1
ii  libkf5parts5  5.70.0-1
ii  libkf5pty55.70.0-1
ii  libkf5purpose-bin 5.70.0-1
ii  libkf5purpose55.70.0-1
ii  libkf5service-bin 5.70.0-1
ii  libkf5service55.70.0-1
ii  libkf5textwidgets55.70.0-1
ii  libkf5wallet-bin  5.70.0-1
ii  libkf5wallet5 5.70.0-1
ii  libkf5widgetsaddons5  5.70.0-1
ii  libkf5windowsystem5   5.70.0-1
ii  libkf5xmlgui5 5.70.0-1+b1
ii  libokular5core9   4:20.04.3-1
ii  libphonon4qt5-4   4:4.11.1-3
ii  libpoppler-qt5-1  0.71.0-6
ii  libqca-qt5-2  2.3.1-1
ii  libqmobipocket2   4:20.04.3-1
ii  libqt5core5a  5.14.2+dfsg-4
ii  libqt5dbus5   5.14.2+dfsg-4
ii  libqt5gui55.14.2+dfsg-4
ii  libqt5printsupport5   5.14.2+dfsg-4
ii  libqt5svg55.14.2-2
ii  libqt5texttospeech5   5.14.2-2
ii  libqt5widgets55.14.2+dfsg-4
ii  libqt5xml55.14.2+dfsg-4
ii  libspectre1   0.2.8-2
ii  libstdc++610.1.0-6
ii  phonon4qt54:4.11.1-3
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages okular recommends:
ii  cups-bsd  2.3.3-2

Versions of packages okular suggests:
ii  ghostscript9.52~dfsg-1
pn  okular-extra-backends  
ii  poppler-data   0.4.9-2
pn  texlive-binaries   
ii  unrar  1:5.6.6-2

-- no debconf information

Bug#968226: Build-Depends-If-Available

[Russ Allbery]

Wouter Verhelst  writes:

> -policy: this is a question that has come up before
> (https://lists.debian.org/debian-devel/2016/12/msg00470.html is another
> example that springs to mind, but I'm pretty sure there are more), so I
> think we should document in Policy that a) buildd only looks at the
> first dependency in alternative build-dependencies, and b) why this is
> the case.

Policy already says:

While Build-Depends, Build-Depends-Indep and Build-Depends-Arch permit
the use of alternative dependencies, these are not normally used by
the Debian autobuilders. To avoid inconsistency between repeated
builds of a package, the autobuilders will default to selecting the
first alternative, after reducing any architecture-specific
restrictions for the build architecture in question. While this may
limit the usefulness of alternatives in a single release, they can
still be used to provide flexibility in building the same package
across multiple distributions or releases, where a particular
dependency is met by differently named packages.

in 7.1.  However, it's hidden in a footnote.  Perhaps we should make it
more prominant (and make it clear that it's normative), and tweak the
wording.

-- 
Russ Allbery (r...@debian.org)  

Bug#968231: global: does not index definitions with pygments anymore

[Gregory Heytings]

Hi Punit,

On my computer this is the output:

echo 'int main(){return 0;}' > main.c
export GTAGSLABEL=pygments

sudo dpkg -i global_6.6.4-3_amd64.deb
gtags -v
[Tue Aug 11 12:58:15 UTC 2020] Gtags started.
 Using configuration file '/etc/gtags/gtags.conf'.
 Using configuration label 'pygments'.
 Using plug-in parser.
[Tue Aug 11 12:58:15 UTC 2020] Creating 'GTAGS' and 'GRTAGS'.
 [1] extracting tags of main.c
[Tue Aug 11 12:58:15 UTC 2020] Done.
gtags -d GTAGS
 __.COMPNAME __.COMPNAME
 __.COMPRESS __.COMPRESS ddefine ttypedef
 __.VERSION  __.VERSION 6
main1 @n 1 int @n(){return 0;}

sudo dpkg -i global_6.6.4-4_amd64.deb
gtags -v
[Tue Aug 11 12:59:10 UTC 2020] Gtags started.
 Using configuration file '/etc/gtags/gtags.conf'.
 Using configuration label 'pygments'.
 Using plug-in parser.
[Tue Aug 11 12:59:10 UTC 2020] Creating 'GTAGS' and 'GRTAGS'.
 [1] extracting tags of main.c
[Tue Aug 11 12:59:10 UTC 2020] Done.
gtags -d GTAGS
 __.COMPNAME __.COMPNAME
 __.COMPRESS __.COMPRESS ddefine ttypedef
 __.VERSION  __.VERSION 6

Gregory

Bug#966575: How to fix LLVM/LUKS installs?

[Colin Watson]

On Tue, Aug 11, 2020 at 12:51:17PM -0400, Todd Howe wrote:
> I got around to fixing my desktop today. In addition to the instructions I
> posted above and the procedure to mount system directories below, there was
> only one necessary change:
> 
> https://gist.github.com/samuelcolvin/43c5ed2807e7db004b1058d0c9bfb068
> 
> That guy suggested used grub-install /dev/sda instead of dpkg-reconfigure
> grub-pc.

If you do this, then it will work for now but you may still have a
problem on later upgrades.  You must do "dpkg-reconfigure grub-pc" at
some point and instruct it to install to the right place, even if you
didn't do it as part of the initial recovery process.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#966575: How to fix LLVM/LUKS installs?

[Todd Howe]

I got around to fixing my desktop today. In addition to the instructions I
posted above and the procedure to mount system directories below, there was
only one necessary change:

https://gist.github.com/samuelcolvin/43c5ed2807e7db004b1058d0c9bfb068

That guy suggested used grub-install /dev/sda instead of dpkg-reconfigure
grub-pc.

That worked no problem. Thanks for your help!

Todd

On Tue, 4 Aug 2020 23:04:17 +0100 Colin Watson  wrote:
> On Tue, Aug 04, 2020 at 05:08:44PM -0400, Todd Howe wrote:
> > ls /media/root/$UUID
> > apt install grub
> > grub-install --root-directory=/media/root/$UUID /dev/sda
>
> I generally don't recommend this sort of approach.  Instead, and
> simpler:
>
>   for x in dev proc sys; do
> mount --rbind "/$x" "/media/root/$UUID/$x"
>   done
>   chroot "/media/root/$UUID/$x"
>   dpkg-reconfigure grub-pc
>   exit
>   for x in dev proc sys; do
> umount -l "/media/root/$UUID/$x"
>   done
>
> (Untested and there may be some minor roadblocks, but this is my usual
> approach; if you do this interactively then hopefully it'll be
> reasonably clear how to make whatever minor adjustments are needed.  I
> think it's essentially just the bind-mounts that you were missing when
> you tried to chroot later on.)
>
> --
> Colin Watson (he/him)  [cjwat...@debian.org]
>
>

Bug#968248: orca: Do not install Orca 3.36.4; wait for Orca 3.36.5

[Samuel Thibault]

Package: orca
Version: 3.36.4-1
Severity: serious
Tags: upstream
Justification: breaks web navigation
Forwarded: https://mail.gnome.org/archives/orca-list/2020-August/msg00085.html

As reported by upstream

https://mail.gnome.org/archives/orca-list/2020-August/msg00085.html

we really need to upload 3.36.5 instead, so let's prevent 3.36.4 from
entering testing.

Samuel

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

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

Versions of packages orca depends on:
ii  gir1.2-glib-2.01.64.1-1
ii  gir1.2-gstreamer-1.0   1.16.2-2
ii  gir1.2-gtk-3.0 3.24.20-1
ii  gir1.2-pango-1.0   1.44.7-4
ii  gir1.2-wnck-3.03.36.0-1
ii  gsettings-desktop-schemas  3.36.1-1
ii  gstreamer1.0-plugins-good  1.16.2-3
ii  python33.8.2-3
ii  python3-brlapi 6.0+dfsg-6
ii  python3-cairo  1.16.2-4
ii  python3-gi 3.36.0-4
ii  python3-louis  3.14.0-1
ii  python3-pyatspi2.37.90-1
ii  python3-speechd0.10.1-1
ii  speech-dispatcher  0.10.1-1

Versions of packages orca recommends:
ii  xbrlapi  6.0+dfsg-6

orca suggests no packages.

-- no debconf information

-- 
Samuel
 pour moi le seul qui est autorisé à fasciser, c moi :-)

Bug#968194: Depends on non-existent python version?

[Osamu Aoki]

Hi,

I don't exactly know what is your local problem with python2. You don't
even bother to describe your installation. (as usual from you)

Please expect this getmail package to be EOLed after buster (=Bullseye)

* Debian is moving to python3 only after buster
* Upstream of getmail hasn't move to python3.
* No one so far created python3 version of getmail.
* If you are using testing now, getmail will not work soon on Bullseye.
* getmaul will be dropped soon

Best regards,

Osamu

On Mon, 2020-08-10 at 20:15 +0800, 積丹尼 Dan Jacobson wrote:
> Package: getmail
> Version: 5.13-1
> 
> Aptitude says:
> The following packages will be upgraded:
>   libpython2-stdlib  python2  python2-minimal
> 3 packages upgraded, 0 newly installed, 0 to remove and 0 not
> upgraded.
> 
> The following packages have unmet dependencies:
>  python : Depends: python2 (= 2.7.17-2) but 2.7.18-2 is to be
> installed
>  libpython-stdlib : Depends: libpython2-stdlib (= 2.7.17-2) but
> 2.7.18-2 is to be installed
>  python-minimal : Depends: python2-minimal (= 2.7.17-2) but 2.7.18-2
> is to be installed
> The following actions will resolve these dependencies:
> 
>  Keep the following packages at their current version:
> 1) libpython2-stdlib [2.7.17-2 (now)]
> 2) python2 [2.7.17-2 (now)]
> 3) python2-minimal [2.7.17-2 (now)]
> 
> Accept this solution? [Y/n/q/?] n
> The following actions will resolve these dependencies:
> 
>   Remove the following packages:
> 1)  getmail [5.13-1 (now, unstable)]

Bug#966100: notmuch-mutt: symlinking now fails for indexed mailboxes with a space in the name

[Kevin J. McCarthy]

On Tue, Aug 11, 2020 at 11:24:16AM -0300, David Bremner wrote:

If you can, please test the upstream patch

  
https://nmbug.notmuchmail.org/nmweb/show/20200727193833.4654-1-tomi.ollila%40iki.fi

You'll need to build notmuch from source after applying the patch. "make
debian-snapshot" will produce installable packages.


I patched my notmuch-mutt script directly, and it seems to fix the 
problem for me.  Thank you very much Tomi and David!


-Kevin

Bug#968231: global: does not index definitions with pygments anymore

[Gregory Heytings]

Package: global
Version: 6.6.4-4
Severity: important
X-Debbugs-Cc: g...@sdf.org

Dear Maintainer,

Version 6.6.4-4 of the package does not index definitions with 
GTAGSLABEL=pygments.  Version 6.6.4-3 did.  Steps to reproduce the bug:

echo 'int main(){return 0;}' > main.c
export GTAGSLABEL=pygments
gtags
gtags -d GTAGS | grep -v '^ '

The last command displays "main" with 6.6.4-3, and nothing with 6.6.4-4.

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

Kernel: Linux 5.7.0-2-amd64 (SMP w/8 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 global depends on:
ii  emacsen-common  3.0.4
ii  libc6   2.31-2
ii  libltdl72.4.6-14
ii  libncurses6 6.2-1
ii  libsqlite3-03.32.3-1
ii  libtinfo6   6.2-1

Versions of packages global recommends:
ii  python3  3.8.2-3

Versions of packages global suggests:
pn  doxygen 
pn  exuberant-ctags 
ii  firefox-esr [www-browser]   68.11.0esr-1
pn  id-utils
ii  python3-pygments2.3.1+dfsg-4
ii  w3m [www-browser]   0.5.3-38

-- no debconf information

Bug#968247: kdeconnect: Cannot browse files: "A folder named ~/.cache/kioexec/krun/(numbers)/ already exists"

[kuezlumjkumchpkvwp]

Package: kdeconnect
Version: 1.3.3-2
Severity: normal
Tags: patch upstream




On Debian 10 Buster: Associate with the phone, open the kdeconnect window
in the tray area, click the file browsing button: it errors out with
"A folder named ~/.cache/kioexec/krun/(numbers)/ already exists".


It seems this has been solved upstream? https://askubuntu.com/a/1129886


Workaround (tested):
- find out your device id with kdeconnect-cli -l
- open your file manager on /run/user/$UID/
- credits: https://rafaelc.org/tech/p/a-workaround-for-kde-connect-browsing-bug/


Workaround (non-tested):
- 
https://www.progclub.org/blog/2018/12/14/a-folder-named-cache-kioexec-krun-13821_0-already-exists/

Bug#968246: dnstwist: Autopkgtest failure due to depgrecation warning with dnspython 2.0.0

[Scott Kitterman]

Package: dnstwist
Version: 0~20200424-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Note: Using FTBTS tag since it's the closest thing we have to this
(since autopkgtest failures block testing migration).

>From the autopkgtest log with python3-dnspython 2.0.0-1:

autopkgtest [11:09:49]: test testdebiandomain:  - - - - - - - - - - results - - 
- - - - - - - -
testdebiandomain FAIL stderr: /usr/bin/dnstwist:618: DeprecationWarning: 
please use dns.resolver.Resolver.resolve() instead
autopkgtest [11:09:49]: test testdebiandomain:  - - - - - - - - - - stderr - - 
- - - - - - - -
/usr/bin/dnstwist:618: DeprecationWarning: please use 
dns.resolver.Resolver.resolve() instead
  domain['dns-ns'] = self.answer_to_list(resolv.query(domain['domain-name'], 
'NS'))
/usr/bin/dnstwist:630: DeprecationWarning: please use 
dns.resolver.Resolver.resolve() instead
  domain['dns-a'] = self.answer_to_list(resolv.query(domain['domain-name'], 
'A'))
/usr/bin/dnstwist:638: DeprecationWarning: please use 
dns.resolver.Resolver.resolve() instead
  domain['dns-'] = self.answer_to_list(resolv.query(domain['domain-name'], 
''))
/usr/bin/dnstwist:647: DeprecationWarning: please use 
dns.resolver.Resolver.resolve() instead
  domain['dns-mx'] = self.answer_to_list(resolv.query(domain['domain-name'], 
'MX'))
autopkgtest [11:09:49]:  summary
testdebiandomain FAIL stderr: /usr/bin/dnstwist:618: DeprecationWarning: 
please use dns.resolver.Resolver.resolve() instead

Since it's just a warning, this could be worked around by allowing
stderr output during the test.  Unless you object, I'll probably do an
NMU to do that since this will block dnspython testing migration.  I'll
post a diff to the bug before I do.

In the longer run, porting to the new .resolve class is a better
solution and is usually pretty trivial (s/query/resolve//).

Scott K

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

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

Bug#964880: [Pkg-javascript-devel] Bug#964880: npm: test failures in ppc64el and s390x

[Xavier]

Le 11/07/2020 à 19:54, Gianfranco Costamagna a écrit :
> Source: npm
> Version: 6.14.6+ds-1
> Severity: serious
> 
> Hello, looks like one test is failing on ppc64el and s390x.
> Could you please have a look?
> 
> this on s390x
> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/s390x/n/npm/20200711_092356_eb5fd@/log.gz
> # Subtest: test/tap/legacy-platform-all.js
> # Subtest: setup
> 1..0
> ok 1 - setup # time=2.926ms
> 
> # Subtest: platform-all
> not ok 1 - no error messages
>   ---
>   found: >
> npm ERR! code EBADPLATFORM
>   
> npm ERR! notsup Unsupported platform for 
> npm-test-platform-all@9.9.9-9: wanted
> 
> {"os":"darwin,linux,win32,solaris,haiku,sunos,freebsd,openbsd,netbsd","arch":"arm,arm64,mips,ia32,x64,sparc"}
> (current: {"os":"linux","arch":"s390x"})
>   
> npm ERR! notsup Valid OS:   
> darwin,linux,win32,solaris,haiku,sunos,freebsd,openbsd,netbsd
>   
> npm ERR! notsup Valid Arch:  arm,arm64,mips,ia32,x64,sparc
>   
> npm ERR! notsup Actual OS:   linux
>   
> npm ERR! notsup Actual Arch: s390x
>   
>   
> npm ERR! A complete log of this run can be found in:
>   
> npm ERR!
> 
> /tmp/autopkgtest.TwzxSV/autopkgtest_tmp/smokeh0DzIy/test/npm_cache_legacy-platform-all/_logs/2020-07-11T09_18_58_795Z-debug.log
>   wanted: ''
>   compare: ===
>   at:
> line: 55
> column: 7
> file: test/tap/legacy-platform-all.js
> type: global
> function: installCheckAndTest
>   stack: |
> installCheckAndTest (test/tap/legacy-platform-all.js:55:7)
> f (/usr/lib/nodejs/once/once.js:25:25)
> ChildProcess. (test/common-tap.js:175:5)
>   source: |
> t.is(stderr, '', 'no error messages')
>   ...
> 
> not ok 2 - install went ok
>   ---
>   found: 1
>   wanted: 0
>   compare: ===
>   at:
> line: 56
> column: 7
> file: test/tap/legacy-platform-all.js
> type: global
> function: installCheckAndTest
>   stack: |
> installCheckAndTest (test/tap/legacy-platform-all.js:56:7)
> f (/usr/lib/nodejs/once/once.js:25:25)
> ChildProcess. (test/common-tap.js:175:5)
>   source: |
> t.is(code, 0, 'install went ok')
>   ...
> 
> 1..2
> # failed 2 of 2 tests
> not ok 2 - platform-all # time=767.548ms
> 
> # Subtest: cleanup
> 1..0
> ok 3 - cleanup # time=1.651ms
> 
> 1..3
> # failed 1 of 3 tests
> # time=782.166ms
> not ok 103 - test/tap/legacy-platform-all.js # time=1350.563ms
> 
> 
> and this on ppc64el
> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/ppc64el/n/npm/20200711_093200_7007f@/log.gz
> # Subtest: test/tap/legacy-platform-all.js
> # Subtest: setup
> 1..0
> ok 1 - setup # time=4.916ms
> 
> # Subtest: platform-all
> not ok 1 - no error messages
>   ---
>   found: >
> npm ERR! code EBADPLATFORM
>   
> npm ERR! notsup Unsupported platform for 
> npm-test-platform-all@9.9.9-9: wanted
> 
> {"os":"darwin,linux,win32,solaris,haiku,sunos,freebsd,openbsd,netbsd","arch":"arm,arm64,mips,ia32,x64,sparc"}
> (current: {"os":"linux","arch":"ppc64"})
>   
> npm ERR! notsup Valid OS:   
> darwin,linux,win32,solaris,haiku,sunos,freebsd,openbsd,netbsd
>   
> npm ERR! notsup Valid Arch:  arm,arm64,mips,ia32,x64,sparc
>   
> npm ERR! notsup Actual OS:   linux
>   
> npm ERR! notsup Actual Arch: ppc64
>   
>   
> npm ERR! A complete log of this run can be found in:
>   
> npm ERR!
> 
> /tmp/autopkgtest.RvsIrP/autopkgtest_tmp/smokevhVLkX/test/npm_cache_legacy-platform-all/_logs/2020-07-11T09_24_22_560Z-debug.log
>   wanted: ''
>   compare: ===
>   at:
> line: 55
> column: 7
> file: test/tap/legacy-platform-all.js
> type: global
> function: installCheckAndTest
>   stack: |
> installCheckAndTest (test/tap/legacy-platform-all.js:55:7)
> f (/usr/lib/nodejs/once/once.js:25:25)
> ChildProcess. (test/common-tap.js:175:5)
>   source: |
> t.is(stderr, '', 'no error messages')
>   ...
> 
> not ok 2 - install went ok
>   ---
>   

Bug#968245: fpc: autopkgtest failure.

[peter green]

Package: fpc
Version: 3.2.0+dfsg-5
Severity: serious

The autopkgtest for fpc 3.2.0 is failing


Compiling utests.pp
PPU Loading 
/usr/lib/x86_64-linux-gnu/fpc/3.2.0/units/x86_64-linux/fcl-base/custapp.ppu
PPU Source: custapp.pp not available
Recompiling CustApp, checksum changed for 
/tmp/autopkgtest-lxc.6w1qz1lt/downtmp/build.rui/src/fpcsrc/rtl/units/x86_64-linux/sysutils.ppu
custapp.pp(14,58) Fatal: Can't find unit CustApp used by cgiapp
Fatal: Compilation aborted


It looks like the testsuite is trying (and failing) to use custapp.ppu from the 
package in conjunction with a
locally-built sysutils.ppu. Afaict the test needs to either use the sysutils 
from the package or build it's own custapp
unit.

Bug#968079: [Python-modules-team] Bug#968079: libapache2-mod-wsgi: Package is not installable. Needs older Python2.

[Emmanuel Arias]

Hi,

The package needs some more work.

I plan work on it this week, I hope have some news
in the next few days.


Cheers,
Arias Emmanuel
@eamanu
http://eamanu.com

El mar., 11 de ago. de 2020 a la(s) 12:15, nb (n...@dagami.org) escribió:
>
> How much time does it take to come to sid?
>
> ___
> Python-modules-team mailing list
> python-modules-t...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team

Bug#968079: libapache2-mod-wsgi: Package is not installable. Needs older Python2.

[nb]

How much time does it take to come to sid?

Bug#953528: #953528 -q doesn't work anymore

[Nemo Thorx]

I just stumbled across this same issue - old scripts no longer silent. 

Seems that there is a newer "-s" option


$ pngcrush --help |& grep -e 'silent\|quiet'
-q (quiet) suppresses console output except for warnings
-s (silent) suppresses console output including warnings
$ pngcrush --version
 pngcrush 1.8.13, uses libpng 1.6.36 and zlib 1.2.11


...but pngcrush manpage only lists -q option


$ man pngcrush |& grep -e 'silent\|quiet'
   -qquiet, the opposite of verbose.


.../Nemo


-- 
  - -
earth native

Bug#968236: davmail: Cannot restrict access to private keys for SSL

[Alexandre Rossi]

Hi,

> Davmail seems to run with systemd's DynamicUser configuration. That means
> that the user the daemon runs with is not known before runtime. Therefore
> I cannot give specific permissions to the private keys for SSL. See the
> excerpt from the configuration file /etc/davmail.properties below. I
> use davmail.ssl.keystoreFile to set the file with the certificate and
> the private key. I have to give o+r permissions to make this work,
> because I cannot change the ownership to the user davmail uses.

I can see multiple solutions to this:

1) if you adduser --system _davmail, systemd should use that user and
you can set permissions on your keystoreFile

2) adding to the service the following and the associated script that
copies the keystoreFile in /var/lib/davmail

StateDirectory=davmail
PermissionsStartOnly=true
ExecStartPre=/usr/share/davmail/service-prepare

The second solution would also copy the conf file so that it can be
writable by davmail in order to save Oauth session tokens which does
not work at the moment using DynamicUser. I'll try this solution and
get back to you.

> Aug 11 14:21:52 delta davmail[167802]: 2020-08-11 14:21:52,294 ERROR [main] 
> davmail  - Unable to set log file path
>
> The log file directive in /etc/davmail.properties is also printed below.
> I use davmail.logFilePath to set the log path. But I cannot give the
> daemon the right permissions to the /var/log path, because the user is
> not known before runtime due to the DynamicUser configuration.

The service file reads:

LogsDirectory=davmail

which means that the service is given access to /var/log/davmail/ and
that configuring the following should work:

davmail.logFilePath=/var/log/davmail/davmail.log

(as it is in the default conf)

Thanks a lot for your feedback, and please get back to me on what
works for you so I can document and improve the package on what works
and what does not.

Alex

Bug#966972: [in-toto-dev] Bug#966972: in-toto: FTBFS: ValueError: SSH supports only 1024 bit DSA keys

[Lukas Puehringer]

FYI: We just bumped upstream to include the fix:
https://github.com/secure-systems-lab/securesystemslib/releases/tag/v0.16.0

Will prepare a downstream release later this week.


On 06.08.2020 2:21 PM, Holger Levsen wrote:
> hey Lukas,
> 
> On Thu, Aug 06, 2020 at 02:03:00PM +0200, Lukas Puehringer wrote:
>> FYI: https://github.com/secure-systems-lab/securesystemslib/pull/264 fixes 
>> the
>> issue upstream.
> 
> nice. once it's released we should get this new version into unstable!
> 
> 

-- 
lukas.puehrin...@nyu.edu
PGP fingerprint: 8BA6 9B87 D43B E294 F23E  8120 89A2 AD3C 07D9 62E8



signature.asc
Description: OpenPGP digital signature

Bug#953574: Can version 0.10.1 be packaged already?

[Shlomi Fish]

Hi!

See https://pypi.org/project/pysol-cards/ . It also blocks
freecell-solver's update to 6.0.1. Does anyone wish to assume
responsibility? See the  explanation of "Rosh Gadol" here:
https://www.joelonsoftware.com/2004/12/06/news-45/ .

-- 
Shlomi Fish https://www.shlomifish.org/

Buddha has the Chuck Norris nature.

Please reply to list if it's a mailing list post - http://shlom.in/reply .

Bug#966100: notmuch-mutt: replace shell pipeline with internal pipe processing

[Tomi Ollila]

The shell pipeline used to symlink files based in search results
to "cache" directory for mutt(1) to use was prone to portability
problems (due to /bin/sh differences).

The replacement executes `notmuch search` without intermediate shell
(so shell_quote was removed in this case), reads the filenames from
piped output and symlinks files internally.
---

Now also tested a bit by me (remoteusage provides stale symlinks ;)

 contrib/notmuch-mutt/notmuch-mutt | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/contrib/notmuch-mutt/notmuch-mutt 
b/contrib/notmuch-mutt/notmuch-mutt
index d33223bd..d1e2c084 100755
--- a/contrib/notmuch-mutt/notmuch-mutt
+++ b/contrib/notmuch-mutt/notmuch-mutt
@@ -12,6 +12,7 @@ use strict;
 use warnings;
 
 use File::Path;
+use File::Basename;
 use Getopt::Long qw(:config no_getopt_compat);
 use Mail::Header;
 use Mail::Box::Maildir;
@@ -41,16 +42,17 @@ sub search($$$) {
 my ($maildir, $remove_dups, $query) = @_;
 my $dup_option = "";
 
-$query = shell_quote($query);
-
-if ($remove_dups) {
-  $dup_option = "--duplicate=1";
-}
+my @args = qw/notmuch search --output=files/;
+push @args, "--duplicate=1" if $remove_dups;
+push @args, $query;
 
 empty_maildir($maildir);
-system("notmuch search --output=files $dup_option $query"
-  . " | sed -e 's: : :g'"
-  . " | while IFS= read -r searchoutput; do ln -s \$searchoutput 
$maildir/cur/; done");
+open my $pipe, '-|', @args or die "Running @args failed: $!\n";
+while (<$pipe>) {
+   chomp;
+   my $ln = "$maildir/cur/" . basename $_;
+   symlink $_, "$ln" or warn "Failed to symlink '$_', '$ln': $!\n";
+}
 }
 
 sub prompt($$) {
-- 
2.25.1
___
notmuch mailing list -- notm...@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Bug#968121: [Pkg-pascal-devel] FPC 3.2.0 upload to SID

[peter green]

On 11/08/2020 13:06, Graham Inggs wrote:

I've had a quick look at ddrescue [1], but I don't know how to fix
that.  Does anyone have any suggestions?


Googling the error message took me to 
https://wiki.freepascal.org/User_Changes_Trunk
which has an entry "Property field access lists no longer allows classes" that
seems to describe the problem. Poking around in svn it seems that this change
was backported to 3.2 but they forgot to move the description of it from the
"user changes trunk" to the "user changes 3.2" page.

The solution is to use a getter rather than direct access for the
property. I have attatched a patch that does that, I have tested that it builds
I have not tested it beyond that.



I've also looked at mricron [2][3], and changing '(**)' to '*)' in
both places fixes the compilation, but I have no idea what the '(**)'
means.  Can anyone tell me?


I followed up on this in a seperate mail, but I did not notice that
the maintainer was not the pascal team and hence the mail would
not go to the pkg-pascal-devel list, you can find a copy at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968126#10

diff -Nru ddrescueview-0.4~alpha3/debian/changelog 
ddrescueview-0.4~alpha3/debian/changelog
--- ddrescueview-0.4~alpha3/debian/changelog2019-01-06 08:34:43.0 
+
+++ ddrescueview-0.4~alpha3/debian/changelog2020-08-11 14:26:53.0 
+
@@ -1,3 +1,12 @@
+ddrescueview (0.4~alpha3-3.1) UNRELEASED; urgency=medium
+
+  * Patch proposed to BTS
+  * Use getters rather than direct access for properties that
+access fields in other classes to fix build with fpc 3.2.
+(Closes: 968121)
+
+ -- Peter Michael Green   Tue, 11 Aug 2020 14:26:53 +
+
 ddrescueview (0.4~alpha3-3) unstable; urgency=medium
 
   * Update Vcs-* URIs for move to salsa.debian.org
diff -Nru ddrescueview-0.4~alpha3/debian/patches/series 
ddrescueview-0.4~alpha3/debian/patches/series
--- ddrescueview-0.4~alpha3/debian/patches/series   1970-01-01 
00:00:00.0 +
+++ ddrescueview-0.4~alpha3/debian/patches/series   2020-08-11 
14:23:43.0 +
@@ -0,0 +1 @@
+use-getters-for-fields-in-other-classes.patch
diff -Nru 
ddrescueview-0.4~alpha3/debian/patches/use-getters-for-fields-in-other-classes.patch
 
ddrescueview-0.4~alpha3/debian/patches/use-getters-for-fields-in-other-classes.patch
--- 
ddrescueview-0.4~alpha3/debian/patches/use-getters-for-fields-in-other-classes.patch
1970-01-01 00:00:00.0 +
+++ 
ddrescueview-0.4~alpha3/debian/patches/use-getters-for-fields-in-other-classes.patch
2020-08-11 14:24:54.0 +
@@ -0,0 +1,58 @@
+Description: Use getters for fields in other classes.
+ fpc 3.2 no longer allows properties to directly access fields in other 
classes.
+ use getters instead to work around this.
+Author: Peter Michael Green 
+
+--- ddrescueview-0.4~alpha3.orig/source/Parser.pas
 ddrescueview-0.4~alpha3/source/Parser.pas
+@@ -64,6 +64,10 @@ type
+ function getMap(): TMap;
+ procedure postParse();
+ procedure setContiguous(mode: Boolean);
++function getCommentLines(): TStringList;
++function getVersion(): String;
++function getMapFileName(): String;
++function getDomFileName(): String;
+   public
+ constructor Create;
+ destructor Destroy; override;
+@@ -75,10 +79,10 @@ type
+ function hasDomFile() : Boolean;
+ property rescueStatus : TRescueStatus read FRescueStatus;
+ property map : TMap read getMap;
+-property CommentLines : TStringList read FMapParser.FComments;
+-property Version : String read FMapParser.FVersion;
+-property MapFileName : String read FMapParser.FFileName;
+-property DomFileName : String read FDomParser.FFileName;
++property CommentLines : TStringList read GetCommentLines;
++property Version : String read getVersion;
++property MapFileName : String read getMapFileName;
++property DomFileName : String read getDomFileName;
+ property ContiguousDomain : Boolean read FContiguous write setContiguous;
+   end;
+ 
+@@ -474,4 +478,24 @@ begin
+   hasFile:=Assigned(FMapStream);
+ end;
+ 
++function TMapParser.getCommentLines(): TStringList;
++begin
++  getCommentLines:=FMapParser.FComments;
++end;
++
++function TMapParser.getVersion(): String;
++begin
++  getVersion:=FMapParser.FVersion;
++end;
++
++function TMapParser.getMapFileName(): String;
++begin
++  getMapFileName:=FMapParser.FFileName;
++end;
++
++function TMapParser.getDomFileName(): String;
++begin
++  getDomFileName:=FDomParser.FFileName;
++end;
++
+ end.

Bug#968242: phipack FTCBFS: unusual compiler variable

[Helmut Grohne]

Source: phipack
Version: 0.0.20160614-3
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

phipack fails to cross build from source, because it uses the variable
CXX for storing a C compiler. During cross compilation dh_auto_build
overrides it with a C++ compiler and the build fails. Please consider
using standard variables. I'm attaching a patch for your convenience.

Helmut
--- phipack-0.0.20160614.orig/src/Makefile
+++ phipack-0.0.20160614/src/Makefile
@@ -1,7 +1,7 @@
 # compiler 
-#CXX= /opt/ibmcmp/vac/6.0/bin/xlc
-CXX= gcc
-CXXFLAGS  += -O3  -Wall
+#CC= /opt/ibmcmp/vac/6.0/bin/xlc
+CC= gcc
+CFLAGS  += -O3  -Wall
 
 # target macros
 PhiOBJ	= normal.o stats.o maxChi.o main.o queue.o graphCode.o fasta.o phylip.o mem.o misc.o pairScore.o seqManip.o global.o
@@ -12,18 +12,18 @@
 
 # implicit construction rule
 %.o : %.c
-	$(CXX) -c  $(CXXFLAGS) $< -o $@
+	$(CC) -c  $(CFLAGS) $< -o $@
 
 
 Phi: $(PhiOBJ) 
-	$(CXX) $(CXXFLAGS)  -o Phi $(PhiOBJ)   -lm $(LDFLAGS)
+	$(CC) $(CFLAGS)  -o Phi $(PhiOBJ)   -lm $(LDFLAGS)
 	cp Phi ../
 	cd ppma_2_bmp && ${MAKE}
 	cp ppma_2_bmp/ppma_2_bmp ../
 
 
 Profile: $(ProfOBJ)
-	$(CXX) $(CXXFLAGS) -o Profile $(ProfOBJ) -lm $(MYLIB) $(LDFLAGS)
+	$(CC) $(CFLAGS) -o Profile $(ProfOBJ) -lm $(MYLIB) $(LDFLAGS)
 	cp Profile ../
 clean : FORCE
 	rm -f *.o

Bug#968241: gkrellm-mailwatch FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: gkrellm-mailwatch
Version: 2.4.3-1.1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

gkrellm-mailwatch fails to cross build from source, because it does not
pass cross tools to make. The compiler is automatically passed by
dh_auto_build, but we need to substitute GTK_CONFIG manually. Please
consider applying the attached patch.

Helmut
diff -u gkrellm-mailwatch-2.4.3/debian/changelog 
gkrellm-mailwatch-2.4.3/debian/changelog
--- gkrellm-mailwatch-2.4.3/debian/changelog
+++ gkrellm-mailwatch-2.4.3/debian/changelog
@@ -1,3 +1,10 @@
+gkrellm-mailwatch (2.4.3-1.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 11 Aug 2020 16:03:02 +0200
+
 gkrellm-mailwatch (2.4.3-1.1) unstable; urgency=medium
 
   * Non-maintainer upload
diff -u gkrellm-mailwatch-2.4.3/debian/rules 
gkrellm-mailwatch-2.4.3/debian/rules
--- gkrellm-mailwatch-2.4.3/debian/rules
+++ gkrellm-mailwatch-2.4.3/debian/rules
@@ -8,6 +8,7 @@
 # This is the debhelper compatability version to use.
 #export DH_COMPAT=3
 
+include /usr/share/dpkg/buildtools.mk
 
 ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
CFLAGS += -g
@@ -29,7 +30,8 @@
dh_testdir
 
# Add here commands to compile the package.
-   $(MAKE) enable_nls=1 \
+   dh_auto_build -- enable_nls=1 \
+ GTK_CONFIG="$(PKG_CONFIG) gtk+-2.0"
  LOCALEDIR=$(CURDIR)/debian/gkrellm-mailwatch/usr/share/locale
touch build-stamp
 

Bug#968243: vstream-client FTCBFS: builds for the build architecture

[Helmut Grohne]

Source: vstream-client
Version: 1.2-6.1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

vstream-client fails to cross build from source, because it does not
pass cross tools to make. The easiest way of doing so is using
dh_auto_build. However, in this case, the makefile build system must be
forced, because debhelper otherwise assumes that configure detects cross
tools. Please consider applying the attached patch.

Helmut
diff --minimal -Nru vstream-client-1.2/debian/changelog 
vstream-client-1.2/debian/changelog
--- vstream-client-1.2/debian/changelog 2011-11-18 20:47:16.0 +0100
+++ vstream-client-1.2/debian/changelog 2020-08-11 16:19:28.0 +0200
@@ -1,3 +1,10 @@
+vstream-client (1.2-6.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 11 Aug 2020 16:19:28 +0200
+
 vstream-client (1.2-6.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff --minimal -Nru vstream-client-1.2/debian/rules 
vstream-client-1.2/debian/rules
--- vstream-client-1.2/debian/rules 2011-11-18 20:47:16.0 +0100
+++ vstream-client-1.2/debian/rules 2020-08-11 16:19:17.0 +0200
@@ -58,10 +58,7 @@
 
 build-stamp:  config.status 
dh_testdir
-
-   # Add here commands to compile the package.
-   $(MAKE)
-
+   dh_auto_build --buildsystem=makefile
touch $@
 
 clean: 

Bug#966100: notmuch-mutt: symlinking now fails for indexed mailboxes with a space in the name

[David Bremner]

Kevin McCarthy  writes:

> Package: notmuch-mutt
> Version: 0.30-1
> Severity: important
> Tags: upstream
>
> Dear Maintainer,
>
> After recently updating from stable to testing, notmuch-mutt search
> and thread commands stopped including results from my "Sent Items"
> maildir folder.  There are broken links in the results folder, and
> symlink error messages in the terminal window after exiting mutt.
>
> I tracked this down to upstream commit
> 
> but unfortunately my shell-fu is not good enough to understand exactly
> why the new version isn't working.
>
> If I manually swap revert the diff then my Sent Items results start
> working again.  So somehow the backslash-escaping works for xargs but
> not for the shell while/read loop.
>

If you can, please test the upstream patch

   
https://nmbug.notmuchmail.org/nmweb/show/20200727193833.4654-1-tomi.ollila%40iki.fi

You'll need to build notmuch from source after applying the patch. "make
debian-snapshot" will produce installable packages.

Bug#968240: new upstream (2.6.5)

[Daniel Baumann]

Package: nextcloud-desktop
Severity: wishlist

Hi,

it would be nice if you could upgrade to version 2.6.5.

Regards,
Daniel

Bug#968237: ITP: auctex-12 -- AUCTeX version 12, LaTeX environment for Emacs

[candeb]

Thanks.  However, I am not a Debian developper / maintainer, and looking for a
sponsor with a good chance of getting into prestige fights with another 
developper
sounds like an unlikely path.

Would an NMU be appropriate for the current situation ?  I would still need a
sponsor I suppose, but the process seems less aggressive.  If so, how should I
go about getting a sponsor ?



- Mail original -
> De: "David Bremner" 
> À: "Itaï BEN YAACOV" , 968...@bugs.debian.org
> Envoyé: Mardi 11 Août 2020 15:12:26
> Objet: Re: Bug#968237: ITP: auctex-12 -- AUCTeX version 12, LaTeX environment 
> for Emacs
> 
> Itaï BEN YAACOV  writes:
> 
> > Package: wnpp
> > Severity: wishlist
> > Owner: Itaï BEN YAACOV 
> > X-Debbugs-Cc: debian-de...@lists.debian.org
> >
> > * Package name: auctex-12
> >   Version : 12.2
> >   Upstream Author : GNU Project
> > * URL : https://www.gnu.org/software/auctex/
> > * License : GPL v3
> >   Description : AUCTeX version 12, LaTeX environment for Emacs
> >
> > Hello,
> >
> > This is not truly an ITP but a request for guidance.
> > auctex v11.91 already exists in Debian, and has not been updated
> > since
> > 2018 despite bug reports requesting that.  Specifically, the
> > preview-latex
> > feature no longer works due to changes in ghostscript, which is
> > solved in
> > upstream.
> >
> > The relevant bug #896844 was filed in Apr 2018, the maintainer said
> > "I'll
> > work on it" and nothing ever happened since, depite numerous
> > follow-ups to
> > the bug.  I tried to contact him directly in early 2020, getting no
> > useful
> > reply, except that he considers that he is still maintaining the
> > package.
> >
> > I am not a Debian developper, but am able to package (in fact I
> > have packaged
> > auctex v12 for personal use).
> 
> In principle you can apply the procedure described in
> 
>https://wiki.debian.org/PackageSalvaging
>
> https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
> 
> Note that the maintainer can fairly easily stop the process.
> 
> 

Bug#967906: systemd 246 resolvconf path unit

[Derek Buitenhuis]

Hi all,

This bug just hit several of my machins and VMs, and nealy destroyed
several of them because I didn't catch the sheer amount of logspam
caused by this in time.

I would strongly advise a bulletin or something is put out, or the change
reverted until a fix is decided upon upstream or in Debian, as this is quite
a serious (disk filling!) bug that people are still hitting a week later,
while we wait for a fix.

- Derek

Bug#966483: iptables-netflow: sourcing of external scripts in dkms file?

[Axel Beckert]

Dear Gianfranco,

Gianfranco Costamagna wrote:
> > > specially because in Debian we don't even use version.sh script to
> > > fill the dkms.conf file.
> > 
> > I don't understand what you refer to with "in Debian". Do you mean the
> > fact that I didn't ship the package's upstream's version.sh? Do you
> > think I should?
> 
> I think we shouldn't, because it is used/useful only at build time...

Thanks for your comment on this!

> > > Can you please remove the two lines?
> > 
> > At least not in the way you propsed. Hence removing the tag "patch".
> > 
> > > this is what we do to test dkms packages:
> > [...]
> > > dkms_pkg=$(bash -c ". $dkms_conf; echo \$PACKAGE_NAME" 2>/dev/null)
> > > dkms_ver=$(bash -c ". $dkms_conf; echo \$PACKAGE_VERSION" 2>/dev/null)
> > 
> > You could do ". $dkms_conf > /dev/null"
> 
> interesting, this works indeed:
[...]
> (and uploaded in sid)

Yay! :-)

> Honestly, I still think my patch is something sane to do (of course, as 
> Debian specific patch), because of this done in rules file:
> override_dh_dkms:
> sed -e 
> 's#`\./version.sh`#$(DEB_VERSION_UPSTREAM)#;s#^PRE_BUILD="\(.*\)"#PRE_BUILD="\1
>  $(DKMS_CONFIGURE_OPTIONS)"#' dkms.conf > debian/dkms
> dh_dkms
> 
> so, in any case, that version.sh is *never* ran in Debian packaging,
> so the whole pushd/popd are useless in this context.

Yeah, and the version.sh call itself can be removed, too. Will do.

Thanks for bringing this up despite the initially differing opinions.
:-)

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

Bug#886798: Fwd: Hey

[Gabriele]

Hotshowshere! - https://wlsg-fkib.myshopify.com/Gabriele

Bug#968126: [Pkg-pascal-devel] FPC 3.2.0 upload to SID

[peter green]

On 11/08/2020 13:06, Graham Inggs wrote:


I've also looked at mricron [2][3], and changing '(**)' to '*)' in
both places fixes the compilation, but I have no idea what the '(**)'
means.  Can anyone tell me?


(* and *) are comment delimeters

Borland style pascal traditionally handled comments in a fairly dumb manner
that did not support nesting comments with the same delimeter but *did*
support nesting comments with different delimeters. This is why for
commenting out large blocks of code people sometimes use (* and *) rather
than the more common { and }.

So (**) would close an (* comment if it was open, but do nothing if no
comment was open (or a different type of comment was open). This would
allow one to comment or uncomment a code block by only editing the code
in a single place.

Freepascal also supports fully-nested comments. When running with fully
nested comments enabled (**) does nothing regardless of current comment
state. So the comment remains open till the end of the file and you get
an "unexpected end of file" error.

In "delphi" mode freepascal uses the borland style comment handling,
but in "objfpc" mode freepascal uses the fully nested comment handling.

Modes can be specified both on the command line with the -M parameter
and within a unit with the {$mode } compiler directive.

Strangely it seems the mricron package builds the main "mricron" binary
with -MDelphi on the command line but builds the "npm" binary with
-MObjFpc on the command line.

Some units in the mricron source also set the mode explicitly to either
objfpc or delphi mode.

That still leaves the question though of why did the build break when
going from 3.0 to 3.2, everything I have said above applies equally to
both versions. My guess would be some change on how mode selections
was handled in programs where some but not all units specify the mode
in the source code.

Anyway I see three possible fixes.

1. Change the npm.lpi file to set the default syntax mode to delphi
2. Add a {$mode delphi} to the source files
3. Edit the code to change (**) to *) and hence make it valid in both modes.

Bug#968234: sendmail starttls moans about unsafe key "Permission denied"

[Michael Grant]

# ls -ald / /etc /etc/mail /etc/mail/private /etc/mail/private/mailhost.key.pem
drwxr-xr-x  29 root  root   4096 Aug 11 09:10 /
drwxr-xr-x 124 root  root  12288 Aug 11 12:50 /etc
drwxr-sr-x  10 smmta smmsp  4096 Aug 11 12:52 /etc/mail
drwx--   2 root  smmsp  4096 Aug 11 12:44 /etc/mail/private
-r   1 root  smmsp  1679 Jul  7 11:10 /etc/mail/private/mailhost.key.pem

I think the reason it’s not working is sendmail changes it’s effective uid to 
smmta or smmsp (depending on whether its an mta or msp).  

/etc/mail/private probably should be owned by smmta.  And/or group readable and 
searchable (g+rx) by group smmsp.

I ran across a similar permissions problem when using certs from 
letsencrypt/certbot.  I got around it by 

1. Adding smmta,smmsp to the ssl-cert group in /etc/group:
ssl-cert:x:114:smmta,smmsp
2. Creating a post-hook script for certbot to run after it renews a cert:
chgrp -R ssl-cert /etc/letsencrypt/archive
find /etc/letsencrypt/archive -name privkey\* -exec chmod o-rw {} \;
# the find is because cerbot seems to create world readable private keys which 
sendmail complains about

I started to think that maybe adding something to /usr/share/sendmail/update_mk 
which creates /etc/mail/Makefile to do this chown/chmod of /etc/mail/private 
and the keys/certs in there.  But I don’t have /etc/mail/private on my Debian 
install, and don’t see it in any of the packages, did I miss something?

So unless I’ve misunderstood and /etc/mail/private is not part of sendmail, 
maybe all you need to do is:

chown -R smmta /etc/mail/private
chmod g+rx /etc/mail/private
chmod g+r /etc/mail/*

This is how I would fix it on my own system, if someone has a better, more 
secure solution, I’d love to know it.

Michael Grant

Bug#966653: Re:See if the same error comes with gitlab 13.2.3 which I just uploaded

[Pirate Praveen]

Control: clone -1 -2
Control: retitle -2 "ruby-sidekiq 6 makes gitlab uninstallable"
Control: reassign -2 gitlab


On Tue, Aug 11, 2020 at 16:08, Pirate Praveen 
 wrote:



On Tue, Aug 11, 2020 at 13:35, dragos.ja...@dynamicpuzzle.ro wrote:
dpkg -i ruby-sidekiq_5.2.7+dfsg-1_all.deb dpkg: warning: downgrading 
ruby-sidekiq from 6.0.4+dfsg-2 to 5.2.7+dfsg-1 (Reading database 
... 411139 files and directories currently installed.) Preparing to 
unpack ruby-sidekiq_5.2.7+dfsg-1_all.deb ... Unpacking ruby-sidekiq 
(5.2.7+dfsg-1) over (6.0.4+dfsg-2) ... dpkg: dependency problems 
prevent configuration of ruby-sidekiq: ruby-railties 
(2:6.0.3.2+dfsg-8) breaks ruby-sidekiq (<< 6.0~) and is installed. 
Version of ruby-sidekiq to be configured is 5.2.7+dfsg-1. 
ruby-activerecord (2:6.0.3.2+dfsg-8) breaks ruby-sidekiq (<< 6.0~) 
and is installed. Version of ruby-sidekiq to be configured is 
5.2.7+dfsg-1. ruby-actionmailer (2:6.0.3.2+dfsg-8) breaks 
ruby-sidekiq (<< 6.0~) and is installed. Version of ruby-sidekiq to 
be configured is 5.2.7+dfsg-1. dpkg: error processing package 
ruby-sidekiq (--install): dependency problems - leaving unconfigured


Ah! Its harder than I thought. You will have to downgrade ruby-rails 
and dependencies to 2:6.0.3.1+dfsg-1 or wait till I fix it properly. 
I'm working on it.


Cloning it to separate bugs,
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/39212

Bug#958253: Use system libjsonparser-dev

[Christoph Berg]

Control: tags -1 upstream

Re: Yangfl
> Source: pgpool2
> Severity: wishlist
> 
> As libjsonparser-dev is now available, please consider linking against
> system library instead of bundled json.c.

Hi,

I don't think it's that simple:

src/utils/json.c:

/* pgpool extension:/

/*
 * pgpool extension:
 * search node with key from json object
 */
json_value *
json_get_value_for_key(json_value * source, const char *key)

... and a few more extra functions.

Christoph

Bug#966983: Help with new sphinx version needed (Was: Bug#966983: Most likely fixed in sphinx (2.4.3-5))

[Dmitry Shachnev]

Control: reassign -1 python3-sphinx 3.2.0-1
Control: affects -1 + src:python-skbio

Hi Andreas!

On Tue, Aug 11, 2020 at 02:26:40PM +0200, Andreas Tille wrote:
> I need some help with a sphinx error for python-skbio:
>
> > > Extension error:
> > > Handler  for event
> > > 'autodoc-process-docstring' threw an exception (exception: module,
> > > class, method, function, traceback, frame, or code object was expected,
> > > got method_descriptor)
>
> Any idea how to fix this?

This is https://github.com/sphinx-doc/sphinx/issues/8074.

Upstream promises to make a new release within a week. If you don't mind,
I will wait for that and then upload the new release to Debian.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#968238: RFS: radsecproxy/1.8.2-1 -- RADIUS protocol proxy supporting RadSec

[Sven Hartge]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: radsecproxy
   Version : 1.8.2-1
   Upstream Author : Fabian Mauchle 
 * URL : https://radsecproxy.github.io/
 * License : BSD-3-clause
 * Vcs : https://salsa.debian.org/debian/radsecproxy
   Section : net

It builds those binary packages:

  radsecproxy - RADIUS protocol proxy supporting RadSec

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/r/radsecproxy/radsecproxy_1.8.2-1.dsc

Changes since the last upload:

 radsecproxy (1.8.2-1) unstable; urgency=medium
 .
   * New upstream version 1.8.2
   * Upgrade debhelper compat level to 13.
   * Remove patches applied upstream
   * Move man-pages for radsecproxy[-hash] into section 8 to be compliant
 with the FHS.
   * Add lintian override for testsuite-autopkgtest-missing.

Regards,
--
  Sven Hartge

Bug#968237: ITP: auctex-12 -- AUCTeX version 12, LaTeX environment for Emacs

[David Bremner]

Itaï BEN YAACOV  writes:

> Package: wnpp
> Severity: wishlist
> Owner: Itaï BEN YAACOV 
> X-Debbugs-Cc: debian-de...@lists.debian.org
>
> * Package name: auctex-12
>   Version : 12.2
>   Upstream Author : GNU Project
> * URL : https://www.gnu.org/software/auctex/
> * License : GPL v3
>   Description : AUCTeX version 12, LaTeX environment for Emacs
>
> Hello,
>
> This is not truly an ITP but a request for guidance.
> auctex v11.91 already exists in Debian, and has not been updated since
> 2018 despite bug reports requesting that.  Specifically, the preview-latex
> feature no longer works due to changes in ghostscript, which is solved in
> upstream.
>
> The relevant bug #896844 was filed in Apr 2018, the maintainer said "I'll
> work on it" and nothing ever happened since, depite numerous follow-ups to
> the bug.  I tried to contact him directly in early 2020, getting no useful
> reply, except that he considers that he is still maintaining the package.
>
> I am not a Debian developper, but am able to package (in fact I have packaged
> auctex v12 for personal use).

In principle you can apply the procedure described in

   https://wiki.debian.org/PackageSalvaging
   
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging

Note that the maintainer can fairly easily stop the process.

Bug#968220: apt: 'apt source' fails: Data left in buffer

[Piotr Engelking]

Julian Andres Klode :

> I have managed to reproduce the issue occassionally after putting my squid
> in front of it.
>
> This should be fixed in 
> https://salsa.debian.org/apt-team/apt/-/merge_requests/130
> but I'll leave the bug open for you to verify.

Thanks, I confirm that the problem is no longer present with the
pu/http-debug branch of https://salsa.debian.org/jak/apt.git repository.

Bug#968235: texlive-base: missing file /usr/share/doc/texlive-base/README.tlmgr-on-Debian.md

[Norbert Preining]

> but the file /usr/share/doc/texlive-base/README.tlmgr-on-Debian.md
> is missing.

Indeed indeed, fix in git, will be in the next upload.

Thanks for the report!

Norbert

(just another Mathematics Olympia participant ;-)

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

Bug#967546: udev: missing /dev/stdin etc.

[Ansgar]

On Tue, 2020-08-11 at 13:42 +0200, Cristian Ionescu-Idbohrn wrote:
> Yes.  What else can match the enjoyment of breaking other peoples' 
> systems?

I recommend taking unhelpful comments like this to the so called
debian-init-diversity mailing list where Debian's code of conduct
doesn't apply. You can also enjoy calling people "sheeple" over there
if you are looking for things to enjoy.

Otherwise, I think your comment just decreases the chance such bugs
will gets fixed. But maybe that is your intention? :-)

Ansgar

Bug#968237: ITP: auctex-12 -- AUCTeX version 12, LaTeX environment for Emacs

[Itaï BEN YAACOV]

Package: wnpp
Severity: wishlist
Owner: Itaï BEN YAACOV 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: auctex-12
  Version : 12.2
  Upstream Author : GNU Project
* URL : https://www.gnu.org/software/auctex/
* License : GPL v3
  Description : AUCTeX version 12, LaTeX environment for Emacs

Hello,

This is not truly an ITP but a request for guidance.
auctex v11.91 already exists in Debian, and has not been updated since
2018 despite bug reports requesting that.  Specifically, the preview-latex
feature no longer works due to changes in ghostscript, which is solved in
upstream.

The relevant bug #896844 was filed in Apr 2018, the maintainer said "I'll
work on it" and nothing ever happened since, depite numerous follow-ups to
the bug.  I tried to contact him directly in early 2020, getting no useful
reply, except that he considers that he is still maintaining the package.

I am not a Debian developper, but am able to package (in fact I have packaged
auctex v12 for personal use).

What should / can be done in this case ?

Cheers,
Itaï

Bug#968236: davmail: Cannot restrict access to private keys for SSL

[Christoph Kling]

Package: davmail
Version: 5.5.1.3299-2
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

Davmail seems to run with systemd's DynamicUser configuration. That means 
that the user the daemon runs with is not known before runtime. Therefore
I cannot give specific permissions to the private keys for SSL. See the
excerpt from the configuration file /etc/davmail.properties below. I
use davmail.ssl.keystoreFile to set the file with the certificate and
the private key. I have to give o+r permissions to make this work,
because I cannot change the ownership to the user davmail uses.

I also suspect that the following error has to do with the same problem:

Aug 11 14:21:52 delta davmail[167802]: 2020-08-11 14:21:52,294 ERROR [main] 
davmail  - Unable to set log file path

The log file directive in /etc/davmail.properties is also printed below.
I use davmail.logFilePath to set the log path. But I cannot give the
daemon the right permissions to the /var/log path, because the user is
not known before runtime due to the DynamicUser configuration.

Is there a solution or should DynamicUser be turned off as it was before?

Best,
Christoph


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

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

Versions of packages davmail depends on:
ii  adduser   3.118
ii  default-jre-headless [java9-runtime-headless] 2:1.11-72
ii  init-system-helpers   1.58
ii  jarwrapper0.75
ii  libcommons-codec-java 1.14-1
ii  libcommons-httpclient-java3.1-15
ii  libcommons-logging-java   1.2-2
ii  libhtmlcleaner-java   2.24-1
ii  libhttpclient-java4.5.11-1
ii  libjackrabbit-java2.18.0+r2.14.6-1
ii  libjcifs-java 1.3.19-2
ii  libjettison-java  1.4.0-1
ii  liblog4j1.2-java  1.2.17-9
ii  libmail-java  1.6.5-1
ii  libservlet-api-java   4.0.1-2
ii  libslf4j-java 1.7.25-3
ii  libstax2-api-java 4.1-1
ii  libwoodstox-java  1:6.2.0-1
ii  logrotate 3.16.0-3
ii  lsb-base  11.1.0
ii  openjdk-11-jre-headless [java9-runtime-headless]  11.0.8+10-1

davmail recommends no packages.

Versions of packages davmail suggests:
ii  libopenjfx-java 11.0.7+0-2
pn  libswt-cairo-gtk-4-jni  
pn  libswt-gtk2-4-jni   

-- Configuration Files:
/etc/davmail.properties changed:
davmail.ssl.keystoreType=PKCS12
davmail.ssl.keystoreFile=/etc/ssl/ServerCA/apache.cert.subaltnames.pkcs12
davmail.logFilePath=/var/log/davmail.log

-- no debconf information

Bug#968200: missing files for bblxml features

[Norbert Preining]

Hi John,

(please if possible keep Cc)

Norbert from the TeX Live and the Debian/TeX Live team here.

It was reported to us that the release tar balls (on CTAN and on sf.net)
seem to miss the file
bblxml.p[lm]
while this file is present in the github tar balls.

This leads to errors like

> $ biber --help | grep output-format
> --output-format=dot|bibtex|biblatexml|bbl|bblxml
> $ biber --output-format=bblxml main
> INFO - This is Biber 2.14 (beta)
> INFO - Logfile is 'main.blg'
> ERROR - Error loading data source package 'Biber::Output::bblxml': Can't 
> locate Biber/Output/bblxml.pm in @INC (you may need to install the 
> Biber::Output::bblxml module) (@INC contains: /etc/perl 
> /usr/local/lib/x86_64-linux-gnu/perl/5.30.3 /usr/local/share/perl/5.30.3 
> /usr/lib/x86_64-linux-gnu/perl5/5.30 /usr/share/perl5 
> /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.30 
> /usr/share/perl/5.30 /usr/local/lib/site_perl) at (eval 393) line 1.

(This is from Debian)

Is this a simple hiccup and the file should be included, or is there
something we are missing?

Thanks a lot and all the best

Norbert

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

Bug#968231: global: does not index definitions with pygments anymore

[Punit Agrawal]

Hi Gregory,

Thank you for the bug report.

I can't seem to reproduce the failure you are seeing. See excerpt below -

% echo 'int main(){return 0;}' > main.c
export GTAGSLABEL=pygments
gtags
gtags -d GTAGS | grep -v '^ '
main1 @n 1 int @n(){return 0;}

What is the output of gtags -v? For reference, I get -

% gtags -v
[Tue Aug 11 21:36:39 JST 2020] Gtags started.
 Using configuration file '/etc/gtags/gtags.conf'.
 Using configuration label 'pygments'.
 Using plug-in parser.
[Tue Aug 11 21:36:39 JST 2020] Creating 'GTAGS' and 'GRTAGS'.
 [1] extracting tags of main.c
[Tue Aug 11 21:36:39 JST 2020] Done.


On Tue, Aug 11, 2020 at 9:03 PM Gregory Heytings  wrote:
>
>
> Package: global
> Version: 6.6.4-4
> Severity: important
> X-Debbugs-Cc: g...@sdf.org
>
> Dear Maintainer,
>
> Version 6.6.4-4 of the package does not index definitions with 
> GTAGSLABEL=pygments.  Version 6.6.4-3 did.  Steps to reproduce the bug:
>
> echo 'int main(){return 0;}' > main.c
> export GTAGSLABEL=pygments
> gtags
> gtags -d GTAGS | grep -v '^ '
>
> The last command displays "main" with 6.6.4-3, and nothing with 6.6.4-4.
>
> -- System Information:
> Debian Release: bullseye/sid
>APT prefers stable-updates
>APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.7.0-2-amd64 (SMP w/8 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 global depends on:
> ii  emacsen-common  3.0.4
> ii  libc6   2.31-2
> ii  libltdl72.4.6-14
> ii  libncurses6 6.2-1
> ii  libsqlite3-03.32.3-1
> ii  libtinfo6   6.2-1
>
> Versions of packages global recommends:
> ii  python3  3.8.2-3
>
> Versions of packages global suggests:
> pn  doxygen 
> pn  exuberant-ctags 
> ii  firefox-esr [www-browser]   68.11.0esr-1
> pn  id-utils
> ii  python3-pygments2.3.1+dfsg-4
> ii  w3m [www-browser]   0.5.3-38
>
> -- no debconf information

Bug#968235: texlive-base: missing file /usr/share/doc/texlive-base/README.tlmgr-on-Debian.md

[Vincent Lefevre]

Package: texlive-base
Version: 2020.20200804-2
Severity: normal

Running "tlmgr conf" gives:

(running on Debian, switching to user mode!)
(see /usr/share/doc/texlive-base/README.tlmgr-on-Debian.md)
[...]

but the file /usr/share/doc/texlive-base/README.tlmgr-on-Debian.md
is missing.

-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource. 

In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.

   *** The Debian TeX Team is *not* a LaTeX Help Desk ***

If you report an error when running one of the TeX-related binaries 
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.

Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.

Don't forget to also include minimal examples of other files that are 
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!

If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at

http://www.minimalbeispiel.de/mini-en.html (english)

or 

http://www.minimalbeispiel.de/mini.html (german)

##
minimal input file


##
other files

##
 List of ls-R files

-rw-r--r-- 1 root root 3440 2020-08-11 14:28:03 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 2020-06-08 10:31:14 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 2020-08-09 14:19:03 
/usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 2020-08-09 14:19:03 
/usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 2020-06-08 18:51:55 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 2020-08-09 14:19:03 
/usr/share/texmf/web2c/fmtutil.cnf -> /var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 2020-08-09 14:19:03 /usr/share/texmf/web2c/updmap.cfg 
-> /var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 5116 2020-08-11 01:52:07 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 2014-10-21 02:46:09 mktex.cnf
-rw-r--r-- 1 root root 475 2020-06-08 18:51:55 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

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

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

Versions of packages texlive-base depends on:
ii  debconf [debconf-2.0]  1.5.74
ii  libpaper-utils 1.1.28+b1
ii  sensible-utils 0.0.12+nmu1
ii  tex-common 6.15
ii  texlive-binaries   2020.20200327.54578-4+b1
ii  ucf3.0043
ii  xdg-utils  1.1.3-2

Versions of packages texlive-base recommends:
ii  lmodern  2.004.5-6

Versions of packages texlive-base suggests:
ii  atril [postscript-viewer]1.24.0-1
ii  ghostscript [postscript-viewer]  9.52~dfsg-1
ii  gv [postscript-viewer]   1:3.7.4-2+b1
pn  perl-tk  
ii  xpdf [pdf-viewer]3.04-13+local2
pn  xzdec

Versions of packages tex-common depends on:
ii  dpkg  1.20.5
ii  ucf   3.0043

Versions of packages tex-common suggests:
ii  debhelper  13.2

Versions of packages texlive-base is related to:
ii  tex-common6.15
ii  texlive-binaries  2020.20200327.54578-4+b1

-- debconf information:
  tex-common/check_texmf_wrong:
  texlive-base/texconfig_ignorant:
* texlive-base/binary_chooser: pdftex, dvips, dvipdfmx, xdvi
  tex-common/check_texmf_missing:

-- 
Vincent Lefèvre  - Web: 

Bug#966983: Help with new sphinx version needed (Was: Bug#966983: Most likely fixed in sphinx (2.4.3-5))

[Andreas Tille]

Hi,

I need some help with a sphinx error for python-skbio:

On Tue, Aug 11, 2020 at 10:26:10AM +0200, Sebastiaan Couwenberg wrote:
> On 8/11/20 9:41 AM, Andreas Tille wrote:
> > On Tue, Aug 11, 2020 at 07:17:30AM +0200, Sebastiaan Couwenberg wrote:
> >> A smiliar issue was reported for mapproxy in #966979, which was not an
> >> issue in mapproxy but in sphinx, and fixed in sphinx (2.4.3-5).
> >>
> >> I have not tested the build of this package, but the dh_sphinxdoc issue
> >> is mostl likely fixed with sphinx (2.4.3-5) as well.
> > 
> > Thanks for the hint but I get:
> > 
> > reading sources... [  0%] generated/skbio.alignment.AlignmentStructure
> > /build/python-skbio-0.5.6/.pybuild/cpython3_3.8_skbio/build/skbio/stats/ordination/_principal_coordinate_analysis.py:143:
> >  RuntimeWarning: The result contains negative eigenvalues. Please compare 
> > their magnitude with the magnitude of some of the largest positive 
> > eigenvalues. If the negative ones are smaller, it's probably safe to ignore 
> > them, but if they are large in magnitude, the results won't be useful. See 
> > the Notes section for more details. The smallest eigenvalue is 
> > -0.011492611219229537 and the largest is 16.021722090908206.
> >   warn(
> > /build/python-skbio-0.5.6/.pybuild/cpython3_3.8_skbio/build/skbio/stats/ordination/_ordination_results.py:285:
> >  UserWarning: Tight layout not applied. The left and right margins cannot 
> > be made large enough to accommodate all axes decorations. 
> >   fig.tight_layout()
> > 
> > Extension error:
> > Handler  for event 
> > 'autodoc-process-docstring' threw an exception (exception: module, class, 
> > method, function, traceback, frame, or code object was expected, got 
> > method_descriptor)
> > make[1]: *** [debian/rules:20: override_dh_auto_build-indep] Error 2
> 
> That's not the dh_sphinxdoc error this issue was filed for.
> 
> This failure is most likely caused by an extension not being compatible
> with sphinx 3.2.0.
> 
> sphinx was upgraded in unstable from 2.4.3-5 to 3.2.0-1 two days ago.

Any idea how to fix this?

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#965253: drbd-utils: drbd not working after kernel upgrade >5.3.x

[Tom Weber]

I can confirm that the patch from

https://bugs.launchpad.net/ubuntu/+source/drbd-utils/+bug/1866458 

against drbd-utils 9.5.0-1 works and fixes the issue for me.

Like Denis I'm on Proxmox PVE 6 (buster based) with linux 5.4.44-2

This problem hit me too.

  Tom





Description: netlink: Add NLA_F_NESTED flag to nested attribute

The mainline kernel v5.2 commit b424e432e770
("netlink: add validation of NLA_F_NESTED flag") imposes strict validation
against nested attribute as follow.

"
Add new validation flag NL_VALIDATE_NESTED which adds three consistency
checks of NLA_F_NESTED_FLAG:

  - the flag is set on attributes with NLA_NESTED{,_ARRAY} policy
  - the flag is not set on attributes with other policies except NLA_UNSPEC
  - the flag is set on attribute passed to nla_parse_nested()
"

Sending messages with nested attribute without NLA_F_NESTED would cause failed
validation. For example,

$ drbdsetup new-resource r0
Invalid argument

This patch adds NLA_F_NESTED flag to all nested attributes.

Signed-off-by: He Zhe 

Author: He Zhe 
Origin: upstream, https://github.com/LINBIT/drbd-utils/commit/859151b228
Bug: https://github.com/LINBIT/drbd-utils/pull/4
Bug-Ubuntu: https://launchpad.net/bugs/1866458
Reviewed-By: Rafael David Tinoco 
Last-Update: 2020-03-09

--- drbd-utils-8.9.10.orig/user/shared/libgenl.h
+++ drbd-utils-8.9.10/user/shared/libgenl.h
@@ -851,7 +851,7 @@ static inline struct nlattr *nla_nest_st
 {
 	struct nlattr *start = (struct nlattr *)msg->tail;
 
-	if (nla_put(msg, attrtype, 0, NULL) < 0)
+	if (nla_put(msg, attrtype | NLA_F_NESTED, 0, NULL) < 0)
 		return NULL;
 
 	return start;