Bug#970899: libflame: add hypothesis to numpy autopkgtests dependencies

[Sandro Tosi]

Source: libflame
Severity: serious

Hello,
please add hypothesis to the autopkgtests dependencies when testing numpy;

autopkgtest [03:28:25]: test numpy-with-default: python3 -c "import numpy as 
np; np.test('full', verbose=3)"
autopkgtest [03:28:25]: test numpy-with-default: [---
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/numpy/_pytesttester.py", line 129, in 
__call__
import hypothesis
ModuleNotFoundError: No module named 'hypothesis'
autopkgtest [03:28:26]: test numpy-with-default: ---]
autopkgtest [03:28:26]: test numpy-with-default:  - - - - - - - - - - results - 
- - - - - - - - -


autopkgtest [03:55:13]: test numpy-with-libflame: python3 -c "import numpy as 
np; np.test('full', verbose=3)"
autopkgtest [03:55:13]: test numpy-with-libflame: [---
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/numpy/_pytesttester.py", line 129, in 
__call__
import hypothesis
ModuleNotFoundError: No module named 'hypothesis'
autopkgtest [03:55:13]: test numpy-with-libflame: ---]
autopkgtest [03:55:14]: test numpy-with-libflame:  - - - - - - - - - - results 
- - - - - - - - - -
numpy-with-libflame  FAIL non-zero exit status 1


it's not appropriate to add hypothesis to python3-numpy Depends since running
numpy tests is beyond the general use of the library, so at best it could be a
Suggests, which wont solve the failure of the autopkgtest.

RC severity since it's blocking the migration of numpy.

Regards,
Sandro

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

Kernel: Linux 5.6.0-1-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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#970848: [Pkg-zsh-devel] Bug#970848: Problem with path to completion scripts

[Daniel Shahaf]

Frank Terbeck wrote on Fri, 25 Sep 2020 00:02 +0200:
> Georgy Komarov wrote:
> > I encountered with a problem, when trying to use custom zsh completions.  
> 
> As debian/README.Debian states:
> 
> Load-path for functions from other packages
> ---
> 
> In respsonse to #620452, the zsh-binary from Debian's zsh package started to
> provide two entries to $fpath (the search path for loadable functions) for
> other packages to drop function files into:
> 
>   - /usr/share/zsh/vendor-completions for functions that add functionality to
> zsh's function based completion system (compsys)
> 
>   - /usr/share/zsh/vendor-functions for all other functions
> 
> If you maintain another Debian package that wants to add functions to zsh's
> function load-path, please use the those conventions when installing function
> files.

These directories are added to $fpath near the start.  Therefore, files
dropped into them will override files provided further down $fpath,
which in particular includes completion functions shipped with zsh
upstream.  In particular, if [a file dropped into] vendor-completions
and zsh upstream both provide completion for /usr/bin/foo, then the
former will be used — even though it's not necessarily the better of
the two.

Recommend to review collisions on a case-by-case basis and resolve
duplications (between zsh on the one hand, and zsh-completions or other
upstreams on the other hand) as needed.

Note that to look for collisions, it's not sufficient to look for
filename collisions, since for a given external command (say,
systemctl(8)) zsh upstream and a third-party upstream might use
different filenames and function names (e.g., "_systemd" v.
"_systemctl").

Cheers,

Daniel

Bug#970896: lintian times out while analyzing package

[Felix Lechner]

Control: severity 970896 normal

Hi Kunal,

On Thu, Sep 24, 2020 at 8:57 PM Kunal Mehta  wrote:
>
> Trying to run lintian locally against src:mediawiki 1:1.35.0~rc.3-1 never
> completed

I cannot confirm that with the version in unstable (see below) but
will also try the build artifacts from your failed job in Salsa.
Perhaps it had something to do with the fact that you were building
for bionic, a Ubuntu codename.

Meanwhile, I downgraded the severity of this bug.

Kind regards,
Felix Lechner

* * *

[/l/l/l/git]─[⎇ master]─[+]|> bin/lintian
/mirror/debian/pool/main/m/mediawiki/mediawiki_1.31.8-1.dsc
I: mediawiki source: patch-not-forwarded-upstream
debian/patches/pear-phail-fail-shebang.diff
P: mediawiki source: package-uses-old-debhelper-compat-version 12
P: mediawiki source: source-contains-browserified-javascript
resources/lib/sinonjs/sinon-1.17.3.js code
fragment:if("object"==typeof exports&&"undefined"!=typeof
module)module.exports=e();else if("fu
P: mediawiki source: source-contains-prebuilt-javascript-object
extensions/Cite/modules/ve-cite/tests/ve.dm.citeExample.js line length
is 297 characters (>256)
P: mediawiki source: source-contains-prebuilt-javascript-object
extensions/CodeEditor/modules/ace/ext-elastic_tabstops_lite.js
P: mediawiki source: source-contains-prebuilt-javascript-object
extensions/CodeEditor/modules/ace/ext-searchbox.js line length is 273
characters (>256)
P: mediawiki source: source-contains-prebuilt-javascript-object ...
use --no-tag-display-limit to see all (or pipe to a file/program)
P: mediawiki source: very-long-line-length-in-source-file
extensions/CodeEditor/modules/ace/mode-actionscript.js line length is
1381 characters (>512)
P: mediawiki source: very-long-line-length-in-source-file
extensions/CodeEditor/modules/ace/mode-apache_conf.js line length is
751 characters (>512)
P: mediawiki source: very-long-line-length-in-source-file
extensions/CodeEditor/modules/ace/mode-assembly_x86.js line length is
4030 characters (>512)
P: mediawiki source: very-long-line-length-in-source-file ... use
--no-tag-display-limit to see all (or pipe to a file/program)
N: pear/net_smtp already in Debian
O: mediawiki source: license-problem-php-license debian/copyright
N: pear/net_smtp already in Debian
O: mediawiki source: license-problem-php-license vendor/pear/net_smtp/LICENSE
N: lintian thinks a bunch of test/data/etc. files are missing source
N: because they have long lines but they're not
O: mediawiki source: source-is-missing
extensions/Cite/modules/ve-cite/tests/ve.dm.citeExample.js line length
is 297 characters (>256)
N: lintian thinks a bunch of test/data/etc. files are missing source
N: because they have long lines but they're not
O: mediawiki source: source-is-missing
extensions/CodeEditor/modules/ace/ext-elastic_tabstops_lite.js
N: lintian thinks a bunch of test/data/etc. files are missing source
N: because they have long lines but they're not
O: mediawiki source: source-is-missing
extensions/CodeEditor/modules/ace/ext-searchbox.js line length is 273
characters (>256)
N: lintian thinks a bunch of test/data/etc. files are missing source
N: because they have long lines but they're not
O: mediawiki source: source-is-missing ... use --no-tag-display-limit
to see all (or pipe to a file/program)
N: we have a composer.json file, but aren't a composer package
O: mediawiki source: composer-package-without-pkg-php-tools-builddep
N: We use upstream's keys.txt exactly for easier integrity verification
O: mediawiki source: public-upstream-key-not-minimal
upstream/signing-key.asc has 15 extra signature(s) for keyid
F6DAD285018FAC02
N: We use upstream's keys.txt exactly for easier integrity verification
O: mediawiki source: public-upstream-key-not-minimal
upstream/signing-key.asc has 7 extra signature(s) for keyid
361F943B15C08DD4
N: We use upstream's keys.txt exactly for easier integrity verification
O: mediawiki source: public-upstream-key-not-minimal
upstream/signing-key.asc has 9 extra signature(s) for keyid
C119E1A64D70938E

Bug#855662: fakeroot: when msgrcv is interrupted by a signal, faked accidentally reprocesses the previous message

[Martin Dorey]

I've no reason to think that the patch I supplied here, some years ago now, was 
anything but a good idea, but it seems that my coworker Susi Berrington has 
found the real cause of my pain.  According to:

https://github.com/systemd/systemd/issues/2039 (Change default value of 
RemoveIPC in logind.conf)

... systemd is removing fakeroot's IPC objects when the user performing the 
build, which in this case are happening under cron, programmatically ssh()s 
into the headless build machine to check on the build status.  Argh!  It's been 
more than a month since we stopped that from happening, a blissful month 
without failures.

Bug#970898: katarakt FTBFS: octal parsing of poppler version

[Helmut Grohne]

Source: katarakt
Version: 0.2-2
Severity: serious
Tags: ftbfs

katarakt fails to build from source. A build ends with:

| g++ -c -pipe -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -D_REENTRANT -Wall -Wextra -fPIC -DQT_DEPRECATED_WARNINGS 
-DPOPPLER_VERSION_MAJOR=20 -DPOPPLER_VERSION_MINOR=09 -DPOPPLER_VERSION_MICRO=0 
-DQT_NO_CAST_FROM_ASCII -DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG -DQT_WIDGETS_LIB 
-DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_XML_LIB -DQT_DBUS_LIB -DQT_CORE_LIB -I. -I. 
-I/usr/include/poppler/qt5 -I/usr/include/poppler 
-I/usr/include/x86_64-linux-gnu/qt5 
-I/usr/include/x86_64-linux-gnu/qt5/QtWidgets 
-I/usr/include/x86_64-linux-gnu/qt5/QtGui 
-I/usr/include/x86_64-linux-gnu/qt5/QtNetwork 
-I/usr/include/x86_64-linux-gnu/qt5/QtXml 
-I/usr/include/x86_64-linux-gnu/qt5/QtDBus 
-I/usr/include/x86_64-linux-gnu/qt5/QtCore -I. 
-I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -o resourcemanager.o 
src/resourcemanager.cpp
| : error: invalid digit "9" in octal constant
| src/util.h:11:59: note: in expansion of macro ‘POPPLER_VERSION_MINOR’
|11 | #define POPPLER_VERSION ((POPPLER_VERSION_MAJOR << 16) | 
(POPPLER_VERSION_MINOR << 8) | (POPPLER_VERSION_MICRO))
|   |   
^
| src/resourcemanager.cpp:121:5: note: in expansion of macro ‘POPPLER_VERSION’
|   121 | #if POPPLER_VERSION >= POPPLER_VERSION_CHECK(0, 18, 0)
|   | ^~~
| : error: invalid digit "9" in octal constant
| src/util.h:11:59: note: in expansion of macro ‘POPPLER_VERSION_MINOR’
|11 | #define POPPLER_VERSION ((POPPLER_VERSION_MAJOR << 16) | 
(POPPLER_VERSION_MINOR << 8) | (POPPLER_VERSION_MICRO))
|   |   
^
| src/resourcemanager.cpp:124:5: note: in expansion of macro ‘POPPLER_VERSION’
|   124 | #if POPPLER_VERSION >= POPPLER_VERSION_CHECK(0, 22, 0)
|   | ^~~
| : error: invalid digit "9" in octal constant
| src/util.h:11:59: note: in expansion of macro ‘POPPLER_VERSION_MINOR’
|11 | #define POPPLER_VERSION ((POPPLER_VERSION_MAJOR << 16) | 
(POPPLER_VERSION_MINOR << 8) | (POPPLER_VERSION_MICRO))
|   |   
^
| src/resourcemanager.cpp:127:5: note: in expansion of macro ‘POPPLER_VERSION’
|   127 | #if POPPLER_VERSION >= POPPLER_VERSION_CHECK(0, 24, 0)
|   | ^~~
| src/resourcemanager.cpp: In member function ‘QDomDocument* 
ResourceManager::get_toc() const’:
| src/resourcemanager.cpp:483:18: warning: ‘QDomDocument* 
Poppler::Document::toc() const’ is deprecated [-Wdeprecated-declarations]
|   483 |  return doc->toc();
|   |  ^
| In file included from src/resourcemanager.h:11,
|  from src/resourcemanager.cpp:10:
| /usr/include/poppler/qt5/poppler-qt5.h:1709:37: note: declared here
|  1709 | Q_DECL_DEPRECATED QDomDocument *toc() const;
|   | ^~~
| src/layout/layout.cpp: In member function ‘virtual void 
Layout::activate_link(int, float, float)’:
| src/layout/layout.cpp:349:12: warning: enumeration value ‘OCGState’ not 
handled in switch [-Wswitch]
|   349 | switch (l->linkType()) {
|   |^
| src/layout/layout.cpp:349:12: warning: enumeration value ‘Hide’ not handled 
in switch [-Wswitch]
| make[2]: *** [Makefile:635: resourcemanager.o] Error 1
| make[2]: *** Waiting for unfinished jobs
| make[2]: Leaving directory '/<>'
| dh_auto_build: error: make -j8 returned exit code 2
| make[1]: *** [debian/rules:13: override_dh_auto_build] Error 25
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:7: binary] Error 2
| dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
2

Also reproducible by reproducible builds in bullseye:
https://tests.reproducible-builds.org/debian/rbuild/bullseye/amd64/katarakt_0.2-2.rbuild.log.gz

Also seen by crossqa in unstable:
http://crossqa.debian.net/build/katarakt_0.2-2_armhf_20200925023420.log

Helmut

Bug#970812: closed by Daniel Echeverri (Re: Bug#970812: glances: systemd service starting unrestricted listener on 0.0.0.0:61209 by default)

[Salvatore Bonaccorso]

Hi Daniel,

> Hi!
> 
> El mié., 23 de sep. de 2020 a la(s) 12:54, compositiv GmbH (
> i...@compositiv.com) escribió:
> 
> > Package: glances
> > Version: 3.1.0-1
> > Severity: important
> >
> > Dear Maintainer,
> >
> > when changing the service file structure from SysVinit to systemd on
> > Debian 10 (Buster), a security issue was introduced:
> > The service unit file is enabled by default without explicitly defining
> > the bind address as localhost or implementing any other form of access
> > control.  Thus, the service is exposed to the whole network and any
> > compatible client can connect and gather an extensive amount of data from
> > the system.
> >
> > This behaviour was not given in previous Debian releases, where execution
> > of the listener was disabled through /etc/default/glances by default
> > (RUN="false").
> >
> > The issue is known since Fri, 11 Oct 2019 and has been fixed with upstream
> > release 3.1.3-1 on Fri, 17 Jan 2020 in testing/unstable (see
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942162), but has never
> > been backported to stable ever since, hence the renewed bug report.
> >
> > Any of the following would be an acceptable solution:
> > - disable the service by default (previous behaviour, service is not
> > required for connection to localhost anyway)
> > - configure the bind address to 127.0.0.1
> > - implement another restriction like setting a random password on
> > installation
> >
> > Kind regards,
> >   David Winterstein
> >
> > compositiv GmbH
> > Hammer Deich 30
> > 20537 Hamburg
> > Tel: +49 40 6094349 0
> > Fax: +49 40 6094349 40
> > Web: www.compositiv.com
> > Mail: i...@compositiv.com
> >
> > Geschäftsführer Matthias Krawen
> > Amtsgericht Hamburg - HRB 122540
> > USt.-IdNr: DE282432834
> >
> >
> 
> The version fixed will be  in stable when bullseye become stable

As an additional note, as we got reached out on this bug report: Such
an issue can (if possible) as well be fixed in a current stable
release (not only via DSAs when they do not warrant it, and this one
is likely such a no-dsa candidate), but as well via the regular point
releases.

Information for that is in
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#special-case-uploads-to-the-stable-and-oldstable-distributions

Hope this helps,

Regards,
Salvatore

Bug#970897: aqemu FTCBFS: builds for the build architecture

[Helmut Grohne]

Source: asp
Version: 1.8-8
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

asp fails to cross build from source, because its configure script is
too old to recognize the --host flag passed by dh_auto_configure.
Instead, one is supposed to initialize CC to a suitable cross compiler.
An easy way to do so is leverage dpkg's buildtools.mk. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru asp-1.8/debian/changelog asp-1.8/debian/changelog
--- asp-1.8/debian/changelog2011-08-15 18:36:30.0 +0200
+++ asp-1.8/debian/changelog2020-09-25 06:19:01.0 +0200
@@ -1,3 +1,10 @@
+asp (1.8-8.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dpkg's buildtools.mk supply CC. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 25 Sep 2020 06:19:01 +0200
+
 asp (1.8-8) unstable; urgency=low
 
   * debian/control:
diff --minimal -Nru asp-1.8/debian/rules asp-1.8/debian/rules
--- asp-1.8/debian/rules2011-08-15 18:29:05.0 +0200
+++ asp-1.8/debian/rules2020-09-25 06:18:59.0 +0200
@@ -1,5 +1,8 @@
 #! /usr/bin/make -f
 
+-include /usr/share/dpkg/buildtools.mk
+export CC
+
 %:
dh $@
 

Bug#970880: [Pkg-freeipa-devel] Bug#970880: freeipa-server: FreeIPA server installation fails with Certificate issuance failed (CA_REJECTED)

[Timo Aaltonen]

On 25.9.2020 0.30, Ferran Obón wrote:

Package: freeipa-server
Version: 4.8.8-2
Severity: important
X-Debbugs-Cc: ferran.o...@gmail.com

Dear Maintainer,

On a fresh install of Debian, the command ipa-server-install ends with the 
following error:
RuntimeError: Certificate issuance failed (CA_REJECTED: Server at 
"https://debian.test.lan:8443/ca/agent/ca//profileProcess; replied:  1: You did 
not provide a valid certificate for this operation).


Yes, this is probably related to jdk11, so could you test if installing 
openjdk-8-jre and linking /usr/share/pki/java-home to 
/usr/lib/jvm/java-8-openjdk-amd64 helps? AIUI dogtag is built with 
support for java8.



--
t

Bug#970896: lintian times out while analyzing package

[Kunal Mehta]

Package: lintian
Version: 2.95.0~bpo10+1
Severity: serious
Justification: fails to run properly

Trying to run lintian locally against src:mediawiki 1:1.35.0~rc.3-1 never
completed, I ^C'd the lintian command after 3+ hours.

A salsa CI run against a slightly older mediawiki package also failed
because it took more than an hour to run:
.

I don't know how to figure out if there's an infinite loop somewhere or
something specific to the size of mediawiki is causing problems, but I
really don't expect lintian to take this long.

Thanks,
-- Kunal

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

Kernel: Linux 4.19.132-1.pvops.qubes.x86_64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
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)

Versions of packages lintian depends on:
ii  binutils2.31.1-16
ii  bzip2   1.0.6-9.2~deb10u1
ii  diffstat1.62-1
ii  dpkg1.19.7
ii  dpkg-dev1.19.7
ii  file1:5.35-4+deb10u1
ii  gettext 0.19.8.1-9
ii  gpg 2.2.12-1+deb10u1
ii  intltool-debian 0.35.0+20060710.5
ii  libapt-pkg-perl 0.1.34+b1
ii  libarchive-zip-perl 1.64-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b2
ii  libclone-perl   0.41-1+b1
ii  libconfig-tiny-perl 2.23-1
ii  libcpanel-json-xs-perl  4.09-1
ii  libdata-dpath-perl  0.57-2
ii  libdata-validate-domain-perl0.10-1
ii  libdevel-size-perl  0.82-1+b1
ii  libdpkg-perl1.19.7
ii  libemail-address-xs-perl1.04-1+b1
ii  libfile-basedir-perl0.08-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1
ii  libhtml-html5-entities-perl 0.004-1
ii  libipc-run3-perl0.048-1
ii  libjson-maybexs-perl1.004000-1
ii  liblist-compare-perl0.53-1
ii  liblist-moreutils-perl  0.416-1+b4
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.003004-2
ii  libmoox-aliases-perl0.001006-1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.108-1
ii  libperlio-gzip-perl 0.19-1+b5
ii  libproc-processtable-perl   0.56-1
ii  libsereal-decoder-perl  4.005+ds-1+b1
ii  libsereal-encoder-perl  4.005+ds-1+b1
ii  libtext-glob-perl   0.10-1
ii  libtext-levenshteinxs-perl  0.03-4+b6
ii  libtext-markdown-discount-perl  0.11-3+b1
ii  libtext-xslate-perl 3.5.6-1+b1
ii  libtime-duration-perl   1.20-1
ii  libtime-moment-perl 0.44-1+b1
ii  libtimedate-perl2.3000-2+deb10u1
ii  libtry-tiny-perl0.30-1
ii  libtype-tiny-perl   1.004004-1
ii  libunicode-utf8-perl0.62-1
ii  liburi-perl 1.76-1
ii  libxml-libxml-perl  2.0134+dfsg-1
ii  libyaml-libyaml-perl0.76+repack-1
ii  lzip1.21-3
ii  lzop1.03-4+b1
ii  man-db  2.8.5-2
ii  patchutils  0.3.4-2
ii  perl [libdigest-sha-perl]   5.28.1-6+deb10u1
ii  t1utils 1.41-3
ii  unzip   6.0-23+deb10u1
ii  xz-utils5.2.4-1

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
pn  libtext-template-perl  

-- no debconf information

Bug#970895: duecredit: new upstream release available

[Drew Parsons]

Source: duecredit
Severity: normal

I'm getting problems running tests for mdanalysis with some broken
citations generated by duecredit,
see https://github.com/MDAnalysis/mdanalysis/issues/2954

Upstream suggests the latest version of duecredit might help the
problem.

Could you upload duecredit 0.8.0 ?

Bug#834540: RFA: cgmanager -- Central cgroup manager daemon

[Serge E. Hallyn]

On Sun, Sep 06, 2020 at 12:20:24AM +0200, Chris Hofstaedtler wrote:
> * Serge E. Hallyn  [200905 22:19]:
> > On Mon, May 01, 2017 at 04:47:17PM +0200, Michael Biebl wrote:
> > > On Tue, 16 Aug 2016 15:26:46 -0500 "Serge E. Hallyn" 
> > > wrote:
> > For what it's worth, we had retired cgmanager upstream, but I'm now
> > considering either picking it back up, or actually starting from scratch
> > (mainly to drop the 'libnih' dependency which is pretty problematic)
> 
> Apparently the upstream repository is now marked as "Archived".
> 
> > > There is elogind [1], which is a standalone logind implementation which
> > > doesn't require systemd-shim and cgmanager.
> > > This might be an alternative approach to provide the logind interfaces
> > > under sysvinit.
> 
> elogind seems to be in Debian now.
> 
> 
> Serge, what's the current upstream status, or would it make more
> sense to RM cgmanager now?

Indeed, RM makes most sense.

Bug#970857: petsc4py breaks slepc4py autopkgtest: No module named 'petsc4py'

[Drew Parsons]

On 2020-09-25 02:56, Paul Gevers wrote:

Control: reassign -1 src:slepc4py 3.13.0-4
Control: affects -1 src:petsc4py
Control: fixed -1 3.13.0-5

Hi Drew,

This bug was filed against *two* packages, so your message didn't 
result
in what you wanted as the bts didn't know which of the two sources 
fixed

the issue.

On 24-09-2020 16:46, Drew Parsons wrote:

Control: fixed -1 3.13.0-5

Close.


I hope my changes do the right thing.



Thanks Paul, looks like it's happy with that.  Just waiting for openmpi 
to migrate to allow the whole stack to clear.


Drew

Bug#964125: calibre: Please switch from sip4 to sip5

[Norbert Preining]

Hi Dmitry,

> And this is done now. PyQt5 in unstable now uses SIP 5.

Is this also the reason why calibre is now broken?

$ calibre
Traceback (most recent call last):
  File "/usr/bin/calibre", line 20, in 
sys.exit(calibre())
  File "/usr/lib/calibre/calibre/gui_launch.py", line 73, in calibre
main(args)
  File "/usr/lib/calibre/calibre/gui2/main.py", line 529, in main
app, opts, args = init_qt(args)
  File "/usr/lib/calibre/calibre/gui2/main.py", line 114, in init_qt
app = Application(args, override_program_name=override, 
windows_app_uid=MAIN_APP_UID)
  File "/usr/lib/calibre/calibre/gui2/__init__.py", line 885, in __init__
raise RuntimeError('Failed to load the progress_indicator C extension, with 
error: {}'.format(pi_err))
RuntimeError: Failed to load the progress_indicator C extension, with error: 
PyCapsule_GetPointer called with incorrect name
$

???

If yes, you could have added a breaks calibre <= ... - and probably some other 
packages, too.

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#970893: debdelta: Ensure correct mode of html documentation and shipped patches.

[Vagrant Cascadian]

Source: debdelta
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: umask
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Several files in debdelta and debdelta-doc use the umask of the build
environment and end up in the package with inconsistent mode as a
result.

Affected files in /usr/share/debdelta-doc/html/* in debdelta-doc and
/usr/share/debdelta/debmirror*.patch in debdelta.

The attached patch sets the modes of these files appropriately, enabling
reproducible builds for debdelta.


Thanks for maintaining debdelta!


live well,
  vagrant
From 68b5ee2b286b013584c38048c8951f5a90569487 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 25 Sep 2020 01:43:50 +
Subject: [PATCH] Ensure correct mode of html documentation and shipped
 patches.

This ensures reproducible builds regardless of the umask.
---
 debdelta/debian/rules | 5 +
 1 file changed, 5 insertions(+)

diff --git a/debdelta/debian/rules b/debdelta/debian/rules
index f103fbf..9d47190 100755
--- a/debdelta/debian/rules
+++ b/debdelta/debian/rules
@@ -68,6 +68,9 @@ binary-indep:	checkroot build
 	chown -R root:root $(D2)
 	find debian/debdelta-doc -newermt '$(BUILD_DATE)' -print0 | \
 		xargs -0r touch --no-dereference --date='$(BUILD_DATE)'
+	# Ensure correct mode for files for reproducible builds
+	chmod -c 0755 $(docdir2doc)/html/
+	chmod -c 0644 $(docdir2doc)/html/*
 	dpkg-deb --build $(D2) ..
 
 binary-arch:	checkroot build
@@ -117,6 +120,8 @@ binary-arch:	checkroot build
 	chown -R root:root $(D)
 	find debian/debdelta -newermt '$(BUILD_DATE)' -print0 | \
 		xargs -0r touch --no-dereference --date='$(BUILD_DATE)'
+	# Ensure correct mode for files for reproducible builds
+	chmod -c 0644 $(D)/usr/share/debdelta/*.patch
 	dpkg-deb --build $(D) ..
 
 define checkdir
-- 
2.28.0



signature.asc
Description: PGP signature

Bug#970892: dlocate.1: fix misuses of a two-font macro

[Bjarni Ingi Gislason]

Package: dlocate
Version: 1.07+nmu1
Severity: minor
Tags: patch

Dear Maintainer,

  Correct the misuse of a two-font macro, which function is to

1) use the first font for each odd numbered argument and the second
font for all others.

2) join the arguments without an intervening space.

  The output is unchanged, except for "(none)", which is not an
argument and thus set in roman type.



  Patch:

--- dlocate.1   2020-09-24 23:38:43.0 +
+++ dlocate.1.new   2020-09-25 00:22:16.0 +
@@ -21,7 +21,7 @@ dlocate - program to view debian package
 .B dlocate
 .RI [ OPTIONS ]
 .RI [ command ]
-.RB [ 
+[
 .IR package .\|.\|.
 |
 .IR PATTERN .\|.\|.]
@@ -34,7 +34,7 @@ is a fast alternative to dpkg for querie
 
 .SH COMMANDS
 .TP
-.BR (none)
+(none)
 List all records where either the package name or the filename matches
 .IR PATTERN .
 
@@ -46,7 +46,7 @@ For example, to search for `/usr/bin/[',
 or
 \fBdlocate \-F '/usr/bin/['\fP
 .TP
-.BR \-S
+.B \-S
 List all records where only the filename matches
 .IR PATTERN .
 
@@ -58,7 +58,7 @@ For example, to search for `/usr/bin/[',
 \fBdlocate  '/usr/bin/\\['\fP
 
 .TP
-.BR \-l
+.B \-l
 Regexp-enhanced emulation of `dpkg \-l'.  Shows all packages which match
 .IR package .
 
@@ -87,79 +87,79 @@ may require some knowledge of regular ex
 want.
 
 .TP
-.BR \-k
+.B \-k
 List package names of installed kernels and all related packages
 .TP
-.BR \-K
+.B \-K
 Detailed list of installed kernels and all related packages
 
 .TP
-.BR \-L
+.B \-L
 List all files in 
 .IR package .
 
 .TP
-.BR \-s
+.B \-s
 Print status of
 .IR package .
 
 .TP
-.BR \-\^\-ls
+.B \-\^\-ls
 `ls \-ldF' of all files in
 .IR package .
 
 .TP
-.BR \-\^\-lsconf
+.B \-\^\-lsconf
 `ls \-ldF' of conffiles in
 .IR package .
 
 .TP
-.BR \-\^\-conf
+.B \-\^\-conf
 List conffiles in
 .IR package .
 
 .TP
-.BR \-\^\-du
+.B \-\^\-du
 `du \-sck' of all files in
 .IR package .
 
 .TP
-.BR \-\^\-md5sum
+.B \-\^\-md5sum
 List md5sums (if any) of 
 .IR package .
 
 .TP
-.BR \-\^\-md5check
+.B \-\^\-md5check
 Check md5sums (if any) of 
 .IR package .
 
 .TP
-.BR \-\^\-man
+.B \-\^\-man
 List man pages (if any) in
 .IR package .
 
 .TP
-.BR \-\^\-lsman
+.B \-\^\-lsman
 List full path/filenames of man pages (if any) in
 .IR package .
 
 .TP
-.BR \-\^\-lsbin
+.B \-\^\-lsbin
 List full path/filenames of executable files (if any) in
 .IR package .
 
 .TP
-.BR \-\^\-lsdir
+.B \-\^\-lsdir
 List only the directories in 
 .IR package .
 
 .SH OPTIONS
 .TP
-.BR \-\^\-filename\-only
+.B \-\^\-filename\-only
 Only output file names when searching for files
 
 .TP
-.BR \-\^\-package\-only
+.B \-\^\-package\-only
 Only output package names when searching for files
 
 .TP
@@ -306,7 +306,7 @@ run \fPupdate-dlocatedb\fP at any time t
 
 .SH ENVIRONMENT VARIABLES
 .TP
-.BR COLUMNS
+.B COLUMNS
 Sets the number of columns \fBdlocate\fP should use when displaying formatted
 text. Currently only used by \-l. Values lower than 80 are increased to 80.
 

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

Kernel: Linux 5.8.7-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages dlocate depends on:
ii  dctrl-tools [grep-dctrl]  2.24-3+b1
ii  dpkg  1.20.5
ii  perl  5.30.3-4
ii  util-linux2.36-3

dlocate recommends no packages.

dlocate suggests no packages.

-- no debconf information

-- 
Bjarni I. Gislason

Bug#970881: ITP: ruby-ms-rest-azure -- library which supports Azure clients generated with autorest tool

[Abraham Raji]

Package: wnppSeverity: wishlistOwner: Abraham Raji 
X-Debbugs-CC: debian-de...@lists.debian.org* Package name    : 
ruby-ms-rest-azure
  Version : 0.12.0
  Upstream Author : Copyright 2015 Microsoft Corporation
* URL : 
https://github.com/Azure/azure-sdk-for-ruby/tree/master/runtime/ms_rest_azure 
* 
License : Expat
  Programming Lang: Ruby
  Description : library which supports Azure clients generated with 
autorest tool MsRestAzure is a library which supports the Azure clients (SDKs) 
generated with Autorest tool. It contains core logic and helper classes for 
error handling and authentication. Also it includes azure specific logic like 
long polling functionality and Azure application authentication. Usually it is 
not supposed to be used as a standalone gem but only as a dependency for 
generated client gems.
.
This package is a dependency for the latest  version of Gitlab. I am a member 
of the Debian Ruby team and with their help I'll maintain the package.
Abraham Raji
--
Mea navis aëricumbens anguillis abundant.

Bug#970266: mount: comment=x-gvfs-show not removed from options for non-reoot user

[Martin Schwenke]

On Fri, 25 Sep 2020 11:28:06 +1000, Martin Schwenke 
wrote:

> I'm sending a patch for an upstream fix...

Patch is attached.

peace & happiness,
martin
>From 97a071f7f1bf5274c027ee92fc0f6ca629ecdd65 Mon Sep 17 00:00:00 2001
From: Martin Schwenke 
Date: Fri, 25 Sep 2020 11:16:39 +1000
Subject: [PATCH] mount.cifs: ignore comment mount option

mount.cifs currently complains about the "comment" option:

  CIFS: Unknown mount option "comment=foo"

mount(8) on Linux says:

  The command mount does not pass the mount options unbindable,
  runbindable, private, rprivate, slave, rslave, shared, rshared,
  auto, noauto, comment, x-*, loop, offset and sizelimit to the
  mount. helpers.

So if mount.cifs decides to re-read /etc/fstab it should ignore the
comment option.

A lot of online posts say to use comment=x-gvfs-show as an option to
have a Linux file manager display a mountpoint for a user mountable
filesystem.  While the "comment=" part is superfluous when combined
with an x-* option, the problem is still difficult to debug.

Signed-off-by: Martin Schwenke 
---
 mount.cifs.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/mount.cifs.c b/mount.cifs.c
index 4feb397..5d43c00 100644
--- a/mount.cifs.c
+++ b/mount.cifs.c
@@ -777,6 +777,8 @@ static int parse_opt_token(const char *token)
 		return OPT_BKUPGID;
 	if (strcmp(token, "nofail") == 0)
 		return OPT_NOFAIL;
+	if (strcmp(token, "comment") == 0)
+		return OPT_IGNORE;
 	if (strncmp(token, "x-", 2) == 0)
 		return OPT_IGNORE;
 	if (strncmp(token, "snapshot", 8) == 0)
-- 
2.28.0

Bug#970891: xzgrep: please add support for zstd

[Adam Borowski]

Package: xz-utils
Version: 5.2.4-1+b1
Severity: wishlist

Hi!
On the battlefield of general-purpose mainstream compressors, there are
two entrants left: xz and zstd.  The former wins for compression ratio,
the latter is good for medium and low compression levels, making stuff
like gzip or lzo redundant.  In fact, I just noticed one of my use cases
gets sped up by ~10× by moving from gzip to zstd.

While zstd is not xz, out of all compressors shipping their own FOOgrep,
your xzgrep can handle most of the rest.  Thus, instead of adding a yet
another set of binaries, I believe it would be nice to instead make
xzgrep more universal -- and perhaps, on a later day, replace all others
with symlinks.

Attached patch does the first part: adds zstd support.


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

Kernel: Linux 5.9.0-rc6-00029-g30fa038072a9 (SMP w/64 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages xz-utils depends on:
ii  libc6 2.31-3
ii  liblzma5  5.2.4-1+b1

xz-utils recommends no packages.

xz-utils suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/bin/xzgrep (from xz-utils package)
>From 54140e8697b8414997bea9d4561fe4aa4f7a02f6 Mon Sep 17 00:00:00 2001
From: Adam Borowski 
Date: Fri, 25 Sep 2020 03:09:11 +0200
Subject: [PATCH] Teach xzgrep about zstd.

---
 src/scripts/xzgrep.1  | 3 +++
 src/scripts/xzgrep.in | 1 +
 2 files changed, 4 insertions(+)

diff --git a/src/scripts/xzgrep.1 b/src/scripts/xzgrep.1
index 4bddbe2d..bc6c8104 100644
--- a/src/scripts/xzgrep.1
+++ b/src/scripts/xzgrep.1
@@ -41,6 +41,7 @@ which may be either uncompressed or compressed with
 .BR lzma (1),
 .BR gzip (1),
 .BR bzip2 (1),
+.BR zstd (1),
 or
 .BR lzop (1).
 All options specified are passed directly to
@@ -54,6 +55,7 @@ and fed to
 When reading from standard input,
 .BR gzip (1),
 .BR bzip2 (1),
+.BR zstd (1),
 and
 .BR lzop (1)
 compressed files are not supported.
@@ -95,4 +97,5 @@ or
 .BR gzip (1),
 .BR bzip2 (1),
 .BR lzop (1),
+.BR zstd (1),
 .BR zgrep (1)
diff --git a/src/scripts/xzgrep.in b/src/scripts/xzgrep.in
index a1fd19cf..cde8128f 100644
--- a/src/scripts/xzgrep.in
+++ b/src/scripts/xzgrep.in
@@ -158,6 +158,7 @@ for i; do
 *[-.][zZ] | *_z | *[-.]gz | *.t[ag]z) uncompress="gzip -cdfq";;
 *[-.]bz2 | *[-.]tbz | *.tbz2) uncompress="bzip2 -cdfq";;
 *[-.]lzo | *[-.]tzo) uncompress="lzop -cdfq";;
+*[-.]zst | *[-.]tzst) uncompress="zstd -cdfq";;
 *) uncompress="$xz -cdfq";;
   esac
   # Fail if xz or grep (or sed) fails.
-- 
2.28.0

Bug#970266: mount: comment=x-gvfs-show not removed from options for non-reoot user

[Martin Schwenke]

On Thu, 24 Sep 2020 17:45:25 +0200, Chris Hofstaedtler
 wrote:

> It appears mount.cifs somehow re-adds a comment=... option from
> /etc/fstab when calling mount(), for "user"-style mounts.
> 
> $ strace -ttf -bexecve -s3 mount /mnt
>  execve("/sbin/mount.cifs", ["/sbin/mount.cifs", "//x/y", "/mnt", "-o", 
> "rw,noexec,nosuid,nodev,username=ch,user"], 0x7ffc40273cb0 /* 42 vars */) = 0
> 
> In a root-strace of mount.cifs, you'll see:
>  mount("//x/y$", ".", "cifs", MS_NOSUID|MS_NODEV, 
> "ip=10.100.0.52,unc=x\\y,noauto,comment=foo,uid=1000,gid=1000,user=ch,pass=yolo")
>  = -1 EINVAL (Invalid argument)
> 
> Doesn't appear to be a util-linux/mount problem to me.

Right.  It turns out that mount.cifs doesn't trust the options passed
by a user so it re-reads them and neglects to ignore the comment
option.

I'm sending a patch for an upstream fix...

Thanks for working this out!

peace & happiness,
martin

Bug#970890: fai: encoding of fai-guide.ps varies based on locale

[Vagrant Cascadian]

Source: fai
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: locale
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The encoding of fai-guide.ps changes depending on weather a UTF-8 locale
or other locale is used.

The attached patch sets LC_ALL=C.UTF-8 to ensure generated files use
UTF-8 encoding.

With this and the previous patches applied, I think fai-doc will build
reproducibly!

Thanks for maintaining fai!

live well,
  vagrant
From 2a3da19f2c266699974a585d136b82d1eac372b1 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 25 Sep 2020 00:45:37 +
Subject: [PATCH 3/3] debian/rules: Pass LC_ALL=C.UTF-8 to dh_auto_build to
 ensure UTF-8 encoding on generated files.

---
 debian/rules | 4 
 1 file changed, 4 insertions(+)

diff --git a/debian/rules b/debian/rules
index 08dc9e7f..c2044ca0 100755
--- a/debian/rules
+++ b/debian/rules
@@ -8,6 +8,10 @@ export FORCE_SOURCE_DATE=1
 %:
 	dh $@
 
+override_dh_auto_build:
+	# Force UTF-8 locale to ensure UTF-8 file encoding for generated files
+	LC_ALL=C.UTF-8 dh_auto_build
+
 override_dh_installdocs:
 	dh_installdocs -Nfai-server -Nfai-quickstart
 	sed -i 's/FAIVERSIONSTRING/$(VERSIONSTRING)/' debian/fai-client/usr/share/doc/fai-client/README
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#970889: lcl-units-2.0: missing Breaks+Replaces: lazarus-src-2.0 (<< 2.0.10+dfsg-3)

[Andreas Beckmann]

Package: lcl-units-2.0
Version: 2.0.10+dfsg-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../lcl-units-2.0_2.0.10+dfsg-3_amd64.deb ...
  Unpacking lcl-units-2.0 (2.0.10+dfsg-3) ...
  dpkg: error processing archive 
/var/cache/apt/archives/lcl-units-2.0_2.0.10+dfsg-3_amd64.deb (--unpack):
   trying to overwrite 
'/usr/lib/lazarus/2.0.10/components/codetools/fpc.errore.msg', which is also in 
package lazarus-src-2.0 2.0.10+dfsg-2
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/lcl-units-2.0_2.0.10+dfsg-3_amd64.deb
 

cheers,

Andreas


lazarus-src-2.0=2.0.10+dfsg-2_lcl-units-2.0=2.0.10+dfsg-3.log.gz
Description: application/gzip

Bug#969312: localechooser doesn’t display Occitan and Kabyle languages

[Holger Wansing]

Hi Quentin,

Quentin PAGÈS  wrote:
> 
> any update for this report? 

Adding new languages to the installer is not as trivial as what was proposed in
the mentioned merge requests!
Are there translators who are willing to work on the translation of the
installer? The installer consists of nearly 100 packages with translatable
material. 

You can get an overview of that under 
https://d-i.debian.org/l10n-stats/
As a bare minimum, sublevel1 should be complete to activate the language,
which means ~1900 strings to translate.
Not sure, how much translation can be imported from Ubuntu though...
What's the translation status there?
(BTW: are Occitan or Kabyle selectable in Ubuntu currently? I did not find
them easily there in the installer.)

The process of adding a new language to the installer is also documented
at https://d-i.debian.org/doc/i18n-guide/ch03.html


So long
Holger


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

Bug#970888: fai: fai-guide.ps embeds timestamps and tempdirs

[Vagrant Cascadian]

Source: fai
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps randomness
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The /usr/share/doc/fai-doc/fai-guide.ps.gz embeds timestamps as well as
the temporary directory used when it was generated:

  15%DVIPSCommandLine:·dvips·-R0·-o·/tmp/tmpafymsm62/fai-guide.ps   15  
%DVIPSCommandLine:·dvips·-R0·-o·/tmp/tmp82mwtb5p/fai-guide.ps
  16%+·/tmp/tmpafymsm62/fai-guide.dvi   16  
%+·/tmp/tmp82mwtb5p/fai-guide.dvi
  17%DVIPSParameters:·dpi=600   17  %DVIPSParameters:·dpi=600
  18%DVIPSSource:··TeX·output·2021.10.16:0452   18  
%DVIPSSource:··TeX·output·2020.09.14:0033

The first patch fixes the timestamp issue by passing exporting
FORCE_SOURCE_DATE=1 in debian/rules.

The second patch fixes the other issue by stripping the temporary
directory from the generated fai-guide.ps in the override_dh_installdocs
target in debian/rules.

Thanks for maintaining fai!

live well,
  vagrant

From 29220386bd13f122de795a3870341f0300615251 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 25 Sep 2020 00:03:02 +
Subject: [PATCH 1/2] debian/rules: Use consistent timestamp in fai-guide.ps
 for reproducible builds.

---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index 0bd3660a..f6c94ab9 100755
--- a/debian/rules
+++ b/debian/rules
@@ -2,6 +2,9 @@
 
 -include VERSION
 
+# Tell texlive to respect SOURCE_DATE_EPOCH for reproducible builds
+export FORCE_SOURCE_DATE=1
+
 %:
 	dh $@
 
-- 
2.28.0

From 7d8284bfce9c854935a1962d7b5994dd37a19e66 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 25 Sep 2020 00:04:39 +
Subject: [PATCH 2/2] debian/rules: Remove embedded temporary directory from
 fai-guide.ps for reproducible builds.

---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index f6c94ab9..08dc9e7f 100755
--- a/debian/rules
+++ b/debian/rules
@@ -11,6 +11,9 @@ export FORCE_SOURCE_DATE=1
 override_dh_installdocs:
 	dh_installdocs -Nfai-server -Nfai-quickstart
 	sed -i 's/FAIVERSIONSTRING/$(VERSIONSTRING)/' debian/fai-client/usr/share/doc/fai-client/README
+	# Remove embedded temporary directory for reproducible builds
+	sed -i -e 's,/tmp/tmp.*/fai-guide.ps,fai-guide.ps,g' debian/fai-doc/usr/share/doc/fai-doc/fai-guide.ps
+	sed -i -e 's,/tmp/tmp.*/fai-guide.dvi,fai-guide.dvi,g' debian/fai-doc/usr/share/doc/fai-doc/fai-guide.ps
 
 override_dh_installchangelogs:
 	dh_installchangelogs -Nfai-server -Nfai-quickstart
-- 
2.28.0



signature.asc
Description: PGP signature

Bug#944738: [Openjdk] Bug#944738: jlink: Hash of module differs to expected hash recorded in java.base

[tony mancill]

On Thu, Sep 24, 2020 at 10:52:50AM +0100, Julian Gilbey wrote:
> On Wed, Sep 23, 2020 at 08:47:52PM -0700, tony mancill wrote:
> > > Obviously, similar builds will be needed for openjdk-{11,13,14,15}.
> > 
> > Yes, I will start working on the others.
> 
> Great, and there's a bug report #944738
> (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944738) for
> openjdk-11; I haven't checked if there are bugs reported against the
> other two versions.

I'm not able to reproduce the problem with openjdk-15.  Perhaps the
non-determinism has already been addressed upstream?

openjdk-13 does have the problem, so we could do another upload, but
given that it's not an LTS release and 14 is already available and
patched, do we need to?

Neither 13 nor 15 have open bugs filed against them for the jlink hash
issue.

Cheers,
tony

Bug#970887: ITP: scanpy -- Single-Cell Analysis in Python

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: scanpy -- Single-Cell Analysis in Python
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: scanpy
  Version : 1.6.0
  Upstream Author : F. Alexander Wolf
* URL : https://github.com/theislab/scanpy
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Single-Cell Analysis in Python
 Scanpy is a scalable toolkit for analyzing single-cell gene expression
 data built jointly with anndata. It includes preprocessing,
 visualization, clustering, trajectory inference and differential
 expression testing. The Python-based implementation efficiently deals
 with datasets of more than one million cells.

Remark: This package is maintained by Steffen Moeller at
   https://salsa.debian.org/debian/scanpy

Bug#930447: nvidia-detect: [PATCH] Add option to only output package name if possible

[Andreas Beckmann]

On 6/12/19 10:35 PM, Markus Lindberg wrote:
> This is quite a big diff since it's was tricky to adapt the new option
> while not changing to much. Please let me know if this can be done
> better or should be avoided.

This can be simplified by conditionally redirecting stdout globally to
/dev/null if terse output is wanted:

#!/bin/sh

if [ "$1" ]; then
exec 3>&1
exec 1>/dev/null
fi

echo verbose

if [ "$1" ]; then
echo terse >&3
fi

> The possibility to use long options (eg.
> --help) was removed since getopts only supports short options (eg. -h).

no objection

Andreas

Bug#970873: ITP: ruby-ms-rest -- Azure Client Library for Ruby

[Abraham Raji]

Package: wnppSeverity: wishlistOwner: Abraham Raji 
X-Debbugs-CC: debian-de...@lists.debian.org* Package name    : 
ruby-ms-rest
  Version : 0.7.6
  Upstream Author : Copyright (c) 2015 Microsoft Corporation
* URL : 
https://github.com/Azure/azure-sdk-for-ruby/tree/master/runtime/ms_rest* 
License : Expat
  Programming Lang: Ruby
  Description : Azure Client Library for Ruby MsRest is a library which 
supports the clients (SDKs) generated with Autorest tool. It contains core 
logic and helper classes for error handling and authentication. Usually it is 
not supposed to be used as a standalone gem but only as a dependency for 
generated client gems. Azure Client Library for Ruby.
.
This package is a dependency for the latest  version of Gitlab. I am a member 
of the Debian Ruby team and with their help I'll maintain the package.
Abraham Raji
--
Mea navis aëricumbens anguillis abundant.

Bug#943794: nvidia driver debain buster unresolved dependencies

[Andreas Beckmann]

Control: found -1 418.74-1
Control: tag -1 moreinfo unreproducible

On 10/29/19 10:50 PM, hardko...@gmail.com wrote:
> root@dionizos:/home/korek/Pobrane/DaVinci_Resolve_16.1_Linux# apt-get
> install nvidia-driver
...> Następujące pakiety mają niespełnione zależności:
>  nvidia-driver : Wymaga: nvidia-driver-libs (= 418.74-1) ale nie
> zostanie zainstalowany lub
>  nvidia-driver-libs-nonglvnd (= 418.74-1) ale
> nie zostanie zainstalowany
> E: Nie udało się naprawić problemów, zatrzymano uszkodzone pakiety.
...

Can you still reproduce this issue with the updated driver that has
reached buster some time ago?


Andreas

Bug#954788: nvidia-legacy-check can't be installed

[Andreas Beckmann]

Control: tag -1 = wontfix
Control: close -1

On 3/23/20 3:52 PM, Andreas Beckmann wrote:
> On 23/03/2020 15.16, Stefano Simonucci wrote:
>> So I'm not able to install nvidia-cuda-toolkit with my GPU.
> 
> Because it wouldn't work.

Closing as wontfix.

Andreas

PS: nvidia-legacy-check can be disabled via preseeding

Bug#969717: libgl1-mesa-dri: Champions of Regnum display deteriorates after libgl1-mesa-dri upgrade to 20.1.7-1

[VB]

I only tried the 20.1.8 release from sid yet. No change, the problem has still 
to be fixed. I will try from experimental then.

24 septembre 2020 16:12 "Timo Aaltonen"  a écrit:

> On 7.9.2020 12.10, VB wrote:
> 
>> Package:libgl1-mesa-dri
>> Version: 20.1.7-1
>> Severity: important
>> Dear Maintainer,
>> Occasionally the native linux 64-bit client of the mmorpg Champions of > 
>> Regnum becomes unuseable
>> with a messed-up display (no/transparent walls, > invisible characters, grey 
>> backgrounds...) after
>> a libgl1-mesa-dri upgrade.
>> Currently, the last working release is 20.0.7-1 and I have to revert and > 
>> downgrade to it as soon
>> as I try a more recent release.
>> Downgrading only the following 5 packages solves the problem entirely.
>> aptitude:
>> [DOWNGRADE] libegl-mesa0:amd64 20.1.7-1 -> 20.0.7-1
>> [DOWNGRADE] libgbm1:amd64 20.1.7-1 -> 20.0.7-1
>> [DOWNGRADE] libgl1-mesa-dri:amd64 20.1.7-1 -> 20.0.7-1
>> [DOWNGRADE] libglapi-mesa:amd64 20.1.7-1 -> 20.0.7-1
>> [DOWNGRADE] libglx-mesa0:amd64 20.1.7-1 -> 20.0.7-1
> 
> Does 20.1.8 from sid or 20.2.0~rc4 from experimental fix it?
> 
> -- t


Regards,
VB

Bug#970883: gjs: should not migrate to testing until GNOME Shell 3.38 is ready

[Marco Trevisan]

Il 25/09/20 00:06, Simon McVittie ha scritto:
> Nobody is likely to have tested gjs 1.66 with GNOME 3.36 very thoroughly,
> if at all, so we should not let gjs migrate to testing until we're ready
> for GNOME 3.38 to migrate. I'm opening this RC bug to stop that happening.

For what it worth, I've been testing it for a while with no issues, but
of course it can't be considered as a global testing.

And new versions of GJS are supposed not to regress, as per quite
extensive unit tests, so while I agree with stop migrating, I'm quite
sure there wouldn't be any problem.

Bug#970125: nvidia-driver: nvidia-persistenced crashes when UEFI is disabled

[Andreas Beckmann]

Hi,

I don't think this bug is in any way related to UEFI.

On 9/12/20 1:23 AM, Arcademan wrote:
>  C. Sep 11 12:28:46 aa nvidia-persistenced: Failed to open libnvidia-
> cfg.so.1: libnvidia-cfg.so.1: cannot open shared object file: No such file or
> directory

> lrwxrwxrwx 1 root root58 Sep 11 16:47 
> /usr/lib/x86_64-linux-gnu/libnvidia-cfg.so.1 -> 
> /etc/alternatives/glx--libnvidia-cfg.so.1-x86_64-linux-gnu

That is "interesting". Why doesn't nvidia-persistenced find
libnvidia-cfg.so.1 which obviously is available?


Andreas

Bug#970886: ITP: piskel -- an easy-to-use sprite editor

[Joseph Nahmias]

Package: wnpp
Severity: wishlist
Owner: Joseph Nahmias 

* Package name: piskel
  Version : 0.15.0
  Upstream Author : Julian Descottes
* URL : http://piskelapp.com/
* License : Apache 2.0
  Programming Lang: Javascript
  Description : an easy-to-use sprite editor

Piskel is an easy-to-use sprite editor. It can be used to create game
sprites, animations, pixel-art, etc... It is the editor used in the online
pixel editor at piskelapp.com. It can export to a number of different
formats including animated GIFs, and spritesheet PNG/ZIP.

Bug#970885: RFP: adriconf -- GUI tool to configure open source graphics drivers

[Rogério Brito]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debia...@lists.debian.org

* Package name: adriconf
  Version : 2.3.2
  Upstream Author : Jean Hertel 
* URL : https://gitlab.freedesktop.org/mesa/adriconf/
* License : GPLv3
  Programming Lang: C++
  Description : GUI tool to configure open source graphics drivers

adriconf (Advanced DRI CONFigurator) is a GUI tool used to configure open
source graphics drivers. It works by setting options and writing them to the
standard drirc file used by the Mesa drivers.

The main features of the tool are:

* Automatic removal of invalid and unsupported options.
* Options whose value is identical to the system-wide value or the
  driver's default value will be ignored.
* System-wide application options with redundant options will be removed
  automatically.

-

AFAIK, we don't seem to have any kind of easy-to-use configurator of
graphics drivers and this tool seems to fill those needs.

It would be a very valuable addition to the Debian users that need to tweak
one aspect or the other of their graphics configurations.


Thanks,

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

Bug#970848: Problem with path to completion scripts

[Frank Terbeck]

Georgy Komarov wrote:
> I encountered with a problem, when trying to use custom zsh completions.

As debian/README.Debian states:

Load-path for functions from other packages
---

In respsonse to #620452, the zsh-binary from Debian's zsh package started to
provide two entries to $fpath (the search path for loadable functions) for
other packages to drop function files into:

  - /usr/share/zsh/vendor-completions for functions that add functionality to
zsh's function based completion system (compsys)

  - /usr/share/zsh/vendor-functions for all other functions

If you maintain another Debian package that wants to add functions to zsh's
function load-path, please use the those conventions when installing function
files.

Bug#970130: bluez-source: Contains bluez-source-tmp directory

[Vagrant Cascadian]

Control: tags 970130 patch

On 2020-09-12, Chris Lamb wrote:
> I think there are problems with the construction of
> /usr/src/bluez.tar.bz2 in the bluez-source package:
>
>   $ tar xfj usr/src/bluez.tar.bz2
>   $ tree -d
>   .
>   ├── bluez-source-tmp <<
>   │   ├── android
...
>   │   ├── tools
>   │   │   ├── mesh
>   │   │   ├── mesh-gatt
>   │   │   └── parser
>   │   └── unit
>   ..
>
> In addition, this file is not reproducible as it varies on the build
> umask, and it also contains symlinks back to the original build tree,
> but this might all be a symptom of a larger problem.

Attached are several patches fixing these and related reproducibility
issues.

The first three I'm fairly confident about.

I'm not 100% sure about the last patch "Exclude autogenerated files ..."
The patch removes autogenerated files which contain paths unlikely to be
present on the end-user's system, so I presume anything relying on
bluez-source will re-run the appropriate autotools and/or libtool
commands.


live well,
  vagrant
From 26348953a91b70bbe16f86a77051d81eca20fa7d Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 24 Sep 2020 21:54:19 +
Subject: [PATCH 1/4] Add patch to use relative symlinks for the
 lib/bluetooth/*.h headers.

Using the absolute build path only works during the build; the
symlinks are included in the tarball, which results in broken symlinks
in the tarball included in the bluez-source package.
---
 .../headers-use-releative-symlinks.patch  | 21 +++
 debian/patches/series |  1 +
 2 files changed, 22 insertions(+)
 create mode 100644 debian/patches/headers-use-releative-symlinks.patch

diff --git a/debian/patches/headers-use-releative-symlinks.patch b/debian/patches/headers-use-releative-symlinks.patch
new file mode 100644
index 0..c40488d6b
--- /dev/null
+++ b/debian/patches/headers-use-releative-symlinks.patch
@@ -0,0 +1,21 @@
+From: vagr...@reproducible-builds.org
+Subject: Use relative symlinks when linking to headers.
+Date: 2020-09-24
+
+Using the absolute build path only works during the build; the
+symlinks are included in the tarball, which results in broken symlinks
+in the tarball included in the bluez-source package.
+
+Index: bluez/Makefile.am
+===
+--- bluez.orig/Makefile.am
 bluez/Makefile.am
+@@ -612,7 +612,7 @@ $(lib_libbluetooth_la_OBJECTS): $(local_
+ 
+ lib/bluetooth/%.h: lib/%.h
+ 	$(AM_V_at)$(MKDIR_P) lib/bluetooth
+-	$(AM_V_GEN)$(LN_S) -f $(abspath $<) $@
++	$(AM_V_GEN)$(LN_S) -f ../$(shell basename $@) $@
+ 
+ ell/internal: Makefile
+ 	$(AM_V_at)$(MKDIR_P) ell
diff --git a/debian/patches/series b/debian/patches/series
index d4709adf3..effeb7fe2 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -9,3 +9,4 @@ org.bluez.obex.service.in.patch
 Fix-typo.patch
 shared-gatt-client-Fix-segfault-after-PIN-entry.patch
 main.conf-Add-more-details-Closes-904212.patch
+headers-use-releative-symlinks.patch
-- 
2.28.0

From 51c21eda7871ab4434ae3c827bdd906843069520 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 24 Sep 2020 21:55:51 +
Subject: [PATCH 2/4] debian/rules: Unpack source tarball in
 debian/tmp-source/bluez-source, to avoid "tmp-" ending up in the tarball.

---
 debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index ca4d04a33..a00250ff0 100755
--- a/debian/rules
+++ b/debian/rules
@@ -70,7 +70,7 @@ override_dh_fixperms-indep:
 	chmod 0644 debian/bluez-test-scripts/usr/share/doc/bluez-test-scripts/examples/*
 
 override_dh_auto_install-indep: build_bluez-source
-BUILDDIRSOURCE := $(shell pwd)/debian/bluez-source-tmp
+BUILDDIRSOURCE := $(shell pwd)/debian/tmp-source/bluez-source
 build_bluez-source:
 	install -d debian/bluez-source/usr/src
 	mkdir -p $(BUILDDIRSOURCE)
-- 
2.28.0

From 08bf9e0419aef57c6af1e19da4eea52ee3122072 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 24 Sep 2020 21:58:06 +
Subject: [PATCH 3/4] debian/rules: Pass arguments to tar to ensure consistant
 sort order, timestamps, uid, gid and umask when generating bluez-source
 tarball.

---
 debian/rules | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index a00250ff0..26f26abb4 100755
--- a/debian/rules
+++ b/debian/rules
@@ -76,5 +76,9 @@ build_bluez-source:
 	mkdir -p $(BUILDDIRSOURCE)
 	tar --exclude debian --exclude .git --exclude .pc -cf - . | (cd $(BUILDDIRSOURCE) && tar -xf -)
 	cd $(dir $(BUILDDIRSOURCE)) \
-		&& tar -cjf $(shell pwd)/debian/bluez-source/usr/src/bluez.tar.bz2 \
+		&& tar --sort=name \
+			--mtime="@${SOURCE_DATE_EPOCH}" \
+			--owner=0 --group=0 --numeric-owner \
+			--pax-option=exthdr.name=%d/PaxHeaders/%f,delete=atime,delete=ctime \
+			-cjf $(shell pwd)/debian/bluez-source/usr/src/bluez.tar.bz2 \
 		$(notdir $(BUILDDIRSOURCE))
-- 
2.28.0

From 

Bug#885140: [pkg-wicd-maint] Bug#885140: Bug#885140: wicd: Depends on unmaintained pygtk

[Salvo Tomaselli]

The one in experimental absolutely doesn't work for me.

It doesn't list all of the networks for some reason, and can't connect.

I'm using wpa_supplicant -Dwext and such at the moment.

Il giorno gio 24 set 2020 alle ore 14:01 Joerg Dorchain
 ha scritto:
>
> Hello all,
>
>
> On Sat, 28 Dec 2019 15:43:05 + Simon McVittie  wrote:
>
> > The python-gtk dependency went away, so it's certainly true to say that
> > the version in experimental no longer depends on the unmaintained package,
> > which is what the submitter of #885140 wanted :-)
> >
>
> just wondering, the version in experimental is more than a year old. Is
> there a change to upload a more recent version of wicd?
>
> Bye,
>
> Joerg
>
> ___
> pkg-wicd-maint mailing list
> pkg-wicd-ma...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-wicd-maint



-- 
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
-- Galileo Galilei

http://ltworf.github.io/ltworf/

Bug#969321: transition: GNOME 3.38 (mutter, evolution-data-server, etc.)

[Simon McVittie]

Control: tags -1 - moreinfo
Control: clone -1 -2
Control: retitle -1 transition: GNOME 3.38, libmutter-7-0
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-mutter.html
Control: retitle -2 transition: Evolution 3.38
Control: forwarded -2 
https://release.debian.org/transitions/html/auto-evolution-data-server.html

On Mon, 31 Aug 2020 at 12:00:05 +0100, Simon McVittie wrote:
> GNOME 3.38 will be released on 2020-09-16, and beta versions of the
> major packages (versioned 3.37.x) are already making their way into
> experimental and Ubuntu.

The ftp team have now accepted mozjs78 (thanks to whoever did that!) and
3.38.0 releases of the core GNOME packages are in either unstable or
experimental, so I think we're ready to do the GNOME Shell 3.38 transition.

> As usual, there will be a series of entangled small transitions which I
> think would be best handled as a single larger transition

This might actually be better as two separate transitions: mutter and
evolution-data-server, with the core GNOME packages accompanying mutter.
The gnome-shell in experimental was actually compiled against unstable's
evolution-data-server anyway.

> * Core packages like gnome-shell, -session, -settings-daemon and gdm3 rely
>   on being at reasonably well-aligned versions and will have Breaks to
>   ensure they're upgraded from 3.36.x to 3.37.x/3.38.x as a batch
> 
> * gnome-shell needs a new version of mutter with ABI breaks (currently
>   in experimental-NEW)
>- budgie-core will need at least binNMUs and maybe sourceful changes
> 
> * The new gjs version needs mozjs78 (currently in unstable-NEW).
>   mozjs68 will continue to exist at least briefly, so we don't have to
>   do a flag-day transition, although we should try to remove some versions
>   from bullseye after this transition is over. We currently have:
>   - mozjs52 (old, RC-buggy, used by Cinnamon)
>   - (mozjs60 became unused and was removed)
>   - mozjs68 (used by current gjs, libproxy and experimental policykit-1)
> + for libproxy we are already considering removing the mozjs plugin
>   (#959805)
> + for policykit-1 as far as I know there's no intention to ship the
>   version that needs mozjs in testing/unstable
>   - mozjs78 (in NEW)
> 
> * gnome-shell almost certainly breaks the JavaScript API that is presented
>   to Shell extensions
>   - IMO, extensions that cannot be ported promptly should be removed from
> testing to avoid holding back the desktop

These are the main GNOME 3.38 transition. The only C ABI break is in
libmutter, but we should do -shell, -session, -settings-daemon, gdm3,
-control-center, -desktop and gsettings-desktop-schemas as part of the
same batch.

The version of gjs that uses mozjs78 was (perhaps mistakenly) uploaded
to unstable already, so moving to mozjs78 and gjs 1.66 will be going
ahead whether we want it to or not. IMO this means we should do rest
of this part of the transition quite soon too - upstream will not have
done serious testing on the old Shell with the new gjs. I've reported
a RC bug to stop gjs from migrating before we're ready for it.

budgie-desktop should be the only non-GNOME-team package directly affected
by this, apart from gnome-shell-xrdesktop which is not in testing anyway
(and needs to move to contrib). budgie needs at least a rebuild and maybe
source changes, but there's already a version built against libmutter-7-0
waiting in experimental.

Ubuntu already did this transition.

As I said before, some GNOME Shell extensions will almost certainly break,
but we don't know which ones (I checked the few I maintain personally and
they seem OK). I think we should be fairly trigger-happy about removing
these from testing if they're broken or uninstallable.

> * evolution-data-server has an ABI break, which has already made its way
>   through NEW
>   - 
> https://release.debian.org/transitions/html/auto-evolution-data-server.html

I think we can perhaps defer this one until after mutter, Shell and
the other core packages have gone through? Or we could entangle them,
whichever you'd prefer. There are more packages involved and I don't know
the status of all of them: Sebastien Bacher would probably know better.

Ubuntu already did this transition too.

Thanks,
smcv

Bug#970883: gjs: should not migrate to testing until GNOME Shell 3.38 is ready

[Simon McVittie]

Package: gjs
Version: 1.66.0-1
Severity: serious
Justification: maintainer says so
Tags: sid

gjs 1.66.0 uses mozjs78, instead of the old mozj68 used in 1.64.x.

Nobody is likely to have tested gjs 1.66 with GNOME 3.36 very thoroughly,
if at all, so we should not let gjs migrate to testing until we're ready
for GNOME 3.38 to migrate. I'm opening this RC bug to stop that happening.

(I do not have any actual evidence that it doesn't work, but I don't
think the GNOME team either upstream or in Debian is prepared to support
partial upgrades for more than a very brief transitional period. We can
add Breaks if we find that there are concrete things that don't work.)

We can close this bug when the core GNOME packages (-shell,
-session, -settings-daemon, gdm3, -control-center, -desktop and
gsettings-desktop-schemas) are ready in unstable.

smcv

Bug#970882: filesystems that don't begin with empty blocks trash sun disk labels as 1st partition

[Jessica Clarke]

Control: reassign -1 partman-auto
Control: found -1 153
Control: severity -1 important
(affects less-common file systems and only for a ports architecture)

> On 24 Sep 2020, at 22:52, Catherine A. Frederick / mptcultist 
>  wrote:
> 
> Package: debian-installer
> Version: 20200314
> Severity: grave
> User: debian-sp...@lists.debian.org
> Usertags: sparc64
> X-Debbugs-Cc: debian-sp...@lists.debian.org
> 
> Currently, the debian installer uses the force(-f) switch on mkfs to
> make sure that mkfs doesn't bail creating the first partition on the
> disk with an error stating it found a partition label where the
> partition start is. This behavior works fine for ext2, which starts
> with 2 empty blocks, but for other filesystems like XFS the partition
> label is immediately trashed(can be observed by parted reporting the
> label type with "loop"). This location was apparently necessary for
> SILO, and it always functioned as the first partition created by
> guided partitioning was always ext-default and boot first, but now
> that debian-sparc64 uses GRUB2 this _probably_ isn't necessary.
> 
> In manual partitioning the behavior is trivially replicable by
> creating a first partition with an XFS filesystem, where upon choosing
> "beginning" for the location of the new filesystem the start is placed
> at 0. When formatting happens after confirming this setup, the disk
> label is promptly trashed and the system is rendered unbootable.
> 
> src: https://tldp.org/HOWTO/LVM-HOWTO/sundisklabels.html
> 

Bug#970882: filesystems that don't begin with empty blocks trash sun disk labels as 1st partition

[Catherine A. Frederick / mptcultist]

Package: debian-installer
Version: 20200314
Severity: grave
User: debian-sp...@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sp...@lists.debian.org

Currently, the debian installer uses the force(-f) switch on mkfs to
make sure that mkfs doesn't bail creating the first partition on the
disk with an error stating it found a partition label where the
partition start is. This behavior works fine for ext2, which starts
with 2 empty blocks, but for other filesystems like XFS the partition
label is immediately trashed(can be observed by parted reporting the
label type with "loop"). This location was apparently necessary for
SILO, and it always functioned as the first partition created by
guided partitioning was always ext-default and boot first, but now
that debian-sparc64 uses GRUB2 this _probably_ isn't necessary.

In manual partitioning the behavior is trivially replicable by
creating a first partition with an XFS filesystem, where upon choosing
"beginning" for the location of the new filesystem the start is placed
at 0. When formatting happens after confirming this setup, the disk
label is promptly trashed and the system is rendered unbootable.

src: https://tldp.org/HOWTO/LVM-HOWTO/sundisklabels.html

Bug#969258: nvidia-driver: Graphical performance drop in both XFCE and OpenGL apps since the nvidia-driver 450.57-3 update

[Andreas Beckmann]

Control: merge -1 970070

#970070 has logs from 450.66-1

Bug#963980: Also my nvidia card is not detected.

[Andreas Beckmann]

On 9/5/20 11:43 AM, Felix Dörre wrote:
> I've just upgraded from nvidia 450.57-2 to 450.66-1 and observe exactly
> the same problem. In parallel, I also upgraded bumblebee from 3.2.1-25
> to 3.2.1-26. And x-server from 2:1.20.8-2 to 2:1.20.9-1. Also my nvidia
...
> - upgrade xserver: auto-detect broken again
...
> Maybe this information helps someone to figure out what is wrong.

please try xserver-xorg-core 2:1.20.9-2 first and file a bug against it
if the issue persists.

Andreas

Bug#970878: ghostscript breaks doc-rfc autopkgtest: segmentation fault

[Jonas Smedegaard]

Quoting Paul Gevers (2020-09-24 21:31:38)
> https://ci.debian.net/data/autopkgtest/testing/amd64/d/doc-rfc/7163820/log.gz
> autopkgtest [06:12:23]: test pspdf-parsing: [---
> Tests that all files are parseable by p*t*xt,
> in order to suport dhelp integration.
>  - testing rfc1119.ps.gz
>  - testing rfc1124.ps.gz
>  - testing rfc1125.ps.gz
>  - testing rfc1128.ps.gz
>  - testing rfc1129.ps.gz
>  - testing rfc1131.ps.gz
>  - testing rfc1142.ps.gz
>  - testing rfc1144.ps.gz
>  - testing rfc1147.ps.gz
>  - testing rfc1168.ps.gz
>  - testing rfc1195.ps.gz
>  - testing rfc12.ps.gz
>  - testing rfc1237.ps.gz
>  - testing rfc1241.ps.gz
>  - testing rfc1245.ps.gz
>  - testing rfc1246.ps.gz
>  - testing rfc1247.ps.gz
> Segmentation fault
> autopkgtest [07:25:45]: test pspdf-parsing: ---]

Seems the error can be reduced to this:

  apt install doc-rfc-old-std
  zcat /usr/share/doc/RFC/links/rfc1247.ps.gz | ps2txt > /dev/null


 - Jonas

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

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

signature.asc
Description: signature

Bug#970880: freeipa-server: FreeIPA server installation fails with Certificate issuance failed (CA_REJECTED)

[Ferran Obón]

Package: freeipa-server
Version: 4.8.8-2
Severity: important
X-Debbugs-Cc: ferran.o...@gmail.com

Dear Maintainer,

On a fresh install of Debian, the command ipa-server-install ends with the 
following error:
RuntimeError: Certificate issuance failed (CA_REJECTED: Server at 
"https://debian.test.lan:8443/ca/agent/ca//profileProcess; replied:  1: You did 
not provide a valid certificate for this operation).


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

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

Versions of packages freeipa-server depends on:
ii  389-ds-base 1.4.4.4-1
ii  acl 2.2.53-8
ii  adduser 3.118
ii  apache2 2.4.46-1
ii  certmonger  0.79.11-1
ii  chrony  3.5.1-2
ii  custodia0.6.0-5
ii  fonts-font-awesome  5.0.10+really4.7.0~dfsg-2
ii  fonts-open-sans 1.11-1
ii  freeipa-client  4.8.8-2
ii  freeipa-common  4.8.8-2
ii  gssproxy0.8.2-2
ii  krb5-admin-server   1.17-10
ii  krb5-kdc1.17-10
ii  krb5-kdc-ldap   1.17-10
ii  krb5-otp1.17-10
ii  krb5-pkinit 1.17-10
ii  ldap-utils  2.4.53+dfsg-1
ii  libapache2-mod-auth-gssapi  1.6.1-1
ii  libapache2-mod-lookup-identity  1.0.0-1
ii  libapache2-mod-wsgi-py3 4.7.1-2
ii  libc6   2.31-3
ii  libjs-dojo-core 1.15.3+dfsg1-1
ii  libjs-jquery3.5.1+dfsg-4
ii  libjs-scriptaculous 1.9.0-2
ii  libk5crypto31.17-10
ii  libkrad01.17-10
ii  libkrb5-3   1.17-10
ii  libldap-2.4-2   2.4.53+dfsg-1
ii  libnss3-tools   2:3.56-1
ii  libsasl2-modules-gssapi-mit 2.1.27+dfsg-2
ii  libssl1.1   1.1.1g-1
ii  libsss-certmap0 2.3.1-2
ii  libsss-nss-idmap0   2.3.1-2
ii  libtalloc2  2.3.1-1
ii  libunistring2   0.9.10-4
ii  libuuid12.36-3+b1
ii  libverto1   0.3.1-1
ii  libwbclient02:4.12.5+dfsg-3
ii  oddjob  0.34.6-1
ii  p11-kit 0.23.21-2
ii  pki-ca  10.9.4-1
ii  pki-kra 10.9.4-1
ii  python3 3.8.2-3
ii  python3-dateutil2.8.1-4
ii  python3-gssapi  1.6.1-1+b1
ii  python3-ipaserver   4.8.8-2
ii  python3-ldap3.2.0-4+b1
ii  python3-systemd 234-3+b2
ii  samba-libs  2:4.12.5+dfsg-3
ii  slapi-nis   0.56.4-1
ii  softhsm22.6.1-2
ii  ssl-cert1.0.39
ii  sssd-dbus   2.3.1-2
ii  systemd-sysv246.6-1

Versions of packages freeipa-server recommends:
ii  freeipa-server-dns  4.8.8-2

freeipa-server suggests no packages.

-- no debconf information

Bug#961371: Migrating to testing

[Geert Stappers]

At https://tracker.debian.org/pkg/due is currently this:
--
testing migrations

excuses:
* Migration status for due (- to 2.0.0-1): BLOCKED: Rejected/violates migration 
policy/introduces a regression
* Issues preventing migration:
* Not built on buildd: arch all binaries uploaded by stappers, a new 
source-only upload is needed to allow migration
* Too young, only 3 of 5 days old
* Additional info:
* Piuparts tested OK - https://piuparts.debian.org/sid/source/d/due.html
* Not considered
--

I don't yet know what the
  "a new source-only upload is needed to allow migration"
does mean.  So I wait for "5 days old" to happen.


Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#949067: nvidia-legacy-340xx-kernel-dkms: NVRM: RmInitAdapter failed! on Linux Kernel 5.4

[Andreas Beckmann]

Control: tag -1 moreinfo

Hi Pietro,

does this issue still persist with newer kernels (and the 340xx driver
patched for these kernels)?
Or was this perhaps another instance of #948032, #948195 (fixed in
340.108-2)?

On 1/16/20 5:08 PM, Pietro Ventura wrote:
> Package: nvidia-legacy-340xx-kernel-dkms
> Version: 340.108

Which exact Debian package version did you report this issue with?

> In dmesg:
> 
> [   11.392659] NVRM: VM: nv_alloc_contig_pages: failed to DMA-map memory
> [   11.392928] NVRM: RmInitAdapter failed! (0x24:0xb:1171)
> [   11.392945] NVRM: rm_init_adapter failed for device bearing minor number
> 0
> [   11.392972] NVRM: nvidia_frontend_open: minor 0, module->open() failed,
> error -5


Andreas

Bug#970804: awscli: Please package AWS CLI 2.0

[Gregor Riepl]

> I've looked at this a little more.  From what I can tell, the dependency
> on botocore v2 is really going to make this hard to package.  We can't
> simply update the botocore packages to version 2, since it is not
> backwards compatible with v1.  Existing packages that depend on botocore
> would need to be updated, but worse would be all the custom code that
> we'd be breaking with such an upgrade.

Thanks for investigating. I wasn't aware of such a breaking change on
botocore.

> It doesn't help that the botocore project still isn't actually making
> releases from the v2 branch (See https://github.com/boto/botocore/issues/2080)

That issue links to: https://github.com/aws/aws-cli/issues/5282
I've asked there if using awscli with botocore v1 is possible.

> I'm not sure that we've got any good options right now, but maybe I'm
> missing something.  We can do one of the following:
> 

> 1. Leave awscli v2 and botocore v2 unpackaged (current state)

That would be the easiest solution...

> 2. Package botocore v2 as a new package that conflicts with v1 (this
> allows both to co-exist in the archive, but not on an installed system.

This would definitely cause problems when v1 is needed for other tools.

> 3. Package botocore v2 as a new package in such a way as to permit
> side-by-side installation with v1.  This likely involves essentially
> renaming the package, which means a bunch of mangling of python import
> paths. This requires any client code using botocore to be written (or
> patched) to specifically target this modified version.

AWS provides bundled installers:
https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2-linux.html#cliv2-linux-install

Perhaps there is a way to re-package this in a way that doesn't affect
other software in the system? Not the best approach, sure, but this
deviation can be cleaned up when botocore v2 enters Debian.

> Is there something else I'm missing?  Given that awscli v2 specifically
> depends on botocore v2, I doubt it's reasonable to port it to v1, but
> that could potentially be another option.

Let's see if upstream can help.

Bug#970879: vim-python-jedi: Please switch to vim-python3

[Nicholas Guriev]

Package: vim-python-jedi
Version: 0.17.0-1
Tags: patch

Dear Maintainer,

Please replace vim-python alternative in the Depends filed of the package with
vim-python3. There is no anymore Vim with Python 2 support even in buster. And
Jedi works fine with gVim from vim-gtk3 which provides the vim-python3 virtual
package, so the fix is easy.


root@barberry:/# apt-get install -s vim-python-jedi vim-gtk3 vim-nox-
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Package 'vim-nox' is not installed, so not removed
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 vim-python-jedi : Depends: vim-nox but it is not going to be installed or
vim-python but it is not installable
E: Unable to correct problems, you have held broken packages.
root@barberry:/# 


diffstat for python-jedi-0.17.0 python-jedi-0.17.0

 control |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff -Nru python-jedi-0.17.0/debian/control python-jedi-0.17.0/debian/control
--- python-jedi-0.17.0/debian/control   2020-03-16 13:29:00.0 +0300
+++ python-jedi-0.17.0/debian/control   2020-05-06 17:10:59.0 +0300
@@ -22,7 +22,7 @@
 
 Package: vim-python-jedi
 Architecture: all
-Depends: python3-jedi, ${python3:Depends}, ${misc:Depends},  vim-nox | 
vim-python
+Depends: python3-jedi, ${python3:Depends}, ${misc:Depends},  vim-nox | 
vim-python3
 Recommends: vim-addon-manager
 Description: autocompletion tool for Python - VIM addon files
  Jedi is an autocompletion tool for Python. It works. With and without syntax



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

Bug#970804: awscli: Please package AWS CLI 2.0

[Noah Meyerhans]

I've looked at this a little more.  From what I can tell, the dependency
on botocore v2 is really going to make this hard to package.  We can't
simply update the botocore packages to version 2, since it is not
backwards compatible with v1.  Existing packages that depend on botocore
would need to be updated, but worse would be all the custom code that
we'd be breaking with such an upgrade.

It doesn't help that the botocore project still isn't actually making
releases from the v2 branch (See https://github.com/boto/botocore/issues/2080)

I'm not sure that we've got any good options right now, but maybe I'm
missing something.  We can do one of the following:

1. Leave awscli v2 and botocore v2 unpackaged (current state)

2. Package botocore v2 as a new package that conflicts with v1 (this
allows both to co-exist in the archive, but not on an installed system.

3. Package botocore v2 as a new package in such a way as to permit
side-by-side installation with v1.  This likely involves essentially
renaming the package, which means a bunch of mangling of python import
paths. This requires any client code using botocore to be written (or
patched) to specifically target this modified version.

Is there something else I'm missing?  Given that awscli v2 specifically
depends on botocore v2, I doubt it's reasonable to port it to v1, but
that could potentially be another option.

noah

Bug#537963: /usr/bin/lspci: card sticker says X550 but card listed as X600

[Guillem Jover]

Hi!

On Wed, 2009-07-22 at 03:07:33 +0200, Michal Suchanek wrote:
> Package: pciutils
> Version: 1:3.1.3-1
> Severity: normal
> File: /usr/bin/lspci
> 
> 
> 04:00.0 0300: 1002:3e50
> 04:00.0 VGA compatible controller: ATI Technologies Inc RV380 0x3e50 [Radeon 
> X600]
> 04:00.1 0380: 1002:3e70
> 04:00.1 Display controller: ATI Technologies Inc RV380 [Radeon X600] 
> (Secondary)

I've requested this change at:

  https://pci-ids.ucw.cz/read/PC/1002/3e50
  https://pci-ids.ucw.cz/read/PC/1002/3e70

Thanks,
Guillem

Bug#969739: closed by Debian FTP Masters (reply to Timo Aaltonen ) (Bug#969739: fixed in xorg-server 2:1.20.9-2)

[Christophe Kalt]

please to confirm that it is indeed/again working with xserver-xorg-core
1.20.9-2

Bug#969054: log4cplus: diff for NMU version 1.1.2-4

[Tobias Frost]

Control: tags 761133 + pending
Control: tags 811183 + pending
Control: tags 863771 + pending
Control: tags 951321 + pending
Control: tags 969054 + patch
Control: tags 969054 + pending


Dear maintainer,

According to the ITS proecudue,
I've prepared an NMU for log4cplus (versioned as 1.1.2-4) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru log4cplus-1.1.2/debian/changelog log4cplus-1.1.2/debian/changelog
--- log4cplus-1.1.2/debian/changelog	2016-08-08 13:06:16.0 +0200
+++ log4cplus-1.1.2/debian/changelog	2020-09-24 21:23:55.0 +0200
@@ -1,3 +1,39 @@
+log4cplus (1.1.2-4) UNRELEASED; urgency=medium
+
+  [ Tobias Frost ]
+  * Salvaging package (Closes: #969054).
+  * Daigo Moriwaki has retired, removing him from the Uploaders list.
+Thanks for your work on the package! (Closes: #863771)
+  * Dropping Eric Kom from the Uploaders list as well. Thanks for your work!
+  * Updating S-B to 4.5.0:
+-  Change priority to optional.
+-  Set Rules-Requires-Root: no
+  * Update VCS-fields to point to salsa.d.o.
+  * Adding old upstream signing keys (for 1.1-2 version)
+  * Pick up Guillems dep5 conversion work and add missing pieces.
+  * Update homepage field in d/control to new upstream homepage.
+  * Use ${DEB_HOST_MULTIARCH} to install multiarch libraries.
+  * Add la library to debian/not-installed.
+  * Add gbp.conf and gitlab-ci.yml
+  * Cherry picking several patchs from Guillem. for details see
+see #929062 and the following section:
+
+  [ Guillem Jover]
+  * Migration to automatic dbgsym package.
+  * Apply wrap-and-sort -sa
+  * d/watch updated to version 4, enabling upstream signature check.
+  * Convert to Machine-readable debian/copyright file.
+  * Stop installing *.la files.
+  * Install pkgconfig file. (Closes: #951321)
+  * Remove debian/docs, as the contents are irrelevant.
+  * Enable all hardening features, although relro gets disabled due to an
+apparent bug in binutils strip. (Closes: #761133)
+  * Convert to debhelper-compat and bump compat level to 13. This allows one
+to drop dh_autoreconf from B-D and its --with stanza from d/rules.
+  * Mark library and development packages as «Multi-Arch: same». (Closes: #811183)
+
+ -- Tobias Frost   Thu, 24 Sep 2020 21:23:55 +0200
+
 log4cplus (1.1.2-3.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru log4cplus-1.1.2/debian/compat log4cplus-1.1.2/debian/compat
--- log4cplus-1.1.2/debian/compat	2016-08-08 13:02:11.0 +0200
+++ log4cplus-1.1.2/debian/compat	1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-9
diff -Nru log4cplus-1.1.2/debian/control log4cplus-1.1.2/debian/control
--- log4cplus-1.1.2/debian/control	2016-08-08 13:02:11.0 +0200
+++ log4cplus-1.1.2/debian/control	2020-09-24 21:05:59.0 +0200
@@ -1,17 +1,27 @@
 Source: log4cplus
 Section: libs
-Priority: extra
+Priority: optional
 Maintainer: Andrew Pollock 
-Uploaders: Daigo Moriwaki , Eric Kom 
-Build-Depends: debhelper (>= 9), dh-autoreconf, libtool, automake, doxygen
-Standards-Version: 3.9.6
-Homepage: http://log4cplus.sourceforge.net
-Vcs-Browser: http://git.debian.org/?p=collab-maint/log4cplus.git;a=summary
-Vcs-Git: git://git.debian.org/collab-maint/log4cplus.git
+Uploaders:
+ Eric Kom ,
+ Tobias Frost 
+Build-Depends:
+ automake,
+ debhelper-compat (= 13),
+ doxygen,
+ libtool
+Standards-Version: 4.5.0
+Homepage: https://sourceforge.net/p/log4cplus/wiki/Home
+Vcs-Browser: https://salsa.debian.org/debian/log4cplus
+Vcs-Git: https://salsa.debian.org/debian/log4cplus.git
+Rules-Requires-Root: no
 
 Package: liblog4cplus-1.1-9
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Multi-Arch: same
+Depends:
+ ${misc:Depends},
+ ${shlibs:Depends}
 Description: C++ logging API modeled after the Java log4j API - shared library
  log4cplus is a simple to use C++ logging API providing thread-safe,
  flexible, and arbitrarily granular control over log management and
@@ -19,27 +29,15 @@
 
 Package: liblog4cplus-dev
 Architecture: any
+Multi-Arch: same
 Section: libdevel
-Depends: liblog4cplus-1.1-9 (= ${binary:Version}), ${misc:Depends}
+Depends:
+ liblog4cplus-1.1-9 (= ${binary:Version}),
+ ${misc:Depends}
 Description: C++ logging API modeled after the Java log4j API - development library
  log4cplus is a simple to use C++ logging API providing thread-safe,
  flexible, and arbitrarily granular control over log management and
  configuration.  It is modeled after the Java log4j API.
  .
- This package contains the header files and static library for 
+ This package contains the header files and static library for
  developers.
-
-Package: liblog4cplus-dbg
-Section: debug
-Priority: extra
-Architecture: any
-Depends: ${misc:Depends}, liblog4cplus-1.1-9 (= ${binary:Version})
-Description: C++ logging API modeled after the Java log4j API - debug library
- log4cplus is a simple to use C++ logging API providing thread-safe,
- flexible, and arbitrarily 

Bug#970878: ghostscript breaks doc-rfc autopkgtest: segmentation fault

[Paul Gevers]

Source: ghostscript, doc-rfc
Control: found -1 ghostscript/9.53.1~dfsg-2
Control: found -1 doc-rfc/20191026-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

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

   passfail
ghostscriptfrom testing9.53.1~dfsg-2
doc-rfcfrom testing20191026-1
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

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

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

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

Paul

[0] You can see what packages were added from the second line of the log
file quoted below. The migration software adds source package from
unstable to the list if they are needed to install packages from
ghostscript/9.53.1~dfsg-2. I.e. due to versioned dependencies or
breaks/conflicts.
[1] https://qa.debian.org/excuses.php?package=ghostscript

https://ci.debian.net/data/autopkgtest/testing/amd64/d/doc-rfc/7163820/log.gz
autopkgtest [06:12:23]: test pspdf-parsing: [---
Tests that all files are parseable by p*t*xt,
in order to suport dhelp integration.
 - testing rfc1119.ps.gz
 - testing rfc1124.ps.gz
 - testing rfc1125.ps.gz
 - testing rfc1128.ps.gz
 - testing rfc1129.ps.gz
 - testing rfc1131.ps.gz
 - testing rfc1142.ps.gz
 - testing rfc1144.ps.gz
 - testing rfc1147.ps.gz
 - testing rfc1168.ps.gz
 - testing rfc1195.ps.gz
 - testing rfc12.ps.gz
 - testing rfc1237.ps.gz
 - testing rfc1241.ps.gz
 - testing rfc1245.ps.gz
 - testing rfc1246.ps.gz
 - testing rfc1247.ps.gz
Segmentation fault
autopkgtest [07:25:45]: test pspdf-parsing: ---]




signature.asc
Description: OpenPGP digital signature

Bug#970877: hostapd with rt2800 not stable on Debian-10, but on Debian-11 (testing)

[kolafl...@kolahilft.de]

Package: hostapd
Version: 2:2.7+git20190128+0c1e29f-6+deb10u2

Hi,
I'm trying to use my new WLAN / Wi-Fi USB adapter via Debian-10 to set
up an access point (master / ap /infrastructure mode).

Sadly that doesn't work on Debian-10.
After a few minutes the client is always disconnected with hostapd
telling me:
handle_probe_req: send failed

On the other hand the device works great with Debian-11 (testing) and
also openSUSE-15.2.

I've tried using a backports Linux-5.7 kernel and I tried hostapd-2.9
(hostapd-2.9 compiled from source). None of both helped to solve the bug.
So I'm actually not sure it's the fault of hostapd. But I just don't
know what else could make the difference to Debian-11 (testing). So I'm
opening this bug for hostapd.

I've tested the USB device with different hosts.
And even if Debian is being run inside Qemu it's always the same
(regardless of the Qemu host os)
I've even made positive and negative tests with Debian-10 and Debian-11
inside Qemu and the results are always the same.


I attached the "hostapd -d ..." output as file.


USB device details

Brand: CSL
Brand Model: 27395
Brand WDP No.: 300649
WEEE-Reg-No. DE 67896761

It's probably equivalent to the: Panda Wireless PAU09
(at least it looks exactly the same, except the labeling)
https://deviwiki.com/wiki/Panda_Wireless_PAU09
https://wiki.debian.org/rt2800usb

Chip: Ralink RT5572
Used driver: rt2800usb by Debian standard kernel


hostapd -d -iwlan0 hostapd.conf

interface=wlan0

ssid=a
country_code=DE

hw_mode=a
channel=36

wpa=2
auth_algs=1
wpa_pairwise=CCMP
wpa_key_mgmt=WPA-PSK
wpa_passphrase=aa

logger_stdout=-1
logger_stdout_level=2

I tested several variations of this. Including 2.4 GHz and 5 GHz modes.
I just didn't test it without encryption.


Interestingly I've had a very similar problem before with another USB
WLAN adapter.

ALFA Network AWUS036ACH - 802.11ac AC1200

It has no upstream driver, so I used aircrack-ng/rtl8812au
Interestingly it showed very similar problems on Debian-10 and also
works fine with Debian-11 (testing) and openSUSE-15.2.
I've opened an issue for aircrack-ng/rtl8812au before. But after finding
out that the bug only appears on Debian-10, I'm still trying to gather
additional details. But I'm hoping it's maybe the same root cause as
with the Ralink RT5572 adapter.
https://github.com/aircrack-ng/rtl8812au/issues/695



Regards,
kolAflash
nl80211: BSS Event 59 (NL80211_CMD_FRAME) received for wlxdc4ef408653b
nl80211: RX frame da=ff:ff:ff:ff:ff:ff sa=76:47:cd:a0:c3:b9 
bssid=ff:ff:ff:ff:ff:ff freq=5180 ssi_signal=-58 fc=0x40 seq_ctrl=0x43a0 
stype=4 (WLAN_FC_STYPE_PROBE_REQ) len=223
nl80211: send_mlme - da= 76:47:cd:a0:c3:b9 noack=0 freq=0 no_cck=0 offchanok=0 
wait_time=0 fc=0x50 (WLAN_FC_STYPE_PROBE_RESP) nlmode=3
nl80211: send_mlme -> send_frame
nl80211: send_frame - Use bss->freq=5180
nl80211: send_frame -> send_frame_cmd
nl80211: Drop oldest pending send action cookie 0x1a
nl80211: BSS Event 59 (NL80211_CMD_FRAME) received for wlxdc4ef408653b
nl80211: RX frame da=ff:ff:ff:ff:ff:ff sa=76:47:cd:a0:c3:b9 
bssid=ff:ff:ff:ff:ff:ff freq=5180 ssi_signal=-58 fc=0x40 seq_ctrl=0x43b0 
stype=4 (WLAN_FC_STYPE_PROBE_REQ) len=214
nl80211: send_mlme - da= 76:47:cd:a0:c3:b9 noack=1 freq=0 no_cck=0 offchanok=0 
wait_time=0 fc=0x50 (WLAN_FC_STYPE_PROBE_RESP) nlmode=3
nl80211: send_mlme -> send_frame
nl80211: send_frame - Use bss->freq=5180
nl80211: send_frame -> send_frame_cmd
nl80211: Drop oldest pending send action cookie 0x0
nl80211: Drv Event 60 (NL80211_CMD_FRAME_TX_STATUS) received for wlxdc4ef408653b
nl80211: Frame TX status event
wlxdc4ef408653b: Event TX_STATUS (16) received
nl80211: BSS Event 59 (NL80211_CMD_FRAME) received for wlxdc4ef408653b
nl80211: RX frame da=ff:ff:ff:ff:ff:ff sa=76:47:cd:a0:c3:b9 
bssid=ff:ff:ff:ff:ff:ff freq=5180 ssi_signal=-50 fc=0x40 seq_ctrl=0x45a0 
stype=4 (WLAN_FC_STYPE_PROBE_REQ) len=223
nl80211: send_mlme - da= 76:47:cd:a0:c3:b9 noack=0 freq=0 no_cck=0 offchanok=0 
wait_time=0 fc=0x50 (WLAN_FC_STYPE_PROBE_RESP) nlmode=3
nl80211: send_mlme -> send_frame
nl80211: send_frame - Use bss->freq=5180
nl80211: send_frame -> send_frame_cmd
nl80211: Drop oldest pending send action cookie 0x1b
nl80211: BSS Event 59 (NL80211_CMD_FRAME) received for wlxdc4ef408653b
nl80211: RX frame da=ff:ff:ff:ff:ff:ff sa=76:47:cd:a0:c3:b9 
bssid=ff:ff:ff:ff:ff:ff freq=5180 ssi_signal=-50 fc=0x40 seq_ctrl=0x45b0 
stype=4 (WLAN_FC_STYPE_PROBE_REQ) len=214
nl80211: send_mlme - da= 76:47:cd:a0:c3:b9 noack=1 freq=0 no_cck=0 offchanok=0 
wait_time=0 fc=0x50 (WLAN_FC_STYPE_PROBE_RESP) nlmode=3
nl80211: send_mlme -> send_frame
nl80211: send_frame - Use bss->freq=5180
nl80211: send_frame -> send_frame_cmd
nl80211: Drop oldest pending send action cookie 0x0
nl80211: Drv Event 60 (NL80211_CMD_FRAME_TX_STATUS) received for wlxdc4ef408653b
nl80211: Frame TX status event
wlxdc4ef408653b: Event TX_STATUS (16) received
nl80211: Drv Event 20 

Bug#970876: gimp: autopkgtest failure: libgimp/gimpthumb.h: No such file or directory

[Paul Gevers]

Source: gimp
Version: 2.10.20-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

You recently added an autopkgtest to your package gimp, great. However,
it fails. Currently this failure is blocking the migration to testing
[1]. Can you please investigate the situation and fix it?

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/g/gimp/6942995/log.gz

autopkgtest [03:09:38]: test libgimp2.0-dev: [---
+ mktemp -d
+ WORKDIR=/tmp/tmp.K2nraOrlN0
+ export XDG_RUNTIME_DIR=/tmp/tmp.K2nraOrlN0
+ trap rm -rf "$WORKDIR" 0 INT QUIT ABRT PIPE TERM
+ cd /tmp/tmp.K2nraOrlN0
+ [ -n  ]
+ CROSS_COMPILE=
+ cat
+ cat
+ cat
+ pkg-config --cflags --libs gimp-2.0
+ gcc -o gimp-2.0-test gimp-2.0.c -pthread -I/usr/include/gimp-2.0
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/cairo
-I/usr/include/pixman-1 -I/usr/include/uuid -I/usr/include/freetype2
-I/usr/include/libpng16 -I/usr/include/gegl-0.4
-I/usr/include/gio-unix-2.0 -I/usr/include/json-glib-1.0
-I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/babl-0.1
-lgimp-2.0 -lgimpmath-2.0 -lgimpconfig-2.0 -lgimpcolor-2.0
-lgimpbase-2.0 -lgdk_pixbuf-2.0 -lcairo -lgegl-0.4 -lgegl-npd-0.4 -lm
-Wl,--export-dynamic -lgmodule-2.0 -pthread -ljson-glib-1.0 -lgio-2.0
-lgobject-2.0 -lglib-2.0 -lbabl-0.1
+ echo build (gimp-2.0): OK
+ [ -x gimp-2.0-test ]
+ xvfb-run -a ./gimp-2.0-test
build (gimp-2.0): OK
+ echo run (gimp-2.0): OK
run (gimp-2.0): OK
+ pkg-config --cflags --libs gimpthumb-2.0
+ gcc -o gimpthumb-2.0-test gimpthumb-2.0.c -pthread
-I/usr/include/gimp-2.0 -I/usr/include/gdk-pixbuf-2.0
-I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -lgimpthumb-2.0
-lgdk_pixbuf-2.0 -lgobject-2.0 -lglib-2.0
gimpthumb-2.0.c:1:10: fatal error: libgimp/gimpthumb.h: No such file or
directory
1 | #include 
  |  ^
compilation terminated.
+ rm -rf /tmp/tmp.K2nraOrlN0
autopkgtest [03:09:38]: test libgimp2.0-dev: ---]



signature.asc
Description: OpenPGP digital signature

Bug#954448: Bug resolved with new nextcloud.desktop file

[Sandro Knauß]

Hi,

> I resolved the runtime error condition with attached .desktop file, to
> be stripped off the .MATE and
> put in ~/.config/autostart or in /usr/share/applications/
> 
> mate should have its own directory in the debian package hierarchy, just
> as gnome or kde have their own.

I can't see any difference against the shipped desktop file
/usr/share/applications/com.nextcloud.desktopclient.nextcloud.desktop 
anyways the desktop file is not KDE or Gnome specific, so MATE should also 
process it.

hefee




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

Bug#955174: further information

[Sandro Knauß]

Control: tags -1 + upstream

Hey,

this is an upstream issue, so please report it upstream and provide us the 
url, so we can track the status:
https://github.com/nextcloud/desktop/issues

hefee



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

Bug#970874: nix: Embeds different paths when built on a usrmerge system

[Vagrant Cascadian]

Source: nix
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: usrmerge
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

When built on a system with usrmerge enabled, and a system without
usrmerge usrmerge enabled, A file in the nix-bin package embeds
different paths for bash, bzip2, gzip and tar:

./usr/share/nix/corepkgs/config.nix
Offset 1, 18 lines modified Offset 1, 18 lines modified
1   let 1   let
2   ··fromEnv·=·var:·def:   2   ··fromEnv·=·var:·def:
3   let·val·=·builtins.getEnv·var;·in   3   
let·val·=·builtins.getEnv·var;·in
4   if·val·!=·""·then·val·else·def; 4   
if·val·!=·""·then·val·else·def;
5   in·rec·{5   in·rec·{
6   ··shell·=·"/bin/bash";  6   ··shell·=·"/usr/bin/bash";
7   ··coreutils·=·"/usr/bin:/bin";  7   ··coreutils·=·"/usr/bin:/bin";
8   ··bzip2·=·"/bin/bzip2"; 8   ··bzip2·=·"/usr/bin/bzip2";
9   ··gzip·=·"/bin/gzip";   9   ··gzip·=·"/usr/bin/gzip";
10  ··xz·=·"/usr/bin/xz";   10  ··xz·=·"/usr/bin/xz";
11  ··tar·=·"/bin/tar"; 11  ··tar·=·"/usr/bin/tar";


I'm not sure if this file is used in a practical way for the installed
package, but if it does, a package built on a usrmerge system will not
correctly run on a non-usrmerge system.

The attached patch hard-codes these to use the compatible paths in /bin
for these binaries, which should be present on both a usrmerge and
non-usrmerge system, resulting in a backwards compatible and
reproducible build.

Another approach might be if this file is not needed during runtime to
exclude it from the package; I'm not familiar enough with nix to know if
that is viable or not.

Thanks for maintaining nix!


live well,
  vagrant
From 6a5712aeedc3b97dfd8de82432f375bc60b312bb Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 24 Sep 2020 18:13:51 +
Subject: [PATCH] Add patch to fix reproducible builds on usrmerge system.

---
 ...bash-bzip2-gzip-and-tar-to-fix-repro.patch | 41 +++
 debian/patches/series |  1 +
 2 files changed, 42 insertions(+)
 create mode 100644 debian/patches/Specify-path-to-bash-bzip2-gzip-and-tar-to-fix-repro.patch

diff --git a/debian/patches/Specify-path-to-bash-bzip2-gzip-and-tar-to-fix-repro.patch b/debian/patches/Specify-path-to-bash-bzip2-gzip-and-tar-to-fix-repro.patch
new file mode 100644
index ..48774dc8
--- /dev/null
+++ b/debian/patches/Specify-path-to-bash-bzip2-gzip-and-tar-to-fix-repro.patch
@@ -0,0 +1,41 @@
+From 710cbeb21274b555bd72a6c5b2b876e8d036107c Mon Sep 17 00:00:00 2001
+From: Vagrant Cascadian 
+Date: Thu, 24 Sep 2020 18:10:01 +
+Subject: [PATCH] Specify path to bash, bzip2, gzip and tar to fix reproducible
+ build when built on usrmerge system.
+
+When built on a system with usrmerge enabled, and a system without
+usrmerge usrmerge enabled, A file in the nix-bin package embeds
+different paths for bash, bzip2, gzip and tar.
+
+This patch hard-codes these binaries to use the paths present on both
+usrmerge and non-usrmerge systems.
+
+---
+ corepkgs/config.nix.in | 8 
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/corepkgs/config.nix.in b/corepkgs/config.nix.in
+index 32ce6b39..7d91ce85 100644
+--- a/corepkgs/config.nix.in
 b/corepkgs/config.nix.in
+@@ -3,12 +3,12 @@ let
+ let val = builtins.getEnv var; in
+ if val != "" then val else def;
+ in rec {
+-  shell = "@bash@";
++  shell = "/bin/bash";
+   coreutils = "@coreutils@";
+-  bzip2 = "@bzip2@";
+-  gzip = "@gzip@";
++  bzip2 = "/bin/bzip2";
++  gzip = "/bin/gzip";
+   xz = "@xz@";
+-  tar = "@tar@";
++  tar = "/bin/tar";
+   tarFlags = "@tarFlags@";
+   tr = "@tr@";
+   nixBinDir = fromEnv "NIX_BIN_DIR" "@bindir@";
+-- 
+2.20.1
+
diff --git a/debian/patches/series b/debian/patches/series
index 0f7766da..0eece566 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
 fix-service-file-path.patch
 fix-Makefile.patch
 remove_callout_graphics.patch
+Specify-path-to-bash-bzip2-gzip-and-tar-to-fix-repro.patch
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#964434: nextcloud-desktop: Please move the menu entry of nextcloud-dektop to internet

[Sandro Knauß]

Control: tags -1 +upstream

> in order to make the program more accessible for the common user I would
> suggest to move it to the menupoine Internet. This is the place where most
> other desktop clients for internet services reside.

This is not a Debian specific issue, so please report upstream and report back 
the issue id of upstream, so we can track the upstream issue:
https://github.com/nextcloud/desktop/issues

hefee


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

Bug#912941: closed wrong bug

[Peter Green]

reopen 912941
thanks

Bug#970872: libpwiz FTCBFS: configures for the build architecture

[Helmut Grohne]

Source: libpwiz
Version: 3.0.18342-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libpwiz fails to cross build from source, because it does not pass
--host to the configure script. Unfortunately, we cannot easily use
dh_auto_configure, because the script resides in a subdirectory of the
source. Explicitly passing the option makes cross building work anyhow.
Please consider applying the attached patch.

Helmut
diff --minimal -Nru libpwiz-3.0.18342/debian/changelog 
libpwiz-3.0.18342/debian/changelog
--- libpwiz-3.0.18342/debian/changelog  2020-06-11 23:29:40.0 +0200
+++ libpwiz-3.0.18342/debian/changelog  2020-09-24 20:04:27.0 +0200
@@ -1,3 +1,10 @@
+libpwiz (3.0.18342-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Pass --host to configure. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 24 Sep 2020 20:04:27 +0200
+
 libpwiz (3.0.18342-3) unstable; urgency=low
 
   * Add patch by Dimitri John Ledkov  forwarded by Adrian
diff --minimal -Nru libpwiz-3.0.18342/debian/rules 
libpwiz-3.0.18342/debian/rules
--- libpwiz-3.0.18342/debian/rules  2020-06-11 23:29:40.0 +0200
+++ libpwiz-3.0.18342/debian/rules  2020-09-24 20:04:26.0 +0200
@@ -3,10 +3,7 @@
 export DH_VERBOSE=1
 export DH_OPTIONS=-v
 
-DEB_HOST_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
-DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
-DEB_BUILD_ARCH ?= $(shell dpkg-architecture -qDEB_BUILD_ARCH)
-DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
+include /usr/share/dpkg/architecture.mk
 
 DEBIAN_DIR = $(CURDIR)/debian
 BUILD_DIR = $(DEBIAN_DIR)/build
@@ -111,7 +108,7 @@
 
 # Regenerate the configure script
cd $(BUILD_DIR)/autotools && autoreconf --force -i && cd .. && \
-   autotools/configure --prefix=/usr
+   autotools/configure --prefix=/usr --build=$(DEB_BUILD_GNU_TYPE) 
--host=$(DEB_HOST_GNU_TYPE)
 
 configure-stamp: configure
@echo "entering the configure-stamp target"

Bug#970857: petsc4py breaks slepc4py autopkgtest: No module named 'petsc4py'

[Paul Gevers]

Control: reassign -1 src:slepc4py 3.13.0-4
Control: affects -1 src:petsc4py
Control: fixed -1 3.13.0-5

Hi Drew,

This bug was filed against *two* packages, so your message didn't result
in what you wanted as the bts didn't know which of the two sources fixed
the issue.

On 24-09-2020 16:46, Drew Parsons wrote:
> Control: fixed -1 3.13.0-5
> 
> Close.

I hope my changes do the right thing.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#896119: Debian Bug report logs - #896119,scilab: ATOMS system is broken in Scilab 6 on buster

[Thiele, Gregor]

Hi,
is there any fix for the described bug? I am using Scilab 6.0.1 on Debian 10.
Gregor

Bug#970827: ping: socket: Operation not permitted while apt dist-upgrade is in progress

[Witold Baryluk]

Thanks Noah.

I was not sure if ping is using suid as in the past, or the capabilities.

You are of course right:

root@debian:~# ls -l `which ping`
-rwxr-xr-x 1 root root 77432 Aug 23 19:08 /usr/bin/ping
root@debian:~# getcap `which ping`
/usr/bin/ping cap_net_raw=ep
root@debian:~#


This looks like a limitation that would only be possible to solve by
dpkg and extending tar / cpio probably.

>From what I found it is possible to do this with tar and
--xattrs-include='security.capability'  when packing and unpacking.

There is some hacky non-standard patches for cpio,
https://github.com/initlove/cpio/commit/531cabc88e9ecdc3231fad6e4856869baa9a91ef
, but afaik not upstreamed.
And even more hacky support in kernel for initramfs uses:
https://lists.gnu.org/archive/html/bug-cpio/2019-05/msg1.html

I didn't see any real updates on this topic, last one is from middle of 2019.

I agree it is hard.

Cheers.

On Thu, 24 Sep 2020 at 02:51, Noah Meyerhans  wrote:
>
> Control: severity -1 minor
>
> > 1) ping is working
> > 2) start apt dist-upgrade
> > 3) at some point new ping stops working with ping: socket: Operation not 
> > permited
> >   for minutes.
> > 4) apt dist-upgrade finishes
> > 5) ping works again
>
> The ping process requires the ability to open a raw network socket,
> which is a privileged operation.  The ping binary contained within the
> package is completely unprivileged, so when it's initially installed it
> can only be executed by the root user or some other user that has
> retained the cap_net_raw capability.  Later in the installation process,
> the package's post-install script tries to add the cap_net_raw
> file-based capability to the binary as that's the safest (least
> privileged) way to grant users the ability to run ping.  If that fails,
> probably because the system is configured with some unusual filesystem
> that doesn't support file-based capabilities, then the script sets the
> suid bit on the binary, granting unprivileged users the ability to run
> ping with a slight reduction in the security posture.
>
> I'm not sure of a practical way to avoid this situation.  If .deb files
> could contain files with capabilities set on them, then this would
> likely improve the situation for most users, but I believe it's still
> the case that this isn't possible.
>
> You can see the script in question at
> https://salsa.debian.org/debian/iputils/-/blob/master/debian/iputils-ping.postinst
>
> noah
>

Bug#970871: "modinfo -F" always shows name for built-ins

[Ben Hutchings]

Package: kmod
Version: 27+20200310-2
Severity: normal

Now that the kernel provides module information for potentially
modular code that's actually built-in, it's possible to query these
built-ins with "modinfo -F".  However, this doesn't work quite right:

$ modinfo -Flicense e1000e
GPL v2
$ modinfo -Flicense bitrev
name:   bitrev
GPL

Ben.

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

Kernel: Linux 5.8.0-1-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 kmod depends on:
ii  libc6  2.31-3
ii  libkmod2   27+20200310-2
ii  liblzma5   5.2.4-1+b1
ii  libssl1.1  1.1.1g-1
ii  lsb-base   11.1.0

kmod recommends no packages.

kmod suggests no packages.

-- no debconf information

Bug#970478: ERROR: Renderer process crashed when using qtwebengine backend.

[Dmitry Shachnev]

Hi Florian,

On Tue, Sep 22, 2020 at 03:04:28PM +0200, Florian Bruhin wrote:
> Let me note that QtWebEngine 5.15.1 has another bug causing frequent
> renderer process crashes: https://bugreports.qt.io/browse/QTBUG-86752
>
> I'm currently trying to bisect it because it seems to work in the
> current 5.15 branch - but I suppose it might be the Chromium update
> between 5.15.1 and 5.15(.2) fixing this again.
>
> Thus, I'd recommend either staying with 5.15.0, or using the current
> 5.15 HEAD (or waiting for 5.15.2).

That's bad news :(

Qt 5.15 is requested by too many people, and I really don't want to wait
until 5.15.2 because that may be a quite close to our transition freeze
(2021-01-12).

But if we land 5.15.1 now (in a few weeks), then it will be easier and
faster to update to 5.15.2 whenever it gets released, if it is before the
transition freeze.

In any case, I have subscribed to upstream bug and keeping an eye on it —
if a concrete patch is identified then I will cherry-pick it to our 5.15
packaging.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#970870: postgresql-autodoc: incompatible with PostgreSQL >= 12

[Nicolas Dandrimont]

Package: postgresql-autodoc
Version: 1.40-3
Severity: grave
Tags: upstream sid bullseye

Dear maintainer,

postgresql-autodoc, as currently packaged in Debian, doesn't work with
PostgreSQL 12, which is the current default version of PostgreSQL in testing and
sid (it works fine with PostgreSQL 11 which is shipped with buster).

The failure mode is the following (excuse my French):

$ postgresql_autodoc -d softwareheritage-dev -f autodoc/db-schema

DBD::Pg::st execute failed: ERREUR:  la colonne � adsrc � n'existe pas
LIGNE 40 : adsrc
   ^ at /usr/bin/postgresql_autodoc line 687.
DBD::Pg::st fetchrow_hashref failed: no statement executing at 
/usr/bin/postgresql_autodoc line 689.
[...]
Use of uninitialized value in numeric comparison (<=>) at 
/usr/bin/postgresql_autodoc line 991.
[...]
Use of uninitialized value in numeric comparison (<=>) at 
/usr/bin/postgresql_autodoc line 1466.
[...]

This generates dot files with a lot of column missings.

Upstream seems to have picked up development on GitHub at
https://github.com/cbbrowne/autodoc. This repository shows a bunch of commits on
top of the current Debian version which should fix at least this bug.

Thank you,
Nicolas

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

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

Versions of packages postgresql-autodoc depends on:
ii  libdbd-pg-perl 3.14.2-1
ii  libhtml-template-perl  2.97-1
ii  libterm-readkey-perl   2.38-1+b1
ii  perl   5.30.3-4

Versions of packages postgresql-autodoc recommends:
ii  dia 0.97.3+git20160930-9
ii  docbook-defguide [docbook-book] 2.0.17+svn9912-2
ii  firefox [www-browser]   80.0.1-1
ii  firefox-esr [www-browser]   78.2.0esr-1
ii  google-chrome-stable [www-browser]  85.0.4183.102-1
ii  graphviz2.42.2-4

postgresql-autodoc suggests no packages.

-- no debconf information

Bug#923696: lintian: Bad examples in Lintian::Tutorial::TestSuite

[Louis-Philippe Véronneau]

Hi,

Kindly bump :)

It seems this bug was never closed and the way to call tests has changed
once again?

I was told `private/build-test-packages && private/runtests` is what one
should now run, but it would be great if the CONTRIBUTING.md
documentation could be updated to make external contributions easier.

Thanks for your work on lintian!

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature

Bug#970867: python3-llvmlite: llvmlite 0.34 depends on incompatible llvm-9

[Drew Parsons]

On 2020-09-25 00:45, Drew Parsons wrote:
...

Secondly, numba has a tight dependency on llvm (< 0.34).
Hence upload of llvmlite 0.34 has broken numba.

llvmlite is a subproject of numba.  You should not upload llvmlite
without checking numba compatibility and uploading the matching
version of numba. But the version of numba compatible with llvmlite
0.34 has not been released yet.


To clarify the state of numba, numba 0.51.2 does support llvmlite 0.34, 
so it needs to be uploaded.

Bug#619442: mtd-utils: please include in armel installer

[Bastian Germann]

On Wed, 26 Nov 2003 18:56:57 -0500 Jonathan Lane
 wrote:
> Package: mtd-utils
> Version: 20090606-1
> Severity: wishlist
> 
> I'm running Debian Squeeze on a Marvell Sheevaplug, and I'd really like to 
> install Debian directly to NAND memory.  The mtd-utils package contains all 
> the tools needed to do that that aren't already in the installer, and the 
> existing method of putting a Debian install on the internal NAND is a pain in 
> the rear.  I'm in no real hurry to get this fixed right now, but it would be 
> nice for future releases like Wheezy.
> 
> Jonathan Lane
> 
> -- System Information:
> Debian Release: 6.0.1
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: armel (armv5tel)
> 
> Kernel: Linux 2.6.32-5-kirkwood
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> 
> Versions of packages mtd-utils depends on:
> ii  libc6   2.11.2-10Embedded GNU C Library: Shared 
> lib
> ii  libgcc1 1:4.4.5-8GCC support library
> ii  liblzo2-2   2.03-2   data compression library
> ii  libuuid12.17.2-9 Universally Unique ID library
> ii  zlib1g  1:1.2.3.4.dfsg-3 compression library - runtime
> 
> mtd-utils recommends no packages.
> 
> mtd-utils suggests no packages.
> 
> -- no debconf information

Would you like the package to have a udeb version like the one that is
referenced at https://wiki.debian.org/DebianInstaller/MTD#MTD_utils ?

Is there still interest in this?

Bug#970869: openvpn: Incorrect handling of multiple instances of template service

[ಚಿರಾಗ್ ನಟರಾಜ್]

Package: openvpn
Version: 2.5~beta3-1
Severity: important
X-Debbugs-Cc: debb...@chiraag.me

Dear Maintainer,

I happened to run into an interesting issue and I'm not entirely sure if the 
problem is in openvpn, openvpn-systemd-resolved, or systemd-resolved.

1. I have several configuration files in /etc/openvpn, say A.conf and B.conf.
2. I run sudo systemctl start openvpn@A and note that the tunnel is 
established, DNS queries don't leak, etc. Everything's good.
3. I then run sudo systemctl start openvpn@B and note that a new tunnel is 
established and DNS queries are (at the very least) _also_ routed to the new 
DNS server. Everything's still good (I'm not sure if DNS queries are *also* 
routed to the first VPN server's DNS server due to both having dhcp-option 
DOMAIN-ROUTE ., but that's irrelevant for my specific use-case and irrelevant 
to this bug).
4. I then disconnect from B by running sudo systemctl stop openvpn@B and note 
that the first tunnel is still established (good!), but all traffic seems to be 
directed to my main network interface instead (bad!). This can be verified by 
going to e.g. https://whatismyipaddress.com and noticing that your ISP's IP 
address is the one showing there rather than the IP address assigned by your 
VPN provider.

I would have expected the first tunnel to take over the connection, especially 
since resolvectl status still seemed to indicate that everything was set 
correctly on the DNS end (correct domain routing, etc) and systemctl status 
openvpn@A seemed to show that the VPN is still connected.

Sincerely,

Chiraag

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

Kernel: Linux 5.8.0-1-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=kn_IN.UTF-8, LC_CTYPE=kn_IN.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 openvpn depends on:
ii  debconf [debconf-2.0]  1.5.74
ii  iproute2   5.8.0-1
ii  libc6  2.31-3
ii  liblz4-1   1.9.2-2
ii  liblzo2-2  2.10-2
ii  libpam0g   1.3.1-5
ii  libpkcs11-helper1  1.26-1+b1
ii  libssl1.1  1.1.1g-1
ii  libsystemd0246.6-1
ii  lsb-base   11.1.0

Versions of packages openvpn recommends:
pn  easy-rsa  

Versions of packages openvpn suggests:
hi  openssl   1.1.1g-1
ii  openvpn-systemd-resolved  1.3.0-3
pn  resolvconf

-- Configuration Files:
/etc/openvpn/update-resolv-conf [Errno 13] Permission denied: 
'/etc/openvpn/update-resolv-conf'

-- debconf information excluded

Bug#944738: openjdk-11: diff for NMU version 11.0.8+10-1.1

[tony mancill]

Control: tags 944738 + pending

Hello Matthias,

I've prepared an NMU for openjdk-11 (versioned as 11.0.8+10-1.1) and
uploaded it to DELAYED/15. Please feel free to tell me if I should delay
it longer or remove the upload from the queue.

Thank you,
tony
diff -Nru openjdk-11-11.0.8+10/debian/changelog openjdk-11-11.0.8+10/debian/changelog
--- openjdk-11-11.0.8+10/debian/changelog	2020-07-22 05:26:43.0 -0700
+++ openjdk-11-11.0.8+10/debian/changelog	2020-09-23 21:16:34.0 -0700
@@ -1,3 +1,12 @@
+openjdk-11 (11.0.8+10-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply patch to strip nondeterminism before computing jmod hash.
+Thank you to Julian Gilbey for the patch.  (Closes: #944738)
+Add Build-Depends on strip-nondeterminism.
+
+ -- tony mancill   Wed, 23 Sep 2020 21:16:34 -0700
+
 openjdk-11 (11.0.8+10-1) unstable; urgency=high
 
   * OpenJDK 11.0.8+10 build (release).
diff -Nru openjdk-11-11.0.8+10/debian/control openjdk-11-11.0.8+10/debian/control
--- openjdk-11-11.0.8+10/debian/control	2020-07-22 05:26:43.0 -0700
+++ openjdk-11-11.0.8+10/debian/control	2020-09-23 21:16:34.0 -0700
@@ -15,6 +15,7 @@
   zlib1g-dev:native, zlib1g-dev, libattr1-dev, libpng-dev, libjpeg-dev, libgif-dev, 
   libnss3-dev (>= 2:3.17.1),
   openjdk-11-jdk-headless ,
+  strip-nondeterminism,
 Build-Depends-Indep: graphviz, pandoc,
 Standards-Version: 4.5.0
 Homepage: http://openjdk.java.net/
diff -Nru openjdk-11-11.0.8+10/debian/patches/reproducible-build-jmod.diff openjdk-11-11.0.8+10/debian/patches/reproducible-build-jmod.diff
--- openjdk-11-11.0.8+10/debian/patches/reproducible-build-jmod.diff	1969-12-31 16:00:00.0 -0800
+++ openjdk-11-11.0.8+10/debian/patches/reproducible-build-jmod.diff	2020-09-23 21:16:34.0 -0700
@@ -0,0 +1,33 @@
+Description: jlink: Hash of module differs to expected hash recorded in java.base
+ The cause is the use of dh_strip_nondeterminism late in the build
+ process.  This reorganises the jmod files, which in turn changes their
+ SHA256 checksums.  This would not be a problem, except that the
+ checksums are saved in java.base.jmod *before* the use of
+ dh_strip_nondeterminism.  Performing this stripping immediately after
+ each jmod file is created results in the checksums being consistent
+ throughout.
+Author: Julian Gilbey 
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944738
+Forwarded: not-needed
+
+--- a/make/CreateJmods.gmk
 b/make/CreateJmods.gmk
+@@ -213,6 +213,9 @@
+ 
+ # Create jmods in a temp dir and then move them into place to keep the
+ # module path in $(IMAGES_OUTPUTDIR)/jmods valid at all times.
++# strip-nondeterminism requires the same timestamp as
++# dh_strip_nondeterminism uses, so we determine this first.
++DSN_TIMESTAMP := $(shell perl -MDebian::Debhelper::Dh_Lib -e 'print get_source_date_epoch()')
+ $(JMODS_DIR)/$(MODULE).jmod: $(DEPS)
+ 	$(call LogWarn, Creating $(patsubst $(OUTPUTDIR)/%, %, $@))
+ 	$(call MakeDir, $(JMODS_DIR) $(JMODS_TEMPDIR))
+@@ -224,7 +227,7 @@
+ 	--module-path $(JMODS_DIR) \
+ 	$(JMOD_FLAGS) $(JMODS_TEMPDIR)/$(notdir $@) \
+ 	)
+-	$(MV) $(JMODS_TEMPDIR)/$(notdir $@) $@
++	strip-nondeterminism --timestamp $(DSN_TIMESTAMP) $(JMODS_TEMPDIR)/$(notdir $@) && $(MV) $(JMODS_TEMPDIR)/$(notdir $@) $@
+ 
+ TARGETS += $(JMODS_DIR)/$(MODULE).jmod
+ 
diff -Nru openjdk-11-11.0.8+10/debian/patches/series openjdk-11-11.0.8+10/debian/patches/series
--- openjdk-11-11.0.8+10/debian/patches/series	2020-07-22 05:26:43.0 -0700
+++ openjdk-11-11.0.8+10/debian/patches/series	2020-09-23 21:16:34.0 -0700
@@ -44,3 +44,4 @@
 reproducible-module-info.diff
 reproducible-copyright-headers.diff
 reproducible-build-user.diff
+reproducible-build-jmod.diff


signature.asc
Description: PGP signature

Bug#862957: file-roller: Fails to deal correctly with filename encodings in zip files

[Matsievskiy S.V.]

I have the same problem. Here's a minimal example:

```bash
touch пример_имени_файла
zip test.zip пример_имени_файла
unzip -l test.zip  # shows name properly
file-roller test.zip # shows gibberish
```

Bug#964125: calibre: Please switch from sip4 to sip5

[Dmitry Shachnev]

On Mon, Sep 21, 2020 at 02:28:24PM +0300, Dmitry Shachnev wrote:
> Sorry for the delay. I hope I will upload it to unstable before end of
> September.

And this is done now. PyQt5 in unstable now uses SIP 5.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#970868: RM: dyndns -- RoQA; Non-DFSG license

[Joao Eriberto Mota Filho]

Package: ftp.debian.org
Severity: normal

Dear admins,

As mentioned in #932796, dyndns is not DFSG compliant. This package has low
popcon and there are alternatives in Debian to provide the same service.

No packages depends of dyndns.

Regards,

Eriberto

Bug#958179: create user-friendly startup configuration

[Florian Schlichting]

Hi Eduard and Francois,

I agree that README.Debian is a mess. What keeps me from fixing it is
that I'm unsure how people are using (or intend to use) mpd.

Historically, the package has shipped a lot of infrastructure for
running as a system service, and I think having mpd run on a headless
box somewhere on the home network and being able to control one's music
remotely is one of its big appeals.

However I feel most users would probably be served better by deleting all
of that infrastructure and configuring mpd to run from their user
session, just like their pulseaudio, which in my understanding is the
proper way to solve the permissions problem that Eduard mentions.

This assumes that "most users" start on a default Gnome desktop with
pulseaudio, but then some people prefer to use JACK oder ALSA with dmix
or want to run several instances of mpd or don't use systemd or do use
systemd but haven't heard of socket activation etc, and there's your
mess.

Can we do sensible things for all of these use cases, or should we try
to do less but have that work out of the box? And what's the default use
case to be?

Confused,
Florian


On Sun, Apr 19, 2020 at 02:12:53PM +0200, Eduard Bloch wrote:
> Package: mpd
> Version: 0.21.20-1
> Severity: wishlist
> 
> Hi,
> 
> I have used mpd like 10 years ago and it was quite okay back then. I
> wanted to revive it, and I failed.
> It seems that:
> 
> a) is no longer capable of auto-detecting an ALSA device. I get errors
> like "Failed to open ALSA device (default)"
> 
> b) when I change the config to use pulse audio, it fails. The reported
> error is not helpful, mentioning some permission problem. Maybe
> README.Debian should explain in detail what this is about?
> 
> In the end it looks like it runs as a separate user without permissions.
> And README.Debian talks around that fact but not saying clearly what's
> up. Then it suggests to clone the config to $HOME in varios ways and
> investigate how to start it.
> 
> I am sorry, but for me those instructions look just messy. There should
> be some kind of script for initial setup which the user just runs and it
> asks "do you want to use it in your Desktop session?" and if not then it
> should clearly communicate how to modify permissions to make the audio
> output accessible.
> 
> Best regards,
> Eduard.
> 
> }
> 
> /etc/mpd.conf changed:
> music_directory   "/data/wdblue_partition5/audio"
> playlist_directory"/var/lib/mpd/playlists"
> db_file   "/var/lib/mpd/tag_cache"
> log_file  "/var/log/mpd/mpd.log"
> pid_file  "/run/mpd/pid"
> state_file"/var/lib/mpd/state"
> sticker_file   "/var/lib/mpd/sticker.sql"
> user  "mpd"
> bind_to_address   "localhost"
> input {
> plugin "curl"
> }
> input {
> enabled"no"
> plugin "qobuz"
> }
> input {
> enabled  "no"
> plugin   "tidal"
> }
> decoder {
> plugin  "hybrid_dsd"
> enabled "no"
> }
> audio_output {
>   type"alsa"
>   name"My ALSA Device"
> }
> filesystem_charset"UTF-8"
> 
> 
> -- no debconf information
> 
> --
>  hat hier wer ne arm und schnell zeit n paket zu bauen?
>  abi: hast du gerade "arm" und "schnell" in einem Satz benutzt?

On Sun, Sep 06, 2020 at 12:09:29PM -0700, Francois Marier wrote:
> Not a solution to the issue you raised, but in case that helps, I've
> documented my own setup here:
> 
>   https://feeding.cloud.geek.nz/posts/home-music-server-with-mpd/
> 
> Francois
> 
> -- 
> https://fmarier.org/
> 
> ___
> Pkg-mpd-maintainers mailing list
> pkg-mpd-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-mpd-maintainers

Bug#966680: src:acpica-unix: fails to migrate to testing for too long: FTBFS on s390x

[Al Stone]

On 24 Sep 2020 11:23, Paul Gevers wrote:
> Hi Al,
> 
> ping
> 
> On Sat, 1 Aug 2020 21:34:14 +0200 Paul Gevers  wrote:
> > This bug will trigger auto-removal when appropriate. As with all new
> > bugs, there will be at least 30 days before the package is auto-removed.
> 
> acpica-unix is a key package and will not be autoremoved. Can you please
> fix the situation?
> 
> Paul

Yup, working on it.  I may have to turn off s390x support for the
short term; the issue is that this package is solely little-endian
upstream and it has been patched and bodged so many times for
big-endian support, it has been become unmaintainable for big-
endian.  These patches are being re-done and made straightforward
but it is taking a lot longer than hoped; ideally, I can get them
upstreamed and simplify further.





-- 
Ciao,
al
--
Al Stone Debian Developer
E-mail: a...@ahs3.nethttp://www.debian.org
 a...@debian.org
--


signature.asc
Description: PGP signature

Bug#969247: FIX: add /etc/boinc-client/config.properties

[Marcel Partap]

.. so after some research, this happens due to these changes merged in March: 
https://github.com/BOINC/boinc/pull/3709

Fortunately, previous behaviour can easily be restored by adding a 
/etc/boinc-client/config.properties file containing:

> data_dir=/var/lib/boinc

That points boincmgr and boinccmd where to find the gui_rpc_auth.cfg file to 
read the password from.
In order for a random password (in case of an empty file) to be written 
successfully, I think I had to change the permission for either the sym link 
/var/lib/boinc-client/gui_rpc_auth.cfg or the actual file in /etc.

Regards!

Bug#970867: python3-llvmlite: llvmlite 0.34 depends on incompatible llvm-9

[Drew Parsons]

Package: python3-llvmlite
Version: 0.34.0-1
Severity: serious
Justification: Policy 7.2
Control: affects -1 src:numba src:dolfinx
Control: block 970694 by -1

llvmlite 0.34.0 has just been uploaded. This is a problem for 2 reasons.

Firstly, llvmlite declares a dependency on llvm-9.  But it is not
compatible with llvm-9, see
https://github.com/numba/llvmlite#compatibility
It requires llvm-10.

Secondly, numba has a tight dependency on llvm (< 0.34).
Hence upload of llvmlite 0.34 has broken numba.

llvmlite is a subproject of numba.  You should not upload llvmlite
without checking numba compatibility and uploading the matching
version of numba. But the version of numba compatible with llvmlite
0.34 has not been released yet.

This also affects dolfinx, which requires a working numba.

Bug#970829: covtobed FTCBFS: uses the build architecture compiler

[Shayan Doust]

Hello Helmut,

Acknowledged. Thank you for this.

Kind regards,
Shayan Doust

On Thu, 24 Sep 2020 06:15:21 +0200 Helmut Grohne  wrote:
> Source: covtobed
> Version: 1.1.2+dfsg-2
> Tags: patch
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
> 
> covtobed fails to cross build from source, because debian/rules uses the
> build architecture compiler as a make default. Please consider letting
> dpkg's buildtools.mk set up the CXX variable to make covtobed cross
> buildable. I'm attaching a patch for your convenience.
> 
> Helmut


0x6D7D441919D02395.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Bug#959693: [Pkg-mpd-maintainers] Bug#959693: mpd: user units should be disabled by default

[Florian Schlichting]

Hi Andrei,

> In the default configuration the user units are both failing for various 
> reasons:
> 
> 1. Without a user mpd.conf mpd will fall back to /etc/mpd.conf, which in 
> the default configuration is not suitable for a user daemon. 
> 
> 2. The port 6600 is already taken by the system instance.
> 
> Since running a user instance already requires explicit configuration 
> the user units can be shipped disabled by default, to prevent them from 
> failing in the default configuration.

I agree that enabling user units without providing a working
configuration probably doesn't make much sense - it was meant as
convenience, but mpd starting without being explicitly enabled by the
has caused confusion more than once. Not sure what to do about the XDG
autostart file though...

> P.S. the mpdconf.example mentioned in README.Debian is missing from the 
> package

oops, thanks for the heads up! Not sure when that one got lost...

Florian

Bug#970694: numba: FTBFS: unsat-dependency: python3-llvmlite:amd64 (< 0.34)

[Drew Parsons]

Source: numba
Followup-For: Bug #970694

There's something amiss here.

llvmlite upstream claims that llvmlite 0.34 is compatible only with
llvm 10.  See https://github.com/numba/llvmlite#compatibility

But this Debian package of llvmlite 0.34 was built against llvm 9 ?

Bug#970266: mount: comment=x-gvfs-show not removed from options for non-reoot user

[Chris Hofstaedtler]

Control: reassign -1 cifs-utils

Dear Samba Maintainers,

this appears to be something you could probably investigate better.

* Martin Schwenke  [200924 15:34]:
> On Mon, 14 Sep 2020 08:45:04 +0200, Chris Hofstaedtler
>  wrote:
> > * Martin Schwenke  [200914 01:48]:
> > [..]
> > > I add this to /etc/fstab:
> > >   //digby/flac/mnt/flac   cifs
> > > noauto,user,username=guest,password=,ro,soft,vers=3,comment=x-gvfs-show   
> > >0   0
> > > "mount /mnt/flac" as root works without a problem.
> > >   
> > [..]
> > > /var/log/kern.log shows:
> > >   Sep 14 09:38:05 kloof kernel: [183360.156767] CIFS: Attempting to mount 
> > > //digby/flac
> > >   Sep 14 09:38:05 kloof kernel: [183360.156809] CIFS: Unknown mount 
> > > option "comment=x-gvfs-show"
> > > 
> > > So it appears that the comment is being passed to the helper, which
> > > does not follow the documentation.  
> > 
> > Please be so kind and run this on your machine:
> > $ strace -ttf -bexecve -s3 mount /mnt/flac
> > 
> > And look for the execve() line, probably something like this:
> > pid 1687840] 06:42:51.534769 execve("/sbin/mount.cifs", 
> > ["/sbin/mount.cifs", "/mnt/flac", "-o", ... 
> > 
> > Please check if comment=x-gvfs-show actually appears there.
> > In my limited testing I found mount does not pass a comment=...
> > option to mount.cifs.
> 
> Wow!  Correct:
[..]

It appears mount.cifs somehow re-adds a comment=... option from
/etc/fstab when calling mount(), for "user"-style mounts.

$ strace -ttf -bexecve -s3 mount /mnt
 execve("/sbin/mount.cifs", ["/sbin/mount.cifs", "//x/y", "/mnt", "-o", 
"rw,noexec,nosuid,nodev,username=ch,user"], 0x7ffc40273cb0 /* 42 vars */) = 0

In a root-strace of mount.cifs, you'll see:
 mount("//x/y$", ".", "cifs", MS_NOSUID|MS_NODEV, 
"ip=10.100.0.52,unc=x\\y,noauto,comment=foo,uid=1000,gid=1000,user=ch,pass=yolo")
 = -1 EINVAL (Invalid argument)

Doesn't appear to be a util-linux/mount problem to me.

Best,
Chris

Bug#970866: rabbiter: package is placed in wrong section: ruby

[Jonas Smedegaard]

Package: rabbiter
Version: 2.0.4-3
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package section "ruby" is for packages implementing or extending
the scripting language Ruby.

It is not for all packages _written_ in Ruby.

Package decription indicates that rabbiter is not a Ruby interpreter
nor a Ruby library, but instead a user-facing tool.

Please change package section - e.g. to "net" or "misc".

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl9sutMACgkQLHwxRsGg
ASHTRw/9E8UPFQ51iTZfEIPlR4kt0i9gaxlrCjw8N8Qhty/hIE6XzGMWLyIzaNbY
KINg/wV76BdZ24rwvGjldrMjAsvLIDSu30xENvE9cjhtvMaF9o9pOVW452qTOqb3
h2o81R8m++TOHC6v0Vbb6qhcJhn4aPoRMQ42cxHkPCj0vPQVcFEyxT2gvt7RfKE6
M2J49WWH+GwHIzDj9dlxH5FR+IKXIEHWyXtyaQOe+TDr7RuXD9k0esynyCaI2wyy
nza9ib5InmneKJVlPo3Mt1nuL6OPtTZxk18/rxxv45ZfyL8Oihj0wXQuKuivEMYv
wHzlHV3nnWr4gN1NqZFduNk7OD1Zi+TutRjYG170YvEPWEees884qt3N3b1mGcQn
+0WjMVJl/2dvG4GIoBVcUhBQ9lC14VUZB7CtEP2u1aIpW6Hce7HbsATEm3WjlgaX
e0AwxzimHUVV38ZDtdJcrYEtCWcCeqy3LMiMLoIvFmfzf1ShT/ym1oHGRWAWjFgu
urO+R5Usim4BWUR7qMHOJV+5wX9yW4zc+wHndo8NBX+VfEKABbKODimBpZdPYSBL
KJMKi6QMASapmqcjB0Nx+QHWy87v2Qo9RGHkQUe7WDOX6D7J92xXwgwX4zYQlKpT
KxB3u5BVUIQaWFJWS1woVDSIoM61SWdxM04vzVbNh+ZZLrUDC60=
=9irg
-END PGP SIGNATURE-

Bug#970864: dolphinx: flaky amd64 autopkgtest on ci.debian.net: regularly times out

[Drew Parsons]

Source: dolfinx
Followup-For: Bug #970864

Thanks for your bug report.

DOLFIN-X is a work-in-progress (i.e. not yet officially released).
Probably the first thing to try is to update to latest upstream
git snapshot.

I note the problematic test is in the complex number build. One option
is to just skip the test.  The real number tests have been passing fine.

Upstream may have thoughts on the problem. I'll let them know.

Bug#966985: Bug#970410: src:html5lib: fails to migrate to testing for too long: autopkgtest regressions

[Sandro Tosi]

> Thank you for the recent upload. Unfortunately, your package still can't
> migrate because it causes a FTBFS/autopkgtest regression in
> python-bleach (hence in CC).
>
> > This bug will trigger auto-removal when appropriate. As with all new
> > bugs, there will be at least 30 days before the package is auto-removed.
>
> Both packages are key packages [1], so will not be removed
> automatically. Please align how to fix the situation.

bleach needs to be upgraded to 3.2.1

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#968927: Affects buster (1.0.114) as well

[Jan Kiszka]

Just to add my 2 cents after spending half of today debugging this issue
out of our kas-isar container [1]: Affects the buster version of
debootstrap as well. The proposed patch fixes it there, too.

Any plans to include this? Would be great!

Thanks,
Jan

[1]
https://groups.google.com/d/msgid/kas-devel/8d2408ef-899f-8479-7674-eb344da2bb85%40siemens.com

Bug#970863: nagstamon: Correct GPL-2 in copyright to GPL-2+

[Bastian Germann]

On Thu, 24 Sep 2020 15:33:08 +0200 Bastian Germann
 wrote:
> Source: nagstamon
> Severity: normal
> 
> Please correct the copyright file to say GPL-2+ (which is the package's
> license) instead of GPL-2 (only). This has an impact on the package
> because it is a derivative work of pyqt5, which is GPL-3 licensed and
> thus incompatible with GPL-2 only.

I see that debian/* are amongst the GPL-2 only licensed files.
Carl and Moritz, would you please consider relicensing to GPL-2+? That
will be necessary at least for the patches.

Also, Nagstamon/Servers/Multisite.py needs more investigation. Does the
checkmk project allow its distribution under GPL-3 as well? I did not
find the file in the current checkmk version.

Bug#970865: openssh 8.3 in buster-backports

[Andreas Pflug]

Package: openssh-client
Version: 1:7.9p1-10+deb10u2

I'd like to see openssh client+server with Version 8.3 in
buster-backports, because I'd like to use the new FIDO2-U2F security key
support which was introduced upstream in 8.2.

Regards,
Andreas

Bug#970862: php-imagick cannot be loaded by apache2: Cannot allocate memory in static TLS block

[Ondřej Surý]

Control: reassign -1 libgomp1

Hi,

that doesn’t really seem to be a problem in the php-imagick:

/lib/aarch64-linux-gnu/libgomp.so.1: cannot allocate memory in static TLS block

Ondrej
--
Ondřej Surý (He/Him)
ond...@sury.org

> On 24. 9. 2020, at 15:29, procyon  wrote:
> 
> Package: php-imagick
> Version: 3.4.3-4.1
> Severity: normal
> 
> Dear Maintainer,
> 
> loading the php module imagick fails with the following error in the apache2 
> error log:
> 
> PHP Warning:  PHP Startup: Unable to load dynamic library 'imagick.so' 
> (tried: /usr/lib/php/20180731/imagick.so 
> (/lib/aarch64-linux-gnu/libgomp.so.1: cannot allocate memory in static TLS 
> block), /usr/lib/php/20180731/imagick.so.so 
> (/usr/lib/php/20180731/imagick.so.so: cannot open shared object file: No such 
> file or directory)) in Unknown on line 0
> 
> on an arm64 system (Raspberry Pi 4B).
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>   * What led up to the situation?
> I installed php-imagick and restarted apache2.
>   * What exactly did you do (or not do) that was effective (or
> ineffective)?
>   * What was the outcome of this action?
> The php module imagick could not be loaded.
>   * What outcome did you expect instead?
> The php module imagick should be loaded without errors.
> 
> 
> -- System Information:
> Debian Release: 10.5
>  APT prefers stable
>  APT policy: (990, 'stable'), (500, 'unstable')
> Architecture: arm64 (aarch64)
> 
> Kernel: Linux 5.8.0-2-arm64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_CRAP
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
> LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages php-imagick depends on:
> ii  libapache2-mod-php7.3 [phpapi-20180731]  7.3.19-1~deb10u1
> ii  libc62.28-10
> ii  libmagickcore-6.q16-68:6.9.10.23+dfsg-2.1+deb10u1
> ii  libmagickwand-6.q16-68:6.9.10.23+dfsg-2.1+deb10u1
> ii  php-common   2:69
> ii  php7.3-cli [phpapi-20180731] 7.3.19-1~deb10u1
> 
> Versions of packages php-imagick recommends:
> ii  ghostscript  9.27~dfsg-2+deb10u4
> ii  ttf-dejavu-core  2.37-1
> 
> php-imagick suggests no packages.
> 
> -- no debconf information
> 

Bug#969717: libgl1-mesa-dri: Champions of Regnum display deteriorates after libgl1-mesa-dri upgrade to 20.1.7-1

[Timo Aaltonen]

On 7.9.2020 12.10, VB wrote:

Package:libgl1-mesa-dri
Version: 20.1.7-1
Severity: important

Dear Maintainer,

Occasionally the native linux 64-bit client of the mmorpg Champions of 
Regnum becomes unuseable with a messed-up display (no/transparent walls, 
invisible characters, grey backgrounds...) after a libgl1-mesa-dri upgrade.


Currently, the last working release is 20.0.7-1 and I have to revert and 
downgrade to it as soon as I try a more recent release.


Downgrading only the following 5 packages solves the problem entirely.

aptitude:
[DOWNGRADE] libegl-mesa0:amd64 20.1.7-1 -> 20.0.7-1
[DOWNGRADE] libgbm1:amd64 20.1.7-1 -> 20.0.7-1
[DOWNGRADE] libgl1-mesa-dri:amd64 20.1.7-1 -> 20.0.7-1
[DOWNGRADE] libglapi-mesa:amd64 20.1.7-1 -> 20.0.7-1
[DOWNGRADE] libglx-mesa0:amd64 20.1.7-1 -> 20.0.7-1


Does 20.1.8 from sid or 20.2.0~rc4 from experimental fix it?




--
t

Bug#970864: dolphinx: flaky amd64 autopkgtest on ci.debian.net: regularly times out

[Paul Gevers]

Source: dolfinx
Version: 2019.2.0~git20200420.6043d6d-6
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky timesout

Dear maintainer(s),

The autopkgtest of dolphinx turns up on the ci.debian.net slow test page
[1]. That's not a problem per se, but your test regularly times out and
fails, while other times it finishes and passes.

Within autopkgtest, there are different timeouts involved (see
autopkgtest(1)), in the case of this package the timeout that is hit is
the per test timeout.

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

I copied the output of one of the failures at the bottom of this report.

Please do get in touch if we need to dive into this together.

Paul

[1] https://ci.debian.net/status/slow/

https://ci.debian.net/data/autopkgtest/testing/amd64/d/dolfinx/7160784/log.gz

python/test/unit/fem/test_expression_evaluation.py
python/test/unit/fem/test_expression_evaluation.py
   [ 32%]
python/test/unit/fem/test_expression_evaluation.py xxx
   [ 33%] [ 33%]
python/test/unit/fem/test_fem_pipeline.py  [ 33%]
python/test/unit/fem/test_fem_pipeline.py
python/test/unit/fem/test_fem_pipeline.py
.autopkgtest
[07:10:36]: ERROR: timed out on command "su -s /bin/bash debci -c set
-e; export USER=`id -nu`; . /etc/profile >/dev/null 2>&1 || true;  .
~/.profile >/dev/null 2>&1 || true;
buildtree="/tmp/autopkgtest-lxc.lgrg6l15/downtmp/build.lxi/src"; mkdir
-p -m 1777 --
"/tmp/autopkgtest-lxc.lgrg6l15/downtmp/test-dolfinx-python-complex-artifacts";
export
AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest-lxc.lgrg6l15/downtmp/test-dolfinx-python-complex-artifacts";
export ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755
"/tmp/autopkgtest-lxc.lgrg6l15/downtmp/autopkgtest_tmp"; export
AUTOPKGTEST_TMP="/tmp/autopkgtest-lxc.lgrg6l15/downtmp/autopkgtest_tmp";
export ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive;
export LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=2; unset LANGUAGE
LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE   LC_MONETARY LC_MESSAGES
LC_PAPER LC_NAME LC_ADDRESS   LC_TELEPHONE LC_MEASUREMENT
LC_IDENTIFICATION LC_ALL;rm -f /tmp/autopkgtest_script_pid; set -C; echo
$$ > /tmp/autopkgtest_script_pid; set +C; trap "rm -f
/tmp/autopkgtest_script_pid" EXIT INT QUIT PIPE; cd "$buildtree"; chmod
+x
/tmp/autopkgtest-lxc.lgrg6l15/downtmp/build.lxi/src/debian/tests/test-dolfinx-python-complex;
touch
/tmp/autopkgtest-lxc.lgrg6l15/downtmp/test-dolfinx-python-complex-stdout
/tmp/autopkgtest-lxc.lgrg6l15/downtmp/test-dolfinx-python-complex-stderr; 
/tmp/autopkgtest-lxc.lgrg6l15/downtmp/build.lxi/src/debian/tests/test-dolfinx-python-complex
2> >(tee -a
/tmp/autopkgtest-lxc.lgrg6l15/downtmp/test-dolfinx-python-complex-stderr
>&2) > >(tee -a
/tmp/autopkgtest-lxc.lgrg6l15/downtmp/test-dolfinx-python-complex-stdout);"
(kind: test)
autopkgtest [07:10:44]: test test-dolfinx-python-complex:
---]



signature.asc
Description: OpenPGP digital signature

Bug#970744: ben: please provide machine-parseable version of transition status

[Stéphane Glondu]

Le 23/09/2020 à 20:52, Sebastian Ramacher a écrit :
>>> thanks for maintaining ben. In additiona to the HTML output, it would be
>>> great to have the same information as machine-parseable file. With such
>>> a file one could feed other tools to further process the info produced
>>> by ben, e.g., to produce a list of binNMUs.
>>
>> Did you know that there were a text output? Probably not what you mean
>> by "machine-parseable", but maybe easier to parse than the HTML output.
> 
> No, I didn't. I work with the HTML output on release.debian.org most of
> the time.

I just realized there is already a JSON output, made by Mehdi in 2015...
maybe it could suit your needs?


Cheers,

-- 
Stéphane

Bug#970863: nagstamon: Correct GPL-2 in copyright to GPL-2+

[Bastian Germann]

Source: nagstamon
Severity: normal

Please correct the copyright file to say GPL-2+ (which is the package's
license) instead of GPL-2 (only). This has an impact on the package
because it is a derivative work of pyqt5, which is GPL-3 licensed and
thus incompatible with GPL-2 only.

Bug#970862: php-imagick cannot be loaded by apache2: Cannot allocate memory in static TLS block

[procyon]

Package: php-imagick
Version: 3.4.3-4.1
Severity: normal

Dear Maintainer,

loading the php module imagick fails with the following error in the apache2 
error log:

PHP Warning:  PHP Startup: Unable to load dynamic library 'imagick.so' (tried: 
/usr/lib/php/20180731/imagick.so (/lib/aarch64-linux-gnu/libgomp.so.1: cannot 
allocate memory in static TLS block), /usr/lib/php/20180731/imagick.so.so 
(/usr/lib/php/20180731/imagick.so.so: cannot open shared object file: No such 
file or directory)) in Unknown on line 0

on an arm64 system (Raspberry Pi 4B).

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
 I installed php-imagick and restarted apache2.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
 The php module imagick could not be loaded.
   * What outcome did you expect instead?
 The php module imagick should be loaded without errors.


-- System Information:
Debian Release: 10.5
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable')
Architecture: arm64 (aarch64)

Kernel: Linux 5.8.0-2-arm64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages php-imagick depends on:
ii  libapache2-mod-php7.3 [phpapi-20180731]  7.3.19-1~deb10u1
ii  libc62.28-10
ii  libmagickcore-6.q16-68:6.9.10.23+dfsg-2.1+deb10u1
ii  libmagickwand-6.q16-68:6.9.10.23+dfsg-2.1+deb10u1
ii  php-common   2:69
ii  php7.3-cli [phpapi-20180731] 7.3.19-1~deb10u1

Versions of packages php-imagick recommends:
ii  ghostscript  9.27~dfsg-2+deb10u4
ii  ttf-dejavu-core  2.37-1

php-imagick suggests no packages.

-- no debconf information

Bug#970810: python3-venv is gone

[Jyrki Pulliainen]

On Thu 24. Sep 2020 at 16.02, Matthias Klose  wrote:

> On 9/24/20 9:51 AM, Jyrki Pulliainen wrote:
>
> > Thanks for the bug report.
>
> >
>
> > Is pyvenv included in 3.8 in sid now? Package repository still lists
>
> > python3-venv as an available package in Sid


>
>
> it's still there, but will be gone for bullseye.
>
>
Ok thanks for the clarification!

Is it included by default in python3? I tried eyeballing experimental
packages but failed miserably there to figure it out
-- 
- Jyrki

Bug#953875: Debian FTP Masters

[Lorenzo]

On 9/24/20 1:45 AM, Felix Freeman wrote:
> It's not solved on my end with Debian 10... here is what I see when I
> try to install git-all.

Hi Felix,

I'm sorry about the trouble that this bug is causing to Debian users.
The bug has been automatically closed by the BTS because there is a new
version of runit that fix it,
but it's in experimental (see the changelog from the previous message).
The bug is certainly still open
in Buster.

The change in runit-2.1.2-37 is an appropriate fix for this bug but
unfortunately is a 'too big' change to
be accepted in the current Stable release.

> This also has been reported on #934646, though really the bug is on this
> package order of preference.

changing the order of preference of the recommend as you (and others)
suggested is not a real
fix, is just dumping this RC bug on another (yeah, smaller) set of users.
Despite the apparent inaction on this bug, I'm still thinking on a
possible different solution.

Regards,
Lorenzo

Bug#970810: python3-venv is gone

[Matthias Klose]

On 9/24/20 9:51 AM, Jyrki Pulliainen wrote:
> Thanks for the bug report.
> 
> Is pyvenv included in 3.8 in sid now? Package repository still lists
> python3-venv as an available package in Sid

it's still there, but will be gone for bullseye.

Bug#970696: One more change

[Tobias Frost]

Uploaded! (Many thanks for ITSing)