Bug#934273: python3-debian: please support parsing Source: package (version)

2020-10-24 Thread Stuart Prescott
Control: tags -1 patch

Hi David

Returning to your excellent idea in #9334273, how does the following seem? It 
adds an accessor for the the `source` and `source_version` to the classes 
generated by the deb822.Packages class:

In [1]: from debian import deb822 

In [2]: def whatmade(name, cat): 
  ...: p = [pkg for pkg in cat if pkg['Package'] == name][0] 
  ...: print("Source %s/%s made binary %s/%s" % ( 
  ...: p.source, 
  ...: p.source_version, 
  ...: p['Package'], 
  ...: p.get_version(), 
  ...: )) 

In [3]: cat = list(deb822.Packages.iter_paragraphs(open('/var/lib/apt/lists/
deb.debian.org_debian_dists_sid_main_binary-amd64_Packages'))) 

In [4]: whatmade('gcc-10', cat) 
Source gcc-10/10.2.0-15 made binary gcc-10/10.2.0-15 

In [5]: whatmade('gcc-10-base', cat) 
Source gcc-10/10.2.0-15 made binary gcc-10-base/10.2.0-15 

In [6]: whatmade('gcc', cat) 
Source gcc-defaults/1.189 made binary gcc/4:10.2.0-1 

https://salsa.debian.org/python-debian-team/python-debian/-/merge_requests/28

Does that provide the sort of API that you were hoping to have?

cheers
Stuart


-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7



Bug#972847: libdbd-pg-perl: last_insert_id doesn't work against PostgreSQL 12 (or greater)

2020-10-24 Thread Andrew Ruthven
Package: libdbd-pg-perl
Version: 3.7.4-3
Severity: important

Dear Maintainer,

The version of DBD::Pg in Buster (and earlier) is incompatible with PostgreSQL
12 (or greater) if the application code using DBD::Pg uses the last_insert_id
function. The last_insert_id method uses the pg_attrdef.adsrc column which was
removed in Pg 12 (search for adsrc):

  https://www.postgresql.org/docs/12/release-12.html

DBD::Pg removed the usage of pg_attrdef.adsrc in version 3.8.0 with commit:

  88d2f8f1fc95bcd16e95d3fc667783fb7a9ab05b

I've set this as important as it may affect people running PostgreSQL from
the pgdg repos provided by PostgreSQL.

This bug shouldn't affect bullseye which currently has version 3.14.2.

Cheers,
Andrew

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

Kernel: Linux 4.9.227-vs2.3.9.12-beng (SMP w/8 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=POSIX (charmap=UTF-8) (ignored: LC_ALL set 
to en_NZ.UTF-8), LANGUAGE=en_NZ:en (charmap=UTF-8) (ignored: LC_ALL set to 
en_NZ.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libdbd-pg-perl depends on:
ii  libc6 2.28-10
ii  libdbi-perl [perl-dbdabi-94]  1.642-1+deb10u1
ii  libpq511.9-0+deb10u1
ii  perl  5.28.1-6+deb10u1
ii  perl-base [perlapi-5.28.1]5.28.1-6+deb10u1

libdbd-pg-perl recommends no packages.

libdbd-pg-perl suggests no packages.

-- no debconf information



Bug#972672: bash SIGSEGV related to locale

2020-10-24 Thread Uoti Urpala
On Thu, 22 Oct 2020 11:47:44 +0200 Thomas Schwinge  wrote:
> ..., that is, SIGSEGV, supposedly when bash tries to expand the last path
> component glob ('*'):

I also encountered this bug. After installing bash-dbgsym, gdb says it
crashes at glob.c line 487 in wdequote_pathname(). The immediate cause
of the crash there seems to be that wpathname is NULL.

I suspect that the bug is the "len" argument on the previous line
  n = wcsrtombs(pathname, (const wchar_t **), len, );

Here "len" is byte length obtained for the original string from
strlen(). But the call seems to expect the length of the wide character
version in wpathname which was obtained above with xdupmbstowcs(), and
so the code should use the return value of that function (in variable
n) instead of len. Using too long a length makes wcsrtombs() set the
pointer to NULL when it continues to a zero character.



Bug#972846: github-backup: always says "Run again later"

2020-10-24 Thread Rob Browning


Package: github-backup
Version: 1.20200721-2

I might well be doing something wrong, but I haven't been able to back
up a repository, e.g.:

  $ git clone https://github.com/bup/bup.git
  $ cd bup

  $ github-backup
  Retrying 7 requests that failed last time...
  Gathering metadata for https://github.com/bup/bup.git ...
  Backup may be incomplete; 7 requests failed:
1 forks
1 issues
1 milestones
1 pullrequests
1 stargazers
1 userrepo
1 watchers
  Run again later.

And I get that same result every time, even after waiting a while and
trying again.

If it matters, that repository has issues disabled, but not pull
requests.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4



Bug#972845: github-backup: control homepage link is no longer reachable

2020-10-24 Thread Rob Browning


Package: github-backup

Perhaps here here now: https://github-backup.branchable.com/
As indicated by: https://joeyh.name/code/github-backup/

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4



Bug#972841: RFS: libutempter/1.2.1-1 -- privileged helper for utmp/wtmp updates (runtime)

2020-10-24 Thread Christian Göttsche
Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: libutempter
   Version : 1.2.1-1
   Upstream Author : Dmitry V. Levin 
 * URL :
http://git.altlinux.org/people/ldv/packages/?p=libutempter.git
 * License : LGPL-2.1
 * Vcs : https://salsa.debian.org/cgzones/libutempter
   Section : libs

It builds those binary packages:

  libutempter0 - privileged helper for utmp/wtmp updates (runtime)
  libutempter-dev - privileged helper for utmp/wtmp updates (development)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libu/libutempter/libutempter_1.2.1-1.dsc

Changes since the last upload:

 libutempter (1.2.1-1) unstable; urgency=medium
 .
   * New upstream version 1.2.1
 .
   * Make autopkgtests cross-test-friendly
 Based on Ubuntu patch by Steve Langasek 
   * d/control:
 - bump to debhelper compat level 13
 - update vcs fields
   * debian: run wrap-and-sort
   * d/watch: scan for .tar.gz and bump version
   * d/upstream/signing-key.asc: update key to A8041FA839E16E36
   * d/copyright: update years
   * d/patches: drop patches incorporated upstream and rebase

Regards,
Christian Göttsche



Bug#972844: lintian: E: musescore2 source: malformed-override Unknown tag testsuite-autopkgtest-missing in line 5

2020-10-24 Thread Thorsten Glaser
Package: lintian
Version: 2.99.0

I’ve been recompiling musescore2_2.3.2+dfsg3-10.dsc (currently
in sid) on latest sid, to test it for Qt 5.14 compatibility and
latest lintian overrides (modulo #969398, still unfixed).

I’m getting this:

N: Using profile debian/main.
N: Starting on group musescore2/2.3.2+dfsg3-10
N: Finished processing group musescore2/2.3.2+dfsg3-10
E: musescore2 source: malformed-override Unknown tag 
testsuite-autopkgtest-missing in line 5
N:
E: malformed-override
N:
N:   Lintian discovered an override entry with an invalid format. An
[…]

The overrides file contains just this:

-
# github doesn’t expose those
musescore2 source: debian-watch-does-not-check-gpg-signature

# not usable / suitable / useful, unfortunately
musescore2 source: testsuite-autopkgtest-missing

# oh really?! what the ever…
musescore2 source: cute-field
-

Something really weird is happening here; lintian output has
become less reliable and more hard to parse in the last few
months…



Bug#972843: kdenlive: abort on start

2020-10-24 Thread Brian May
Package: kdenlive
Version: 20.08.2-1
Severity: grave
Justification: renders package unusable

If I try to start kdenlive on a new system that has never run kdenlive
before, it aborts with an error.

$ kdenlive
Using modified system locale without group separator for numbers
NEW LC_ALL en_AU.UTF-8
Metadata for "glsl.manager" is invalid.
WARNING : Fails to parse  "glsl.manager"
Metadata for "movit.convert" is invalid.
WARNING : Fails to parse  "movit.convert"
Metadata for "movit.crop" is invalid.
WARNING : Fails to parse  "movit.crop"
Metadata for "movit.resample" is invalid.
WARNING : Fails to parse  "movit.resample"
Metadata for "movit.resize" is invalid.
WARNING : Fails to parse  "movit.resize"
"resample" is blacklisted
Metadata for "deinterlace" is invalid.
WARNING : Fails to parse  "deinterlace"
"rgblut" is blacklisted
"spot_remover" is blacklisted
"text" is blacklisted
"timer" is blacklisted
"qtext" is blacklisted
"motion_est" is blacklisted
Invalid title/identifier for  "crop_detect"
 / 
WARNING : Fails to parse  "crop_detect"
"gtkrescale" is blacklisted
"videostab" is blacklisted
"videostab2" is blacklisted
Metadata for "audiochannels" is invalid.
WARNING : Fails to parse  "audiochannels"
Metadata for "audioconvert" is invalid.
WARNING : Fails to parse  "audioconvert"
Metadata for "data_feed" is invalid.
WARNING : Fails to parse  "data_feed"
"data_show" is blacklisted
Metadata for "imageconvert" is invalid.
WARNING : Fails to parse  "imageconvert"
"mask_apply" is blacklisted
"mask_start" is blacklisted
"mono" is blacklisted
"region" is blacklisted
"resize" is blacklisted
"transition" is blacklisted
"watermark" is blacklisted
"frei0r.3dflippo" is blacklisted
"frei0r.bluescreen0r" is blacklisted
"frei0r.bw0r" is blacklisted
"frei0r.gamma" is blacklisted
"frei0r.invert0r" is blacklisted
"frei0r.rgbsplit0r" is blacklisted
"frei0r.transparency" is blacklisted
"frei0r.vertigo" is blacklisted
"burningtv" is blacklisted
Metadata for "telecide" is invalid.
WARNING : Fails to parse  "telecide"
Metadata for "jack" is invalid.
WARNING : Fails to parse  "jack"
"jackrack" is blacklisted
Metadata for "avcolour_space" is invalid.
WARNING : Fails to parse  "avcolour_space"
Metadata for "avcolor_space" is invalid.
WARNING : Fails to parse  "avcolor_space"
Metadata for "avdeinterlace" is invalid.
WARNING : Fails to parse  "avdeinterlace"
Metadata for "swscale" is invalid.
WARNING : Fails to parse  "swscale"
"avfilter.abench" is blacklisted
"avfilter.acompressor" is blacklisted
"avfilter.adelay" is blacklisted
"avfilter.aecho" is blacklisted
"avfilter.aemphasis" is blacklisted
"avfilter.aeval" is blacklisted
"avfilter.afade" is blacklisted
"avfilter.afftfilt" is blacklisted
"avfilter.agate" is blacklisted
"avfilter.ametadata" is blacklisted
"avfilter.arealtime" is blacklisted
"avfilter.ashowinfo" is blacklisted
"avfilter.channelmap" is blacklisted
"avfilter.chorus" is blacklisted
"avfilter.earwax" is blacklisted
"avfilter.volume" is blacklisted
"avfilter.volumedetect" is blacklisted
"avfilter.ass" is blacklisted
"avfilter.atadenoise" is blacklisted
"avfilter.avgblur" is blacklisted
"avfilter.bbox" is blacklisted
"avfilter.bench" is blacklisted
"avfilter.blackdetect" is blacklisted
"avfilter.blackframe" is blacklisted
"avfilter.boxblur" is blacklisted
"avfilter.bwdif" is blacklisted
"avfilter.chromakey" is blacklisted
"avfilter.colorkey" is blacklisted
"avfilter.colormatrix" is blacklisted
"avfilter.colorspace" is blacklisted
"avfilter.convolution" is blacklisted
"avfilter.crop" is blacklisted
"avfilter.cropdetect" is blacklisted
"avfilter.curves" is blacklisted
"avfilter.datascope" is blacklisted
"avfilter.dctdnoiz" is blacklisted
"avfilter.deband" is blacklisted
"avfilter.deflate" is blacklisted
"avfilter.deinterlace_vaapi" is blacklisted
"avfilter.deshake" is blacklisted
"avfilter.despill" is blacklisted
"avfilter.doubleweave" is blacklisted
"avfilter.drawbox" is blacklisted
"avfilter.drawgraph" is blacklisted
"avfilter.drawgrid" is blacklisted
"avfilter.drawtext" is blacklisted
"avfilter.elbg" is blacklisted
"avfilter.eq" is blacklisted
"avfilter.fade" is blacklisted
"avfilter.field" is blacklisted
"avfilter.fieldhint" is blacklisted
"avfilter.fieldorder" is blacklisted
"avfilter.find_rect" is blacklisted
"avfilter.floodfill" is blacklisted
"avfilter.fspp" is blacklisted
"avfilter.gblur" is blacklisted
"avfilter.geq" is blacklisted
"avfilter.hflip" is blacklisted
"avfilter.hqdn3d" is blacklisted
"avfilter.hqx" is blacklisted
"avfilter.hue" is blacklisted
"avfilter.hwdownload" is blacklisted
"avfilter.idet" is blacklisted
"avfilter.il" is blacklisted
"avfilter.lenscorrection" is blacklisted
"avfilter.loop" is blacklisted
"avfilter.lumakey" is blacklisted
"avfilter.lut" is blacklisted
"avfilter.lutrgb" is blacklisted
"avfilter.lutyuv" is blacklisted
"avfilter.mcdeint" is blacklisted
"avfilter.metadata" is blacklisted
"avfilter.negate" is blacklisted
"avfilter.nlmeans" is blacklisted
"avfilter.nnedi" is blacklisted

Bug#972512:

2020-10-24 Thread Sudip Mukherjee
Update: blocked on https://github.com/OfflineIMAP/offlineimap3/issues/12.


-- 
Regards
Sudip



Bug#584726: rdiff-backup: preserve_atime option

2020-10-24 Thread Pablo Mestre
tags 584726 moreinfo

Please you can provide more information?


-- 
  ⢀⣴⠾⠻⢶⣦⠀  Pablo Mestre Drake
  ⣾⠁⢠⠒⠀⣿⡁  --
  ⢿⡄⠘⠷⠚⠋   https://debian.org
  ⠈⠳⣄  Debian, the universal operating system.



Bug#508063: rdiff-backup tries to read/list directories, no matter --exclude rules

2020-10-24 Thread Pablo Mestre
Hi

Thank you very much for reporting this error.

I would like to ask you if this error is still present in the most
recent versions of rdiff-backup. Currently after a series of
improvements and bug fixes, rdiff-backup is at version 2.0.5 [1]

It would be very helpful if you checked again if this bug is still present. 
Otherwise we can agree to close the bug,

[1] https://github.com/rdiff-backup/rdiff-backup/releases/tag/v2.0.5

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Pablo Mestre Drake
  ⣾⠁⢠⠒⠀⣿⡁  --
  ⢿⡄⠘⠷⠚⠋   https://debian.org
  ⠈⠳⣄  Debian, the universal operating system.



Bug#310442: rdiff-backup: no way to recover from full filesystem

2020-10-24 Thread Pablo Mestre
Hi

Thank you very much for reporting this error.

I would like to ask you if this error is still present in the most
recent versions of rdiff-backup. Currently after a series of
improvements and bug fixes, rdiff-backup is at version 2.0.5 [1]

It would be very helpful if you checked again if this bug is still present. 
Otherwise we can agree to close the bug,

[1] https://github.com/rdiff-backup/rdiff-backup/releases/tag/v2.0.5

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Pablo Mestre Drake
  ⣾⠁⢠⠒⠀⣿⡁  --
  ⢿⡄⠘⠷⠚⠋   https://debian.org
  ⠈⠳⣄  Debian, the universal operating system.



Bug#557951: option to force backup (--include-if-present)

2020-10-24 Thread Pablo Mestre
Hi

Thank you very much for reporting this error.

I would like to ask you if this error is still present in the most
recent versions of rdiff-backup. Currently after a series of
improvements and bug fixes, rdiff-backup is at version 2.0.5 [1]

It would be very helpful if you checked again if this bug is still present. 
Otherwise we can agree to close the bug,

[1] https://github.com/rdiff-backup/rdiff-backup/releases/tag/v2.0.5

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Pablo Mestre Drake
  ⣾⠁⢠⠒⠀⣿⡁  --
  ⢿⡄⠘⠷⠚⠋   https://debian.org
  ⠈⠳⣄  Debian, the universal operating system.



Bug#967997: [Solved] rdiff-backup: maintainer address invalid

2020-10-24 Thread Pablo Mestre
The maintainer's addresses have already been updated.
It is currently under the responsibility of the Python Applications
Packaging team.


Since this isseu has already been solved, we proceed to close the bug

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Pablo Mestre Drake
  ⣾⠁⢠⠒⠀⣿⡁  --
  ⢿⡄⠘⠷⠚⠋   https://debian.org
  ⠈⠳⣄  Debian, the universal operating system.



Bug#734925: rdiff-backup: remove-older-than fails to communicate with remote server

2020-10-24 Thread Pablo Mestre
Hi

Thank you very much for reporting this error.

I would like to ask you if this error is still present in the most
recent versions of rdiff-backup. Currently after a series of
improvements and bug fixes, rdiff-backup is at version 2.0.5 [1]

It would be very helpful if you checked again if this bug is still present. 
Otherwise we can agree to close the bug,

[1] https://github.com/rdiff-backup/rdiff-backup/releases/tag/v2.0.5

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Pablo Mestre Drake
  ⣾⠁⢠⠒⠀⣿⡁  --
  ⢿⡄⠘⠷⠚⠋   https://debian.org
  ⠈⠳⣄  Debian, the universal operating system.



Bug#972758: ABI breakage without soname bump

2020-10-24 Thread Iustin Pop
On 2020-10-23 15:32:48, Steinar H. Gunderson wrote:
> On Fri, Oct 23, 2020 at 03:27:23PM +0200, Guillem Jover wrote:
> > If we want to support the interim versions that have never been in a
> > stable release, then I think the only way is to bump the minmum
> > version in liburing shlibs and symbols files to 0.7, then rebuild the
> > couple of packages built with 0.6 against 0.7, and then add Breaks in
> > liburing against the old dependent package versions using the previous
> > liburing releases.
> 
> Well, seemingly there are people who run old sid, and then only
> “apt update ; apt install plocate” -- which will pull in newer plocate
> but not liburing1 :-)

Yes, but those people know (or should know) that this is somewhat risky,
always. I do that sometimes, but I'm not surprised when things do break.

> But all that _must_ be supported as per Policy is upgrades from stable to
> stable, I believe? Not entirely sure how strict it is. It helps that
> liburing1 has never been in stable (only stable-bpo).

+1 here, stable-to-stable should be enough.



Bug#972842: "asciidoctor --backend=manpage" has at least two bugs

2020-10-24 Thread Bjarni Ingi Gislason
Package: asciidoctor
Version: 2.0.10-2
Severity: normal

Dear Maintainer,

  I found defects in some manuals in the linux-perf-5.[89] packages.

1) Wrong escape, '\F' (which means the font family)

perf_5.9-data.1:.SH "OPTIONS FOR \FICONVERT\FP"
perf_5.9-sched.1:.SH "OPTIONS FOR \FIPERF SCHED MAP\FP"
perf_5.9-sched.1:.SH "OPTIONS FOR \FIPERF SCHED TIMEHIST\FP"

 '\F' must be '\f'.

  So the text should first be capitalized and
then the straight quotes ('...') be changed to "\fI...\fP".

( It could be better
a) to keep the text in lower case with just the
sentence starting with a capital;
or
b) not to capitalize the whole text.)

  The source lines are:

OPTIONS for 'convert'

OPTIONS for 'perf sched map'

OPTIONS for 'perf sched timehist'


2) Trailing space with the .URL macro

perf_5.9-diff.1:.URL "file://filename" "" " "

perf_5.9-report.1:.URL "file://filename" "" " "

perf_5.9-script.1:.URL "file://filename" "" " "

  These are made from the text line:

file://filename entries.

  The third argument of ".URL" should be empty
as there is no punctuation mark attached to the web address.

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

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

Versions of packages asciidoctor depends on:
ii  ruby  1:2.7+1
ii  ruby-asciidoctor  2.0.10-2

asciidoctor recommends no packages.

asciidoctor suggests no packages.

-- no debconf information

-- 
Bjarni I. Gislason



Bug#710897: rdiff-backup 1.2.8-6 DeprecationWarning (Squeeze)

2020-10-24 Thread Pablo Mestre
Given that the error that is mentioned in this bugya was fixed in
version 1.2.8-7 we terminate this bug and we proceed to closure.
Thank you very much ... for all the information provided

You can get more information here

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

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

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Pablo Mestre Drake
  ⣾⠁⢠⠒⠀⣿⡁  --
  ⢿⡄⠘⠷⠚⠋   https://debian.org
  ⠈⠳⣄  Debian, the universal operating system.



Bug#626113: rdiff-backup: python backtrace when using --verify (IOError: CRC check failed)

2020-10-24 Thread Pablo Mestre
Hi

Thank you very much for reporting this error.

I would like to ask you if this error is still present in the most
recent versions of rdiff-backup. Currently after a series of
improvements and bug fixes, rdiff-backup is at version 2.0.5 [1]

It would be very helpful if you checked again if this bug is still present. 
Otherwise we can agree to close the bug,

[1] https://github.com/rdiff-backup/rdiff-backup/releases/tag/v2.0.5

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Pablo Mestre Drake
  ⣾⠁⢠⠒⠀⣿⡁  --
  ⢿⡄⠘⠷⠚⠋   https://debian.org
  ⠈⠳⣄  Debian, the universal operating system.



Bug#972833: intel-media-va-driver: SIGSEGV's on use (vlc, finch for example)

2020-10-24 Thread Sebastian Ramacher
Control: forwarded -1 https://github.com/intel/libva/issues/466
Control: reassign -1 libva2 2.9.0-1
control: retitle -1 libva: loads media-driver on unsupported GPU

On 2020-10-24 23:39:05 +0200, Karsten Hilbert wrote:
> On Sat, Oct 24, 2020 at 10:39:09PM +0200, Sebastian Ramacher wrote:
> 
> > >   Okt 24 17:56:50 hermes kernel: traps: vlc[27504] trap invalid opcode 
> > > ip:89c9d6fb sp:8e550370 error:0 in iHD_drv_video.so[899dc000+3c2000]
> >
> > Which Intel CPU/GPU do you have? If the instruction is not supported, libva
> > shouldn't load the driver for your's.
> 
> Architecture:i686
> CPU op-mode(s):  32-bit, 64-bit
> Byte Order:  Little Endian
> Address sizes:   36 bits physical, 48 bits virtual
> CPU(s):  2
> On-line CPU(s) list: 0,1
> Thread(s) per core:  1
> Core(s) per socket:  2
> Socket(s):   1
> Vendor ID:   GenuineIntel
> CPU family:  6
> Model:   23
> Model name:  Pentium(R) Dual-Core CPU   T4300  @ 
> 2.10GHz
> Stepping:10
> CPU MHz: 1342.405
> CPU max MHz: 2100.
> CPU min MHz: 1200.
> BogoMIPS:4189.84
> L1d cache:   64 KiB
> L1i cache:   64 KiB
> L2 cache:1 MiB
> Vulnerability Itlb multihit: KVM: Mitigation: VMX unsupported
> Vulnerability L1tf:  Mitigation; PTE Inversion
> Vulnerability Mds:   Vulnerable: Clear CPU buffers attempted, no 
> microcode; SMT disabled
> Vulnerability Meltdown:  Vulnerable
> Vulnerability Spec store bypass: Vulnerable
> Vulnerability Spectre v1:Mitigation; usercopy/swapgs barriers and 
> __user pointer sanitization
> Vulnerability Spectre v2:Mitigation; Full generic retpoline, STIBP 
> disabled, RSB filling
> Vulnerability Srbds: Not affected
> Vulnerability Tsx async abort:   Not affected
> Flags:   fpu vme de pse tsc msr pae mce cx8 apic sep 
> mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe nx 
> lm constant_tsc arch_perfmon pebs bts cpuid aperfmperf pni dtes64 monitor 
> ds_cpl est tm2 ssse3 cx16 xtpr pdcm xsave lahf_lm dtherm
> 
> 
> 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset 
> Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller])
> Subsystem: ASUSTeK Computer Inc. Mobile 4 Series Chipset Integrated 
> Graphics Controller
> Flags: bus master, fast devsel, latency 0, IRQ 16
> Memory at fe40 (64-bit, non-prefetchable) [size=4M]
> Memory at d000 (64-bit, prefetchable) [size=256M]
> I/O ports at dc00 [size=8]
> Expansion ROM at 000c [virtual] [disabled] [size=128K]
> Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit-
> Capabilities: [d0] Power Management version 3
> Kernel driver in use: i915
> Kernel modules: i915
> 
> 
> Does that help ?

Thanks, that is definitely not supported by intel-media-driver and
shouldn't be loaded in the first place. Reported upstream.

Cheers

> 
> Karsten
> --
> GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature


Bug#972702: ruby-bundler: dependency resolution fails for compiled gems

2020-10-24 Thread Lucas Kanashiro
It seems the search path is not right in this newer ruby-bundler
version. Using the following Gemfile and running 'bundle --local' works
fine.

root@rubygems-test:~/test# cat Gemfile
path "/usr/share/rubygems-integration/2.7.0" do
  gem 'ffi'
end
root@rubygems-test:~/test# bundle --local
Don't run Bundler as root. Bundler can ask for sudo if it is needed, and
installing your bundle
as root will break this application for all non-root users on this machine.
Using bundler 2.2.0.rc.1
Using ffi 1.12.2 from source at `/usr/share/rubygems-integration/2.7.0`
Bundle complete! 1 Gemfile dependency, 2 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.

Interestingly, I have 2 containers (one with ruby-bundler 2.2.0.rc.1 and
another with version 2.1.4) and both of them have the same set of
directories in GEM PATHS, so both should be looking at the same directories.

root@rubygems-test-old:~/test# bundler version
Bundler version 2.1.4 (2020-01-05 commit 32a4159325)
root@rubygems-test-old:~/test# gem env
RubyGems Environment:
  - RUBYGEMS VERSION: 3.2.0.rc.1
  - RUBY VERSION: 2.7.2 (2020-10-01 patchlevel 137) [x86_64-linux-gnu]
  - INSTALLATION DIRECTORY: /var/lib/gems/2.7.0
  - USER INSTALLATION DIRECTORY: /root/.local/share/gem/ruby/2.7.0
  - RUBY EXECUTABLE: /usr/bin/ruby2.7
  - GIT EXECUTABLE:
  - EXECUTABLE DIRECTORY: /usr/local/bin
  - SPEC CACHE DIRECTORY: /root/.local/share/gem/specs
  - SYSTEM CONFIGURATION DIRECTORY: /etc
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86_64-linux
  - GEM PATHS:
 - /var/lib/gems/2.7.0
 - /root/.local/share/gem/ruby/2.7.0
 - /usr/local/lib/ruby/gems/2.7.0
 - /usr/lib/ruby/gems/2.7.0
 - /usr/lib/x86_64-linux-gnu/ruby/gems/2.7.0
 - /usr/share/rubygems-integration/2.7.0
 - /usr/share/rubygems-integration/all
 - /usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0
  - GEM CONFIGURATION:
 - :update_sources => true
 - :verbose => true
 - :backtrace => false
 - :bulk_threshold => 1000
  - REMOTE SOURCES:
 - https://rubygems.org/
  - SHELL PATH:
 - /usr/local/sbin
 - /usr/local/bin
 - /usr/sbin
 - /usr/bin
 - /sbin
 - /bin


root@rubygems-test:~/test# bundler version
Bundler version 2.2.0.rc.1 (2020-10-24 commit unknown)
root@rubygems-test:~/test# gem env
RubyGems Environment:
  - RUBYGEMS VERSION: 3.2.0.rc.1
  - RUBY VERSION: 2.7.2 (2020-10-01 patchlevel 137) [x86_64-linux-gnu]
  - INSTALLATION DIRECTORY: /var/lib/gems/2.7.0
  - USER INSTALLATION DIRECTORY: /root/.local/share/gem/ruby/2.7.0
  - RUBY EXECUTABLE: /usr/bin/ruby2.7
  - GIT EXECUTABLE:
  - EXECUTABLE DIRECTORY: /usr/local/bin
  - SPEC CACHE DIRECTORY: /root/.local/share/gem/specs
  - SYSTEM CONFIGURATION DIRECTORY: /etc
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86_64-linux
  - GEM PATHS:
 - /var/lib/gems/2.7.0
 - /root/.local/share/gem/ruby/2.7.0
 - /usr/local/lib/ruby/gems/2.7.0
 - /usr/lib/ruby/gems/2.7.0
 - /usr/lib/x86_64-linux-gnu/ruby/gems/2.7.0
 - /usr/share/rubygems-integration/2.7.0
 - /usr/share/rubygems-integration/all
 - /usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0
  - GEM CONFIGURATION:
 - :update_sources => true
 - :verbose => true
 - :backtrace => false
 - :bulk_threshold => 1000
  - REMOTE SOURCES:
 - https://rubygems.org/
  - SHELL PATH:
 - /usr/local/sbin
 - /usr/local/bin
 - /usr/sbin
 - /usr/bin
 - /sbin
 - /bin

I'll keep investigating to understand what is going on.

-- 
Lucas Kanashiro



Bug#972833: intel-media-va-driver: SIGSEGV's on use (vlc, finch for example)

2020-10-24 Thread Karsten Hilbert
On Sat, Oct 24, 2020 at 10:39:09PM +0200, Sebastian Ramacher wrote:

> > Okt 24 17:56:50 hermes kernel: traps: vlc[27504] trap invalid opcode 
> > ip:89c9d6fb sp:8e550370 error:0 in iHD_drv_video.so[899dc000+3c2000]
>
> Which Intel CPU/GPU do you have? If the instruction is not supported, libva
> shouldn't load the driver for your's.

Architecture:i686
CPU op-mode(s):  32-bit, 64-bit
Byte Order:  Little Endian
Address sizes:   36 bits physical, 48 bits virtual
CPU(s):  2
On-line CPU(s) list: 0,1
Thread(s) per core:  1
Core(s) per socket:  2
Socket(s):   1
Vendor ID:   GenuineIntel
CPU family:  6
Model:   23
Model name:  Pentium(R) Dual-Core CPU   T4300  @ 2.10GHz
Stepping:10
CPU MHz: 1342.405
CPU max MHz: 2100.
CPU min MHz: 1200.
BogoMIPS:4189.84
L1d cache:   64 KiB
L1i cache:   64 KiB
L2 cache:1 MiB
Vulnerability Itlb multihit: KVM: Mitigation: VMX unsupported
Vulnerability L1tf:  Mitigation; PTE Inversion
Vulnerability Mds:   Vulnerable: Clear CPU buffers attempted, no 
microcode; SMT disabled
Vulnerability Meltdown:  Vulnerable
Vulnerability Spec store bypass: Vulnerable
Vulnerability Spectre v1:Mitigation; usercopy/swapgs barriers and 
__user pointer sanitization
Vulnerability Spectre v2:Mitigation; Full generic retpoline, STIBP 
disabled, RSB filling
Vulnerability Srbds: Not affected
Vulnerability Tsx async abort:   Not affected
Flags:   fpu vme de pse tsc msr pae mce cx8 apic sep 
mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe nx lm 
constant_tsc arch_perfmon pebs bts cpuid aperfmperf pni dtes64 monitor ds_cpl 
est tm2 ssse3 cx16 xtpr pdcm xsave lahf_lm dtherm


00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset 
Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. Mobile 4 Series Chipset Integrated 
Graphics Controller
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at fe40 (64-bit, non-prefetchable) [size=4M]
Memory at d000 (64-bit, prefetchable) [size=256M]
I/O ports at dc00 [size=8]
Expansion ROM at 000c [virtual] [disabled] [size=128K]
Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 3
Kernel driver in use: i915
Kernel modules: i915


Does that help ?

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B



Bug#972543: apt-file: Apt-update downloads full Contents file, not pdiffs

2020-10-24 Thread calumlikesapplepie
> > Basically, on every call to apt-update that isn't completely
> > trivial (ie, at least
> > 1 package changed), my computer downloads the full 60 Mb of
> > Contents files.  This
> > is irritating, for while I am often on a fast internet, I
> > frequently find myself on
> > a very slow connection.  
> > 
> > I know my config file enables pdiffs (and I attached it so you can
> > know, too).
> > The Readme talks a lot about pdiffs, and why I should enable them,
> > but except for
> > one sentence, it doesn't mention anything about apt update.  (The
> > sentence in 
> > question *could* be interpreted to mean that apt update will never
> > download
> > Pdiffs, but that is unlikely, given its context).
> > 
> > I don't know what's the cause.  If you need me to get a log file, I
> > can, but
> > Apt doesnt include these files in its final output: only while it
> > is
> > drawing progress bars.
> > 
> > Thank you!
> > Calum
> > 
> > [...]
> > > > 
> Hi Calum,
> I am sorry to hear it does not work as expected.

> All of the Contents downloading is outsourced to apt, so most likely
> it is a configuration (or a bug in apt itself).  Can you provide the
> output/contents of?

>   $ apt-config dump Acquire::IndexTargets

I'll paste the full output below

>   file:/etc/apt/apt-file.conf  (if it exists)

This file doesn't exist, though I attached what I think is it's
equivalent in my initial message.
> This will show the effective fetching configuration for apt and apt-
> file.
> Relatedly, just to confirm: The bug is on the system you are
> reporting
> from (i.e. running testing/sid) and you run "apt update" at least
> once a week.  Are these assumptions of mine correct?
Yes, that's correct.

apt-config dump Aquire::IndexTargets output:

Acquire::IndexTargets "";
Acquire::IndexTargets::deb "";
Acquire::IndexTargets::deb::Packages "";
Acquire::IndexTargets::deb::Packages::MetaKey "$(COMPONENT)/binary-
$(ARCHITECTURE)/Packages";
Acquire::IndexTargets::deb::Packages::flatMetaKey "Packages";
Acquire::IndexTargets::deb::Packages::ShortDescription "Packages";
Acquire::IndexTargets::deb::Packages::Description
"$(RELEASE)/$(COMPONENT) $(ARCHITECTURE) Packages";
Acquire::IndexTargets::deb::Packages::flatDescription "$(RELEASE)
Packages";
Acquire::IndexTargets::deb::Packages::Optional "0";
Acquire::IndexTargets::deb::Translations "";
Acquire::IndexTargets::deb::Translations::MetaKey
"$(COMPONENT)/i18n/Translation-$(LANGUAGE)";
Acquire::IndexTargets::deb::Translations::flatMetaKey "$(LANGUAGE)";
Acquire::IndexTargets::deb::Translations::ShortDescription
"Translation-$(LANGUAGE)";
Acquire::IndexTargets::deb::Translations::Description
"$(RELEASE)/$(COMPONENT) Translation-$(LANGUAGE)";
Acquire::IndexTargets::deb::Translations::flatDescription "$(RELEASE)
Translation-$(LANGUAGE)";
Acquire::IndexTargets::deb::DEP-11 "";
Acquire::IndexTargets::deb::DEP-11::MetaKey
"$(COMPONENT)/dep11/Components-$(NATIVE_ARCHITECTURE).yml";
Acquire::IndexTargets::deb::DEP-11::ShortDescription "Components-
$(NATIVE_ARCHITECTURE)";
Acquire::IndexTargets::deb::DEP-11::Description
"$(RELEASE)/$(COMPONENT) $(NATIVE_ARCHITECTURE) DEP-11 Metadata";
Acquire::IndexTargets::deb::DEP-11::KeepCompressed "true";
Acquire::IndexTargets::deb::DEP-11::KeepCompressedAs "gz";
Acquire::IndexTargets::deb::DEP-11-icons-small "";
Acquire::IndexTargets::deb::DEP-11-icons-small::MetaKey
"$(COMPONENT)/dep11/icons-48x48.tar";
Acquire::IndexTargets::deb::DEP-11-icons-small::ShortDescription
"icons-48x48";
Acquire::IndexTargets::deb::DEP-11-icons-small::Description
"$(RELEASE)/$(COMPONENT) DEP-11 48x48 Icons";
Acquire::IndexTargets::deb::DEP-11-icons-small::KeepCompressed "true";
Acquire::IndexTargets::deb::DEP-11-icons-small::KeepCompressedAs "gz";
Acquire::IndexTargets::deb::DEP-11-icons-small::DefaultEnabled "true";
Acquire::IndexTargets::deb::DEP-11-icons "";
Acquire::IndexTargets::deb::DEP-11-icons::MetaKey
"$(COMPONENT)/dep11/icons-64x64.tar";
Acquire::IndexTargets::deb::DEP-11-icons::ShortDescription "icons-
64x64";
Acquire::IndexTargets::deb::DEP-11-icons::Description
"$(RELEASE)/$(COMPONENT) DEP-11 64x64 Icons";
Acquire::IndexTargets::deb::DEP-11-icons::KeepCompressed "true";
Acquire::IndexTargets::deb::DEP-11-icons::KeepCompressedAs "gz";
Acquire::IndexTargets::deb::DEP-11-icons::DefaultEnabled "true";
Acquire::IndexTargets::deb::DEP-11-icons-hidpi "";
Acquire::IndexTargets::deb::DEP-11-icons-hidpi::MetaKey "$(COMPONENT)
/dep11/icons-64...@2.tar";
Acquire::IndexTargets::deb::DEP-11-icons-hidpi::ShortDescription "
icons-64x64@2";
Acquire::IndexTargets::deb::DEP-11-icons-hidpi::Description
"$(RELEASE)/$(COMPONENT) DEP-11 64x64@2 Icons";
Acquire::IndexTargets::deb::DEP-11-icons-hidpi::KeepCompressed "true";
Acquire::IndexTargets::deb::DEP-11-icons-hidpi::KeepCompressedAs "gz";
Acquire::IndexTargets::deb::DEP-11-icons-hidpi::DefaultEnabled "false";
Acquire::IndexTargets::deb::DEP-11-icons-large "";
Acquire::IndexTargets::deb::DEP-11-icons-large::MetaKey

Bug#972833: intel-media-va-driver: SIGSEGV's on use (vlc, finch for example)

2020-10-24 Thread Sebastian Ramacher
Control: tags -1 + moreinfo

On 2020-10-24 18:41:08 +0200, Karsten Hilbert wrote:
> Package: intel-media-va-driver
> Version: 20.3.0+dfsg1-1
> Severity: important
> Tags: upstream
> 
> This happens when running vlc (or finch, for that matter):
> 
>   VLC media player 3.0.11.1 Vetinari (revision 3.0.11.1-0-g52483f3ca2)
>   [006aabe0] main libvlc: VLC wird mit dem Standard-Interface ausgeführt. 
> Benutzen Sie 'cvlc', um VLC ohne Interface zu verwenden.
>   [991bf220] gl gl: Initialized libplacebo v2.72.0 (API v72)
>   libva info: VA-API version 1.9.0
>   libva info: Trying to open /usr/lib/i386-linux-gnu/dri/iHD_drv_video.so 
> Ungültiger Maschinenbefehl
> 
> journalctl -b:
> 
>   Okt 24 17:56:50 hermes kernel: traps: vlc[27504] trap invalid opcode 
> ip:89c9d6fb sp:8e550370 error:0 in iHD_drv_video.so[899dc000+3c2000]

Which Intel CPU/GPU do you have? If the instruction is not supported, libva
shouldn't load the driver for your's.

Cheers

> 
> gdb:
> 
> ncq@hermes:/media/ncq/SIMMAX/ccc$ gdb --args vlc 
> 36c3-10961-eng-deu-fra-Boeing_737MAX_Automated_Crashes_sd.mp4
> GNU gdb (Debian 9.2-1) 9.2
> Copyright (C) 2020 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "i686-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> 
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from vlc...
> (No debugging symbols found in vlc)
> (gdb) run
> Starting program: /usr/bin/vlc 
> 36c3-10961-eng-deu-fra-Boeing_737MAX_Automated_Crashes_sd.mp4
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
> VLC media player 3.0.11.1 Vetinari (revision 3.0.11.1-0-g52483f3ca2)
> [New Thread 0xb4b6fb40 (LWP 7805)]
> [New Thread 0xb435db40 (LWP 7806)]
> [New Thread 0xaff9ab40 (LWP 7807)]
> [New Thread 0xa3dffb40 (LWP 7808)]
> [New Thread 0xa3bffb40 (LWP 7809)]
> [00405be0] main libvlc: VLC wird mit dem Standard-Interface ausgeführt. 
> Benutzen Sie 'cvlc', um VLC ohne Interface zu verwenden.
> [New Thread 0x9d37bb40 (LWP 7810)]
> [New Thread 0x9d027b40 (LWP 7811)]
> [Thread 0xa3bffb40 (LWP 7809) exited]
> [New Thread 0xa3bffb40 (LWP 7812)]
> [New Thread 0xa39ffb40 (LWP 7814)]
> [Thread 0xa39ffb40 (LWP 7814) exited]
> [New Thread 0xa37f2b40 (LWP 7815)]
> [Thread 0xa3dffb40 (LWP 7808) exited]
> [Thread 0xa3bffb40 (LWP 7812) exited]
> [New Thread 0xa3bffb40 (LWP 7817)]
> [New Thread 0x9de08b40 (LWP 7819)]
> [New Thread 0x9a5a5b40 (LWP 7820)]
> [New Thread 0x99da4b40 (LWP 7821)]
> [New Thread 0x995a3b40 (LWP 7822)]
> [New Thread 0xa3dffb40 (LWP 7823)]
> [New Thread 0xa39ffb40 (LWP 7824)]
> [New Thread 0x9d4ffb40 (LWP 7825)]
> [Thread 0x9d4ffb40 (LWP 7825) exited]
> [New Thread 0x8d40 (LWP 7826)]
> [New Thread 0x8d1ffb40 (LWP 7827)]
> [New Thread 0x8c9feb40 (LWP 7828)]
> [New Thread 0x9d4ffb40 (LWP 7829)]
> [Thread 0xa39ffb40 (LWP 7824) exited]
> [New Thread 0xa39ffb40 (LWP 7831)]
> [New Thread 0x8b7ffb40 (LWP 7832)]
> [New Thread 0x8abbeb40 (LWP 7833)]
> [New Thread 0x8a3bdb40 (LWP 7834)]
> [New Thread 0x89bbcb40 (LWP 7835)]
> [New Thread 0x893bbb40 (LWP 7836)]
> [9f7c4c20] gl gl: Initialized libplacebo v2.72.0 (API v72)
> libva info: VA-API version 1.9.0
> libva info: Trying to open /usr/lib/i386-linux-gnu/dri/iHD_drv_video.so
> 
> Thread 25 "vlc" received signal SIGILL, Illegal instruction.
> [Switching to Thread 0x8b7ffb40 (LWP 7832)]
> 0x86f9d6fb in ?? () from /usr/lib/i386-linux-gnu/dri/iHD_drv_video.so
> (gdb) bt
> #0  0x86f9d6fb in ?? () from /usr/lib/i386-linux-gnu/dri/iHD_drv_video.so
> #1  0x86f9fb61 in ?? () from /usr/lib/i386-linux-gnu/dri/iHD_drv_video.so
> #2  0x86ceb0a6 in ?? () from /usr/lib/i386-linux-gnu/dri/iHD_drv_video.so
> #3  0xb7fe5e9c in call_init (l=, argc=argc@entry=2, 
> argv=argv@entry=0xb224, env=0xb230) at dl-init.c:72
> #4  0xb7fe5fa2 in call_init (env=0xb230, argv=0xb224, argc=2, 
> l=) at dl-init.c:30
> #5  _dl_init (main_map=, argc=2, argv=0xb224, 
> env=0xb230) at dl-init.c:119
> #6  0xb7fe92a7 in call_dl_init (closure=0x8b7fe660) at dl-open.c:469
> #7  0xb7e9f524 in __GI__dl_catch_exception (exception=, 
> operate=, args=) at dl-error-skeleton.c:182
> #8  0xb7fea08d in dl_open_worker (a=) at dl-open.c:758
> #9  0xb7e9f4c9 in __GI__dl_catch_exception (exception=0x8b7fe790, 
> operate=0xb7fe9990 , args=0x8b7fe79c) at 
> dl-error-skeleton.c:208
> #10 0xb7fe95e6 in _dl_open (file=0x87752e50 
> 

Bug#970606: [Openjdk] Bug#970606: Bug#970606: src:openjdk-*: autopkgtest times out on Debian/Ubuntu infrastructure

2020-10-24 Thread Paul Gevers
Hi Matthias

On 23-10-2020 13:31, Matthias Klose wrote:
> On 10/7/20 10:33 PM, Paul Gevers wrote:
>> Hi Matthias,
>>
>> On 21-09-2020 17:52, Paul Gevers wrote:
 Apparently
 the very same tests don't time out on the buildds.
>>>
>>> I don't know what timeouts apply to buildds, but indeed I think they are
>>> much higher to cope with *building* some extremely big packages.
>>
>> Do you know how much time these tests would take? If so, I wonder if we
>> should make it possible for individual packages to have a longer
>> timeout. It would be work on the debci/ci.d.n side of things, but not
>> impossible of course.
> 
> For an upper bound, use the build time: The very same tests are run during the
> build.

Ack. Side note: I see a hell load of errors and failures in the build
log, is that expected? And some builds took more than a day, is that
reasonable to do for these tests (if they're ignored anyways, your tests
are marked flaky)?

> The other question is, if it's sensible to run the upstream test suite as an
> autopkg test, if it's already run during the build.  Ideally it should only 
> run
> the autopkg tests which test on integration issues with run time dependencies,
> but this would require analyzing some 1 tests and
> 
> For now I just disabled the jdk tests as an autopkg test. So please clear the
> test results, to run it again, and let it migrate.

Also the hotpot test times out, so only having the jdk tests disabled
doesn't really help at this stage.

Paul



signature.asc
Description: OpenPGP digital signature


Bug#972831: tar: produces incorrect TAR+zstd archive when creating archive remotely

2020-10-24 Thread Laurent Bonnaud



Package: tar
Version: 1.30+dfsg-7
Severity: important


Dear Maintainer,

here is a a short list of commands that demonstrate the problem (it needs a SSH 
server):

$ mkdir foo
$ tar --zstd -cvf localhost:foo.tar.zst foo
$ zstd -t foo.tar.zst
foo.tar.zst  : 0 MB... zstd: foo.tar.zst: unsupported format

$ tar --zstd -tvf foo.tar.zst
zstd: /*stdin*\: unsupported format
drwxr-xr-x bonnaudl/bonnaudl 0 2020-10-24 17:41 foo/
tar: Child returned status 1
tar: Error is not recoverable: exiting now

The same thing without SSH (creating the archive on a local filesystem) works 
well.


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

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

Versions of packages tar depends on:
ii  libacl1  2.2.53-8
ii  libc62.31-4
ii  libselinux1  3.1-2+b1

tar recommends no packages.

Versions of packages tar suggests:
ii  bzip21.0.8-4
ii  ncompress4.2.4.6-3
pn  tar-doc  
pn  tar-scripts  
ii  xz-utils 5.2.4-1+b1

-- no debconf information

--
Laurent.



Bug#972115: buster-pu: package sqlite3/3.27.2-3+deb10u1

2020-10-24 Thread GCS
On Sat, Oct 24, 2020 at 8:51 PM Adam D. Barratt
 wrote:
> Control: tags -1 + confirmed
>
> On Mon, 2020-10-12 at 22:50 +0200, Moritz Muehlenhoff wrote:
> > A number of security fixes in sqlite, which don't warrant a DSA.
[...]
> Please go ahead.
 Thanks, uploaded.

Cheers,
Laszlo/GCS



Bug#972840: screen manpage documents "caption top", but it isn't supported

2020-10-24 Thread Josh Triplett
Package: screen
Version: 4.8.0-2
Severity: normal
X-Debbugs-Cc: j...@joshtriplett.org

The screen manual page documents a "caption top" option (as well as
"caption bottom"), but those options aren't actually supported. (I wish
they were; that's https://bugs.debian.org/548845 .)

-- Package-specific info:
File Existence and Permissions
--

drwxr-xr-x 23 root root540 Oct 24 12:28 /run
lrwxrwxrwx  1 root root  4 Oct 26  2017 /var/run -> /run
-rwxr-xr-x  1 root root 470024 May 25 18:50 /usr/bin/screen
-rw-r--r--  1 root root 29 Oct 26  2017 /etc/tmpfiles.d/screen-cleanup.conf
lrwxrwxrwx  1 root root  9 Oct 26  2017 
/lib/systemd/system/screen-cleanup.service -> /dev/null
-rwxr-xr-x  1 root root   1222 May 21  2017 /etc/init.d/screen-cleanup
lrwxrwxrwx  1 root root 24 Oct 26  2017 /etc/rcS.d/S01screen-cleanup -> 
../init.d/screen-cleanup

File contents
-

### /etc/tmpfiles.d/screen-cleanup.conf
__
d /run/screen 1777 root utmp
__

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

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

Versions of packages screen depends on:
ii  libc6 2.31-4
ii  libcrypt1 1:4.4.17-1
ii  libpam0g  1.3.1-5
ii  libtinfo6 6.2+20200918-1
ii  libutempter0  1.1.6-6

screen recommends no packages.

Versions of packages screen suggests:
pn  byobu | screenie | iselect  
ii  ncurses-term6.2+20200918-1

-- no debconf information



Bug#972839: buster-pu: package systemd/241-7~deb10u5

2020-10-24 Thread Michael Biebl
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org

Hi,

I'd like to make a stable upload for systemd fixing two issues:

- #963488
  systemd-network assigns a random network address to bridge interfaces
  Helmut Grohne explicitly asked for a back port of this specific fix

https://salsa.debian.org/systemd-team/systemd/-/commit/99e4b8f0c74731b4a80fa7ed8c31c540a69cc997


- #964926
  systemctl show  prints "Failed to parse bus message: Invalid
  argument" before output

Reported by several people running buster with a kernel >= 5.8 (either
self-compiled or via bpo)

https://salsa.debian.org/systemd-team/systemd/-/commit/efe7d941f7b23d13c87be0b018eea67a56b9378c
https://salsa.debian.org/systemd-team/systemd/-/commit/4bdc4f8c5ed82ea5fe515b9a8b71d321e439cfe9

The package is build tested and tested via the (extensive) autopkgtest
suite, and users also confirmed the fix at least for #964926

The complete debdiff is attached.
The changes do not touch udev code so shouldn't affect d-i. That said, I've CC
kibi for an ACK.

Regards,
Michael



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

Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/debian/changelog b/debian/changelog
index 14ef57f..8c3b276 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+systemd (241-7~deb10u5) buster; urgency=medium
+
+  * basic/cap-list: parse/print numerical capabilities (Closes: #964926)
+  * missing: add new Linux capabilities.
+Linux kernel v5.8 adds two new capabilities. Make sure we can recognize
+them even when built with an older kernel.
+  * networkd: do not generate MAC for bridge device (Closes: #963488)
+
+ -- Michael Biebl   Sat, 24 Oct 2020 20:44:48 +0200
+
 systemd (241-7~deb10u4) buster; urgency=medium
 
   * polkit: when authorizing via PolicyKit re-resolve callback/userdata
diff --git 
a/debian/patches/basic-cap-list-parse-print-numerical-capabilities.patch 
b/debian/patches/basic-cap-list-parse-print-numerical-capabilities.patch
new file mode 100644
index 000..3b9eb09
--- /dev/null
+++ b/debian/patches/basic-cap-list-parse-print-numerical-capabilities.patch
@@ -0,0 +1,87 @@
+From: =?utf-8?q?Zbigniew_J=C4=99drzejewski-Szmek?= 
+Date: Thu, 9 Jul 2020 23:15:47 +0200
+Subject: basic/cap-list: parse/print numerical capabilities
+
+We would refuse to print capabilities which were didn't have a name
+for. The kernel adds new capabilities from time to time, most recently
+cap_bpf. 'systmectl show -p CapabilityBoundingSet ...' would fail with
+"Failed to parse bus message: Invalid argument" because
+capability_set_to_string_alloc() would fail with -EINVAL. So let's
+print such capabilities in hexadecimal:
+
+CapabilityBoundingSet=cap_chown cap_dac_override cap_dac_read_search
+  cap_fowner cap_fsetid cap_kill cap_setgid cap_setuid cap_setpcap
+  cap_linux_immutable cap_net_bind_service cap_net_broadcast cap_net_admin
+  cap_net_raw cap_ipc_lock cap_ipc_owner 0x10 0x11 0x12 0x13 0x14 0x15 0x16
+  0x17 0x18 0x19 0x1a ...
+
+For symmetry, also allow capabilities that we don't know to be specified.
+
+Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1853736.
+
+(cherry picked from commit 417770f3033c426ca848b158d0bf057cd8ad1329)
+---
+ src/basic/cap-list.c | 10 +++---
+ src/test/test-cap-list.c |  4 +++-
+ 2 files changed, 10 insertions(+), 4 deletions(-)
+
+diff --git a/src/basic/cap-list.c b/src/basic/cap-list.c
+index 29a17d9..b72b037 100644
+--- a/src/basic/cap-list.c
 b/src/basic/cap-list.c
+@@ -10,6 +10,7 @@
+ #include "macro.h"
+ #include "missing.h"
+ #include "parse-util.h"
++#include "stdio-util.h"
+ #include "util.h"
+ 
+ static const struct capability_name* lookup_capability(register const char 
*str, register GPERF_LEN_TYPE len);
+@@ -37,7 +38,7 @@ int capability_from_name(const char *name) {
+ /* Try to parse numeric capability */
+ r = safe_atoi(name, );
+ if (r >= 0) {
+-if (i >= 0 && (size_t) i < ELEMENTSOF(capability_names))
++if (i >= 0 && i < 64)
+ return i;
+ else
+ return -EINVAL;
+@@ -65,11 +66,14 @@ int capability_set_to_string_alloc(uint64_t set, char **s) 
{
+ for (i = 0; i < cap_last_cap(); i++)
+ if (set & (UINT64_C(1) << i)) {
+ const char *p;
++char buf[2 + 16 + 1];
+ size_t add;
+ 
+ p = capability_to_name(i);
+-

Bug#948105: Remove build dep on libuhttpmock-dev

2020-10-24 Thread peter green

severity 948105 serious
thanks


In #917104 uhttpmock has been filed for removal, but libgdata still
uses it.


uhttpmock has now been removed from testing/unstable, so libgdata's 
build-dependencies are no longer satisfiable.



Bug#972674: ITP: toolbox -- Unprivileged container development environment

2020-10-24 Thread Hayley Hughes
Hey Gunnar,
That’s a good point you’ve raised.

Personally I’m leaning towards the name podman-toolbox because it explicitly 
states the container runtime which toolbox is designed for; Although it doesn’t 
quite roll off the tongue as nice as container-toolbox.

Although I’m open for suggestions/feedback.

Hayley

> On 24 Oct 2020, at 05:13, Gunnar Wolf  wrote:
> 
> Hayley Hughes dijo [Thu, Oct 22, 2020 at 09:31:30PM +1100]:
>> * Package name : toolbox
>> (...)
>> Toolbox is a tool that offers a familiar package based environment for
>> developing and debugging software that runs fully unprivileged using Podman.
>> 
>> The toolbox environment is based on an OCI image such as fedora-toolbox.
>> This image is used to create a toolbox container that seamlessly integrates
>> with the rest of the operating system.
>> (...)
> 
> The name "toolbox" is very non-descriptive. There are many different
> toolboxes for different things in Debian. Even though this is, of
> course, upstream's chosen project name, I suggest you to consider
> qualifying the name in a way to make it clearer - probably something
> like "toolbox-container", "container-toolbox" or something like that?



Bug#790303: snmpd: "snmpd" fails to "restart" during "logrotate" if it is too busy

2020-10-24 Thread Graham Inggs
Is this fix really still pending?



Bug#964987: marked as pending in reportbug

2020-10-24 Thread Adam D. Barratt
Hi Nis,

On Thu, 2020-07-16 at 19:40 +, Nis Martensen wrote:
> Control: tag -1 pending
> reportbug/debbugs.py: Fix crash with stable-pu update request
[...]
> TypeError: not all arguments converted during string formatting
> 
> Closes: #964987

Is there an ETA for getting the fix for this issue uploaded? It's been
marked as pending for a few months now, and we've had several queries
on IRC from people trying to file p-u requests and hitting this bug.

Regards,

Adam



Bug#970999: buster-pu: package glances/3.1.0-1+deb10u1

2020-10-24 Thread Adam D. Barratt
Control: tags -1 + confirmed
Control: fixed 970812 3.1.3-1

On Fri, 2020-09-25 at 21:12 -0500, Daniel Echeverri wrote:
> Currently, the glances version in buster listen 0.0.0.0 by default.

+  * Now glances listen in 127.0.0.1. (Closes: #970812) 

A few small things...

- The metadata of #970812 should clearly indicate that it is fixed in
unstable, and when. I've fixed that with this mail, but please bear it
in mind for any future updates.

- For the changelog entry:

  - s/in/on/ ("listen on")
  - it might be worth clarifying that the change is to _only_ listen on
localhost

Bearing the above in mind, please go ahead.

Regards,

Adam



Bug#972115: buster-pu: package sqlite3/3.27.2-3+deb10u1

2020-10-24 Thread Adam D. Barratt
Control: tags -1 + confirmed

On Mon, 2020-10-12 at 22:50 +0200, Moritz Muehlenhoff wrote:
> A number of security fixes in sqlite, which don't warrant a DSA.
> This has been tested on a Buster system (along with validating
> included test cases that issues are correctly fixed).

Please go ahead.

Regards,

Adam



Bug#971685: buster-pu: package fish/3.0.2-2+deb10u1

2020-10-24 Thread Adam D. Barratt
Control: tags -1 + confirmed

On Sun, 2020-10-04 at 19:53 -0400, Boyuan Yang wrote:
> I am working on solving https://bugs.debian.org/970777 , a bug that
> made package fish in Debian 10 unusable with sudo in terminal. The
> patch comes from upstream trunk.

Please go ahead.

Regards,

Adam



Bug#972183: buster-pu: package libjpeg-turbo/1:1.5.2-2+deb10u1

2020-10-24 Thread Adam D. Barratt
Control: tags -1 + confirmed

On Tue, 2020-10-13 at 22:39 +0200, Moritz Muehlenhoff wrote:
> This fixes a number of security issues in libjpeg,
> which don't warrant a DSA. Package has been tested on
> a buster system.

Please go ahead.

Regards,

Adam



Bug#972351: buster-pu: package ros-ros-comm/1.14.3+ds1-5+deb10u1

2020-10-24 Thread Adam D. Barratt
Control: tags -1 + confirmed

On Fri, 2020-10-16 at 18:46 +0200, Jochen Sprickerhof wrote:
> CVE-2020-16124 was published with a number of integer overflow in the
> XML RPC layer of ros-ros-comm.

Please go ahead.

Regards,

Adam



Bug#972651: buster-pu: package fastd/18-3+deb10u1

2020-10-24 Thread Adam D. Barratt
Control: tags -1 + confirmed

On Wed, 2020-10-21 at 22:34 +0200, Sven Eckelmann wrote:
> The new packet buffer code (and checks) in v20 revealed a long
> standing issue  in fastd: A buffer with an invalid packet will just
> leak.
> 
> This results in an assert with v20 and memory exhaustion in earlier
> versions.  While v21 (already in unstable) fixed it, the memory
> exhaustion is still a  problem for stable and oldstable.

Please go ahead.

Regards,

Adam



Bug#972694: buster-pu: package node-object-path/0.11.4-2+deb10u1

2020-10-24 Thread Adam D. Barratt
Control: tags -1 + confirmed

On Thu, 2020-10-22 at 18:44 +0200, Xavier Guimard wrote:
> node-object-path is vulnerable to a prototype pollution (CVE-2020-
> 15256)

Please go ahead.

Regards,

Adam



Bug#972158: falkon: FTBFS with Qt 5.15: error: aggregate ‘QPainterPath path’ has incomplete type and cannot be defined

2020-10-24 Thread Dmitry Shachnev
Control: tags -1 + pending

On Tue, Oct 13, 2020 at 03:25:23PM +0300, Dmitry Shachnev wrote:
> Dear Maintainer,
>
> falkon fails to build with Qt 5.15, currently available in experimental.
>
> After successfully rebuilding kguiaddons and kxmlgui, I get this error:
>
>   /<>/src/lib/tools/qztools.cpp:413:18: error: aggregate 
> ‘QPainterPath path’ has incomplete type and cannot be defined
> 413 | QPainterPath path;
> |  ^~~~
>
> This is fixed upstream, see the linked merge request.

I have now uploaded the NMU fixing this to DELAYED/5.

The debdiff is attached, and I have also created a merge request on salsa:

https://salsa.debian.org/georgesk/falkon/-/merge_requests/2

--
Dmitry Shachnev
diff -Nru falkon-3.1.0+dfsg1/debian/changelog falkon-3.1.0+dfsg1/debian/changelog
--- falkon-3.1.0+dfsg1/debian/changelog	2020-08-24 10:55:39.0 +0300
+++ falkon-3.1.0+dfsg1/debian/changelog	2020-10-24 13:51:42.0 +0300
@@ -1,3 +1,10 @@
+falkon (3.1.0+dfsg1-8.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport upstream patch to fix build with Qt 5.15 (closes: #972158).
+
+ -- Dmitry Shachnev   Sat, 24 Oct 2020 13:51:42 +0300
+
 falkon (3.1.0+dfsg1-8) unstable; urgency=medium
 
   * backported the last version of networkmanages.cpp. Closes: #964775
diff -Nru falkon-3.1.0+dfsg1/debian/patches/Fix-build-with-Qt-5.15.patch falkon-3.1.0+dfsg1/debian/patches/Fix-build-with-Qt-5.15.patch
--- falkon-3.1.0+dfsg1/debian/patches/Fix-build-with-Qt-5.15.patch	1970-01-01 03:00:00.0 +0300
+++ falkon-3.1.0+dfsg1/debian/patches/Fix-build-with-Qt-5.15.patch	2020-10-24 13:51:42.0 +0300
@@ -0,0 +1,24 @@
+From: Heiko Becker 
+Date: Sun, 29 Mar 2020 12:53:00 +0200
+Subject: Fix build with Qt 5.15
+
+QPainterPath is no longer included via qtransform.h (since
+5.15.0-beta2, 50d2acdc93b4de2ba56eb67787e2bdcb21dd4bea in qtbase.git).
+
+(cherry picked from commit 2ca83509dbc72dfdfa9cc7103c2b29db31e07f3a)
+---
+ src/lib/tools/qztools.cpp | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/src/lib/tools/qztools.cpp b/src/lib/tools/qztools.cpp
+index 499b225..04f19b7 100644
+--- a/src/lib/tools/qztools.cpp
 b/src/lib/tools/qztools.cpp
+@@ -25,6 +25,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ #include 
+ #include 
+ #include 
diff -Nru falkon-3.1.0+dfsg1/debian/patches/series falkon-3.1.0+dfsg1/debian/patches/series
--- falkon-3.1.0+dfsg1/debian/patches/series	2020-08-24 10:52:18.0 +0300
+++ falkon-3.1.0+dfsg1/debian/patches/series	2020-10-24 13:51:42.0 +0300
@@ -1,3 +1,4 @@
 registerSchemes.patch
 add-source-minified-js.patch
 verticaltabsplugin.cpp.patch
+Fix-build-with-Qt-5.15.patch


signature.asc
Description: PGP signature


Bug#972837: sysvinit: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

2020-10-24 Thread Adriano Rafael Gomes

Package: sysvinit
Tags: l10n patch
Severity: wishlist

Hello,

Please, Could you update the Brazilian Portuguese Translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is
tested with msgfmt and podebconf-display-po.

Kind regards.


pt_BR.po.gz
Description: application/gzip


signature.asc
Description: PGP signature


Bug#972838: fontconfig: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

2020-10-24 Thread Adriano Rafael Gomes

Package: fontconfig
Tags: l10n patch
Severity: wishlist

Hello,

Please, Could you update the Brazilian Portuguese Translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is
tested with msgfmt and podebconf-display-po.

Kind regards.


pt_BR.po.gz
Description: application/gzip


signature.asc
Description: PGP signature


Bug#972836: RFS: streamlink/1.7.0+dfsg-1~bpo10+1 -- CLI for extracting video streams from various websites to a video player

2020-10-24 Thread Alexis Murzeau
Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian-backpo...@lists.debian.org

Dear mentors,

I am looking for a sponsor for my package "streamlink" into Debian
buster-backports repository.

 * Package name: streamlink
   Version : 1.7.0+dfsg-1~bpo10+1
   Upstream Author : Streamlink Team
 * URL : https://streamlink.github.io/
 * License : BSD-2-clause, Apache-2.0, MIT/Expat, SIL-OFL-1.1
   Section : python

It builds those binary packages:

  python3-streamlink - Python module for extracting video streams from various 
websites
  python3-streamlink-doc - CLI for extracting video streams from various 
websites (documentation)
  streamlink - CLI for extracting video streams from various websites to a 
video player

To access further information about this package, please visit the
following URL:
  https://mentors.debian.net/package/streamlink


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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_1.7.0+dfsg-1~bpo10+1.dsc

More information about streamlink can be obtained at
https://streamlink.github.io/

Changes since the last upload to buster-backports:
streamlink (1.7.0+dfsg-1~bpo10+1) buster-backports; urgency=medium

  * Rebuild for buster-backports.

 -- Alexis Murzeau   Sat, 24 Oct 2020 19:28:55 +0200

streamlink (1.7.0+dfsg-1) unstable; urgency=medium

  * New upstream version 1.7.0+dfsg
  * Update patches

 -- Alexis Murzeau   Tue, 20 Oct 2020 23:59:16 +0200


Differences from testing package (1.7.0+dfsg-1):
  * Update d/README.source for buster-backports
  * Revert docs-use-recommonmark-as-an-extension (upstream applied) patch as
Buster has recommonmark 0.4.0 and this patch requires recommonmark 0.5.0+.

Regards,
-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F










signature.asc
Description: OpenPGP digital signature


Bug#972835: mdadm: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

2020-10-24 Thread Adriano Rafael Gomes

Package: mdadm
Tags: l10n patch
Severity: wishlist

Hello,

Please, Could you update the Brazilian Portuguese Translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is
tested with msgfmt and podebconf-display-po.

Kind regards.


pt_BR.po.gz
Description: application/gzip


signature.asc
Description: PGP signature


Bug#971277: dpdk 18.11.10-1~deb10u1 flagged for acceptance

2020-10-24 Thread Adam D. Barratt
On Fri, 2020-10-16 at 17:05 +, Adam D Barratt wrote:
> Package: dpdk
> Version: 18.11.10-1~deb10u1
> 
> Explanation: new upstream stable release; fix remote code execution
> issue [CVE-2020-14374], TOCTOU issues [CVE-2020-14375], buffer
> overflow [CVE-2020-14376], buffer over read [CVE-2020-14377] and
> integer underflow [CVE-2020-14377]

Unfortunately, this FTBFS on armhf (in three attempts across two
different buildds):

--- start log extract ---

FAILED: drivers/a715181@@tmp_rte_pmd_i40e@sta/net_i40e_i40e_rxtx_vec_neon.c.o 
cc -Idrivers/a715181@@tmp_rte_pmd_i40e@sta -Idrivers -I../drivers 
-Idrivers/net/i40e -I../drivers/net/i40e -Idrivers/net/i40e/base 
-I../drivers/net/i40e/base -Ilib/librte_ethdev -I../lib/librte_ethdev -I. -I../ 
-Iconfig -I../config -Ilib/librte_eal/common -I../lib/librte_eal/common 
-Ilib/librte_eal/common/include -I../lib/librte_eal/common/include 
-Ilib/librte_eal/common/include/arch/arm 
-I../lib/librte_eal/common/include/arch/arm 
-I../lib/librte_eal/linuxapp/eal/include 
-Ilib/librte_eal/linuxapp/eal/../../../librte_compat 
-I../lib/librte_eal/linuxapp/eal/../../../librte_compat -Ilib/librte_eal 
-I../lib/librte_eal -Ilib/librte_kvargs/../librte_eal/common/include 
-I../lib/librte_kvargs/../librte_eal/common/include -Ilib/librte_kvargs 
-I../lib/librte_kvargs -Ilib/librte_compat -I../lib/librte_compat 
-Ilib/librte_net -I../lib/librte_net -Ilib/librte_mbuf -I../lib/librte_mbuf 
-Ilib/librte_mempool -I../lib/librte_mempool -Ilib/librte_ring 
-I../lib/librte_ring -Ilib/librte_cmdline/../librte_eal/common/include 
-I../lib/librte_cmdline/../librte_eal/common/include -Ilib/librte_cmdline 
-I../lib/librte_cmdline -Idrivers/bus/pci -I../drivers/bus/pci 
-I../drivers/bus/pci/linux -Ilib/librte_pci -I../lib/librte_pci 
-Idrivers/bus/vdev -I../drivers/bus/vdev -Ilib/librte_hash -I../lib/librte_hash 
-fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -include rte_config.h 
-Wsign-compare -Wcast-qual -Wno-pointer-to-int-cast -D_GNU_SOURCE -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -march=armv7-a 
-mfpu=neon -Wno-format-truncation -DPF_DRIVER -DVF_DRIVER -DINTEGRATED_VF 
-DX722_A0_SUPPORT -DALLOW_EXPERIMENTAL_API  -MD -MQ 
'drivers/a715181@@tmp_rte_pmd_i40e@sta/net_i40e_i40e_rxtx_vec_neon.c.o' -MF 
'drivers/a715181@@tmp_rte_pmd_i40e@sta/net_i40e_i40e_rxtx_vec_neon.c.o.d' -o 
'drivers/a715181@@tmp_rte_pmd_i40e@sta/net_i40e_i40e_rxtx_vec_neon.c.o' -c 
../drivers/net/i40e/i40e_rxtx_vec_neon.c
../drivers/net/i40e/i40e_rxtx_vec_neon.c: In function ‘desc_to_olflags_v’:
../drivers/net/i40e/i40e_rxtx_vec_neon.c:142:31: warning: implicit declaration 
of function ‘vqtbl1q_u8’; did you mean ‘vtbl1_u8’? 
[-Wimplicit-function-declaration]
  vlan0 = vreinterpretq_u32_u8(vqtbl1q_u8(vlan_flags,
   ^~
   vtbl1_u8
../drivers/net/i40e/i40e_rxtx_vec_neon.c:142:31: error: incompatible type for 
argument 1 of ‘vreinterpretq_u32_u8’
  vlan0 = vreinterpretq_u32_u8(vqtbl1q_u8(vlan_flags,
   ^~
   vreinterpretq_u8_u32(vlan1)));
[...]
../drivers/net/i40e/i40e_rxtx_vec_neon.c: In function ‘_recv_raw_pkts_vec’:
../drivers/net/i40e/i40e_rxtx_vec_neon.c:320:11: error: incompatible types when 
assigning to type ‘uint8x16_t’ from type ‘int’
   pkt_mb4 = vqtbl1q_u8(vreinterpretq_u8_u64(descs[3]), shuf_msk);
   ^
../drivers/net/i40e/i40e_rxtx_vec_neon.c:321:11: error: incompatible types when 
assigning to type ‘uint8x16_t’ from type ‘int’
   pkt_mb3 = vqtbl1q_u8(vreinterpretq_u8_u64(descs[2]), shuf_msk);
   ^
../drivers/net/i40e/i40e_rxtx_vec_neon.c:351:11: error: incompatible types when 
assigning to type ‘uint8x16_t’ from type ‘int’
   pkt_mb2 = vqtbl1q_u8(vreinterpretq_u8_u64(descs[1]), shuf_msk);
   ^
../drivers/net/i40e/i40e_rxtx_vec_neon.c:352:11: error: incompatible types when 
assigning to type ‘uint8x16_t’ from type ‘int’
   pkt_mb1 = vqtbl1q_u8(vreinterpretq_u8_u64(descs[0]), shuf_msk);
   ^
../drivers/net/i40e/i40e_rxtx_vec_neon.c:383:13: error: incompatible types when 
assigning to type ‘uint8x16_t’ from type ‘int’
eop_bits = vqtbl1q_u8(eop_bits, eop_shuf_mask);

 ^

--- end log extract ---

Regards,

Adam



Bug#972689: Some more details

2020-10-24 Thread Karsten
In the Multimediasettingsof KDE you can see that the soundblaster card is 
greyed out - why?
This is the card that is working in ALSA, but only sometimes with pulseaudio in 
KDE.

I tried to create an installation of Debian Bullseye, but this is not possible 
too ...
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972820


Bug#972385: petsc4py: autopkgtest failure on amd64: Caught signal number 11 SEGV

2020-10-24 Thread Drew Parsons
Seems the problem is that the kspsolve demo needs the number of 
processors to be a power of 2. Not 5, not 48.




Bug#972834: nvidia-driver: dkms failed after upgrate to linux 5.9 in testing

2020-10-24 Thread Ruben Herold
Package: nvidia-driver
Version: 450.66-1 
Severity: important
Tags: upstream


hi,

the driver is not compatible with linux 5.9. Please upgrade to 450.80.2.

thx


Ruben


-- 
Ruben Herold 
ru...@insecure.pw


pgparUhwXWAjr.pgp
Description: PGP signature


Bug#972833: intel-media-va-driver: SIGSEGV's on use (vlc, finch for example)

2020-10-24 Thread Karsten Hilbert
Package: intel-media-va-driver
Version: 20.3.0+dfsg1-1
Severity: important
Tags: upstream

This happens when running vlc (or finch, for that matter):

VLC media player 3.0.11.1 Vetinari (revision 3.0.11.1-0-g52483f3ca2)
[006aabe0] main libvlc: VLC wird mit dem Standard-Interface ausgeführt. 
Benutzen Sie 'cvlc', um VLC ohne Interface zu verwenden.
[991bf220] gl gl: Initialized libplacebo v2.72.0 (API v72)
libva info: VA-API version 1.9.0
libva info: Trying to open /usr/lib/i386-linux-gnu/dri/iHD_drv_video.so 
Ungültiger Maschinenbefehl

journalctl -b:

Okt 24 17:56:50 hermes kernel: traps: vlc[27504] trap invalid opcode 
ip:89c9d6fb sp:8e550370 error:0 in iHD_drv_video.so[899dc000+3c2000]

gdb:

ncq@hermes:/media/ncq/SIMMAX/ccc$ gdb --args vlc 
36c3-10961-eng-deu-fra-Boeing_737MAX_Automated_Crashes_sd.mp4
GNU gdb (Debian 9.2-1) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from vlc...
(No debugging symbols found in vlc)
(gdb) run
Starting program: /usr/bin/vlc 
36c3-10961-eng-deu-fra-Boeing_737MAX_Automated_Crashes_sd.mp4
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
VLC media player 3.0.11.1 Vetinari (revision 3.0.11.1-0-g52483f3ca2)
[New Thread 0xb4b6fb40 (LWP 7805)]
[New Thread 0xb435db40 (LWP 7806)]
[New Thread 0xaff9ab40 (LWP 7807)]
[New Thread 0xa3dffb40 (LWP 7808)]
[New Thread 0xa3bffb40 (LWP 7809)]
[00405be0] main libvlc: VLC wird mit dem Standard-Interface ausgeführt. 
Benutzen Sie 'cvlc', um VLC ohne Interface zu verwenden.
[New Thread 0x9d37bb40 (LWP 7810)]
[New Thread 0x9d027b40 (LWP 7811)]
[Thread 0xa3bffb40 (LWP 7809) exited]
[New Thread 0xa3bffb40 (LWP 7812)]
[New Thread 0xa39ffb40 (LWP 7814)]
[Thread 0xa39ffb40 (LWP 7814) exited]
[New Thread 0xa37f2b40 (LWP 7815)]
[Thread 0xa3dffb40 (LWP 7808) exited]
[Thread 0xa3bffb40 (LWP 7812) exited]
[New Thread 0xa3bffb40 (LWP 7817)]
[New Thread 0x9de08b40 (LWP 7819)]
[New Thread 0x9a5a5b40 (LWP 7820)]
[New Thread 0x99da4b40 (LWP 7821)]
[New Thread 0x995a3b40 (LWP 7822)]
[New Thread 0xa3dffb40 (LWP 7823)]
[New Thread 0xa39ffb40 (LWP 7824)]
[New Thread 0x9d4ffb40 (LWP 7825)]
[Thread 0x9d4ffb40 (LWP 7825) exited]
[New Thread 0x8d40 (LWP 7826)]
[New Thread 0x8d1ffb40 (LWP 7827)]
[New Thread 0x8c9feb40 (LWP 7828)]
[New Thread 0x9d4ffb40 (LWP 7829)]
[Thread 0xa39ffb40 (LWP 7824) exited]
[New Thread 0xa39ffb40 (LWP 7831)]
[New Thread 0x8b7ffb40 (LWP 7832)]
[New Thread 0x8abbeb40 (LWP 7833)]
[New Thread 0x8a3bdb40 (LWP 7834)]
[New Thread 0x89bbcb40 (LWP 7835)]
[New Thread 0x893bbb40 (LWP 7836)]
[9f7c4c20] gl gl: Initialized libplacebo v2.72.0 (API v72)
libva info: VA-API version 1.9.0
libva info: Trying to open /usr/lib/i386-linux-gnu/dri/iHD_drv_video.so

Thread 25 "vlc" received signal SIGILL, Illegal instruction.
[Switching to Thread 0x8b7ffb40 (LWP 7832)]
0x86f9d6fb in ?? () from /usr/lib/i386-linux-gnu/dri/iHD_drv_video.so
(gdb) bt
#0  0x86f9d6fb in ?? () from /usr/lib/i386-linux-gnu/dri/iHD_drv_video.so
#1  0x86f9fb61 in ?? () from /usr/lib/i386-linux-gnu/dri/iHD_drv_video.so
#2  0x86ceb0a6 in ?? () from /usr/lib/i386-linux-gnu/dri/iHD_drv_video.so
#3  0xb7fe5e9c in call_init (l=, argc=argc@entry=2, 
argv=argv@entry=0xb224, env=0xb230) at dl-init.c:72
#4  0xb7fe5fa2 in call_init (env=0xb230, argv=0xb224, argc=2, 
l=) at dl-init.c:30
#5  _dl_init (main_map=, argc=2, argv=0xb224, 
env=0xb230) at dl-init.c:119
#6  0xb7fe92a7 in call_dl_init (closure=0x8b7fe660) at dl-open.c:469
#7  0xb7e9f524 in __GI__dl_catch_exception (exception=, 
operate=, args=) at dl-error-skeleton.c:182
#8  0xb7fea08d in dl_open_worker (a=) at dl-open.c:758
#9  0xb7e9f4c9 in __GI__dl_catch_exception (exception=0x8b7fe790, 
operate=0xb7fe9990 , args=0x8b7fe79c) at dl-error-skeleton.c:208
#10 0xb7fe95e6 in _dl_open (file=0x87752e50 
"/usr/lib/i386-linux-gnu/dri/iHD_drv_video.so", mode=-2147479294, 
caller_dlopen=0x8dc67cc3, nsid=, argc=2, argv=0xb224, 
env=0xb230) at dl-open.c:837
#11 0xb7f4a2c8 in dlopen_doit (a=0x8b7fe99c) at dlopen.c:66
#12 0xb7e9f4c9 in __GI__dl_catch_exception (exception=0x8b7fe930, 
operate=0xb7f4a250 , args=0x8b7fe99c) at dl-error-skeleton.c:208
#13 0xb7e9f590 in __GI__dl_catch_error (objname=0xa06fbb0c, 
errstring=0xa06fbb10, mallocedp=0xa06fbb08, 

Bug#972514: nvidia-kernel-dkms: fails to build with linux-headers-5.9.0-1-amd64

2020-10-24 Thread Alexander Heinlein
Same problem here.

Installing nvidia-kernel-dkms from unstable (455.23.04-1) works.



Bug#968951: [pkg-apparmor] Bug#968951: apparmor-profiles: Profile incomplete for pidgin and telepathy

2020-10-24 Thread intrigeri
Control: reassign -1 telepathy-mission-control-5
Control: retitle -1 AppArmor profile conflicts with pidgin-openpgp

Hi,

Henning Follmann (2020-08-24):
> When you try to login to a jabber server either via empathy or pidgin
> /usr/lib/purple-2/XEP-0027.pl will be called but fails because of an
> incomplete AppArmor profile:
>
> Aug 06 19:55:20 typer audit[4039]: AVC apparmor="DENIED" operation="open" 
> profile="/usr/lib/telepathy/telepathy-*" 
> name="/usr/share/perl/5.28.1/strict.pm"
> +pid=4039 comm="telepathy-haze" requested_mask="r" denied
> Aug 06 19:55:20 typer org.freedesktop.Telepathy.ConnectionManager.haze[3320]: 
> Can't locate strict.pm:   /usr/share/perl/5.28/strict.pm: Permission denied at
> +/usr/lib/purple-2/XEP-0027.pl line 31.
> Aug 06 19:55:20 typer org.freedesktop.Telepathy.ConnectionManager.haze[3320]: 
> BEGIN failed--compilation aborted at /usr/lib/purple-2/XEP-0027.pl line 31.
> Aug 06 19:55:20 typer kernel: audit: type=1400 audit(1596758120.240:27): 
> apparmor="DENIED" operation="open" profile="/usr/lib/telepathy/telepathy-*"
> +name="/usr/share/perl/5.28.1/strict.pm" pid=4039 comm="telepat

Reassigning to the package that ships the telepathy profile.
I suppose it's the same problem as for the usr.bin.pidgin profile,
for which I did this:
https://salsa.debian.org/apparmor-team/apparmor-profiles-extra/-/commit/eedb248ece01e65ce5572f5cc0b1a59c1bfc8f06

> or for pidgin
>
> Aug 18 09:58:17 typer audit[2790]: AVC apparmor="DENIED" operation="open" 
> profile="/usr/bin/pidgin" name="/usr/share/perl/5.28.1/strict.pm" pid=2790 
> comm=
> Aug 18 09:58:17 typer kernel: audit: type=1400 audit(1597759097.069:42): 
> apparmor="DENIED" operation="open" profile="/usr/bin/pidgin" 
> name="/usr/share/per

The pidgin-openpgp part is tracked by https://bugs.debian.org/968607
so let's focus on Telepathy here.

Cheers!



Bug#968607: pidgin-openpgp: AppArmor profil prevents execution of XEP-0027.pl

2020-10-24 Thread intrigeri
Control: tag -1 + pending

Hi,

Henning Follmann (2020-08-18):
> On start of pidgin I get this error:
>  Can't locate strict.pm:   /usr/share/perl/5.28/strict.pm: Permission denied 
> at /usr/lib/purple-2/XEP-0027.pl line 31.
> BEGIN failed--compilation aborted at /usr/lib/purple-2/XEP-0027.pl line 31.
>
> Journalctl info:
> Aug 18 09:58:17 typer audit[2790]: AVC apparmor="DENIED" operation="open" 
> profile="/usr/bin/pidgin" name="/usr/share/perl/5.28.1/strict.pm" pid=2790 
> comm=
> Aug 18 09:58:17 typer kernel: audit: type=1400 audit(1597759097.069:42): 
> apparmor="DENIED" operation="open" profile="/usr/bin/pidgin" 
> name="/usr/share/per

Given pidgin-openpgp was removed from testing and sid,
IMO it's not worth adding support for it in the AppArmor profile,
so let's instead ensure the obsolete pidgin-openpgp package
gets removed if apparmor-profiles-extra is installed:

https://salsa.debian.org/apparmor-team/apparmor-profiles-extra/-/commit/eedb248ece01e65ce5572f5cc0b1a59c1bfc8f06

Cheers!



Bug#972831: tar: produces incorrect TAR+zstd archive when creating archive remotely

2020-10-24 Thread Bdale Garbee
Laurent Bonnaud  writes:

> $ tar --zstd -cvf localhost:foo.tar.zst foo

I took a quick look and the problem is with the use of localhost: in the
filename, it appears to be unrelated to the compression algorithm
chosen.  I don't have time to chase this further today.

Bdale


signature.asc
Description: PGP signature


Bug#972832: dialog: can't change menu border lines

2020-10-24 Thread Ennio-Sr
Package: dialog
Version: 1.3-20160828-2
Severity: minor

Hi all!

As I like to work on virtual console with black background, when I try to
use dialog with my personalized colors (and a .dialogrc file) the 'upper
left inner box'  and 'lower right external box' lines appear as black
lines on white background, whereas the remaining lines come out on a black
background as the whole dialog background.
Deleting the .dialogrc file the corner lines are still in differnet
colors, but on the same 'grey' background.

What can I do to correct these results?
Thanks for your attention,
   Ennio


PS: My PC is quite old and I'm afraid there would be no room to upgrade
and install a newer dialog version


-- System Information:
Debian Release: 9.13
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages dialog depends on:
ii  debianutils   4.8.1.1
ii  libc6 2.24-11+deb9u4
ii  libncursesw5  6.0+20161126-1+deb9u2
ii  libtinfo5 6.0+20161126-1+deb9u2

dialog recommends no packages.

dialog suggests no packages.

-- no debconf information



Bug#972387: [Info-mtools] mtools does not work in Turkish locale

2020-10-24 Thread Alain Knaff

Hi,

Thanks for the details, this is now fixed in 4.0.25

Regards,

Alain


On 22/10/2020 19:01, Pali Rohár wrote:

Hello!

On Thursday 22 October 2020 16:55:04 Chris Lamb wrote:

   $ LC_CTYPE=tr_TR.UTF-8 mtools
   Syntax error at line 5 for drive A: column 9 in file /etc/mtools.conf: 
unrecognized keyword

   $ echo $?
   1


...

As I describe in my followup to that bug, I can confirm that this is
indeed locale issue, as commenting out the setlocale(3) call at the
top of the "main" entry point fixes this issue.

The following "patch" against mtools.c also ""works"" for me:

   +#ifdef HAVE_SETLOCALE
   +   char *old_locale = setlocale(LC_ALL, NULL);
   +   setlocale(LC_ALL, "C");
   +   read_config();
   +   setlocale(LC_ALL, old_locale);
   +#else
   read_config();
   +#endif


.. but this is obviously not right, as it would mean that genuine
syntax errors printed in read_config() would not be translated into,
well, Turkish. Can't seem to get a "C" locale version of toupper(3) to
work right this second, and am assuming you folks will have a cleaner
solution anyway, hence forwarding this to you.


IIRC toupper() for lowercase i with dot in Turkish locale returns
uppercase I with dot. In English or C locale it is uppercase I without
dot.

I guess that for case-insensitive parsing of config options (which are
written in English) should be used toupper() variant in C locale.

There is a standard POSIX function toupper_l() which takes as a second
argument locale. So I think that for reading config file it should be
used function toupper_l() with C locale instead of locale-dependent
toupper() function.





Bug#972339: armhf: hpcups crashes with free() invalid pointer for some printers

2020-10-24 Thread Bernhard Übelacker
Dear Maintainer,
I could reproduce this issue too.

Attached is a valgrind run showing one invalid write
and a gdb session showing the issue.

It looks like mallocs management data, which resides in the 8 bytes
before a returned pointer, gets overwritten and therefore
the free fails because "mchunk_size" is then 0.

Kind regards,
Bernhard


Old value = 6057
New value = 0
__memcpy_neon () at ../sysdeps/arm/armv7/multiarch/memcpy_impl.S:295
warning: Source file is more recent than executable.
295 tst count, #4
1: compressBuf = 
2: /x *(int*)(0x7f5f43e8-4) = 0x0
(gdb) bt
#0  __memcpy_neon () at ../sysdeps/arm/armv7/multiarch/memcpy_impl.S:295
#1  0x7f55b8d2 in memcpy (__len=379, __src=, 
__dest=) at 
/usr/include/arm-linux-gnueabihf/bits/string_fortified.h:34
#2  Mode9::Process (this=0x7f5e0e70, input=0x7f5e0e84) at 
prnt/hpcups/Mode9.cpp:405
#3  0x7f562de0 in Pipeline::Process (raster=, 
this=0x7f5d7340) at prnt/hpcups/Pipeline.cpp:79
#4  Pipeline::Execute (this=0x7f5d7340, InputRaster=) at 
prnt/hpcups/Pipeline.cpp:79
#5  0x7f562e02 in Pipeline::Execute (this=0x7f5e6b88, 
InputRaster=) at prnt/hpcups/Pipeline.cpp:83
#6  0x7f562e02 in Pipeline::Execute (this=0x7f5e6b70, 
InputRaster=) at prnt/hpcups/Pipeline.cpp:83
#7  0x7f55a20a in HPCupsFilter::processRasterData (this=0x7f5b87c4 
, cups_raster=) at prnt/hpcups/HPCupsFilter.cpp:766
#8  0x7f55a6ee in HPCupsFilter::StartPrintJob (this=0x7f5b87c4 , 
argc=6, argv=0xbefff7b4) at prnt/hpcups/HPCupsFilter.cpp:584
#9  0xb6bd9a20 in __libc_start_main (main=0x7f5587d1 , 
argc=6, argv=0xbefff7b4, init=, fini=0x7f56ed5d 
<__libc_csu_fini>, rtld_fini=0xb6fe1075 <_dl_fini>, stack_end=0xbefff7b4) at 
libc-start.c:308
#10 0x7f55889c in _start () at prnt/hpcups/HPCupsFilter.cpp:919


https://sources.debian.org/src/hplip/3.20.5+dfsg0-3/prnt/hpcups/Mode9.cpp/#L405


# Bullseye/testing chroot 2020-10-23 running on Android/LineageOS kernel


apt update
apt dist-upgrade


apt install mc htop psmisc net-tools strace sshfs wget gdb gdbserver cups 
printer-driver-hpcups printer-driver-hpcups-dbgsym
apt build-dep libc6



root@localhost:~# lscpu
Architecture: armv7l
Byte Order:   Little Endian
CPU(s):   4
On-line CPU(s) list:  0
Off-line CPU(s) list: 1-3
Thread(s) per core:   1
Core(s) per socket:   1
Socket(s):1
Vendor ID:Qualcomm
Model:0
Model name:   Krait
Stepping: 0x1
CPU max MHz:  1728,
CPU min MHz:  384,
BogoMIPS: 13.50
Flags:swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 
idiva idivt
root@localhost:~# uname -a
Linux localhost 3.4.113-g2fff5b1955c0 #1 SMP PREEMPT Sun Mar 8 06:23:52 CST 
2020 armv7l GNU/Linux

groupadd -g 3001 aid_net_bt_admin
groupadd -g 3002 aid_net_bt
groupadd -g 3003 aid_inet
groupadd -g 3004 aid_net_raw
groupadd -g 3005 aid_net_admin
groupadd -g 3006 aid_net_bw_stats
groupadd -g 3007 aid_net_bw_acct
groupadd -g 3008 aid_net_bt_stack
usermod -G 3003,3004 -a root
usermod -G 3003 -a benutzer
usermod -g 3003 -G 3003,3004 -a _apt

root@localhost:~# dpkg -l | grep driver-hpcups
ii  printer-driver-hpcups 3.20.5+dfsg0-3+b1  armhf
HP Linux Printing and Imaging - CUPS Raster driver (hpcups)
ii  printer-driver-hpcups-dbgsym  3.20.5+dfsg0-3+b1  armhf
debug symbols for printer-driver-hpcups






mkdir /home/benutzer/source/libc6/orig -p
cd/home/benutzer/source/libc6/orig
apt source libc6
cd










wget 
https://sources.debian.org/data/main/h/hplip/3.20.9+dfsg0-3/ppd/hpcups/hp-officejet_pro_1150c.ppd
gzip hp-officejet_pro_1150c.ppd

export PPD=/home/benutzer/hp-officejet_pro_1150c.ppd.gz
/usr/lib/cups/filter/pdftopdf   1 debian '' 1 '' 
print_step_1.pdf
/usr/lib/cups/filter/gstoraster 1 debian '' 1 '' print_step_2.raster
/usr/lib/cups/filter/hpcups 1 debian '' 1 '' print_step_3.hpcups




/usr/bin/gdbserver localhost: /usr/lib/cups/filter/hpcups 1 debian '' 1 
'' print_step_3.hpcups

gdb -q
set width 0
set pagination off
target remote localhost:
cont




benutzer@localhost:~$ /usr/bin/gdbserver localhost: 
/usr/lib/cups/filter/hpcups 1 debian x 1 x print_step_3.hpcups
Process /usr/lib/cups/filter/hpcups created; pid = 9723
Listening on port 
Remote debugging from host ::1, port 42055
STATE: -marker-supply-low-warning
PAGE: 1 1
free(): invalid pointer



benutzer@localhost:~$ gdb -q
(gdb) set width 0
(gdb) set pagination off
(gdb) target remote localhost:
Remote debugging using localhost:
Reading /usr/lib/cups/filter/hpcups from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to 
access files locally instead.
Reading /usr/lib/cups/filter/hpcups from remote target...
Reading symbols from target:/usr/lib/cups/filter/hpcups...
Reading /usr/lib/cups/filter/25b6b40d5874920ba6c57ce85bb60b35661f71.debug from 

Bug#941978: Acknowledgement (pavucontrol: Use sink_name for labels instead of device.description)

2020-10-24 Thread Benjamin Bänziger
Any help with this, please?

Pavucontrol from other users/distros don't seem to have this issue.

The command to generate the sinks is for example "pacmd load-module
module-null-sink sink_name=HF", so I expect the label to be "HF" and not
"Null Output".


Thank you


Bug#972791: setzer: "Namespace GtkSource not available for version 4"

2020-10-24 Thread Stephan Lachnit
Fixed in 0.3.4-1, which is on Salsa on Mentors already.
@Anton can you upload it?

Cheers,
Stephan



Bug#972830: Britney fails to try Go packages together

2020-10-24 Thread Adrian Bunk
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: britney

trying: golang-github-spf13-cobra
skipped: golang-github-spf13-cobra (2, 17, 1)
got: 31+0: a-14:a-0:a-0:a-0:i-16:m-0:m-0:p-0:s-1
* amd64: golang-etcd-server-dev, golang-github-containers-buildah-dev, 
golang-github-containers-common-dev, golang-github-containers-image-dev, 
golang-github-docker-docker-dev, golang-github-docker-leadership-dev, 
golang-github-docker-libkv-dev, golang-github-docker-notary-dev, 
golang-github-fsouza-go-dockerclient-dev, 
golang-github-openshift-imagebuilder-dev, 
golang-github-samalba-dockerclient-dev, golang-github-tonistiigi-fsutil-dev, 
golang-github-xordataexchange-crypt-dev
trying: golang-github-urfave-cli
skipped: golang-github-urfave-cli (2, 18, 0)
got: 31+0: a-14:a-0:a-0:a-0:i-16:m-0:m-0:p-0:s-1
* amd64: golang-etcd-server-dev, golang-github-containers-buildah-dev, 
golang-github-containers-common-dev, golang-github-containers-image-dev, 
golang-github-docker-docker-dev, golang-github-docker-leadership-dev, 
golang-github-docker-libkv-dev, golang-github-docker-notary-dev, 
golang-github-fsouza-go-dockerclient-dev, 
golang-github-openshift-imagebuilder-dev, 
golang-github-samalba-dockerclient-dev, golang-github-tonistiigi-fsutil-dev, 
golang-github-xordataexchange-crypt-dev


Note that the "newly uninstallable" packages in these lists are the same.

Installing all these "newly uninstallable" packages in bullseye,
apt does find the correct solution of upgrading golang-github-spf13-cobra
and golang-github-urfave-cli together:

# apt-get -t unstable install golang-github-spf13-cobra-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  golang-github-cpuguy83-go-md2man-v2-dev
  golang-github-russross-blackfriday-v2-dev
  golang-github-shurcool-sanitized-anchor-name-dev
  golang-github-urfave-cli-dev
The following packages will be REMOVED:
  golang-github-cpuguy83-go-md2man-dev golang-github-russross-blackfriday-dev
The following NEW packages will be installed:
  golang-github-cpuguy83-go-md2man-v2-dev
  golang-github-russross-blackfriday-v2-dev
  golang-github-shurcool-sanitized-anchor-name-dev
The following packages will be upgraded:
  golang-github-spf13-cobra-dev golang-github-urfave-cli-dev
2 upgraded, 3 newly installed, 2 to remove



Bug#972385: 5 cpu also fails

2020-10-24 Thread Drew Parsons

forwarded 972385 https://gitlab.com/petsc/petsc4py/-/issues/7
thanks

The problem is not as simple as the kspsolve demo being too small to 
distribute over 48 CPUs. The failure happens also with 5 processes.




Bug#972829: rust-lldb, depends on nonexistent package in buster.

2020-10-24 Thread peter green

Package: rust-lldb
Version: 1.41.1+dfsg1-1~deb10u1
Severity: serious

rust-lldb in buster now depends on python3-lldb-7, however it does not appear 
that this package has ever existed in Debian.



Bug#965360: apparmor-profiles: Please meke seperate packages for each apparmor profile

2020-10-24 Thread Mikhail Morfikov
On 24/10/2020 14.42, intrigeri wrote:
> Control: tag -1 + moreinfo
> 
> Hi,
> 
> Mikhail Morfikov (2020-07-20):
>> currently when the apparmor-profiles package is installed, it installs 
>> several
>> apparmor profile files. In this way users can have all or none of the 
>> profiles
>> installed in their systems. Sometimes a user wants only a specific profile 
>> (or
>> profiles) installed and doesn't really want the other profiles to be 
>> installed
>> as well because:
>>  - he doesn't need the other profiles,
>>  - he has his own alternative profiles, which differ in rule sets,
>>  - the other profiles simply cause some issues with applications they 
>> confine.
> 
>> What do you think about another approach, which is to create separate 
>> packages
>> containing individual apparmor profiles? For instance, there's the
>> usr.sbin.dnsmasq file which is related to the dnsmasq package. In this case
>> there could be a package named dnsmasq-apparmor-profile which would include 
>> the
>> usr.sbin.dnsmasq file. If a user wanted to install dnsmasq and also wanted it
>> to be confined by the default apparmor profile provided by Debian, he could
>> also install dnsmasq-apparmor-profile, which wouldn't affect any other app
>> functionality.
> 
> The profiles shipped by the apparmor-profiles package are installed in
> complain mode. Then the user may choose to enforce the profiles they
> need. To me, it seems to already provide the kind of flexibility
> you're wishing for, with a much lower overhead on the package
> maintenance side. What did I miss?
> 
> Apart of this, the way the Debian archive works, having many tiny
> packages is problematic, so I don't think your proposal would be
> acceptable by the project. I'm not closing this bug report just yet as
> I'd like to first better understand what the current setup is lacking
> for you.
> 
> Cheers!
> 

There are three ways of installing apparmor profiles in debian:
- an app's package contains some apparmor profile
- some packages contain lots of apparmor profiles
- there are a few packages which contain an app's apparmor profile itself, for 
  instance fwknop-apparmor-profile

So it's a mess.

It would be better to have just one way of installing official debian apparmor 
profiles for apps, i.e. the 3rd option above.  Of course a user doesn't 
have to install the big package with all the profiles, but when I see bunch of 
apparmor profiles that I don't really need, I simply skip the package or 
extract the needed profile and forget about the package. So basically having 
multiple profiles in one package makes people less likely to test any of 
the profiles included in it and hence less likely to report any issues. It 
would 
be nice to have profiles in individual packages, so users could decide what 
they want to install. 

What if I had my own profile that would match to a specific one that is 
provided 
by apparmor-profiles? What would I have to do in order to install/upgrade the 
rest of the profiles from the package and leave my profile intact? It's very 
inconvenient and problematic for the end user to handle such packages.

BTW: Why having many small packages is a problem for debian archive? 


OpenPGP_0x32D9CB634796CCA1.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature


Bug#919350: Followup-For: Bug #919350

2020-10-24 Thread Scherb, Carsten
Dear Maintainer,

the problem still exists in hyperv-daemons 5.8.10-1~bpo10+1

# systemctl status hv-kvp-daemon
● hv-kvp-daemon.service - Hyper-V key-value pair (KVP) daemon
   Loaded: loaded (/lib/systemd/system/hv-kvp-daemon.service; disabled; vendor 
preset: enabled)
   Active: active (running) since Thu 2020-10-22 18:24:30 CEST; 1 day 22h ago
 Main PID: 427 (hv_kvp_daemon)
Tasks: 1 (limit: 4625)
   Memory: 2.9M
   CGroup: /system.slice/hv-kvp-daemon.service
   └─427 /usr/sbin/hv_kvp_daemon -n

Okt 24 16:11:55 proxyk hv_kvp_daemon[427]: sh: 1: 
/usr/libexec/hypervkvpd/hv_get_dns_info: not found
Okt 24 16:11:55 proxyk hv_kvp_daemon[427]: sh: 1: 
/usr/libexec/hypervkvpd/hv_get_dhcp_info: not found
Okt 24 16:17:09 proxyk hv_kvp_daemon[427]: sh: 1: 
/usr/libexec/hypervkvpd/hv_get_dns_info: not found
Okt 24 16:17:09 proxyk hv_kvp_daemon[427]: sh: 1: 
/usr/libexec/hypervkvpd/hv_get_dhcp_info: not found
Okt 24 16:17:09 proxyk hv_kvp_daemon[427]: sh: 1: 
/usr/libexec/hypervkvpd/hv_get_dns_info: not found
Okt 24 16:17:09 proxyk hv_kvp_daemon[427]: sh: 1: 
/usr/libexec/hypervkvpd/hv_get_dhcp_info: not found
Okt 24 16:22:23 proxyk hv_kvp_daemon[427]: sh: 1: 
/usr/libexec/hypervkvpd/hv_get_dns_info: not found
Okt 24 16:22:23 proxyk hv_kvp_daemon[427]: sh: 1: 
/usr/libexec/hypervkvpd/hv_get_dhcp_info: not found
Okt 24 16:22:24 proxyk hv_kvp_daemon[427]: sh: 1: 
/usr/libexec/hypervkvpd/hv_get_dns_info: not found
Okt 24 16:22:24 proxyk hv_kvp_daemon[427]: sh: 1: 
/usr/libexec/hypervkvpd/hv_get_dhcp_info: not found



Bug#972828: ITP: calcium -- exact computation with real and complex numbers

2020-10-24 Thread Julien Puydt
Package: wnpp
Severity: wishlist
Owner: Julien Puydt 
X-Debbugs-CC: debian-scie...@lists.debian.org

* Package name: calcium
Version: 0.2.0
Upstream author: Fredrick Johansson
* License: LGPL-2.1+
URL: http://fredrikj.net/calcium/
Programming language: C
Description: exact computation with real and complex numbers


This software is still pretty experimental, but there are already
discussions of using it in sagemath -- and its author has a track-
record of delivering good software.

I would like to package it (and maintain, of course!) within the Debian
Science team ; perhaps I'll start by uploading it to experimental,
waiting for either more definite plans to use it in sagemath or a more
stable version before uploading to unstable.

Cheers,

JP



Bug#972827: libgiac-dev: should include config.h

2020-10-24 Thread Benjamin Barenblat
Package: libgiac-dev
Version: 1.4.9.69+dfsg1-2
Severity: grave

Many Giac headers #include "config.h", and they use its contents in such
a way that config.h is essential to define the library ABI. (For
example, some members are gated behind #ifdef HAVE_LIBPTHREAD.)
Developing against Giac without the exact config.h generated during the
library build thus triggers an ABI mismatch, usually manifesting as a
segfault.

Requiring Giac’s config.h is unfortunate, and upstream recognizes it –
giac/gen.h includes the note

  // FIXME: macros defined in config.h are not welcome in a public header!

Until that FIXME is resolved, though, Debian needs to ship Giac’s
config.h with the other Giac headers.


signature.asc
Description: PGP signature


Bug#972826: gourmet: Typo in reccard.py - gourmet does not start

2020-10-24 Thread Thomas Renard
Package: gourmet
Version: 0.17.5~alpha2-3
Severity: normal

Dear Maintainer,

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

* Starting of gourmet fails with:
ceback (most recent call last):
  File "/usr/local/bin/gourmet", line 11, in 
load_entry_point('gourmet==0.17.5', 'console_scripts', 'gourmet')()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 473, in 
load_entry_point
return get_distribution(dist).load_entry_point(group, name)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2843, 
in load_entry_point
return ep.load()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2447, 
in load
return self.resolve()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2453, 
in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File 
"/usr/local/lib/python3.8/dist-packages/gourmet-0.17.5-py3.8.egg/gourmet/GourmetRecipeManager.py",
 line 10, in 
from gourmet import (
  File 
"/usr/local/lib/python3.8/dist-packages/gourmet-0.17.5-py3.8.egg/gourmet/reccard.py",
 line 26, in 
from gourmet.gtk_extra.pango_buffer import PangoBuffer
ModuleNotFoundError: No module named 'gourmet.gtk_extra'

* can be fixed by correcting line 26 in reccard.py:
from gourmet.gtk_extras.pango_buffer import PangoBuffer

*** End of the template - remove these template lines ***


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

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

Versions of packages gourmet depends on:
ii  gir1.2-gtk-3.0  3.24.23-2
ii  python3 3.8.2-3
ii  python3-bs4 4.9.3-1
ii  python3-gi  3.38.0-1+b1
ii  python3-pil 7.2.0-1+b1
ii  python3-reportlab   3.5.53-1
ii  python3-sqlalchemy  1.3.19+ds1-1

Versions of packages gourmet recommends:
pn  kpython3-gtkspellcheck
ii  python3-lxml  4.5.2-1+b1
ii  python3-pyglet1.4.10-1
pn  python3-scrape-schema-recipe  

gourmet suggests no packages.

-- no debconf information



Bug#972818: okular: Wrong page order if printing a subset of pages

2020-10-24 Thread ale
Package: okular
Followup-For: Bug #972818

Dear Maintainer,

this happens with a network printer also with other programs and other PCs,
so this is not an Okular's problem.

Who is interested can check bug #972825 .

Thank you for your patience



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

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

Versions of packages okular depends on:
ii  kinit 5.54.0-1
ii  kio   5.54.1-1
ii  libc6 2.30-8
ii  libfreetype6  2.10.1-2
ii  libjpeg62-turbo   1:1.5.2-2+b1
ii  libkf5activities5 5.70.0-1
ii  libkf5archive55.70.0-1
ii  libkf5bookmarks5  5.70.0-1
ii  libkf5codecs5 5.70.0-1
ii  libkf5completion5 5.70.0-1
ii  libkf5configcore5 5.70.0-1
ii  libkf5configgui5  5.70.0-1
ii  libkf5configwidgets5  5.70.0-1
ii  libkf5coreaddons5 5.70.0-1
ii  libkf5crash5  5.70.0-1
ii  libkf5i18n5   5.70.0-1
ii  libkf5iconthemes5 5.70.0-1
ii  libkf5itemviews5  5.70.0-1
ii  libkf5jobwidgets5 5.70.0-1
ii  libkf5kexiv2-15.0.0   17.08.3-1
ii  libkf5kiocore55.70.1-1
ii  libkf5kiowidgets5 5.70.1-1
ii  libkf5parts5  5.70.0-1
ii  libkf5pty55.70.0-1
ii  libkf5purpose-bin 5.70.0-2
ii  libkf5purpose55.70.0-2
ii  libkf5service-bin 5.70.0-1
ii  libkf5service55.70.0-1
ii  libkf5textwidgets55.70.0-1
ii  libkf5wallet-bin  5.62.0-1+b1
ii  libkf5wallet5 5.62.0-1+b1
ii  libkf5widgetsaddons5  5.70.0-1
ii  libkf5windowsystem5   5.70.0-1
ii  libkf5xmlgui5 5.70.0-1+b1
ii  libokular5core9   4:20.08.1-1
ii  libphonon4qt5-4   4:4.10.2-1
ii  libpoppler-qt5-1  20.09.0-2
ii  libqca-qt5-2  2.2.1-2
ii  libqmobipocket2   4:17.08.3-2+b1
ii  libqt5core5a  5.14.2+dfsg-4
ii  libqt5dbus5   5.14.2+dfsg-4
ii  libqt5gui55.14.2+dfsg-4
ii  libqt5printsupport5   5.14.2+dfsg-4
ii  libqt5svg55.14.2-2
ii  libqt5texttospeech5   5.14.2-2
ii  libqt5widgets55.14.2+dfsg-4
ii  libqt5xml55.14.2+dfsg-4
ii  libspectre1   0.2.8-2
ii  libstdc++610-20200418-1
ii  phonon4qt54:4.10.2-1
ii  zlib1g1:1.2.11.dfsg-2

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

Versions of packages okular suggests:
ii  ghostscript9.27~dfsg-2+deb10u3
pn  okular-extra-backends  
ii  poppler-data   0.4.9-2
ii  texlive-binaries   2020.20200327.54578-4+b1
pn  unrar  

-- no debconf information



Bug#972825: cups: Remote printing results in wrong page order

2020-10-24 Thread nemo
Package: cups
Version: 2.2.10-6+deb10u3
Severity: important

Dear Maintainer,

   * What led up to the situation?

I have an HP printer configured via HPLIP and shared in LAN. 

The version of HPLIP installed is
hplip  3.18.12+dfsg0-2+b2
hplip-data 3.18.12+dfsg0-2

I can print successfully in sequential order, but not in reverse.

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

I tried to print a set of pages (the even ones) in reverse order so that I can
print a document double-side, after printing the odd ones.

   * What was the outcome of this action?

- If I tried to print the even pages in reverse order I obtained also a blank 
page
  that resulted in an offset of the printing, e.g. behind page 3 was page 6
  instead of page 4. I want to point out that the blank page was found in both
  "even" and "odd" printing job. Those pages weren't in the document.

- If I manually inserted pages values "10,8,6,4,2" the result was
  pages "2,4,6,8,10", even if "reverse order" was NOT checked.
  This obviously resulted in page 10 printed behind page 1, 8 behind page 3,
  and so on.

   * What outcome did you expect instead?

What I did expect in both cases was being able to print pages 1,3,5,7,9 and
then pages 10,8,6,4,2 .


-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 10 (buster)
Release:10
Codename:   buster
Architecture: armv7l

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

Versions of packages cups depends on:
ii  cups-client2.2.10-6+deb10u3
ii  cups-common2.2.10-6+deb10u3
ii  cups-core-drivers  2.2.10-6+deb10u3
ii  cups-daemon2.2.10-6+deb10u3
ii  cups-filters   1.21.6-5+rpt1
ii  cups-ppdc  2.2.10-6+deb10u3
ii  cups-server-common 2.2.10-6+deb10u3
ii  debconf [debconf-2.0]  1.5.71
ii  ghostscript9.27~dfsg-2+deb10u4
ii  libavahi-client3   0.7-4+b1
ii  libavahi-common3   0.7-4+b1
ii  libc6  2.28-10+rpi1
ii  libcups2   2.2.10-6+deb10u3
ii  libcupsimage2  2.2.10-6+deb10u3
ii  libgcc11:8.3.0-6+rpi1
ii  libstdc++6 8.3.0-6+rpi1
ii  libusb-1.0-0   2:1.0.22-2
ii  poppler-utils  0.71.0-5
ii  procps 2:3.3.15-2

Versions of packages cups recommends:
ii  avahi-daemon 0.7-4+b1
ii  colord   1.4.3-4
ii  cups-filters [ghostscript-cups]  1.21.6-5+rpt1
ii  printer-driver-gutenprint5.3.1-7

Versions of packages cups suggests:
pn  cups-bsd   
pn  cups-pdf   
pn  foomatic-db-compressed-ppds | foomatic-db  
ii  hplip  3.18.12+dfsg0-2+b2
ii  printer-driver-hpcups  3.18.12+dfsg0-2+b2
pn  smbclient  
ii  udev   241-7~deb10u4+rpi1

-- debconf information:
  cupsys/raw-print: true
  cupsys/backend: lpd, socket, usb, snmp, dnssd



Bug#969114: apparmor-profiles: usr.sbin.dovecot does not allow reading /usr/share/dovecot/dh.pem (dovecot fails to start)

2020-10-24 Thread intrigeri
Hi Vincas!

Vincas Dargis (2020-08-27):
> This is produced if usr.sbin.dovecot is copied to /etc/apparmor.d:
>
> ```
> type=AVC msg=audit(1598556536.092:901): apparmor="DENIED" operation="open" 
> profile="dovecot" name="/usr/share/dovecot/dh.pem" pid=12625 comm="doveconf" 
> requested_mask="r" denied_mask="r" fsuid=0 ouid=0
> ```
>
> This results in dovecot failing to start:
>
> ```
> Aug 27 22:31:47 systemd[1]: Started Dovecot IMAP/POP3 email server.
> Aug 27 22:31:47 dovecot[13693]: doveconf: Fatal: Error in configuration file 
> /etc/dovecot/conf.d/10-ssl.conf line 50: ssl_dh: Can't open file 
> /usr/share/dove
> Aug 27 22:31:47 systemd[1]: dovecot.service: Main process exited, 
> code=exited, status=89/n/a
> Aug 27 22:31:47 systemd[1]: dovecot.service: Failed with result 'exit-code'.
> ```
>
> It is fixed by adding single rule:
>
> ```
> /usr/share/dovecot/dh.pem r,
> ```

Do you think it's too Debian-specific to fix upstream?

Cheers!



Bug#972824: mysql-5.7: Security fixes from the October 2020 CPU

2020-10-24 Thread Salvatore Bonaccorso
Source: mysql-5.7
Version: 5.7.26-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi

See
https://www.oracle.com/security-alerts/cpuoct2020.html#AppendixMSQL
for a list of CVEs affecting src:mysql-5.7.

Regards,
Salvatore



Bug#965360: apparmor-profiles: Please meke seperate packages for each apparmor profile

2020-10-24 Thread intrigeri
Control: tag -1 + moreinfo

Hi,

Mikhail Morfikov (2020-07-20):
> currently when the apparmor-profiles package is installed, it installs several
> apparmor profile files. In this way users can have all or none of the profiles
> installed in their systems. Sometimes a user wants only a specific profile (or
> profiles) installed and doesn't really want the other profiles to be installed
> as well because:
>  - he doesn't need the other profiles,
>  - he has his own alternative profiles, which differ in rule sets,
>  - the other profiles simply cause some issues with applications they confine.

> What do you think about another approach, which is to create separate packages
> containing individual apparmor profiles? For instance, there's the
> usr.sbin.dnsmasq file which is related to the dnsmasq package. In this case
> there could be a package named dnsmasq-apparmor-profile which would include 
> the
> usr.sbin.dnsmasq file. If a user wanted to install dnsmasq and also wanted it
> to be confined by the default apparmor profile provided by Debian, he could
> also install dnsmasq-apparmor-profile, which wouldn't affect any other app
> functionality.

The profiles shipped by the apparmor-profiles package are installed in
complain mode. Then the user may choose to enforce the profiles they
need. To me, it seems to already provide the kind of flexibility
you're wishing for, with a much lower overhead on the package
maintenance side. What did I miss?

Apart of this, the way the Debian archive works, having many tiny
packages is problematic, so I don't think your proposal would be
acceptable by the project. I'm not closing this bug report just yet as
I'd like to first better understand what the current setup is lacking
for you.

Cheers!



Bug#949395: Bug#972703: gnome-boxes does not start, undefined symbol libusb_set_option

2020-10-24 Thread Carnë Draug
Hi Simon

This is embarassing but I found now what was the issue.  There is one
package that I installed some months ago that was not from Debian
repos and for some reason it installs /lib/libusb.  It's not even a
deb file which is why dpkg-query does not know about it.

The package in question is xiAPI, from ximea, a company for microscope
cameras https://www.ximea.com/support/wiki/apis/xiAPI .  Without the
whole working from home thing, I would have never have installed on my
computer.

I'm very sorry for the noise.  Thank you for the help, it was the
process of answering your questions, and searching for other libs that
dpkg did not know about, that made me remember this.

David



Bug#970111: enigmail: Upgrade to migration version 2.2.x for Thunderbird 78

2020-10-24 Thread Jonas Smedegaard
No-op post to bump timestapm of this bugreport: Helps nudge the 
kick-packages-with-broken-rdeps-from-testing machinery to look further 
back at thunderbird for the real cause.

 - Jonas

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

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

signature.asc
Description: signature


Bug#971770: webext-dav4tbsync: Incompatible with Thunderbird 78

2020-10-24 Thread Jonas Smedegaard
Control: retitle -1 webext-dav4tbsync: Incompatible with Thunderbird 78

No-op post to bump timestapm of this bugreport: Helps nudge the 
kick-packages-with-broken-rdeps-from-testing machinery to look further 
back at thunderbird for the real cause.

...and while at it, tidy the bugreport title to include package name.


 - Jonas

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

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

signature.asc
Description: signature


Bug#968102: tbsync: Incompatible with Thunderbird 78

2020-10-24 Thread Jonas Smedegaard
No-op post to bump timestapm of this bugreport: Helps nudge the 
kick-packages-with-broken-rdeps-from-testing machinery to look further 
back at thunderbird for the real cause.

 - Jonas

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

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

signature.asc
Description: signature


Bug#972387: [Info-mtools] mtools does not work in Turkish locale

2020-10-24 Thread Chris Lamb
Hi Pali,

> IIRC toupper() for lowercase i with dot in Turkish locale returns
> uppercase I with dot. In English or C locale it is uppercase I without
> dot.
>
> I guess that for case-insensitive parsing of config options (which are
> written in English) should be used toupper() variant in C locale.
>
> There is a standard POSIX function toupper_l() which takes as a second
> argument locale. So I think that for reading config file it should be
> used function toupper_l() with C locale instead of locale-dependent
> toupper() function.

Indeed. This all matches my own analysis and reflects where I had got
to in previous email; apologies if that was not clearer.


Regards,

--
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-



Bug#972822: switch pbseqlib packages to Architecture: any

2020-10-24 Thread Helmut Grohne
Package: libpbdata-dev
Version: 5.3.3+dfsg-4
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:blasr src:pbdagcon

libpbdata-dev presently is an Architecture: all package. As such it
cannot satisfy host architecture dependencies during cross builds at
all. Marking it Multi-Arch: foreign is out of question as it exposes a
real shared library from another package. Thus it needs to be switched
to Architecture: any.

This applies to all other Architecture: all packages built from pbseqlib
as well, which is why the attached patch just converts them all. Please
consider applying it.

Helmut
diff --minimal -Nru pbseqlib-5.3.3+dfsg/debian/changelog 
pbseqlib-5.3.3+dfsg/debian/changelog
--- pbseqlib-5.3.3+dfsg/debian/changelog2020-01-29 15:28:50.0 
+0100
+++ pbseqlib-5.3.3+dfsg/debian/changelog2020-10-24 12:12:10.0 
+0200
@@ -1,3 +1,10 @@
+pbseqlib (5.3.3+dfsg-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch all packages to Architecture: any. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 24 Oct 2020 12:12:10 +0200
+
 pbseqlib (5.3.3+dfsg-4) unstable; urgency=medium
 
   * Breaks+Replaces: libblasr (<< 5.3.3)
diff --minimal -Nru pbseqlib-5.3.3+dfsg/debian/control 
pbseqlib-5.3.3+dfsg/debian/control
--- pbseqlib-5.3.3+dfsg/debian/control  2020-01-29 15:28:50.0 +0100
+++ pbseqlib-5.3.3+dfsg/debian/control  2020-10-24 12:12:10.0 +0200
@@ -22,9 +22,9 @@
 Homepage: https://github.com/PacificBiosciences/blasr_libcpp
 
 Package: libpbseq
-Architecture: all
+Architecture: any
 Depends: ${misc:Depends},
- libblasr  (>= ${source:Version})
+ libblasr (= ${binary:Version})
 Description: library for analyzing PacBio sequencing data
  Blasr_libcpp is a library used by blasr and other executables such as
  samtoh5, loadPulses for analyzing PacBio sequences. This library contains
@@ -36,8 +36,8 @@
 Architecture: any
 Section: libdevel
 Depends: ${misc:Depends},
- libpbdata-dev (= ${source:Version}),
- libpbihdf-dev (= ${source:Version}),
+ libpbdata-dev (= ${binary:Version}),
+ libpbihdf-dev (= ${binary:Version}),
  libblasr-dev  (= ${binary:Version})
 Description: library for analyzing PacBio sequencing data (development files)
  Blasr_libcpp is a library used by blasr and other executables such as
@@ -47,7 +47,7 @@
  This is a metapackage that depends on the pbseqlib component development 
files.
 
 Package: libpbdata-dev
-Architecture: all
+Architecture: any
 Section: libdevel
 Depends: ${misc:Depends},
  libpbcopper-dev
@@ -60,7 +60,7 @@
  sublibrary.
 
 Package: libpbihdf-dev
-Architecture: all
+Architecture: any
 Section: libdevel
 Depends: libhdf5-dev,
  ${misc:Depends}
@@ -76,7 +76,7 @@
 Architecture: any
 Section: libdevel
 Depends: libblasr (= ${binary:Version}),
- libpbdata-dev (= ${source:Version}),
+ libpbdata-dev (= ${binary:Version}),
  ${misc:Depends}
 Breaks: libblasr (<< 5.3.3)
 Replaces: libblasr (<< 5.3.3)


Bug#972823: votca-csg FTCBFS: build dependency python3 not installable

2020-10-24 Thread Helmut Grohne
Source: votca-csg
Version: 1.6.2-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

votca-csg cannot be cross built from source, because the python3
dependency is not installable. votca-csg does not actually need a host
architecture Python though. It merely wants to run one. That can be
achieved by depending on python3:any.

Even after fixing this aspect, votca-csg continues to fail cross
building, because it generates its manual pages from the --help output
of contained tools. That doesn't work as it requires running host
architecture executables.

Please consider applying the attached patch as an incremental
improvement and close this bug when doing so even without solving the
manual page aspect.

Helmut
diff --minimal -Nru votca-csg-1.6.2/debian/changelog 
votca-csg-1.6.2/debian/changelog
--- votca-csg-1.6.2/debian/changelog2020-08-26 07:28:01.0 +0200
+++ votca-csg-1.6.2/debian/changelog2020-10-24 12:03:05.0 +0200
@@ -1,3 +1,11 @@
+votca-csg (1.6.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Make cross Build-Depends satisfiably: Annotate python3 with :any.
+(Closes: #-1)
+
+ -- Helmut Grohne   Sat, 24 Oct 2020 12:03:05 +0200
+
 votca-csg (1.6.2-1) unstable; urgency=medium
 
   * New upstream release.
diff --minimal -Nru votca-csg-1.6.2/debian/control 
votca-csg-1.6.2/debian/control
--- votca-csg-1.6.2/debian/control  2020-08-26 07:25:00.0 +0200
+++ votca-csg-1.6.2/debian/control  2020-10-24 12:03:04.0 +0200
@@ -19,7 +19,7 @@
libvotca-tools-dev (<= 1.7~),
libvotca-tools-dev (>= 1.6.2),
pkg-config,
-   python3,
+   python3:any,
txt2tags
 Standards-Version: 4.5.0
 Rules-Requires-Root: no


Bug#972468: Error! Bad return status for module build on kernel: 5.9.0-1-amd64 (x86_64)

2020-10-24 Thread Markus Steinko

Dear maintainer,

when reinstalling the nvidia-kernel-dkms package the following error 
occours:


DKMS: install completed.
Building initial module for 5.9.0-1-amd64
Error! Bad return status for module build on kernel: 5.9.0-1-amd64 (x86_64)
Consult /var/lib/dkms/nvidia-current/450.66/build/make.log for more 
information.

dpkg: Fehler beim Bearbeiten des Paketes nvidia-kernel-dkms (--configure):
 »installiertes nvidia-kernel-dkms-Skript des Paketes 
post-installation«-Unterprozess gab den Fehlerwert 10 zurück

Fehler traten auf beim Bearbeiten von:
 nvidia-kernel-dkms


The make file is attached.

DKMS make.log for nvidia-current-450.66 for kernel 5.9.0-1-amd64 (x86_64)
Sa 24. Okt 13:49:27 CEST 2020
make KBUILD_OUTPUT=/lib/modules/5.9.0-1-amd64/build V=1 -C /lib/modules/5.9.0-1-amd64/source M=/var/lib/dkms/nvidia-current/450.66/build ARCH=x86_64 NV_KERNEL_SOURCES=/lib/modules/5.9.0-1-amd64/source NV_KERNEL_OUTPUT=/lib/modules/5.9.0-1-amd64/build NV_KERNEL_MODULES="nvidia nvidia-uvm nvidia-modeset nvidia-drm" INSTALL_MOD_DIR=kernel/drivers/video NV_SPECTRE_V2=0 modules
make[1]: Verzeichnis „/usr/src/linux-headers-5.9.0-1-common“ wird betreten
make -C /usr/src/linux-headers-5.9.0-1-amd64 -f /usr/src/linux-headers-5.9.0-1-common/Makefile modules
make[2]: Verzeichnis „/usr/src/linux-headers-5.9.0-1-amd64“ wird betreten
test -e include/generated/autoconf.h -a -e include/config/auto.conf || (		\
echo >&2;			\
echo >&2 "  ERROR: Kernel configuration is invalid.";		\
echo >&2 " include/generated/autoconf.h or include/config/auto.conf are missing.";\
echo >&2 " Run 'make oldconfig && make prepare' on kernel src to fix it.";	\
echo >&2 ;			\
/bin/false)
make -f /usr/src/linux-headers-5.9.0-1-common/scripts/Makefile.build obj=/var/lib/dkms/nvidia-current/450.66/build \
single-build= \
need-builtin=1 need-modorder=1
scripts/Makefile.lib:8: 'always' is deprecated. Please use 'always-y' instead
NV_CONFTEST_CMD=/bin/sh /var/lib/dkms/nvidia-current/450.66/build/conftest.sh " gcc-10" x86_64 /lib/modules/5.9.0-1-amd64/source /lib/modules/5.9.0-1-amd64/build
NV_CONFTEST_CFLAGS=-O2 -D__KERNEL__ -DKBUILD_BASENAME="#conftest26943" -DKBUILD_MODNAME="#conftest26943" -nostdinc -isystem /usr/lib/gcc/x86_64-linux-gnu/10/include -I/lib/modules/5.9.0-1-amd64/source/arch/x86/include/asm/mach-default -I/lib/modules/5.9.0-1-amd64/source/include/asm-x86/mach-default -I/lib/modules/5.9.0-1-amd64/build/include2 -I/lib/modules/5.9.0-1-amd64/build/include -include /lib/modules/5.9.0-1-amd64/build/include/generated/autoconf.h -I/lib/modules/5.9.0-1-amd64/source/arch/x86/include -I/lib/modules/5.9.0-1-amd64/source/arch/x86/include/uapi -I/lib/modules/5.9.0-1-amd64/build/arch/x86/include/generated -I/lib/modules/5.9.0-1-amd64/build/arch/x86/include/generated/uapi -I/lib/modules/5.9.0-1-amd64/source/include -I/lib/modules/5.9.0-1-amd64/source/include/uapi -I/lib/modules/5.9.0-1-amd64/source/include/xen -I/lib/modules/5.9.0-1-amd64/build/include/generated/uapi -I/var/lib/dkms/nvidia-current/450.66/build/common/inc -I/var/lib/dkms/nvidia-current/450.66/build -Wall -MD   -Wno-cast-qual -Wno-error -Wno-format-extra-args -D__KERNEL__ -DMODULE -DNVRM -DNV_VERSION_STRING=\"450.66\" -Wno-unused-function -Wuninitialized -fno-strict-aliasing -mno-red-zone -mcmodel=kernel -DNV_UVM_ENABLE -Werror=undef -DNV_SPECTRE_V2=0 -fno-pie -Wall -Wundef -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -Wno-format-security -std=gnu89 -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone -mcmodel=kernel -DCONFIG_X86_X32_ABI -Wno-sign-compare -fno-asynchronous-unwind-tables -mindirect-branch=thunk-extern -mindirect-branch-register -fno-jump-tables -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -Wno-address-of-packed-member -O2 -fno-allow-store-data-races -Wframe-larger-than=2048 -fstack-protector-strong -Wno-unused-but-set-variable -Wimplicit-fallthrough -Wno-unused-const-variable -fno-var-tracking-assignments -g -pg -mrecord-mcount -mfentry -DCC_USING_FENTRY -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wno-stringop-truncation -Wno-zero-length-bounds -Wno-array-bounds -Wno-stringop-overflow -Wno-restrict -Wno-maybe-uninitialized -fno-strict-overflow -fno-merge-all-constants -fmerge-constants -fno-stack-check -fconserve-stack -fmacro-prefix-map=/usr/src/linux-headers-5.9.0-1-common/= -fcf-protection=none -Wno-packed-not-aligned
KBUILD_CFLAGS=-Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration -Werror=implicit-int -Wno-format-security -std=gnu89 -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone 

Bug#972820: Distribution of Debian cannot be upgraded from Buster to Bullseye

2020-10-24 Thread Karsten
The correct count is 1295 packages that where not correct upgraded.
A new try to upgrade fails with this message:

# apt-get upgrade  
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.  
Statusinformationen werden eingelesen Fertig
Paketaktualisierung (Upgrade) wird berechnet... Fertig
Die folgenden Pakete wurden automatisch installiert und werden nicht mehr 
benötigt:
  libdevel-globaldestruction-perl libdsm3 libkgantt2-l10n libsugarext-data 
python-mutagen python3-asn1crypto
python3-entrypoints
  python3-gst-1.0 python3-keyring python3-keyrings.alt python3-secretstorage 
vlc-plugin-notify vlc-plugin-samba
x11proto-input-dev
  x11proto-kb-dev
Verwenden Sie »apt autoremove«, um sie zu entfernen.
Die folgenden Pakete sind zurückgehalten worden:
  accountsservice accountwizard akonadi-backend-mysql akonadi-contacts-data 
akonadi-mime-data akonadi-server akregator
alsa-tools
  alsa-utils apparmor-utils apper appstream apt apt-utils aptitude 
aptitude-common ark aspell atril audacity audacity-data
  avidemux-plugins avidemux-qt avrdude baloo-kf5 bc bind9-host binutils 
binutils-common binutils-x86-64-linux-gnu
bluedevil bluez breeze
  breeze-cursor-theme breeze-gtk-theme bsdmainutils bsdutils build-essential 
clementine colord coreutils cpp cpp-8 cups
cups-browsed
  cups-bsd cups-client cups-core-drivers cups-daemon cups-filters 
cups-filters-core-drivers cups-ipp-utils cups-ppdc cutecom
  debconf-kde-data debconf-kde-helper dh-python digikam-private-libs dirmngr 
dnsmasq-base dnsutils dolphin dragonplayer
drkonqi e2fsprogs
  e2fsprogs-l10n enblend enfuse espeak-ng-data evince evince-common exim4-base 
exim4-config exim4-daemon-light exo-utils
fbreader ffmpeg
  fig2dev filezilla filezilla-common frameworkintegration ftp g++ g++-8 gawk 
gcc gcc-8 gcc-8-base gcc-8-base:i386 gcr
gdal-bin gdal-data
  gdb-minimal gdisk ghostscript gimp gimp-data gir1.2-evince-3.0 
gir1.2-freedesktop gir1.2-glib-2.0
gir1.2-gst-plugins-base-1.0
  gir1.2-gstreamer-1.0 gir1.2-gtk-3.0 gir1.2-javascriptcoregtk-4.0 
gir1.2-packagekitglib-1.0 gir1.2-pango-1.0
gir1.2-polkit-1.0
  gir1.2-rsvg-2.0 gir1.2-soup-2.4 gir1.2-sugarext-1.0 gir1.2-vte-2.91 
gir1.2-webkit2-4.0 glib-networking
glib-networking-services
  gnome-desktop3-data gnupg gnupg-agent gnupg-l10n gnupg-utils gnupg2 gnuradio 
gnuradio-dev gnustep-base-common
gnustep-base-runtime
  gparted gpg gpg-agent gpg-wks-client gpg-wks-server gpgconf gpgsm gpgv 
gpsbabel gqrx-sdr gr-fcdproplus gr-fosphor
gr-iqbal gr-osmosdr
  graphviz groff-base gstreamer1.0-alsa gstreamer1.0-gl gstreamer1.0-libav 
gstreamer1.0-plugins-bad
gstreamer1.0-plugins-base
  gstreamer1.0-plugins-base:i386 gstreamer1.0-plugins-good 
gstreamer1.0-plugins-ugly gstreamer1.0-pulseaudio
gstreamer1.0-rtsp
  gstreamer1.0-tools gstreamer1.0-vaapi gstreamer1.0-x gvfs gvfs-common 
gvfs-daemons gvfs-libs gwenview haveged hplip
hplip-data html2text
  hugin hugin-data hugin-tools i965-va-driver iftop inkscape 
intel-media-va-driver iproute2 iptables isc-dhcp-client juk
k3b k3b-data
  kaccounts-providers kactivities-bin kactivitymanagerd kaddressbook kaffeine 
kamera kate kcalc kchmviewer kcolorchooser
kde-baseapps
  kde-cli-tools kde-cli-tools-data kde-config-gtk-style 
kde-config-mailtransport kde-config-screenlocker kde-config-sddm
  kde-plasma-desktop kde-spectacle kde-standard kde-style-breeze 
kde-style-oxygen-qt5 kde-style-qtcurve-qt5
kdeaccessibility kdeconnect
  kded5 kdepim-addons kdepim-runtime kdepim-themeeditors kdeplasma-addons-data 
kdialog kdiff3 kdoctools5 keditbookmarks
  kf5-kdepim-apps-libs-data kf5-messagelib-data kfind kgamma5 khelpcenter 
khotkeys khotkeys-data kicad
kimageformat-plugins kinfocenter
  kinit kio kio-audiocd kio-extras kio-extras-data kio-ldap kipi-plugins 
kipi-plugins-common kmag kmahjongg kmail
kmenuedit kmousetool
  kmouth knotes konq-plugins konqueror konsole konsole-kpart korganizer 
kpackagelauncherqml kpackagetool5 kronometer
kross krusader
  kscreen ksshaskpass ksudoku ksysguard ksysguard-data ksysguardd 
ktexteditor-data ktexteditor-katepart kwalletmanager
kwayland-data
  kwayland-integration kwin-common kwin-data kwin-decoration-oxygen 
kwin-style-breeze kwin-x11 kwrite kwrited lame lftp
lib32stdc++6
  libaccountsservice0 libalglib3.14 libalgorithm-diff-xs-perl libappstream4 
libappstreamqt2 libapt-pkg-perl libarchive13
libarmadillo9
  libarpack2 libasan5 libasound2 libasound2:i386 libasound2-data 
libasound2-plugins libaspell15 libass9 libastro1 libatomic1
  libatomic1:i386 libatrildocument3 libatrilview3 libavcodec58 libavdevice58 
libavfilter7 libavformat58 libavresample4
libavutil56
  libayatana-ido3-0.4-0 libayatana-indicator3-7 libb-hooks-op-check-perl 
libbabl-0.1-0 libbasicusageenvironment1
libbind9-161 libbinutils
  libblockdev-part2 libbluray2 libboost-date-time-dev libboost-filesystem-dev 
libboost-program-options-dev
libboost-system-dev
  libboost-test-dev libboost-thread-dev libbrotli1 libc-bin libc-dev-bin libc6 
libc6:i386 libc6-dev 

Bug#972821: ITS: python-crontab

2020-10-24 Thread Michael Fladischer
Source: python-crontab
Severity: important
X-Debbugs-Cc: 
stu...@nanonanonano.net,kilob...@angband.pl,z...@debian.org,jmetzmeie...@gmail.com,m...@qa.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

I intend to salvage this package for DPT.
There is a 2 years old unresolved bug for packaging a new upstream version
(#914192). This bugs block the upgrade of another package
(python-django-celery-beat: #972565) which is currently unusable because of
this.

I also tried to contact you in private on 2020-03-03 regarding python-crontab
without any response.

If you are still interessed on working on this package (maybe as part of DPT)
please follow up to this bug report in the next 21 days. After this I will move
the package to the DPT and upload its latest release to the archive.

Regards,
Michael


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

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

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAl+UFTQRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WqGlgf+IBP950VmT6bszu5jl1qCRBfSzVjRUW7Z
hrh7UK5Oafob1iQihpwLkEPzZ7ybeTdjEGgDJgo4KHKImFnBEfDKx1MVb3GhE1Jq
vMn9Hi15rMmrvxiPBhUDwySf7mObg0umC6WbSXJcJGwDSkX9wA0BKc6RzBPqsOrc
DYJjXRAXUFDU2oGgCZSRdvps6LIEiJT3iGYgmUPGaCo0LkbJpZvqLSLaQgzb9dSD
0CSvBQhi2WdXuiHMqG4BJYWXKJQNpyhqi38LCiq+iws0b5M9UPgN8VrC3mCDPaDY
5aNy3jYP+Uif3DHMBRY+zkwxpoT0ECraphrGLxSuR3w0B5wsGz3USQ==
=xDda
-END PGP SIGNATURE-



Bug#972820: Distribution of Debian cannot be upgraded from Buster to Bullseye

2020-10-24 Thread Karsten
I tried everything.
With aptitude the process did not end and was killed with Ctrl-C:

# aptitude upgrade
Auflösen der Abhängigkeiten ...
offen: 91831;
geschlossen: 108907;
zurückgestellt: 353;
Konflikte:3108 (there are 3108 conflicts!)

I think after an reboot this installation is dead ...
What must be done?
 



Bug#956272: xournalpp

2020-10-24 Thread Barak A. Pearlmutter
Absolutely. I made a tentative packaging, at
https://salsa.debian.org/debian/xournalpp

Builds and works fine. I use it daily, for teaching remotely. Would
welcome testers.

The only reason I have not actually pushed it into Debian is that the
debian/copyright file is a bit of a mess. Some of the .svg files in
particular have embedded copyright strings with CC of various
flavours, and nobody's had the time or enthusiasm to dive in and check
all the copyrights and record them in debian/copyright, and if any
problematic .svg files are found to replace them with free
replacements from one of the collections of actually free artistic SVG
files.



Bug#972468: nvidia-driver 450.66-1

2020-10-24 Thread Markus Steinko
I am facing the same bug for nvidia-driver (450.66-1) on a a bullseye 
system where the nvidia-persistenced package still remains on version 
(450.57-1).




Bug#972820: Distribution of Debian cannot be upgraded from Buster to Bullseye

2020-10-24 Thread Karsten
Package: libgcc-8-dev
Version: 8.3.0-6
Severity: important

Hello,

i try to upgrade an copy of Debian Buster on another partition to Debian 
Bullseye, but it fails with this message:
(sorry i don't know how to switch the output to english)

# apt-get dist-upgrade
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.  
Statusinformationen werden eingelesen Fertig
Paketaktualisierung (Upgrade) wird berechnet... Fehler!
Einige Pakete konnten nicht installiert werden. Das kann bedeuten, dass
Sie eine unmögliche Situation angefordert haben oder, wenn Sie die
Unstable-Distribution verwenden, dass einige erforderliche Pakete noch
nicht erstellt wurden oder Incoming noch nicht verlassen haben.
Die folgenden Informationen helfen Ihnen vielleicht, die Situation zu lösen:

Die folgenden Pakete haben unerfüllte Abhängigkeiten:
 libc6-dev : Beschädigt: libgcc-8-dev (< 8.4.0-2~) aber 8.3.0-6 soll 
installiert werden
E: Fehler: Unterbrechungen durch pkgProblemResolver::Resolve hervorgerufen; 
dies könnte durch zurückgehaltene Pakete
verursacht worden sein.



Before there where about 1117 packages been updated successfully with
# apt-get upgrade



With aptitude there is this result:
(I think there is more than one package and reason involved)

# aptitude dist-upgrade
Die folgenden NEUEN Pakete werden zusätzlich installiert:
  alsa-topology-conf{a} alsa-ucm-conf{a} bind9-dnsutils{a} bind9-libs{a} 
bladerf{a} bsdextrautils{a} calendar{a} cpp-10{a}
  digikam-data{a} enchant-2{a} fonts-liberation2{a} fonts-opensymbol{a} 
fonts-symbola{a} fonts-urw-base35{a} fuse3{ab}
g++-10{a}
  gcc-10{a} gcc-10-base{a} gcc-10-base:i386{a} gcc-9-base{a} 
gir1.2-harfbuzz-0.0{a} gir1.2-telepathyglib-0.12{a}
  glib-networking:i386{a} gparted-common{a} gstreamer1.0-gtk3{a} 
gstreamer1.0-plugins-good:i386{a} gstreamer1.0-x:i386{a}
  i965-va-driver:i386{a} icu-devtools{a} intel-media-va-driver:i386{a} 
ipp-usb{ab} ipp-usb:i386{ab} lib32gcc-s1{a}
libaa1:i386{a}
  libaliased-perl{a} libann0{a} libany-uri-escape-perl{a} libaom2{a} 
libaom2:i386{a} libapt-pkg6.0{a}
libaribb24-0:i386{a} libasan6{a}
  libatopology2{a} libavc1394-0:i386{a} libavcodec58:i386{a} 
libavutil56:i386{a} libbladerf2{a} libboost-atomic1.71-dev{a}
  libboost-atomic1.71.0{a} libboost-chrono1.71-dev{a} libboost-chrono1.71.0{a} 
libboost-date-time1.71-dev{a}
  libboost-date-time1.71.0{a} libboost-filesystem1.71-dev{a} 
libboost-filesystem1.71.0{a} libboost-iostreams1.71.0{a}
  libboost-locale1.71.0{a} libboost-program-options1.71-dev{a} 
libboost-program-options1.71.0{a} libboost-regex1.71-dev{a}
  libboost-regex1.71.0{a} libboost-serialization1.71-dev{a} 
libboost-serialization1.71.0{a} libboost-system1.71-dev{a}
  libboost-system1.71.0{a} libboost-test1.71-dev{a} libboost-test1.71.0{a} 
libboost-thread1.71-dev{a}
libboost-thread1.71.0{a}
  libboost1.71-dev{a} libbrlapi0.8{a} libbrotli1:i386{a} libbz2-1.0:i386{a} 
libcaca0:i386{a} libcairo-gobject-perl{a}
  libcairo-gobject2:i386{a} libcbor0{a} libcfitsio9{a} 
libclass-data-inheritable-perl{a} libclucene-contribs1v5{a}
  libclucene-core1v5{a} libcmis-0.5-5v5{a} libcodec2-0.9{a} 
libcodec2-0.9:i386{a} libconfig-tiny-perl{a}
libcpanel-json-xs-perl{a}
  libcppunit-1.15-0{a} libcrypt-dev{a} libcrypt1{a} libcrypt1:i386{a} 
libctf-nobfd0{a} libctf0{a} libcurl3-gnutls:i386{a}
  libcurl4:i386{a} libcwidget4{a} libdata-dpath-perl{a} 
libdata-messagepack-perl{a} libdata-validate-domain-perl{a}
libdatrie1:i386{a}
  libdav1d4{a} libdav1d4:i386{a} libdc1394-25{a} libdevel-size-perl{a} 
libdevel-stacktrace-perl{a} libdns-export1110{a}
  libdouble-conversion3{a} libdv4:i386{a} libdvdread8{a} libdw1:i386{a} 
libebml5{a} libemail-address-xs-perl{a}
libenchant-2-2{a}
  libeot0{a} libept1.6.0{a} libevent-2.1-7{a} libexception-class-perl{a} 
libexiv2-27{a} libexttextcat-2.0-0{a}
libexttextcat-data{a}
  libextutils-depends-perl{a} libextutils-pkgconfig-perl{a} libfaudio0{a} 
libfaudio0:i386{a} libfdk-aac2:i386{a} libffi7{a}
  libffi7:i386{a} libfido2-1{a} libfile-find-rule-perl{a} libfluidsynth2{a} 
libfont-ttf-perl{a} libfribidi0:i386{a}
libfuse3-3{a}
  libgarcon-gtk3-1-0{a} libgbm1:i386{a} libgc1{a} libgcc-10-dev{a} libgcc-s1{a} 
libgcc-s1:i386{a} libgdal27{a}
libgdbm-compat4:i386{a}
  libgdbm6:i386{a} libgdcm3.0{a} libgdk-pixbuf2.0-0:i386{a} libgdl-3-5{a} 
libgdl-3-common{a} libgeos-3.8.1{a}
libgeotiff5{a}
  libgit2-28{a} libglib-object-introspection-perl{a} libgmp-dev{a} 
libgmpxx4ldbl{a} libgnome-desktop-3-19{a}
libgnuradio-analog3.8.2{a}
  libgnuradio-audio3.8.2{a} libgnuradio-blocks3.8.2{a} 
libgnuradio-channels3.8.2{a} libgnuradio-digital3.8.2{a}
libgnuradio-dtv3.8.2{a}
  libgnuradio-fcdproplus3.8.0{a} libgnuradio-fec3.8.2{a} 
libgnuradio-fft3.8.2{a} libgnuradio-filter3.8.2{a}
libgnuradio-fosphor3.8.0{a}
  libgnuradio-iqbalance3.8.0{a} libgnuradio-osmosdr0.2.0{a} 
libgnuradio-pmt3.8.2{a} libgnuradio-qtgui3.8.2{a}
  

Bug#972819: RM: binaries not built anymore from python-defaults

2020-10-24 Thread Matthias Klose
Package: ftp.debian.org

Please remove the binary packages in unstable, which are not built anymore from
python-defaults.

The python-is-python2 package now provides python, and python-dev-is-python2 now
provides python-dev.



Bug#972818: okular: Wrong page order if printing a subset of pages

2020-10-24 Thread ale
Package: okular
Version: 4:20.08.1-1
Severity: important

Dear Maintainer,

I tried to print a set of pages (the even ones) in reverse order so that I can
print a document double-side, after printing the odd ones.

What happened depending on my print settings in the print dialog was:

- If I selected "even pages" and "reverse order" I obtained also a blank page
  that resulted in an offset of the printing, e.g. behind page 3 was page 6
  instead of page 4. I want to point out that the blank page was found in both
  "even" and "odd" printing job. Those pages weren't in the document.

- If I manually inserted in "Pages" the values "10,8,6,4,2" the result was
  pages "2,4,6,8,10", even if "reverse order" was NOT checked.
  This obviously resulted in page 10 printed behind page 1, 8 behind page 3,
  and so on.

What I did expect in both cases was being able to print pages 1,3,5,7,9 and
then pages 10,8,6,4,2 .



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

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

Versions of packages okular depends on:
ii  kinit 5.54.0-1
ii  kio   5.54.1-1
ii  libc6 2.30-8
ii  libfreetype6  2.10.1-2
ii  libjpeg62-turbo   1:1.5.2-2+b1
ii  libkf5activities5 5.70.0-1
ii  libkf5archive55.70.0-1
ii  libkf5bookmarks5  5.70.0-1
ii  libkf5codecs5 5.70.0-1
ii  libkf5completion5 5.70.0-1
ii  libkf5configcore5 5.70.0-1
ii  libkf5configgui5  5.70.0-1
ii  libkf5configwidgets5  5.70.0-1
ii  libkf5coreaddons5 5.70.0-1
ii  libkf5crash5  5.70.0-1
ii  libkf5i18n5   5.70.0-1
ii  libkf5iconthemes5 5.70.0-1
ii  libkf5itemviews5  5.70.0-1
ii  libkf5jobwidgets5 5.70.0-1
ii  libkf5kexiv2-15.0.0   17.08.3-1
ii  libkf5kiocore55.70.1-1
ii  libkf5kiowidgets5 5.70.1-1
ii  libkf5parts5  5.70.0-1
ii  libkf5pty55.70.0-1
ii  libkf5purpose-bin 5.70.0-2
ii  libkf5purpose55.70.0-2
ii  libkf5service-bin 5.70.0-1
ii  libkf5service55.70.0-1
ii  libkf5textwidgets55.70.0-1
ii  libkf5wallet-bin  5.62.0-1+b1
ii  libkf5wallet5 5.62.0-1+b1
ii  libkf5widgetsaddons5  5.70.0-1
ii  libkf5windowsystem5   5.70.0-1
ii  libkf5xmlgui5 5.70.0-1+b1
ii  libokular5core9   4:20.08.1-1
ii  libphonon4qt5-4   4:4.10.2-1
ii  libpoppler-qt5-1  20.09.0-2
ii  libqca-qt5-2  2.2.1-2
ii  libqmobipocket2   4:17.08.3-2+b1
ii  libqt5core5a  5.14.2+dfsg-4
ii  libqt5dbus5   5.14.2+dfsg-4
ii  libqt5gui55.14.2+dfsg-4
ii  libqt5printsupport5   5.14.2+dfsg-4
ii  libqt5svg55.14.2-2
ii  libqt5texttospeech5   5.14.2-2
ii  libqt5widgets55.14.2+dfsg-4
ii  libqt5xml55.14.2+dfsg-4
ii  libspectre1   0.2.8-2
ii  libstdc++610-20200418-1
ii  phonon4qt54:4.10.2-1
ii  zlib1g1:1.2.11.dfsg-2

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

Versions of packages okular suggests:
ii  ghostscript9.27~dfsg-2+deb10u3
pn  okular-extra-backends  
ii  poppler-data   0.4.9-2
ii  texlive-binaries   2020.20200327.54578-4+b1
pn  unrar  

-- no debconf information



Bug#702107: reportbug failed (my error) saved report in /tmp; no obvious way of resending report

2020-10-24 Thread ale
Package: reportbug
Version: 7.7.0
Followup-For: Bug #702107

Dear Maintainer,

it just happenend to me the same thing described by John Hughes in 2013.

If not a "retry" button, at least some instruction of what I can do would be
useful.

Thank you



-- Package-specific info:
** Environment settings:
PAGER="less"
INTERFACE="gtk"

** /home/ale/.reportbugrc:
reportbug_version "7.7.0"
mode novice
ui gtk
email "n...@autistici.org"
smtphost "smtp.autistici.org:587"
smtpuser "n...@autistici.org"
smtppasswd 
smtptls

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

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

Versions of packages reportbug depends on:
ii  apt2.1.7
ii  python33.8.2-3
ii  python3-reportbug  7.7.0
ii  sensible-utils 0.0.12+nmu1

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
pn  debconf-utils  
pn  debsums
pn  dlocate
pn  emacs-bin-common   
ii  exim4-daemon-light [mail-transport-agent]  4.94-6
ii  file   1:5.38-5
ii  gnupg  2.2.20-1
pn  python3-urwid  
ii  reportbug-gtk  7.7.0
ii  xdg-utils  1.1.3-2

Versions of packages python3-reportbug depends on:
ii  apt2.1.7
ii  file   1:5.38-5
ii  python33.8.2-3
ii  python3-apt2.1.3
ii  python3-debian 0.1.37
ii  python3-debianbts  3.0.2
ii  python3-requests   2.23.0+dfsg-2
ii  sensible-utils 0.0.12+nmu1

python3-reportbug suggests no packages.

-- no debconf information



Bug#971595: mupdf: CVE-2020-26519

2020-10-24 Thread Bastian Germann
On Fri, 23 Oct 2020 21:05:44 +0200 Bastian Germann 
 wrote:

On Oct, 7th, upstream version 1.18.0 was released which contains the
fix. Please update to that version.


At https://salsa.debian.org/koster/mupdf/-/merge_requests/6, I published 
the changes for the package to import the new upstream version.




Bug#972430: nvidia-legacy-340xx-driver: Fails to build with kernel 5.9

2020-10-24 Thread jim_p
Package: nvidia-legacy-340xx-driver
Followup-For: Bug #972430

I just made the update to version -8 and everything works as it should. Thank
you once more :)



-- Package-specific info:
uname -a:
Linux mitsos 5.9.0-1-amd64 #1 SMP Debian 5.9.1-1 (2020-10-17) x86_64 GNU/Linux

/proc/version:
Linux version 5.9.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.0-15) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP Debian 
5.9.1-1 (2020-10-17)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  340.108  Wed Dec 11 11:06:58 
PST 2019
GCC version:  gcc version 10.2.0 (Debian 10.2.0-15) 

lspci 'display controller [030?]':
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT218 [GeForce 
210] [10de:0a65] (rev a2) (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. GT218 [GeForce 210] [1043:8490]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: nvidia
Kernel modules: nvidia

dmesg:
[0.152032] Console: colour VGA+ 80x25
[0.588768] pci :01:00.0: vgaarb: setting as boot VGA device
[0.588768] pci :01:00.0: vgaarb: VGA device added: 
decodes=io+mem,owns=io+mem,locks=none
[0.588768] pci :01:00.0: vgaarb: bridge control possible
[0.588768] vgaarb: loaded
[0.775309] Linux agpgart interface v0.103
[3.341216] nvidia: loading out-of-tree module taints kernel.
[3.341228] nvidia: module license 'NVIDIA' taints kernel.
[3.404196] nvidia: module verification failed: signature and/or required 
key missing - tainting kernel
[3.466536] nvidia :01:00.0: vgaarb: changed VGA decodes: 
olddecodes=io+mem,decodes=none:owns=io+mem
[3.476205] [drm] Initialized nvidia-drm 0.0.0 20150116 for :01:00.0 on 
minor 0
[3.476224] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  340.108  Wed Dec 
11 11:06:58 PST 2019
[3.821678] snd_hda_intel :01:00.1: Handle vga_switcheroo audio client
[3.936000] input: HDA NVidia HDMI/DP,pcm=3 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input9
[3.936085] input: HDA NVidia HDMI/DP,pcm=7 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input10
[3.936159] input: HDA NVidia HDMI/DP,pcm=8 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input11
[3.939633] input: HDA NVidia HDMI/DP,pcm=9 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input12
[8.943902] caller _nv000788rm+0xe4/0x1c0 [nvidia] mapping multiple BARs

Device node permissions:
crw-rw+ 1 root video 226,   0 Oct 24 14:01 /dev/dri/card0
crw-rw-rw-  1 root root  195,   0 Oct 24 14:01 /dev/nvidia0
crw-rw-rw-  1 root root  195, 255 Oct 24 14:01 /dev/nvidiactl

/dev/dri/by-path:
total 0
lrwxrwxrwx 1 root root 8 Oct 24 14:01 pci-:01:00.0-card -> ../card0
video:*:44:jim

OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root   15 Jun  8 11:36 /etc/alternatives/glx -> 
/usr/lib/nvidia
lrwxrwxrwx 1 root root   44 Jun  8 11:36 
/etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libEGL.so.1
lrwxrwxrwx 1 root root   43 Jun  8 11:36 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   43 Jun  8 11:36 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   25 Jun  8 11:36 
/etc/alternatives/glx--linux-libglx.so -> /usr/lib/nvidia/libglx.so
lrwxrwxrwx 1 root root   42 Jun  8 11:36 
/etc/alternatives/glx--nvidia-blacklists-nouveau.conf -> 
/etc/nvidia/nvidia-blacklists-nouveau.conf
lrwxrwxrwx 1 root root   36 Jun  8 11:36 
/etc/alternatives/glx--nvidia-bug-report.sh -> 
/usr/lib/nvidia/nvidia-bug-report.sh
lrwxrwxrwx 1 root root   39 Jun  8 11:36 
/etc/alternatives/glx--nvidia-drm-outputclass.conf -> 
/etc/nvidia/nvidia-drm-outputclass.conf
lrwxrwxrwx 1 root root   28 Jun  8 11:36 
/etc/alternatives/glx--nvidia-load.conf -> /etc/nvidia/nvidia-load.conf
lrwxrwxrwx 1 root root   32 Jun  8 11:36 
/etc/alternatives/glx--nvidia-modprobe.conf -> /etc/nvidia/nvidia-modprobe.conf
lrwxrwxrwx 1 root root   29 Jun  8 11:36 
/etc/alternatives/glx--nvidia_drv.so -> /usr/lib/nvidia/nvidia_drv.so
lrwxrwxrwx 1 root root   28 Jan  5  2020 /etc/alternatives/nvidia -> 
/usr/lib/nvidia/legacy-340xx
lrwxrwxrwx 1 root root   57 Jan  5  2020 
/etc/alternatives/nvidia--libEGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/legacy-340xx/libEGL.so.1
lrwxrwxrwx 1 root root   56 Jan  5  2020 
/etc/alternatives/nvidia--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/legacy-340xx/libGL.so.1
lrwxrwxrwx 1 root root   56 Jan  5  2020 
/etc/alternatives/nvidia--libGL.so.1-x86_64-linux-gnu -> 

Bug#972802: rust-webpki-roots: duplicates ca-certificates, remove from Debian?

2020-10-24 Thread Bastian Germann

On Sat, 24 Oct 2020 11:50:14 +0800 Paul Wise  wrote:

On Sat, 2020-10-24 at 03:06 +, kpcyrd wrote:

> Yes, running the build.py script would cause reproducible builds issues
> because it's used to take snapshots of Mozilla's trusted root CA
> certificates.

Hmm, I assume that is because it would build from the current snapshot
each time it is run? 


> This is a very non-trivial downstream patch though, the project I'm
> trying to package runs in a sandbox and loading certificates from disk
> at runtime is not possible without redesigning some things.

One option to solve this would be to have src:rust-webpki-roots provide
webpki-roots-build containing build.py and then have ca-certificates
build-dep on webpki-roots, run build.py and build a binary package
containing the generated rust code. That seems a bit ick though.

Is there any chance of webpki/rustls upstream switching from embedding
to runtime loading of certs like other TLS stacks do?

> webpki-roots is an optional dependency of reqwest, see
> librust-reqwest+webpki-roots-dev[1].

It looks like this package needs rebuilding, because the binary package
librust-webpki-roots-dev doesn't provide the virtual package named
librust-webpki-roots-0.16+default-dev any more, which is probably why
dak didn't know that something in Debian uses src:rust-webpki-roots.

>  It's related to webpki[2]/rustls[3], the later only got accepted
> into debian very recently.

These appear to be the websites for these two:

https://briansmith.org/rustdoc/webpki/
https://github.com/ctz/rustls
I packaged rustls and webpki-roots as preconditions for packaging 
MesaLink. I will not pursue this project any longer; the reason for it 
was #963699 which is not relevant anymore.


I am okay with removing both of these packages again. However, rustls is 
a common package in Rust world and the Rust team might want to keep it.




Bug#972813: xournal FTBFS: wrongly declared R³

2020-10-24 Thread Barak A. Pearlmutter
ack



Bug#972817: ITP: golang-github-canonical-go-dqlite -- Go bindings for libdqlite

2020-10-24 Thread Clement Hermann
Package: wnpp
Severity: wishlist
Owner: Clement Hermann 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-canonical-go-dqlite
  Version : 1.8.0-1
  Upstream Author : Canonical
* URL : https://github.com/canonical/go-dqlite
* License : Apache-2.0
  Programming Lang: Go
  Description : Go bindings for libdqlite

 Go-dqlite provides bindings for the dqlite
 (https://dqlite.io) C library.

This package is a dependency of LXD (#768073) and will be maintained
under the Go pkg team umbrella.  Note: I don't intend to provide the
example program (demo API and client program) as a binary package
initially.  However, feel free to chime in here or file a bug in the
package once it's in Debian if you think it'd be useful!



Bug#972511: nvidia-legacy-390xx-driver: DKMS module build fail ioctl32.h not found

2020-10-24 Thread Olivier Allard-Jacquin
Hi,

same issue here, with AMD64 processor.

According to
https://www.phoronix.com/scan.php?page=news_item=NVIDIA-Linux-5.9-Delayed
, this is an incompatibility with 5.9 kernel.

I suggest to install 5.8 kernel.

Regards,
Olivier



Bug#949395: Bug#972703: gnome-boxes does not start, undefined symbol libusb_set_option

2020-10-24 Thread Simon McVittie
dpkg maintainers: This looks similar to #896019 in GLib and #948318
in libcrypt, except instead of their transition from /lib/MULTIARCH
to /usr/lib/MULTIARCH, it involves libusb's transition from /lib to
/lib/MULTIARCH. I'm worried that we might see this more often as more /lib
libraries, like libdbus in experimental, transition from /lib to /usr/lib.

If we need to be preemptively detecting and fixing up this sort of thing
in all packages that move libraries from one directory to another, then
the script in https://salsa.debian.org/gnome-team/glib/-/merge_requests/9
might be a useful basis for that - review and testing would be
appreciated.

On Fri, 23 Oct 2020 at 22:10:11 +0100, Carnë Draug wrote:
> I checked and other than "/lib/x86_64-linux-gnu/libusb-1.0.so.0"
> (provided by libusb-1.0-0) I also have "/lib/libusb-1.0.so.0" (which
> seems to be what is loaded

Please move that file to another directory for further investigation,
for example:

mkdir /lib/removed-for-bug-972703
mv /lib/libusb-1.0.so.0* /lib/removed-for-bug-972703/

(This should fix the immediate failure.)

Then please send the results of:

ls -l /lib/removed-for-bug-972703/*
md5sum /lib/removed-for-bug-972703/*

It would also be interesting to know whether there are other libraries
in /lib and /usr/lib that dpkg doesn't know about:

find /lib /usr/lib -name '*.so.*' | while read -r x; do dpkg -S "$x" 
>/dev/null; done

You'll get messages on stderr like:

dpkg-query: no path found matching pattern 
/lib/removed-for-bug-972703/libusb-1.0.so.0

Some of the results of this will be files that are managed by
alternatives, like /usr/lib/x86_64-linux-gnu/libblas.so.3, which are
harmless - but others might not be.

> Removing "/lib/libusb-1.0.so*" (and run ldconfig to update the linker
> cache), makes it load the right libusb [...]
> And gnome-boxes now works properly.

This seems reminiscent of rare upgrade issues that we've seen before in
GLib, when libglib-2.0.so.0 moved from /lib/x86_64-linux-gnu to
/usr/lib/x86_64-linux-gnu - but you're maybe seeing it for a previous
transition, when libusb-1.0.so.0 moved from /lib to /lib/x86_64-linux-gnu.

> The thing is, I have no idea where this /lib/libusb came from.  I'm
> pretty sure I didn't install anything other than debs from the
> official debian repos.  dpkg-query also does not know which package
> installed it:
> 
> $ dpkg-query -S /lib/libusb-1.0.so.0.1.0
> dpkg-query: no path found matching pattern /lib/libusb-1.0.so.0.1.0

The libusb-1.0-0 package installed /lib/libusb-1.0.so.0 before 2011.
The ls -l and md5sum output will help to determine whether this is an
outdated version from Debian, or a different version from outside Debian.

Are these old Debian installations that were installed before 2011 and
have been upgraded since then?

If yes, did they have unreliable disks, frequent crashes, or anything
like that in the 2011-2012 timeframe?

> Any clues
> where that file came from and what it may be used for?

The best theory I have at the moment is: when you upgrade from an old
package to a new package, and the new package ships different files,
dpkg is meant to delete the old file, leaving only the new file. It is
possible that there is a rare bug that causes it to *not* delete the
old file. If that happens, then ldconfig prefers the new file, and you
don't immediately notice that anything is wrong.

Perhaps years later, the library moves from a lower-priority directory in
the search path to a higher-priority directory, and suddenly ldconfig
will be preferring the older version: but you *still* don't notice
anything is wrong until a different program or library (in your case
libusbredirhost.so.1 and qemu) requires a symbol that wasn't available
in the new version.

smcv



Bug#972354: deepin-screenshot: FTBFS with Qt 5.15: error: aggregate ‘QPainterPath rectPath’ has incomplete type and cannot be defined

2020-10-24 Thread Dmitry Shachnev
Control: tags -1 + pending

On Fri, Oct 16, 2020 at 08:49:38PM +0300, Dmitry Shachnev wrote:
> Dear Maintainer,
>
> deepin-screenshot fails to build with Qt 5.15, currently available in
> experimental.

I have just uploaded an NMU fixing this to DELAYED/5.

The debdiff is attached, and I also created a merge request:

https://salsa.debian.org/pkg-deepin-team/deepin-screenshot/-/merge_requests/2

--
Dmitry Shachnev
diff --git a/debian/changelog b/debian/changelog
index 308832b..97730fd 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,16 @@
+deepin-screenshot (5.0.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Debian Janitor ]
+  * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository,
+Repository-Browse.
+
+  [ Dmitry Shachnev ]
+  * Add a patch to fix build with Qt 5.15 (closes: #972354).
+
+ -- Dmitry Shachnev   Sat, 24 Oct 2020 13:07:59 +0300
+
 deepin-screenshot (5.0.0-1) unstable; urgency=medium
 
   * New upstream release 5.0.0.
diff --git a/debian/patches/0002-Add-missing-QPainterPath-include.patch b/debian/patches/0002-Add-missing-QPainterPath-include.patch
new file mode 100644
index 000..c7d0499
--- /dev/null
+++ b/debian/patches/0002-Add-missing-QPainterPath-include.patch
@@ -0,0 +1,20 @@
+From: Dmitry Shachnev 
+Date: Sat, 24 Oct 2020 13:05:51 +0300
+Subject: Add missing QPainterPath include to fix build with Qt 5.15
+
+---
+ src/widgets/shapeswidget.cpp | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/src/widgets/shapeswidget.cpp b/src/widgets/shapeswidget.cpp
+index 3421937..5d346b4 100644
+--- a/src/widgets/shapeswidget.cpp
 b/src/widgets/shapeswidget.cpp
+@@ -21,6 +21,7 @@
+ 
+ #include 
+ #include 
++#include 
+ #include 
+ 
+ #include "src/utils/calculaterect.h"
diff --git a/debian/patches/series b/debian/patches/series
index 4cd7e70..da7f854 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 0001-bypass-deepin-turbo-invoker.patch
+0002-Add-missing-QPainterPath-include.patch
diff --git a/debian/upstream/metadata b/debian/upstream/metadata
new file mode 100644
index 000..028eeda
--- /dev/null
+++ b/debian/upstream/metadata
@@ -0,0 +1,4 @@
+Bug-Database: https://github.com/linuxdeepin/deepin-screenshot/issues
+Bug-Submit: https://github.com/linuxdeepin/deepin-screenshot/issues/new
+Repository: https://github.com/linuxdeepin/deepin-screenshot.git
+Repository-Browse: https://github.com/linuxdeepin/deepin-screenshot


signature.asc
Description: PGP signature


Bug#972389: libdatetime-timezone-perl 2.23-1+2020d flagged for acceptance

2020-10-24 Thread Adam D Barratt
package release.debian.org
tags 972389 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: libdatetime-timezone-perl
Version: 2.23-1+2020d

Explanation: update included data



Bug#972175: closed by Debian FTP Masters (reply to Thomas Pierson ) (Bug#972175: fixed in clementine 1.4.0~rc1+git346-g4e3e9c8d1+dfsg-1)

2020-10-24 Thread Dmitry Shachnev
Hi Thomas!

On Sun, Oct 18, 2020 at 01:06:06PM +, Debian Bug Tracking System wrote:
> We believe that the bug you reported is fixed in the latest version of
> clementine, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 972...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> Thomas Pierson  (supplier of updated clementine 
> package)

Unfortunately clementine cannot migrate to testing because it has
unsatisfiable Build-Depends on libprojectm-dev on armel/armhf.

On these two architectures, we build Qt with OpenGL ES instead of desktop
OpenGL. It looks like projectm ≥ 3 does not support that configuration.

Maybe you can build clementine with -DHAVE_VISUALISATIONS=OFF CMake option
on these architectures?

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Bug#972389: libdatetime-timezone-perl 2.23-1+2020c flagged for acceptance

2020-10-24 Thread Adam D Barratt
package release.debian.org
tags 972389 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: libdatetime-timezone-perl
Version: 2.23-1+2020c

Explanation: update included data



  1   2   >