Bug#1037050: Please package libstd-rust-dev-macos

[Matt Corallo]

Package: src:rustc
Version: 1.63.0+dfsg1-2

Similar to libstd-rust-dev-windows, it would be nice to have a macos version as well, which is 
generally well-supported by clang/LLVM/rustc.

Bug#1028031: Acknowledgement (Main spamassassin.service file missing)

[Matt Corallo]

Ah, sorry for the noise, the package was split. Seems funny to do in a backport.

Should the package split get a changelog notice for the bullseye upgrade? I'd assume most users of 
spamassassin actually use the spamd feature, so it being silently removed may be surprising for an 
upgrade.


Thanks for maintaining the package!

On 1/5/23 7:09 PM, Debian Bug Tracking System wrote:

Thank you for filing a new Bug report with Debian.

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

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
  Noah Meyerhans 

If you wish to submit further information on this problem, please
send it to 1028...@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#1028031: Main spamassassin.service file missing

[Matt Corallo]

Package: spamassassin
Version: 4.0.0-1~bpo11+1

It seems the main spamassassin.service file was lost in the 4.0 upgrade.

Bug#1028030: /usr/sbin/spamassassin-maint makes reference to /etc/init.d/spamd

[Matt Corallo]

Package: spamassassin
Version: 4.0.0-1~bpo11+1

/etc/init.d/spamd does not exist (and in the 3.X branch it's 
/etc/init.d/spamassassin).

Bug#1016543: rsync CVE-2022-29154 not being applies on -security

[Matt Corallo]

Hi!

I was pointed to rsync CVE-2022-29154 and noted that both Debian and Ubuntu didn't apply the fix on 
the security repos. From what I can tell they've been treated as mild, seemingly in part due to an 
assumption that clients rarely fetch data from untrusted servers?


At least in the context of packages like rpki-client, a security vulnerability allowing a malicious 
server to overwrite arbitrary files on the client's filesystem would allow said server to remove any 
internet network from the global routing table of most large ISPs, allowing them to effectively nuke 
any network on the internet for some time.


I hope I'm misinformed and I'm simply misreading the description provided.

Thanks,
Matt

Bug#1018918: Please Consider Building the stub_status module

[Matt Corallo]

Package: src:nginx
Version: 1.22.0-3

The http_stub_status module is not built by default but is useful to monitor a running server. In 
fact, another package (prometheus-nginx-exporter) relies on stub_status to operate. Please consider 
building it as an optional package as with other nginx modules.

Bug#1017963: Please Consider Building the ngx_http_gzip_static_module

[Matt Corallo]

Package: src:nginx
Version: 1.18.0-6.1+deb11u2

The ngx_http_gzip_static_module is not built by default per 
https://nginx.org/en/docs/http/ngx_http_gzip_static_module.html but is otherwise very useful. Please 
consider building it as an optional package as with other nginx modules.


THanks

Bug#1004740: exim4: SIGSEGV (maybe attempt to write to immutable memory) when sending a mail; message frozen

[Matt Corallo]

On 5/11/22 8:09 AM, Gedalya wrote:

I'm a little dazzled by the variety of crashes I've seen so far: smtp_setup_conn > 
tls_client_start > verify_certificate, and during ARC signing, but it could be 
just noise so I'll leave it alone for now.



As a passer-by might I suggest valgrind or building with address/undefined-behavior sanitizer? I 
don't see any mention of it in this issue, and "it keeps crashing in random places that may or may 
not be related" screams "memory corruption".


Matt

Bug#1010293: Please enable CONFIG_CRYPTO_CRC32C_VPMSUM on ppc64el (and other power)

[Matt Corallo]

Package: src:linux
Version: 5.16.12-1~bpo11+1

Pretty self-explanatory - its set in the upstream ppc64_defconfig, powernv_defconfig, and 
pseries_defconfig but not set in debian.

Bug#999435: APT::Default-Release "bullseye" disables bullseye-security

[Matt Corallo]

Package: apt
Version: 2.2.4

Default-Release now prefers the main archive over the security archive. This seems to be a behavior 
change from buster, presumably due to the renaming of the -security archive. eg


# apt-cache policy dnsutils
dnsutils:
  Installed: (none)
  Candidate: 1:9.16.15-1
  Version table:
 1:9.16.22-1~deb11u1 500
500 http://security.debian.org/debian-security bullseye-security/main 
arm64 Packages
 1:9.16.15-1 990
990 http://deb.debian.org/debian bullseye/main arm64 Packages

Bug#979665: [Pkg-rust-maintainers] Bug#979665: Please package libstd-rust-dev-emscripten

[Matt Corallo]

I'm not exactly an expert on the subject, but my understanding roughly matches yours. wasi is newer and not yet 100% 
feature complete, but once it is my understanding is that it should/will be a much better replacement for emscripten.


Matt

On 6/15/21 16:36, Ximin Luo wrote:

Thanks for the update.

Is there much point supporting rust emscripten at all? Apart from this 
C-linking thing that is now apparently fixed, what is the actual advantage (or 
even, point) of it?

 From what I understand from [1] it seems that emscripten does for C what 
wasm32-wasi and/or web-sys, js-sys already does for rust?

X

[1] 
https://stackoverflow.com/questions/64690937/what-is-the-difference-between-emscripten-and-clang-in-terms-of-webassembly-comp

Matt Corallo:

This is no longer the case. As of https://github.com/rust-lang/rust/pull/79998 
(rustc 1.51) you can now link C and rust code with the wasm32-wasi target.

On 1/9/21 16:16, Matt Corallo wrote:

Package: src:rustc
Version: 1.48.0+dfsg1-2

Due to issues with the way rustc interacts with LLVM-wasm [1], building rust 
packages with --target=wasm-unknown-{wasi,unknown} is not practical if any C 
code is to be used in the same binary (which is common). Instead, 
wasm-unknown-emscripten is the only option, however not librust-std is packaged 
for emscripten. rustup's emscripten is broken on debian testing due to them 
shipping their own LLVM, so that is also not a practical solution for most 
users wishing to link C and rust code in any context, let alone WASM.


[1] https://github.com/rustwasm/team/issues/291


___
Pkg-rust-maintainers mailing list
pkg-rust-maintain...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers

Bug#989844: Cross-compilation support (please package more libstd-rust-dev-*)

[Matt Corallo]

Package: src:rustc
Version: 1.48.0+dfsg1-2

It would be nice to support cross-compilation in the Debian rustc builds, both across-platforms targeting linux and for 
additional targets in the host platform (eg apple-darwin, assuming its possible to build std without the proprietary 
apple sysroot), or freebsd/android/etc. I assume the biggest requirement there is just packaging the libstd.

Bug#979665: Please package libstd-rust-dev-emscripten

[Matt Corallo]

This is no longer the case. As of https://github.com/rust-lang/rust/pull/79998 (rustc 1.51) you can now link C and rust 
code with the wasm32-wasi target.


On 1/9/21 16:16, Matt Corallo wrote:

Package: src:rustc
Version: 1.48.0+dfsg1-2

Due to issues with the way rustc interacts with LLVM-wasm [1], building rust packages with 
--target=wasm-unknown-{wasi,unknown} is not practical if any C code is to be used in the same binary (which is common). 
Instead, wasm-unknown-emscripten is the only option, however not librust-std is packaged for emscripten. rustup's 
emscripten is broken on debian testing due to them shipping their own LLVM, so that is also not a practical solution for 
most users wishing to link C and rust code in any context, let alone WASM.



[1] https://github.com/rustwasm/team/issues/291

Bug#989317: systemd kill background processes after user logs out (#825394 regression)

[Matt Corallo]

On 6/8/21 14:02, Michael Biebl wrote:
Is there an alternate way to run things that lxc should instead be recommending? In my interactions with the lxc folks 
it seems this workaround is only relevant for Debian bullseye, so maybe other distros are patching systemd or changing 
cgroup settings such that interacting with systemd isn't required.


Are you sure? Which distros are that? Which exact version of that distro?


No, I'm not sure, but that was the response any time I mentioned systemd-run was immediately "I assume Debian bullseye 
or something". Its possible it also impacts fedora and the Ubuntu folks just have some crazy workaround that doesn't 
really make sense.


Similar to the discussion in 825394, having daemons  spontaneously killed is incredibly surprising, maybe it makes 
sense to enable-linger by default?


That's not a good idea I think.
Starting long running daemons from a user session is not the norm, I'd argue.


Would defer to you, I've never seen systemd-run used or mentioned anywhere 
outside of lxc.


In any case, I'm not sure there remains anything to be done on the systemd 
side. Afaics, everything behaves as documented.


Sounds good.

Bug#989317: systemd kill background processes after user logs out (#825394 regression)

[Matt Corallo]

On 6/8/21 12:31, Michael Biebl wrote:

Am 08.06.2021 um 18:08 schrieb Matt Corallo:
Hmmm, with set-linger and --scope I can't seem to reproduce now either, its possible I had forgotten the --scope at 
some point while testing set-linger before, sorry for the noise here.


Still, based on my read of #825394, it seems like it should be the case that you do not need set-linger and the 
default behavior should be that things aren't automatically killed in the background? Is that something that was an 
intentional change?


Change to what exactly?

I guess we need to differentiate between login and user sessions.
It's my understanding that KillUserProcesses= only affects a login session.


I admit I am definitely not a systemd expert (which I suppose should be obvious by now :) ), so have no idea what this 
means, and systemd-run's man page doesn't really elucidate it. Not Debian's or your problem, of course, though.


If you start a process as part of a user session (which is what systemd-run --user does), ending that user session will 
stop that process.


Is there an alternate way to run things that lxc should instead be recommending? In my interactions with the lxc folks 
it seems this workaround is only relevant for Debian bullseye, so maybe other distros are patching systemd or changing 
cgroup settings such that interacting with systemd isn't required.


Similar to the discussion in 825394, having daemons  spontaneously killed is incredibly surprising, maybe it makes sense 
to enable-linger by default?


> Did you use systemd-run in buster to start your lxc containers?
> You need to be very explicit, otherwise I can only guess what exactly you 
were/are doing.

No, but also didn't need to, its only with bullseye that (systemd's ?) cgroup settings prevent direct calls to 
lxc-start, which is what makes the whole thing such a mess - one cannot simply call lxc functions anymore because 
systemd gets in the way. Using systemd for this, sadly, is an excercize in puzzling through man pages and lack of 
documentation for how to do any of this (half of the lxc docs for how to do this are because I had to ask lxc 
maintainers how to do basic lxc things with bullseye).


Thanks,
Matt

Bug#989317: systemd kill background processes after user logs out (#825394 regression)

[Matt Corallo]

Hmmm, with set-linger and --scope I can't seem to reproduce now either, its possible I had forgotten the --scope at some 
point while testing set-linger before, sorry for the noise here.


Still, based on my read of #825394, it seems like it should be the case that you do not need set-linger and the default 
behavior should be that things aren't automatically killed in the background? Is that something that was an intentional 
change?


The systemd-run manpage seems to indicate that with debian's default change of KillUserProcesses=no this should not 
occur with or without linger. In either case, it seems the manpage should be updated to describe this behavior, and 
maybe updated to mention that KilUserProcesses is *not* the default on Debian, which it states in the EXAMPLES section.


Thanks,
Matt

On 6/8/21 10:19, Michael Biebl wrote:

Control: tags -1 + unreproducible

So, I've been following the instructions in /usr/share/doc/lxc/README.Debian to 
allow unprivileged containers.

After that, I could successfully run a container. I used the command line as 
suggested in that README.Debian:

$ systemd-run --scope --quiet --user --property=Delegate=yes \
     lxc-start -n mycontainer


Once I logged out, the systemd --user session was stopped including the 
container, which is expected, as ansgar wrote.

After enabling "linger" for that user, the systemd --user session was not stopped anymore after logging out and the 
container continued running.


I'm thus marking this bug report as unreproducible.

(note that the lxc maintainers recommend to use --scope with systemd-run)

Michael

Bug#989317: systemd kill background processes after user logs out (#825394 regression)

[Matt Corallo]

Is there any further information I can provide to help debug this (or should it 
get a -moreinfo)?

Note that of interest may be that the workaround of spawning in a screen session only works if lxc-start is passed the 
-F command which places it in the foreground (though sshd still gets the -D option running inside the container).


Matt

On 6/1/21 11:26, Matt Corallo wrote:

Is your sshd configured to use PAM?


Yes, "UsePAM yes" is in the sshd_config (I don't believe I've changed that, it 
appears to be the default?).


So, you log in via ssh, then start a (second) sshd process (inside a lxc 
container) via the above command?


That is correct, yes.


Would be great to have a set a commands which allows us reproduce the problem.


The above command paste should basically do it, eg install lxc, then `lxc-create --name fuzzer -t download` to create a 
(debian) container, then install sshd inside of it via apt, then run the `systemd-run --user -p "Delegate=yes" 
--unit=fuzzer -- lxc-start --name fuzzer -- /usr/sbin/sshd -D` command to spawn it, then log out of the ssh session 
which spawned it. There's likely some network configuration which needs to happen in between but I don't know off-hand 
how to set it up without public IPs for things.



Once you started the process, can you create a systemd-cgls output and attach 
it to this bug report.


Relevant bits post-spawn:

Control group /:
-.slice
├─user.slice
│ └─user-1000.slice
│   ├─user@1000.service
│   │ ├─app.slice
│   │ │ └─run-rc291ab200158464d9b477a247d01a095.service
│   │ │   ├─lxc.payload.fuzzer
│   │ │   │ └─12319 /usr/sbin/sshd -D
│   │ │   └─lxc.monitor.fuzzer
│   │ │ └─12313 [lxc monitor] /home/matt/.local/share/lxc fuzzer
│   │ └─init.scope
│   │   ├─1164 /lib/systemd/systemd --user
│   │   └─1165 (sd-pam)
│   ├─session-24.scope
│   │ ├─12207 sshd: matt [priv]
│   │ ├─12213 sshd: matt@pts/0
│   │ ├─12214 -bash
│   │ └─12374 systemd-cgls
│   └─session-1.scope
│ ├─1192 SCREEN
│ └─1193 /bin/bash



On 6/1/21 11:20, Michael Biebl wrote:

Am 01.06.2021 um 17:18 schrieb Michael Biebl:

Am 01.06.2021 um 16:24 schrieb Matt Corallo:

No, the shell is spawned from sshd (and almost nothing else running on the 
host).

On 6/1/21 04:22, Michael Biebl wrote:

Control: tags -1 + moreinfo

Am 01.06.2021 um 02:37 schrieb Matt Corallo:
After upgrading to bullseye on a test machine, spawning an lxc container with systemd-run[1] still kills the lxc 
container after the spawning shell is closed (and the user logs out). No only does the lxc container eventually 
get killed, but systemd refuses any further login for the user while it waits for the lxc container to die 
(something like maybe 30 seconds for a simple lxc container running an sshd service), making it appear the system 
has hung.


This doesn't appear to be resolved by the options suggested in the man page for systemd-run like `loginctl 
enable-linger` or `KillUserProcesses=no` (which appears to still be the default).


Matt

[1] eg systemd-run --user -p "Delegate=yes" --unit=fuzzer -- lxc-start --name 
fuzzer -- /usr/sbin/sshd -D


So, you log in via ssh, then start a (second) sshd process (inside a lxc 
container) via the above command?


Would be great to have a set a commands which allows us reproduce the problem.

Bug#989317: systemd kill background processes after user logs out (#825394 regression)

[Matt Corallo]

> Is your sshd configured to use PAM?

Yes, "UsePAM yes" is in the sshd_config (I don't believe I've changed that, it 
appears to be the default?).

> So, you log in via ssh, then start a (second) sshd process (inside a lxc 
container) via the above command?

That is correct, yes.

> Would be great to have a set a commands which allows us reproduce the problem.

The above command paste should basically do it, eg install lxc, then `lxc-create --name fuzzer -t download` to create a 
(debian) container, then install sshd inside of it via apt, then run the `systemd-run --user -p "Delegate=yes" 
--unit=fuzzer -- lxc-start --name fuzzer -- /usr/sbin/sshd -D` command to spawn it, then log out of the ssh session 
which spawned it. There's likely some network configuration which needs to happen in between but I don't know off-hand 
how to set it up without public IPs for things.


> Once you started the process, can you create a systemd-cgls output and attach 
it to this bug report.

Relevant bits post-spawn:

Control group /:
-.slice
├─user.slice
│ └─user-1000.slice
│   ├─user@1000.service
│   │ ├─app.slice
│   │ │ └─run-rc291ab200158464d9b477a247d01a095.service
│   │ │   ├─lxc.payload.fuzzer
│   │ │   │ └─12319 /usr/sbin/sshd -D
│   │ │   └─lxc.monitor.fuzzer
│   │ │ └─12313 [lxc monitor] /home/matt/.local/share/lxc fuzzer
│   │ └─init.scope
│   │   ├─1164 /lib/systemd/systemd --user
│   │   └─1165 (sd-pam)
│   ├─session-24.scope
│   │ ├─12207 sshd: matt [priv]
│   │ ├─12213 sshd: matt@pts/0
│   │ ├─12214 -bash
│   │ └─12374 systemd-cgls
│   └─session-1.scope
│ ├─1192 SCREEN
│ └─1193 /bin/bash



On 6/1/21 11:20, Michael Biebl wrote:

Am 01.06.2021 um 17:18 schrieb Michael Biebl:

Am 01.06.2021 um 16:24 schrieb Matt Corallo:

No, the shell is spawned from sshd (and almost nothing else running on the 
host).

On 6/1/21 04:22, Michael Biebl wrote:

Control: tags -1 + moreinfo

Am 01.06.2021 um 02:37 schrieb Matt Corallo:
After upgrading to bullseye on a test machine, spawning an lxc container with systemd-run[1] still kills the lxc 
container after the spawning shell is closed (and the user logs out). No only does the lxc container eventually get 
killed, but systemd refuses any further login for the user while it waits for the lxc container to die (something 
like maybe 30 seconds for a simple lxc container running an sshd service), making it appear the system has hung.


This doesn't appear to be resolved by the options suggested in the man page for systemd-run like `loginctl 
enable-linger` or `KillUserProcesses=no` (which appears to still be the default).


Matt

[1] eg systemd-run --user -p "Delegate=yes" --unit=fuzzer -- lxc-start --name 
fuzzer -- /usr/sbin/sshd -D


So, you log in via ssh, then start a (second) sshd process (inside a lxc 
container) via the above command?


Would be great to have a set a commands which allows us reproduce the problem.

Bug#989317: systemd kill background processes after user logs out (#825394 regression)

[Matt Corallo]

Please see the issue description - `loginctl enable-linger` does not change the behavior. The suggestions in 
systemd-run's manpage for how to address this issue do not work.


On 6/1/21 07:15, Ansgar wrote:

On Mon, 2021-05-31 at 20:37 -0400, Matt Corallo wrote:

[1] eg systemd-run --user -p "Delegate=yes" --unit=fuzzer -- lxc-
start --name fuzzer -- /usr/sbin/sshd -D


I think this is treated like a user .service unit.

So what happen should be: user logs out and no processes are left as
part of the login session[*].  As a result the `systemd --user` session
is shut down.  This causes all user units to be shut down, including
the process started by systemd-run.

To keep user units running, you would need to have the `systemd --user`
instance never shut down after logout which I don't think is the best
default behavior.  Or some way to switch this on-demand.  This is half
of what `loginctl enable-linger` does (but that setting also always
starts the `systemd --user` instance for the given users which is not
needed here).

Ansgar

   [*]: These processes are what "KillUserProcesses" are about AFAIU.

Bug#989317: systemd kill background processes after user logs out (#825394 regression)

[Matt Corallo]

No, the shell is spawned from sshd (and almost nothing else running on the 
host).

On 6/1/21 04:22, Michael Biebl wrote:

Control: tags -1 + moreinfo

Am 01.06.2021 um 02:37 schrieb Matt Corallo:
After upgrading to bullseye on a test machine, spawning an lxc container with systemd-run[1] still kills the lxc 
container after the spawning shell is closed (and the user logs out). No only does the lxc container eventually get 
killed, but systemd refuses any further login for the user while it waits for the lxc container to die (something like 
maybe 30 seconds for a simple lxc container running an sshd service), making it appear the system has hung.


This doesn't appear to be resolved by the options suggested in the man page for systemd-run like `loginctl 
enable-linger` or `KillUserProcesses=no` (which appears to still be the default).


Matt

[1] eg systemd-run --user -p "Delegate=yes" --unit=fuzzer -- lxc-start --name 
fuzzer -- /usr/sbin/sshd -D


Are you using a desktop environment to start your shell/terminal?
If so, which desktop environment is it exactly? Which terminal emulator do you 
use?

Bug#989317: Acknowledgement (systemd kill background processes after user logs out (#825394 regression))

[Matt Corallo]

The following work-around appears to work:

(a) ssh in and spawn screen, (b) disconnect the ssh session which spawned screen, (c) ssh to open a new session, (d) log 
back into screen, (e) spawn a container from inside screen.


On 5/31/21 20:51, Debian Bug Tracking System wrote:

Thank you for filing a new Bug report with Debian.

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

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
  Debian systemd Maintainers 

If you wish to submit further information on this problem, please
send it to 989...@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#989317: systemd kill background processes after user logs out (#825394 regression)

[Matt Corallo]

Package: systemd
Version: 247.3-5

After upgrading to bullseye on a test machine, spawning an lxc container with systemd-run[1] still kills the lxc 
container after the spawning shell is closed (and the user logs out). No only does the lxc container eventually get 
killed, but systemd refuses any further login for the user while it waits for the lxc container to die (something like 
maybe 30 seconds for a simple lxc container running an sshd service), making it appear the system has hung.


This doesn't appear to be resolved by the options suggested in the man page for systemd-run like `loginctl 
enable-linger` or `KillUserProcesses=no` (which appears to still be the default).


Matt

[1] eg systemd-run --user -p "Delegate=yes" --unit=fuzzer -- lxc-start --name 
fuzzer -- /usr/sbin/sshd -D

Bug#955208: [Pkg-rust-maintainers] Bug#955208: Bug#955208: rustc: rustup is not available on Debian

[Matt Corallo]

I was just trying to ensure that the trust chain was correct here as some of the earlier comments seemed confused - 
unlike most other things that install software in $HOME, rustup doesn't fetch source (and optionally compile it), it 
just fetches binaries from the same source that provides rustup itself. Last I checked, it didn't even have signatures 
on them, only, as you note, checking via X509 root CAs. If people want to use that (and package it), of course.


Matt

On 3/26/21 10:19, Ximin Luo wrote:

Not sure what your purpose is with your comment. Nobody is asking you to 
package it. If somebody else wants to, this doesn't affect you, you don't have 
to install it.

Packaging 3rd party software in general gives the user a trust chain from 
Debian trust keys to that software, rather than e.g. via HTTPS X509 root CAs.

Lots of package managers are packaged in Debian that install other software 
into $HOME, such as cargo itself, opam, cabal, gem, pypi, etc etc etc.

X

Matt Corallo:

What is the use-case for rustup being packaged? rustup is just a thin wrapper 
around downloading binaries from a third party, so why not just download it 
from the same third-party? It is geared at installing things in the local 
users' home directory anyway.

Packaging rustup doesn't address the many limitations of rustup's rustc vs 
Debian's (excellently-packaged) rustc (eg cross-language LTO, LLVM plugins, 
etc).

Matt

On Sat, 4 Apr 2020 01:19:59 +0100 Ximin Luo  wrote:

Hi all,

I agree that rustup should be in Debian. Achieving this is currently blocked on 
either of these two issues:

- https://github.com/rust-lang/rustup/issues/835 OR
- https://salsa.debian.org/rust-team/debcargo/-/merge_requests/22

If you want to help, achieving either of these would help to unblock progress.

X

Ralph Giles:

I would also like to start off with a Debian-packaged rustup rather
than having to install it from upstream.

It's been discussed before, but I think no one was pursuaded to start

maintaining a package. IIRC one issue was that rustup likes to update
itself. You'd need to check how difficult it would be to have the
system rustup always just install any updates in the user's .cargo
subtree, without trying to write to the root filesytem. The user's
local version would then take precedence through the normal PATH
setting.

I think there was also some concern about support over the lifetime of

a debian release, should upstream change their API sufficiently to stop
the packaged version working.

   -r
On Sat, 2020-03-28 at 14:04 +0100, Martin Monperrus wrote:
Package: rustc
Version: 1.40.0+dfsg1-5
Severity: normal

Dear Awesome Rust Debian Maintainers,

I notice that rustup is not packaged for Debian. One option is to go
through
snap (https://snapcraft.io/install/rustup/debian) but native packages
are
preferable.

Since rustup is used by many projects, it would be great to have it
natively on
Debian:

apt-get install rustup

What do you think?

Best regards,

--Martin





-- System Information:
Debian Release: bullseye/sid


___
Pkg-rust-maintainers mailing list
pkg-rust-maintain...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers

Bug#955208: [Pkg-rust-maintainers] Bug#955208: rustc: rustup is not available on Debian

[Matt Corallo]

What is the use-case for rustup being packaged? rustup is just a thin wrapper around downloading binaries from a third 
party, so why not just download it from the same third-party? It is geared at installing things in the local users' home 
directory anyway.


Packaging rustup doesn't address the many limitations of rustup's rustc vs Debian's (excellently-packaged) rustc (eg 
cross-language LTO, LLVM plugins, etc).


Matt

On Sat, 4 Apr 2020 01:19:59 +0100 Ximin Luo  wrote:

Hi all,

I agree that rustup should be in Debian. Achieving this is currently blocked on 
either of these two issues:

- https://github.com/rust-lang/rustup/issues/835 OR
- https://salsa.debian.org/rust-team/debcargo/-/merge_requests/22

If you want to help, achieving either of these would help to unblock progress.

X

Ralph Giles:
> I would also like to start off with a Debian-packaged rustup rather
> than having to install it from upstream.
> 
> It's been discussed before, but I think no one was pursuaded to start

> maintaining a package. IIRC one issue was that rustup likes to update
> itself. You'd need to check how difficult it would be to have the
> system rustup always just install any updates in the user's .cargo
> subtree, without trying to write to the root filesytem. The user's
> local version would then take precedence through the normal PATH
> setting.
> 
> I think there was also some concern about support over the lifetime of

> a debian release, should upstream change their API sufficiently to stop
> the packaged version working.
> 
>  -r
> 
> On Sat, 2020-03-28 at 14:04 +0100, Martin Monperrus wrote:

>> Package: rustc
>> Version: 1.40.0+dfsg1-5
>> Severity: normal
>>
>> Dear Awesome Rust Debian Maintainers,
>>
>> I notice that rustup is not packaged for Debian. One option is to go
>> through
>> snap (https://snapcraft.io/install/rustup/debian) but native packages
>> are
>> preferable.
>>
>> Since rustup is used by many projects, it would be great to have it
>> natively on
>> Debian:
>>
>> apt-get install rustup
>>
>> What do you think?
>>
>> Best regards,
>>
>> --Martin
>>
>>
>>
>>
>>
>> -- System Information:
>> Debian Release: bullseye/sid

Bug#982507: lxc-net/dnsmasq-base shouldn't be required

[Matt Corallo]

Package: lxc
Version: 1:4.0.6-1

I've been happily using lxc on debian for some time, without dnsmasq-base or lxc-net. The recent addition of 
dnsmasq-base and lxc-net as a required dependency is somewhat surprising, given lxc-net edits IP address information for 
lxc-attched bridges which were created outside of lxc-net, and dnsmasq doubly so given DSA 4844-1 was only a few days 
ago. Several commentors on IRC seemed equally surprised by this change.


Is there more information available for why lxc-net is now an explicit dependency and not optional or can this change be 
reverted?


Thanks for all the work keeping lxc working!
Matt

Bug#979665: Please package libstd-rust-dev-emscripten

[Matt Corallo]

Package: src:rustc
Version: 1.48.0+dfsg1-2

Due to issues with the way rustc interacts with LLVM-wasm [1], building rust packages with 
--target=wasm-unknown-{wasi,unknown} is not practical if any C code is to be used in the same binary (which is common). 
Instead, wasm-unknown-emscripten is the only option, however not librust-std is packaged for emscripten. rustup's 
emscripten is broken on debian testing due to them shipping their own LLVM, so that is also not a practical solution for 
most users wishing to link C and rust code in any context, let alone WASM.



[1] https://github.com/rustwasm/team/issues/291

Bug#976791: closed by Debian FTP Masters (reply to Bastian Blank ) (Bug#976791: fixed in linux 5.10~rc7-1~exp1)

[Matt Corallo]

Note that the CONFIG_SND_SOC_INTEL_SOUNDWIRE_SOF_MACH in the x86 config is bogus - 
CONFIG_SND_SOC_INTEL_SOUNDWIRE_SOF_MACH depends on CONFIG_SND_SOC_INTEL_USER_FRIENDLY_LONG_NAMES which is not set.


On 12/27/20 5:16 PM, Matt Corallo wrote:
Note that this issue was not closed as CONFIG_SND_SOC_INTEL_SOUNDWIRE_SOF_MACH is still missing. The (relevant) diff 
between my (working, self-built) rc7 and 5.10.1 in exp is:


$ diff /boot/config-5.10.0-* | grep "SND\|SOUND"
< CONFIG_SND_SOC_INTEL_USER_FRIENDLY_LONG_NAMES=y
 > # CONFIG_SND_SOC_INTEL_USER_FRIENDLY_LONG_NAMES is not set
< CONFIG_SND_SOC_INTEL_SOUNDWIRE_SOF_MACH=m
< CONFIG_SND_SOC_RT1308=m

On 12/13/20 6:03 AM, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the linux-image-amd64 package:

#976791: Enable CONFIG_SOUNDWIRE (and related drivers)

It has been closed by Debian FTP Masters  (reply to 
Bastian Blank ).

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Debian FTP Masters  (reply to 
Bastian Blank ) by

replying to this email.

Bug#976791: closed by Debian FTP Masters (reply to Bastian Blank ) (Bug#976791: fixed in linux 5.10~rc7-1~exp1)

[Matt Corallo]

Note that this issue was not closed as CONFIG_SND_SOC_INTEL_SOUNDWIRE_SOF_MACH is still missing. The (relevant) diff 
between my (working, self-built) rc7 and 5.10.1 in exp is:


$ diff /boot/config-5.10.0-* | grep "SND\|SOUND"
< CONFIG_SND_SOC_INTEL_USER_FRIENDLY_LONG_NAMES=y
> # CONFIG_SND_SOC_INTEL_USER_FRIENDLY_LONG_NAMES is not set
< CONFIG_SND_SOC_INTEL_SOUNDWIRE_SOF_MACH=m
< CONFIG_SND_SOC_RT1308=m

On 12/13/20 6:03 AM, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the linux-image-amd64 package:

#976791: Enable CONFIG_SOUNDWIRE (and related drivers)

It has been closed by Debian FTP Masters  (reply to 
Bastian Blank ).

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Debian FTP Masters 
 (reply to Bastian Blank ) by
replying to this email.

Bug#962134: add Sound Open Firmware

[Matt Corallo]

With the fixes for #976791 landed in linux-5.10~rc7-1~exp1 and the new release of alsa-ucm-conf in testing, this is the 
last remaining issue for getting audio to work on modern Dell machines (in my case a Precision 5750). It would be quite 
a shame for this to sit for a few more months and Debian end up not having working audio on year-old machines come bullseye.


On 8/26/20 12:35 PM, Matt Corallo wrote:
This now impacts more and more devices - new generation Dell laptops that ship with linux need this (plus a new release 
of alsa-ucm-conf with current git) to get audio.

Bug#976791: Acknowledgement (Enable CONFIG_SOUNDWIRE (and related drivers))

[Matt Corallo]

Saw the commits in salsa and went and tested them. Looks like to get audio working config also needs (but definitely 
works now)


CONFIG_SND_SOC_INTEL_USER_FRIENDLY_LONG_NAMES=y
CONFIG_SND_SOC_INTEL_SOUNDWIRE_SOF_MACH=m
CONFIG_SND_SOC_MAX98373_SDW=m
CONFIG_SND_SOC_RT1308=m
CONFIG_SND_SOC_RT1308_SDW=m
CONFIG_SND_SOC_RT5682_SDW=m

Why you have to enable "User Friendly Long Names" in order to enable drivers, I 
have no idea.

On 12/7/20 6:18 PM, Debian Bug Tracking System wrote:

Thank you for filing a new Bug report with Debian.

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

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
  Debian Kernel Team 

If you wish to submit further information on this problem, please
send it to 976...@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#976791: Acknowledgement (Enable CONFIG_SOUNDWIRE (and related drivers))

[Matt Corallo]

Oops, it seems I was confused about when this landed upstream. Enabling soundwire on 5.9 doesn't accomplish much, but 
5.10 should bring support for audio on new Dell machines, presumably with something like the following:


CONFIG_REGMAP_SOUNDWIRE=m
CONFIG_SND_SOC_SOF_INTEL_SOUNDWIRE_LINK=y
CONFIG_SND_SOC_SOF_INTEL_SOUNDWIRE=m
CONFIG_SND_SOC_RT700=m
CONFIG_SND_SOC_RT700_SDW=m
CONFIG_SND_SOC_RT711=m
CONFIG_SND_SOC_RT711_SDW=m
CONFIG_SND_SOC_RT715=m
CONFIG_SND_SOC_RT715_SDW=m
CONFIG_SOUNDWIRE=m
CONFIG_SOUNDWIRE_CADENCE=m
CONFIG_SOUNDWIRE_INTEL=m
CONFIG_SOUNDWIRE_GENERIC_ALLOCATION=m

On 12/7/20 6:18 PM, Debian Bug Tracking System wrote:

Thank you for filing a new Bug report with Debian.

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

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
  Debian Kernel Team 

If you wish to submit further information on this problem, please
send it to 976...@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#976791: Enable CONFIG_SOUNDWIRE (and related drivers)

[Matt Corallo]

Package: linux-image-amd64
Version: 5.9.11-1

Some newer Intel machines (eg high-end 2020 Dell XPS machines) require soundwire for audio, however current Debian 
kernel configs do not include CONFIG_SOUNDWIRE at all. This may depend on #962134 as well, however #962134 can be 
resolved locally without rebuilding packages by copying the related firmware binaries.

Bug#970421: apparmor limit blocks temperature reading

[Matt Corallo]

Package: chrony
Version: 3.4-4

Current apparmor profile for chrony lists
@{sys}/class/hwmon/hwmon[0-9]*/temp[0-9]*_input r,

which is great (and even how I have mine configured -
tempcomp /sys/class/hwmon/hwmon0/temp1_input 1 0 0 0 0) but it doesn't actually 
work. It results in lots of log lines like

Sep 15 23:06:37 gw.as397444.net audit[24397]: AVC apparmor="DENIED" operation="open" profile="/usr/sbin/chronyd" 
name="/sys/devices/virtual/thermal/thermal_zone0/hwmon0/temp1_input" pid=24397 comm="chronyd" requested_mask="r" 
denied_mask="r" fsuid=112 ouid=0

Sep 15 23:06:37 gw.as397444.net chronyd[24397]: Could not read temperature from 
/sys/class/hwmon/hwmon0/temp1_input
Sep 15 23:06:37 gw.as397444.net kernel: audit: type=1400 audit(1600225597.313:127): apparmor="DENIED" operation="open" 
profile="/usr/sbin/chronyd" name="/sys/devices/virtual/thermal/thermal_zone0/hwmon0/temp1_input" pid=24397 
comm="chronyd" requested_mask="r" denied_mask="r" fsuid=112 ouid=0


Looks like somehow apparmor is resolving the file to a different path, 
checking, and then failing it.

An extra line like the following fixes it:
@{sys}/devices/virtual/thermal/thermal_zone[0-9]*/hwmon[0-9]*/temp[0-9]*_input 
r,

Matt

Bug#962134: add Sound Open Firmware

[Matt Corallo]

This now impacts more and more devices - new generation Dell laptops that ship with linux need this (plus a new release 
of alsa-ucm-conf with current git) to get audio.

Bug#964425: Root Zone AXFR Primaries Should be in dns-root-data

[Matt Corallo]

Package: bind9
Version: 1:9.16.4-1

Current versions of BIND provide a hardcoded list of root servers which provide 
access to the root zone via AXFR so that
they can be used as primaries in a "mirror"-type root zone
(https://gitlab.isc.org/isc-projects/bind9/-/blob/main/bin/named/config.c#L305).

It seems that list should likely be moved to dns-root-data so that it can be 
updated separately from a full bind
installation (and possibly used by other resolvers).

I presume such a file should be usable as an include statement in bind.conf, 
though this may preclude use by other
resolvers.

Feel free to move this to dns-root-data or tell me off to go file upstream or 
so if this isn't the right place to file.

Bug#961760: Inclusion of C-Root Slows Down Some Networks

[Matt Corallo]

Package: dns-root-data
Version: 2019052802

The C-Root is unreachable over IPv6 from some chunk of the Internet due to the 
ongoing (many-year) peering wars between
Cogent and Hurricane Electric/Google. The website for the C root even describes 
the issue and suggests that there is no
desire to address the issue (after all, the C root operator is a party to the 
dispute). This delays DNS requests for
some users. It probably makes sense to patch out at least the v6 entry for the 
C Root.

Bug#939329: named crashes when setting nsec3param

[Matt Corallo]

Note that upstream claims this is fixed (I haven't verified). Would be nice to 
get a patch backport to stable.

On 9/3/19 10:42 AM, Matt Corallo wrote:
> Yep, no problem. I moved it out of the way to keep it around, will try
> to avoid upgrading bind and losing the original deb to run backtraces
> against.
> 
> 
> On 9/3/19 2:10 PM, Ondřej Surý wrote:
>> Thanks Matt, could you please save the core in case we (ISC) are going to 
>> need more information from it?
>>
>> Ondrej
>> --
>> Ondřej Surý
>> ond...@sury.org
>>
>>
>>
>>> On 3 Sep 2019, at 16:05, Matt Corallo  wrote:
>>>
>>> Core dump trace follows:
>>>
>>> [New LWP 29244]
>>> [New LWP 29241]
>>> [New LWP 29245]
>>> [New LWP 29243]
>>> [New LWP 29242]
>>> [New LWP 29246]
>>> [New LWP 29247]
>>> [Thread debugging using libthread_db enabled]
>>> Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
>>> Core was generated by `/usr/sbin/named -u bind'.
>>> Program terminated with signal SIGABRT, Aborted.
>>> #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
>>> 50  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
>>> [Current thread is 1 (Thread 0xafda91a0 (LWP 29244))]
>>> (gdb) thread apply all bt
>>>
>>> Thread 7 (Thread 0xae5a61a0 (LWP 29247)):
>>> #0  0xb2ffbc00 in __GI_epoll_pwait (epfd=,
>>> events=events@entry=0xb0db6010, maxevents=maxevents@entry=64,
>>>timeout=timeout@entry=-1, set=set@entry=0x0) at
>>> ../sysdeps/unix/sysv/linux/epoll_pwait.c:42
>>> #1  0xb2ffbd40 in epoll_wait (epfd=,
>>> events=events@entry=0xb0db6010, maxevents=maxevents@entry=64,
>>>timeout=timeout@entry=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:32
>>> #2  0xb3471a9c in watcher (uap=0xb0db5010) at
>>> ../../../../lib/isc/unix/socket.c:4260
>>> #3  0xb335b7e4 in start_thread (arg=0xd7e8b09f) at
>>> pthread_create.c:486
>>> #4  0xb2ffbadc in thread_start () at
>>> ../sysdeps/unix/sysv/linux/aarch64/clone.S:78
>>>
>>> Thread 6 (Thread 0xaeda71a0 (LWP 29246)):
>>> #0  futex_abstimed_wait_cancelable (private=0, abstime=0xaeda6858,
>>> expected=0, futex_word=0xb0db30a8)
>>>at ../sysdeps/unix/sysv/linux/futex-internal.h:205
>>> #1  __pthread_cond_wait_common (abstime=,
>>> mutex=, cond=) at pthread_cond_wait.c:539
>>> #2  __pthread_cond_timedwait (cond=cond@entry=0xb0db3080,
>>> mutex=mutex@entry=0xb0db3028, abstime=abstime@entry=0xaeda6858)
>>>at pthread_cond_wait.c:667
>>> #3  0xb347bc54 in isc_condition_waituntil
>>> (c=c@entry=0xb0db3080, m=m@entry=0xb0db3028,
>>> t=t@entry=0xb0db3074)
>>>at ../../../../lib/isc/pthreads/condition.c:59
>>> #4  0xb3463f44 in run (uap=0xb0db3010) at
>>> ../../../lib/isc/timer.c:806
>>> #5  0xb335b7e4 in start_thread (arg=0xd7e8b14f) at
>>> pthread_create.c:486
>>> #6  0xb2ffbadc in thread_start () at
>>> ../sysdeps/unix/sysv/linux/aarch64/clone.S:78
>>>
>>> Thread 5 (Thread 0xb0dab1a0 (LWP 29242)):
>>> #0  0xb36553c0 in ?? () from /lib/aarch64-linux-gnu/libcrypto.so.1.1
>>> #1  0xb0da6d30 in ?? ()
>>> #2  0x94603695287e7065 in ?? ()
>>> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>>>
>>> Thread 4 (Thread 0xb05aa1a0 (LWP 29243)):
>>> #0  futex_wait_cancelable (private=0, expected=0,
>>> futex_word=0xb0db10d0) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
>>> #1  __pthread_cond_wait_common (abstime=0x0, mutex=0xb0db1028,
>>> cond=0xb0db10a8) at pthread_cond_wait.c:502
>>> #2  __pthread_cond_wait (cond=cond@entry=0xb0db10a8,
>>> mutex=mutex@entry=0xb0db1028) at pthread_cond_wait.c:655
>>> #3  0xb345dae4 in dispatch (manager=0xb0db1010) at
>>> ../../../lib/isc/task.c:1089
>>> #4  run (uap=0xb0db1010) at ../../../lib/isc/task.c:1315
>>> #5  0xb335b7e4 in start_thread (arg=0xd7e8b10f) at
>>> pthread_create.c:486
>>> #6  0xb2ffbadc in thread_start () at
>>> ../sysdeps/unix/sysv/linux/aarch64/clone.S:78
>>>
>>> Thread 3 (Thread 0xaf5a81a0 (LWP 29245)):
>>> #0  futex_wait_cancelable (private=0, expected=0,
>>> futex_word=0xb

Bug#951177: NULL pointer dereference in iwlwifi

[Matt Corallo]

Package: linux-image-5.4.0-3-amd64
Version: 5.4.13-1

Since switching to 5.4.13 from 5.3.15 (IIRC, though I may have been on
5.4.8), my laptop hangs regularly when transmitting a bunch of wireguard
traffic over iwlwifi. The following kernel log is one of the lucky cases
where the soft-lockup recovered, but other times it seems to not.

Feb 11 15:53:26 BMXPSv3 kernel: iwlwifi :3b:00.0: Error sending
STATISTICS_CMD: time out after 2000ms.
Feb 11 15:53:26 BMXPSv3 kernel: iwlwifi :3b:00.0: Current CMD queue
read_ptr 248 write_ptr 249
Feb 11 15:53:28 BMXPSv3 kernel: iwlwifi :3b:00.0: HW error,
resetting before reading
Feb 11 15:53:28 BMXPSv3 kernel: iwlwifi :3b:00.0: Microcode SW error
detected. Restarting 0xA5A505A2.
Feb 11 15:53:28 BMXPSv3 kernel: BUG: kernel NULL pointer dereference,
address: 0008
Feb 11 15:53:28 BMXPSv3 kernel: #PF: supervisor read access in kernel mode
Feb 11 15:53:28 BMXPSv3 kernel: #PF: error_code(0x) - not-present page
Feb 11 15:53:28 BMXPSv3 kernel: PGD 0 P4D 0
Feb 11 15:53:28 BMXPSv3 kernel: Oops:  [#1] SMP PTI
Feb 11 15:53:28 BMXPSv3 kernel: CPU: 0 PID: 568 Comm: irq/158-iwlwifi
Tainted: G   OE 5.4.0-3-amd64 #1 Debian 5.4.13-1
Feb 11 15:53:28 BMXPSv3 kernel: Hardware name: Dell Inc. Precision
5530/0W8N6V, BIOS 1.8.1 02/01/2019
Feb 11 15:53:28 BMXPSv3 kernel: RIP:
0010:iwl_pcie_irq_msix_handler+0x12f/0x370 [iwlwifi]
Feb 11 15:53:28 BMXPSv3 kernel: Code: 00 41 f6 c6 01 0f 85 a4 00 00 00
48 8b 45 10 44 89 f2 83 e2 02 83 78 10 13 0f 84 2d 01 00 00 85 d2 74 37
48 8b 83 38 72 00 00 <8b> 40 08 3d d3 00 00 00 0f 84 06 02 00 00 3d d0
00 00 00 0f 84 fb
Feb 11 15:53:28 BMXPSv3 kernel: RSP: 0018:ae2680cd3e60 EFLAGS: 00010202
Feb 11 15:53:28 BMXPSv3 kernel: RAX:  RBX:
9c92dc240318 RCX: 
Feb 11 15:53:28 BMXPSv3 kernel: RDX: 0002 RSI:
0246 RDI: 0246
Feb 11 15:53:28 BMXPSv3 kernel: RBP: 9c92dc240018 R08:
9c92dc248fa8 R09: ae2680cd3df8
Feb 11 15:53:28 BMXPSv3 kernel: R10: ae2680cd3b50 R11:
 R12: a5a505a2
Feb 11 15:53:28 BMXPSv3 kernel: R13: 9c92dc24907c R14:
24000182 R15: 9c92dc247ea4
Feb 11 15:53:28 BMXPSv3 kernel: FS:  ()
GS:9c92ec00() knlGS:
Feb 11 15:53:28 BMXPSv3 kernel: CS:  0010 DS:  ES:  CR0:
80050033
Feb 11 15:53:28 BMXPSv3 kernel: CR2: 0008 CR3:
0002c1660006 CR4: 003606f0
Feb 11 15:53:28 BMXPSv3 kernel: Call Trace:
Feb 11 15:53:28 BMXPSv3 kernel:  ? irq_finalize_oneshot.part.0+0x100/0x100
Feb 11 15:53:28 BMXPSv3 kernel:  irq_thread_fn+0x20/0x60
Feb 11 15:53:28 BMXPSv3 kernel:  irq_thread+0xdc/0x170
Feb 11 15:53:28 BMXPSv3 kernel:  ? irq_forced_thread_fn+0x80/0x80
Feb 11 15:53:28 BMXPSv3 kernel:  kthread+0xf9/0x130
Feb 11 15:53:28 BMXPSv3 kernel:  ? irq_thread_check_affinity+0xd0/0xd0
Feb 11 15:53:28 BMXPSv3 kernel:  ? kthread_park+0x90/0x90
Feb 11 15:53:28 BMXPSv3 kernel:  ret_from_fork+0x35/0x40
Feb 11 15:53:28 BMXPSv3 kernel: Modules linked in: veth ccm ip6t_REJECT
nf_reject_ipv6 sch_fq_codel sch_htb ipt_REJECT nf_reject_ipv4 xt_tcpudp
xt_MASQUERADE xt_nat nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6
nf_defrag_ipv4 crc32c_generic nft_counter xt_mark xt_owner nft_compat
bridge stp llc wireguard(OE) ip6_udp_tunnel udp_tunnel wacom usbhid
hid_multitouch hid_generic dell_rbtn snd_sof_pci
snd_sof_intel_hda_common nf_tables snd_sof_intel_hda snd_sof_intel_byt
nfnetlink snd_sof_intel_ipc snd_sof snd_sof_xtensa_dsp snd_soc_skl
snd_hda_codec_hdmi snd_soc_hdac_hda snd_hda_ext_core snd_soc_sst_ipc
snd_soc_sst_dsp x86_pkg_temp_thermal intel_powerclamp
snd_soc_acpi_intel_match coretemp snd_soc_acpi snd_hda_codec_realtek
snd_soc_core snd_hda_codec_generic kvm_intel iTCO_wdt rtsx_pci_ms iwlmvm
i2c_designware_platform snd_compress rtsx_pci_sdmmc mei_wdt
iTCO_vendor_support i2c_designware_core dell_laptop intel_rapl_msr
mmc_core memstick watchdog kvm ledtrig_audio snd_hda_intel btusb
dell_wmi wmi_bmof irqbypass
Feb 11 15:53:28 BMXPSv3 kernel:  mac80211 btrtl intel_wmi_thunderbolt
mxm_wmi tpm_crb snd_intel_nhlt dell_smbios btbcm snd_hda_codec btintel
dell_wmi_descriptor dcdbas dell_smm_hwmon bluetooth uvcvideo libarc4
snd_hda_core crct10dif_pclmul crc32_pclmul videobuf2_vmalloc snd_hwdep
ahci videobuf2_memops snd_pcm videobuf2_v4l2 ghash_clmulni_intel drbg
videobuf2_common libahci efi_pstore snd_timer intel_cstate iwlwifi
ansi_cprng intel_uncore cfg80211 ecdh_generic intel_lpss_pci
processor_thermal_device joydev ecc intel_rapl_perf videodev snd
intel_lpss pcspkr libata efivars rfkill crc16 ucsi_acpi soundcore mei_me
typec_ucsi cdc_acm rtsx_pci intel_rapl_common idma64 mei mc i2c_i801
i2c_hid mfd_core tpm_tis intel_pch_thermal intel_soc_dts_iosf typec
battery hid tpm_tis_core tpm int3403_thermal int3400_thermal intel_hid
wmi int340x_thermal_zone dell_smo8800 rng_core ac sparse_keymap
acpi_thermal_rel acpi_pad button efivarfs ip_tables 

Bug#939329: named crashes when setting nsec3param

[Matt Corallo]

Yep, no problem. I moved it out of the way to keep it around, will try
to avoid upgrading bind and losing the original deb to run backtraces
against.


On 9/3/19 2:10 PM, Ondřej Surý wrote:
> Thanks Matt, could you please save the core in case we (ISC) are going to 
> need more information from it?
> 
> Ondrej
> --
> Ondřej Surý
> ond...@sury.org
> 
> 
> 
>> On 3 Sep 2019, at 16:05, Matt Corallo  wrote:
>>
>> Core dump trace follows:
>>
>> [New LWP 29244]
>> [New LWP 29241]
>> [New LWP 29245]
>> [New LWP 29243]
>> [New LWP 29242]
>> [New LWP 29246]
>> [New LWP 29247]
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
>> Core was generated by `/usr/sbin/named -u bind'.
>> Program terminated with signal SIGABRT, Aborted.
>> #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
>> 50   ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
>> [Current thread is 1 (Thread 0xafda91a0 (LWP 29244))]
>> (gdb) thread apply all bt
>>
>> Thread 7 (Thread 0xae5a61a0 (LWP 29247)):
>> #0  0xb2ffbc00 in __GI_epoll_pwait (epfd=,
>> events=events@entry=0xb0db6010, maxevents=maxevents@entry=64,
>>timeout=timeout@entry=-1, set=set@entry=0x0) at
>> ../sysdeps/unix/sysv/linux/epoll_pwait.c:42
>> #1  0xb2ffbd40 in epoll_wait (epfd=,
>> events=events@entry=0xb0db6010, maxevents=maxevents@entry=64,
>>timeout=timeout@entry=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:32
>> #2  0xb3471a9c in watcher (uap=0xb0db5010) at
>> ../../../../lib/isc/unix/socket.c:4260
>> #3  0xb335b7e4 in start_thread (arg=0xd7e8b09f) at
>> pthread_create.c:486
>> #4  0xb2ffbadc in thread_start () at
>> ../sysdeps/unix/sysv/linux/aarch64/clone.S:78
>>
>> Thread 6 (Thread 0xaeda71a0 (LWP 29246)):
>> #0  futex_abstimed_wait_cancelable (private=0, abstime=0xaeda6858,
>> expected=0, futex_word=0xb0db30a8)
>>at ../sysdeps/unix/sysv/linux/futex-internal.h:205
>> #1  __pthread_cond_wait_common (abstime=,
>> mutex=, cond=) at pthread_cond_wait.c:539
>> #2  __pthread_cond_timedwait (cond=cond@entry=0xb0db3080,
>> mutex=mutex@entry=0xb0db3028, abstime=abstime@entry=0xaeda6858)
>>at pthread_cond_wait.c:667
>> #3  0xb347bc54 in isc_condition_waituntil
>> (c=c@entry=0xb0db3080, m=m@entry=0xb0db3028,
>> t=t@entry=0xb0db3074)
>>at ../../../../lib/isc/pthreads/condition.c:59
>> #4  0xb3463f44 in run (uap=0xb0db3010) at
>> ../../../lib/isc/timer.c:806
>> #5  0xb335b7e4 in start_thread (arg=0xd7e8b14f) at
>> pthread_create.c:486
>> #6  0xb2ffbadc in thread_start () at
>> ../sysdeps/unix/sysv/linux/aarch64/clone.S:78
>>
>> Thread 5 (Thread 0xb0dab1a0 (LWP 29242)):
>> #0  0xb36553c0 in ?? () from /lib/aarch64-linux-gnu/libcrypto.so.1.1
>> #1  0xb0da6d30 in ?? ()
>> #2  0x94603695287e7065 in ?? ()
>> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>>
>> Thread 4 (Thread 0xb05aa1a0 (LWP 29243)):
>> #0  futex_wait_cancelable (private=0, expected=0,
>> futex_word=0xb0db10d0) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
>> #1  __pthread_cond_wait_common (abstime=0x0, mutex=0xb0db1028,
>> cond=0xb0db10a8) at pthread_cond_wait.c:502
>> #2  __pthread_cond_wait (cond=cond@entry=0xb0db10a8,
>> mutex=mutex@entry=0xb0db1028) at pthread_cond_wait.c:655
>> #3  0xb345dae4 in dispatch (manager=0xb0db1010) at
>> ../../../lib/isc/task.c:1089
>> #4  run (uap=0xb0db1010) at ../../../lib/isc/task.c:1315
>> #5  0xb335b7e4 in start_thread (arg=0xd7e8b10f) at
>> pthread_create.c:486
>> #6  0xb2ffbadc in thread_start () at
>> ../sysdeps/unix/sysv/linux/aarch64/clone.S:78
>>
>> Thread 3 (Thread 0xaf5a81a0 (LWP 29245)):
>> #0  futex_wait_cancelable (private=0, expected=0,
>> futex_word=0xb0db10d0) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
>> #1  __pthread_cond_wait_common (abstime=0x0, mutex=0xb0db1028,
>> cond=0xb0db10a8) at pthread_cond_wait.c:502
>> #2  __pthread_cond_wait (cond=cond@entry=0xb0db10a8,
>> mutex=mutex@entry=0xb0db1028) at pthread_cond_wait.c:655
>> #3  0xb345dae4 in dispatch (manager=0xb0db1010) at
>> ../../../lib/isc/task.c:1089
>> #4  run (uap=0xb0db1010) at ../../../lib/isc/task.c:1315
>> #5  0xb

Bug#939329: named crashes when setting nsec3param

[Matt Corallo]

tiontype_require,
cond=cond@entry=0xb3b1e398 "rbtdb->future_version == ((void *)0)")
at ../../../lib/isc/assertions.c:51
#4  0xb3a1368c in newversion (db=0xada1fc70,
versionp=0xafda87d0) at ../../../lib/dns/rbtdb.c:1546
#5  0xb3ad4bd4 in setnsec3param (task=,
event=) at ../../../lib/dns/zone.c:19016
#6  0xb345dca0 in dispatch (manager=0xb0db1010) at
../../../lib/isc/task.c:1143
#7  run (uap=0xb0db1010) at ../../../lib/isc/task.c:1315
#8  0xb335b7e4 in start_thread (arg=0xd7e8b10f) at
pthread_create.c:486
#9  0xb2ffbadc in thread_start () at
../sysdeps/unix/sysv/linux/aarch64/clone.S:78
(gdb)


On 9/3/19 1:39 PM, Ondřej Surý wrote:
> Nope, sorry, it’s here:
> 
> https://wiki.debian.org/AutomaticDebugPackages
> 
> …
> 
> e.g. adding:
> 
> deb http://deb.debian.org/debian-debug/ stable-debug main
> 
> should do the trick.
> 
> Ondrej
> --
> Ondřej Surý
> ond...@sury.org
> 
> 
> 
>> On 3 Sep 2019, at 15:37, Ondřej Surý  wrote:
>>
>> I don’t know why it’s not available in the stable, but since we haven’t 
>> updated the package in the unstable yet, it should be identical to:
>>
>> https://packages.debian.org/unstable/bind9-dbgsym
>>
>> Ondrej
>> --
>> Ondřej Surý
>> ond...@sury.org
>>
>>
>>
>>> On 3 Sep 2019, at 15:19, Matt Corallo  wrote:
>>>
>>> I do have a core, but don't see what package to get debug symbols from?
>>>
>>> Matt
>>>
>>> On 9/3/19 12:27 PM, Ondřej Surý wrote:
>>>> Hi,
>>>>
>>>> could you please take a look if you have a core around and you could 
>>>> install debug symbols to decode the coredump?
>>>>
>>>> Ondrej
>>>> --
>>>> Ondřej Surý
>>>> ond...@sury.org
>>>>
>>>>
>>>>
>>>>> On 3 Sep 2019, at 13:51, li...@bluematt.me wrote:
>>>>>
>>>>> Package: bind9
>>>>> Version: 1:9.11.5.P4+dfsg-5.1
>>>>>
>>>>> Woke up this morning to the following in syslog. Looks to maybe be a
>>>>> race condition when reloading zones that have changed and setting
>>>>> nsec3params immediately after/during the reload.
>>>>>
>>>>> Sep  3 05:56:06 odroid-dns named[29241]: zone bluematt.me/IN (unsigned):
>>>>> loaded serial 2015412479
>>>>> Sep  3 05:56:06 odroid-dns named[29241]: received control channel
>>>>> command 'signing -nsec3param 1 0 100 D1D6B923 mattcorallo.com'
>>>>> Sep  3 05:56:06 odroid-dns named[29241]: ../../../lib/dns/rbtdb.c:1494:
>>>>> REQUIRE(rbtdb->future_version == ((void *)0)) failed, back trace
>>>>> Sep  3 05:56:06 odroid-dns named[29241]: #0 0xdda1f958 in ??
>>>>> Sep  3 05:56:06 odroid-dns named[29241]: #1 0xb3437944 in ??
>>>>> Sep  3 05:56:06 odroid-dns named[29241]: #2 0xb3a1368c in ??
>>>>> Sep  3 05:56:06 odroid-dns named[29241]: #3 0xb3ad4bd4 in ??
>>>>> Sep  3 05:56:06 odroid-dns named[29241]: #4 0xb345dca0 in ??
>>>>> Sep  3 05:56:06 odroid-dns named[29241]: #5 0xb335b7e4 in ??
>>>>> Sep  3 05:56:06 odroid-dns named[29241]: #6 0xb2ffbadc in ??
>>>>> Sep  3 05:56:06 odroid-dns named[29241]: exiting (due to assertion 
>>>>> failure)
>>>>>
>>>>
>>
> 

Bug#939329: named crashes when setting nsec3param

[Matt Corallo]

I do have a core, but don't see what package to get debug symbols from?

Matt

On 9/3/19 12:27 PM, Ondřej Surý wrote:
> Hi,
> 
> could you please take a look if you have a core around and you could install 
> debug symbols to decode the coredump?
> 
> Ondrej
> --
> Ondřej Surý
> ond...@sury.org
> 
> 
> 
>> On 3 Sep 2019, at 13:51, li...@bluematt.me wrote:
>>
>> Package: bind9
>> Version: 1:9.11.5.P4+dfsg-5.1
>>
>> Woke up this morning to the following in syslog. Looks to maybe be a
>> race condition when reloading zones that have changed and setting
>> nsec3params immediately after/during the reload.
>>
>> Sep  3 05:56:06 odroid-dns named[29241]: zone bluematt.me/IN (unsigned):
>> loaded serial 2015412479
>> Sep  3 05:56:06 odroid-dns named[29241]: received control channel
>> command 'signing -nsec3param 1 0 100 D1D6B923 mattcorallo.com'
>> Sep  3 05:56:06 odroid-dns named[29241]: ../../../lib/dns/rbtdb.c:1494:
>> REQUIRE(rbtdb->future_version == ((void *)0)) failed, back trace
>> Sep  3 05:56:06 odroid-dns named[29241]: #0 0xdda1f958 in ??
>> Sep  3 05:56:06 odroid-dns named[29241]: #1 0xb3437944 in ??
>> Sep  3 05:56:06 odroid-dns named[29241]: #2 0xb3a1368c in ??
>> Sep  3 05:56:06 odroid-dns named[29241]: #3 0xb3ad4bd4 in ??
>> Sep  3 05:56:06 odroid-dns named[29241]: #4 0xb345dca0 in ??
>> Sep  3 05:56:06 odroid-dns named[29241]: #5 0xb335b7e4 in ??
>> Sep  3 05:56:06 odroid-dns named[29241]: #6 0xb2ffbadc in ??
>> Sep  3 05:56:06 odroid-dns named[29241]: exiting (due to assertion failure)
>>
> 

Bug#916897: Firefox Upstream Suggests Switching to clang+LTO

[Matt Corallo]

Package: firefox
Version: 64.0-1

As of Firefox 64 upstream release binaries are built using clang+LTO, 
and at least some mozillaians' blogs [1] suggest downstreams may wish to 
do so as well as it can be a rather significant performance improvement.


[1] https://glandium.org/blog/?p=3888

Bug#895362: Acknowledgement (Testing CD/DVD Missing algif_skcipher on Power64LE (so cannot use encrypted volumes))

[Matt Corallo]

Also missing at least the ecb module, which is needed to initialize the
xts mode to do a default encrypted-partition install.

On 04/10/18 11:00, Debian Bug Tracking System wrote:
> Thank you for filing a new Bug report with Debian.
> 
> You can follow progress on this Bug here: 895362: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895362.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
> 
> Your message has been sent to the package maintainer(s):
>  Debian Kernel Team 
> 
> If you wish to submit further information on this problem, please
> send it to 895...@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#895362: Testing CD/DVD Missing algif_skcipher on Power64LE (so cannot use encrypted volumes)

[Matt Corallo]

Package: linux-image-powerpc64le
Version: 4.15+91

(I know its not the right package as this is an issue only in the
testing CD, not a running system, but I can't seem to find the right
package to file against, and figure this will at least CC the right
people, sorry about that).

Pretty self-explanatory, algif_skcipher mod is missing on the weekly
buster install CD/DVD, so any time you try to use encrypted volumes you
get a cryptic error in the install prompt and a "Error allocating crypto
tfm" error in dmesg.

Bug#675376:

[Matt Corallo]

Slightly more useful backtrace:

#0  nm_secret_agent_cancel_secrets (self=0x27122a0, call=0x1) at
nm-secret-agent.c:308
#1  0x00499be0 in request_free (req=0x7ffe60009e70) at
nm-agent-manager.c:472
#2  0x7ffe6aaf3eea in ?? ()
from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00463fb4 in dispose (object=0x2710ad0) at
nm-activation-request.c:548
#4  0x7ffe6adc7604 in g_object_unref ()
from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#5  0x0042b648 in nm_device_state_changed (device=0x272e030,
state=state@entry=NM_DEVICE_STATE_UNAVAILABLE,
reason=reason@entry=NM_DEVICE_STATE_REASON_NONE) at nm-device.c:4359
#6  0x00435745 in real_set_enabled (device=0x272e030, enabled=0)
at nm-device-wifi.c:3250
#7  0x00458542 in manager_update_radio_enabled
(self=self@entry=0x2716040, enabled=enabled@entry=0, rstate=error
reading variable: Unhandled dwarf expression opcode 0xfa,
rstate=error reading variable: Unhandled dwarf expression opcode
0xfa) at nm-manager.c:1338
#8  0x0045c742 in manager_radio_user_toggled (self=0x2716040,
rstate=0x27160a8, enabled=0) at nm-manager.c:4228
#9  0x7ffe6adc9c34 in g_object_set_valist ()
from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#10 0x7ffe6adca447 in g_object_set ()
from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#11 0x0045aed5 in prop_filter (connection=0x26a7570,
message=0x275a2b0, user_data=optimized out) at nm-manager.c:3913
#12 0x7ffe6c3ff3fe in dbus_connection_dispatch ()
from /lib/x86_64-linux-gnu/libdbus-1.so.3
#13 0x7ffe6c640715 in ?? ()
from /usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2
#14 0x7ffe6ab04205 in g_main_context_dispatch ()
from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#15 0x7ffe6ab04538 in ?? ()
from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#16 0x7ffe6ab04932 in g_main_loop_run ()
from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#17 0x004258f1 in main (argc=1, argv=0x7fffd45150a8) at
main.c:635


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

Bug#675376: network-manager: Crashes with SIGSEGV when disabling wireless.

[Matt Corallo]

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

With two wireless interfaces, one disabled the other connected, disabling
wireless overall results in a SIGSEGV.

Backtrace from gdb is as follows:

Program received signal SIGSEGV, Segmentation fault.
nm_secret_agent_cancel_secrets (self=0x11cdd20, call=0x2) at 
nm-secret-agent.c:308
308 nm-secret-agent.c: No such file or directory.
(gdb) bt
#0  nm_secret_agent_cancel_secrets (self=0x11cdd20, call=0x2) at 
nm-secret-agent.c:308
#1  0x011ce400 in ?? ()
#2  0x7f2396ccf1e1 in g_mutex_unlock () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x011f66e0 in ?? ()
#4  0x in ?? ()

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (700, 'testing'), (400, 'unstable'), (300, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages network-manager depends on:
ii  adduser3.113+nmu2
ii  dbus   1.5.12-1
ii  dpkg   1.16.3
ii  isc-dhcp-client4.2.2.dfsg.1-5
ii  libc6  2.13-32
ii  libdbus-1-31.5.12-1
ii  libdbus-glib-1-2   0.98-1
ii  libgcrypt111.5.0-3
ii  libglib2.0-0   2.32.3-1
ii  libgnutls262.12.19-1
ii  libgudev-1.0-0 175-3.1
ii  libnl-3-2003.2.7-2
ii  libnl-genl-3-200   3.2.7-2
ii  libnl-route-3-200  3.2.7-2
ii  libnm-glib40.9.4.0-4
ii  libnm-util20.9.4.0-4
ii  libpolkit-gobject-1-0  0.104-2
ii  libuuid1   2.20.1-5
ii  lsb-base   4.1+Debian4
ii  udev   175-3.1
ii  wpasupplicant  1.0-2

Versions of packages network-manager recommends:
ii  crda  1.1.2-1
ii  dnsmasq-base  2.61-1
ii  iptables  1.4.13-1.1
ii  modemmanager  0.5.2.0-1
ii  policykit-1   0.104-2
ii  ppp   2.4.5-5.1

Versions of packages network-manager suggests:
pn  avahi-autoipd  none

-- Configuration Files:
/etc/init.d/network-manager changed [not included]

-- 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#675376: network-manager: Crashes with SIGSEGV when disabling wireless.

[Matt Corallo]

Forgot to mention, this appeared after upgrading to 0.9.4.0-4 from
0.9.4.0-3, but it could be related to upgrading one of a number of other
packages.




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

Bug#671789: libc6: getaddrinfo returns EAI_NONAME when only the loopback interface is up

[Matt Corallo]

Package: libc6
Version: 2.13-32
Severity: normal

When only the loopback interface is available, getaddrinfo incorrectly returns
EAI_NONAME when looking up localhost/127.0.0.1.
The following code snippet normally prints
0: Unknown error
0: Unknown error
when connected to the internet, but prints
-2: Name or service not known
-2: Name or service not known
when no non-loopback interface is available.


#include netdb.h
#include string.h
#include stdio.h

int main() {
char* ip = 127.0.0.1;
char* name = localhost;

struct addrinfo aiHint;
memset(aiHint, 0, sizeof(struct addrinfo));

aiHint.ai_socktype = SOCK_STREAM;
aiHint.ai_protocol = IPPROTO_TCP;
aiHint.ai_family = AF_INET;
aiHint.ai_flags = AI_ADDRCONFIG | AI_NUMERICHOST;

struct addrinfo *aiRes = NULL;

int nErr = getaddrinfo(ip, NULL, aiHint, aiRes);
printf(%d: %s\n, nErr, gai_strerror(nErr));

aiHint.ai_flags = AI_ADDRCONFIG;
nErr = getaddrinfo(name, NULL, aiHint, aiRes);
printf(%d: %s\n, nErr, gai_strerror(nErr));

return 0;
}



-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (700, 'testing'), (600, 'testing'), (500, 'testing'), (400, 
'unstable'), (300, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages libc6 depends on:
ii  libc-bin  2.13-32
ii  libgcc1   1:4.6.3-1

libc6 recommends no packages.

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.41
ii  glibc-doc  none
ii  locales2.13-27

-- debconf information:
  glibc/upgrade: true
  glibc/restart-services:
  libraries/restart-without-asking: false
  glibc/disable-screensaver:
  glibc/restart-failed:



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

Bug#671590: readahead-fedora: readahead --build does not work if --maxsize is not used

[Matt Corallo]

Package: readahead-fedora
Version: 2:1.5.6-4
Severity: important

If --maxsize is not set, readahead.c:560 calls list_new without setting 
withsize.
If we are not calling with --sort, filesizes never get read, thus every file
is of size 0, and thus no files are written to output.
This (should) make readahead break entirely on all systems with SSDs for boot 
drives
(mine isnt properly identified, so expect another bug report when I track down 
the
problems there...)

Thanks,
Matt

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (700, 'testing'), (600, 'testing'), (500, 'testing'), (400, 
'unstable'), (300, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages readahead-fedora depends on:
ii  dpkg 1.16.1.2
ii  e2fslibs 1.42.1-2
ii  initscripts  2.88dsf-22
ii  libaudit01:1.7.18-1.1
ii  libblkid12.20.1-4
ii  libc62.13-27

readahead-fedora recommends no packages.

readahead-fedora suggests no packages.

-- Configuration Files:
/etc/default/readahead-fedora changed:
READAHEAD=yes
READAHEAD_COLLECT=yes
READAHEAD_EXTRA_COLLECT=15
RUN_IN_BACKGROUND=yes
NICE_COLLECTOR=5
SORT_AT_SHUTDOWN=yes


-- 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#671591: readahead-fedora: build-lists fails to identify crypt/raid/etc SSDs

[Matt Corallo]

Package: readahead-fedora
Version: 2:1.5.6-4
Severity: normal

/usr/share/readahead-fedora/build-lists does not identify special devices that 
are
on physical SSDs.  eg encrypted drives, raid disks, etc.
For some such devices, eg encrypted drives, looking up the physical disk 
shouldn't
be too hard, for others it may be harder...
Though less common scenarios might not be worth implementing, the common ones 
like
cryptsetup luks partitions should IMHO be handled properly.

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (700, 'testing'), (600, 'testing'), (500, 'testing'), (400, 
'unstable'), (300, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages readahead-fedora depends on:
ii  dpkg 1.16.1.2
ii  e2fslibs 1.42.1-2
ii  initscripts  2.88dsf-22
ii  libaudit01:1.7.18-1.1
ii  libblkid12.20.1-4
ii  libc62.13-27

readahead-fedora recommends no packages.

readahead-fedora suggests no packages.

-- Configuration Files:
/etc/default/readahead-fedora changed:
READAHEAD=yes
READAHEAD_COLLECT=yes
READAHEAD_EXTRA_COLLECT=15
RUN_IN_BACKGROUND=yes
NICE_COLLECTOR=5
SORT_AT_SHUTDOWN=yes


-- 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#636357: sshfs: New Upstream Version (2.3)

[Matt Corallo]

Package: sshfs
Version: 2.2-1build1
Severity: wishlist

New upstream version of sshfs is out (2.3) which has hard linking support for 
openssh 6.7+.
Would be really nice for those who want to use sshfs as a incremental backup 
target.



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