Bug#1082601: wkhtmltopdf: The “--header-left '[webpage]'” option has no effect
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]... [OBJECT]... ”. The description of “[OBJECT]” is imprecise and tedious to read because BNF is not used. If it said: OBJECT := URL | table of contents that would be more clear. ② The proxy option is not completely described anywhere. The man page only has: “-p, --proxy ” with no discription of what the arguments refer to or what syntax is accepted. If the user figures out to do “wkhtmltopdf --readme”, some examples are given like a scheme of socks5://, but socks4a:// is rejected with a strange error. Users should not have to guess what is accepted. ③ The --header-left option is undocumented in both the man page and the readme. I had to go online to learn about it here: https://wkhtmltopdf.org/usage/wkhtmltopdf.txt When that doc says --header-*, it’s unclear what the asterisk can be. Examples mention left and right, but what about center? And in the end, it actually has no effect. There is no error message (which suggests that my version supports the option), yet the output has no header. The full command was: $ wkhtmltopdf --proxy socks5://127.0.0.1:9050\ --header-left '[webpage]'\ --background --images --disable-javascript\ --enable-local-file-access\ "$url_of_tor_hostile_website" output.pdf That command routes the request over Tor to a tor hostile website. The use-case was to document the tor hostility (the 403 error). It does produce the same 403 forbidden render that Firefox produces. But it’s missing the header. Perhaps the header would work if the website had been more inclusive. But in any case the header should be produced nonetheless. -- System Information: Debian Release: 12.7 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages wkhtmltopdf depends on: ii libc62.36-9+deb12u8 ii libgcc-s112.2.0-14 ii libqt5core5a 5.15.8+dfsg-11+deb12u2 ii libqt5gui5 5.15.8+dfsg-11+deb12u2 ii libqt5network5 5.15.8+dfsg-11+deb12u2 ii libqt5printsupport5 5.15.8+dfsg-11+deb12u2 ii libqt5svg5 5.15.8-3 ii libqt5webkit55.212.0~alpha4-30 ii libqt5widgets5 5.15.8+dfsg-11+deb12u2 ii libstdc++6 12.2.0-14 Versions of packages wkhtmltopdf recommends: ii xserver-xorg [xserver] 1:7.7+23 ii xvfb [xserver] 2:21.1.7-3+deb12u7 wkhtmltopdf suggests no packages. -- no debconf information
Bug#1081556: pdf2djvu: bilevel / bitonal documents result in excessively large files
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 relatively small PDF. Then ocrmypdf is used to embed text. When the output PDF from the above operations is fed to pdf2djvu, the resulting DjVu file is much _bigger_ than the PDF. This mostly defeats the point of the DjVu format. There must be a deficiency in pdf2djvu to cause that. When the PBM file is directly fed to cjb2, the resulting djvu file is rightfully _smaller_ than the PDF was. One could use cjb2 as a workaround, but the problem is the PDF middle step is useful for OCR ops. It’s worth noting that this project may have fallen out of maintenance: https://github.com/jwilk-archive/pdf2djvu/issues/157 The man page still points to that bug tracker and the mailing list (which also became inactive in 2022). Workaround (untested and complex!): A workaround that would result in text would normally involve using ocrodjvu, but that package has been killed off. It’s unclear if “djvused --save-script” can somehow be used. Perhaps it can be run on the fat OCRd djvu file, then the output could perhaps be injected into the lean file from cjb2 using “djvused -f”. -- System Information: Debian Release: 12.6 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pdf2djvu depends on: ii djvulibre-bin 3.5.28-2+b1 ii libc6 2.36-9+deb12u7 ii libdjvulibre21 3.5.28-2+b1 ii libexiv2-27 0.27.6-1 ii libgcc-s1 12.2.0-14 ii libgomp112.2.0-14 ii libgraphicsmagick++-q16-12 1.4+really1.3.40-4 ii libgraphicsmagick-q16-3 1.4+really1.3.40-4 ii libpoppler126 22.12.0-2+b1 ii libstdc++6 12.2.0-14 ii libuuid12.38.1-5+deb12u1 pdf2djvu recommends no packages. Versions of packages pdf2djvu suggests: ii poppler-data 0.4.12-1 -- no debconf information
Bug#1081416: poppler-utils: pdftocairo docs: man page BNF expresses a mandatory parameter as optional & somewhat hides quality reduction
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 [options] PDF-file [output-file] > DESCRIPTION >pdftocairo converts Portable Document Format (PDF) files … Bug ①: That BNF tells the user that they can simply run pdftocairo on a PDF doc with no options (as the square brackets imply that the token is not required). This immediately leaves the user wondering what effect that would have. In reality, pdftocairo terminates with an error. So the BNF needs to be fixed. Bug ②: It’s not obvious from the man page that quality will be altered. Consider the extraction_works.pdf sample that was attached to: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076283 The PDF is 2.1mb. When pdfimages extracts the PNG file (which involves no manipulation), the resulting PNG is about the same size as the only difference is metadata and overhead. But when “pdftocairo -png” is used, the output PNG is about half the size: ===8<-- $ identify pdfimages_extraction_works-000.png pdfimages_extraction_works-000.png PNG 2550x2452 2550x2452+0+0 8-bit sRGB 2130440B 0.000u 0:00.000 $ identify cairo_extraction_works-1.png cairo_extraction_works-1.png PNG 1275x2100 1275x2100+0+0 8-bit sRGB 1312420B 0.000u 0:00.000 ===8<-- The resolution was cut in half. Why is that? Some would say this fails the principle of least astonishment. Is it that the PDF metadata includes some parameters about paper size and resolution, and the embedded image was much larger than necessary for the PDF’s rendering? The man page says this: > The image dimensions will depend on the PDF page size and the > resolution. That’s clear to careful and meticulous readers but a bit subtle, no? I think misunderstanding by users can in part be attributed to the mention of “converts” in the description: “pdftocairo converts Portable Document Format (PDF) files”. Mere conversion does not lead the user to expect manipulation. If it would say something like: “pdftocairo RENDERS output images with the size properties specified by the PDF page spec… Resolution does not necessarily match that of the source images contained in the PDF and may be increased or decreased.” it might be more clear to users what to expect. Perhaps even better, it would also be extra helpful if the output text would inform the user of what happened. E.g. “output image resolution was decreased by 51% on image 1 page 1, 26% on image 2 page 1, 35% on image 1 page 2, …” etc. It is indeed useful that it generates output that matches the render quality specified by the PDF. This enables us to repackage a PDF for transmission such that size is not wasteful for a given quality. But users could be made more clearly aware of that. ③ (enhancement) It might also be useful if users could specify a “maintain source quality” option, whereby the output preserves the internal image parameters. Though I hesitate to suggest this because I realize that would only be sensible in situations where each page contains exactly one image to consumes the whole page (like a scanned doc). Nonetheless, I thought it would be worth mentioning. -- System Information: Debian Release: 12.6 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages poppler-utils depends on: ii libc6 2.36-9+deb12u7 ii libcairo2 1.16.0-7 ii libfreetype6 2.12.1+dfsg-5+deb12u3 ii liblcms2-2 2.14-2 ii libpoppler126 22.12.0-2+b1 ii libstdc++6 12.2.0-14 poppler-utils recommends no packages. poppler-utils suggests no packages. -- no debconf information
Bug#974724: no useful documentation of pdfjam commands
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. I think it’s the Debian Policy Manual that suggests docs be shipped with Debian, and that they be included with the package when small, or when large be packaged separately as $pkgname-doc. Sadly, the Debian Technical Committee was not interested in supporting an amendment to the Debian consititution to put documentation within reach of all users: https://linux.community/post/649372 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066034 np> Do you expect that pdfjam duplicates the complete documentation of np> pdfpages? This is a case where the docs themselves require substantial technical knowledge. It is comparable to “use the source, Luke”.. like reading code to understand how to use the app. So what Eduard is asking for is not duplication. It’s a user guide, as opposed to docs for LaTeX insiders. It’s unclear if pdfjam intends to exclude non-LaTeX users, or if it is intended to give non-LaTeX users access to LaTeX functionality. If it’s the former, then there should be a clear warning to non-LaTeX users that trying to learn to use it will make their brain explode. If it’s the latter, then the docs are unfit for the job. Certainly pdfjam has potential to be useful for users who don’t have a shred of LaTeX knowledge. np> Please bring this up to the author of pdfjam. Eduard apparently tried that first (see the link in the OP). eb> First, what is texdoc anyway? eb> eb> $ man pdfjam | grep texdoc > np> Did I send you that command line? I would normally expect that someone np> using Debian and has considerabl experience, is aware that the correct np> invocation is np> man texdoc np> ? The problem with that is a Debian user (even a veteran) does not generally know of the existence of texdoc (a precondition to running /man texdoc/). eb> A regular user has no idea about this command. Why should we even care? > np> Well, at least in the TeX World it is well known. Even as a LaTeX user, I don’t think I discovered the texdoc command until a decade after starting to use LaTeX, at which point I wished I had learnt about it sooner. It’s the job of documentation to inform users of relevant commands. Since /man pdfjam/ is incomplete, it should inform users about where the rest of the docs are. It should mention “texdoc pdfjam”. np> Ok, I pose you a good question: np> Please come up with a better way to provide 2.9G (!!!) of np> documentation, that is what TeX Live is shipping. np> Make a decent proposal, and send pull requests to the packaging np> infrastructure at github.com/debian-tex/ np> I am anxiously waiting. Anything upstream from Debian can wildly document their tools however they want, or not at all. Sometimes upstream packages do not even have a man page. Debian has its own standards and conventions for documentation. When for example, there is no upstream man page, the Debian pkg is required by Debian policies to supply one. A bug report for lack of man page can never be closed. That’s the Debian way. It stops short of actually requiring someone to fix the bug b/c at the same time Debian has a principle that no one is forced to do work. The case at hand is an incomplete man page. I don’t think “wontfix” is an appropriate treatment of a bug report on an incomplete man page because it seems to imply the bug report lacks merit. Maybe /you/ won’t fix it and that’s fair enough, but it should persist indefinitely as a valid open bug report that needs a fix. np> Because the author of pdfjam has decided so. If you don't like it, np> why don't you stop complaining and simply use a different tool? I np> already sugested one, pdftk. It’s good to suggest pdftk from a user support standpoint, so long as pdftk’s existence is not used as rationale not to improve pdfjam. Man pages often have a “SEE ALSO” section. It would be a good idea to add such a section to the pdfjam man page which references pdftk and pdfunite. The doc bugs I see are numbered below (some of which are not from this thread, as I encountered this thread with some doc bugs in mind). ① The man page contains incomplete BNF: ===8<-- SYNOPSIS pdfjam [OPTION [OPTION] ...] [SRC [PAGESPEC] [SRC [PAGESPEC]] ...] ===8<-- The BNF expansion for [OPTION], [SRC], and [PAGESPEC] are missing. That’s a defect. It vaguely says “Detailed information can be found via "pdfjam --help", and also in the web page mentioned below .” It does not say those places are where the missing BNF is. Users expect _detailed_ to mean extraneous detail about how to use a package. But the BNF is extremely basic information that should be defined on the man page, most certainly when the top
Bug#1080449: dig no longer works over tor; hangs and never times out
> 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 MX lookups over tor, which further suggests the problem is with torsocks. However, I must say I did not touch torsocks recently. In fact, I have pinned torsocks version 2.3.0-3 because bug 1069949 broke torsocks version 2.4.0-1. Version 2.3.0-3 of torsocks still functions for other applications. It only quit working for dig. So apparently dig uses some network facility that other apps do not which was recently broken in torsocks despite torsocks being pinned to version 2.3.0-3. MX lookups by way of torsocks+dig only broke relatively recently. I suppose a package I upgraded or installed recently must have some kind of interplay with torsocks or dig, though nothing looks obvious in the apt logs. Anyway, whoever tries to tackle this problem: if you cannot reproduce it, try torsocks version 2.3.0-3 with bind9-dnsutils version 1:9.18.28-1~deb12u2. Sorry for the erroneous report against bind9-dnsutils.
Bug#1080466: bugs.debian.org: (regression) the BTS “Display info messages” tickbox has no effect
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 became a tickbox. I seem to recall it was a hyperlink written as “toggle useless messages”. A tickbox is somewhat unusual when there is no form or submit button. Aesthetics aside, it does not function. Tested in a Chromium based browser and a Firefox based browser, ticking the box has no effect.
Bug#1080449: bind9-dnsutils: dig no longer works over tor; hangs and never times out
* 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¹. > ”BIND 9 Bugs/Feature Requests > > To report a non-security-related bug or request a feature in BIND, > please navigate to our GitLab instance and enter your issue > there. You will have the option of marking your issue confidential, > if necessary. You will need to create an account on GitLab, but you > can link your credentials from another GitLab instance or social > media account. Once you have logged your issue, you may follow up > with us via email to i...@isc.org.” In particular, be sure to read the last sentence where email is explicitly solicited for this scenario. The Gitlab instance as a bug tracker is a non-starter due to a broken CAPTCHA as a barrier to entry. It is therefore an exclusive website and I am in the excluded group. Please also familiarize yourself with Debian policy². Search for “Don't file bugs upstream” on that page. Note as well the Debian Social Contract³ which ¶3 states “We will not hide problems”. That principle implies bug tracker access particularly when upstream resources are exclusive. > Second, it’s not clear where the bug is. I would recommend running > the dig with -d argument and also using strace -f to see where the > full command gets stuck. The “-d” parameter is undocumented (another bug) and in this case it has no effect. No output is generated before the hang. When “strace -f” is used as follows: $ torsocks strace -f dig @"$dns_server" -d -t mx -q "$email_domain" +noclass +nocomments +nostats +short +tcp +nosearch The tail of the output when it hangs is as follows: ===8< … mprotect(0x7efeadb8d000, 4096, PROT_READ) = 0 mprotect(0x7efeae19a000, 4096, PROT_READ) = 0 mprotect(0x56499f748000, 4096, PROT_READ) = 0 mprotect(0x7efeae1ce000, 8192, PROT_READ) = 0 prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0 munmap(0x7efeae16c000, 101230) = 0 readlink("/etc/malloc.conf", 0x7ffdd2b44370, 4096) = -1 ENOENT (No such file or directory) mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7efeae184000 madvise(0x7efeae184000, 4096, MADV_DONTNEED) = 0 munmap(0x7efeae184000, 4096)= 0 getuid()= 1000 geteuid() = 1000 futex(0x7efeadf547c0, FUTEX_WAIT_PRIVATE, 2, NULL ===8< Footnotes: ¹ https://www.isc.org/reportbug/ ² https://www.debian.org/Bugs/Reporting ³ https://www.debian.org/social_contract
Bug#1080449: bind9-dnsutils: dig no longer works over tor; hangs and never times out
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 +nocomments +nostats +short +tcp +nosearch It just hangs forever and does not matter which DNS server is supplied. In the past 8.8.8.8 worked. It’s unclear whether there is a bug in the software or whether the network is broken, but certainly it’s a defect for dig to not timeout. By default it should timeout after 5 seconds. -- System Information: Debian Release: 12.6 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages bind9-dnsutils depends on: ii bind9-host [host] 1:9.18.28-1~deb12u2 ii bind9-libs 1:9.18.28-1~deb12u2 ii libc6 2.36-9+deb12u7 ii libedit2 3.1-20221030-2 ii libidn2-0 2.3.3-1+b1 ii libjemalloc2 5.3.0-1 ii libkrb5-3 1.20.1-2+deb12u2 ii libprotobuf-c1 1.4.1-1+b1 bind9-dnsutils recommends no packages. bind9-dnsutils suggests no packages. -- no debconf information
Bug#1080321: aptitude-common: TUI re-fetches packages already fetched by the CLI
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 capped Internet connection, aptitude was executed with no arguments to launch the TUI. This was done because the CLI gives no way to selectively exclude a package from the upgrade for an operation for just one execution. The TUI makes it possible to exclude a package on a one-off basis. These steps were followed: $ aptitude Entered “+” on the “Upgradeable” line Expanded the tree and highlighted a pkg to exclude from the upgrade Entered “:” to unmark a pkg Entered “u” on the “Upgradeable” line It proceeded to download /everything/. Internet credit was getting sucked dry. Why? I had to quickly kill the operation. Then I ran this: $ aptitude upgrade --simulate The output printed: “Need to get 1,979 kB/567 MB of archives,” That means only a small amount needs to fetched. Just two megs, likely a new prospective upgrade was detected the 1 week lag between the download. But the TUI was re-downloading all 567mb. The aptitude TUI and CLI should be storing the data in the same location. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled aptitude-common depends on no packages. Versions of packages aptitude-common recommends: ii aptitude 0.8.13-5 aptitude-common suggests no packages. -- no debconf information
Bug#1080025: fetchmail: Return-Path hdrs w/out domain causes fetchmail to generate an RFC non-compliant envelope
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 message and delivered it to the inbox of the sender. But the Return-Path: lacked a domain and was therefore RFC non-complaint. Specifically, the header was→ “Return-Path: ” ③ fetchmail fetched the bounce message then used the Return-Path header to attempt to construct a valid envelope-from address in the local SMTP session. It sent this→ “MAIL FROM: BODY=8BITMIME SIZE=4623”. That is also RFC non-compliant by today’s standards. IP addresses must be bracketed in order to be valid. (I think in the 1990s a naked IP address was valid) ④ Postfix locally generates another bounce message containing this: In: MAIL FROM: BODY=8BITMIME SIZE=4623 Out: 501 5.1.7 Bad sender address syntax The first defect to manifest is the email provider generating a malformed Return-Path (obviously not a fetchmail bug). The second bug is fetchmail botching the “MAIL FROM” header in attempt to salvage the bad Return-Path. It’s nice that fetchmail tries to be forgiving and work with bad input. But if it’s going to take that route then it needs to generate valid output. A low-effort fix is to simply add brackets around the IP address. A better fix is likely to extract a domain name from the “From:” header and use that instead of the localhost IP address. But note that it may be non-trivial considering that the “From:” field could legally contain mutliple addresses. Or the “From:” field could also be invalid in the same way, in which case finding a sensible domain might become more of a crap shoot. In my particular scenario, my email provider had a trivial and proper “From:” field as: mailer-dae...@mx.server.tld. Alternative /possible/ fix: Perhaps outsourcing this to formail is sensible? I sometimes have to process email locally by feeding messages with missing headers into procmail. E.g. $ formail < msg_with_bad_or_missing_headers > proper_msg.mbox I just did a couple tests with formail. The first msg was the same msg that fetchmail botched. When that same msg is fed to formail, formail generates a “From ” header at the top of the msg. Note the space after the From. That is apparently another way to embed the envelope-from. Formail ignored the malformed Return-Path header and used the From: header to generate the “From ” header. In another test, the Return-Path header on the input was made proper by adding an “@domain.tld”. In that case formail favored the Return-Path header over the From: header. Fetchmail could either duplicate that logic, or perhaps better outsource the job to formail to make use of code reuse benefits. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fetchmail depends on: ii adduser3.134 ii debianutils5.7-0.5~deb12u1 ii init-system-helpers1.65.2 ii libc6 2.36-9+deb12u7 ii libcom-err21.47.0-2 ii libgssapi-krb5-2 1.20.1-2+deb12u1 ii libkrb5-3 1.20.1-2+deb12u1 ii libssl33.0.11-1~deb12u2 ii lsb-base 11.6 ii sysvinit-utils [lsb-base] 3.06-4 Versions of packages fetchmail recommends: ii ca-certificates 20230311 Versions of packages fetchmail suggests: pn fetchmailconf ii postfix [mail-transport-agent] 3.7.10-0+deb12u1 ii systemd-resolved [resolvconf] 252.22-1~deb12u1 -- no debconf information
Bug#1079095: dino-im: crash → Error select: arp.c:202 arp_check: Invalid argument
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 quite serious but I have selected severity normal because this is a rare event. It only happened once ever (as far as I remember). I immediately re-ran it and it launched fine. So it’s not reproduceable. But since the error message gives a SLOC reference I figured it’s worth reporting. I always run it this way: $ firejail --net=tornetwork0 --dns="$DNS"\ --whitelist="$HOME"\ --whitelist="$HOME"/.local/share/dino\ dino-im -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dino-im depends on: ii dino-im-common 0.4.2-1 ii libadwaita-1-0 1.2.2-1 ii libc6 2.36-9+deb12u7 ii libcairo2 1.16.0-7 ii libgcc-s1 12.2.0-14 ii libgcrypt20 1.10.1-3 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libgee-0.8-20.20.6-1 ii libglib2.0-02.74.6-2+deb12u2 ii libgnutls30 3.7.9-2+deb12u2 ii libgpgme11 1.18.0-3+b1 ii libgraphene-1.0-0 1.10.8-1 ii libgstreamer-plugins-base1.0-0 1.22.0-3+deb12u1 ii libgstreamer1.0-0 1.22.0-2 ii libgtk-4-1 4.8.3+ds-2+deb12u1 ii libgtk-4-media-gstreamer4.8.3+ds-2+deb12u1 ii libicu7272.1-3 ii libnice10 0.1.21-1 ii libpango-1.0-0 1.50.12+ds-1 ii libqrencode44.1.1-1 ii libsignal-protocol-c2.3.2 2.3.3-3 ii libsoup-3.0-0 3.2.2-2 ii libsqlite3-03.40.1-2 ii libsrtp2-1 2.5.0-3 ii libstdc++6 12.2.0-14 ii libwebrtc-audio-processing1 0.3-1+b1 Versions of packages dino-im recommends: ii ca-certificates 20230311 ii dbus1.14.10-1~deb12u1 ii fonts-noto-color-emoji 2.042-0+deb12u1 ii network-manager 1.42.4-1 dino-im suggests no packages. -- no debconf information
Bug#1078251: latexdiff: this could be a user error
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: https://github.com/ftilmann/latexdiff/issues/294#issuecomment-1950289552 So then I attempted to the following command variations: $ latexdiff --append-safecmd=append-file='colchunk' old.tex new.tex > diff.tex $ latexdiff --append-context1cmd='colchunk' old.tex new.tex > diff.tex $ latexdiff --append-context2cmd='colchunk' old.tex new.tex > diff.tex $ latexdiff --append-safecmd=append-file='bilingual' old.tex new.tex > diff.tex $ latexdiff --append-context1cmd='bilingual' old.tex new.tex > diff.tex $ latexdiff --append-context2cmd='bilingual' old.tex new.tex > diff.tex Those did not make a difference. But matters are apparently complicated by the \bilingual command that wraps a sequence of \colchunk commands. When the \bilingual command is removed and \colchunk is used more directly, then this command works: $ latexdiff --append-context1cmd='colchunk' old.tex new.tex > diff.tex It’s unclear why --append-safecmd='bilingual' failed to have effect but I get the impression some PERL is needed. The --append-context*cmd variations only operate on the last argument to bilingual, but in this case there are two paragraph text arguments so the first paragraph is ignored. The latexdiff default configuration should probably treat colchunk correctly in the normal case. And the configuration options probably need an extra parameter so users can specify which arguments to a custom command need treatment.
Bug#1078256: latexdiff: slight modification to a length passed to \raisebox results in diff output that does not compile
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}{\begin{minipage}…\end{minipage}} This results in diff output that latexpdf chokes on. Sample input files are attached. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages latexdiff depends on: ii perl 5.36.0-7+deb12u1 Versions of packages latexdiff recommends: ii texlive-latex-base 2022.20230122-3 ii texlive-latex-extra2022.20230122-4 ii texlive-latex-recommended 2022.20230122-3 ii texlive-plain-generic 2022.20230122-4 Versions of packages latexdiff suggests: ii git 1:2.39.2-1.1 -- no debconf information \documentclass{minimal} \usepackage[UKenglish,dutch]{babel} \begin{document} This sample document demonstrates a latexdiff defect whereby a slight change to a length passed to raisebox results in an uncompilable diff.\\ \noindent\begin{minipage}[b]{0.32\textwidth}\selectlanguage{dutch} blurb of Dutch text here.% \end{minipage}\hfill% \raisebox{-4\baselineskip}{% \begin{minipage}[b]{0.36\textwidth} \rule{\textwidth}{\textwidth}% \end{minipage}}\hfill% \noindent\begin{minipage}[b]{0.28\textwidth}\selectlanguage{UKenglish} blurb of English text here.% \end{minipage}% \end{document} \documentclass{minimal} \usepackage[UKenglish,dutch]{babel} \begin{document} This sample document demonstrates a latexdiff defect whereby a slight change to a length passed to raisebox results in an uncompilable diff.\\ \noindent\begin{minipage}[b]{0.32\textwidth}\selectlanguage{dutch} altered blurb of Dutch text here.% \end{minipage}\hfill% \raisebox{-5\baselineskip}{% \begin{minipage}[b]{0.36\textwidth} \rule{\textwidth}{\textwidth}% \end{minipage}}\hfill% \noindent\begin{minipage}[b]{0.28\textwidth}\selectlanguage{UKenglish} altered blurb of English text here.% \end{minipage}% \end{document}
Bug#1078251: latexdiff: (parcolumns incompatible) Text inside a \colchunk is ignored by diffing algorithm
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 environment but not in a colchunk is treated correctly. But \colchunk is essential to the core functionality of parcolumns. A minimal working example is attached. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages latexdiff depends on: ii perl 5.36.0-7+deb12u1 Versions of packages latexdiff recommends: ii texlive-latex-base 2022.20230122-3 ii texlive-latex-extra2022.20230122-4 ii texlive-latex-recommended 2022.20230122-3 ii texlive-plain-generic 2022.20230122-4 Versions of packages latexdiff suggests: ii git 1:2.39.2-1.1 -- no debconf information \documentclass{minimal} \usepackage[UKenglish,dutch]{babel} \usepackage{parcolumns} \newcommand{\bilingual}[2]{% \colchunk{\selectlanguage{dutch}#1}% \colchunk{\selectlanguage{UKenglish}#2}% \colplacechunks% } \begin{document} This minimal sample document demonstrates a latexdiff defect whereby text inside a parcolumns environment escapes the diffing algorithm. The next paragraph from the GDPR is printed in a two column format. Words are added to the left side (Dutch) but latexdiff does not notice.\\ \centerline{\textbf{broken diff:}} \begin{parcolumns}[nofirstindent]{2} \bilingual{% De betrokkene heeft het recht niet te worden onderworpen aan een uitsluitend op geautomatiseerde verwerking, waaronder profilering, gebaseerd besluit waaraan voor hem rechtsgevolgen zijn verbonden of dat hem anderszins in aanmerkelijke mate treft.\\ }{% The data subject shall have the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly significantly affects him or her.\\ } The new version of text prevails, but it has no markups. Below is the same text laid out inside adjecent minipages instead, which shows latexdiff working as expected.\\ \end{parcolumns} \centerline{\textbf{working diff:}} \noindent\begin{minipage}[t]{0.49\textwidth}\selectlanguage{dutch} De betrokkene heeft het recht niet te worden onderworpen aan een uitsluitend op geautomatiseerde verwerking, waaronder profilering, gebaseerd besluit waaraan voor hem rechtsgevolgen zijn verbonden of dat hem anderszins in aanmerkelijke mate treft.% \end{minipage}\hfill% \noindent\begin{minipage}[t]{0.47\textwidth}\selectlanguage{UKenglish} The data subject shall have the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly significantly affects him or her.% \end{minipage}% \end{document} \documentclass{minimal} \usepackage[UKenglish,dutch]{babel} \usepackage{parcolumns} \newcommand{\bilingual}[2]{% \colchunk{\selectlanguage{dutch}#1}% \colchunk{\selectlanguage{UKenglish}#2}% \colplacechunks% } \begin{document} This minimal sample document demonstrates a latexdiff defect whereby text inside a colchunk environment escapes the diffing algorithm. The next paragraph from the GDPR is printed in a two column format. Words are added to the left side (Dutch) but latexdiff does not notice.\\ \centerline{\textbf{broken diff:}} \begin{parcolumns}[nofirstindent]{2} \bilingual{% De betrokkene heeft het recht niet te worden onderworpen aan een uitsluitend op geautomatiseerde verwerking, waaronder profilering, gebaseerd besluit waaraan voor hem of haar rechtsgevolgen zijn verbonden of dat hem of haar anderszins in aanmerkelijke mate treft.\\ }{% The data subject shall have the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly significantly affects him or her.\\ } The new version of text prevails, but there are no markups. Below is the same text laid out inside adjecent minipages instead, which shows latexdiff working as expected.\\ \end{parcolumns} \centerline{\textbf{working diff:}} \noindent\begin{minipage}[t]{0.49\textwidth}\selectlanguage{dutch} De betrokkene heeft het recht niet te worden onderworpen aan een uitsluitend op geautomatiseerde verwerking, waaronder profile
Bug#1077836: latexdiff: processing 13-page document takes indefinite time (11 hours so far)
> 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 on this is that the document was split into several pieces and latexdiff executed on each piece, in attempt to isolate the problem. Every piece ran quickly and correctly terminated. So the defect is perhaps related to a transition from one piece to another.
Bug#1077836: latexdiff: comments here
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.
Bug#1077836: latexdiff: processing 13-page document takes indefinite time (11 hours so far)
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 pegged around 99% according to /top/. CPU fan is running which also indicates hard work is being done. There is no output to indicate how much progress has been made. When compiled, the document yields 13 pages in PDF form. I do not imagine that 11+ hours is reasonable for that volume. Bug fixes and enhancements are needed. ① There is likely some kind of faulty logic such as an endless loop ② A progress indicator is needed ③ A detailed debug log is needed ④ Periodic assessments should be made throughout the processing as to whether reasonable progress is being made. If an hour is spent on a normal sized paragraph, the tool should abort and perhaps give an indication of which segment of text is exceeding time thresholds. This should be configurable but many users don’t know what to expect so there should be a reasonable default. I’ve seen latexdiff take forever in past executions and had to give up and kill it. The document latexdiff struggles with at the moment is a bilingual document that uses parcolumns to produce a left and right column. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages latexdiff depends on: ii perl 5.36.0-7+deb12u1 Versions of packages latexdiff recommends: ii texlive-latex-base 2022.20230122-3 ii texlive-latex-extra2022.20230122-4 ii texlive-latex-recommended 2022.20230122-3 ii texlive-plain-generic 2022.20230122-4 Versions of packages latexdiff suggests: ii git 1:2.39.2-1.1 -- no debconf information
Bug#1077183: hplip: compression option ignored, PNG format missing from compression options, raw produces a jpg…
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 the patch has not been integrated upstream. This is not just some oscure corner case bug. It’s a fundamental failure of basic options that every user experiences. There is a long list of bug reports that come with patches and it seems a lot of patches are not getting integrated: https://bugs.launchpad.net/hplip/+patches It seems as if HP is in over their head or relatively inactive. Not sure if there anything Debian can or should do about that, but thought it should be highlighted here in the Debian BTS. It’s worth noting that the upstream bug tracker is rightfully mentioned in the man page and in the reportbug submission dialog, but not on: https://packages.debian.org//hplip-data -- Package-specific info: -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages hplip depends on: ii adduser3.134 ii cups 2.4.2-3+deb12u5 ii hplip-data 3.22.10+dfsg0-2 ii libc6 2.36-9+deb12u7 ii libcups2 2.4.2-3+deb12u5 ii libdbus-1-31.14.10-1~deb12u1 ii libhpmud0 3.22.10+dfsg0-2 ii libpython3.11 3.11.2-6 ii libsane-hpaio 3.22.10+dfsg0-2 ii libsane1 1.2.1-2 ii lsb-base 11.6 ii printer-driver-hpcups 3.22.10+dfsg0-2 ii python33.11.2-1+b1 ii python3-dbus 1.3.2-4+b1 ii python3-gi 3.42.2-3+b1 ii python3-pexpect4.8.0-4 ii python3-pil9.4.0-1.1+b1 ii python3-reportlab 3.6.12-1 ii sysvinit-utils [lsb-base] 3.06-4 ii wget 1.21.3-1+b2 ii xz-utils 5.4.1-0.2 Versions of packages hplip recommends: ii avahi-daemon 0.8-10 ii policykit-1 122-3 ii printer-driver-postscript-hp 3.22.10+dfsg0-2 ii sane-utils1.2.1-2 Versions of packages hplip suggests: ii hplip-doc 3.22.10+dfsg0-2 pn hplip-gui pn python3-notify2 pn system-config-printer -- no debconf information
Bug#1076963: dino-im: (security) defaults to insecure, padlock waaaay to subtle, people are getting stung by this!
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 information. The padlock is grey, and when it’s unlocked there is only a very tiny gap between the shank and the body, so it’s very hard to notice the unlocked state before sending a message. Then after sending a message, sometimes there is a red padlock and sometimes just a grey checkmark. The red unlocked padlock has the same problem as the grey unlocked padlock: very hard to notice that it’s unlocked. It’s so hard to notice that I only discovered the problem after *months* of unintentionally exposed chatter. I am gutted. I’m also not the only one. Lots of people are getting stung by this. The bug was reported upstream *4 years* ago. I am reporting it here to make this bug loud and clear for other Debian users in an effort to try to mitigate more people getting burnt. These changes are essential: ① the default should be OMEMO or OpenPGP. Does not matter which, but /unencrypted/ is a reckless default. ② there needs to be an option to force a loud popup warning that interrupts all unencrypted transmission attempts. It should also default to ENABLED. The pop-up should have a “don’t show me this again” button so security ambivalent users only see the nag once. ③ the padlock icon in the message entry field should be bigger. ④ the unlocked state should not just be a tiny gap between the shank and the body; it should be rotated 180° so it’s more clear that it’s in the open state. ⑤ the open state should never be red, green, blue, or grey. Yellow is probably best, perhaps with a “☣” or “⚠” as well. ⑥ in fact, the unlocked padlock icon should be blinking. This would be quite annoying for people who intend to have insecure comms, so the blinking should probably be tied to the toggle option described in ② above. ⑦ fix the inconsistent indicator on insecure messages. It should not be a just a checkmark sometimes and sometimes both a checkmark and an unlocked padlock. In fact, the open padlock is should be paired with the word “unencrypted” spelled out next to it. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dino-im depends on: ii dino-im-common 0.4.2-1 ii libadwaita-1-0 1.2.2-1 ii libc6 2.36-9+deb12u7 ii libcairo2 1.16.0-7 ii libgcc-s1 12.2.0-14 ii libgcrypt20 1.10.1-3 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libgee-0.8-20.20.6-1 ii libglib2.0-02.74.6-2+deb12u2 ii libgnutls30 3.7.9-2+deb12u2 ii libgpgme11 1.18.0-3+b1 ii libgraphene-1.0-0 1.10.8-1 ii libgstreamer-plugins-base1.0-0 1.22.0-3+deb12u1 ii libgstreamer1.0-0 1.22.0-2 ii libgtk-4-1 4.8.3+ds-2+deb12u1 ii libgtk-4-media-gstreamer4.8.3+ds-2+deb12u1 ii libicu7272.1-3 ii libnice10 0.1.21-1 ii libpango-1.0-0 1.50.12+ds-1 ii libqrencode44.1.1-1 ii libsignal-protocol-c2.3.2 2.3.3-3 ii libsoup-3.0-0 3.2.2-2 ii libsqlite3-03.40.1-2 ii libsrtp2-1 2.5.0-3 ii libstdc++6 12.2.0-14 ii libwebrtc-audio-processing1 0.3-1+b1 Versions of packages dino-im recommends: ii ca-certificates 20230311 ii dbus1.14.10-1~deb12u1 ii fonts-noto-color-emoji 2.042-0+deb12u1 ii network-manager 1.42.4-1 dino-im suggests no packages. -- no debconf information
Bug#1076604: fetchmail: “configuration invalid, you normally need --ssl for port 995” ← probably incorrect msg
Package: fetchmail Version: 6.4.37-1 Severity: minor Tags: upstream X-Debbugs-Cc: debbug.fetchm...@sideload.33mail.com This warning: fetchmail: WARNING: pop.yandex.com configuration invalid, you normally need --ssl for port 995/service pop3s. is triggered by this configuration stanza: 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 sslfingerprint "94:6A:CF:B1:A7:BE:30:11:B5:E0:B1:F9:0C:3B:37:B7" fetchall The 'SSL3+' is not accidental or arbitrary. It is there after a struggle with the normal parameters (“ssl”) and experimentation found SSL3+ was necessary in order to establish a connection. I stopped using Yandex when they started blocking Tor years ago, so it’s unclear whether “SSL3+” still needed. But that’s irrelevant anyway. The problem is that fetchmail is making a false assertion. It’s a nuance of English but fetchmail cannot know for certain if this stanza is an “invalid” config. The warning should probably be rephrased to say something like “the configuration is unusual and possibly incorrect…” And even then, it’s a bit annoying to see this warning every invocation. IMO it would be more appropriate to put the warning in the logs, not print to the screen. Or perhaps have a separate CLI option just for checking the config file. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fetchmail depends on: ii adduser3.134 ii debianutils5.7-0.5~deb12u1 ii init-system-helpers1.65.2 ii libc6 2.36-9+deb12u7 ii libcom-err21.47.0-2 ii libgssapi-krb5-2 1.20.1-2+deb12u1 ii libkrb5-3 1.20.1-2+deb12u1 ii libssl33.0.11-1~deb12u2 ii lsb-base 11.6 ii sysvinit-utils [lsb-base] 3.06-4 Versions of packages fetchmail recommends: ii ca-certificates 20230311 Versions of packages fetchmail suggests: pn fetchmailconf ii postfix [mail-transport-agent] 3.7.10-0+deb12u1 ii systemd-resolved [resolvconf] 252.22-1~deb12u1 -- no debconf information
Bug#1073788: localc crashes sway/xwayland and behaves similarly to gimp
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 localc. Sometimes there was no issue, in which case the screen would very briefly blink black (about as fast as blinking your eyes), and then it would continue functioning fine until the next cell color change attempt. Sometimes the tiled dialog frame (which uses ½ the screen in a Sway) would start flickerly madly. I could close it and hit control-1 try again. I noticed a pattern. If clicking the “color” button in the “background” tab would cause it to go apeshit and I close and immediately retry, it behaves well the 2nd time. So about every other time it would go apeshit. There is a slight difference between the kernels. In kernel 5.x I could go 1 or two steps further. In kernel 6.x, clicking the button literally labeled “color” causes it to go apeshit, blink very slowly (black screens for 1 or 2 whole seconds, followed by a whole system freeze. In kernel 5.x I don’t think clicking the button literally labeled “color” caused any issue, but then when I selected an actual color from the pallet and apply it, then it would go apeshit. Gimp is also a disaster on kernel 6.1.0-21, as with 5.x. But what differs is on kernel 6.x Gimp tended to crash itself without crashing sway, but shortly thereafter the whole system would freeze. On kernel 5.x, Gimp tended to take Sway down with it but without freezing the whole system. One behavior that’s consistent with Gimp on both kernels (5.x and 6.x) and also localc on both kernels is both screens of the 2 headed system would go black for a second or two. Sometimes that’s followed quickly with more severe crashes, and sometimes things continue functioning fine after the blinking. It’s interesting to note that after running kernel 6.1.0-21 and causing several freezes, the journalctl output did not show anything interesting.. no “GPU hang”.
Bug#1073788: localc crashes sway/xwayland and behaves similarly to gimp
* 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?bug=1071381 Perhaps I could still try it because the defect in kernels 6+ may take a couple hours to hit. I could probably boot and quickly do the gimp and localc tests before the kernel freeze hits.
Bug#1071381: linux-image-6.1.0-15-amd64: (regression) spontaneous freezing on Thinkpad
* 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://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071520#5 Specifically: “The tp-smapi-dkms modules were initially suspect, but kernel version 6.1.90-1 still froze when tp_smapi and thinkpad_ec modules were removed.”
Bug#1075893: curl: -L does not have effect when a 404 is coupled with a redirect to a parking service
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 exists. When visiting that URL in a GUI browser, it instantly redirects to a “parking” service (“https://www.hugedomains.com/domain_profile.cfm?d=lawlita.com”). But cURL stops short of finding that: ===8<-- $ curl -v --ssl --socks4a 127.0.0.1:9050 --connect-timeout 240 -L --head -w '(%{url} [aka %{redirect_url}] → [effective URL] "%{url_effective}")' --globoff http://lawlita.com Warning: --ssl is an insecure option, consider --ssl-reqd instead * Trying 127.0.0.1:9050... * Connected to 127.0.0.1 (127.0.0.1) port 9050 (#0) * SOCKS4 communication to lawlita.com:80 * SOCKS4a request granted. * Connected to 127.0.0.1 (127.0.0.1) port 9050 (#0) > HEAD / HTTP/1.1 > Host: lawlita.com > User-Agent: curl/7.88.1 > Accept: */* > * HTTP 1.0, assume close after body < HTTP/1.0 404 Not Found HTTP/1.0 404 Not Found < cache-control: no-cache cache-control: no-cache < content-type: text/html content-type: text/html < x-reason: UnsupportedMethod x-reason: UnsupportedMethod < * Closing connection 0 (http://lawlita.com [aka ] → [effective URL] "http://lawlita.com/";) ===8<-- My guess is cURL sees a 404 error and gives up early. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages curl depends on: ii libc6 2.36-9+deb12u7 ii libcurl4 7.88.1-10+deb12u5 ii zlib1g1:1.2.13.dfsg-1 curl recommends no packages. curl suggests no packages. -- no debconf information
Bug#1073788: localc crashes sway/xwayland and behaves similarly to gimp
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 screen recovers. The first time it then froze for a few seconds and went back to functioning. The second time this happened, Sway crashed and dumped me in a terminal. All graphical windows were lost but the underlying apps were still running. So if there is anything similar between localc » right cick » format cells » background and Gimp’s threshold dialog, that might give a clue. > To me this bug sounds a lot like a out of memory problem (maybe even out of > video memory). Can you have a log at the system log at the time of the > crash? Try: > > sudo journalctl -S 2024-06-18 > > for that. Also, can you reproduce the bug? The bug seems relatively reproducable. Every time I enter Gimp threshold or localc background color things slow down, the screens blink, and sometimes recover and sometimes crash. Gimp hung and needed a forced power off after the screens blinked. Localc caused sway to crash after blinking the screens. It’s obviously risky to make things crash so I’m not keen to repeat the actions that cause the freeze and crash. When I run journalctl, it looks like a “GPU HANG … Resetting chip for stopped heartbeat on rcs0” might be relevant: ===8<-- Jul 06 16:35:22 kernel: audit: type=1400 audit(1720276522.925:1405): apparmor="ALLOWED" operation="open" profile="libreoffice-soffi> Jul 06 16:35:22 audit[54762]: AVC apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" name="~/.config/lib> Jul 06 16:35:22 audit[54762]: AVC apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" name="~/.config/lib> Jul 06 16:35:22 audit[54762]: AVC apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" name="~/.config/lib> Jul 06 16:35:22 audit[54762]: AVC apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" name="~/.config/lib> Jul 06 16:35:22 audit[54762]: AVC apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" name="~/.config/lib> Jul 06 16:35:22 audit[54762]: AVC apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" name="~/.config/lib> Jul 06 16:35:24 audit[54762]: AVC apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" name="~/.config/lib> Jul 06 16:35:24 audit[54762]: AVC apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" name="~/.config/lib> Jul 06 16:35:30 kernel: i915 :00:02.0: [drm] GPU HANG: ecode 4:1:9fe7fbfd, in Xwayland [1512] Jul 06 16:35:31 kernel: i915 :00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0 Jul 06 16:35:31 kernel: i915 :00:02.0: [drm] Xwayland[1512] context reset due to GPU hang Jul 06 16:35:43 audit[54762]: AVC apparmor="ALLOWED" operation="mknod" profile="libreoffice-soffice" name="~/.config/li> Jul 06 16:35:43 audit[54762]: AVC apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" name="~/.config/lib> Jul 06 16:35:43 audit[54762]: AVC apparmor="ALLOWED" operation="file_lock" profile="libreoffice-soffice" name="~/.config/> Jul 06 16:35:43 kernel: kauditd_printk_skb: 8 callbacks suppressed Jul 06 16:35:43 kernel: audit: type=1400 audit(1720276543.934:1414): apparmor="ALLOWED" operation="mknod" profile="libreoffice-soff> Jul 06 16:35:43 kernel: audit: type=1400 audit(1720276543.934:1415): apparmor="ALLOWED" operation="open" profile="libreoffice-soffi> Jul 06 16:35:43 kernel: audit: type=1400 audit(1720276543.934:1416): apparmor="ALLOWED" operation="file_lock" profile="libreoffice-> Jul 06 16:35:43 audit[54762]: AVC apparmor="ALLOWED" operation="rename_src" profile="libreoffice-soffice" name="~/.config/> Jul 06 16:35:43 audit[54762]: AVC apparmor="ALLOWED" operation="rename_dest" profile="libreoffice-soffice" name="~/.config/> Jul 06 16:35:43 kernel: audit: type=1400 audit(1720276543.942:1417): apparmor="ALLOWED" operation="rename_src" profile="libreoffice> Jul 06 16:35:43 kernel: audit: type=1400 audit(1720276543.942:1418): apparmor="ALLOWED" operation="rename_dest" profile="libreoffic> … Jul 06 16:35:48 audit[54762]: AVC apparmor="ALLOWED" operation="mknod" profile="libreoffice-soffice" name="~/.config/li> Jul 06 16:35:48 audit[54762]: AVC apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" name="~/.config/lib> Jul 06 16:35:48 audit[54762]: AVC apparmor="ALLOWED" operation="file_lock" profile="libreoffice-soffice" name="~/.config/> Jul 06 16:35:48 audit[54762]: AVC apparmor="ALLOWED" operation="rename_src" profile="libreoffice-soffice" name="/.config/> Jul 06 16:35:48 audit[54762]: AVC apparmor="ALLOWED" operation="rename_dest" profile="libreoffice-soffice" name="/.config/> Jul 06 16:35:48 audit[54762]: AVC apparmor="ALLOWED" operation="chown" profile="libreoffice-soffice" name="~/.config/li>
Bug#1074249: artha: Artha description is incomplete. It’s a dictionary, not just a thesaurus.
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 worsened by the fact that Artha is not even described as a dictionary. IIUC, a dictionary is in fact the primary purpose of Artha. I have no idea why the author just describes it as a thesaurus, but in this case the Debian package should probably not just be a copy of the upstream description. This was reported upstream 12 years ago: https://bugs.launchpad.net/artha/+bug/998635 -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages artha depends on: ii libc6 2.36-9+deb12u7 ii libdbus-1-3 1.14.10-1~deb12u1 ii libdbus-glib-1-2 0.112-3 ii libglib2.0-0 2.74.6-2+deb12u2 ii libgtk2.0-0 2.24.33-2 ii libx11-6 2:1.8.4-2+deb12u2 ii wordnet 1:3.0-37 Versions of packages artha recommends: ii libenchant-2-2 2.3.3-2 ii libnotify4 0.8.1-1 ii wordnet-sense-index 1:3.0-37 Versions of packages artha suggests: ii aspell-en 2020.12.07-0-1 -- no debconf information
Bug#1073788: gimp: whole-system froze when adjusting threshold
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 a “Layer » Layer to Image Size” operation. No problems so far (and likely irrelevent - it’s just my typical workflow FWIW). Opened “Colors » Threshold…”. Some images have an interesting graph to help determine where to move the slider and some just have an empty graph. This may not be related but I noticed that both times spaz’d out it was when an image had an empty graph (or nearly empty). As soon as the slider is moved, *both* screens on a dual headed machine go black for ~1½ seconds then pop back on. GIMP is only ever present one of the two displays, never spread out. On one occassion, the system froze for a few seconds before the cursor could move again. On another occasion, the keyboard and mouse were permanently frozen. I walked away from the machine for ~5 minutes or so to give it time to unfreeze, but it never unfroze. I was ultimately forced to physically force a power down of the whole system. It would have been catastrophic if I had unsaved work in any application. GIMP’s tendency to affect other apps also manifests in another way (though less extreme). When GIMP is full screen on one display and emacs is full screen on the other display, if I click on a menu like Colors, leave the menu list open and move the mouse cursor out of GIMP and onto the emacs window, the emacs window takes focus as expected but GIMP fights to keep control of the keyboard. When I type a few keys, the first character appears in the emacs buffer but GIMP seems to react to all keys pressed when emacs is in focus. Emacs only receives the first key but GIMP acts on all keys pressed. When this fight for keyboard control is occurring, both displays go all black for ~1½ seconds before restoring and the mouse is frozen for a second or two after that. Sometimes the GIMP popup window (triggered by the keys pressed in emacs) flickers wildly with different buttons in the window flickering as well. I click cancel to end the madness. So far in that case the system goes back to normal. But the behaviour is similar to when the threshold slider is moved so it appears to be ultimately associated to the same problem. This is on Wayland with Sway running. A similar but different bug was reported here: https://gitlab.gnome.org/GNOME/gimp/-/issues/11275 Paulo Crepaldi called it a “crash” not a freeze, and that was on Windows while my experience was on Debian. These bugs could be related but possibly not. Without more certainty, I did not tag this bug as forwarded upstream. There is also a security problem here. In principle, what if a user were to leave GIMP to enter a password in another app? GIMP should not have access to the keyboard when it is not in focus. This security flaw is not in GIMP, but rather in Wayland or Sway and GIMP is merely demonstrating how an unfocused app can eavesdrop on the keystrokes. The upstream bug tracker blocks registration by pushing a broken CAPTCHA, so I am unable to report this upstream. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gimp depends on: ii gimp-data2.10.34-1+deb12u2 ii graphviz 2.42.2-7+b3 ii libaa1 1.4p5-50 ii libbabl-0.1-01:0.1.98-1+b1 ii libbz2-1.0 1.0.8-5+b1 ii libc62.36-9+deb12u7 ii libcairo21.16.0-7 ii libfontconfig1 2.14.1-4 ii libfreetype6 2.12.1+dfsg-5 ii libgcc-s112.2.0-14 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libgegl-0.4-01:0.4.42-2 ii libgexiv2-2 0.14.0-1+b1 ii libgimp2.0 2.10.34-1+deb12u2 ii libglib2.0-0 2.74.6-2+deb12u2 ii libgs10 10.0.0~dfsg-11+deb12u3 ii libgtk2.0-0 2.24.33-2 ii libgudev-1.0-0 237-2 ii libharfbuzz0b6.0.0+dfsg-3 ii libheif1 1.15.1-1 ii libjpeg62-turbo 1:2.1.5-2 ii libjson-glib-1.0-0 1.6.6-1 ii libjxl0.70.7.0-10 ii liblcms2-2 2.14-2 ii liblzma5 5.4.1-0.2 ii libmng1 1.0.10+dfsg-3.1+b5 ii libmypaint-1.5-1 1.6.0-2 ii libopenexr-3-1-303.1.5-5 ii libopenjp2-7 2.5.0-2 ii libpango-1.0-0 1.50.12+ds-1 ii libpangocairo-1.0-0 1.50.12+ds-1 ii libpangoft2-1.0-01.50.12+d
Bug#1072811: www.debian.org: Bug reporting guides have poor coverage on modifiers and some incomprehendable language
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 the links to other pages are vaguely described. That said, I started here: https://www.debian.org/Bugs/server-refcard The bottom of that page merely mentions the existence of the “nnn-quiet” modifier. No description and no link to a description. I would expect some mention of it here: https://www.debian.org/Bugs/server-control but there is no mention of -quiet there. I could only find a blurb about -quiet here: https://www.debian.org/Bugs/Developer So the -quiet modifier is described inside the paragraph that talks about an obsolete variation. And the English is rough: “It used to be possible to prevent the bug tracking system from forwarding anywhere messages it received at debian-bugs, by putting an X-Debian-PR: quiet line in the actual mail header.” What is meant by “forwarding anywhere messages”? That needs to be rewritten. There is also an oversight with the bug closure procedure. The control command “close” is described¹ as: “close bugnumber [ fixed-version ] (deprecated)” The reason for deprecation neglects a use case. That is, it’s deprecated to promote a process that ensures the submitter receives rationale for the closure. And rightfully so, but this neglects the case where the submitter closes their own bug report, which usually means the report was opened erroneously. Often this happens early, before maintainers have interacted. I’ll stop short of prescribing a BTS process, but in any case the documentation needs to cover the scenario of a submitter who needs to close an erroneous report. In principle, the closure of erroneous submissions should be as quiet as possible, so as to not make further noise in people’s inboxes with more forwarded messages (possibly via the -quiet modifer and using the deprecated “close” control command, not sure). ¹ https://www.debian.org/Bugs/server-control
Bug#1072782: kristall: Enormous gaps between words
> 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 installed an earlier version than 0.4, which might have had a different default, which then would have stuck through upgrades. I just installed 0.4 to use Kristall for the first time, and the default standard font was simply “Sans Serif”/normal/12. > I will see if I can select a more sensible default font - although I > discovered people can be very pick about their fonts :-) Can you > send the exact style you had in your settings and a website I can > test it to see if we can improve the user experience? There are many sans serif fonts on my system, which perhaps has a different catalog of fonts than other Debian systems would have. And because of that, I wonder if the default might be selected arbitrarily. In my case, the font that was plainly named “Sans Serif” was used as the “Standard Font” as well as H1, H2, H3, and blockquote. This font is a disaster for all of those purposes. I guess I should assume I have DejaVu* fonts because I installed djvu pkgs, and TeX* fonts because I installed texlive. So in looking for a generic and possibly common font, I tried “Latin Modern Roman” as the standard font, which looks nice. I’m just guessing that’d be widely available. I wouldn’t try to cater for people’s personal tastes because the software is designed to make it easy for users to tune the font. It’s really just important to get rid of the intolerable default font. It’s a disaster on every single site/page it renders. I’ll just name gemini://techrights.org to give an arbitrary example. Note as well I have in version 0.4 the known defect of blank icons to the left of the URL field. They at least have a mouseover hover msg. But in settings»style, all the icons on the right are also blank and there is no mouseover for them. That was reported upstream in 2022, IIRC. Though I guess Debian is not a good place to fix that one.
Bug#1072782: kristall: Enormous gaps between words
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 matters. Per the guidance, I disabled justification and changed the font (DejaVu Serif regular, in my case). That worked well. It was already reported upstream but I am reporting this here because the spaces are so severe that they would perhaps instantly lower morale and put someone off Gemini. Users see this description in the apt db: “high-quality visual cross-platform gemini browser” So they would naturally have high expectations. Having this bug report in Debian BTS might help someone who looks for info on this. The bug was reported in 2021. Since it can be fixed with a config tweak, I wonder if it might make sense to fix it in the Debian package. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kristall depends on: ii libc6 2.36-9+deb12u7 ii libcmark0.30.20.30.2-6 ii libgcc-s1 12.2.0-14 ii libgumbo1 0.10.1+dfsg-5 ii libqt5core5a 5.15.8+dfsg-11 ii libqt5gui55.15.8+dfsg-11 ii libqt5multimedia5 5.15.8-2 ii libqt5multimediawidgets5 5.15.8-2 ii libqt5network55.15.8+dfsg-11 ii libqt5widgets55.15.8+dfsg-11 ii libssl3 3.0.11-1~deb12u2 ii libstdc++612.2.0-14 kristall recommends no packages. kristall suggests no packages. -- no debconf information
Bug#1072482: dino-im: manpage missing, no proxy docs
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 considered as a bug and should be reported to the Debian Bug Tracking System (the maintainer of the package is allowed to write this bug report themselves, if they so desire). Do not close the bug report until a proper man page is available.” ¹ https://www.debian.org/doc/debian-policy/ch-docs.html The best place to fix this is upstream. But I did not tag this bug report as upstream because lack of manpage may or may not be considered a bug upstream, yet nonetheless it is a bug in the Debian scope. The upstream devs have been CC’d, hopefully. What I was expecting to find in the man page is a way to configure a proxy. AFAICT, there are no docs or user guides for dino-im anywhere. The only information is in the Github bug reports and the code. This comment states that dino respects systemwide proxy settings: https://github.com/dino/dino/issues/1103#issuecomment-908595528 But it does not state /how/ dino obtains those settings from the system. In principle, by convention, it should look at the http_proxy and https_proxy environment variables, which would appear in an “ENVIRONMENT” section of the man page. According to this comment: https://github.com/dino/dino/issues/342#issuecomment-384610205 Dino works with proxychains. I believe proxychains is the same as torsocks in terms of what it does and how it works. This comment seems to imply torsocks works with dino-im: https://github.com/dino/dino/issues/567#issuecomment-55526 This comment mentions using dconf (which is an overloaded word between gnome and debian projects and deprecated in Debian). The coment also says that dino is deliberately designed not to support any proxies: https://github.com/dino/dino/issues/342#issuecomment-385427600 So apparently the only way to proxy dino is to intercept systems calls, IIUC, which is a big hackish IMO. All this confusion from people in the bug tracker reinforces the need for a man page. Ideally the man page would explicitly state that proxy support is not offered, but that proxychains and torsocks works. Or if mentioning the absence of an option is regarded as excessively verbose for a man page, even the mere presence of a man page with no options (apart from maybe -h to print itself) would at least signal to users that the proxy options are likely non-existent. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dino-im depends on: ii dino-im-common 0.4.2-1 ii libadwaita-1-0 1.2.2-1 ii libc6 2.36-9+deb12u7 ii libcairo2 1.16.0-7 ii libgcc-s1 12.2.0-14 ii libgcrypt20 1.10.1-3 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libgee-0.8-20.20.6-1 ii libglib2.0-02.74.6-2+deb12u2 ii libgnutls30 3.7.9-2+deb12u2 ii libgpgme11 1.18.0-3+b1 ii libgraphene-1.0-0 1.10.8-1 ii libgstreamer-plugins-base1.0-0 1.22.0-3+deb12u1 ii libgstreamer1.0-0 1.22.0-2 ii libgtk-4-1 4.8.3+ds-2+deb12u1 ii libgtk-4-media-gstreamer4.8.3+ds-2+deb12u1 ii libicu7272.1-3 ii libnice10 0.1.21-1 ii libpango-1.0-0 1.50.12+ds-1 ii libqrencode44.1.1-1 ii libsignal-protocol-c2.3.2 2.3.3-3 ii libsoup-3.0-0 3.2.2-2 ii libsqlite3-03.40.1-2 ii libsrtp2-1 2.5.0-3 ii libstdc++6 12.2.0-14 ii libwebrtc-audio-processing1 0.3-1+b1 Versions of packages dino-im recommends: ii ca-certificates 20230311 ii dbus1.14.10-1~deb12u1 ii fonts-noto-color-emoji 2.042-0+deb12u1 ii network-manager 1.42.4-1 dino-im suggests no packages. -- no debconf information
Bug#1071783: Bug#1071762: texlive-base: tlmgr documentation omissions, inaccuracies, and pitfalls
> 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/texlive.tlpdb There is also a problem installing the 2021 version of acro: ===8< $ torsocks tlmgr --usermode --repository rsync://tug.org/historic/systems/texlive/2021/tlnet-final/ install acro TLPDB: not a directory, not loading: rsync://tug.org/historic/systems/texlive/2021/tlnet-final/ tlmgr: Cannot load TeX Live database from rsync://tug.org/historic/systems/texlive/2021/tlnet-final/ $ torsocks tlmgr --usermode --repository https://pi.kwarc.info/historic/systems/texlive/2021/tlnet-final/ install acro xz: (stdin): Unexpected end of input tlmgr: The TeX Live versions supported by the repository https://pi.kwarc.info/historic/systems/texlive/2021/tlnet-final/ (2016--2021) do not include the version of the local installation (2022). ===8< The first attempt used the German repo https://www.tug.org/historic/. If that host is the basis of the mirrors, why would the directory structure be different? This seems to be implied by the error message, but unlikely, so the error message might be wrong. The 2nd attempt used a path that I could test using a browser. The xz error came relatively quick, then it seemed to hang. It was unclear what it was doing. This makes me nervous because I am on a measured rate connection. A big download can be costly for me. When a download manager or package manager does not state the size of what will be fetched in advance, users on limited connections have to decide between walking away or gamble and give a blank cheque. I started looking at a bandwidth meter and I could see that ~15mb was being fetched from the time I started looking. The acro package is under 1.5mb including the docs. There was no indication of what it was fetching -- could be all of texlive for all I know. There could be dependencies to fetch, but tlmgr does not communicate this to the user. I was getting ready to cancel it but then it finished at the 15mb mark before I could kill it. The output is a mystery. I think it’s attempting to give an error. It’s clear that acro was not added to ~/.local/share/texmf/tex/. My choice to install the previous version of acro is deliberate and tlmgr seems to assume I want the version I already have despite my express instructions. I wonder if this apparent protection mechanism can be overridden with --force. The man page for --force says: “If updates to "tlmgr" itself (or other parts of the basic infrastructure) are present, "tlmgr" will bail out and not perform the installation unless this option is given. Not recommended.” That would seem apply to my situation. It would be more clear if the error output would also tell the user that --force could be used. Or better, if it would prompt the user for feedback. Because apparently the downloaded data was thrown away. The ~/.local/share/texmf/ does not have the acro tarball. I also tried: $ find .cache/ -name acro.tar.xz which came up empty. I would rather not experiment too much because every attempt is another ~15+ mb. I have to wonder as well what this apparent protection mechanism is protecting from. In normal mode, it’s understandable that you would not want mismatched versions to ruin a whole systemwide installation. But in usermode, you inherently have a sandbox or degree of isolation anyway, particularly when there is nothing in ~/.local/share/texmf/ that tlmgr is aware of. When running in user mode, shouldn’t the installation only stop if there is a conflict with another local user-specific object?
Bug#1071783: Bug#1071762: texlive-base: tlmgr documentation omissions, inaccuracies, and pitfalls
> 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 support staff use inclusion of software in official repos as the defining factor as to whether they support an app. Alternatively, I think it would be fair to say there is limited support if its existence persists in Debian, but that needs to be defined. Debian users are receiving documentation and a tool that does not work as documented. There are two reasonable options: fix the tool or fix the docs. I certainly do not mean to try to push any work on anyone, but one of those directions should at least be selected as a goal to work toward. Fixing the docs, IMO, could be a matter of explicity listing the features that function in Debian while listing the dysfunctional features (in a “KNOWN BUGS” section, for example). Otherwise, how do testers even know what is a reportable bug and what is not? How does a user know whether tlmgr can help them before they spend much time on it? The docs are not doing their job. The README.tlmgr-on-Debian.md (which escaped me before my first 2 bug reports) is a good start on this and gives a good overview of the situation. But what’s missing is a list of functionality Debian users can expect to work. > For example, tlmgr info does not work because we don't have a tlpdb > at hand. I got the /info/ action partially working after you mentioned a specific mirror URL. You had to mention a specific URL because the docs are missing that information. The docs point to https://ctan.org/mirrors/mirmon but that page also neglects to mention historic versions. Even though you gave this specific URL: https://pi.kwarc.info/historic/systems/texlive/2022/tlnet-final/ I still stumbled. When visiting that directory, all the files therein are installation and upgrade scripts, which intuitively seems incorrect for a repository location to supply to a package manager, so I first tried supplying this URL instead: https://pi.kwarc.info/historic/systems/texlive/2022/ which failed: ===8< /usr/bin/tlmgr: TLPDB::from_file could not initialize from: https://pi.kwarc.info/historic/systems/texlive/2022//tlpkg/texlive.tlpdb /usr/bin/tlmgr: Maybe the repository setting should be changed. /usr/bin/tlmgr: More info: https://tug.org/texlive/acquire.html ===8< There seems to be a presumption of TeX expertise on users. So then I tried the path verbatim as you suggested: ===8< $ tlmgr option repository https://pi.kwarc.info/historic/systems/texlive/2022/tlnet-final/ … $ tlmgr --usermode info --only-installed (no output) ===8< It still failed to list locally installed packages and versions. Omitting --only-installed now has output but the list is misleading. I believe the list of packages given by the /info/ action with no options should show /both/ locally installed packages and remotely available packages. It gives a package list without indicating whether they are locally installed or remotely available. I can only speculate based on use of the --only-installed switch that the unconstrained list is actually purely remotely available packages. So “info --only-installed” is still broken. I cannot think of a more basic function that users would expect to work. The default repository on Debian should not be https://mirror.ctan.org/systems/texlive/tlnet because that’s broken out of the box. The working repo URL probably changes as time passes and/or as the package moves from testing to stable, which makes it tricky. But the docs should compensate by covering that. > > “(running on Debian THUS switching to user mode!)” > > Yes, that is the meaning. I think this is obvious enough., It’s not obvious because even when it’s fully understood that Debian implies user mode, it’s still an astonishing circumstance for both users and admins. Users expect to be in a user mode inherently, but not in the slightest as a consequence of the distro they are working on. Even if “thus” replaced the comma, root users will be in disbelief. The ambiguity of the comma worsens that and exacerbates the disbelief. Debian is designed for systemwide installations of multi-user software that is controlled by root, and texlive is installed as such, not as a user. So users and admins do not expect Debian to be a reason for being put into user mode. A package manager that runs as a user when launched by root is inherently a dodgy situation because the root account should not be running apps like latex. Thus root should not generally be doing a /user/ installation of a tool like texlive for themself, for the admin’s own use. Root running user apps not for admin work is wid
Bug#1071783: texlive-base: tlmgr cannot list packages and directs users to upgrade
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< There was simply no output when a long list of texlive packages were expected. So --only-installed was omitted to see if allowing cloud access would change anything: ===8< $ torsocks tlmgr --usermode list tlmgr: Local TeX Live (2022) is older than remote repository (2024). Cross release updates are only supported with update-tlmgr-latest(.sh/.exe) --update See https://tug.org/texlive/upgrade.html for details. ===8< This seems to imply that users cannot list packages unless their texlive installation is the same version as that of the remote repository. That’s a bit drastic to simply get a list of packages and many Debian users would not want to update the whole texlive installation outside of the apt manager. Ideally, apt would have installed a configuration where the tlmgr-configured repository is aligned with the Debian version. To check the repo, I ran this: ===8< $ tlmgr option repository (running on Debian, switching to user mode!) (see /usr/share/doc/texlive-base/README.tlmgr-on-Debian.md) Default package repository (repository): https://mirror.ctan.org/systems/texlive/tlnet ===8< There was mention of “update-tlmgr-latest(.sh/.exe) --update”. This script is not installed and in fact apt-file search does not find it in the Debian repos. The webpage https://tug.org/texlive/upgrade.html suggests installing texlive 2024 and says it can be done without tampering with the existing installation. But still, texlive is huge. So the sensible approach appears to be to find a mirror that matches the locally installed version. The PDF guide mentions this location: https://ctan.org/mirrors/mirmon That list of mirrors does not mention which texlive version is available. It seems having a version-aligned repo is critical to using tlmgr but the guide does not cover how to find a compatible mirror. Having read this doc: /usr/share/doc/texlive-base/README.tlmgr-on-Debian.md it’s unclear if tlmgr can safely accomplish the ultimate mission I had planned: to gracefully downgrade the acro package and pin that older version. That doc suggests using apt, which is generally sensible but in the case at hand it’s too blunt of a tool for that considering the acro package is bundled with in texlive-latex-extra with other apps I would not want to donwgrade. Nonetheless, tlmgr was provided and IMO at a minimum should offer the basic functionality of listing packages and versions without changing the installation. -- Package-specific info: ## List of ls-R files -rw-rw-r-- 1 root staff 5281 Jul 22 2021 /usr/local/share/texmf/ls-R -rw-r--r-- 1 root root 3381 Apr 24 16:00 /var/lib/texmf/ls-R lrwxrwxrwx 1 root root 29 Oct 12 2022 /usr/share/texmf/ls-R -> /var/lib/texmf/ls-R-TEXMFMAIN lrwxrwxrwx 1 root root 31 Apr 9 2023 /usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST lrwxrwxrwx 1 root root 31 Apr 9 2023 /usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST ## Config files -rw-r--r-- 1 root root 508 Apr 24 15:43 /etc/texmf/web2c/texmf.cnf lrwxrwxrwx 1 root root 33 Apr 9 2023 /usr/share/texmf/web2c/fmtutil.cnf -> /var/lib/texmf/fmtutil.cnf-DEBIAN -rw-r--r-- 1 root staff 16 Jul 21 2021 /usr/local/share/texmf/web2c/updmap.cfg -rw-r--r-- 1 root root 5130 Apr 24 15:54 /var/lib/texmf/tex/generic/config/language.dat ## Files in /etc/texmf/web2c/ total 8 -rw-r--r-- 1 root root 283 Feb 12 2021 mktex.cnf -rw-r--r-- 1 root root 508 Apr 24 15:43 texmf.cnf ## md5sums of texmf.d 59de20a5ea3b9f41ff51e16811e8499c /etc/texmf/texmf.d/00debian.cnf -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages texlive-base depends on: ii debconf [debconf-2.0] 1.5.82 ii libpaper-utils 1.1.29 ii sensible-utils 0.0.17+nmu1 ii tex-common 6.18 ii texlive-binaries 2022.20220321.62855-5.1+deb12u1 ii ucf3.0043+nmu1 ii xdg-utils 1.1.3-4
Bug#1071763: texlive-base: tlmgr gives misinfo about installed pkgs + runs in user mode as root
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 acro /usr/bin/tlmgr: TLPDB::from_file could not initialize from: https://mirror.ctan.org/systems/texlive/tlnet/tlpkg/texlive.tlpdb /usr/bin/tlmgr: Maybe the repository setting should be changed. /usr/bin/tlmgr: More info: https://tug.org/texlive/acquire.html ===8< Then noticed docs state “If *pkg* is not locally installed, searches in the remote installation source.” Although the acro pkg is locally installed, I added the --only-installed option because the cloud should not be needed: ===8< $ tlmgr --usermode info --only-installed acro package: acro installed: No ===8< I know acro is installed system-wide, so tlmgr is apparently not finding it when I run as a user and thus may only know about user-installed pkgs. So I ran as root: ===8< # tlmgr info --only-installed acro (running on Debian, switching to user mode!) (see /usr/share/doc/texlive-base/README.tlmgr-on-Debian.md) TLPDB: not a directory, not loading: /root/.local/share/texmf tlmgr: user mode not initialized, please read the documentation! ===8< I was baffled that it’s switching to user mode when running as root. This comment clarifies: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907415#8 It’s because tlmgr runs on Debian that it runs in user mode. That’s not exactly clear from the output message: “(running on Debian, switching to user mode!)” I took that to mean tlmgr detected a Debian system for some reason beyond me, and that it also switched to user mode for some other reason beyond me. It would be more clear if it said: “(running on Debian THUS switching to user mode!)” Users will still be astonished about why Debian implies that we can only run as a user, but it would at least be clear that user mode is an intentional consequence of being on Debian. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages texlive-base depends on: ii debconf [debconf-2.0] 1.5.82 ii libpaper-utils 1.1.29 ii sensible-utils 0.0.17+nmu1 ii tex-common 6.18 ii texlive-binaries 2022.20220321.62855-5.1+deb12u1 ii ucf3.0043+nmu1 ii xdg-utils 1.1.3-4.1 Versions of packages texlive-base recommends: ii lmodern 2.005-1 Versions of packages texlive-base suggests: ii evince [postscript-viewer] 43.1-2+b1 ii ghostscript [postscript-viewer] 10.0.0~dfsg-11+deb12u3 ii mupdf [pdf-viewer] 1.21.1+ds2-1+b4 ii okular [postscript-viewer] 4:22.12.3-1 pn perl-tk ii qpdfview [pdf-viewer] 0.5.0+ds-2 ii qpdfview-ps-plugin [postscript-viewer] 0.5.0+ds-2 ii xpdf [pdf-viewer] 3.04+git20220601-1+b2 pn xzdec Versions of packages tex-common depends on: ii ucf 3.0043+nmu1 Versions of packages tex-common suggests: ii debhelper 13.11.4 Versions of packages texlive-base is related to: ii tex-common6.18 ii texlive-binaries 2022.20220321.62855-5.1+deb12u1 -- debconf information: texlive-base/binary_chooser: pdftex, dvips, dvipdfmx, xdvi texlive-base/texconfig_ignorant:
Bug#1071762: texlive-base: tlmgr documentation omissions, inaccuracies, and pitfalls
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 guide would be comprehensive and complete to some extent, while the man page would typically just serve as a complete but concise reference. In the case of tlmgr the reality is an inversion of that. The PDF is titled “Basic Usage…”, which tries to clarify the coverage is /basic/ but I simply still expected the PDF to be more complete than a man page. I figured the man page must be even more basic. The intro gave an overview which reinforced that expectation. So I expected to learn everything I needed from that PDF. My first command failed: ===8< $ tlmgr info acro (running on Debian, switching to user mode!) (see /usr/share/doc/texlive-base/README.tlmgr-on-Debian.md) TLPDB: Cannot determine type of tlpdb from ~/.local/share/texmf! tlmgr: user mode not initialized, please read the documentation! ===8< The last line was discouraging because I read what I thought was the comprehensive documentation. The PDF makes no mention of user mode, not even mention of the existence of the --usermode parameter. It is covered in the man page though. I was surprised that I would need a user-maintained database to simply query for the version of the acro package. Adding --usermode eliminated the warning but still made no progress: ===8< $ tlmgr --usermode info acro TLPDB: Cannot determine type of tlpdb from /home/blee/.local/share/texmf! tlmgr: user mode not initialized, please read the documentation! ===8< I also expected a list of what’s installed to not require a user-maintained database, so I tried that as well: ===8< $ tlmgr --usermode list TLPDB: Cannot determine type of tlpdb from /home/blee/.local/share/texmf! tlmgr: user mode not initialized, please read the documentation! ===8< >From the man page: manpg> "tlmgr" is switched into user mode with the command line option manpg> "--usermode". It does not switch automatically, nor is there any manpg> configuration file setting for it. Thus, this option has to be manpg> explicitly given every time user mode is to be activated. The claim that tlmgr does not switch to user mode automatically is apparently inaccurate assuming the output is accurate. manpg> This mode of "tlmgr" works on a user tree, by default the value of the manpg> "TEXMFHOME" variable. This can be overridden with the command line manpg> option "--usertree". In the following when we speak of the user tree we manpg> mean either "TEXMFHOME" or the one given on the command line. There is no mention of what happens if --usertree is not supplied and TEXMFHOME is unset. Users would rather not guess and experiment. But I was forced to experiment because at the same time I did not want to select a unconventional custom location. So I took a risk and ran the init-usertree command without feeding it a location. init-usertree printed no output. So it was unclear if it did any work. And if it did, it was unclear where the database was put. I happened to have had stuff in ~/.local/share/texmf/ and so I guessed that the db would be created there. So I ran “find ~/.local/share/texmf/” before and after init-usertree, which luckily revealed that was the default. Novices will not know about that path. The “ENVIRONMENT VARIABLES” section does not include $TEXMFHOME. This might also be a good place to mention the default dir if $TEXMFHOME is unset. manpg> Before using "tlmgr" in user mode, you have to set up the user tree with manpg> the "init-usertree" action. This creates *usertree*"/web2c" and manpg> *usertree*"/tlpkg/tlpobj", and a minimal manpg> *usertree*"/tlpkg/texlive.tlpdb". At that point, you can tell "tlmgr" to manpg> do the (supported) actions by adding the "--usermode" command line manpg> option. I was alienated by the use of “*usertree*”. It was indeed mentioned that “when we speak of the user tree we mean either "TEXMFHOME" or the one given on the command line” but that is easily overlooked by speed readers and the asterisks imply a wildcard which confuses things. The convention for a variable token in BNF would be angle brackets and the double quotes are not needed; thus I think /tlpkg/tlpobj would be more clear to more readers. BTW, a “tree” is normally thought to be the whole heiarchy of directories, not the root or home. I would change the wording to or or perhaps . manpg> Some "tlmgr" actions don't need any write permissions and thus work the manpg> same in user mode and normal mode. Currently these are: "check", "help", manpg> "list", "print-platform"
Bug#1071696: profanity: (security) Untrusted OMEMO keys are being used. Fingerprint trust is inconsistent.
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 correspondents but not others. I have four people configured as follows: * Alice - trusted fingerprint * Bob - untrusted fingerprint (implicit distrust) * Freddie - untrusted fingerprint (implicit distrust) * Martin - untrusted fingerprint (implicit distrust) My trustmodel is “manual”. All those users are using Snikket on iOS and the server is also Snikket. OMEMO is always enabled for all those users. According to the documentation, only Alice should be able to receive messages from me in this situation. However, Alice, Freddie, and Martin all seem to receive messages from me. Bob is exceptionally plagued with a false error claiming lack of OMEMO support every time I send Bob a msg. Apart from the error message being false, msgs to Bob are rightfully dysfunctional (though I would prefer if he receives no msg at all - what’s the point of sending him a msg he cannot open?). Msgs to Alice are rightfully functional. But what about Freddie & Martin? They generally receive my msgs fine, yet I apparently did not trust their fingerprints. This suggests a noteworthy security vulnerability because an untrusted key should not be used with a trust model of /manual/. Alternative theory 1: I did not keep notes on whose fingerprints I trusted. I am surprised I did not trust Freddie’s key. So I wonder if Profanity might be lying about whether keys are trusted. After entering /msg Freddie to get a dedicated 1:1 window, I entered “/omemo fingerprint” and it showed a fingerprint. It does not say trusted or untrusted. But if I do the same for Alice, “(trusted)” is printed next to the fingerprint. So by the way, the absence of “(trusted)” is an incredibly cryptic way of telling users a key is untrusted. I struggled to trust the software. So I found this file: ~/.local/share/profanity/omemo/$my_acct/trust.txt And indeed the fingerprints for Bob, Freddie, and Martin were not there. So I think we can rule out the alternative narrative that Profanity is lying about which keys are trusted. Alternative theory 2: Perhaps the “OMEMO” tag in the window status bar is a lie, and Profanity is actually sending unencrypted payloads to Freddie & Martin. This also seems unlikely but I will ask them if Snikket shows a padlock or shield on messages they receive from me. If not, I’ll amend this ticket. Otherwise assume they are getting a padlock. ¹ https://profanity-im.github.io/guide/0131/omemo.html -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages profanity depends on: ii libc6 2.36-9+deb12u7 ii libcurl3-gnutls7.88.1-10+deb12u5 ii libgcrypt201.10.1-3 ii libgdk-pixbuf-2.0-02.42.10+dfsg-1+b1 ii libglib2.0-0 2.74.6-2+deb12u2 ii libgpgme11 1.18.0-3+b1 ii libgtk-3-0 3.24.38-2~deb12u1 ii libncursesw6 6.4-4 ii libnotify4 0.8.1-1 ii libotr54.1.1-5 ii libpython3.11 3.11.2-6 ii libreadline8 8.2-1.3 ii libsignal-protocol-c2.3.2 2.3.3-3 ii libsqlite3-0 3.40.1-2 ii libstrophe00.12.2-1 ii libtinfo6 6.4-4 profanity recommends no packages. profanity suggests no packages. -- no debconf information
Bug#1071467: apt metadata needs revision
> 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 the defect was already fixed. The problem is apparently that the linux-image-6.6.13+bpo-amd64 neglects to disclose to apt "Breaks: tp-smapi-dkms (< 0.44-1~)". So it seems bug 1071467 needs to be reopened to correct the apt metadata, IIUC.
Bug#1071520: tp-smapi-dkms: (regression) breaks kernel versions 6.6.13-1~bpo12+1
> 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 to have failed.
Bug#1071539: wpasupplicant: Open networks associate but IP address unobtainable. Closed networks: no problem w/DHCP
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 problem goes back to Bullseye, maybe further back, and persists in Bookworm. Pre-Bullseye, I think I used the Gnome and the graphical network manager. Then I switched to Wayland in Bullseye which neglected to present a GUI Network Manager out of the box. In preference with CLI and text anyway, I went whole-hog CLI instead of sorting out NM. It’s crippling to be limited to encrypted networks. This procedure was used to attempt to connect to a public library: ===8< $ wpa_cli > scan > scan_results > add_network > set_network 0 ssid "library_free_assange" > set_network 0 key_mgmt NONE > list_networks > enable_network 4 > disable_network 0 > save config ===8< Edited /etc/wpa_supplicant/wpa_supplicant.conf Added an “id_str” field and custom identifier to the wpa_cli-generated stanza, yielding: ===8< … network={ ssid="library_free_assange" key_mgmt=NONE mesh_fwding=1 id_str="public_library" } … ===8< Side note: I do not recall “mesh_fwding=1” being there in Bullseye. No idea what introduced that but I do not think it was me¹. The interfaces config needs to be told to use DHCP for public_library (hence the need for id_str): $ echo "iface public_library inet dhcp" >> /etc/network/interfaces ===8< $ wpa_cli > status bssid=[redacted library MAC address 2] freq=0 ssid=library_free_assange id=4 id_str=public_library mode=station pairwise_cipher=NONE group_cipher=NONE key_mgmt=NONE wpa_state=COMPLETED address=[redacted MAC address of my NIC] uuid=[redacted some unique hash] <3>CTRL-EVENT-DISCONNECTED bssid=[redacted library MAC address 2] reason=0 <3>CTRL-EVENT-SCAN-RESULTS <3>WPS-AP-AVAILABLE <3>Trying to associate with [redacted library MAC address 1] (SSID='library_free_assange' freq=5240 MHz) <3>Associated with [redacted library MAC address 1] <3>CTRL-EVENT-CONNECTED - Connection to [redacted library MAC address 1] completed [id=0 id_str=] <3>Trying to associate with [redacted library MAC address 1] (SSID='library_free_assange' freq=5240 MHz) <3>CTRL-EVENT-DISCONNECTED bssid=[redacted library MAC address 1] reason=0 <3>Associated with [redacted library MAC address 1] <3>CTRL-EVENT-CONNECTED - Connection to [redacted library MAC address 1] completed [id=4 id_str=public_library] <3>CTRL-EVENT-DISCONNECTED bssid=[redacted library MAC address 1] reason=0 <3>CTRL-EVENT-SCAN-RESULTS <3>WPS-AP-AVAILABLE <3>Trying to associate with [redacted library MAC address 2] (SSID='library_free_assange' freq=5320 MHz) <3>Associated with [redacted library MAC address 2] <3>CTRL-EVENT-CONNECTED - Connection to [redacted library MAC address 2] completed [id=0 id_str=] <3>Trying to associate with [redacted library MAC address 2] (SSID='library_free_assange' freq=5320 MHz) <3>CTRL-EVENT-DISCONNECTED bssid=[redacted library MAC address 2] reason=0 <3>Associated with [redacted library MAC address 2] <3>CTRL-EVENT-CONNECTED - Connection to [redacted library MAC address 2] completed [id=4 id_str=public_library] ===8< ===8< $ ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host noprefixroute valid_lft forever preferred_lft forever 2: enp0s25: mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000 link/ether [redacted ethernet MAC] brd ff:ff:ff:ff:ff:ff 3: wls3: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether [redacted MAC address of my NIC] brd ff:ff:ff:ff:ff:ff altname wlp3s0 inet6 f00d::bad:cafe:d3ad:fa11/64 scope link valid_lft forever preferred_lft forever 4: vnet0: mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether de:ad:be:ef:de:ad brd ff:ff:ff:ff:ff:ff inet 172.16.0.1/24 brd 172.16.0.255 scope global vnet0 valid_lft forever preferred_lft forever ===8< ↑ It’s bizarre that there seems to be an IPv6 assignment for wls3 sometimes (IIUC), but not IPv4. I overwrote the hex for privacy but retained format. I would somewhat expect IPv6 to work these days, but to be clear, the network is dead. No DNS resolution. The library has a captive portal but pointing a browser to http://neverssl.com gives a no network message. Nor does it work to attempt to point the browser to the library’s gateway or captive portal URL
Bug#1071520: tp-smapi-dkms: (regression) breaks kernel versions 6.6.13-1~bpo12+1
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 to install because thinkpad_ec.c fails to build. This was originally filed as a bug against the kernel, but it’s actually a bug in tp-smapi-dkms. Transcript and logs are here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071467#22 Kernels 5.10.209-2 and earlier have no issues. Kernel versions 6.1.x are questionable. Kernel 6.1.x freezes. The tp-smapi-dkms modules were initially suspect, but kernel version 6.1.90-1 still froze when tp_smapi and thinkpad_ec modules were removed. In any case, thinkpad_ec.c is a non-starter for kernel 6.6.13-1~bpo12+1. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages tp-smapi-dkms depends on: ii dkms 3.0.10-8+deb12u1 tp-smapi-dkms recommends no packages. tp-smapi-dkms suggests no packages. -- no debconf information
Bug#1071467: linux-image-6.6.13+bpo-amd64: installation botched, tiny and corrupt deb file
> 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 collaborators as well. So indeed I need to give more info. > What do you want to say? This message is from apt and is pretty clearly > a missconfiguration, why does it try to find a package from the Debian > archive in your home? This is the full transcript: ===8< $ apt -t bookworm-backports install linux-image-amd64 Reading package lists... Done Building dependency tree... Done Reading state information... Done linux-image-amd64 is already the newest version (6.6.13-1~bpo12+1). The following packages were automatically installed and are no longer required: libwpe-1.0-1 libwpebackend-fdo-1.0-1 linux-headers-6.1.0-20-amd64 linux-headers-6.1.0-20-common linux-image-5.10.0-16-amd64 linux-image-5.10.0-19-amd64 linux-image-5.10.0-28-amd64 linux-image-5.10.0-7-amd64 linux-image-5.10.0-8-amd64 linux-image-6.1.0-15-amd64 linux-image-6.1.0-20-amd64 Use 'apt autoremove' to remove them. 0 upgraded, 0 newly installed, 0 to remove and 137 not upgraded. 4 not fully installed or removed. After this operation, 0 B of additional disk space will be used. Do you want to continue? [Y/n] y Setting up linux-image-6.6.13+bpo-amd64 (6.6.13-1~bpo12+1) ... /etc/kernel/postinst.d/dkms: dkms: running auto installation service for kernel 6.6.13+bpo-amd64. Sign command: /lib/modules/6.6.13+bpo-amd64/build/scripts/sign-file Signing key: /var/lib/dkms/mok.key Public certificate (MOK): /var/lib/dkms/mok.pub Building module: Cleaning build area... make -j2 KERNELRELEASE=6.6.13+bpo-amd64 -C /lib/modules/6.6.13+bpo-amd64/build M=/var/lib/dkms/tp_smapi/0.43/build HDAPS=1...(bad exit status: 2) Error! Bad return status for module build on kernel: 6.6.13+bpo-amd64 (x86_64) Consult /var/lib/dkms/tp_smapi/0.43/build/make.log for more information. Error! One or more modules failed to install during autoinstall. Refer to previous errors for more information. dkms: autoinstall for kernel: 6.6.13+bpo-amd64 failed! run-parts: /etc/kernel/postinst.d/dkms exited with return code 11 dpkg: error processing package linux-image-6.6.13+bpo-amd64 (--configure): installed linux-image-6.6.13+bpo-amd64 package post-installation script subprocess returned error exit status 1 dpkg: dependency problems prevent configuration of linux-image-amd64: linux-image-amd64 depends on linux-image-6.6.13+bpo-amd64 (= 6.6.13-1~bpo12+1); however: Package linux-image-6.6.13+bpo-amd64 is not configured yet. dpkg: error processing package linux-image-amd64 (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of linux-headers-6.6.13+bpo-amd64: linux-headers-6.6.13+bpo-amd64 depends on linux-image-6.6.13+bpo-amd64 (= 6.6.13-1~bpo12+1) | linux-image-6.6.13+bpo-amd64-unsigned (= 6.6.13-1~bpo12+1); however: Package linux-image-6.6.13+bpo-amd64 is not configured yet. Package linux-image-6.6.13+bpo-amd64-unsigned is not installed. dpkg: error processing package linux-headers-6.6.13+bpo-amd64 (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of linux-headers-amd64: linux-headers-amd64 depends on linux-headers-6.6.13+bpo-amd64 (= 6.6.13-1~bpo12+1); however: Package linux-headers-6.6.13+bpo-amd64 is not configured yet. dpkg: error processing package linux-headers-amd64 (--configure): dependency problems - leaving unconfigured Errors were encountered while processing: linux-image-6.6.13+bpo-amd64 linux-image-amd64 linux-headers-6.6.13+bpo-amd64 linux-headers-amd64 E: Sub-process /usr/bin/dpkg returned an error code (1) ===8< /var/lib/dkms/tp_smapi/0.43/build/make.log: ===8< DKMS make.log for tp_smapi-0.43 for kernel 6.6.13+bpo-amd64 (x86_64) Tue May 14 05:01:10 PM CEST 2024 make: Entering directory '/usr/src/linux-headers-6.6.13+bpo-amd64' CC [M] /var/lib/dkms/tp_smapi/0.43/build/thinkpad_ec.o CC [M] /var/lib/dkms/tp_smapi/0.43/build/tp_smapi.o /var/lib/dkms/tp_smapi/0.43/build/thinkpad_ec.c:94:42: error: macro "DEFINE_SEMAPHORE" requires 2 arguments, but only 1 given 94 | static DEFINE_SEMAPHORE(thinkpad_ec_mutex); | ^ In file included from /var/lib/dkms/tp_smapi/0.43/build/thinkpad_ec.c:45: /usr/src/linux-headers-6.6.13+bpo-common/include/linux/semaphore.h:34: note: macro "DEFINE_SEMAPHORE" defined here 34 | #define DEFINE_SEMAPHORE(_name, _n) \ | /var/lib/dkms/tp_smapi/0.43/build/thinkpad_ec.c:94:8: error: type defaults to ‘int’ in declaration of ‘DEFINE_SEMAPHORE’ [-Werror=implicit-int] 94 | static DEFINE_SEMAPHORE(thinkpad_ec_mutex); |^~~
Bug#1071497: util-linux: (script security feature) conversion from typescript to raw text needed
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 information. This forces users into the dilemma of disclosing their script in full (including sensitive info), or not collaborating at all. Users need to be able to edit the transcript in a text editor to redact any sensitive or irrelevant bulky content. There is also a practical problem in general. Binary typescript cannot be pasted into a pastebin. Some pastebin services have a “typescript” data type, but this is actually an unfortunate language clash (“typescript” is actually a programming language, unrelated). A common use case of /script/ is to capture problems, study the output for diagnosis, and share the output with expert collaborators. The sharing is often done with pastebin services. But those UIs only accommodate raw text. Bug trackers will accept binary attachments but then others need to have the tools and knowledge to handle typescript. The mere extra hurdle dissuades some people from looking at the bug report. Pasting the output text into the body of a bug report invites more participation because it’s more convenient for readers. So a feature is needed to convert typescript into text. I was surprised to discover that the /scriptreplay/ command does not have a feature to convert to raw text. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-21-amd64 (SMP w/2 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages util-linux depends on: ii libblkid1 2.38.1-5+deb12u1 ii libc6 2.36-9+deb12u7 ii libcap-ng00.8.3-1+b3 ii libcrypt1 1:4.4.33-2 ii libmount1 2.38.1-5+deb12u1 ii libpam0g 1.5.2-6+deb12u1 ii libselinux1 3.4-1+b6 ii libsmartcols1 2.38.1-5+deb12u1 ii libsystemd0 252.22-1~deb12u1 ii libtinfo6 6.4-4 ii libudev1 252.22-1~deb12u1 ii libuuid1 2.38.1-5+deb12u1 ii util-linux-extra 2.38.1-5+deb12u1 ii zlib1g1:1.2.13.dfsg-1 Versions of packages util-linux recommends: ii sensible-utils 0.0.17+nmu1 Versions of packages util-linux suggests: ii dosfstools 4.2-1 ii kbd 2.5.1-1+b1 pn util-linux-locales -- no debconf information
Bug#1071496: wl-clipboard: An option to strip out ANSI color and bold contol characters needed
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 behaviour deviates from copy/paste using a mouse. If the terminal is showing text that is colored and formatted, and the mouse is used to select a string of text which is then pasted into emacs or a pastebin form, the control characters are stripped out uncolored raw text is pasted. The wl-copy tool should be able to simulate that. This can easily be reproduced using the “script” command to capture a typescript, as follows: $ script $ [do anything arbitrary here, such as “man wl-clipboard”] $ $ file typescript typescript: Unicode text, UTF-8 text, with CRLF, CR, LF line terminators, with escape sequences, with overstriking $ wl-copy -p < typescript When pasting into a place where raw text is expected, control codes appear. Whereas if you use a mouse to do the copy, the paste is raw text. So it would be useful if wl-copy had an option to simulate the mouse action. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-21-amd64 (SMP w/2 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages wl-clipboard depends on: ii libc6 2.36-9+deb12u7 ii libwayland-client0 1.21.0-1 Versions of packages wl-clipboard recommends: ii xdg-utils 1.1.3-4.1 wl-clipboard suggests no packages. -- no debconf information
Bug#1071468: linux-image-amd64: mess left when kernel installation fails (grub treats the uninstalled kernel as existing)
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 Apparently whatever generic installation mechanism is used, it fails to properly treat a botched delivery. That is, even though the deb file for kernel version 6.6.13-1~bpo12+1 is only 1480 bytes and so corrupt it cannot even be unpacked, the package was erroneously flagged as installed, at least in part: ===8< $ dpkg -l | grep 6.6.13-1~bpo12+1 iU linux-headers-6.6.13+bpo-amd64 6.6.13-1~bpo12+1 amd64 Header files for Linux 6.6.13+bpo-amd64 ii linux-headers-6.6.13+bpo-common 6.6.13-1~bpo12+1 all Common header files for Linux 6.6.13+bpo iU linux-headers-amd64 6.6.13-1~bpo12+1 amd64 Header files for Linux amd64 configuration (meta-package) iF linux-image-6.6.13+bpo-amd64 6.6.13-1~bpo12+1 amd64 Linux 6.6 for 64-bit PCs (signed) iU linux-image-amd646.6.13-1~bpo12+1 amd64 Linux for 64-bit PCs (meta-package) ii linux-kbuild-6.6.13+bpo 6.6.13-1~bpo12+1 amd64 Kbuild infrastructure for Linux 6.6.13+bpo ii linux-libc-dev 6.6.13-1~bpo12+1 all Linux support headers for userspace development ===8< Perhaps “iU” and “iF” are correct flags in the first column (it’s unclear because “man dpkg” does not document these). But grub alterations were carried out despite the failure and the default kernel became the version that could not even be unpacked from the deb file (6.6.13-1~bpo12+1). So it’s not just a failure of that kernel but also a failure in the installation logic, perhaps in apt. Though I doubt apt would influence grub, so I’m filing this in the virtual pkg linux-image-amd64 for lack of a better place. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-21-amd64 (SMP w/2 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linux-image-amd64 depends on: ih linux-image-6.6.13+bpo-amd64 6.6.13-1~bpo12+1 linux-image-amd64 recommends no packages. linux-image-amd64 suggests no packages. -- no debconf information
Bug#1071467: linux-image-6.6.13+bpo-amd64: installation botched, tiny and corrupt deb file
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 transcript of the session but it’s probably not worth posting. It’s in the binary format produced by the “script” command. The deb file is only 1,480 bytes, which is obviously a non-starter. The final output was this: Download is performed unsandboxed as root as file '/root/linux-image-amd64_6.6.13-1~bpo12+1_amd64.deb' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied) -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-21-amd64 (SMP w/2 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linux-image-6.6.13+bpo-amd64 depends on: ii initramfs-tools [linux-initramfs-tool] 0.142 ii kmod30+20221128-1 ii linux-base 4.9 Versions of packages linux-image-6.6.13+bpo-amd64 recommends: ii apparmor 3.0.8-3 ii firmware-linux-free 20200122-1 Versions of packages linux-image-6.6.13+bpo-amd64 suggests: pn debian-kernel-handbook ii grub-pc 2.06-13+deb12u1 pn linux-doc-6.6 Versions of packages linux-image-6.6.13+bpo-amd64 is related to: pn firmware-amd-graphics pn firmware-atheros pn firmware-bnx2 pn firmware-bnx2x pn firmware-brcm80211 pn firmware-cavium pn firmware-intel-sound pn firmware-intelwimax pn firmware-ipw2x00 pn firmware-ivtv ii firmware-iwlwifi 20230210-5 pn firmware-libertas pn firmware-linux-nonfree pn firmware-misc-nonfree pn firmware-myricom pn firmware-netxen pn firmware-qlogic pn firmware-realtek pn firmware-samsung pn firmware-siano pn firmware-ti-connectivity pn xen-hypervisor -- no debconf information
Bug#1071415: curl: (regression) URLs containing a space fail syntax check (“URL using bad/illegal format…”)
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 "$document" --disable-epsv --netrc-optional but after upgrading from Bullseye to Bookworm (cURL 7.74.0-1.3+deb11u11 to 7.88.1-10+deb12u5), the URL is rejected with this output: curl: (3) URL using bad/illegal format or missing URL The workaround is to manually encode the space like this: 'ftps://host.domain.com/word1%20word2/dir/' /Documentation/ The --url parameter is documented in the man page this way: > --url >Specify a URL to fetch. This option is mostly handy when you want to > specify URL(s) in a config file. < … This is misleading because the URL is not necessarily used to do a *fetch*. So it could cause confusion for people who are transmitting. There is also no mention in the man page whether spaces are accepted or refused, nor is there mention of how encodings are treated. When I experimented with using “%20” in place of a space, my concern was that cURL would further encode /that/ to result in a literal “%20”. User should be explicitly informed. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages curl depends on: ii libc6 2.36-9+deb12u7 ii libcurl4 7.88.1-10+deb12u5 ii zlib1g1:1.2.13.dfsg-1 curl recommends no packages. curl suggests no packages. -- no debconf information
Bug#1071386: yt-dlp: “501 Tor is not an HTTP Proxy” error when SOCKS proxying was requested
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 * HTTP proxy listening on port 8118 This is the result of an attempt to use the socks5h:// scheme: ===8< $ yt-dlp --proxy socks5h://127.0.0.1:9050 --max-filesize 1M http://ng27owmagn5amdm7l5s3rsqxwscl5ynppnis5dqcasogkyxcfqn7psid.onion/watch?v=-Zj50DmBFp0 [youtube] Extracting URL: http://ng27owmagn5amdm7l5s3rsqxwscl5ynppnis5dqcasogkyxcfqn7psid.onion/watch?v=-Zj50DmBFp0 [youtube] -Zj50DmBFp0: Downloading webpage WARNING: [youtube] Unable to download webpage: [youtube] -Zj50DmBFp0: Downloading android player API JSON WARNING: [youtube] . Retrying (1/3)... [youtube] -Zj50DmBFp0: Downloading android player API JSON WARNING: [youtube] . Retrying (2/3)... [youtube] -Zj50DmBFp0: Downloading android player API JSON WARNING: [youtube] . Retrying (3/3)... [youtube] -Zj50DmBFp0: Downloading android player API JSON [youtube] -Zj50DmBFp0: Downloading iframe API JS WARNING: [youtube] Unable to download webpage: [youtube] -Zj50DmBFp0: Downloading web player API JSON WARNING: [youtube] . Retrying (1/3)... [youtube] -Zj50DmBFp0: Downloading web player API JSON WARNING: [youtube] . Retrying (2/3)... [youtube] -Zj50DmBFp0: Downloading web player API JSON WARNING: [youtube] . Retrying (3/3)... [youtube] -Zj50DmBFp0: Downloading web player API JSON WARNING: [youtube] Unable to download API page: (caused by URLError(OSError('Tunnel connection failed: 501 Tor is not an HTTP Proxy'))) ERROR: [youtube] -Zj50DmBFp0: Unable to download API page: (caused by URLError(OSError('Tunnel connection failed: 501 Tor is not an HTTP Proxy'))) ===8< The error message itself is erroneous nonsense. The user never claimed Tor to *be* an HTTP proxy. Proxies are wholly independent of Tor and should be treated genericly. yt-dlp is trying to be smart in working out that an onion URL implies Tor, but really all it needs to know is that the “h” in SOCKS5h means to make the proxy handle the DNS resolution. Workaround: Supplying --proxy http://127.0.0.1:8118 works for me because I happen to have an HTTP proxy configured as well. But the man page explicitly states that both socks and http proxies are supported. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages yt-dlp depends on: ii python33.11.2-1+b1 ii python3-brotli 1.0.9-2+b6 ii python3-certifi2022.9.24-1 ii python3-mutagen1.46.0-1 ii python3-pkg-resources 66.1.1-1 ii python3-pycryptodome 3.11.0+dfsg1-4 ii python3-websockets 10.4-1 Versions of packages yt-dlp recommends: ii aria21.36.0-1 ii ca-certificates 20230311 ii curl 7.88.1-10+deb12u5 ii ffmpeg 7:5.1.4-0+deb12u1 ii python3-pyxattr 0.8.1-1 ii rtmpdump 2.4+20151223.gitfa8646d.1-2+b2 ii wget 1.21.3-1+b2 Versions of packages yt-dlp suggests: pn libfribidi-bin | bidiv ii mpv 0.35.1-4 pn phantomjs -- no debconf information
Bug#1071381: linux-image-6.1.0-15-amd64: (regression) spontaneous freezing on Thinkpad
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 spontaneously freezes usually around 3 hours after booting. This never happened with Bullseye. The following kernels were tested: linux-image-5.10.0-6-amd64 5.10.28-1 no freezing linux-image-5.10.0-7-amd64 5.10.40-1 no freezing linux-image-5.10.0-8-amd64 5.10.46-5 no freezing linux-image-5.10.0-16-amd64 5.10.127-2 no freezing linux-image-5.10.0-19-amd64 5.10.149-2 no freezing linux-image-5.10.0-28-amd64 5.10.209-2 no freezing linux-image-6.1.0-15-amd64 6.1.66-1freezing (test 1) linux-image-6.1.0-20-amd64 6.1.85-1freezing (test 1+2) linux-image-6.1.0-21-amd64 6.1.90-1freezing (test 1+3) test 1: All keyboard and mouse input is completely ignored and ineffective. test 2: An Android was attached and adb was used with the “watch” command to transmit a file over the USB bus to the phone every minute, which contained a timestamp. Effectively this was a heartbeat signal. When the freezing happens, the phone stops receiving the file that’s pushed over USB. Thus the “watch” process is likely frozen. test 3: Wi-Fi-attached device attempted to SSH to the frozen machine. It could not make a connection. I was never doing anything i/o or cpu intensive when it froze. On one occasion emacs was open and a browser was open, nothing else. IIRC, I wasn’t even online. The browser was just on a static local page. On another occasion I was offline editing in emacs and had evince viewing a PDF with no browser open. The freeze is spontaneous but has a high degree of reproduceability. That is, although no user action seems to trigger the freeze, I cannot get through a day without a freeze. It always freezes a few hours after booting. My sample size is only 5 or so sessions. It’s an intolerable defect so I only run kernel 5.10.0-28 now. -- Package-specific info: ** Version: Linux version 6.1.0-15-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.66-1 (2023-12-09) ** Command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-15-amd64 root=/dev/mapper/[REDACTED] ro rd.luks.name=UUID=[REDACTED]=cryptlvm quiet ** Tainted: OE (12288) * externally-built ("out-of-tree") module was loaded * unsigned module was loaded ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information sys_vendor: LENOVO product_name: 6465CTO product_version: ThinkPad T61 chassis_vendor: LENOVO chassis_version: Not Available bios_vendor: LENOVO bios_version: 7LETC9WW (2.29 ) board_vendor: LENOVO board_name: 6465CTO board_version: Not Available ** Loaded modules: snd_seq_dummy snd_hrtimer snd_seq snd_seq_device ipt_REJECT nf_reject_ipv4 xt_REDIRECT nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_tcpudp nft_compat nf_tables libcrc32c nfnetlink qrtr bridge stp llc binfmt_misc iwl3945 iwlegacy snd_hda_codec_analog snd_hda_codec_generic coretemp mac80211 i915 kvm_intel snd_hda_intel kvm r852 pcmcia snd_intel_dspcfg sm_common libarc4 irqbypass snd_intel_sdw_acpi nand cfg80211 snd_hda_codec nandcore r592 iTCO_wdt bch snd_hda_core yenta_socket drm_buddy intel_pmc_bxt mtd pcspkr pcmcia_rsrc iTCO_vendor_support snd_hwdep wmi_bmof memstick pcmcia_core thinkpad_acpi drm_display_helper snd_pcm nvram watchdog cec platform_profile snd_timer ledtrig_audio rc_core snd soundcore ttm rfkill drm_kms_helper ac i2c_algo_bit acpi_cpufreq button sg joydev evdev serio_raw tp_smapi(OE) thinkpad_ec(OE) parport_pc ppdev lp parport fuse drm loop efi_pstore configfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic crypto_simd cryptd xts ecb hid_generic usbhid hid dm_crypt dm_mod sd_mod t10_pi crc64_rocksoft_generic crc64_rocksoft crc_t10dif crct10dif_generic crc64 sdhci_pci crct10dif_common cqhci ata_generic xhci_pci xhci_hcd sdhci sha512_ssse3 sha512_generic ata_piix ahci libahci psmouse sha256_ssse3 libata sha1_ssse3 mmc_core scsi_mod firewire_ohci i2c_i801 uhci_hcd ehci_pci lpc_ich ehci_hcd firewire_core scsi_common i2c_smbus crc_itu_t usbcore e1000e usb_common video battery wmi ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub [8086:2a00] (rev 0c) Subsystem: Lenovo ThinkPad T61/R61 [17aa:20b3] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (primary) [8086:2a02] (rev 0c) (prog-if 00 [VGA controller]) Subsystem: Leno
Bug#1070901: binary blob is a red herring
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 to why authentication is denied. We still likely have a bug but it’s non-trivial to see what the issue is.
Bug#1070901: POP3 authentication failures due to binary blob transmission before credentials (2 bugs)
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 behaviour in some cases, but fetchmail works nonetheless. cURL should be able to emulate the working fetchmail session. The access instructions from the server (which may have changed): ===8< POP3 Server yllvy3mhtamstbqzm4wucfwab57ap6zraxqvkjn2iobmrtxdsnb37dqd.onion Server type POP3 Server Port 110 SSL Mode Use SSL via STLS (TLS) Password type Clear Connect via TOR network ===8< Fetchmail has no problem accessing the server. A successful fetchmail transcript looks like this: ===8< fetchmail: 6.4.37 querying onionmail (protocol POP3) at Sat 11 May 2024 00:00:00 AM CEST: poll started fetchmail: Trying to connect to 127.0.0.1/12345...connected. fetchmail: POP3< +OK POP3 yllvy3mhtamstbqzm4wucfwab57ap6zraxqvkjn2iobmrtxdsnb37dqd.onion INF N/A t2gi9 fetchmail: POP3> CAPA fetchmail: POP3< +OK Capability list follows fetchmail: POP3< USER fetchmail: POP3< LOGIN-DELAY 900 fetchmail: POP3< EXPIRE 30 fetchmail: POP3< UIDL fetchmail: POP3< STLS fetchmail: POP3< STARTTLS fetchmail: POP3< RQUS fetchmail: POP3< RQEX fetchmail: POP3< IMPLEMENTATION POP3 fetchmail: POP3< . fetchmail: POP3> STLS fetchmail: POP3< +OK Begin TLS negotiation fetchmail: Loaded OpenSSL library 0x30b0 newer than headers 0x3080, trying to continue. fetchmail: Server certificate: fetchmail: Issuer Organization: anonmail fetchmail: Issuer CommonName: yllvy3mhtamstbqzm4wucfwab57ap6zraxqvkjn2iobmrtxdsnb37dqd.onion fetchmail: Subject CommonName: yllvy3mhtamstbqzm4wucfwab57ap6zraxqvkjn2iobmrtxdsnb37dqd.onion fetchmail: Server CommonName mismatch: yllvy3mhtamstbqzm4wucfwab57ap6zraxqvkjn2iobmrtxdsnb37dqd.onion != 127.0.0.1 fetchmail: onionmail key fingerprint: 25:95:69:E6:A9:3A:97:7B:B1:4A:4B:36:09:14:EF:93 fetchmail: Server certificate verification error: unable to get local issuer certificate fetchmail: Broken certification chain at: /ST=onionland/OU=anonmail/O=anonmail/C=XX/CN=yllvy3mhtamstbqzm4wucfwab57ap6zraxqvkjn2iobmrtxdsnb37dqd.onion fetchmail: This could mean that the server did not provide the intermediate CA's certificate(s), which is nothing fetchmail could do anything about. For details, please see the README.SSL-SERVER document that ships with fetchmail. fetchmail: This could mean that the root CA's signing certificate is not in the trusted CA certificate location, or that c_rehash needs to be run on the certificate directory. For details, please see the documentation of --sslcertpath and --sslcertfile in the manual page. See README.SSL for details. fetchmail: Server certificate: fetchmail: Issuer Organization: anonmail fetchmail: Issuer CommonName: yllvy3mhtamstbqzm4wucfwab57ap6zraxqvkjn2iobmrtxdsnb37dqd.onion fetchmail: Subject CommonName: yllvy3mhtamstbqzm4wucfwab57ap6zraxqvkjn2iobmrtxdsnb37dqd.onion fetchmail: Server CommonName mismatch: yllvy3mhtamstbqzm4wucfwab57ap6zraxqvkjn2iobmrtxdsnb37dqd.onion != 127.0.0.1 fetchmail: Server certificate verification error: hostname mismatch fetchmail: Server certificate: fetchmail: Issuer Organization: anonmail fetchmail: Issuer CommonName: yllvy3mhtamstbqzm4wucfwab57ap6zraxqvkjn2iobmrtxdsnb37dqd.onion fetchmail: Subject CommonName: yllvy3mhtamstbqzm4wucfwab57ap6zraxqvkjn2iobmrtxdsnb37dqd.onion fetchmail: Server CommonName mismatch: yllvy3mhtamstbqzm4wucfwab57ap6zraxqvkjn2iobmrtxdsnb37dqd.onion != 127.0.0.1 fetchmail: Server certificate verification error: unable to verify the first certificate fetchmail: Server certificate: fetchmail: Issuer Organization: anonmail fetchmail: Issuer CommonName: yllvy3mhtamstbqzm4wucfwab57ap6zraxqvkjn2iobmrtxdsnb37dqd.onion fetchmail: Subject CommonName: yllvy3mhtamstbqzm4wucfwab57ap6zraxqvkjn2iobmrtxdsnb37dqd.onion fetchmail: Server CommonName mismatch: yllvy3mhtamstbqzm4wucfwab57ap6zraxqvkjn2iobmrtxdsnb37dqd.onion != 127.0.0.1 fetchmail: SSL/TLS: using protocol TLSv1.2, cipher AES256-GCM-SHA384, 256/256 secret/processed bits fetchmail: Warning: the connection is insecure, continuing anyways. (Better use --sslcertck!) fetchmail: 127.0.0.1: upgrade to TLS succeeded. fetchmail: POP3> CAPA fetchmail: POP3< +OK Capability list follows fetchmail: POP3< USER fetchmail: POP3< LOGIN-DELAY 900 fetchmail: POP3< EXPIRE 30 fetchmail: POP3< UIDL fetchmail: POP3< RQUS fetchmail: POP3< RQEX fetchmail: POP3< IMPLEMENTATION POP3 fetchmail: POP3< . fetchmail: POP3> USER mannysUID fetchmail: POP3< +OK fetchmail: POP3> PASS * fetchmail: POP3< +OK fetchmail: POP3> STAT fetchmail: POP3< +OK
Bug#1070802: texlive-latex-extra: (regression) acro no longer compiles
> 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 problematic. > I won't do a roll back. If you need the old version back, please install it > into your LOCALTEMXMF tree and use it. To be clear, the rollback was not suggested to fix it for me. It’s how the Debian release would be fixed to function for everyone. Maybe I’m missing something but I thought the point of version control and the purpose of Debian stable targeting specific versions? This aspect of the Debian effort is a bit murky. It’s strange that the Debian policy manual and developers’ reference guide do not cover a rollback procedure when a particular version turns out to be a disaster. Though I suppose whatever would be prescribed, TeXlive is a beast that would need an exceptional approach anyway. Indeed I can hack around the problem to fix it for myself. I appreciate the tip about LOCALTEMXMF. TIL there is a TeXlive pkg manager (tlmgr), so I probably need to look into how that works.
Bug#1070802: texlive-latex-extra: (regression) acro no longer compiles
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 crippling bug has not been reported there, but I found this comment: https://github.com/cgnieder/acro/issues/233#issuecomment-1013665911 Apparently Bookworm is using the absolute latest version of acro (3.8). So from the Debian side, the acro version needs to be rolled back. I have made use of the X-Debbugs-Cc feature on this message to get the author in the loop, which I guess I should have done on the submission.
Bug#1070802: texlive-latex-extra: (regression) acro no longer compiles
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 compiled and functioned fine in the past (version 2020.20210202-3) but no longer compile after the upgrade to 2022.20230122-4. This is a short sample document: ===8< \documentclass{scrlttr2} \usepackage{acro} %\DeclareAcronym{foo}{short=FOO, long=breaks even if no acronym is defined} \begin{document} \begin{letter}{recipient} lipsum \end{letter} \end{document} ===8< The error is this: ===8< ERROR: Package acro Error: Patching `maketitle' failed. Please contact the acro (acro)author. Type to continue. ... l.6 \begin{document} --- HELP --- No help available ===8< The upstream tag was applied because that’s where the defect is, but action can still be taken on the Debian release. Debian should either roll back the acro.sty version, or advance it. The current version is apparently completely unusable. Both latex and pdflatex fail to compile it. This is the fls file: ===8< PWD /tmp INPUT /etc/texmf/web2c/texmf.cnf INPUT /usr/share/texmf/web2c/texmf.cnf INPUT /usr/share/texlive/texmf-dist/web2c/texmf.cnf INPUT /var/lib/texmf/web2c/pdftex/latex.fmt INPUT sample.tex OUTPUT sample.log INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlttr2.cls INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlttr2.cls INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlttr2.cls INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlttr2.cls INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlttr2.cls INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlttr2.cls INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlttr2.cls INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlttr2.cls INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlttr2.cls INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlttr2.cls INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlttr2.cls INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrkbase.sty INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrkbase.sty INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrkbase.sty INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrkbase.sty INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrkbase.sty INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrkbase.sty INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrkbase.sty INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrkbase.sty INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrkbase.sty INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrkbase.sty INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrkbase.sty INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrbase.sty INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrbase.sty INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrbase.sty INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrbase.sty INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrbase.sty INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrbase.sty INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrbase.sty INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrbase.sty INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrbase.sty INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrbase.sty INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrbase.sty INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile.sty INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile.sty INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile.sty INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile.sty INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile.sty INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile.sty INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile.sty INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile.sty INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile.sty INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile.sty INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile.sty INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile-hook.sty INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile-hook.sty
Bug#1070286: pipx: The ‘list’ command falsely claims “nothing has been installed with pipx 😴”
> 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 argostranslate 1.9.6, installed using Python 3.11.2 - argos-translate - argospm ===8< As user: ===8< $ PIPX_HOME=${prefix:-/opt/}/pipx PIPX_BIN_DIR=${prefix:-/usr/local}/bin pipx list Traceback (most recent call last): File "/usr/lib/python3.11/logging/config.py", line 562, in configure handler = self.configure_handler(handlers[name]) ^^ File "/usr/lib/python3.11/logging/config.py", line 747, in configure_handler result = factory(**kwargs) ^ File "/usr/lib/python3.11/logging/__init__.py", line 1181, in __init__ StreamHandler.__init__(self, self._open()) File "/usr/lib/python3.11/logging/__init__.py", line 1213, in _open return open_func(self.baseFilename, self.mode, ^^^ PermissionError: [Errno 13] Permission denied: '/opt/pipx/logs/cmd_2024-05-03_20.14.46.log' The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/usr/bin/pipx", line 8, in sys.exit(cli()) ^ File "/usr/lib/python3/dist-packages/pipx/main.py", line 814, in cli setup(parsed_pipx_args) File "/usr/lib/python3/dist-packages/pipx/main.py", line 753, in setup setup_logging("verbose" in args and args.verbose) File "/usr/lib/python3/dist-packages/pipx/main.py", line 745, in setup_logging logging.config.dictConfig(logging_config) File "/usr/lib/python3.11/logging/config.py", line 812, in dictConfig dictConfigClass(config).configure() File "/usr/lib/python3.11/logging/config.py", line 569, in configure raise ValueError('Unable to configure handler ' ValueError: Unable to configure handler 'file' ===8< Which is discussed here: https://github.com/pypa/pipx/issues/754#issuecomment-1181082995 I granted read access to /opt/pipx/logs/ for users and it made no difference. I’ll just have to use root to list pkgs and call it good enough for me. But certainly it’s a bug for pipx to crash and give a stack dump. In the very least it should give a specific user-readable error msg.
Bug#990451: apt: the --no-all-versions option not working as documented
> 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 all *.deb > files to be downloaded from non-local (that mostly means non-file:/) > sources… Thanks! That’s useful indeed. > Not sure about the later "each source location"… that can turn out to be > a lot of details for not that much gain: a typical Debian stable has > 'normal', 'updates' and 'security'. You could add 'proposed' and e.g. > 'backports' and a random set of 3rd parties like the typical Ubuntu user > with seemingly 42+ PPAs added. That is 3+X counters useless even to you > as you were just interested in the data coming from your local mirror > vs. others. And that would assume that all mirrors are complete and > available, no retries, no fallbacks, no redirects. Indeed the cloud vs. local counts are the most useful. I was thinking in terms of luxury. Many different sources being fetched in parallel would give the expectation of a fast fetch. And if some are fetched over tor or a slow host, it would also give an indication of time. And if something comes from a Tor source and your in a place that blocks Tor, that’s marginally useful information. But indeed the effort would not be justfied with apt and apt-get already giving what’s needed. >From there, I suppose my use-case does not justify making --no-all-versions function. But the man page should at least reflect reality.
Bug#1070297: cargo: Chronic spurious network errors blocked installation
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 mechanism by which users can use more robust tools for the download and then feed the file to cargo. Installing a package took a few days of running around a city to try different internet connections and different libraries and cafes until a single connection was found to be up to the full task. The procedure was like this: ===8< $ env -C /usr/local/src git clone --config http.proxy=http://127.0.0.1:8118 https://github.com/wireapp/cryptobox-c $ env -C /usr/local/src/cryptobox-c make cargo build Updating crates.io index warning: spurious network error (2 tries remaining): http parser error: stream ended at an unexpected time; class=Http (34) Fetch [ ] 3.11%, 33.10KiB/s warning: spurious network error (1 tries remaining): http parser error: stream ended at an unexpected time; class=Http (34) Fetch [ ] 2.47%, 44.87KiB/s ===8< The “cargo build” was tried probably ~30 or so times. Sometimes over tor; sometimes over a vpn; often over normal clearnet. The following was added to /usr/local/src/cryptobox-c/Cargo.toml and various parameters were fiddled with to try to get more forgiveness on the network problems: ===8< [http] #proxy = "http://127.0.0.1:8118"; # HTTP proxy in libcurl format timeout = 80# timeout for each HTTP request, in seconds low-speed-limit = 1 # network timeout threshold (bytes/sec) multiplexing = false# HTTP/2 multiplexing [net] retry = 30 # network retries git-fetch-with-cli = false # use the `git` executable for git operations ===8< That was futile. A warning was given about the section titles “[http]” and “[net]”, but some of the parameters seemed to take effect. There was also no way to pass in git parameters. It would have been useful to pass in “--depth 1 --shallow-submodules” Setting git-fetch-with-cli=true would not help because shallow fetching options are not offered by git as global configuration variables. The verbose logs showed that it made around ~40% progress on a ~750mb file and die due to spurious network errors. Then on the next attempt it would only get 10% of that same file, starting from the beginning. I had to connection shop, travelling around town until I could find a high-bandwidth low-latency connection at a time of day with relatively low traffic to get the package downloaded. It finally succeeded but only because of that overperforming uplink was available to me. Many improvements are needed: ① a way to pass in git options. ② crash recovery/resume - it’s crazy to fetch half of a 700mb file and then throw it all away and start over when the network fails. ③ a way to be informed about the exact URL being fetched so we can use something like “aria2c -c” or “wget -c” to fetch the big files using robust tools dedicated to this purpose. (maybe http.debug covers this.. not tested) ④ when cargo quits due to spurious network errors, it needs to keep the partial download around and tell users where the partial file is. ⑤ a way to feed a complete local file to cargo to use in place of whatever it would normally fetch. ⑥ a way to specify a log file. All output was dumped to the terminal and no transcription mechanism was being used. The man page and the config manual¹ make no mention of a logfile option. The files that gave the most grief were apparently standard libraries not specific to cryptobox. The full Debian release disk (90gb, which I have on-hand) likely even has the file that was needed somewhere. But cargo lacked the options needed to put it to use. This is tagged with severity normal. The five improvements listed above may technically be “wishlist” severity, but it seems more like a defect that cargo is essentially rendered dysfunctional on any less than perfect or average network. ¹ https://doc.rust-lang.org/cargo/reference/config.html -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cargo depends on: ii bi
Bug#1070290: python3-pip: (security) Processing continues despite malformed --proxy arg + man page omits scheme:// from --proxy arg
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 Specify a proxy in the form scheme://[user:passwd@]proxy.server:port. $ man pip3 | grep proxy --proxy Specify a proxy in the form [user:passwd@]proxy.server:port. ===8< (it’s the same inconsistency for pip, btw) I did not keep a copy of the command that was executed but it was something like this with the omitted scheme: $ pip3 --proxy 127.0.0.1:8118 --log-file '$logfile1" --log "$logfile2" argostranslate The detailed log file prints: “ERROR: Could not install packages due to an EnvironmentError: Proxy URL had no scheme, should start with http:// or https://” but then it presses ahead anyway. Yikes! There should have been a syntax check as a very first task, and as soon as something fails that check, it should terminate with an error. This is actually a security issue because proxies are sometimes used for confidentiality purposes. ===8< 2022-04-21T21:33:39,656 Using pip 20.3.4 from /usr/lib/python3/dist-packages/pip (python 3.9) 2022-04-21T21:33:39,661 Non-user install because site-packages writeable 2022-04-21T21:33:39,814 Created temporary directory: /tmp/pip-ephem-wheel-cache-20ytbstg 2022-04-21T21:33:39,815 Created temporary directory: /tmp/pip-req-tracker-byaf3m_3 2022-04-21T21:33:39,816 Initialized build tracking at /tmp/pip-req-tracker-byaf3m_3 2022-04-21T21:33:39,816 Created build tracker: /tmp/pip-req-tracker-byaf3m_3 2022-04-21T21:33:39,816 Entered build tracker: /tmp/pip-req-tracker-byaf3m_3 2022-04-21T21:33:39,816 Created temporary directory: /tmp/pip-install-mtsrwt9e 2022-04-21T21:33:39,834 1 location(s) to search for versions of argostranslategui: 2022-04-21T21:33:39,834 * https://pypi.org/simple/argostranslategui/ 2022-04-21T21:33:39,835 Fetching project page and analyzing links: https://pypi.org/simple/argostranslategui/ 2022-04-21T21:33:39,835 Getting page https://pypi.org/simple/argostranslategui/ 2022-04-21T21:33:39,836 Found index url https://pypi.org/simple 2022-04-21T21:33:39,838 Looking up "https://pypi.org/simple/argostranslategui/"; in the cache 2022-04-21T21:33:39,838 Request header has "max_age" as 0, cache bypassed 2022-04-21T21:33:39,838 ERROR: Could not install packages due to an EnvironmentError: Proxy URL had no scheme, should start with http:// or https:// 2022-04-21T21:33:39,839 Removed build tracker: '/tmp/pip-req-tracker-byaf3m_3' 2022-04-21T21:33:59,899 Using pip 20.3.4 from /usr/lib/python3/dist-packages/pip (python 3.9) 2022-04-21T21:33:59,901 Non-user install because site-packages writeable 2022-04-21T21:34:00,029 Created temporary directory: /tmp/pip-ephem-wheel-cache-51z4eis3 2022-04-21T21:34:00,030 Created temporary directory: /tmp/pip-req-tracker-8knmidku 2022-04-21T21:34:00,030 Initialized build tracking at /tmp/pip-req-tracker-8knmidku 2022-04-21T21:34:00,030 Created build tracker: /tmp/pip-req-tracker-8knmidku 2022-04-21T21:34:00,030 Entered build tracker: /tmp/pip-req-tracker-8knmidku 2022-04-21T21:34:00,031 Created temporary directory: /tmp/pip-install-s4xagkiz 2022-04-21T21:34:00,043 1 location(s) to search for versions of argostranslategui: 2022-04-21T21:34:00,043 * https://pypi.org/simple/argostranslategui/ 2022-04-21T21:34:00,043 Fetching project page and analyzing links: https://pypi.org/simple/argostranslategui/ 2022-04-21T21:34:00,044 Getting page https://pypi.org/simple/argostranslategui/ 2022-04-21T21:34:00,045 Found index url https://pypi.org/simple 2022-04-21T21:34:00,046 Looking up "https://pypi.org/simple/argostranslategui/"; in the cache 2022-04-21T21:34:00,046 Request header has "max_age" as 0, cache bypassed 2022-04-21T21:34:00,047 Starting new HTTPS connection (1): pypi.org:443 2022-04-21T21:34:00,065 ERROR: Exception: 2022-04-21T21:34:00,065 Traceback (most recent call last): 2022-04-21T21:34:00,065 File "/usr/share/python-wheels/resolvelib-0.5.4-py2.py3-none-any.whl/resolvelib/resolvers.py", line 171, in _merge_into_criterion 2022-04-21T21:34:00,065 crit = self.state.criteria[name] 2022-04-21T21:34:00,065 KeyError: 'argostranslategui' 2022-04-21T21:34:00,065 2022-04-21T21:34:00,065 During handling of the above exception, another exception occurred: 2022-04-21T21:34:00,065 2022-04-21T21:34:00,065 Traceback (most recent call last): 2022-04-21T21:34:00,065 File "/usr/lib/python3/dist-packages/pip/_internal/cli/base_command.py", line 223, in _main 2022-04-21T21:34:00,065 status = self.run(options, args) 2022-04-21T21:34:00,065 File "/usr/lib/python3/dist-packages/pip/_internal/cli/req_command.py", line 180, in wrapper 2022-04-21T21:34:00,065 return
Bug#1070286: pipx: The ‘list’ command falsely claims “nothing has been installed with pipx 😴”
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_BIN_DIR=${prefix:-/usr/local}/bin pipx install --verbose argostranslate pipx >(setup:757): pipx version is 1.1.0 pipx >(setup:758): Default python interpreter is '/usr/bin/python3' pipx >(package_name_from_spec:323): Determined package name: argostranslate pipx >(package_name_from_spec:324): Package name determined in 0.0s creating virtual environment... pipx >(run_subprocess:173): running /usr/bin/python3 -m venv --without-pip /opt/pipx/venvs/argostranslate pipx >(run_subprocess:173): running /opt/pipx/venvs/argostranslate/bin/python -c import sysconfig; print(sysconfig.get_path('purelib')) pipx >(run_subprocess:173): running /opt/pipx/shared/bin/python -c import sysconfig; print(sysconfig.get_path('purelib')) pipx >(run_subprocess:173): running /opt/pipx/venvs/argostranslate/bin/python --version pipx >(_parsed_package_to_package_or_url:128): cleaned package spec: argostranslate installing argostranslate... pipx >(run_subprocess:173): running /opt/pipx/venvs/argostranslate/bin/python -m pip install argostranslate pipx >(run_subprocess:173): running pipx >(get_venv_metadata_for_package:303): get_venv_metadata_for_package: 2081ms pipx >(_parsed_package_to_package_or_url:128): cleaned package spec: argostranslate pipx >(needs_upgrade:69): Time since last upgrade of shared libs, in seconds: 6108. Upgrade will be run by pipx if greater than 2592000. installed package argostranslate 1.9.6, installed using Python 3.11.2 These apps are now globally available - argos-translate - argospm pipx >(warn_if_not_on_path:410): ⚠️ Note: '/usr/local/bin' is not on your PATH environment variable. These apps will not be globally accessible until your PATH is updated. Run `pipx ensurepath` to automatically add it, or manually modify your PATH in your shell's config file (i.e. ~/.bashrc). done! ✨ 🌟 ✨ ===8< Running “pipx list” both as root and as a user yields: ===8< nothing has been installed with pipx 😴 ===8< On the off chance that this is an environmental issue, running within the venv was also tested: ===8< $ source /opt/pipx/venvs/argostranslate/bin/activate (argostranslate) 0 $ pipx list nothing has been installed with pipx 😴 ===8< The argostranslate app runs fine. So it’s unclear why pipx would lose track of it right away. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pipx depends on: ii python3 3.11.2-1+b1 ii python3-argcomplete 2.0.0-1 ii python3-importlib-metadata 4.12.0-1 ii python3-packaging 23.0-1 ii python3-userpath1.8.0-1 ii python3-venv3.11.2-1+b1 Versions of packages pipx recommends: ii fonts-font-awesome 5.0.10+really4.7.0~dfsg-4.1 ii libjs-bootstrap44.6.1+dfsg1-4 ii libjs-highlight.js 9.18.5+dfsg1-2 ii libjs-jquery3.6.1+dfsg+~3.5.14-1 ii libjs-lunr 2.3.9~dfsg-2 ii mkdocs 1.4.2+dfsg-2 pipx suggests no packages. -- no debconf information
Bug#1070206: python3-pip: The options --log and --log-file have no effect on the install command
> 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 advocate for this bug upstream than > I am. I agree with all of that. I would report upstream if the bug tracker were hosted in a more open and neutral place. Microsoft venues are places I will not go to interact, apart from searching to see if a report already exists. Github in particular has access problems. Debian shelters users with this bug reporting policy¹: “Don't file bugs upstream If you file a bug in Debian, don't send a copy to the upstream software maintainers yourself, as it is possible that the bug exists only in Debian. If necessary, the maintainer of the package will forward the bug upstream.” I don’t expect anyone to mirror it upstream because I think everyone should equally have the option to avoid Microsoft’s platform, and also I agree with the Debian project principle to not impose work on others. This report has the upstream tag so upstream developers can filter on that tag and so downstream devs can filter it out. I just noticed the --log and --log-file options function correctly in one case. Part of the problem might be interplay with a bug² where pip continues even if there is a problem with the log file location for the user running it. Reproducing it myself might be non-trivial since I would need an unlimited internet connection to test more installations (which do not indicate their size prior to action). So perhaps the report could be closed on that basis anyway. There are several more upstream bugs to report against pip*. I intend to report them in Debian’s BTS using the upstream tag, unless no one wants them. I realise that they may never be seen by someone who would work them. ¹ https://www.debian.org/Bugs/Reporting ² https://github.com/pypa/pip/issues/114
Bug#1070258: release-notes: Approach to managing other package managers when upgrading needs documentation
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 the upgrade warning that the non-debian python app “argostranslate” would be ruined. It was just a surprise the next time the app was needed that it no longer functioned. I’m not sure if the release notes could give any detailed guidance, but users should probably be instructed to minimally become aware of packages that are at risk. These existing sections are probably relevant: 4.2.6. Remove non-Debian packages 4.2.13. Check package status Perhaps users should probably be instructed to run: $ pip list $ pip3 list $ pipx list to at least become aware of non-Debian packages that might be impacted so they can be reminded to give some thought to it. IMO it’s sensible to save the lists from that output to a file and then refer to it post-upgrade to test these fragile apps so the nasty surprise of lost functionality does not manifest at the time that they need to use it, which is about the worst time to discover the loss. Rust also has its own package manager (cargo), as does emacs. I have no idea if they have the same special needs that pip does. I don’t think cargo gives a listing mechanism so perhaps nothing can be done there.
Bug#1070203: python3-pip: app silently lost in upgrade to Bookworm + pip3 lost track of the status (4 bugs)
> 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 bug ① (“an app module was dropped/lost”). Apparently that bug cannot realistically be remedied, although perhaps the release notes should cover this topic. I’m a bit confused because “pip3 list” shows a list of 146 packages, but not argostranslation. Why did all those other packages survive the upgrade? I wonder if some of them are somehow managed by apt. There are still 3 other bugs. > So, I'm afraid you're well out of the supported area of pip. > Sorry. Is it necessary for aptitude full-upgrade to withhold information from the user about package destruction or removal? Ideally users would get a loud warning when actions are taken that are expected to impact an installed package. If it’s a mission critical tool, users need to be able to back out of the upgrade and assess the consequences. I would also like to mention a fifth defect I just discovered: ⑤ argostranslate was only /partially/ removed. There are some big language files that were originally installed by argostranslate. The argostranslate executable survived the upgrade but not some of the modules it relies on, leaving it in a broken partially existent state with no information given to the user. The language packs remained in tact. I don’t know where on the filesystem they live, but when I installed argostranslate again the previous language packs were found and automatically available for use. In my case, this happened to be a benefit as it saved me from the effort of refetching the language files. But it’s probably not an favorable general behavior for packages to be partially removed. Ideally the user should receive a warning about pending removal and an option for a clean removal or a partial removal. The pip package manager has an uninstall procedure and since pip is the manager of the argostranslate package, users rely on it to keep track of the objects associated to the application. > Can I suggest using pipx for installing applications instead? It > actually understands this problem and has a "reinstall-all" feature to > help you recover from Python minor-version upgrades. I really appreciate the suggestion. I gave it a try. It had several issues, but it could very well turn out to be the lesser of evils. After several hurdles pipx was able to install argostranslate in the end.
Bug#990451: apt: the --no-all-versions option not working as documented
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 be fetched from the cloud and which are sourced from my local storage (which is the full 90gb debian release from 4 months ago). If the download is big, it will suck the bandwidth quota dry (which costs money). So I tried this: $ while read -d ' ' pkg; do apt-cache policy --no-all-versions "${pkg%%{*}"; done <\ <(yes | aptitude install $some_pkg --simulate | sed -ne '/^ /p') non-starter: ===8< E: Command line option --no-all-versions is not understood in combination with the other options E: Command line option --no-all-versions is not understood in combination with the other options E: Command line option --no-all-versions is not understood in combination with the other options E: Command line option --no-all-versions is not understood in combination with the other options … ===8< There is a bug here no matter what, because the man page does not disclose the narrow scope by which --no-all-versions applies. It took trial and error with several apt-cache commands before it became evident that it only works on the “apt-cache show” command. The show command does not give the information needed. That is, it does not indicate the location where the candidate version will be sourced from. My workaround hackery is this: $ while read -d ' ' pkg; do apt-cache policy -o APT::Cache::AllNames=false "${pkg%%{*}"; done <\ <(yes | aptitude install $some_pkg --simulate | sed -ne '/^ /p') | sed -ne '/^[a-z]/Ip;/Version.table/{N;N;p}' Note that “-o APT::Cache::AllNames=false” is used in vain (it has no effect but at least it does not interfere either). The work of suppressing the non-candidate noise is done by the last sed command. It would be nice if I could also get a total size on any files to be fetched. My knee-jerk thought would be to filter on all packages that are not sourced from file:/local/filesystem, run apt-cache on that subset to get full URLs, then do something like: apt-cache show "$pkg" | awk '/^Size/{print $2}' Anyway, the low-effort fix would be to at least update the man page to state the narrow availability of --no-all-versions. Though it would be useful if it worked for policy. In light of my use case, you could also say it’s already hacking territory that apt-cache was needed at all. In principle, aptitude’s installer output of how much data will be fetched should give a breakdown of data volume to be fetched from each source location, perhaps when run in a verbose mode. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages apt depends on: ii adduser 3.134 ii debian-archive-keyring 2023.3+deb12u1 ii gpgv2.2.40-1.1 ii libapt-pkg6.0 2.6.1 ii libc6 2.36-9+deb12u6 ii libgcc-s1 12.2.0-14 ii libgnutls30 3.7.9-2+deb12u2 ii libseccomp2 2.5.4-1+b3 ii libstdc++6 12.2.0-14 ii libsystemd0 252.22-1~deb12u1 Versions of packages apt recommends: ii ca-certificates 20230311 Versions of packages apt suggests: pn apt-doc ii aptitude0.8.13-5 ii dpkg-dev1.21.22 ii gnupg 2.2.40-1.1 ii powermgmt-base 1.37 -- no debconf information
Bug#1070206: python3-pip: The options --log and --log-file have no effect on the install command
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_install_"$(date +%F)".err --log "$log_dir"/pip-argostranslate_install_"$(date +%F)".log -e . ===8< The operation failed about 150 megs into the download and dumped a stack trace to the terminal. The "$log_dir" contained no log files. I also used a similar command on Bullseye likely version 20.3.4-4+deb11u1 of python3-pip, without using a venv. The operation succeeded, but the logfile was not produced. I cannot say that with certainty though. My notes indicate that I used the --log* options, but today the old log files are not there; and nor are the new ones. I doubt I would have deleted the old logs, but it’s remotely possible. In any case, certainly the bug is present in today’s version. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-pip depends on: ii ca-certificates 20230311 ii python3 3.11.2-1+b1 ii python3-distutils 3.11.2-3 ii python3-setuptools 66.1.1-1 ii python3-wheel 0.38.4-2 Versions of packages python3-pip recommends: ii build-essential 12.9 ii python3-dev 3.11.2-1+b1 python3-pip suggests no packages. -- no debconf information
Bug#1070203: python3-pip: app silently lost in upgrade to Bookworm + pip3 lost track of the status (4 bugs)
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/pip3-argostranslategui.err --log $logs_dir/pip3-argostranslategui.log --cache-dir /usr/local/tarballs argostranslategui $ torsocks argospm install translate-${lang1}_$lang2 ===8< It ran fine. Then an update to the latest Bullseye point release was performed, followed immediately with an “aptitude full-upgrade”. A full log of the upgrade was not kept, but I did note this conflict: ===8< python3-virtualenv : Depends: python3-pip-whl but it is not going to be installed Depends: python3-setuptools-whl but it is not going to be installed ===8< It’s probably irrelevant because aptitude’s resolution resulted in a functioning python/pip - but worth mentioning in case it matters. An attempt to execute the app after the upgrade to Bookworm went like this: ===8< $ /usr/local/bin/argos-translate -v Traceback (most recent call last): File "/usr/local/bin/argos-translate", line 3, in from argostranslate import cli ModuleNotFoundError: No module named 'argostranslate' $ pip3 list | grep -i argo (no output) $ pip list | grep -i argo (no output) ===8< It’s also a bug for pip3 to have lost track of the fact that it managed the app. Running “pip3 list” should reveal the existence of the app. I’m told it would have been wise to have installed the app in a virtual environment not in the system (likely accurate). But nonetheless a needed app module should never be silently dropped without informing the user in the very least. If a needed module needed to be scrapped for some reason, ideally a signal would be sent to the apt procedure to block the upgrade and inform the user of steps needed. Recapping, I see four bugs: ① (upstream) an app module was dropped/lost ② (upstream) the user was not informed about the loss ③ (debian) the anomaly failed to block aptitude from moving forward ④ (upstream) pip3 lost track of the fact it was managing the app I did not apply the upstream tag because bug 3 above is debian related. But this report should probably be seen by upstream devs as well. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-pip depends on: ii ca-certificates 20230311 ii python3 3.11.2-1+b1 ii python3-distutils 3.11.2-3 ii python3-setuptools 66.1.1-1 ii python3-wheel 0.38.4-2 Versions of packages python3-pip recommends: ii build-essential 12.9 ii python3-dev 3.11.2-1+b1 python3-pip suggests no packages. -- no debconf information
Bug#1070146: aria2: The -o option could offer a substitution pattern for the original basename
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 directory given in --dir option. When the --force-sequential option is used, this option is ignored. NOTE: You cannot specify a file name for Metalink or BitTorrent downloads. The file name specified here is only used when the URIs fed to aria2 are given on the command line directly, but not when using --input-file, --force-sequential op‐ tion. Example: $ aria2c -o myfile.zip "http://mirror1/file.zip"; "http://mirror2/file.zip"; ===8< There is an ambiguity in the first sentence: “The file name of the downloaded file.” It’s unclear from that phrasing if the parameter will be taken as the name of the source file or the a potentially new name. The example disambiguates it but it would be better if the wording were more clear to begin with so readers are not confused until they study the example. Simply changing it to: “The name to give the downloaded file” would make a difference. I also suggest introducing a pattern substitution mechanism. It’s very common to want to preserve the original filename but add something to the name to clarify what it is. For example, consider this file: http://download.virtualbox.org/virtualbox/UserManual.pdf It’s contextually clear from the source path that it’s a user manual for vbox. But we typically do not want to preserve the original path. A good filename to produce would be: virtualbox_UserManual.pdf But if there are a lot of files it’s tedious to copy-paste and error prone to retype them. If a token like “%o” were designated to hold the original basename, a user could simply write: -o virtualbox_%o. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages aria2 depends on: ii libaria2-0 1.36.0-1 ii libc6 2.36-9+deb12u6 ii libgcc-s1 12.2.0-14 ii libstdc++6 12.2.0-14 Versions of packages aria2 recommends: ii ca-certificates 20230311 aria2 suggests no packages. -- no debconf information
Bug#1070028: aptitude: Extremely alarming warning when pkgs for a foreign architecture will be removed (2 or 3 bugs)
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 shows an upgrade from Bullseye to Bookworm. ===8< $ aptitude full-upgrade --show-resolver-actions The following NEW packages will be installed: … The following packages will be REMOVED: … The following packages will be upgraded: … The following packages are RECOMMENDED but will NOT be installed: e2fsprogs-l10n exfatprogs laptop-detect libatm1 libnss-systemd libpam-cap os-prober thin-provisioning-tools 2130 packages upgraded, 384 newly installed, 451 to remove and 0 not upgraded. Need to get 0 B/5,556 MB of archives. After unpacking 1,720 MB will be used. The following packages have unmet dependencies: virtualbox : Depends: python3 (< 3.10) but 3.11.2-1+b1 is to be installed asymptote : Depends: libgsl27 (>= 2.7.1) but it is not going to be installed python3-virtualenv : Depends: python3-pip-whl but it is not going to be installed Depends: python3-setuptools-whl but it is not going to be installed filezilla : Depends: libfilezilla34 (>= 0.41.0) but it is not going to be installed libsemanage1 : Depends: libsemanage-common (= 3.1-1) but 3.4-1 is to be installed The following actions will resolve these dependencies: Remove the following packages: 1) libsemanage1 [3.1-1+b2 (now)] 2) virtualbox [6.1.26-dfsg-3 (now)] 3) virtualbox-ext-pack [6.1.26-1 (now)] 4) virtualbox-qt [6.1.26-dfsg-3 (now)] Install the following packages: 5) libfilezilla-common [0.41.0-2 (stable)] 6) libfilezilla34 [0.41.0-2 (stable)] 7) libgsl27 [2.7.1+dfsg-5 (stable)] 8) python3-pip-whl [23.0.1+dfsg-1 (stable)] 9) python3-setuptools-whl [66.1.1-1 (stable)] Upgrade the following packages: 10) libgslcblas0 [2.6+dfsg-2 (now) -> 2.7.1+dfsg-5 (stable)] Leave the following dependencies unresolved: 11) virtualbox-dkms recommends virtualbox (>= 6.1.26-dfsg-3) 12) virtualbox-guest-additions-iso recommends virtualbox (>= 6.1.22) Accept this solution? [Y/n/q/?] y The following NEW packages will be installed: … The following packages will be REMOVED: … The following packages will be upgraded: … The following packages are RECOMMENDED but will NOT be installed: e2fsprogs-l10n exfatprogs laptop-detect libatm1 libnss-systemd libpam-cap os-prober thin-provisioning-tools 2130 packages upgraded, 389 newly installed, 464 to remove and 0 not upgraded. Need to get 0 B/5,560 MB of archives. After unpacking 1,526 MB will be used. Do you want to continue? [Y/n/?] y The following ESSENTIAL packages will be REMOVED! libcrypt1:i386 libgcc-s1:i386 WARNING: Performing this action will probably cause your system to break! Do NOT continue unless you know EXACTLY what you are doing! To continue, type the phrase "I am aware that this is a very bad idea": yikes! $ aptitude remove wine32:i386; # I would have liked to keep this to manage a Garmin satnav but it’s apparently causing the extreme messaging $ aptitude full-upgrade --show-resolver-actions … WARNING: Performing this action will probably cause your system to break! Do NOT continue unless you know EXACTLY what you are doing! To continue, type the phrase "I am aware that this is a very bad idea": wtf $ aptitude why libcrypt1:i386 i A libcrypt1:i386 Depends libc6:i386 (>= 2.25) i A libc6:i386 Depends libgcc-s1:i386 $ aptitude why libgcc-s1:i386 i libwine:i386 Depends libc6:i386 (>= 2.29) i A libc6:i386 Depends libgcc-s1:i386 $ aptitude why libwine:i386 Manually installed, current version 5.0.3-3, priority optional No dependencies require to install libwine:i386 $ aptitude remove libwine:i386 $ aptitude why libcrypt1:i386 Automatically installed, current version 1:4.4.18-4, priority optional No dependencies require to install libcrypt1:i386 $ aptitude why libc6:i386 Automatically installed, current version 2.31-13+deb11u8, priority optional No dependencies require to install libc6:i386 $ aptitude why zlib1g:i386 Automatically installed, current version 1:1.2.11.dfsg-2+deb11u2, priority required No dependencies require to install zlib1g:i386 $ aptitude why libgcc-s1:i386 Automatically installed, current version 10.2.1-6, priority optional No dependencies require to install libgcc-s1:i386 $ aptitude remove libcrypt1:i386 libc6:i386 zlib1g:i386 libgcc-s1:i386 The following packages will be REMOVED: libc6:i386 libcom-err2:i386{u} libcrypt1:i386 libgcc-s1:i386{u} libgssapi-krb5-2:i386{u} libidn2-0:i386{u} libk5crypto3:i386{u} libkeyutils1:i386{u} libkrb5-3:i386{u} libkrb5support0:i386{u} libnsl2:i386{u} libnss-nis:i386{u} libnss-nisplus:i386{u} libssl1.1:i386{u} libtirpc3:i386{u} libunistring2
Bug#987017: release-notes: Giving many ways to do something *is* useful
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 notes would be better. As an aptitude user, I was bothered by the lack of aptitude ways of doing things in the upgrade guide. I had to research and use guesswork to work out what is the aptitude-equivalent command, which complicated my effort. For the minimal system upgrade, users were directed to run “apt upgrade --without-new-pkgs”. I thought why is the aptitude approach missing? Is aptitude incapable of this? I then went to the man page and found “aptitude safe-upgrade”. I am still not sure if that is the equivalent command. And if so, is it exacly the same or are there differences? Whether someone wants to know a bit of many tools or be a master of few tools is a matter of preference, but the docs would ideally accommodate both kinds of users (though not necessarily in the same doc… that’s another matter - but if the different methods are side-by-side in the same doc it helps users learn about the equivalences and makes it easier for them to settle on a preferred method). But certainly it’s sensible to drop methods that have no advantage of any kind. The advice I was given early in my Debian years was that apt-get was a more primitive command and aptitude was more complete/comprehensive, that it logs or tracks more things and generally the better tool according to folks giving IRC support. I think aptitude calls apt IIRC, which makes it a higher level tool. > I am not sure we should tell people to "remove any non-Debian package" > before the upgrade. They might have legitimate reasons to have > third-party package repositories...? Concur. I’m not sure what the past release notes said, but the Bookworm release notes simply bluntly direct users to “Remove non-Debian packages”. This was frustrating for me. **Why?** I want to know why I am doing something. The list of non-Debian packages contained pkgs *I need*. Users need to know why they are directed to destroy something they need. Is there a real likeliness that a non-Debian pkg will make a mess or disaster of the upgrade? Or is this step a generic “we only officially support our officially distributed software” scenario? I decided to go against the guidance. There was one non-Debian pkg that I no longer used, so removal was a trivial choice for that one. But I left the other non-Debian pkgs alone. Some of them broke and some survived. The guide should probably suggest removing any non-Debian pkgs that are not needed to mitigate dependency complications, but simply warn that non-Debian pkgs allowed to persist might not run correctly and should be also treated with low priority if conflicts arise. @ Justin B Rye >> aptitude search '~o' > > This is nice and simple, but frankly as an aptitude user I wouldn't > bother. Instead I'd do what the text just above mentions - launch > aptitude, notice that there was a category for "Obsolete and Locally > Created Packages" If the guide is intended to help train the user and advance their Debian skills, then the CLI advice is probably favorable because it’s more likely to improve the user’s knowledge than a UI that needs no manual. If the guide is intended to just execute steps to do a job (git’r done), then the CLI is still the winner because it’s just one line for a user to copy-paste and get instant results with minimal text and minimal reading. Briefly mentioning the UI option probably doesn’t hurt though in addition to the CLI. >> apt-forktracer | sort > > I've never quite been able to understand how it is that anybody > could get themselves into the situation of *needing* this specialised > package installed to work around the weirdness of their setup, but > still need to be told what it is that's unusual about their system. > … >> In my personal documentation, I've settled on `apt-forktracer`, > > I'd be interested to know what you find it useful for. For me, apt-forktracer gives 1 pkg additional output: $ apt-forktracer | sort linux-image-5.10.0-16-amd64 (5.10.127-2) linux-image-5.10.0-19-amd64 (5.10.149-2) linux-image-5.10.0-6-amd64 (5.10.28-1) linux-image-5.10.0-7-amd64 (5.10.40-1) linux-image-5.10.0-8-amd64 (5.10.46-5) mastodon-archive (1.4.4-izzy1) openjdk-11-jre (11.0.23+9-1~deb11u1) [Debian: 11.0.22+7-1~deb11u1] openjdk-11-jre-headless (11.0.23+9-1~deb11u1) [Debian: 11.0.22+7-1~deb11u1] ungoogled-chromium (90.0.4430.212-1.sid1) ungoogled-chromium-common (90.0.4430.212-1.sid1) ungoogled-chromium-sandbox (90.0.4430.212-1.sid1) ungoogled-chromium-shell (90.0.4430.212-1.sid1) wire-desktop (3.35.3348-3348) xdiskusage (1.60-4~bpo12+1) [Debian Backports: 1.60-4~bpo12+1] [Debian: 1.48-10.1+b1] The “apt list '?narrow(?installed, ?not(?origin(Debian)))'” command excludes the last line (x
Bug#1069960: passwordsafe: (regression) pwsafe crashes after supplying master password
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< pwsafe: ./src/core/PWSfileV1V2.cpp:391: size_t PWSfileV1V2::ReadCBC(unsigned char&, StringX&): Assertion `wcLen != 0' failed. ===8< I was previously able to access my passwords with version 1.12.0+dfsg-1. So this is a regression. It’s worth noting that my DB file was originally created by Bruce Schneier’s “pwsafe” CLI tool. That package died for some reason and as a refugee I was forced to adopt this GUI “passwordsafe”, which was originally claimed to be compatible with Schneier’s CLI tool. However, it was only compatible in terms of *reading* the DB. Edits result in corruption (yikes!). So I was crippled with version 1.12.0+dfsg-1 but at least I could /read/ my DB. Of course this crash in version 1.16.0+dfsg-4 is a total show stopper. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages passwordsafe depends on: ii libc6 2.36-9+deb12u6 ii libgcc-s1 12.2.0-14 ii libmagic1 1:5.44-3 ii libqrencode4 4.1.1-1 ii libstdc++612.2.0-14 ii libuuid1 2.38.1-5+deb12u1 ii libwxbase3.0-0v5 3.0.5.1+dfsg-2 ii libwxgtk3.0-gtk3-0v5 3.0.5.1+dfsg-2 ii libx11-6 2:1.8.4-2+deb12u2 ii libxerces-c3.23.2.4+debian-1 ii libxtst6 2:1.2.3-1.1 ii libykpers-1-1 1.20.0-3 ii passwordsafe-common 1.16.0+dfsg-4 Versions of packages passwordsafe recommends: ii xvkbd 4.1-2 passwordsafe suggests no packages. -- no debconf information
Bug#1069957: postfix: false syslog_name (misinfo) in the logs
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 The logs are shown in bug report 1069949¹. This severely crippled troubleshooting efforts because it misleads testers about what actually executed. Notice in the logs of that bug report that a well-behaved smtp program correctly yielded the “postfix/smtptor” string. In the failure scenario, the string “postfix/smtp” was logged, falsely implying that the wrapper script was never called, yet it actually logged output from the wrapper script. This resulting deception led the bug chase down the wrong path. I suspect whatever code applies the custom syslog_name is running sequentially late and an initialised default value of “postfix/smtp” is used as a placeholder. A low-effort fix would be to change that initialisation to something that’s at least non-misleading, such as: * “postfix/TBD” * “postfix/smtpAppTBD” * “postfix/UNKNOWN” * “postfix/UNSET” * “postfix/UNSETsmtp” * “postfix/DEADBEEF” * “postfix/ifYouSeeThis,TellWietse” * “postfix/thisWillNeverHappen” * “postfix/youFoundAbug” Any of those as an initialisation default would at least avoid misinformation. Going the extra mile would be fixing whatever caused the logger to act before the custom syslog_name took effect. ¹ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069949 -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages postfix depends on: ii adduser3.134 ii cpio 2.13+dfsg-7.1 ii debconf [debconf-2.0] 1.5.82 ii dpkg 1.21.22 ii e2fsprogs 1.47.0-2 ii init-system-helpers1.65.2 ii libc6 2.36-9+deb12u6 ii libdb5.3 5.3.28+dfsg2-1 ii libicu72 72.1-3 ii libnsl21.3.0-2 ii libsasl2-2 2.1.28+dfsg-10 ii libssl33.0.11-1~deb12u2 ii netbase6.4 ii ssl-cert 1.1.2 Versions of packages postfix recommends: ii ca-certificates 20230311 ii python3 3.11.2-1+b1 Versions of packages postfix suggests: ii emacs-gtk [mail-reader]1:28.2+1-15 ii libsasl2-modules 2.1.28+dfsg-10 ii mailutils [mail-reader]1:3.15-4 ii neomutt [mail-reader] 20220429+dfsg1-4.1 pn postfix-cdb ii postfix-doc3.7.10-0+deb12u1 pn postfix-ldap pn postfix-lmdb pn postfix-mta-sts-resolver pn postfix-mysql ii postfix-pcre 3.7.10-0+deb12u1 pn postfix-pgsql pn postfix-sqlite ii procmail 3.22-27 ii systemd-resolved [resolvconf] 252.22-1~deb12u1 ii ufw0.36.2-1 -- Configuration Files: /etc/postfix/post-install changed [not included] /etc/postfix/postfix-files changed [not included] /etc/postfix/postfix-script [Errno 2] No such file or directory: '/etc/postfix/postfix-script' -- debconf information excluded
Bug#1069956: postfix: logs flooded as Postfix rapidly reattempts smtp too frequently (240 times per second)
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://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069949 An smtp wrapper script was created which was impacted by a Postfix-unrelated defect. The defect caused an instant failure of the smtp call. The wrapper script logged its own actions in a separate file. Each line of the wrapper script log began with a timestamp like this: 2024-04-27T13:10:30 That exact same timestamp appeared on ~1200 lines in the log file before advancing to the next second. Each execution yields five lines, so the smpt program was apparently called ~240 times per second on very old hardware. A modern machine would have run many times more; probably thousands of times per second. Strangely, /var/log/mail.log only showed output that was timestamped once per second. That is still excessive, but it also raises the question: why is there just 1 line in /var/log/mail.log for every 240 smtp executions? Is result output being lost, or is the logger doing something extra smart and saying “the hundreds of reattempts in the past second all have the same error output, thus we only need to print it once per second”? Either way, this could use improvement. Retrying outbound smtp 240 times per second is crazy. Some tuning parameters are provided¹ but they seem to miss this egress smtp scenario. Ideally the frequency of attempts should be non-linear. A sensible schedule would be something like this: 1st second: 2 attempts 2nd second: 1 attempt 3rd second: 1 attempt 4th second: 0 attempts 5th second: 1 attempt 10th second: 1 attempt Then try once again 20 seconds later, etc, until perhaps going linear on a once per 10 min basis. Assuming the Postfix logger is cleverly consolidating repetitious error messages, that’s great! But it should not conceal the count from the user. This line: 2024-04-25T13:10:28.533021+02:00 MannysHost postfix/smtp[*]: fatal: socket: Function not implemented would be written better as: 2024-04-25T13:10:28.533021+02:00 MannysHost postfix/smtp[*] (240 identical output instances) → fatal: socket: Function not implemented There is also some confusion by the way the docs are written. The section title “Slowing down SMTP clients that make many errors” is ambiguous and implies the case above (the need to control egress SMTP client transmissions). But it’s actually talking about a control on the smtpd server to limit *ingress* traffic from external SMTP clients. ¹ file:///usr/share/doc/postfix/html/TUNING_README.html#slowdown -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages postfix depends on: ii adduser3.134 ii cpio 2.13+dfsg-7.1 ii debconf [debconf-2.0] 1.5.82 ii dpkg 1.21.22 ii e2fsprogs 1.47.0-2 ii init-system-helpers1.65.2 ii libc6 2.36-9+deb12u6 ii libdb5.3 5.3.28+dfsg2-1 ii libicu72 72.1-3 ii libnsl21.3.0-2 ii libsasl2-2 2.1.28+dfsg-10 ii libssl33.0.11-1~deb12u2 ii netbase6.4 ii ssl-cert 1.1.2 Versions of packages postfix recommends: ii ca-certificates 20230311 ii python3 3.11.2-1+b1 Versions of packages postfix suggests: ii emacs-gtk [mail-reader]1:28.2+1-15 ii libsasl2-modules 2.1.28+dfsg-10 ii mailutils [mail-reader]1:3.15-4 ii neomutt [mail-reader] 20220429+dfsg1-4.1 pn postfix-cdb ii postfix-doc3.7.10-0+deb12u1 pn postfix-ldap pn postfix-lmdb pn postfix-mta-sts-resolver pn postfix-mysql ii postfix-pcre 3.7.10-0+deb12u1 pn postfix-pgsql pn postfix-sqlite ii procmail 3.22-27 ii systemd-resolved [resolvconf] 252.22-1~deb12u1 ii ufw0.36.2-1 -- Configuration Files: /etc/postfix/post-install changed [not included] /etc/postfix/postfix-files changed [not included] /etc/postfix/postfix-script [Errno 2] No such file or directory: '/etc/postfix/postfix-script' -- debconf information: postfix/mydomain_warning: postfix/recipient_delim: + postfix/mail
Bug#1069949: (regression) fatal: socket: Function not implemented
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< 2024-04-25T13:10:25.165542+02:00 MannysHost postfix/smtpd[*]: connect from localhost[127.0.0.1] 2024-04-25T13:10:25.186729+02:00 MannysHost postfix/smtpd[*]: 2D6EFE313A: client=localhost[127.0.0.1] 2024-04-25T13:10:25.232021+02:00 MannysHost postfix/cleanup[*]: 2D6EFE313A: message-id= 2024-04-25T13:10:25.236765+02:00 MannysHost postfix/qmgr[*]: 2D6EFE313A: from=, size=1181, nrcpt=1 (queue active) 2024-04-25T13:10:25.236875+02:00 MannysHost postfix/smtpd[*]: disconnect from localhost[127.0.0.1] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5 2024-04-25T13:10:25.298945+02:00 MannysHost postfix/smtp[*]: fatal: socket: Function not implemented 2024-04-25T13:10:26.357045+02:00 MannysHost postfix/smtp[*]: fatal: socket: Function not implemented 2024-04-25T13:10:27.444922+02:00 MannysHost postfix/smtp[*]: fatal: socket: Function not implemented 2024-04-25T13:10:28.533021+02:00 MannysHost postfix/smtp[*]: fatal: socket: Function not implemented 2024-04-25T13:10:29.636915+02:00 MannysHost postfix/smtp[*]: fatal: socket: Function not implemented 2024-04-25T13:10:30.694143+02:00 MannysHost postfix/smtp[*]: fatal: socket: Function not implemented 2024-04-25T13:10:31.808365+02:00 MannysHost postfix/smtp[*]: fatal: socket: Function not implemented 2024-04-25T13:10:32.921259+02:00 MannysHost postfix/smtp[*]: fatal: socket: Function not implemented 2024-04-25T13:10:34.026594+02:00 MannysHost postfix/smtp[*]: fatal: socket: Function not implemented 2024-04-25T13:10:35.140735+02:00 MannysHost postfix/smtp[*]: fatal: socket: Function not implemented 2024-04-25T13:10:36.234895+02:00 MannysHost postfix/smtp[*]: fatal: socket: Function not implemented 2024-04-25T13:10:37.352079+02:00 MannysHost postfix/smtp[*]: fatal: socket: Function not implemented 2024-04-25T13:10:38.440755+02:00 MannysHost postfix/smtp[*]: fatal: socket: Function not implemented 2024-04-25T13:10:39.549476+02:00 MannysHost postfix/smtp[*]: fatal: socket: Function not implemented … ===8< This is what the log looked like in Bullseye just before the upgrade, when sending over Tor still worked correctly: (/var/log/mail.log) ===8< Apr 24 09:37:17 MannysHost postfix/postfix-script[2130]: refreshing the Postfix mail system Apr 24 09:37:17 MannysHost postfix/master[1026]: reload -- version 3.5.24, configuration /etc/postfix Apr 24 09:37:17 MannysHost postfix/postfix-script[2168]: refreshing the Postfix mail system Apr 24 09:37:17 MannysHost postfix/master[1026]: reload -- version 3.5.24, configuration /etc/postfix Apr 24 12:32:42 MannysHost postfix/submission/smtpd[27946]: connect from localhost[127.0.0.1] Apr 24 12:32:42 MannysHost postfix/submission/smtpd[27946]: 3C344E3262: client=localhost[127.0.0.1] Apr 24 12:32:42 MannysHost postfix/submission/cleanup/cleanup[27949]: 3C344E3262: message-id= Apr 24 12:32:42 MannysHost postfix/submission/smtpd[27946]: disconnect from localhost[127.0.0.1] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5 Apr 24 12:32:42 MannysHost postfix/qmgr[2173]: 3C344E3262: from=, size=1126, nrcpt=1 (queue active) Apr 24 12:32:50 MannysHost postfix/smtptor/smtp[27956]: 3C344E3262: to=, relay=recipient.mx.server[1.2.3.4]:587, delay=8.1, delays=0.07/0.13/5.8/2.1, dsn=2.0.0, status=sent (250 OK id=yadayada) ===8< Sending over clearnet has no issues in any version. It’s only when a message must go over the Tor network that there is a problem. The configuration consists of the following: (/etc/postfix/master.cf) ===8< # The syslog_name option is not needed. It can be set to # anything. It’s just to add distinction in mail.log between clearnet # and Tor mail (otherwise both kinds of transmission are prefixed as # “postfix/smtp”). # smtptor unix - - n - - smtp_tor -o smtp_address_preference=ipv4 -o smtp_dns_support_level=disabled -o smtp_tls_security_level=none -o debug_peer_level=2 -o syslog_name=postfix/smtptor ===8< (/usr/lib/postfix/sbin/smtp_tor) ===8< !/bin/bash typeset -r dir_cmd=$(/usr/sbin/postconf -h command_directory) typeset -r exec_smtp=$("$dir_cmd"/postconf -h daemon_directory)/smtp setx_output() { if [[ $1 ]]; then exec 4>>"$1" BASH_XTRACEFD=4 PS4='\D{+%F}T\t $LINENO: ' set -x else set +x #BASH_XTRACEFD=2 exec 4>&- fi } setx_output /var/log/mail_${0##*/}.log torsocks "$exec_smtp" "$@" setx_output ===8< To setup routing,
Bug#1069758: sorry for the duplicate!
> 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 it so fast that when I did a search today to see if the report was filed, it was already resolved.
Bug#1069758: www.debian.org: upgrade procedure instructs users to run “apt update” but neglects upgrading
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-upgrading.en.html#upgrade-to-latest-point-release When following that link, the article says to do an “apt update” then neglects to tell users to perform the upgrade.
Bug#1069417: www.debian.org: upgrade procedure instructs users to run “apt update” but neglects upgrading
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-upgrading.en.html#upgrade-to-latest-point-release When following that link, the article says to do an “apt update” then neglects to tell users to perform the upgrade.
Bug#1068257: urlscan: Related security project → email-untracker
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 regular expressions known to email-untracker, according to the docs: https://bengtan.com/blog/email-cleaner-clean-tracking-links-and-pixels/#how-it-works But it would be interesting if urlscan would source the regular expressions from the email-untracker project and disclose matches to users in a more overt way. There could be a “known trackers found” list in the output of urlscan, and a list of IMG URLs for users to manually evaluate. -- System Information: Debian Release: 11.5 APT prefers oldstable-updates APT policy: (990, 'oldstable-updates'), (990, 'oldstable-security'), (990, 'testing'), (990, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages urlscan depends on: ii python33.9.2-3 ii python3-urwid 2.1.2-1 Versions of packages urlscan recommends: ii libcanberra-gtk3-module 0.30-7 Versions of packages urlscan suggests: ii elinks [www-browser] 0.13.2-1+b1 ii firefox-esr [www-browser] 102.6.0esr-1~deb11u1 ii lynx [www-browser]2.9.0dev.6-3~deb11u1 ii neomutt 20201127+dfsg.1-1.2 ii ungoogled-chromium [www-browser] 90.0.4430.212-1.sid1 ii w3m [www-browser] 0.5.3+git20210102-6 -- no debconf information
Bug#1068257: urlscan: (security) extract IMG URLs so users can see tracker pixels
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 that users might want to visit 2) IMG URLs. This list can be useful in two ways: * Someone might want to view or fetch an image (though unlikely; they can always render the message in a GUI browser for that) * To view all possible urls that could be a tracker pixel. Tracker pixels cannot easily be detected programatically, so the URLs need to be presented in a way that makes it easy for a human to detect it manually. It might also be useful for a user to have the option of tagging an URL they determine to be a tracker pixel which could then be added to a database of known tracker pixel URLs. Senders tend to make tracker pixels unique per recipient, not per message. So when another message from the same sender is fed to urlscan, it could recognize already identified tracker pixels and highlight them in some way. And more usefully, the DB could be queried by the MUA so tracked messages can be highlighted to users in the MUA. If this functionality is implemented, the developer should be mindful of embedded images. It’s possible for IMG tags to contain an embedded “URI image”, whereby a very long string in base64 encodes an image. Syntax is described here: https://www.thesitewizard.com/html-tutorial/embed-images-with-data-urls.shtml Such images are certainly not tracker pixels and should be ignored. Though URI images would probably be ignored naturally since they contain no URL anyway. FYI, this same request was be submitted to the urlview project: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068252 -- System Information: Debian Release: 11.5 APT prefers oldstable-updates APT policy: (990, 'oldstable-updates'), (990, 'oldstable-security'), (990, 'testing'), (990, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages urlscan depends on: ii python33.9.2-3 ii python3-urwid 2.1.2-1 Versions of packages urlscan recommends: ii libcanberra-gtk3-module 0.30-7 Versions of packages urlscan suggests: ii elinks [www-browser] 0.13.2-1+b1 ii firefox-esr [www-browser] 102.6.0esr-1~deb11u1 ii lynx [www-browser]2.9.0dev.6-3~deb11u1 ii neomutt 20201127+dfsg.1-1.2 ii ungoogled-chromium [www-browser] 90.0.4430.212-1.sid1 ii w3m [www-browser] 0.5.3+git20210102-6 -- no debconf information
Bug#1068252: urlview: (security) extract IMG URLs so users can see tracker pixels
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 tags, but then urlview cannot be used simultaneously for what it was intended (to visit URLs). In principle there should ideally be two lists of URLs (thus two regular expressions): 1) URLs that users might want to visit 2) IMG URLs. This list can be useful in two ways: * Someone might want to view or fetch an image (though unlikely; they can always render the message in a GUI browser for that) * To view all possible urls that could be a tracker pixel. Tracker pixels cannot easily be detected programatically, so the URLs need to be presented in a way that makes it easy for a human to detect it manually. It might also be useful for a user to have the option of tagging an URL they determine to be a tracker pixel which could then be added to a database of known tracker pixel URLs. Senders tend to make tracker pixels unique per recipient, not per message. So when another message from the same sender is fed to urlview, it could recognize already identified tracker pixels and highlight them in some way. And more usefully, the DB could be queried by the MUA so tracked messages can be highlighted to users in the MUA. If this functionality is implemented, the developer should be mindful of embedded images. It’s possible for IMG tags to contain an embedded “URI image”, whereby a very long string in base64 encodes an image. Syntax is described here: https://www.thesitewizard.com/html-tutorial/embed-images-with-data-urls.shtml Such images are certainly not tracker pixels and should be ignored. Though such images would probably be ignored naturally since they contain no URL anyway. FYI, this same request will be submitted to the urlscan project. -- System Information: Debian Release: 11.5 APT prefers oldstable-updates APT policy: (990, 'oldstable-updates'), (990, 'oldstable-security'), (990, 'testing'), (990, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages urlview depends on: ii libc6 2.31-13+deb11u5 ii libncurses6 6.2+20201114-2 ii libtinfo6 6.2+20201114-2 ii sensible-utils 0.0.14 Versions of packages urlview recommends: ii elinks [www-browser] 0.13.2-1+b1 ii firefox-esr [www-browser] 102.6.0esr-1~deb11u1 ii lynx [www-browser]2.9.0dev.6-3~deb11u1 ii ungoogled-chromium [www-browser] 90.0.4430.212-1.sid1 ii w3m [www-browser] 0.5.3+git20210102-6 Versions of packages urlview suggests: pn mutt pn ncftp | lftp ii wget 1.21-1+deb11u1 -- no debconf information
Bug#1067642: firefox-esr: The script for Debian’s reportbug hangs if torsocks is in play
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" firefox-esr This gets printed to the terminal: ===8< Gathering additional data, this may take a while... ===8< Then it goes to lunch indefinitely. I had to kill a process that resembled this: firefox-esr -dump-addons-info "$tmpfile" When I manually run this: firefox-esr -dump-addons-info "$(mktemp)" it completes quickly enough. But if I prefix torsocks like this: torsocks firefox-esr -dump-addons-info "$(mktemp)" then it just hangs. This is the script that needs to be made robust for running inside a torified network space: /usr/share/bug/firefox-esr/script -- System Information: Debian Release: 11.5 APT prefers oldstable-updates APT policy: (990, 'oldstable-updates'), (990, 'oldstable-security'), (990, 'testing'), (990, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages firefox-esr depends on: ii debianutils 4.11.2 ii fontconfig 2.13.1-4.2 ii libasound2 1.2.4-1.1 ii libatk1.0-0 2.36.0-2 ii libc62.31-13+deb11u5 ii libcairo-gobject21.16.0-5 ii libcairo21.16.0-5 ii libdbus-1-3 1.12.24-0+deb11u1 ii libdbus-glib-1-2 0.110-6 ii libevent-2.1-7 2.1.12-stable-1 ii libffi7 3.3-6 ii libfontconfig1 2.13.1-4.2 ii libfreetype6 2.10.4+dfsg-1+deb11u1 ii libgcc-s110.2.1-6 ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1+deb11u1 ii libglib2.0-0 2.66.8-1 ii libgtk-3-0 3.24.24-4+deb11u2 ii libpango-1.0-0 1.46.2-3 ii libstdc++6 10.2.1-6 ii libvpx6 1.9.0-1 ii libx11-6 2:1.7.2-1 ii libx11-xcb1 2:1.7.2-1 ii libxcb-shm0 1.14-3 ii libxcb1 1.14-3 ii libxcomposite1 1:0.4.5-1 ii libxdamage1 1:1.1.5-2 ii libxext6 2:1.3.3-1.1 ii libxfixes3 1:5.0.3-2 ii libxrandr2 2:1.5.1-1 ii libxtst6 2:1.2.3-1 ii procps 2:3.3.17-5 ii zlib1g 1:1.2.11.dfsg-2+deb11u2 Versions of packages firefox-esr recommends: ii libavcodec58 7:4.3.5-0+deb11u1 Versions of packages firefox-esr suggests: ii fonts-lmodern 2.004.5-6.1 ii fonts-stix [otf-stix] 1.1.1-4.1 ii libcanberra0 0.30-7 ii libgssapi-krb5-2 1.18.3-6+deb11u3 ii pulseaudio 14.2-2 -- no debconf information
Bug#1067640: firefox-esr: PDF.js does not render annotations
Package: firefox-esr Version: 102.6.0esr-1~deb11u1 Severity: normal Tags: upstream X-Debbugs-Cc: debbug.firefox-...@sideload.33mail.com forwarded -1 https://bugzilla.mozilla.org/show_bug.cgi?id=1797614 It was already reported upstream a year ago. -- System Information: Debian Release: 11.5 APT prefers oldstable-updates APT policy: (990, 'oldstable-updates'), (990, 'oldstable-security'), (990, 'testing'), (990, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages firefox-esr depends on: ii debianutils 4.11.2 ii fontconfig 2.13.1-4.2 ii libasound2 1.2.4-1.1 ii libatk1.0-0 2.36.0-2 ii libc62.31-13+deb11u5 ii libcairo-gobject21.16.0-5 ii libcairo21.16.0-5 ii libdbus-1-3 1.12.24-0+deb11u1 ii libdbus-glib-1-2 0.110-6 ii libevent-2.1-7 2.1.12-stable-1 ii libffi7 3.3-6 ii libfontconfig1 2.13.1-4.2 ii libfreetype6 2.10.4+dfsg-1+deb11u1 ii libgcc-s110.2.1-6 ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1+deb11u1 ii libglib2.0-0 2.66.8-1 ii libgtk-3-0 3.24.24-4+deb11u2 ii libpango-1.0-0 1.46.2-3 ii libstdc++6 10.2.1-6 ii libvpx6 1.9.0-1 ii libx11-6 2:1.7.2-1 ii libx11-xcb1 2:1.7.2-1 ii libxcb-shm0 1.14-3 ii libxcb1 1.14-3 ii libxcomposite1 1:0.4.5-1 ii libxdamage1 1:1.1.5-2 ii libxext6 2:1.3.3-1.1 ii libxfixes3 1:5.0.3-2 ii libxrandr2 2:1.5.1-1 ii libxtst6 2:1.2.3-1 ii procps 2:3.3.17-5 ii zlib1g 1:1.2.11.dfsg-2+deb11u2 Versions of packages firefox-esr recommends: ii libavcodec58 7:4.3.5-0+deb11u1 Versions of packages firefox-esr suggests: ii fonts-lmodern 2.004.5-6.1 ii fonts-stix [otf-stix] 1.1.1-4.1 ii libcanberra0 0.30-7 ii libgssapi-krb5-2 1.18.3-6+deb11u3 ii pulseaudio 14.2-2 -- no debconf information
Bug#1067614: texlive-latex-extra: pdfcomment docs reference the cloud instead of local files; also font option broken
Package: texlive-latex-extra Version: 2020.20210202-3 Severity: normal X-Debbugs-Cc: debbug.texlive-latex-ex...@sideload.33mail.com There is a Debian-specific bug in the manual located here: /usr/share/doc/texlive-doc/latex/pdfcomment/pdfcomment.pdf Page 7 links to example.pdf here: http://mirror.ctan.org/macros/latex/contrib/pdfcomment/doc/example.pdf It references the cloud location when in fact there is a local copy of example.pdf in the same directory as the manual itself. This occurs in a few other places in the manual, such as page 12. The links should reference the local file so there is no network dependency. Anything can go wrong with links into the cloud, such as websites joining Cloudflare (which then denies access to several demographics of people). Apart from that minor issue, there’s a bigger problem upstream. The “font” option is somewhat broken. Use of the font option produces documents that only render correctly in Adobe Acrobat. Bug 1067612 gives more detail, sample code, and sample output: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067612 Poppler is apparently dropping the ball on fonts, even the so-called 14 standard fonts that the manual claims are safe. The manual needs to go further to clarify and warn. I wasted a lot of time trying to figure out why even the most mainstream fonts were not rendering before someone told me to try Acrobat. There is very likely a defect in pdfcomment that cause a giant arrow to appear in the middle of every page where \pdffreetextcomment is used. It’s apparent in the attachments to bug 1067612: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1067612;filename=example_Acro.djvu;msg=5 https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=1067612;filename=annotation_font_samples_Acro.djvu;msg=5 It’s also worth noting that the default font isn’t good for the annotation purpose. An uppercase “I” is just a vertical bar which is indistinguishable from a digit 1 or lowercase “l”. It’s not a good default to be trapped with for annotations where you do not generally have much text to infer context. E.g. if a lawyer wants to label something “Exhibit I” there can be confusion.. is that Exhibit 1 or Exhibit “l”? There is a problem when pdfcomment is imported before the datetime2 package. This causes an option clash error: \usepackage{pdfcomment} \usepackage[calc,useregional]{datetime2} But if that sequence is reversed, there is no error. I’m not sure if that’s something that needs to be fixed in the code, but if not then I suggest noting the idiosyncracy in the manual because it can be tricky for users to sort out the problem. I tried to report the upstream-specific bugs upstream. It was a disaster. Hence why this bug report herein is a blend of upstream and downstream bugs. I followed this process in attempt to register on bitbucket: ① solved a CAPTCHA just to reach a reg. form (I have image loading disabled but the graphical CAPTCHA puzzle displayed anyway [Firefox bug?]) ② disposable email address rejected (so Bitbucket can protect themselves from spam but other people cannot?) ③ tried a forwarding acct instead of disposable (accepted) ③ another CAPTCHA emerged, this time Google reCAPTCHA. I never solve these because it violates so many digital right principles and I boycott Google. I made an exception for this experiment. The puzzle was empty because I disable images (can’t afford the bandwidth). Exceptionally, I enable images for this poorly designed website. I managed to solve enough of the ambiguous puzzles to get a pass. ④ got the green checkmark ✓ ⑤ clicked “sign up” ⑥ “We are having trouble verifying reCAPTCHA for this request. Please try again. If the problem persists, try another browser/device or reach out to Atlassian Support.” So Google profited from my labor in solving a reCAPTCHA then my access was refused by Bitbucket anyway. It’s worth noting that the Debian Social Contract (DSC) and Debian Free Software Guidelines (DFSG) condemn discrimination. Blind people cannot likely get passed all those CAPTCHAs to reach the upstream bug tracker. One might say the upstream bug tracker is not Debian’s problem. OTOH, the texlive package (understandably) steers people to file bugs upstream because this beast has the complexity of an OS in itself. But at the same time there’s an infrastructural problem when people are being directed into those shitty upstream walled gardens particularly when thy are discriminatory. I don’t have the answer -- just laying out the problem. It gets worse. So then (step ⑦) I attempted to e-mail the code author: ===8< status=bounced (host $authors_own_mx_svr said: 550-host $my_ip is listed at combined.mail.abusix.zone (127.0.0.11); 550 see https://lookup.abusix.com/search?q=$my_ip (in reply to RCPT TO command)) ===8< If only the Debian-specific bug is worked and the rest of this report is closed,
Bug#1067092: man-db: “man -K --regex” fails to match whole words in some cases
Package: man-db Version: 2.9.4-2 Severity: normal Tags: upstream X-Debbugs-Cc: debbug.man...@sideload.33mail.com Searching the whole DB for a whole word requires using --regex and then using word boundaries. So to find pages that reference the TZ environment variable, this *should* work (in principle): $ man -aK --regex '\' It appears to work because it finds many pages. But it misses the “tree” package (/usr/share/man/man1/tree.1.gz). $ zgrep 'TZ' /usr/share/man/man1/tree.1.gz \fBTZ\fPTimezone for timefmt output, see \fBstrftime\fP(3). As you can see, the nroff language intereferes with matching the regular expression as “TZ” is surrounded by code. Users of man-db obviously do not intend to have their regex matched against nroff code. Thus operations are being performed in the wrong order. The regular expression matching needs to happen on nroff-decoded text. $ zcat /usr/share/man/man1/tree.1.gz | nroff -man | grep '\' TZTimezone for timefmt output, see strftime(3). * Workaround * One approach: $ find /usr/share/man/ -iname \*gz -exec zcat {} + | nroff -man | grep '\<'"$whole_word"'\>' In rare situations such as environment variable searches, case sensitivity can be leveraged: $ man -aKI --regex TZ -- System Information: Debian Release: 11.5 APT prefers oldstable-updates APT policy: (990, 'oldstable-updates'), (990, 'oldstable-security'), (990, 'testing'), (990, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages man-db depends on: ii bsdextrautils 2.36.1-8+deb11u1 ii debconf [debconf-2.0] 1.5.77 ii dpkg 1.20.12 ii groff-base 1.22.4-6 ii libc6 2.31-13+deb11u5 ii libgdbm6 1.19-2 ii libpipeline1 1.5.3-1 ii libseccomp22.5.1-1+deb11u1 ii zlib1g 1:1.2.11.dfsg-2+deb11u2 man-db recommends no packages. Versions of packages man-db suggests: ii apparmor 2.13.6-10 ii elinks [www-browser] 0.13.2-1+b1 ii firefox-esr [www-browser] 102.6.0esr-1~deb11u1 pn groff ii less 551-2 ii lynx [www-browser]2.9.0dev.6-3~deb11u1 ii ungoogled-chromium [www-browser] 90.0.4430.212-1.sid1 ii w3m [www-browser] 0.5.3+git20210102-6 -- debconf information: man-db/install-setuid: false man-db/auto-update: true
Bug#729549: manwhatis QUERY_STRING parse error?
Package: man2html Version: 1.6g-6 I am unable to follow the section links in the localhost manual webpages via, e.g. '/cgi-bin/man/manwhatis?1'. I get a "no section number" error message. Testing by direct execution in the directory shows that (declare -x QUERY_STRING=1; ./manwhatis) results in the same error. './manwhatis 1' works correctly. And a 'test' script called via the same localhost web server with '?1' sees the correct value of QUERY_STRING. This is an essentially vanilla, up-to-date wheezy (kde) installation with lighttpd as the locahost web server. Best wishes, Manny -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#729548: man2html.swish++.index needs a+r permissions
Package: man2html Version: 1.6g-6 I tried to use the locahost cgi scripts through lighttpd to browse/read the manual pages. 'cgi-bin/man/mansearch?query=help' came up with no results. Applying chmod a+r /var/cache/man2html/man2html.swish++.index fixed this problem: The query came up with many results. Note: lighttpd runs as www-data. The original permissions on this file in /var/cache/man2html owned by root had no o+r permissions. The installation is close to vanilla wheezy (kde) and up-to-date. Best, Manny -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#698230: uninitialized variable causes firefox to crash when card is inserted into reader
Package: coolkey Version: 1.1.0-12 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu raring ubuntu-patch *** /tmp/tmpbG98u8/bug_body In Ubuntu, the attached patch was applied to achieve the following: * Fix Firefox crash due to "Assertion `mOldCAC' failed" error based on patch from www.spinics.net/linux/fedora/coolkey/msg00368.html Thanks for considering the patch. -- System Information: Debian Release: wheezy/sid APT prefers precise-updates APT policy: (500, 'precise-updates'), (500, 'precise-security'), (500, 'precise-proposed'), (500, 'precise'), (100, 'precise-backports') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-36-generic (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash === modified file 'debian/changelog' === added file 'debian/patches/99-fixmAsserterror.patch' --- debian/patches/99-fixmAsserterror.patch 1970-01-01 00:00:00 + +++ debian/patches/99-fixmAsserterror.patch 2013-01-15 15:34:29 + @@ -0,0 +1,16 @@ +## Description: add some description +## Origin/Author: add some origin or author +## Bug: bug URL +Index: coolkey/src/coolkey/slot.cpp +=== +--- coolkey.orig/src/coolkey/slot.cpp 2013-01-15 10:25:31.690342000 -0500 coolkey/src/coolkey/slot.cpp 2013-01-15 10:34:08.539195695 -0500 +@@ -2215,6 +2215,8 @@ + CKYBuffer_InitEmpty(&vBuf); + CKYBuffer_Resize(cert, 0); + ++*nextSize = 0; ++ + /* handle the new CAC card read */ + /* read the TLV */ + status = CACApplet_ReadFile(conn, CAC_TAG_FILE, &tBuf, NULL); === modified file 'debian/patches/series' --- debian/patches/series 2012-04-11 20:56:20 + +++ debian/patches/series 2013-01-15 15:32:25 + @@ -8,3 +8,4 @@ coolkey-cac-rhl5.patch 0001-Fix-working-with-empty-certificates-in-not-zero-slot.patch Handle-pcscd-restarting +99-fixmAsserterror.patch
Bug#558222: Imagej crashes with NullPointerException only java-gcj-compat is installed
Hi, I was worried that this might be a bug that only affected ubuntu so I checked if it would run in a squeeze chroot and I it also fails with the NullPointerException. The other thing is it is probably better for the binary to depend on default-jre instead of openjdk-6-jre as it has not been ported to all debian architectures. However you might still have a runtime error for the architectures that use gcj-jre as the default: [avr32, hppa, hurd-i386, kfreebsd-amd64, kfreebsd-i386, m68k]. On Fri, Nov 27, 2009 at 1:22 AM, Manny Vindiola wrote: > Package: imagej > Version: 1.43g-1 > Severity: important > Tags: patch > > When java-gcj-compat is the only java version installed on the system the > application will not run. It fails with message /usr/bin/imagej: line 420: > //bin/java: No such file or directory. This is because of the JAVA_HOME hack > introduced inversion 1.43b-1. > > When the correct path is specified it still will not run. It crashes with > error: > (lucid32)ma...@laptop:~/dev/submitted/imagej$ imagej > Open other images in this ImageJ panel as follows: > imagej -p 1 [ ... ] > > Exception in thread "main" java.lang.NullPointerException > at java.awt.Component.setDropTarget(libgcj.so.10) > at ij.plugin.DragAndDrop.run(DragAndDrop.java:28) > at ij.IJ.runPlugIn(IJ.java:152) > at ij.IJ.runPlugIn(IJ.java:135) > at ij.ImageJ.(ImageJ.java:184) > at ij.ImageJ.main(ImageJ.java:554) > > These errors can be corrected by depending on openjdk-6-jre and reverting the > JAVA_HOME hack to what it used to be. I have attached a patch to correct > these problems. > > > -- System Information: > Debian Release: squeeze/sid > APT prefers karmic-updates > APT policy: (500, 'karmic-updates'), (500, 'karmic-security'), (500, > 'karmic-proposed'), (500, 'karmic-backports'), (500, 'karmic') > Architecture: amd64 (x86_64) > > Kernel: Linux 2.6.31-15-generic (SMP w/2 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > > Versions of packages imagej depends on: > ii gcj-4.4-jre [java2-r 4.4.1-5ubuntu2 Java runtime environment using > GIJ > ii gcj-jre [java2-runti 4:4.4.1-1ubuntu2 Java runtime environment using > GIJ > ii openjdk-6-jre [java2 6b16-1.6.1-3ubuntu1 OpenJDK Java runtime, using > Hotspo > ii sun-java6-jre [java2 6-15-1 Sun Java(TM) Runtime Environment > ( > > imagej recommends no packages. > > Versions of packages imagej suggests: > ii gcj-4.4-jre-headless [j 4.4.1-5ubuntu2 Java runtime environment using > GIJ > ii gcj-jre-headless [java- 4:4.4.1-1ubuntu2 Java runtime environment using > GIJ > ii gij-4.3 [java-virtual-m 4.3.4-4ubuntu1 The GNU Java bytecode interpreter > ii sun-java6-jre [java-vir 6-15-1 Sun Java(TM) Runtime Environment > ( > > -- 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#558222: Imagej crashes with NullPointerException only java-gcj-compat is installed
Package: imagej Version: 1.43g-1 Severity: important Tags: patch When java-gcj-compat is the only java version installed on the system the application will not run. It fails with message /usr/bin/imagej: line 420: //bin/java: No such file or directory. This is because of the JAVA_HOME hack introduced inversion 1.43b-1. When the correct path is specified it still will not run. It crashes with error: (lucid32)ma...@laptop:~/dev/submitted/imagej$ imagej Open other images in this ImageJ panel as follows: imagej -p 1 [ ... ] Exception in thread "main" java.lang.NullPointerException at java.awt.Component.setDropTarget(libgcj.so.10) at ij.plugin.DragAndDrop.run(DragAndDrop.java:28) at ij.IJ.runPlugIn(IJ.java:152) at ij.IJ.runPlugIn(IJ.java:135) at ij.ImageJ.(ImageJ.java:184) at ij.ImageJ.main(ImageJ.java:554) These errors can be corrected by depending on openjdk-6-jre and reverting the JAVA_HOME hack to what it used to be. I have attached a patch to correct these problems. -- System Information: Debian Release: squeeze/sid APT prefers karmic-updates APT policy: (500, 'karmic-updates'), (500, 'karmic-security'), (500, 'karmic-proposed'), (500, 'karmic-backports'), (500, 'karmic') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31-15-generic (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages imagej depends on: ii gcj-4.4-jre [java2-r 4.4.1-5ubuntu2 Java runtime environment using GIJ ii gcj-jre [java2-runti 4:4.4.1-1ubuntu2Java runtime environment using GIJ ii openjdk-6-jre [java2 6b16-1.6.1-3ubuntu1 OpenJDK Java runtime, using Hotspo ii sun-java6-jre [java2 6-15-1 Sun Java(TM) Runtime Environment ( imagej recommends no packages. Versions of packages imagej suggests: ii gcj-4.4-jre-headless [j 4.4.1-5ubuntu2 Java runtime environment using GIJ ii gcj-jre-headless [java- 4:4.4.1-1ubuntu2 Java runtime environment using GIJ ii gij-4.3 [java-virtual-m 4.3.4-4ubuntu1 The GNU Java bytecode interpreter ii sun-java6-jre [java-vir 6-15-1 Sun Java(TM) Runtime Environment ( -- no debconf information diff -u imagej-1.43k/debian/control imagej-1.43k/debian/control --- imagej-1.43k/debian/control +++ imagej-1.43k/debian/control @@ -13,7 +13,7 @@ Package: imagej Architecture: all -Depends: ${java:Depends}, ${misc:Depends}, java-gcj-compat | java2-runtime, +Depends: ${java:Depends}, ${misc:Depends}, openjdk-6-jre | java2-runtime Suggests: java-virtual-machine Description: Image processing program inspired by NIH Image for the Macintosh It can display, edit, analyze, process, save and print 8-bit, 16-bit and diff -u imagej-1.43k/debian/imagej.sh imagej-1.43k/debian/imagej.sh --- imagej-1.43k/debian/imagej.sh +++ imagej-1.43k/debian/imagej.sh @@ -26,9 +26,7 @@ # DEFINE JAVA_HOME # if [ -z "$JAVA_HOME" ] ; then -# This does not work see #505315 -# JAVA_HOME=$(/usr/sbin/update-java-alternatives -l | head -1 | cut -d' ' -f 3) -JAVA_HOME=$(dirname $(dirname $(dirname $(readlink /etc/alternatives/java +JAVA_HOME=$(/usr/sbin/update-java-alternatives -l | head -1 | cut -d' ' -f 3) fi # CREATE THE RIGHT ENVIRONMENT #
Bug#509518: cups-pdf: does not reliably create pdf-queue
Package: cups-pdf Version: 2.4.8-4 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu intrepid ubuntu-patch We applied these changes in Ubuntu and thought you might consider doing the same: Sometime due to restart/configuration race condition the PDF-printer (queue) is not created We have modified the postinstall so that it no longer restarts cups and installs a pdf queue and printer. Patches are attached. *** /tmp/tmpowFKGE In Ubuntu, we've applied the attached patch to achieve the following: * Merge from debian unstable (LP: #310290), remaining changes: - debian/postinst, debian/prerm: Let PDF print queue being created automatically when installing the package and being removed automatically when uninstalling the package. - debian/postinst: Updated PPD file name to the new one used by the upstream package (LP: #241701). Updated the name of the CUPS startup script to "cups". We thought you might be interested in doing the same. -- System Information: Debian Release: lenny/sid APT prefers intrepid-updates APT policy: (500, 'intrepid-updates'), (500, 'intrepid-security'), (500, 'intrepid-backports'), (500, 'intrepid') Architecture: i386 (i686) Kernel: Linux 2.6.27-9-generic (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash diff -u cups-pdf-2.4.8/debian/changelog cups-pdf-2.4.8/debian/changelog diff -u cups-pdf-2.4.8/debian/postinst cups-pdf-2.4.8/debian/postinst --- cups-pdf-2.4.8/debian/postinst +++ cups-pdf-2.4.8/debian/postinst @@ -14,9 +14,81 @@ chown nobody:nogroup /var/spool/cups-pdf/ANONYMOUS chmod 1777 /var/spool/cups-pdf/ANONYMOUS chmod 0700 /usr/lib/cups/backend/cups-pdf + # This package needs the CUPS daemon running to actually work if [ -f /etc/init.d/cups ] then - invoke-rc.d cups force-reload || invoke-rc.d cups start || /bin/true + lpstat -r > /dev/null 2>&1 || invoke-rc.d cups start || /bin/true + fi + if lpstat -r > /dev/null 2>&1 + then + # Create a PDF CUPS queue if we have none yet (only + # if CUPS daemon is running) + if [ -z "`LC_ALL=C lpstat -v 2>/dev/null | grep 'cups-pdf:/'`" ] + then + # Find a name for the PDF queue + queue=PDF + number=0 + while LC_ALL=C lpstat -v 2>/dev/null | cut -d ':' -f 1 | cut -d ' ' -f 3 | grep -q ^$queue\$ + do + number=$(($number + 1)) + queue="PDF$number" + done + # Find system's default paper size + size="`LC_ALL=C paperconf 2>/dev/null`" || size=a4 + # Create the queue + lpadmin -h localhost -p $queue -E -v cups-pdf:/ -m lsb/usr/cups-pdf/CUPS-PDF.ppd -o printer-is-shared=no -o PageSize=$size 2>/dev/null || : + # Set the PDF printer as default when there is not + # already a default printer + #if [ -z "`LC_ALL=C lpstat -d 2>/dev/null | grep 'system default destination:'`" ] + #then + # lpadmin -d $queue 2>/dev/null || : + #fi + fi + else + # Create a PDF CUPS queue if we have none yet (for the + # case that CUPS is not running or even not installed) + if [ -z "`grep 'DeviceURI cups-pdf:/' /etc/cups/printers.conf 2> /dev/null`" ] + then + # Find a name for the PDF queue + queue=PDF + number=0 + while grep -q "Printer $queue>" /etc/cups/printers.conf + do + number=$(($number + 1)) + queue="PDF$number" + done + # Find system's default paper size + size="`LC_ALL=C paperconf 2>/dev/null`" || size=a4 + # Create the queue + time=`date +%s` + mkdir -p /etc/cups/ppd + cat << EOF >> /etc/cups/printers.conf + +Info Print into PDF file +DeviceURI cups-pdf:/ +State Idle +StateTime $time +Accepting Yes +Shared No +JobSheets none none +Qu
Bug#130309: acquiring a boner has never been easier, check out this
Good evening! Get ready for Christmas holidays with a new you http://dobongworld.com Keep, oh! keep your chairs and candle, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#149954: Treating your maiden as a goddess, become a God in her bedroom!
Hello Your holiday would be not full without gd se.>.< http://slipgrow.com Kerstin mcclafferty Was placed in a friendly Bark, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#130893: tipsSearch politik
MAC EXCLUSIVES MAP amp Hotspot NewsFile SearchRSS http://img444.imageshack.us/img444/2302/oho1ug4.gif Because incredibly flexible draw write hand Tablet -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#87665: she had
Padudi, weeks disgusting since got married kevin carrier, going. Links sites linking, clicks. Comment, at least, will die. Wish bad, luck racist holls, remember once watching guy. An, old version of. WE HELP THE WORLD MOVE! TRANSFORMING THE LIVES OF DEVELOPING NATIONS This is an amazing story. WE urge you to go read the news on this company and visit the website. The company website will be listed in news releases. Watch this company closely starting NOW! TRANSNATIONAL AUTOMOTIVE GROUP TAMG.OB Founded in 2005, TAMG Provides transportation systems and infrastructure to the developing world. Our bus fleets provide an efficient way for communities in need to travel and prosper. Affordable for riders, and economically sustainable for the company, TAMG has turned capital investments in the developing world into sustainable and profitable transportation solutions NEWS February 15, 2007 - Transnational Automotive Group Launches "LeCar" Inter-Urban Bus Operations between YaoundE and Douala, Cameroon *** December 18 , 2006 - After Le Bus, Here comes Le Car *** December 11 , 2006 - Transnational Automotive Announces $800,000 USD Investment by the Chamber of Commerce of Cameroon *** November 30, 2006 - Transnational Automotive Announces Purchase of 60 City Buses for its Urban Transportation Operation in Cameroon *** November 16, 2006 - Transnational Automotive Announces $800,000 USD Investment by the Chamber of Commerce of Cameroon Him xtina month just wanted say maybe better. Tiene ideas diferentes, tengo. Ni siquiera poda escuchar msica acausa del. Pero en fin cada kien tiene ideas diferentes tengo. Justin madona, only female performing. Realize could dangerous very crynez months bueno ya. Than christina honestly really. Pero en fin cada kien tiene ideas. Comment at least will die. Die within copy and paste. Who things, about decision. Now playing justinfrom mmc yechhfrom pig boyfrom mickey. Reply cookie, vieja culera comment at least will die. Hse, did concert, over, tehnext day reply cookie, vieja. See cityfrom ltlt now playing justinfrom mmc yechhfrom! To favorites, add groups. Her for that hey does. Favorited links sites linking clicks from infoclose. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]