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-0
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
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
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",
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
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:
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<
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
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
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}
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
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: +
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
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
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#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#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#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 man...@gmail.com 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 image1 [image2 ... imageN] 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.init(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 image1 [image2 ... imageN]
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.init(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 21 || invoke-rc.d cups start || /bin/true + fi + if lpstat -r /dev/null 21 + 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 +Printer $queue +Info Print into PDF file +DeviceURI cups-pdf:/ +State Idle +StateTime $time +Accepting Yes +Shared No +JobSheets none none +QuotaPeriod 0 +PageLimit
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]
