--
To reproduce that, this is the relevant config stanza:
===8<
torlibera = {
type = "IRC";
nick = "manny";
username = "manny";
realname = "manny";
sasl_mechanism = "ex
Package: irssi
Version: 1.4.3-2
Severity: minor
Tags: upstream
X-Debbugs-Cc: debbug.ir...@sideload.33mail.com
In the course of troubleshooting connection issues I found some
problems with the /help pages that added to the frustration:
/help server:
① “/server connect” is indistinguised from “/co
Package: irssi
Version: 1.4.3-2
Severity: wishlist
Tags: upstream
X-Debbugs-Cc: debbug.ir...@sideload.33mail.com
The OFTC onion server is:
ircs://oftcnet6xg6roj6d7id4y4cu6dchysacqj2ldgea73qzdagufflqxrid.onion:6697
That onion has some load balancing function so there are multiple
different host
* Agustin Martin 'agmar...@debian.org' via 33Mail
[2025-04-03 09:17]:
>
> If the same happens to you, I am afraid linuxdoc-tools is not the program
> you expect, but your remarks are valid anyway. Please let me know if the
> same happens to your .gpx file after linking as favourites.sgml. By the
Package: irssi
Version: 1.4.3-2
Severity: normal
Tags: upstream
X-Debbugs-Cc: debbug.ir...@sideload.33mail.com
A command like this was given:
/server add -tls_cert ~/certs/oftc.pem -notls_verify -noauto -network toroftc
-tls_pinned_pubkey
63:0F:19:BB:AF:61:5A:9F:B1:03:98:0A:70:4A
* Enrico Scholz [2010-03-29 08:03]:
>
> dunno; there was neither a response on the maillist nor in the bugtracker.
> Perhaps, proxies are such an exotic feature that nobody needs them.
The simplest users and use cases can escape the need for proxies, but
I will highlight a real need for proxy su
Package: linuxdoc-tools
Version: 0.9.82-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: debbug.linuxdoc-to...@sideload.33mail.com
A simple attempt to validate SGML conformance of a GPX file from OSMand fails:
$ linuxdoc -B check favourites.gpx
Processing file favourites.gpx
LinuxdocTools::p
Package: pdftk-java
Version: 3.3.2-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: sid.stew...@pdflabs.com, debbug.pdftk-j...@sideload.33mail.com
This bug was previously reported:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799526
It was closed but the bug still persists in the current v
Package: pdftk-java
Version: 3.3.2-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: sid.stew...@pdflabs.com, debbug.pdftk-j...@sideload.33mail.com
Some PDFs contain OCG layers, where some content is assigned to a
layer that users can toggle the visibility of. For LaTeX users the
ocgx2 package provi
t; UIDL
fetchmail: POP3< RESP-CODES
fetchmail: POP3< PIPELINING
fetchmail: POP3< AUTH-RESP-CODE
fetchmail: POP3< STLS
fetchmail: POP3< USER
fetchmail: POP3< SASL PLAIN LOGIN
fetchmail: POP3< .
fetchmail: 127.0.0.1: WARNING: server offered STLS, but sslproto '' given.
Package: djvulibre-bin
Version: 3.5.28-2+b1
Severity: normal
Tags: upstream
X-Debbugs-Cc: debbug.djvulibre-...@sideload.33mail.com
A multipage DjVu file had a bookmark for every page (14 pages thus 14
bookmarks in my test). I deleted pages 2 to 14 this way:
$ for i in {14..2}; do djvm -d file.d
Package: imagemagick-doc
Version: 8:6.9.11.60+dfsg-1.6+deb12u2
Severity: normal
X-Debbugs-Cc: debbug.imagemagick-...@sideload.33mail.com
The “man identify” command suggests getting more documentation here:
file:///usr/share/doc/imagemagick-6-common/html/www/identify.html
or
https://www.imagem
Package: unpaper
Followup-For: Bug #1082830
X-Debbugs-Cc: debbug.1082...@sideload.33mail.com
The defect is very reproduceable when the width well exceeds 2550
pixels. However, even when an image is normal (2550 pixels wide a4,
300dpi), it sometimes still truncates ⅓ of the image.
The following tw
Package: djvulibre-bin
Version: 3.5.28-2+b1
Severity: important
Tags: upstream
X-Debbugs-Cc: debbug.djvulibre-...@sideload.33mail.com
The djvm tool crash with the following output:
===8<
$ djvm -c collection.djvu extracted_page*.djvu
*** [1-11711] Failed to
Package: sane
Version: 1.0.14-17
Severity: important
Tags: upstream
X-Debbugs-Cc: debbug.s...@sideload.33mail.com
The scanadf command apparently does not pass the --adf option to the
HP driver, so the device scans the platen instead of using the ADF:
===8<
Package: sane
Version: 1.0.14-17
Severity: normal
Tags: upstream
X-Debbugs-Cc: debbug.s...@sideload.33mail.com
When trying to list the devices (-L or --list-devices), there is some
useful output followed by a segfault:
===8<
$ scanadf -L
device `escl:http:/
Package: wget
Version: 1.21.3-1+b2
Severity: normal
Tags: upstream
X-Debbugs-Cc: debbug.w...@sideload.33mail.com
Apparently when a URL refers to a directory that redirects to a file,
wget gives up instantly without checking the redirect header. This is
a sample broken session:
===8<--
Package: gimp
Version: 2.10.34-1+deb12u2
Severity: normal
Tags: upstream
X-Debbugs-Cc: debbug.g...@sideload.33mail.com
After creating a path, every single function in the menus was examined
in search of the /text along path/ function. It does not
exist. According to this guide:
https://docs.gim
I did another test: used GIMP to crop ½ of a 600 DPI image so that
there would be as many pixels wide as there would be for a full 300
DPI page. Then fed that into unpaper. There was no data loss.
So apparently the unpaper bug manifests when an image is more than
~2550 pixels wide.
Package: unpaper
Version: 7.0.0-0.1
Severity: normal
Tags: upstream
X-Debbugs-Cc: debbug.unpa...@sideload.33mail.com
The man page states:
> Input and output files can be in either .pbm, .pgm or .ppm format,
> thus generally in .pnm format, as also used by the Linux scanning
> tools scanimag
Package: unpaper
Version: 7.0.0-0.1
Severity: normal
Tags: upstream
X-Debbugs-Cc: debbug.unpa...@sideload.33mail.com
Control: forwarded -1 https://github.com/unpaper/unpaper/issues/230
When the input file is 600 dpi, the leftmost 25% and rightmost 25% of
the content is truncated. Only the middle 5
Package: wkhtmltopdf
Version: 0.12.6-2+b1
Severity: normal
Tags: upstream
X-Debbugs-Cc: debbug.wkhtmlto...@sideload.33mail.com
I’ll start by saying the documentation is rough and incomplete, some
of which is related to the bug at hand:
① The synopsis in the man page is
“wkhtmltopdf [GLOBAL OPTION
Package: pdf2djvu
Version: 0.9.18.2-2+b2
Severity: wishlist
Tags: upstream
X-Debbugs-Cc: debbug.pdf2d...@sideload.33mail.com
If a doc is scanned then unpaper is used to produce a bilevel PBM
file, which is then converted to PNG and embedded as-is without
manipulation into a PDF, the result is a re
Package: poppler-utils
Version: 22.12.0-2+b1
Severity: minor
X-Debbugs-Cc: debbug.poppler-ut...@sideload.33mail.com
The pdftocairo man page starts with:
> NAME
>pdftocairo - Portable Document Format (PDF) to
> PNG/JPEG/TIFF/PDF/PS/EPS/SVG using cairo
> SYNOPSIS
>pdftocairo [optio
For quotes below:
eb ← Eduard Bloch
np ← Norbert Preining
eb> The manpage refers to ONLINE documentation. IMHO this should be part
eb> of a package and NOT require a user to establish internet
eb> connection.
Indeed, docs that are exclusively online are a detriment to the
quality of Debian.
> Since the strace indicates the program gets stuck inside jemalloc,
> I’ve tried to recompile dig with and without jemalloc and the
> aforementioned behavior doesn’t happen when BIND 9 is not compiled
> with jemalloc.
I just tested with a torsocks alternative and there was no issue with
dig doing
Package: bugs.debian.org
Severity: normal
X-Debbugs-Cc: debbug.bugs.debian@sideload.33mail.com
When viewing a bug report at bugs.debian.org, there is a tickbox to
“Display info messages”. That did not used to be a tickbox. I don’t
recall how it was presented but it used to work before it becam
* Ondřej Surý [2024-09-04 11:16]:
> First of all, why do you spam i...@isc.org? The ISC pages clearly state how
> you should report bugs in BIND 9.
First of all, please read your own source before taking a hostile
posture with uncivil tone. I will quote it for you here and give you
the exact URL
Package: bind9-dnsutils
Version: 1:9.18.28-1~deb12u2
Severity: normal
Tags: upstream
X-Debbugs-Cc: i...@isc.org, debbug.bind9-dnsut...@sideload.33mail.com
To do an MX lookup over Tor, this command has worked for for years:
$ torsocks dig @"$dns_server" -t mx -q "$email_domain" +noclass +nocomme
Package: aptitude-common
Version: 0.8.13-5
Severity: normal
X-Debbugs-Cc: debbug.aptitude-com...@sideload.33mail.com
This was executed when connected to a good high-speed Internet
connection:
$ aptitude upgrade -D
That fetched all pkgs without installing them. Then a week later when
on a cappe
Package: fetchmail
Version: 6.4.37-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: debbug.fetchm...@sideload.33mail.com
The failure scenario played out like this:
① sent a message that was larger than the receiving server accepts
② the email provider’s SMTP server rightfully generated a bounce me
Package: dino-im
Version: 0.4.2-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: cont...@dino.im, debbug.dino...@sideload.33mail.com
Dino crashed instantly after launch before a GUI could render. The
terminal message was:
Error select: arp.c:202 arp_check: Invalid argument
This is normally quit
Package: latexdiff
Version: 1.3.2-1
Followup-For: Bug #1078251
X-Debbugs-Cc: debbug.1078...@sideload.33mail.com
This was in part a stupid user error, although in the end I think
latexdiff could still use a fix here. This comment made me realise
there is a bit of configurability, which is essential
Package: latexdiff
Version: 1.3.2-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: tilm...@gfz-potsdam.de, debbug.latexd...@sideload.33mail.com
An old version has text like this:
\raisebox{-4\baselineskip}{\begin{minipage}…\end{minipage}}
A new version has instead:
\raisebox{-5\baselineskip}
Package: latexdiff
Version: 1.3.2-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: tilm...@gfz-potsdam.de, debbug.latexd...@sideload.33mail.com
Text inside the \colchunk command (which is used inside a parcolumns
environment) escapes the diffing algorithm. Text that is inside a
parcolumns environme
> Dear reporter. Without access to the report-old.tex and report_new.tex
> files this bug report is impossible to address.
I just sent you the documents directly, which will reproduce the
issue. At the moment I would rather not publish them here.
What I will say for anyone else who wants to work
Package: latexdiff
Version: 1.3.2-1
Followup-For: Bug #1077836
X-Debbugs-Cc: debbug.1077...@sideload.33mail.com
After letting it run 24 hours it’s still running. So I’m pulling the
plug.
Package: latexdiff
Version: 1.3.2-1
Severity: important
Tags: upstream
X-Debbugs-Cc: frederik.tilm...@gfz-potsdam.de,
debbug.latexd...@sideload.33mail.com
This was executed:
$ latexdiff report_old.tex report_new.tex > report_diff.tex
After 11 hours the process is still running hard with CPU p
Package: hplip
Version: 3.22.10+dfsg0-2
Severity: normal
Tags: upstream
X-Debbugs-Cc: debbug.hp...@sideload.33mail.com
Control: forwarded -1 https://bugs.launchpad.net/hplip/+bug/1779307
This bug was reported upstream six years ago. A patch was submitted by
a user in that same report. Still today
Package: dino-im
Version: 0.4.2-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: debbug.dino...@sideload.33mail.com
Control: forwarded -1 https://github.com/dino/dino/issues/971
Dino-im defaults to insecure. This is a terrible security issue
because users are being setup to expose sensitive informa
:
poll pop.yandex.com
no dns
plugin "socat STDIO SOCKS4A:127.0.0.1:%h:%p,socksport=9050"
protocol pop3
port 995
username manny
sslproto 'SSL3+'
sslcertck
sslfingerprin
I just did a variety of tests with linux-image-6.1.0-21-amd64
booted. The bugs manifesting from gimp and localc certainly are not
fixed or avoided in any way.
Gimp threshold dialog and localc background color changing both led to
severe issues.
I tried to change the background on a few cells in l
* Jochen Sprickerhof [2024-07-13 11:14]:
>
> But also this: 5.10.0-28-amd64 is from around 2020 and does not seem to be
> from Debian. Can you retry with the Debian bookworm kernel (currently
> 6.1.94+1)?
Kernels version 6+ are a disaster for me:
https://bugs.debian.org/cgi-bin/bugreport.cgi?
* Bastian Blank [2024-05-18 10:03]:
>
> You run with modules that modify low level system characteristics. Do
> the freezes also happen without?
Sorry I missed this reply. It did not make it to my inbox for some
reason and I am just noticing it today. This msg answers that
question:
https://
Package: curl
Version: 7.88.1-10+deb12u5
Severity: normal
Tags: upstream
X-Debbugs-Cc: dan...@haxx.se, debbug.c...@sideload.33mail.com
cURL neglects to follow a redirection for a particular URL
(“http://lawlita.com/”) which was originally a disposable email
service at one point but no longer exist
I just had another crash, this time with libreoffice-calc. When
working on a spreadsheet I get the similar behavior to gimp if I try
to change the background color of a collection of cells. Both screens
go black. Then the a second later the left display recovers and maybe
½ second later the right s
Package: artha
Version: 1.0.5-3
Severity: minor
X-Debbugs-Cc: debbug.ar...@sideload.33mail.com
There is frustration in finding an English dictionary by searching the
apt DB because there are lots of simple world lists and translation
libraries which do not provide word definitions. This is worsene
Package: gimp
Version: 2.10.34-1+deb12u2
Severity: critical
Tags: upstream
Justification: breaks the whole system
X-Debbugs-Cc: debbug.g...@sideload.33mail.com
Control: affects -1 sway xwayland
A source document was scanned as a grayscale PNG file. It was loaded
into GIMP, cropped, and followed by
Package: www.debian.org
Severity: normal
X-Debbugs-Cc: debbug.www.debian@sideload.33mail.com
I was looking for the meaning of the “quiet” modifier
(e.g. -qu...@bugs.debian.org). Navigation of the BTS
documentation is always painful. I often just have to control-click
links arbitrarily because
> Thanks for using kristall and filling bugs!
Thanks for supporting Kristall!
> I'm also on wayland but I'm not sure I'm seeing the problem. PS: I think
> I made it happen with DejaVu Sans, although Cantarell was the default one
> here and I don't remember changing it.
Maybe you originally insta
Package: kristall
Version: 0.4+dfsg-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: debbug.krist...@sideload.33mail.com
Control: forwarded -1 https://github.com/ikskuh/kristall/issues/147
There are enormous spaces between words with the default configs. This
is in wayland - not sure if that matter
Package: dino-im
Version: 0.4.2-1
Severity: minor
X-Debbugs-Cc: cont...@dino.im, debbug.dino...@sideload.33mail.com
There is no man page. There is a /usr/share/doc/dino-im/README.md but
it contains no user guide. From the Debian Policy Manual¹:
“If no manual page is available, this is considere
> You don't have any package installed.
> So the above output is correct.
>
> What do you expect?
I have had this file installed since 2015:
~/.local/share/texmf/tex/digsig.sty
tlmgr did not find it. But tlmgr found that tree because it added a DB
next to it:
~/.local/share/texmf/tlpkg/tex
> All the three bugs boil down to the same:
>
> tlmgr is NOT supported if you install it via Debian.
> Only VERY REDUCED functionality is provided, as you found.
In that case it should not exist in Debian. A pkg in the official
Debian repo should never be unsupported by Debian because Debian
supp
Package: texlive-base
Version: 2022.20230122-3
Severity: normal
X-Debbugs-Cc: debbug.texlive-b...@sideload.33mail.com
This is an attempt to list the locally install pkgs:
===8<
$ tlmgr --usermode info --only-installed
===8<--
Package: texlive-base
Version: 2022.20230122-3
Severity: normal
X-Debbugs-Cc: debbug.texlive-b...@sideload.33mail.com
I was surprised tlmgr had to access the cloud to tell me what version
of the acro pkg I have installed:
===8<
$ tlmgr --usermode info acr
Package: texlive-base
Version: 2022.20230122-3
Severity: minor
X-Debbugs-Cc: debbug.texlive-b...@sideload.33mail.com
I tried to start using tlmgr for the first time. It was pleasing to
find that “texdoc tlmgr” presented a PDF manual.
There is a natural expectation with linux tools that a PDF gui
Package: profanity
Version: 0.13.1-2
Severity: normal
Tags: upstream
X-Debbugs-Cc: debbug.profan...@sideload.33mail.com
The Profanity user guide¹ states
“Before you can start talking with a contact you need to
authenticate him by trusting his fingerprint(s).”
That seems to be true for some
> So we are back at tp_smapi being the culprit, not the kernel.
>
> I'm closing this bug here, as all points to tp_smapi as the culprit,
> both for the freeze and the installation problems.
I opened this bug report:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071520
and it turns out th
> This was reported and fixed in #1038207
>
> If you're using a bpo kernel, I highly suggest to use kernel modules
> from bpo too.
I appreciate the suggestion. But I have to wonder, why didn’t apt
prevent this? The purpose of apt is to manage dependencies and
version compatibility and it seems t
Package: wpasupplicant
Version: 2:2.10-12
Severity: important
X-Debbugs-Cc: debbug.wpasupplic...@sideload.33mail.com
There is no problem using a closed Wi-Fi network that requires a
password. But unencrypted open networks are all wholly unusable. Many
have been tried (libraries, cafes, etc). This
Package: tp-smapi-dkms
Version: 0.43-3
Severity: serious
Tags: upstream ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: debbug.tp-smapi-d...@sideload.33mail.com
Control: affects -1 linux-image-6.6.13+bpo-amd64
Kernel version 6.6.13-1~bpo12+1 fails
> The size of this deb should be correct, this is a meta-package, aka it
> only depends on other packages.
Oh, I was expecting it to be a real pkg and figured it must be the
root cause of things falling over (this caused me to disregard the
other errors a red herring). This fooled some collaborato
Package: util-linux
Version: 2.38.1-5+deb12u1
Severity: wishlist
Tags: upstream
X-Debbugs-Cc: debbug.util-li...@sideload.33mail.com
The /script/ command will faithfully capture a session including
anything sensitive. The resulting typescript is binary which hinders
efforts to edit out sensitive in
Package: wl-clipboard
Version: 2.1.0-0.1+b1
Severity: wishlist
Tags: upstream
X-Debbugs-Cc: debbug.wl-clipbo...@sideload.33mail.com
ANSI color codes, boldfacing, and various other control codes for
linefeeds is being captured literally with wl-copy and faithfully
reproduced when pasting. This beha
Package: linux-image-amd64
Version: 6.6.13-1~bpo12+1
Severity: normal
X-Debbugs-Cc: debbug.linux-am...@sideload.33mail.com
A kernel installation failed due to a corrupt deb file that could not
be unpacked. That was reported here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071467
Appare
Package: src:linux
Version: 6.6.13-1~bpo12+1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: debbug.linux-am...@sideload.33mail.com
To install linux-image-6.6.13+bpo-amd64, this command was executed:
$ apt -t bookworm-backports install linux-image-amd64
I have a transcrip
Package: curl
Version: 7.88.1-10+deb12u5
Severity: normal
Tags: upstream
X-Debbugs-Cc: dan...@haxx.se, debbug.c...@sideload.33mail.com
For years a script ran fine which contained a command like this:
$ curl -x socks5h://127.0.0.1:9050 --url 'ftps://host.domain.com/word1
word2/dir/' -T "$docume
Package: yt-dlp
Version: 2023.03.04-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: debbug.yt-...@sideload.33mail.com
The app incorrectly interprets a SOCKS proxy as an HTTP proxy. The
host machine has both kinds of proxies configured for Tor as follows:
* SOCKS proxy listening on port 9050
* HTT
Package: src:linux
Version: 6.1.66-1
Severity: important
Tags: upstream
X-Debbugs-Cc: debbug.linux-image-am...@sideload.33mail.com
Control: affects -1 linux-image-6.1.0-20-amd64
Control: affects -1 linux-image-6.1.0-21-amd64
An upgrade from Debian Bullseye to Bookworm resulted in a kernel that
spo
control: retitle 1070901 POP3 authentication failure and “error:0A00010B:SSL
routines::wrong version number” (2 bugs)
After submitting this bug report, I picked up on the nuance
“=> Send SSL data”, which differs from “=> Send header”.
So whatever is happening with that SSL data may be unrelated
Package: curl
Version: 7.88.1-10+deb12u5
Severity: normal
Tags: upstream
X-Debbugs-Cc: dan...@haxx.se, debbug.c...@sideload.33mail.com
cURL is unable to get a list of emails via POP3 from any of the
onionmail.info servers¹. These servers are fragile with quality issues
that show astonishing behavi
> I do not fully understand the comment, but to me it rather looks as if the
> author gave some comments on the new behavior of the package instead of
> accepting a bug.
The comment reveals that \maketitle was tinkered with in the newest
version, which is what the new error output points to as pro
X-Debbugs-Cc: cont...@mychemistry.eu
> normally I don't have time to care about issues like this. Are you willing
> to report this issue to the upstream author?
The upstream project is in MS Github which is a non-starter for
me. I’ll go as far as /reading/ from the site. I’m surprised such a
crip
Package: texlive-latex-extra
Version: 2022.20230122-4
Severity: normal
Tags: upstream
X-Debbugs-Cc: debbug.texlive-latex-ex...@sideload.33mail.com
After an upgrade from Bullseye to Bookworm, the acro package breaks
compilation even if no acronyms are even defined. Documents making use
of acro comp
> Maybe something to do with setting a weird PIPX_HOME ?
Good catch. As root:
===8<
$ PIPX_HOME=${prefix:-/opt/}/pipx PIPX_BIN_DIR=${prefix:-/usr/local}/bin pipx
list
venvs are in /opt/pipx/venvs
apps are exposed on your $PATH at /usr/local/bin
package
> I think you meant All*Versions*, not Names.
Oh, right.. must have been a copy-paste error.
> fwiw: I don't know about aptitude and if you think it should get some
> feature I suppose you should report it there, but for apt(-get) I have
> to note that both display "download size" as the size of
Package: cargo
Version: 0.66.0+ds1-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: debbug.ca...@sideload.33mail.com
Cargo has proven to be seriously fragile and flimsy when it comes to
fetching large files from the cloud. Cargo is also (inadvertently)
designed to trap users so there is no mechanis
Package: python3-pip
Version: 23.0.1+dfsg-1
X-Debbugs-Cc: debbug.python3-...@sideload.33mail.com
The man page tells users not to include a scheme:// on the proxy
setting, while the help pages require it:
===8<
$ python3 -m pip --help | grep proxy
--proxy
Package: pipx
Version: 1.1.0-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: debbug.p...@sideload.33mail.com
The argostranslate app was installed successfully by root as a
system-wide multi-user app as follows:
===8<
$ PIPX_HOME=${prefix:-/opt/}/pipx PIPX
> Please report this upstream to https://github.com/pypa/pip
> This does not sound Debian-specific at all.
>
> I can't reproduce the bug, without writing a proxy that causes a failure
> like you had, which is far beyond the effort I'm willing to put in here.
> You're in a much better position to a
Package: release-notes
Severity: normal
X-Debbugs-Cc: debbug.release-no...@sideload.33mail.com
One of the ways I got burnt in the Bullseye → Bookworm full-upgrade is
documented here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070203
There was no signal given before, during, or after th
> If you upgrade from bullseye to bookworm, your python3 is upgraded from
> 3.9 to 3.11. These are incompatible versions, and install libraries to
> different paths (when you use pip3).
> Anything installed with pip on 3.9 will not be importable in 3.11.
Thanks for the explanation. That explains b
Package: apt
Version: 2.6.1
Followup-For: Bug #990451
X-Debbugs-Cc: debbug.990...@sideload.33mail.com
I just ran into this problem.
Scenario: I am on a limited internet connection. So if I do “aptitude
install $somepkg” which then pulls in many other packages, I need to
know which packages will b
Package: python3-pip
Version: 23.0.1+dfsg-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: debbug.python3-...@sideload.33mail.com
This command was executed inside a venv:
===8<
$ pip install --proxy 127.0.0.1:8118 --log-file
"$log_dir"/pip-argostranslate_in
Package: python3-pip
Version: 23.0.1+dfsg-1
Severity: normal
X-Debbugs-Cc: debbug.python3-...@sideload.33mail.com
In Bullseye, an app was installed as follows:
===8<
$ torsocks pip3 install argostranslate
$ torsocks pip3 install --log-file $logs_dir/pip
Package: aria2
Version: 1.36.0-1
Severity: wishlist
Tags: upstream
X-Debbugs-Cc: debbug.ar...@sideload.33mail.com
The -o option is documented as follows:
===8<
-o, --out=
The file name of the downloaded file. It is always relative to the
dire
Package: aptitude
Version: 0.8.13-3
Severity: normal
X-Debbugs-Cc: debbug.aptit...@sideload.33mail.com
Aptitude gives a quite extreme warning if it is tasked with removing
packages from a foreign architecture. Packages for i386 were
originally installed to support wine32. The following transcript
Package: release-notes
Followup-For: Bug #987017
X-Debbugs-Cc: debbug.release-no...@sideload.33mail.com
@ Antoine Beaupre
> Is there any reason why we have all that diversity?
> …
> I'm not arguing for deprecating aptitude altogether, but it would seem
> to me that using less tools in the release
Package: passwordsafe
Version: 1.16.0+dfsg-4
Severity: important
Tags: upstream
X-Debbugs-Cc: debbug.passwords...@sideload.33mail.com
After upgrading from Bullseye to Bookworm, pwsafe crashes after
supplying the master password. Terminal output shows:
===8<
Package: postfix
Version: 3.7.10-0+deb12u1
Severity: normal
Tags: upstream
X-Debbugs-Cc: debbug.post...@sideload.33mail.com
When an smtp command failed to send an outbound message, Postfix
neglected to correctly log the syslog_name as specified by this
option:
-o syslog_name=postfix/smtptor
Th
Package: postfix
Version: 3.7.10-0+deb12u1
Severity: wishlist
Tags: upstream
X-Debbugs-Cc: debbug.post...@sideload.33mail.com
When an outbound smtp command fails, Postfix retries the command
*hundreds* of times per second. This was discovered in the course of
troubleshooting bug 1069949:
https:
Package: torsocks
Version: 2.4.0-1
Severity: important
Tags: upstream
X-Debbugs-Cc: debbug.torso...@sideload.33mail.com
After upgrading from Bullseye to Bookworm, this is what happens in the
logs when sending a Tor-routed message:
(/var/log/mail.log)
===8<
> Sorry, why report again?
> You don't get anything by reporting the same issue multiple times.
>
> Closing.
Sorry for the dupe!
Sometimes my submissions don’t make it to the BTS for some reason and
due to some tech issues on my side I thought this was one of those
cases. You apparently fixed i
Package: www.debian.org
Severity: normal
X-Debbugs-Cc: debbug.www.debian@sideload.33mail.com
The Bookworm release notes instruct users to “upgrade” to the latest point
release of Bullseye prior to upgrading to Bookworm:
https://www.debian.org/releases/stable/i386/release-notes/ch-upgradin
Package: www.debian.org
Severity: normal
X-Debbugs-Cc: debbug.www.debian@sideload.33mail.com
The Bookworm release notes instruct users to “upgrade” to the latest point
release of Bullseye prior to upgrading to Bookworm:
https://www.debian.org/releases/stable/i386/release-notes/ch-upgradin
Package: urlscan
Version: 0.9.5-1
Followup-For: Bug #1068257
It’s worth noting that there is a non-Debian project that’s related to
tracker pixels in email:
https://github.com/bengtan/email-untracker
That tool could not replace the proposal urlscan because it merely
looks for a few specific re
Package: urlscan
Version: 0.9.5-1
Severity: wishlist
Tags: upstream
X-Debbugs-Cc: debbug.urls...@sideload.33mail.com
Tracker pixels are quite commonly used to snoop on email
recipients. URLscan ignores URLs that specify an image to render.
Ideally there should be two lists of URLs:
1) URLs tha
Package: urlview
Version: 0.9-21+b1
Severity: wishlist
Tags: upstream
X-Debbugs-Cc: debbug.urlv...@sideload.33mail.com
Tracker pixels are quite commonly used to snoop on email
recipients. URLview ignores URLs that specify an image to render.
We can perhaps configure the REGEXP variable to match
Package: firefox-esr
Version: 102.6.0esr-1~deb11u1
Severity: normal
X-Debbugs-Cc: debbug.firefox-...@sideload.33mail.com
To report a bug on firefox-esr, I ran this:
$ torsocks /usr/bin/reportbug --offline --paranoid --no-cc --email="$email"
--draftpath="$draftpath" --output="$output_file" fire
1 - 100 of 113 matches
Mail list logo
