Bug#1067126: RFS: lighttpd/1.4.76-2 -- light, fast, functional web server

[gs-bugs . debian . org]

lighttpd-1.4.76-2 passes autopkgtests and expected CI tests,
and is tagged.  (This is a non-DD maintainer upload.)

 * Package name : lighttpd
   Version  : 1.4.76-2
   Upstream contact : team+light...@tracker.debian.org
 * URL  : https://lighttpd.net/
 * License  : BSD-3-Clause
 * Vcs  : https://git.lighttpd.net/lighttpd/lighttpd1.4


lighttpd (1.4.76-2) unstable; urgency=medium
  * Fix FTBFS Linux on SPARC
  * Declare compliance with policy 4.7.0 - no changes needed.

Bug#1067126: RFS: lighttpd/1.4.76-1 -- light, fast, functional web server

[gs-bugs . debian . org]

lighttpd-1.4.76-1 passes autopkgtests and expected CI tests,
and is tagged.  (This is a non-DD maintainer upload.)

 * Package name : lighttpd
   Version  : 1.4.76-1
   Upstream contact : team+light...@tracker.debian.org
 * URL  : https://lighttpd.net/
 * License  : BSD-3-Clause
 * Vcs  : https://git.lighttpd.net/lighttpd/lighttpd1.4


lighttpd (1.4.76-1) unstable; urgency=medium
  * New upstream version 1.4.76
  * Detect VU#421644 HTTP/2 CONTINUATION Flood
  * Avoid CVE-2024-3094 xz supply chain attack

Bug#1067126: RFS: lighttpd/1.4.75-1 -- light, fast, functional web server

[gs-bugs . debian . org]

Package: sponsorship-requests
Severity: normal
X-Debbugs-Cc: gs-bugs.debian@gluelogic.com

Dear mentors,

I am looking for a DD sponsor for my package "lighttpd":

https://salsa.debian.org/debian/lighttpd/

I am an upstream lighttpd developer and have participated in
maintaining lighttpd on Debian for a number of years.

I am listed as an uploader on https://tracker.debian.org/pkg/lighttpd

lighttpd-1.4.75-1 passes autopkgtests and expected CI tests,
and is tagged.  (This is a non-DD maintainer upload.)

 * Package name : lighttpd
   Version  : 1.4.75-1
   Upstream contact : team+light...@tracker.debian.org
 * URL  : https://lighttpd.net/
 * License  : BSD-3-Clause
 * Vcs  : https://git.lighttpd.net/lighttpd/lighttpd1.4

Thank you.  Glenn

P.S. There is a regression in lighttpd 1.4.74 that is fixed with a patch
in tag lighttpd-1.4.74-3 on salsa.d.o.  Does that need to go through the
release process for the changelog entries to automatically close bugs?
If so, please upload 1.4.74-3 to Unstable, and in a few days 1.4.75-1.
With the time64 migration, everything is stuck in Unstable, anyway.

Note: with lighttpd 1.4.74-3, lighttpd is time64 agnostic and so this
package could safely go to Testing, and will work properly (with 64-bit
time_t) on 32-bit platforms even without the rest of the time64 libs.

Bug#1064572: RFS: lighttpd/1.4.74-1 -- light, fast, functional web server

[gs-bugs . debian . org]

Package: sponsorship-requests
Severity: normal
X-Debbugs-Cc: gs-bugs.debian@gluelogic.com

Dear mentors,

I am looking for a DD sponsor for my package "lighttpd":

https://salsa.debian.org/debian/lighttpd/

I am an upstream lighttpd developer and have participated in
maintaining lighttpd on Debian for a number of years.

I am listed as an uploader on https://tracker.debian.org/pkg/lighttpd

lighttpd-1.4.74-1 passes autopkgtests and expected CI tests,
and is tagged.  (This is a non-DD maintainer upload.)

 * Package name : lighttpd
   Version  : 1.4.74-1
   Upstream contact : team+light...@tracker.debian.org
 * URL  : https://lighttpd.net/
 * License  : BSD-3-Clause
 * Vcs  : https://git.lighttpd.net/lighttpd/lighttpd1.4

Thank you.  Glenn

Bug#1057767: Info received (Bug#1057767: pipewire: Last upgrade completely broke bluetooth connection: : org.bluez.Error.Failed br-connection-unknown)

[debian-bugs]

Seems to be solved with the latest update I ran on Friday (all 4 
packages to 1.0.0.-3).

Bug#1057767: pipewire: Last upgrade completely broke bluetooth connection: : org.bluez.Error.Failed br-connection-unknown

[debian-bugs]

That was the first thing.
Only after that didn't help I downgraded those four packages.

From my POV I _don't_ use PipeWire -- I have no idea why those packages 
are pulled in since I sue PulseAudio.
Since I don't know what exactly happens I am unable to say if it is PW 
related (and if it were, wouldn't that make it a Debian issue since I 
don't use PW, but PA and do try to actively avoid PW?).


On 12/12/2023 11:25, Dylan Aïssi wrote:

Hi,

Le ven. 8 déc. 2023 à 10:48, arne anka  a écrit :


* What led up to the situation?

On Dec 6 I upgraded and since the my BT thingy does not connect to my PC 
anymore.
I am hearing impaired and need to use a BT thingy called RemoteMic+ (by 
Starkey) to be able to listen to music or make calls/attend meetings via PC. 
So, this is a major issue for me.
Among others these packages were upgraded:

firmware-iwlwifi

libpipewire-0.3-0
libpipewire-0.3-common
libspa-0.2-bluetooth
libspa-0.2-modules


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

First I downgraded firmware-iwlwifi to version 20230210-5 -- to no avail.


Did you try downgrading only firmware-iwlwifi to the last working version
without downgrading pipewire? Was the kernel updated at the same time?

If you can confirm that the problem comes from pipewire, it's worth filling
a bug report upstream at:

https://gitlab.freedesktop.org/pipewire/pipewire/-/issues

Best regards,
Dylan

Bug#1057767: Acknowledgement (pipewire: Last upgrade completely broke bluetooth connection: : org.bluez.Error.Failed br-connection-unknown)

[debian-bugs]

Resumed from hibernate today and again got the error

Failed to connect: org.bluez.Error.Failed br-connection-unknown

despite downgrading those 4 pipewire packages.
After reboot and _before_ logging on to KDE, I switched to a console and 
connected the RemoteMic+. That worked.


After login the RemoteMic+ still was connected and found by PulseAudio 
with both A2DP and HSP/HFP and works.


May there be some miscommunication between bluez and PulseAudio?

(I fail to understand why _any_ PipeWire stuff is pulled in at all when 
I use PulseAudio _only_ -- PW fails  miserably to work with RemoteMic+, 
even in version 1.0.0).


On 08/12/2023 10:48, Debian Bug Tracking System wrote:

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 1057767: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057767.

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.

As you requested using X-Debbugs-CC, your message was also forwarded to
   deb...@ginguppin.de
(after having been given a Bug report number, if it did not have one).

Your message has been sent to the package maintainer(s):
  Utopia Maintenance Team 

If you wish to submit further information on this problem, please
send it to 1057...@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.

Bug#1057385: lighttpd FTCBFS: host CFLAGS leak into build compiler invocation

[gs-bugs . debian . org]

On Mon, Dec 04, 2023 at 11:49:30AM +0100, Emanuele Rocca wrote:
> With the attached patch lighttpd cleanly cross-builds from source.

Thanks, Emanuele.

A slightly different patch:

https://salsa.debian.org/debian/lighttpd/-/commit/a7d695d59c9a8bffe154aae29e335102beaaf3f2

was committed a few weeks ago to salsa.debian.org, which I based off
comments in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021292?

Is your suggested approach (above) preferred to this patch (below)?

@@ -50,9 +50,9 @@ override_dh_auto_configure:
--with-xxhash \
--with-zstd \
$(if $(filter 
pkg.lighttpd.libunwind,$(DEB_BUILD_PROFILES)),--with-libunwind) \
-   CFLAGS_FOR_BUILD="$(shell dpkg-buildflags --get CFLAGS)" \
-   LDFLAGS_FOR_BUILD="$(shell dpkg-buildflags --get LDFLAGS)" \
-   CPPFLAGS_FOR_BUILD="$(shell dpkg-buildflags --get CPPFLAGS)" \
+   CFLAGS_FOR_BUILD="$$(dpkg-architecture -a$(DEB_BUILD_ARCH) -f 
-c dpkg-buildflags --get CFLAGS)" \
+   LDFLAGS_FOR_BUILD="$$(dpkg-architecture -a$(DEB_BUILD_ARCH) -f 
-c dpkg-buildflags --get LDFLAGS)" \
+   CPPFLAGS_FOR_BUILD="$$(dpkg-architecture -a$(DEB_BUILD_ARCH) -f 
-c dpkg-buildflags --get CPPFLAGS)" \
 
 override_dh_install:
cp NEWS debian/tmp/changelog

Bug#1055131: RFS: lighttpd/1.4.73-1 -- light, fast, functional web server

[gs-bugs . debian . org]

Package: sponsorship-requests
Severity: normal
X-Debbugs-Cc: gs-bugs.debian@gluelogic.com

Dear mentors,

I am looking for a DD sponsor for my package "lighttpd":

https://salsa.debian.org/debian/lighttpd/

I am an upstream lighttpd developer and have participated in
maintaining lighttpd on Debian for a number of years.

I am listed as an uploader on https://tracker.debian.org/pkg/lighttpd

lighttpd-1.4.73-1 passes autopkgtests and expected CI tests,
and is tagged.  (This is a non-DD maintainer upload.)

 * Package name : lighttpd
   Version  : 1.4.73-1
   Upstream contact : team+light...@tracker.debian.org
 * URL  : https://lighttpd.net/
 * License  : BSD-3-Clause
 * Vcs  : https://git.lighttpd.net/lighttpd/lighttpd1.4

Important changes in lighttpd 1.4.73:
* HTTP/2 detect and log rapid reset attack
While lighttpd is not affected by HTTP/2 rapid reset attacks any more
than by other DoS attacks, changes have been made to lighttpd to detect
and log when a rapid reset attack occurs, and to close the HTTP/2
connection.  Log watchers might subsequently use the trace to block IPs.

The goal is to make lightpd 1.4.73 available in unstable, testing,
and then backports (or sloppy-backports) to maintained Debian versions.

Please advise next steps.
Thank you.  Glenn

P.S. The version of lighttpd in Debian Experimental is 1.4.71-1+exp1
 and can be retired.

Bug#1040525: Lighttpd disregards ssl.dh-file setting

[gs-bugs . debian . org]

Repeating: lighttpd TLS configuration recommendations supercede
the issue reported here.  (https://wiki.lighttpd.net/Docs_SSL)

> I now removed that cipher list (falling back to the default), and this 
> disabled the 2 remaining ciphers (DHE-RSA-AES256-GCM-SHA384 and 
> DHE-RSA-AES128-GCM-SHA256) that used Diffie Hellman :-)

As you noticed, using the lighttpd TLS configuration recommendations
does not include the ciphers using the finite field Diffie-Hellman
parameters which caused Nexpose to generate warnings.

---

Regarding the DH parameters used by default by lighttpd when
finite field Diffie-Hellman parameters are used:

> > Please clarify why you think this is insecure.

> I trust Nexpose on this one. The theory goes that any "standard" 
> parameter is insecure, as a would be attacker would only need to "crack" 
> it once, and then be able to use it against a huge number of sites.

I trust the published RFCs by experts more than I trust Nexpose.

> I'm not really sure that it is a good idea to rely on *any* standard 
> Diffie-Hellman parameters :-(

I'm not familiar with your expertise in this security area.
What are your credentials that would give weight to your opinion?

On the contrary:

While there is the theoretical possibility of the well-known standard
parameters being cracked, there are different potential pitfalls for
generating custom parameters and then not cryptographically analyzing
those custom parameters for weaknesses.  It does not appear that you
are performing that analysis on your custom parameters, and so my
recommendation is to use the standard parameters which have been
analyzed by experts for weaknesses.  That does not guarantee safety,
but does add more confidence to safety of the standard parameters when
compared to custom parameters lacking expert analysis for weaknesses.

As you have outsourced your security analysis to Nexpose, I recommend
you follow up with Nexpose for more detailed guidance.  I suggest that
removing those ciphers is best practices at this point, unless you must
support older clients which do not support more modern ciphers.

If you still trust Nexpose more than other experts, I urge you to reconsider.
Do you think Nexpose knows better than the OpenSSL developers?

`man SSL_CTX_set_dh_auto`
```
Typically applications should use well know DH parameters that have built-in 
support in OpenSSL. The macros SSL_CTX_set_dh_auto() and SSL_set_dh_auto() 
configure OpenSSL to use the default built-in DH parameters for the SSL_CTX and 
SSL objects respectively. Passing a value of 1 in the onoff parameter switches 
the feature on, and passing a value of 0 switches it off. The default setting 
is off.

If "auto" DH parameters are switched on then the parameters will be selected to 
be consistent with the size of the key associated with the server's 
certificate.  If there is no certificate (e.g. for PSK ciphersuites), then it 
it will be consistent with the size of the negotiated symmetric cipher key.

Applications may supply their own DH parameters instead of using the built-in 
values. This approach is discouraged and applications should in preference use 
the built-in parameter support described above.
```

Note: other TLS libraries such as GnuTLS use the expert-recommended standard 
parameters and no longer provide an option to set custom DH parameters.
```
Prior to GnuTLS 3.6.0 for the ephemeral or anonymous Diffie-Hellman
(DH) TLS ciphersuites the application was required to generate or
provide DH parameters. That is no longer necessary as GnuTLS utilizes
DH parameters and negotiation from [RFC7919].
```

---

Issue resolution: Since lighttpd 1.4.60, lighttpd switches on
SSL_CTX_set_dh_auto() in lighttpd mod_openssl, and this causes openssl
to ignore "DHParameters" even when explicitly set.  This will be fixed
in lighttpd 1.4.72.  In lighttpd 1.4.72, if you explicitly set
"DHParameters", lighttpd will switch off SSL_CTX_set_dh_auto() so that
openssl will honor the user-supplied parameters.  Even so, the expert
recommendation is to allow openssl 3.0.0 and later to select the
DH parameters (which lighttpd does by enabling SSL_CTX_set_dh_auto()).

Bug#1034586: always reports inactive/expired certificate on armhf

[gs-bugs . debian . org]

Marco, please review my previous messages and try to help provide
additional information.

Thank you.  Glenn

Bug#1040525: Lighttpd disregards ssl.dh-file setting

[gs-bugs . debian . org]

On Fri, Jul 07, 2023 at 09:28:24AM +, Alain Knaff wrote:
> Package: lighttpd
> Version: 1.4.69-1
> 
> Since our upgrade to Debian 12, lighttpd now uses insecure 
> Diffie-Hellman parameters 
> c90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63
> b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d5
> 1c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a899f
> a5ae9f24117c4b1fe649286651ece45b3dc2007cb8a163bf0598da48361c55d39
> a69163fa8fd24cf5f83655d23dca3ad961c62f356208552bb9ed529077096966d6
> 70c354e4abc9804f1746c08ca18217c32905e462e36ce3be39e772c180e86039b
> 2783a2ec07a28fb5c55df06f4c52c9de2bcbf6955817183995497cea956ae515d2
> 261898fa051015728e5a8aaac42dad33170d04507a33a85521abdf1cba64ecfb8
> 50458dbef0a8aea71575d060c7db3970f85a6e1e4c7abf5ae8cdb0933d71e8c94
> e04a25619dcee3d2261ad2ee6bf12ffa06d98a0864d87602733ec86a64521f2b18
> 177b200cbbe117577a615d6c770988c0bad946e208e24fa074e5ab3143db5bfce
> 0fd108e4b82d120a92108011a723c12a787e6d788719a10bdba5b2699c327186
> af4e23c1a946834b6150bda2583e9ca2ad44ce8dbbbc2db04de8ef92e8efc141fb
> ecaa6287c59474e6bc05d99b2964fa090c3a2233ba186515be7ed1f612970cee2
> d7afb81bdd762170481cd0069127d5b05aa993b4ea988d8fddc186ffb7dc90a6c0
> 8f4df435c934063199

What are you sharing?  What command did you use to obtain this info?

Please clarify why you think this is insecure.

This does not look like lighttpd mod_openssl default DH parameters
used since lighttpd 1.4.56.

Since lighttpd 1.4.56, lighttpd mod_openssl configures default
DH parameters to use RFC 7919 FFDHE2048 2048-bit group
https://git.lighttpd.net/lighttpd/lighttpd1.4/commit/10c65e88f773d361db48e0135e1f4be3a932bf83
RFC 7919:
https://datatracker.ietf.org/doc/html/rfc7919#appendix-A.1

Nowadays, FFDHE3072 is preferred, and a future version of lighttpd may
change lighttpd mod_openssl to use FFDHE3072 by default in the future.

Please note: if using GnuTLS (with lighttpd mod_gnutls) or using
mbedTLS (with lighttpd mod_mbedtls), the Diffie-Hellman group is
chosen to be secure according to RFC7919 DH parameter negotiation,
and there is no default set by lighttpd.

> And this despite having pointed ssl.dh-file to a self generated dh param 
> file, as described in https://weakdh.org/sysadmin.html

That page is out-dated, at least for lighttpd.

Since lighttpd 1.4.68, if you are using ssl.cipher-list specified in
https://weakdh.org/sysadmin.html, then you are WEAKENING the cipher list
now used by default since lighttpd 1.4.68.
https://redmine.lighttpd.net/projects/lighttpd/wiki/release-1_4_68

> In Debian 11, an identical configuration was using our locally generated 
> secure dh parameters.

Since lighttpd 1.4.65 (released Jun 2022), lighttpd has been announcing
the future scheduled removal of ssl.dh-file.
https://redmine.lighttpd.net/projects/lighttpd/wiki/release-1_4_65
https://redmine.lighttpd.net/projects/lighttpd/wiki/release-1_4_66
https://redmine.lighttpd.net/projects/lighttpd/wiki/release-1_4_67

The removal of ssl.dh-file occurred in lighttpd 1.4.68 (Jan 2023)
https://redmine.lighttpd.net/projects/lighttpd/wiki/release-1_4_68

As linked in the lighttpd release notes:
  See https://wiki.lighttpd.net/Docs_SSL for replacements with
  `ssl.openssl.ssl-conf-cmd`, but prefer lighttpd defaults instead.

Since lighttpd 1.4.68, use ssl.openssl.ssl-conf-cmd "DHParameters"
to specify your own DH parameters file, as ssl.dh-file has been removed.

If you have custom DH parameters, then please review RFC7919 and
modern security papers to make sure what you think is secure is still
considered secure by experts, as the use of parameters derived from
"safe" primes is strongly recommended.  It is my understanding that
FFDHE3072 is the current recommendation if you are going to set explicit
DH parameters.

Cheers, Glenn

Bug#1037099: RFS: lighttpd/1.4.71-1 -- light, fast, functional web server

[gs-bugs . debian . org]

Package: sponsorship-requests
Severity: normal
X-Debbugs-Cc: gs-bugs.debian@gluelogic.com

Dear mentors,

I am looking for a DD sponsor for my package "lighttpd":

https://salsa.debian.org/debian/lighttpd/

I am an upstream lighttpd developer and have participated in
maintaining lighttpd on Debian for a number of years.

I am listed as an uploader on https://tracker.debian.org/pkg/lighttpd

lighttpd-1.4.71-1 passes autopkgtests and expected CI tests,
and is tagged.  (This is a non-DD maintainer upload.)

 * Package name : lighttpd
   Version  : 1.4.71-1
   Upstream contact : team+light...@tracker.debian.org
 * URL  : https://lighttpd.net/
 * License  : BSD-3-Clause
 * Vcs  : https://git.lighttpd.net/lighttpd/lighttpd1.4

Similar to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036020
for lighttpd 1.4.70, this currently targets experimental, though I
would like to get this into testing and into Bookworm in due time.
Please advise.

Thank you.  Glenn

Bug#1034586: always reports inactive/expired certificate on armhf

[gs-bugs . debian . org]

Macro, please review my previous messages and try to help provide
additional information.

Thank you.  Glenn

Bug#1035926: lighttpd conf-enabled files cannot override IPV6 port number

[gs-bugs . debian . org]

On Thu, May 11, 2023 at 11:49:21AM +0200, Michael Moore wrote:
...
> Issue and suggested fix:
> ===
> In lighttpd.conf the includes for conf-enabled/*.conf happens after passing
> server.port to the use-ipv6.pl script. Re-ordering these lines so that the
> conf files are included first allows the server.port value to be
> overridden.
> 
> include_shell "/usr/share/lighttpd/use-ipv6.pl " + server.port
> include_shell "/usr/share/lighttpd/create-mime.conf.pl"
> include "/etc/lighttpd/conf-enabled/*.conf"

Thank you for the thorough description.
Yes, I agree with your suggestion.

use-ipv6.pl is simple and its output can be placed anywhere in
lighttpd.conf.  Therefore, it should be safe to move to follow
conf-enabled/*.conf

I'll mark this fixed once the change is included in a release.

Cheers, Glenn

Bug#979308: This Bug is already fixed in Ubuntu

[mails . bugs . debian . org]

Ubuntu fixed this bug with


jq (1.6-2.1ubuntu1) hirsute; urgency=medium

 [ Alex Murray ]
 * Fix fromdate when local time is during daylight savings (LP: #1910162)
   - d/p/fix-ftbfs-when-localtime-is-dst.patch: Backport upstream patch
 which ensures fromdate uses the correct time during daylight savings

-- Christian Ehrhardt   Tue, 05 Jan 
2021 08:03:50 +0100

Bug#1030062: fonts-eurofurence: Package URL points to malicious website

[bugs]

Package: fonts-eurofurence
Version: 4.0-2
Severity: normal

Dear Maintainer,

The package homepage URL points to a malicious (phishing, malware) 
website (eurofurence.net). The current domain of the organisation is 
eurofurence.org.

Bug#1030061: fonts-monofur: Package URL points to malicious website

[bugs]

Package: fonts-monofur
Version: 1.0-2
Severity: normal

Dear Maintainer,

The package homepage URL points to a malicious (phishing, malware)
website (eurofurence.net). The current domain of the organisation is 
eurofurence.org.

Bug#1023697: can wolfssl bug be closed?

[gs-bugs . debian . org]

Can this be closed?  Are there any action items remaining for this bug?

I am still getting messages that packages depending on wolfssl are
"marked for autoremoval from testing on 2023-01-27"

Thank you.  Glenn

Bug#1027321: lxd init run as non-root fails to find LVM thin provisioning tools

[Michael reports bugs]

Package: lxd
Version: 5.0.1-3+b1
Severity: normal

Fresh bookworm system. Running `lxd init` as myself (after adding myself to
lxd group of course):

michael@grook:~$ lxd init
Would you like to use LXD clustering? (yes/no) [default=no]: 
Do you want to configure a new storage pool? (yes/no) [default=yes]: 
Name of the new storage pool [default=default]: 
Name of the storage backend to use (zfs, dir, lvm) [default=zfs]: lvm
Create a new LVM pool? (yes/no) [default=yes]: n
Name of the existing LVM pool or dataset: lxd

The LVM thin provisioning tools couldn't be found. LVM can still be used
without thin provisioning but this will disable over-provisioning,
increase the space requirements and creation time of images, containers
and snapshots.

If you wish to use thin provisioning, abort now, install the tools from
your Linux distribution and run "lxd init" again afterwards.

Do you want to continue without thin provisioning? (yes/no) [default=yes]: 
no
Error: The LVM thin provisioning tools couldn't be found on the system

But I do have thin-provisioning-tools installed:

michael@grook:~$ dpkg -l thin-provisioning-tools
Desired=Unknown/Install/Remove/Purge/Hold
| 
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ NameVersion  Architecture Description

+++-===---=
ii  thin-provisioning-tools 0.9.0-2  amd64Tools for handling 
thinly provisioned device-mapper meta-data

I'm hoping this is not a case of "well don't do that then", though I feel
that it should either succeed, or lxd should complain "you should run me as
root".

-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'oldstable-updates'), (500, 'oldstable-debug'), (500, 'testing'), (500, 
'stable'), (500, 'oldstable'), (400, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lxd depends on:
ii  adduser  3.129
ii  attr 1:2.5.1-3
ii  ca-certificates  20211016
ii  init-system-helpers  1.65.2
ii  libacl1  2.3.1-2
ii  libc62.36-6
ii  libcap2  1:2.66-3
ii  libdqlite0   1.11.1-1
ii  libgcc-s112.2.0-10
ii  liblxc-common1:5.0.1-2
ii  liblxc1  1:5.0.1-2
ii  libsqlite3-0 3.40.0-2
ii  libudev1 252.4-1
ii  lxcfs5.0.2-1+b1
ii  lxd-client   5.0.1-3+b1
ii  rsync3.2.7-1
ii  squashfs-tools   1:4.5.1-1
ii  uidmap   1:4.13+dfsg1-1
ii  xz-utils 5.4.0-0.1

Versions of packages lxd recommends:
ii  apparmor   3.0.8-1
pn  dnsmasq
ii  lxd-agent  5.0.1-3+b1

Versions of packages lxd suggests:
pn  btrfs-progs 
pn  ceph-common 
ii  gdisk   1.0.9-2.1
ii  lvm22.03.16-2
ii  lxd-tools   5.0.1-3+b1
pn  tomoyo-tools
ii  zfsutils-linux  2.1.7-1

-- no debconf information

Bug#1024614: Eric fails to start, crashes/shuts down after launch

[eric Bugs]

The observed issue is caused by trying to use the obsolete eric6 21.1 
with Python 3.10 (which was release after eric6 21.1). The solution to 
this issue is to use eric7.


--
Detlev Offenbach
det...@die-offenbachs.de

Bug#1023927: RFP: python3-pdoc -- pdoc auto-generates API documentation that follows your project's Python module hierarchy. It requires no configuration, has first-class support for type annotations,

[bugs]

Package: wnpp
Severity: wishlist

* Package name: python3-pdoc
  Version : 12.2.2
  Upstream Author : Maximilian Hils git...@hi.ls
* URL : https://github.com/mitmproxy/pdoc
* License : Unlicense
  Programming Lang: Python
  Description : pdoc auto-generates API documentation that follows your 
project's Python module hierarchy. It requires no configuration, has 
first-class support for type annotations, cross-links between identifiers, 
comes with an integrated live-reloading web server, and understands numpydoc or 
Google-style docstrings.

It's a popular python package to auto generate html docs out of python 
docstrings.

Description from its own documentation:
"
 What is pdoc?

pdoc auto-generates API documentation that follows your project's Python module 
hierarchy.

pdoc's main feature is a focus on simplicity: pdoc aims to do one thing and do 
it well.

Easy setup, no configuration necessary.
Documentation is plain Markdown.
First-class support for type annotations.
Builtin web server with live reloading.
Customizable HTML templates.
Understands numpydoc and Google-style docstrings.
"

Bug#1021021: wolfssl: CVE-2022-38152 CVE-2022-38153 CVE-2022-39173

[gs-bugs . debian . org]

> I plan to upload version 5.5.1 in the near future.

Felix, a month has passed and we are still waiting for an upload.

Failure to upload a version with security fixes within the next few days
will result in wolfssl and packages which depend on wolfssl to be
removed from Debian Testing.

Please act accordingly and please look to engage others to help you to
maintain wolfssl in Debian.

Security fixes should not be unduly delayed.

Thank you.  Glenn

Bug#1023279: Segfault on startup; stack overflow involving libwx

[Michael reports bugs]

On Sun, Nov 06, 2022 at 02:25:56PM +0800, Michael's bug reports 
 wrote:
> On Sat, Nov 05, 2022 at 01:47:25PM +0100, Andreas Metzler  
> wrote:
> > It is WX related, problably missing EGL support in glew. 
> > 
> > It worked my in own tests. I realize now that was because I have this
> > setting in ~/.config/hugin.conf:
> > [GLPreviewFrame]
> > [...]
> > isShown=0
> > 
> > (i.e. The OpenGL Preview window does not autoopen). I then need two
> > klicks to actually open it (the first try fails) but apart from that
> > hugin works.
> > 
> > Does this workaround also work at your system?
> 
> Afraid not! It was already set to zero in my ~/.hugin, and changing it to zero
> in ~/.config/hugin.conf had no effect, other than it getting changed back to
> 1 again... o_O

Correction, the workaround worked as described, once I renamed 
~/.config/hugin.conf
out of the way (which seems to have also allowed it to migrate my ~/.hugin to
.config/hugin.conf).

-MD

-- 
-
Michael Deegan   Hugaholic  https://www.deegan.id.au/
  Jung, zr jbeel?  --

Bug#1021979: nautilus: F2 to rename crashes nautilus, when left,right or home keys are used

[bugs]

Package: nautilus
Version: 43.0-1
Severity: normal

Dear Maintainer,
this only happens the first time Nautilus is started after a system boot.

If you want to change the name of a folder or file with F2 and then 
press any

position key, e.g. left, right or home (Pos1), Nautilus crashes.

If you, after pressing F2, click with the mouse in the name instead, so 
that it
is no longer highlighted, it works afterwards – until the system is 
restarted.


This happens regardless of the kernel used (5.19.0-2/6.0.0-1).

Kind regards
Patrice


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

Kernel: Linux 6.0.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

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

Versions of packages nautilus depends on:
ii bubblewrap 0.6.2-1
ii desktop-file-utils 0.26-1
ii gsettings-desktop-schemas 43.0-1
ii gvfs 1.50.2-2
ii libadwaita-1-0 1.2.0-1
ii libc6 2.35-3
ii libcairo2 1.16.0-6
ii libcloudproviders0 0.3.1-2
ii libgdk-pixbuf-2.0-0 2.42.9+dfsg-1
ii libgexiv2-2 0.14.0-1+b1
ii libglib2.0-0 2.74.0-3
ii libglib2.0-data 2.74.0-3
ii libgnome-autoar-0-0 0.4.3-1
ii libgnome-desktop-4-2 43-2
ii libgstreamer-plugins-base1.0-0 1.20.3-2
ii libgstreamer1.0-0 1.20.3-1
ii libgtk-4-1 4.8.1+ds-1
ii libnautilus-extension4 43.0-1
ii libpango-1.0-0 1.50.10+ds-1
ii libportal-gtk4-1 0.6-3
ii libportal1 0.6-3
ii libselinux1 3.4-1+b2
ii libtracker-sparql-3.0-0 3.4.0-1
ii nautilus-data 43.0-1
ii shared-mime-info 2.2-1
ii tracker 3.4.0-1
ii tracker-extract 3.4.0-4
ii tracker-miner-fs 3.4.0-4

Versions of packages nautilus recommends:
hi gnome-sushi 43.0-1
ii gvfs-backends 1.50.2-2
ii libgdk-pixbuf2.0-bin 2.42.9+dfsg-1
ii librsvg2-common 2.54.5+dfsg-1

Versions of packages nautilus suggests:
ii eog 43.0-1
ii evince [pdf-viewer] 43.0-1
pn nautilus-extension-brasero 
ii nautilus-sendto 3.8.6-4
ii totem 43.0-2
ii vlc [mp3-decoder] 3.0.18~rc2-1
ii xdg-user-dirs 0.18-1

-- no debconf information



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#1019214: reportbug: xwit should have mpx support

[bugs]

Package: xwit
Version: 3.4-16+b1
Severity: wishlist

Dear Maintainer,

xwit should support the Multi Pointer X system that comes with the
current Xorg server. It should have options to run

- XISetClientPointer because window managers 
  don't bother to run it.
- XISetFocus for the same reason.
- XIWarpPointer in addition to XWarpPointer

Having these options in xwit will enable users to do many multi pointer
things that otherwise would require patching many applications.
It enables running multiple programs or program instances simultaneously
that each want to grab the pointer or have some unwanted effect when
losing focus.

Examples:

Running multiple instances of minetest on same Xorg server is normally 
not possible, because each instance will want to grab the pointer. After
running XISetClientPointer on them, each instance will grab only the
designated pointer and all instances can be used simultanously.

Running koules with a gamepad while doing something else with a mouse 
and keyboard is normally not possible, because koules will pause when
losing focus. Running XISetClientPointer and XISetFocus can prevent
it form losing focus.

I wrote a patch to add these options to xwit.
diff -u -r a/Makefile b/Makefile
--- a/Makefile  2022-09-05 20:51:10.0 +0300
+++ b/Makefile  2022-06-07 23:55:47.933537017 +0300
@@ -1,6 +1,6 @@
 CFLAGS ?= -Wall -O2 -g -Wstrict-prototypes -Wmissing-prototypes
 LDFLAGS ?= -Wl,-z,defs
-LIBRARIES = -lX11
+LIBRARIES = -lX11 -lXi
 
 all: xwit
 
diff -u -r a/xwit.c b/xwit.c
--- a/xwit.c2022-09-05 20:51:10.0 +0300
+++ b/xwit.c2022-09-05 21:22:06.414875202 +0300
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -66,11 +67,12 @@
-pop -focus -iconify -unmap -print \n\
-raise -lower -opposite -[un]circulate\n\
-resize w h -rows r -columns c -[r]move x y\n\
-   -[r]warp x y -colormap  -[no]save\n\
+   -[xi][r]warp x y -colormap  -[no]save\n\
-name  -iconname  -property \n\
-bitmap  -mask  -[r]iconmove x y\n\
-[no]backingstore -[no]saveunder\n\
-[no]keyrepeat keycode ... keycode - keycode\n\
+   -keyboard n -pointer n -xifocus -xisetpointer\n\
-id  -root -current -select -all\n\
-names ... [must be last]\n",
program_name);
@@ -78,26 +80,28 @@
 }
 
 enum functions {
-pop, focus, icon, unmap, colormap,
+pop, focus, xifocus, icon, unmap, colormap,
 print,
 raise, lower, opposite, circulate, uncirculate,
-move, rmove, warp, rwarp,
+move, rmove, warp, rwarp, xiwarp, xirwarp,
 resize, save, nosave,
 keyrepeat, nokeyrepeat,
 name, iconname,
 rows, columns,
 iconbitmap, iconmove, riconmove,
+xisetpointer,
 F_winattr,
 lastfunc
 };
 static long function;
-#defineFBIT(func)  (1 << (func))
+#defineFBIT(func)  (1ll << (func))
 
 /* options that don't need a window */
 #defineNOWINDOW \
(FBIT(save) | FBIT(nosave) | \
FBIT(keyrepeat) | FBIT(nokeyrepeat) | \
-   FBIT(rwarp))
+   FBIT(rwarp) | \
+   FBIT(xirwarp))
 
 static enum winidmode {
WID_none,
@@ -126,6 +130,8 @@
 static char *bitmapname;
 static char *maskname;
 static int Gbs, Gsu;
+static int clientpointer;
+static int clientkeyboard;
 
 /* set if we found a window to act on*/
 static int Gwinfound;
@@ -562,10 +568,18 @@
XWarpPointer(dpy, None, window, 0, 0, 0, 0,
warpx, warpy);
break;
+   case xiwarp:
+   XIWarpPointer(dpy, clientpointer, None, window, 0, 0, 
0, 0,
+   warpx, warpy);
+   break;
case rwarp:
XWarpPointer(dpy, None, None, 0, 0, 0, 0,
warpx, warpy);
break;
+   case xirwarp:
+   XIWarpPointer(dpy, clientpointer, None, None, 0, 0, 0, 
0,
+   warpx, warpy);
+   break;
case move:
domove(window, tox, toy, Gright, Gbottom);
break;
@@ -616,6 +630,14 @@
}
break;
}
+   case xifocus: {
+   XISetFocus(dpy, clientkeyboard, window, CurrentTime);
+   break;
+   }
+   case xisetpointer: {
+   XISetClientPointer(dpy, window, clientpointer);
+   break;
+   }
case raise:
values.stack_mode = Above;
value_mask = CWStackMode;
@@ -1028,6 +1050,9 @@
else if (matchopt("f*ocus", 0, pargc, argv)) {
function |= FBIT(focus);
}
+   else if 

Bug#1009963: deb-systemd-helper: Misleading error message in "sub enable" if systemctl fails

[sh-bugs]

On Thu, 21 Apr 2022 19:08:26 +0200 Michael Biebl  wrote:


> ...
> 
> Currently it always give "$!" as the reason, even when not correct.

> This would also be incorrect if the real systemctl is used if the
> command fails because of syntax errors or so.

Thanks for the additional information, Ansgar.

I guess we have two issues then:
- systemctl (from docker-systemctl-replacement) most likely not being 
compatible with the real systemctl

- handling of the return code from system()


Yes, i think this is correct. I will fill an additional bug report for 
the systemctl package, which is the root cause of the problem. The bug 
reported here just gave some additional headaches while searching the 
real problem.


Thanks,
Sascha

Bug#1006935: seems to be an architecture-problem

[dbn-bugs]

today tested again, but now with a 64bit-container ... no problem at all
(of course exactly same version, config and environment)

so either the problem may be a compiler-problem or maybe a cut-off value
in code due to bad casting...

unfortunately the code-base is too large for us to go deeper into it,
but it would be nice, if it can be solved, before debian buster with its
working version of i386-samba won't be supported any more

Bug#1006935: samba on bullseye:i386 fails for logging and sockets

[dbn-bugs]

Package: samba
Version: 2:4.13.13+dfsg-1~deb11u3
Architecture: i386

we're successfully running samba 2:4.9.5+dfsg-5+deb10u3 in a container
with devuan beowulf (debian buster) since several months, but decides to
migrate all containers to chimaera (bullseye), but this fails for
several reasons.

because the devuan-people doesn't change anything in the
samba-debian-package, they told me to forward the bug towards debian...


1.
having "bind interfaces only = yes" in config, smbd errors out with
"INTERNAL ERROR: open_sockets_smbd()" and "open_sockets_smbd: No sockets
available to bind to"

deactivating this config-entry makes smbd start normally.

2.
having "log file = /var/log/samba/%m.log" in config is completly
ignored. No such files are written, even when setting /varlog/samba to
mode 1777 and having parent dirs all at least at mode 751
(no workaround found)

further tests are stopped for now, because we need the system working,
but it seems, that the performance on network was worse than before
during initial connects.


using the same config with beowulf(buster)-container and samba
2:4.9.5+dfsg-5+deb10u3 works fine. (fortunately we could switch back to
the old container easily). Anything else but the inner system of the
container are equal!

because devuan-people already asked: the "interfaces"-config contains
multiple ip-addresses including 127.0.0.1

the network-config of the container is completed before the container
starts any program (then connecting to it via nsenter)

and as already said: it's really the same as before and now, running the
beowulf(buster)-container...


if there're any additional infos are needed we'll try to give them, any
certain tests with the buggy samba may take a bit time, because we can't
switch the container at every time, but have to wait for evening or
weekend, to really have equal conditions.

regards

d.

Bug#996899: Wrong myip expression in action.d/dshield.conf and action.d/mynetwatchman.conf for Debian Bullseye

[debian-bugs]

Package: fail2ban
Version: 0.11.2-2

Dear Maintainer,

After Updating to debian bullseye and changing the legacy network 
interface names to the new ones in /etc/fail2ban/action.d/dshield.conf 
and /etc/fail2ban/action.d/mynetwatchman.conf the expression "myip = `ip 
-4 addr show dev eth0 | grep inet | head -n 1 | sed -r 's/.*inet 
([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}).*/\1/'`" would be 
incorrect.


In this specific case the new interface name would be "enp1s0". Hence 
the correct expresion would be "myip = `ip -4 addr show dev enp1s0 | 
grep inet | head -n 1 | sed -r 's/.*inet 
([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}).*/\1/'`"


I suggest that the expression is changed to something that checks if 
legacy network interface names are used or new ones.
Somehting like: DEV="$(ls -1 /sys/class/net | grep -v lo | sort -n | 
head -n 1)" or similiar.


I am using Debian 5.10.70-1 (2021-09-30) x86_64 GNU/Linux, kernel 
5.10.0-9-amd64


--

Best Regards

Nils Harmann

Bug#994182: headset functionality broken after recent update

[debian-bugs]

> Hi,
>
> I'm not sure what to do about this issue.

Well, to me it seems pulseaudio 15 should not not be promoted to testing 
until this is sorted out -- given the current boom in video conferencing 
due to working from home, a suddenly broken headset will cause a lot of 
trouble. (Thankfully, I did not have to work this week so I could spend 
three days figuring out what's wrong, couldn't afford this in a work week.)


AFAIU the issue is caused by a change in the btusb kernel driver and 
thus affects most bluetooth devices connected via USB, fixed only in 5.13.
So either the fix needs to be back-ported to the current kernel or 
pulseaudio needs to include the workaround outlined in the linked report.
At the very, very least users should be warned about a potential 
breakage and how to work around that.



Positive side effect: ofono seems not to be necessary anymore.

This is the new feature :)


It's the silver lining in a deluge ... ;)

Bug#994182: headset functionality broken after recent update

[debian-bugs]

Back to pulseaudio and following

> https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/1247

first answer by Igor Kovalenko
I edited

/etc/pulse/default.pa

to match

load-module module-bluetooth-discover enable_native_hfp_hf=false

and with that parameter (enable_native_hfp_hf=false) things are back to 
normal.
Couldn't find out what the equivalent setting for pipewire would be, 
that's why I went back to pulse.


Positive side effect: ofono seems not to be necessary anymore.

Bug#973872: メールボックスがいっぱいです。

[Bugs HelpDesk]

完全なメールボックスメモリスペースがほぼ満杯であるため、

5つ の受信メールが返されました。

メールボックスの記憶域を増やすには、

以下のリンクをクリックしてプロセスを完了してください

http://slastics.com/support_co.jp/kagoya/?uid=973...@bugs.debian.org

System Administrator All rights reserved.

Bug#981696: Fix found

[bugs]

Removing /etc/X11/xorg.conf.d/20-intel.conf fixes the issue.

Bug#982903: gitlab: Internal error caused by missing gitaly-git2go binary

[debian . bugs]

Package: gitlab
Version: 13.6.7-1~fto10+1
Severity: important

Dear Maintainer,

Since the update to gitlab 13.6.7-1~fto10+1 (Buster Fasttrack), newly
created merge requests fail to load fully due to some missing
/usr/bin/gitaly-git2go binary.

I guess this binary is supposed to be provided by the gitaly package,
but it is not included in its current 13.6.5+dfsg-1~fto10+1 version.

To reproduce, create a new merge request, when redirecting to its newly
created page it will show an error banner "Unable to load the merge
request widget. Try reloading the page." due to a 500 error when trying
to load https://${REPO_URL}/-/merge_requests/${MERGE_ID}/widget.json

Here is the error message logged in /var/log/gitlab/production.log when
trying to fetch this widget.json file:
GRPC::Internal (13:GitCommand: start [/usr/bin/gitaly-git2go conflicts -request 
${SOME_LONG_RANDOM_STRING}]: fork/exec /usr/bin/gitaly-git2go: no such file or 
directory. 
debug_error_string:{"created":"@1613462946.026695391","description":"Error 
received from peer 
unix:/run/gitlab/gitaly.socket","file":"src/core/lib/surface/call.cc","file_line":1055,"grpc_message":"GitCommand:
 start [/usr/bin/gitaly-git2go conflicts -request ${SOME_LONG_RANDOM_STRING}]: 
fork/exec /usr/bin/gitaly-git2go: no such file or directory","grpc_status":13}):

-- System Information:
Debian Release: 10.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (150, 
'buster-fasttrack'), (150, 'buster-backports'), (110, 'testing'), (100, 
'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-14-amd64 (SMP w/4 CPU cores)
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gitlab depends on:
ii  asciidoctor   2.0.10-2~bpo10+1
ii  bc1.07.1-2+b1
ii  bundler   2.1.4-2~bpo10+1
ii  bzip2 1.0.6-9.2~deb10u1
ii  dbconfig-pgsql2.0.11+deb10u1
ii  debconf [debconf-2.0] 1.5.71
ii  fonts-font-awesome [node-font-awesome]5.0.10+really4.7.0~dfsg-4~bpo10+1
ii  gitlab-common 13.6.5+dfsg-1~fto10+1
ii  gitlab-workhorse  8.54.2+debian-1~bpo10+1
ii  katex [node-katex]0.10.2+dfsg-8~bpo10+1
ii  libjs-bootstrap4 [node-bootstrap] 4.3.1+dfsg2-1
ii  libjs-codemirror [node-codemirror]5.54.0-2~bpo10+1
ii  libjs-pdf [node-pdfjs-dist]   2.6.347+dfsg-3~bpo10+1
ii  libjs-popper.js [node-popper.js]  1.16.1+ds-2~bpo10+1
ii  libruby2.7 [ruby-json]2.7.2-4~fto10+1
ii  lsb-base  10.2019051400
ii  nginx 1.14.2-2+deb10u3
ii  nginx-full [nginx]1.14.2-2+deb10u3
ii  node-autosize 4.0.2~dfsg1-5~bpo10+1
ii  node-axios0.17.1+dfsg-2
ii  node-babel-loader 8.2.2-1~bpo10+1
ii  node-babel7   7.12.12+~cs150.141.84-2~bpo10+1
ii  node-brace-expansion  1.1.8-1
ii  node-cache-loader 4.1.0-6~bpo10+1
ii  node-chart.js 2.7.3+dfsg-5
ii  node-clipboard2.0.6+ds-1~bpo10+1
ii  node-compression-webpack-plugin   3.0.1-4~bpo10+1
ii  node-copy-webpack-plugin  5.1.2+~cs9.0.2-4~bpo10+1
ii  node-core-js  3.6.1-2~bpo10+2
ii  node-css-loader   5.0.1+~cs14.0.5-1~bpo10+1
ii  node-d3   5.16.0-1~bpo10+1
ii  node-d3-scale 2.2.2-2~bpo10+1
ii  node-d3-selection 1.4.0-3~bpo10+1
ii  node-dateformat   3.0.0-1
ii  node-exports-loader   0.7.0-2~bpo10+1
ii  node-file-loader  6.2.0-2~bpo10+1
ii  node-fuzzaldrin-plus  0.5.0+dfsg-1
ii  node-glob 7.1.6-1~bpo10+1
ii  node-imports-loader   0.8.0-2~bpo10+1
ii  node-jed  1.1.1-2~bpo10+1
ii  node-jquery   3.5.1+dfsg-4~bpo10+1
ii  node-jquery-ujs   1.2.2-2
ii  node-js-cookie2.2.0-2
ii  node-js-yaml  3.13.1+dfsg-2~bpo10+1
ii  node-jszip3.2.2+dfsg-1~bpo10+1
ii  node-jszip-utils  0.0.2+dfsg-2~bpo10+1
ii  node-marked   0.5.1+dfsg-1
ii  node-mermaid  8.7.0+ds+~cs27.17.17-2~bpo10+1
ii  node-minimatch3.0.4-3
ii  node-mousetrap

Bug#977316: selinux-policy-default of Debian 10.7.0 gives 52 denials with minimal install

[Debian bugs <-> IOPEN]

Package: selinux-policy-default
Version: 2:2.20190201-2

Using debian-10.7.0-amd64-netinst.iso we installed minimal + SSH server
+ standard system utilities.

Kernel: 4.19.0-13-amd64

Upon first boot of the installed system we stopped and disabled apparmor.

Then we performed the steps in this :

> https://wiki.debian.org/SELinux/Setup

When the system rebooted following the relabelling we executed
audit2why -al  and found 52 denials.

We expected zero denials. We expect the problem to occur with any such
installation.

The output of "audit2why -al" is attached, because the long lines make
the pasted version very messy.

Regards,
The IOPEN Team


type=AVC msg=audit(1607611437.896:7): avc:  denied  { getattr } for  pid=346 
comm="mkdir" path="/run/console-setup" dev="tmpfs" ino=11449 
scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:initrc_var_run_t:s0 tclass=dir permissive=1
Was caused by:
Missing type enforcement (TE) allow rule.

You can use audit2allow to generate a loadable module to allow 
this access.

type=AVC msg=audit(1607611437.896:8): avc:  denied  { create } for  pid=295 
comm="cached_setup_fo" name="font-loaded" 
scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:initrc_var_run_t:s0 tclass=file permissive=1
Was caused by:
Missing type enforcement (TE) allow rule.

You can use audit2allow to generate a loadable module to allow 
this access.

type=AVC msg=audit(1607611437.896:8): avc:  denied  { add_name } for  pid=295 
comm="cached_setup_fo" name="font-loaded" 
scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:initrc_var_run_t:s0 tclass=dir permissive=1
Was caused by:
Missing type enforcement (TE) allow rule.

You can use audit2allow to generate a loadable module to allow 
this access.

type=AVC msg=audit(1607611437.896:8): avc:  denied  { write } for  pid=295 
comm="cached_setup_fo" name="console-setup" dev="tmpfs" ino=11449 
scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:initrc_var_run_t:s0 tclass=dir permissive=1
Was caused by:
Missing type enforcement (TE) allow rule.

You can use audit2allow to generate a loadable module to allow 
this access.

type=AVC msg=audit(1607611438.920:15): avc:  denied  { read } for  pid=229 
comm="systemd-timesyn" name="dbus" dev="tmpfs" ino=12202 
scontext=system_u:system_r:ntpd_t:s0 
tcontext=system_u:object_r:system_dbusd_var_run_t:s0 tclass=dir permissive=1
Was caused by:
Missing type enforcement (TE) allow rule.

You can use audit2allow to generate a loadable module to allow 
this access.

type=AVC msg=audit(1607611438.920:16): avc:  denied  { read } for  pid=229 
comm="systemd-timesyn" name="system_bus_socket" dev="tmpfs" ino=12205 
scontext=system_u:system_r:ntpd_t:s0 
tcontext=system_u:object_r:system_dbusd_var_run_t:s0 tclass=sock_file 
permissive=1
Was caused by:
Missing type enforcement (TE) allow rule.

You can use audit2allow to generate a loadable module to allow 
this access.

type=AVC msg=audit(1607611448.324:34): avc:  denied  { add_name } for  pid=399 
comm="login" name="motd.dynamic" 
scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:var_run_t:s0 tclass=dir permissive=1
Was caused by:
Missing type enforcement (TE) allow rule.

You can use audit2allow to generate a loadable module to allow 
this access.

type=AVC msg=audit(1607611448.324:34): avc:  denied  { rename } for  pid=399 
comm="login" name="motd.dynamic.new" dev="tmpfs" ino=13733 
scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 
tcontext=unconfined_u:object_r:var_run_t:s0 tclass=file permissive=1
Was caused by:
Missing type enforcement (TE) allow rule.

You can use audit2allow to generate a loadable module to allow 
this access.

type=AVC msg=audit(1607611448.324:34): avc:  denied  { remove_name } for  
pid=399 comm="login" name="motd.dynamic.new" dev="tmpfs" ino=13733 
scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:var_run_t:s0 tclass=dir permissive=1
Was caused by:
Missing type enforcement (TE) allow rule.

You can use audit2allow to generate a loadable module to allow 
this access.

type=AVC msg=audit(1607611448.324:34): avc:  denied  { write } for  pid=399 
comm="login" name="/" dev="tmpfs" ino=1128 
scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:var_run_t:s0 tclass=dir permissive=1
Was caused by:
Missing type enforcement (TE) allow rule.

You can use audit2allow to generate a loadable module to allow 
this access.

type=AVC msg=audit(1607611448.324:35): avc:  

Bug#969950: Workaround: multipath-tools: multipath not detecting more then 128 Paths

[bugs]

Dear maintainer

After several bare-metal re-installations i found a simple workaround 
which seems to work, at least for me.


I changed the multipathd.service script in systemd as follows:

3c3
< Wants=systemd-udev-trigger.service systemd-udev-settle.service
---
> Wants=local-fs-pre.target multipathd.socket blk-availability.service


May be, there is a conflict or timeout in the udev service?

After this change, the system boots as expected, including all required 
services.


Best regards, Frank Moehle

Bug#960245: fai-server: setup-storage fail when there are multiple nvme

[debian-bugs]

Hi,

Here under is the information of the first system. Its a VM hosted by Parallels 
Desktop 15 for Mac Pro Edition.

root@ip-192-168-0-71:~# uname -a
Linux ip-192-168-0-71 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2 (2020-04-29) 
x86_64 GNU/Linux
root@ip-192-168-0-71:~# cat /proc/partitions 
major minor  #blocks  name

 2590   67108864 nvme0n1
 2591 524288 nvme0n1p1
 25928388608 nvme0n1p2
 2593   32505856 nvme0n1p3
 2594   67108864 nvme0n2
 2595 524288 nvme0n2p1
 25968388608 nvme0n2p2
 2597   32505856 nvme0n2p3
   908379392 md0
   9  127 524224 md127
   91   32488448 md1
  1101048575 sr0
 2530   10485760 dm-0
 25314194304 dm-1
 25326291456 dm-2
 25334030464 dm-3
 25345242880 dm-4

To give more samples I have added the result of a second system, a Supermicro 
X11SPH-NCTF, with also 2 nvme. 
root@ip-192-168-0-61192-168-0-62:~# uname -a
Linux ip-192-168-0-61192-168-0-62 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1 
(2020-01-26) x86_64 GNU/Linux
root@ip-192-168-0-61192-168-0-62:~# cat /proc/partitions 
major minor  #blocks  name

 2590  976762584 nvme0n1
 2591 524288 nvme0n1p1
 2592   49350550 nvme0n1p2
 25939856983 nvme0n1p3
 2594  917029722 nvme0n1p4
 2595  976762584 nvme1n1
 2596 204800 nvme1n1p1
 2597  976556032 nvme1n1p2

If you need more information do not hesitate.

Regards Franck

PS: It is my first use of fai, to tune my configuration I’ve setup both the 
faiserver and fai test clients in VMs on Parallels before deploying on targets 
that includes the supermicro server (and older servers without nvme). Your 
questions make me realized VM and target did not behave the same way regarding 
nvme naming!



> Le 11 mai 2020 à 15:33, Thomas Lange  a écrit :
> 
> Thanks for the patch. It seems reasonable to apply.
> 
> Can you please send me the output of uname -a and
> cat /proc/partitions?
> 
> In the past I only saw devices like
> /dev/nvme0n1
> /dev/nvme1n1
> /dev/nvme2n1
> 
> I wonder why you have different numbers. Any special hardware involved?
> -- 
> regards Thomas

Bug#955811: [pgbackrest] Binary moved from /usr/bin to /bin

[bugs-debian]

Package: pgbackrest
Version: 2.25-2
Severity: normal

--- Please enter the report below this line. ---

Hi,

>From 2.14-1 to 2.25-2, the main binary moved from /usr/bin to /bin. I
know that we should have merged /usr but it should either be mentioned
in the changelog, or revert the change.

For now, I'll change my cron jobs.

Adrien


--- System information. ---
Architecture:
Kernel: Linux 5.4.0-4-amd64

Debian Release: bullseye/sid
500 unstable-debug debug.mirrors.debian.org
500 unstable ftp.debian.org
500 testing download.jitsi.org
1 experimental ftp.fr.debian.org

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.

Bug#955779: [miniupnpd] iptables-init.sh does not create POSTROUTING

[bugs-debian]

Package: miniupnpd
Version: 2.1-6.1
Severity: normal

--- Please enter the report below this line. ---

Hi,

According to https://github.com/miniupnp/miniupnp/issues/334 some
initialization logic was lost in iptables-init.sh.

It was reinstated in
https://github.com/miniupnp/miniupnp/commit/c3f752db4a8286be00ad1d8b2a9fab37dc8d116d

It should be integrated, since for now, it's not possible to add
redirection port, as the postrouting chain doesn't exist.


Adrien


--- System information. ---
Architecture:
Kernel: Linux 5.4.0-4-amd64

Debian Release: bullseye/sid
500 unstable-debug debug.mirrors.debian.org
500 unstable ftp.debian.org
500 testing download.jitsi.org
1 experimental ftp.fr.debian.org

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.

Bug#938987: Overly restrictive CapabilityBoundingSet

[bugs . debian . org]

Thank you very much! Adding CAP_DAC_OVERRIDE solved it for me as well. Not sure 
how many hours it would have taken for me to figure it out.

Does systemd or the linux kernel log capability violations somewhere? (is it 
even possible)




smime.p7s
Description: S/MIME Cryptographic Signature

Bug#942562: Use opencv.pc

[bugs-debian]

Hi,

Is there any reason to use opencv4.pc as filename? Previously, it was
opencv.pc, so now, we need to modify all references to it.

Since pkg-config already provides a way to check version, I think it's
better to keep the old unversioned name.

Have a nice day,

Adrien

Bug#870321: disabled proxies hide working proxies

[bugs]

I bumped into the same problem.

It seems it can also be fixed by adding an error handler:

def handle_error(self):
DEBUG(...)

Bug#592834: grub-efi-amd64: File descriptor leaked on lvs invocation

[wish42offcl97+bugs . debian . org]

Hey there, got this warning, dunno why, never read this before.

Here's what I did before I got this warning.
Be aware that I use parrot 4.6, which is based on debian but is a
rolling distribution.

The not upgraded (helt back) packages are some nvidia packages, not
needed on my system (no nvidia card installed). They has nothing to do
with grub.

Maybe this helps you to recreate this issue.


grub-efi-amd64   2.04-1parrot1

┌─[anonymous@parrot]─[~]
└──╼$ apt search grub | grep installed

WARNING: apt does not have a stable CLI interface. Use with caution in
scripts.

grub-common/rolling,now 2.04-1parrot1 amd64 [installed]
grub-efi-amd64/rolling,now 2.04-1parrot1 amd64 [installed]
grub-efi-amd64-bin/rolling,now 2.04-1parrot1 amd64 [installed,automatic]
grub-imageboot/rolling,rolling,now 0.6 all [installed]
grub2-common/rolling,now 2.04-1parrot1 amd64 [installed,automatic]
hashcat/rolling,now 5.1.0+ds1-1 amd64 [installed,automatic]




┌─[anonymous@parrot]─[~]
└──╼$ sudo apt install grub-imageboot
[sudo] password for anonymous:
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  syslinux-common
The following NEW packages will be installed:
  grub-imageboot syslinux-common
0 upgraded, 2 newly installed, 0 to remove and 16 not upgraded.
Need to get 1,242 kB of archives.
After this operation, 3,619 kB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 https://ftp.halifax.rwth-aachen.de/parrotsec rolling/main amd64
syslinux-common all 3:6.04~git20190206.bf6db5b4+dfsg1-1 [1,237 kB]
Get:2 https://ftp.halifax.rwth-aachen.de/parrotsec rolling/main amd64
grub-imageboot all 0.6 [4,354 B]
Fetched 1,242 kB in 2s (710 kB/s)
Selecting previously unselected package syslinux-common.
(Reading database ... 333752 files and directories currently installed.)
Preparing to unpack
.../syslinux-common_3%3a6.04~git20190206.bf6db5b4+dfsg1-1_all.deb ...
Unpacking syslinux-common (3:6.04~git20190206.bf6db5b4+dfsg1-1) ...
Selecting previously unselected package grub-imageboot.
Preparing to unpack .../grub-imageboot_0.6_all.deb ...
Unpacking grub-imageboot (0.6) ...
Setting up syslinux-common (3:6.04~git20190206.bf6db5b4+dfsg1-1) ...
Setting up grub-imageboot (0.6) ...
Copy syslinux memdisk to /boot/memdisk
Scanning application launchers
Updating active launchers
Done
┌─[anonymous@parrot]─[~]
└──╼$ sudo apt purge memtest86+
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
  memtest86+*
0 upgraded, 0 newly installed, 1 to remove and 16 not upgraded.
After this operation, 2,449 kB disk space will be freed.
Do you want to continue? [Y/n]
(Reading database ... 333972 files and directories currently installed.)
Removing memtest86+ (5.01-3+b1) ...
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-5.1.0-parrot1-3t-amd64
Found initrd image: /boot/initrd.img-5.1.0-parrot1-3t-amd64
Found linux image: /boot/vmlinuz-4.19.37-6parrot2-amd64
Found initrd image: /boot/initrd.img-4.19.37-6parrot2-amd64
Adding boot menu entry for EFI firmware configuration
Found memdisk: /memdisk
Imagepath /boot/images not found
done
(Reading database ... 333955 files and directories currently installed.)
Purging configuration files for memtest86+ (5.01-3+b1) ...
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-5.1.0-parrot1-3t-amd64
Found initrd image: /boot/initrd.img-5.1.0-parrot1-3t-amd64
Found linux image: /boot/vmlinuz-4.19.37-6parrot2-amd64
Found initrd image: /boot/initrd.img-4.19.37-6parrot2-amd64
Adding boot menu entry for EFI firmware configuration
Found memdisk: /memdisk
Imagepath /boot/images not found
done
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-5.1.0-parrot1-3t-amd64
Found initrd image: /boot/initrd.img-5.1.0-parrot1-3t-amd64
Found linux image: /boot/vmlinuz-4.19.37-6parrot2-amd64
Found initrd image: /boot/initrd.img-4.19.37-6parrot2-amd64
Adding boot menu entry for EFI firmware configuration
Found memdisk: /memdisk
Imagepath /boot/images not found
done
Scanning application launchers
Updating active launchers
Done
┌─[✗]─[anonymous@parrot]─[~]
└──╼$ sudo apt install memtest86+
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
  hwtools memtester kernel-patch-badram memtest86 grub-pc | grub-legacy
The following NEW packages will be installed:
  memtest86+
0 upgraded, 1 newly installed, 0 to remove and 16 not upgraded.
Need to get 78.1 kB of archives.
After this operation, 2,449 kB of additional disk space will be used.
Get:1 https://mirror.yandex.ru/mirrors/parrot rolling/main amd64
memtest86+ amd64 5.01-3+b1 [78.1 kB]

Bug#912109: Spectre Meltdown. System has more than MAX_PA/2 memory. L1TF mitigation not effective for CVE-2018-3620

[bugs]

Thx!
Installed the kernel from proposed-updates and that fixes the issue.


Tobias.

-Original Message-
From: Salvatore Bonaccorso [mailto:salvatore.bonacco...@gmail.com] On Behalf
Of Salvatore Bonaccorso
Sent: Sunday, October 28, 2018 1:21 PM
To: tobias ; 912...@bugs.debian.org
Subject: Re: Bug#912109: Spectre Meltdown. System has more than MAX_PA/2
memory. L1TF mitigation not effective for CVE-2018-3620

Hi

This issue is already tracked with 907581, merging the two bugs. The next
point release will include a fix, but it is already installable from
stretch-proposed-updates as of now.

HTH,

Regards,
Salvatore

Bug#912109: Spectre Meltdown. System has more than MAX_PA/2 memory. L1TF mitigation not effective for CVE-2018-3620

[bugs]

Hi,

Thx for responding quickly.
I have the microcode package installed.

dpkg -l | grep microcode
ii  intel-microcode3.20180807a.1~deb9u1   amd64
Processor microcode firmware for Intel
and activated:
# dmesg | grep microc
[0.00] microcode: microcode updated early to revision 0x20, date =
2018-04-10
[0.545764] microcode: sig=0x306a9, pf=0x2, revision=0x20
[0.545879] microcode: Microcode Update Driver: v2.01
, Peter Oruba

>From what i read the issue applies to certain ram / cpu combo's.
Not sure if it's reproducible @ azure.

There is some more about it as well:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1788563

and here the upstream fix:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i
d=b0a182f875689647b014bc01d36b340217792852

regards,

Tobias.


On Sun, 28 Oct 2018 10:50:26 +0100 tobias  wrote:
> Package: src:linux
> Version: 4.9.110-3+deb9u6
> Severity: normal
> Tags: security
> 
> According to
https://github.com/speed47/spectre-meltdown-checker/releases/tag/v0.40 my
system is vulnerable for vulnerability CVE-2018-3620 
> 
> results:
> 
> CVE-2018-3620 aka 'Foreshadow-NG (OS), L1 terminal fault'
> * Mitigated according to the /sys interface:  NO  (Vulnerable)
> * Kernel supports PTE inversion:  YES  (found in kernel image)
> * PTE inversion enabled and active:  NO
> STATUS:  VULNERABLE  (Vulnerable)
> 
> 
>  dmesg | grep L1TF
>  [    0.014828] L1TF: System has more than MAX_PA/2 memory. L1TF
>  mitigation not effective.
> 
> workaround:
> as described here: https://bugzilla.opensuse.org/show_bug.cgi?id=1105536
> supplied command line parameter "mem=33554428k" and the issue is gone.
> 
> 
> 
> -- Package-specific info:
> ** Version:
> Linux version 4.9.0-8-amd64 (debian-ker...@lists.debian.org) (gcc version
6.3.0 20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.110-3+deb9u6
(2018-10-08)
> 
> ** Command line:
> BOOT_IMAGE=/boot/vmlinuz-4.9.0-8-amd64 root=/dev/mapper/vol00-lvroot ro
ipv6.disable=1 quiet
> 
> ** Not tainted
> 
> ** Kernel log:
> [   22.581813] device veth5bacacd entered promiscuous mode
> [   22.581854] br-f6f67b537c3b: port 1(veth5bacacd) entered blocking state
> [   22.581855] br-f6f67b537c3b: port 1(veth5bacacd) entered forwarding
state
> [   22.581935] br-f6f67b537c3b: port 1(veth5bacacd) entered disabled state
> [   22.587449] br-ced3a9da9295: port 1(veth1f742ed) entered blocking state
> [   22.587450] br-ced3a9da9295: port 1(veth1f742ed) entered disabled state
> [   22.587483] device veth1f742ed entered promiscuous mode
> [   22.587522] br-ced3a9da9295: port 1(veth1f742ed) entered blocking state
> [   22.587523] br-ced3a9da9295: port 1(veth1f742ed) entered forwarding
state
> [   22.587564] br-ced3a9da9295: port 1(veth1f742ed) entered disabled state
> [   22.696461] br-429b9edca99c: port 1(veth8d7b672) entered blocking state
> [   22.696463] br-429b9edca99c: port 1(veth8d7b672) entered disabled state
> [   22.696495] device veth8d7b672 entered promiscuous mode
> [   22.696533] br-429b9edca99c: port 1(veth8d7b672) entered blocking state
> [   22.696534] br-429b9edca99c: port 1(veth8d7b672) entered forwarding
state
> [   22.696568] br-429b9edca99c: port 1(veth8d7b672) entered disabled state
> [   22.717457] br-f6f67b537c3b: port 2(veth423bb83) entered blocking state
> [   22.717458] br-f6f67b537c3b: port 2(veth423bb83) entered disabled state
> [   22.717488] device veth423bb83 entered promiscuous mode
> [   22.717772] br-eb3952fed7f5: port 1(vethe2fd06e) entered blocking state
> [   22.717773] br-eb3952fed7f5: port 1(vethe2fd06e) entered disabled state
> [   22.717801] device vethe2fd06e entered promiscuous mode
> [   22.717835] br-eb3952fed7f5: port 1(vethe2fd06e) entered blocking state
> [   22.717836] br-eb3952fed7f5: port 1(vethe2fd06e) entered forwarding
state

Bug#881659: pyside2-tools package already created?

[olekw . dev+deb . bugs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Actually, I just looked at the binary packages provided by pyside2 [0] and
pyside2-tools seems to already be there[1]! So it seems like this bug [2]
can probably be closed?

Copying pyside2 uploaders for their perspective.

- -Olek

[0] https://packages.debian.org/source/sid/pyside2
[1] https://packages.debian.org/sid/pyside2-tools
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881659
-BEGIN PGP SIGNATURE-
Version: FlowCrypt 6.0.2 Gmail Encryption
Comment: Seamlessly send and receive encrypted email

wsFcBAEBCgAQBQJbvRdbCRB9g9QGoJ3B5AAA1zoP+wV640WJ2nBrVYmHyR8/
ePwOGAg36IoBOyzVGfS7F7QokhLKqsNar+EDkJYPryaseAeZcPWPumusqDzq
Hkk/vw8kjDQKSbBapHzOLCalXzBCrjvqVGBr46viR7aAo7+zsVYTadnZahgU
6DhvRTV6r/wliP07HBl978ra/ezKvX4z4rLykBdJ18G0q9J+x5kk6VX1Jg6d
vU1vHmg87/DyMlJvJIxfOc7U0YHoCq9zytJQO35/XAXJrJflVn8DVzEK/J5c
jI7+Y8RJZcNTUOlYV1o0B3oflnTBAbtcregqfxu/xpimyVaVkzAlyKKmQAsr
VRLM0Xb2+K55gbxptHhYSbnJEcCjvdpH6gxudJeRjs7n6R4a23JSK18FzMx8
P+bCagUDKcJSkYiF2xC2zpoRSvJ9lRIpUUvoJJaBXTR20sdtxJvm9lR+iqLa
YueIJv50F2m4aXPkSubSGTQjvvBbnIqbeF70CfLlU8+YrlSjHGjW9j76870N
gCL6fYB2/lM4n18sW7F/Mi9DB5cLyMalWHYyNjyLMSSzm2t9Y522w+23DrXp
vCXzc8sDNbtLc8QyhXGHk3B7LYWralbG1TeaGomaXd1xLdmnKrFxP3Gru5IU
/oJSqRWH6xMzMML7eAfmM3d/cWOd3YlRLZqByzeQttLOU0PEQqSkdRAu9nJH
ols0
=bKI7
-END PGP SIGNATURE-


0xEBE4E3EE94176FC2.asc
Description: application/pgp-keys

Bug#908449: (no subject)

[bugs]

Package: firefox-esr
Version: 60.2.0esr-1~deb9u2
Severity: grave

Debian Release: 9.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)


After updating from firefox-esr:i386 52.9.0esr-1~deb9u1 to 60.2.0esr-1~deb9u2, 
it no longer works.

It opens the crashreporter every time when trying to open it:
«Firefox had a problem and crashed. We’ll try to restore your tabs and 
windows when it restarts.

To help us diagnose and fix the problem, you can send us a crash report.»
and choosing to restart it only leads to that same window.

Running under gdb shows it is trying to run an unsupported instruction:
Thread 1 "firefox-esr" received signal SIGILL, Illegal instruction.
0xb352826f in ?? () from /usr/lib/firefox-esr/libxul.so

(gdb) x/i 0xb352826f
=> 0xb352826f:  movsd  -0x18(%ebp),%xmm0

or in intel syntax:
(gdb) set disassembly-flavor intel
(gdb) x/i 0xb352826f
=> 0xb352826f:  movsd  xmm0,QWORD PTR [ebp-0x18]


and indeed, this instruction is not accepted on the -admittedly old- computer 
where the fault happened.

/proc/cpuinfo shows it supports sse, but not sse2. And movsd is a sse2 
instruction [1]


1- https://en.wikipedia.org/wiki/X86_instruction_listings#SSE2_instructions

Bug#907029: buici-clock documents but does not implement showSecondHand [patch]

[debian-bugs-buici-clock]

Package: buici-clock
Version: 0.4.9.4

buici-clock manpage documents a showSecondHand resource/option, but does 
not actually implement it.  The below patch implements the documented 
behaviour.


How to reproduce:

Run "buici-clock --show-second-hand=0", observer that it incorrectly 
displays a ticking second-hand.


Fix: apply the patch below:

diff -u buici-clock-0.4.9.2-orig/clock.cxx buici-clock-0.4.9.2/clock.cxx
--- buici-clock-0.4.9.2-orig/clock.cxx  2011-07-25 12:54:11.0 -0700
+++ buici-clock-0.4.9.2/clock.cxx   2014-10-19 03:55:19.862690022 -0700
@@ -106,7 +106,8 @@
 void draw_dial (Display* display, Visual* visual,
Pixmap pixmap, int dx, int dy);
 void draw_hands (Display* display, Visual* visual,
-   Pixmap pixmap, int dx, int dy, int seconds);
+   Pixmap pixmap, int dx, int dy, int seconds,
+   bool showSecondHand);
 void draw_dial_shape (Display* display, Pixmap pixmap, int dx, int dy);

 class WTopLevel : public LWindow {
@@ -538,7 +539,7 @@
 _gc, 0, 0, width (), height (), 0, 0);


-  draw_hands (xdisplay (), xvisual (), pixmap, width (), height (), seconds);
+  draw_hands (xdisplay (), xvisual (), pixmap, width (), height (), seconds, 
m_fSecondHand);

 #if 0
// -- Draw hands
diff -u buici-clock-0.4.9.2-orig/draw.cc buici-clock-0.4.9.2/draw.cc
--- buici-clock-0.4.9.2-orig/draw.cc2011-07-25 12:54:11.0 -0700
+++ buici-clock-0.4.9.2/draw.cc 2014-10-19 03:55:50.805687985 -0700
@@ -145,7 +145,8 @@


 void draw_hands (Display* display, Visual* visual,
-Pixmap pixmap, int dx, int dy, int seconds)
+Pixmap pixmap, int dx, int dy, int seconds,
+bool showSecondHand)
 {
   cairo_surface_t* s = cairo_xlib_surface_create (display, pixmap, visual,
  dx, dy);
@@ -198,16 +199,18 @@
 cairo_path_destroy (path);

// Second hand
-cairo_save (cr);
-cairo_rotate (cr, ((2.0*M_PI)*seconds)/60.0);
-cairo_set_line_width (cr, WIDTH_THIN);
-cairo_move_to (cr, 0,  (DY/2.0)*0.20);
-cairo_line_to (cr, 0, -(DY/2.0)*0.64);
-cairo_set_source_rgb (cr, 1.0, 0, 0);
-cairo_stroke (cr);
-cairo_arc (cr, 0, -(DY/2.0)*0.64, DX*0.03, 0, 2*M_PI);
-cairo_fill (cr);
-cairo_restore (cr);
+if (showSecondHand){
+cairo_save (cr);
+cairo_rotate (cr, ((2.0*M_PI)*seconds)/60.0);
+cairo_set_line_width (cr, WIDTH_THIN);
+cairo_move_to (cr, 0,  (DY/2.0)*0.20);
+cairo_line_to (cr, 0, -(DY/2.0)*0.64);
+cairo_set_source_rgb (cr, 1.0, 0, 0);
+cairo_stroke (cr);
+cairo_arc (cr, 0, -(DY/2.0)*0.64, DX*0.03, 0, 2*M_PI);
+cairo_fill (cr);
+cairo_restore (cr);
+}
   }

   cairo_destroy (cr);


 -Jason

Bug#903815: ITP: pw -- A simple command-line password manager

[bugs-debian]

> This is called proof by counter-example.
> If you cannot do this, and if nobody else can do this, then you cannot
> claim that it is not safe to use this script.
This is not a valid argument. Nobody can yet prove (by example) that it
is not safe to go near a black hole. But it is not safe.
The non existence of a counter-example does not mean that the theory is
valid.

Nonetheless, I don't have any opinion about pw. I use pass, and I think
that forks are welcomed.

Adrien

Bug#903491: [marble]

[bugs-debian]

Package: marble
Version: 4:17.08.3-3

--- Please enter the report below this line. ---
Upstream bug: https://bugs.kde.org/show_bug.cgi?id=394517

So nobody has proposed something yet. Since contributing to Marble is a
bit complicated (I don't have any account for now), here is a small patch.

Adrien

--- System information. ---
Architecture:
Kernel: Linux 4.16.0-2-amd64

Debian Release: buster/sid
500 unstable ftp.fr.debian.org
500 testing download.jitsi.org
1 experimental ftp.fr.debian.org

--- Package information. ---
Depends (Version) | Installed
===-+-=
marble-data (>= 4:17.08.3-3) | 4:17.08.3-3
marble-plugins (= 4:17.08.3-3) | 4:17.08.3-3
kio | 5.47.0-1
libc6 (>= 2.14) | 2.27-4
libgcc1 (>= 1:3.0) | 1:8.1.0-9
libkf5configcore5 (>= 4.98.0) | 5.47.0-1
libkf5configgui5 (>= 4.97.0) | 5.47.0-1
libkf5configwidgets5 (>= 4.96.0) | 5.47.0-1
libkf5coreaddons5 (>= 4.100.0) | 5.47.0-1
libkf5crash5 (>= 4.96.0) | 5.47.0-1
libkf5i18n5 (>= 4.97.0) | 5.47.0-1
libkf5kiowidgets5 (>= 4.99.0) | 5.47.0-1
libkf5newstuff5 (>= 4.95.0) | 5.47.0-1
libkf5parts5 (>= 4.96.0) | 5.47.0-1
libkf5widgetsaddons5 (>= 4.96.0) | 5.47.0-1
libkf5xmlgui5 (>= 4.98.0) | 5.47.0-1
libmarblewidget-qt5-28 (= 4:17.08.3-3) | 4:17.08.3-3
libqt5core5a (>= 5.9.0~beta) | 5.10.1+dfsg-7
libqt5dbus5 (>= 5.4) | 5.10.1+dfsg-7
libqt5gui5 (>= 5.7.0) | 5.10.1+dfsg-7
libqt5network5 (>= 5.4) | 5.10.1+dfsg-7
libqt5printsupport5 (>= 5.4) | 5.10.1+dfsg-7
libqt5widgets5 (>= 5.4) | 5.10.1+dfsg-7
libqt5xml5 (>= 5.4) | 5.10.1+dfsg-7
libstdc++6 (>= 4.1.1) | 8.1.0-9


Package's Recommends field is empty.

Suggests (Version) | Installed
===-+-===
gosmore |
monav-routing-daemon |
routino |
Index: marble-17.08.3/src/plugins/runner/nominatim-reversegeocoding/OsmNominatimReverseGeocodingRunner.cpp
===
--- marble-17.08.3.orig/src/plugins/runner/nominatim-reversegeocoding/OsmNominatimReverseGeocodingRunner.cpp
+++ marble-17.08.3/src/plugins/runner/nominatim-reversegeocoding/OsmNominatimReverseGeocodingRunner.cpp
@@ -49,7 +49,7 @@ void OsmNominatimRunner::returnNoReverse
 void OsmNominatimRunner::reverseGeocoding( const GeoDataCoordinates  )
 {
 m_coordinates = coordinates;
-QString base = "http://nominatim.openstreetmap.org/reverse?format=xml=1;;
+QString base = "https://nominatim.openstreetmap.org/reverse?format=xml=1;;
 // @todo: Alternative URI with addressdetails=1 could be used for shorther placemark name
 QString query = "=%1=%2=%3";
 double lon = coordinates.longitude( GeoDataCoordinates::Degree );
Index: marble-17.08.3/src/plugins/runner/nominatim-search/OsmNominatimSearchRunner.cpp
===
--- marble-17.08.3.orig/src/plugins/runner/nominatim-search/OsmNominatimSearchRunner.cpp
+++ marble-17.08.3/src/plugins/runner/nominatim-search/OsmNominatimSearchRunner.cpp
@@ -50,7 +50,7 @@ void OsmNominatimRunner::returnNoResults
 
 void OsmNominatimRunner::search( const QString , const GeoDataLatLonBox  )
 {
-QString base = "http://nominatim.openstreetmap.org/search?;;
+QString base = "https://nominatim.openstreetmap.org/search?;;
 QString query = "q=%1=xml=1=%2";
 QString url = QString(base + query).arg(searchTerm).arg(MarbleLocale::languageCode());
 if( !preferred.isEmpty() ) {

Bug#902171: libvirt-clients: unsafe blockresize behaviour inconsistent with vol-resize

[debian-bugs]

Package: libvirt-clients
Version: 3.0.0-4+deb9u3
Severity: grave
Justification: causes serious data loss

A user that is familiar with the vol-resize command may inadvertently 
assume that virsh will protect them against data loss when using 
blockresize.


The 'virsh vol-resize' command (applicable to offline virtual machines) 
has sanity checks prior to shrinking a volume.


If a new size is proposed that is smaller than the current size, the 
following error message is produced:
error: invalid argument: Can't shrink capacity below current capacity 
unless shrink flag explicitly specified


The 'virsh blockresize' command (applicable to online virtual machines), 
however, will happily accept any proposed new size, even if it is 
smaller than the current size. It will execute without prior warning and 
without requiring specific confirmation or flag.


Unintentional volume shrinking leads to data loss/corrupted filesystems. 
It should require user confirmation, as occurs for vol-resize.

Bug#894770: alternative workaround

[bugs]

For those who need to get work done but are stuck due to this bug
here is an alternative work around that I was previously unaware of.
(I know this isn't exactly bug information but it will probably
 help quite a few people that arrive on this page looking for a solution)

Just install the package arduino-mk

You can compile upload and monitor arduino sketches using Makefile.
There are several tutorials around, here is one that I found.
https://hardwarefun.com/tutorials/compiling-arduino-sketches-using-makefile

This works well for me on debian buster.

Bug#897184: [mnemosyne] No meaningful error message for malformed file on csv import

[bugs]

Package: mnemosyne
Version: 2.4-0.1
Severity: normal

--- Please enter the report below this line. ---

I tried to convert an existing wordlist to be able to import it
to Mnemosyne as 'tab delimited (txt)'.

However, the importer wasn't able to import it and presented an error
message:

"""
An unexpected error has occurred.
Please forward the following info to the developers:

Traceback (innermost last):
  File "/usr/lib/python3/dist-packages/mnemosyne/pyqt_ui/import_dlg.py",
line 76, in accept
self.format().do_import(filename, extra_tag_names)
  File
"/usr/lib/python3/dist-packages/mnemosyne/libmnemosyne/file_formats/tsv.py",
line 82, in do_import
tag_names=tag_names, check_for_duplicates=False, save=False)
  File
"/usr/lib/python3/dist-packages/mnemosyne/libmnemosyne/controllers/default_controller.py",
line 112, in create_new_cards
assert card_type.is_fact_data_valid(fact_data)
 AssertionError
"""

In the end, the input file was not absolutely correct: one entry was
missing.
I found out hat this happens when a line directly starts with a tab
(i.e. content is missing).
See also attached file where an error is in line 3.

The other way round (content, tab, line-end) there is a meaningful error
message:
"Badly formed input on line 3:"

--- System information. --
Architecture: Kernel:   Linux 4.9.0-6-amd64

Debian Release: 9.4
  500 stable-updates  ftp.de.debian.org   500 stable
security.debian.org   500 stable  ftp.de.debian.org
--- Package information. ---
Depends (Version) | Installed
=-+-===
libqt5sql5-sqlite | 5.7.1+dfsg-3+b1
python3  (>= 3.5) | 3.5.3-1
python3-cherrypy3 | 3.5.0-2
python3-matplotlib| 2.0.0+dfsg1-2
python3-pyqt5 | 5.7+dfsg-5
python3-pyqt5.qtsql   | 5.7+dfsg-5
python3-pyqt5.qtwebchannel| 5.7+dfsg-5
python3-pyqt5.qtwebengine | 5.7+dfsg-5
python3-webob | 1:1.6.2-2
python3:any (>= 3.5~) | libjs-sphinxdoc
(>= 1.0) | 1.4.9-2

 
 
 

Bug#893972: [borgbackup] msgpack-python>=0.4.6 distribution was not found

[bugs-debian]

After another apt update; apt upgrade, everything is working fine…

I don't know if it was linked, but there was an update for:
   python3-pkg-resources (38.5.2-1 => 39.0.1-1)
   python3-setuptools (38.5.2-1 => 39.0.1-1)

Anyway, this can be closed for me. Sorry for the disturbance.

Adrien

Bug#872257: Possible memory leak

[bugs]

Can confirm this. 

The "oom_reaper" killed all hvm's one after another. Only the pv's seems to be 
unaffected.

oom_reaper: reaped process 2031 (qemu-system-i38), now anon-rss:8kB, 
file-rss:0kB, shmem-rss:0kB

Downgrading to version 1:2.8+dfsg-6 helps.

Maybe the severity of this bug should be increased ...

Bug#870572: nvidia-legacy-340xx-driver: Trying to start xserver gives undefined symbol: miEmptyData

[debian-bugs]

Package: nvidia-legacy-340xx-driver
Version: 340.102-1
Severity: important

Hello,

xserver fails to start with the following in the log:
[ 16261.012] (II) Module glx: vendor="NVIDIA Corporation"
[ 16261.013]compiled for 4.0.2, module version = 1.0.0
[ 16261.013]Module class: X.Org Server Extension
[ 16261.013] (II) NVIDIA GLX Module  340.102  Mon Jan 16 12:37:38 PST 2017
[ 16261.013] (II) LoadModule: "nvidia"
[ 16261.013] (II) Loading /usr/lib/xorg/modules/drivers/nvidia_drv.so
[ 16261.013] (EE) Failed to load /usr/lib/xorg/modules/drivers/nvidia_drv.so: 
/usr/lib/xorg/modules/drivers/nvidia_drv.so: undefined symbol: miEmptyData
[ 16261.013] (II) UnloadModule: "nvidia"
[ 16261.013] (II) Unloading nvidia
[ 16261.013] (EE) Failed to load module "nvidia" (loader failed, 7)

Recently upgraded to Debian Stretch, used the proprietary nvidia installer in 
the past.  If I remember correctly there was not a Debian package that worked 
for my card in the past.  I am pretty sure I removed all the prior Debian 
installer stuff, the cleanup had an issue but I re-ran the install --uninstall 
and it seemed to work, purged all my nvidia related packaged and installed 
nvidia-legacy-340xx-driver.  Now I get this error.

-- Package-specific info:
uname -a:
Linux speedy 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26) x86_64 
GNU/Linux

/proc/version:
Linux version 4.9.0-3-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 
20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  340.102  Mon Jan 16 13:06:29 
PST 2017
GCC version:  gcc version 6.3.0 20170516 (Debian 6.3.0-18) 

lspci 'VGA compatible controller [0300]':
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G84 [GeForce 8600 
GTS] [10de:0400] (rev a1) (prog-if 00 [VGA controller])
Subsystem: eVga.com. Corp. G84 [GeForce 8600 GTS] [3842:c773]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: nvidia
Kernel modules: nvidia

dmesg:

Device node permissions:
crw-rw 1 root video 226, 0 Aug  2 17:47 /dev/dri/card0
video:x:44:gokee2,mythtv,guest

OpenGL and NVIDIA library files installed:
-rw-r--r-- 1 root root 2313 Jun 11  2015 /etc/X11/xorg.conf
lrwxrwxrwx 1 root root   15 Aug  2 17:39 /etc/alternatives/glx -> 
/usr/lib/nvidia
lrwxrwxrwx 1 root root   42 Aug  2 17:39 
/etc/alternatives/glx--libEGL.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libEGL.so.1
lrwxrwxrwx 1 root root   44 Aug  2 17:39 
/etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libEGL.so.1
lrwxrwxrwx 1 root root   48 Aug  2 17:39 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root   48 Aug  2 17:39 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root   41 Aug  2 17:39 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   41 Aug  2 17:39 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   43 Aug  2 17:39 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   43 Aug  2 17:39 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   48 Aug  2 17:39 
/etc/alternatives/glx--libGLESv1_CM.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   48 Aug  2 17:39 
/etc/alternatives/glx--libGLESv1_CM.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   50 Aug  2 17:39 
/etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   50 Aug  2 17:39 
/etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   45 Aug  2 17:39 
/etc/alternatives/glx--libGLESv2.so.2-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libGLESv2.so.2
lrwxrwxrwx 1 root root   45 Aug  2 17:39 
/etc/alternatives/glx--libGLESv2.so.2-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libGLESv2.so.2
lrwxrwxrwx 1 root root   47 Aug  2 17:39 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGLESv2.so.2
lrwxrwxrwx 1 root root   47 Aug  2 17:39 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGLESv2.so.2
lrwxrwxrwx 1 root root   49 Aug  2 17:39 

Bug#869422: closed by Michael Biebl <bi...@debian.org> (Re: Bug#869422: systemd-logind lacks an init script)

[sm-bugs-tp]

That might answer that question about those instruments pointing away
from Earth.

Bug#869422: closed by Michael Biebl <bi...@debian.org> (Re: Bug#869422: systemd-logind lacks an init script)

[sm-bugs-tp]

Don't know if that's reliable enough but a naive init script approach
could be:

stop: killall systemd-logind
start: loginctl list-sessions

Bug#869422: closed by Michael Biebl <bi...@debian.org> (Re: Bug#869422: systemd-logind lacks an init script)

[sm-bugs-tp]

Well, saying systemd-logind is started by dbus but after that no one
cares about it doesn't sound like a resonable solution. If you have
systemd you can say "service systemd-logind restart", but if you have
SysV init you can't? Bizarre.

Bug#869422: systemd-logind lacks an init script

[sm-bugs-tp]

Package: systemd
Version: 232-25+deb9u1
Severity: normal

I upgraded my Jessie installation to Stretch recently following the description 
in the Stretch release notes. I use sysvinit instead of systemd. Since the 
upgrade I see a process called systemd-logind that doesn't seem to have in init 
script so it cannot be restarted when there are library updates. Please provide 
an init script. Also, when I first login as a user it produces the message 
"systemd-logind[3215]: Failed to start user service, ignoring: Unknown unit: 
user@1000.service" on the console.

-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser 3.115
ii  libacl1 2.2.52-3+b1
ii  libapparmor12.11.0-3
ii  libaudit1   1:2.6.7-2
ii  libblkid1   2.29.2-1
ii  libc6   2.24-11+deb9u1
ii  libcap2 1:2.25-1
ii  libcryptsetup4  2:1.7.3-4
ii  libgcrypt20 1.7.6-2+deb9u1
ii  libgpg-error0   1.26-2
ii  libidn111.33-1
ii  libip4tc0   1.6.0+snapshot20161117-6
ii  libkmod223-2
ii  liblz4-10.0~r131-2+b1
ii  liblzma55.2.2-1.2+b1
ii  libmount1   2.29.2-1
ii  libpam0g1.1.8-3.6
ii  libseccomp2 2.3.1-2.1
ii  libselinux1 2.6-3+b1
ii  libsystemd0 232-25+deb9u1
ii  mount   2.29.2-1
ii  procps  2:3.3.12-3
ii  util-linux  2.29.2-1

Versions of packages systemd recommends:
ii  dbus1.10.18-1
ii  libpam-systemd  232-25+deb9u1

Versions of packages systemd suggests:
ii  policykit-10.105-18
pn  systemd-container  
pn  systemd-ui 

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.130
ii  udev 232-25+deb9u1

Bug#868224: Re: Bug#868224: linux-image-4.9.0-3-amd64: Upgrade to linux-image-4.9.0-3-amd64 hangs while or after generating initrd

[debian . bugs . jg]

> -Ursprüngliche Nachricht-
> Von: Ben Hutchings 
> Gesendet: So. 16.07.2017 23:23
> An: Jens Gruentjes , ,  868...@bugs.debian.org
> Betreff: Re: Bug#868224: linux-image-4.9.0-3-amd64: Upgrade to 
> linux-image-4.9.0-3-amd64 hangs while or after generating initrd
>
> Control: reassign -1 src:initramfs-tools 0.130
> Control: tag -1 moreinfo
>
> On Thu, 2017-07-13 at 11:17 +0200, Jens Gruentjes wrote:
> [...]
>> I upgraded to the latest stable kernel via apt-get upgrade. The upgrade
>> hangs at the following point:
>>
>> linux-image-4.9.0-3-amd64 (4.9.30-2+deb9u2) wird eingerichtet ...
>> /etc/kernel/postinst.d/initramfs-tools:
>> update-initramfs: Generating /boot/initrd.img-4.9.0-3-amd64
>>
>> After waiting a couple of hours I interrupted the upgrade. After that I
>> tried dpkg --configure -a or apt-get -f install but the result was
>> always the same.
>>
>> I trid to build the initrd file manually via
>>
>> update-initramfs -u -t
>>
>> which worked and created the file /boot/initrd.img-4.9.0-3-amd64
>>
>> Another apt-get -f install leads to the same problem that the upgrade
>> hangs with 
>>
>> /etc/kernel/postinst.d/initramfs-tools:
>> update-initramfs: Generating /boot/initrd.img-4.9.0-3-amd64
> [...]
>
> Please edit the line 'verbose=0' in /usr/sbin/update-initramfs (near
> the bottom) to be 'verbose=1' and then re-run 'dpkg --configure -a'.
> This should generate a lot of output but if you send the last, say, 100
> lines, I think that should give me a clue where it is getting stuck.
>
> Ben.
>
> -- 
> Ben Hutchings
> If the facts do not conform to your theory, they must be disposed of.
>
>
>
> -Ursprüngliche Nachricht Ende-
[...]
Adding module /lib/modules/4.9.0-3-amd64/kernel/drivers/acpi/video.ko
Adding module /lib/modules/4.9.0-3-amd64/kernel/drivers/gpu/drm/i915/i915.ko
Adding module /lib/modules/4.9.0-3-amd64/kernel/drivers/gpu/drm/bochs/bochs-
drm.ko
Adding module /lib/modules/4.9.0-3-amd64/kernel/drivers/gpu/drm/virtio/virtio-
gpu.ko
Adding module /lib/modules/4.9.0-3-amd64/kernel/drivers/gpu/drm/mgag200/
mgag200.ko
Adding module /lib/modules/4.9.0-3-amd64/kernel/drivers/gpu/drm/gma500/
gma500_gfx.ko
Adding module /lib/modules/4.9.0-3-amd64/kernel/drivers/gpu/drm/vmwgfx/
vmwgfx.ko
Adding module /lib/modules/4.9.0-3-amd64/kernel/drivers/gpu/drm/vgem/vgem.ko
Adding module /lib/modules/4.9.0-3-amd64/kernel/drivers/gpu/drm/qxl/qxl.ko
Adding module /lib/modules/4.9.0-3-amd64/kernel/drivers/gpu/drm/i2c/sil164.ko
Adding module /lib/modules/4.9.0-3-amd64/kernel/drivers/gpu/drm/i2c/ch7006.ko
Adding module /lib/modules/4.9.0-3-amd64/kernel/drivers/platform/x86/wmi.ko
Adding module /lib/modules/4.9.0-3-amd64/kernel/drivers/platform/x86/mxm-
wmi.ko
Adding module /lib/modules/4.9.0-3-amd64/kernel/drivers/gpu/drm/nouveau/
nouveau.ko
Adding module /lib/modules/4.9.0-3-amd64/kernel/drivers/gpu/drm/ast/ast.ko
Adding module /lib/modules/4.9.0-3-amd64/kernel/drivers/gpu/drm/radeon/
radeon.ko
Adding binary /usr/lib/x86_64-linux-gnu/plymouth/renderers/frame-buffer.so
Adding binary /usr/lib/x86_64-linux-gnu/plymouth/renderers/drm.so
Adding library-link /usr/lib/x86_64-linux-gnu/libdrm.so.2
Adding library /usr/lib/x86_64-linux-gnu/libdrm.so.2.4.0
Adding binary /lib/x86_64-linux-gnu/libnss_files-2.24.so
Adding binary-link /lib/x86_64-linux-gnu/libnss_files.so.2
Adding binary /lib/x86_64-linux-gnu/libnss_files-2.24.so
Calling hook resume
Calling hook thermal
Adding module /lib/modules/4.9.0-3-amd64/kernel/drivers/acpi/fan.ko
Adding module /lib/modules/4.9.0-3-amd64/kernel/drivers/acpi/thermal.ko
Calling hook udev
Adding binary /lib/systemd/systemd-udevd
Adding library-link /lib/x86_64-linux-gnu/libacl.so.1
Adding library /lib/x86_64-linux-gnu/libacl.so.1.1.0
Adding library-link /lib/x86_64-linux-gnu/libkmod.so.2
Adding library /lib/x86_64-linux-gnu/libkmod.so.2.3.1
Adding library-link /lib/x86_64-linux-gnu/libattr.so.1
Adding library /lib/x86_64-linux-gnu/libattr.so.1.1.0
Adding binary /bin/udevadm
Adding binary /lib/udev/ata_id
Adding binary /lib/udev/scsi_id
Adding binary /sbin/blkid
Calling hook zz-busybox
Adding binary /bin/busybox
Calling hook cryptpassdev
Calling hook cryptopensc
Calling hook cryptopenct
Calling hook cryptkeyctl
Calling hook cryptgnupg
Calling hook ntfs_3g
Adding binary /bin/ntfs-3g
Adding library-link /lib/x86_64-linux-gnu/libntfs-3g.so.871
Adding library /lib/x86_64-linux-gnu/libntfs-3g.so.871.0.0
Calling hook dmsetup
Calling hook klibc-utils
/usr/share/initramfs-tools/scripts/local-block/ORDER ignored: not executable
/usr/share/initramfs-tools/scripts/init-premount/ORDER ignored: not executable
/usr/share/initramfs-tools/scripts/local-top/ORDER ignored: not executable
/usr/share/initramfs-tools/scripts/init-bottom/ORDER ignored: not executable
/usr/share/initramfs-tools/scripts/local-premount/ORDER ignored: not 
executable
/usr/share/initramfs-tools/scripts/panic/ORDER ignored: not executable
/usr/share/initramfs-tools/scripts/local-bottom/ORDER ignored: not executable

Bug#868563: apparmor-profiles: Apparmor profiles for postfix programs have incorrect path

[debian-bugs]

Package: apparmor-profiles
Version: 2.11.0-3
Severity: important

Dear Maintainer,

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

After upgrading from jessie to stretch I noticed that postfix was no longer 
constrained by apparmor profiles (using aa-unconfined, ps auxZ etc).

The cause of this issue seems to be that the profiles in this package use paths 
like /usr/lib/postfix/master but this has moved to /usr/lib/postfix/sbin/master.
This applies to all /usr/lib/postfix/* profiles. Thus the profiles do not 
properly apply to the correct process. The profiles will need to be updated to 
point
to the right executables.

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


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

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

Versions of packages apparmor-profiles depends on:
ii  apparmor  2.11.0-3

apparmor-profiles recommends no packages.

apparmor-profiles suggests no packages.

-- Configuration Files:

-- no debconf information

Bug#867256: monitoring-plugins-basic: fails to install: Error: The new file apt.cfg does not exist!

[bugs . monitoring-plugins]

Hi,

I can confirm that problem on several machines. We were able to get 
around by altering the post-installation script:


--- snip
# diff -rupN3 monitoring-plugins.dpkg.functions.orig 
/usr/share/monitoring-plugins/dpkg/functions
--- monitoring-plugins.dpkg.functions.orig2017-07-10 
13:07:13.562944671 +0200
+++ /usr/share/monitoring-plugins/dpkg/functions2017-07-10 
13:05:16.656944917 +0200

@@ -9,7 +9,7 @@ register_cfgs(){
 cd $templdir
 for f in *cfg; do
 dest=${npconfdir}/$f
-ucf $f $dest
+ucf $templdir/$f $dest
 done
 );
 }
--- /snip

As you can see, we just added "$templdir/" into that line and 
installation worked again. Without it, ucf seems to be unable to locate 
the "new file".

Bug#860534: Similar bug

[bugs . report . filter]

Hi.

I get a similar bug, but my system doesn't freeze, it directly reboot 
without any warning. I looked into all my logs files, nothing is 
reported by the system.


I've got the same GPU as the guy who reported this bug : AMD/ATI Juniper 
XT [Radeon HD 5770]


lspci :

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. 
[AMD/ATI] Juniper XT [Radeon HD 5770] (prog-if 00 [VGA controller])

Subsystem: Gigabyte Technology Co., Ltd Juniper XT [Radeon HD 5770]
Flags: bus master, fast devsel, latency 0, IRQ 5, NUMA node 0
Memory at d000 (64-bit, prefetchable) [size=256M]
Memory at fdfc (64-bit, non-prefetchable) [size=128K]
I/O ports at ae00 [size=256]
[virtual] Expansion ROM at 000c [disabled] [size=128K]
Capabilities: [50] Power Management version 3
Capabilities: [58] Express Legacy Endpoint, MSI 00
Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 

Capabilities: [150] Advanced Error Reporting
Kernel modules: radeon

Regards.

Bug#800344: upgrade to 14.4.2

[debian-bugs]

Dear maintainer,

is there any problem with the new sox version? It, additionally to the
fixed bugs, would support opus.

The named version is from February 22, 2015.

cheers

wof

Bug#859653: ntopng: Segmentation fault with mysql

[debian-bugs]

dmesg output:
[Wed Apr  5 09:14:11 2017] ntopng[5476]: segfault at 7ffe507c7000 ip 
560e93462ffe sp 7ffe507c3c00 error 4 in ntopng[560e9344e000+8a000]
[Wed Apr  5 09:14:13 2017] ntopng[5486]: segfault at 7fff5c828000 ip 
55b31fd46ffe sp 7fff5c823e10 error 4 in ntopng[55b31fd32000+8a000]
[Wed Apr  5 09:14:14 2017] ntopng[5489]: segfault at 7ffd4ce5 ip 
556b06ef1ffe sp 7ffd4ce4d800 error 4 in ntopng[556b06edd000+8a000]
[Wed Apr  5 09:14:17 2017] ntopng[5493]: segfault at 7ffceff51000 ip 
5648480d9ffe sp 7ffceff4cdd0 error 4 in ntopng[5648480c5000+8a000]
[Wed Apr  5 09:14:19 2017] ntopng[5496]: segfault at 7ffc7cbb6000 ip 
564307584ffe sp 7ffc7cbb2270 error 4 in ntopng[56430757+8a000]
[Wed Apr  5 09:14:21 2017] ntopng[5499]: segfault at 7ffc12f5c000 ip 
55724f8c2ffe sp 7ffc12f58a30 error 4 in ntopng[55724f8ae000+8a000]
[Wed Apr  5 09:14:23 2017] ntopng[5502]: segfault at 721ab000 ip 
56399b218ffe sp 721a6870 error 4 in ntopng[56399b204000+8a000]
[Wed Apr  5 09:14:25 2017] ntopng[5506]: segfault at 7ffece96d000 ip 
561ed1589ffe sp 7ffece969d20 error 4 in ntopng[561ed1575000+8a000]
[Wed Apr  5 09:14:28 2017] ntopng[5511]: segfault at 7ffe902e ip 
56216eb96ffe sp 7ffe902dbb80 error 4 in ntopng[56216eb82000+8a000]
[Wed Apr  5 09:14:30 2017] ntopng[5514]: segfault at 7ffd7d323000 ip 
5567c50d2ffe sp 7ffd7d31f290 error 4 in ntopng[5567c50be000+8a000]
[Wed Apr  5 09:14:32 2017] ntopng[5517]: segfault at 7ffdb0f93000 ip 
5590c171fffe sp 7ffdb0f8f5b0 error 4 in ntopng[5590c170b000+8a000]
[Wed Apr  5 09:17:44 2017] ntopng[5939]: segfault at 7ffe29a0b000 ip 
55d940272ffe sp 7ffe29a068e0 error 4 in ntopng[55d94025e000+8a000]
[Wed Apr  5 09:17:47 2017] ntopng[5944]: segfault at 7ffd2d642000 ip 
557cf8c06ffe sp 7ffd2d63dee0 error 4 in ntopng[557cf8bf2000+8a000]
[Wed Apr  5 09:17:49 2017] ntopng[5947]: segfault at 7ffe3a407000 ip 
55f54dc7cffe sp 7ffe3a4030d0 error 4 in ntopng[55f54dc68000+8a000]
[Wed Apr  5 09:17:51 2017] ntopng[5950]: segfault at 7fff45c4d000 ip 
55d7f78cbffe sp 7fff45c4a090 error 4 in ntopng[55d7f78b7000+8a000]
[Wed Apr  5 09:17:53 2017] ntopng[5953]: segfault at 7fff366d1000 ip 
55b18eedeffe sp 7fff366ccad0 error 4 in ntopng[55b18eeca000+8a000]
[Wed Apr  5 09:17:55 2017] ntopng[5957]: segfault at 7fffdfb17000 ip 
55c1d2864ffe sp 7fffdfb12eb0 error 4 in ntopng[55c1d285+8a000]
[Wed Apr  5 09:17:58 2017] ntopng[5960]: segfault at 7ffca3912000 ip 
55f3133dfffe sp 7ffca390df10 error 4 in ntopng[55f3133cb000+8a000]
[Wed Apr  5 09:18:00 2017] ntopng[5963]: segfault at 7fff2a29f000 ip 
55771589dffe sp 7fff2a29ae30 error 4 in ntopng[557715889000+8a000]
[Wed Apr  5 09:18:01 2017] ntopng[5966]: segfault at 7ffca0c55000 ip 
55eeb0892ffe sp 7ffca0c525e0 error 4 in ntopng[55eeb087e000+8a000]
[Wed Apr  5 09:18:03 2017] ntopng[5969]: segfault at 7ffc98794000 ip 
55f774d76ffe sp 7ffc987912c0 error 4 in ntopng[55f774d62000+8a000]
[Wed Apr  5 09:18:05 2017] ntopng[5972]: segfault at 7ffed608e000 ip 
55e80c866ffe sp 7ffed608a670 error 4 in ntopng[55e80c852000+8a000]
[Wed Apr  5 09:18:08 2017] ntopng[5975]: segfault at 7ffd01cbf000 ip 
5619f1203ffe sp 7ffd01cbac00 error 4 in ntopng[5619f11ef000+8a000]
[Wed Apr  5 09:18:10 2017] ntopng[5978]: segfault at 7ffe2e374000 ip 
561e83c5dffe sp 7ffe2e370cf0 error 4 in ntopng[561e83c49000+8a000]
[Wed Apr  5 09:18:12 2017] ntopng[5981]: segfault at 7ffc0b45c000 ip 
560b4ff91ffe sp 7ffc0b457a30 error 4 in ntopng[560b4ff7d000+8a000]
[Wed Apr  5 09:18:14 2017] ntopng[5984]: segfault at 7ffeab818000 ip 
558fe78b6ffe sp 7ffeab814330 error 4 in ntopng[558fe78a2000+8a000]
[Wed Apr  5 09:18:16 2017] ntopng[5987]: segfault at 7ffc196ed000 ip 
56405ee9cffe sp 7ffc196ea090 error 4 in ntopng[56405ee88000+8a000]
[Wed Apr  5 09:18:19 2017] ntopng[5990]: segfault at 7ffc904ba000 ip 
5643e411bffe sp 7ffc904b5ee0 error 4 in ntopng[5643e4107000+8a000]
[Wed Apr  5 09:18:21 2017] ntopng[5993]: segfault at 7ffedf3b8000 ip 
560d127caffe sp 7ffedf3b4270 error 4 in ntopng[560d127b6000+8a000]
[Wed Apr  5 09:18:23 2017] ntopng[5996]: segfault at 7ffef9529000 ip 
563a47c9cffe sp 7ffef9524f60 error 4 in ntopng[563a47c88000+8a000]
[Wed Apr  5 09:18:25 2017] ntopng[5999]: segfault at 7ffd3413 ip 
55eda928fffe sp 7ffd3412cef0 error 4 in ntopng[55eda927b000+8a000]
[Wed Apr  5 09:18:27 2017] ntopng[6004]: segfault at 7ffcf0dd6000 ip 
55dcf3210ffe sp 7ffcf0dd2b70 error 4 in ntopng[55dcf31fc000+8a000]
[Wed Apr  5 09:18:29 2017] ntopng[6007]: segfault at 7ffd785b7000 ip 
55cfc7c22ffe sp 7ffd785b2e90 error 4 in ntopng[55cfc7c0e000+8a000]
[Wed Apr  5 09:18:31 2017] ntopng[6010]: segfault at 7ffcb3f88000 ip 
55bd0a7caffe sp 7ffcb3f850b0 error 4 in ntopng[55bd0a7b6000+8a000]
[Wed Apr  5 09:18:33 2017] ntopng[6013]: segfault at 

Bug#798224: Bug report: 71d93401ff02340d71f04bd6f92c105e

[tails-bugs]

We can reproduce this bug in Tails consistently:

How to reproduce:

- Open Tails
- Click on Florence keyboard on the Top-Right corner. Florence appears
- Click on the Florence bottom-left-most key. (-)


Error:
- Florence becomes very tiny (VERY tiny, almost unreadable)
- Clicking on the (+) does not make it bigger.

What should happen instead:
- Florence should decrease more slowly of size
- Florence should become bigger when clicking the (+) sign.


-- 
--
Our help desk is helping hundreds of Tails users each month.
Each user request costs us $6 on average to proceed.
If you find our help useful, please consider donating to Tails so we
can continue helping more people like you:

https://tails.boum.org/donate#help

pgpmmKDYyqlWC.pgp
Description: PGP signature

Bug#857502: Remote crash while producing list of netjoins

[bugs]

Package: irssi
Version: 1.0.1-1
Severity: important

"Irssi 1.0.2 has been released. This release fixes a remote crash issue in 
Irssi 1.0 as well as a few bug fixes, the most notable a regression that broke 
incoming DCC file transfers. T
here are no new features. All Irssi 1.0 users should upgrade to this version."
 - https://irssi.org/2017/03/11/irssi-1.0.2-released/


"Use after free while producing list of netjoins (CWE-416)
This issue usually leads to segmentation faults. Targeted code
execution should be difficult.

We believe Irssi 0.8.21 and prior are not affected since a different
code path causes the netjoins to be flushed prior to reaching the use
after free condition."
 - https://irssi.org/security/irssi_sa_2017_03.txt


Thus stretch/sid (version 1.0.1-1) and jessie-backports (1.0.0-1~bpo8+1) are 
affected but jessie (0.8.17-1+deb8u3) is not

Bug#855519: olpc-powerd: Please package new upstream version (currently v110)

[sascha-debian-bugs-powerd-2017-02-19]

Package: olpc-powerd
Version: 23-2
Severity: normal

Dear Andres,

the powerd version in Debian is rather old and doesn't support the ARM
based XO models (XO-1.75, XO-4) at all. It would be great to have an
up to date version in Debian. Upstream [1] is currently at v110.

There have been significant changes upstream (e.g. dbus service,
olpc-switchd daemon) so some work on the packaging will be required.

If you're already at it, how about switching to git-buildpackage? ;)

Sascha

[1] https://dev.laptop.org/git/users/pgf/powerd/refs/tags

-- System Information:
Debian Release: 8.7
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable'), (100, 'testing')
Architecture: armhf (armv7l)

Kernel: Linux 3.0.19-mimosa-9-01604-gfaccdbaa5fd7 (PREEMPT)
Locale: LANG=en_GB, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages olpc-powerd depends on:
ii  ethtool  1:3.16-1
ii  libc62.19-18+deb8u7

Versions of packages olpc-powerd recommends:
ii  iptables  1.4.21-2+b1

olpc-powerd suggests no packages.

-- Configuration Files:
/etc/olpc-powerd/powerd.conf changed [not included]

-- no debconf information

Bug#851821: linux: Please enable CONFIG_TOUCHSCREEN_GOODIX

[russm-debian-bugs]

Source: linux
Version: 4.9.2-2
Severity: wishlist
Tags: patch

Dear Maintainer,

Please enable CONFIG_TOUCHSCREEN_GOODIX, for use on devices that have
this touchscreen hardware installed.

Thank you!



diff --git a/debian/config/config b/debian/config/config
index bd87c7f32..9dabf1feb 100644
--- a/debian/config/config
+++ b/debian/config/config
@@ -1423,7 +1423,7 @@ CONFIG_TOUCHSCREEN_HAMPSHIRE=m
 CONFIG_TOUCHSCREEN_EETI=m
 # CONFIG_TOUCHSCREEN_EGALAX is not set
 CONFIG_TOUCHSCREEN_FUJITSU=m
-# CONFIG_TOUCHSCREEN_GOODIX is not set
+CONFIG_TOUCHSCREEN_GOODIX=m
 # CONFIG_TOUCHSCREEN_ILI210X is not set
 CONFIG_TOUCHSCREEN_GUNZE=m
 # CONFIG_TOUCHSCREEN_ELAN is not set



-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Bug#843589: Change severity

[bugs-debian]

Hi,

I don't really know if this should be an RC bug, but this package has
entered testing. And as such, migration is not possible without fetching
source package.

Adrien

Bug#830074: fixed in iodine 0.7.0-5

[bugs-debian]

Sorry for being late on all of this, but I have a few remarks on this.
First, thanks for the service file, and the long explanation.
Regarding socket activation, I currently have this (custom) socket unit:

[Unit]
Description=Iodine socket

[Socket]
# For now, listen only in IPv4
ListenDatagram=0.0.0.0:5354
BindIPv6Only=both

[Install]
WantedBy=sockets.target

This is fine. It does not solve the case where "-i" exit too quickly,
but I have not experienced this. Do you have a bug report for this
incorrect behavior?

Since iodine is a pure network service, it should be protected as much
as possible with systemd's own mechanism like:
PrivateTmp=true
ProtectSystem=full
ProtectHome=true
NoNewPrivileges=true

I understand that chroot can offer some protection, so I'll be glad to
here that those directive are useless with it. In the same way, I may
have missed new containement directives that can be used to restrict the
attack surface further.

Adrien

Bug#830683: Missing dependency on module-udev?

[bugs-debian]

Le 14/07/2016 à 13:51, Scott Leggett a écrit :
>
> If a package really does recommend other packages which are useless, you
> should file a bug on that package, not just start blindly using
> --no-install-recommends everywhere.
It is a never ending debate. If installing recommended packages is the
default, then it is more like a dependency, since the package will get
installed anyway. That's why APT::Install-Recommends "false" is in my
apt.conf. When I install a package, I read the summary, and decide by
myself to install or not some or all recommended packages. There should
be an "ask" value by the way.
However, when a builtin code is moved to a recommended package, it can
broke some systems. So the changelog should clearly mentionned that the
split is done in a recommended package, because apt does not do that.

> The relationship between pulseaudio and pulseaudio-module-udev matches
> the Policy description of the Recommends field.
I totally trust you on this point. However, the arguable issue we have
here is when a new recommended package is created with some previously
builtin features.

Adrien

Bug#830683: Missing dependency on module-udev?

[bugs-debian]

On Sun, 10 Jul 2016 23:37:01 -0300 Felipe Sateler 
wrote:
>
> Do you have disabled installation of Recommends?
>

Hi,

I guess he did, just like me, because installing recommends often leads
to a workload of useless packages.
Even if I totally understand that the packager is not expected to
support every configuration, maybe a line or two in NEWS.Debian should
be enough. I read each Changelog.Debian, I saw the split announcement,
but I totally missed the fact that it will render my system soundless.

Adrien

Bug#825748: (no subject)

[bugs . debian . org]

Additionnal informations:

python
Python 2.7.11+ (default, May  9 2016, 15:54:33)
[GCC 5.3.1 20160429] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import requests; requests.__version__.split('.')
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/requests/__init__.py", line 
61, in 

from .packages.urllib3.exceptions import DependencyWarning
ImportError: cannot import name DependencyWarning

Bug#813452: Feedback from #fpc

[bugs]

13:00 < Laksen> Hmm, looks like 3.0 does not have r30276. I suspect that might 
be the cause
13:06 < Laksen> But then it shouldn't be triggered if it's just using the 
default processor architecture..
13:08 < Laksen> Which it wouldn't because that's armv3 in 3.0, which does not 
have umull. So maybe that buildmachine has a custom fpc.cfg?
13:08 < nemo> update-alternatives: using /etc/fpc-3.0.0.cfg to provide 
/etc/fpc.cfg (fpc.cfg) in auto mode
13:08 < nemo> that feels like some generic thing
13:09 < nemo> but maybe debian arm generic

Bug#818276: boot problems on systems with dash as default shell

[debian-bugs]

Package: ifupdown-extra
Version: 0.25

On systems with dash as the default shell, the 00check-network-cable script can 
exit with an error.

This error can cause some network configuration in /etc/network/interfaces to 
be left unprocessed. On my system, the IPv6 portion of a dual stack 
configuration remains unapplied.

Example of the script having an error:

# IFACE=eth0 dash 00check-network-cable 
00check-network-cable: 72: local: detected:: bad variable name

However, running the following produces no errors.
# IFACE=eth0 bash 00check-network-cable 

The system boots correctly with full network configuration applied if the 
system’s default shell is changed to bash, or if the #!/bin/sh line is changed 
to #!/bin/bash

Debian policy discourages undeclared bashisms - if this package requires bash, 
it should have the appropriate dependencies and specify #!/bin/bash as its 
shell. Alternatively, the script can be written in a dash-safe shell language 
subset.

Bug#817928: live build 4.0.3 by default destroys settings done in the chroot stage

[Submit Bugs]

Package: live-build
Version: 4.0.3-1

The Live Build manual describes how to prepare a system in the chroot stage.

I do it.

On my live system (a firewall), I find destroyed settings in /etc/hosts, 
/etc/network/interfaces, /etc/resolv.conf and probably several others.
Further, a user not existing in the chroot, "user" is created with a 
world-known password "live".  This user can sudo.  (and via a little bit of 
TCP, the whole world can sudo on my box...)

I had to spend many hours to dig out, what happened and how to work around all 
this surprising magic.  The reporter of case #787617 was surprised, too.

The architectural flaw, that I see in all these symptoms, is, that live-build 
violates the principle of least surprise.  It is a great tool to automate the 
building of live images.  And without all the magic, it could be a great tool 
to do this generically for arbitrary live images based on Debian and Ubuntu.  
The problem is, that this magic happens by default.

It is clear, that there has to be a separation between build time customisation 
(which determines the properties of all produced live images) and run time 
customisation (determining the properties of the particular running instance).  
BUT: if I did not do any particular runtime configuration, I expect, that the 
system behaves as defined at build time -- and if I do a particular chroot-time 
customisation, that it survives chroot time (/etc/hosts is destroyed in a later 
stage of lb_build).

This way, a tool, promising to be simple and used for a simple use case, 
becomes complicated and unforeseeably expensive.

I would propose to switch default (no customisation) behaviour to the simplest 
possible.  Eg., if I don't define a live user, there will be none, if I don't 
switch something on, which alters my /etc/network/interfaces, it shouldn't, ...

The various customisation "switches" shall have well-defined and -documented 
behaviour.
Otherwise, the risk is too high, that I'm building a system full of security 
flaws.


Carpe diem

Bug#787220: 404 error with websocket/websocket jars not installed

[debian-bugs]

Package: tomcat7
Version: 7.0.56-3
Severity: normal

Dear Maintainer,

Running a very simple websocket endpoint fails with a 404 (not found)
error because the required websocket jars (tomcat-websocket.jar and
websocket-api.jar) are not installed.

I think the jars are not installed because the tomcat7 build scripts
need a java7 compiler to build them (and don't assume that there is one
installed). Adding the line

java.7.home=/usr/lib/jvm/java-7-openjdk-amd64

to build.properties (in the root of the unpacked tomcat7 source) will
make the build scripts build the required jars. Once the jars have been
built, copying them to /usr/share/tomcat7/lib (and making no other
changes) fixes the problem.

I'd guess a tomcat7-websocket package (with a java7 dependency) with
the required jars (and symlinks etc) would solve the problem?

Thanks,
   Osric Wilkinson

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

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

Versions of packages tomcat7 depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.56
ii  tomcat7-common 7.0.56-3
ii  ucf3.0030

Versions of packages tomcat7 recommends:
ii  authbind  2.1.1

Versions of packages tomcat7 suggests:
pn  libtcnative-1 none
ii  tomcat7-admin 7.0.56-3
pn  tomcat7-docs  none
pn  tomcat7-examples  none
pn  tomcat7-user  none

-- Configuration Files:
/etc/tomcat7/context.xml changed [not included]
/etc/tomcat7/server.xml changed [not included]
/etc/tomcat7/tomcat-users.xml [Errno 13] Permission denied: 
u'/etc/tomcat7/tomcat-users.xml'

-- debconf information:
  tomcat7/groupname: tomcat7
  tomcat7/username: tomcat7
  tomcat7/javaopts: -Djava.awt.headless=true -Xmx128m -XX:+UseConcMarkSweepGC


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#732452: Still valid?

[debian . bugs]

Carlo Stemberger schreef op 07.03.2015 03:24:

Hi Roy,
is this bug report still valid with Icecast 2.4.0?

Thank you!

Carlo


Hi Carlo,

I'm not sure. I still have the Wheezy version (2.3.2-9+deb7u2). Would 
you want me to try the backported version?


Best regards,

Roy


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#767343: libvirt-daemon shoud recommend libvirt-daemon-system

[bugs]

Package: libvirt-daemon
Version: 1.2.9-3
Severity: minor

Hi,

I haven't had any VM on system in use for quite some time. However after trying
to start up virt-manager I got notification that libvirt-daemon is not running.
After some digging I found out that even though the LSB init script is
available, the systemd however-it's-called file isn't. Quick search revealed
existence of libvirt-daemon-system. There might have been some transition but
that managed to miss me.

So from my PoV it'd make sense for libvirt-daemon to at least recommend
libvirt-daemon-system.

// M



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

Kernel: Linux 3.12.4-haruhi-4ist-nodelay (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libvirt-daemon depends on:
ii  libapparmor12.9.0-1
ii  libaudit1   1:2.4-1
ii  libavahi-client30.6.31-4
ii  libavahi-common30.6.31-4
ii  libblkid1   2.25.1-5
ii  libc6   2.19-12
ii  libcap-ng0  0.7.4-2
ii  libdbus-1-3 1.8.8-2
ii  libdevmapper1.02.1  2:1.02.90-2
ii  libfuse22.9.3-15
ii  libgnutls-deb0-28   3.3.8-3
ii  libnetcf1   1:0.2.3-4.1
ii  libnl-3-200 3.2.24-2
ii  libnl-route-3-200   3.2.24-2
ii  libnuma12.0.10~rc2-3
ii  libparted2  3.2-6
ii  libpcap0.8  1.6.2-2
ii  libpciaccess0   0.13.2-3
ii  librados2   0.80.7-1
ii  librbd1 0.80.7-1
ii  libsasl2-2  2.1.26.dfsg1-12
ii  libselinux1 2.3-2
ii  libssh2-1   1.4.3-4
ii  libsystemd0 215-5+b1
ii  libudev1215-5+b1
ii  libvirt01.2.9-3
ii  libxen-4.4  4.4.1-3
ii  libxenstore3.0  4.4.1-3
ii  libxml2 2.9.1+dfsg1-4
ii  libyajl22.1.0-2

Versions of packages libvirt-daemon recommends:
ii  libxml2-utils   2.9.1+dfsg1-4
ii  netcat-openbsd  1.105-7
ii  qemu2.1+dfsg-5+b1
ii  qemu-kvm2.1+dfsg-5+b1

libvirt-daemon suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758619: reportbug fails with Attempt to unlock mutex that was not locked

[bugs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,
I have had the same problem, reportbug has not launched, and when I
tried from command line, I got the messages
Attempt to unlock mutex that was not locked
Aborted
I found that bug 763690 claims to have a patch to this.
Z

- --- System information. ---
Architecture: amd64
Kernel:   Linux 3.16-2-amd64

Debian Release: jessie/sid
  500 testing-updates ftp.uk.debian.org
  500 testing security.debian.org
  500 testing ftp.uk.debian.org
  500 testing deb.bitmask.net
  500 stable  deb.bitmask.net
1 experimentalftp.uk.debian.org

- --- Package information. ---
Depends   (Version) | Installed
===-+-===
python (= 2.6) | 2.7.8-1
apt | 1.0.9.3
python-reportbug (= 6.5.0+nmu1) | 6.5.1
python (= 2.6) | 2.7.8-1
python-support  (= 0.90.0) | 1.0.15
apt | 1.0.9.3
python-debian   | 0.1.24
python-debianbts| 1.12


Package's Recommends field is empty.

Suggests   (Version) | Installed
-+-
postfix  |
 OR exim4| 4.84-2
 OR mail-transport-agent |
gnupg| 1.4.18-4
 OR pgp  |
debconf-utils ( 1.1.0) |
debsums  (= 2.0.47) |
file   ( 1.30) | 1:5.19-2
dlocate  |
python-urwid |
python-gtk2  | 2.24.0-4
python-vte   | 1:0.28.2-5
python-gtkspell  | 2.25.3-13
xdg-utils| 1.1.0~rc1+git20111210-7.1
emacs22-bin-common   |
 OR emacs23-bin-common   |
claws-mail(= 3.8.0) |
reportbug| 6.5.1



- --- Output from package bug script ---
reportbug_version 6.4.4
mode standard
ui gtk2
realname Z
email b...@theloosespoke.org.uk
no-cc
header X-Debbugs-CC: b...@theloosespoke.org.uk
smtphost reportbug.debian.org
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJUQ3J5AAoJEC8Z0Emvryki5QEIAJd3ht2DOm8Dgf32xE8fNoQl
+G1wvriZXyXYdH5FbctHTFoHrmQHFn43sQXTjy8JSMfpextQXir2fIHij0aRtdmw
ZCVxIHng+sW1A/0X2azDIsv+LVOgo2rPagoemDmZrf/p6phhoi3Ic1JbbfHf2ENT
Slzg/eClr4g1CBN63MRcpBIv1tuZ88IGwW3D4mTIGQMJSXIH0gB+yjM2ZkBkaeQn
67/CC2xmOdDIMks6qIf3vB7VDVHDmzOiJl/8IlfbeTHZ+dCJmFbi0ZLyRtiJIFeJ
ePJ961mX3fBl/XNSTKaUikkPCz+guyqCaqI1Qxm7GTLW6yCx1PbIlZaABf2GIj4=
=2Ie9
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758183: [gdm3] same issue

[bugs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: gdm3
Version: 3.14.0-1

- --- Please enter the report below this line. ---
I have had the same issue and it still persists in 3.14.

- --- System information. ---
Architecture: amd64
Kernel:   Linux 3.16-2-amd64

Debian Release: jessie/sid
  500 testing-updates ftp.uk.debian.org
  500 testing security.debian.org
  500 testing ftp.uk.debian.org
  500 testing deb.bitmask.net
  500 stable  deb.bitmask.net
1 experimentalftp.uk.debian.org

- --- Package information. ---
Depends (Version) | Installed
=-+-
libaccountsservice0(= 0.6.8) | 0.6.37-3+b1
libatk1.0-0   (= 1.12.4) | 2.14.0-1
libaudit1(= 1:2.2.1) | 1:2.4-1
libc6   (= 2.14) |
libcairo-gobject2 (= 1.10.0) |
libcairo2  (= 1.2.4) |
libcanberra-gtk3-0  (= 0.25) |
libcanberra0 (= 0.2) |
libgdk-pixbuf2.0-0(= 2.22.0) |
libgdm1(= 3.12.2-2.1) |
libglib2.0-0  (= 2.37.3) |
libgtk-3-0 (= 3.0.0) |
libpam0g(= 0.99.7.1) |
libpango-1.0-0(= 1.14.0) |
libpangocairo-1.0-0   (= 1.14.0) |
libselinux1 (= 1.32) |
libsystemd-daemon0(= 31) |
libsystemd-id128-0(= 38) |
libsystemd-journal0   (= 38) |
libsystemd-login0(= 186) |
libwrap0  (= 7.6-4~) |
libx11-6  |
libxau6   |
libxdmcp6 |
libxrandr2(= 2:1.2.99.3) |
dconf-gsettings-backend (= 0.20) |
debconf (= 0.5)  |
 OR debconf-2.0   |
gir1.2-gdm3(= 3.12.2-2.1) |
adduser   |
libpam-modules(= 0.72-1) |
libpam-runtime (= 0.76-13.1) |
libpam-systemd|
gnome-session-bin   (= 3.10) |
gnome-settings-daemon(= 3.2) |
gnome-shell(= 3.10.1-2~) |
gnome-session |
 OR x-session-manager |
 OR x-window-manager  |
 OR x-terminal-emulator   |
lsb-base  (= 3.2-14) |
librsvg2-common   |
accountsservice   (= 0.6.12) |
policykit-1 (= 0.105-5~) |
gsettings-desktop-schemas |
libglib2.0-bin(= 2.35.0) |
dconf-cli   (= 0.20) |
ucf   |
x11-common  (= 1:7.6+11) |
x11-xserver-utils |


Recommends (Version) | Installed
-+-===
zenity   | 3.14.0-1
xserver-xephyr   | 2:1.16.1-1
x11-xkb-utils| 7.7+1
xserver-xorg | 1:7.7+7
at-spi2-core | 2.12.0-2
gnome-icon-theme | 3.12.0-1
gnome-icon-theme-symbolic| 3.12.0-1
desktop-base  (= 6) | 7.0.3


Suggests  (Version) | Installed
===-+-===
libpam-gnome-keyring| 3.14.0-1
gnome-orca  | 3.14.0-1

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJUQ3WzAAoJEC8Z0Emvryki/E4IAJR4yMdGkdw0n0C5UUJKf+p2
SHMvz0A1VGFaho22qTuF3jwHGXKak7DEIkETXjt9As4qr4r39Pfo9ytKyegtE+iF
e2lZi0BagvFPifo2lx+3GU5rFvFsEtTXoqOWvYi/9cjrz9WnMw+s39xrjTlBdwcL
qWPvY8ZiiguNp+XQhJjwxNeP0A3WTnnnzI16mEJ33KasoE7Sl7Mzy3bBLeKAEqJh
zSeedKEoDw2TNLT7Tx1ym5bEpkfLvC2zMLq0JcKetAa127mFccXsp07O54fFH6nq
pvArtFXKM383FrzkXWPsQbTF0zCCii5YbLYhIa0rrx6sunbqHai1xoVfQrwEQXk=
=8M6A
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#749711: gdm3: When switching between users password requested twice unnecessarily.

[bugs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Laurent Bigonville:
 Hello,
 
 Could you please check if this is still an issue for you with the 
 latest version from unstable.
 
 Cheers,
 
 Laurent Bigonville
 

Nope, this seems to be solved with the update.
Thanks.
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJUCux6AAoJEC8Z0EmvrykiawIIAJbp/wo80Fmsdy5Ip1Hutwxw
vWMoTrkmhn5dLU3ge6TMUmlGCGlvc7E8L/NEHuzDyF4dlSeQM4hQ6kHGrHukJJWc
PfCrjENNiR/dsXEqhWImAyCCInWMj0uZudHpediS+UY7vQE8dLD9wNeaX9/UrGOK
4tj5KncIG531EN+PvvfXwGZQjcMgryPDro3vagc/vAoKyVvzv8YDw+0RhpPQUjgx
aP6HpWqCQDmmk9C4Tx7ytIamL5GvIDiTCQTFnDEUpnYuQDOIQYwW0AtA1OCdgULn
3chtPoJ5noybC5tzq4gL1ELMJRPduz7sylwXuHBz+/LOSNpyAp8VAfQ6GZBBVQI=
=lnFJ
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#739042: #739042 - nautilus: Says 'Contains Music' and tries to open with Banshee incorrectly.

[bugs]

Yes, I have reinstalled debian completely for another reason, and it
still happens on jessie/testing with 2.12.2-1, the same. I insert the
usb stick, and the notification pops up on the bottom saying 'Open with
Rhythmbox' or 'Eject', then when I open with nautilus, it says 'Contains
Music' and 'Rhythmbox'.

Pedro Beja:
 Hey,
 
 Could you please still reproduce this issue with newer nautilus version
 like 3.12.2-1 ?
 
 thanks
 regards
 Pedro
 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#755699: openjdk-7-jdk: trying to overwrite /usr/lib/jvm/java-7-openjdk-amd64/src.zip

[debian-bugs]

Package: openjdk-7-jdk
Version: 7u60-2.5.0-2
Justification: tries to overwrite contents of package openjdk-7-source 
7u60-2.5.0-2
Severity: serious

Dear Maintainer,

When upgrading openjdk-7-jdk from 7u60-2.5.0-2 to 7u65-2.5.1-2 it tries to 
overwrite the contents of openjdk-7-source 7u60-2.5.0-2 for file
/usr/lib/jvm/java-7-openjdk-amd64/src.zip

Here are the relevant lines from aptitude safe-upgrade:

Packar upp openjdk-7-jdk:amd64 (7u65-2.5.1-2) över (7u60-2.5.0-2) ...
dpkg: fel vid hantering av arkivet /var/cache/apt/archives/openjdk-7-
jdk_7u65-2.5.1-2_amd64.deb (--unpack):
 försöker skriva över /usr/lib/jvm/java-7-openjdk-amd64/src.zip som också 
finns i paketet openjdk-7-source 7u60-2.5.0-2




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

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages openjdk-7-jdk depends on:
ii  libc6  2.19-7
ii  libx11-6   2:1.6.2-2
ii  openjdk-7-jre  7u65-2.5.1-2

Versions of packages openjdk-7-jdk recommends:
ii  libxt-dev  1:1.1.4-1

Versions of packages openjdk-7-jdk suggests:
pn  openjdk-7-demonone
iu  openjdk-7-source  7u65-2.5.1-2
pn  visualvm  none

-- no debconf information


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#755699: (no subject)

[debian-bugs+755699]

Severity: serious


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#753097: openntpd: Linux doesn't have a SIGINFO (for stats dump to syslog)

[debian-bugs]

Package: openntpd
Version: 20080406p-5
Severity: normal

Dear Maintainer,

The openntpd man page says 

When  ntpd receives a SIGINFO signal, it will 
write its peer and sensor status to syslog.

However, Linux doesn't have a SIGINFO. 

I've attached a simple patch that uses SIGUSR1 instead of
SIGINFO to trigger the report.

  Thanks,
Osric Wilkinson

-- System Information:
Debian Release: 7.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-486
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages openntpd depends on:
ii  adduser  3.113+nmu3
ii  libc62.13-38+deb7u1
ii  libssl1.0.0  1.0.1e-2+deb7u11
ii  netbase  5.0

openntpd recommends no packages.

openntpd suggests no packages.

-- Configuration Files:
/etc/default/openntpd changed [not included]
/etc/openntpd/ntpd.conf changed [not included]

-- no debconf information

If you want to provide additional information, please wait to receive the bug
tracking number via email; you may then send any extra information to
n...@bugs.debian.org (e.g. 999...@bugs.debian.org), where n is the bug number.
Normally you will receive an acknowledgement via email including the bug report
number within an hour; if you haven't received a confirmation, then the bug
reporting process failed at some point (reportbug or MTA failure, BTS
maintenance, etc.).


openntpd-signals-fix.patch
Description: Binary data

Bug#748805: Bug only seems to affect system with a btrfs rootfs

[debian-bugs]

I've installed the same package on a Debian 7.5 that uses an ext4 rootfs
(running as a VirtualBox guest) and it boots without issues.
So apparently the problem only occurs with the combination of the 3.14
kernel image and a btrfs rootfs.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#748805: System fails to boot after upgrading to linux-image-3.14-0.bpo.1-amd64 from wheezy-backports

[debian-bugs]

Package: linux-image-3.14-0.bpo.1-amd64
Version: 3.14.4-1~bpo70+1

I'm running a freshly installed Debian 7.5 on a KVM guest system.
The rootfs resides in a btrfs subvolume.
To get access to the improvements to btrfs in newer kernel versions, I
added the wheezy-backports repository to /etc/apt/sources.list and
upgraded linux-image-amd64 from it, which installed
linux-image-3.14-0.bpo.1-amd64.
After the upgrade, the system fails to boot when the 3.14 kernel is
selected — error message below (OCRed, so there might still be a typo
somewhere in there).
The system still boots normally when I select the 3.2 kernel in the GRUB
menu.

The issue has happened on two different KVM guests on different hosts
(configured exactly the same otherwise).

When the 3.14 kernel failed to boot, I installed
linux-headers-3.13-0.bpo.1-amd64 instead, which has been booting and
working without issues for a few days now.

On-screen output during a failed boot attempt:
--8--
Decompressing Linux... Parsing ELF... done.
Booting the kernel.
Loading, please wait...00:03.0 C900 PCI2.10 PnP PHH+3FFC9E10+3FFB9E10 C900
modprobe: can’t load module btrfs (kernel/fs/btrfs/btrfs.ko): unknown symbol in
module, or unknown parameter
modprobe: can’t load module btrfs (kernel/fs/btrfs/btrfs.ko): unknown symbol in
module, or unknown parameter
mount: mounting /deu/disk/by-uuid/38709399-9e41-43c4-bb54-5db6135cf795 on /root
failed: No such device
mount: mounting /dev on /root/dev failed: No such file or directory
Target filesystem doesn’t have requested /sbin/init.
No init found. Try passing init= bootarg.
modprobe: module ehci-pci not found in modules.dep
modprobe: module ehci-orion not found in modules.dep
modprobe: module ehci-hcd not found in modules.dep
modprobe: module uhci-hcd not found in modules.dep
modprobe: module ohci-hcd not found in modules.dep
modprobe: module usbhid not found in modules.dep


BusyBox v1.20.2 (Debian 1:1.20.0-7) built-in shell (ash)
Enter ’help’ for a list of built-in commands.

bin/sh: can’t access tty: job control turned off
(initramfs)
--8--


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#729073: icedove won't start

[bugs]

 

Hi Carsten, 

Ok, thanks - I'll do that. sorry for posting this against the wrong bug.


Cheers, 

Nick 

On 2014-04-10 12:20, Carsten Schoenert wrote: 

 Hello Nick,
 
 Am 10.04.2014 12:51, schrieb Nick:
 
 I'm getting the same or similar bug after the most recent update. 
 Ironically, I first realised I had the problem after trying to debug 
 icedove, in relation to another bug ( 
 https://bugzilla.mozilla.org/show_bug.cgi?id=963114 [1] ). Icedove started 
 and first and showed the checking extensions compatibility dialogue. It said 
 the lightning (calendar) addon needed updating, which I did. It sorted that, 
 and then dissappeared. After that it wouldn't start again.
 
 you have installed the Lightning extension from Mozilla?
 Lightning *and* Icedove won't work together after version 24 because of
 internally symbol mismatch. Please use iceowl-extension from the Debian
 repositories instead of the Mozilla Lightning extension.
 
 The backtrace shows exactly the same error as bug #724688 [1].
 
 [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724688 [2]
 

Links:
--
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=963114
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724688

Bug#738352: Further information

[bugs]

I realised afterwards this could be a partial duplicate of bug #671594; 
however the second assertion I triggered is different from the one 
reported in that bug.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#696360: nvidia-glx: Sporadic X freezes in gnome shell ( 3.8)

[Bugs in package nvidia-glx (version 304.88) in wheezy]

Package: nvidia-glx
Version: 304.88-1+deb7u1
Followup-For: Bug #696360

I did this:
  59  apt-get purge nvidia*

  85  apt-get install build-essential

  107  uname -r
  108  apt-get install linux-headers-3.2.0-4-686-pae
  109  apt-get install module-assistant nvidia-kernel-common
  110  module-assistant auto-install nvidia
  111  m-a a-i nvidia
  112  depmod -a
  113  modprobe nvidia
  114  apt-get install nvidia-glx
  115  nano /etc/X11/xorg.conf

Section Device
...
...
Driver  nvidia
...
EndSection

  116  /etc/init.d/gdm3 restart




-- Package-specific info:
uname -a:
Linux desktop-debian 3.2.0-4-686-pae #1 SMP Debian 3.2.46-1 i686 GNU/Linux

/proc/version:
Linux version 3.2.0-4-686-pae (debian-ker...@lists.debian.org) (gcc version 
4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.46-1

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86 Kernel Module  304.88  Wed Mar 27 14:31:12 PDT 
2013
GCC version:  gcc version 4.6.3 (Debian 4.6.3-14) 

lspci 'VGA compatible controller [0300]':
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT218 [GeForce 
8400 GS] [10de:10c3] (rev a2) (prog-if 00 [VGA controller])
Subsystem: eVga.com. Corp. Device [3842:1302]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 16
Region 0: Memory at f600 (32-bit, non-prefetchable) [size=16M]
Region 1: Memory at e000 (64-bit, prefetchable) [size=256M]
Region 3: Memory at f000 (64-bit, prefetchable) [size=32M]
Region 5: I/O ports at e000 [size=128]
[virtual] Expansion ROM at f700 [disabled] [size=512K]
Capabilities: access denied
Kernel driver in use: nvidia

dmesg:
[0.00] Console: colour VGA+ 80x25
[0.555743] vgaarb: device added: 
PCI::01:00.0,decodes=io+mem,owns=io+mem,locks=none
[0.555745] vgaarb: loaded
[0.555746] vgaarb: bridge control possible :01:00.0
[1.223763] Linux agpgart interface v0.103
[5.465822] nvidia: module license 'NVIDIA' taints kernel.
[5.635186] nvidia :01:00.0: setting latency timer to 64
[5.635190] vgaarb: device changed decodes: 
PCI::01:00.0,olddecodes=io+mem,decodes=none:owns=io+mem
[5.635239] NVRM: loading NVIDIA UNIX x86 Kernel Module  304.88  Wed Mar 27 
14:31:12 PDT 2013
[7.134047] input: HDA NVidia HDMI/DP,pcm=9 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input4
[7.134235] input: HDA NVidia HDMI/DP,pcm=8 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input5
[7.134418] input: HDA NVidia HDMI/DP,pcm=7 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input6
[7.134603] input: HDA NVidia HDMI/DP,pcm=3 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input7

OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root   15 Aug  4 22:32 /etc/alternatives/glx - 
/usr/lib/nvidia
lrwxrwxrwx 1 root root   46 Aug  5 17:36 
/etc/alternatives/glx--libGL.so-i386-linux-gnu - 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so
lrwxrwxrwx 1 root root   46 Aug  5 17:36 
/etc/alternatives/glx--libGL.so-i386-linux-gnu - 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so
lrwxrwxrwx 1 root root   41 Aug  4 22:32 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu - 
/usr/lib/i386-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   41 Aug  4 22:32 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu - 
/usr/lib/i386-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   49 Aug  4 22:32 
/etc/alternatives/glx--libXvMCNVIDIA.so.1-i386-linux-gnu - 
/usr/lib/i386-linux-gnu/nvidia/libXvMCNVIDIA.so.1
lrwxrwxrwx 1 root root   57 Aug  4 22:32 
/etc/alternatives/glx--libXvMCNVIDIA_dynamic.so.1-i386-linux-gnu - 
/usr/lib/i386-linux-gnu/nvidia/libXvMCNVIDIA_dynamic.so.1
lrwxrwxrwx 1 root root   49 Aug  4 22:32 
/etc/alternatives/glx--libnvidia-cfg.so.1-i386-linux-gnu - 
/usr/lib/i386-linux-gnu/nvidia/libnvidia-cfg.so.1
lrwxrwxrwx 1 root root   25 Aug  4 22:32 
/etc/alternatives/glx--linux-libglx.so - /usr/lib/nvidia/libglx.so
lrwxrwxrwx 1 root root   36 Aug  4 22:32 
/etc/alternatives/glx--nvidia-bug-report.sh - 
/usr/lib/nvidia/nvidia-bug-report.sh
lrwxrwxrwx 1 root root   29 Aug  4 22:32 
/etc/alternatives/glx--nvidia_drv.so - /usr/lib/nvidia/nvidia_drv.so
lrwxrwxrwx 1 root root   22 Aug  5 17:36 /etc/alternatives/libGL.so-master 
- /usr/lib/mesa-diverted
lrwxrwxrwx 1 root root   23 Aug  4 22:32 /etc/alternatives/nvidia - 
/usr/lib/nvidia/current
lrwxrwxrwx 1 root root   49 Aug  4 22:32 
/etc/alternatives/nvidia--libGL.so.1-i386-linux-gnu - 
/usr/lib/i386-linux-gnu/nvidia/current/libGL.so.1
lrwxrwxrwx 1 root root   49 Aug  4 22:32 
/etc/alternatives/nvidia--libGL.so.1-i386-linux-gnu - 

Bug#606397: [patch] /etc/vnstat.conf: Unclear what 'system default value' for Locale is

[debian-bugs]

Hi,
  I've just encountered this problem too, and I think the problem is that 
vnstat is not calling setlocale with the empty string argument to set the 
locale from the environment (see 
http://www.gnu.org/software/libc/manual/html_node/Setting-the-Locale.html)

  A quick patch to fix it:

--- vnstat.c.old2011-05-31 23:29:51.0 +0100
+++ vnstat.c2013-08-06 07:55:16.0 +0100
@@ -72,6 +72,8 @@
} else {
if (getenv(LC_ALL)) {
setlocale(LC_ALL, getenv(LC_ALL));
+   } else {
+   setlocale(LC_ALL, );
}
}
strncpy(interface, default, 32);


I think the same thing is happening in vnstati.c. I've created a similar patch, 
but I haven't tested this one (I haven't used vnstati yet)

--- vnstati.c.old   2011-05-31 23:29:51.0 +0100
+++ vnstati.c   2013-08-06 08:20:53.0 +0100
@@ -65,6 +65,8 @@
} else {
if (getenv(LC_ALL)) {
setlocale(LC_ALL, getenv(LC_ALL));
+   } else {
+   setlocale(LC_ALL, );
}
}
strncpy(interface, cfg.iface, 32);


(I am in no way a locale expert, but I think the calls to setlocale(LC_ALL, 
getenv(LC_ALL)) should probably be removed)

  Hope this helps,
Osric.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#715332: icedove: when importing feeds quit icedove with segmentation fault

[bugs]

Sorry I just realised that didn't seem to work properly, the output 
isn't very helpful, I'm not sure what I need to do to make it more so.

On Mon 08 Jul 2013 11:17:10 BST, bugs wrote:


 On Mon 08 Jul 2013 10:18:19 BST, Carsten Schoenert wrote:
 Hello,

 On Mon, Jul 08, 2013 at 09:29:51AM +0100, River wrote:
 Package: icedove
 Version: 17.0.7-1~deb7u1
 Severity: normal

 Dear Maintainer,
* I set up a blogs and news feed account on icedove, and then I wanted to
 import my feeds. I clicked on manage subscriptions, clicked import, and 
 chose
 the .opml file. It appeared for a split second to be importing them, and 
 then
 icedove quit. I tried this again several times in terminal with icedove in
 safemode, and I got a consistent output every time of Segmentation fault 
 just
 as it terminates. I am still able to import feeds manually one by one, but 
 this
 is impractical with as many feeds as I have.
 I could not find any way to stop this happening. I know that this was not an
 issue that I experienced with icedove 10.x and has only come with icedove 
 17.x.

 Can you please provide some logs so we can see more that's going on
 there?
 http://wiki.debian.org/Icedove#Debugging

 Thanks
 Carsten


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#715332: icedove: when importing feeds quit icedove with segmentation fault

[bugs]

On Mon 08 Jul 2013 10:18:19 BST, Carsten Schoenert wrote:
 Hello,

 On Mon, Jul 08, 2013 at 09:29:51AM +0100, River wrote:
 Package: icedove
 Version: 17.0.7-1~deb7u1
 Severity: normal

 Dear Maintainer,
* I set up a blogs and news feed account on icedove, and then I wanted to
 import my feeds. I clicked on manage subscriptions, clicked import, and chose
 the .opml file. It appeared for a split second to be importing them, and then
 icedove quit. I tried this again several times in terminal with icedove in
 safemode, and I got a consistent output every time of Segmentation fault 
 just
 as it terminates. I am still able to import feeds manually one by one, but 
 this
 is impractical with as many feeds as I have.
 I could not find any way to stop this happening. I know that this was not an
 issue that I experienced with icedove 10.x and has only come with icedove 
 17.x.

 Can you please provide some logs so we can see more that's going on
 there?
 http://wiki.debian.org/Icedove#Debugging

 Thanks
 Carsten
Warning: unrecognized command line flag -g

Bug#709593: dovecot-managesieve: checkpassword Temporary authentication failure/TRYLATER protocol error

[debian-bugs]

Package: dovecot-managesieved
Version: 1:2.1.7-7
Severity: important
File: dovecot-managesieve
Tags: upstream

Dear Maintainer,

I'm using checkpassword (http://wiki.dovecot.org/AuthDatabase/CheckPassword)
as an authentication method for managesieve, however when the checkpassword
script exits with code 111 (Temporary authentication failure) managesieved
outputs a message that is wrong per rfc5804:

$ nc localhost 4190
S: IMPLEMENTATION Dovecot Pigeonhole
S: SIEVE fileinto reject envelope encoded-character vacation subaddress
S: comparator-i;ascii-numeric relational regex imap4flags copy include
S: variables body enotify environment mailbox date ihave
S: NOTIFY mailto
S: SASL PLAIN
S: STARTTLS
S: VERSION 1.0
S: OK Dovecot ready.

C: AUTHENTICATE PLAIN AHRlc3QAdGVzdA==

S: NO [TRYLATER] Temporary authentication failure. [hathor:2013-05-24
S: 07:56:09]

That last server line should be NO (TRYLATER) (that is, round brackets
rather than square brakets).


Example checkpassword script:

#!/usr/bin/perl -w

exit(111)



-- Package-specific info:

dovecot configuration
-
# 2.1.7: /etc/dovecot/dovecot.conf
# OS: Linux 3.2.0-4-486 i686 Debian 7.0 ext3
auth_debug = yes
auth_username_chars = 
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@*
first_valid_uid = 116
last_valid_uid = 116
lda_mailbox_autocreate = yes
mail_gid = vmail
mail_location = maildir:/home/vmail/mail/%u/Maildir
mail_uid = vmail
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope encoded-character 
vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy 
include variables body enotify environment mailbox date ihave
namespace inbox {
  inbox = yes
  location = 
  mailbox Drafts {
special_use = \Drafts
  }
  mailbox Junk {
special_use = \Junk
  }
  mailbox Sent {
special_use = \Sent
  }
  mailbox Sent Messages {
special_use = \Sent
  }
  mailbox Trash {
special_use = \Trash
  }
  prefix = 
}
passdb {
  args = /home/osric/bin/checkpassword
  driver = checkpassword
}
plugin {
  sieve = ~/dovecot.sieve
  sieve_dir = ~/sieve
}
postmaster_address = postmaster@address hidden
protocols = imap sieve
service imap-login {
  inet_listener imap {
port = 143
  }
  process_min_avail = 0
  service_count = 1
}
service managesieve-login {
  inet_listener sieve {
port = 4190
  }
  process_min_avail = 0
  service_count = 1
}
ssl_cert = /etc/dovecot/dovecot.pem
ssl_key = /etc/dovecot/private/dovecot.pem
userdb {
  args = uid=vmail gid=vmail home=/home/vmail/mail/%n allow_all_users=yes
  driver = static
}
protocol sieve {
  mail_max_userip_connections = 2
}

-- System Information:
Debian Release: 7.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-486
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages dovecot-managesieved depends on:
ii  dovecot-core   1:2.1.7-7
ii  dovecot-sieve  1:2.1.7-7
ii  libc6  2.13-38
ii  libssl1.0.01.0.1e-2
ii  ucf3.0025+nmu3

dovecot-managesieved recommends no packages.

dovecot-managesieved suggests no packages.

Versions of packages dovecot-managesieved is related to:
ii  dovecot-core [dovecot-common]  1:2.1.7-7
pn  dovecot-dbgnone
pn  dovecot-devnone
pn  dovecot-gssapi none
ii  dovecot-imapd  1:2.1.7-7
pn  dovecot-ldap   none
pn  dovecot-lmtpd  none
ii  dovecot-managesieved   1:2.1.7-7
ii  dovecot-mysql  1:2.1.7-7
pn  dovecot-pgsql  none
pn  dovecot-pop3d  none
ii  dovecot-sieve  1:2.1.7-7
pn  dovecot-sqlite none

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#707683: knot: init script searches for /etc/default/knotd but package install /etc/default/knot

[debian-bugs]

Package: knot
Version: 1.2.0-1
Severity: normal

Dear Maintainer,

knot packages installs /etc/default/knot but init script searches for 
/etc/default/knotd:
 
NAME=knotd # Introduce the short server's name here
DAEMON=/usr/sbin/$NAME # Introduce the server's location here
DAEMON_ARGS=-d # Arguments to run the daemon with
PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME
 
# Read configuration variable file if it is present
[ -r /etc/default/$NAME ]  . /etc/default/$NAME
 

Therefore this init configuration file will never be sourced. 
The best way to fix this is probably to install /etc/default/knotd.

Martin


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

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages knot depends on:
ii  libc62.13-38
ii  libssl1.0.0  1.0.1e-2
ii  liburcu1 0.7.6-1
ii  zlib1g   1:1.2.7.dfsg-13

knot recommends no packages.

knot suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#707685: knot: running knot as non-root prevents /var/run/knotd.pid from being created

[debian-bugs]

Package: knot
Version: 1.2.0-1
Severity: normal

Dear Maintainer,

when running knot as a different user from root the pid file /var/run/knotd.pid 
cannot be created as /run on debian doesn't have write permissions for all.

without this pid file knot cannot be stopped using the init script.

the quick workaround is to put the pid file creation in /etc/default/knotd and 
change
the ownership there but this hardly seems like the best solution.

mk


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

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages knot depends on:
ii  libc62.13-38
ii  libssl1.0.0  1.0.1e-2
ii  liburcu1 0.7.6-1
ii  zlib1g   1:1.2.7.dfsg-13

knot recommends no packages.

knot suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org