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.
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.
Package: spamassassin
Version: 4.0.0-1~bpo11+1
It seems the main spamassassin.service file was lost in the 4.0 upgrade.
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).
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
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
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
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
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.
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
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
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
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
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
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
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
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 proce
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
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
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
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
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
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
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
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
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
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
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
> #
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.
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
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
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
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
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.
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).
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
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 back
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
n 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]
@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/unstabl
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
>
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
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:
>
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
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
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
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
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
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)
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
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
51 matches
Mail list logo
