Bug#919628: Apply Julia's LLVM patches

[Mo Zhou]

Hi Sylvestre,

Thank you! I think I'm filing an exception request for julia shortly.

On Fri, Feb 22, 2019 at 08:41:14AM +0100, Sylvestre Ledru wrote:
> Hello,
> 
> I started the work ( 
> https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/commit/408f329cd84ad41cef7fc41ee4ac2b4b4573945f
> ) on that but:
> 
> * some patches didn't apply

That's exactly why I do things about patchset quite slowly...
 
> * some are breaking the builds

Sounds strange. The LLVM embedded in Julia source doesn't fail to build.

> I will try to finish this week end
> 
> Anyway, this should not prevent you to move back to llvm packages as
> 
> I took this fix  "Fix a baseline violation on armhf (Closes: #914268)"

If the release team allows me to upload Julia 1.0.4 (next LTS release),
I'll remove the embedded LLVM (what a relief!)
 
> Cheers,
> 
> S

Bug#919557: [Pkg-mozext-maintainers] Bug#919557: webext-umatrix: garbled display of toolbar menu in Firefox 64.0-1

[Ximin Luo]

Control: block -1 by 922944

Martin Steigerwald:
> Package: webext-umatrix
> Version: 1.3.14+dfsg-2
> Severity: important
> 
> Dear Ximin,
> 
> I just installed webext-umatrix and found that its control panel does not
> show up correctly in Firefox. I attach a screenshot.
> 
> Some chars are missing, as if a font could not be loaded. Also the matrix
> of what is allowed and forbidden is not displayed at all for any webpage I
> have tried. The bug looks similar to
> 
> webext-ublock-origin: Missing icons in the toolbar menu
> https://bugs.debian.org/916431
> 
> where the issue was Firefox did not follow a relative symlink to the
> necessary font file. Maybe something similar is the culprit here?
> 

Hi Martin, symlinks is indeed the issue. Unfortunately and contrary to what was 
stated in that bug report, an absolute symlink doesn't work either.

For the time being you can work around the issue either by using firefox-esr 
instead of firefox (65) which is why I myself had not yet noticed this issue, 
it was working perfectly fine for me.

If you cannot run firefox-esr and must run firefox 65, you can also work around 
the issue by running:

$ sudo rm /usr/share/webext/umatrix/lib/punycode.js
$ sudo cp /usr/share/javascript/punycode/punycode.js 
/usr/share/webext/umatrix/lib/punycode.js

Since it works perfectly fine in firefox-esr I assume it's a regression and 
that the firefox Debian maintainer can hopefully get a fix out soon.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#922936: Acknowledgement (ganeti: KVM/QEMU Virtual machines won't start after the last qemu-system-x86_64 update.)

[Apollon Oikonomopoulos]

Control: tags -1 + upstream fixed-upstream - newcomer

Hi and thanks for the report!

On 02:30 Fri 22 Feb , Paul Parsons wrote:
> I can confirm, altering the following file, compiling it and restarting the
> ganeti service restores functionality :-
> 
> /usr/share/ganeti/2.16/ganeti/hypervisor/hv_kvm/__init__.py
> 
> Ln1286 - kvm_cmd.extend(["*-device", "virtio-balloon*"])

This has been fixed upstream[1] and I will upload a fixed version soon.  
Note that it's not only `-balloon` that has been dropped, but `-balloon` 
is the only option that is passed to *every* instance by default and so 
it will prevent all instances from starting.

Cheers,
Apollon

[1] https://github.com/ganeti/ganeti/pull/1342

Bug#847440: [Resolvconf-devel] Bug#847440: pending

[Thomas Hood]

Hi there,

I am still the maintainer, at least on paper.

After my attempt to get through the new maintainer process failed (several
years ago now) I tried to find someone to take over as maintainer of
resolvconf but I was not successful. (Know anyone who might be interested?)
As I felt it was my duty I carried on as maintainer with a sponsor, but not
being a member of the project my interest in Debian gradually declined and
releases became less and less frequent. The importance of the package has
also declined, especially now that the package is no longer part of Ubuntu
base. I use Ubuntu, not Debian.

Doing a new release has been on my TODO list for many months but it didn't
have a high enough priority to get executed. Sometimes, the longer one
avoids a task, the more one avoids it.

I still want to do a new release in order to close the open bugs, none of
which is RC. Setting a deadline should help. I hereby set a deadline for
myself of the end of March 2019. I realize that is too late for Buster.

Cheers,
Thomas Hood



Op do 21 feb. 2019 13:09 schreef Michael Prokop :

> * Bernhard Schmidt [Sun May 07, 2017 at 10:57:24PM +0200]:
> > On Thu, Dec 15, 2016 at 11:18:47AM +, Thomas Hood wrote:
>
> > > package resolvconf
> > > tags 847440 pending
> > > stop
>
> > You set this to Pending almost five months ago, do you still plan to
> > apply this for Stretch?
>
> I'm re-asking the same question for buster. :)
> We have resolvconf 1.79 in stable, testing and unstable,
> its upload dating back to 2016-05-30.
>
> Is someone still working on resolvconf?
>
> regards,
> -mika-
> ___
> Resolvconf-devel mailing list
> resolvconf-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/resolvconf-devel

Bug#919628: Apply Julia's LLVM patches

[Sylvestre Ledru]

Hello,

I started the work ( 
https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/commit/408f329cd84ad41cef7fc41ee4ac2b4b4573945f 
) on that but:


* some patches didn't apply

* some are breaking the builds

I will try to finish this week end

Anyway, this should not prevent you to move back to llvm packages as

I took this fix  "Fix a baseline violation on armhf (Closes: #914268)"

Cheers,

S


Le 22/02/2019 à 00:55, Mo Zhou a écrit :

Hi Sylvestre,

Any chance for getting this into Buster? If there is any, I'd like
to apply for freeze exception early, especially for the next Julia
LTS release 1.0.4 (likely to come out before 1st March)

On Fri, Feb 08, 2019 at 08:46:06AM +0100, Sylvestre Ledru wrote:

Wahou, better than I was expecting! Many thanks!

I will take as much as possible! Thanks

S


Le 08/02/2019 à 07:47, Mo Zhou a écrit :

Hi Sylvestre,

Please cherry-pick at least: (8) (12) (13) (14) (15)

Recommended to include: (1) (2) (4) (5) (11)

Feel free to ignore: (6) (9) (16) (17)

I have no idea about: (3) (7) (10)

https://github.com/JuliaLang/julia/tree/master/deps/patches
I've listed patches for llvm 6.0.1




(1) [unwind] llvm-D27629-AArch64-large_model_6.0.1

  Fix unwind info relocation with large code model on AArch64
  https://reviews.llvm.org/D27629

(2) [performance] llvm-D34078-vectorize-fdiv

  Enable support for floating-point division reductions
  https://reviews.llvm.org/D34078

(3) [nvptx] llvm-6.0-NVPTX-addrspaces

  No idea about this patch.

(4) [performance regression] llvm-D42262-jumpthreading-not-i1

  For details see Julia commit: e94a1f8b08e0bc3b8093d8f1dc2bf3c8f5d59519
  merged upstream: https://reviews.llvm.org/D42262

(5) [???] llvm-PPC-addrspaces

  merged upstream: https://reviews.llvm.org/D43781

(6) [ignore: mingw] llvm-6.0.0_D27296-libssp
  [ignore: mingw] llvm-6.0-D44650

(7) [???] llvm-D46460

  still under review: https://reviews.llvm.org/D46460

(8) [???] llvm-rL327898

  
https://github.com/JuliaLang/julia/blob/master/deps/patches/llvm-rL327898.patch
  Fixes Julia issues: #27055 #27080 #27032 #27603

(9) [ignore: compiler complain] llvm-6.0-DISABLE_ABI_CHECKS

(10) [profiling] llvm-OProfile-line-num

(11) [profiling] llvm-D44892-Perf-integration

   merged upstream: https://reviews.llvm.org/D44892

(12) [bug fix] llvm-D49832-SCEVPred
   [bug fix] llvm-rL323946-LSRTy

  Add LLVM patches for bugs introducing illegal ptrtoint
  rL323946 [LSR] Don't force bases of foldable formulae to the final type.
  D49832   [SCEV] Don't expand Wrap predicate using inttoptr in ni 
addrspaces

(13) llvm-D50010-VNCoercion-ni

  Fixes julia issue: #28360 (#28362)
  https://reviews.llvm.org/D50010

(14) llvm-D50167-scev-umin

  Add LLVM patch to explicitly represent umin in SCEV (#28403)
  Fix mix-type arithmetic detection in umin/max expansion (#28465)
  Fixes #28464
  Fixes #28379
  Fixes #28388

(15) llvm-rL326967-aligned-load

  Fixes incorrect codegen: #28726

(16) [ignore: win64] llvm-D51842-win64-byval-cc

(17) [...] llvm-D57118-powerpc

  https://reviews.llvm.org/D57118

Bug#916594: [Pkg-mozext-maintainers] Bug#916594: webext-umatrix: Can not load configuration from backup

[Ximin Luo]

Control: severity -1 important
Control: forwarded -1 https://github.com/uBlockOrigin/uBlock-issues/issues/144
Control: tags -1 + upstream

Bumping down the severity, there is no data loss. The "backup" function works 
fine, it's just the "restore" functionality that doesn't work.

X

Antoine Beaupre:
> Package: webext-umatrix
> Version: 1.3.14+dfsg-2
> Followup-For: Bug #916594
> 
> Control: severity 916594 grave
> 
> I think this is serious enough to forbid this package from being
> shipped with buster. It makes it impossible, for example, for a user
> to switch from the extension shipped from addons.mozilla.org to the
> Debian package, which was my use case.
> 
> Also note that the rules cannot be modified by hand either, nor do
> they persist when modified through the normal UI.
> 
> Thefore I'm marking this as "grave", as it "makes the package in
> question unusable or mostly so" and "causes data loss".
> 
> Thank you for your attention,
> 
> A.
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (500, 'testing'), (1, 'experimental'), (1, 'unstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), 
> LANGUAGE=fr_CA.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages webext-umatrix depends on:
> ii  fonts-font-awesome   5.0.10+really4.7.0~dfsg-1
> ii  fonts-roboto-hinted  2:0~20170802-1
> ii  libjs-codemirror 5.19.0-1
> ii  libjs-punycode   1.3.2-2
> ii  publicsuffix 20190128.1516-1
> 
> Versions of packages webext-umatrix recommends:
> ii  firefox-esr  60.4.0esr-1
> 
> webext-umatrix suggests no packages.
> 
> -- debconf-show failed
> 
> ___
> Pkg-mozext-maintainers mailing list
> pkg-mozext-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-mozext-maintainers
> 


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#922944: firefox refuses to follow symlinks in /usr/share/webext outside of it

[Ximin Luo]

Package: firefox
Version: 65.0.1-1
Severity: important
Control: affects -1 webext-umatrix

Dear Maintainer,

I'm not sure if this relates to upstream, since it's to do with webextension
loading Debian paths.

The behaviour in firefox-esr is fine. I only recently switched to using firefox
65, so did not notice this until recently.

The webext-umatrix extension uses symlinks to other packages, like this:

$ ls -gG /usr/share/webext/umatrix/lib/
total 16
drwxr-xr-x 2 4096 Feb 21 22:38 diff/
lrwxrwxrwx 1   30 Aug  6  2011 codemirror -> ../../../javascript/codemirror/
-rw-r--r-- 1 9994 Feb 21 22:21 publicsuffixlist.js
lrwxrwxrwx 1   40 Feb 21 23:04 punycode.js -> 
../../../javascript/punycode/punycode.js

This works in firefox-esr but not firefox (65), instead in the Browser Console 
I get:

Loading failed for the 

Bug#841524: [Pkg-emacsen-addons] Bug#841524: Depend or Suggest markdown package for preview to work

[Nicholas D Steeves]

On Sat, Feb 16, 2019 at 04:18:04PM -0400, David Bremner wrote:
> Nicholas D Steeves  writes:
> 
> >
> > List of supported converters from upstream README.md: markdown |
> > libtext-multimarkdown-perl | pandoc
> >
> > Also available in Debian: discount | python3-markdown
...
> > Given that markdown-mode is configured upstream to use "bin:markdown",
> > it seems more reasonable (and easy!) to just Recommends markdown, and
> > then add a list of alternatives to Suggests.  This way it works out of
> > the box, and the user can consult Suggests when interpreting the
> > upstream README.md.
> 
> I don't usually think about Suggests as alternatives to Recommends, but
> rather things less commonly useful, but still enabling additional
> functionality.

That's fair, and I'll confess that my idea for using Suggests in this
way might be hacky...  Also, 'just realised that declaring a list of
optional packages in Suggests might increase the maintenance burden of
this package.

So I guess the wonderful kinda bloated pandoc will not be in Suggests,
even though upstream specifically mentions it, because a) it doesn't
provide /u/b/markdown and won't work ootb.  b) it potentially
increases our maintenance burden.  c) using Suggests in this way might
be hacky?

> markdown, libtext-markdown-perl and discount provide
> /usr/bin/markdown. You could test how well those work ootb, 
> and recommend them as alternatives if it seems ok.

That seems like a solid plan.  In particular, any that fail at
markdown-mode's special support for github flavour can be dropped from
the list of alternative Recommends.  So we'll eventually end up with
one or more recommends, and html export will work ootb.

Rather than manually test these three alternative Recommends, I'd
prefer to enable the upstream self-tests, and then figure out how to
run the suite for each of markdown, libtext-markdown-perl, and
discount.  <- that seems like a fun challenge, with some useful
problems.

> There are also conflicts between several of those, which looks odd to
> me, but I'll investigate that seperately.

Maybe they conflict on the file path /usr/bin/markdown?  I asked
someone on #devel about whether it would be hypothetically reasonable
for markdown-to-html packages to "Provide:
virtual-markdown-converter".  In his/her view, it's not...

Thanks for investigating this bit, very much appreciated!


Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#922942: logcheck-database: systemd ignores does not handle "Add random time" in milliseconds

[Vincas Dargis]

Package: logcheck-database
Version: 1.3.18
Severity: minor

Dear Maintainer,

I've got email from logheck with these lines:

Feb 22 06:13:56 hostname systemd[1]: apt-daily-upgrade.timer: Adding 43min 
991.357ms random time.

Feb 18 20:09:53 hostname systemd[1]: apt-daily.timer: Adding 1h 4min 37.081ms 
random time.

Looks like rule [0] does not handle millisecond case.

Here's the fix:

^[[:alpha:]]{3} [ :[:digit:]]{11} [._[:alnum:]\-]+ systemd\[[0-9]+\]: 
[-_[:alnum:]]+.timer: Adding ([0-9]+h )?([0-9]{1,2}min 
)?*([0-9]{1,2}\.[0-9]{6}s)|([0-9]{1,3}\.[0-9]{3}ms) random time\.$

I'll provide Salsa MR in upcomming days.

[0] 
https://sources.debian.org/src/logcheck/1.3.19/rulefiles/linux/ignore.d.server/systemd/#L6


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

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

-- Configuration Files:
/etc/logcheck/cracking.d/kernel [Errno 13] Permission denied: 
'/etc/logcheck/cracking.d/kernel'
/etc/logcheck/cracking.d/rlogind [Errno 13] Permission denied: 
'/etc/logcheck/cracking.d/rlogind'
/etc/logcheck/cracking.d/rsh [Errno 13] Permission denied: 
'/etc/logcheck/cracking.d/rsh'
/etc/logcheck/cracking.d/smartd [Errno 13] Permission denied: 
'/etc/logcheck/cracking.d/smartd'
/etc/logcheck/cracking.d/tftpd [Errno 13] Permission denied: 
'/etc/logcheck/cracking.d/tftpd'
/etc/logcheck/cracking.d/uucico [Errno 13] Permission denied: 
'/etc/logcheck/cracking.d/uucico'
/etc/logcheck/ignore.d.paranoid/bind [Errno 13] Permission denied: 
'/etc/logcheck/ignore.d.paranoid/bind'
/etc/logcheck/ignore.d.paranoid/cron [Errno 13] Permission denied: 
'/etc/logcheck/ignore.d.paranoid/cron'
/etc/logcheck/ignore.d.paranoid/incron [Errno 13] Permission denied: 
'/etc/logcheck/ignore.d.paranoid/incron'
/etc/logcheck/ignore.d.paranoid/logcheck [Errno 13] Permission denied: 
'/etc/logcheck/ignore.d.paranoid/logcheck'
/etc/logcheck/ignore.d.paranoid/postfix [Errno 13] Permission denied: 
'/etc/logcheck/ignore.d.paranoid/postfix'
/etc/logcheck/ignore.d.paranoid/ppp [Errno 13] Permission denied: 
'/etc/logcheck/ignore.d.paranoid/ppp'
/etc/logcheck/ignore.d.paranoid/pureftp [Errno 13] Permission denied: 
'/etc/logcheck/ignore.d.paranoid/pureftp'
/etc/logcheck/ignore.d.paranoid/qpopper [Errno 13] Permission denied: 
'/etc/logcheck/ignore.d.paranoid/qpopper'
/etc/logcheck/ignore.d.paranoid/squid [Errno 13] Permission denied: 
'/etc/logcheck/ignore.d.paranoid/squid'
/etc/logcheck/ignore.d.paranoid/ssh [Errno 13] Permission denied: 
'/etc/logcheck/ignore.d.paranoid/ssh'
/etc/logcheck/ignore.d.paranoid/stunnel [Errno 13] Permission denied: 
'/etc/logcheck/ignore.d.paranoid/stunnel'
/etc/logcheck/ignore.d.paranoid/sysklogd [Errno 13] Permission denied: 
'/etc/logcheck/ignore.d.paranoid/sysklogd'
/etc/logcheck/ignore.d.paranoid/telnetd [Errno 13] Permission denied: 
'/etc/logcheck/ignore.d.paranoid/telnetd'
/etc/logcheck/ignore.d.paranoid/tripwire [Errno 13] Permission denied: 
'/etc/logcheck/ignore.d.paranoid/tripwire'
/etc/logcheck/ignore.d.paranoid/usb [Errno 13] Permission denied: 
'/etc/logcheck/ignore.d.paranoid/usb'
/etc/logcheck/ignore.d.server/acpid [Errno 13] Permission denied: 
'/etc/logcheck/ignore.d.server/acpid'
/etc/logcheck/ignore.d.server/amandad [Errno 13] Permission denied: 
'/etc/logcheck/ignore.d.server/amandad'
/etc/logcheck/ignore.d.server/amavisd-new [Errno 13] Permission denied: 
'/etc/logcheck/ignore.d.server/amavisd-new'
/etc/logcheck/ignore.d.server/anacron [Errno 13] Permission denied: 
'/etc/logcheck/ignore.d.server/anacron'
/etc/logcheck/ignore.d.server/anon-proxy [Errno 13] Permission denied: 
'/etc/logcheck/ignore.d.server/anon-proxy'
/etc/logcheck/ignore.d.server/apache [Errno 13] Permission denied: 
'/etc/logcheck/ignore.d.server/apache'
/etc/logcheck/ignore.d.server/apcupsd [Errno 13] Permission denied: 
'/etc/logcheck/ignore.d.server/apcupsd'
/etc/logcheck/ignore.d.server/arpwatch [Errno 13] Permission denied: 
'/etc/logcheck/ignore.d.server/arpwatch'
/etc/logcheck/ignore.d.server/asterisk [Errno 13] Permission denied: 
'/etc/logcheck/ignore.d.server/asterisk'
/etc/logcheck/ignore.d.server/automount [Errno 13] Permission denied: 
'/etc/logcheck/ignore.d.server/automount'
/etc/logcheck/ignore.d.server/bind [Errno 13] Permission denied: 
'/etc/logcheck/ignore.d.server/bind'
/etc/logcheck/ignore.d.server/bluez-utils [Errno 13] Permission denied: 
'/etc/logcheck/ignore.d.server/bluez-utils'
/etc/logcheck/ignore.d.server/courier [Errno 13] Permission denied: 
'/etc/logcheck/ignore.d.server/courier'
/etc/logcheck/ignore.d.server/cpqarrayd [Errno 13] Permission denied: 
'/etc/logcheck/ignore.d.server/cpqarrayd'

Bug#922943: xdiskusage: segmentation fault by du result which is just 2 lines

[Tanaka Akira]

Package: xdiskusage
Version: 1.48-10.1+b1
Severity: normal

I found that xdiskusage aborts as follows.

  % mkdir a b
  % du a b > du.txt
  % cat du.txt
  4 a
  4 b
  % xdiskusage < du.txt
  zsh: segmentation fault  xdiskusage < du.txt

It seems the problem is fixed at latest version, xdiskusage-1.51.tgz in
http://xdiskusage.sourceforge.net/
(It needs "-" argument, though.)

  % ./xdiskusage - < /tmp/du.txt

I hope debian package incorporates the latest version.

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

Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores)
Locale: LANG=ja_JP.utf8, LC_CTYPE=ja_JP.utf8 (charmap=sh: 0: getcwd()
failed: No such file or directory
UTF-8), LANGUAGE=ja_JP.utf8 (charmap=sh: 0: getcwd() failed: No such
file or directory
UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages xdiskusage depends on:
ii  libc6 2.24-11+deb9u3
ii  libfltk1.11.1.10-23
ii  libgcc1   1:6.3.0-18+deb9u1
ii  libgl1-mesa-glx [libgl1]  13.0.6-1+b2
ii  libglu1-mesa [libglu1]9.0.0-2.1
ii  libstdc++66.3.0-18+deb9u1
ii  libx11-6  2:1.6.4-3+deb9u1
ii  libxext6  2:1.3.3-1+b2
ii  libxinerama1  2:1.1.3-1+b3

xdiskusage recommends no packages.

xdiskusage suggests no packages.

-- no debconf information
-- 
Tanaka Akira

Bug#922941: RFP: node-eslump -- Fuzz testing JavaScript parsers and suchlike programs.

[Jeff Cliff]

Package: wnpp
Severity: wishlist

* Package name: node-eslump
  Version : 1.6.2
  Upstream Author : Simon Lydell
* URL : 
http://zr4zqgxlhgljst3kuqu7azx43w6p7ezsb6kgh2msg7pkwvoiairffwid.onion/dir
* License : MIT
  Programming Lang: javascript
  Description : Fuzz testing JavaScript parsers and suchlike programs.

Testing tool for testing edge cases in javascript parser code.

Initially, eslump basically was just strung together shift-fuzzer and 
shift-codegen.
Later it became its own nodejs/npm package and was used for 'fuzzing' 
node-prettier ( #879665 ).

node-eslump is a prerequisite for node-eslint ( #743404 )

Bug#922925: libreoffice: Please add a crash tracker

[Rene Engelhard]

tag 992925 + moreinfo
thanks

Hi,

On Thu, Feb 21, 2019 at 10:47:48PM +0100, Jean-Philippe MENGUAL wrote:
> I would love to have the LO crash tracker in Debian, so that I could use Deb 
> packages to report bugs with a good trace. Would it be
> possible?

And send where? Upstrem? Where we have a different build config than
them? (Let alone think about external libraries). Do we really want our
LO to "phone home" on a crash? Do we want to set up a web service for
those reports? (The latter one definitely is no)

For a meaningful backtrace you just need the *-dbgsym's, not necessarily
the "crash reporter".

And then there's it using libbreakpad. Which TTBOMK is not packaged, and
I am not going to do that (and I am not going to use the internal
library for this either).

And if I read upstreams configure.ac right the default for
--enable-breakpad even is no.

So no: won't do it.

Regards,

Rene

Bug#922826: Acknowledgement (unblock: calamares/3.2.4-3)

[Jonathan Carter]

calamares's reverse dependencies calamares-settings-debian and
live-wrapper have also been removed. Unblocking those after calamares
would also be great, thanks!

Bug#922940: RFS: ruby-debian/0.3.10

[Carlos Maddela]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "ruby-debian"

 * Package name: ruby-debian
   Version : 0.3.10
   Upstream Author : Fumitoshi UKAI 
 * License : GPL-2+
   Section : ruby

  It builds this binary package:

ruby-debian - ruby interface for dpkg

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

  https://mentors.debian.net/package/ruby-debian


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

dget -ux 
https://mentors.debian.net/debian/pool/main/r/ruby-debian/ruby-debian_0.3.10.dsc

  I have also pushed my changes here:

https://salsa.debian.org/e7appew-guest/ruby-debian.

  Changes since the last upload:

ruby-debian (0.3.10) unstable; urgency=medium

  [ Cédric Boutillier ]
  * Remove version in the gem2deb build-dependency.

  [ Antonio Terceiro ]
  * Remove myself from uploaders.

  [ Carlos Maddela ]
  * Build with Debhelper compat level 12.
  * Fix formatting and remove trailing spaces from debian/changelog.
  * Update VCS details.
  * Update debian/copyright.
  * Fix spelling error in dpkg-ruby man page.
  * Suppress uses-dpkg-database-directly Lintian warning.
  * Mark ruby-debian package Multi-Arch: same.
  * Build as verbosely as possible, unless terse build option set.
  * Re-implement gnu_build_architecture() using dpkg-architecture.
dpkg's --print-gnu-build-architecture option was removed in version
1.13.1.
  * Set Rules-Requires-Root: no.
  * Declare compliance with Debian Policy 4.3.0.
  * Add myself to uploaders list and remove Ryan Niebur. (Closes: #856365)
  * Re-run wrap-and-sort.
  * Add support for xz, lzma and bzip2 compressed debs. (Closes: #718389)
  * Ignore :any after package names when checking dependencies.
  * Include unpurged conf files in Debian::Dpkg.listfiles results.
(Closes: #681988)
  * Fix errors during argument parsing in dpkg-checkdeps.
  * Improve handling of non-UTF8 package info.
Instead of just giving up when non-UTF8 package info is found, try
to convert it to UTF8 first, and then skip the current package if
this fails. (Closes: #773485)

  [ James Lu ]
  * Call 'dpkg --print-architecture' instead of
'dpkg --print-installation-architecture'. (Closes: #854522)

  [ Sam Morris ]
  * Fix warnings generated by lib/debian.rb. (Closes: #889651)

 -- Carlos Maddela   Fri, 22 Feb 2019 15:12:04 +1100


  Regards,
   Carlos Maddela

Bug#810964: [Xen-devel] MCE/EDAC Status/Updating?

[Elliott Mitchell]

On Mon, Feb 18, 2019 at 02:37:48AM -0700, Jan Beulich wrote:
> >>> On 18.02.19 at 09:42,  wrote:
> > On Mon, Feb 18, 2019 at 01:12:16AM -0700, Jan Beulich wrote:
> >> >>> On 15.02.19 at 19:20,  wrote:
> >> > On Fri, Feb 15, 2019 at 03:58:49AM -0700, Jan Beulich wrote:
> >> >> Well, Fam10 is mentioned explicitly, but as per the use of e.g.
> >> >> mcheck_amd_famXX newer ones are supported by this code
> >> >> as well.
> >> > 
> >> > In that case sometime between Xen 4.1 and Xen 4.4, the AMD MCE/EDAC code
> >> > was completely broken and hasn't been fixed.
> >> 
> >> I can't say I'm surprised, but details of the breakage would still
> >> be appreciated.
> > 
> > Originally noticed with Debian: https://bugs.debian.org/810964 
> > 
> > Original observer noticed that half the memory controllers were missing
> > from Linux's Domain-0 dmesg with Xen 4.4.  EDAC capability flags are
> > missing with Xen 4.4.
> 
> And I had been commenting in this bug. I don't recall technical data
> ever having emerged on the list here as to what is really going on,
> and what the root of this perceived regression is.

I've been having an interesting time trying to figure out where to look
to find appropriate information.

I'm thinking Debian's default Xen log level is a little too high.  Adding
"loglvl=info" doesn't put all that much in Xen's dmesg.  I'm suspecting
"mce_verbosity=verbose" may be a different story though.

"loglvl=info" gets me "AMD Fam10h machine check reporting enabled", so
looks like Xen is successfully getting its MCE support operational.

Taking a closer look at Dom0's dmesg though:

MCE: In-kernel MCE decoding enabled.
EDAC amd64: DRAM ECC enabled.
EDAC amd64: NB MCE bank disabled, set MSR 0x017b[4] on node 0 to enable.
EDAC amd64: ECC disabled in the BIOS or no ECC capability, module will not load.
 Either enable ECC checking or force module loading by setting 
'ecc_enable_override'.
 (Note that use of the override may cause unknown side effects.)

So it seems Linux wants bit 4 of MSR_IA32_MCG_CTL set before it will
willingly enable MCE support (I've no idea what this does).

This was done in commit b272353fe98db5bdc73fff3c60a0574835df4c87.


> > I'd been working with a processor Linux was reporting as
> > "cpu family : 16" (ah yes "10h", that funky olde way of refering to
> > things) and noticing Linux's EDAC support failing on kernel start.  In
> > which case the EDAC support on AMD processors was completely broken
> > between 4.1 and 4.4 (hadn't realized that processor was just old enough
> > to be interesting).
> 
> While there's a relation, I think we need to keep #MC handling
> and EDAC separate here: The latter lives entirely in Dom0. And
> as said in the Debian bug, at least back at the time there was no
> reason to believe the driver would work on Xen other than by
> accident.

True, they might have merely been noticed at the same time and in fact
be two distinct issues.  Having EDAC reporting broken is *very* bad.

I am left though noticing how the state of Xen's EDAC support looks
rather odd from how other bits of Xen are evolving.  Rather than going
more in a direction of para-virtualization, this code looks to be heading
more towards true virtualization.

A more PV type approach might be to let Dom0 handle decoding the machine
check registers.  Then Dom0 asks Xen for what is at physical address X,
then potentially turns this into a PV message to the appropriate
domain and potentially logs the event.  Such an approach could be used
to synthesize machine check events for testing VMs.  Qemu would then
need code to simulate the appropriate register values for a HVM.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445









On Mon, Feb 18, 2019 at 02:37:48AM -0700, Jan Beulich wrote:
> >>> On 18.02.19 at 09:42,  wrote:
> > On Mon, Feb 18, 2019 at 01:12:16AM -0700, Jan Beulich wrote:
> >> >>> On 15.02.19 at 19:20,  wrote:
> >> > On Fri, Feb 15, 2019 at 03:58:49AM -0700, Jan Beulich wrote:
> >> >> Well, Fam10 is mentioned explicitly, but as per the use of e.g.
> >> >> mcheck_amd_famXX newer ones are supported by this code
> >> >> as well.
> >> > 
> >> > In that case sometime between Xen 4.1 and Xen 4.4, the AMD MCE/EDAC code
> >> > was completely broken and hasn't been fixed.
> >> 
> >> I can't say I'm surprised, but details of the breakage would still
> >> be appreciated.
> > 
> > Originally noticed with Debian: https://bugs.debian.org/810964 
> > 
> > Original observer noticed that half the memory controllers were missing
> > from Linux's Domain-0 dmesg with Xen 4.4.  EDAC capability flags are
> > missing with Xen 4.4.
> 
> And I had been commenting in this bug. I don't recall technical data
> ever having emerged on the list here as to what is really going on,
> and 

Bug#922939: sxiv FTCBFS: uses the wrong compiler

[Helmut Grohne]

Source: sxiv
Version: 25-1
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

sxiv fails to cross build from source, because it uses the build
architecture compiler. It actually uses the correct compiler during
dh_auto_build and successfully cross builds. But then, it figures that
since .git/index doesn't exist, it must remake version.h during
dh_auto_install. Since dh_auto_install does not pass cross tools to
make, this fails. Having to rebuild during dh_auto_install sounds like a
bug though and that's what the attached patch fixes. Please consider
applying it.

Helmut
--- sxiv-25.orig/Makefile
+++ sxiv-25/Makefile
@@ -52,7 +52,7 @@
 	@echo "GEN $@"
 	cp $(srcdir)/config.def.h $@
 
-version.h: Makefile .git/index
+version.h: Makefile $(wildcard .git/index)
 	@echo "GEN $@"
 	v="$$(cd $(srcdir); git describe 2>/dev/null)"; \
 	echo "#define VERSION \"$${v:-$(version)}\"" >$@

Bug#922006: please move dkimpy-milter to python3

[Daniel Kahn Gillmor]

Control: forwarded 922006 
https://code.launchpad.net/~dkimpy-milter-dev/dkimpy-milter/+git/dkimpy-milter/+ref/dkg/python3

On Mon 2019-02-11 03:02:30 -0500, Scott Kitterman wrote:
> I think the code changes are probably very small.  I just did an SPF milter 
> using pyspf and the python3 pymilter (pyspf-milter - in Buster already) and 
> it 
> seemed pretty straightforward.
>
> It may be as little as using io.BytesIO vice StringIO.StringIO.  Given it 
> wasn't a bother for the SPF milter, I'll probably go ahead with it soon.

thanks!  I've submitted the dkg/python3 branch upstream for your
review.  It is applied after a series of changes i made that provide a
simple test environment, so you can verify that the milter behaves the
same way after the python3 conversion.  Commit ID
ea09bab1a8fb9eeed3429e9a8411ee42f9c423f3 is the most complex patch, in
particular bytes vs. strings.  the commit message there provides more
information about the difficulties i encountered.

I'm now running this; i'll let you know if i see any problems with it.

--dkg


signature.asc
Description: PGP signature

Bug#922048: please allow socket-activation of dkimpy-milter via systemd

[Daniel Kahn Gillmor]

Control: forwarded 922048 
https://code.launchpad.net/~dkimpy-milter-dev/dkimpy-milter/+git/dkimpy-milter/+ref/dkg/socket-activation

On Mon 2019-02-11 17:15:53 -0500, Scott Kitterman wrote:
> In the near-term, I think we need to have two ways to start: one with systemd 
> (socket activation) and one for all other init systems.  If you can give me 
> an 
> idea what the socket activation changes might look like, I can think about 
> how 
> I might integrate the two.

thanks, i've done that in the linked upstream series, which depends on
the conversion to python3 and a test suite that i built to make sure
dkimpy-milter actually works.  let me know if you want to talk over the
changes.

--dkg


signature.asc
Description: PGP signature

Bug#922938: RFS: python-css-parser/1.0.4-1~bpo9+1

[Nicholas D Steeves]

Package: sponsorship-requests
Severity: normal
Justification: necessary for to update the bpo for Calibre

Dear mentors,

I am looking for a sponsor for my package "python-css-parser"

Package name: python-css-parser
Version : 1.0.4-1~bpo9+1
Upstream Author : Christof Hoeke, Walter Doerwald,
  and Kovid Goyal 
URL : https://github.com/ebook-utils/css-parser
License : LGPL-3+
Section : python

It builds these binary packages:

  python-css-parser - CSS related utilities (parsing, serialization, etc) for 
Python 2
  python3-css-parser - CSS related utilities (parsing, serialization, etc) for 
Python 3

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

  https://mentors.debian.net/package/python-css-parser

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

dget -x 
https://mentors.debian.net/debian/pool/main/p/python-css-parser/python-css-parser_1.0.4-1~bpo9+1.dsc


Regards,
Nicholas

Bug#922937: aaphoto FTCBFS: Missing dependency libgomp1

[Do Thanh Trung]

Source: aaphoto
Version: 0.45-1
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Hi,

"aaphoto" fails to cross build because of missing dependency "libgomp1".
When build native, "libgomp1" can be installed through dependencies of 
"debhelper".
However when cross build, for example armhf, debhelper:native will be 
used instead of debhelper:armhf, so libgomp1:armhf is not installed.


Error:
dpkg-shlibdeps: error: cannot find library libgomp.so.1 needed by 
debian/aaphoto/usr/bin/aaphoto (ELF format: 'elf32-littlearm' abi: 
'01010028'; RPATH: '')

dpkg-shlibdeps: error: cannot continue due to the error above


This can be fixed by adding libgomp1 to Build-Depends.

--
Trung
diff -Nru aaphoto-0.45/debian/control aaphoto-0.45/debian/control
--- aaphoto-0.45/debian/control 2016-07-10 08:06:47.0 -0400
+++ aaphoto-0.45/debian/control 2016-07-10 07:38:19.0 -0400
@@ -6,7 +6,8 @@
  dh-autoreconf,
  autotools-dev,
  libjpeg-dev,
- libpng-dev
+ libpng-dev,
+ libgomp1
 Standards-Version: 3.9.8
 Homepage: http://log69.com/aaphoto_en.html
 
-- 
This mail was scanned by BitDefender
For more information please visit http://www.bitdefender.com

Bug#922936: Acknowledgement (ganeti: KVM/QEMU Virtual machines won't start after the last qemu-system-x86_64 update.)

[Paul Parsons]

I can confirm, altering the following file, compiling it and restarting the
ganeti service restores functionality :-

/usr/share/ganeti/2.16/ganeti/hypervisor/hv_kvm/__init__.py

Ln1286 - kvm_cmd.extend(["*-device", "virtio-balloon*"])


On Fri, 22 Feb 2019 at 01:30, Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 922936:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922936.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Debian Ganeti Team 
>
> If you wish to submit further information on this problem, please
> send it to 922...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 922936: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922936
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#905309: nvidia-modeset: WARNING: GPU:0: Lost display notification (0:0x00000000); continuing

[Allan Wind]

nvidia-driver 390.87 crashes the kernel on the host where I had 
this issue, so I think the technical correct answer is "unknown".


This is an intermittent issue, at times minutes apart, but mostly 
weeks or months.  Is the required hard reboot that really makes 
this awful.  If it helps, I can report back in 3 months on 
the unstable version currently 410.93-2.


On 2019-02-22 02:42:03, Andreas Beckmann wrote:

Control: tag -1 moreinfo upstream

On 2018-08-03 02:25, Allan Wind wrote:

Package: nvidia-driver
Version: 384.130-1



I noticed the fan on my laptop was spinning at full speed which
signifies heavy load.  Screens suspended, and they don't unsuspend when
I pressed the keyboard.  I ssh into the machine remotely, and see that
nvidia-modeset is using 100% cpu.  The only thing unusual in syslog is:

2018-08-02T22:49:34.702+00:00 vent kernel: nvidia-modeset: WARNING:
GPU:0: Lost display notification (0:0x); continuing.


Is this still reproducible with the 390.xx driver now in stretch?

Andreas


--
Allan Wind
Yaxto - Runs Your Business

Bug#922798: nvidia-driver: Xorg uses wrong copy of libglx.so with nvidia-driver version 415.27

[Andreas Beckmann]

Control: tag -1 moreinfo

On 2019-02-20 21:42, Michael wrote:
> I do not know the origin of '/usr/lib/xorg/modules/extensions/libglx.so' but 
> it

That's the one from xserver-xorg-core
(dpkg -S /usr/lib/xorg/modules/extensions/libglx.so)
Try
  debsums -c xserver-xorg-core
to see whether this has been replaced by using the .run installer.

> seems to me that it was installed via nvidia-installer. And therefore the 
> issue
> could be solved with the 'nvidia-installer-cleanup' package.

The 415.xx driver does no longer have a replacement libglx.so, so it
should be fine to load the original one.

But from your xorg.log.old I conclude that it did not even attempt to
load the nvidia driver ... was the kernel module loaded after booting
with the 415.xx driver?
You could try this minimal /etc/X11/xorg.conf:

Section "Device"
Identifier "My GPU"
Driver "nvidia"
EndSection


Andreas

Bug#922615: nvidia-driver: Windows not visible on third screen after stable upgrade

[Andreas Ronnquist]

On Fri, 22 Feb 2019 02:30:42 +0100
Andreas Beckmann  wrote:

>On 2019-02-18 14:08, Andreas Ronnquist wrote:
>> << /etc/X11/xorg.conf >>
>> # nvidia-settings: X configuration file generated by nvidia-settings
>> # nvidia-settings:  version 384.111  (build-user@build-machine)  Sun
>> Feb 25 17:18:20 UTC 2018  
>
>That xorg.conf was generated for an older driver.
>a) do you really need an xorg.conf? I assume yes due to your special
>display setup
>b) you probably need to regenerate it for the current driver - maybe
>some internals have changed that you are now fixing manually every time
>

Hi!

Thanks - 

Trying to remove the xorg.conf does work - Then the setup works fine
when logged in, but then it is problematic in the lightdm login (The
screens are in the wrong order and doesn't honor my pivot setup, but
this fixes itself when logging in - I guess this is Xfce screen
settings that activates here, you probably know better) -

If I generate a xorg.conf in nvidia-settings and save to /etc/X11/ I
run into the problems described in my original post to this bug. (But
then the lightdm login is correct regarding to positions and pivot).

I guess I could use xrandr to set up it properly also in lightdm.

Sorry for being a bit of a noob when it comes to X / Nvidia setting
up, I could probably use some hints on how to set it up.

/Andreas
gus...@debian.org

Bug#905309: nvidia-modeset: WARNING: GPU:0: Lost display notification (0:0x00000000); continuing

[Andreas Beckmann]

Control: tag -1 moreinfo upstream

On 2018-08-03 02:25, Allan Wind wrote:
> Package: nvidia-driver
> Version: 384.130-1

> I noticed the fan on my laptop was spinning at full speed which
> signifies heavy load.  Screens suspended, and they don't unsuspend when
> I pressed the keyboard.  I ssh into the machine remotely, and see that
> nvidia-modeset is using 100% cpu.  The only thing unusual in syslog is:
> 
> 2018-08-02T22:49:34.702+00:00 vent kernel: nvidia-modeset: WARNING:
> GPU:0: Lost display notification (0:0x); continuing.

Is this still reproducible with the 390.xx driver now in stretch?

Andreas

Bug#922615: nvidia-driver: Windows not visible on third screen after stable upgrade

[Andreas Beckmann]

On 2019-02-18 14:08, Andreas Ronnquist wrote:
> << /etc/X11/xorg.conf >>
> # nvidia-settings: X configuration file generated by nvidia-settings
> # nvidia-settings:  version 384.111  (build-user@build-machine)  Sun Feb 25 
> 17:18:20 UTC 2018

That xorg.conf was generated for an older driver.
a) do you really need an xorg.conf? I assume yes due to your special
display setup
b) you probably need to regenerate it for the current driver - maybe
some internals have changed that you are now fixing manually every time

Andreas

Bug#922679: Locking screen with light-locker/nvidia-driver crashes system to blinking cursor

[Andreas Beckmann]

Control: tag -1 moreinfo

On 2019-02-19 12:03, nodiscc wrote:
> The solution I found was simply to generate a /etc/X11/xorg.conf file using
> 'sudo nvidia-xconfig'.

Does it already work with just this minimal xorg.conf:

Section "Device"
Identifier "My GPU"
Driver "nvidia"
EndSection


Andreas

Bug#922936: ganeti: KVM/QEMU Virtual machines won't start after the last qemu-system-x86_64 update.

[Paul Parsons]

Package: ganeti
Version: 2.16.0-4
Severity: grave
Tags: newcomer
Justification: renders package unusable

Dear Maintainer,

After performing the usual apt upgrade on my system, I found Ganeti was unable
to start my virtual machines.

The error message, from qemu, was that -balloon was an invalid option.
Searching the man showed no reference on Buster, but on Stretch it was there.

Looking over the change log for qemu 3.1
(https://wiki.qemu.org/ChangeLog/3.1#Incompatible_changes) the 4th entry
mentioned `-balloon` had changed to `-device virtio-balloon`

Hopefully this can be resolved by a simple search and replace within the Python
scripts powering Ganeti.
As of yet, I haven't had a look. There will likely be other options that will
be affected by the update to qemu.



-- Package-specific info:
Version symlinks:
  /etc/ganeti/share -> /usr/share/ganeti/2.16
  /etc/ganeti/lib -> /usr/lib/ganeti/2.16
Cluster config version: 2.16.0
Address family: IPv4
Enabled hypervisors: kvm
kvm hypervisor parameters:
  acpi=True
  boot_order=disk
  cpu_cores=0
  cpu_mask=all
  cpu_sockets=1
  cpu_threads=0
  disk_aio=threads
  disk_cache=default
  disk_discard=default
  disk_type=paravirtual
  kernel_args=ro
  keymap=en-gb
  kvm_path=/usr/bin/kvm
  kvm_pci_reservations=12
  migration_bandwidth=32
  migration_downtime=30
  migration_mode=live
  migration_port=8102
  nic_type=paravirtual
  reboot_behavior=reboot
  root_path=/dev/vda1
  scsi_controller_type=lsi
  security_model=none
  serial_console=True
  serial_speed=38400
  spice_ip_version=0
  spice_playback_compression=True
  spice_tls_ciphers=HIGH:-DES:-3DES:-EXPORT:-DH
  spice_use_tls=False
  spice_use_vdagent=True
  use_chroot=False
  use_guest_agent=False
  use_localtime=False
  user_shutdown=False
  vhost_net=False
  virtio_net_queues=1
  vnc_bind_address=0.0.0.0
  vnc_tls=False
  vnc_x509_verify=False
  vnet_hdr=True

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

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

Versions of packages ganeti depends on:
ii  adduser  3.118
ii  ganeti-2.16  2.16.0-4
ii  ganeti-haskell-2.16  2.16.0-4
ii  ganeti-htools-2.16   2.16.0-4
ii  lsb-base 10.2018112800
ii  python   2.7.15-4

Versions of packages ganeti recommends:
ii  drbd-utils   9.5.0-1
ii  fdisk2.33.1-0.1
ii  ganeti-instance-debootstrap  0.16-6
ii  ndisc6   1.0.4-1
ii  qemu-kvm 1:3.1+dfsg-4

Versions of packages ganeti suggests:
pn  blktap-dkms  
pn  ganeti-doc   
pn  molly-guard  

-- no debconf information

Bug#922479: nvidia-legacy-340xx-kernel-dkms unknown symbols, kernel 4.20.x

[Andreas Beckmann]

On 2019-02-16 19:33, S R Wright wrote:
> This is completely functional in kernel 4.19.x and before,  but an
> attempt to use this in 4.20.x has failed.  While dkms can build the
> module to completion,  at boot time in throws a large number of unknown
> symbols.

-rw-r--r--   1 root root 22174712 Feb 22 00:30 
/lib/modules/4.20.0-trunk-amd64/updates/dkms/nvidia-current.ko
-rw-r--r--   1 root root   279896 Feb 22 00:27 
/lib/modules/4.20.0-trunk-amd64/updates/dkms/nvidia-legacy-340xx.ko
-rw-r--r--   1 root root 22175072 Feb 22 00:29 
/lib/modules/4.19.0-3-amd64/updates/dkms/nvidia-current.ko
-rw-r--r--   1 root root 14518232 Feb 22 00:26 
/lib/modules/4.19.0-3-amd64/updates/dkms/nvidia-legacy-340xx.ko

For whatever reason it seems to no longer link the blob into the module ...
But this works for the current driver.


Andreas

Bug#741888: postfix: vulnerability, remotely exploitable, spews DSNs

[Scott Kitterman]

On Thursday, February 21, 2019 05:35:26 PM Robert Munyer wrote:
> Control: found -1 3.1.9-0+deb9u2
> 
> Scott Kitterman wrote:
> > I agree this is a problem.  A design change like this should not be
> > implemented at the distro level, so it's not a patch I would consider
> > for Debian.  It should be discussed with the upstream developers.
> 
> Does upstream have a BTS?  I remember looking for an upstream BTS
> when I filed this, and not finding one.  I did find a mailing list,
> but it already had multiple reports about this vulnerability.
> 
> What I did to my own copy of Postfix (and shared with others, via
> this bug report) was not a design change, but a surgical removal of
> Postfix's ability to send "bounce" messages to strangers.
> 
> It's true that a design change would be better, but one doesn't want
> to wait that long.  This exploit had been made public almost 10 years
> before I first encountered it (in Petter Urkedal's 2004-09-17 message,
> linked in my bug report) and the version of Postfix that's in Debian
> Stable today is still vulnerable to this 14.4-year-old exploit!
> 
> I (and probably many others) want an MTA that just doesn't ever send
> "bounce" messages to strangers.

No, they still don't.

I intend to bring it up again with them once postfix 3.4.0 is out (there's no 
way they'd pay attention now).

Scott K

Bug#922935: Run without cron or is cron job still needed?

[Bryan Quigley]

Package: passwd
Version: 1:4.5-1.1

This is regards to passwd.cron.daily which backups
passwd/group/shadow/gshadow daily, which AFAICT is not upstream, but
may have been in the past.

I'm looking at what it takes to run systems without cron and following
the example of other packages like logrotate:

They add this bit to the cron script:
# skip in favour of systemd timer
if [ -d /run/systemd/system ]; then
exit 0
fi

and then create a systemd service/timer.  Happy to do the work to make
a patch if the above is the preferred solution.

___

Alternatively, I have also wondered if the cron job functionality is
still needed or if the built-in generated backups are enough -
/etc/group- etc.

On my machine the /etc/group- backup would have been much more useful
then the one replaced daily by the cron job in /var/backups.

Thanks!

Bug#908216: btrfs blocked for more than 120 seconds

[Russell Mosemann]

 
Package: src:linux
Version: 4.19.16-1~bpo9+1
Severity: important
 
 
 
This is a frequent bug that occurs nearly daily for many months, now.
 
Feb 21 19:02:38 vhost182 kernel: INFO: task btrfs-transacti:617 blocked for 
more than 120 seconds.
Feb 21 19:02:38 vhost182 kernel:   Not tainted 4.19.0-0.bpo.2-amd64 #1 
Debian 4.19.16-1~bpo9+1
Feb 21 19:02:38 vhost182 kernel: "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Feb 21 19:02:38 vhost182 kernel: btrfs-transacti D0   617  2 0x8000
Feb 21 19:02:38 vhost182 kernel: Call Trace:
Feb 21 19:02:38 vhost182 kernel:  ? __schedule+0x3f5/0x880
Feb 21 19:02:38 vhost182 kernel:  schedule+0x32/0x80
Feb 21 19:02:38 vhost182 kernel:  btrfs_start_ordered_extent+0xed/0x120 [btrfs]
Feb 21 19:02:38 vhost182 kernel:  ? remove_wait_queue+0x60/0x60
Feb 21 19:02:38 vhost182 kernel:  btrfs_wait_ordered_range+0xa0/0x100 [btrfs]
Feb 21 19:02:38 vhost182 kernel:  __btrfs_wait_cache_io+0x46/0x1c0 [btrfs]
Feb 21 19:02:38 vhost182 kernel:  btrfs_start_dirty_block_groups+0x1ad/0x4b0 
[btrfs]
Feb 21 19:02:38 vhost182 kernel:  btrfs_commit_transaction+0xc8/0x8a0 [btrfs]
Feb 21 19:02:38 vhost182 kernel:  ? start_transaction+0x8f/0x3e0 [btrfs]
Feb 21 19:02:38 vhost182 kernel:  transaction_kthread+0x157/0x180 [btrfs]
Feb 21 19:02:38 vhost182 kernel:  kthread+0xf8/0x130
Feb 21 19:02:38 vhost182 kernel:  ? btrfs_cleanup_transaction+0x500/0x500 
[btrfs]
Feb 21 19:02:38 vhost182 kernel:  ? kthread_create_worker_on_cpu+0x70/0x70
Feb 21 19:02:38 vhost182 kernel:  ret_from_fork+0x35/0x40
Feb 21 19:04:38 vhost182 kernel: INFO: task btrfs-transacti:617 blocked for 
more than 120 seconds.
Feb 21 19:04:38 vhost182 kernel:   Not tainted 4.19.0-0.bpo.2-amd64 #1 
Debian 4.19.16-1~bpo9+1
Feb 21 19:04:38 vhost182 kernel: "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Feb 21 19:04:38 vhost182 kernel: btrfs-transacti D0   617  2 0x8000
Feb 21 19:04:38 vhost182 kernel: Call Trace:
Feb 21 19:04:38 vhost182 kernel:  ? __schedule+0x3f5/0x880
Feb 21 19:04:38 vhost182 kernel:  schedule+0x32/0x80
Feb 21 19:04:38 vhost182 kernel:  btrfs_start_ordered_extent+0xed/0x120 [btrfs]
Feb 21 19:04:38 vhost182 kernel:  ? remove_wait_queue+0x60/0x60
Feb 21 19:04:38 vhost182 kernel:  btrfs_wait_ordered_range+0xa0/0x100 [btrfs]
Feb 21 19:04:38 vhost182 kernel:  __btrfs_wait_cache_io+0x46/0x1c0 [btrfs]
Feb 21 19:04:38 vhost182 kernel:  btrfs_start_dirty_block_groups+0x1ad/0x4b0 
[btrfs]
Feb 21 19:04:38 vhost182 kernel:  btrfs_commit_transaction+0xc8/0x8a0 [btrfs]
Feb 21 19:04:38 vhost182 kernel:  ? start_transaction+0x8f/0x3e0 [btrfs]
Feb 21 19:04:38 vhost182 kernel:  transaction_kthread+0x157/0x180 [btrfs]
Feb 21 19:04:38 vhost182 kernel:  kthread+0xf8/0x130
Feb 21 19:04:38 vhost182 kernel:  ? btrfs_cleanup_transaction+0x500/0x500 
[btrfs]
Feb 21 19:04:38 vhost182 kernel:  ? kthread_create_worker_on_cpu+0x70/0x70
Feb 21 19:04:38 vhost182 kernel:  ret_from_fork+0x35/0x40
Feb 21 19:06:39 vhost182 kernel: INFO: task btrfs-transacti:617 blocked for 
more than 120 seconds.
Feb 21 19:06:39 vhost182 kernel:   Not tainted 4.19.0-0.bpo.2-amd64 #1 
Debian 4.19.16-1~bpo9+1
Feb 21 19:06:39 vhost182 kernel: "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Feb 21 19:06:39 vhost182 kernel: btrfs-transacti D0   617  2 0x8000
Feb 21 19:06:39 vhost182 kernel: Call Trace:
Feb 21 19:06:39 vhost182 kernel:  ? __schedule+0x3f5/0x880
Feb 21 19:06:39 vhost182 kernel:  schedule+0x32/0x80
Feb 21 19:06:39 vhost182 kernel:  btrfs_start_ordered_extent+0xed/0x120 [btrfs]
Feb 21 19:06:39 vhost182 kernel:  ? remove_wait_queue+0x60/0x60
Feb 21 19:06:39 vhost182 kernel:  btrfs_wait_ordered_range+0xa0/0x100 [btrfs]
Feb 21 19:06:39 vhost182 kernel:  __btrfs_wait_cache_io+0x46/0x1c0 [btrfs]
Feb 21 19:06:39 vhost182 kernel:  btrfs_start_dirty_block_groups+0x1ad/0x4b0 
[btrfs]
Feb 21 19:06:39 vhost182 kernel:  btrfs_commit_transaction+0xc8/0x8a0 [btrfs]
Feb 21 19:06:39 vhost182 kernel:  ? start_transaction+0x8f/0x3e0 [btrfs]
Feb 21 19:06:39 vhost182 kernel:  transaction_kthread+0x157/0x180 [btrfs]
Feb 21 19:06:39 vhost182 kernel:  kthread+0xf8/0x130
Feb 21 19:06:39 vhost182 kernel:  ? btrfs_cleanup_transaction+0x500/0x500 
[btrfs]
Feb 21 19:06:39 vhost182 kernel:  ? kthread_create_worker_on_cpu+0x70/0x70
Feb 21 19:06:39 vhost182 kernel:  ret_from_fork+0x35/0x40
Feb 21 19:08:40 vhost182 kernel: INFO: task btrfs-transacti:617 blocked for 
more than 120 seconds.
Feb 21 19:08:40 vhost182 kernel:   Not tainted 4.19.0-0.bpo.2-amd64 #1 
Debian 4.19.16-1~bpo9+1
Feb 21 19:08:40 vhost182 kernel: "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Feb 21 19:08:40 vhost182 kernel: btrfs-transacti D0   617  2 0x8000
Feb 21 19:08:40 vhost182 kernel: Call Trace:
Feb 21 19:08:40 vhost182 kernel:  ? __schedule+0x3f5/0x880
Feb 21 19:08:40 vhost182 kernel:  schedule+0x32/0x80
Feb 21 19:08:40 vhost182 kernel:  

Bug#922934: RFP: elpa-kotlin-mode -- Emacs major mode for editing Kotlin files

[Rogério Brito]

Package: wnpp
Severity: wishlist

* Package name: elpa-kotlin-mode
  Version : 20190116.2055
  Upstream Author : Russel Winder , Gregg Hernandez 

* URL : https://github.com/Emacs-Kotlin-Mode-Maintainers/kotlin-mode
* License : GPL-3+
  Programming Lang: Elisp
  Description : Emacs major mode for editing Kotlin files

 This mode provides syntax highlighting, indentation and keyboard shortcuts
 to edit and run Kotlin files with the Kotlin Read-Eval-Print-Loop (REPL)
 for experiments with the language.


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

Bug#908216: btrfs blocked for more than 120 seconds

[Russell Mosemann]

 
Package: src:linux
Version: 4.19.16-1~bpo9+1
Severity: important
 
 
Feb 21 17:19:15 vhost002 kernel: INFO: task btrfs-transacti:636 blocked for 
more than 120 seconds.
Feb 21 17:19:15 vhost002 kernel:   Not tainted 4.19.0-0.bpo.2-amd64 #1 
Debian 4.19.16-1~bpo9+1
Feb 21 17:19:15 vhost002 kernel: "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Feb 21 17:19:15 vhost002 kernel: btrfs-transacti D0   636  2 0x8000
Feb 21 17:19:15 vhost002 kernel: Call Trace:
Feb 21 17:19:15 vhost002 kernel:  ? __schedule+0x3f5/0x880
Feb 21 17:19:15 vhost002 kernel:  schedule+0x32/0x80
Feb 21 17:19:15 vhost002 kernel:  btrfs_start_ordered_extent+0xed/0x120 [btrfs]
Feb 21 17:19:15 vhost002 kernel:  ? remove_wait_queue+0x60/0x60
Feb 21 17:19:15 vhost002 kernel:  btrfs_wait_ordered_range+0xa0/0x100 [btrfs]
Feb 21 17:19:15 vhost002 kernel:  __btrfs_wait_cache_io+0x46/0x1c0 [btrfs]
Feb 21 17:19:15 vhost002 kernel:  btrfs_start_dirty_block_groups+0x1ad/0x4b0 
[btrfs]
Feb 21 17:19:15 vhost002 kernel:  btrfs_commit_transaction+0xc8/0x8a0 [btrfs]
Feb 21 17:19:15 vhost002 kernel:  ? start_transaction+0x8f/0x3e0 [btrfs]
Feb 21 17:19:15 vhost002 kernel:  transaction_kthread+0x157/0x180 [btrfs]
Feb 21 17:19:15 vhost002 kernel:  kthread+0xf8/0x130
Feb 21 17:19:15 vhost002 kernel:  ? btrfs_cleanup_transaction+0x500/0x500 
[btrfs]
Feb 21 17:19:15 vhost002 kernel:  ? kthread_create_worker_on_cpu+0x70/0x70
Feb 21 17:19:15 vhost002 kernel:  ret_from_fork+0x35/0x40
Feb 21 17:21:16 vhost002 kernel: INFO: task btrfs-transacti:636 blocked for 
more than 120 seconds.
Feb 21 17:21:16 vhost002 kernel:   Not tainted 4.19.0-0.bpo.2-amd64 #1 
Debian 4.19.16-1~bpo9+1
Feb 21 17:21:16 vhost002 kernel: "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Feb 21 17:21:16 vhost002 kernel: btrfs-transacti D0   636  2 0x8000
Feb 21 17:21:16 vhost002 kernel: Call Trace:
Feb 21 17:21:16 vhost002 kernel:  ? __schedule+0x3f5/0x880
Feb 21 17:21:16 vhost002 kernel:  schedule+0x32/0x80
Feb 21 17:21:16 vhost002 kernel:  btrfs_start_ordered_extent+0xed/0x120 [btrfs]
Feb 21 17:21:16 vhost002 kernel:  ? remove_wait_queue+0x60/0x60
Feb 21 17:21:16 vhost002 kernel:  btrfs_wait_ordered_range+0xa0/0x100 [btrfs]
Feb 21 17:21:16 vhost002 kernel:  __btrfs_wait_cache_io+0x46/0x1c0 [btrfs]
Feb 21 17:21:16 vhost002 kernel:  btrfs_start_dirty_block_groups+0x1ad/0x4b0 
[btrfs]
Feb 21 17:21:16 vhost002 kernel:  btrfs_commit_transaction+0xc8/0x8a0 [btrfs]
Feb 21 17:21:16 vhost002 kernel:  ? start_transaction+0x8f/0x3e0 [btrfs]
Feb 21 17:21:16 vhost002 kernel:  transaction_kthread+0x157/0x180 [btrfs]
Feb 21 17:21:16 vhost002 kernel:  kthread+0xf8/0x130
Feb 21 17:21:16 vhost002 kernel:  ? btrfs_cleanup_transaction+0x500/0x500 
[btrfs]
Feb 21 17:21:16 vhost002 kernel:  ? kthread_create_worker_on_cpu+0x70/0x70
Feb 21 17:21:16 vhost002 kernel:  ret_from_fork+0x35/0x40
Feb 21 17:23:16 vhost002 kernel: INFO: task btrfs-transacti:636 blocked for 
more than 120 seconds.
Feb 21 17:23:16 vhost002 kernel:   Not tainted 4.19.0-0.bpo.2-amd64 #1 
Debian 4.19.16-1~bpo9+1
Feb 21 17:23:17 vhost002 kernel: "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Feb 21 17:23:17 vhost002 kernel: btrfs-transacti D0   636  2 0x8000
Feb 21 17:23:17 vhost002 kernel: Call Trace:
Feb 21 17:23:17 vhost002 kernel:  ? __schedule+0x3f5/0x880
Feb 21 17:23:17 vhost002 kernel:  schedule+0x32/0x80
Feb 21 17:23:17 vhost002 kernel:  btrfs_start_ordered_extent+0xed/0x120 [btrfs]
Feb 21 17:23:17 vhost002 kernel:  ? remove_wait_queue+0x60/0x60
Feb 21 17:23:17 vhost002 kernel:  btrfs_wait_ordered_range+0xa0/0x100 [btrfs]
Feb 21 17:23:17 vhost002 kernel:  __btrfs_wait_cache_io+0x46/0x1c0 [btrfs]
Feb 21 17:23:17 vhost002 kernel:  btrfs_start_dirty_block_groups+0x1ad/0x4b0 
[btrfs]
Feb 21 17:23:17 vhost002 kernel:  btrfs_commit_transaction+0xc8/0x8a0 [btrfs]
Feb 21 17:23:17 vhost002 kernel:  ? start_transaction+0x8f/0x3e0 [btrfs]
Feb 21 17:23:17 vhost002 kernel:  transaction_kthread+0x157/0x180 [btrfs]
Feb 21 17:23:17 vhost002 kernel:  kthread+0xf8/0x130
Feb 21 17:23:17 vhost002 kernel:  ? btrfs_cleanup_transaction+0x500/0x500 
[btrfs]
Feb 21 17:23:17 vhost002 kernel:  ? kthread_create_worker_on_cpu+0x70/0x70
Feb 21 17:23:17 vhost002 kernel:  ret_from_fork+0x35/0x40
Feb 21 17:25:17 vhost002 kernel: INFO: task btrfs-transacti:636 blocked for 
more than 120 seconds.
Feb 21 17:25:17 vhost002 kernel:   Not tainted 4.19.0-0.bpo.2-amd64 #1 
Debian 4.19.16-1~bpo9+1
Feb 21 17:25:17 vhost002 kernel: "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Feb 21 17:25:17 vhost002 kernel: btrfs-transacti D0   636  2 0x8000
Feb 21 17:25:17 vhost002 kernel: Call Trace:
Feb 21 17:25:17 vhost002 kernel:  ? __schedule+0x3f5/0x880
Feb 21 17:25:17 vhost002 kernel:  schedule+0x32/0x80
Feb 21 17:25:17 vhost002 kernel:  btrfs_start_ordered_extent+0xed/0x120 [btrfs]
Feb 21 17:25:17 vhost002 kernel:  ? 

Bug#922667: beep: Error: could not open any device

[Hugh Morris]

Hello

I don't yet understand all the above, but I, too, was puzzled when my 
beeping scripts went silent.


Hugh Morris

Bug#922933: librdf-aref-perl: Failures due to changing prefix

[Kjetil Kjernsmo]

Package: librdf-aref-perl
Version: 0.27-1
Severity: important
Tags: upstream

Dear Maintainer,

I figured you might use an explanation of the recent breakage of this
package. First of all, it has been reported upstream, but there has
been no action:
https://github.com/nichtich/RDF-aREF/issues/21

The root cause is that librdf-ns-perl is based on a crowd-sourced
database, and sometimes crowd-sourced things change. The occasional breakage is 
usually a small price to pay for access to the large, crowdsourced
database, but for a stable environment, like Debian, it can cause some 
headaches.

The breakage seen in this package is directly due to that a prefix has
changed in the crowdsourced database, and only upstream can really fix
that. Changing the test should be upstream's call, as it may alter the
meaning of the code. Probably the best solution that you can do is
fixate the tests on a database from the past.

Kjetil


-- System Information:
Debian Release: 9.5
  APT prefers stable
  APT policy: (501, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages librdf-aref-perl depends on:
ii  librdf-ns-perl  20170111-1
ii  perl5.24.1-3+deb9u4

librdf-aref-perl recommends no packages.

Versions of packages librdf-aref-perl suggests:
pn  libunicode-normalize-perl  

Bug#922497: BUG: unable to handle kernel paging request at ffff9b30a7cb488

[Allan Wind]

Thanks Andreas.

I doubt NVIDIA will spend any cycles on troubleshooting issues 
with an older driver.


About a year ago I reported #905309 to the forum that NVIDIA says 
is the official support channel for Linux driver issues.  I never 
heard back.


The main reason why I filed the bug report was to document the 
workaround should anyone else hit this.  It is highly unusual

for a stable upgrade to cause an issue of this magnitude.


/Allan

On 2019-02-22 00:39:36, Andreas Beckmann wrote:

Control: tag -1 upstream

On 2019-02-17 07:40, Allan Wind wrote:

The stable release 9.8 contained an upgrade of nvidia-drivers from
384.130-1 to 390.87-8~deb9u1 which caused my system hang during
subsequent boots.  The release also contains a linux-image update, and I
installed a known working kernel (4.9.0-5) and it too failed to boot
with 390.87-8~deb9u1. Then I upgraded nividia-driver to the version in
unstable, and I was able to boot my system.  Unfortunately, this is the
version information being picked up in this bug report.


There haven't been similar reports with the 390.xx driver from
stretch-backports or with the 390.xx driver in sid (with newer kernels
than 4.9) - maybe it is specific to your card. Or some other hardware.

There is nothing we can do about bugs in the proprietary driver. And I
expect you don't want to try reporting this upstream - since you have a
working configuration now, and getting useful information if the system
fails to boot is difficult.


Andreas


--
Allan Wind
Yaxto - Runs Your Business

Bug#922108: [Tts-project] Bug#922108: speech-dispatcher: sd_ibmtts with PulseAudio doesn't work

[Samuel Thibault]

Hello,

Samuel Thibault, le mar. 12 févr. 2019 09:48:53 +0100, a ecrit:
> When the next version of speech-dispatcher-contrib gets into Debian,

It got in.

> you will be able to just install speech-dispatcher-ibmtts from Debian
> itself, that will pull a 32bit version and a few 32bit dependencies,
> which can be used directly by speech-dispatcher instead of via voxind.

You now should be able to do it with version 0.9.0-6 of
speech-dispatcher-contrib and 0.9.0-5 of speech-dispatcher.

Samuel

Bug#922932: pnmixer dies in vol_meter_draw: assertion failed

[Marco d'Itri]

Package: pnmixer
Version: 0.7.2-1
Severity: important

I do not know if it works in other conditions, but pnmixer reliably 
crashes on my system with this error when I change the volume over 100% 
with "pulsemixer --change-volume +10":

ERROR:/build/pnmixer-s2Hxqg/pnmixer-0.7.2/src/ui-tray-icon.c:271:vol_meter_draw:
 assertion failed: (y >= 0 && y + vm_height <= icon_height)

Since this command is bound to the volume up key the net effect is that 
pnmixer crashes every time I change the volume.

It also logs this all the time:

warning: /build/pnmixer-s2Hxqg/pnmixer-0.7.2/src/ui-tray-icon.c: Unable to 
lookup icon 'audio-volume-off'
error: /build/pnmixer-s2Hxqg/pnmixer-0.7.2/src/alsa.c: 'default': Can't get 
playback dB range: Invalid argument


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

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

Versions of packages pnmixer depends on:
ii  libasound2  1.1.8-1
ii  libc6   2.28-7
ii  libgdk-pixbuf2.0-0  2.38.0+dfsg-7
ii  libglib2.0-02.58.3-1
ii  libgtk-3-0  3.24.5-1
ii  libnotify4  0.7.7-4
ii  libx11-62:1.6.7-1

pnmixer recommends no packages.

pnmixer suggests no packages.

-- no debconf information

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#919628: Apply Julia's LLVM patches

[Mo Zhou]

Hi Sylvestre,

Any chance for getting this into Buster? If there is any, I'd like
to apply for freeze exception early, especially for the next Julia
LTS release 1.0.4 (likely to come out before 1st March)

On Fri, Feb 08, 2019 at 08:46:06AM +0100, Sylvestre Ledru wrote:
> Wahou, better than I was expecting! Many thanks!
> 
> I will take as much as possible! Thanks
> 
> S
> 
> 
> Le 08/02/2019 à 07:47, Mo Zhou a écrit :
> > Hi Sylvestre,
> > 
> > Please cherry-pick at least: (8) (12) (13) (14) (15)
> > 
> > Recommended to include: (1) (2) (4) (5) (11)
> > 
> > Feel free to ignore: (6) (9) (16) (17)
> > 
> > I have no idea about: (3) (7) (10)
> > 
> > https://github.com/JuliaLang/julia/tree/master/deps/patches
> > I've listed patches for llvm 6.0.1
> > 
> > 
> > 
> > 
> > (1) [unwind] llvm-D27629-AArch64-large_model_6.0.1
> > 
> >  Fix unwind info relocation with large code model on AArch64
> >  https://reviews.llvm.org/D27629
> > 
> > (2) [performance] llvm-D34078-vectorize-fdiv
> > 
> >  Enable support for floating-point division reductions
> >  https://reviews.llvm.org/D34078
> > 
> > (3) [nvptx] llvm-6.0-NVPTX-addrspaces
> > 
> >  No idea about this patch.
> > 
> > (4) [performance regression] llvm-D42262-jumpthreading-not-i1
> > 
> >  For details see Julia commit: e94a1f8b08e0bc3b8093d8f1dc2bf3c8f5d59519
> >  merged upstream: https://reviews.llvm.org/D42262
> > 
> > (5) [???] llvm-PPC-addrspaces
> > 
> >  merged upstream: https://reviews.llvm.org/D43781
> > 
> > (6) [ignore: mingw] llvm-6.0.0_D27296-libssp
> >  [ignore: mingw] llvm-6.0-D44650
> > 
> > (7) [???] llvm-D46460
> > 
> >  still under review: https://reviews.llvm.org/D46460
> > 
> > (8) [???] llvm-rL327898
> > 
> >  
> > https://github.com/JuliaLang/julia/blob/master/deps/patches/llvm-rL327898.patch
> >  Fixes Julia issues: #27055 #27080 #27032 #27603
> > 
> > (9) [ignore: compiler complain] llvm-6.0-DISABLE_ABI_CHECKS
> > 
> > (10) [profiling] llvm-OProfile-line-num
> > 
> > (11) [profiling] llvm-D44892-Perf-integration
> > 
> >   merged upstream: https://reviews.llvm.org/D44892
> > 
> > (12) [bug fix] llvm-D49832-SCEVPred
> >   [bug fix] llvm-rL323946-LSRTy
> > 
> >  Add LLVM patches for bugs introducing illegal ptrtoint
> >  rL323946 [LSR] Don't force bases of foldable formulae to the final 
> > type.
> >  D49832   [SCEV] Don't expand Wrap predicate using inttoptr in ni 
> > addrspaces
> > 
> > (13) llvm-D50010-VNCoercion-ni
> > 
> >  Fixes julia issue: #28360 (#28362)
> >  https://reviews.llvm.org/D50010
> > 
> > (14) llvm-D50167-scev-umin
> > 
> >  Add LLVM patch to explicitly represent umin in SCEV (#28403)
> >  Fix mix-type arithmetic detection in umin/max expansion (#28465)
> >  Fixes #28464
> >  Fixes #28379
> >  Fixes #28388
> > 
> > (15) llvm-rL326967-aligned-load
> > 
> >  Fixes incorrect codegen: #28726
> > 
> > (16) [ignore: win64] llvm-D51842-win64-byval-cc
> > 
> > (17) [...] llvm-D57118-powerpc
> > 
> >  https://reviews.llvm.org/D57118
> > 

Bug#922931: intel-mkl does not set alternatives for non-multiarch blas/lapack in Stretch

[Mo Zhou]

Source: intel-mkl
Version: 2019.1.144-3~bpo9+1
Severity: normal

Hi Frederik,

Thank you for reporting this issue. To some extent I don't like
to restore the old behavior as it increases the differential
between the unstable version and the one for stable-backports.

I'll leave it as a bug. Maybe I'll fix it for the next bpo upload.
(i.e. 2019.2.187-1~bpo9+1 when it migrates)

On Thu, Feb 21, 2019 at 02:47:39PM +0100, Frederik Himpe wrote:
> The intel-mkl backport sets multiarch alternatives for libblas and
> liblapack. However Stretch does not use multiarch libblas/liblapack
> yet, which means that all Stretch packages still are not using libmkl,
> even when set as default.
> 
> 
> # update-alternatives --display liblapack.so.3
> liblapack.so.3 - auto mode
>   link best version is /usr/lib/openblas-base/liblapack.so.3
>   link currently points to /usr/lib/openblas-base/liblapack.so.3
>   link liblapack.so.3 is /usr/lib/liblapack.so.3
>   slave liblapack.so.3gf is /usr/lib/liblapack.so.3gf
> /usr/lib/lapack/liblapack.so.3 - priority 10
> /usr/lib/openblas-base/liblapack.so.3 - priority 40
>   slave liblapack.so.3gf: /usr/lib/openblas-base/liblapack.so.3
> 
> # update-alternatives --display liblapack.so.3-x86_64-linux-gnu
> liblapack.so.3-x86_64-linux-gnu - manual mode
>   link best version is /usr/lib/x86_64-linux-gnu/libmkl_rt.so
>   link currently points to /usr/lib/x86_64-linux-gnu/libmkl_rt.so
>   link liblapack.so.3-x86_64-linux-gnu is /usr/lib/x86_64-linux-
> gnu/liblapack.so.3
> /usr/lib/x86_64-linux-gnu/libmkl_rt.so - priority 1
> 
> 
> -- 
> Frederik Himpe 
> Vrije Universiteit Brussel
> 

Bug#896080: [pkg-apparmor] Improve samba/AppArmor integration

[Christian Boltz]

Hello,

Am Donnerstag, 21. Februar 2019, 21:26:58 CET schrieb Mathieu Parent:
> As a last-minute fix for buster, I want to fix "#896080 samba: Improve
> AppArmor integration" [SambaAppArmor].
> 
> I've prepared the fixes [Diff], inspired by what is done in Suse. But
> they also patch apparmor-profiles [AppArmor-Patch]. This solution does
> not conforms to policy as a file owned by a package could not be
> changed by another one (/etc/apparmor.d/local/usr.sbin.smbd-shares
> owned by apparmor-profiles, changed by samba).
> 
> I can add in samba's README the need to add "#include
> " in /etc/apparmor.d/usr.sbin.smbd, but
> maybe you have a better solution? Maybe use dpkg-diversion?

To simplify things, I'd propose to apply a slightly modified version of
https://build.opensuse.org/package/view_file/openSUSE:Factory/apparmor/apparmor-samba-include-permissions-for-shares.diff?expand=1
to the usr.sbin.smbd profile in the apparmor-profiles package:

Instead of   #include   you {c,sh]ould use   #include if exists
so that it doesn't matter if   local/usr.sbin.smbd-shares   exists or 
which package creates it.

That might even be an upstream-able solution because it doesn't break 
distributions without the autogenerated samba profile sniplet (or without
the package owning that file installed).

The local/usr.sbin.smbd file can then be owned by whatever package
(probably samba, because that also owns the script changing the file).


BTW: Minor nitpicking on 
https://salsa.debian.org/samba-team/samba/compare/874f9270b6f743c4d0c3eb1a1a3e1fa814bf25cc...bd4c1577a9b

Can you please change the changelog to "Christian Boltz (openSUSE)" 
(instead of "SUSE")? ;-)


Regards,

Christian Boltz
-- 
[vordefinierte Perlvariablen $_, $>, $[ usw.]
>Steht eigentlich in $§ die Lizenz? ;-)))
$ perl -we 'print $§'
Use of uninitialized value in print at -e line 1.
[> Christian Boltz und David Haller in fontlinge-devel]


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

Bug#922497: BUG: unable to handle kernel paging request at ffff9b30a7cb488

[Andreas Beckmann]

Control: tag -1 upstream

On 2019-02-17 07:40, Allan Wind wrote:
> The stable release 9.8 contained an upgrade of nvidia-drivers from
> 384.130-1 to 390.87-8~deb9u1 which caused my system hang during
> subsequent boots.  The release also contains a linux-image update, and I
> installed a known working kernel (4.9.0-5) and it too failed to boot
> with 390.87-8~deb9u1. Then I upgraded nividia-driver to the version in
> unstable, and I was able to boot my system.  Unfortunately, this is the
> version information being picked up in this bug report.

There haven't been similar reports with the 390.xx driver from
stretch-backports or with the 390.xx driver in sid (with newer kernels
than 4.9) - maybe it is specific to your card. Or some other hardware.

There is nothing we can do about bugs in the proprietary driver. And I
expect you don't want to try reporting this upstream - since you have a
working configuration now, and getting useful information if the system
fails to boot is difficult.


Andreas

Bug#875358: Powermock RC #875358

[Markus Koschany]

Hi,

powermock has been failing to build from source since we introduced
OpenJDK 9 to Debian. It has not been removed yet because several
packages build-depend on it.

reverse-depends -b libpowermock-java

Reverse-Build-Depends-Indep
===
* jline2

Reverse-Build-Depends
=
* commons-email
* dnssecjava
* libcommons-compress-java
* shiro


The best solution would be to upgrade powermock to a version that builds
fine with OpenJDK 11. If I recall correctly this would also require an
update of libmockito-java. Since we are running out of time now, and
there is a risk of breaking other reverse-dependencies, removing
libpowermock-java from the aforementioned r-deps is probably a more
sensible solution.

I have checked all those reverse-dependencies and only
libcommons-compress-java requires an additional patch to disable some
tests (worst case: disabling all of them). All other packages build fine
when I remove libpowermock-java from Build-Depends and add it to
maven.ignoreRules.

I intend to implement those changes on 01.03.2019 unless someone else
objects and steps forward with a better solution.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#896080: AppArmor/Samba integration in Debian

[Christian Boltz]

Hi Mathieu,

Am Donnerstag, 21. Februar 2019, 22:19:34 CET schrieb Mathieu Parent:
> I'm working on AppArmor/Samba integration in Samba and integrated you'
> "update-apparmor-samba-profile" script.

I'm happy to hear that :-)

> I've taken version 1.1, but it silently exists with:
> 
> grep -q '^/usr/sbin/smbd (' /sys/kernel/security/apparmor/profiles
> || \ silentexit "smbd profile not loaded"
> 
> I don't have the complete path but the profile name in this file:
> 
> $ sudo cat /sys/kernel/security/apparmor/profiles | grep smbd
> smbd (enforce)
> 
> I don't know much about Apparmor, is this a bug in the script or a
> behavior difference under Debian?

It's a new/changed behaviour of latest upstream AppArmor, and I have to 
admit that I completely forgot that this script will need to be adjusted.

Historically, the profiles used the attachment (= path of the binary, 
"/usr/sbin/smbd" in this case) as the profile name. This also means that 
the profile name changes if you extend the profile to attach to
"/usr/{bin,sbin}/smbd" (which is needed for distributions with merged 
/usr/bin/ and /usr/sbin/)

Latest AppArmor switched to using profile names ("smbd") instead, which 
makes this easier (and keeps the profile name short and readable).
The switch causes a one-time pain, but ensures that future attachment
changes (like the {bin,sbin} alternation) won't cause additional pain.

Both Debian and openSUSE will have to adjust the 
update-apparmor-samba-profile script - for backward compability, the 
best way is to grep for both names:

 grep '^smbd (\|^/usr/sbin/smbd (' /sys/kernel/security/apparmor/profiles 
|| \
 silentexit "smbd profile not loaded"


Oh, BTW - thanks for accidently ;-) reporting this openSUSE bug!
I forwarded it to our Samba maintainers in
https://bugzilla.opensuse.org/show_bug.cgi?id=1126377

Please grab the patch from this bugreport to ensure that the Debian and
openSUSE scripts stay in sync.


Regards,

Christian Boltz
-- 
I am not a Dictator, I can think of no example where I've ordered
anyone to do anything. And I would expect people to stare at me funny
and tell me 'no', if I tried. [Richard Brown in opensuse-project]


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

Bug#922878: Upstream fixes available

[Kjetil Kjernsmo]

Hi all!

So, I gotta admit as upstream dev of two of the modules that failed, that 
this is partly my fault. And I am happy to report that I have fixed it 
upstream for two packages.

The root cause is that librdf-ns-perl is based on a crowd-sourced database, 
and sometimes crowd-sourced things change. The occasional breakage is 
usually a small price to pay for access to the large, crowdsourced 
database, but for a stable environment, like Debian, it can cause some 
headaches.

Finding the right balance can sometimes be hard, and I therefore suggested 
one change to librdf-ns-perl that made it into this release, and that has 
now been reverted. I still think that the change is appropriate, and I 
think it should not be applied, as it merely fixes a symptom and not the 
root cause, and might lead to breakage for those who do not rely on RDF::NS 
for the entire lifetime of the distribution, but upgrades from upstream.

Moreover, I suspect it doesn't fix the problem for librdf-aref-perl, that's 
still failing, right? The breakage seen there is directly due to that a 
prefix has changed in the crowdsourced database, and only upstream can 
really fix that. 

The actual root cause in libatteanx-serializer-rdfa-perl and librdf-trine-
serializer-rdfa-perl was a particularly embarrassing and silly mistake on 
my part. It just failed very rarely, since testers would generally have 
both RDF::NS and RDF::Prefixes installed... 

I have now released a new upstream version of both, and I think that 
librdf-ns-perl should be unchanged from the upstream.

Best,

Kjetil

Bug#922533: please document location of accounting file

[Marcos Fouces]

Hello Marc

I did some investigation about the localization for pacct in various
distros and i saw that /var/account is the more widely used (Fedora,
RedHat, Gentoo...). This path is the standard even on {Free,Net,Open}BSD
where this file is called acct. So, i migrated the log files to this new
path.

I uploaded a new revision to salsa.d.o [0] but i am not sure if this bug
fixing worths an upload in the middle of a freeze.

If so, could you consider sponsor the package?

Greetings,

Marcos

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



On 20/2/19 17:46, Marc Haber wrote:
> Hi Marcos,
>
> thanks for your answer.
>
> My suggestion is to have a well documented file in a stable location
> that says where to find the actual accounting file. Currently, atop's
> code is full of constructs like
>
> for PACCTFILE in /var/account/pacct /var/log/pacct
> do
> if [ -f "$PACCTFILE" ]  # file exists?
> then
>
> (which is obviously missing the current plac /var/log/account/pacct)
>
> otoh, if this will be a Debianism, atop's code won't get any easier since atop
> will need to continue handling all those places in other
> distributions.
>
> Greetings
> Marc
>
>
> On Tue, Feb 19, 2019 at 11:44:39PM +0100, Marcos Fouces wrote:
>> From: Marcos Fouces 
>> Subject: Re: Bug#922533: please document location of accounting file
>> To: Marc Haber , 922...@bugs.debian.org,
>>  Debian Bug Tracking System 
>> Date: Tue, 19 Feb 2019 23:44:39 +0100
>> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
>>  Thunderbird/60.5.0
>> X-Spam-Score: (--) -2.1
>> X-Spam-Report: torres.zugschlus.de  Content analysis details:   (-2.1
>>  points, 5.0 required)   pts  rule name  description  
>>  -- --- -1.9
>>  BAYES_00   BODY: Bayes spam probability is 0 to 1%
>>  [score: 0.] -0.0 RCVD_IN_DNSWL_NONE
>>  RBL: Sender listed at http://www.dnswl.org/,
>>  no trust
>>  [2a00:1450:4864:20:0:0:0:42c listed in]
>>  [list.dnswl.org]  0.0 FREEMAIL_FROM
>>   Sender email is commonly abused enduser mail
>>  provider (marcos.fouces[at]gmail.com) -0.0
>>  SPF_PASS   SPF: sender matches SPF record -0.1 DKIM_VALID_AU
>>   Message has a valid DKIM or DK signature from
>>  author's domain  0.1 DKIM_SIGNED
>> Message has a DKIM or DK signature, not necessarily
>>  valid -0.1 DKIM_VALID_EF  Message has
>>  a valid DKIM or DK signature from
>>  envelope-from domain -0.1 DKIM_VALID
>>  Message has at least one valid DKIM or DK signature
>>
>> Hi Marc
>>
>> In Debian, the pacct file is located in /var/log/account/pacct while in
>> Fedora it is in /var/account/pacct.
>>
>> I don't see the reason to be less parsable in that location.
>>
>> What is your suggestion?
>>
>> Greetings,
>>
>> Marcos
>>
>> On 17/2/19 20:50, Marc Haber wrote:
>>> Package: acct
>>> Version: 6.6.4-2
>>> Severity: wishlist
>>>
>>> Hi,
>>>
>>> my package atop needs to adapt itself to acct being installed or not. If
>>> acct is installed, atop reads from acct's log files, while establishing
>>> its own accounting interface it acct is not installed.
>>>
>>> Historically, the pacct file is found in various different places,
>>> varying across distribution, so atop's upstream code does through
>>> various contortions to find the correct file. It for example acts on
>>> /etc/logrotate.d/psacct to find the file being rotated, which fails on
>>> Debian since Debian's acct package uses savelog in /etc/cron.d/acct.
>>>
>>> atop on Debian is currently growing code to parse for the savelog line
>>> in /etc/cron.d/acct to find out the acct file being used.
>>>
>>> Would it be possible ot have the acct file's location in a more easily
>>> parsable location? Thanks for helping!
>>>
>>> Greetings
>>> Marc
>>>
>>>
>>> -- System Information:
>>> Debian Release: buster/sid
>>>   APT prefers unstable
>>>   APT policy: (500, 'unstable'), (500, 'stable')
>>> Architecture: amd64 (x86_64)
>>> Foreign Architectures: i386
>>>
>>> Kernel: Linux 4.20.8-zgws1 (SMP w/4 CPU cores)
>>> Kernel taint flags: TAINT_OOT_MODULE
>>> Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en 
>>> (charmap=UTF-8)
>>> Shell: /bin/sh linked to /bin/dash
>>> Init: systemd (via /run/systemd/system)
>>>
>>> Versions of packages acct depends on:
>>> ii  dpkg  1.19.4
>>> ii  install-info  6.5.0.dfsg.1-4+b1
>>> ii  libc6 2.28-7
>>> ii  lsb-base  10.2018112800
>>>
>>> acct recommends no packages.
>>>
>>> acct suggests no packages.
>>>

Bug#917896: libinput10: Same here

[Benjamin]

Package: libinput10
Version: 1.12.6-1
Followup-For: Bug #917896

I was too excited to find your answer, it seems that setting it with
dconf does not make it work on my Dell Latitude 7490.

Bug#915407: ping

[Adam Borowski]

Hi!
Because of the looming freeze, and the need to update a number of other
packages _after this_, could you please upload NOW?

I pinged mpitt privately multiple times.  Should I NMU?

-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Have you accepted Khorne as your lord and saviour?
⠈⠳⣄

Bug#922484: nmu: paw_1:2.14.04.dfsg.2-9.1, mclibs_20061220+dfsg3-3.1, geant321_1:3.21.14.dfsg-11

[Andreas Beckmann]

On Sat, 16 Feb 2019 22:09:11 +0100 Gilles Filippini  wrote:
> Now that #922453 is fixed, paw, mclibs and geant321 have to be rebuilt
> against this fixed cernlib release.

Please binNMU the packages with a "gap" in the binNMU version s.t. this 
bug can be fixed by binNMUing in stable, too. The stretch binNMUs need a 
fixed cernlib in stretch-pu first of course (no pu request filed, yet).

given that we have these binary versions currently in stretch and sid:

paw | 1:2.14.04.dfsg.2-9.1| stable | source, 
amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
paw | 1:2.14.04.dfsg.2-9.1+b2 | unstable   | amd64, 
arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x

libherwig59-2-dev   | 20061220+dfsg3-3.1  | stable | amd64, 
armel, armhf, i386, mips, mipsel, s390x
libherwig59-2-dev   | 20061220+dfsg3-3.1+b2   | unstable   | amd64, 
armel, armhf, i386, mips, mipsel, s390x

libgeant321-2-dev   | 1:3.21.14.dfsg-11+b2| stable | amd64, 
arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
libgeant321-2-dev   | 1:3.21.14.dfsg-11+b4| unstable   | amd64, 
arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x

the following binNMUs should leave the required gap:

nmu 4 paw_1:2.14.04.dfsg.2-9.1 . ANY . unstable . -m "rebuild against fixed 
cernlib regarding #922453"
nmu 4 mclibs_20061220+dfsg3-3.1 . ANY . unstable . -m "rebuild against fixed 
cernlib regarding #922453"
nmu 6 geant321_1:3.21.14.dfsg-11 . ANY . unstable . -m "rebuild against fixed 
cernlib regarding #922453"


For future reference, the corresponding binNMUs for stretch would be:

nmu 3 paw_1:2.14.04.dfsg.2-9.1 . ANY . stretch . -m "rebuild against fixed 
cernlib regarding #922453"
dw paw_1:2.14.04.dfsg.2-9.1 . ANY . stretch . -m "cernlib-base-dev (>= 
20061220+dfsg3-4.4~deb9u1)
nmu 3 mclibs_20061220+dfsg3-3.1 . ANY . stretch . -m "rebuild against fixed 
cernlib regarding #922453"
dw mclibs_20061220+dfsg3-3.1 . ANY . stretch . -m "cernlib-base-dev (>= 
20061220+dfsg3-4.4~deb9u1)
nmu 5 geant321_1:3.21.14.dfsg-11 . ANY . stretch . -m "rebuild against fixed 
cernlib regarding #922453"
dw geant321_1:3.21.14.dfsg-11 . ANY . stretch . -m "cernlib-base-dev (>= 
20061220+dfsg3-4.4~deb9u1)

Andreas

Bug#917896: libinput10: Same here

[Benjamin]

Package: libinput10
Version: 1.12.6-1
Followup-For: Bug #917896

I agree. I spent one day before finding your dconf solution, so you
saved me two. Should probably be moved out of libinput to
gnome-control-center or something.

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

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

Versions of packages libinput10 depends on:
ii  libc6 2.28-7
ii  libevdev2 1.6.0+dfsg-1
ii  libinput-bin  1.12.6-1
ii  libmtdev1 1.1.5-1+b1
ii  libudev1  240-6
ii  libwacom2 0.31-1

libinput10 recommends no packages.

libinput10 suggests no packages.

-- no debconf information

Bug#741888: postfix: vulnerability, remotely exploitable, spews DSNs

[Robert Munyer]

Control: found -1 3.1.9-0+deb9u2

Scott Kitterman wrote:

> I agree this is a problem.  A design change like this should not be
> implemented at the distro level, so it's not a patch I would consider
> for Debian.  It should be discussed with the upstream developers.

Does upstream have a BTS?  I remember looking for an upstream BTS
when I filed this, and not finding one.  I did find a mailing list,
but it already had multiple reports about this vulnerability.

What I did to my own copy of Postfix (and shared with others, via
this bug report) was not a design change, but a surgical removal of
Postfix's ability to send "bounce" messages to strangers.

It's true that a design change would be better, but one doesn't want
to wait that long.  This exploit had been made public almost 10 years
before I first encountered it (in Petter Urkedal's 2004-09-17 message,
linked in my bug report) and the version of Postfix that's in Debian
Stable today is still vulnerable to this 14.4-year-old exploit!

I (and probably many others) want an MTA that just doesn't ever send
"bounce" messages to strangers.

Bug#859553: pidentd: Please migrate to openssl1.1 in buster

[Moritz Muehlenhoff]

On Thu, Feb 21, 2019 at 11:37:02PM +0100, Sebastian Andrzej Siewior wrote:
> On 2019-02-21 23:18:33 [+0100], Moritz Muehlenhoff wrote:
> > On Thu, Feb 21, 2019 at 08:56:14PM +0100, Sebastian Andrzej Siewior wrote:
> > > Its popcon is dropping. It will not be part of Buster. So either RM it
> > > or
> > 
> > I have no use it for, I was just looking at it because it's one of the
> > five packages blocking the removal of src:openssl1.0, 
> so am I.
> 
> > from my PoV it can
> > be removed for sure.
> 
> The debian maintainer of this package looks MIA. Nobody spoke up for
> keeping it so far. I'm happy to NMU it so it builds against libssl-dev
> but I see little to no reason for it. I think we have alternatives which
> *are* in Buster.
> Would you mind filling a RM request?

Ack, gonna file an RM bug tomorrow.

Cheers,
Moritz

Bug#922923: qemu: CVE-2019-8934: ppc64: sPAPR emulator leaks the host hardware identity

[Michael Tokarev]

22.02.2019 0:22, Salvatore Bonaccorso wrote:

Source: qemu
Version: 1:3.1+dfsg-4
Severity: normal
Tags: security upstream
Forwarded: https://lists.gnu.org/archive/html/qemu-devel/2019-02/msg04821.html

Hi,

The following vulnerability was published for qemu.

CVE-2019-8934[0]:
ppc64: sPAPR emulator leaks the host hardware identity


This one's interesting. The vuln itself and the fix too.
First is described elsewhere.

For the second, we can't "just" fix it, -- the fix is to provide
a way to avoid the "leakage" by a means of a command-line option,
and ofcourse a management tool. if any, to run qemu, needs to know
and use this option.

But it is not all really, since this "fix" breaks migration stream
format, so it can't just be backported to 3.1 (the fix applies to
the ongoing next version of qemu). I dunno how much do we care about
the online migration of a ppc guest, probably not _very_ mich, so
this might be an easy path to take. If it is, we can just use a
stright backport of this patch to current debian 3.1 version and
be done with it (modulo the first part -- something needs to actually
use the fix anyway).

Thanks,

/mjt

Bug#859553: pidentd: Please migrate to openssl1.1 in buster

[Sebastian Andrzej Siewior]

On 2019-02-21 23:18:33 [+0100], Moritz Muehlenhoff wrote:
> On Thu, Feb 21, 2019 at 08:56:14PM +0100, Sebastian Andrzej Siewior wrote:
> > Its popcon is dropping. It will not be part of Buster. So either RM it
> > or
> 
> I have no use it for, I was just looking at it because it's one of the
> five packages blocking the removal of src:openssl1.0, 
so am I.

> from my PoV it can
> be removed for sure.

The debian maintainer of this package looks MIA. Nobody spoke up for
keeping it so far. I'm happy to NMU it so it builds against libssl-dev
but I see little to no reason for it. I think we have alternatives which
*are* in Buster.
Would you mind filling a RM request?

> Cheers,
> Moritz

Sebastian

Bug#891858: libinput10: Same error message with unresponsive keyboard

[Benjamin]

Package: libinput10
Version: 1.12.6-1
Followup-For: Bug #891858

Dear Maintainer,

I also get the "offset negative" error messages. It happens once and a
while and the symptoms are that the keyboard becomes unresponsive for
3-5 seconds. Characters don't get lost but delayed for that time. I am
on a Dell Latitude 7490 laptop and it happens irregardless of if I use
the integrated or a USB keyboard.

Feb 21 22:47:47 debian org.gnome.Shell.desktop[1029]: libinput error: client 
bug: timer event10 keyboard: offset negative (-484ms)
Feb 21 22:47:47 debian org.gnome.Shell.desktop[1029]: libinput error: client 
bug: timer event10 keyboard: offset negative (-358ms)
Feb 21 22:47:47 debian org.gnome.Shell.desktop[1029]: libinput error: client 
bug: timer event10 keyboard: offset negative (-246ms)
Feb 21 22:47:47 debian org.gnome.Shell.desktop[1029]: libinput error: client 
bug: timer event10 keyboard: offset negative (-102ms)


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

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

Versions of packages libinput10 depends on:
ii  libc6 2.28-7
ii  libevdev2 1.6.0+dfsg-1
ii  libinput-bin  1.12.6-1
ii  libmtdev1 1.1.5-1+b1
ii  libudev1  240-6
ii  libwacom2 0.31-1

libinput10 recommends no packages.

libinput10 suggests no packages.

-- no debconf information

Bug#885947: marco: After updating, restart (user or pc) and log in, desktop fails

[Y G2709]

Package: marco
Followup-For: Bug #885947
Version: 1.20.3-1


(I send this out of reporbug because I can not use it because due to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905737)

Dear Maintainer,  on the regular disk, after updating marco to the
latest version 1.20.3-1 and returning the default Window Manager from
metacity to marco and restart, follow the same problem.
Even on a clean disk, after installing a fresh DVD image from scratch
(Official Snapshot amd64 DVD Binary-1 20190211-05:12), there are the
same symptoms.

As it seems to me a problem of the frequencies used for the refreshing
of the monitor, I have carried out several tests, discovering the following:

  + The installation from fresh DVD image chooses by default a
resolution of 1152x864 @ 75Hz: it does not work with marco but with
metacity.

  + After temporarily changing the Window Manager in tty2 with 'metacity
--replace' and going back to tty7 which looks good, I now change the
screen resolution (System / Preferences / Hardware / Screens) to another
lower resolution (1024x768 @ 75Hz ) or higher (1280x1024 @ 60Hz), and
restart ... and the problem disappears! having the latest version of marco.

For the above, I think the problem is in which marco does not delegate
the monitor refresh rates well, while metacity does. What do you think?

Unfortunately for me, the lower and upper resolution are very
uncomfortable, returning to the previous situation with metacity, until
a new marco's version to solve it.

If you need any more information, I'll send it to you.

Regards.


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

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

Versions of packages marco depends on:
ii  libatk1.0-0   2.30.0-2
ii  libc6 2.28-7
ii  libcairo-gobject2 1.16.0-2
ii  libcairo2 1.16.0-2
ii  libcanberra-gtk3-0    0.30-7
ii  libcanberra0  0.30-7
ii  libgdk-pixbuf2.0-0    2.38.0+dfsg-7
ii  libglib2.0-0  2.58.3-1
ii  libgtk-3-0    3.24.5-1
ii  libgtop-2.0-11    2.38.0-4
ii  libice6   2:1.0.9-2
ii  libmarco-private1 1.20.3-1
ii  libpango-1.0-0    1.42.4-6
ii  libpangocairo-1.0-0   1.42.4-6
ii  libsm6    2:1.2.3-1
ii  libstartup-notification0  0.12-6
ii  libx11-6  2:1.6.7-1
ii  libxcomposite1    1:0.4.4-2
ii  libxcursor1   1:1.1.15-2
ii  libxdamage1   1:1.1.4-3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes3    1:5.0.3-1
ii  libxinerama1  2:1.1.4-2
ii  libxpresent1  1.0.0-2+b10
ii  libxrandr2    2:1.5.1-1
ii  libxrender1   1:0.9.10-1
ii  marco-common  1.20.3-1
ii  mate-desktop-common   1.20.4-2
ii  zenity    3.30.0-2

marco recommends no packages.

marco suggests no packages.


Versions of packages metacity depends on:
ii  gsettings-desktop-schemas  3.28.1-1
ii  libatk1.0-0    2.30.0-2
ii  libc6  2.28-7
ii  libcairo2  1.16.0-2
ii  libcanberra-gtk3-0 0.30-7
ii  libcanberra0   0.30-7
ii  libgdk-pixbuf2.0-0 2.38.0+dfsg-7
ii  libglib2.0-0   2.58.3-1
ii  libgtk-3-0 3.24.5-1
ii  libgtop-2.0-11 2.38.0-4
ii  libice6    2:1.0.9-2
ii  libmetacity1   1:3.30.1-2
ii  libpango-1.0-0 1.42.4-6
ii  libsm6 2:1.2.3-1
ii  libstartup-notification0   0.12-6
ii  libx11-6   2:1.6.7-1
ii  libxcomposite1 1:0.4.4-2
ii  libxcursor1    1:1.1.15-2
ii  libxdamage1    1:1.1.4-3
ii  libxext6   2:1.3.3-1+b2
ii  libxfixes3 1:5.0.3-1
ii  libxinerama1   2:1.1.4-2
ii  libxrandr2 2:1.5.1-1
ii  libxrender1    1:0.9.10-1
ii  metacity-common    1:3.30.1-2
ii  zenity 3.30.0-2

metacity recommends no packages.

Versions of packages metacity suggests:
pn  gnome-control-center  
ii  xdg-user-dirs 0.17-2


-- no debconf information

Bug#859553: pidentd: Please migrate to openssl1.1 in buster

[Moritz Muehlenhoff]

On Thu, Feb 21, 2019 at 08:56:14PM +0100, Sebastian Andrzej Siewior wrote:
> Its popcon is dropping. It will not be part of Buster. So either RM it
> or

I have no use it for, I was just looking at it because it's one of the
five packages blocking the removal of src:openssl1.0, from my PoV it can
be removed for sure.

Cheers,
Moritz

Bug#910906: Acknowledgement (postfix: smtp segfaults (signal 11) while authenticating to gmail due to latest cyrus-sasl incompatibility (?))

[Jacek Kawa]

I've upgraded to the latest unstable  2.1.27+dfsg-1 version of libsasl and the 
SEGFAULT seems to be gone.

>From my point of view the bug can be closed.

-- 
Jacek Kawa

Bug#916595: vlc: program doesn't close its process in some cases

[pazifi]

Hi all,

here ist the same problem, vlc 3.0.6-1 (or kaffeine 2.0.15-2 which uses the vlc 
libs) 
don't close correctly if i use the "X" button from window-border to close the 
player.
If i go over the menu (File -> Exit) the programm cleanly.

$ lspci | grep VGA
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc.
[AMD/ATI] Seymour [Radeon HD 6400M/7400M Series]

$ dpkg -l | grep -i -E
"libglx-mesa0|libgl1-mesa-dri|vlc-plugin-video-output"
ii  libgl1-mesa-dri:amd64 18.3.2-1
amd64free implementation of the OpenGL API -- DRI modules
ii  libgl1-mesa-dri:i386  18.3.2-1
i386 free implementation of the OpenGL API -- DRI modules
ii  libglx-mesa0:amd6418.3.2-1
amd64free implementation of the OpenGL API -- GLX vendor
library
ii  libglx-mesa0:i386 18.3.2-1
i386 free implementation of the OpenGL API -- GLX vendor
library
ii  vlc-plugin-video-output:amd64 3.0.6-1
amd64multimedia player and streamer (video output plugins)


I hope i can help with this informations.

King regards,
pazifi

Bug#922930: stretch-pu: package slurm-llnl/16.05.9-1+deb9u2

[Gennaro Oliva]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

I'd like to update slurm-llnl in the next stable point release to
fix a security vulnerability (CVE-2019-6438) on 32-bit systems that
would potentially allow heap-overflow.

debdiff attached, diffstat follows:

 changelog |7 +
 patches/CVE-2019-6438 |   67 ++
 patches/series|1
 3 files changed, 75 insertions(+)

Thanks
-- 
Gennaro Oliva
diff -Nru slurm-llnl-16.05.9/debian/changelog 
slurm-llnl-16.05.9/debian/changelog
--- slurm-llnl-16.05.9/debian/changelog 2018-07-23 12:00:49.0 +0200
+++ slurm-llnl-16.05.9/debian/changelog 2019-02-21 17:24:53.0 +0100
@@ -1,3 +1,10 @@
+slurm-llnl (16.05.9-1+deb9u3) stretch; urgency=medium
+
+  * Fix CVE-2019-6438 by adding mitigation for a potential
+heap-overflow on 32-bit systems (Closes: #920997)
+
+ -- Gennaro Oliva   Thu, 21 Feb 2019 17:24:53 +0100
+
 slurm-llnl (16.05.9-1+deb9u2) stretch-security; urgency=high
 
   * Fix CVE-2018-10995 caused by mishandling user names (aka user_name
diff -Nru slurm-llnl-16.05.9/debian/patches/CVE-2019-6438 
slurm-llnl-16.05.9/debian/patches/CVE-2019-6438
--- slurm-llnl-16.05.9/debian/patches/CVE-2019-6438 1970-01-01 
01:00:00.0 +0100
+++ slurm-llnl-16.05.9/debian/patches/CVE-2019-6438 2019-02-21 
17:19:14.0 +0100
@@ -0,0 +1,67 @@
+Description: Add mitigation for a potential heap-overflow on 32-bit systems
+ Force intermediate values to uint64_t to catch the potential overflow
+ This patch was adapted from the changes of the 17.11 upstream branch
+Author: Gennaro Oliva 
+Bug-Debian: https://bugs.debian.org/920997
+Origin: 
https://github.com/SchedMD/slurm/commit/750cc23edcc6fddfff21d33bdaf4fb7deb28cfda
+Forwarded: no
+Last-Update: 2019-02-12
+
+--- a/src/common/xmalloc.c
 b/src/common/xmalloc.c
+@@ -72,13 +72,17 @@ static void malloc_assert_failed(char *,
+  *   clear (IN) initialize to zero
+  *   RETURN   pointer to allocate heap space
+  */
+-void *slurm_xmalloc(size_t size, bool clear,
++void *slurm_xmalloc(uint64_t size, bool clear,
+   const char *file, int line, const char *func)
+ {
+   void *new;
+   size_t *p;
+   size_t total_size = size + 2 * sizeof(size_t);
+ 
++
++  if (size > 0x)
++  fatal("attempt at overflow");
++
+   if (clear)
+   p = calloc(1, total_size);
+   else
+--- slurm-llnl-16.05.9.orig/src/common/xmalloc.h
 slurm-llnl-16.05.9/src/common/xmalloc.h
+@@ -76,6 +76,8 @@
+ #ifndef _XMALLOC_H
+ #define _XMALLOC_H
+ 
++#include 
++
+ #if HAVE_SYS_TYPES_H
+ #  include 
+ #endif
+@@ -83,13 +85,13 @@
+ #include "macros.h"
+ 
+ #define xmalloc(__sz) \
+-  slurm_xmalloc (__sz, true, __FILE__, __LINE__, __CURRENT_FUNC__)
++  slurm_xmalloc ((uint64_t) __sz, true, __FILE__, __LINE__, 
__CURRENT_FUNC__)
+ 
+ #define xmalloc_nz(__sz) \
+-  slurm_xmalloc (__sz, false, __FILE__, __LINE__, __CURRENT_FUNC__)
++  slurm_xmalloc ((uint64_t) __sz, false, __FILE__, __LINE__, 
__CURRENT_FUNC__)
+ 
+ #define try_xmalloc(__sz) \
+-  slurm_try_xmalloc(__sz, __FILE__, __LINE__, __CURRENT_FUNC__)
++  slurm_try_xmalloc((uint64_t) __sz, __FILE__, __LINE__, __CURRENT_FUNC__)
+ 
+ #define xfree(__p) \
+   slurm_xfree((void **)&(__p), __FILE__, __LINE__, __CURRENT_FUNC__)
+@@ -109,7 +111,7 @@
+ #define xsize(__p) \
+   slurm_xsize((void *)__p, __FILE__, __LINE__, __CURRENT_FUNC__)
+ 
+-void *slurm_xmalloc(size_t, bool, const char *, int, const char *);
++void *slurm_xmalloc(uint64_t, bool, const char *, int, const char *);
+ void *slurm_try_xmalloc(size_t , const char *, int , const char *);
+ void slurm_xfree(void **, const char *, int, const char *);
+ void *slurm_xrealloc(void **, size_t, bool, const char *, int, const char *);
diff -Nru slurm-llnl-16.05.9/debian/patches/series 
slurm-llnl-16.05.9/debian/patches/series
--- slurm-llnl-16.05.9/debian/patches/series2018-06-22 09:53:34.0 
+0200
+++ slurm-llnl-16.05.9/debian/patches/series2019-02-21 17:19:14.0 
+0100
@@ -5,3 +5,4 @@
 CVE-2017-15566
 CVE-2018-10995
 CVE-2018-7033
+CVE-2019-6438

Bug#922929: doc-debian: please convert to git and migrate to salsa

[Joost van Baal-Ilić]

Package: doc-debian
Version: 6.4

Hi,

https://tracker.debian.org/pkg/doc-debian still lists
svn://anonscm.debian.org/ddp/packages/trunk/doc-debian/ as vcs.

The repo should get converted from SVN to git and should get moved to e.g.
https://salsa.debian.org/ddp-team .

(it seems https://salsa.debian.org/debian/ddp is not used; maybe
that should get removed?)

Bye,

Joost

Bug#922928: cyrus-common: /usr/share/man/man8/restore.8.gz is already provided by the dump package

[Andreas Beckmann]

Package: cyrus-common
Version: 3.0.8-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

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

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

  Selecting previously unselected package cyrus-common. 

   Preparing to unpack 
.../36-cyrus-common_3.0.8-2_amd64.deb ...   

 Unpacking cyrus-common (3.0.8-2) ...   


  dpkg: error processing archive 
/tmp/apt-dpkg-install-GxfAgg/36-cyrus-common_3.0.8-2_amd64.deb (--unpack):  

   trying to overwrite '/usr/share/man/man8/restore.8.gz', 
which is also in package dump 0.4b46-5  

Errors were encountered while processing:   

  
/tmp/apt-dpkg-install-GxfAgg/36-cyrus-common_3.0.8-2_amd64.deb  

  

cheers,

Andreas


dump=0.4b46-5_cyrus-common=3.0.8-2.log.gz
Description: application/gzip

Bug#922927: embree-tools: /usr/bin/convert is already provided by graphicsmagick-imagemagick-compat

[Andreas Beckmann]

Package: embree-tools
Version: 3.5.0+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files.

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

  Preparing to unpack .../embree-tools_3.5.0+dfsg-1_amd64.deb ...   

   Unpacking embree-tools 
(3.5.0+dfsg-1) ...  

  dpkg: error processing archive 
/var/cache/apt/archives/embree-tools_3.5.0+dfsg-1_amd64.deb (--unpack): 

   trying to overwrite '/usr/bin/convert', which is also in 
package graphicsmagick-imagemagick-compat 1.4~hg15896-1 
   
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)

 Errors were encountered 
while processing:   

  
/var/cache/apt/archives/embree-tools_3.5.0+dfsg-1_amd64.deb 

  

cheers,

Andreas


graphicsmagick-imagemagick-compat=1.4~hg15896-1_embree-tools=3.5.0+dfsg-1.log.gz
Description: application/gzip

Bug#922926: commit-patch: fails to install along xemacs21: Invalid read syntax: "Weird old-backquote syntax"

[Andreas Beckmann]

Package: commit-patch
Version: 2.6-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

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

  Setting up commit-patch (2.6-1) ...
  Install emacsen-common for xemacs21
  emacsen-common: Handling install of emacsen flavor xemacs21
  Loading /usr/share/emacsen-common/debian-startup...
  Loading 00debian...
  Compiling /usr/share/xemacs21/site-lisp/debian-startup.el...
  Wrote /usr/share/xemacs21/site-lisp/debian-startup.elc
  Done
  Install commit-patch for xemacs21
  install/commit-patch: Handling install for emacsen flavor xemacs21
  Loading /usr/share/emacsen-common/debian-startup...
  Loading 00debian...
  Compiling /usr/share/xemacs21/site-lisp/commit-patch/commit-patch-buffer.el...
  Loading dired-mule...
  While compiling toplevel forms in file 
/usr/share/xemacs21/site-lisp/commit-patch/commit-patch-buffer.el:
!! Invalid read syntax (("Weird old-backquote syntax"))
  >>Error occurred processing commit-patch-buffer.el: 
  Invalid read syntax: "Weird old-backquote syntax"
  
  
  Done
  ERROR: install script from commit-patch package failed
  dpkg: error processing package commit-patch (--configure):
   installed commit-patch package post-installation script subprocess returned 
error exit status 1
  Errors were encountered while processing:
   commit-patch


cheers,

Andreas


commit-patch=2.6-1_xemacs21.log.gz
Description: application/gzip

Bug#922925: libreoffice: Please add a crash tracker

[Jean-Philippe MENGUAL]

Package: libreoffice
Version: 1:6.1.5-1
Severity: wishlist

Dear Maintainer,

I would love to have the LO crash tracker in Debian, so that I could use Deb 
packages to report bugs with a good trace. Would it be
possible?

Regards

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

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

Versions of packages libreoffice depends on:
ii  libreoffice-avmedia-backend-gstreamer  1:6.1.5-1
ii  libreoffice-base   1:6.1.5-1
ii  libreoffice-calc   1:6.1.5-1
ii  libreoffice-core   1:6.1.5-1
ii  libreoffice-draw   1:6.1.5-1
ii  libreoffice-impress1:6.1.5-1
ii  libreoffice-math   1:6.1.5-1
ii  libreoffice-report-builder-bin 1:6.1.5-1
ii  libreoffice-writer 1:6.1.5-1
ii  python3-uno1:6.1.5-1

Versions of packages libreoffice recommends:
ii  fonts-crosextra-caladea 20130214-2
ii  fonts-crosextra-carlito 20130920-1
ii  fonts-dejavu2.37-1
ii  fonts-liberation1:1.07.4-9
ii  fonts-liberation2   2.00.4-1
ii  fonts-linuxlibertine5.3.0-4
ii  fonts-noto-core 20181227-1
ii  fonts-noto-mono 20181227-1
ii  fonts-noto-ui-core  20181227-1
ii  fonts-sil-gentium-basic 1.102-1
ii  libreoffice-java-common 1:6.1.5-1
ii  libreoffice-librelogo   1:6.1.5-1
ii  libreoffice-nlpsolver   0.9+LibO6.1.5-1
ii  libreoffice-report-builder  1:6.1.5-1
ii  libreoffice-script-provider-bsh 1:6.1.5-1
ii  libreoffice-script-provider-js  1:6.1.5-1
ii  libreoffice-script-provider-python  1:6.1.5-1
ii  libreoffice-sdbc-postgresql 1:6.1.5-1
ii  libreoffice-wiki-publisher  1.2.0+LibO6.1.5-1

Versions of packages libreoffice suggests:
ii  cups-bsd2.2.10-4
ii  default-jre [java6-runtime] 2:1.11-71
ii  ghostscript 9.26a~dfsg-2
ii  gnupg   2.2.12-1
pn  gpa 
pn  gstreamer1.0-libav  
ii  gstreamer1.0-plugins-bad1.14.4-1+b1
ii  gstreamer1.0-plugins-base   1.14.4-1
ii  gstreamer1.0-plugins-good   1.14.4-1
ii  gstreamer1.0-plugins-ugly   1.14.4-1
ii  hunspell-en-us [hunspell-dictionary]1:2018.04.16-1
ii  hunspell-fr-comprehensive [hunspell-dictionary] 1:6.3-2
ii  hyphen-en-us [hyphen-hyphenation-patterns]  2.8.8-7
ii  imagemagick 8:6.9.10.23+dfsg-2
ii  imagemagick-6.q16 [imagemagick] 8:6.9.10.23+dfsg-2
ii  libgl1  1.1.0-1
pn  libreoffice-gnome | libreoffice-kde5
pn  libreoffice-grammarcheck
pn  libreoffice-help
pn  libreoffice-l10n
pn  libreoffice-officebean  
ii  libsane 1.0.27-3.1
ii  libxrender1 1:0.9.10-1
pn  myspell-dictionary  
pn  mythes-thesaurus
pn  openclipart2-libreoffice | openclipart-libreoffice  
ii  openjdk-11-jre [java6-runtime]  11.0.2+9-3
pn  pstoedit
ii  thunderbird 1:60.5.1-1
pn  unixodbc

Versions of packages libreoffice-core depends on:
ii  fontconfig2.13.1-2
ii  fonts-opensymbol  2:102.10+LibO6.1.5-1
ii  libboost-date-time1.67.0  1.67.0-13
ii  libboost-locale1.67.0 1.67.0-13
ii  libc6 2.28-7
ii  libcairo2 1.16.0-2
ii  libclucene-contribs1v52.3.3.4+dfsg-1
ii  libclucene-core1v5

Bug#921913: locales: character map file `C' not found: No such file or directory

[Aurelien Jarno]

On 2019-02-21 22:01, Helge Kreutzmann wrote:
> Hello Aurelien,
> On Wed, Feb 20, 2019 at 09:14:15PM +0100, Aurelien Jarno wrote:
> > On 2019-02-10 08:48, Helge Kreutzmann wrote:
> > > Package: locales
> > > Version: 2.28-6
> > > Severity: minor
> > > 
> > > In todays upgrade in my sid chroot I see the following messages
> > > locales (2.28-6) wird eingerichtet ...
> > > Generating locales (this might take a while)...
> > >   de_DE.ISO-8859-1... done
> > >   de_DE.UTF-8... done
> > >   en_GB.UTF-8... done
> > >   en_US.UTF-8... done
> > >   C.C...[error] character map file `C' not found: No such file or 
> > > directory
> > >  done
> > > Generation complete.
> > > 
> > > I don't know if this is new or older or if this poses a problem. I can 
> > > provide you with mor details if necessary.
> > > 
> > 
> > The list of locales to be generated is defined by /etc/locale.gen, it
> > looks like there is someting wrong there. Could you please send me a
> > copy of this file?
> 
> I attached the file.

The issue is the "C C" line in that file. Now I have no idea how it
ended up there, as it's not one of the value offered by default in the
debconf template. It only appears there if it is found in the
/etc/locale.gen config file.

Aurelien

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


signature.asc
Description: PGP signature

Bug#922924: RM: libopencv3.3-java/experimental libopencv3.4-java/experimental -- RoQA; superseded by libopencv4.0-java

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

this arch:all removal should enable auto-decrufting opencv arch:any in
experimental.


Andreas

Bug#922923: qemu: CVE-2019-8934: ppc64: sPAPR emulator leaks the host hardware identity

[Salvatore Bonaccorso]

Source: qemu
Version: 1:3.1+dfsg-4
Severity: normal
Tags: security upstream
Forwarded: https://lists.gnu.org/archive/html/qemu-devel/2019-02/msg04821.html

Hi,

The following vulnerability was published for qemu.

CVE-2019-8934[0]:
ppc64: sPAPR emulator leaks the host hardware identity

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-8934
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-8934
[1] https://lists.gnu.org/archive/html/qemu-devel/2019-02/msg04821.html
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1668022

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#922919: devscripts: ltnu does not show real last upload

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Thu, 2019-02-21 at 22:01 +0100, Helge Kreutzmann wrote:
> If I run ltnu:
> helge@samd:~$ ltnu
>   source   |ver|uploaded
> ---+---+
>  asclock   | 2.0.12-29 | 2018-06-25 17:34:04+00
>  linuxinfo | 3.1.2-1   | 2018-11-27 11:36:05+00
>  goobox| 3.5.1-2   | 2019-01-12 12:34:33+00
> 
[...]
> As you can see, latest goobox is 3.5.1-6 (uploaded early 
> February), not 3.5.1-2.

FWIW, running the script from git appears to work fine:

$ ./scripts/ltnu.sh  deb...@helgefjell.de
  source   |ver|uploaded
---+---+
 asclock   | 2.0.12-29 | 2018-06-25 17:34:04+00
 linuxinfo | 3.1.2-1   | 2018-11-27 11:36:05+00
 goobox| 3.5.1-6   | 2019-02-10 08:45:50+00
(3 rows)

Regards,

Adam

Bug#896080: AppArmor/Samba integration in Debian

[Mathieu Parent]

Hi Christian,

I'm working on AppArmor/Samba integration in Samba and integrated you'
"update-apparmor-samba-profile" script.

I've taken version 1.1, but it silently exists with:

grep -q '^/usr/sbin/smbd (' /sys/kernel/security/apparmor/profiles || \
silentexit "smbd profile not loaded"

I don't have the complete path but the profile name in this file:

$ sudo cat /sys/kernel/security/apparmor/profiles | grep smbd
smbd (enforce)

I don't know much about Apparmor, is this a bug in the script or a
behavior difference under Debian?

Regards
-- 
Mathieu Parent

Bug#922921: RFP: node-socks -- A simple SOCKS implementation and demo proxy in nodejs

[Jeff Cliff]

Package: wnpp
Severity: wishlist

* Package name: node-socks
  Version : 0.1.0
  Upstream Author : Gert Van Gool
* URL : 
http://kpeg6pch3dxlxfgejngjgpigdyuwigjicffvenohanelvk2mmsijxpid.onion/dir
* License : MIT
  Programming Lang: javascript
  Description : A simple SOCKS implementation and demo proxy in nodejs

SOCKS is an Internet protocol that exchanges network packets between a client 
and server through 
a proxy server. 

You can run node-socks as easily as "./socks" - this will create a SOCKS proxy 
at 127.0.0.1 on 
port .

node-socks is a dependency of meteor #842425.

Bug#922920: RM: imdbpy -- python-imdbpy package removed

[Ana Guerrero Lopez]

Package: ftp.debian.org
Severity: normal

Hi,

In the last upload, imdbpy dropped the python-imdbpy package and
it's now only shipping python3-imdbpy.
Could you please remove the python-imdbpy binaries?

Thanks!

Ana

Bug#922922: koji: CVE-2018-1002161: SQL injection in multiple remote calls

[Salvatore Bonaccorso]

Source: koji
Version: 1.16.1-1
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for koji.

CVE-2018-1002161[0]:
SQL injection in multiple remote calls

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-1002161
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1002161
[1] https://pagure.io/koji/issue/1183
[2] https://docs.pagure.org/koji/CVE-2018-1002161/

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#922914: Check also on storing item

[積丹尼 Dan Jacobson]

$ XDG_UTILS_DEBUG_LEVEL=33 xdg-mime default .desktop text/html
make_default_kde: No kde runtime detected
make_default_generic .desktop text/html
Updating /home/jidanni/.config/mimeapps.list
$ cat /home/jidanni/.config/mimeapps.list
[Default Applications]
text/html=.desktop
$ XDG_UTILS_DEBUG_LEVEL=33 xdg-mime query default text/html
Checking /home/jidanni/.config/mimeapps.list
Checking /home/jidanni/.local/share/applications/mimeapps.list
Checking /home/jidanni/.local/share/applications/defaults.list and 
/home/jidanni/.local/share/applications/mimeinfo.cache
Checking /home/jidanni/.local/share/applications/defaults.list and 
/home/jidanni/.local/share/applications/mimeinfo.cache
Checking /usr/local/share//applications/defaults.list and 
/usr/local/share//applications/mimeinfo.cache
Checking /usr/local/share//applications/defaults.list and 
/usr/local/share//applications/mimeinfo.cache
Checking /usr/share//applications/defaults.list and 
/usr/share//applications/mimeinfo.cache
org.gnome.Epiphany.desktop
$ XDG_UTILS_DEBUG_LEVEL=33 xdg-mime query default text/html 2>&1|uniq -c
  1 Checking /home/jidanni/.config/mimeapps.list
  1 Checking /home/jidanni/.local/share/applications/mimeapps.list
  2 Checking /home/jidanni/.local/share/applications/defaults.list and 
/home/jidanni/.local/share/applications/mimeinfo.cache
  2 Checking /usr/local/share//applications/defaults.list and 
/usr/local/share//applications/mimeinfo.cache
  1 Checking /usr/share//applications/defaults.list and 
/usr/share//applications/mimeinfo.cache
  1 org.gnome.Epiphany.desktop

We notice: same checks messages twice. Spurious "//"s.

$ XDG_UTILS_DEBUG_LEVEL=33 xdg-mime query default text/html 2>&1|tr \  \\n|sort 
-u|grep ^/ |xargs grep text/html 2>&-
/home/jidanni/.config/mimeapps.list:text/html=.desktop
/home/jidanni/.local/share/applications/mimeapps.list:text/html=userapp-Aurora-OCQ17W.desktop
/home/jidanni/.local/share/applications/mimeapps.list:text/html=userapp-Aurora-OCQ17W.desktop;
/usr/share//applications/mimeinfo.cache:text/html=org.gnome.Epiphany.desktop;chromium.desktop;firefox.desktop;abiword.desktop;

$ XDG_UTILS_DEBUG_LEVEL=33 xdg-mime query default text/html
Checking /home/jidanni/.config/mimeapps.list
chromium.desktop

Conclusion:
So there is a check on if the item really exists, but it is only done on
retrieving it. Not storing it. Why not both?

Bug#912193: Post message upstream

[Paul Szabo]

Dear Mathieu,

> As Louis said ... please
> ask on the samba mailing list, and add a pointer here.

I expect that the Samba people will simply tell me to use latest
version; and we have 4.5, still.

Still, I might contact them sometime; it will take me a while to get
there, though (too many "day jobs" to complete first).

Cheers, Paul
-- 
Paul Szabo   p...@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of SydneyAustralia

Bug#921913: locales: character map file `C' not found: No such file or directory

[Helge Kreutzmann]

Hello Aurelien,
On Wed, Feb 20, 2019 at 09:14:15PM +0100, Aurelien Jarno wrote:
> On 2019-02-10 08:48, Helge Kreutzmann wrote:
> > Package: locales
> > Version: 2.28-6
> > Severity: minor
> > 
> > In todays upgrade in my sid chroot I see the following messages
> > locales (2.28-6) wird eingerichtet ...
> > Generating locales (this might take a while)...
> >   de_DE.ISO-8859-1... done
> >   de_DE.UTF-8... done
> >   en_GB.UTF-8... done
> >   en_US.UTF-8... done
> >   C.C...[error] character map file `C' not found: No such file or directory
> >  done
> > Generation complete.
> > 
> > I don't know if this is new or older or if this poses a problem. I can 
> > provide you with mor details if necessary.
> > 
> 
> The list of locales to be generated is defined by /etc/locale.gen, it
> looks like there is someting wrong there. Could you please send me a
> copy of this file?

I attached the file.

Thanks and Greetings

   Helge
-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


locale.gen
Description: GENbank data


signature.asc
Description: Digital signature

Bug#922919: devscripts: ltnu does not show real last upload

[Helge Kreutzmann]

Package: devscripts
Version: 2.19.2
Severity: normal

If I run ltnu:
helge@samd:~$ ltnu
  source   |ver|uploaded
---+---+
 asclock   | 2.0.12-29 | 2018-06-25 17:34:04+00
 linuxinfo | 3.1.2-1   | 2018-11-27 11:36:05+00
 goobox| 3.5.1-2   | 2019-01-12 12:34:33+00
(3 Zeilen)

helge@samd:~$ dpkg -l goobox|grep ii
ii  goobox 3.5.1-6  amd64CD player and ripper with GNOME 3 
integration

As you can see, latest goobox is 3.5.1-6 (uploaded early 
February), not 3.5.1-2.

-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
Not present

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

Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to de_DE.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages devscripts depends on:
ii  dpkg-dev  1.19.2
ii  fakeroot  1.23-1
ii  file  1:5.35-2
ii  gnupg 2.2.12-1
ii  gnupg22.2.12-1
ii  gpgv  2.2.12-1
ii  libc6 2.28-7
ii  libfile-homedir-perl  1.004-1
ii  libfile-which-perl1.23-1
ii  libipc-run-perl   20180523.0-1
ii  libmoo-perl   2.003004-2
ii  libwww-perl   6.36-1
ii  patchutils0.3.4-2
ii  perl  5.28.1-4
ii  python3   3.7.2-1
ii  sensible-utils0.0.12
ii  wdiff 1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 1.8.0~rc3
pn  at  
ii  curl7.64.0-1
ii  dctrl-tools 2.24-3
ii  debian-keyring  2018.12.24
ii  dput1.0.3
pn  equivs  
pn  libdistro-info-perl 
ii  libdpkg-perl1.19.2
ii  libencode-locale-perl   1.05-1
pn  libgit-wrapper-perl 
pn  libgitlab-api-v4-perl   
pn  liblist-compare-perl
ii  liblwp-protocol-https-perl  6.07-2
pn  libsoap-lite-perl   
pn  libstring-shellquote-perl   
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 1.76-1
pn  licensecheck
ii  lintian 2.6.0
ii  man-db  2.8.5-2
ii  patch   2.7.6-3
ii  python3-apt 1.8.3
ii  python3-debian  0.1.34
ii  python3-magic   2:0.4.15-2
ii  python3-requests2.20.0-2
pn  python3-unidiff 
pn  python3-xdg 
ii  strace  4.26-0.2
ii  unzip   6.0-22
ii  wget1.20.1-1
ii  xz-utils5.2.4-1

Versions of packages devscripts suggests:
pn  adequate   
pn  autopkgtest
pn  bls-standalone 
pn  bsd-mailx | mailx  
ii  build-essential12.5
pn  check-all-the-things   
pn  cvs-buildpackage   
ii  debhelper  12.1
pn  devscripts-el  
pn  diffoscope 
pn  disorderfs 
pn  dose-extra 
pn  duck   
pn  faketime   
pn  gnuplot
ii  how-can-i-help 16
ii  libauthen-sasl-perl2.1600-1
ii  libdbd-pg-perl 3.7.4-2
ii  libfile-desktopentry-perl  0.22-1
pn  libnet-smtps-perl  
pn  libterm-size-perl  
ii  libtimedate-perl   2.3000-2
pn  libyaml-syck-perl  
ii  mozilla-devscripts 0.53
ii  mutt   1.10.1-2
ii  openssh-client [ssh-client]1:7.9p1-6
pn  piuparts   
ii  postgresql-client  11+199
ii  postgresql-client-11 [postgresql-client]   11.1-2
ii  postgresql-client-9.5 [postgresql-client]  9.5.4-3
ii  quilt  0.65-3
pn  ratt   
pn  reprotest  
pn  svn-buildpackage   
pn  w3m

-- no debconf information

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered

Bug#922918: stretch-pu: package twitter-bootstrap3/3.3.7+dfsg-2+deb9u1

[Xavier Guimard]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Hi all,

A little fix for CVE-2019-8331.

Cheers,
Xavier

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

Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru twitter-bootstrap3-3.3.7+dfsg/debian/changelog 
twitter-bootstrap3-3.3.7+dfsg/debian/changelog
--- twitter-bootstrap3-3.3.7+dfsg/debian/changelog  2019-02-04 
22:25:25.0 +0100
+++ twitter-bootstrap3-3.3.7+dfsg/debian/changelog  2019-02-21 
21:42:06.0 +0100
@@ -1,3 +1,9 @@
+twitter-bootstrap3 (3.3.7+dfsg-2+deb9u2) UNRELEASED; urgency=medium
+
+  * Add patch to fix CVE-2019-8331: XSS in tooltip or popover
+
+ -- Xavier Guimard   Thu, 21 Feb 2019 21:42:06 +0100
+
 twitter-bootstrap3 (3.3.7+dfsg-2+deb9u1) stretch; urgency=high
 
   * Team upload.
diff -Nru twitter-bootstrap3-3.3.7+dfsg/debian/patches/CVE-2019-8331.patch 
twitter-bootstrap3-3.3.7+dfsg/debian/patches/CVE-2019-8331.patch
--- twitter-bootstrap3-3.3.7+dfsg/debian/patches/CVE-2019-8331.patch
1970-01-01 01:00:00.0 +0100
+++ twitter-bootstrap3-3.3.7+dfsg/debian/patches/CVE-2019-8331.patch
2019-02-21 21:40:12.0 +0100
@@ -0,0 +1,257 @@
+Description: Fix XSS - CVE-2019-8331
+Author: Xavier Guimard 
+Origin: upstream
+Forwarded: not-needed
+Last-Update: 2019-02-21
+
+--- a/js/dropdown.js
 b/js/dropdown.js
+@@ -29,7 +29,7 @@
+   selector = selector && /#[A-Za-z]/.test(selector) && 
selector.replace(/.*(?=#[^\s]*$)/, '') // strip for ie7
+ }
+ 
+-var $parent = selector && $(document).find(selector)
++var $parent = selector !== '#' ? $(document).find(selector) : null
+ 
+ return $parent && $parent.length ? $parent : $this.parent()
+   }
+--- a/js/popover.js
 b/js/popover.js
+@@ -45,10 +45,25 @@
+ var title   = this.getTitle()
+ var content = this.getContent()
+ 
+-$tip.find('.popover-title')[this.options.html ? 'html' : 'text'](title)
+-$tip.find('.popover-content').children().detach().end()[ // we use append 
for html objects to maintain js events
+-  this.options.html ? (typeof content == 'string' ? 'html' : 'append') : 
'text'
+-](content)
++if (this.options.html) {
++  var typeContent = typeof content
++
++  if (this.options.sanitize) {
++title = this.sanitizeHtml(title)
++
++if (typeContent === 'string') {
++  content = this.sanitizeHtml(content)
++}
++  }
++
++  $tip.find('.popover-title').html(title)
++  $tip.find('.popover-content').children().detach().end()[
++typeContent === 'string' ? 'html' : 'append'
++  ](content)
++} else {
++  $tip.find('.popover-title').text(title)
++  $tip.find('.popover-content').children().detach().end().text(content)
++}
+ 
+ $tip.removeClass('fade top bottom left right in')
+ 
+--- a/js/tooltip.js
 b/js/tooltip.js
+@@ -11,6 +11,137 @@
+ +function ($) {
+   'use strict';
+ 
++  var DISALLOWED_ATTRIBUTES = ['sanitize', 'whiteList', 'sanitizeFn']
++
++  var uriAttrs = [
++'background',
++'cite',
++'href',
++'itemtype',
++'longdesc',
++'poster',
++'src',
++'xlink:href'
++  ]
++
++  var ARIA_ATTRIBUTE_PATTERN = /^aria-[\w-]*$/i
++
++  var DefaultWhitelist = {
++// Global attributes allowed on any supplied element below.
++'*': ['class', 'dir', 'id', 'lang', 'role', ARIA_ATTRIBUTE_PATTERN],
++a: ['target', 'href', 'title', 'rel'],
++area: [],
++b: [],
++br: [],
++col: [],
++code: [],
++div: [],
++em: [],
++hr: [],
++h1: [],
++h2: [],
++h3: [],
++h4: [],
++h5: [],
++h6: [],
++i: [],
++img: ['src', 'alt', 'title', 'width', 'height'],
++li: [],
++ol: [],
++p: [],
++pre: [],
++s: [],
++small: [],
++span: [],
++sub: [],
++sup: [],
++strong: [],
++u: [],
++ul: []
++  }
++
++  /**
++   * A pattern that recognizes a commonly useful subset of URLs that are safe.
++   *
++   * Shoutout to Angular 7 
https://github.com/angular/angular/blob/7.2.4/packages/core/src/sanitization/url_sanitizer.ts
++   */
++  var SAFE_URL_PATTERN = 
/^(?:(?:https?|mailto|ftp|tel|file):|[^&:/?#]*(?:[/?#]|$))/gi
++
++  /**
++   * A pattern that matches safe data URLs. Only matches image, video and 
audio types.
++   *
++   * Shoutout to Angular 7 
https://github.com/angular/angular/blob/7.2.4/packages/core/src/sanitization/url_sanitizer.ts
++   */
++  var DATA_URL_PATTERN = 
/^data:(?:image\/(?:bmp|gif|jpeg|jpg|png|tiff|webp)|video\/(?:mpeg|mp4|ogg|webm)|audio\/(?:mp3|oga|ogg|opus));base64,[a-z0-9+/]+=*$/i
++
++  function 

Bug#912193: Post message upstream

[Mathieu Parent]

Hello,

As Louis said (in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912193#25), please
ask on the samba mailing list, and add a pointer here.

Regards

-- 
Mathieu Parent

Bug#922917: Non-standard man page ruins apropos(1) view

[積丹尼 Dan Jacobson]

Package: gvfs-common
Version: 1.39.90-1
Severity: minor
File: /usr/share/man/man1/gvfs-open.1.gz

$ apropos bzcat
bzcat (1)- decompresses files to stdout
$ apropos gvfs-open
gvfs-open (1)- (unknown subject)

Bug#922916: network-manager: I think it's the same as #922554. No wifi connection is possible.

[Steve Newcomb]

Package: network-manager
Version: 1.14.4-4
Severity: normal

Dear Maintainer,


   * What led up to the situation?
Regular maintenance via aptitude (apt update).
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Waited for connection to be made.  
   * What was the outcome of this action?
No connection was made, either to secure or open wireless APs. 
   * What outcome did you expect instead?
A connection to be made, as was the case before maintenance.

By the way, all our similar systems (3 Lenovo X-220s) running Stretch
9.6 still work fine, unlike the 2 Lenovo X-220s running Buster/Sid.
All were updated via apt today.

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

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

Versions of packages network-manager depends on:
ii  adduser3.118
ii  dbus   1.12.12-1
ii  init-system-helpers1.56+nmu1
ii  libaudit1  1:2.8.4-2
ii  libbluetooth3  5.50-1
ii  libc6  2.28-6
ii  libcurl3-gnutls7.64.0-1
ii  libglib2.0-0   2.58.3-1
ii  libgnutls303.6.6-2
ii  libjansson42.12-1
ii  libmm-glib01.10.0-1
ii  libndp01.6-1+b1
ii  libnewt0.520.52.20-8
ii  libnm0 1.14.4-4
ii  libpam-systemd 240-5
ii  libpolkit-agent-1-00.105-25
ii  libpolkit-gobject-1-0  0.105-25
ii  libpsl50.20.2-2
ii  libreadline7   7.0-5
ii  libselinux12.8-1+b1
ii  libsystemd0240-5
ii  libteamdctl0   1.28-1
ii  libudev1   240-5
ii  libuuid1   2.33.1-0.1
ii  lsb-base   10.2018112800
ii  policykit-10.105-25
ii  udev   240-5
ii  wpasupplicant  2:2.6-21

Versions of packages network-manager recommends:
ii  crda 3.18-1
ii  dnsmasq-base [dnsmasq-base]  2.80-1
ii  iptables 1.8.2-3
ii  isc-dhcp-client  4.4.1-2
ii  modemmanager 1.10.0-1
ii  ppp  2.4.7-2+4

Versions of packages network-manager suggests:
pn  libteam-utils  

-- no debconf information

Bug#922915: initscripts: Please do not enable tmpfs-based shm on Hurd

[Samuel Thibault]

Package: initscripts
Version: 2.93-6
Severity: important
Tags: patch

Hello,

Please do not enable tmpfs-based shm by default on the Hurd yet, the
tmpfs implementation is not ready for that yet and triggers runtime
issues.

The attached patch makes the default per-kernel, could you apply it?

Thanks,
Samuel

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

Kernel: Linux 4.20.0 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages initscripts depends on:
ii  coreutils   8.30-1
ii  debianutils 4.8.6.1
ii  lsb-base10.2018112800
ii  mount   2.33.1-0.1
ii  sysv-rc 2.93-6
ii  sysvinit-utils  2.93-6

Versions of packages initscripts recommends:
ii  e2fsprogs  1.44.5-1
ii  psmisc 23.2-1

initscripts suggests no packages.

-- Configuration Files:
/etc/default/rcS changed [not included]

-- no debconf information

-- 
Samuel
 > et sinon, quand on s'interesse a un media que l'on ne maitrise pas,
 > on essaye de le comprendre d'abord.
 (Suivi par l'intégralité du message initial de 45 lignes.)
 -+-BM in : GNU - La maîtrise est un long apprentissage petit scarabé -+-
---
 debian/src/initscripts/lib/init/tmpfs.sh |   10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

--- a/debian/src/initscripts/lib/init/tmpfs.sh
+++ b/debian/src/initscripts/lib/init/tmpfs.sh
@@ -85,8 +85,16 @@ need_overflow_tmp ()
 # values here.
 
 RAMLOCK=yes
+KERNEL="$(uname -s)"
 # These might be overridden by /etc/default/rcS
-if [ -z "$RAMSHM" ]; then RAMSHM=yes; fi
+case "$KERNEL" in
+   GNU)
+   if [ -z "$RAMSHM" ]; then RAMSHM=no; fi
+   ;;
+   *)
+   if [ -z "$RAMSHM" ]; then RAMSHM=yes; fi
+   ;;
+esac
 if [ -z "$RAMTMP" ]; then RAMTMP=no; fi
 
 TMPFS_SIZE=20%VM

Bug#892244: debian-faq: broken link in extended description / Re: debian-www: doc-debian package page contains invalid URL

[Joost van Baal-Ilić]

Indeed, https://packages.debian.org/sid/debian-faq
(and the extended description in the debian faq package control file)
should link to https://deb.debian.org/debian/doc/FAQ ,
not to https://ftp.debian.org/debian/doc/FAQ .

Bug#887841: followup

[Jeffrey Cliff]

A year ago you expressed interest in packaging node-smart-buffer.  Are you
still interested in doing so?  Is there anything in particular that is
getting in your way?

Bug#896080: Improve samba/AppArmor integration

[Mathieu Parent]

Hello,

As a last-minute fix for buster, I want to fix "#896080 samba: Improve
AppArmor integration" [SambaAppArmor].

I've prepared the fixes [Diff], inspired by what is done in Suse. But
they also patch apparmor-profiles [AppArmor-Patch]. This solution does
not conforms to policy as a file owned by a package could not be
changed by another one (/etc/apparmor.d/local/usr.sbin.smbd-shares
owned by apparmor-profiles, changed by samba).

I can add in samba's README the need to add "#include
" in /etc/apparmor.d/usr.sbin.smbd, but
maybe you have a better solution? Maybe use dpkg-diversion?

Regards
-- 
Mathieu Parent

[SambaAppArmor]: https://bugs.debian.org/896080
[Diff]: 
https://salsa.debian.org/samba-team/samba/compare/874f9270b6f743c4d0c3eb1a1a3e1fa814bf25cc...bd4c1577a9b
[AppArmor-Patch]:
https://build.opensuse.org/package/view_file/openSUSE:Factory/apparmor/apparmor-samba-include-permissions-for-shares.diff?expand=1

Bug#922914: If cannot change default, then at least return an error

[積丹尼 Dan Jacobson]

Package: xdg-utils
Version: 1.1.3-1
File: /usr/bin/xdg-mime

$ xdg-mime default .desktop text/html; echo $?
0
$ xdg-mime query default text/html
org.gnome.Epiphany.desktop

Or make a sixth exit code to say what happened in this case.

EXIT CODES
   An exit code of 0 indicates success while a non-zero exit code indicates 
failure. The following failure codes can be returned:

   1
   Error in command line syntax.

   2
   One of the files passed on the command line did not exist.

   3
   A required tool could not be found.

   4
   The action failed.

   5
   No permission to read one of the files passed on the command line.

Bug#920631: [rb-general] debian-installer: Ensure build is reproducible regardless of the user's umask(2)

[Vagrant Cascadian]

On 2019-02-21, Chris Lamb wrote:
> Chris Lamb wrote:
>> > #920631 debian-installer: Ensure build is reproducible regardless
>> > of the user's umask(2)
>> [..]
>> > #920676: debian-installer: Ensure build is reproducible
>> > regardless of the underlying filesystem ordering
>> 
>> Thank you for developing and maintainer the Debian Installer. I
>> was wondering what might be needed on my end to ensure that these
>> patches end up in the next alpha/beta release?
>
> Sorry to bug you again folks but I haven't done any d-i development
> for almost 10 years now so I may not be aware of the most
> productive, helpful and — above everything else! — friendly way of
> getting things merged, particularly in time for buster. Can you
> help? :-)

I went ahead and merged them into git.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#776246: Processed: severity of 776246 is grave

[Valentin Vidic]

On Tue, Feb 19, 2019 at 10:26:09AM +0100, Christoph Martin wrote:
> What can we do to not loose these packages (burp in my case)?
> 
> librsync  2.0.2-1~exp1 was uploaded to experimental three days ago.

csync2 seems to build fine with librsync2 from experimental so if
you can upload that to unstable, maybe we can still save some of
the affected packages.

-- 
Valentin

Bug#903399: Fix makes tag untestable

[Felix Lechner]

On Thu, Feb 21, 2019 at 11:51 AM Chris Lamb  wrote:
> Not sure how we can get around this. Have you implemented similar
> things for other tags...?

The best alternative would be for the test to read the the value from
data/python/versions when constructing the test package. That way the
test fails when the value is changed. We can then remove the sed
script. Perhaps the sed script could even check before running if the
versions are the same. Then the whole thing would be on autopilot.

Bug#919048: fixed in unstable : should postpone autoremoval from testing

[Cédric Boutillier]

Hi,

This bug has been fixed with 1.0.0-1. ruby-haml-rails is flagged for
autoremoval in 19 hours. Hoping that writing to this bug will postpone
the autoremoval to let the package from unstable migrate to testing in
time.

Cédric

Bug#922913: galculator: % does not work in any way

[USR1987]

Package: galculator
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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



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

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

Versions of packages galculator depends on:
ii  libc6   2.24-11+deb9u4
ii  libglib2.0-02.50.3-2
ii  libgtk-3-0  3.22.11-1
ii  libpango-1.0-0  1.40.5-1
ii  libquadmath06.3.0-18+deb9u1

galculator recommends no packages.

galculator suggests no packages.

Bug#903399: Fix makes tag untestable

[Felix Lechner]

On Thu, Feb 21, 2019 at 11:51 AM Chris Lamb  wrote:
>
> Not sure how we can get around this. Have you implemented similar
> things for other tags...?

So far I have not faked a test, but sed will do a great job. Could the
Python minor number differ between the tags?

Bug#859553: pidentd: Please migrate to openssl1.1 in buster

[Sebastian Andrzej Siewior]

On 2019-02-20 23:09:11 [+0100], Moritz Mühlenhoff wrote:
> On Wed, Feb 20, 2019 at 08:51:16AM +0100, Moritz Muehlenhoff wrote:
> > On Wed, Feb 20, 2019 at 12:28:48AM +0100, Sebastian Andrzej Siewior wrote:
> > > On 2017-10-12 23:44:37 [+0200], To 859...@bugs.debian.org wrote:
> > > > this is a remainder about the openssl transition [0]. We really want to
> > > > remove libssl1.0-dev from unstable for Buster. I will raise the severity
> > > > of this bug to serious in a month. Please react before that happens.
> > > 
> > > There has been no action on pidentd and it is out of testing during
> > > soft-freeze. Should there be a RM bug filled? We do have alternative
> > > ident daemons in the archive. This package is holding back the removal
> > > of openssl 1.0.2 in the archive.
> > 
> > Or alternatively we can simply drop the idecrypt binary package, and remove
> > --with-des* from the configure (and the build dep). I doubt anyone really
> > uses the DES feature of ident...
> 
> Like the attached patch.

No, I don't think it makes sense. If I understand it correctly the DES
part is used to hide the real user but the admin should still be able to
decrypt/find out who was the orignal user.
Therefore I would suggest to either RM this and switch over to oidentd
with the spoof reply (and lookup in the user in the logfile) or fix this
package and upload it.
Its popcon is dropping. It will not be part of Buster. So either RM it
or (if you decide against it) I can NMU it with fixed DES support. There
is a patch in this bug report and it looks straight forward.

> Cheers,
> Moritz

Sebastian

Bug#922912: Update project URL

[積丹尼 Dan Jacobson]

Package: xdg-utils
Version: 1.1.3-1
Severity: minor
File: /usr/share/doc/xdg-utils/copyright

The project URL needs to be changed to
https://www.freedesktop.org/wiki/Software/xdg-utils/
from http://portland.freedesktop.org .

Bug#903399: Fix makes tag untestable

[Chris Lamb]

Hi Felix,

> The fix for this bug makes the tag 'old-python-version-field'
> untestable. When the version for old-python equals ancient-python,
> there is no way to reach the second block:
> 
> if (versions_lte($v, $ancient)) {
> tag 'ancient-python-version-field', $field, $v;
> } elsif (versions_lte($v, $old)) {
> tag 'old-python-version-field', $field, $v;
> 
> The tags cannot be combined.

Isn't that the point of them?

> Can we please find another solution, so that this tag is
> testable, too?

Not sure how we can get around this. Have you implemented similar
things for other tags...?


Regards,

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

Bug#903399: Fix makes tag untestable

[Felix Lechner]

The fix for this bug makes the tag 'old-python-version-field'
untestable. When the version for old-python equals ancient-python,
there is no way to reach the second block:

if (versions_lte($v, $ancient)) {
tag 'ancient-python-version-field', $field, $v;
} elsif (versions_lte($v, $old)) {
tag 'old-python-version-field', $field, $v;

The tags cannot be combined. They have different severities. I can
fake a test that swaps an actual 'ancient' tag for an 'old' tag, but
it would be a last resort. The test suite has almost full tag
coverage. Can we please find another solution, so that this tag is
testable, too?

Bug#859123: heads up: DLA should now be published on the website

[Holger Levsen]

On Thu, Feb 21, 2019 at 01:51:07PM -0500, Antoine Beaupré wrote:
> > -> this script is incorrect/broken for DLAs it seems, as 
> > https://www.debian.org/lts/security/ does list the DLAs 1677-1681,
> > just DLAs 1682-1685 are missing. And they are called DLA-1234 there,
> > not "DLA 1234-1"...
> Weird. Is your local checkout up to date?

yes

> What if you run in debug mode?

~/Projects/debian-www/cron$ ../cron/parts/10-check-advisories --mode DLA 
--debug 2>&1 | head -50
INFO: fetching URL 
https://salsa.debian.org/security-tracker-team/security-tracker/raw/master/data/DLA/list
DEBUG: Starting new HTTPS connection (1): salsa.debian.org
DEBUG: https://salsa.debian.org:443 "GET 
/security-tracker-team/security-tracker/raw/master/data/DLA/list HTTP/1.1" 200 
47253
INFO: checking DLA-1685-1 (2019)
ERROR: .data or .wml file missing for DLA 1685-1
DEBUG: skipping line: " {CVE-2019-6338}"
DEBUG: skipping line: " [jessie] - drupal7 7.32-1+deb8u15"
INFO: checking DLA-1684-1 (2019)
ERROR: .data or .wml file missing for DLA 1684-1
DEBUG: skipping line: " {CVE-2019-6454}"
DEBUG: skipping line: " [jessie] - systemd 215-17+deb8u10"
INFO: checking DLA-1683-1 (2019)
ERROR: .data or .wml file missing for DLA 1683-1
DEBUG: skipping line: " {CVE-2018-8791 CVE-2018-8792 CVE-2018-8793 
CVE-2018-8794 CVE-2018-8795 CVE-2018-8796 CVE-2018-8797 CVE-2018-8798 
CVE-2018-8799 CVE-2018-8800 CVE-2018-20174 CVE-2018-20175 CVE-2018-20176 
CVE-2018-20177 CVE-2018-20178 CVE-2018-20179 CVE-2018-20180 CVE-2018-20181 
CVE-2018-20182}"
DEBUG: skipping line: " [jessie] - rdesktop 1.8.4-0+deb8u1"
INFO: checking DLA-1660-2 (2019)
ERROR: .data or .wml file missing for DLA 1660-2
DEBUG: skipping line: " [jessie] - rssh 2.3.4-4+deb8u3"
INFO: checking DLA-1682-1 (2019)
ERROR: .data or .wml file missing for DLA 1682-1
DEBUG: skipping line: " {CVE-2018-20721}"
DEBUG: skipping line: " [jessie] - uriparser 0.8.0.1-2+deb8u2"
INFO: checking DLA-1681-1 (2019)
ERROR: .data or .wml file missing for DLA 1681-1
DEBUG: skipping line: " {CVE-2019-7659}"
DEBUG: skipping line: " [jessie] - gsoap 2.8.17-1+deb8u2"
INFO: checking DLA-1680-1 (2019)
ERROR: .data or .wml file missing for DLA 1680-1
DEBUG: skipping line: " {CVE-2018-17000 CVE-2018-19210 CVE-2019-7663}"
DEBUG: skipping line: " [jessie] - tiff 4.0.3-12.3+deb8u8"
INFO: checking DLA-1679-1 (2019)
ERROR: .data or .wml file missing for DLA 1679-1
DEBUG: skipping line: " [jessie] - php5 5.6.40+dfsg-0+deb8u1"
INFO: checking DLA-1678-1 (2019)
ERROR: .data or .wml file missing for DLA 1678-1
DEBUG: skipping line: " {CVE-2018-18356 CVE-2018-18500 CVE-2018-18501 
CVE-2018-18505 CVE-2018-18509 CVE-2019-5785}"
DEBUG: skipping line: " [jessie] - thunderbird 1:60.5.1-1~deb8u1"
INFO: checking DLA-1677-1 (2019)
ERROR: .data or .wml file missing for DLA 1677-1
DEBUG: skipping line: " {CVE-2018-18356 CVE-2019-5785}"
DEBUG: skipping line: " [jessie] - firefox-esr 60.5.1esr-1~deb8u1"
INFO: checking DLA-1676-1 (2019)
ERROR: .data or .wml file missing for DLA 1676-1
DEBUG: skipping line: " {CVE-2017-15105}"
DEBUG: skipping line: " [jessie] - unbound 1.4.22-3+deb8u4"
INFO: checking DLA-1675-1 (2019)
ERROR: .data or .wml file missing for DLA 1675-1
DEBUG: skipping line: " {CVE-2019-6690}"
DEBUG: skipping line: " [jessie] - python-gnupg 0.3.6-1+deb8u1"
INFO: checking DLA-1674-1 (2019)

> > Also, if this merge request would be merged, it would just run it in
> > normal, DSA, mode. Do you have a suggestion how to run it in DLA mode?
> We could simply change the default here:
> 
> parser.add_argument('--mode', default='DSA', choices=('DSA', 'DLA'),
> help='which sort of advisory to check (default: 
> %(default)s)')  # noqa: E501

hmm. (and then, what about missing DSAs?)


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#908438: same problem on buster/testing

[Axel]

Hi,

As my cubietruck went down because of a kernel bug in stretch i tought
it was maybe better to upgrade to buster since that's around the corner.
However now wifi stopped working:

[   16.871534] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
[   16.877576] brcmfmac: brcmf_bus_started: failed: -110
[   16.928040] brcmfmac: brcmf_attach: dongle is not responding:
err=-110
[   16.972120] brcmfmac: brcmf_sdio_firmware_callback: brcmf_attach
failed

A powercycle doesn't help in my case. Reports of similar issues mention
a firmware problem. This is what's currently installed on it:

ii  firmware-brcm80211  20190114-1   all
Binary firmware for Broadcom/Cypress 802.11 wireless cards

ii  linux-image-4.19.0-2-armmp-lpae 4.19.16-1armhf
Linux 4.19 for ARMv7 multiplatform compatible SoCs supporting LPAE

Kind regards,
Axel

Bug#922907: Updating the openmx Uploaders list

[Tobias Frost]

Source: openmx
Version: 3.8.5+dfsg1-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Innocent De Marchi  can unfortunatly no longer 
maintain openmx.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.