Bug#1070998: bookworm-pu: package fossil/2.24-5~deb11u1
Thanks! I guess preparing these is pretty straightforward. Would like to think my efforts to keep debian/rules etc clean and tidy made this work so easily. Given that the patch is nothing but a changelog entry, I'm assuming it's not really worth making a branch on fossil. " * Backport to bookworm (no changes required)"? Cheers, --Barak.
Bug#1070069: fossil: CVE-2024-24795 unreleated breakage
Well, it would certainly be simple enough: the source code should compile fine, and the debian/* scripts would need only the very most minor tweaks.
Bug#1070126: fossil: Do not use embded sqlite
The fossil upstream is also the sqlite3 upstream. They could not possibly be more familiar with sqlite3! When you ask fossil to build using an external (system) sqlite3 library, configuration-time checks are performed to see if the external sqlite3 is up to snuff. If not, either because it is too early a version or because it was compiled without some necessary functionality, it ignores your request and builds with the internal version anyway. Some time ago, not defining SQLITE_ENABLE_JSON1 was the deficiency with the Debian system sqlite3 that it noticed. Maybe it's something else now. Here's what the sources *say* it needs: $ ./configure --print-minimum-sqlite-version Host System...x86_64-pc-linux-gnu Build System...x86_64-pc-linux-gnu C compiler... cc -g -O2 C++ compiler... c++ -g -O2 Build C compiler...cc Checking for stdlib.h...ok 3.43.0 Here's what the autobuilder logs for fossil 2.24 say: dh_auto_configure -- --disable-option-checking \ --disable-internal-sqlite \ ... Checking for sqlite3_open in sqlite3...-lsqlite3 JSON support enabled TH1 embedded documentation support enabled TH1 hooks support enabled Checking libs for iconv...none needed ... Using sqlite3.c from this source tree. Why the fall back to the internal version? It doesn't say. Perhaps there is some bit rot because they may not exercise this option much. I will look into it. But in the meantime, getting it to build with the external sqlite3 might require surgery to disable fossil's configure-time sqlite3-check logic. I would be loath to do that, for obvious reasons. In the past, fossil upstream has sometimes put bleeding-edge sqlite3 versions into its internal version. Right now it's version 3.46.0, while Debian/sid is at 3.45.3. Sometimes they've accidentally used recent features without updating the version it asks for. I wouldn't feel comfortable overriding fossil's config-time checks without coordination with them on the issue.
Bug#1070069: fossil: CVE-2024-24795 unreleated breakage
I've uploaded a package with this fixed to unstable, 1:2.24-5, and it's been autobuilt and pushed out. Seems to work okay, and can be co-installed with apache2/sid. Just uploaded 1:2.24-6 that adds Breaks: apach2-bin per your recent message. Honestly, I'm not confident in my ability to properly back-port security-related patches to old versions of fossil. It's a big network-facing program with a large number of moving parts and a substantial attack surface, all written in C. It uses its own sqlite3 copy when the shared library in Debian isn't a high enough version or doesn't have the right options enabled (currently Debian sqlite3 is compiled without SQLITE_ENABLE_JSON1 so the internal version is used.) All this means it would be super easy for me to miss some issue and introduce a vulnerability if I try to back-port a security patch, particularly without myself deeply understanding the security issue. Stable has 1:2.21-1. I just made a debian-bookworm-proposed-updates branch rooted there and tried to cherry-pick the fix, https://fossil-scm.org/home/info/f4ffefe708793b03 but it does not apply cleanly. Obviously I can do it manually though, however there have been changes in the neighborhood. Also, are you *sure* I shouldn't also be applying https://fossil-scm.org/home/info/71919ad1b542832c to the fixed versions? Because I'm not! I'd be most comfortable if upstream simply made a proper release with this fixed (which I bet they'd do upon request), and I uploaded that with the appropriate "Breaks: apache2-bin (<<...)", and did the (trivial) backport of that package to bookworm and bullseye, with the "breaks:" modified to the appropriate version.
Bug#1070069: fossil: CVE-2024-24795 unreleated breakage
uploaded
Bug#1070069: fossil: CVE-2024-24795 unreleated breakage
will do
Bug#1070069: fossil: CVE-2024-24795 unreleated breakage
Bastien, Okay, got it. Thanks for letting me know. I can cherry-pick that fossil commit, but you know the right magic for a versioned apache2 breakage and how to deal with proposed-updates. So I think it would make sense for you to do all of this in a coordinated fashion? If that's okay with you, please feel free to just do a regular upload if you want, or an NMU, as you please. I will push your changes into the debian fossil branch, unless you'd like write access to my fossil packaging repo https://people.debian.org/~bap/fossil.fsl which I'd be happy to set up. Cheers, --Barak.
Bug#1068436: transmission RFS
Well, it's not a *violation* of the DFSG to include derived files in the upstream sources, as long as the source needed to regenerate them is also included. That's often done for bootstrapping compilers. Source tarballs also often include documentation PDFs and such so people installing the software can read the documentation without having to have that part of the build working. That said, since you've already done the work to get that stuff generated and debian-build time, I certainly have no objections to just doing that, and even removing them from the source tarball if you so desire. Can't believe I missed the debian/control broken lines. Thanks. Barring issues, will upload.
Bug#1068436: transmission RFS
Well, given that the main maintainer dropped themselves from the debian/control file, I think the package can be freely adopted, keeping Leo Antunes on of course in case he reappears. I'll drop the two of them a note asking for objections, and assuming there are none, I'd suggest we go ahead with that. What do you think? This would be: Maintainer: Leo Antunes Uploaders: Alexandre Rossi , Barak A. Pearlmutter and would allow "proper" uploads, not just NMUs. I merged your "fix build on bookworm" patch, but the package still builds fine on a chroot on my own machine, and fails to build on salsa, https://salsa.debian.org/bap/transmission/-/pipelines If you feel like preparing a serious 4.0.5-2 candidate with *everything* you think belongs included, rather than just a minimal NMU, that would be great! What I meant with the pre-built javascript business was that it's more robust to set things up so *if* the tools to do so are available, that stuff is rebuilt. But if not, e.g., if someone is building for a small platform or porting or just wants to build a local copy and doesn't want to install that stuff, it would use pre-built files instead. This also makes it easier for porters. This seems like pretty much what upstream advocates in web/README.md, except the idea is to automate it. With that stuff in place, it's a lot easier to argue that using the prebuilt files under some particular circumstance (like some package is missing from Debian for the moment) is not serious enough of an issue to delay progression to testing etc. And yes, your "proper" cmake-test-based -latomic fix is the "right" way to do it, unlike the sleazy hack I put in debian/rules. --Barak.
Bug#1068436: transmission RFS
I use transmission constantly and would be happy to sponsor. In principle of course: assuming there are no technical show-stoppers. I already have my own fork on salsa.debian.org/bap/transmission with some very minor tweaks. In the meantime, I note that Sandro Tosi has dropped his maintainership of the package, but pushed a debian/4.0.5-2 tag without uploading. Do you know the status of that? The two top bugs are a missing -latomic on ARM, which should be easy enough to work around in debian/rules using include /usr/share/dpkg/architecture.mk if ... and the prebuilt javascript business, which I note from MR/16 you've been working on. One suggestion I have for that is to set things up so that *if* the tools are available, the javascript can be rebuilt; but if not, pre-built versions are used anyway. This would make things robust, and would I think allow the bug to be downgraded. I'm also not thrilled with how the build process adds a git hook if it can. Should probably hot-wire that off, because it seems to present a potential security issue. Just a quilt patch to disable the entire if(GIT_FOUND) thing at the end of CMakeLists.txt seems about right. (The Source Control System is supposed to control the build, not vice versa!) Anyway, let me know if/when you want me to dput. Cheers, --Barak.
Bug#1062023: ddccontrol: NMU diff for 64-bit time_t transition
The libddccontrol library is, to my knowledge, only used by packages generated by the same source package, namely ddccontrol and gddccontrol. And time_t is only used internally, not exposed via the library's ABI. Under these circumstances, I don't think transitioning libddccontrol is, technically speaking, actually necessary. Cheers, --Barak. On Wed, 31 Jan 2024 at 00:09, wrote: > > Source: ddccontrol > Version: 1.0.1-1 > Severity: serious > Tags: patch pending > Justification: library ABI skew on upgrade > User: debian-...@lists.debian.org > Usertags: time-t > > Dear maintainer, > > As part of the 64-bit time_t transition required to support 32-bit > architectures in 2038 and beyond > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified > ddccontrol as a source package shipping runtime libraries whose ABI > either is affected by the change in size of time_t, or could not be > analyzed via abi-compliance-checker (and therefore to be on the safe > side we assume is affected). > > To ensure that inconsistent combinations of libraries with their > reverse-dependencies are never installed together, it is necessary to > have a library transition, which is most easily done by renaming the > runtime library package. > > Since turning on 64-bit time_t is being handled centrally through a change > to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is > important that libraries affected by this ABI change all be uploaded close > together in time. Therefore I have prepared a 0-day NMU for ddccontrol > which will initially be uploaded to experimental if possible, then to > unstable after packages have cleared binary NEW. > > Please find the patch for this NMU attached. > > If you have any concerns about this patch, please reach out ASAP. Although > this package will be uploaded to experimental immediately, there will be a > period of several days before we begin uploads to unstable; so if information > becomes available that your package should not be included in the transition, > there is time for us to amend the planned uploads. > > > > -- System Information: > Debian Release: trixie/sid > APT prefers unstable > APT policy: (500, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 6.5.0-15-generic (SMP w/16 CPU threads; PREEMPT) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_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)
Bug#888480: Still a Problem - Gets Worse
This is still a problem. And here's a scenario where it's worse! Which happened to me. User "helena" is marked admin. But has never logged in, so as yet has no password set. User "barak" is logged in, and wants to run synaptic. That user is set up to allow sudo with no password. But oops, synaptic wants him to fill in helena's password. Which does not exist. And the authentication dialog has grabbed everything: cannot exit or abort, cannot switch virtual consoles. Completely unresponsive. Only options are to hit the power button, or log in from another host via ssh and figure out which is the bad process and kill it. Neither of these are things we should require from a normal user.
Bug#1057140: libemf: FTBFS: error: #error Unknown CPU architecture
Thanks. Please feel free to just fix and upload stuff like this, push fix to salsa git repo. I absolutely don't mind. If you don't I'll get to it in a few days.
Bug#1029125: Please!
I'm the gmailieer, aka lieer, maintainer. Yes, please upgrade this! Lieer is assuming the 2.x version (well, 1.8 or above) of the python google auth library, with the to_json method. There isn't much I can do to fix lieer until this package is upgraded. (See also #1053227)
Bug#1054390: noisy output
Well that seems a bit drastic! You don't want to lose *all* the error messages. I was thinking something which leaves stdout alone and just filters out annoying stderr lines. Like this: #!/usr/bin/bash set -e xournalpp "$@" 2> >(egrep -v '^ALSA lib .*snd_')
Bug#1054390: noisy output
It's great that people are using Xournal++, and care enough about it to be bothered by this! These are coming from libsndfile1. Many Linux GUI programs do output a constant stream of harmless warnings, and Xournal++ is hardly the worst offender. The "right" fix is presumably to tell libsndfile1 (the calls are sf_xxx()) to try other sound systems first, like pipewire or pulse, before going to devices. Or maybe there's a way to tell it to be less verbose. Perhaps libsndfile1 has build options that would avoid this by trying things in a different order, or tell it to be less verbose. Anyway, patches welcome, at least to Xournal++. If it really bugs you, as a workaround I'd suggest redirecting standard error to a log file, maybe via a pipe that removes the annoying ALSA stuff. Cheers, --Barak Pearlmutter
Bug#1052929: yasnippet: FTBFS: make: *** [debian/rules:4: binary] Error 25
I pushed a quick update, it has a few test failures though.
Bug#967455: granule: depends on deprecated GTK 2
Yeah, I'll do that: flush the package, with a parting recommendation on mnemosyne.
Bug#1051962: New Upstream Version
Package: kexec-tools Version: 1:2.0.25-3 Version 2.0.27 is available upstream. Also the packaging was a bit scruffy around the edges, so I updated the packaging scripts and yanking in the newest upstream version and put it all in https://salsa.debian.org/debian/kexec-tools (I did it because 2.0.25 wasn't working on all my machines while 2.0.27 is.) Naturally I fixed little silly things, without addressing the elephant in the room: correct inter-operations with systemd and not invoking the sysvinit scripts inappropriately during systemd shutdown. Anyway, please feel free to disregard, cherry pick, tell me to delete that repo, force push your packaging over it, whatever. Just trying to lend a hand! And thanks for packaging kexec-tools. Cheers, --Barak.
Bug#1041389: Will Upload NMU
Dear Alexander, Since minidlna upstream version 1.3.3 has been out since the end of May 2023, and I've been testing my packaging of it pretty hard and it seems significantly more robust than the current version in Debian, I'm going to take the liberty of doing an NMU of it with a delay of three days. Hope that's okay! (And if you're looking for a co-maintainer, or an extra team member, or whatever: pick me! Pick me! Also if you cancel the upload and tell me to go away and stop bothering you: also okay, and sorry for the trouble!) Cheers, --Barak. PS It's great that minidlna is in Debian; nothing else seems to just work, and the Gnome rygel thing just mysteriously crashes, while minidlna just does its job.
Bug#719897: pretty much moot now
This issue is now pretty much moot, since by default $ sysctl fs.inotify.max_user_watches fs.inotify.max_user_watches = 65536 and 64K "should be enough for anyone."
Bug#1023565: dleyna adoption
I've done a bit more packaging of dleyna, pushed to https://salsa.debian.org/debian/dleyna.git branch debian/main, mainly moving to the latest upstream 0.8.2. My plan is to adopt it by uploading, which hopefully will result in mopidy-dleyna becoming usable and then I'll be able to listen to DLNA music on my home network using Debian boxes, yippee. Any objections to my just doing an upload? Should I close 1023565 in the changelog? (I am, BTW, always thrilled to have co-maintainers, and even happy if people just do 0-day NMUs or just uploading fixes or whatever.) Cheers, --Barak.
Bug#1050068: add loong64 Architectrue
woops
Bug#1033648: Testing
I tried this patch with the new upstream release 1.3.3, see https://salsa.debian.org/bap/minidlna.git branch master and it didn't really work. I have a computer connected to WiFi and also a direct ethernet cable connection to a TV, and the TV cable can bounce up and down, and this patch made things not work. When I did "systemctl stop minidlna.socket" it started working again. This seemed replicable. So, I reverted the patch from my fork of the repo. This is a deep enough issue that any fix, or additional functionality of this sort, should probably go through upstream rather than just be a Debian patch.
Bug#1043158: waka waka waka
Package: elpa-use-package Version: 2.4.4-1 I am a fun-loving bloke so /usr/games is on my path and pacman (the package) is installed. When emacs is started and elpa-use-package loads and searches for an appropriate value for system-packages-package-manager it finds the executable /usr/games/pacman so the variable gets set to "pacman" instead of "apt". Waka waka waka.
Bug#1042902: emacs-gtk: system-package-package-manager should be "apt"
reassign 1042902 elpa-system-packages 1.0.11-2 thanks The variable system-packages-package-manager gets set to "pacman" because the executable path is searched for appropriate programs, and "pacman" is searched for before "apt", and so if the game pacman is installed (package pacman) and "/usr/games" is on $path because the user is just a fun loving bloke... I'd suggest just hard-coding it to "/usr/bin/apt" in a Debian patch.
Bug#1042902: emacs-gtk: system-package-package-manager should be "apt"
Package: emacs-gtk Version: 1:29.1+1-2 Severity: normal The global variable system-packages-package-manager (introduced in 29.x) defaults to "pacman" instead of the more debian-appropriate "apt".
Bug#1041389: New Upstream Version 1.3.3
Package: minidlna Version: 1.3.2+dfsg-1.1 Severity: wishlist I've done a packaging of the new upstream release, 1.3.3, in branch master of https://salsa.debian.org/bap/minidlna forked from the debian/minidlna repo, which also includes a quick update of the packaging scripts for things like enabling hardening. --Barak Pearlmutter PS MiniDLNA is fantastic! Thanks for packaging it.
Bug#1038396: RM: gtkboard -- ROM; ancient, unmaintained upstream, uses sdl 1.2 and gtk 2
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: gtkbo...@packages.debian.org Control: affects -1 + src:gtkboard Nothing depends on this package. It is ancient, unmaintained upstream, and uses the obsolete SDL 1.2 and GTK 2.
Bug#1034629: pdf-presenter-console: pdfpc terminates with symbol lookup error
Wow, thanks everyone for tracking this down so quickly! I'm going to close it, since it was due to non-debian packages.
Bug#1034452: Wayland Incompatible
Package: veyon-service Version: 4.7.5+repack1-1 Veyon does not have Wayland support, which is slated to be released with version 5.x in about two and a half years ago. In the meantime, when client machines are logged in with Wayland, the master cannot view their screens etc. I would suggest that, until Wayland support materializes, there be a configuration option which tells the display manager to discourage Wayland sessions. This could of course come with varying levels of stridency: forbid Wayland entirely, pop up a scary Wayland warning, just make X11 sessions the default, etc.
Bug#1033448: black-box-terminal: Package was renamed and most probably should no longer exist
Thanks for noting that. Already filed for RM, see bugs.debian.org/1033450
Bug#1033450: ROM
PS This is at ROM
Bug#1033450: RM: black-box-terminal -- redundant with blackbox-terminal
Package: ftp.debian.org Severity: normal Upstream requested we use the name blackbox-terminal instead of black-box-terminal, for compatibility with other distribution channels. So I changed the name up and uploaded to NEW, but was unable to stop the old name black-box-terminal from getting through NEW. (I tried to dcut, and when I realized that wouldn't work, I asked, but by then it was too late.) So, please remove source and binary packages black-box-terminal from the archive, since it is identical (except for naming) with blackbox-terminal. tldr: RM black-box-terminal; KEEP (DO NOT RM) blackbox-terminal
Bug#1032846: rename
Upstream has suggested renaming this to blackbox-terminal, for compatibility with other distributions, flatpacks, etc, which are using that name. So I'm doing the rename and re-uploading to new.
Bug#1032965: Upstream 1.2.2 with Prelim Packaging
I've done a bit of testing, and my prelim 1.2.2 packaging seems to work fine. Also a tiny bit more yak shaving. I have not tried to get the unit testing stuff working with the debian/tests automated test suite business. But if that were done, this version might be able to get past the freeze. (Also a good idea for its own sake, of course.) There's a lot of test stuff, and it's set up with Docker and tox. Just "cd testing && ./run_tests" downloads all sorts of python stuff and runs it without Docker just fine (see below), but ways to directly invoke just the tests are documented in README-TESTING.md. Bottom line, I don't see any particular difficulty in getting it to work in an autopkgtest / DEP-8 setup. "./setup.py test" from the main directory might even be enough, once all the right dependencies are marshalled in debian/tests/control. Cheers, --Barak. testing/functional/test_restart.py .. [ 81%] testing/functional/test_selection.py ... [ 98%] testing/functional/test_verify.py [100%] == warnings summary == .tox/py311/lib/python3.11/site-packages/future/standard_library/__init__.py:65 /home/barak/src/git/duplicity/.tox/py311/lib/python3.11/site-packages/future/standard_library/__init__.py:65: DeprecationWarning: the imp module is deprecated in favour of importlib and slated for removal in Python 3.12; see the module's documentation for alternative uses import imp -- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html generated xml file: /home/barak/src/git/duplicity/report.xml == 467 passed, 10 skipped, 1 warning in 1044.34s (0:17:24) === __ summary ___ code: commands succeeded ERROR: py27: InterpreterNotFound: python2.7 ERROR: py35: InterpreterNotFound: python3.5 ERROR: py36: InterpreterNotFound: python3.6 ERROR: py37: InterpreterNotFound: python3.7 ERROR: py38: InterpreterNotFound: python3.8 ERROR: py39: InterpreterNotFound: python3.9 ERROR: py310: InterpreterNotFound: python3.10 py311: commands succeeded
Bug#1030857: transmission 4.0.1-1
cool. force pushed yours to my repo, and rebased some yak shaving onto it
Bug#1030857: transmission 4.0.1-1
I would say that marking lots of 100% downloaded torrent as 0%, and refusing to re-verify them, would count as a severity: important bug, and hence allow 4.0.2 to get into the release. The release team wants a high-quality release just as much as we do, and transmission is a leaf package and therefore they might be a bit more lenient. Anyway, I've just prepared a 4.0.2-1 release candidate, https://salsa.debian.org/bap/transmission branch "master" with "upstream" and "pristine-tar" branches updated as well, and new tag "upstream/4.0.2". I've tested it, and it solves the "fully downloaded torrent sticks as 0% and refuses to verify" problem, and seems otherwise functional.
Bug#1030857: transmission 4.0.1-1
Leo, Thanks for uploading 4.0.1-1. Good idea to disable libtransmission-dev for now. I did a bit of testing, and it seems to get a bunch of those old "no bencoded data to parse" errors, and a whole bunch of fully downloaded torrents showed up as 0%. So I cherry-picked to the tip of upstream/main (as of yesterday) above your branch, see branch cherry-pick-devel on https://salsa.debian.org/bap/transmission, and that fixed *everything*! All fully-downloaded torrents verify completely and show as 100% downloaded. Yes, even all the single-file ones. And no more "no bencoded data to parse" errors. If you look at the commits, there are a bunch of seemingly-relevant bug fixes. And also some minor stuff. Anyway, I think it would be a service to our users to not have them upgrade and suddenly half their complete torrents show up as 0% and they're getting screenfulls of "bencoded" errors about torrents that used to work fine. So I think it might be a good idea to upload a version patched with these upstream fixes, or at least some coherent subset of them. Really upstream should release 4.0.2 with these fixes right away, since 4.0.1 is, technically speaking, what we in the biz call "broken". But I digress. Cheers, --Barak.
Bug#1032965: Upstream 1.2.2 with Prelim Packaging
Package: duplicity Version: 0.8.22-1+b3 Upstream has shifted to a new homepage and development repo, and is up to 1.2.2 as of Jan 2023. I've prepared a preliminary packaging of the latest release, as a series of commits on top of the salsa.debian.org/debian/duplicity repo, in a fork of that repo, on branch debian of https://salsa.debian.org/bap/duplicity I have not had a chance to test it yet. Please let me know if there's anything else I can do to help get duplicity updated; I have a script that runs it on terebytes of data every day, so using an up to date version seems sensible. I'm a DD, so would be happy to do an NMU if you'd like, after a bit of testing of course. Cheers, --Barak Pearlmutter.
Bug#1032846: ITP: black-box-terminal -- Black Box aka Blackbox Terminal Emulator
Package: wnpp Owner: Barak A. Pearlmutter Severity: wishlist * Package name: black-box-terminal Version : 0.13.2 Upstream Author : Paulo Queiroz * URL or Web page : https://gitlab.gnome.org/raggesilver/blackbox.git * License : GPL-3+ Description : Black Box aka Blackbox Terminal Emulator GTK-4 based terminal with reasonably small footprint and the usual features. - Theming (Tilix-compatible color scheme support) - App theming based on terminal color scheme - Transparent background - Custom fonts and cell spacing - Tabs - Toggleable header bar - Click to open links - Files drag-n-drop support - Sixel (experimental) - Customizable UI - Customizable shortcuts This is unrelated to the Blackbox X Window Manager. There is a dependency on libpqmarble for which I have filed another ITP. Preliminary packaging in https://gitlab.gnome.org/barak/blackbox.git branch debian.
Bug#1032845: ITP: libpqmarble -- Paulo Quizroz's collection of useful and reusable widgets
Package: wnpp Owner: Barak A. Pearlmutter Severity: wishlist * Package name: libpqmarble Version : 1.3.0 Upstream Author : Paulo Queiroz * URL or Web page : https://gitlab.gnome.org/raggesilver/marble * License : GPL-3+ Description : Paulo Quizroz's collection of useful and reusable widgets. Packaging this because it's used by black-box-terminal which I'll also package. See https://gitlab.gnome.org/barak/pqmarble.git branch debian for prelim packaging. This used to be named marble / libmarble but that conflicts with the existing debian libmarble package; hence the (upstream endorsed) libpqmarble rename, and the stray references as just plain marble in some URLs.
Bug#1030857: verification issue
For me it triggered verification of all existing torrents, but some of them which are actually 100% downloaded show as 0% even after verification. These are (after the cherry picking etc) only ones with a single file download, rather than a directory. And only some of them. Some of the ones that got in that state proceeded to download again successfully. But some could not find any peers and are stuck at 0%, even though I can see that they are actually 100% downloaded. For ones that proceeded to download again, I *think*, but am not sure, that after connecting to a peer they verified correctly instead of actually re-downloading. Anyway, I think we might be able to squeeze transmission through the freeze if we upload chop-chop! I thought it was soft now, and didn't apply to "leaf" packages like this.
Bug#1030857: verification issue
Okay, I cherry-picked upstream commits 487cc27e1..d21a3b622, the endpoint being the current upstream/main, and built, and installed, and it seems to solve this problem. The "no bencoded data to parse" messages are gone. And things verify upon request, with most of them succeeding. A few failed to verify even though they are absolutely downloaded; these are all single file torrents, instead of a directory containing files. So that's a clue as to the bug, I suppose. Anyway, this issue does seem at least mostly fixed upstream post-release.
Bug#1030857: testing
Okay, I installed the package generated by 16c2e55a0 in my repo, which is a 4.0.1-1 candidate. It seems to work okay EXCEPT ... (a) is kicks out messages like this Feb 26 21:49:35 sweat transmission-daemon[1174]: [2023-02-26 21:49:35.396] ERR torrent-metainfo.cc:630 no bencoded data to parse (84) (./libtransmission/torrent-metainfo.cc:630) Feb 26 21:49:35 sweat transmission-daemon[1174]: [2023-02-26 21:49:35.396] ERR torrent-metainfo.cc:630 no bencoded data to parse (84) (./libtransmission/torrent-metainfo.cc:630) Feb 26 21:49:35 sweat transmission-daemon[1174]: [2023-02-26 21:49:35.396] ERR torrent-metainfo.cc:630 no bencoded data to parse (84) (./libtransmission/torrent-metainfo.cc:630) Feb 26 21:49:35 sweat transmission-daemon[1174]: [2023-02-26 21:49:35.396] ERR torrent-metainfo.cc:630 no bencoded data to parse (84) (./libtransmission/torrent-metainfo.cc:630) Feb 26 21:49:35 sweat transmission-daemon[1174]: [2023-02-26 21:49:35.396] ERR torrent-metainfo.cc:630 no bencoded data to parse (84) (./libtransmission/torrent-metainfo.cc:630) Feb 26 21:49:35 sweat transmission-daemon[1174]: [2023-02-26 21:49:35.396] ERR torrent-metainfo.cc:630 no bencoded data to parse (84) (./libtransmission/torrent-metainfo.cc:630) Feb 26 21:49:35 sweat transmission-daemon[1174]: [2023-02-26 21:49:35.396] ERR torrent-metainfo.cc:630 no bencoded data to parse (84) (./libtransmission/torrent-metainfo.cc:630) Feb 26 21:49:35 sweat transmission-daemon[1174]: [2023-02-26 21:49:35.396] ERR torrent-metainfo.cc:630 no bencoded data to parse (84) (./libtransmission/torrent-metainfo.cc:630) And, it is refusing to verify a whole bunch of stuff that to my knowledge was already downloaded just fine under 3.x. It just lists them as 0%. Hitting "verify" on them does nothing, nor does resume or re-announce. Some of them list as downloading; of those, sometimes one wakes up and verifies and jumps to seeding. No idea what's going on. Not sure this is a sufficient show-stopper to preclude uploading this version, but thought I'd mention it. Looking at the post-release upstream commits, I suspect some may address this. I could try cherry-picking some of those commits, or maybe just merging the development tip, and seeing if that fixes the problem. Or, maybe we should wait for 4.0.2 which might address this properly? Is anyone in touch with upstream? It might help to get their take, find out if they're going to do a point release fixing this stuff sometime soon.
Bug#1030857: Testing
Testing the 4.0.1 daemon. Upgrade seems okay, although there's some straggler ghost file /etc/init/itransmission-daemon.conf The upgraded daemon invalidates all downloaded data and wants to verify them, which is a local operation, but is still taking forever. I think that's supposed to be a feature not a bug. If someone were to test the clients that would be great!
Bug#1030857: 4.0.1
Okay, well... > Just FYI: I have done some work in the salsa repo[0], but there are still a > few kinks to iron out before we can ship it. It builds, but my debhelper-foo > is a bit rusty :) > If anyone wants to jump in and finish it up, I wouldn't complain! Don't complain, because I did a bit more work, on a fork of that repo, salsa.debian.org/bap/transmission I *think* it's good to go, although someone should give it a bit of a test first. I only use the daemon, so I'm not in a good position for it.
Bug#1001005: static library
I went and tried to do a trial updating of the package to 4.0.1.
Still monkeying around with that.
It seems that the cmake build scripts have the option -DINSTALL_LIB=ON
to generate a library, but it generates a *static* libtransmisison.a,
and there is no option to generate a dynamic/shared
libtransmission.so. This would appear to be a deliberate upstream
decision, which we would normally defer to.
On the other hand, upstream also makes the deliberate decision to add
crazy buggy git pre-commit hooks when you build the package.
configure_file("${CMAKE_SOURCE_DIR}/extras/pre-commit"
"${TR_GIT_ROOT}/.git/hooks/pre-commit" COPYONLY)
Bug#1008280: pstoedit: silently fails with success return for some purifyeps use cases
> >Failing on some inputs is not a justification for a `serious` severity. > > *Silently* failing, i.e. saying you succeed but not doing so, > however is Regardless of severity, does anyone have any good ideas for fixing this? Patches welcome! Feel free to just upload a fix if you have the urge. Please, let's make this moot.
Bug#1029257: webcamoid: segmentation fault
Thanks for the bug report. On a "testing" system, with webcamoid 9.0.0-5. $ rm -r ~/.cache/Webcamoid $ webcamoid [2023-01-20 12:04:13.838, Webcamoid, 0x7f432a7577c0, (0)] warning: QSocketNotifier: Can only be used with threads started with QThread [2023-01-20 12:04:14.975, Webcamoid, 0x7f432a7577c0, main.qml (152)] warning: qrc:/Webcamoid/share/qml/main.qml:152:5: QML ColumnLayout: Binding loop detected for property "width" [2023-01-20 12:04:15.037, Webcamoid, 0x7f432a7577c0, main.qml (152)] warning: qrc:/Webcamoid/share/qml/main.qml:152:5: QML ColumnLayout: Binding loop detected for property "width" [2023-01-20 12:04:15.153, Webcamoid, 0x7f426dffb6c0, (0)] debug: Camera input frame format: AkCaps(mimeType="video/unknown",fourcc=QVariant(QString, "MJPG"),fps=QVariant(QString, "30/1"),height=QVariant(uint, 720),width=QVariant(uint, 1280)) $ Pops up a window, quits when I hit the quit button. So I'm going to mark this as done as of 9.0.0-5, after merging it with 979029 which seems to be the same issue.
Bug#1014897: this bug ++
I would also find this useful, in my case for the mit-scheme package. Please do it! (Should the Debian BTS have an upvote system? It's already basically reddit, with each package a subreddit and each bug a post.) I also hate having to guess which dh_* commands do substitution and which don't. Please make them all do it except when there's a show stopper. $ grep Substitution: debian/control Scripts-Require-Substitution: dh_installalternatives $ cd ... $ grep Substitution: debian/control Scripts-Require-Substitution: *
Bug#1023557: rygel: consider After=network.target in rygel.service for lingering
Just wanted to confirm that upgrading to libgupnp-1.6-0 from sid, version 1.6.3-1, seems to have completely solved this problem. Rygel used to crash constantly, and now seems rock solid on a server with a WiFi link to the home network and exposing a NAT Ethernet connection to a TV, with both bouncing sporadically. Thanks!
Bug#1023557: rygel: consider After=network.target in rygel.service for lingering
Cool! I had assumed, from the log messages etc, that this was likely a race condition between the network configuration changing and rygel being notified of, and adjusting to, said configuration.
Bug#1023557: rygel: consider After=network.target in rygel.service for lingering
Okay, here's a manifestation of some network-change rygel-stops issue. This is rygel 0.42.0-2. Logs below. After "systemctl --user restart rygel.service" it works fine. $ last -1 reboot reboot system boot 6.0.0-6-amd64Wed Dec 21 09:00 still running $ systemctl --user status rygel.service ○ rygel.service - Rygel DLNA/UPnP server Loaded: loaded (/usr/lib/systemd/user/rygel.service; enabled; preset: enabled) Active: inactive (dead) since Wed 2022-12-21 09:00:46 GMT; 13min ago Duration: 30.065s Process: 853 ExecStart=/usr/bin/rygel (code=exited, status=0/SUCCESS) Main PID: 853 (code=exited, status=0/SUCCESS) CPU: 6.485s Dec 21 09:00:20 sweat rygel[853]: Error sending SSDP packet to FF0E::C: Error sending message: Network is unreachable Dec 21 09:00:20 sweat rygel[853]: Error sending SSDP packet to FF0E::C: Error sending message: Network is unreachable Dec 21 09:00:20 sweat rygel[853]: Error creating GUPnP context: Failed to bind socketError binding to address [fe80::4f84:2ae9:bb96:f67f%3]:1900: Cannot assign requested address Dec 21 09:00:46 sweat systemd[811]: Stopping Rygel DLNA/UPnP server... Dec 21 09:00:46 sweat rygel[853]: Process check_async failed: Child process killed by signal 15 Dec 21 09:00:46 sweat rygel[853]: g_file_new_for_uri: assertion 'uri != NULL' failed Dec 21 09:00:46 sweat rygel[853]: rygel_media_export_harvesting_task_on_extractor_error_cb: assertion 'file != NULL' failed Dec 21 09:00:46 sweat mx-extract[2354]: rygel-media-export-extract.vala:180: Started with descriptors 3 (in) 4 (out), extracting meta-data: true Dec 21 09:00:46 sweat systemd[811]: Stopped Rygel DLNA/UPnP server. Dec 21 09:00:46 sweat systemd[811]: rygel.service: Consumed 6.485s CPU time.
Bug#1025468: gnome-music: Does not support DLNA
Package: gnome-music Version: 42.1-1 Severity: normal X-Debbugs-Cc: none, Barak A. Pearlmutter The package description reads, in part: > Objectives includes ... a player for DLNA media servers ... "If wishes were horses, beggars would ride." Right now there is no DLNA support in Gnome-Music. I think this should be made clear in the package description, because if someone wants a music player with DLNA support, they need to find something else. As currently written, it's not unreasonable to expect DLNA support, and to spend some time bashing around on the program trying to find it. Developers have lists of features they'd like to see implemented someday, but users mainly care about what capabilities actually exist.
Bug#1025235: rygel seems to depend upon ffmpeg
Package: rygel Version: 0.42.0-2 Severity: normal X-Debbugs-Cc: none, Barak A. Pearlmutter My rygel DLNA server stopped actually worked (did not show the actual video files, just directories, on my LG TV; showed the files, but did not show thumbnails or actually serve their content, on totem or vlc clients) on the upgrade to 0.42.0-2. After considerable fiddling around trying to figure out what was going on, I gave up. Then I tried installing ffmpeg and restarting rygel it started working immediately, thumbnails and all. So I'd suggest rygel "Depends: ffmpeg". I'm not sure what indirect path is leading rygel to ffmpeg, perhaps some dbus service it uses? Cheers, --Barak. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (530, 'testing'), (520, 'proposed-updates'), (510, 'stable-updates'), (500, 'stable'), (450, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages rygel depends on: ii init-system-helpers 1.65.2 ii libc6 2.36-5 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1 ii libgee-0.8-20.20.6-1 ii libges-1.0-01.20.3-1 ii libglib2.0-02.74.1-2 ii libgssdp-1.6-0 1.6.2-2 ii libgstreamer-plugins-base1.0-0 1.20.4-1 ii libgstreamer1.0-0 1.20.4-1 ii libgupnp-1.6-0 1.6.2-1 ii libgupnp-av-1.0-3 0.14.1-1 ii libgupnp-dlna-2.0-4 0.12.0-3 ii libmediaart-2.0-0 1.9.6-1 ii librygel-core-2.8-0 0.42.0-2 ii librygel-db-2.8-0 0.42.0-2 ii librygel-renderer-2.8-0 0.42.0-2 ii librygel-server-2.8-0 0.42.0-2 ii libsoup-3.0-0 3.2.1-2 ii libsqlite3-03.40.0-1 ii libx11-62:1.8.1-2 ii libxml2 2.9.14+dfsg-1.1+b2 Versions of packages rygel recommends: ii dbus-user-session 1.14.4-1 ii gstreamer1.0-libav 1.20.3-1+b1 ii gstreamer1.0-plugins-base 1.20.4-1 ii gstreamer1.0-plugins-good 1.20.3-1+b1 ii gstreamer1.0-plugins-ugly 1.20.3-1 Versions of packages rygel suggests: ii rygel-playbin 0.42.0-2 pn rygel-preferences pn rygel-ruih ii rygel-tracker 0.42.0-2 pn tumbler -- no debconf information
Bug#1024997: install-info: dir entry for emacs is bolloxed
Yes! That fixes it.
Bug#1024905: minidlna: new upstream version
Just to be clear: I didn't get a chance yet to, like, actually test it.
Bug#1024997: install-info: dir entry for emacs is bolloxed
Package: install-info Version: 6.8-6+b1 Severity: normal X-Debbugs-Cc: none, Barak A. Pearlmutter The directory file /usr/share/info/dir entry for emacs itself is messed up, even after a clean regeneration. Note the strange characters here that mess up the entry: $ cat -v /usr/share/info/dir | egrep -2 '[(]emacs[)]' * Magit: (magit). Using Git from Emacs with Magit. * With-Editor: (with-editor). Using the Emacsclient as $EDITOR. ^ZM-^L}[^EM-^KM-6M-bd^E* Emacs: (emacs). The extensible self-documenting text editor. * Emacs FAQ: (efaq).Frequently Asked Questions about Emacs. * Haskell Mode: (haskell-mode). Haskell Development Environment for Emacs(en) I'd also note that /usr/sbin/update-info-dir does not ignore *~ files, but it *does* ignore symbolic links. $ egrep find /usr/sbin/update-info-dir find "$INFODIR" -type f | while read file ; do $ ls -l /usr/share/info/emacs.info.gz lrwxrwxrwx 1 root root 31 Sep 26 2019 /usr/share/info/emacs.info.gz -> /etc/alternatives/emacs.info.gz In fact, one might wonder why the above "find" looks for anything other than *.info.gz files. One might also wonder whether install-info.c needs to be rewritten from scratch in something sane, but I digress. In any case, tracing through the construction of /usr/share/info/dir by hot-wiring update-info-dir to pause after each invocation of install-info, I found that the "bad" material is installed by processing of /usr/share/info/mutt-alias.info.gz, which is installed because emacs-goodies-el depends on elpa-mutt-alias, even though I do not have mutt installed. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (530, 'testing'), (520, 'proposed-updates'), (510, 'stable-updates'), (500, 'stable'), (450, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages install-info depends on: ii libc6 2.36-5 install-info recommends no packages. install-info suggests no packages. -- no debconf information
Bug#1024905: minidlna: new upstream version
Package: minidlna Version: 1.3.0+dfsg-2.2+b3 Severity: wishlist X-Debbugs-Cc: none, Barak A. Pearlmutter Merge upstream version 1.3.2, packaging updates, and minor patches. I've put these in a git fork on salsa, see https://salsa.debian.org/debian/minidlna/-/merge_requests/4 Cheers, --Barak.
Bug#1024214: youtubedl-gui: please change dependency from youtube-dl to yt-dlp
Wow, thanks! Will dput asap.
Bug#1024214: youtubedl-gui: please change dependency from youtube-dl to yt-dlp
Can do, although patches would be welcome. Here's a broader suggestion though. I can change the dependency to "yt-dlp | youtube-dl", but how about if yt-dlp sets up an alternative (using update-alternatives) for /usr/bin/youtube-dl to a little script that tosses a "--compat-options" onto the front and trampolines to yt-dlp. I suppose youtube-dl should have a final version uploaded that also sets itself up with the same update-alternative thing (move the actual executable to /usr/lib/youtube-dl/youtube-dl), and yt-dlp would need to conflict with previous versions of youtube-dl, and should also provide:youtube-dl. Anyway, the upshot would be a graceful transition. And I'd put a version on the yt-dlp dependency of this particular package. But in general user scripts which invoke youtube-dl (of which there must be a gazillion; I myself have dozens scattered about) would keep working. What do you think?
Bug#1023557: rygel: consider After=network.target in rygel.service for lingering
Package: rygel Version: 0.42.0-2 Dear Maintainer, Thanks for maintaining Rygel. It's made our big TV useful! And tablets! Everyone on the local network is happy! To keep everyone happy, I turned on lingering for the involved user (me) $ loginctl enable-linger $(whoami) and enabled rygel. This causes rygel to start when the machine boots, instead of waiting for me to log in. One tiny problem: rygel starts before the network is up, gets an error having to do with the network not being set up, and apparently fails to announce itself on the local network, so nobody can watch videos or listen to music. Which makes everyone in the house sad until I log in and $ systemctl --user restart rygel.service which is a hassle. I *think* the right way to solve this is by adding a line After=network.target to the rygel unit file, /usr/lib/systemd/user/rygel.service Cheers, --Barak. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (550, 'testing'), (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable'), (450, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.19.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages rygel depends on: ii init-system-helpers 1.65.2 ii libc6 2.36-4 ii libgdk-pixbuf-2.0-0 2.42.9+dfsg-1 ii libgee-0.8-20.20.6-1 ii libges-1.0-01.20.3-1 ii libglib2.0-02.74.1-1 ii libgssdp-1.6-0 1.6.0-3 ii libgstreamer-plugins-base1.0-0 1.20.3-2 ii libgstreamer1.0-0 1.20.3-1 ii libgupnp-1.6-0 1.6.0-3 ii libgupnp-av-1.0-3 0.14.1-1 ii libgupnp-dlna-2.0-4 0.12.0-3 ii libmediaart-2.0-0 1.9.6-1 ii librygel-core-2.8-0 0.42.0-2 ii librygel-db-2.8-0 0.42.0-2 ii librygel-renderer-2.8-0 0.42.0-2 ii librygel-server-2.8-0 0.42.0-2 ii libsoup-3.0-0 3.2.1-2 ii libsqlite3-03.39.4-1 ii libx11-62:1.8.1-2 ii libxml2 2.9.14+dfsg-1+b1 Versions of packages rygel recommends: ii dbus-user-session 1.14.4-1 ii gstreamer1.0-libav 1.20.3-1+b1 ii gstreamer1.0-plugins-base 1.20.3-2 ii gstreamer1.0-plugins-good 1.20.3-1+b1 ii gstreamer1.0-plugins-ugly 1.20.3-1 Versions of packages rygel suggests: ii rygel-playbin 0.42.0-2 pn rygel-preferences pn rygel-ruih ii rygel-tracker 0.42.0-2 ii tumbler4.16.1-1 -- no debconf information
Bug#1019199: update
Updated my prelim packaging to upstream 0.5.4.
Bug#1019385: swisswatch: add command-line parameter to display arbitrary time
Great idea! Patches welcome.
Bug#1019199: New Upstream Version and Ubuntu/Upstream Coordination
Package: timekpr-next Version: 0.5.2-1 Thanks for packaging timekpr-nExT. My 11yo daughter hates it! There's a new upstream version available. I did a quick packaging in https://salsa.debian.org/bap/timekpr-next which installs fine but would require testing. I note that the upstream author maintains an Ubuntu PPA https://code.launchpad.net/~mjasnik/+archive/ubuntu/ppa which has (as of my writing this) a packaged version of 0.5.3 and also a development binary tracking post-0.5.3 development (misleadingly with the name 0.5.4). The 0.5.3 PPA has a longer postinst script than the Debian package, which maybe does useful things? It might make sense to coordinate on this with upstream, to make sure the official Debian package isn't missing something important.
Bug#1018302: New Upstream Version
I light of 2.46, I rejiggered my patches and packaging for that. See https://salsa.debian.org/bap/xdaliclock branch master.
Bug#1018302: New Upstream Version
Package: xdaliclock Version: 2.44+debian-3 Upstream 2.45 is out, and uses gtk3 and is antialiased. I've done a prelim packaging (including reworking the upstream autotools stuff in a patch), feel free to cannibalize any or all as you see fit; in salsa.debian.org/bap/xdaliclock
Bug#1013089: ddccontrol-db: Version number not matching with upstream
Thanks. Good eye! Turns out upstream had a typo in a git tag, which is what the packaging tooling sees. Hardly seems worth bumping an epoch when it will be solved by just waiting a few weeks. We call this "laziness", right?
Bug#997823: Fix as merge request
I've issued merge requests on salsa to the pulseaudio package that addresses this issue. All it does is install the modules in /usr/lib/pulse-MAJOR.MINOR/modules/. Using that small fix, paprefs is not grayed out anymore.
Bug#997823: module path
Just took over paprefs. Yes this is an issue. You can fix it for now by adding a symbolic link, but yuck. Open to suggestions. See https://bugs.debian.org/1003163 (Maybe these bugs should be merged)
Bug#1003163: What's the Problem
The root cause here seems to be that pa_get_library_version() in libpulse0 does not include the "+dfsg" suffix. I'd say that either (A) it should, or (B) the pulse stuff should all be installed in a directory without the suffix, or (C) there should be a symbolic link from a non-suffix directory to the suffix one. It's not clear to me why the "+dfsg" in the debian package version should be something the innards of the package knows about, so I'd vote for (B). It's tempting to reassign this bug to libpulse0. It's even more tempting to suggest that libpulse0 should have a function that takes the name of a module and returns the path to that module, so clients don't need to go through torturous logic to figure out where the modules might be. $ ls -d /usr/lib/*pulse* /usr/lib/pulse-15.0+dfsg1 $ gdb /usr/bin/paprefs (gdb) run C-c (gdb) print (char *)pa_get_library_version() $1 = 0x774cad12 "15.0.0"
Bug#1010418: Proposed bugfix
I don't understand this code in that patch:
+ while (true) {
+ unowned Posix.Passwd passwd =
Posix.getpwent();
+ if (passwd.pw_name ==
GLib.Environment.get_user_name()) {
+ found = true;
+ cmd += passwd.pw_shell;
+ break;
+ }
+ }
Will that loop forever if get_user_name returns something that doesn't
have an entry in /etc/passwd?
Bug#1008354: fossil: FTBFS: ./conftest__.c:3: undefined reference to `sqlite3_open'
Yes. I patched over the issue for now by just using the internal sqlite3 library, so I think it can wait until the next official release to pick up the proper bug fix and go back to using the system sqlite3 library.
Bug#1009000: Prelim Packaging
I've done a prelim (UNRELEASED) packaging of 1.2, see packaging repo fork https://salsa.debian.org/bap/paprefs I've enabled CI, so if you go to CI/CD>Pipelines and click on the "build" job, you should be able to download a built binary amd64 package as one of the "Job artifacts" on the right.
Bug#1009324: GPU (CUDA) Support
Package: libsvm-dev Version: 3.24+ds-6 Severity: wishlist Any chance of a GPU-enabled version? Appropriate mods to use CUDA are in https://github.com/prehensilecode/mklabiti-libsvm-cuda although that might be a bit dated, not sure it's tracked since libsvm 3.0. But it would be really nice to enjoy the speedups at the bottom of that README.md, we are running hundreds of jobs that each take a couple CPU-days, and turning that into GPU-minutes would be amazing.
Bug#812227: Sort of solved
You can right click in the left column and there's a menu with one item: REFRESH. I don't think it's well placed, a button next to CONNECT would be better. But it does address this issue...
Bug#1009246: New Upstream Version
Package: transmission-remote-gtk Version: 1.4.1-5 Severity: wishlist There's a new upstream version available. I've taken the liberty of doing a prelim updated packaging; it uses meson, and I patched it to use libayatana-appindicator3-dev, which is license compatible and the successor to libappindicator. My packaging is on branch "debian" repo https://salsa.debian.org/bap/transmission-remote-gtk.git which is a clone of your packaging repo. (Thanks for maintaining transmission-remote-gtk, it is super useful!)
Bug#1008207: Nice Script but Small
That's a useful little shell script. But small. Maybe it would make sense to get it included in /usr/share/doc/openssh-client/examples/? Or make a package ssh-misc-utils that contains a bunch of scripts for doing useful little tasks? Basically, to agglomerate it with some other related things, so as to avoid fragmentation.
Bug#1006680: Stopgap
As a stop-gap until this is fixed, you can run this script (as root, obviously). fix-guake-desktop-link Description: Binary data
Bug#1004678: git-lfs: allow offline operation
I will file an issue upstream. But I don't expect them to care, because github (the company) probably views this issue as a feature, not a bug. This issue ties people to a single central repository and makes migration nearly impossible, at least for non-wizards. Which is basically their business model: come for the issue tracker and repo sharing, stay because you have no choice, you can't leave, you can't even commit without connecting.
Bug#1004678: git-lfs: allow offline operation
Package: git-lfs Version: 3.0.2-1 Severity: wishlist X-Debbugs-Cc: none, Barak A. Pearlmutter I have a repo whose only remote is on a gitlab instance. I'm using git-lfs to manage large binary files in this repo. The remote goes down. Now "git add foo.pdf / git commit", when *.pdf files are tracked by lfs, freezes! Waits forever for the remote when trying to transfer the big blobs. This violates what I consider a central concept of git, namely that operations are local unless you explicitly fetch or push. It means you cannot work with lfs while offline, like on an aeroplane, or even (as above) when the gitlab instance is offline for maintenance. There is also a potential security issue. Users might reasonably assume they can safely do "git add/commit/rebase" operations locally, with intermediate steps exposing secret information that is later removed before doing a push. Nope! Anyway: I *wish* git-lfs allowed remote operation, like git-annex does. It seems like it should be technically possible to wait until an lfs-tracked file (well, its https://git-lfs.github.com/spec/v1 smudge stub) is actually pushed before transferring the associated big binary blob. Or at the very least, giving up and remembering to try again later if there's a big binary blob transfer problem. -- System Information: Versions of packages git-lfs depends on: ii git1:2.34.1-1 ii libc6 2.33-5
Bug#1004529: imagemagick-6.q16: convert foo.png foo.eps security violation leaves empty foo.eps
Package: imagemagick-6.q16 Version: 8:6.9.11.60+dfsg-1.3 Severity: normal When "convert foo.png foo.eps" gets a security error, it leaves an empty foo.eps. /usr/bin/convert should not generate incorrect output files. If the output cannot be correctly generated, the output file should be removed. The current behaviour is a problem when convert is used in a Makefile, where the first run of "make" generates an error but also an empty output file, then a second run of "make" treats that empty output file as correct and continues later stages of the build. Example: $ ls -l stroke-signs-1.eps ls: cannot access 'stroke-signs-1.eps': No such file or directory $ convert stroke-signs-1.png stroke-signs-1.eps convert-im6.q16: attempt to perform an operation not allowed by the security policy `EPS' @ error/constitute.c/IsCoderAuthorized/421. $ ls -l stroke-signs-1.eps -rw-rw-r-- 1 barak barak 0 Jan 14 22:36 stroke-signs-1.eps
Bug#1004160: Newer Upstream Version
UPDATE! I've merged and pushed mods for the even-newer just-released upstream version 3.0, which removes the need for running with privs entirely.
Bug#1004160: New Upstream Version
Package: usbview Version: 2.0-21-g6fe2f4f-2.1 Mark, There's a new upstream version, 2.2, which addresses those security CVEs and fixes some other problems, and upstreams a bunch of Debian mods, and has some other improvements and such. I've taken the liberty of packaging it, and doing some general packaging script updating. See https://salsa.debian.org/debian/usbview branch debian-bap, a repo I took the liberty of creating and populating with the package's history. Please feel free to snarf whatever changes I've made you like, or tell me to sod off, or whatever. Or, I'm happy to co-maintain, or do an NMU, if you'd like. Just let me know. Cheers, --Barak.
Bug#1003749: imagemagick-6.q16: convert foo.png foo.eps security violation leaves empty foo.eps
Package: imagemagick-6.q16 Version: 8:6.9.11.60+dfsg-1.3 Severity: normal /usr/bin/convert should not generate incorrect output files. If the output cannot be correctly generated, the output file should be removed. The current behaviour is a problem when convert is used in a Makefile, where the first run of "make" generates an error but also an empty output file, then a second run of "make" treats that empty output file as correct and continues later stages of the build. Example: $ ls -l stroke-signs-1.eps ls: cannot access 'stroke-signs-1.eps': No such file or directory $ convert stroke-signs-1.png stroke-signs-1.eps convert-im6.q16: attempt to perform an operation not allowed by the security policy `EPS' @ error/constitute.c/IsCoderAuthorized/421. $ ls -l stroke-signs-1.eps -rw-rw-r-- 1 barak barak 0 Jan 14 22:36 stroke-signs-1.eps
Bug#981464: systemctl --user start fetchmail.service
Seems to work!
Bug#1001033: pdf-presenter-console: pdfpc terminates with 'std::bad_alloc'
Thanks for the bug report. I'm unable to replicate this with some other PDF file using version 4.5.0-3. Could I trouble you to upgrade to the version in testing and see if it still happens? And if so, I need details: a particular PDF file it does this on, and also info about the environment: Gnome with Wayland, or whatever.
Bug#981464: systemctl --user start fetchmail.service
Great! Just for a bit of eye candy, here's what it looks like in use: $ systemctl --user status fetchmail.service *●* fetchmail.service - Fetchmail Daemon Loaded: loaded (/home/barak/.config/systemd/user/fetchmail.service; enabled; vendor preset: enabled) Active: *active (running)* since Fri 2021-11-19 10:06:05 GMT; 1 week 1 day ago Docs: man:fetchmail(1) Main PID: 33578 (fetchmail) Tasks: 1 (limit: 19040) Memory: 3.4M CPU: 22.160s CGroup: /user.slice/user-1000.slice/user@1000.service /app.slice/fetchmail.service └─33578 fetchmail --nodetach --daemon 300 Nov 25 21:54:12 tarsk fetchmail[33578]: 1 message for barak.pearlmutter@xxx at outlook.office365.com. Nov 25 21:54:12 tarsk fetchmail[33578]: reading message barak.pearlmutter@x...@dub-efz.ms-acdc.office.com:1 of 1 (3529 header octets) (2423 body octets) flu> Nov 26 15:25:25 tarsk fetchmail[33578]: 1 message for barak.pearlmutter@xxx at outlook.office365.com. Nov 26 15:25:26 tarsk fetchmail[33578]: reading message barak.pearlmutter@x...@dub-efz.ms-acdc.office.com:1 of 1 (4387 header octets) (61207 body octets) fl> Nov 26 16:20:30 tarsk fetchmail[33578]: 1 message for barak.pearlmutter@xxx at outlook.office365.com. Nov 26 16:20:30 tarsk fetchmail[33578]: reading message barak.pearlmutter@x...@dub-efz.ms-acdc.office.com:1 of 1 (8659 header octets) (43658 body octets) fl> Nov 26 17:45:37 tarsk fetchmail[33578]: 1 message for barak.pearlmutter@xxx at outlook.office365.com. Nov 26 17:45:37 tarsk fetchmail[33578]: reading message barak.pearlmutter@x...@dub-efz.ms-acdc.office.com:1 of 1 (4271 header octets) (573358 body octets) f> Nov 27 08:11:41 tarsk fetchmail[33578]: 1 message for barak.pearlmutter@xxx at outlook.office365.com. Nov 27 08:11:42 tarsk fetchmail[33578]: reading message barak.pearlmutter@x...@dub-efz.ms-acdc.office.com:1 of 1 (7244 header octets) (196879 body octets) f>
Bug#981464: systemctl --user start fetchmail.service
Agreed: it would probably make sense for these systemd support materials to go upstream. (Modulo approval, smoothing off rough edges, etc.) Let me know if there's anything I should do to help.
Bug#981464: systemctl --user start fetchmail.service
I've written a unit so I can run fetchmail under systemd as a user service. I'd suggest that the file /usr/lib/systemd/user/fetchmail.service (see below) be included in the package. It would also make sense to describe how to actually enable it, by putting something like the following into /usr/share/doc/fetchmail/README.systemd: To run fetchmail as a systemd user service, for an individual user: (1) Configuration Set up your .fetchmailrc so that "fetchmail --nodetach" actually fetches your mail correctly. (2) Tell systemd to run it as a service Allow daemons to keep running after you log out (optional): $ sudo loginctl enable-linger $USERNAME Make the service available: $ systemctl --user enable fetchmail.service Actually turn it on: $ systemctl --user start fetchmail.service Monitor it, to check if it's okay: $ systemctl --user status fetchmail.service Monitor it harder: $ journalctl --user -xeu fetchmail.service - Caveat: In the below fetchmail.service file, I'm not sure if the "ExecStop=" command is a good idea. If you just leave that line out, systemd will kill the process using its own mechanisms, which are effective but perhaps a bit brutal. Might be more robust to just leave it out. It's currently set to wake up every 5min. Not sure how to make this default nicely but still be easy to change. Perhaps some systemd wizard can help? $ cat /usr/lib/systemd/user/fetchmail.service [Unit] Description=Fetchmail Daemon Documentation=man:fetchmail(1) [Service] ExecStart=fetchmail --nodetach --daemon 300 ExecStop=fetchmail --quit Restart=always [Install] WantedBy=default.target
Bug#999944: terminus: depends on obsolete pcre3 library
It looks to me like the pcre3 dependency in the terminus package is entirely due to its use of valac and other build support. There doesn't appear to be any direct use, except in a build dependency. If I remove that build dependency, libpcre3-dev is still pulled into the build environment, due to its being a transitive requirement. So as a matter of policy, can I just remove the build dependency and close this bug and relax, even though the actual executable still ends up linked against libpcre3? Seeing as how that needs to be fixed in some other package...
Bug#995802: ddccontrol: doesn't reload systemd service from postinst
Lovely. After a quick look through that discussion, it seems that the "right" thing to do is install into whatever $ pkg-config systemd --variable=systemdsystemunitdir gives, and one day that will swizzle but there's no need to worry about it. And in the meantime, no need to pollute pre/post scripts with reloads. Barring objections from people more knowledgeable than me, that's what I'll do to close this bug.
Bug#995802: ddccontrol: doesn't reload systemd service from postinst
Thanks for the report, Paul. Wow, that's annoying! I'd assumed debhelper had some dh_ thing in its pipeline that automatically noticed .service files being installed in the relevant places and emitted pre/post code to tickle systemd appropriately, or that dpkg would trigger on the .service files the same way it does on .so files, or something automatic like that. Is a postinst / postrm "systemctl --system daemon-reload" really appropriate? My read of the documentation is that this would reload all the daemons, not just the ddccontrol one. But maybe it's more gentle than I'm giving it credit for?
Bug#969418: Library Package from PPA
Looks like this is not necessary?
Bug#993517: RM: mit-scheme [i386] -- ROM; i386 support removed upstream
Package: ftp.debian.org Severity: normal Upstream no longer supports building for i386. Well, trying to build on i386 runs out of memory, and upstream no longer releases i386 binaries, so I'm taking that to mean i386 support is kaput.
Bug#978839: confused and unable to reproduce
This doesn't seem like an autoconf issue, as the problem crops up post-configuration. Unless I'm missing something. And, I'm unable to reproduce it, using autoconf 2.71. Could you check if the current version still exhibits the problem?
Bug#978865: confused and unable to reproduce
This doesn't seem like an autoconf issue, as the problem crops up post-configuration. Unless I'm missing something. And, I'm unable to reproduce it. Could you check if the version I just uploaded still exhibits the problem?
Bug#992191: deborphan: deborphan --help unterminated last line
Package: deborphan Version: 1.7.33 The last line of "deborphan --help" is not terminated: no final EOL, aka NL, aka 0x0A, aka C-j. $ deborphan --help | tail -1 ; echo '***UNTERMINATED LINE***' See also: deborphan(1), orphaner(8)***UNTERMINATED LINE***
Bug#927076: xournalpp packaging in Debian
Okay, I used a git snapshot for the version and tarball, and all seems well.
