date:20191105

Package: enigmail
Version: 2:2.1.3+ds1-1
Control: tags -1 + help

I've uploaded Enigmail 2.1.3 to debian unstable, but there are still a
handful of errors in the test suite when running the unit tests.

This bug report is meant to keep track of them, hopefully it will help
someone™ figure out where the problems are coming from as well.

The three problems each come in pairs of test failures, likely all to do
with the replacement of openpgp.js with GnuPG, which we're continuing to
do because OpenPGP.js appears to be unpackagable by debian (see
https://bugs.debian.org/787774).

The issues are:

A) Something is wrong with the basic autocrypt test:

AssertionError: message is long enough - false == true - JS frame :: 
file:///home/dkg/src/enigmail/enigmail/package/tests/autocrypt-test.js :: 
shouldGetKeyFunctions/< :: line 187
AssertionError: this should not happen - "keyImportFailed" == 0 - JS frame :: 
file:///home/dkg/src/enigmail/enigmail/package/tests/autocrypt-test.js :: 
shouldGetKeyFunctions/< :: line 197

B) Minimal key export is different:

AssertionError: "LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCg" == 
"xsDNBFub08oBDACmb04i4u8xUV1ADbnbN5l83mpr70OyWVJb5E" - JS frame :: 
file:///home/dkg/src/enigmail/enigmail/package/tests/keyObj-test.js :: 
shouldExportMinimalSubkey :: line 53
AssertionError: "U1Ci0tLS0tRU5EIFBHUCBQVUJMSUMgS0VZIEJMT0NLLS0tLS0K" == 
"1MU0qOC5SusatWeaebL9igZMla4aqtnLyRwLcsKODSTaZXQw==" - JS frame :: 
file:///home/dkg/src/enigmail/enigmail/package/tests/keyObj-test.js :: 
shouldExportMinimalSubkey :: line 54

C) Some problem with Autocrypt setup message:

AssertionError: keys must not be null - null != null - JS frame :: 
file:///home/dkg/src/enigmail/enigmail/package/tests/autoSetup-test.js :: 
performAutocryptSetupTest :: line 606
RuntimeError: Caught unhandled exception: TypeError: keys is null - 
file:///home/dkg/src/enigmail/enigmail/package/tests/autoSetup-test.js ::  :: 
line 607
Stack: 
performAutocryptSetupTest@file:///home/dkg/src/enigmail/enigmail/package/tests/autoSetup-test.js:607:3
withEnigmail/<@file:///home/dkg/src/enigmail/enigmail/package/tests/testHelper.js:330:14
withTestGpgHome/<@file:///home/dkg/src/enigmail/enigmail/package/tests/testHelper.js:167:7
runTests@file:///home/dkg/src/enigmail/enigmail/package/tests/testHelper.js:77:31
@chrome://jsunit/content/modules/jsunit-exec.js:15:3
executeScript@chrome://jsunit/content/modules/jsunit-main.jsm:214:29
do_subtest@chrome://jsunit/content/modules/jsunit-wrapper.js:37:17
execTest@file:///home/dkg/src/enigmail/enigmail/package/tests/main.js:20:5
@file:///home/dkg/src/enigmail/enigmail/package/tests/main.js:60:1
executeScript@chrome://jsunit/content/modules/jsunit-main.jsm:212:27
startCmdLineTests@chrome://jsunit/content/modules/jsunit-service.js:42:14
_f@chrome://jsunit/content/modules/jsunit-service.js:58:7
notify@resource://gre/modules/Timer.jsm:62:17


A is the most troubling -- it seems possible that A indicates a failure
to import an OpenPGP certificate from an autocrypt header.

B looks like it might just be an issue with a differently-formatted
secret key -- the test is very strict about exactly what the right key
is, but this isn't something that should be too bad -- as long as the
constructed minimal OpenPGP certificate is plausible, we might even just
fix this by updating the test to match whatever GnuPG does.

C looks like a possible problem with symmetric encryption and decryption
using GnuPG.  This is probably best tested with some minimal test like
so:

--
"use strict";
let enc = {
message: "this is a silly test, right?\ni know!\n",
password: "abc1234",
format: "utf8"
};
dump("message: " + enc.message + "\n");
dump("password: " + enc.password + "\n");

const EnigmailGpg = 
ChromeUtils.import("chrome://enigmail/content/modules/gpg.jsm").EnigmailGpg;
msg = EnigmailGpg.symmetricDecrypt(enc);
dump("output: " + msg + "\n");
--

However this fails on the ChromeUtils.import line, with:

Exception occurred:
[Exception... "File error: Not found"  nsresult: "0x80520012 
(NS_ERROR_FILE_NOT_FOUND)"  location: "JS frame :: file:///home/dkg/main.js :: 
 :: line 10"  data: no] - 
** Tests aborted **


I'd love any advice or guidance people care to share here :)

--dkg


signature.asc
Description: PGP signature

Bug#944152: network access during the build

Now fixed, although I got the changelog message wrong because I still
didn't understand properly.  Ugh.  I could have sworn that Debian buildds
didn't allow network access.  I'll fix the changelog message in a future
upload.

Thank you!

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

Bug#944151: remctl: attempts internet connection during testsuite

Now fixed, although I got the changelog message wrong because I still
didn't understand properly.  Ugh.  I could have sworn that Debian buildds
didn't allow network access.  I'll fix the changelog message in a future
upload.

Thank you!

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

Bug#245416:

2019-11-05 Thread Володя Казка

Помилка 245416

Bug#941147: Please stop removing affects of #941147

2019-11-05 Thread Helmut Grohne

Control: affects 941147 + src:kde-cli-tools src:powerdevil src:systemsettings 
src:apper src:kget src:kdeplasma-addons src:khotkeys src:plasma-desktop

Hi Pino,

Please stop removing the affected bugs of #941147 without giving a
reason. The submission explains why they are needed and QA tooling
relies on these affects to avoid duplicate work. Thank you.

Dear ow...@bugs.debian.org,

I am hereby reporting that Pino Toscano  vanadlizes
metadata of bug #941147 and ask you to take note of that behaviour in
case it is repeated elsewhere.

Helmut

Bug#816215: hi

2019-11-05 Thread yusuf osman

Hello dear, i have been waiting for your response, kindly check your
inbox and get back to me, i really need your responds as soon as
possible, i look forward to hear from you soon. Thanks

Yours Sincerely
Yusuf

Bug#944155: lintian: Version format vs source format mismatch tags disappeared

2019-11-05 Thread Felix Lechner

Hi Guillem,

On Tue, Nov 5, 2019 at 5:54 PM Guillem Jover  wrote:
>
> Perhaps we
> can turn this report around on making the tag name more clear instead?

What would you say if Lintian were to catch the parsing error and
issue the old tags---the ones with clearer names---when those
conditions apply?

When those conditions are not identified, Lintian could perhaps issue
other helpful tags and only fall back on the bland
'malformed-debian-changelog-version' as a last resort.

Kind regards
Felix

Bug#921328: auctex: please generate and install auto-loads.el (upstream Makefile target)

2019-11-05 Thread Nicholas D Steeves

Hi Davide,

On Mon, Feb 04, 2019 at 02:50:07AM -0700, Nicholas D Steeves wrote:
> Package: auctex
> Version: 11.91-2
> Severity: normal
> Control: block 906259 by -1
> 
> Dear Auctex maintainers,
> 
> While doing packaging smartparens I discovered that our AUCTeX does not 
> generate or install auto-loads.el.  Smartparens' self-tests fail as a result.
> 
> I believe the solution is probably as simple as just adding "$(MAKE) 
> auto-loads.el" to debian/rules:L57, because this is an existing upstream 
> Makefile target, and then installing the file.
> 

I've waited most of a year for a response and am considering pursuing
an NMU for this bug if it's not resolved by the time the other
blockers for smartparens have been resolved.  I took a quick stab at
my proposed solution and will have to spend some time deducing what
style of installation you'd prefer.

Please consider taking the time to fix this so it doesn't come to that
:-)

Sincerely,
Nicholas

P.S. ideally it would be nice to see this package converted to use
dh-elpa, but I suspect you'd be against it, because it seems like
XEmacs support is a priority, and this conversion drops support for
XEmacs.  Personally I believe that's a worthwhile compromise due to
all the time it saves from ongoing maintenance.

signature.asc
Description: PGP signature

Bug#944215: Please update your chrome to latest stable #78.0.3904.87

2019-11-05 Thread 積丹尼 Dan Jacobson

Package: chromium
Version: 76.0.3809.100-1
Severity: wishlist

On https://bugs.chromium.org/p/chromium/issues/detail?id=1019570#c4 I
was told to Please update your chrome to latest stable #78.0.3904.87 .

Bug#944155: lintian: Version format vs source format mismatch tags disappeared

2019-11-05 Thread Guillem Jover

Hi!

On Tue, 2019-11-05 at 03:39:19 -0800, Felix Lechner wrote:
> On Tue, Nov 5, 2019 at 2:27 AM Guillem Jover  wrote:
> > At least the following tags:
> > have disappeared,
> >
> >   debian-changelog-version-requires-debian-revision
> >   hyphen-in-native-debian-changelog-version
> 
> Both tags were replaced by 'malformed-debian-changelog-version'. Do
> you see that tag anywhere?

Ah right, sorry didn't notice that tag when looking for one from the
entire list as the name didn't seem obviously involved with this.

I've dug a bit and noticed that the previous tags that had somewhat
clearer names got renamed multiple times up to the current
'malformed-debian-changelog-version':

  - native-package-with-dash-version ->
hyphen-in-native-debian-changelog-version
  - non-native-package-with-native-version ->
hyphen-in-upstream-part-of-debian-changelog-version

I guess the reason I found the current tag name confusing is that to
me it seems to imply a parsing error, not a logic or consistency error,
which is what I'd expect from a mismatch between the source package
format and the source version format.

> > I suspect because dpkg-source does not allow a
> > mismatch between the version format and source formats 3.0?
> 
> I am not sure how dpkg-source figures into your line of thinking, but
> I have been eliminating tags from Lintian because they are untestable.
> The primary and perhaps sole reason is that dpkg and friends refuse to
> create packages (or files) with such conditions. On occasion I have
> thought about sending you our discarded code for the dpkg test suite.

Sorry, that was probably stemming from our recent conversation about
exactly those untestable tags. And I assumed a possible switch to
format 3.0 in the tests might have caused this removal, my bad. :)

> > But this
> > mismatch is still possible with source format 1.0.
> 
> The source format is not presently an input for our version parser,
> nor does policy seem to consider it relevant for that purpose. I think
> Lintian still detects the condition you are thinking of (provided dpkg
> does not quit when trying to create the defective package).

Yes it does.

> > So reintroducing
> > these would be very much appreciated.
> 
> That is not currently planned, but there is potential for improvement.
> We appreciate all merge requests, especially from those who know
> version parsing better than anyone.

Given my bogus initial understanding that's perfectly fine. Perhaps we
can turn this report around on making the tag name more clear instead?
:)

Otherwise if you disagree, closing it would seem acceptable too.

Thanks,
Guillem

Bug#944214: libaqbanking: please make the build reproducible

2019-11-05 Thread Chris Lamb

Source: libaqbanking
Version: 5.99.43beta-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
libaqbanking could not be built reproducibly.

This is because the Debian-specific manpage generation script includes
stderr into the manpage which, alas, contains an timestamped error
message. Patch attached that discards the standard error stream.

As an aside, regardless of this change the manpage includes a "This is
version $version" in a strange place:

 40 Two common options need to be distinguished carefully from
each other: "\-c CUSTOMER_ID" refers to the German "Kunden\-
ID" or "Kundennummer"\&. "\-u USER_ID" refers to the
>>German "Benutzerkennung"\&. If your bank has specified both
to you, you need to check carefully not to confuse one with
the other\&.
 41 .sp
 42 This is version 5\&.99\&.43
 43 .PP
 44 \-D PARAM, \-\-cfgdir=PARAM
 45 .RS 4
 46 Specify the configuration folder

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/doc/Makefile   2019-11-05 17:14:36.913153978 -0800
--- b/debian/doc/Makefile   2019-11-05 17:35:14.565626230 -0800
@@ -9,7 +9,7 @@
asciidoc -d manpage -b docbook $<
 
 aqhbci-tool4.1.generated.txt: ../../src/tools/aqbanking-cli/aqhbci-tool4
-   $< --help 2>&1 \
+   $< --help \
| sed -e 's/^Usage:.*//;s/^Global 
Options:.*//;s/:$$/::/g;s/^\(\S\+.*\)::$$/== \1/g;s/^  \(\S\+\)::/\1::/g;s/^ 
\[\(.*\)\]/\1::/g' \
> $@

Bug#944213: mimefilter: is a salvaging candidate, possibly should be orphaned

2019-11-05 Thread Nicholas D Steeves

Package: mimefilter
Version: 1.7+nmu2
Severity: normal

Dear Davide, Salvatore, and Damyan,

It seems to me that mimefilter is a candidate for salvaging, because
the last upload by the maintainer was in 2002, the NMUdiff at Bug
#673267 has not been merged for seven years, and a second NMU was
uploaded since then.

Davide, are you still interested in maintaining this package?

Salvatore and Damyan, I've CCed you because you did the NMUs and seem
like the primary candidates for salvaging.  I've also CCed the MIA
team on olly's recommendation.


Regards,
Nicholas

Bug#944188: /etc/msmtprc password disclosure

2019-11-05 Thread Simon Deziel

Hi Jakub,

On 2019-11-05 9:29 a.m., Jakub Wilk wrote:
> Package: msmtp
> Version: 1.8.6-1
> Tags: security
> 
> If /etc/msmtprc is readable by group msmtp (as suggested in
> README.Debian), any user can acquire password from that file:
> 
>   $ ls -l /etc/msmtprc
>   -rw-r- 1 root msmtp 86 Nov  5 15:06 /etc/msmtprc
> 
>   $ cat /etc/msmtprc
>   cat: /etc/msmtprc: Permission denied
> 
>   $ msmtp --debug nob...@example.org < /dev/null
>   loaded system configuration file /etc/msmtprc
>   ignoring user configuration file /home/jwilk/.msmtprc: No such file or
> directory
>   falling back to default account
>   using account default from /etc/msmtprc
>   ...
>   --> AUTH PLAIN AGFsaWNlAGh1bnRlcjI=
>   ...
> 
>   $ base64 -d <<< 'AGFsaWNlAGh1bnRlcjI=' | tr '\0' ':'; echo
>   :alice:hunter2

Nice catch! Having /etc/msmtprc group readable is AFAIK, a "debianism".
I don't know if upstream endorses this method of restricting access
to the default account's password.

That said, I think it would be feasible for msmtp to obfuscate the AUTH
line when the UID/GID do not match the EUID/EGID and the config file
used it not world-readable.

The upstream developer is usually very responsive so it would be great
if you could report it to him.

Thank you!
Simon

Bug#944212: harfbuzz: FTBFS on hppa - test timeout

2019-11-05 Thread John David Anglin

Source: harfbuzz
Version: 2.6.2-1
Severity: normal

Dear Maintainer,

The build fails because of the following fuzzer timeout:
running subset fuzzer against 
../../../test/fuzzing/fonts/clusterfuzz-testcase-hb-subset-fuzzer-5717414645334016
error: timeout, 
failed for 
../../../test/fuzzing/fonts/clusterfuzz-testcase-hb-subset-fuzzer-5717414645334016

Full log is here:
https://buildd.debian.org/status/fetch.php?pkg=harfbuzz=hppa=2.6.4-1=1573000897=0

There is a similar fail on sparc64.  It also has another timeout:
running subset fuzzer against 
../../../test/fuzzing/fonts/clusterfuzz-testcase-minimized-hb-subset-fuzzer-5763024094232576
error: timeout, 
failed for 
../../../test/fuzzing/fonts/clusterfuzz-testcase-minimized-hb-subset-fuzzer-5763024094232576

Regards,
Dave Anglin

-- System Information:
Debian Release: bullseye/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

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

Bug#944211: id-utils: FTBFS on all 32-bit archs

Source: id-utils
Version: 4.6.21+20171216ss6cdfd-1
Severity: serious
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal

Hi Bradley,

The latest upstream version of id-utils has been stuck in unstable for over
200 days, because it has regressed its buildability on 32-bit architectures:

[...]
  CC   walker.o
walker.c:1139:20: error: conflicting types for 'dev_ino_hash_1'
 DEV_INO_HASH_DEFUN(dev_ino_hash_1, xform_NOP)
^~
walker.c:1116:1: note: in definition of macro 'DEV_INO_HASH_DEFUN'
 FN_NAME (void const *x)   \
 ^~~
walker.c:77:22: note: previous declaration of 'dev_ino_hash_1' was here
 static unsigned long dev_ino_hash_1 (void const *key);
  ^~
[...]

  
(https://buildd.debian.org/status/fetch.php?pkg=id-utils=armhf=4.6.21%2B20171216ss6cdfd-1=1549776380=0)

If upstream is taking the position that this package should no longer be
built on 32-bit archs, you should ask the ftp team to remove the old
binaries on these architectures.  Otherwise, you have a serious build
regression in this version of the package.

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


signature.asc
Description: PGP signature

Bug#944210: aqbanking-tools: Add note about rename settings to settings6

2019-11-05 Thread Sandro Knauß

Package: aqbanking-tools
Version: 5.99.43beta-1
Severity: important

Hey,

the version 5.99.43 is already using the new AqBanking6 settings layout.
In order to reuse old settings like accounts etc. you need to rename the
settings folders. Like it is described at this page:

https://www.aquamaniac.de/rdm/projects/aqbanking/wiki/AqBanking6

Please add a section in NEWS.Debian to inform unsers, that it is needed
to copy the settings, if they want to reuse anything.

Something like this:

AqBanking6 can reuse the configuration from AqBanking5 in a semi automatic way.
To trigger this reuse, you need to copy those data:

cd ~/.aqbanking
mkdir -p settings6
cp -r settings/* settings6

AqBanking6 will use only the new directory "settings6". This means, that it
is possible to use apps, that use ApBanking5 (still using the
"settings" directory) in parallel with those that use AqBanking6.

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

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

Versions of packages aqbanking-tools depends on:
ii  libaqbanking43   5.99.43beta-1
ii  libc62.29-3
ii  libgwenhywfar78  4.99.24rc8-1

aqbanking-tools recommends no packages.

Versions of packages aqbanking-tools suggests:
pn  gwenhywfar-tools  

-- no debconf information

Bug#944192: python3-h5py: 'import h5py' produces Open MPI message to stderr

2019-11-05 Thread Jameson Graef Rollins

FYI downgrading to 2.8.0-3 from stable make the message go away, so it
appears to actually be something in the newer 2.10.0 release.

Thanks.

jamie.

Bug#943891: umoci: autopkgtest regression: bug in the autopkgtest-pkg-go

2019-11-05 Thread Dmitry Smirnov

On Monday, 4 November 2019 8:03:14 AM AEDT Paul Gevers wrote:
> > On 02-11-2019 08:31, Dmitry Smirnov wrote:
> > I suspect a bug in autopkgtest as I don't see why would
> > that particular command fail.
> 
> Do you mean autodep8 here? I don't see how autopkgtest could be to
> blame, but please enlighten me.

Well, I was right and the problem is not in the "umoci" package indeed.

Yesterday I've uploaded a small improvement [1] to "go generate" invocation
and it exposed wrongdoing in the "autopkgtest-pkg-go".

As you can see in the following fragment of the latest CI log [2],
"vendor" part of the source is absent when "override_dh_auto_build" is
executed so "cd" command fails:

cd _build/src/github.com/openSUSE/umoci/vendor/ \
&& GO111MODULE=off go generate -v ./...
/bin/sh: 1: cd: can't cd to _build/src/github.com/openSUSE/umoci/vendor/
make[1]: *** [debian/rules:12: override_dh_auto_build] Error 2

Apparently this is happening because "override_dh_auto_configure"
(not defined in my package!) removes "vendor" tree from source.

Note that build system have no such problem as the package builds
successfully:

  https://buildd.debian.org/status/package.php?p=umoci

Frustratingly I was not able to locate where "autopkgtest-pkg-go"
is defined. I've checked "apt-cache search", "apt-file search",
Debian wiki, Golang team at Salsa and few other places.

Unless someone fix "autopkgtest-pkg-go" I see no other option
but to remove "Testsuite: autopkgtest-pkg-go" from "umoci".

[1]: https://salsa.debian.org/go-team/packages/umoci/commit/30f60ae3
[2]: https://ci.debian.net/data/autopkgtest/testing/amd64/u/umoci/3337341/log.gz

-- 
Regards,
 Dmitry Smirnov.

---

Any fool can know. The point is to understand.
-- Albert Einstein

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

Bug#944208: thunderbird warns addMetadata: Add-on wetrans...@extensions.thunderbird.net is invalid (NS_ERROR_FILE_TARGET_DOES_NOT_EXIST)

Control: affects 944208 + src:enigmail

This produces noise on the enigmail test suite, so i'm marking it as
"affects" enigmail.

On Tue 2019-11-05 18:01:16 -0500, Daniel Kahn Gillmor wrote:
> When trying to set up a temporary testing profile with thunderbird on an
> otherwise clean system, that i want to not access the network, i see
> nasty error messages on stderr:

An even simpler reproducer to generate the warnings:

x=$(mktemp -d profdir.XX)
printf 'user_pref("browser.dom.window.dump.enabled", true);\n' > 
"$x/prefs.js"
thunderbird --headless --profile "$(pwd)/$x"

hope this is useful,

 --dkg

Bug#793354: ITP: pytest-services -- collection of fixtures and utility functions for py.test

2019-11-05 Thread Pierre-Elliott Bécue

Control: owner -1
Control: retitle -1 ITP: pytest-services -- collection of fixtures and utility 
functions for py.test

Le jeudi 23 juillet 2015 à 08:40:11+0200, Daniel Stender a écrit :
> Package: wnpp
> Severity: wishlist
> Owner: Daniel Stender 
> 
> * Package name: pytest-services
>   Version : 1.1.3
>   Upstream Author : Anatoly Bubenkov 
> * URL : https://github.com/pytest-dev/pytest-services
> * License : Expat
>   Programming Lang: Python
>   Description : collection of fixtures and utility functions for py.test
> 
> Another item from the pytest-dev team to enrich the py.test plugin collection 
> in
> Debian. This a collection of basic infrastructure and service fixtures and 
> utilites functions for writing test suites for py.test, please see the Github 
> page for details. The resulting binaries are going to be 
> python{,3}-pytest-services.

Cheers.

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#944209: thunderbird warning on shutdown: JavaScript error: chrome://messenger/content/mailWindow.js, line 226: TypeError: messagepane.docShell is null

Package: thunderbird
Version: 1:68.2.1-1
Control: affects -1 + jsunit enigmail

I'm using jsunit to test enigmail and when i start up thunderbird using
jsunit with a simple test, it terminates with a strange warning.

(i'm omitting warnings from wetransfer, which happen at startup, and are
covered in #944208):

here's the setup:

x=$(mktemp -d profdir.XX)
touch main.js
cat > "$x/prefs.js" < "$x/extensions/jsu...@enigmail.net"
thunderbird --headless --profile "$(pwd)/$x"

and the output is:

JSUnit: startup
JSUnit starting tests
Starting JS unit tests main.js


FINAL STATS

TestResult: executed : 0
TestResult: succeeded: 0
TestResult: failed   : 0
JavaScript error: chrome://messenger/content/mailWindow.js, line 226: 
TypeError: messagepane.docShell is null


This happens even if i don't use --headless.

It's possible that the error resides in something jsunit is doing, but
i'm not sure of that, or how i would debug it.

--dkg


signature.asc
Description: PGP signature

Bug#892907: ITP: python-pytest-vcr -- pytest plugin for managing python-vcr cassettes

2019-11-05 Thread Craig Small

Hi,
  Thanks for packaging this, it will help with some other packages I have.
No need to add me to the uploaders, the main thing is the package is in the
archive.

 - Craig


On Wed, 6 Nov 2019 at 10:11, Pierre-Elliott Bécue  wrote:

> Le mercredi 14 mars 2018 à 22:28:14+1100, Craig Small a écrit :
> > Package: wnpp
> > Severity: wishlist
> > Owner: Craig Small 
> >
> > * Package name: python-pytest-vcr
> >   Version : 0.3.0
> >   Upstream Author : Tomasz Kontusz
> > * URL : https://pypi.python.org/pypi/pytest-vcr
> > * License : MIT
> >   Programming Lang: Python
> >   Description : pytest plugin for managing python-vcr cassettes
> >
> > Allows pytest-runner tests to use a simple decoration for their
> > python-vcr tests. Requires python-pytest and python-vcr which
> > are both already packaged.
> >
> > This is required for testing the Mastodon python module which
> > I am also going to ITP.
> >
> > While I can maintain it, I excpect this will form under the DPMT
> > and use their salsa project.
>
> Hi Craig,
>
> I created a salsa repo and packaged the thing. Do you wish me to add you
> to uploaders?
>
> With best regards,
>
> --
> Pierre-Elliott Bécue
> GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
> It's far easier to fight for one's principles than to live up to them.
>

Bug#892907: ITP: python-pytest-vcr -- pytest plugin for managing python-vcr cassettes

2019-11-05 Thread Pierre-Elliott Bécue

Le mercredi 14 mars 2018 à 22:28:14+1100, Craig Small a écrit :
> Package: wnpp
> Severity: wishlist
> Owner: Craig Small 
> 
> * Package name: python-pytest-vcr
>   Version : 0.3.0
>   Upstream Author : Tomasz Kontusz
> * URL : https://pypi.python.org/pypi/pytest-vcr
> * License : MIT
>   Programming Lang: Python
>   Description : pytest plugin for managing python-vcr cassettes
> 
> Allows pytest-runner tests to use a simple decoration for their
> python-vcr tests. Requires python-pytest and python-vcr which
> are both already packaged.
> 
> This is required for testing the Mastodon python module which
> I am also going to ITP.
> 
> While I can maintain it, I excpect this will form under the DPMT
> and use their salsa project.

Hi Craig,

I created a salsa repo and packaged the thing. Do you wish me to add you
to uploaders?

With best regards,

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#367515: Bug#749991: debian-installer: Wrong kernel in debian-installer package

Control: tags 749991 + pending
Control: tags 367515 + pending


Ben Hutchings  wrote:
> On Tue, 2019-11-05 at 22:17 +0100, Holger Wansing wrote:
> [...]
> > I just noticed that the relevant message currently appears with netinst 
> > image,
> > too (because build badly broken).
> > 
> > So, maybe we should not restrict the above proposed changing to the 
> > "netboot"
> > installation method?
> > (means: skipping the "check if you are using an up-to-date netboot image" 
> > part)
> 
> That seems reasonable.

Ok.

Now committed.

Tagging bugs as pending


Holger


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

Bug#944208: thunderbird warns addMetadata: Add-on wetrans...@extensions.thunderbird.net is invalid (NS_ERROR_FILE_TARGET_DOES_NOT_EXIST)

Package: thunderbird
Version: 1:68.2.1-1

When trying to set up a temporary testing profile with thunderbird on an
otherwise clean system, that i want to not access the network, i see
nasty error messages on stderr:

0 dkg@sid:~$ x=$(mktemp -d profdir.XX)
0 dkg@sid:~$ cat prefs.js 
user_pref("browser.dom.window.dump.enabled", true);
user_pref("extensions.autoDisableScopes", 14);
user_pref("extensions.update.enabled", false);
user_pref("lightweightThemes.update.enabled", false);
user_pref("extensions.blocklist.enabled", false);
user_pref("browser.search.update", false);
user_pref("toolkit.telemetry.prompted", false);
user_pref("toolkit.telemetry.rejected", true);
user_pref("toolkit.telemetry.enabled", false);
0 dkg@sid:~$ cp prefs.js $x/prefs.js
0 dkg@sid:~$ printf '{"created":%d000}' "$(date '+%s')" >"$x/times.json"
0 dkg@sid:~$ thunderbird --headless --profile "$(pwd)/$x"
*** You are running in headless mode.
1572994320282   addons.xpi  WARNCan't get modified time of 
/usr/lib/thunderbird/features/wetrans...@extensions.thunderbird.net.xpi
1572994320332   addons.xpi-utilsWARNaddMetadata: Add-on 
wetrans...@extensions.thunderbird.net is invalid: [Exception... "Component 
returned failure code: 0x80520006 (NS_ERROR_FILE_TARGET_DOES_NOT_EXIST) 
[nsIFile.isFile]"  nsresult: "0x80520006 (NS_ERROR_FILE_TARGET_DOES_NOT_EXIST)" 
 location: "JS frame :: resource://gre/modules/addons/XPIInstall.jsm :: get :: 
line 235"  data: no] Stack trace: 
get()@resource://gre/modules/addons/XPIInstall.jsm:235
syncLoadManifest()@resource://gre/modules/addons/XPIInstall.jsm:745
addMetadata()@resource://gre/modules/addons/XPIDatabase.jsm:2711
processFileChanges()@resource://gre/modules/addons/XPIDatabase.jsm:3152
checkForChanges()@resource://gre/modules/addons/XPIProvider.jsm:2946
startup()@resource://gre/modules/addons/XPIProvider.jsm:2406
callProvider()@resource://gre/modules/AddonManager.jsm:213
_startProvider()@resource://gre/modules/AddonManager.jsm:649
startup()@resource://gre/modules/AddonManager.jsm:873
startup()@resource://gre/modules/AddonManager.jsm:3469
observe()@resource://gre/modules/addonManager.js:70
1572994320333   addons.xpi-utilsWARNCould not uninstall invalid 
item from locked install location
^C
130 dkg@sid:~$

I'm assuming that the wetransfer extension isn't being installed by
default (which seems reasonable to me given the dubiousness of the
source code, e.g. [0]).

However, if it's not installed by default, something is referencing it
anyway, and that reference should probably be patched out too to avoid
these warnings.

  --dkg

[0] 
https://sources.debian.org/src/thunderbird/1:68.2.1-1/comm/mail/components/cloudfile/wetransfer/background/background.js/?hl=16#L19


signature.asc
Description: PGP signature

Bug#943986: wrong shared linkage position of mv's library dependency

2019-11-05 Thread David Frey

On Mon, Nov 04, 2019 at 08:17:33AM -0500, Michael Stone wrote:
> On Sat, Nov 02, 2019 at 12:51:41AM +0100, David Frey wrote:
> > cp and mv have a runtime linkage to libacl and libattr which are
> > installed in /usr/lib/x86_64-linux-gnu/.
> > 
> > This means that a single-user booted system without mounted /usr,
> > is not able to cp or mv files!
> > 
> > Either the dependancy should be dropped, or the libacl and libattr
> > shared libraries should be moved into /lib.
> 
> I don't believe that operating without /usr is a current design goal for
> debian.

In my opinion it should be. It is very useful for system repair and restore.

>From hier(7):

   /bin   This directory contains executable programs which are needed  in
  single user mode and to bring the system up or repair it.

...

   /lib   This  directory should hold those shared libraries that are nec‐
  essary to boot the system and to run the commands  in  the  root
  filesystem.

Keyword is *run* the commands.

Thanks,
  David

reopen 943986

Bug#367515: Bug#749991: debian-installer: Wrong kernel in debian-installer package

2019-11-05 Thread Ben Hutchings

On Tue, 2019-11-05 at 22:17 +0100, Holger Wansing wrote:
[...]
> I just noticed that the relevant message currently appears with netinst image,
> too (because build badly broken).
> 
> So, maybe we should not restrict the above proposed changing to the "netboot"
> installation method?
> (means: skipping the "check if you are using an up-to-date netboot image" 
> part)

That seems reasonable.

Ben.

-- 
Ben Hutchings
If God had intended Man to program,
we'd have been born with serial I/O ports.




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

Bug#944129: arp-scan: not returning any results

2019-11-05 Thread Marcos Fouces

Hello

I just uploaded a new release of arp-scan to git [0]. I tested it and
it works well on my machine (Debian testing).

Could some DD review and upload the package?

Greetings, 
Marcos

[0] https://salsa.debian.org/pkg-security-team/arp-scan



El lun, 04-11-2019 a las 18:42 +0100, Reiner Herrmann escribió:
> Package: arp-scan
> Version: 1.9.5-1
> Severity: serious
> Tags: fixed-upstream
> 
> Dear maintainer,
> 
> arp-scan is no longer returning any results in Debian sid.
> 
> > # arp-scan 10.0.0.0/24
> > Interface: wlan0, datalink type: EN10MB (Ethernet)
> > Starting arp-scan 1.9.5 with 256 hosts (
> > https://github.com/royhills/arp-scan)
> > 
> > 14 packets received by filter, 0 packets dropped by kernel
> > Ending arp-scan 1.9.5: 256 hosts scanned in 2.031 seconds (126.05
> > hosts/sec). 0 responded
> 
> With wireshark I can actually see arp replies (and it sounds like
> they
> were also received ("14 packets received")),
> With another machine that is running buster I can still see the
> results, so it could have been introduced by a different libpcap
> version?
> 
> After noticing that the bug has also been filed in Ubuntu [0],
> I also tested the version from git and got it running successfully.
> This is the first commit at which it is returning results again: [1].
> It is contained in the new upstream release 1.9.6.
> 
> Kind regards,
>   Reiner
> 
> [0] https://bugs.launchpad.net/ubuntu/+source/arp-scan/+bug/1849740
> [1] https://github.com/royhills/arp-scan/commit/8513a18

Bug#944207: d-i netinst image with firmware: should NOT be labeled "Official amd64 NETINST" image

Package: debian-cd
X-Debbugs-CC: debian-b...@lists.debian.org


Discovered with image "firmware-10.1.0-amd64-netinst.iso"
from 
https://cdimage.debian.org/cdimage/unofficial/non-free/images-including-firmware/10.1.0+nonfree/amd64/iso-cd/

That image is labeled 
» Debian GNU/Linux 10.1.0 "Buster - Official amd64 NETINST 20190908-01:08" «

Should be something like
"UNOFFICIAL netinst with firmware" or the like, right?


Holger


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

Bug#943936: supervisor: Build-depends on python3-all but should only need python3

On Tue, Nov 05, 2019 at 09:53:48PM +, Samuel Henrique wrote:
> Hello Steve,

> > The only reason I noticed this is because python3.8 has been added as a
> > supported, non-default version of python3 in Ubuntu, and supervisor
> > 4.0.4 was not compatible with python3.8.  I'd suggest the attach patch,
> > to avoid the build failing in the future on build-time tests that are
> > not relevant to the functioning of the binary package.

> I see that you decided to upload 4.1.0u1 to Ubuntu before syncing 4.1.0-1
> from Debian, if you look at the upstream changelog, you will notice that
> 4.1.0 solved some python 3.8 issue, did you check if this solved the
> compatibility issue you detected before doing the u1 upload?

> I would recommend checking if that's not the case, and if not, I would be
> happy to forward the issue (or maybe even patch it) upstream, so I
> appreciate if you could help me understand how the issue was detected and
> how I can navigate through Ubuntu's QA myself, I would gladly help
> reducing the delta between the distros.

Yes, 4.1.0 does build with python3.8, which I discovered in the process of
trying to prepare a fixed build for 4.0.4 (the current package at the time I
started).  I went ahead anyway with submitting this bug because I think it's
still per se correct to only build-depend on python3 here instead of
python3-all, regardless of whether the new upstream version happens to be
compatible with python3.8.

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


signature.asc
Description: PGP signature

Bug#943936: supervisor: Build-depends on python3-all but should only need python3

2019-11-05 Thread Samuel Henrique

Hello Steve,

> The only reason I noticed this is because python3.8 has been added as a
> supported, non-default version of python3 in Ubuntu, and supervisor 4.0.4
> was not compatible with python3.8.
> I'd suggest the attach patch, to avoid the build failing in the future on
build-time
> tests that are not relevant to the functioning of the binary package.

I see that you decided to upload 4.1.0u1 to Ubuntu before syncing 4.1.0-1
from
Debian, if you look at the upstream changelog, you will notice that 4.1.0
solved
some python 3.8 issue, did you check if this solved the compatibility issue
you
detected before doing the u1 upload?

I would recommend checking if that's not the case, and if not, I would be
happy
to forward the issue (or maybe even patch it) upstream, so I appreciate if
you
could help me understand how the issue was detected and how I can navigate
through Ubuntu's QA myself, I would gladly help reducing the delta between
the
distros.

Regards,

-- 
Samuel Henrique

Bug#944206: evolution: missing text in html mail (white text on white background)

2019-11-05 Thread Tess Jones

Source: evolution
Version: 3.30.5-1.1
Severity: important

Dear Maintainer,

I just upgraded from stretch to buster. Mails in evolution are now
displayed with most of the text missing if viewed in HTML mode. It
turns out that this is because most of the text is white on white.

The theme in use is 'high contrast'. The same effect is apparent if
'adwaita-dark' is chosen. All the other basic xfce themes seems to
work correctly. This theme has ben in use for a couple of years anddid notcause 
thisproblem on stretch.

I don't know if this should be deemed a bug in the themes or evolution?

So far as I can tell the high-contrast theme comes from the package
gnome-accessibility-themes, which is installed and there are files under 
/usr/share/themes/HighContrast (gtk-2.0/gtkrc and gtk-3.0/gtk.rss and 
index.theme

One thing I notice is that there are many more theme files in
/usr/share/themes than appear in the 'Appearance' dialog. Not sure if
that's relevant.

Any ideas how to debug or fix this, and why it broke inthe upgrade?

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

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

Bug#560327:

2019-11-05 Thread feliicitas loupez

 Hello Dear,

My name is Felicitas Lopez, I have a friendly feeling in you when I saw
your profile, so I decided to leave a message for you. if it Touches you to
be a friend you can write back to me. so that I will know more about you
and introduce my self to you very well. I believe we can start from here to
know each other better. Hoping to read your mail soon, thanks, I'm waiting
for your reply

Regards,
Sgt Felicitas Lopez

Bug#367515: Bug#749991: debian-installer: Wrong kernel in debian-installer package

Hi,

Holger Wansing  wrote:
> That looks reasonable.
> I have prepared a proposal for this:
> 
> 
>  snip ===
> 
> diff --git a/debian/anna.templates b/debian/anna.templates
> index 66677ee..3709584 100644
> --- a/debian/anna.templates
> +++ b/debian/anna.templates
> @@ -66,14 +66,14 @@ Template: anna/no_kernel_modules
>  Type: boolean
>  Default: false
>  # :sl2:
> -_Description: Continue the install without loading kernel modules?
> +_Description: No kernel modules found
>   No kernel modules were found. This probably is due to a mismatch between
>   the kernel used by this version of the installer and the kernel version
>   available in the archive.
>   .
> - If you're installing from a mirror, you can work around this problem by
> - choosing to install a different version of Debian. The install will probably
> - fail to work if you continue without kernel modules.
> + You should make sure that your installation image is current (check if you
> + are using an up-to-date netboot image), or - if that's the case - try a
> + different mirror, preferably deb.debian.org.
>  
>  Template: anna/retriever
>  Type: string

I just noticed that the relevant message currently appears with netinst image,
too (because build badly broken).

So, maybe we should not restrict the above proposed changing to the "netboot"
installation method?
(means: skipping the "check if you are using an up-to-date netboot image" part)


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

Bug#609730: kannel: Kannel on ARM based SheevaPlug rises PANIC in gwlib

2019-11-05 Thread Chris Hofstaedtler

* Vladimir Mach  [191105 20:57]:
> I am trying to set up default installation of kannel package, but if I try to 
> start it I always get following error (with or without any parameters).
> 
> # /usr/sbin/bearerbox
> 2011-01-11 23:06:21 [14196] [0] PANIC: gwlib/octstr.c:2479: seems_valid_real: 
> Assertion `immutables_init' failed.

Not sure what you exactly expect to happen, but without any further
backtrace it's impossible to debug from here.

As this is also a really old bug report, could you either try to
reproduce it with a current version of Kannel? 

Otherwise I'll have to close this report soon.

Thanks,
Chris

Bug#944205: spacefm: 100% cpu when creating files/folders

2019-11-05 Thread Jack Barns

Package: spacefm
Version: 1.0.6-4
Severity: normal

Dear Maintainer,

Different characters and symbols in folder names will freeze and spike
the cpu usage to 100% for spacefm. The only change I can see is that a
horizontal bar gets added to the path field. (To see the horizontal
bar do steps: 1, 2.5 but don't go inside
"l_daacc_this_iz_am_tomiio_oww_-Ro" instead: Right click on it >
Rename and look at the path field.)

Some characters are interchangeable in the folder name:
a = o, u, e
d = q, b, v
_ = z, L, c

In the quick testing I did, the following symbols seem to be needed
to "push" it so it not only wraps (in the path field) but also gets
the horizontal bar:
-, w, #, ^, [, ], (, ), !

Steps to reproduce:
1. Create this folder path and cd into atatlza:
/home/jack/Downloads/abcdef_gh_1234a/123/atatlza/

2. Right click > New > Folder and paste the following:
l_daacc_this_iz_am_tomiio_oww_-Ro

You should notice that spacefm has frozen and top/htop report it
using 100% cpu.

Alternatively you can paste the full folder path into the path field
and see the same results.
/home/jack/Downloads/abcdef_gh_1234a/123/atatlza/l_daacc_this_iz_am_tomiio_oww_-Ro

2.5. Making the folder elsewhere and moving it in:
Make the "l_daacc_this_iz_am_tomiio_oww_-Ro" folder then move it
inside atatlza. Go inside and Right click > New > Folder and get the
same results as step 2.

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

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

Versions of packages spacefm depends on:
ii  desktop-file-utils0.24-1
ii  e2fsprogs 1.45.4-1
ii  libc6 2.29-2
ii  libcairo2 1.16.0-4
ii  libffmpegthumbnailer4v5   2.1.1-0.2+b1
ii  libgdk-pixbuf2.0-02.40.0+dfsg-1
ii  libglib2.0-0  2.62.2-1
ii  libgtk2.0-0   2.24.32-4
ii  libpango-1.0-01.42.4-7
ii  libpangocairo-1.0-0   1.42.4-7
ii  libstartup-notification0  0.12-6
ii  libudev1  242-7
ii  libx11-6  2:1.6.8-1
ii  shared-mime-info  1.10-1
ii  spacefm-common1.0.6-4

Versions of packages spacefm recommends:
ii  udisks2  2.8.4-1

Versions of packages spacefm suggests:
ii  dbus1.12.16-2
ii  eject   2.1.5+deb1+cvs20081104-14+b1
pn  gksu
pn  ktsuss  
ii  lsof4.93.2+dfsg-1
ii  sshfs   2.10+repack-2+b1
pn  udevil  
ii  wget1.20.3-1+b2

-- no debconf information

Bug#944204: coq: Updating ocaml to 4.08.1-2 removes coq

2019-11-05 Thread Witold Baryluk

Source: coq
Version: 8.9.1-1
Severity: important

Dear Maintainer,

root@debian:~# apt dist-upgrade -V
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
   libdevel-globaldestruction-perl (0.14-1)
   libfindlib-ocaml (1.8.1-1+b1)
   libfindlib-ocaml-dev (1.8.1-1+b1)
   ocaml-findlib (1.8.1-1+b1)
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
   coq (8.9.1-1)
   coq-theories (8.9.1-1)
   libcoq-ocaml (8.9.1-1)
The following NEW packages will be installed:
   ocaml-man (4.08.1-2)
The following packages will be upgraded:
   bamfdaemon (0.5.4-1 => 0.5.4-2)
   bittwist (2.0-11 => 2.0-12)
   bruteforce-salted-openssl (1.4.2-1 => 1.4.2-2)
   cewl (5.4.4.2-1 => 5.4.4.2-2)
   chromium (76.0.3809.100-1 => 78.0.3904.87-1)
   chromium-common (76.0.3809.100-1 => 78.0.3904.87-1)
   chromium-l10n (76.0.3809.100-1 => 78.0.3904.87-1)
   chromium-sandbox (76.0.3809.100-1 => 78.0.3904.87-1)
   gir1.2-bamf-3 (0.5.4-1 => 0.5.4-2)
   ledit (2.04-3 => 2.04-4)
   libbamf3-2 (0.5.4-1 => 0.5.4-2)
   libfindlib-ocaml (1.8.1-1 => 1.8.1-1+b1)
   libfindlib-ocaml-dev (1.8.1-1 => 1.8.1-1+b1)
   libhivex0 (1.3.18-1+b2 => 1.3.18-1+b3)
   libhpmud0 (3.19.8+dfsg0-7+b1 => 3.19.11+dfsg0-1)
   libwin-hivex-perl (1.3.18-1+b2 => 1.3.18-1+b3)
   libz3-4 (4.8.6-2 => 4.8.6-2+b1)
   libz3-4:i386 (4.8.6-2 => 4.8.6-2+b1)
   libz3-4-dbgsym (4.8.6-2 => 4.8.6-2+b1)
   libz3-dev (4.8.6-2 => 4.8.6-2+b1)
   ocaml (4.05.0-12 => 4.08.1-2)
   ocaml-base (4.05.0-12 => 4.08.1-2)
   ocaml-base-nox (4.05.0-12 => 4.08.1-2)
   ocaml-compiler-libs (4.05.0-12 => 4.08.1-2)
   ocaml-interp (4.05.0-12 => 4.08.1-2)
   ocaml-nox (4.05.0-12 => 4.08.1-2)
   printer-driver-hpcups (3.19.8+dfsg0-7+b1 => 3.19.11+dfsg0-1)
   printer-driver-hpijs (3.19.8+dfsg0-7+b1 => 3.19.11+dfsg0-1)
   printer-driver-postscript-hp (3.19.8+dfsg0-7+b1 => 3.19.11+dfsg0-1)
29 upgraded, 1 newly installed, 3 to remove and 0 not upgraded.
Need to get 0 B/270 MB of archives.
After this operation, 335 MB disk space will be freed.
Do you want to continue? [Y/n] 
(Reading database ... 637762 files and directories currently installed.)
Removing coq (8.9.1-1) ...
Removing coq-theories (8.9.1-1) ...
Removing libcoq-ocaml (8.9.1-1) ...
(Reading database ... 633168 files and directories currently installed.)
...
...


Not sure if coq needs to target specific version of ocaml and it is
correct (and I shoudl simply wait), or maybe dependencies are specified
incorrect in coq package.


Best regards,
Witold



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

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

Bug#870641:

2019-11-05 Thread dinar qurbanov

i have found, with " site:https://bugs.debian.org/ wake black " and "
site:https://lists.debian.org/debian-user/ wake black " in google,
some other bugs that may be related: 680586, 773913, 882027, 886302.
and also some mailing list discussions:
https://lists.debian.org/debian-user/2015/09/msg00145.html ,
https://lists.debian.org/debian-user/2018/09/msg00033.html .

Bug#944188: /etc/msmtprc password disclosure

2019-11-05 Thread Simon Deziel

On 2019-11-05 3:30 p.m., Jakub Wilk wrote:
> * Simon Deziel , 2019-11-05, 10:02:
>> Having /etc/msmtprc group readable is AFAIK, a "debianism".
> 
> This is my understanding, too.
> 
>> I don't know if upstream endorses this method of restricting access to
>> the default account's password.
> 
> I don't belive they do.
> 
>> That said, I think it would be feasible for msmtp to obfuscate the
>> AUTH line when the UID/GID do not match the EUID/EGID and the config
>> file used it not world-readable.
> 
> That wouldn't be sufficient. The attacker could run:
> 
>   $ msmtp --proxy-host=$HOST --proxy-port=$PORT --tls=off --auth=plain
> nob...@example.org < /dev/null
> 
> to make msmtp send unencrypted password to a proxy server of the
> attacker's choice.

That's an interesting variation because it also defeat other ways of
concealing the password from users (like a secret helper to decrypt it).

Maybe the proxy directives provided as argument or env vars could be
ignored when the UID/GID do not match the EUID/EGID.

Simon

Bug#944126: ocaml-nox: Files overwrite /usr/lib/ocaml/bigarray.cmi in ocaml-base-nox package

2019-11-05 Thread Witold Baryluk

Package: ocaml-nox
Followup-For: Bug #944126


Same here when updating from 4.05.0-12 to 4.08.1-2 :

root@debian:~# apt dist-upgrade -V
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
   libdevel-globaldestruction-perl (0.14-1)
   libfindlib-ocaml (1.8.1-1+b1)
   libfindlib-ocaml-dev (1.8.1-1+b1)
   ocaml-findlib (1.8.1-1+b1)
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
   coq (8.9.1-1)
   coq-theories (8.9.1-1)
   libcoq-ocaml (8.9.1-1)
The following NEW packages will be installed:
   ocaml-man (4.08.1-2)
The following packages will be upgraded:
   bamfdaemon (0.5.4-1 => 0.5.4-2)
   bittwist (2.0-11 => 2.0-12)
   bruteforce-salted-openssl (1.4.2-1 => 1.4.2-2)
   cewl (5.4.4.2-1 => 5.4.4.2-2)
   chromium (76.0.3809.100-1 => 78.0.3904.87-1)
   chromium-common (76.0.3809.100-1 => 78.0.3904.87-1)
   chromium-l10n (76.0.3809.100-1 => 78.0.3904.87-1)
   chromium-sandbox (76.0.3809.100-1 => 78.0.3904.87-1)
   gir1.2-bamf-3 (0.5.4-1 => 0.5.4-2)
   ledit (2.04-3 => 2.04-4)
   libbamf3-2 (0.5.4-1 => 0.5.4-2)
   libfindlib-ocaml (1.8.1-1 => 1.8.1-1+b1)
   libfindlib-ocaml-dev (1.8.1-1 => 1.8.1-1+b1)
   libhivex0 (1.3.18-1+b2 => 1.3.18-1+b3)
   libhpmud0 (3.19.8+dfsg0-7+b1 => 3.19.11+dfsg0-1)
   libwin-hivex-perl (1.3.18-1+b2 => 1.3.18-1+b3)
   libz3-4 (4.8.6-2 => 4.8.6-2+b1)
   libz3-4:i386 (4.8.6-2 => 4.8.6-2+b1)
   libz3-4-dbgsym (4.8.6-2 => 4.8.6-2+b1)
   libz3-dev (4.8.6-2 => 4.8.6-2+b1)
   ocaml (4.05.0-12 => 4.08.1-2)
   ocaml-base (4.05.0-12 => 4.08.1-2)
   ocaml-base-nox (4.05.0-12 => 4.08.1-2)
   ocaml-compiler-libs (4.05.0-12 => 4.08.1-2)
   ocaml-interp (4.05.0-12 => 4.08.1-2)
   ocaml-nox (4.05.0-12 => 4.08.1-2)
   printer-driver-hpcups (3.19.8+dfsg0-7+b1 => 3.19.11+dfsg0-1)
   printer-driver-hpijs (3.19.8+dfsg0-7+b1 => 3.19.11+dfsg0-1)
   printer-driver-postscript-hp (3.19.8+dfsg0-7+b1 => 3.19.11+dfsg0-1)
29 upgraded, 1 newly installed, 3 to remove and 0 not upgraded.
Need to get 0 B/270 MB of archives.
After this operation, 335 MB disk space will be freed.
Do you want to continue? [Y/n] 
(Reading database ... 637762 files and directories currently installed.)
Removing coq (8.9.1-1) ...
Removing coq-theories (8.9.1-1) ...
Removing libcoq-ocaml (8.9.1-1) ...
(Reading database ... 633168 files and directories currently installed.)
Preparing to unpack .../00-bamfdaemon_0.5.4-2_amd64.deb ...
Unpacking bamfdaemon (0.5.4-2) over (0.5.4-1) ...
Preparing to unpack .../01-libbamf3-2_0.5.4-2_amd64.deb ...
Unpacking libbamf3-2:amd64 (0.5.4-2) over (0.5.4-1) ...
Preparing to unpack .../02-bittwist_2.0-12_amd64.deb ...
Unpacking bittwist (2.0-12) over (2.0-11) ...
Preparing to unpack .../03-bruteforce-salted-openssl_1.4.2-2_amd64.deb ...
Unpacking bruteforce-salted-openssl (1.4.2-2) over (1.4.2-1) ...
Preparing to unpack .../04-cewl_5.4.4.2-2_all.deb ...
Unpacking cewl (5.4.4.2-2) over (5.4.4.2-1) ...
Preparing to unpack .../05-chromium-l10n_78.0.3904.87-1_all.deb ...
Unpacking chromium-l10n (78.0.3904.87-1) over (76.0.3809.100-1) ...
Preparing to unpack .../06-chromium_78.0.3904.87-1_amd64.deb ...
Unpacking chromium (78.0.3904.87-1) over (76.0.3809.100-1) ...
Preparing to unpack .../07-chromium-common_78.0.3904.87-1_amd64.deb ...
Unpacking chromium-common (78.0.3904.87-1) over (76.0.3809.100-1) ...
Preparing to unpack .../08-chromium-sandbox_78.0.3904.87-1_amd64.deb ...
Unpacking chromium-sandbox (78.0.3904.87-1) over (76.0.3809.100-1) ...
Preparing to unpack .../09-gir1.2-bamf-3_0.5.4-2_amd64.deb ...
Unpacking gir1.2-bamf-3 (0.5.4-2) over (0.5.4-1) ...
Preparing to unpack .../10-ocaml-compiler-libs_4.08.1-2_amd64.deb ...
Unpacking ocaml-compiler-libs (4.08.1-2) over (4.05.0-12) ...
Preparing to unpack .../11-ocaml_4.08.1-2_amd64.deb ...
Unpacking ocaml (4.08.1-2) over (4.05.0-12) ...
Preparing to unpack .../12-libfindlib-ocaml-dev_1.8.1-1+b1_amd64.deb ...
Unpacking libfindlib-ocaml-dev (1.8.1-1+b1) over (1.8.1-1) ...
Preparing to unpack .../13-ocaml-nox_4.08.1-2_amd64.deb ...
Unpacking ocaml-nox (4.08.1-2) over (4.05.0-12) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-wDlzux/13-ocaml-nox_4.08.1-2_amd64.deb (--unpack):
 trying to overwrite '/usr/lib/ocaml/bigarray.cmi', which is also in package 
ocaml-base-nox 4.05.0-12
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Preparing to unpack .../14-ocaml-base_4.08.1-2_amd64.deb ...
Unpacking ocaml-base (4.08.1-2) over (4.05.0-12) ...
Preparing to unpack .../15-libfindlib-ocaml_1.8.1-1+b1_amd64.deb ...
Unpacking libfindlib-ocaml (1.8.1-1+b1) over (1.8.1-1) ...
Preparing to unpack .../16-ledit_2.04-4_all.deb ...
Unpacking ledit (2.04-4) over (2.04-3) ...
Preparing to unpack .../17-ocaml-base-nox_4.08.1-2_amd64.deb ...
Unpacking ocaml-base-nox (4.08.1-2) over (4.05.0-12) ...
dpkg: error processing archive

Bug#941853: crypt(3) should be provided by libxcrypt

2019-11-05 Thread Aurelien Jarno

On 2019-10-20 19:19, Aurelien Jarno wrote:
> On 2019-10-10 01:30, Marco d'Itri wrote:
> > On Oct 09, Aurelien Jarno  wrote:
> > 
> > > I have implemented the first option in the libxcrypt branch:
> > > 
> > > https://salsa.debian.org/glibc-team/glibc/tree/libxcrypt
> > And here you can see a tentative libxcrypt package: does it look right 
> > to you?
> > 
> 
> Sorry for the delay. I got a look at it, and all looks right.
> 

We have done a new upload of glibc into sid. I have just merged the
changes to the libxcrypt branch. You might want to update your branch by
adding 1 to the debian revision for the breaks/conflicts.


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


signature.asc
Description: PGP signature

Bug#944203: dpkg: error processing package wireguard (--configure):

2019-11-05 Thread Bhagwan Jha

Package: wireguard-dkms
module: wireguard

Please find the attached make.log file for your reference.

I have tried to fix out using this method but it's not worked.

*Tried Method*
# echo "deb http://deb.debian.org/debian/ unstable main" >
/etc/apt/sources.list.d/unstable.list

# printf 'Package: *\nPin: release a=unstable\nPin-Priority: 90\n' >
/etc/apt/preferences.d/limit-unstable
# apt update
# apt install wireguard

When I want to install wireguard it's throwing error for this also please
refer to make.log file.

Can you look into this and let me know if any thing required from my side.

Machine Information are as follows:-

1. Linux parrot 5.2.0-2parrot1-amd64 #1 SMP Debian 5.2.9-2parrot1
(2019-08-25) x86_64 GNU/Linux
2.
No LSB modules are available.
Distributor ID: Parrot
Description:Parrot GNU/Linux 4.7
Release:4.7
Codename: sid
DKMS make.log for wireguard-0.0.20191012 for kernel 5.2.0-2parrot1-amd64 (x86_64)
Tue 05 Nov 2019 02:44:06 PM EST
make: Entering directory '/usr/src/linux-headers-5.2.0-2parrot1-amd64'
CC [M] /var/lib/dkms/wireguard/0.0.20191012/build/main.o
CC [M] /var/lib/dkms/wireguard/0.0.20191012/build/noise.o
gcc-8: internal compiler error: Segmentation fault signal terminated program cc1
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
make[3]: *** [/usr/src/linux-headers-5.2.0-2parrot1-common/scripts/Makefile.build:284: /var/lib/dkms/wireguard/0.0.20191012/build/main.o] Error 4
make[3]: *** Waiting for unfinished jobs
CC [M] /var/lib/dkms/wireguard/0.0.20191012/build/device.o
gcc-8: internal compiler error: Segmentation fault signal terminated program cc1
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
CC [M] /var/lib/dkms/wireguard/0.0.20191012/build/peer.o
make[3]: *** [/usr/src/linux-headers-5.2.0-2parrot1-common/scripts/Makefile.build:284: /var/lib/dkms/wireguard/0.0.20191012/build/noise.o] Error 4
gcc-8: internal compiler error: Segmentation fault signal terminated program cc1
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
gcc-8: internal compiler error: Segmentation fault signal terminated program cc1
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
make[3]: *** [/usr/src/linux-headers-5.2.0-2parrot1-common/scripts/Makefile.build:284: /var/lib/dkms/wireguard/0.0.20191012/build/device.o] Error 4
make[3]: *** [/usr/src/linux-headers-5.2.0-2parrot1-common/scripts/Makefile.build:284: /var/lib/dkms/wireguard/0.0.20191012/build/peer.o] Error 4
make[2]: *** [/usr/src/linux-headers-5.2.0-2parrot1-common/Makefile:1610: _module_/var/lib/dkms/wireguard/0.0.20191012/build] Error 2
make[1]: *** [Makefile:179: sub-make] Error 2
make: *** [Makefile:8: all] Error 2
make: Leaving directory '/usr/src/linux-headers-5.2.0-2parrot1-amd64'

Bug#944188: /etc/msmtprc password disclosure

2019-11-05 Thread Jakub Wilk


* Simon Deziel , 2019-11-05, 10:02:

Having /etc/msmtprc group readable is AFAIK, a "debianism".


This is my understanding, too.

I don't know if upstream endorses this method of restricting access to 
the default account's password.


I don't belive they do.

That said, I think it would be feasible for msmtp to obfuscate the AUTH 
line when the UID/GID do not match the EUID/EGID and the config file 
used it not world-readable.


That wouldn't be sufficient. The attacker could run:

  $ msmtp --proxy-host=$HOST --proxy-port=$PORT --tls=off --auth=plain 
nob...@example.org < /dev/null

to make msmtp send unencrypted password to a proxy server of the 
attacker's choice.


--
Jakub Wilk

Bug#925703: gr-hpsdr: ftbfs with GCC-9

On Tue, Nov 05, 2019 at 09:20:43PM +0100, Paul Gevers wrote:
> Hi Steve,

> On 05-11-2019 21:02, Steve Langasek wrote:
> > Did it fail in the same way? I did test in a Debian sid environment before
> > closing, but I didn't record any details, so perhaps my environment was not
> > up to date in some other way.

> No, it did not, but the package was still FTBFS-ing, so closing the only
> FTBFS against the package suggested to me that the package could now be
> build, hence I reacted on it. I misunderstood your remark to mean that
> the gcc-9 issue was fixed but that in current sid, the FTBFS is still
> there, except for a different reason (I understood that the other issue
> was also fixed). So, we can close this one and reopen another if that
> makes people happy.

I didn't reproduce /any/ build failure of gr-hpsdr in my sid environment. 
But since it was using gcc-9 to build, and it didn't fail to build with a
gcc-9 problem, I was confident that this bug was fixed; and if there are
other problems, I think they should be separate bug reports.

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


signature.asc
Description: PGP signature

Bug#936207: biosig4c++: Python2 removal in sid/bullseye

However, after applying that patch, the package fails to build because:

 - it tries to invoke python, which is not present.  Fixed by setting
   PYTHON=python3 in MAKEOPTS from debian/rules.
 - the python3 pkgconfig handling is completely messed up in
   python/setup.py; it tries to find a pkgconfig file in the system
   directory (why, when it's part of the same source package we're just
   building right now?), and when it doesn't find it, under python3 it
   raises a different exception than ValueError, so the fallback code
   doesn't work.  And if I set PKG_CONFIG_PATH to point at the libbiosig.pc
   in the parent directory, it just fails later at linking time because ../
   isn't on the linker path.

I'm stopping my investigation there, it really looks like this needs some
upstream cleanup.

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


signature.asc
Description: PGP signature

Bug#925703: gr-hpsdr: ftbfs with GCC-9

2019-11-05 Thread Paul Gevers

Hi Steve,

On 05-11-2019 21:02, Steve Langasek wrote:
> Did it fail in the same way? I did test in a Debian sid environment before
> closing, but I didn't record any details, so perhaps my environment was not
> up to date in some other way.

No, it did not, but the package was still FTBFS-ing, so closing the only
FTBFS against the package suggested to me that the package could now be
build, hence I reacted on it. I misunderstood your remark to mean that
the gcc-9 issue was fixed but that in current sid, the FTBFS is still
there, except for a different reason (I understood that the other issue
was also fixed). So, we can close this one and reopen another if that
makes people happy.

Paul

signature.asc
Description: OpenPGP digital signature

Bug#944202: RFP: fonts-recursive -- Recursive Mono & Sans variable font family

2019-11-05 Thread Andrej Shadura

Package: wnpp
Severity: wishlist

* Package name: fonts-recursive
  Version : 1.022
  Upstream Author : Type
* URL : https://github.com/arrowtype/recursive
https://www.recursive.design/
* License : OFL-1.1
  Programming Lang: N/A
  Description : Recursive Mono & Sans variable font family

Recursive Mono & Sans is a variable type family built for better code &
UI. It is inspired by casual script signpainting, but designed primarily
to meet the needs of programming environments and application interfaces.

In programming, “recursion” is when a function calls itself, using its
own output as an input to yield powerful results. Recursive Mono was used
as a tool to help build itself: it was used to write Python scripts to
automate type production work and to generate specimen images, and it was
used in HTML, CSS, and JS to create web-based proofs & prototypes. Through
this active usage, Recursive Mono was crafted to be both fun to look at
as well as deeply useful for all-day work.

Recursive Sans borrows glyphs from its parent mono but adjusts the
widths of many key glyphs for comfortable readability. Its metrics are
superplexed – every style takes up the exact same horizontal space,
across all styles. In this 3-axis variable font, this allows for fluid
transitions between weight, slant, and “expression” (casual to strict
letterforms), all without text shifts or layout reflow. Not only does
this allow for new interactive possibilities in UI, but it also makes
for a uniquely fun typesetting experience.

Bug#944006: nginx-extras missing TLS1.3

2019-11-05 Thread Florent CARRÉ

Hi,

I use nginx-extras from buster (Debian official repository)

nginx version: nginx/1.14.2
built with OpenSSL 1.1.1c  28 May 2019 (running with OpenSSL 1.1.1d
10 Sep 2019)
TLS SNI support enabled
configure arguments: --with-cc-opt='-g -O2
-fdebug-prefix-map=/build/nginx-tBUzFN/nginx-1.14.2=.
-fstack-protector-strong -Wformat -Werror=format-security -fPIC
-Wdate-time -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-z,relro
-Wl,-z,now -fPIC' --prefix=/usr/share/nginx
--conf-path=/etc/nginx/nginx.conf
--http-log-path=/var/log/nginx/access.log
--error-log-path=/var/log/nginx/error.log
--lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid
--modules-path=/usr/lib/nginx/modules
--http-client-body-temp-path=/var/lib/nginx/body
--http-fastcgi-temp-path=/var/lib/nginx/fastcgi
--http-proxy-temp-path=/var/lib/nginx/proxy
--http-scgi-temp-path=/var/lib/nginx/scgi
--http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug
--with-pcre-jit --with-http_ssl_module --with-http_stub_status_module
--with-http_realip_module --with-http_auth_request_module
--with-http_v2_module --with-http_dav_module --with-http_slice_module
--with-threads --with-http_addition_module --with-http_flv_module
--with-http_geoip_module=dynamic --with-http_gunzip_module
--with-http_gzip_static_module --with-http_image_filter_module=dynamic
--with-http_mp4_module --with-http_perl_module=dynamic
--with-http_random_index_module --with-http_secure_link_module
--with-http_sub_module --with-http_xslt_module=dynamic
--with-mail=dynamic --with-mail_ssl_module --with-stream=dynamic
--with-stream_ssl_module --with-stream_ssl_preread_module
--add-dynamic-module=/build/nginx-tBUzFN/nginx-1.14.2/debian/modules/http-headers-more-filter
--add-dynamic-module=/build/nginx-tBUzFN/nginx-1.14.2/debian/modules/http-auth-pam
--add-dynamic-module=/build/nginx-tBUzFN/nginx-1.14.2/debian/modules/http-cache-purge
--add-dynamic-module=/build/nginx-tBUzFN/nginx-1.14.2/debian/modules/http-dav-ext
--add-dynamic-module=/build/nginx-tBUzFN/nginx-1.14.2/debian/modules/http-ndk
--add-dynamic-module=/build/nginx-tBUzFN/nginx-1.14.2/debian/modules/http-echo
--add-dynamic-module=/build/nginx-tBUzFN/nginx-1.14.2/debian/modules/http-fancyindex
--add-dynamic-module=/build/nginx-tBUzFN/nginx-1.14.2/debian/modules/nchan
--add-dynamic-module=/build/nginx-tBUzFN/nginx-1.14.2/debian/modules/http-lua
--add-dynamic-module=/build/nginx-tBUzFN/nginx-1.14.2/debian/modules/rtmp
--add-dynamic-module=/build/nginx-tBUzFN/nginx-1.14.2/debian/modules/http-uploadprogress
--add-dynamic-module=/build/nginx-tBUzFN/nginx-1.14.2/debian/modules/http-upstream-fair
--add-dynamic-module=/build/nginx-tBUzFN/nginx-1.14.2/debian/modules/http-subs-filter

Le mar. 5 nov. 2019 à 14:46, Thomas Ward  a écrit :
>
> Can you include the output of `nginx -V` please as well?  Part of TLS support 
> is having a version of NGINX that is compiled against an OpenSSL in the 
> repositories for the version of Debian you're using which supports TLS1.3, 
> but that may not be the case in all releases of Debian.
>
>
> Thomas
>
>
> On 11/2/19 1:15 PM, Florent CARRÉ wrote:
>
> Package: nginx-extras
> Version: 1.14.2-2+deb10u1
>
> When I modify to have exclusively TLS1.2 and TLS1.3, just TLS1.2 is available.
>
> Steps to reproduce :
> - switch to ssl_protocols TLSv1.2 TLSv1.3
> - restart nginx
> - curl -v --tlsv1.3 mydomain.com
>
> I obtain :
> * TLSv1.3 (OUT), TLS handshake, Client hello (1):
> * TLSv1.3 (IN), TLS alert, protocol version (582):
> * error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version
> * Closing connection 0
> curl: (35) error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert
> protocol version
>
> And it's available in openssl : openssl ciphers -v | grep " TLSv1\.3 "
> TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any  Au=any  Enc=AESGCM(256) Mac=AEAD
> TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any  Au=any
> Enc=CHACHA20/POLY1305(256) Mac=AEAD
> TLS_AES_128_GCM_SHA256  TLSv1.3 Kx=any  Au=any  Enc=AESGCM(128) Mac=AEAD
>
> Regards
>

Bug#907970: Bug #907970: Please stop using debiandoc-sgml (deprecated)

Control: tags -1 + pending


Osamu Aoki (4 Sep 2018):
> Package: debian-installer
> Version: 20180610
> Severity: normal
> Tags: patch
> 
> I am in process of dropping debiandoc-sgml.  So please convert
> partman-doc to DocBook XML with attached patch.

Just committed, thanks Osamu.
Tagging this bug as pending.


Holger

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

Bug#925703: gr-hpsdr: ftbfs with GCC-9

On Tue, Nov 05, 2019 at 08:40:14PM +0100, Paul Gevers wrote:
> Control: reopen -1
> Control: block -1 by 943965

> On Fri, 1 Nov 2019 14:11:32 -0700 Steve Langasek
>  wrote:
> > In resolving the gnuradio 3.8 transition in Ubuntu, I found that this build
> > failure no longer applies to gr-hpsdr, with no changes to that package's
> > source.  There is an unrelated failure that requires an update to
> > gnuradio-dev (missing dependency on libgmp-dev), but with that fixed,
> > gr-hpsdr builds fine in both Debian and Ubuntu with gcc 9.

> I did a binNMU two days ago, which failed on all archs. I guess the fix
> didn't land in Debian? If so, let's not have this bug closed. Or did I
> miss something?

Did it fail in the same way? I did test in a Debian sid environment before
closing, but I didn't record any details, so perhaps my environment was not
up to date in some other way.

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


signature.asc
Description: PGP signature

Bug#944056: i3-wm: i3 ignores system keyboard layouts

2019-11-05 Thread Vlastimil Zíma

Hi,

thanks for the reply. I'm referring to the used keyboard layout in general.
It mainly affects the text input, but since different layouts have
different keys on different positions it may also cause troubles with the
shortcuts as well.

Anyhow, I investigated the logs today into a greater detail and found the
following lines. At first, the keyboard loads correctly:

Nov  5 20:06:26 ziima /usr/lib/gdm3/gdm-x-session[11706]: (**) Option
"xkb_model" "pc105"
Nov  5 20:06:26 ziima /usr/lib/gdm3/gdm-x-session[11706]: (**) Option
"xkb_layout" "us,cz"
Nov  5 20:06:26 ziima /usr/lib/gdm3/gdm-x-session[11706]: (**) Option
"xkb_variant" ",qwerty"
Nov  5 20:06:26 ziima /usr/lib/gdm3/gdm-x-session[11706]: (**) Option
"xkb_options" "grp:alt_shift_toggle,grp_led:scroll,caps:none"

but this may mess that up:

Nov  5 20:06:36 ziima systemd[11420]: Stopped target GNOME Keyboard
handling.
Nov  5 20:06:36 ziima systemd[11420]: Stopping GNOME Keyboard handling...

Since I'm in transition to i3, I still have gnome shell installed and I
suspect it may cause the mess. Though I'm not sure why it tries to start,
when I launch i3.

Regards,
Vlastimil


út 5. 11. 2019 v 20:45 odesílatel Michael Stapelberg 
napsal:

> i3 is not involved in handling keys, only keyboard shortcuts.
>
> Are you saying that keybindings (such as Mod+2 to switch to workspace 2)
> you configured in the i3 config file are not working? Or are you referring
> to text input to applications, such as entering your name in a web form in
> Firefox?
>
> On Sun, Nov 3, 2019 at 3:09 PM Vlastimil Zima 
> wrote:
>
>> Package: i3-wm
>> Version: 4.17.1-1
>> Severity: normal
>> Tags: l10n
>>
>> Dear Maintainer,
>>
>> I'm trying to setup a i3, but I encountered a problem with keyboard
>> layout setup. Multiple layouts set up in /etc/default/keyboard are
>> ignored by i3 and only 'us' layout is available. On the other hand,
>> keyboard options are respected.
>>
>> I have in /etc/default/keyboard
>>
>> XKBLAYOUT="us,cz"
>> XKBVARIANT=",qwerty"
>> BACKSPACE="guess"
>> XKBMODEL="pc105"
>> XKBOPTIONS="grp:alt_shift_toggle,grp_led:scroll,caps:none"
>>
>> but after i3 is started, 'setxkbmap -query' returns
>>
>> rules:  evdev
>> model:  pc105
>> layout: us
>> options:grp:alt_shift_toggle,grp_led:scroll,caps:none
>>
>> I'd expect the layouts from the keyborad setup would be used as well. I
>> wasn't able to find another location which would override the keyboard
>> layout.
>>
>> Regards,
>> Vlastimil Zíma
>>
>>
>> -- System Information:
>> Debian Release: bullseye/sid
>>   APT prefers testing
>>   APT policy: (500, 'testing'), (500, 'stable')
>> Architecture: amd64 (x86_64)
>>
>> Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores)
>> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
>> Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8),
>> LANGUAGE=en_DK.UTF-8 (charmap=UTF-8)
>> Shell: /bin/sh linked to /usr/bin/dash
>> Init: systemd (via /run/systemd/system)
>> LSM: AppArmor: enabled
>>
>> Versions of packages i3-wm depends on:
>> ii  libc6 2.29-2
>> ii  libcairo2 1.16.0-4
>> ii  libev41:4.27-1
>> ii  libglib2.0-0  2.62.2-1
>> ii  libpango-1.0-01.42.4-7
>> ii  libpangocairo-1.0-0   1.42.4-7
>> ii  libpcre3  2:8.39-12+b1
>> ii  libstartup-notification0  0.12-6
>> ii  libxcb-cursor00.1.1-4
>> ii  libxcb-icccm4 0.4.1-1.1
>> ii  libxcb-keysyms1   0.4.0-1+b2
>> ii  libxcb-randr0 1.13.1-2
>> ii  libxcb-shape0 1.13.1-2
>> ii  libxcb-util0  0.3.8-3+b2
>> ii  libxcb-xinerama0  1.13.1-2
>> ii  libxcb-xkb1   1.13.1-2
>> ii  libxcb-xrm0   1.0-3
>> ii  libxcb1   1.13.1-2
>> ii  libxkbcommon-x11-00.8.4-1
>> ii  libxkbcommon0 0.8.4-1
>> ii  libyajl2  2.1.0-3
>> ii  perl  5.30.0-9
>>
>> Versions of packages i3-wm recommends:
>> ii  fonts-dejavu-core 2.37-1
>> ii  gnome-terminal [x-terminal-emulator]  3.34.2-1
>> ii  libanyevent-i3-perl   0.17-1
>> ii  libjson-xs-perl   4.020-1+b1
>> ii  xfonts-base   1:1.0.5
>> ii  xterm [x-terminal-emulator]   349-1
>>
>> i3-wm suggests no packages.
>>
>> -- no debconf information
>>
>
>
> --
> Best regards,
> Michael
>

Bug#944201: apt-listchanges: [INTL:de] updated German po file translation

2019-11-05 Thread Helge Kreutzmann

Package: apt-listchanges
Version: 3.21
Severity: wishlist
Tags: patch l10n

Please find the updated German po file translation for apt-listchanges
attached.

If you update your template, please use 
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the 
German translation.

Greetings
Helge
# german po-file for apt-listchanges
# Copyright (C) 2002 Free Software Foundation
# Leonard Michlmayr , 2002.
# Jens Seidel , 2007.
# Helge Kreutzmann , 2008, 2017, 2019.
#
msgid ""
msgstr ""
"Project-Id-Version: apt-listchanges 3.21\n"
"Report-Msgid-Bugs-To: apt-listchan...@packages.debian.org\n"
"POT-Creation-Date: 2019-11-03 20:05+0100\n"
"PO-Revision-Date: 2019-11-05 20:54+0100\n"
"Last-Translator: Helge Kreutzmann \n"
"Language-Team: German \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Generated-By: pygettext.py 1.4\n"

#: ../apt-listchanges.py:62
#, python-format
msgid "Unknown frontend: %s"
msgstr "Unbekannte Oberfläche: %s"

#: ../apt-listchanges.py:78
#, python-format
msgid "Cannot reopen /dev/tty for stdin: %s"
msgstr "/dev/tty konnte nicht erneut für Stdin geöffnet werden: %s"

#: ../apt-listchanges.py:133
#, python-format
msgid "News for %s"
msgstr "Neuigkeiten für %s"

#: ../apt-listchanges.py:135
#, python-format
msgid "Changes for %s"
msgstr "Änderungen für %s"

#: ../apt-listchanges.py:145
msgid "Informational notes"
msgstr "Anmerkungen"

#: ../apt-listchanges.py:152
msgid "apt-listchanges: News"
msgstr "apt-listchanges: Neuigkeiten"

#: ../apt-listchanges.py:153
msgid "apt-listchanges: Changelogs"
msgstr "apt-listchanges: Changelogs"

#: ../apt-listchanges.py:159
#, python-format
msgid "apt-listchanges: news for %s"
msgstr "apt-listchanges: Neuigkeiten für %s"

#: ../apt-listchanges.py:160
#, python-format
msgid "apt-listchanges: changelogs for %s"
msgstr "apt-listchanges: Changelogs für %s"

#: ../apt-listchanges.py:166
msgid "Didn't find any valid .deb archives"
msgstr "Keine gültigen .deb-Archive gefunden"

#: ../apt-listchanges.py:183
#, python-format
msgid "%s: will be newly installed"
msgstr "%s: wird erstmals installiert"

#: ../apt-listchanges.py:210
#, python-format
msgid "%(pkg)s: Version %(version)s has already been seen"
msgstr "%(pkg)s: Version %(version)s wurde schon einmal angezeigt"

#: ../apt-listchanges.py:214
#, python-format
msgid ""
"%(pkg)s: Version %(version)s is lower than version of related packages "
"(%(maxversion)s)"
msgstr ""
"%(pkg)s: Version %(version)s ist niedriger als die Version der zugehörigen "
"Pakete (%(maxversion)s)"

#: ../apt-listchanges.py:268
msgid "Binary NMU of"
msgstr "Binärer NMU von"

#: ../apt-listchanges.py:302
#, python-format
msgid "Received signal %d, exiting"
msgstr "Signal %d empfangen, Ende"

#: ../apt-listchanges/apt_listchanges.py:55
msgid "Aborting"
msgstr "Abbruch"

#: ../apt-listchanges/apt_listchanges.py:60
#, python-format
msgid "Confirmation failed: %s"
msgstr "Bestätigung fehlgeschlagen: %s"

#: ../apt-listchanges/apt_listchanges.py:64
#, python-format
msgid "Mailing %(address)s: %(subject)s"
msgstr "Senden von E-Mail an %(address)s: %(subject)s"

#: ../apt-listchanges/apt_listchanges.py:83
#, python-format
msgid "Failed to send mail to %(address)s: %(errmsg)s"
msgstr "Fehler beim Senden von E-Mail an %(address)s: %(errmsg)s"

#: ../apt-listchanges/apt_listchanges.py:92
#, python-format
msgid "The mail frontend needs an installed 'sendmail', using %s"
msgstr ""
"Die E-Mail-Oberfläche benötigt ein installiertes »sendmail«, »%s« wird "
"verwandt"

#: ../apt-listchanges/apt_listchanges.py:98
#, python-format
msgid "The mail frontend needs an e-mail address to be configured, using %s"
msgstr ""
"Die E-Mail-Oberfläche benötigt eine E-Mail-Adresse zum Konfigurieren, »%s« "
"wird verwandt"

#: ../apt-listchanges/apt_listchanges.py:111
msgid "Available apt-listchanges frontends:"
msgstr "Verfügbare Apt-listchanges-Oberflächen:"

#: ../apt-listchanges/apt_listchanges.py:113
msgid "Choose a frontend by entering its number: "
msgstr "Wählen Sie eine Oberfläche durch Eingabe ihrer Nummer"

#: ../apt-listchanges/apt_listchanges.py:122
#: ../apt-listchanges/apt_listchanges.py:431
#, python-format
msgid "Error: %s"
msgstr "Fehler: %s"

#: ../apt-listchanges/apt_listchanges.py:124
#, python-format
msgid "Using default frontend: %s"
msgstr "Standard-Oberfläche wird verwandt: %s"

#: ../apt-listchanges/apt_listchanges.py:167
#, python-format
msgid "$DISPLAY is not set, falling back to %(frontend)s"
msgstr "$DISPLAY ist nicht gesetzt, Rückfall auf %(frontend)s"

#: ../apt-listchanges/apt_listchanges.py:187
#, python-format
msgid ""
"The gtk frontend needs a working python3-gi,\n"
"but it cannot be loaded. Falling back to %(frontend)s.\n"
"The error is: %(errmsg)s"
msgstr ""
"Die GTK-Oberfläche benötigt ein funktionierendes python3-gi,\n"
"es kann aber nicht geladen werden.

Bug#943423: libccfits-doc: FTBFS with doxygen 1.8.16-1~exp3 from experimental)

2019-11-05 Thread Aurelien Jarno

tag 943423 + moreinfo

Hi,

On 2019-10-24 18:59, Paolo Greppi wrote:
> Package: libccfits-doc
> Version: 2.5+dfsg-1
> Severity: normal
> 
> Dear Maintainer,
> 
> This package failed to build with doxygen 1.8.16-1~exp3 from experimental.
> 
> It FTBFS with this error:
> 
> /usr/bin/make -C latex
> make[2]: Entering directory '/<>/latex'
> rm -f *.ps *.dvi *.aux *.toc *.idx *.ind *.ilg *.log *.out *.brf *.blg *.bbl 
> refman.pdf
> pdflatex refman
> This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/Debian) 
> (preloaded format=pdflatex)
>  restricted \write18 enabled.
> entering extended mode
> (./refman.tex
> LaTeX2e <2018-12-01>
> 
> make[2]: *** [Makefile:8: refman.pdf] Error 1
> make[2]: Leaving directory '/<>/latex'
> make[1]: *** [debian/rules:15: override_dh_auto_build-indep] Error 2
> make[1]: Leaving directory '/<>'
> make: *** [debian/rules:6: build] Error 2
> 
> More details can be found in the file latex/refman.log at the end of the 
> build.
> I attach it.
> 
> This had been notified already for doxygen 1.8.15 but the bug was closed:
> https://bugs.debian.org/921296

The bug was closed because it's not a bug of the ccfits package. The
ccfits package doesn't do anything fancy, it uses doxygen to generate
a latex file and runs pdflatex on it. doxygen should be fixed instead
to generate valid latex output.

Aurelien

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

Bug#941078: transition: postgresql-12

2019-11-05 Thread Paul Gevers

Hi Christoph,

Did I see correctly that not much changed in the status of the
postgresql-12 transition? Are you done uploading and do the other
packages need binNMU's? Or are you just busy?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#944006: nginx-extras missing TLS1.3

2019-11-05 Thread Thomas Ward

Can you include the output of `nginx -V` please as well?  Part of TLS 
support is having a version of NGINX that is compiled against an OpenSSL 
in the repositories for the version of Debian you're using which 
supports TLS1.3, but that may not be the case in all releases of Debian.



Thomas


On 11/2/19 1:15 PM, Florent CARRÉ wrote:

Package: nginx-extras
Version: 1.14.2-2+deb10u1

When I modify to have exclusively TLS1.2 and TLS1.3, just TLS1.2 is available.

Steps to reproduce :
- switch to ssl_protocols TLSv1.2 TLSv1.3
- restart nginx
- curl -v --tlsv1.3 mydomain.com

I obtain :
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS alert, protocol version (582):
* error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version
* Closing connection 0
curl: (35) error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert
protocol version

And it's available in openssl : openssl ciphers -v | grep " TLSv1\.3 "
TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any  Au=any  Enc=AESGCM(256) Mac=AEAD
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any  Au=any
Enc=CHACHA20/POLY1305(256) Mac=AEAD
TLS_AES_128_GCM_SHA256  TLSv1.3 Kx=any  Au=any  Enc=AESGCM(128) Mac=AEAD

Regards

Bug#944056: i3-wm: i3 ignores system keyboard layouts

2019-11-05 Thread Michael Stapelberg

i3 is not involved in handling keys, only keyboard shortcuts.

Are you saying that keybindings (such as Mod+2 to switch to workspace 2)
you configured in the i3 config file are not working? Or are you referring
to text input to applications, such as entering your name in a web form in
Firefox?

On Sun, Nov 3, 2019 at 3:09 PM Vlastimil Zima 
wrote:

> Package: i3-wm
> Version: 4.17.1-1
> Severity: normal
> Tags: l10n
>
> Dear Maintainer,
>
> I'm trying to setup a i3, but I encountered a problem with keyboard
> layout setup. Multiple layouts set up in /etc/default/keyboard are
> ignored by i3 and only 'us' layout is available. On the other hand,
> keyboard options are respected.
>
> I have in /etc/default/keyboard
>
> XKBLAYOUT="us,cz"
> XKBVARIANT=",qwerty"
> BACKSPACE="guess"
> XKBMODEL="pc105"
> XKBOPTIONS="grp:alt_shift_toggle,grp_led:scroll,caps:none"
>
> but after i3 is started, 'setxkbmap -query' returns
>
> rules:  evdev
> model:  pc105
> layout: us
> options:grp:alt_shift_toggle,grp_led:scroll,caps:none
>
> I'd expect the layouts from the keyborad setup would be used as well. I
> wasn't able to find another location which would override the keyboard
> layout.
>
> Regards,
> Vlastimil Zíma
>
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (500, 'testing'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_DK.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages i3-wm depends on:
> ii  libc6 2.29-2
> ii  libcairo2 1.16.0-4
> ii  libev41:4.27-1
> ii  libglib2.0-0  2.62.2-1
> ii  libpango-1.0-01.42.4-7
> ii  libpangocairo-1.0-0   1.42.4-7
> ii  libpcre3  2:8.39-12+b1
> ii  libstartup-notification0  0.12-6
> ii  libxcb-cursor00.1.1-4
> ii  libxcb-icccm4 0.4.1-1.1
> ii  libxcb-keysyms1   0.4.0-1+b2
> ii  libxcb-randr0 1.13.1-2
> ii  libxcb-shape0 1.13.1-2
> ii  libxcb-util0  0.3.8-3+b2
> ii  libxcb-xinerama0  1.13.1-2
> ii  libxcb-xkb1   1.13.1-2
> ii  libxcb-xrm0   1.0-3
> ii  libxcb1   1.13.1-2
> ii  libxkbcommon-x11-00.8.4-1
> ii  libxkbcommon0 0.8.4-1
> ii  libyajl2  2.1.0-3
> ii  perl  5.30.0-9
>
> Versions of packages i3-wm recommends:
> ii  fonts-dejavu-core 2.37-1
> ii  gnome-terminal [x-terminal-emulator]  3.34.2-1
> ii  libanyevent-i3-perl   0.17-1
> ii  libjson-xs-perl   4.020-1+b1
> ii  xfonts-base   1:1.0.5
> ii  xterm [x-terminal-emulator]   349-1
>
> i3-wm suggests no packages.
>
> -- no debconf information
>


-- 
Best regards,
Michael

Bug#944200: liblrdf0-dev: move lrdf.pc to a multiarch location

2019-11-05 Thread Helmut Grohne

Package: liblrdf0-dev
Version: 0.6.1-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:sonic-visualiser

The affected packages fail to cross build from source, because they fail
to find lrdf.pc using pkg-config. During cross compilation, pkg-config
only searches /usr/lib//pkgconfig and /usr/share/pkgconfig, but
not /usr/lib/pkgconfig. The attached patch moves the whole library to a
multiarch directory. Please consider applying it.

Helmut
diff --minimal -Nru liblrdf-0.6.1/debian/changelog 
liblrdf-0.6.1/debian/changelog
--- liblrdf-0.6.1/debian/changelog  2017-01-09 19:50:09.0 +0100
+++ liblrdf-0.6.1/debian/changelog  2019-11-05 20:22:13.0 +0100
@@ -1,3 +1,10 @@
+liblrdf (0.6.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move lrdf.pc to a multiarch location. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 05 Nov 2019 20:22:13 +0100
+
 liblrdf (0.6.1-1) unstable; urgency=medium
 
   [ upstream ]
diff --minimal -Nru liblrdf-0.6.1/debian/control liblrdf-0.6.1/debian/control
--- liblrdf-0.6.1/debian/control2017-01-09 19:43:40.0 +0100
+++ liblrdf-0.6.1/debian/control2019-11-05 20:20:25.0 +0100
@@ -8,7 +8,7 @@
  libtool,
  automake,
  autoconf,
- debhelper,
+ debhelper (>= 8.1.3),
  dh-buildinfo,
  licensecheck,
  d-shlibs (>= 0.79~),
diff --minimal -Nru liblrdf-0.6.1/debian/rules liblrdf-0.6.1/debian/rules
--- liblrdf-0.6.1/debian/rules  2017-01-09 17:38:11.0 +0100
+++ liblrdf-0.6.1/debian/rules  2019-11-05 20:22:13.0 +0100
@@ -54,15 +54,16 @@
  src/Makefile.in
 DEB_ACLOCAL_ARGS = -Im4 --install --force
 DEB_AUTOMAKE_ARGS = --add-missing --copy --foreign --force
+DEB_CONFIGURE_EXTRA_FLAGS += '--libdir=$${prefix}/lib/$(DEB_HOST_MULTIARCH)'
 clean::
rm -f compile stamp-h
 
 binary-post-install/liblrdf0::
-   d-shlibmove --commit \
+   d-shlibmove --commit --multiarch \
--movedev "debian/tmp/usr/include/*" usr/include/ \
-   --movedev "debian/tmp/usr/lib/pkgconfig/*.pc" 
usr/lib/pkgconfig/ \
+   --movedev 
"debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/pkgconfig/*.pc" 
usr/lib/$(DEB_HOST_MULTIARCH)/pkgconfig/ \
--moveshl debian/tmp/usr/share/ladspa/rdf/ladspa.rdfs 
usr/share/ladspa/rdf/ \
-   debian/tmp/usr/lib/liblrdf.so
+   debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/liblrdf.so
 
 binary-predeb/liblrdf0-dev::
find debian/liblrdf0-dev/ -type f -name '*.la' -delete

Bug#944199: exim4: dsearch in config end up in exim4 panic

2019-11-05 Thread Benedikt Spranger

Package: exim4
Version: 4.93~RC1-2
Severity: important

Dear Maintainer,

using a virtual domain config as described in the current exim manual
https://www.exim.org/exim-html-current/doc/html/spec_html/ch-some_common_configuration_settings.html#SECTvirtualdomains

renders exim4 unusable.

Config files:
# ls /etc/exim4/virtual
example.com
#

Config snippet:
virtual:
  driver = redirect
  domains = dsearch;/etc/mail/virtual
  data = ${lookup{$local_part}lsearch{/etc/mail/virtual/$domain}}
  no_more

Error (paniclog):
2019-11-05 17:27:01 1iRbGs-X0-9x Taint mismatch, string_vformat: 
dsearch_find 87
2019-11-05 17:27:50 Taint mismatch, string_vformat: dsearch_find 87

Regards
Benedikt Spranger

Bug#925703: gr-hpsdr: ftbfs with GCC-9

2019-11-05 Thread Paul Gevers

Control: reopen -1
Control: block -1 by 943965

Hi Steve,

On Fri, 1 Nov 2019 14:11:32 -0700 Steve Langasek
 wrote:
> In resolving the gnuradio 3.8 transition in Ubuntu, I found that this build
> failure no longer applies to gr-hpsdr, with no changes to that package's
> source.  There is an unrelated failure that requires an update to
> gnuradio-dev (missing dependency on libgmp-dev), but with that fixed,
> gr-hpsdr builds fine in both Debian and Ubuntu with gcc 9.

I did a binNMU two days ago, which failed on all archs. I guess the fix
didn't land in Debian? If so, let's not have this bug closed. Or did I
miss something?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#936207: biosig4c++: Python2 removal in sid/bullseye

Package: biosig4c++
Followup-For: Bug #936207
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Attached is a patch to drop python2 support from biosig4c++.  It has been
uploaded to Ubuntu, since the resulting build failure is currently blocking
the octave 5 transition there.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru biosig4c++-1.9.3/debian/control biosig4c++-1.9.3/debian/control
--- biosig4c++-1.9.3/debian/control 2019-01-20 13:09:35.0 -0800
+++ biosig4c++-1.9.3/debian/control 2019-11-05 11:24:07.0 -0800
@@ -8,11 +8,8 @@
dh-python,
d-shlibs,
gawk,
-   python-dev,
python3-dev,
swig,
-   python-numpy,
-   python-pkgconfig,
python3-numpy,
python3-pkgconfig,
zlib1g-dev,
@@ -67,17 +64,6 @@
 CWFB.  save2gdf can be also used to upload or retrieve data from a
 bscs server.
 
-Package: python-biosig
-Architecture: any
-Section: python
-Depends: ${python:Depends},
- ${shlibs:Depends},
- ${misc:Depends}
-Description: Python bindings for BioSig library
- This package provides Python bindings for BioSig library.  Primary
- goal -- I/O interface to variety of biomedical file formats, including
- but not limited to SCP-ECG(EN1064), HL7aECG (FDA-XML), GDF, EDF.
-
 Package: python3-biosig
 Architecture: any
 Section: python
diff -Nru biosig4c++-1.9.3/debian/python-biosig.examples 
biosig4c++-1.9.3/debian/python-biosig.examples
--- biosig4c++-1.9.3/debian/python-biosig.examples  2019-01-20 
13:09:35.0 -0800
+++ biosig4c++-1.9.3/debian/python-biosig.examples  1969-12-31 
16:00:00.0 -0800
@@ -1,2 +0,0 @@
-python/demo*.py
-python/example.py
diff -Nru biosig4c++-1.9.3/debian/rules biosig4c++-1.9.3/debian/rules
--- biosig4c++-1.9.3/debian/rules   2019-01-20 13:09:35.0 -0800
+++ biosig4c++-1.9.3/debian/rules   2019-11-05 11:24:07.0 -0800
@@ -11,7 +11,7 @@
 export DEB_BUILD_MAINT_OPTIONS=hardening=+all
 
 %:
-   dh  $@ --with python2,python3
+   dh  $@ --with python3
 
 override_dh_auto_configure:
dh_auto_configure
@@ -37,11 +37,8 @@
 
 # Manual crafting of installing Octave and Python bindings
 # TODO: proper
-PYTHON=$(shell pyversions -d)
 PYTHON3=$(shell py3versions -d)
-PYDIR=$(shell /bin/ls -d /usr/lib/$(PYTHON)/*-packages)
 PY3DIR=$(shell if /bin/ls -d /usr/lib/${PYTHON3}/*-packages 2>/dev/null ; then 
/bin/ls -d /usr/lib/${PYTHON3}/*-packages ; else /bin/ls -d 
/usr/lib/python3/*-packages ; fi)
-PYVER=$(shell pyversions -d -v)
 PY3VER=$(shell py3versions -d -v)
 
 OCTDIR=$(shell octave-config -p LOCALOCTFILEDIR)/biosig
@@ -50,8 +47,6 @@
dh_auto_install
 
: I: install Python binding for current Python verion TODO: all
-   mkdir -p debian/python-biosig$(PYDIR)
-   cp -a python/build/lib.*-$(PYVER)/biosig.so debian/python-biosig$(PYDIR)
mkdir -p debian/python3-biosig$(PY3DIR)
cp -a python/build/lib.*-$(PY3VER)/biosig.*.so 
debian/python3-biosig$(PY3DIR)/biosig.so

Bug#944198: ITP: python-fsspec -- A specification that python filesystems should adhere to

2019-11-05 Thread Emmanuel Arias

Package: wnpp
Severity: wishlist
Owner: Emmanuel Arias 

  Package name: python-fsspec
  Version : 0.5.2
  Upstream Author : Martin Durant
  URL : https://github.com/intake/filesystem_spec
  License : BSD 3-Clause License
  Programming Lang: Python
  Description : A specification that python filesystems should adhere to

The package produce a template or specification for a file-system interface,
that specific implementations should follow, so that applications making use
of them can rely on a common behaviour and not have to worry about the
specific internal implementation decisions with any given backend.

It is a dependency of python-dask (see #942235:).

This package will be team-maintained by the Debian Python Modules
Team

Bug#944196: Correction: Version is 4.19.67. Additional kernel logs.

2019-11-05 Thread Matt Johnson

Apologies, version should be 4.19.67.

Full console log for debug kernel boot:
---

InsydeH2O Version : B193.25A
BIOS Build Date : 03/25/2019
Processor Type : Intel(R) Atom(TM) CPU C3958 @ 2.00GHz
System Memory Speed : 2400 MHz

Press Del to Setup Utility
[0.00] Linux version 4.19.0-6-686-pae (debian-ker...@lists.debian.org) 
(gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.67-2+deb10u1 
(2019-09-20)
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'
[0.00] x86/fpu: xstate_offset[3]:  576, xstate_sizes[3]:   64
[0.00] x86/fpu: xstate_offset[4]:  640, xstate_sizes[4]:   64
[0.00] x86/fpu: Enabled xstate features 0x1b, context size is 704 
bytes, using 'compacted' format.
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009ebff] usable
[0.00] BIOS-e820: [mem 0x0009ec00-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x65ffefff] usable
[0.00] BIOS-e820: [mem 0x65fff000-0x727fefff] reserved
[0.00] BIOS-e820: [mem 0x727ff000-0x7e7fefff] ACPI NVS
[0.00] BIOS-e820: [mem 0x7e7ff000-0x7effefff] ACPI data
[0.00] BIOS-e820: [mem 0x7efff000-0x7eff] usable
[0.00] BIOS-e820: [mem 0x7f00-0x7fff] reserved
[0.00] BIOS-e820: [mem 0xe000-0xefff] reserved
[0.00] BIOS-e820: [mem 0xfd00-0xfe80] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfec8-0xfed00fff] reserved
[0.00] BIOS-e820: [mem 0xfed1-0xfed17fff] reserved
[0.00] BIOS-e820: [mem 0xfed84000-0xfed84fff] reserved
[0.00] BIOS-e820: [mem 0xff80-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00047fff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 3.0 present.
[0.00] DMI:  /DV970, BIOS B193.25A 03/25/2019
[0.00] tsc: Detected 2000.000 MHz processor
[0.006105] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.006110] e820: remove [mem 0x000a-0x000f] usable
[0.006122] last_pfn = 0x48 max_arch_pfn = 0x100
[0.006128] MTRR default type: uncachable
[0.006130] MTRR fixed ranges enabled:
[0.006134]   0-9 write-back
[0.006136]   A-B uncachable
[0.006138]   C-E7FFF write-protect
[0.006141]   E8000-E write-combining
[0.006143]   F-F write-protect
[0.006145] MTRR variable ranges enabled:
[0.006148]   0 base 00FF80 mask 7FFF80 write-protect
[0.006151]   1 base 00 mask 7F8000 write-back
[0.006153]   2 base 007F00 mask 7FFF00 uncachable
[0.006156]   3 base 01 mask 7F write-back
[0.006158]   4 base 02 mask 7E write-back
[0.006161]   5 base 04 mask 7F8000 write-back
[0.006163]   6 disabled
[0.006165]   7 disabled
[0.006166]   8 disabled
[0.006168]   9 disabled
[0.006961] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT
[0.012272] found SMP MP-table at [mem 0x000fe1d0-0x000fe1df]
[0.012824] initial memory mapped: [mem 0x-0x1bff]
[0.012896] BRK [0x1bb96000, 0x1bb96fff] PGTABLE
[0.012925] BRK [0x1bb97000, 0x1bb98fff] PGTABLE
[0.012928] BRK [0x1bb99000, 0x1bb99fff] PGTABLE
[0.012930] BRK [0x1bb9a000, 0x1bb9afff] PGTABLE
[0.012940] RAMDISK: [mem 0x356ad000-0x36b4dfff]
[0.012948] ACPI: Early table checksum verification disabled
[0.013276] ACPI: RSDP 0x000FE020 24 (v02 INSYDE)
[0.013283] ACPI: XSDT 0x7EFE2188 DC (v01 INSYDE DNV  
0001  0113)
[0.013292] ACPI: FACP 0x7EFF4000 00010C (v05 INSYDE DNV  
0001 ACPI 0004)
[0.013301] ACPI: DSDT 0x7EFEB000 004778 (v02 INSYDE DNV  
 ACPI 0004)
[0.013308] ACPI: FACS 0x7E64A000 40
[0.013313] ACPI: UEFI 0x7EFFD000 000236 (v01 INSYDE DNV  
0001 ACPI 0004)
[0.013319] ACPI: UEFI 0x7EFFB000 42 (v01 INSYDE DNV  
 ACPI 0004)
[0.013325] ACPI: SSDT 0x7EFFA000 000554 (v01 INSYDE DNV  
1000 ACPI 0004)
[0.013331] ACPI: TPM2 0x7EFF9000 34 (v03 INSYDE DNV  
0002 ACPI 0004)
[

Bug#939571: uploaded a NMU, delayed 15 days

2019-11-05 Thread Georges Khaznadar

Hello Gianfranco,

as the bug is (not elegantly) fixed, and as the deadline for autoremoval
is in 25 days, I uploaded python-pyqtgraph_0.10.0-4.1 as an NMU.

If you prefer download the good fix before two weeks, do not worry, the
NMU will silently die.

Best regards,   Georges.

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#944163: interimap: seems --repair doesn't work

2019-11-05 Thread Guilhem Moulin

Hi Jonas,

On Tue, 05 Nov 2019 at 13:55:59 +0100, Jonas Smedegaard wrote:
> $ interimap --config hb INBOX
> remote: ERROR: UIDVALIDITY changed! (1571588814 != 1154884797)  Need to 
> invalidate the UID cache.
> 
> ..and it seems the --repair option doesn't do its job:

I guess naming that command ‘--repair’ wasn't the best choice; it's not
meant to reconcile UIDVALIDITY mismatch anyway, but to perform a
so-called “full synchronization” à la offlineimap to compare the
UID+flag list between the local and remote mailboxes.  (Unless there is
a bug in interimap or the IMAPd's QRESYNC implementation there shouldn't
be anything to repair, but it's still useful for integrity checking
etc.)

IMAP4rev1 allows servers without mechanism for storing persistent UID and
UIDVALIDITY values.  However synchronizing such server is out of scope
for interimap(1), and I guess other IMAP-based synchronization software,
cf. RFC 3501 sec. 2.3.1.1: “Persistent unique identifiers are required
for a client to resynchronize its state from a previous session with the
server […] The combination of mailbox name, UIDVALIDITY, and UID must
refer to a single immutable message on that server forever.”

There is nothing interimap can do so resolve UIDVALIDITY conflicts.  It
needs to invalidate its cache, because per RFC 3501 the lUID ↔ rUID
mapping can't be relied upon anymore.  (Rebuilding the mapping by
comparing message RFC 5355 data is not reliable either, because IMAP
does allow duplicates.)

> local: S: * STATUS INBOX (UIDNEXT 290008 UIDVALIDITY 1571588814 HIGHESTMODSEQ 
> 71671)
> […]
> remote: S: * STATUS INBOX (UIDNEXT 280739 UIDVALIDITY 1571588814 
> HIGHESTMODSEQ 74538)
> […]
> remote: ERROR: UIDVALIDITY changed! (1571588814 != 1154884797)  Need to 
> invalidate the UID cache.

I find it suspicious that both mailboxes have the same UIDVALIDITY
value.  By RFC 3501 that value is an arbitrary unsigned >0 32-bits
integer.  That value (like UID values) are set by the server and can't
be chosen or altered by the client (otherwise interimap wouldn't need a
database to keep track of the lUID ↔ rUID mapping, a mere state file
would be sufficient).  Dovecot doesn't pick it at random, but AFAICT
uses the timestamp at which the mailbox was created.

It looks kind of weird to me that both your local and remote INBOX
appears to have been created at the very same time (Oct 20 18:26 CEST)
while the timestamp found in the database is many years older (Aug 06
2006).  The UIDVALIDITY conflict can't be caused by interimap or any
other IMAP client, because that's beyond the IMAP protocol.  Did you
maybe run a lower-level synchronization tool like dsync(1) between these
mailboxes?  IIRC dsync preserve states, so it could explain why the
UIDVALIDITY value was reset to the very same timestamp.  (UIDVALIDITY
reset could also happen when the dovecot index files are removed, but it
seems unlikely that they would be set to the very same value.)  It
should never happen with a “normal” layered IMAP stack.  Dovecot does
have persistent UID values, at least when the index files are not stored
on a volatile medium.

Now, how to fix this?  The easiest is to remove the database entry for
that mailbox: `interimap --target=database delete INBOX` (this won't
touch your mails, just the database) and then try to sync again.
However every message in the local INBOX will be copied remotely and
vice-versa, so if you have a lot of messages in both mailboxes this will
create a lot of duplicates :-(  This won't cause any data loss though.

Another thing which seems to suggest that there is a lower-level
synchronization running and causing cache corruption, is the huge spike
between the local INBOX's current state and the one from the database
(ie the last successful sync): UIDNEXT=9598 / HIGHESTMODSEQ=165 vs.
UIDNEXT=290008 / HIGHESTMODSEQ=71671.  While sudden heavy-traffic
mailboxes are certainly possible, it's still a bit suspicious.

The first step is to identify what's causing the cache corruption as
it's likely to happen again otherwise, and that's beyond the scope of
interimap and other plain IMAP clients :-P  If it was indeed dsync(1)
causing the cache corruption, then it's possible to avoid duplicates:
you could run it once more so both sides are in sync (with matching/
overwritten UIDs, UIDVALIDITY, etc. values), then nuke *one* end along
with the database (using `interimap --target=database --target=local
delete INBOX`) and finally sync again.  I reckon it's a bit scary
though, so feel free to poke me over IRC if you'd like.

-- 
Guilhem.

signature.asc
Description: PGP signature

Bug#944196: Kernel Panic with Debian 10 (32-bit) on Intel Atom C3958

2019-11-05 Thread Matt Johnson

Package: linux
Version: 4.19.37

A kernel panic occurs when attempting to boot Debian 10.1.0
(32-bit) on an Intel Atom C3958 processor.
https://ark.intel.com/content/www/us/en/ark/products/97927/intel-atom-processor-c3958-16m-cache-up-to-2-0-ghz.html

The hardware I'm using is this board: https://www.dfi.com/product/index/149 
(rev 3),
with carrier board https://www.dfi.com/product/index/223 (rev 3.0).

When booting the system, the following panic occurs:

[2.457743] Kernel panic - not syncing: BIOS has enabled x2apic but kernel 
doesn't support x2apic, please disable x2apic in BIOS.
[2.457743]
[2.457743] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.19.0-6-686-pae #1 
Debian 4.19.67-2+deb10u1
[2.457743] Hardware name:  /DV970, BIOS B193.25A 03/25/2019
[2.457743] Call Trace:
[2.457743]  dump_stack+0x58/0x7e
[2.457743]  ? apic_verify+0xab/0xab
[2.457743]  panic+0x94/0x1e0
[2.457743]  ? apic_verify+0xab/0xab
[2.457743]  ? apic_verify+0xab/0xab
[2.457743]  validate_x2apic+0x4d/0x4f
[2.457743]  do_one_initcall+0x42/0x19a
[2.457743]  ? proc_register+0xab/0x110
[2.457743]  ? proc_create_seq_private+0x3e/0x40
[2.457743]  ? init_mm_internals+0x181/0x18b
[2.457743]  kernel_init_freeable+0xb0/0x1e0
[2.457743]  ? rest_init+0x8a/0x8a
[2.457743]  kernel_init+0xd/0xea
[2.457743]  ret_from_fork+0x2e/0x38
[2.457743] ---[ end Kernel panic - not syncing: BIOS has enabled x2apic but 
kernel doesn't support x2apic, please disable x2apic in BIOS.
[2.457743]  ]---


There is no option to disable APIC in the board BIOS.
When attempting to boot without APIC enabled, the panic still occurs:

[0.202575] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-6-686-pae 
root=UUID=3d4351e7-53e9-4d65-8a81-c205f3cd7a6e ro quiet console=tty 
console=ttyS1,115200 noapic nox2apic noioapic debug apic=debug show_lapic=all
...
[2.944990] Kernel panic - not syncing: BIOS has enabled x2apic but kernel 
doesn't support x2apic, please disable x2apic in BIOS.
[2.944990]
[2.944990] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.19.0-6-686-pae #1 
Debian 4.19.67-2+deb10u1
[2.944990] Hardware name:  /DV970, BIOS B193.25A 03/25/2019
[2.944990] Call Trace:
[2.944990]  dump_stack+0x58/0x7e
[2.944990]  ? apic_verify+0xab/0xab
[2.944990]  panic+0x94/0x1e0
[2.944990]  ? apic_verify+0xab/0xab
[2.944990]  ? apic_verify+0xab/0xab
[2.944990]  validate_x2apic+0x4d/0x4f
[2.944990]  do_one_initcall+0x42/0x19a
[2.944990]  ? proc_register+0xab/0x110
[2.944990]  ? proc_create_seq_private+0x3e/0x40
[2.944990]  ? init_mm_internals+0x181/0x18b
[2.944990]  kernel_init_freeable+0xb0/0x1e0
[2.944990]  ? rest_init+0x8a/0x8a
[2.944990]  kernel_init+0xd/0xea
[2.944990]  ret_from_fork+0x2e/0x38
[2.944990] ---[ end Kernel panic - not syncing: BIOS has enabled x2apic but 
kernel doesn't support x2apic, please disable x2apic in BIOS.
[2.944990]  ]---


When booting with the kernel parameters
"acpi=off noapic nosmp forcepae", the panic message changes:

[0.201640] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-6-686-pae 
root=UUID=3d4351e7-53e9-4d65-8a81-c205f3cd7a6e ro quiet console=tty 
console=ttyS1,115200 debug acpi=off noapic nosmp forcepae
...
[2.025480] [ cut here ]
[2.030212] kernel BUG at arch/x86/kernel/apic/apic.c:1500!
[2.035919] invalid opcode:  [#1] SMP NOPTI
[2.040571] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.19.0-6-686-pae #1 
Debian 4.19.67-2+deb10u1
[2.049675] Hardware name:  /DV970, BIOS B193.25A 03/25/2019
[2.055456] EIP: setup_local_APIC+0x4a0/0x510
[2.059929] Code: 00 eb 84 8d b4 26 00 00 00 00 a1 80 f7 85 c8 ba 00 04 00 
00 8b 48 08 b8 60 03 00 00 e8 41 36 65 00 e9 07 fe ff ff 8d 74 26 00 <0f> 0b 8d 
b6 00 00 00 00 a1 cc 6d a5 c8 0b 05 a4 6e a5 c8 0f 85 8d
[2.078893] EAX:  EBX:  ECX: c8a5fde4 EDX: f000
[2.085276] ESI: c89b6948 EDI: f6ffc568 EBP: c88abf54 ESP: c88abf24
[2.091665] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00210246
[2.098573] CR0: 80050033 CR2: ff9ff000 CR3: 08a48000 CR4: 000406b0
[2.104959] Call Trace:
[2.107524]  ? vprintk_default+0x17/0x20
[2.111566]  apic_bsp_setup+0x81/0x97
[2.115342]  apic_intr_mode_init+0x1a6/0x1ab
[2.119729]  x86_late_time_init+0x16/0x1d
[2.123853]  start_kernel+0x3a3/0x45f
[2.127630]  i386_start_kernel+0xac/0xb0
[2.131672]  startup_32_smp+0x164/0x168
[2.135623] Modules linked in:
[2.138811] ---[ end trace 2d2c9d5d7faf9f9e ]---
[2.143560] EIP: setup_local_APIC+0x4a0/0x510
[2.148049] Code: 00 eb 84 8d b4 26 00 00 00 00 a1 80 f7 85 c8 ba 00 04 00 
00 8b 48 08 b8 60 03 00 00 e8 41 36 65 00 e9 07 fe ff ff 8d 74 26 00 <0f> 0b 8d 
b6 00 00 00 00 a1 cc 6d a5 c8 0b 05 a4 6e a5 c8 0f 85 8d
[2.167032] EAX:  EBX:  ECX: c8a5fde4 EDX: f000
[2.173432] ESI: c89b6948 EDI: f6ffc568

Bug#944189: Needs source-only re-upload to be able to migrate

2019-11-05 Thread Cyril Brulebois

Control: reassign -1 haveged-udeb 1.9.8-1
Control: severity -1 serious
Control: fixed -1 1.9.8-2

Cyril Brulebois  (2019-11-05):
> Control: retitle -1 haveged-udeb uninstallable: depends on non-udeb libhavege2
> 
> Steve McIntyre  (2019-11-05):
> > On Tue, Nov 05, 2019 at 05:24:54PM +0100, Cyril Brulebois wrote:
> > >
> > >As mentioned on IRC, rebuilding will likely not fix the actual problem,
> > >which is the udeb depending on the library. That the migration is
> > >prevented because of a missing source-only upload is another topic.
> > 
> > Ugh, yes. I missed that, seeing what looked like an obvious fix. It
> > was, just a fix for a different bug... :-)
> 
> Right, adjusting bug title to reflect the actual problem you were
> getting and that I'm fixing; it's just been uploaded with a
> source-only upload, which should also help transition-wise.
> 
> Details are in:
>   
> https://salsa.debian.org/debian/haveged/commit/2e6b6a581c4db9e5dbfb685cdd20bfd8fcb646c5

More meta data tweaks, I didn't spot initially that the NMU was
uploaded and not just announced…


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#944195: Makefile: The MACHINE variable has been renamed to ARCH

2019-11-05 Thread Lucas Kanashiro


Source: lm-sensors
Version: 1:3.6.0-1
Severity: normal

Dear Maintainer,

As described in upstream CHANGES file, the MACHINE variable used in the
Makefile was renamed to ARCH in the latest version (3.6.0) [1]. This
variable is also used in debian/rules [2], so it should be renamed to
ARCH as well.

[1] https://sources.debian.org/src/lm-sensors/1:3.6.0-1/CHANGES/#L9
[2] https://sources.debian.org/src/lm-sensors/1:3.6.0-1/debian/rules/#L13

Thanks for considering this!

--
Lucas Kanashiro

Bug#944189: Needs source-only re-upload to be able to migrate

2019-11-05 Thread Cyril Brulebois

Control: retitle -1 haveged-udeb uninstallable: depends on non-udeb libhavege2

Steve McIntyre  (2019-11-05):
> On Tue, Nov 05, 2019 at 05:24:54PM +0100, Cyril Brulebois wrote:
> >
> >As mentioned on IRC, rebuilding will likely not fix the actual problem,
> >which is the udeb depending on the library. That the migration is
> >prevented because of a missing source-only upload is another topic.
> 
> Ugh, yes. I missed that, seeing what looked like an obvious fix. It
> was, just a fix for a different bug... :-)

Right, adjusting bug title to reflect the actual problem you were
getting and that I'm fixing; it's just been uploaded with a
source-only upload, which should also help transition-wise.

Details are in:
  
https://salsa.debian.org/debian/haveged/commit/2e6b6a581c4db9e5dbfb685cdd20bfd8fcb646c5


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#944194: dput: Authenticated HTTP uploads are broken in Python 3.7

2019-11-05 Thread TQ Hirsch

Package: dput
Version: 1.0.3
Severity: normal
Tags: patch

Using dput to an HTTP host that expects Basic authentication ("hsg" in
the config below) results in the following stack trace:

Uploading to hsg (via http to localhost:8123):
  Uploading thequux-apt-config_2019.11.02.dsc: need authentication.
Traceback (most recent call last):
  File "/usr/bin/dput", line 11, in 
    load_entry_point('dput==1.0.3', 'console_scripts', 'execute-dput')()
  File "/usr/share/dput/dput/dput.py", line 1156, in main
    files_to_upload, debug, 0, progress=progress)
  File "/usr/share/dput/dput/methods/http.py", line 154, in upload
    url, res.msg, pwman).get_auth_headers()
  File "/usr/share/dput/dput/methods/http.py", line 82, in get_auth_headers
    ah.http_error_401(self, None, 401, None, self.resp_headers)
  File "/usr/lib/python3.7/urllib/request.py", line 1025, in http_error_401
    url = req.full_url
AttributeError: 'AuthHandlerHackAround' object has no attribute 'full_url'

I would have expected this to prompt me for a password and then
proceed to upload the package.

The attached patch seems to fix the problem, but it has not been
thoroughly tested (only a quick trial).

-- Package-specific info:

-- /etc/dput.cf --
# Example dput.cf that defines the host that can be used
# with dput for uploading.

[DEFAULT]
login            = *
method            = ftp
hash            = md5
allow_unsigned_uploads    = 0
allow_dcut        = 0
run_lintian        = 0
run_dinstall        = 0
check_version        = 0
scp_compress        = 0
post_upload_command    =
pre_upload_command    =
passive_ftp        = 1
default_host_main    =
allowed_distributions    = (?!UNRELEASED)

[ftp-master]
fqdn            = ftp.upload.debian.org
incoming        = /pub/UploadQueue/
login            = anonymous
allow_dcut        = 1
method            = ftp
# Please, upload your package to the proper archive
#
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security-upload
allowed_distributions    = (?!UNRELEASED|.*-security)

# https://lists.debian.org/debian-project/2009/05/msg00036.html
[ftp-eu]
fqdn            = ftp.eu.upload.debian.org
method            = ftp
incoming        = /pub/UploadQueue/
login            = anonymous
allow_dcut        = 1
# Please, upload your package to the proper archive
#
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security-upload
allowed_distributions    = (?!UNRELEASED|.*-security)

# https://lists.debian.org/debian-devel-announce/2008/09/msg7.html
[ssh-upload]
login            = *
# login            = another_username
fqdn            = ssh.upload.debian.org
method            = scp
incoming        = /srv/upload.debian.org/UploadQueue/
allow_dcut        = 1
# Please, upload your package to the proper archive
#
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security-upload
allowed_distributions    = (?!UNRELEASED|.*-security)

# And if you want to override one of the defaults, add it here.
# For example, comment out the next line
# post_upload_command    = /path/to/some/script
# pre_upload_command    = /path/to/some/script

[security-master]
fqdn            = ftp.security.upload.debian.org
method            = ftp
incoming        = /pub/SecurityUploadQueue
login            = anonymous
allow_dcut        = 1
# This has been added at the request of the security team.
# Please be sure to know what you are doing before taking it out.
pre_upload_command    = /usr/share/dput/helper/security-warning

[security-master-unembargoed]
fqdn            = ftp.security.upload.debian.org
method            = ftp
incoming        = /pub/OpenSecurityUploadQueue
login            = anonymous
allow_dcut        = 1
# This has been added at the request of the security team.
# Please be sure to know what you are doing before taking it out.
pre_upload_command    = /usr/share/dput/helper/security-warning

[ubuntu]
fqdn            = upload.ubuntu.com
method            = ftp
incoming        = /
login            = anonymous

[ppa]
fqdn            = ppa.launchpad.net
method            = ftp
# replace  with your Launchpad ID
incoming        = ~/ubuntu
login            = anonymous

[mentors]
method            = ftp
fqdn            = mentors.debian.net
incoming        = /pub/UploadQueue
login            = anonymous

[local]
method            = local
incoming        = ~/public_html/debian/mini-dinstall/incoming
run_dinstall        = 0
post_upload_command    = /usr/bin/mini-dinstall --batch


# Local variables:
# coding: utf-8
# mode: conf
# End:
# vim: fileencoding=utf-8 filetype=config :

-- /home/thequux/.dput.cf --
[hsg]
fqdn = localhost:8123
method = http
login = thequux
incoming = /incoming
# distributions = hsg

[DEFAULT]
login = *
method = ftp
hash = md5
allow_unsigned_uploads = 0
allow_dcut = 0
distributions =
allowed_distributions = (?!UNRELEASED)
run_lintian = 0
run_dinstall = 0
check_version = 0
scp_compress = 0
default_host_main =
post_upload_command =
pre_upload_command =

Bug#944151: remctl: attempts internet connection during testsuite

Gianfranco Costamagna  writes:

> Hello, according to build log:
> Testing Python extension
> running pytest
> Searching for typing
> Reading https://pypi.org/simple/typing/
> Downloading 
> https://files.pythonhosted.org/packages/fe/2e/b480ee1b75e6d17d2993738670e75c1feeb9ff7f64452153cf018051cc92/typing-3.7.4.1-py3-none-any.whl#sha256=f38d83c5a7a7086543a0f649564d661859c5146a85775ab90c0d2f93ffaa9714
> Best match: typing 3.7.4.1
> Processing typing-3.7.4.1-py3-none-any.whl
> Installing typing-3.7.4.1-py3-none-any.whl to /<>/python/.eggs

Ah, thank you, I thought setuptools was much smarter than apparently it
actually is.  I'll look at this tonight; I may fix this upstream instead
of only in the Debian package if it doesn't take too long to do.

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

Bug#944152: network access during the build