Ha, okay, so maybe given the hardware in question triggers a buffer overflow in the kernel maybe we
fix that first and then enable CONFIG_PMBUS :)
https://lore.kernel.org/linux-hwmon/985cd95f-155b-4b8a-9fe7-59938d0c2...@mattcorallo.com/
On 4/17/25 12:39 PM, Debian Bug Tracking System wrote:
Th
Package: src:linux
Version: 6.1.128-1
pmbus.ko appears to be included in Ubuntu, but only in arm builds in Debian, and is useful for
various power supply monitoring in server or more robust hardware (eg I have a FSP Twins Pro, which
is a common-ish redundant ATX power supply which speaks PMBus
On 4/14/25 2:15 PM, Fabian Grünbichler wrote:
That's not really possible/in scope for Debian..
I don't see why? Debian already ships libstd-rust-dev-windows as well
as gcc packages for tons of
random targets, but really I guess this is just #989844, then.
most such targets don't really hav
On 4/7/25 3:47 PM, Fabian Grünbichler wrote:
That's bookworm, the version with the fix came later, Trixie/did ship the
Cargo.lock file:
Ha, apologies, I'd filed this against the wrong version. Glad its fixed in
trixie, at least.
note that this lock file includes a lot of things that we
Package: src:rustc
Version: 1.63.0+dfsg1-2
Because various libstds aren't packaged (including ones which cannot be packaged for license reasons
like macOS targets), `-Zbuild-std` is an important feature for being able to build for various targets.
Sadly, by default builds fail because of a mis
On 3/11/25 10:16 AM, Chris Lamb wrote:
Matt Corallo wrote:
https://git.bitcoin.ninja/?p=ldk-java-bins;a=tree;f=v0.1.1.0;hb=refs/heads/main
and
https://git.bitcoin.ninja/?p=ldk-java-bins;a=tree;f=v0.1.0.0;hb=refs/heads/main
Thanks for linking these. So, the proximate cause of this issue is
On 3/6/25 2:15 AM, Chris Lamb wrote:
Hi Matt,
Package: diffoscope
Version: 240+deb12u1
AAR files are identified by file as "Android package (APK), with
AndroidManifest.xml", but really
they're just zips with specific files inside. It would be nice to be
able to use diffoscope's diff
view gi
Package: diffoscope
Version: 240+deb12u1
AAR files are identified by file as "Android package (APK), with AndroidManifest.xml", but really
they're just zips with specific files inside. It would be nice to be able to use diffoscope's diff
view given that, but currently we just drop to a binary d
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.
Thank
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 modul
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 buildi
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
V
ready 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 wit
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),
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 s
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
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 th
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) ss
.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 schri
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 --us
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 fil
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
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
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 cr
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 o
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
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_IN
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
CONFIG_SND_SOC_RT1308_SD
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
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 with
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
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 add
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
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 recove
rom 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/un
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:
> https://
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-expla
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 0x004
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.
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 (sel
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
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
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
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.d
59 matches
Mail list logo
