Package: dhttpd
Version: 1.02a-16.1
Severity: wishlist
I would be helpful if src/httpsock.cc would be updated to add in:-
{ .dat, application/x-ns-proxy-autoconfig },
{ .pac, application/x-ns-proxy-autoconfig },
Investigation confirms that 'apache2' default configuration does
Package: xtightvncviewer
Version: 1.3.9-4
Severity: grave
Tags: security
Justification: user security hole
As far as I can tell, The Debian pagkages for xtightvncviewer
(also included unchanged in ubuntu) are still vulnerable to
known problem fixed upstream.
Advisory here:-
Package: nginx
Version: 1.1.12-1
Severity: normal
Tags: ipv6
The version of nginx in Squeeze [0.7.67-3], without any reconfiguration,
[in particular, without adding any explicit listen configuration],
happily creates both a 0.0.0.0:80 IPv4-only and a [::]:80 IPv6-only
socket.
However,
Package: squid3
Version: 3.1.12-1
Severity: normal
Tags: upstream
The versions of Squid3 included in Debian Stable (squid 3.1 series),
include a known upstream bug, that miss_access rules do not work.
When using squid, to restrict use of upstream bandwidth without
disallowing cached requests, or
This bug, seems to be not quite so simple .
For example, is possible to /connect -x www.openssl.org 443
which is apparently TLS1.3-enabled and then GET / HTTP/1.0
with no issue.
But stunnel4 service providing TLS1.3 and this failure does happen!.
Puzzle...
--Simon
Package: tf5
Version: 5.0beta8-7
Severity: important
Tags: upstream
Dear Maintainer,
As per brief discussion with Russ Allberry, I posting this bug report.
tf5 in testing/sid and also debian buster, along with GNUtls versions thereby
provided, has some undeseriable interaction/bug.
Package: mitmproxy
Version: 4.0.4-5
Severity: wishlist
Dear Maintainer,
I would like mitmproxy 5.1.1 (or newer) packaged in debian.
In part, I have had had numerous incidental issues with certificate acceptance
with specific browser versions not documented in this bug, and considerable
Package: mitmproxy
Version: 5.1.1-1
Severity: grave
Justification: renders package unusable
Dear Maintainer,
As per comments added to #963067 , new mitmproxy seemingly cannot be used via
debian dependencies.
Relates to bugs #963181 #963114 that probably should be attended to first.
Copy
Package: python3-zstd
Severity: wishlist
Tags: upstream
For Python3 packaging team,
Please package python3 zstandard (libstd) bindings in debian.
https://pypi.org/project/zstd/
Zstandard is increasingly used in linux distributions packaging formats, and is
used in upstream python3 application
Dear Python3 application packagers team,
Please re-open the bug because Mitmproxy update 5.1.1 does not, in
fact, work, so far as I can see it cannot even work on a debian
'unstable' chroot due to internal dependencies as provided.
Despite 'patching out zstandard' done by packager, mitmproxy
Package: courier-mta
Version: 1.0.16-2
Severity: grave
Justification: renders package unusable
On current debian bullseye, courier-mta is not startable, looks like some kind
of
problem in init scripts (but could be executables/environment), as per system
info
and console log below.
Even with
I can confirm the same problem in Debian Squeeze6.0,
mini-httpd 1.19-9.2, just discovered it myself...
--Simon
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
I had intended this bug report to cover the squeeze version
(3.1.6-1.2+squeeze1) rather than the exact version on my
bugreport system at the time, although the bug-megadata does
not seem to reflect this ;-(.
--Simon
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a
Bug still present, affects for-example X201-Tablet, similar
hardware to T410 with Intel Graphics variant.
Affects at least debian kernels:-
5.6.0-2-amd64 5.6.14-2
5.7.0-2-amd64 5.7.10-1
5.7.0-3-amd64 5.7.17-1
--Simon
> Please do test as well the yesterday uploaded 5.8.7-1 but I suspect
> the bug is still present there.
Yes, indeed.
> To isolate the issue it might be worth trying to bisect were the issue
> is introduced and ideally then reported upstream.
Confirmed between 5.4.19-1 and 5.5.13-1.
> Some
Julian and bug 942318,
buster-backports now provides kernel 5.10.0-0.bpo.7 via the
buster-backports linux-image-amd64 linux-headers-amd64 packages.
Please confirm if this solves the issue for you, and close the bug.
--Simon
Dear Janusz
linux-image-amd64 linux-headers-amd64 have now come out in version
5.10.0-0.bpo.7 in buster-backports.
Please confirm the issue is solved for you (or not) by using that
kernel as above, so the bug report can be prgressed or closed.
--Simon
GSR,
Buster now has xserver-xorg-core version 2:1.20.4-1+deb10u3
[in-between the versions you quoted] and bullseye now has a newer
newer 2:1.20.11-1 version.
Given the date of your bug-report, it looks like you had the old
2018 version of the xorg-xserver package even though the
buster package
I can confirm the buster-backports now offers kernel
5.10.0-0.bpo.7-amd64 ..
Please test this following notes on previous bug pointer.
Can the bug now be closed, if that works, or doesn't -- I don't
think there is an X.org bug here.
--Simon
Can you confirm this issue is/is-not relevant any more on either of:-
* Debian Bullseye (testing)
* Debian Buster (stable) with the backported version of kernel
(5.10.0-0.bpo.7) installed.
Amdgpu has improved a long way since the time this bug report was
created, and would be good to get the
Alan and bug 899086,
Please try testing if this situation is improved or fixed in debian
testing (to soon become bullseye) images, similarly to as you did
before.
In fact the cdimage address you linked seems to be still exactly correct!.
I'd like to see bug-report either closed or updated for
Dear all on this bug,
I would like to briefly point out these crashes are showing kernel
errors, the kernel / amdgpu modesetting seems to be a very significant
part of the problem if I am not mistaken, this bug being against
the X-server component.
I would say, from the deb-10 / MX19.4 side of
I would generally say this looks like problems more in kernel
and firmware land, than bugs in the xserver driver to me...
I would, generally note a lot of wider AMD instability/issues
(that Alan) talks about improved a lot in 5.8-ubuntu
and 5.10-debian (bullseye and buster-backports) kernels.
Given some other experiences with amdgpu modesetting
problems, and looking at this bug, I would say:-
1) Please try updating all packages and reboot and
try again, kernel should be now 4.19.0-16
2) Secondly, enable backports
https://backports.debian.org/Instructions/
and then:-
I have had first-hand experience of these Xorg crashes and lockups
in combination with either sleep or un-powering monitors.
I would 100% agree with Hermann that this is highly likely to be
improved with kernel update.
In short, I would go to *at least* the buster-backports kernel i.e.
I can say, I understood a limitation of amdgpu kernel driver
has been not supporting VGA/analogue outputs in some (or all?)
cases. I understood this is part of the reason it is not the
default driver over radeon for some cards.
However, given many other other experiences and bugreports
with
Package: courier-mta
Version: 1.0.16-2
Severity: grave
Justification: renders package unusable
On current debian bullseye, courier-mta is not startable, looks like
some kind of
problem in init scripts (but could be executables/environment), as per
system info
and console log below.
Even with
On 17/07/2021 15.04, Simon Josefsson wrote:
> Hi. I just installed Debian bullseye daily today (linux-image-amd64
> version 5.10.40-1), and ran into this problem on a Lenovo X201. The
> message repeats every other second or so. I don't notice any other
I believe, the messages/behaviour was
I'm noticing bullseye still failing to connect to WPA3 where the server
and client driver and wpasupplicant should all support it.
I'm wondering if issues above are more around this issue:-
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/638
Apparently 1.30.2
I can conform that applying
https://github.com/irssi/irssi/commit/db2fed
to the irssi_1.2.3-1 debian source, builds and works on
debian bullseye i386 and amd64.
I have found no regressions, use 'saved' TLS+SASL network configs
*and* ad-hoc TLS network configs, both of which now work fine
in
I can confirm the same bug and the same solution (libmailtools-perl)
present in debian 11 bullseye...
--Simon
31 matches
Mail list logo
