Bug#877464: git-remote-gcrypt: git push always behaves as if --force is given
Joey Hess wrote: > with the old ref I saw on the remote. If the shas are different, I > check `git log --oneline $old..$src` -- if this outputs nothing, then > history is not advancing and it refuses to push that ref, and > reports the error to git. That's not quite right, because git log outputs commits when the two refs are diverged but share a common ancestor. I think the best way to detect it is git merge-base --ancestor $old $src which will exit nonzero on a non-fast-forward. -- see shy jo signature.asc Description: PGP signature
Bug#1060224: bluetoothd started segfaulting
Thanks, I've tried 5.73-1 and have not been able to get it to crash so far. -- see shy jo signature.asc Description: PGP signature
Bug#877464: git-remote-gcrypt: git push always behaves as if --force is given
I was implementing another gitremote-helper today and ran into what I think is the same problem. Since I've worked around the problem in my gitremote-helper successfully, I wanted to share what I've learned in case it can help git-remote-gcrypt. When git push is run, for a non-forced push, it asks the gitremote-helper program for "list for-push". It then sends a "push" to it. And only after that does it go compare the list of refs it got with the list of refs it has asked to be pushed, and notice if the push would overwrite a ref. At that point, git pull will complain that refs were not able to be pushed. But actually nothing stopped the gitremote-helper from doing a push that overwrote a ref, effectively a force push. I think this is a bug in git. I can't imagine why it behaves this way. It requires that every gitremote-helper program effectively replicate git's own detection of a disallowed push, in order to reject the "push" with "error $ref" It is certainly possible for a gitremote-helper program to do that though. What I did is, when git runs "list for-push", I remember the refs that are on the remote. Then when git runs "push $src:$dst", (but not when it's a "+$src" forced push), I compare the sha of $src with the old ref I saw on the remote. If the shas are different, I check `git log --oneline $old..$src` -- if this outputs nothing, then history is not advancing and it refuses to push that ref, and reports the error to git. -- see shy jo signature.asc Description: PGP signature
Bug#1068024: revert to version that does not contain changes by bad actor
Guillem Jover wrote:
> dpkg should be able to use an old liblzma w/o multi-threaded compressor
> or decompressor support
Ah you're right. configure did find the library, but I'd missed updating
some ifdefs. Attached updated dpkg patch which does build with the
shared library and works.
--
see shy jo
diff -ur orig/dpkg-1.22.6/Makefile.in dpkg-1.22.6/Makefile.in
--- orig/dpkg-1.22.6/Makefile.in 2024-03-10 15:21:24.0 -0400
+++ dpkg-1.22.6/Makefile.in 2024-04-03 02:46:40.893211227 -0400
@@ -344,7 +344,7 @@
LTLIBINTL = @LTLIBINTL@
LTLIBOBJS = @LTLIBOBJS@
LT_SYS_LIBRARY_PATH = @LT_SYS_LIBRARY_PATH@
-LZMA_LIBS = @LZMA_LIBS@
+LZMAUNSCATHED_LIBS = @LZMAUNSCATHED_LIBS@
MAKEINFO = @MAKEINFO@
MANIFEST_TOOL = @MANIFEST_TOOL@
MD_LIBS = @MD_LIBS@
diff -ur orig/dpkg-1.22.6/config.h.in dpkg-1.22.6/config.h.in
--- orig/dpkg-1.22.6/config.h.in 2024-03-10 15:21:24.0 -0400
+++ dpkg-1.22.6/config.h.in 2024-04-03 02:46:40.585213979 -0400
@@ -511,8 +511,8 @@
/* Define to 1 to use bz2 library rather than console tool */
#undef WITH_LIBBZ2
-/* Define to 1 to use lzma library rather than console tool */
-#undef WITH_LIBLZMA
+/* Define to 1 to use lzmaunscathed library rather than console tool */
+#undef WITH_LIBLZMAUNSCATHED
/* Define to 1 to compile in SELinux support */
#undef WITH_LIBSELINUX
diff -ur orig/dpkg-1.22.6/configure.ac dpkg-1.22.6/configure.ac
--- orig/dpkg-1.22.6/configure.ac 2024-03-02 21:30:15.0 -0400
+++ dpkg-1.22.6/configure.ac 2024-03-30 13:15:26.981883607 -0400
@@ -113,7 +113,7 @@
DPKG_LIB_MD
DPKG_LIB_Z
DPKG_LIB_BZ2
-DPKG_LIB_LZMA
+DPKG_LIB_LZMAUNSCATHED
DPKG_LIB_ZSTD
DPKG_LIB_SELINUX
AS_IF([test "x$build_dselect" = "xyes"], [
@@ -336,7 +336,7 @@
libselinux . . . . . . . . . : $have_libselinux
libmd . . . . . . . . . . . . : $have_libmd
libz . . . . . . . . . . . . : $have_libz_impl
-liblzma . . . . . . . . . . . : $have_liblzma
+liblzmaunscathed . . . . . . .: $have_liblzmaunscathed
libzstd . . . . . . . . . . . : $have_libzstd
libbz2 . . . . . . . . . . . : $have_libbz2
libcurses . . . . . . . . . . : ${have_libcurses:-no}
diff -ur orig/dpkg-1.22.6/debian/control dpkg-1.22.6/debian/control
--- orig/dpkg-1.22.6/debian/control 2024-03-02 21:30:15.0 -0400
+++ dpkg-1.22.6/debian/control 2024-03-30 13:14:37.746223895 -0400
@@ -20,7 +20,7 @@
zlib1g-dev,
libbz2-dev,
# Version needed for multi-threaded decompressor support.
- liblzma-dev (>= 5.4.0),
+ liblzmaunscathed-dev,
# Version needed for the new streaming API.
libzstd-dev (>= 1.4.0),
libselinux1-dev [linux-any],
@@ -28,7 +28,7 @@
# Needed for the functional test.
bzip2 ,
# Version needed for multi-threaded decompressor support.
- xz-utils (>= 5.4.0) ,
+ xz-utils ,
# Needed for the functional test.
zstd ,
# Needed for the author release process.
@@ -89,7 +89,7 @@
libmd-dev,
zlib1g-dev,
# Version needed for multi-threaded decompressor support.
- liblzma-dev (>= 5.4.0),
+ liblzmaunscathed-dev,
# Version needed for the new streaming API.
libzstd-dev (>= 1.4.0),
libbz2-dev,
@@ -113,7 +113,7 @@
tar (>= 1.28-1),
bzip2,
# Version needed for multi-threaded decompressor support.
- xz-utils (>= 5.4.0),
+ xz-utils,
# Version needed for git-style diff support.
patch (>= 2.7),
make,
@@ -165,7 +165,7 @@
liblocale-gettext-perl,
bzip2,
# Version needed for multi-threaded decompressor support.
- xz-utils (>= 5.4.0),
+ xz-utils,
Suggests:
debian-keyring,
gnupg | sq | sqop | pgpainless-cli | sequoia-chameleon-gnupg,
diff -ur orig/dpkg-1.22.6/debian/libdpkg-dev.install dpkg-1.22.6/debian/libdpkg-dev.install
--- orig/dpkg-1.22.6/debian/libdpkg-dev.install 2024-02-04 22:31:16.0 -0400
+++ dpkg-1.22.6/debian/libdpkg-dev.install 2024-03-30 13:25:27.043840706 -0400
@@ -1,4 +1,5 @@
usr/include/dpkg/*.h
-usr/lib/*/pkgconfig/libdpkg.pc
-usr/lib/*/libdpkg.a
+usr/lib/pkgconfig/libdpkg.pc
+usr/lib/libdpkg.a
usr/share/aclocal/dpkg-*.m4
+usr/lib/libdpkg.la
diff -ur orig/dpkg-1.22.6/debian/rules dpkg-1.22.6/debian/rules
--- orig/dpkg-1.22.6/debian/rules 2024-03-02 21:30:15.0 -0400
+++ dpkg-1.22.6/debian/rules 2024-03-30 13:22:38.316130018 -0400
@@ -67,7 +67,8 @@
$(D)/usr/share/lintian/profiles/dpkg/main.profile
override_dh_auto_test:
- dh_auto_test -- $(testflags)
+ echo tests disabled for now
+ #dh_auto_test -- $(testflags)
override_dh_installsystemd:
dh_installsystemd -a --name=dpkg-db-backup \
diff -ur orig/dpkg-1.22.6/dselect/Makefile.in dpkg-1.22.6/dselect/Makefile.in
--- orig/dpkg-1.22.6/dselect/Makefile.in 2024-03-10 15:21:24.0 -0400
+++ dpkg-1.22.6/dselect/Makefile.in 2024-04-03 02:46:40.917211013 -0400
@@ -366,7 +366,7 @@
LTLIBINTL = @LTLIBINTL@
LTLIBOBJS = @LTLIBOBJS@
LT_SYS_LIBRARY_PATH = @LT_SYS_LIBRARY_PATH@
-LZMA_LIBS = @LZMA_LIBS@
+LZMAUNSCATHED_LIBS = @LZMAUNSCATHED_LIBS@
MAKEINFO = @MAKEINFO@
MANIFEST_TOOL = @MANIFEST_TOOL@
MD_LIBS = @MD_LIBS@
diff -ur
Bug#1068024: revert to version that does not contain changes by bad actor
> The situation is being analysed by a cross-team taskforce, > please let them do the already-stressing job ☻ Sorry, didn't see that before sending my previous message. I'll leave it to you guys. -- see shy jo signature.asc Description: PGP signature
Bug#1068024: revert to version that does not contain changes by bad actor
Since there's been some discussion about versions, the version in my xz-unscathed git repository is the same as xz 5.3.2alpha, with the addition of a fix for CVE-2022-1271 that did not make it into that version. (It was fixed in 5.2.6, but 5.3.2alpha was diverged from 5.2.5. Jia Tan was involved in 5.2.6.) 5.2.5 might be a more stable version to revert to; it also predates Jia Tan's involvement. The CVE-2022-1271 fix would need to be included. Note that erofs-utils apparently had a reason to need the 5.3.2alpha release, so reverting to 5.2.5 would probably cause difficulty with that package. That dependency versioning information is not included in the debian sources for erofs-utils BTW. I have not checked compatability with other packages except for dpkg. -- see shy jo signature.asc Description: PGP signature
Bug#1068024: revert to version that does not contain changes by bad actor
I have prepared a git repository that is a fork of xz from the point I
identified before the attacker(s) did anything to it. In my fork, I have
renamed liblzma to liblzmaunscathed. That allows it to be installed
alongside current dpkg without breaking dpkg with an old version of
liblzma.
My git repository is here (note all my commits are gpg signed):
https://git.joeyh.name/index.cgi/xz-unscathed/
It also has a debian branch which contains a debian directory. I've
built packages of that, as well as building dpkg-1.22.6 against it.
I've attached the patch I used to build dpkg.
My build of dpkg ended up not being linked to a lzma library at all,
because liblzmaunscathed is too old to support concurrent decompression,
which the configure script detects. So dpkg-deb instead uses xz-utils
to decompress debs. I replaced xz-utils.deb with the one built from my
fork, and dpkg seems to work fine using it.
If Debian decided to go this route, you could add xz-utils-unscathed
to unstable, and at the same time update xz-utils to not build
xz-utils.deb. Then build dpkg against it. Then look into forward porting
or re-implementing concurrent decompression if that is really important
to have.
I only plan to maintain this fork minimally, eg backporting security
fixes. The goal is not to take over from xz upstream, but to get the
possibly backdoored code off of production systems ASAP. Presumably xz
upstream will come up with their own solution long-term.
--
see shy jo
diff -ur orig/dpkg-1.22.6/Makefile.in dpkg-1.22.6/Makefile.in
--- orig/dpkg-1.22.6/Makefile.in 2024-03-10 15:21:24.0 -0400
+++ dpkg-1.22.6/Makefile.in 2024-03-30 13:28:12.823685407 -0400
@@ -344,7 +344,7 @@
LTLIBINTL = @LTLIBINTL@
LTLIBOBJS = @LTLIBOBJS@
LT_SYS_LIBRARY_PATH = @LT_SYS_LIBRARY_PATH@
-LZMA_LIBS = @LZMA_LIBS@
+LZMAUNSCATHED_LIBS = @LZMAUNSCATHED_LIBS@
MAKEINFO = @MAKEINFO@
MANIFEST_TOOL = @MANIFEST_TOOL@
MD_LIBS = @MD_LIBS@
diff -ur orig/dpkg-1.22.6/config.h.in dpkg-1.22.6/config.h.in
--- orig/dpkg-1.22.6/config.h.in 2024-03-10 15:21:24.0 -0400
+++ dpkg-1.22.6/config.h.in 2024-03-30 13:28:12.563685572 -0400
@@ -511,8 +511,8 @@
/* Define to 1 to use bz2 library rather than console tool */
#undef WITH_LIBBZ2
-/* Define to 1 to use lzma library rather than console tool */
-#undef WITH_LIBLZMA
+/* Define to 1 to use lzmaunscathed library rather than console tool */
+#undef WITH_LIBLZMAUNSCATHED
/* Define to 1 to compile in SELinux support */
#undef WITH_LIBSELINUX
diff -ur orig/dpkg-1.22.6/configure.ac dpkg-1.22.6/configure.ac
--- orig/dpkg-1.22.6/configure.ac 2024-03-02 21:30:15.0 -0400
+++ dpkg-1.22.6/configure.ac 2024-03-30 13:15:26.981883607 -0400
@@ -113,7 +113,7 @@
DPKG_LIB_MD
DPKG_LIB_Z
DPKG_LIB_BZ2
-DPKG_LIB_LZMA
+DPKG_LIB_LZMAUNSCATHED
DPKG_LIB_ZSTD
DPKG_LIB_SELINUX
AS_IF([test "x$build_dselect" = "xyes"], [
@@ -336,7 +336,7 @@
libselinux . . . . . . . . . : $have_libselinux
libmd . . . . . . . . . . . . : $have_libmd
libz . . . . . . . . . . . . : $have_libz_impl
-liblzma . . . . . . . . . . . : $have_liblzma
+liblzmaunscathed . . . . . . .: $have_liblzmaunscathed
libzstd . . . . . . . . . . . : $have_libzstd
libbz2 . . . . . . . . . . . : $have_libbz2
libcurses . . . . . . . . . . : ${have_libcurses:-no}
diff -ur orig/dpkg-1.22.6/debian/control dpkg-1.22.6/debian/control
--- orig/dpkg-1.22.6/debian/control 2024-03-02 21:30:15.0 -0400
+++ dpkg-1.22.6/debian/control 2024-03-30 13:14:37.746223895 -0400
@@ -20,7 +20,7 @@
zlib1g-dev,
libbz2-dev,
# Version needed for multi-threaded decompressor support.
- liblzma-dev (>= 5.4.0),
+ liblzmaunscathed-dev,
# Version needed for the new streaming API.
libzstd-dev (>= 1.4.0),
libselinux1-dev [linux-any],
@@ -28,7 +28,7 @@
# Needed for the functional test.
bzip2 ,
# Version needed for multi-threaded decompressor support.
- xz-utils (>= 5.4.0) ,
+ xz-utils ,
# Needed for the functional test.
zstd ,
# Needed for the author release process.
@@ -89,7 +89,7 @@
libmd-dev,
zlib1g-dev,
# Version needed for multi-threaded decompressor support.
- liblzma-dev (>= 5.4.0),
+ liblzmaunscathed-dev,
# Version needed for the new streaming API.
libzstd-dev (>= 1.4.0),
libbz2-dev,
@@ -113,7 +113,7 @@
tar (>= 1.28-1),
bzip2,
# Version needed for multi-threaded decompressor support.
- xz-utils (>= 5.4.0),
+ xz-utils,
# Version needed for git-style diff support.
patch (>= 2.7),
make,
@@ -165,7 +165,7 @@
liblocale-gettext-perl,
bzip2,
# Version needed for multi-threaded decompressor support.
- xz-utils (>= 5.4.0),
+ xz-utils,
Suggests:
debian-keyring,
gnupg | sq | sqop | pgpainless-cli | sequoia-chameleon-gnupg,
diff -ur orig/dpkg-1.22.6/debian/libdpkg-dev.install dpkg-1.22.6/debian/libdpkg-dev.install
--- orig/dpkg-1.22.6/debian/libdpkg-dev.install 2024-02-04 22:31:16.0 -0400
+++ dpkg-1.22.6/debian/libdpkg-dev.install 2024-03-30 13:25:27.043840706 -0400
@@ -1,4 +1,5 @@
Bug#1068024: revert to version that does not contain changes by bad actor
Aurelien Jarno wrote: > Note that reverted to such an old version will break packages that use > new symbols introduced since then. From a quick look, this is at least: > - dpkg > - erofs-utils > - kmod > > Having dpkg in that list means that such downgrade has to be planned > carefully. I agree this would be a challanging downgrade. I've tried it myself experimentally and once a downgraded liblzma5 is unpacked, dpkg-deb is broken with missing symbol 'XZ_5.4'. Renaming liblzma5 to something else (liblzma6?) and making dpkg-deb depend on that seems like one way to go that would avoid messy situations. FWIW, I rebuilt xz-utils 5.2.5-2.1~deb11u1 (from bullseye) on sid and then got dpkg to build against that successfully after a few minor changes to dpkg's packaging: --- debian/libdpkg-dev.install.orig 2024-03-30 07:31:46.635365816 -0400 +++ debian/libdpkg-dev.install 2024-03-30 07:34:48.667477725 -0400 @@ -1,4 +1,5 @@ usr/include/dpkg/*.h -usr/lib/*/pkgconfig/libdpkg.pc -usr/lib/*/libdpkg.a +usr/lib/pkgconfig/libdpkg.pc +usr/lib/libdpkg.a usr/share/aclocal/dpkg-*.m4 +usr/lib/libdpkg.la (And after disabling the test suite since changes in xz message output caused a test failure.) -- see shy jo signature.asc Description: PGP signature
Bug#1068024: revert to version that does not contain changes by bad actor
Package: xz-utils Version: 5.6.1+really5.4.5-1 Severity: important Tags: security I count a minimum of 750 commits or contributions to xz by Jia Tan, who backdoored it. This includes all 700 commits made after they merged a pull request in Jan 7 2023, at which point they appear to have already had direct push access, which would have also let them push commits with forged authors. Probably a number of other commits before that point as well. Reverting the backdoored version to a previous version is not sufficient to know that Jia Tan has not hidden other backdoors in it. Version 5.4.5 still contains the majority of those commits. Commits by them such as 18d7facd3802b55c287581405c4d49c98708c136 and ae5c07b22a6b3766b84f409f1b6b5c100469068a show that they were deep into analyzing the security of xz. They were well placed to insert a buffer overflow that could allow eg, a targeted xz file to cause arbitrary code execution. The impact of such a security hole could be much more stealthy and bad than the known backdoor since it would allow chaining xz with other unrelated software releases on an ongoing basis. The package should be reverted to a version before their involvement, which started with commit 6468f7e41a8e9c611e4ba8d34e2175c5dacdbeb4. Or their early commits vetted and revert to a later point, but any arbitrary commit by a known bad and malicious actor almost certainly has less value than the risk that a subtle change go unnoticed. I'd suggest reverting to 5.3.1. Bearing in mind that there were security fixes after that point for ZDI-CAN-16587 that would need to be reapplied. -- see shy jo signature.asc Description: PGP signature
Bug#1065072: packagekit spinning cpu
Matthias Klumpp wrote: > either GNOME Software is wrong (I think it unconditionally has a > problem, it should never retry a cache refresh at that insane > frequency), or the APT backend in PackageKit does something wrong and > emits package changes for blocked packages when it shouldn't do so. > I guess as soon as your system is up-to-date (with no blocked > packages), this issue will go away temporarily. Is there anything I can do while I seem to be able to reproduce this pretty easily? -- see shy jo signature.asc Description: PGP signature
Bug#1065072: packagekit spinning cpu
Joey Hess wrote: > It may also be relevant somehow that the topmost update was a thinkpad > AMD firmware update which "requires restart". I masked and stopped packagekit again and now in gnome-software, it displays only the thinkpad amd firmware update, and it's no longer alternating with the loading updates screen. This makes me think that firmware update is not related to the problem. The other updates gnome-software displays when packagekit is running are debian package updates. My last upgrade was an apt-get safe-upgrade, because dist-upgrade wants to remove several packages, including gnome. (I'm tracking unstable, this is typical transient dependency issues I suppose. Also I have bluez on hold at an older version due to #1060224) So maybe gnome-software gets confused in this kind of situation and keeps retrying? -- see shy jo signature.asc Description: PGP signature
Bug#1065072: packagekit spinning cpu
Below is a pkmon while the problem is occurring. Since it points at gnome-software causing the activity, I tried opening that. I noticed that the updates tab had an indicator that there were updates. Switching to it, I saw it continuously alternate between "Loading updates" with a spinner and a list of updates. Each transition back to "Loading updates" corresponds to more pkmon activity. It may also be relevant somehow that the topmost update was a thinkpad AMD firmware update which "requires restart". Transactions: [none] daemon connected=1 network status=online Transactions: 1 /15795_aacdccdd /15795_aacdccdd allow_cancel 1 /15795_aacdccdd percentage -1 /15795_aacdccdd role get-updates /15795_aacdccdd sender /usr/bin/gnome-software /15795_aacdccdd status setup (pkmon:3985472): GLib-GIO-CRITICAL **: 02:02:25.371: GTask 0x556f0677f540 (source object: 0x556f0677c360, source tag: 0x7f08eae881c0) finalized without ever returning (using g_task_return_*()). This potentially indicates a bug in the program. Transactions: 1 /15795_aacdccdd 2 /15796_cadeddaa /15796_cadeddaa allow_cancel 1 /15796_cadeddaa percentage -1 /15796_cadeddaa role get-updates /15796_cadeddaa sender /usr/bin/gnome-software /15796_cadeddaa status wait (pkmon:3985472): GLib-GIO-CRITICAL **: 02:02:25.442: GTask 0x556f06783290 (source object: 0x556f0677c360, source tag: 0x7f08eae881c0) finalized without ever returning (using g_task_return_*()). This potentially indicates a bug in the program. Transactions: 1 /15796_cadeddaa Transactions: [none] Transactions: 1 /15797_cbbadaab Transactions: 1 /15797_cbbadaab 2 /15798_ceeaaabb /15797_cbbadaab allow_cancel 1 /15797_cbbadaab percentage -1 /15797_cbbadaab role get-details /15797_cbbadaab sender /usr/bin/gnome-software /15797_cbbadaab status setup (pkmon:3985472): GLib-GIO-CRITICAL **: 02:02:27.100: GTask 0x556f06783390 (source object: 0x556f0677c360, source tag: 0x7f08eae881c0) finalized without ever returning (using g_task_return_*()). This potentially indicates a bug in the program. /15798_ceeaaabb allow_cancel 1 /15798_ceeaaabb percentage -1 /15798_ceeaaabb role get-updates /15798_ceeaaabb sender /usr/bin/gnome-software /15798_ceeaaabb status wait (pkmon:3985472): GLib-GIO-CRITICAL **: 02:02:27.100: GTask 0x556f06784f30 (source object: 0x556f0677c360, source tag: 0x7f08eae881c0) finalized without ever returning (using g_task_return_*()). This potentially indicates a bug in the program. Transactions: 1 /15798_ceeaaabb Transactions: [none] Transactions: 1 /15799_eebaebcb /15799_eebaebcb allow_cancel 1 /15799_eebaebcb percentage -1 /15799_eebaebcb role get-updates /15799_eebaebcb sender /usr/bin/gnome-software /15799_eebaebcb status setup (pkmon:3985472): GLib-GIO-CRITICAL **: 02:02:31.374: GTask 0x556f06788660 (source object: 0x556f0677c360, source tag: 0x7f08eae881c0) finalized without ever returning (using g_task_return_*()). This potentially indicates a bug in the program. Transactions: 1 /15799_eebaebcb 2 /15800_caeadeca /15800_caeadeca allow_cancel 1 /15800_caeadeca percentage -1 /15800_caeadeca role get-updates /15800_caeadeca sender /usr/bin/gnome-software /15800_caeadeca status wait (pkmon:3985472): GLib-GIO-CRITICAL **: 02:02:31.448: GTask 0x556f06783f90 (source object: 0x556f0677c360, source tag: 0x7f08eae881c0) finalized without ever returning (using g_task_return_*()). This potentially indicates a bug in the program. Transactions: 1 /15800_caeadeca Transactions: [none] Transactions: 1 /15801_dceaeeeb Transactions: 1 /15801_dceaeeeb 2 /15802_cbacedec /15801_dceaeeeb allow_cancel 1 /15801_dceaeeeb percentage -1 /15801_dceaeeeb role get-details /15801_dceaeeeb sender /usr/bin/gnome-software /15801_dceaeeeb status setup (pkmon:3985472): GLib-GIO-CRITICAL **: 02:02:33.169: GTask 0x556f0677ee00 (source object: 0x556f0677c360, source tag: 0x7f08eae881c0) finalized without ever returning (using g_task_return_*()). This potentially indicates a bug in the program. /15802_cbacedec allow_cancel 1 /15802_cbacedec percentage -1 /15802_cbacedec role get-updates /15802_cbacedec sender /usr/bin/gnome-software /15802_cbacedec status wait (pkmon:3985472): GLib-GIO-CRITICAL **: 02:02:33.170: GTask 0x556f06788750 (source object: 0x556f0677c360, source tag: 0x7f08eae881c0) finalized without ever returning (using g_task_return_*()). This potentially indicates a bug in the program. Transactions: 1 /15802_cbacedec Transactions: [none] Transactions: 1 /15803_ecbdcdcd /15803_ecbdcdcd allow_cancel 1 /15803_ecbdcdcd percentage -1 /15803_ecbdcdcd role get-updates /15803_ecbdcdcd sender /usr/bin/gnome-software /15803_ecbdcdcd status setup (pkmon:3985472): GLib-GIO-CRITICAL **:
Bug#1065072: packagekit spinning cpu
I'm confident I saw this same problem today, with packagekit repeatedly updating and spinning a CPU for 10 minutes. It only stopped at that point because I stopped and masked it. (Stopping it was not enough, something was restarting the service every time I stopped it.) See attached log. I did not capture the trigger for that pkmon, but just before it started I had used window+s in gnome and typed in "paperwm", before remembering that doesn't find anything and pressing escape. When I repeat that with pkmon open, I see it does trigger packagekit: root@darkstar:/home/joey>pkmon Transactions: [none] daemon connected=1 network status=online Transactions: 1 /14317_cdeeebeb /14317_cdeeebeb allow_cancel 1 /14317_cdeeebeb percentage -1 /14317_cdeeebeb role resolve /14317_cdeeebeb sender /usr/bin/gnome-software /14317_cdeeebeb status setup (pkmon:3940508): GLib-GIO-CRITICAL **: 22:40:26.794: GTask 0x5621e2846510 (source object: 0x5621e2843330, source tag: 0x7fc2bdc121c0) finalized without ever returning (using g_task_return_*()). This potentially indicates a bug in the program. Transactions: [none] I found similar bug reports filed on fedora, upstream, etc. Going back years. Also looking back through the journal, it's been doing this on my system for months, every week or two, generally with only a few minutes cpu time wasted per indicent. Also, I notice that when packagekit is masked, it makes apt-get update display a message to that effect. Since this bug makes masking packagekit very appealing, that is not very nice either. -- see shy jo log.gz Description: application/gzip signature.asc Description: PGP signature
Bug#879723: can get stuck in state INSANE and stop responding
Pali Rohár wrote: > I have looked at the whole netplugd state machine and transitions > between states. I identified more bugs than the one described in this > issue report. I have prepared fixes for all of them. > > Joey, would you be interested in testing netplugd fixes? Thanks for your work, I'm no longer using netplugd so can't test. -- see shy jo signature.asc Description: PGP signature
Bug#1053472: starts w/o writing pid file, leading systemd to kill it
Correction: Not the default configuration per se, just the configuration that is necessary to interoperate with the default (chrooted) configuration of postfix. -- see shy jo signature.asc Description: PGP signature
Bug#1060224: bluetoothd started segfaulting
Package: bluez Version: 5.71-1 Severity: normal On upgrade to this version, bluetoothd started segfaulting frequently: [ 59.628624] input: Avantree SP750 (AVRCP) as /devices/virtual/input/input26 [ 97.073761] bluetoothd[838]: segfault at 561314652a23 ip 56167406a375 sp 7fffb128a200 error 4 in bluetoothd[561674048000+ec000] likely on CPU 11 (core 5, socket 0) [ 97.073799] Code: 00 31 c0 e9 54 ff ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 41 55 41 54 55 53 48 83 ec 08 48 8b 2a 48 8b 7a 08 <48> 8b 45 20 4c 8b ad 88 00 00 00 4c 8b 20 48 85 ff 74 19 c7 47 08 [ 219.074962] input: Avantree SP750 (AVRCP) as /devices/virtual/input/input27 [ 241.708695] bluetoothd[4477]: segfault at 55c5369dc8d4 ip 55c069877375 sp 7fff8f7198c0 error 4 in bluetoothd[55c069855000+ec000] likely on CPU 0 (core 0, socket 0) [ 241.708725] Code: 00 31 c0 e9 54 ff ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 41 55 41 54 55 53 48 83 ec 08 48 8b 2a 48 8b 7a 08 <48> 8b 45 20 4c 8b ad 88 00 00 00 4c 8b 20 48 85 ff 74 19 c7 47 08 To reproduce this crash all I have to do is: 1. connect to the bluetooth device 2. use it briefly 3. stop using it and wait 5 seconds Based on the timing, the crash probably occurs when it's put into power save mode. I have downgraded to 5.70-1.1, which does not have this problem. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.9-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 bluez depends on: ii dbus [default-dbus-system-bus] 1.14.10-3+b1 ii init-system-helpers 1.66 ii kmod31-1 ii libasound2 1.2.10-3 ii libc6 2.37-13 ii libdbus-1-3 1.14.10-3+b1 ii libdw1 0.190-1+b1 ii libglib2.0-02.78.3-1 ii libreadline88.2-3 ii libudev1255.2-3 ii udev255.2-3 bluez recommends no packages. Versions of packages bluez suggests: pn pulseaudio-module-bluetooth -- Configuration Files: /etc/bluetooth/main.conf changed: [General] Experimental = true [BR] [LE] [GATT] [CSIS] [AVDTP] [Policy] AutoEnable=true [AdvMon] -- no debconf information -- see shy jo signature.asc Description: PGP signature
Bug#1055070: /usr/share/doc/ghc-doc/html/libraries/index.html missing boot libraries
Package: ghc-doc Version: 9.4.7-1 Severity: normal /usr/share/doc/ghc-doc/html/libraries/index.html used to include Prelude, Data.List, GHC.* etc. Now that is all missing and it only contains docs for libghc-*-doc packages. I did find the docs in /usr/share/doc/ghc-doc/html/libraries/base-4.17.2.0/index.html -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-3-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 ghc-doc depends on: ii dpkg1.22.0 ii ghc [haddock-interface-41] 9.4.7-1 ii libjs-mathjax 2.7.9+dfsg-1 ii perl5.36.0-9 ghc-doc recommends no packages. ghc-doc suggests no packages. -- no debconf information -- see shy jo signature.asc Description: PGP signature
Bug#1054671: Acknowledgement (gdm not starting on boot)
I had plymouth installed. Removing it avoided this bug. -- see shy jo signature.asc Description: PGP signature
Bug#1054671: gdm not starting on boot
Package: gdm3 Version: 45.0.1-1 Severity: normal gdm was starting on boot until an upgrade a couple weeks ago. Now the laptop boots to a getty, and I have to log in as root and systemctl start gdm3 There are no other login managers installed, although lightdm did get installed breifly around the time this broke, and then removed. Of course I've tried to enable the service, but: root@darkstar:~>systemctl enable gdm3 Synchronizing state of gdm3.service with SysV service script with /lib/systemd/systemd-sysv-install. Executing: /lib/systemd/systemd-sysv-install enable gdm3 The unit files have no installation config (WantedBy=, RequiredBy=, UpheldBy=, Also=, or Alias= settings in the [Install] section, and DefaultInstance= for template units). This means they are not meant to be enabled or disabled using systemctl. Possible reasons for having this kind of units are: • A unit may be statically enabled by being symlinked from another unit's .wants/ or .requires/ directory. • A unit's purpose may be to act as a helper for some other unit which has a requirement dependency on it. • A unit may be started when needed via activation (socket, path, timer, D-Bus, udev, scripted systemctl call, ...). • In case of template units, the unit is meant to be enabled with some instance name specified. I don't see what other unit is supposed to depend on gdm3 and start it. I've not been able to find any services like that on my system. Note that I have task-gnome-desktop installed in full and am using gnome on wayland. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-3-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 gdm3 depends on: ii accountsservice 23.13.9-4 ii adduser 3.137 ii alacritty [x-terminal-emulator] 0.12.2-2+b1 ii dbus [default-dbus-system-bus]1.14.10-1 ii dbus-bin 1.14.10-1 ii dbus-daemon 1.14.10-1 ii dconf-cli 0.40.0-4 ii dconf-gsettings-backend 0.40.0-4 ii debconf [debconf-2.0] 1.5.82 ii foot [x-terminal-emulator]1.15.3-2 ii gir1.2-gdm-1.045.0.1-1 ii gnome-session [x-session-manager] 45.0-1 ii gnome-session-bin 45.0-1 ii gnome-session-common 45.0-1 ii gnome-settings-daemon 45.0-1 ii gnome-shell 44.5-2 ii gnome-terminal [x-terminal-emulator] 3.50.0-1 ii gsettings-desktop-schemas 45.0-1 ii libaccountsservice0 23.13.9-4 ii libaudit1 1:3.1.1-1 ii libc6 2.37-12 ii libcanberra-gtk3-00.30-10 ii libcanberra0 0.30-10 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libgdm1 45.0.1-1 ii libglib2.0-0 2.78.0-2 ii libglib2.0-bin2.78.0-2 ii libgtk-3-03.24.38-5 ii libgudev-1.0-0238-2 ii libkeyutils1 1.6.3-2 ii libpam-modules1.5.2-7 ii libpam-runtime1.5.2-7 ii libpam-systemd [logind] 254.5-1 ii libpam0g 1.5.2-7 ii librsvg2-common 2.54.7+dfsg-2 ii libselinux1 3.5-1 ii libsystemd0 254.5-1 ii libx11-6 2:1.8.7-1 ii libxau6 1:1.0.9-1 ii libxcb1 1.15-1 ii libxdmcp6 1:1.1.2-3 ii polkitd 123-1 ii procps2:4.0.4-2 ii systemd-sysv 254.5-1 ii ucf 3.0043+nmu1 ii x11-common1:7.7+23 ii x11-xserver-utils 7.7+9+b1 ii xfce4-session [x-session-manager] 4.18.3-1 ii xfwm4 [x-window-manager] 4.18.0-1 ii xmonad [x-window-manager] 0.17.2-1 ii xterm [x-terminal-emulator] 385-1 Versions of packages gdm3 recommends: ii at-spi2-core 2.50.0-1 ii desktop-base 12.0.6+nmu1 ii gnome-session [x-session-manager] 45.0-1 ii x11-xkb-utils 7.7+7 ii xfce4-session [x-session-manager] 4.18.3-1 ii xserver-xephyr 2:21.1.8-1 ii xserver-xorg
Bug#1053472: starts w/o writing pid file, leading systemd to kill it
Package: sasl2-bin Version: 2.1.28+dfsg1-3 Severity: normal saslauthd was not running after an upgrade. Investigation showed this happening after systemctl start: Oct 04 14:21:21 kite systemd[1]: Failed to start saslauthd.service - SASL Authentication Daemon. Oct 04 14:21:21 kite systemd[1]: saslauthd.service: Failed with result 'timeout'. Oct 04 14:21:21 kite systemd[1]: saslauthd.service: start operation timed out. Terminating. Oct 04 14:20:21 kite saslauthd[752305]: : auth failure: [user=linda] [service=smtp] [realm=kitenet.net] [mech=sasldb] [reason=Unknown] Oct 04 14:19:51 kite systemd[1]: saslauthd.service: Can't open PID file /run/saslauthd/saslauthd.pid (yet?) after start: No such file or directory Oct 04 14:19:51 kite saslauthd[752305]: : listening on socket: /var/spool/postfix/var/run/saslauthd/mux Oct 04 14:19:51 kite saslauthd[752305]: : master pid is: 752305 Oct 04 14:19:51 kite systemd[1]: Starting saslauthd.service - SASL Authentication Daemon... /run/saslauthd/saslauthd.pid did not exist. Apparently the daemon did start though since it was handling auth attempts. systemctl start saslauthd actually hung while this was going on, until systemd timed out and killed the daemon. I have worked around this by editing /usr/lib/systemd/system/saslauthd.service and commenting out PIDFile=/var/run/saslauthd/saslauthd.pid Aha: I notice that the pid file is being created, but in /var/spool/postfix/var/run/saslauthd. Apparently because I use -m to make it put the mix file there. It seems it might be new behavior for it to write the pid file there too? Or systemd has changed its behavior when it doesn't find a pid file. Anyway, I think -m should not affect where it puts the pid file. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-7-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 sasl2-bin depends on: ii db-util5.3.2 ii debconf [debconf-2.0] 1.5.82 ii init-system-helpers1.65.2 ii libc6 2.37-12 ii libcrypt1 1:4.4.36-2 ii libdb5.3 5.3.28+dfsg2-2 ii libkrb5-3 1.20.1-4 ii libldap-2.5-0 2.5.13+dfsg-5 ii libpam0g 1.5.2-7 ii libsasl2-2 2.1.28+dfsg1-3 ii libssl33.0.11-1 ii perl 5.36.0-9 sasl2-bin recommends no packages. sasl2-bin suggests no packages. -- Configuration Files: /etc/default/saslauthd changed: START=yes DESC="SASL Authentication Daemon" NAME="saslauthd" MECHANISMS="pam" MECH_OPTIONS="" THREADS=5 OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd" MECHANISMS=sasldb -- debconf information: cyrus-sasl2/purge-sasldb2: false cyrus-sasl2/upgrade-sasldb2-failed: cyrus-sasl2/upgrade-sasldb2-backup-failed: cyrus-sasl2/backup-sasldb2: /var/backups/sasldb2.bak -- see shy jo
Bug#1053278: Acknowledgement (embeds fasttext LLM)
Screenshot attached -- see shy jo signature.asc Description: PGP signature
Bug#1053279: contains 100+kb minified .js file without corresponding source
Package: firefox Version: 118.0-1 Severity: normal toolkit/components/translations/fasttext/fasttext_wasm.js is 100+ kb of minified js. There is no other source code. AFAIK this is not acceptable in a Debian package. https://firefox-source-docs.mozilla.org/toolkit/components/translations/resources/02_contributing.html#building-fasttext discusses this file and how it was generated, including minification. -- Package-specific info: -- Addons package information -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-1-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 firefox depends on: ii debianutils 5.13 ii fontconfig 2.14.2-6 ii libasound2 1.2.10-1 ii libatk1.0-0 2.50.0-1 ii libc62.37-11 ii libcairo-gobject21.18.0-1 ii libcairo21.18.0-1 ii libdbus-1-3 1.14.10-1 ii libdbus-glib-1-2 0.112-3 ii libevent-2.1-7 2.1.12-stable-8 ii libffi8 3.4.4-1 ii libfontconfig1 2.14.2-6 ii libfreetype6 2.13.2+dfsg-1 ii libgcc-s113.2.0-4 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libglib2.0-0 2.78.0-2 ii libgtk-3-0 3.24.38-5 ii libnspr4 2:4.35-1.1 ii libnss3 2:3.93-1 ii libpango-1.0-0 1.51.0+ds-2 ii libstdc++6 13.2.0-4 ii libvpx7 1.12.0-1 ii libx11-6 2:1.8.6-1 ii libx11-xcb1 2:1.8.6-1 ii libxcb-shm0 1.15-1 ii libxcb1 1.15-1 ii libxcomposite1 1:0.4.5-1 ii libxdamage1 1:1.1.6-1 ii libxext6 2:1.3.4-1+b1 ii libxfixes3 1:6.0.0-2 ii libxrandr2 2:1.5.2-2+b1 ii libxtst6 2:1.2.3-1.1 ii procps 2:4.0.3-1 ii zlib1g 1:1.2.13.dfsg-3 Versions of packages firefox recommends: ii libavcodec59 7:5.1.3-2 ii libavcodec60 7:6.0-7 Versions of packages firefox suggests: ii fonts-lmodern 2.005-1 pn fonts-stix | otf-stix ii libcanberra0 0.30-10 ii libgssapi-krb5-2 1.20.1-4 ii pulseaudio 16.1+dfsg1-2+b1 -- no debconf information -- see shy jo signature.asc Description: PGP signature
Bug#1053278: embeds fasttext LLM
Package: firefox Version: 118.0-1 Severity: normal Firefox has a new offline translation capability in version 118. Step one of that is determining the language used in a web page. It uses https://fasttext.cc/ to acomplish that. I have experimentally verified that firefox is able to detect the language of a Spanish language web page when used offline. So it is not downloading the LLM from a server and using it, instead the LLM must be baked into firefox. (The LLMs used for the actual translation are downloaded on demand.) See attached screenshot. This is the first run of firefox in a user account, while offline. The localhost webserver does not send any headers indicating the page's language. This is arguably a DFSG violation. I have no firm opinion on that matter, but I *do* have the opinion that the free software community needs to come to a consensus about the question. Inclusion of LLMs in packages like this risks a decision by default. Note that the fasttext LLM uses wikipedia or the common crawl as its corpus. The pre-trained vectors, which I think some would prefer to consider as "source" rather than the training corpus, are 500+ mb so it seems that are not included in the source package either. I think what is included is a quantized model, as described here https://fasttext.cc/docs/en/faqs.html -- Package-specific info: -- Addons package information -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-1-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 firefox depends on: ii debianutils 5.13 ii fontconfig 2.14.2-6 ii libasound2 1.2.10-1 ii libatk1.0-0 2.50.0-1 ii libc62.37-11 ii libcairo-gobject21.18.0-1 ii libcairo21.18.0-1 ii libdbus-1-3 1.14.10-1 ii libdbus-glib-1-2 0.112-3 ii libevent-2.1-7 2.1.12-stable-8 ii libffi8 3.4.4-1 ii libfontconfig1 2.14.2-6 ii libfreetype6 2.13.2+dfsg-1 ii libgcc-s113.2.0-4 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libglib2.0-0 2.78.0-2 ii libgtk-3-0 3.24.38-5 ii libnspr4 2:4.35-1.1 ii libnss3 2:3.93-1 ii libpango-1.0-0 1.51.0+ds-2 ii libstdc++6 13.2.0-4 ii libvpx7 1.12.0-1 ii libx11-6 2:1.8.6-1 ii libx11-xcb1 2:1.8.6-1 ii libxcb-shm0 1.15-1 ii libxcb1 1.15-1 ii libxcomposite1 1:0.4.5-1 ii libxdamage1 1:1.1.6-1 ii libxext6 2:1.3.4-1+b1 ii libxfixes3 1:6.0.0-2 ii libxrandr2 2:1.5.2-2+b1 ii libxtst6 2:1.2.3-1.1 ii procps 2:4.0.3-1 ii zlib1g 1:1.2.13.dfsg-3 Versions of packages firefox recommends: ii libavcodec59 7:5.1.3-2 ii libavcodec60 7:6.0-7 Versions of packages firefox suggests: ii fonts-lmodern 2.005-1 pn fonts-stix | otf-stix ii libcanberra0 0.30-10 ii libgssapi-krb5-2 1.20.1-4 ii pulseaudio 16.1+dfsg1-2+b1 -- no debconf information -- see shy jo signature.asc Description: PGP signature
Bug#1051987: Acknowledgement (too old for ghc)
I've confirmed that the same build that fails with this version of cabal succeeds with cabal-install version 3.10.1.0 compiled using version 3.10.1.0 of the Cabal library -- see shy jo signature.asc Description: PGP signature
Bug#1051987: too old for ghc
Package: cabal-install Version: 3.4.1.0-3 Severity: normal This version of cabal in unstable is too old to properly support ghc 9.4.6 in unstable: joey@darkstar:~/src/git-annex>cabal configure 'cabal.project.local' already exists, backing it up to 'cabal.project.local~'. Warning: Unknown/unsupported 'ghc' version detected (Cabal 3.4.1.0 supports 'ghc' version < 9.1): /usr/bin/ghc is version 9.4.6 Resolving dependencies... cabal: Could not resolve dependencies: [__0] trying: git-annex-10.20230828 (user goal) [__1] next goal: git-annex:setup.Cabal (dependency of git-annex) [__1] rejecting: git-annex:setup.Cabal-3.8.1.0/installed-3.8.1.0, git-annex:setup.Cabal-3.10.1.0, git-annex:setup.Cabal-3.8.1.0, git-annex:setup.Cabal-3.6.3.0, git-annex:setup.Cabal-3.6.2.0, git-annex:setup.Cabal-3.6.1.0, git-annex:setup.Cabal-3.6.0.0 (constraint from maximum version of Cabal used by Setup.hs requires <3.6) [__1] trying: git-annex:setup.Cabal-3.4.1.0 [__2] next goal: git-annex:setup.base (dependency of git-annex) [__2] rejecting: git-annex:setup.base-4.17.2.0/installed-4.17.2.0 (conflict: git-annex:setup.Cabal => git-annex:setup.base>=4.6 && <4.16) [__2] skipping: git-annex:setup.base-4.18.0.0, git-annex:setup.base-4.17.2.0, git-annex:setup.base-4.17.1.0, git-annex:setup.base-4.17.0.0, git-annex:setup.base-4.16.4.0, git-annex:setup.base-4.16.3.0, git-annex:setup.base-4.16.2.0, git-annex:setup.base-4.16.1.0, git-annex:setup.base-4.16.0.0 (has the same characteristics that caused the previous version to fail: excluded by constraint '>=4.6 && <4.16' from 'git-annex:setup.Cabal') [__2] rejecting: git-annex:setup.base-4.15.1.0, git-annex:setup.base-4.15.0.0, git-annex:setup.base-4.14.3.0, git-annex:setup.base-4.14.2.0, git-annex:setup.base-4.14.1.0, git-annex:setup.base-4.14.0.0, git-annex:setup.base-4.13.0.0, git-annex:setup.base-4.12.0.0, git-annex:setup.base-4.11.1.0, git-annex:setup.base-4.11.0.0, git-annex:setup.base-4.10.1.0, git-annex:setup.base-4.10.0.0, git-annex:setup.base-4.9.1.0, git-annex:setup.base-4.9.0.0, git-annex:setup.base-4.8.2.0, git-annex:setup.base-4.8.1.0, git-annex:setup.base-4.8.0.0, git-annex:setup.base-4.7.0.2, git-annex:setup.base-4.7.0.1, git-annex:setup.base-4.7.0.0, git-annex:setup.base-4.6.0.1, git-annex:setup.base-4.6.0.0, git-annex:setup.base-4.5.1.0, git-annex:setup.base-4.5.0.0, git-annex:setup.base-4.4.1.0, git-annex:setup.base-4.4.0.0, git-annex:setup.base-4.3.1.0, git-annex:setup.base-4.3.0.0, git-annex:setup.base-4.2.0.2, git-annex:setup.base-4.2.0.1, git-annex:setup.base-4.2.0.0, git-annex:setup.base-4.1.0.0, git-annex:setup.base-4.0.0.0, git-annex:setup.base-3.0.3.2, git-annex:setup.base-3.0.3.1 (constraint from non-upgradeable package requires installed instance) [__2] fail (backjumping, conflict set: git-annex, git-annex:setup.Cabal, git-annex:setup.base) After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: git-annex, git-annex:setup.Cabal, git-annex:setup.base -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.4.0-4-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 cabal-install depends on: ii ghc9.4.6-1 ii libc6 2.37-8 ii libffi83.4.4-1 ii libgmp10 2:6.3.0+dfsg-2 ii sgml-base 1.31 ii zlib1g 1:1.2.13.dfsg-3 Versions of packages cabal-install recommends: ii curl 8.3.0-1 ii wget 1.21.4-1+b1 cabal-install suggests no packages. -- no debconf information -- see shy jo signature.asc Description: PGP signature
Bug#1050380: dhcpcd-run-hooks.8 man page missing
Package: dhcpcd Version: 1:10.0.2-4 Severity: normal The man pages refer to this man page, but it's not included in the binary package. (It is in the source, hooks/dhcpcd-run-hooks.8.in) -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 dhcpcd depends on: pn dhcpcd-base ii lsb-base 11.6 ii sysvinit-utils [lsb-base] 3.07-1 dhcpcd recommends no packages. Versions of packages dhcpcd suggests: pn dhcpcd-gtk -- see shy jo signature.asc Description: PGP signature
Bug#1042915: please update to 0.24
Package: libghc-aws-dev Version: 0.22.1-1+b4 Severity: wishlist Version 0.24 enables new features in git-annex, including anonymous import from a public bucket. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.3.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER, TAINT_WARN Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 libghc-aws-dev depends on: ii ghc [libghc-transformers-dev-0.5.6.2-fc6f3] 9.0.2-4 ii libc6 2.37-6 ii libghc-aeson-dev [libghc-aeson-dev-2.0.3.0-6cd28] 2.0.3.0-1+b5 ii libghc-attoparsec-dev [libghc-attoparsec-dev-0.14.4-9b90 0.14.4-2+b1 1] pn libghc-base-dev-4.15.1.0-6a406 ii libghc-base16-bytestring-dev [libghc-base16-bytestring-d 1.0.2.0-1+b3 ev-1.0.2.0-ab752] ii libghc-base64-bytestring-dev [libghc-base64-bytestring-d 1.2.1.0-1+b1 ev-1.2.1.0-ba29f] ii libghc-blaze-builder-dev [libghc-blaze-builder-dev-0.4.2 0.4.2.2-1+b3 .2-91bf6] ii libghc-byteable-dev [libghc-byteable-dev-0.1.1-8f6f5] 0.1.1-11+b2 pn libghc-bytestring-dev-0.10.12.1-ced9a ii libghc-case-insensitive-dev [libghc-case-insensitive-dev 1.2.1.0-3+b2 -1.2.1.0-ea097] ii libghc-cereal-dev [libghc-cereal-dev-0.5.8.3-8b478] 0.5.8.3-1 ii libghc-conduit-dev [libghc-conduit-dev-1.3.4.3-84779] 1.3.4.3-1 ii libghc-conduit-extra-dev [libghc-conduit-extra-dev-1.3.6 1.3.6-1+b4 -c95cb] pn libghc-containers-dev-0.6.4.1-31c3b ii libghc-cryptonite-dev [libghc-cryptonite-dev-0.29-99264] 0.29-1+b2 ii libghc-data-default-dev [libghc-data-default-dev-0.7.1.1 0.7.1.1-6+b3 -6d3b3] pn libghc-directory-dev-1.3.6.2-311c9 pn libghc-exceptions-dev-0.10.4-c14ff pn libghc-filepath-dev-1.4.2.1-4459f ii libghc-http-client-tls-dev [libghc-http-client-tls-dev-0 0.3.6.1-1+b3 .3.6.1-2a1f1] ii libghc-http-conduit-dev [libghc-http-conduit-dev-2.3.8-f 2.3.8-1+b4 35fc] ii libghc-http-types-dev [libghc-http-types-dev-0.12.3-4a0a 0.12.3-5+b1 b] ii libghc-lifted-base-dev [libghc-lifted-base-dev-0.2.3.12- 0.2.3.12-4+b3 e0695] ii libghc-memory-dev [libghc-memory-dev-0.16.0-89fb0]0.16.0-1+b3 ii libghc-monad-control-dev [libghc-monad-control-dev-1.0.3 1.0.3.1-1+b3 .1-20361] pn libghc-mtl-dev-2.2.2-e3bae ii libghc-network-bsd-dev [libghc-network-bsd-dev-2.8.1.0-7 2.8.1.0-3+b2 26d3] ii libghc-network-dev [libghc-network-dev-3.1.2.7-bb8a0] 3.1.2.7-1+b3 ii libghc-old-locale-dev [libghc-old-locale-dev-1.0.0.7-60e 1.0.0.7-10+b3 52] ii libghc-resourcet-dev [libghc-resourcet-dev-1.2.6-16c70] 1.2.6-1+b1 ii libghc-safe-dev [libghc-safe-dev-0.3.19-b4ca4]0.3.19-2+b2 ii libghc-scientific-dev [libghc-scientific-dev-0.3.7.0-de1 0.3.7.0-1+b2 a8] ii libghc-tagged-dev [libghc-tagged-dev-0.8.6.1-38317] 0.8.6.1-1+b3 pn libghc-text-dev-1.2.5.0-8553e pn libghc-time-dev-1.9.3-bda76 ii libghc-unordered-containers-dev [libghc-unordered-contai 0.2.17.0-2+b2 ners-dev-0.2.17.0-1d16d] ii libghc-utf8-string-dev [libghc-utf8-string-dev-1.0.2-a50 1.0.2-1+b2 cd] ii libghc-vector-dev [libghc-vector-dev-0.12.3.1-f377c] 0.12.3.1-1+b2 ii libghc-xml-conduit-dev [libghc-xml-conduit-dev-1.9.1.1-e 1.9.1.1-2+b4 d422] ii libgmp10 2:6.2.1+dfsg1-1.1 ii zlib1g1:1.2.13.dfsg-1 libghc-aws-dev recommends no packages. libghc-aws-dev suggests no packages. -- no debconf information -- see shy jo signature.asc Description: PGP signature
Bug#1040674: config.txt during kernel upgrade spends time in non-bootable state
Package: raspi-firmware Version: 1.20220830+ds-1 Severity: normal While upgrading the kernel, my raspberry pi reset and failed to come back up to a usable state. Serial console showed the last thing output was the kernel saying it was running init. Investigation of the SD card found this in config.txt (abbreviated to relevant lines): kernel=vmlinuz-6.3.0-1-armmp.dpkg-new initramfs initrd.img-6.1.0-9-armmp Note the kernel and initrd version mismatch. (The .dpkg-new being used in there also seems a bit problimatic..) I had to edit it back to using vmlinuz-6.1.0-9-armmp to fix the problem. It seems to me that since rpis are known to be rather picky about power[1], it's especially important to make such a critical thing as a kernel upgrade not fail if the power goes out. -- see shy jo [1] Though I suspect mine is just a bad board, since it regularly resets when under load and was being powered by USB from my laptop, which should be a good solid power supply. signature.asc Description: PGP signature
Bug#1039050: same bug here
I've worked around this using upstream's gtk4 branch. That runs stably though it's missing a few minor features. -- see shy jo signature.asc Description: PGP signature
Bug#1039050: same bug here
(com.github.johnfactotum.Foliate:203690): Gjs-WARNING **: 13:14:57.747: Unhandled promise rejection. To suppress this warning, add an error handler to your promise chain with .catch() or a try-catch block around your await expression. Stack trace of the failed promise: main@resource:///com/github/johnfactotum/Foliate/js/main.js:478:24 run@resource:///org/gnome/gjs/modules/script/package.js:206:19 @/usr/bin/foliate:9:17 Segmentation fault Foliate had been stable up until recently. I'm tracking unstable so perhaps something changed that broke it. Note that the upstream's .deb of foliate is also crashing in the same way. -- see shy jo signature.asc Description: PGP signature
Bug#1037310: missing space in PING line for ipv6
Package: iputils-ping Version: 3:20221126-1 Severity: normal PING www.google.com(yi-in-f147.1e100.net (2607:f8b0:4002:c0c::93)) 56 data bytes Compare with ipv4 PING duckduckgo.com (52.149.246.39) 56(84) bytes of data. -- System Information: Debian Release: 12.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-7-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 iputils-ping depends on: ii libc62.36-9 ii libcap2 1:2.66-4 ii libcap2-bin 1:2.66-4 ii libidn2-02.3.3-1+b1 iputils-ping recommends no packages. iputils-ping suggests no packages. -- no debconf information -- see shy jo signature.asc Description: PGP signature
Bug#1036023: same problem on armhf
I rebuilt cabal-install from source, turning off the lukko build flag, and confirmed that fixed this problem. My recommendation would be to just do that for now, until lukko gets fixed. -- see shy jo signature.asc Description: PGP signature
Bug#1036023: same problem on armhf
I'm experiencing the same bug on armhf with cabal-install 3.4.1.0-3. My workaround was to downgrade it to 3.0.0.0-3+b1. This may be a relevant upstream issue: https://github.com/haskellari/lukko/issues/15 -- see shy jo signature.asc Description: PGP signature
Bug#1034648: postinst runs linux-update-symlinks before initrd exists
Ben Hutchings wrote: > This behaviour is intentional. The expectation is that these symlinks > are used by programs that update the boot loader configuration later > on, and those will be run only after the initramfs has been generated. > What do you think will go wrong here? Ok, I am probably wrong in my concern then. -- see shy jo signature.asc Description: PGP signature
Bug#1034648: postinst runs linux-update-symlinks before initrd exists
Source: linux Version: 6.1.20-2 Severity: normal I was upgrading a slow arm board and noticed this: Setting up linux-image-6.1.0-7-armmp-lpae (6.1.20-2) ... I: /vmlinuz.old is now a symlink to boot/vmlinuz-5.18.0-4-armmp-lpae I: /initrd.img.old is now a symlink to boot/initrd.img-5.18.0-4-armmp-lpae I: /vmlinuz is now a symlink to boot/vmlinuz-6.1.0-7-armmp-lpae I: /initrd.img is now a symlink to boot/initrd.img-6.1.0-7-armmp-lpae /etc/kernel/postinst.d/initramfs-tools: update-initramfs: Generating /boot/initrd.img-6.1.0-7-armmp-lpae It probably took 5 minutes to generate the initrd, and until then /initrd.img was a dangling symlink. A power failure in this wide window would not be fun. -- System Information: Debian Release: 12.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER, TAINT_WARN Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- see shy jo signature.asc Description: PGP signature
Bug#1034319: debootstrap of foreign arch fails w/o recommended binfmt-support
Package: qemu-user-static Version: 1:7.2+dfsg-5 Severity: normal I got a new arm64 host at Hetzner, and needed an amd64 chroot in it. Of course that's easy, since debootstrap --arch just works for foreign arches with qemu-user-static installed. root@sparrow:/tmp>apt-get install debootstrap qemu-user-static root@sparrow:/tmp>debootstrap --arch amd64 sid sid ... W: Failure trying to run: chroot "/tmp/sid" /bin/true W: See /tmp/sid/debootstrap/debootstrap.log for details root@sparrow:/tmp>tail -1 /tmp/sid/debootstrap/debootstrap.log chroot: failed to run command '/bin/true': Exec format error Oops, so it doesn't just work. Some digging in the postinst revealed I needed binfmt-support installed, and it was not installed. I think because qemu-user-static Recommends: systemd | binfmt-support and of course I have systemd installed. If systemd by itself is supposed to somehow handle what binfmt-support does, it did not work in my case. I had to install binfmt-support and rerun /var/lib/dpkg/info/qemu-user-static.postinst to fix the problem. -- see shy jo signature.asc Description: PGP signature
Bug#1033627: exporttree=yes data loss
Package: git-annex
Version: 10.20230126-2
Severity: important
git-annex has this bug, which can result in data loss when using an
external special remote with exporttree=yes
https://git-annex.branchable.com/bugs/external_remote_export_sent_to_wrong_process/
This is fixed in version 10.20230329.
I've attached a patch series that fixes this. Note that the second patch
is not strictly necessary, but it's all that's needed to support
VERSION 2, which some external special remote programs will now be
using to avoid being used with the buggy git-annex. So, I strongly
recommend including it.
(The patches are lightly trimmed versions of upstream commits
02662f52920e84cd9464641ada84f6c3bbe3f86a and
18d326cb6f27912542f41fbb9525eefdbd553d09)
--
see shy jo
From 02662f52920e84cd9464641ada84f6c3bbe3f86a Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Tue, 28 Mar 2023 15:21:10 -0400
Subject: [PATCH 1/6] fix concurrency bug causing EXPORT to be sent to the
wrong external
Fix bug that caused broken protocol to be used with external remotes that
use exporttree=yes. In some cases this could result in the wrong content
being exported to, or retrieved from the remote.
Sponsored-by: Nicholas Golder-Manning on Patreon
diff --git a/Remote/External.hs b/Remote/External.hs
index 4077030fa3..352b9eb68d 100644
--- a/Remote/External.hs
+++ b/Remote/External.hs
@@ -377,19 +377,27 @@ handleRequest external req mp responsehandler =
handleRequest' st external req mp responsehandler
handleRequestKey :: External -> (SafeKey -> Request) -> Key -> Maybe MeterUpdate -> ResponseHandler a -> Annex a
-handleRequestKey external mkreq k mp responsehandler = case mkSafeKey k of
- Right sk -> handleRequest external (mkreq sk) mp responsehandler
+handleRequestKey external mkreq k mp responsehandler =
+ withSafeKey k $ \sk -> handleRequest external (mkreq sk) mp responsehandler
+
+withSafeKey :: Key -> (SafeKey -> Annex a) -> Annex a
+withSafeKey k a = case mkSafeKey k of
+ Right sk -> a sk
Left e -> giveup e
{- Export location is first sent in an EXPORT message before
- the main request. This is done because the ExportLocation can
- contain spaces etc. -}
handleRequestExport :: External -> ExportLocation -> (SafeKey -> Request) -> Key -> Maybe MeterUpdate -> ResponseHandler a -> Annex a
-handleRequestExport external loc mkreq k mp responsehandler = do
- withExternalState external $ \st -> do
- checkPrepared st external
- sendMessage st (EXPORT loc)
- handleRequestKey external mkreq k mp responsehandler
+handleRequestExport external loc mkreq k mp responsehandler =
+ withSafeKey k $ \sk ->
+ -- Both the EXPORT and subsequent request must be sent to the
+ -- same external process, so run both with the same external
+ -- state.
+ withExternalState external $ \st -> do
+ checkPrepared st external
+ sendMessage st (EXPORT loc)
+ handleRequest' st external (mkreq sk) mp responsehandler
handleRequest' :: ExternalState -> External -> Request -> Maybe MeterUpdate -> ResponseHandler a -> Annex a
handleRequest' st external req mp responsehandler
--
2.39.1
From 18d326cb6f27912542f41fbb9525eefdbd553d09 Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Tue, 28 Mar 2023 17:00:08 -0400
Subject: [PATCH 4/6] external protocol VERSION 2
Support VERSION 2 in the external special remote protocol, which is
identical to VERSION 1, but avoids external remote programs neededing to
work around the above bug. External remote program that support
exporttree=yes are recommended to be updated to send VERSION 2.
Sponsored-by: Kevin Mueller on Patreon
diff --git a/Remote/External/Types.hs b/Remote/External/Types.hs
index 894f09dc30..633dc641bd 100644
--- a/Remote/External/Types.hs
+++ b/Remote/External/Types.hs
@@ -415,7 +415,7 @@ newtype JobId = JobId Integer
deriving (Eq, Ord, Show)
supportedProtocolVersions :: [ProtocolVersion]
-supportedProtocolVersions = [1]
+supportedProtocolVersions = [1, 2]
instance Proto.Serializable JobId where
serialize (JobId n) = show n
diff --git a/doc/design/external_special_remote_protocol.mdwn b/doc/design/external_special_remote_protocol.mdwn
index 3d2f0588ae..665687f5be 100644
--- a/doc/design/external_special_remote_protocol.mdwn
+++ b/doc/design/external_special_remote_protocol.mdwn
@@ -39,7 +39,7 @@ empty, but the separating spaces are still required in that case.
The special remote is responsible for sending the first message, indicating
the version of the protocol it is using.
- VERSION 1
+ VERSION 2
Recent versions of git-annex respond with a message indicating
protocol extensions that it supports. Older versions of
@@ -271,7 +271,7 @@ These messages may be sent by the special remote at any time that it's
handling a request.
* `VERSION Int`
- Supported protocol version. Current version is 1. Must be sent first
+ Supported protocol version. Current version is 2. Must be sent fir
Bug#1032531: dh_installchangelogs puts incorrect comment at the end of trimmed changelogs
Package: debhelper Version: 13.11.4 Severity: normal I wanted to see the earlier changelog for debconf, and saw its changelog ends with: -- Colin Watson Sat, 03 Aug 2019 11:51:13 +0100 # Older entries have been removed from this changelog. # To read the complete changelog use `apt changelog debconf`. So I followed those instructions to see the rest: joey@darkstar:~>apt changelog debconf| tail -n5 WARNING: apt does not have a stable CLI interface. Use with caution in scripts. -- Colin Watson Sat, 03 Aug 2019 11:51:13 +0100 # Older entries have been removed from this changelog. # To read the complete changelog use `apt changelog debconf`. Fetched 5,388 B in 0s (0 B/s) Oops, that didn't work! Pulling the source package, there are 10 years of changelog entries that are not included. Perhaps this is really a bug in apt or some debian infrastructure, I don't know. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER, TAINT_WARN Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 debhelper depends on: ii autotools-dev20220109.1 ii dh-autoreconf20 ii dh-strip-nondeterminism 1.13.1-1 ii dpkg 1.21.19 ii dpkg-dev 1.21.19 ii dwz 0.15-1 ii file 1:5.44-3 ii libdebhelper-perl13.11.4 ii libdpkg-perl 1.21.19 ii man-db 2.11.2-1 ii perl 5.36.0-7 ii po-debconf 1.0.21+nmu1 debhelper recommends no packages. Versions of packages debhelper suggests: pn dh-make -- no debconf information -- see shy jo signature.asc Description: PGP signature
Bug#1031647: git-annex: Bogus build dependency whitelist results in FTBFS on m68k
Sean Whitton wrote: > Joey, do you know why d/control restricts these build deps as it does? IIRC some of those deps are or were not available on some architectures like m68k. And the deps used to be gated behind the webapp build flag, so it would still build on those architectures without them installed. (I don't know how to get rmadison to display what packages are available on m68k? If those deps are avilable now, you could make git-annex use them.) Unfortunately, commit 78440ca37d75039d5eadd52eafbcd1751daba70a moved those build dependencies from behind that build flag. See commit for details; for some reason a new version of cabal changed its behavior in a way that seemed buggy, and that was the only workaround I could come up with at the time. One way you could get git-annex to build on arches where those build deps are not available would be to remove those build deps from the cabal file when building on those arches, and turning off the Assistant build flag. I think I have a better way though. The attached patch seems to work around that cabal problem in a way that will keep git-annex building when those deps are not installd. It should be in the next release of git-annex. -- see shy jo From f24f96e0186a61ef5940ce97de2713413989b63c Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Thu, 23 Feb 2023 10:35:19 -0400 Subject: [PATCH] move webapp build deps under Assistant build flag git-annex.cabal: Move webapp build deps under the Assistant build flag so git-annex can be built again without yesod etc installed. Commit 78440ca37d75039d5eadd52eafbcd1751daba70a got rid of the webapp build flag to work around what was apparently a cabal bug. It moved the webapp build deps to the main build-depends list. But that prevents building git-annex when yesod etc are not installed. Putting them under the Assistant build flag seems to not tickle that cabal bug, and lets git-annex build automatically with the assistant disabled when the webapp build deps are not installed. I hypotehesize that the problem may have involved build-depends nested behind two build flags. Also, cabal clean may need to be run in order for cabal to find the right solution after this change, when building in a directory where cabal configure had been run before. Also moved 3 modules that are needed to build git-annex w/o the assistant out from under the Assistant build flag. Sponsored-by: Brock Spratlen on Patreon --- CHANGELOG | 2 ++ git-annex.cabal | 37 +++-- 2 files changed, 21 insertions(+), 18 deletions(-) diff --git a/CHANGELOG b/CHANGELOG index a9dfdf469b..b833a04e23 100644 --- a/CHANGELOG +++ b/CHANGELOG @@ -6,6 +6,8 @@ git-annex (10.20230215) UNRELEASED; urgency=medium * info: Fix reversion in last release involving handling of unsupported input by continuing to handle any other inputs, before exiting nonzero at the end. + * git-annex.cabal: Move webapp build deps under the Assistant build flag +so git-annex can be built again without yesod etc installed. -- Joey Hess Tue, 14 Feb 2023 14:11:11 -0400 diff --git a/git-annex.cabal b/git-annex.cabal index d3e0193005..349bda66bb 100644 --- a/git-annex.cabal +++ b/git-annex.cabal @@ -377,21 +377,7 @@ Executable git-annex aws (>= 0.20), DAV (>= 1.0), network (>= 3.0.0.0), - network-bsd, - mountpoints, - yesod (>= 1.4.3), - yesod-static (>= 1.5.1), - yesod-form (>= 1.4.8), - yesod-core (>= 1.6.0), - path-pieces (>= 0.2.1), - warp (>= 3.2.8), - warp-tls (>= 3.2.2), - wai, - wai-extra, - blaze-builder, - clientsession, - template-haskell, - shakespeare (>= 2.0.11) + network-bsd CC-Options: -Wall GHC-Options: -Wall -fno-warn-tabs -Wincomplete-uni-patterns Default-Language: Haskell2010 @@ -432,6 +418,21 @@ Executable git-annex if flag(Assistant) && ! os(solaris) && ! os(gnu) CPP-Options: -DWITH_ASSISTANT -DWITH_WEBAPP +Build-Depends: + mountpoints, + yesod (>= 1.4.3), + yesod-static (>= 1.5.1), + yesod-form (>= 1.4.8), + yesod-core (>= 1.6.0), + path-pieces (>= 0.2.1), + warp (>= 3.2.8), + warp-tls (>= 3.2.2), + wai, + wai-extra, + blaze-builder, + clientsession, + template-haskell, + shakespeare (>= 2.0.11) Other-Modules: Assistant Assistant.Alert @@ -447,8 +448,6 @@ Executable git-annex Assistant.Fsck Assistant.Gpg Assistant.Install - Assistant.Install.AutoStart - Assistant.Install.Menu Assistant.MakeRemote Assistant.MakeRepo Assistant.Monad @@ -540,7 +539,6 @@ Executable git-annex Command.Watch Command.WebApp Utility.Mounts - Utility.OSX Utility.Yesod Utility.WebApp @@ -673,6 +671,8 @@ Executable git-annex Annex.WorkerPool Annex.WorkTree Annex.Youtube
Bug#1030317: youtube-dl replacement by yt-dlp prevents git-annex frm using it
Package: git-annex Version: 10.20221003-3 Severity: normal Now when youtube-dl is installed, there is no youtube-dl in path, so git-annex cannot use it. Newer versions of git-annex have been changed to support yt-dlp. This could be fixed by upgrading it, or cherry picking these commits: 5256be61c12fb030fe2eebe2751ee1601a5e7514 43f681d4c15221096975250c0809ded40bf8a5fd -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER, TAINT_WARN Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 git-annex depends on: ii curl7.87.0-1 ii git 1:2.39.1-0.1 ii libc6 2.36-8 ii libffi8 3.4.4-1 ii libgmp102:6.2.1+dfsg1-1.1 ii libmagic1 1:5.44-1 ii libsqlite3-03.40.1-1 ii libyaml-0-2 0.2.5-1 ii netbase 6.4 ii openssh-client 1:9.1p1-2 ii rsync 3.2.7-1 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages git-annex recommends: ii aria2 1.36.0-1 ii bind9-host 1:9.18.10-2 ii git-remote-gcrypt 1.5-1 ii gnupg 2.2.40-1 ii lsof 4.95.0-1 ii nocache1.1-1+b1 Versions of packages git-annex suggests: ii adb 1:29.0.6-22 ii bup 0.33-2 ii libnss-mdns 0.15.1-3 ii magic-wormhole 0.12.0-1 pn tahoe-lafs ii tor 0.4.7.13-1 ii uftp4.10.2-1.1+b2 pn xdot ii yt-dlp 2023.01.06-1 -- no debconf information -- see shy jo signature.asc Description: PGP signature
Bug#1030037: fsck.repair=yes is not documented
Package: initramfs-tools Version: 0.142 Severity: wishlist I wanted automatic fsck for problems on the root filesystem, and it was difficult to disconver that fsck.repair=yes on the kernel cmdline is the way to configure that. initramfs-tools was made to support the same configuration used by systemd-fsck (#783410). So there is a documentation path in that direction, but since I was trying to change the behavior of the initramfs, which I know does not use systemd, I did not think to look in systemd's documentation. -- Package-specific info: -- initramfs sizes -rw-r--r-- 1 root root 50M May 9 2022 /boot/initrd.img-5.17.0-1-amd64 -rw-r--r-- 1 root root 52M Jul 16 2022 /boot/initrd.img-5.18.0-2-amd64 -rw-r--r-- 1 root root 52M Aug 4 13:50 /boot/initrd.img-5.18.0-3-amd64 -rw-r--r-- 1 root root 52M Sep 16 22:14 /boot/initrd.img-5.19.0-1-amd64 -rw-r--r-- 1 root root 52M Oct 19 20:06 /boot/initrd.img-5.19.0-2-amd64 -rw-r--r-- 1 root root 53M Nov 2 12:28 /boot/initrd.img-6.0.0-2-amd64 -rw-r--r-- 1 root root 53M Nov 29 16:40 /boot/initrd.img-6.0.0-5-amd64 -rw-r--r-- 1 root root 54M Jan 14 16:20 /boot/initrd.img-6.0.0-6-amd64 -- /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-6.0.0-6-amd64 root=UUID=9dd447eb-fde2-4d3f-8f1a-b1a52c230084 ro i915.enable_psr=1 -- resume RESUME=none -- /proc/filesystems btrfs ext3 ext2 ext4 fuseblk -- lsmod Module Size Used by pl2303 28672 0 usbserial 65536 1 pl2303 ath10k_pci 49152 0 ath10k_core 450560 1 ath10k_pci ath36864 1 ath10k_core ses20480 0 enclosure 20480 1 ses scsi_transport_sas 49152 1 ses uas32768 0 usb_storage81920 1 uas sctp 446464 30 ip6_udp_tunnel 16384 1 sctp udp_tunnel 24576 1 sctp ccm20480 0 snd_seq_dummy 16384 0 snd_seq90112 1 snd_seq_dummy snd_seq_device 16384 1 snd_seq uinput 20480 0 rfcomm 90112 16 cmac 16384 3 algif_hash 16384 1 algif_skcipher 16384 1 af_alg 36864 6 algif_hash,algif_skcipher bnep 32768 2 snd_soc_skl 184320 0 qrtr 49152 4 btusb 65536 0 snd_soc_hdac_hda 24576 1 snd_soc_skl snd_hda_codec_hdmi 81920 1 snd_hda_ext_core 40960 2 snd_soc_hdac_hda,snd_soc_skl btrtl 28672 1 btusb intel_pmc_core_pltdrv16384 0 snd_soc_sst_ipc20480 1 snd_soc_skl intel_pmc_core 53248 0 snd_soc_sst_dsp40960 1 snd_soc_skl btbcm 24576 1 btusb btintel45056 1 btusb x86_pkg_temp_thermal20480 0 snd_soc_acpi_intel_match73728 1 snd_soc_skl intel_powerclamp 20480 0 coretemp 20480 0 btmtk 16384 1 btusb snd_soc_acpi 16384 2 snd_soc_acpi_intel_match,snd_soc_skl kvm_intel 372736 0 snd_hda_codec_realtek 167936 1 bluetooth 954368 44 btrtl,btmtk,btintel,btbcm,bnep,btusb,rfcomm snd_hda_codec_generic98304 1 snd_hda_codec_realtek snd_soc_core 348160 2 snd_soc_hdac_hda,snd_soc_skl ledtrig_audio 16384 1 snd_hda_codec_generic snd_compress 28672 1 snd_soc_core kvm 1122304 1 kvm_intel irqbypass 16384 1 kvm jitterentropy_rng 16384 1 snd_hda_intel 57344 6 sha512_ssse3 49152 1 snd_intel_dspcfg 36864 2 snd_hda_intel,snd_soc_skl snd_intel_sdw_acpi 20480 1 snd_intel_dspcfg sha512_generic 16384 1 sha512_ssse3 snd_hda_codec 184320 5 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec_realtek,snd_soc_hdac_hda ghash_clmulni_intel16384 0 snd_hda_core 122880 8 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_ext_core,snd_hda_codec,snd_hda_codec_realtek,snd_soc_hdac_hda,snd_soc_skl mac80211 1159168 1 ath10k_core snd_hwdep 16384 1 snd_hda_codec mei_hdcp 24576 0 uvcvideo 131072 0 intel_rapl_msr 20480 0 aesni_intel 393216 4 snd_pcm 159744 9 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_compress,snd_soc_core,snd_soc_skl,snd_hda_core videobuf2_vmalloc 20480 1 uvcvideo libarc416384 1 mac80211 videobuf2_memops 20480 1 videobuf2_vmalloc ctr16384 0 videobuf2_v4l2 36864 1 uvcvideo crypto_simd16384 1 aesni_intel hid_sensor_accel_3d20480 1 videobuf2_common 73728 4 videobuf2_vmalloc,videobuf2_v4l2,uvcvideo,videobuf2_memops hid_sensor_als 20480 0 cryptd 28672 3 crypto_simd,ghash_clmulni_intel rapl 20480 0 hid_sensor_trigger 20480 4 hid_sensor_als,hid_sensor_accel_3d snd_timer
Bug#848578: [PATCH] ts: Enable UTF-8 binary mode for input and output processing (Closes: #848578)
Nicolas Schier wrote: > Are there chances that you still apply such patches? After your call > for adoption: Is there some new maintainer for moreutils already > available? I'm still maintaining moreutils until I find someone else. I am not considering new additions of tools to it any longer. -- see shy jo signature.asc Description: PGP signature
Bug#848578: [PATCH] ts: Enable UTF-8 binary mode for input and output processing (Closes: #848578)
Nicolas Schier wrote: > Enable UTF-8 compatible processing of input and output to correctly output > e.g. > timestamps containing non-latin letters (cp. [1]). > +# Ensure that text read or printed are converted from/to UTF-8. > +binmode STDIN, ':utf8'; > +binmode STDOUT, ':utf8'; > +binmode STDERR, ':utf8'; What if the input is not valid utf8? What if the user's locale is not utf8 and the timestamp contains a character that is not utf8? -- see shy jo signature.asc Description: PGP signature
Bug#1027038: QR code support
Package: impass Version: 0.12.2-1 Severity: wishlist The "pass" password manager has a show QR code option, which makes it easy to transfer a single password to a phone. On the phone, you just copy and paste the password into whatever program. This is perfect for me, since I don't want my phone to have access to all my passwords, but do occasionally need one there. Might it make sense to add a similar feature to impass? I'll leave that to you. I tried to cobble something together from existing parts, and the script below does a decent job. But a feature would make the idea discoverable to users; I would not have thought of doing this if I had not see the feature in "pass". #!/bin/sh buf="$(xsel)" IMPASS_XPASTE=xclip impass gui xsel -b | qr echo "$buf" | xsel -i -- see shy jo signature.asc Description: PGP signature
Bug#1025967: intermittent hang
Package: git-annex
Version: 10.20221003-3
Severity: important
Unfortunately git-annex 10.20220927 introduced a new bug, an
intermittent hang when running a command such as git-annex move,
operating on unlocked files. Approximately 0.1% of such commands
willl hang.
https://git-annex.branchable.com/bugs/git_annex_test_never_exits__63__/
The attached patch fixes the bug. This is also being released in
git-annex version 10.20221212.
--
see shy jo
From 65f9e7a3c73626f17f6f49d0c8266041fd333e93 Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Thu, 8 Dec 2022 14:18:54 -0400
Subject: [PATCH 1/8] fix deadlock in restagePointerFiles
Fix a hang that occasionally occurred during commands such as move.
(A bug introduced in 10.20220927, in
commit 6a3bd283b8af53f810982e002e435c0d7c040c59)
The restage.log was kept locked while running a complex index refresh
action. In an unusual situation, that action could need to write to the
restage log, which caused a deadlock.
The solution is a two-stage process. First the restage.log is moved to a
work file, which is done with the lock held. Then the content of the work
file is read and processed, which happens without the lock being held.
This is all done in a crash-safe manner.
Note that streamRestageLog may not be fully safe to run concurrently
with itself. That's ok, because restagePointerFiles uses it with the
index lock held, so only one can be run at a time.
streamRestageLog does delete the restage.old file at the end without
locking. If a calcRestageLog is run concurrently, it will either see the
file content before it was deleted, or will see it's missing. Either is
ok, because at most this will cause calcRestageLog to report more
work remains to be done than there is.
Sponsored-by: Dartmouth College's Datalad project
---
Annex/Locations.hs| 5 ++
CHANGELOG | 2 +
Logs/File.hs | 21 ++--
Logs/Restage.hs | 54 +++
..._230038504d75704baacd4d3ac750ee95._comment | 8 +++
5 files changed, 75 insertions(+), 15 deletions(-)
create mode 100644 doc/bugs/git_annex_test_never_exits__63__/comment_9_230038504d75704baacd4d3ac750ee95._comment
diff --git a/Annex/Locations.hs b/Annex/Locations.hs
index ace33a5da2..e8361b377e 100644
--- a/Annex/Locations.hs
+++ b/Annex/Locations.hs
@@ -50,6 +50,7 @@ module Annex.Locations (
gitAnnexSmudgeLog,
gitAnnexSmudgeLock,
gitAnnexRestageLog,
+ gitAnnexRestageLogOld,
gitAnnexRestageLock,
gitAnnexMoveLog,
gitAnnexMoveLock,
@@ -385,6 +386,10 @@ gitAnnexSmudgeLock r = gitAnnexDir r P. "smudge.lck"
gitAnnexRestageLog :: Git.Repo -> RawFilePath
gitAnnexRestageLog r = gitAnnexDir r P. "restage.log"
+{- .git/annex/restage.old is used while restaging files in git -}
+gitAnnexRestageLogOld :: Git.Repo -> RawFilePath
+gitAnnexRestageLogOld r = gitAnnexDir r P. "restage.old"
+
gitAnnexRestageLock :: Git.Repo -> RawFilePath
gitAnnexRestageLock r = gitAnnexDir r P. "restage.lck"
diff --git a/Logs/File.hs b/Logs/File.hs
index 7609a40593..56b0c90dda 100644
--- a/Logs/File.hs
+++ b/Logs/File.hs
@@ -13,8 +13,10 @@ module Logs.File (
appendLogFile,
modifyLogFile,
streamLogFile,
+ streamLogFileUnsafe,
checkLogFile,
calcLogFile,
+ calcLogFileUnsafe,
) where
import Annex.Common
@@ -98,7 +100,12 @@ checkLogFile f lck matchf = withSharedLock lck $ bracket setup cleanup go
-- | Folds a function over lines of a log file to calculate a value.
calcLogFile :: RawFilePath -> RawFilePath -> t -> (L.ByteString -> t -> t) -> Annex t
-calcLogFile f lck start update = withSharedLock lck $ bracket setup cleanup go
+calcLogFile f lck start update =
+ withSharedLock lck $ calcLogFileUnsafe f start update
+
+-- | Unsafe version that does not do locking.
+calcLogFileUnsafe :: RawFilePath -> t -> (L.ByteString -> t -> t) -> Annex t
+calcLogFileUnsafe f start update = bracket setup cleanup go
where
setup = liftIO $ tryWhenExists $ openFile f' ReadMode
cleanup Nothing = noop
@@ -125,7 +132,15 @@ calcLogFile f lck start update = withSharedLock lck $ bracket setup cleanup go
-- is running.
streamLogFile :: FilePath -> RawFilePath -> Annex () -> (String -> Annex ()) -> Annex ()
streamLogFile f lck finalizer processor =
- withExclusiveLock lck $ bracketOnError setup cleanup go
+ withExclusiveLock lck $ do
+ streamLogFileUnsafe f finalizer processor
+ liftIO $ writeFile f ""
+ setAnnexFilePerm (toRawFilePath f)
+
+-- Unsafe version that does not do locking, and does not empty the file
+-- at the end.
+streamLogFileUnsafe :: FilePath -> Annex () -> (String -> Annex ()) -> Annex ()
+streamLogFileUnsafe f finalizer processor = bracketOnError setup cleanup go
where
setup = liftIO $ tryWhenExists $ openFile f ReadMode
cleanup Nothing = noop
@@ -135,8 +150,6 @@
Bug#1024226: git-annex: please replace youtube-dl suggests with yt-dlp
Sean Whitton wrote:
> Do you happen to know whether git-annex currently works with youtube-dl
> replaced with yt-dlp? Thanks.
Yes, it does, with this git config:
git config annex.youtube-dl-command yt-dlp
If youtube-dl becomes a wrapper script calling yt-dlp, it would also work
without that config.
I've also changed git-annex to fall back to yt-dlp when youtube-dl is
not in path; see attached patch. Also there was a small problem with
parsing yt-dlp's output that prevented git-annex from displaying
progress; see second attached patch.
--
see shy jo
From 5256be61c12fb030fe2eebe2751ee1601a5e7514 Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Mon, 21 Nov 2022 14:39:26 -0400
Subject: [PATCH] When youtube-dl is not available in PATH, use yt-dlp instead
Debian is going to drop youtube-dl which is not active upstream, and yt-dlp
is the replacement. This will make it be used if youtube-dl gets removed.
If an old version of youtube-dl remains installed, git-annex will still use
it. That might not be desirable, but changing git-annex to use yt-dlp in
preference to youtube-dl when both are installed risks breaking when
the user has annex.youtube-dl-options set to something that is supported
by youtube-dl, but not by yt-dlp.
Sponsored-by: Boyd Stephen Smith Jr. on Patreon
---
Annex/YoutubeDl.hs | 5 +++--
CHANGELOG | 1 +
debian/control | 2 +-
doc/git-annex.mdwn | 7 ---
4 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/Annex/YoutubeDl.hs b/Annex/YoutubeDl.hs
index e466f01eba..ba050d4024 100644
--- a/Annex/YoutubeDl.hs
+++ b/Annex/YoutubeDl.hs
@@ -249,8 +249,9 @@ youtubeDlOpts addopts = do
return (opts ++ addopts)
youtubeDlCommand :: Annex String
-youtubeDlCommand = fromMaybe "youtube-dl" . annexYoutubeDlCommand
- <$> Annex.getGitConfig
+youtubeDlCommand = annexYoutubeDlCommand <$> Annex.getGitConfig >>= \case
+ Just c -> pure c
+ Nothing -> fromMaybe "yt-dlp" <$> liftIO (searchPath "youtube-dl")
supportedScheme :: UrlOptions -> URLString -> Bool
supportedScheme uo url = case parseURIRelaxed url of
diff --git a/CHANGELOG b/CHANGELOG
index d193ceca85..78fa628e4f 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -4,6 +4,7 @@ git-annex (10.20221105) UNRELEASED; urgency=medium
* Sped up the initial scan for annexed files by 21%.
* init: Avoid scanning for annexed files, which can be lengthy in a
large repository. Instead that scan is done on demand.
+ * When youtube-dl is not available in PATH, use yt-dlp instead.
-- Joey Hess Fri, 18 Nov 2022 12:58:06 -0400
diff --git a/debian/control b/debian/control
index 762052186a..ac28ca029c 100644
--- a/debian/control
+++ b/debian/control
@@ -111,7 +111,7 @@ Recommends:
lsof,
gnupg,
bind9-host,
- youtube-dl,
+ yt-dlp,
git-remote-gcrypt (>= 0.20130908-6),
nocache,
aria2,
diff --git a/doc/git-annex.mdwn b/doc/git-annex.mdwn
index 5eca6600c8..60811dce06 100644
--- a/doc/git-annex.mdwn
+++ b/doc/git-annex.mdwn
@@ -1719,8 +1719,8 @@ Remotes are configured using these settings in `.git/config`.
* `annex.youtube-dl-options`
- Options to pass to youtube-dl when using it to find the url to download
- for a video.
+ Options to pass to youtube-dl (or yt-dlp) when using it to find the url
+ to download for a video.
Some options may break git-annex's integration with youtube-dl. For
example, the --output option could cause it to store files somewhere
@@ -1730,7 +1730,8 @@ Remotes are configured using these settings in `.git/config`.
* `annex.youtube-dl-command`
- Command to run for youtube-dl. Default is "youtube-dl".
+ Command to run for youtube-dl. Default is to use "youtube-dl" or
+ if that is not available in the PATH, to use "yt-dlp".
* `annex.aria-torrent-options`
--
2.38.1
From 43f681d4c15221096975250c0809ded40bf8a5fd Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Mon, 21 Nov 2022 15:04:36 -0400
Subject: [PATCH 2/2] Support parsing yt-dpl output to display download
progress
Before this fix, no progress was displayed when yt-dpl was used.
Sponsored-by: Graham Spencer on Patreon
---
Annex/YoutubeDl.hs | 11 ---
CHANGELOG | 1 +
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/Annex/YoutubeDl.hs b/Annex/YoutubeDl.hs
index ba050d4024..c6d0f2253e 100644
--- a/Annex/YoutubeDl.hs
+++ b/Annex/YoutubeDl.hs
@@ -265,8 +265,10 @@ supportedScheme uo url = case parseURIRelaxed url of
_ -> allowedScheme uo u
{- Strategy: Look for chunks prefixed with \r, which look approximately
- - like this:
+ - like this for youtube-dl:
- "ESC[K[download] 26.6% of 60.22MiB at 254.69MiB/s ETA 00:00"
+ - or for yt-dlp, like this:
+ - "\r[download] 1.8% of1.14GiB at1.04MiB/s ETA 18:23"
- Look at the number before "% of " and the number and unit after,
- to determine the number of bytes.
-}
@@ -2
Bug#1021840: mention borg compact in NEWS.Debian
Package: borgbackup Version: 1.2.2-2 Severity: wishlist borg compact is needed to actually free up pruned space, which was not the case with the version in stable. I noticed this only after my backup disk overflowed, and I think that having a mention of it in NEWS.Debian might have made me aware of it earlier. -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.19.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER, TAINT_WARN Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 borgbackup depends on: ii libacl12.3.1-1 ii libc6 2.35-3 ii liblz4-1 1.9.4-1 ii libssl33.0.5-4 ii libxxhash0 0.8.1-1 ii libzstd1 1.5.2+dfsg-1 ii python33.10.6-1 ii python3-msgpack1.0.3-1+b1 ii python3-packaging 21.3-1.1 ii python3-pkg-resources 65.3.0-1.1 Versions of packages borgbackup recommends: ii fuse3 [fuse] 3.11.0-1 ii python3-llfuse 1.4.1+dfsg-2+b1 ii python3-pyfuse3 3.2.1-1+b1 Versions of packages borgbackup suggests: pn borgbackup-doc -- no debconf information -- see shy jo signature.asc Description: PGP signature
Bug#728024: rejected upstream
I have rejected this idea in upstream commit 28ec94ee7fb080ec31a29fe121f2e94bc68e6fba: > I think this is out of scope for git-annex. It's not its place to change > what files git allows to be version controlled. I will not change my mind regarding this. Of course, Debian can patch git-annex to behave differently if they like, but I would strongly advise against it. I recommend this Debian bug report be closed. -- see shy jo signature.asc Description: PGP signature
Bug#789225: seems fixed?
I don't know the version, but I'm sure this was fixed years ago. -- see shy jo signature.asc Description: PGP signature
Bug#1004043: seems fixed
I was able to reproduce this using version 8.20210128. It seems to be fixed in version 10.20220526. I think this was fixed by commit 1cacfd1b199b1a9a093716e04afd7e5ef4bd26a5. While that commit was fixing problems caused by test suite parallization that happened well after this bug was filed, so cannot be the cause of the bug itself, the commit really fixes a deeper concurrency problem that could have also affected older versions of git-annex. -- see shy jo signature.asc Description: PGP signature
Bug#1021206: new upstream release fixes numerous reversions and bugs
Package: git-annex Version: 10.20220724-1 Severity: normal The current git-annex release is 10.20221003, and it fixes a number of reversions and bugs that are present in the version in Debian. I've gathered the main ones here, although if you chose to cherry-pick these commits, you would need to watch out for other commits they may depend on. My recommendation would be to update to the new version instead. This one avoids data loss, although only when someone has an unfortunately placed symlink: ed39979ac8ec6ff2a279939440574927d5cc894a * import: Avoid following symbolic links inside directories being imported. Git integration fixes: a23fd7349fb9cd5b5b0d6c4790d58fe205ca6f3b * Work around bug in git 2.37 that causes a segfault when core.untrackedCache is set, which broke git-annex init. ce65f11de081ec3903ac388c59f5fdf021ccd237 bfa451fc4e621700883fb3b34600bdf71f515a62 * enable-tor: Fix breakage caused by git's fix for CVE-2022-24765. Fixes for regressions in git-annex: 94029995fa2754ed8c22f23cf7bf0157edeeef7a Fix a regression in 10.20220624 that caused git-annex add to crash when there was an unstaged deletion. 8a4cfd4f2d672b57a97e53b6d141378770171e66 Fix crash importing from a directory special remote that contains a broken symlink. 1fe9cf7043e9c24bd8719d45f68f349c0c87e215 * Improve handling of directory special remotes with importtree=yes whose ignoreinode setting has been changed. When getting a file from such a remote, accept the content that would have been accepted with the previous ignoreinode setting. 8d26fdd6709ba341570bf665f1ace0556bdcf5cb * Fix a reversion that prevented git-annex from working in a repository when --git-dir or GIT_DIR is specified to relocate the git directory to somewhere else. (Introduced in version 10.20220525) Other significant bug fixes: 0756f4453d988776e689855851b472f1060889c3 0ffc59d34107a3ee671b90fc7c59ca09c00abbf5 * directory, adb: Fixed a bug with importtree=yes and multiple files in the special remote have the same content, that caused it to refuse to get a file from the special remote, incorrectly complaining that it had changed, due to only accepting the inode+mtime of one file (that was since modified or deleted) and not accepting the inode+mtime of other duplicate files. f1c85ac11b3b7004bf1b1917f9c504622d15e1aa * p2p: Pass wormhole the --appid option before the receive/send command, as it does not accept that option after the command -- see shy jo signature.asc Description: PGP signature
Bug#900173: probably fixed
commit 947d2a10bcf80e74758f65b3cc3fd5ac1bff3fa8 Author: Joey Hess Date: Wed May 12 15:08:03 2021 -0400 assistant: Fix a crash on startup by avoiding using forkProcess ghc 8.8.4 seems to have changed something that broke code that has been successfully using forkProcess since 2012. Likely a change to GC internals. Since forkProcess has never had clear documentation about how to use it safely, avoid using it at all. Instead, when git-annex needs to daemonize itself, re-run the git-annex command, in a new process group and session. -- see shy jo signature.asc Description: PGP signature
Bug#965135: probably fixed in 8.20201007
This bug seems very similar to a known fixed git-annex bug. commit 922621301ae750e9ee86807ae21709e2e5b2d352 Author: Joey Hess Date: Thu Sep 17 17:27:42 2020 -0400 Serialize use of C magic library, which is not thread safe. This fixes failures uploading to S3 when using -J. -- see shy jo signature.asc Description: PGP signature
Bug#1014628: FWD: Re: git-annex arm 32-bit builds
I was looking at this bug the other day trying to determine why git-annex was not in testing, and did not realize it was due to this dbus issue. My mail below digs into it, if the issue is still happening. - Forwarded message from Joey Hess - Date: Mon, 23 May 2022 12:48:21 -0400 From: Joey Hess To: Sean Whitton Subject: Re: git-annex arm 32-bit builds Sean Whitton wrote: > git-annex is failing on Debian's autobuilders for armel and armhf. It > looks like an actual type error rather than the linker failing or > something like that \o/ > > Would you be able to take a look, please? > > https://buildd.debian.org/status/fetch.php?pkg=git-annex=armel=10.20220504-1=1652058911=0 What fun.. addMatch comes from libghc-dbus-dev, and has type addMatch :: Client -> MatchRule -> (DBus.Internal.Message.Signal -> IO ()) -> IO SignalHandler -- Defined in ‘DBus.Client’ I have verified in an armel (testing) chroot that it has that type. FWIW, git-annex is building successfully for me in that chroot. That has the identical package version 1.2.16-1+b1 that the autobuild log has. Somehow, the autobuilder is seeing a different type for it despite the same version of the same package being installed. The type seems to be :: ByteString. I also looked at the source of the haskell package and it does not have any conditional compilation or other way for addMatch to have that type, that I can see. This seems to point to the autobuilder having some manually hacked up version of the haskell library installed on it that somehow overrides the package. Or, ghc is somehow getting massively confused and is finding the wrong symbol or something like that. It would be interesting, I think to find out what is in that ByteString! I suppose you could upload a package with something like this in its rules: ghc -e 'import DBus.Client' -e 'print DBus.Client.addMatch' || true -- see shy jo - End forwarded message - -- see shy jo signature.asc Description: PGP signature
Bug#1019462: started checking for mail in the middle of tab completion
Package: bash Version: 5.2~rc2-2 Severity: normal For example, here I entered "cd sr" joey@darkstar:~>cd srYou have mail in /home/joey/Maildir c/ I think this behavior started on this upgrade: 2022-09-07 15:08:53 upgrade bash:amd64 5.1-6.1 5.2~rc2-2 -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER, TAINT_DIE, TAINT_WARN Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 bash depends on: ii base-files 12.2 ii debianutils 5.7-0.3 ii libc62.34-7 ii libtinfo66.3+20220423-2 Versions of packages bash recommends: ii bash-completion 1:2.11-6 Versions of packages bash suggests: pn bash-doc -- no debconf information -- see shy jo signature.asc Description: PGP signature
Bug#1019215: "AGE" in man page is unclear
Package: mail-expire Version: 0.9.1 Severity: normal mail-expire AGE FILES... What is this "AGE"? I am not going to run a program that messes with my email to find out. The rest of the man page does not say. I found the answer in mail-expire --help Usage: /usr/bin/mail-expire [ options ] DAYS FILES where DAYS is an integer specifying the maximum age of a mail in days and The man page should say that it's age in days. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') merged-usr: no Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-1-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 mail-expire depends on: ii libmail-mbox-messageparser-perl 1.5111-2 ii perl 5.34.0-5 mail-expire recommends no packages. mail-expire suggests no packages. -- no debconf information -- see shy jo
Bug#992995: mail-expire: Add support to skip new or unread marked mails
I agree, I would also need this in order to replace my useage of archivemail with mail-expire. I'm probably not unusual in having certian mailboxes full of messages that need to remain in there despite being old or unread. -- see shy jo signature.asc Description: PGP signature
Bug#1014007: too old for current ghc
Package: cabal-install Version: 3.0.0.0-3+b1 Severity: normal cabal build now complains about an unsupported ghc version Warning: Unknown/unsupported 'ghc' version detected (Cabal 3.0.1.0 supports 'ghc' version < 8.10): /usr/bin/ghc is version 9.0.2 -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER, TAINT_WARN Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 cabal-install depends on: ii ghc 9.0.2-2 ii libc6 2.33-7 ii libffi8 3.4.2-4 ii libgmp10 2:6.2.1+dfsg1-1 ii zlib1g1:1.2.11.dfsg-4 Versions of packages cabal-install recommends: ii curl 7.84.0-1 ii wget 1.21.3-1+b2 cabal-install suggests no packages. -- no debconf information -- see shy jo signature.asc Description: PGP signature
Bug#1013898: significantly slower than 3.0.17.4-3
Package: vlc Version: 3.0.17.4-4 Severity: normal I'm seeing only a few frames per second with -4 on 1080p H264 video. After downgrading to -3, it's back to ~60 FPS. This is the last part of the output of -4. The VA-API stuff seems relevant somehow since the changelog says that was disabled in this version, but I'm only guessing. [7fb0d8028210] gl gl: Initialized libplacebo v4.192.1 (API v192) libva info: VA-API version 1.14.0 libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so libva info: Found init function __vaDriverInit_1_14 libva info: va_openDriver() returns 0 [7fb0f0c1f940] avcodec decoder: Using OpenGL/VAAPI backend for VDPAU for hardware decoding With -3, the output is the same except for the last line, which is: [7fcc00c1d530] avcodec decoder: Using Intel iHD driver for Intel(R) Gen Graphics - 22.4.3 () for hardware decoding -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER, TAINT_WARN Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 vlc depends on: ii vlc-bin 3.0.17.4-4 ii vlc-plugin-base 3.0.17.4-4 ii vlc-plugin-qt3.0.17.4-4 ii vlc-plugin-video-output 3.0.17.4-4 Versions of packages vlc recommends: pn vlc-l10n pn vlc-plugin-access-extra pn vlc-plugin-notify pn vlc-plugin-samba ii vlc-plugin-skins2 3.0.17.4-4 pn vlc-plugin-video-splitter pn vlc-plugin-visualization Versions of packages vlc suggests: pn vlc-plugin-fluidsynth pn vlc-plugin-jack ii vlc-plugin-pipewire3-2 pn vlc-plugin-svg Versions of packages libvlc-bin depends on: ii libc62.33-7 ii libvlc5 3.0.17.4-4 Versions of packages libvlc5 depends on: ii libc62.33-7 ii libvlccore9 3.0.17.4-4 Versions of packages libvlc5 recommends: ii libvlc-bin 3.0.17.4-4 Versions of packages libvlccore8 depends on: ii dpkg 1.21.8 ii libc62.33-7 ii libdbus-1-3 1.14.0-1 ii libidn11 1.33-3 Versions of packages libvlccore8 recommends: ii libproxy-tools 0.4.17-2 Versions of packages vlc-bin depends on: ii libc6 2.33-7 ii libvlc-bin 3.0.17.4-4 ii libvlc5 3.0.17.4-4 Versions of packages vlc-plugin-base depends on: ii liba52-0.7.4 0.7.4-20 ii libarchive13 3.6.0-1 ii libaribb24-0 1.0.3-2 ii libasound2 1.2.6.1-2+b1 ii libass9 1:0.16.0-1 ii libavahi-client3 0.8-6 ii libavahi-common3 0.8-6 ii libavc1394-0 0.5.4-5 ii libavcodec59 7:5.0.1-3 ii libavformat597:5.0.1-3 ii libavutil57 7:5.0.1-3 ii libbluray2 1:1.3.1-2 ii libc62.33-7 ii libcairo21.16.0-5 ii libcddb2 1.3.2-7 ii libchromaprint1 1.5.1-2+b1 ii libdav1d61.0.0-2 ii libdbus-1-3 1.14.0-1 ii libdc1394-25 2.2.6-4 ii libdca0 0.0.7-2 ii libdvbpsi10 1.3.3-1 ii libdvdnav4 6.1.1-1 ii libdvdread8 6.1.3-1 ii libebml5 1.4.2-2 ii libfaad2 2.10.0-2 ii libflac8 1.3.4-2 ii libfontconfig1 2.13.1-4.4 ii libfreetype6 2.12.1+dfsg-3 ii libfribidi0 1.0.8-2.1 ii libgcc-s112.1.0-4 ii libgcrypt20 1.10.1-2 ii libglib2.0-0 2.72.2-2 ii libgnutls30 3.7.6-2 ii libgpg-error01.45-2 ii libharfbuzz0b2.7.4-1+b1 ii libixml101:1.8.4-2 ii libjpeg62-turbo 1:2.1.2-1 ii libkate1 0.4.1-11 ii liblirc-client0 0.10.1-7 ii liblua5.2-0 5.2.4-2 ii libmad0 0.15.1b-10 ii libmatroska7 1.6.3-2 ii libmpcdec6 2:0.1~r495-2 ii libmpeg2-4 0.5.1-9 ii libmpg123-0 1.29.3-1 ii libmtp9 1.1.19-1 ii libncursesw6
Bug#1010278: xterm_set_titles is broken
I have the same problem, which causes a broken display when eg, deleting messages. I can confirm that setting TERM=xterm-p370 avoids the problem. -- see shy jo signature.asc Description: PGP signature
Bug#1010397: Fwd: Bug#1010397: git-annex sync fails in rsync remotes with rsync 3.2.4-1
Fixed with attached patch.
--
see shy jo
From 43701759a32e38613c61de6dc923c24069f435d6 Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Tue, 3 May 2022 12:12:25 -0400
Subject: [PATCH] disable shellescape for rsync 3.2.4
rsync 3.2.4 broke backwards-compatability by preventing exposing filenames
to the shell. Made the rsync and gcrypt special remotes detect this and
disable shellescape.
An alternative fix would have been to always set RSYNC_OLD_ARGS=1.
Which would avoid the overhead of probing rsync --help for each affected
remote. But that is really very fast to run, and it seemed better to switch
to the modern code path rather than keeping on using the bad old code path.
Sponsored-by: Tobias Ammann on Patreon
---
CHANGELOG | 3 +++
Remote/GCrypt.hs | 3 ++-
Remote/Rsync.hs| 27 ++-
doc/special_remotes/rsync.mdwn | 15 ---
4 files changed, 35 insertions(+), 13 deletions(-)
diff --git a/CHANGELOG b/CHANGELOG
index 263da8e6e..6f53e3e1a 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -11,6 +11,9 @@ git-annex (10.20220323) UNRELEASED; urgency=medium
* Fix test failure on NFS when cleaning up gpg temp directory.
* Fix a build failure with ghc 9.2.2.
Thanks, gnezdo for the patch.
+ * rsync 3.2.4 broke backwards-compatability by preventing exposing
+filenames to the shell. Made the rsync and gcrypt special remotes
+detect this and disable shellescape. Closes: #1010397
-- Joey Hess Mon, 28 Mar 2022 14:46:10 -0400
diff --git a/Remote/GCrypt.hs b/Remote/GCrypt.hs
index 9662e75d4..0b120806a 100644
--- a/Remote/GCrypt.hs
+++ b/Remote/GCrypt.hs
@@ -130,7 +130,8 @@ gen' r u c gc rs = do
cst <- remoteCost gc $
if repoCheap r then nearlyCheapRemoteCost else expensiveRemoteCost
let (rsynctransport, rsyncurl, accessmethod) = rsyncTransportToObjects r gc
- let rsyncopts = Remote.Rsync.genRsyncOpts c gc rsynctransport rsyncurl
+ protectsargs <- liftIO Remote.Rsync.probeRsyncProtectsArgs
+ let rsyncopts = Remote.Rsync.genRsyncOpts protectsargs c gc rsynctransport rsyncurl
let this = Remote
{ uuid = u
, cost = cst
diff --git a/Remote/Rsync.hs b/Remote/Rsync.hs
index 81d60311e..e7e9ff740 100644
--- a/Remote/Rsync.hs
+++ b/Remote/Rsync.hs
@@ -16,7 +16,8 @@ module Remote.Rsync (
withRsyncScratchDir,
rsyncRemoteConfigs,
genRsyncOpts,
- RsyncOpts
+ RsyncOpts,
+ probeRsyncProtectsArgs,
) where
import Annex.Common
@@ -36,6 +37,7 @@ import Remote.Rsync.RsyncUrl
import Crypto
import Utility.Rsync
import Utility.CopyFile
+import Utility.Process.Transcript
import Messages.Progress
import Utility.Metered
import Types.Transfer
@@ -74,7 +76,8 @@ gen r u rc gc rs = do
cst <- remoteCost gc expensiveRemoteCost
(transport, url) <- rsyncTransport gc $
fromMaybe (giveup "missing rsyncurl") $ remoteAnnexRsyncUrl gc
- let o = genRsyncOpts c gc transport url
+ protectsargs <- liftIO probeRsyncProtectsArgs
+ let o = genRsyncOpts protectsargs c gc transport url
let islocal = rsyncUrlIsPath $ rsyncUrl o
return $ Just $ specialRemote c
(fileStorer $ store o)
@@ -124,6 +127,18 @@ gen r u rc gc rs = do
, remoteStateHandle = rs
}
+-- | Since 3.2.4, rsync protects filenames from being exposed to the shell.
+newtype RsyncProtectsArgs = RsyncProtectsArgs Bool
+
+probeRsyncProtectsArgs :: IO RsyncProtectsArgs
+probeRsyncProtectsArgs = do
+ (helpoutput, _) <- processTranscript "rsync" ["--help"] Nothing
+ -- The --old-args option was added to disable the new arg
+ -- protection, so use it to detect when that feature is supported
+ -- by rsync, rather than parsing versions.
+ return (RsyncProtectsArgs $ "--old-args" `isInfixOf` helpoutput)
+
+
-- Things used by genRsyncOpts
rsyncRemoteConfigs :: [RemoteConfigFieldParser]
rsyncRemoteConfigs =
@@ -131,15 +146,17 @@ rsyncRemoteConfigs =
(FieldDesc "set to no to avoid usual shell escaping (not recommended)")
]
-genRsyncOpts :: ParsedRemoteConfig -> RemoteGitConfig -> Annex [CommandParam] -> RsyncUrl -> RsyncOpts
-genRsyncOpts c gc transport url = RsyncOpts
+genRsyncOpts :: RsyncProtectsArgs -> ParsedRemoteConfig -> RemoteGitConfig -> Annex [CommandParam] -> RsyncUrl -> RsyncOpts
+genRsyncOpts (RsyncProtectsArgs protectsargs) c gc transport url = RsyncOpts
{ rsyncUrl = url
, rsyncOptions = appendtransport $ opts []
, rsyncUploadOptions = appendtransport $
opts (remoteAnnexRsyncUploadOptions gc)
, rsyncDownloadOptions = appendtransport $
opts (remoteAnnexRsyncDownloadOptions gc)
- , rsyncShellEscape = fromMaybe True (getRemoteConfigValue shellEscapeField c)
+ , rsyncShellEscape = if protectsargs
+ then False
+ else fromMaybe True (getRemoteConfigValue shellEscapeField c)
}
where
appendtransport l = (++ l) <$> transport
diff --git a/doc/special_remotes/rsync.mdwn b/doc/special_remotes/rsync.mdwn
index 96e452b10.
Bug#1010397: Fwd: Bug#1010397: git-annex sync fails in rsync remotes with rsync 3.2.4-1
> > git-annex enableremote foo shellescape=no I've confirmed that this workaround works. Also, the client's version of rsync is what matters. 3.2.3 client and 3.2.4 server does not have the problem. -- see shy jo signature.asc Description: PGP signature
Bug#1010397: Fwd: Bug#1010397: git-annex sync fails in rsync remotes with rsync 3.2.4-1
Sean Whitton wrote: > > git-annex can be configured to not do its own shell escaping when accessing > > a rsync special remote. If your remote is named "foo", you can configure it > > that way as follows: > > > > git-annex enableremote foo shellescape=no > > Thanks for looking into it. Do you see this as a workaround or what > people using newer rsync should use going forward? That's a workaround. If it works, perhaps git-annex could probe the rsync version and do the same thing automatically. Depends on it only the local rsync version matters, not the remote one. -- see shy jo signature.asc Description: PGP signature
Bug#1010397: Fwd: Bug#1010397: git-annex sync fails in rsync remotes with rsync 3.2.4-1
Joey Hess wrote: > The rsync command that git-annex runs has a trailing close quote, as > seen in the first excerpt above. But rsync then complains about the path > with that close quote removed. > > I'm having a hard time not seeing this as a bug in rsync. # NEWS for rsync 3.2.4 (15 Apr 2022) ## Changes in this version: ### BEHAVIOR CHANGES: - A new form of arg protection was added that works similarly to the older [`--protect-args`](rsync.1#opt) (`-s`) option but in a way that avoids breaking things like rrsync (the restricted rsync script): rsync now uses backslash escaping for sending "shell-active" characters to the remote shell. This includes spaces, so fetching a remote file via a simple quoted filename value now works by default without any extra quoting This change must be the cause of the problem. git-annex can be configured to not do its own shell escaping when accessing a rsync special remote. If your remote is named "foo", you can configure it that way as follows: git-annex enableremote foo shellescape=no -- see shy jo signature.asc Description: PGP signature
Bug#1010397: Fwd: Bug#1010397: git-annex sync fails in rsync remotes with rsync 3.2.4-1
> [2022-04-30 13:00:20.39881781] (Utility.Process) process [1635096] read: > rsync ["-e","'ssh' '-S' '../.git/annex/ssh/user@host-key' '-o' > 'ControlMaster=auto' '-o' 'ControlPersist=yes' '-l' 'user' > '-T'","--progress","--inplace", > "user@host-key:/backup/dspace/repositories/repository.git/ff7/84a/'GPGHMACSHA1--f5a2f4c1b3562feff26d0d1d6db70298087fd851/GPGHMACSHA1--f5a2f4c1b3562feff26d0d1d6db70298087fd851'" > ,"../.git/annex/tmp/GPGHMACSHA1--f5a2f4c1b3562feff26d0d1d6db70298087fd851"] > rsync: [sender] change_dir > "/backup/dspace/repositories/repository.git/ff7/84a/'GPGHMACSHA1--f5a2f4c1b3562feff26d0d1d6db70298087fd851" > failed: No such file or directory (2) The rsync command that git-annex runs has a trailing close quote, as seen in the first excerpt above. But rsync then complains about the path with that close quote removed. I'm having a hard time not seeing this as a bug in rsync. -- see shy jo signature.asc Description: PGP signature
Bug#1009649: libc upgrade caused connection failure after "ssh debug1: expecting" SSH2_MSG_KEX_ECDH_REPLY
Package: openssh-server Version: 1:9.0p1-1 Severity: normal I upgraded libc6 on a armhf box running a rather stale version of testing, due to installing some package that needed the new version: 2022-04-12 18:23:06 upgrade libc6:armhf 2.32-4 2.33-7 After this partial upgrade, sshing to the host failed. With -v, the last line displayed was: ssh debug1: expecting SSH2_MSG_KEX_ECDH_REPLY I fell down a rabbit hole of old bug reports about connections failing (or hanging) at that point, which seemed to indicate a MTU or other networking problem. Notably though, even ssh localhost failed like that, and it was not hanging like in old reports such as [1], so this seemed like a slightly different problem. There was nothing useful logged in the journal. I resolved the problem with this upgrade: 2022-04-13 11:38:09 upgrade openssh-server:armhf 1:8.4p1-6 1:9.0p1-1 So it seems that something about openssh 8.4p1-6 was broken by glibc 2.33. I'm filing this bug because it seems at least possible that whatever incompatability that was is still lurking, and will be triggered again by a future glibs upgrade. Kernel: Linux honeybee 5.14.0-2-armmp-lpae #1 SMP Debian 5.14.9-2 (2021-10-03) armv7l GNU/Linux -- see shy jo [1] https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1254085 signature.asc Description: PGP signature
Bug#856870: me too
Version: 1.5.2-2.1 I'm now seeing this bug. Oddly, I did not see the bug back in 2020, when I was successfully using arduino-mk. But now: make do_upload make[1]: Entering directory '/home/joey/src/arduino-copilot/Examples/Blink' /usr/share/arduino/hardware/tools/avr/bin/avrdude -q -V -p atmega328p -C /usr/share/arduino/hardware/tools/avr/etc/avrdude.conf -D -c arduino -b 115200 -P /dev/ttyUSB0 \ -U flash:w:build-uno/Blink_.hex:i avrdude: can't open config file "/usr/share/arduino/hardware/tools/avr/etc/avrdude.conf": No such file or directory avrdude: error reading system wide configuration file "/usr/share/arduino/hardware/tools/avr/etc/avrdude.conf" make[1]: *** [/usr/share/arduino/Arduino.mk:1462: do_upload] Error 1 make[1]: Leaving directory '/home/joey/src/arduino-copilot/Examples/Blink' make: *** [/usr/share/arduino/Arduino.mk:1455: upload] Error 2 I think it was probably fixed in the interim and then broken again, since the path is different than in the original bug report. My workaround: root@darkstar:/usr/share/arduino/hardware/tools/avr>mkdir etc root@darkstar:/usr/share/arduino/hardware/tools/avr>cd etc root@darkstar:/usr/share/arduino/hardware/tools/avr/etc>ln -s /etc/avrdude.conf -- see shy jo signature.asc Description: PGP signature
Bug#1004965: -1: unknown option error from whiptail
Colin Watson wrote: > On Fri, Feb 04, 2022 at 09:24:25AM -0400, Joey Hess wrote: > > -1: unknown option > > debconf: whiptail output the above errors, giving up! > > Hm, I *think* this can only happen if the height or width of the dialog > computed by Debconf::FrontEnd::Dialog::showtext somehow ends up being > negative, but I've never seen this happen. How did you run into this? > Do you have any idea how I might reproduce it? Hmm, I know the height of the console was smaller than usual. My best guess at dimensions were COLUMNS=55 LINES=11 or perhaps LINES=17 I'm not sure which package or template was involved, but I think it involved checking the running kernel, or something like that, probably in a trigger based on some other surrounding context I should have included in the bug report but now only remember vaguely. Sorry I don't have a clearer idea of how to reproduce it. -- see shy jo signature.asc Description: PGP signature
Bug#997933: me too
Seeing this bug after upgrade. My imap server is dovecot. -- see shy jo signature.asc Description: PGP signature
Bug#1004965: -1: unknown option error from whiptail
Package: debconf Version: 1.5.79 Severity: normal -1: unknown option debconf: whiptail output the above errors, giving up! -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_USER, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 debconf depends on: ii perl-base 5.32.1-6 Versions of packages debconf recommends: ii apt-utils 2.3.15 ii debconf-i18n 1.5.79 Versions of packages debconf suggests: pn debconf-doc pn debconf-kde-helper pn debconf-utils ii libgtk3-perl 0.038-1 pn libnet-ldap-perl ii libterm-readline-gnu-perl 1.42-2 ii perl 5.32.1-6 ii whiptail 0.52.21-5+b1 -- debconf information excluded -- see shy jo signature.asc Description: PGP signature
Bug#934926: update
The simple fact is that as an upstream author who used the debian locations because they were the ones that worked on my system, I get bug reports from users of other systems that it's not right for wider uses of zsh. And Debian seems to be leaving it up to me to deal with it, which just makes me want to not include zsh completions, honestly. (I got another bug report about this today, for etckeeper.) -- see shy jo signature.asc Description: PGP signature
Bug#1002965: opens last ebook when asked to open corrupt file
Package: fbreader Version: 0.12.10dfsg2-5 Severity: normal touch foo.epub fbreader foo.epub This will display whatever ebook you last had open in fbreader, without any indication that there's a problem with the file it was asked to open. In some situations, this can be very confusing behavior. -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_USER, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 fbreader depends on: ii libc6 2.32-4 ii libsqlite3-0 3.36.0-2 ii libstdc++6 11.2.0-12 ii libzlcore0.13 0.12.10dfsg2-5 ii libzltext0.13 0.12.10dfsg2-5 ii libzlui-gtk0.12.10dfsg2-5 Versions of packages fbreader recommends: ii sensible-utils 0.0.17 fbreader suggests no packages. -- no debconf information -- see shy jo signature.asc Description: PGP signature
Bug#1001724: /usr/bin/firefox is difficult to wrap
Package: firefox
Version: 94.0.2-1
Severity: normal
I have a ~/bin/firefox wrapper script ahead of the usual firefox in PATH.
#!/bin/sh
MOZ_USE_XINPUT2=1 /usr/bin/firefox "$@"
This has a very surprising behavior, because /usr/bin/firefox contains:
FIREFOX="$(command -v firefox)"
[ -x "$FIREFOX.real" ] && exec "$FIREFOX.real" "$@"
So FIREFOX gets set to ~/bin/firefox and there is no ~/bin/firefox.real
to run. So instead it falls through and runs firefox-esr which I also happen
to have installed. Since firefox-esr doesn't use my usual firefox
config, my wrapper script effectively breaks the configuration.
The workaround was to change my wrapper script to this:
#!/bin/sh
MOZ_USE_XINPUT2=1 PATH=/usr/bin:$PATH exec firefox "$@"
Although notice that this can turn into an infinite loop if firefox
is somehow not in /usr/bin anymore. Also it prevents firefox from running
any other wrapper scripts I might have in ~/bin when starting a program
such as a PDF viewer. So this is a suboptimal workaround.
I don't know if there is a reason you are not using $0 or not simply
hardcoding the path to firefox.real, either seems like a way to avoid this.
-- Package-specific info:
-- Extensions information
Name: Abstract — Balanced theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled
Name: Abstract — Bold theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled
Name: Abstract — Soft theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled
Name: Add-ons Search Detection
Location:
/home/joey/.mozilla/firefox/darkstar.default/features/{24d1e21e-7f68-43e8-b88d-0ac0a57147bf}/addons-search-detect...@mozilla.com.xpi
Status: enabled
Name: Amazon.com
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled
Name: Bing
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled
Name: Cheers — Balanced theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled
Name: Cheers — Bold theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled
Name: Cheers — Soft theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled
Name: Dark theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled
Name: DoH Roll-Out
Location: /usr/lib/firefox/browser/features/doh-roll...@mozilla.org.xpi
Package: firefox
Status: enabled
Name: DuckDuckGo
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled
Name: eBay
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled
Name: Elemental — Balanced theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled
Name: Elemental — Bold theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled
Name: Elemental — Soft theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled
Name: Firefox Alpenglow theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled
Name: Firefox Multi-Account Containers
Location: ${PROFILE_EXTENSIONS}/@testpilot-containers.xpi
Status: enabled
Name: Firefox Screenshots
Location: /usr/lib/firefox/browser/features/screensh...@mozilla.org.xpi
Package: firefox
Status: enabled
Name: Form Autofill
Location: /usr/lib/firefox/browser/features/formautof...@mozilla.org.xpi
Package: firefox
Status: enabled
Name: Foto — Balanced theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled
Name: Foto — Bold theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled
Name: Foto — Soft theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled
Name: Google
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled
Name: Graffiti — Balanced theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled
Name: Graffiti — Bold theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled
Name: Graffiti — Soft theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled
Name: Light theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled
Name: Lush — Balanced theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled
Name: Lush — Bold theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled
Name: Lush — Soft theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled
Name: Picture-In-Picture
Location: /usr/lib/firefox/browser/features/pictureinpict...@mozilla.org.xpi
Package: firefox
Status: enabled
Name: Proxy Failover
Location: /usr/lib/firefox/browser/features/proxy-failo...@mozilla.com.xpi
Package: firefox
Status: enabled
Name: Reset Search Defaults
Location:
Bug#996962: enable CONFIG_USB_SERIAL_XR
Package: src:linux
Version: 5.10.46-4
Severity: wishlist
I am currently having to use the out of tree Exar USB Serial Driver
(xr_usb_serial_common) to talk to a modbus communication cable.
Last year, a reimplementation of that driver finally made mainline,
as CONFIG_USB_SERIAL_XR.
Looking at the metadata for CONFIG_USB_SERIAL_XR, it seems to support
my device:
vendor: 04e2 ("Exar Corp."), product: 1411, interface class: 02
("Communications")
lsusb -v:
Bus 001 Device 005: ID 04e2:1411 Exar Corp. XR21B1411
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2
bDeviceProtocol 1 Interface Association
bMaxPacketSize064
idVendor 0x04e2 Exar Corp.
idProduct 0x1411
bcdDevice0.01
iManufacturer 1 Exar Corp.
iProduct2 XR21B1411
iSerial 3 G9107376441
bNumConfigurations 1
Also worth noting that Ubuntu has included the original Exar serial
module in their kernel tree for some time.
--
see shy jo
signature.asc
Description: PGP signature
Bug#996934: install failure without /etc/flash-kernel/machine pre-existing
Package: flash-kernel Version: 3.104 Severity: normal I have some image building scripts that installed flash-kernel in a chroot (on unrelated hardware; user mode qemu), then configured /etc/flash-kernel/machine, then ran flash-kernel. That used to work (in 2018), and now fails: Creating config file /etc/default/flash-kernel with new version Setting up flash-kernel (3.104) ... Processing triggers for libc-bin (2.32-4) ... Processing triggers for initramfs-tools (0.140) ... Warning: root device does not exist Unsupported platform ''. run-parts: /etc/initramfs/post-update.d//flash-kernel exited with return code 1 dpkg: error processing package initramfs-tools (--configure): installed initramfs-tools package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: initramfs-tools This left initramfs-tools half-configured, and apt-get install flash-kernel exited nonzero. It seems unreasonable for installing the flash-kernel package to leave the system in this state when a file that is only documented in that package does not exist before the package is installed. Also "Unsupported platform ''" is not the best error message. -- see shy jo signature.asc Description: PGP signature
Bug#995403: cert_fingerprint not working for self-signed certificate after upgrade
Package: offlineimap Version: 7.3.3+dfsg1-1+0.0~git20210825.4ca9c75+dfsg-1 Severity: normal ERROR: Unknown SSL protocol connecting to host 'kitenet.net' for repository 'kite'. OpenSSL responded: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self signed certificate (_ssl.c:1129) Traceback: File "/usr/share/offlineimap3/offlineimap/accounts.py", line 298, in syncrunner self.__sync() File "/usr/share/offlineimap3/offlineimap/accounts.py", line 374, in __sync remoterepos.getfolders() File "/usr/share/offlineimap3/offlineimap/repository/IMAP.py", line 686, in getfolders imapobj = self.imapserver.acquireconnection() File "/usr/share/offlineimap3/offlineimap/imapserver.py", line 661, in acquireconnection raise OfflineImapError(reason, severity, exc_info()[2]) My previously-working .offlineimaprc has: cert_fingerprint = a8bda27c49ba6390e477960014caa672e2beb01d with no other ssl configs. I have had to downgrade back to 7.3.3+dfsg1-1+0.0~git20210225.1e7ef9e+dfsg-4 to get offlineimap working. -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 offlineimap depends on: ii offlineimap3 0.0~git20210825.4ca9c75+dfsg-1 offlineimap recommends no packages. offlineimap suggests no packages. -- no debconf information -- see shy jo signature.asc Description: PGP signature
Bug#995129: Acknowledgement (upgrade of libc or something resulted in postfix/smtp[3114]: fatal: unknown service: smtp/tcp)
root@kite:~>sh -x /usr/lib/postfix/configure-instance.sh
+ INSTANCE=
+ SYNC_CHROOT=y
+ test -r /etc/default/postfix
+ [ X = X ]
+ POSTCONF=postconf -o inet_interfaces=
+ + tr A-Z a-z
postconf -o inet_interfaces= -hx myorigin
+ MYORIGIN=kitenet.net
+ [ Xkitenet.net != Xkitenet.net ]
+ [ Xkitenet.net = Xubuntu.com ]
+ [ Xkitenet.net = Xdebian.org ]
+ postconf -o inet_interfaces= -hx config_directory
+ config_dir=/etc/postfix
+ postconf -o inet_interfaces=+ cut -d. -f1
-hx mail_version
+ MAJOR_VER=3
+ [ 3 -ge 3 ]
+ CHROOT_TEST=[yY]
+ awk /^[0-9a-z]/ && ($5 ~ "[yY]") { print "y"; exit} /etc/postfix/master.cf
+ NEED_CHROOT=
+ [ -n ]
This happens despite master.cf containing:
smtp unix - - - - - smtp
relay unix - - - - - smtp
It seems that it only treats 'y' as being a chroot, but appears to not
match how postfix is parsing my file, which treats '-' as being a chroot
too. I'm basing this on changing that to a 'n' having fixed my problem.
So why is postfix parsing my master.cf that way? My file starts like this:
#
# Postfix master process configuration file. For details on the format
# of the file, see the master(5) manual page (command: "man 5 master" or
# on-line: http://www.postfix.org/master.5.html).
#
# Do not forget to execute "postfix reload" after editing this file.
#
# ==
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==
smtp inet n - n - - smtpd
#smtp inet n - - - 1 postscreen
#smtpd pass - - - - - smtpd
#dnsblog unix - - - - 0 dnsblog
#tlsproxy unix - - - - 0 tlsproxy
Could it be that something about this is making postfix parse it
with its old parser, that defaulted to enabling chroot for '-'?
Sep 26 16:32:41 kite postfix/master[24015]: /etc/postfix/master.cf: line 50:
using backwards-compatible default setting chroot=y
Aha. My main.cf does not have a value for compatibility_level,
so it defaults to level 0, which behaves that way.
My postfix configs are quite old, addmittedly, but it seems
that if you're going to parse master.cf, it needs to be done fully
compatibly with how postfix parses it..
(I also noticed BTW, that /etc/init.d/postfix's running() check
always thinks postfix is running, even when it's not.
Somehow /usr/lib/postfix/sbin/master -t exits nonzero
even when no daemon is running. This would prevent updating
the chroot ever if that init script were actually used, but with
systemd it is not.)
--
see shy jo
signature.asc
Description: PGP signature
Bug#995129: upgrade of libc or something resulted in postfix/smtp[3114]: fatal: unknown service: smtp/tcp
Package: postfix Version: 3.5.6-1+b1 Severity: normal This server is following testing, and has automatic upgrades enabled. On Sep 22, all outgoing mail ceased flowing. I have been able to work around the problem by disabling chrooting for smtp in master.cf. /var/spool/postfix/etc/services seems ok, it was last modified in 2020 and has: smtp25/tcp mail It does seem like it's out of date compared to /etc/services. Looking at the logs, the error first occurred at 6:32. At very close to the same time, there was this automatic upgrade: 2021-09-22 06:30:46 upgrade libc6:amd64 2.31-17 2.32-4 Other packages were upgraded too, but a libc upgrade folowed by a nsswitch problem 2 minutes later seems probably related. Looking at /var/spool/postfix/lib/x86_64-linux-gnu/ I notice it's kind of a mess: -rw-r--r-- 1 root root 99K May 7 2020 libgcc_s.so.1 -rw-r--r-- 1 root root 31K Sep 21 2015 libnss_compat-2.19.so -rw-r--r-- 1 root root 31K Feb 17 2016 libnss_compat-2.21.so -rw-r--r-- 1 root root 31K Jun 26 2016 libnss_compat-2.22.so -rw-r--r-- 1 root root 31K Aug 23 2016 libnss_compat-2.23.so -rw-r--r-- 1 root root 31K Aug 26 2017 libnss_compat-2.24.so -rw-r--r-- 1 root root 31K Dec 16 2017 libnss_compat-2.25.so -rw-r--r-- 1 root root 31K Jan 26 2018 libnss_compat-2.26.so -rw-r--r-- 1 root root 39K Oct 29 2018 libnss_compat-2.27.so -rw-r--r-- 1 root root 39K May 1 2019 libnss_compat-2.28.so -rw-r--r-- 1 root root 39K Feb 4 2020 libnss_compat-2.29.so -rw-r--r-- 1 root root 39K Mar 25 2020 libnss_compat-2.30.so lrwxrwxrwx 1 root root 21 Mar 25 2020 libnss_compat.so.2 -> libnss_compat-2.30.so -rw-r--r-- 1 root root 23K Sep 21 2015 libnss_dns-2.19.so -rw-r--r-- 1 root root 23K Feb 17 2016 libnss_dns-2.21.so -rw-r--r-- 1 root root 23K Jun 26 2016 libnss_dns-2.22.so -rw-r--r-- 1 root root 23K Aug 23 2016 libnss_dns-2.23.so -rw-r--r-- 1 root root 23K Aug 26 2017 libnss_dns-2.24.so -rw-r--r-- 1 root root 23K Dec 16 2017 libnss_dns-2.25.so -rw-r--r-- 1 root root 23K Jan 26 2018 libnss_dns-2.26.so -rw-r--r-- 1 root root 27K Oct 29 2018 libnss_dns-2.27.so -rw-r--r-- 1 root root 27K May 1 2019 libnss_dns-2.28.so -rw-r--r-- 1 root root 27K Feb 4 2020 libnss_dns-2.29.so -rw-r--r-- 1 root root 27K Mar 25 2020 libnss_dns-2.30.so lrwxrwxrwx 1 root root 18 Mar 25 2020 libnss_dns.so.2 -> libnss_dns-2.30.so -rw-r--r-- 1 root root 47K Sep 21 2015 libnss_files-2.19.so -rw-r--r-- 1 root root 47K Feb 17 2016 libnss_files-2.21.so -rw-r--r-- 1 root root 47K Jun 26 2016 libnss_files-2.22.so -rw-r--r-- 1 root root 47K Aug 23 2016 libnss_files-2.23.so -rw-r--r-- 1 root root 47K Aug 26 2017 libnss_files-2.24.so -rw-r--r-- 1 root root 47K Dec 16 2017 libnss_files-2.25.so -rw-r--r-- 1 root root 47K Jan 26 2018 libnss_files-2.26.so -rw-r--r-- 1 root root 55K Oct 29 2018 libnss_files-2.27.so -rw-r--r-- 1 root root 55K May 1 2019 libnss_files-2.28.so -rw-r--r-- 1 root root 51K Feb 4 2020 libnss_files-2.29.so -rw-r--r-- 1 root root 51K Mar 25 2020 libnss_files-2.30.so lrwxrwxrwx 1 root root 18 Mar 25 2020 libnss_files.so.2 -> libnss_files-2.30.so Same for the ooutside the chroot. of these libs in /lib/x86_64-linux-gnu/ lrwxrwxrwx 1 root root 20 Sep 19 14:46 /lib/x86_64-linux-gnu/libnss_files.so.2 -> libnss_files-2.32.so This makes me wonder a) why are the old ones not getting cleaned out b) why are the new ones not copied in yet, and c) might there be libnss version skew with libc? -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 postfix depends on: ii adduser3.118 ii cpio 2.13+dfsg-7 ii debconf [debconf-2.0] 1.5.77 ii dpkg 1.20.9 ii e2fsprogs 1.46.4-1 ii libc6 2.32-4 ii libdb5.3 5.3.28+dfsg1-0.8 ii libicu67 67.1-7 ii libnsl21.3.0-2 ii libsasl2-2 2.1.27+dfsg-2.1 ii libssl1.1 1.1.1l-1 ii lsb-base 11.1.0 ii netbase6.3 ii ssl-cert 1.1.0+nmu1 Versions of packages postfix recommends: ii ca-certificates 20210119 ii python3 3.9.2-3 Versions of packages postfix suggests: ii bsd-mailx [mail-reader]8.1.2-0.20180807cvs-2 ii dovecot-core [dovecot-common] 1:2.3.16+dfsg1-3 ii libsasl2-modules 2.1.27+dfsg-2.1 ii mutt [mail-reader] 2.0.5-4.1 pn postfix-cdb pn postfix-doc pn postfix-ldap pn postfix-lmdb pn postfix-mysql ii postfix-pcre
Bug#993807: fixes needing backporting for "content changed while it was being sent" and "failed to send content to remote"
Package: git-annex Version: 8.20210223-2 Severity: normal There have been some two related fixes upstream since this version to bugs that affect a sizable number of git-annex users, and make git-annex fairly unusable. (Unable to send content to remotes, which a crucial part of many workflows. I'll leave you to decide the real severity.) These problems were introduced in the upgrade to git-annex version 8. I noticed Debian needs to be fixed because a user reported both of problems after upgrading their Debian system to this version. https://git-annex.branchable.com/bugs/sync_failing_after_debian_bullseye_upgrade/ The original bug report for both issues was https://git-annex.branchable.com/bugs/__34__failed_to_send_content_to_remote__34__/ The "content changed while it was being sent" was fixed in git-annex 8.20210803, in commit 3b5a3e168d8decd196509ad582ad4b8795d979a6 The "failed to send content to remote" was fixed in the same version, in a series of commits. I think all of these commits are necessary but have not verified. 73e0cbbb19703f08daf783d8788370726f852162 a30656037459b4006ba6ec12bd1cb4e705d04ea8 817ccbbc47156c24aade4c6c4dc0c195332a991e d2aead67bd17faac753ccf41964789a3a62ddaf3 It may be that this second commit sequence also fixes the prior problem, since I think they had the same root cause. But I have not tested git-annex without both fixes. -- see shy jo signature.asc Description: PGP signature
Bug#992712: apt-secure does not document how to accept new release info
Package: apt Version: 2.2.4 Severity: normal E: Repository 'http://ftp.us.debian.org/debian stable InRelease' changed its 'Codename' value from 'buster' to 'bullseye' N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details. The apt-secure man page is a detailed explanation of how apt security works, but it does not tell the user what to do when they want to accept the change of a release's codename. So the probably somewhat large numbers of users who will see this message will be left puzzling over 1300 words of documentation that is not useful for what they probably want to do. This could be fixed by making the apt-secure man page include, in its "INFORMATION CHANGES" section, a mention of apt-get update --allow-releaseinfo-change and/or of apt's ability to prompt the user in this situation. -- Package-specific info: -- apt-config dump -- APT ""; APT::Architecture "amd64"; APT::Build-Essential ""; APT::Build-Essential:: "build-essential"; APT::Install-Recommends "1"; APT::Install-Suggests "0"; APT::Sandbox ""; APT::Sandbox::User "_apt"; APT::Authentication ""; APT::Authentication::TrustCDROM "true"; APT::NeverAutoRemove ""; APT::NeverAutoRemove:: "^firmware-linux.*"; APT::NeverAutoRemove:: "^linux-firmware$"; APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$"; APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$"; APT::VersionedKernelPackages ""; APT::VersionedKernelPackages:: "linux-.*"; APT::VersionedKernelPackages:: "kfreebsd-.*"; APT::VersionedKernelPackages:: "gnumach-.*"; APT::VersionedKernelPackages:: ".*-modules"; APT::VersionedKernelPackages:: ".*-kernel"; APT::Never-MarkAuto-Sections ""; APT::Never-MarkAuto-Sections:: "metapackages"; APT::Never-MarkAuto-Sections:: "contrib/metapackages"; APT::Never-MarkAuto-Sections:: "non-free/metapackages"; APT::Never-MarkAuto-Sections:: "restricted/metapackages"; APT::Never-MarkAuto-Sections:: "universe/metapackages"; APT::Never-MarkAuto-Sections:: "multiverse/metapackages"; APT::Move-Autobit-Sections ""; APT::Move-Autobit-Sections:: "oldlibs"; APT::Move-Autobit-Sections:: "contrib/oldlibs"; APT::Move-Autobit-Sections:: "non-free/oldlibs"; APT::Move-Autobit-Sections:: "restricted/oldlibs"; APT::Move-Autobit-Sections:: "universe/oldlibs"; APT::Move-Autobit-Sections:: "multiverse/oldlibs"; APT::LastInstalledKernel "5.10.0-7-amd64"; APT::Update ""; APT::Update::Post-Invoke-Success ""; APT::Update::Post-Invoke-Success:: "/usr/bin/test -e /usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && /usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call --system --dest org.freedesktop.PackageKit --object-path /org/freedesktop/PackageKit --timeout 4 --method org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo > /dev/null"; APT::Architectures ""; APT::Architectures:: "amd64"; APT::Architectures:: "i386"; APT::Compressor ""; APT::Compressor::. ""; APT::Compressor::.::Name "."; APT::Compressor::.::Extension ""; APT::Compressor::.::Binary ""; APT::Compressor::.::Cost "0"; APT::Compressor::zstd ""; APT::Compressor::zstd::Name "zstd"; APT::Compressor::zstd::Extension ".zst"; APT::Compressor::zstd::Binary "false"; APT::Compressor::zstd::Cost "60"; APT::Compressor::lz4 ""; APT::Compressor::lz4::Name "lz4"; APT::Compressor::lz4::Extension ".lz4"; APT::Compressor::lz4::Binary "false"; APT::Compressor::lz4::Cost "50"; APT::Compressor::gzip ""; APT::Compressor::gzip::Name "gzip"; APT::Compressor::gzip::Extension ".gz"; APT::Compressor::gzip::Binary "gzip"; APT::Compressor::gzip::Cost "100"; APT::Compressor::gzip::CompressArg ""; APT::Compressor::gzip::CompressArg:: "-6n"; APT::Compressor::gzip::UncompressArg ""; APT::Compressor::gzip::UncompressArg:: "-d"; APT::Compressor::xz ""; APT::Compressor::xz::Name "xz"; APT::Compressor::xz::Extension ".xz"; APT::Compressor::xz::Binary "xz"; APT::Compressor::xz::Cost "200"; APT::Compressor::xz::CompressArg ""; APT::Compressor::xz::CompressArg:: "-6"; APT::Compressor::xz::UncompressArg ""; APT::Compressor::xz::UncompressArg:: "-d"; APT::Compressor::bzip2 ""; APT::Compressor::bzip2::Name "bzip2"; APT::Compressor::bzip2::Extension ".bz2"; APT::Compressor::bzip2::Binary "bzip2"; APT::Compressor::bzip2::Cost "300"; APT::Compressor::bzip2::CompressArg ""; APT::Compressor::bzip2::CompressArg:: "-6"; APT::Compressor::bzip2::UncompressArg ""; APT::Compressor::bzip2::UncompressArg:: "-d"; APT::Compressor::lzma ""; APT::Compressor::lzma::Name "lzma"; APT::Compressor::lzma::Extension ".lzma"; APT::Compressor::lzma::Binary "xz"; APT::Compressor::lzma::Cost "400"; APT::Compressor::lzma::CompressArg ""; APT::Compressor::lzma::CompressArg:: "--format=lzma"; APT::Compressor::lzma::CompressArg:: "-6"; APT::Compressor::lzma::UncompressArg ""; APT::Compressor::lzma::UncompressArg:: "--format=lzma"; APT::Compressor::lzma::UncompressArg:: "-d"; Dir "/"; Dir::State "var/lib/apt"; Dir::State::lists "lists/";
Bug#992472: fails to open file with relative path
Package: bookworm Version: 1.1.2+git20210715-1 Severity: normal I ran com.github.babluboy.bookworm foo.epub and it complained: [WARNING 22:12:14.238713] bookworm.vala:681: EBook not found at provided location:foo.epub [FATAL 22:12:14.244095] [GLib-GIO] g_file_query_exists: assertion 'G_IS_FILE(file)' failed Using an absolute path worked. This is rather surprising behavior. -- System Information: Debian Release: 11.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 bookworm depends on: ii dconf-gsettings-backend [gsettings-backend] 0.38.0-2 ii html2text1.3.2a-28 ii libc62.31-12 ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1 ii libgee-0.8-2 0.20.4-1 ii libglib2.0-0 2.66.8-1 ii libgranite5 5.5.0-1+b1 ii libgtk-3-0 3.24.24-4 ii libpango-1.0-0 1.46.2-3 ii libpoppler-glib8 20.09.0-3.1 ii libsoup2.4-1 2.72.0-2 ii libsqlite3-0 3.34.1-3 ii libwebkit2gtk-4.0-37 2.32.1-2 ii libxml2 2.9.10+dfsg-6.7 ii poppler-utils20.09.0-3.1 ii python3 3.9.2-3 ii unar 1.10.1-2+b6 ii unzip6.0-26 bookworm recommends no packages. bookworm suggests no packages. -- no debconf information -- see shy jo signature.asc Description: PGP signature
Bug#981341: bup split does not honor the -q flag
This bug affects git-annex, which runs bup split -q, possibly multiple of them concurrently, and so gets its output messed up by the undesired output. Note that the output goes to stderr, so it cannot even be safely piped to /dev/null without potentally swallowing error messages. I'm fairly sure this is a reversion in bup. -- see shy jo signature.asc Description: PGP signature
Bug#986947: backported patch to fix bug importing from a special remote into a subdirectory more than one level deep
Package: git-annex Version: 8.20210223-1 Severity: normal Since I assume git-annex is frozen at this version, and a subsequent version fixed a relatively bad bug, I've put together this backport of a patch. I'd rate this just below a data loss bug, since it can end up generating trees that significantly confuse git. https://git-annex.branchable.com/bugs/Importing_into_nested_directory_overwrites_files__63__/ -- see shy jo From 4611813ef1a6ecc86fafc095a324ef0cfe7427e7 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 26 Mar 2021 16:01:55 -0400 Subject: [PATCH] Fix bug importing from a special remote into a subdirectory more than one level deep Which generated unusual git trees that could confuse git merge, since they incorrectly had 2 subtrees with the same name. Root of the bug was a) not testing that at all! but also b) confusing graftdirs, which contains eg "foo/bar" with non-recursively read trees, which would contain eg "bar" when reading a subtree of "foo". It's worth noting that Annex.Import uses graftTree, but it really shouldn't have needed to. Eg, when importing into foo/bar from a remote, it's enough to generate a tree of foo/bar/x, foo/bar/y, and does not include other files that are at the top of the master branch. It uses graftTree, so it does include the other files, as well as the foo/bar tree. git merge will do the same thing for both trees. With that said, switching it away from graftTree would result in another import generating a new commit that seems to delete files that were there in a previous commit, so it probably has to keep using graftTree since it used it before. --- Git/Tree.hs | 26 +-- diff --git a/Git/Tree.hs b/Git/Tree.hs index 325508e46..6a43cff0e 100644 --- a/Git/Tree.hs +++ b/Git/Tree.hs @@ -306,43 +306,43 @@ graftTree' -> Repo -> MkTreeHandle -> IO Sha -graftTree' subtree graftloc basetree repo hdl = go basetree graftdirs +graftTree' subtree graftloc basetree repo hdl = go basetree subdirs graftdirs where - go tsha (topmostgraphdir:restgraphdirs) = do + go tsha (subdir:restsubdirs) (topmostgraphdir:restgraphdirs) = do Tree t <- getTree LsTree.LsTreeNonRecursive tsha repo - t' <- case partition isabovegraft t of + let abovegraftpoint i = gitPath i == gitPath subdir + t' <- case partition abovegraftpoint t of + -- the graft point is not already in the tree, + -- so graft it in, keeping the existing tree + -- content ([], _) -> do graft <- graftin (topmostgraphdir:restgraphdirs) return (graft:t) - -- normally there can only be one matching item - -- in the tree, but it's theoretically possible - -- for a git tree to have multiple items with the - -- same name, so process them all (matching, rest) -> do newshas <- forM matching $ \case RecordedSubTree tloc tsha' _ | null restgraphdirs -> return $ RecordedSubTree tloc subtree [] | otherwise -> do - tsha'' <- go tsha' restgraphdirs + tsha'' <- go tsha' restsubdirs restgraphdirs return $ RecordedSubTree tloc tsha'' [] _ -> graftin (topmostgraphdir:restgraphdirs) return (newshas ++ rest) mkTree hdl t' - go _ [] = return subtree - - isabovegraft i = beneathSubTree i graftloc || gitPath i == gitPath graftloc + go _ _ [] = return subtree graftin t = recordSubTree hdl $ graftin' t graftin' [] = RecordedSubTree graftloc subtree [] graftin' (d:rest) | d == graftloc = graftin' [] | otherwise = NewSubTree d [graftin' rest] - + + subdirs = splitDirectories $ gitPath graftloc + -- For a graftloc of "foo/bar/baz", this generates -- ["foo", "foo/bar", "foo/bar/baz"] graftdirs = map (asTopFilePath . toInternalGitPath . encodeBS) $ - mkpaths [] $ splitDirectories $ gitPath graftloc + mkpaths [] subdirs mkpaths _ [] = [] mkpaths base (d:rest) = (joinPath base d) : mkpaths (base ++ [d]) rest -- 2.30.2 signature.asc Description: PGP signature
Bug#985663: utf-8 decoding error
Sudip Mukherjee wrote: > There seems to be a version discrepancy. > > offlineimap3 is still old and thats the reason you still have that old stack > trace. > I think, for now just doing "apt-get update && apt-get install offlineimap3" > should fix your issue. Ah, I didn't remember there was a transitional package. Upgrading did fix it. I think I may have put offlineimap3 on hold in the past due to other bugs in it, perhaps that's why it didn't get upgraded. -- see shy jo signature.asc Description: PGP signature
Bug#985663: utf-8 decoding error
Package: offlineimap Version: 7.3.3+dfsg1-1+0.0~git20210225.1e7ef9e+dfsg-3 Severity: normal Copy message UID -347 (1/347) local: -> kite:INBOX ERROR: Copying message -347 [acc: joey] 'utf-8' codec can't decode byte 0xa0 in position 3278: invalid start byte ERROR: while syncing [account joey] 'utf-8' codec can't decode byte 0xa0 in position 3278: invalid start byte ERROR: ERROR in syncfolder for joey folder : Traceback (most recent call last): File "/usr/share/offlineimap3/offlineimap/accounts.py", line 666, in syncfolder localfolder.syncmessagesto(remotefolder, statusfolder) File "/usr/share/offlineimap3/offlineimap/folder/Base.py", line 1186, in syncmessagesto action(dstfolder, statusfolder) File "/usr/share/offlineimap3/offlineimap/folder/Base.py", line 1013, in __syncmessagesto_copy self.copymessageto(uid, dstfolder, statusfolder, register=0) File "/usr/share/offlineimap3/offlineimap/folder/Base.py", line 902, in copymessageto message = self.getmessage(uid) File "/usr/share/offlineimap3/offlineimap/folder/Maildir.py", line 262, in getmessage retval = file.read() File "/usr/lib/python3.9/codecs.py", line 322, in decode (result, consumed) = self._buffer_decode(data, self.errors, final) UnicodeDecodeError: 'utf-8' codec can't decode byte 0xa0 in position 3278: invalid start byte 'utf-8' codec can't decode byte 0xa0 in position 3278: invalid start byte This seems the same as bug #981485 but I've upgraded to this version that is supposed to fix that, and still happening. It's not clear to me which message is causing the problem. Especially since it seems to be trying to upload a message from inbox, but I normally don't make changes to inbox that would need to upload a new message. (I'm very surprised that offlineimap would be concerning itself with the encoding of emails at all.) -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_USER, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 offlineimap depends on: ii offlineimap3 0.0~git20210105.00d395b+dfsg-3 offlineimap recommends no packages. offlineimap suggests no packages. -- no debconf information -- see shy jo signature.asc Description: PGP signature
Bug#984832: has generally unnecessary dependency on python
Package: etckeeper Version: 1.18.16-1 Severity: normal I have systems that would not have python installed except etckeeper depends on it. The dependency is for brz if I understand correctly. However, etckeeper does not use brz by default, and its dependencies let the user choose their vcs without pulling in all the dependencies of all the others, except for in this case. Since the python module needs to be registered using python in order to be used, and the postinst does that, just removing the dep would be a problem. Maybe split the package and replace depends | brz | with etckeeper-brz? -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_USER, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 etckeeper depends on: ii brz3.1.0-8 ii debconf [debconf-2.0] 1.5.74 ii git1:2.30.1-1 ii python33.9.1-1 Versions of packages etckeeper recommends: ii cron [cron-daemon] 3.0pl1-136 Versions of packages etckeeper suggests: ii sudo 1.9.5p2-2 -- debconf information excluded -- see shy jo signature.asc Description: PGP signature
Bug#955299: fixed upstream
This is fixed in version 0.26. http://joeyh.name/code/mpdtoys/ -- see shy jo signature.asc Description: PGP signature
Bug#981338: self signed ssl cert unusuable after upgrade
Sudip Mukherjee wrote:
> I was looking into this error and this has been caused by an upstream
> commit which is supposed to be an improvement for new users. More
> details at
> https://github.com/OfflineIMAP/offlineimap3/issues/41#issuecomment-778798223.
>
> The attached patch should fix this.
>
> @Joey Hess It will be great if you test the patch and confirm if it
> fixes your problem.
It does, but only after I fixed an unrelated problem:
OfflineIMAP 7.3.0
Licensed under the GNU GPL v2 or any later version (with an OpenSSL exception)
imaplib2 v3.05, Python v3.9.1+, OpenSSL 1.1.1i 8 Dec 2020
Account sync joey:
*** Processing account joey
Establishing connection to kitenet.net:993 (kite)
ERROR: While attempting to sync account 'joey'
sequence item 2: expected str instance, bytes found
*** Finished account 'joey' in 0:03
ERROR: Exceptions occurred during the run!
ERROR: While attempting to sync account 'joey'
sequence item 2: expected str instance, bytes found
Traceback:
File "/usr/share/offlineimap3/offlineimap/accounts.py", line 298, in
syncrunner
self.__sync()
File "/usr/share/offlineimap3/offlineimap/accounts.py", line 374, in __sync
remoterepos.getfolders()
File "/usr/share/offlineimap3/offlineimap/repository/IMAP.py", line 646, in
getfolders
imapobj = self.imapserver.acquireconnection()
File "/usr/share/offlineimap3/offlineimap/imapserver.py", line 592, in
acquireconnection
self.__authn_helper(imapobj)
File "/usr/share/offlineimap3/offlineimap/imapserver.py", line 449, in
__authn_helper
if func(imapobj):
File "/usr/share/offlineimap3/offlineimap/imapserver.py", line 375, in
__authn_plain
imapobj.authenticate('PLAIN', self.__plainhandler)
File "/usr/lib/python3/dist-packages/imaplib2.py", line 691, in authenticate
typ, dat = self._simple_command('AUTHENTICATE', mechanism.upper())
File "/usr/lib/python3/dist-packages/imaplib2.py", line 1684, in
_simple_command
return self._command_complete(self._command(name, *args), kw)
File "/usr/lib/python3/dist-packages/imaplib2.py", line 1404, in _command
literal = literator(data, rqb)
File "/usr/lib/python3/dist-packages/imaplib2.py", line 2247, in process
ret = self.mech(self.decode(data))
File "/usr/share/offlineimap3/offlineimap/imapserver.py", line 217, in
__plainhandler
retval = NULL.join((authz, authc, passwd))
Which seems to be caused by remotepassfile being set, pointing at a file
that contained a password in plain text. I unset that and it prompted
for the password and worked.
(Also I remember seeing this "expected str instance" failure before,
when I was trying lots of config file changes to work around the ssl cert
problem, so one of those changes must have worked at the time. I don't
remember what change it was.)
--
see shy jo
signature.asc
Description: PGP signature
Bug#981338: self signed ssl cert unusuable after upgrade
Sudip Mukherjee wrote: > I have also faced the same issue while trying to debug another issue and > this happens when 'cert_fingerprint' is used. I had to use 'sslcacertfile' > in my setup. > Anyways, this has been reported upstream already at > 'https://github.com/OfflineIMAP/offlineimap3/issues/41'. Thanks for finding the upstream bug report. I did try setting sslcacertfile before, and was not able to get it to work. However, I also can't get it to work the the older version of offlineimap, so either there must be something about my cert chain that doesn't work with that, or perhaps I was putting the wrong thing in the file. -- see shy jo signature.asc Description: PGP signature
Bug#981338: self signed ssl cert unusuable after upgrade
Package: offlineimap Version: 7.3.3+dfsg1-1+0.0~git20210105.00d395b+dfsg-2 Severity: normal ERROR: Exceptions occurred during the run! ERROR: Unknown SSL protocol connecting to host 'kitenet.net' for repository 'kite'. OpenSSL responded: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self signed certificate (_ssl.c:1123) I was using offlineimap 7.3.3+dfsg1-1 and this cert was working fine. It is not expired and the server has not changed. I have tried all available ssl configuration settings to try to work around the problem, but nothing seems to work. What I was using before, which works with the old version, is: type = IMAP ssl = yes remotehost = kitenet.net remoteuser = joey cert_fingerprint = a8bda27c49ba6390e477960014caa672e2beb01d Of course, the server could be changed to use a lets encrypt ssl cert instead of the old self-signed cert, but I'm currently unable to access and fix all the users' devices that would need to be tweaked to work with a new cert. I've currently downgraded offlineimap, but hope there's some solution that makes self-signed ssl certs work again. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_USER, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 offlineimap depends on: ii offlineimap3 0.0~git20210105.00d395b+dfsg-2 offlineimap recommends no packages. offlineimap suggests no packages. -- no debconf information -- see shy jo signature.asc Description: PGP signature
Bug#980397: support standard rsync urls
Patch attached, tested lightly.
I noticed that rclone URIs are also nonstandard but since I don't have
any experience with rclone, I didn't try to fix that.
--
see shy jo
From 18f9ecfa6aa1a0ff580855e7ace87651529f64fd Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Wed, 20 Jan 2021 11:23:01 -0400
Subject: [PATCH] support more standard rsync URIs
This adds support for "rsync://user@host/path", which is a valid URI,
and will be parseable by URI parsers, unlike the old "rsync://user@host:path",
which at least some URI parsers will reject due to the ":path" looking
like an unparseable port number. The old nonstandard URI form is also
still accepted.
Note that, the path in the new URI form is not relative to the home
directory, but absolute. This is necessary because "/path" looks like an
absolute directory, and there needs to be a way to specify an absolute
directory. Something like "/~/path" could be added to specify the home
directory, but seems like an unncessary complication.
Note that rsync supports rsync:// URIs itself, but those communicate
with a rsync daemon on its own port, rather than via ssh. gcrypt already
was using rsync:// to denote rsync over ssh, and this does not change
that. So, the url has to be rewritten from "rsync://user@host/path"
to the rsync location "user@host:/path"
I used this test suite while developing the rather complicated sed
expression, to make sure I did not break handling of the old URI form.
set -e
test $(rsynclocation "rsync://host/path/foo") = host:/path/foo
test $(rsynclocation "rsync://host:path/foo") = host:path/foo
test $(rsynclocation "rsync://user@host/path/foo") = user@host:/path/foo
test $(rsynclocation "rsync://user@host:path/foo") = user@host:path/foo
test $(rsynclocation "rsync://user@host/path:foo") = user@host:/path:foo
test $(rsynclocation "rsync://user@host:path:foo") = user@host:path:foo
test $(rsynclocation "rsync://user@host/path:foo/bar") = user@host:/path:foo/bar
test $(rsynclocation "rsync://user@host:path:foo/bar") = user@host:path:foo/bar
test $(rsynclocation "rsync://user@host/path/foo/bar") = user@host:/path/foo/bar
test $(rsynclocation "rsync://user@host:path/foo/bar") = user@host:path/foo/bar
---
README.rst| 14 --
git-remote-gcrypt | 14 ++
2 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/README.rst b/README.rst
index 097c05c..a86d567 100644
--- a/README.rst
+++ b/README.rst
@@ -40,7 +40,7 @@ Quickstart
Create an encrypted remote by pushing to it::
-git remote add cryptremote gcrypt::rsync://example.com:repo
+git remote add cryptremote gcrypt::rsync://example.com/repo
git push cryptremote master
> gcrypt: Setting up new repository
> gcrypt: Remote ID is :id:7VigUnLVYVtZx8oir34R
@@ -116,7 +116,7 @@ Examples
How to set up a remote for two participants::
-git remote add cryptremote gcrypt::rsync://example.com:repo
+git remote add cryptremote gcrypt::rsync://example.com/repo
git config remote.cryptremote.gcrypt-participants "KEY1 KEY2"
git push cryptremote master
@@ -163,10 +163,12 @@ Performance
repository hosting service like Gitolite, GitHub or GitLab.
rsync URIs
-Note that the URI format for the rsync backend is, regretably,
-non-standard. git-remote-gcrypt uses ``rsync://user@host:path``
-whereas plain rsync uses either ``user@host:path`` or
-``rsync://user@host/path``.
+The URI format for the rsync backend is ``rsync://user@host/path``,
+which translates to the rsync location ``user@host:/path``,
+accessed over ssh. Note that the path is absolute, not relative to the
+home directory. An earlier non-standard URI format is also supported:
+``rsync://user@host:path``, which translates to the rsync location
+``user@host:path``
rclone backend
In addition to adding the rclone backend as a remote with URI like
diff --git a/git-remote-gcrypt b/git-remote-gcrypt
index 5c15b60..c519bf8 100755
--- a/git-remote-gcrypt
+++ b/git-remote-gcrypt
@@ -149,6 +149,12 @@ line_count()
xecho "$#"
}
+# Convert URI in standard or nonstandard form to rsync's user@host:path
+rsynclocation ()
+{
+ echo "${1#rsync://}" | sed 's/\(^[^:/]*\)\//\1:\//'
+}
+
## gitception part
# Fetch giturl $1, file $2
@@ -229,7 +235,7 @@ GET()
(exec 0>&-; curl -s -S -k "$1/$2") > "$3"
elif isurl rsync "$1"
then
- (exec 0>&-; rsync -I -W "${1#rsync://}"/"$2" "$3" >&2)
+ (exec 0>&-; rsync -I -W "$(rsynclocation "$1")"/"$2" "$3" >&2)
elif isurl rclone "$1"
then
(exec 0>&-; rclone copyto "${1#rclone://}"/"$2" "$3&qu
Bug#980397: support standard rsync urls
Package: git-remote-gcrypt Version: 1.3-1 Severity: normal rsync URIs Note that the URI format for the rsync backend is, regretably, non-standard.git-remote-gcrypt uses rsync://user@host:path whereas plain rsync useseitheruser@host:pathor rsync://user@host/path. That needs to be supported for backwards compatability, I suppose, but is there any reason not to let gcrypt::rsync://user@host/path be used too? -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_USER, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 git-remote-gcrypt depends on: ii git 1:2.30.0-1 ii gpg 2.2.20-1 Versions of packages git-remote-gcrypt recommends: ii curl 7.74.0-1 ii gnupg 2.2.20-1 ii rsync 3.2.3-3 Versions of packages git-remote-gcrypt suggests: pn rclone -- no debconf information -- see shy jo signature.asc Description: PGP signature
Bug#972846: rate limit
Upstream issue: http://github-backup.branchable.com/todo/rate_limit_exceeded_immediately_on_first_API_request/ (Also I am no longer maintaining github-backup.) -- see shy jo signature.asc Description: PGP signature
Bug#977894: gui is broken, python3-xdo
Daniel Kahn Gillmor wrote: > thanks for the diagnosis, Joey! this looks like a change between the > ctypes module between python 3.8 and 3.9. I'll fix it in python3-xdo, > and hopefully that will resolve your problem. Independent of getting this fixed, I think it's concerning that ctypes falls back to looking for library files in cwd when a shared library is unavailable. That has potential to be part of a security exploit chain, although I have not dug deeply enough to know if it's exploitable. -- see shy jo signature.asc Description: PGP signature
Bug#977894: gui is broken, python3-xdo
Daniel Kahn Gillmor wrote:
> I'm seeing comparable weird behavior, including the invocations of
> ldconfig and gcc, even if i don't see your particular failure. yikes.
> But, a simple file like this produces the same behavior (with ldconfig
> and gcc):
>
> ~~~
> #!/usr/bin/python3
> import xdo
> ~~~
> I still don't understand why we're seeing that xdo isn't found, though.
> Perhaps you could try applying the diff below to __main__.py in impass,
> removing liblibc.a, and trying impass gui again?
>
> -except:
> +except ModuleNotFoundError:
> This is testing the hypothesis that there's some other error that
> happens when importing the xdo module, and we're imagining that it means
> the module isn't found.
Yes, I get the same backtrace from both the 2 line script and the
modified impass:
joey@darkstar:~>impass gui
Traceback (most recent call last):
File "/usr/bin/impass", line 11, in
load_entry_point('impass==0.12', 'console_scripts', 'impass')()
File "/usr/lib/python3/dist-packages/impass/__main__.py", line 620, in main
func(args)
File "/usr/lib/python3/dist-packages/impass/__main__.py", line 350, in gui
import xdo
File "/usr/lib/python3/dist-packages/xdo/__init__.py", line 8, in
from ._xdo import libxdo as _libxdo
File "/usr/lib/python3/dist-packages/xdo/_xdo.py", line 14, in
libc = ctypes.CDLL(ctypes.util.find_library('libc'))
File "/usr/lib/python3.9/ctypes/util.py", line 341, in find_library
_get_soname(_findLib_gcc(name)) or _get_soname(_findLib_ld(name))
File "/usr/lib/python3.9/ctypes/util.py", line 147, in _findLib_gcc
if not _is_elf(file):
File "/usr/lib/python3.9/ctypes/util.py", line 99, in _is_elf
with open(filename, 'br') as thefile:
FileNotFoundError: [Errno 2] No such file or directory: b'liblibc.a'
And so I modified /usr/lib/python3/dist-packages/xdo/_xdo.py as follows,
which fixed the problem:
- libc = ctypes.CDLL(ctypes.util.find_library('libc'))
+ libc = ctypes.CDLL(ctypes.util.find_library('c'))
--
see shy jo
signature.asc
Description: PGP signature
Bug#977894: gui is broken, python3-xdo
Jameson Graef Rollins wrote: > Hey, Joey. Sorry you're having trouble. What is the error when you try > to execute "impass gui"? It should pop up a small context dialog > window. That winodw is not appearing? Is there a python exception? No gui. All I see it the output I pasted. > What does your environment look like? You don't happen to be running > wayland, do you? No, X with xfce and xmonad. -- see shy jo signature.asc Description: PGP signature
Bug#977894: gui is broken, python3-xdo
Daniel Kahn Gillmor wrote: > this is odd, and it makes me think that there's some python module path > failure happening. if it can't find the system xdo, maybe it also can't > find the gobject introspection libraries that are used to interface with > GTK? > > is it possible that this is being run from within some sort of python > virtualenv? No, definitely not. It is possible something got broken on disk (SSH) somehow. -- see shy jo signature.asc Description: PGP signature
Bug#977894: gui is broken, python3-xdo
Package: impass Version: 0.12.2-1 Severity: normal > impass gui The xdo module is not found, so the 'xdo' paste method is not available. Please install python3-xdo. - exit 1 I do have that recommends installed. I did try to reinstall it in case it was somehow broken. Real problem is that the gui does not appear, I don't know if that's due to whatever the problem is with python3-xdo. impass is working at the command line still -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_USER, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 impass depends on: ii python3 3.9.0-4 ii python3-gi 3.38.0-1+b2 ii python3-gpg 1.14.0-1+b2 Versions of packages impass recommends: ii gir1.2-gtk-3.0 3.24.24-1 ii python3-xdo 0.4-2 ii xclip 0.13-1 impass suggests no packages. -- no debconf information -- see shy jo signature.asc Description: PGP signature
Bug#975562: odd no-op in debian patch
Antoine Beaupré wrote: > --- a/etckeeper > +++ b/etckeeper > @@ -54,6 +54,10 @@ fi > if [ ! -z "$AVOID_SPECIAL_FILE_WARNING" ]; then > export AVOID_SPECIAL_FILE_WARNING > fi > +if [ -z "$LANG" ]; then > + # Default to UTF8 encoding, if unset > + export LANG=C.UTF-8 > +fi That is rather problimatic, bear in mind that etckeeper can run things like interactive git commits and editors, which could be translated. Also, LANG only influences sort order when LC_COLLATE is not set. I guess my commit 4bc7ebe6d29d83df9b86e1be64e696d4d2a70947 upstream probably fixes whatever this was trying to fix in a better way, although it's hard to be sure without an explanation of what the actual problem was. > # Make sure sort always sorts in same order. > -LANG=C > +LANG=C.UTF-8 Why would it matter whether it handles unicode characters or not, if the point is sort stability? -- see shy jo signature.asc Description: PGP signature
Bug#975562: odd no-op in debian patch
Package: etckeeper Version: 1.18.15 Severity: normal +if [ -z "en_GB.UTF-8" ]; then + # Default to UTF8 encoding, if unset + export LANG=C.UTF-8 +fi I'm fairly sure it's impossible for this part of the debian patch to do anything.. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_USER Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 etckeeper depends on: ii brz [bzr] 3.1.0-5 ii bzr2.7.0+bzr6622+brz ii debconf [debconf-2.0] 1.5.74 ii git1:2.28.0+next.20200813-1 Versions of packages etckeeper recommends: ii cron [cron-daemon] 3.0pl1-136 Versions of packages etckeeper suggests: ii sudo 1.9.3p1-1 -- debconf information excluded -- see shy jo signature.asc Description: PGP signature
