Bug#1071436: qt6: mixing incompatible versions is not precluded
Package: qt6-5compat-dev Version: 6.6.2-1+b1 Severity: normal i installed qt6-l10n-tools 6.6 from experimental, which also upgraded qtbase and some other packages. however, it left qt6-5compat-dev at the unstable 6.4, thus breaking subsequent builds due to binary incompatibility; i got a bunch of errors looking like /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libQt6Core5Compat.so.6.4.2: undefined reference to `QUtf16::convertToUnicode(QByteArrayView, QStringConverterBase::State*, DataEndianness)@Qt_6' manually pulling qt6-5compat-dev from experimental as well fixed the problem.
Bug#1061686: kmscon: The removal of the kmscon package does not bring back the classical linux consoles
Package: kmscon Version: 9.0.0-5+b1 Followup-For: Bug #1061686 "I suspect systemd is spooking somewhere" is quite correct: the package leaves /etc/systemd/system/autovt@.service dangling instead of restoring it to getty@.service. i find the whole integration kinda questionable. why isn't there a proper alternatives-like selection mechanism?
Bug#1070279: valgrind: new upstream release
Package: valgrind Version: 1:3.20.0-2.1 Severity: wishlist the currently packaged version is more than 1.5 years old. upstream released 3.23 a few days ago.
Bug#1066824: lirc: socket missing
Package: lirc Version: 0.10.2-0.7 Severity: important # systemctl status lircd ● lircd.service - Flexible IR remote input/output application support Loaded: loaded (/usr/lib/systemd/system/lircd.service; enabled; preset: enabled) Active: active (running) since Wed 2024-03-13 23:05:48 CET; 3s ago TriggeredBy: ● lircd.socket Docs: man:lircd(8) http://lirc.org/html/configure.html Main PID: 247266 (lircd) Tasks: 2 (limit: 19009) Memory: 624.0K (peak: 1.8M) CPU: 26ms CGroup: /system.slice/lircd.service └─247266 /usr/sbin/lircd --nodaemon Mar 13 23:05:48 ugly lircd-0.10.2[247266]: Notice: Current driver: default Mar 13 23:05:48 ugly lircd-0.10.2[247266]: Notice: Driver API version: 3 Mar 13 23:05:48 ugly lircd-0.10.2[247266]: Notice: Driver version: 0.10.2 Mar 13 23:05:48 ugly lircd-0.10.2[247266]: Notice: Driver info: See file:///usr/share/doc/lirc/plugindocs/default.html Mar 13 23:05:48 ugly lircd-0.10.2[247266]: Info: lircd: Opening log, level: Info Mar 13 23:05:48 ugly lircd-0.10.2[247266]: Notice: Using systemd fd Mar 13 23:05:48 ugly lircd-0.10.2[247266]: Warning: Running as root Mar 13 23:05:48 ugly lircd-0.10.2[247266]: Info: Using remote: maxdome. Mar 13 23:05:48 ugly lircd-0.10.2[247266]: Info: Using remote: RH6820. Mar 13 23:05:48 ugly lircd-0.10.2[247266]: Notice: lircd(default) ready, using /var/run/lirc/lircd # irw Cannot connect to socket /run/lirc/lircd: No such file or directory # ls -l /var/run/lirc total 4 -rw-r--r-- 1 root root 7 Mar 13 23:05 lircd.pid so the notice about he used socket clearly does not reflect reality. this started after the latest upgrade, the first within a month or so. i haven't investigated this further yet. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.7.7-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lirc depends on: ii libasound2t64 1.2.11-1 ii libc6 2.37-15.1 ii libftdi1-2 1.5-6+b3 ii libgcc-s1 14-20240303-1 ii liblirc-client0t64 0.10.2-0.7 ii liblirc0t64 0.10.2-0.7 ii libportaudio2 19.6.0-1.2+b1 ii libstdc++6 14-20240303-1 ii libsystemd0 255.4-1+b1 ii libusb-0.1-42:0.1.12-35 ii libusb-1.0-02:1.0.27-1 ii python3 3.11.6-1 Versions of packages lirc recommends: ii gir1.2-vte-2.91 0.74.2-1 ii python3-gi 3.46.0-3 ii python3-yaml 6.0.1-2 ii systemd 255.4-1+b1 Versions of packages lirc suggests: ii ir-keytable 1.26.1-3 pn lirc-compat-remotes pn lirc-doc pn lirc-drv-irman ii lirc-x 0.10.2-0.7 ii setserial2.17-53+b1 -- Configuration Files: /etc/lirc/lirc_options.conf changed: [lircd] nodaemon= False driver = default device = /dev/lirc0 output = /var/run/lirc/lircd pidfile = /var/run/lirc/lircd.pid plugindir = /usr/lib/x86_64-linux-gnu/lirc/plugins permission = 666 allow-simulate = Yes repeat-max = 600 [lircmd] uinput = False nodaemon= False /etc/lirc/lircd.conf.d/devinput.lircd.conf [Errno 2] No such file or directory: '/etc/lirc/lircd.conf.d/devinput.lircd.conf' -- no debconf information
Bug#1057780: gdb-minimal provides gdb, without providing all the features in gdb
it would be more logical to invert the provides, having gdb provide gdb-minimal, and have packages depend on gdb-minimal where it's sufficient. currently, such packages express it by depending on "gdb-minimal | gdb".
Bug#1063396: lircd systemd service times out
Package: lirc Version: 0.10.2-0.5 Severity: important from the journal: Feb 07 00:04:05 ugly lircd-0.10.2[35370]: Notice: lircd(default) ready, using /var/run/lirc/lircd Feb 07 00:05:35 ugly systemd[1]: lircd.service: start operation timed out. Terminating. so lircd gets terminated despite everything being just fine. that's because the service type is specified as "notify", but clearly the daemon doesn't actually send a readiness notification. that's probably either because lirc was built without systemd support against intentions (missing build-dep?), or because it doesn't actually have support for systemd in the first place, and the service type should be "simple" (or maybe "exec", but nobody seems to use that). -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.7-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lirc depends on: ii libasound2 1.2.10-3 ii libc62.37-15 ii libftdi1-2 1.5-6+b3 ii libgcc-s114-20240201-3 ii liblirc-client0 0.10.2-0.5 ii liblirc0 0.10.2-0.5 ii libportaudio219.6.0-1.2 ii libstdc++6 14-20240201-3 ii libusb-0.1-4 2:0.1.12-35 ii libusb-1.0-0 2:1.0.27-1 ii python3 3.11.6-1 Versions of packages lirc recommends: ii gir1.2-vte-2.91 0.74.2-1 ii python3-gi 3.46.0-3 ii python3-yaml 6.0.1-2 ii systemd 255.3-2 Versions of packages lirc suggests: ii ir-keytable 1.26.1-3 pn lirc-compat-remotes pn lirc-doc pn lirc-drv-irman ii lirc-x 0.10.2-0.5 ii setserial2.17-53+b1 -- Configuration Files: /etc/lirc/lirc_options.conf changed [not included] /etc/lirc/lircd.conf.d/devinput.lircd.conf [Errno 2] No such file or directory: '/etc/lirc/lircd.conf.d/devinput.lircd.conf' /etc/lirc/lircmd.conf changed [not included] -- no debconf information
Bug#1053329: gimp-gmic: new upstream version available
Package: gimp-gmic Version: 2.9.4-4+b4 Severity: wishlist the current stable version is 3.3.0 as of now. the debian package lags it quite a bit. -- 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-4-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gimp-gmic depends on: ii gimp 2.10.34-1 ii libbabl-0.1-0 1:0.1.106-2 ii libc6 2.37-7 ii libfftw3-double3 3.3.10-1 ii libgcc-s1 13.2.0-3 ii libgegl-0.4-0 1:0.4.46-3 ii libgimp2.02.10.34-1 ii libglib2.0-0 2.77.3-1 ii libgmic1 2.9.4-4+b4 ii libgomp1 13.2.0-3 ii libqt5core5a 5.15.10+dfsg-3 ii libqt5gui55.15.10+dfsg-3 ii libqt5network55.15.10+dfsg-3 ii libqt5widgets55.15.10+dfsg-3 ii libstdc++613.2.0-3 ii libx11-6 2:1.8.6-1 ii zlib1g1:1.2.13.dfsg-3 gimp-gmic recommends no packages. Versions of packages gimp-gmic suggests: pn gmic -- no debconf information
Bug#1038699: more info
turns out my suspicion was correct. the issue is tracked upstream at https://bugreports.qt.io/browse/QTBUG-87776 . please re-open the bug and retitle it appropriately.
Bug#1040237: RM: masqmail -- RoQA; dead upstream, RC-buggy
fwiw, because i failed to find a minimal replacement MTA that i actually liked, i just sort of revived masqmail: https://github.com/ossilator/masqmail i did some build system polishing; otherwise it's taken straight from meillo's repo, and i don't think i'll do much more with it. i also updated the debian packaging a tiny bit (adjusted the patches): https://github.com/ossilator/masqmail-debian
Bug#1038699: closed by Patrick Franz ()
huh? if the declaration of the private dependency is just missing in that qtc plugin, then fair enough. but that doesn't explain the total garbage error message which suggests some kind of internal error (it sort of suggests that an incomplete package is installed like in the other bug i reported, except that it's just not there). please investigate whether this is a result of splitting, and forward the bug to upstream with your findings.
Bug#1038693: qt6-declarative-dev: inappropriately included cmake file
cmake files are necessary for static builds, because the "plugins" aren't actually plugins then. at least i'm assuming that this functionality wasn't lost during the cmake port ... plugins may also be listed as runtime dependencies for deployment. theoretically - whether that was actually implemented, i don't know. neither of these are immediately relevant for a regular desktop build, but you shouldn't be surprised when applications fail to build due to formally missing dependencies.
Bug#1038699: qt6-declarative-dev: files missing ... somehow
Package: qt6-declarative-dev Version: 6.4.2+dfsg-1 Severity: normal while building qt creator, cmake spits out this message during the generation phase (that is, after configuration is done): == CMake Error in src/plugins/qmldesigner/CMakeLists.txt: Imported target "Qt::QmlPrivate" includes non-existent path "/usr/include/x86_64-linux-gnu/qt6/QtQml/6.4.2" in its INTERFACE_INCLUDE_DIRECTORIES. Possible reasons include: * The path was deleted, renamed, or moved to another location. * An install or uninstall procedure did not complete successfully. * The installation package was faulty and references files it does not provide. == i have no clue where this is coming from, because there are no obvious hits for QmlPrivate in the cmake directory. but once i install qt6-declarative-private-dev, the error goes away. i suppose this might be some dynamic magic in the upstream code that isn't prepared for actually being split into public and private. -- 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-1-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages qt6-declarative-dev depends on: ii libqt6labsanimation6 6.4.2+dfsg-1 ii libqt6labsfolderlistmodel6 6.4.2+dfsg-1 ii libqt6labsqmlmodels6 6.4.2+dfsg-1 ii libqt6labssettings66.4.2+dfsg-1 ii libqt6labssharedimage6 6.4.2+dfsg-1 ii libqt6labswavefrontmesh6 6.4.2+dfsg-1 ii libqt6opengl6-dev 6.4.2+dfsg-11 ii libqt6qml6 6.4.2+dfsg-1 ii libqt6qmlcompiler6 6.4.2+dfsg-1 ii libqt6qmlcore6 6.4.2+dfsg-1 ii libqt6qmllocalstorage6 6.4.2+dfsg-1 ii libqt6qmlmodels6 6.4.2+dfsg-1 ii libqt6qmlworkerscript6 6.4.2+dfsg-1 ii libqt6qmlxmllistmodel6 6.4.2+dfsg-1 ii libqt6quick6 6.4.2+dfsg-1 ii libqt6quickcontrols2-6 6.4.2+dfsg-1 ii libqt6quickcontrols2impl6 6.4.2+dfsg-1 ii libqt6quickdialogs2-6 6.4.2+dfsg-1 ii libqt6quickdialogs2quickimpl6 6.4.2+dfsg-1 ii libqt6quickdialogs2utils6 6.4.2+dfsg-1 ii libqt6quicklayouts66.4.2+dfsg-1 ii libqt6quickparticles6 6.4.2+dfsg-1 ii libqt6quickshapes6 6.4.2+dfsg-1 ii libqt6quicktemplates2-66.4.2+dfsg-1 ii libqt6quicktest6 6.4.2+dfsg-1 ii libqt6quickwidgets66.4.2+dfsg-1 ii qt6-base-dev 6.4.2+dfsg-11 ii qt6-declarative-dev-tools 6.4.2+dfsg-1 ii qt6-qmltooling-plugins 6.4.2+dfsg-1 qt6-declarative-dev recommends no packages. qt6-declarative-dev suggests no packages. -- no debconf information
Bug#1038693: qt6-declarative-dev: inappropriately included cmake file
Package: qt6-declarative-dev Version: 6.4.2+dfsg-1 Severity: normal trying to build qt creator, i got this error message: === CMake Error at /usr/lib/x86_64-linux-gnu/cmake/Qt6QmlCompilerPrivate/Qt6QmlLintQuickPluginTargets.cmake:96 (message): The imported target "Qt6::QmlLintQuickPlugin" references the file "/usr/lib/x86_64-linux-gnu/qt6/plugins/qmllint/libquicklintplugin.so" but this file does not exist. Possible reasons include: * The file was deleted, renamed, or moved to another location. * An install or uninstall procedure did not complete successfully. * The installation package was faulty and contained "/usr/lib/x86_64-linux-gnu/cmake/Qt6QmlCompilerPrivate/Qt6QmlLintQuickPluginTargets.cmake" but not all the files it references. === installing qt6-qmllint-plugins fixes the issue. i suppose you might need to split off qt6-qmllint-plugins-dev. -- 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-1-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages qt6-declarative-dev depends on: ii libqt6labsanimation6 6.4.2+dfsg-1 ii libqt6labsfolderlistmodel6 6.4.2+dfsg-1 ii libqt6labsqmlmodels6 6.4.2+dfsg-1 ii libqt6labssettings66.4.2+dfsg-1 ii libqt6labssharedimage6 6.4.2+dfsg-1 ii libqt6labswavefrontmesh6 6.4.2+dfsg-1 ii libqt6opengl6-dev 6.4.2+dfsg-11 ii libqt6qml6 6.4.2+dfsg-1 ii libqt6qmlcompiler6 6.4.2+dfsg-1 ii libqt6qmlcore6 6.4.2+dfsg-1 ii libqt6qmllocalstorage6 6.4.2+dfsg-1 ii libqt6qmlmodels6 6.4.2+dfsg-1 ii libqt6qmlworkerscript6 6.4.2+dfsg-1 ii libqt6qmlxmllistmodel6 6.4.2+dfsg-1 ii libqt6quick6 6.4.2+dfsg-1 ii libqt6quickcontrols2-6 6.4.2+dfsg-1 ii libqt6quickcontrols2impl6 6.4.2+dfsg-1 ii libqt6quickdialogs2-6 6.4.2+dfsg-1 ii libqt6quickdialogs2quickimpl6 6.4.2+dfsg-1 ii libqt6quickdialogs2utils6 6.4.2+dfsg-1 ii libqt6quicklayouts66.4.2+dfsg-1 ii libqt6quickparticles6 6.4.2+dfsg-1 ii libqt6quickshapes6 6.4.2+dfsg-1 ii libqt6quicktemplates2-66.4.2+dfsg-1 ii libqt6quicktest6 6.4.2+dfsg-1 ii libqt6quickwidgets66.4.2+dfsg-1 ii qt6-base-dev 6.4.2+dfsg-11 ii qt6-declarative-dev-tools 6.4.2+dfsg-1 ii qt6-qmltooling-plugins 6.4.2+dfsg-1 qt6-declarative-dev recommends no packages. qt6-declarative-dev suggests no packages. -- no debconf information
Bug#1030950: btrfs-convert is built without support for reiserfs
Package: btrfs-progs Version: 6.1.2-1 Severity: normal for the purpose of helping people to move away from reiserfs, it would make sense to actually build btrfs-convert with support for it. the catch is that libreiserfscore is not packaged separately; rather, it's built into reiserfsprogs. i guess factoring out a static-only libreiserfscore-dev would make sense.
Bug#1012636: isync: license conflict with libsasl2
On Fri, Nov 18, 2022 at 08:51:51PM +0100, Pierre-Elliott Bécue wrote: Would you agree to release isync 1.4.5 or do I need to import your license exception? the thing is that it isn't even in master - i pushed a preliminary commit to a branch. the reason for that is that its legal foundation is mildly shaky without at least ME's explicit consent (he's not responding at all). having said that, i'll go ahead with it anyway when i'm about to release 1.5, but that is still some time in the future, as there are some known bugs and i'm currently busy with other projects. you're welcome to pick the change at your own peril. note that you'll need to pick 72ba7ef1 and 93563009 as well if you want the patch to apply (more or less) cleanly.
Bug#1017591: libkf5service5: missing symbols in library
Package: libkf5service5 Version: 5.97.0-1 Severity: grave Justification: renders package unusable /usr/bin/startplasma-x11: symbol lookup error: /usr/lib/x86_64-linux-gnu/libKF5Service.so.5: undefined symbol: _ZN8KSandbox9isFlatpakEv -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libkf5service5 depends on: ii libc6 2.34-4 ii libkf5configcore5 5.97.0-1 ii libkf5coreaddons5 5.97.0-1 ii libkf5dbusaddons5 5.97.0-1 ii libkf5i18n5 5.97.0-1 ii libkf5service-data 5.97.0-1 ii libqt5core5a5.15.4+dfsg-5 ii libqt5dbus5 5.15.4+dfsg-5 ii libqt5xml5 5.15.4+dfsg-5 ii libstdc++6 12.1.0-8 Versions of packages libkf5service5 recommends: ii libkf5service-bin 5.97.0-1 libkf5service5 suggests no packages. -- no debconf information
Bug#1014871: reportbug: is being confusing with the -r option
Package: reportbug Version: 11.5.0 Severity: normal after submitting a bug failed, i changed my mta config, and subsequently ran "reportbug -r /tmp/reportbug-..." as instructed. as the mail was already in its final state, i immediately exited the editor, which lead to this weird interaction: No changes were made in the editor. Report will be sent to Debian Bug Tracking System Submit this report on reportbug (e to edit) [y|n|a|c|E|i|l|m|p|q|d|t|?]? y Report is unchanged. Edit this report or quit [E|q|s|?]? s Sending empty report anyway... Sending message via /usr/sbin/sendmail... firstly, in the given case it's rather pointless (and therefore confusing) to say that the report is unchanged. to give an accurate account, it would have to create a pristine report template from scratch and compare the contents. secondly, it says "sending empty report", which would be confusing even if this wasn't a perfectly finalized report, as it actually means "sending unmodified generated report" or some such. -- Package-specific info: ** Environment settings: EDITOR="sensible-editor" PAGER="sensible-pager" EMAIL="Oswald Buddenhagen " INTERFACE="text" ** /home/ossi/.reportbugrc: reportbug_version "2.3" mode advanced ui text no-cc -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages reportbug depends on: ii apt2.5.1 ii python33.10.4-1+b1 ii python3-reportbug 11.5.0 ii sensible-utils 0.0.17 reportbug recommends no packages. Versions of packages reportbug suggests: pn claws-mail ii debconf 1.5.79 ii debsums 3.0.2 pn dlocate pn emacs-bin-common ii file 1:5.41-4 ii gnupg2.2.35-3 ii masqmail [mail-transport-agent] 0.3.4-1 ii python3-urwid2.1.2-2+b1 pn reportbug-gtk ii xdg-utils1.1.3-4.1 Versions of packages python3-reportbug depends on: ii apt2.5.1 ii file 1:5.41-4 ii python33.10.4-1+b1 ii python3-apt2.3.0+b1 ii python3-debian 0.1.44 ii python3-debianbts 3.2.3 ii python3-requests 2.27.1+dfsg-1 ii sensible-utils 0.0.17 python3-reportbug suggests no packages. -- Configuration Files: /etc/reportbug.conf changed: submit query-bts check-available cc config-files compress verify -- no debconf information
Bug#1014869: reportbug: support calling sendmail without envelope address
Package: reportbug Version: 11.5.0 Severity: wishlist sendmail just rejected to send my report, because the current user didn't have permission to set a return address. this is actually quite expected, and using the sendmail -f option is rather unusual. i suggest not doing that by default, or at least allowing the envelopefrom option being empty (note: i didn't check whether that's already the case - but the reportbug.conf manual does not mention it). -- Package-specific info: ** Environment settings: EDITOR="sensible-editor" PAGER="sensible-pager" EMAIL="Oswald Buddenhagen " INTERFACE="text" ** /home/ossi/.reportbugrc: reportbug_version "2.3" mode advanced ui text no-cc -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages reportbug depends on: ii apt2.5.1 ii python33.10.4-1+b1 ii python3-reportbug 11.5.0 ii sensible-utils 0.0.17 reportbug recommends no packages. Versions of packages reportbug suggests: pn claws-mail ii debconf 1.5.79 ii debsums 3.0.2 pn dlocate pn emacs-bin-common ii file 1:5.41-4 ii gnupg2.2.35-3 ii masqmail [mail-transport-agent] 0.3.4-1 ii python3-urwid2.1.2-2+b1 pn reportbug-gtk ii xdg-utils1.1.3-4.1 Versions of packages python3-reportbug depends on: ii apt2.5.1 ii file 1:5.41-4 ii python33.10.4-1+b1 ii python3-apt2.3.0+b1 ii python3-debian 0.1.44 ii python3-debianbts 3.2.3 ii python3-requests 2.27.1+dfsg-1 ii sensible-utils 0.0.17 python3-reportbug suggests no packages. -- Configuration Files: /etc/reportbug.conf changed: submit query-bts check-available cc config-files compress verify -- no debconf information
Bug#1014868: python3-pyaudio: needs patch for python 3.10
Package: python3-pyaudio Version: 0.2.11-1.4 Severity: normal pyaudio started throwing this message: SystemError: PY_SSIZE_T_CLEAN macro must be defined for '#' formats https://stackoverflow.com/questions/70344884/pyaudio-write-systemerror-py-ssize-t-clean-macro-must-be-defined-for-format explains it and links to a solution (https://git.skeh.site/skeh/pyaudio/commit/2ee560056ec889ea7cd3ce1801b796b0939dd540). -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-pyaudio depends on: ii libc6 2.33-7 ii libportaudio2 19.6.0-1.2 ii python33.10.4-1+b1 python3-pyaudio recommends no packages. Versions of packages python3-pyaudio suggests: pn python-pyaudio-doc -- no debconf information
Bug#1012636: isync: license conflict with libsasl2
On Fri, Jun 10, 2022 at 10:45:53PM +0200, Bastian Germann wrote: isync (mbsync binary) is GPL-2+ licensed and depends on libsasl2-2, which is licensed under CMU's BSD-4-clause license and covered by the RSA-MD and OpenSSL licenses. whoops. 3) Ask upstream to add a license exception for libsasl2-2, similar to the one that was required by Debian for OpenSSL for a long time. that's ok from my side, but we'll need permission from michael elkins and a few others as well. at least it should be easier than with mutt ... i'd go with a general exception for libraries with advertizing clauses. i wonder if there is legal precedent for inferring such a will from the existing exception? 4) Port to gsasl or another compatible SASL implementation. patches welcome.
Bug#170390: (no subject)
isync had the --one2one option since v0.9, and the Patterns option since v1.0. i think these satisfy the request.
Bug#990117: (no subject)
fixed upstream in v1.4.3.
Bug#226100: (no subject)
since v1.0, one can use mbsync --push-delete to achieve the desired effect.
Bug#921666: isync: error:141A318A:SSL with one server
maybe the openssl/libssl package changed its default config, or maybe the affected server simply had its configuration fixed. in either case it wasn't an isync bug to start with. for reference, isync has the CipherString option since v1.4, which could be used to work around this issue.
Bug#403554: isync: Messes up boxes while syncing
there have been some subtle changes in the namespace interpretation over the years, which caused some configuration breakage in (more or less) corner cases. also, some genuine bugs, which have been fixed long since. i don't think it makes sense to keep this report open, given its age.
Bug#908368: isync: Does not work with GSSAPI authentication
fixed upstream in v1.4 for good (dynamic buffer). for v1.3, see #1004979.
Bug#512182: isync: mbsync crash
i recommend closing this report, as it's useless in its current form, and the issue has almost certainly been fixed upstream meanwhile.
Bug#1004979: isync: Passwords are limited to 80 chars with PassCmd, need to backport upstream patches
feel like doing that? it's a low-risk, high-impact change, and thus a reasonable request. i'd include it upstream if 1.3 was still active.
Bug#766385: Generating /boot/initrd... seen twice in a single aptitude full-upgrade
some more context probably helps: ... Setting up linux-image-5.15.0-3-amd64 (5.15.15-2) ... /etc/kernel/postinst.d/dkms: dkms: running auto installation service for kernel 5.15.0-3-amd64:. /etc/kernel/postinst.d/initramfs-tools: update-initramfs: Generating /boot/initrd.img-5.15.0-3-amd64 ... /etc/kernel/postinst.d/zz-update-grub: Generating grub configuration file ... Found linux image: /boot/vmlinuz-5.15.0-3-amd64 Found initrd image: /boot/initrd.img-5.15.0-3-amd64 ... Setting up virtualbox-dkms (6.1.32-dfsg-1+b1) ... Loading new virtualbox-6.1.32 DKMS files... Building for 5.15.0-3-amd64 Building initial module for 5.15.0-3-amd64 ... Processing triggers for initramfs-tools (0.140) ... update-initramfs: Generating /boot/initrd.img-5.15.0-3-amd64 ... so it would appear that the mistake is that the kernel postinst does an instantaneous initramfs update, rather than letting the trigger take care of it, after DKMS has built the modules of other upgraded packages. it may also make sense to sequence the grub setup after the initrd setup, so it doesn't register kernels for which building the initrd failed.
Bug#941480: Please package the new version of mediathekview
two+ more years later, current version is 13.8.1, build system is still maven-based.
Bug#1001756: nvidia-legacy-340xx-driver: udev rules broken/stale; no graphical login
Package: nvidia-legacy-340xx-driver
Version: 340.108-11
Severity: important
udev fails to associate the nvidia graphics card with a seat (query with
`loginctl seat-status seat0`), which results in modern display managers
like sddm not even attempting to start a graphical login screen.
special rules are needed, as the usual drm udev rules don't work due to
the legacy driver not providing a drm interface (it appears that the 390
driver is the first one to do so).
adding /etc/udev/rules.d/61-nvidia.rules with the following content
fixes it:
SUBSYSTEM=="pci", ATTRS{vendor}=="0x10de", DRIVERS=="nvidia", TAG+="seat",
TAG+="master-of-seat"
(that file should obviously to go to /lib/udev/rules.d in the package.)
Bug#687164: sudo calls pam stack with wrong requesting user
On Sat, Dec 11, 2021 at 09:16:04AM +0100, Marc Haber wrote: is this still reproducible in current unstable? no (logs edited for brevity): === su (to root) ossi on pts/13 pam_xauth(su:session): requesting user 1000/100, target user 0/0 pam_xauth(su:session): reading keys from `/home/ossi/.Xauthority' pam_xauth(su:session): running "/usr/bin/xauth -f /home/ossi/.Xauthority nlist :0" as 1000/100 pam_xauth(su:session): writing key `blabla' to temporary file `/root/.xauthlSdyO1' pam_xauth(su:session): running "/usr/bin/xauth -f /root/.xauthlSdyO1 nmerge -" as 0/0 === sudo === ossi : TTY=pts/13 ; PWD=/root ; USER=root ; COMMAND=/bin/bash pam_unix(sudo:session): session opened for user root(uid=0) by ossi(uid=1000) pam_xauth(sudo:session): requesting user 1000/100, target user 0/0 pam_xauth(sudo:session): reading keys from `/home/ossi/.Xauthority' pam_xauth(sudo:session): running "/usr/bin/xauth -f /home/ossi/.Xauthority nlist :0" as 1000/0 pam_xauth(sudo:session): writing key `blabla' to temporary file `/root/.xauthUuD5Vi' pam_xauth(sudo:session): running "/usr/bin/xauth -f /root/.xauthUuD5Vi nmerge -" as 0/0 note that there is still a difference in the gid used for the 1st xauth call for some reason, but that doesn't impact function. How would I obtain that debug output? add "debug" to the pam_xauth.so line, as is shown in the followup messages to this report, and as you could have found out yourself by searching for "linux pam enable debug output". ;-) p.s.: it seems pointless to include both nnn-submitter@ and the actual submitter in the 'to' list.
Bug#990117: mbsync: Recursive symlink in maildir path causes abort
On Mon, Jun 21, 2021 at 10:44:42AM +0200, Nicolas Schier wrote:
A recursive symlink (here: Inbox -> ".") might be considered bad
practise. But perhaps a recursion detection is more user-friendly?
it's unreasonable to implement an actual recursion detection to cover
such a corner case. an arbitrary nesting depth limitation of 10 would be
easy to do, though.
>From 9b8fc616f3986c3bcdc8195f5ec221c38043e8d6 Mon Sep 17 00:00:00 2001
From: Oswald Buddenhagen
Date: Mon, 21 Jun 2021 11:35:24 +0200
Subject: [PATCH] limit maildir nesting depth
this is a cheap way to catch symlink loops. 10 seems like a reasonable
limit, as it's unlikely that anyone would be able to actually work with
such a deeply nested mailbox tree.
fixes debian bug #990117.
---
src/drv_maildir.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/src/drv_maildir.c b/src/drv_maildir.c
index 5ba83f7..cd8e849 100644
--- a/src/drv_maildir.c
+++ b/src/drv_maildir.c
@@ -395,7 +395,7 @@ static int maildir_list_inbox( maildir_store_t *ctx, int flags, const char *base
static int maildir_list_path( maildir_store_t *ctx, int flags, const char *inbox );
static int
-maildir_list_recurse( maildir_store_t *ctx, int isBox, int flags,
+maildir_list_recurse( maildir_store_t *ctx, int isBox, int flags, int depth,
const char *inbox, uint inboxLen, const char *basePath, uint basePathLen,
char *path, int pathLen, char *name, int nameLen )
{
@@ -417,6 +417,12 @@ maildir_list_recurse( maildir_store_t *ctx, int isBox, int flags,
closedir( dir );
return -1;
}
+ if (++depth > 10) {
+ // We do the other checks first to avoid confusing error messages for files.
+ error( "Maildir error: path nesting level exceeds 10 for %s\n", path );
+ closedir( dir );
+ return -1;
+ }
while ((de = readdir( dir ))) {
const char *ent = de->d_name;
if (ent[0] == '.' && (!ent[1] || (ent[1] == '.' && !ent[2])))
@@ -464,7 +470,7 @@ maildir_list_recurse( maildir_store_t *ctx, int isBox, int flags,
add_string_list( >boxes, name );
path[pl] = 0;
name[nl++] = '/';
- if (maildir_list_recurse( ctx, isBox + 1, flags, inbox, inboxLen, basePath, basePathLen, path, pl, name, nl ) < 0) {
+ if (maildir_list_recurse( ctx, isBox + 1, flags, depth, inbox, inboxLen, basePath, basePathLen, path, pl, name, nl ) < 0) {
closedir( dir );
return -1;
}
@@ -485,7 +491,7 @@ maildir_list_inbox( maildir_store_t *ctx, int flags, const char *basePath )
add_string_list( >boxes, "INBOX" );
return maildir_list_recurse(
- ctx, 1, flags, NULL, 0, basePath, basePath ? strlen( basePath ) - 1 : 0,
+ ctx, 1, flags, 0, NULL, 0, basePath, basePath ? strlen( basePath ) - 1 : 0,
path, nfsnprintf( path, _POSIX_PATH_MAX, "%s/", ctx->conf->inbox ),
name, nfsnprintf( name, _POSIX_PATH_MAX, "INBOX/" ) );
}
@@ -502,7 +508,7 @@ maildir_list_path( maildir_store_t *ctx, int flags, const char *inbox )
if (maildir_ensure_path( ctx->conf ) < 0)
return -1;
return maildir_list_recurse(
- ctx, 0, flags, inbox, inbox ? strlen( inbox ) : 0, NULL, 0,
+ ctx, 0, flags, 0, inbox, inbox ? strlen( inbox ) : 0, NULL, 0,
path, nfsnprintf( path, _POSIX_PATH_MAX, "%s", ctx->conf->path ),
name, 0 );
}
--
2.31.1.2.g8c0bdb8a70
Bug#986648: masqmail: new upstream version 0.3.5 available
Package: masqmail Version: 0.3.4-1 Severity: wishlist version 0.3.5 has been available at http://marmaro.de/prog/masqmail/files/ since 2015; i'd say it's about time to package it.
Bug#986471: imagemagick-6.q16: mailcap definition contains extra dot
Package: imagemagick-6.q16 Version: 8:6.9.11.60+dfsg-1 Severity: minor the command name in the first line of /usr/lib/mime/packages/imagemagick-6.q16 contains an extra trailing period, which presumably causes the display of image/avs to fail.
Bug#964438: closed by Michael Biebl (Re: Bug#964438: apt-listbugs: dns error when running from cron job)
guys, are you serious? it's fine that you document a dependency on a missing systemd feature for a clean solution (if you actually file a request upstream), but the bug is nonetheless in the current implementation of the apt-listbugs package, and can be worked around there (e.g., by polling the network for ten seconds before proceeding).
Bug#980244: python3-alsaaudio: upgrade to new upstream version 0.9
Package: python3-alsaaudio Version: 0.8.4-1.1+b3 Severity: normal the new release has been available for a while already. please upgrade. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-1-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-alsaaudio depends on: ii libasound2 1.2.4-1.1 ii libc6 2.31-9 ii python3 3.9.1-1 Versions of packages python3-alsaaudio recommends: ii libjs-jquery 3.5.1+dfsg+~3.5.5-5 ii libjs-underscore 1.9.1~dfsg-1 python3-alsaaudio suggests no packages. -- no debconf information
Bug#978475: hugin lens calibration gui asserts at startup
Package: hugin Version: 2020.0.0+dfsg-1 Severity: important ASSERT INFO: ../src/gtk/bitmap.cpp(1262): assert "bmpData->m_pixbufNoMask" failed in SetSourceSurface(): no bitmap data BACKTRACE: [1] wxBitmap::SetSourceSurface(_cairo*, int, int, wxColour const*, wxColour const*) const [2] wxBitmap::Draw(_cairo*, int, int, bool, wxColour const*, wxColour const*) const [3] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) [4] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) [5] wxEvtHandler::TryHereOnly(wxEvent&) [6] wxEvtHandler::ProcessEventLocally(wxEvent&) [7] wxEvtHandler::ProcessEvent(wxEvent&) [8] wxEvtHandler::SafelyProcessEvent(wxEvent&) [9] wxWindow::GTKSendPaintEvents(_cairo*) [10] g_closure_invoke [11] g_signal_emit_valist [12] g_signal_emit [13] gtk_container_propagate_draw [14] gtk_container_propagate_draw [15] gtk_container_propagate_draw [16] g_closure_invoke [17] g_signal_emit_valist [18] g_signal_emit [19] gtk_container_propagate_draw [20] g_closure_invoke [21] g_signal_emit_valist [22] g_signal_emit [23] gtk_container_propagate_draw [24] gtk_container_propagate_draw [25] gtk_main_do_event [26] g_signal_emit_valist [27] g_signal_emit [28] g_main_context_dispatch [29] g_main_loop_run [30] gtk_main [31] wxGUIEventLoop::DoRun() [32] wxEventLoopBase::Run() [33] wxAppConsoleBase::MainLoop() [34] wxEntry(int&, wchar_t**) [35] __libc_start_main -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-5-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages hugin depends on: ii enblend 4.2-7 ii enfuse 4.2-7 ii hugin-tools 2020.0.0+dfsg-1 ii libc6 2.31-6 ii libexiv2-27 0.27.3-3 ii libfftw3-double33.3.8-2 ii libgcc-s1 10.2.1-3 ii libglew2.1 2.1.0-4+b1 ii libglu1-mesa [libglu1] 9.0.1-1 ii libglx0 1.3.2-1 ii libgomp110.2.1-3 ii libimage-exiftool-perl 12.13+dfsg-1 ii liblcms2-2 2.9-4+b1 ii libopengl0 1.3.2-1 ii libpano13-3 2.9.20~rc2+dfsg-3 ii libsqlite3-03.34.0-1 ii libstdc++6 10.2.1-3 ii libtiff54.2.0-1 ii libvigraimpex11 1.11.1+dfsg-7+b7 ii libwxbase3.0-0v53.0.5.1+dfsg-2 ii libwxgtk3.0-gtk3-0v53.0.5.1+dfsg-2 ii make4.3-4 hugin recommends no packages. Versions of packages hugin suggests: pn dcraw | rawtherapee | darktable -- no debconf information
Bug#889924: progress?
can something be done about this, please? this affects every 3rd party repository, and it seems a bit off that aptitude can't do something that the "regular" apt tools have done for years.
Bug#973545: gcc-10: 10.2.0-15 to 10.2.0-16 900MB larger?
well, the consequences should be somewhat predictable to anyone who's been using sid for a while. also, they are clearly visible when you use an interactive update tool like aptitude (which you really should when you use sid). more of a mystery to me is why this is done this way at all. there are -dbgsym packages, so why not bloat these some more instead?
Bug#968042: upgrading packet python2 from 2.7.17-2 up to 2.7.18-2 asks packets deletion
this bug is duplicated by #970430, from which i learned that the unversioned packages are indeed supposed to be deleted (see also #937695). this resolution appears satisfactory: --\ Remove the following packages: libpython-dev libpython-stdlib python-dev python-minimal python --\ Install the following packages: python-dev-is-python2 python-is-python2 however, that's not what apt or aptitude will propose by default, so the upgrade experience is anything but optimal. not quite as bad as #970375, though. ;-)
Bug#964438: apt-listbugs: dns error when running from cron job
On Tue, Jul 14, 2020 at 10:51:06PM +0200, Francesco Poli wrote: Do you mean that your "no network when apt-listbugs timer runs" only happens immediately after a wake-up from a suspended state and only when the system has had no chance to run the timer between 7:00 a.m. and the wake-up itself? yes And I suppose /var/spool/apt-listbugs/lastprefclean modification time is somewhat later, between 10:20 and 10:40 a.m. yes, from the next regular timer wakeup at 10:38.
Bug#964438: apt-listbugs: dns error when running from cron job
On Mon, Jul 13, 2020 at 11:25:21PM +0200, Francesco Poli wrote: I haven't found a satisfying strategy to get what I wanted. ok, fair enough. please make sure the maintainers know about this requirement if you haven't done so yet. Could it be that the timer was just about to be triggered, when the machine woke up? that's implausible, because the suspensions and wakeups are essentially random (measured against "your" schedule), while the problem appears with utter regularity (whenever the wakeup happens on the next day, as defined by your mechanism). Well, I am using systemd/245.6-2 right now, and I do not experience your DNS issues. So I cannot reproduce the bug. it's wrong to concentrate on the dns problem in particular. the question is why the service is started so early during wakeup, literally during the same second, even before many drivers have woken up, and several seconds before avahi and dhclient get their turn at restoring network normality. about the same time (order is random) systemd-sleep is logging resumption, so maybe the kernel is being funny (the driver timing seems weird)? but then, the weird user space sequencing seems more likely due to a bad service config, except that anacron and several other apt services are fired as well. anyway, the boot log says: Linux version 5.7.0-1-amd64 #1 SMP Debian 5.7.6-1 (2020-06-24) and with Linux version 5.6.0-2-amd64 #1 SMP Debian 5.6.14-1 (2020-05-23) and systemd 245.5 the timing was apparently the same already. i haven't gone further back (the logs were rotated out already), but as far as the most recent updates go, these were clearly dead ends. here's a log of the wakeup: Jul 14 09:53:46 ugly kernel: ACPI: Low-level resume complete Jul 14 09:53:46 ugly kernel: PM: Restoring platform NVS memory Jul 14 09:53:46 ugly kernel: Enabling non-boot CPUs ... Jul 14 09:53:46 ugly kernel: x86: Booting SMP configuration: Jul 14 09:53:46 ugly kernel: smpboot: Booting Node 0 Processor 1 APIC 0x2 Jul 14 09:53:46 ugly kernel: CPU1 is up Jul 14 09:53:46 ugly kernel: smpboot: Booting Node 0 Processor 2 APIC 0x4 Jul 14 09:53:46 ugly kernel: CPU2 is up Jul 14 09:53:46 ugly kernel: smpboot: Booting Node 0 Processor 3 APIC 0x6 Jul 14 09:53:46 ugly kernel: CPU3 is up Jul 14 09:53:46 ugly kernel: smpboot: Booting Node 0 Processor 4 APIC 0x1 Jul 14 09:53:46 ugly kernel: CPU4 is up Jul 14 09:53:46 ugly kernel: smpboot: Booting Node 0 Processor 5 APIC 0x3 Jul 14 09:53:46 ugly kernel: CPU5 is up Jul 14 09:53:46 ugly kernel: smpboot: Booting Node 0 Processor 6 APIC 0x5 Jul 14 09:53:46 ugly kernel: CPU6 is up Jul 14 09:53:46 ugly kernel: smpboot: Booting Node 0 Processor 7 APIC 0x7 Jul 14 09:53:46 ugly kernel: CPU7 is up Jul 14 09:53:46 ugly kernel: ACPI: Waking up from system sleep state S3 Jul 14 09:53:46 ugly kernel: hpet: Lost 6587 RTC interrupts Jul 14 09:53:46 ugly kernel: sd 1:0:0:0: [sdb] Starting disk Jul 14 09:53:46 ugly kernel: sd 0:0:0:0: [sda] Starting disk Jul 14 09:53:46 ugly kernel: sd 6:0:0:0: [sdc] Starting disk Jul 14 09:53:46 ugly kernel: nuvoton-cir 00:02: activated Jul 14 09:53:46 ugly kernel: OOM killer enabled. Jul 14 09:53:46 ugly systemd[1]: Started Run anacron jobs. Jul 14 09:53:46 ugly systemd-sleep[789697]: System resumed. Jul 14 09:53:46 ugly kernel: Restarting tasks ... done. Jul 14 09:53:46 ugly kernel: PM: suspend exit Jul 14 09:53:46 ugly systemd[1]: Starting Daily apt upgrade and clean activities... Jul 14 09:53:46 ugly systemd[1]: Starting Daily apt-listbugs preferences cleanup... Jul 14 09:53:46 ugly kernel: ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Jul 14 09:53:46 ugly kernel: ata1.00: supports DRM functions and may not be fully accessible Jul 14 09:53:46 ugly kernel: ata1.00: disabling queued TRIM support Jul 14 09:53:46 ugly kernel: ata1.00: supports DRM functions and may not be fully accessible Jul 14 09:53:46 ugly kernel: ata1.00: disabling queued TRIM support Jul 14 09:53:46 ugly kernel: ata1.00: configured for UDMA/133 Jul 14 09:53:46 ugly anacron[789710]: Anacron 2.3 started on 2020-07-14 Jul 14 09:53:46 ugly anacron[789710]: Will run job `cron.daily' in 5 min. Jul 14 09:53:46 ugly anacron[789710]: Jobs will be executed sequentially Jul 14 09:53:47 ugly systemd[1]: apt-daily-upgrade.service: Succeeded. Jul 14 09:53:47 ugly systemd[1]: Finished Daily apt upgrade and clean activities. Jul 14 09:53:47 ugly systemd[1]: apt-listbugs.service: Succeeded. Jul 14 09:53:47 ugly systemd[1]: Finished Daily apt-listbugs preferences cleanup. Jul 14 09:53:50 ugly kernel: e1000e :00:19.0 eth0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx Jul 14 09:53:50 ugly kernel: ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Jul 14 09:53:50 ugly kernel: ata2.00: configured for UDMA/133 Jul 14 09:53:50 ugly systemd-sleep[789799]: /dev/sdb: Jul 14 09:53:50 ugly systemd-sleep[789799]: setting Advanced Power Management level to 0xfe (254) Jul 14 09:53:50 ugly
Bug#964438: apt-listbugs: dns error when running from cron job
On Tue, Jul 07, 2020 at 10:53:59PM +0200, Francesco Poli wrote: On Tue, 7 Jul 2020 20:17:15 +0200 Oswald Buddenhagen wrote: there is a report every hour despite it claiming to be a daily job. that's weird at least. It works this way by design. [...] The rationale is: the job must be attempted at various times, since the network could be down sometimes. i see. you actually want anacron-like functionality with network awareness. i guess systemd should be doing something like that ... Was your system offline 5 min after waking up from sleep? no, my point was that this is happening *right* after waking up. there is no delay. Please reply to the other questions in my previous message. the only one which seems relevant would be the one about recent changes, to which i can speculate that this possibly started with the recent-ish systemd v245.6 upgrade.
Bug#964438: apt-listbugs: dns error when running from cron job
On Tue, Jul 07, 2020 at 07:46:50PM +0200, Francesco Poli wrote: • when did it begin? i don't remember - i tend to ignore non-critical errors at first. the journal doesn't say when it began, either, as it says that the sevice "succeeded" despite the error mail ... but there are actually clues in the journal: there is a report every hour despite it claiming to be a daily job. that's weird at least. more importantly, there is another report (outside the hourly schedule) right after waking up from sleep - and this one could plausibly consistently run into a dns failure, as it runs before the network stack is restarted. so it's systemd-related, just differently than i thought.
Bug#964438: apt-listbugs: dns error when running from cron job
Package: apt-listbugs Version: 0.1.32 Severity: normal for some days/weeks now, i get this mail every day: -- From: apt-listbugs timer To: root Subject: prefclean output on ugly /usr/libexec/apt-listbugs/prefclean: E: getaddrinfo: Temporary failure in name resolution (bugs.debian.org:80) E: Exiting with error --- the program works just fine when invoked from the command line, and these errors are a little bit too consistent to be actual network outages, so i suspect a permission problem in the configuration of the systemd timer (note that apparmor is enabled). -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-1-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages apt-listbugs depends on: ii apt 2.1.6 ii ruby1:2.7+1 ii ruby-debian 0.3.10+b3 ii ruby-gettext3.3.3-2 ii ruby-soap4r 2.0.5-4 ii ruby-unicode0.4.4-2+b11 ii ruby-xmlparser 0.7.3-3+b4 Versions of packages apt-listbugs recommends: ii ruby-httpclient 2.8.3-2 -- no debconf information
Bug#952718: qtcreator: Clang code model fail to find stddef.h if libclang-common-8-dev package is not installed
Package: qtcreator Version: 4.11.0-2 Followup-For: Bug #952718 i just wasted about half an hour on researching this, so i'll summarize my current understanding: libclang-N needs to depend on libclang-common-N-dev, as otherwise it's dysfunctional. failing that, qtcreator needs to recommend libclang-common-N-dev. this could be upgraded to depends if the clang-related plugins incl. libclangsupport are factored out to a separate qtcreator sub-package which qtcreator recommends. alternatively, this approach could be used to isolate the libclang-N dependency itself. that qtcreator's code model technically uses the wrong headers is correct, but orthogonal to the issue, and usually not problematic (which is why the approach was deemed accepatable in the first place).
Bug#953876: python3-q-text-as-data: new upstream version available
Package: python3-q-text-as-data Version: 1.7.4+2018.12.21+git+28f776ed46-2 Severity: normal the current upstream version on github is 2.0.10. please package it.
Bug#926345: isync: Fails to sync Maildir++ subfolders after initial sync
repeated attempts to contact mswatch's author have failed. :-( anyway, i suggest to close this bug, as mbsync itself works just fine for all i can tell.
Bug#940961: aptitude: upgrade of apt is not smooth
Package: aptitude Version: 0.8.12-1 Severity: normal while upgrading apt from within aptitude, i got this error: [...] Setting up libapt-pkg5.0:amd64 (1.8.4) ... (Reading database ... 316101 files and directories currently installed.) Preparing to unpack .../libapt-inst2.0_1.8.4_amd64.deb ... Unpacking libapt-inst2.0:amd64 (1.8.4) over (1.8.3) ... Preparing to unpack .../archives/apt_1.8.4_amd64.deb ... Unpacking apt (1.8.4) over (1.8.3) ... dpkg: error: dpkg frontend lock is locked by another process /etc/cron.daily/apt-compat.dpkg-new /etc/kernel/postinst.d/apt-auto-removal.dpkg-new /etc/apt/apt.conf.d/01autoremove.dpkg-new /etc/logrotate.d/apt.dpkg-new /etc/ld.so.conf.d/zz_i386-biarch-compat.conf.dpkg-new E: Sub-process /usr/bin/dpkg returned an error code (2) dpkg: error: dpkg frontend lock is locked by another process Press Return to continue, 'q' followed by Return to quit. however, immediately trying again (apparently) resolved the issue: Preconfiguring packages ... Setting up apt (1.8.4) ... (Reading database ... 316101 files and directories currently installed.) Preparing to unpack .../apt-utils_1.8.4_amd64.deb ... [...] -- Package-specific info: Terminal: xterm $DISPLAY is set. which aptitude: /usr/bin/aptitude aptitude version information: aptitude 0.8.12 Compiler: g++ 9.2.1 20190821 Compiled against: apt version 5.0.2 NCurses version 6.1 libsigc++ version: 2.10.1 Gtk+ support disabled. Qt support disabled. Current library versions: NCurses version: ncurses 6.1.20190803 cwidget version: 0.5.18 Apt version: 5.0.2 aptitude linkage: linux-vdso.so.1 (0x7ffd1b0d5000) libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 (0x7fa6bf1bf000) libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 (0x7fa6bf184000) libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x7fa6bf154000) libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 (0x7fa6bf14b000) libcwidget.so.4 => /usr/lib/x86_64-linux-gnu/libcwidget.so.4 (0x7fa6bf045000) libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x7fa6bef21000) libboost_iostreams.so.1.67.0 => /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.67.0 (0x7fa6bef01000) libxapian.so.30 => /usr/lib/x86_64-linux-gnu/libxapian.so.30 (0x7fa6bece8000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fa6becc7000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7fa6beaee000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fa6be9a9000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7fa6be98f000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fa6be7cd000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x7fa6be7b5000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fa6be798000) libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x7fa6be785000) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7fa6be75c000) liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x7fa6be73d000) libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1 (0x7fa6be693000) libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7fa6be668000) libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x7fa6be5c1000) /lib64/ld-linux-x86-64.so.2 (0x7fa6bf81b000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fa6be5bc000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7fa6be5b1000) libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7fa6be5a6000) libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x7fa6be489000) libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x7fa6be466000) -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages aptitude depends on: ii aptitude-common 0.8.12-1 ii libapt-pkg5.0 1.8.4 ii libboost-iostreams1.67.0 1.67.0-13 ii libc6 2.29-2 ii libcwidget4 0.5.18-5 ii libgcc1 1:9.2.1-8 ii libncursesw6 6.1+20190803-1 ii libsigc++-2.0-0v5 2.10.1-2 ii libsqlite3-0 3.29.0-2 ii libstdc++69.2.1-8 ii libtinfo6 6.1+20190803-1 ii libxapian30 1.4.12-1 Versions of packages aptitude recommends: ii libparse-debianchangelog-perl
Bug#926345: isync: Fails to sync Maildir++ subfolders after initial sync
On Wed, Apr 03, 2019 at 03:19:57PM -0400, Nik A. Melchior wrote: > + mbsync hostname:lists.ip > Maildir error: store 'local', folder 'lists.ip': SubFolders style Maildir++ > does not support dots in mailbox names > you need to use the canonical mailbox name, so hostname:lists/ip
Bug#888704: xoscope has been compiled without alsa support
Package: xoscope Version: 2.2-1+b1 Followup-For: Bug #888704 indeed, libasound2-dev needs to be added to Build-depends. things work fine after this is done. note that esd support is also not built in due to being utterly obsolete. that's just fine, but i'd suggest to patch the man page accordingly.
Bug#913679: kopete: libjingle-call keeps crashing
Package: kopete Version: 4:17.08.3-2 Severity: important when an xmpp account is configured and "Enable libjingle support" is enabled, kopete will spawn libjingle-call (being online is apparently sufficient). this will immediately crash, leaving such an entry in the journal: Nov 14 00:23:30 host kernel: libjingle-call[6998]: segfault at 48 ip 7fa8d882ec73 sp 7ffe90fdb610 error 4 in libcrypto.so.1.1[7fa8d87f1000+19f000] Nov 14 00:23:30 host kernel: Code: 40 24 01 00 00 00 4c 89 e2 c7 40 50 01 00 00 00 0f ae f0 e8 ff 35 fc ff 85 c0 74 6c e8 86 4c fc ff 48 89 43 70 48 85 c0 74 2d <48> 8b 45 48 48 85 c0 74 74 48 89 df ff d0 85 c0 0f 84 a7 00 00 00 [...] the executable will be instantly respawned, which on my system produces about six entries per second. within some hours, the disk fills up, rendering the system unusable. the non-existing handling of the "keeps crashing" situation is certainly an upstream issue. but the crash itself may be related to the packaging. here's an actual backtrace: #0 BIO_new (method=0x0) at ../crypto/bio/bio_lib.c:94 #1 0x555fe062667a in BIO_new_socket (socket=0x555fe17fee08) at ./protocols/jabber/libjingle/talk/base/openssladapter.cc:123 #2 0x555fe0626fc3 in talk_base::OpenSSLAdapter::BeginSSL (this=this@entry=0x555fe17fef10) at ./protocols/jabber/libjingle/talk/base/openssladapter.cc:345 #3 0x555fe0627122 in talk_base::OpenSSLAdapter::StartSSL (hostname=0x555fe17ff700 "kde.org", restartable=, this=0x555fe17fef10) at ./protocols/jabber/libjingle/talk/base/openssladapter.cc:320 #4 talk_base::OpenSSLAdapter::StartSSL (this=0x555fe17fef10, hostname=0x555fe17ff700 "kde.org", restartable=) at ./protocols/jabber/libjingle/talk/base/openssladapter.cc:307 #5 0x555fe0799413 in XmppSocket::StartTls (domainname=..., this=0x555fe17fdca0) at /usr/include/c++/8/bits/basic_string.h:2290 #6 XmppSocket::StartTls (this=0x555fe17fdca0, domainname=...) at ./protocols/jabber/libjingle/talk/examples/login/xmppsocket.cc:227 #7 0x555fe07749e3 in buzz::XmppEngineImpl::StartTls (this=0x555fe17ff610, domain=...) at /usr/include/c++/8/bits/basic_string.h:1031 #8 0x555fe0777507 in buzz::XmppLoginTask::Advance (this=this@entry=0x555fe17ffe60) at ./protocols/jabber/libjingle/talk/xmpp/jid.h:55 #9 0x555fe0777c20 in buzz::XmppLoginTask::Advance (this=0x555fe17ffe60) at ./protocols/jabber/libjingle/talk/xmpp/xmpplogintask.cc:98 #10 buzz::XmppLoginTask::IncomingStanza (this=0x555fe17ffe60, element=element@entry=0x555fe1801a90, isStart=isStart@entry=false) at ./protocols/jabber/libjingle/talk/xmpp/xmpplogintask.cc:85 #11 0x555fe0773c16 in buzz::XmppEngineImpl::IncomingStanza (this=0x555fe17ff610, stanza=0x555fe1801a90) at ./protocols/jabber/libjingle/talk/xmpp/xmppengineimpl.cc:306 #12 0x555fe0777dbf in buzz::XmppStanzaParser::IncomingEndElement (name=, pctx=, this=0x555fe17ff628) at ./protocols/jabber/libjingle/talk/xmpp/xmppstanzaparser.cc:93 #13 buzz::XmppStanzaParser::IncomingEndElement (this=0x555fe17ff628, pctx=, name=) at ./protocols/jabber/libjingle/talk/xmpp/xmppstanzaparser.cc:82 #14 0x7f4731f203ff in doContent (parser=parser@entry=0x555fe17ff920, startTagLevel=startTagLevel@entry=0, enc=, s=, end=0x555fe18005cb "", nextPtr=0x555fe17ff950, haveMore=1 '\001') at ../../src/lib/xmlparse.c:2924 #15 0x7f4731f214bc in contentProcessor (parser=0x555fe17ff920, start=, end=, endPtr=) at ../../src/lib/xmlparse.c:2552 #16 0x7f4731f23a06 in XML_ParseBuffer (parser=0x555fe17ff920, len=50, isFinal=0) at ../../src/lib/xmlparse.c:1988 #17 0x555fe074d9c3 in buzz::XmlParser::Parse (this=0x555fe17ff640, data=, len=, isFinal=isFinal@entry=false) at ./protocols/jabber/libjingle/talk/xmllite/xmlparser.cc:172 #18 0x555fe074dbe8 in buzz::XmlParser::Parse (this=, data=, len=, isFinal=isFinal@entry=false) at ./protocols/jabber/libjingle/talk/xmllite/xmlparser.cc:169 #19 0x555fe0774cad in buzz::XmppStanzaParser::Parse (isFinal=false, len=, data=, this=) at ./protocols/jabber/libjingle/talk/xmpp/xmppstanzaparser.h:52 #20 buzz::XmppEngineImpl::HandleInput (this=, bytes=, len=) at ./protocols/jabber/libjingle/talk/xmpp/xmppengineimpl.cc:109 #21 0x555fe076fef4 in buzz::XmppClient::Private::OnSocketRead (this=0x555fe17fd370) at ./protocols/jabber/libjingle/talk/xmpp/xmppclient.cc:350 #22 0x555fe0799805 in sigslot::signal0::operator() (this=0x555fe17fdd08) at /usr/include/c++/8/bits/stl_list.h:301 #23 XmppSocket::OnReadEvent (this=0x555fe17fdca0, socket=) at ./protocols/jabber/libjingle/talk/examples/login/xmppsocket.cc:88 #24 0x555fe0626e58 in sigslot::signal1::operator() (a1=0x555fe17fef10, this=0x555fe17fef18) at /usr/include/c++/8/bits/stl_list.h:301 #25 talk_base::AsyncSocketAdapter::OnReadEvent (socket=, this=0x555fe17fef10) at ./protocols/jabber/libjingle/talk/base/asyncsocket.h:119 #26 talk_base::OpenSSLAdapter::OnReadEvent (this=0x555fe17fef10, socket=) at
Bug#909441: ngspice: new upstream version available
Package: ngspice Version: 27-1 Severity: wishlist Dear Maintainer, upstream released version 28 with some interesting new features a few months ago.
Bug#908368: isync: Does not work with GSSAPI authentication
ok, that seems convincing. i bumped it to 4KiB (just to be safe) on the 1.3 branch.
Bug#908368: isync: Does not work with GSSAPI authentication
please increase the buffer to whatever size works and then send me the output of an -l session with the -D option, so i can see where i made the wrong assumption.
Bug#737043: Fails to display processes with non-ascii characters
Package: iotop Version: 0.6-24-g733f3f8-1 Followup-For: Bug #737043 the current incarnation of this (?) problem: Traceback (most recent call last): File "/usr/sbin/iotop", line 17, in main() File "/usr/lib/python3/dist-packages/iotop/ui.py", line 737, in main main_loop() File "/usr/lib/python3/dist-packages/iotop/ui.py", line 727, in main_loop = lambda: run_iotop(options) File "/usr/lib/python3/dist-packages/iotop/ui.py", line 620, in run_iotop return curses.wrapper(run_iotop_window, options) File "/usr/lib/python3.6/curses/__init__.py", line 94, in wrapper return func(stdscr, *args, **kwds) File "/usr/lib/python3/dist-packages/iotop/ui.py", line 612, in run_iotop_window ui.run() File "/usr/lib/python3/dist-packages/iotop/ui.py", line 189, in run self.process_list.duration) File "/usr/lib/python3/dist-packages/iotop/ui.py", line 476, in refresh_display lines = self.get_data() File "/usr/lib/python3/dist-packages/iotop/ui.py", line 457, in get_data return list(map(format, processes)) File "/usr/lib/python3/dist-packages/iotop/ui.py", line 432, in format cmdline = p.get_cmdline() File "/usr/lib/python3/dist-packages/iotop/data.py", line 305, in get_cmdline cmdline = proc_cmdline.read(4096) File "/usr/lib/python3.6/codecs.py", line 321, in decode (result, consumed) = self._buffer_decode(data, self.errors, final) UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc0 in position 69: invalid start byte -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages iotop depends on: ii python3 3.6.6-1 iotop recommends no packages. iotop suggests no packages. -- no debconf information
Bug#872672: gcc-7: packages are *huuuge*
Source: gcc-7 Version: 7.2.0-1 Severity: normal the cpp/gcc/g++-6 packages are around 25mb. the gcc-7 equivalents are 150+mb. while this isn't necessarily a bug, it looks *relly* fishy, so i'm bringing it up for attention. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.11.12 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#872420: isync FTCBFS: misdetects openssl by using the build architecture pkg-config
i upstreamed this patch with an adjusted commit message.
Bug#872046: isync: does not synchronize yahoo email accounts anymore
if the timing is accurate, then the event that triggered both problems is that yahoo implemented SASL. the error message you're getting is just an elaborate way of saying "login failed". judging by the mozilla bug, the problem might be that you're using different capitalization of your login name. alternatively, the login *is* wrong, because the password expired or something like that. if neither applies, try configuring "AuthMech LOGIN".
Bug#871813: isync: please allow the usage of TLS1.1+ by default
this should be considered a duplicate of Bug#871765. the patch is rather incomplete in the compat wrapper part. but my own patch does not touch it at all, and i think i'll leave it at that (introducing new features to the compat wrapper seems anti-thetical). also, don't mix in the ssl2/3 removal into the same patch. i'll remove sslv2 separately in master (to be 1.3 soon). i know that debian disables sslv3 in openssl, but it seems odd to prune it from mbsync at this point.
Bug#782054: mbsync: New version cannot open Maildir boxes
On Mon, Jan 16, 2017 at 06:54:33PM +0100, chrysn wrote: > Oswald, do you think you could apply that patch to the 1.2 branch? > that's entirely out of the question. i need to finally make an 1.3 release. i just have a bunch of things cooking which i want to get done first ...
Bug#843395: qtcreator: missing dependency to qml-module-qtqml-models2
Package: qtcreator Version: 4.1.0-3+b1 Severity: normal switching to the welcome screen yields this message: qrc:/timeline/TimelineContent.qml:29:1: module "QtQml.Models" is not installed installing qml-module-qtqml-models2 manually makes it go away. (the welcome screen is still empty even with that fixed, but whatever ...) -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.5 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages qtcreator depends on: ii libbotan-1.10-1 1.10.12-1.1 ii libc6 2.24-5 ii libclang1-3.8 1:3.8.1-13 ii libgcc1 1:6.2.0-11 ii libqbscore1 1.6.0+dfsg-2 ii libqbsqtprofilesetup1 1.6.0+dfsg-2 ii libqt5concurrent5 5.7.1~20161021+dfsg-5 ii libqt5core5a 5.7.1~20161021+dfsg-5 ii libqt5designer5 5.7.1~20161021-2 ii libqt5designercomponents5 5.7.1~20161021-2 ii libqt5gui55.7.1~20161021+dfsg-5 ii libqt5help5 5.7.1~20161021-2 ii libqt5network55.7.1~20161021+dfsg-5 ii libqt5printsupport5 5.7.1~20161021+dfsg-5 ii libqt5qml5 [qtdeclarative-abi-5-7-0] 5.7.1~20161021-4 ii libqt5quick5 5.7.1~20161021-4 ii libqt5quickwidgets5 5.7.1~20161021-4 ii libqt5sql55.7.1~20161021+dfsg-5 ii libqt5sql5-sqlite 5.7.1~20161021+dfsg-5 ii libqt5webkit5 5.7.1~20161021+dfsg-2 ii libqt5widgets55.7.1~20161021+dfsg-5 ii libqt5xml55.7.1~20161021+dfsg-5 ii libstdc++66.2.0-11 ii qml-module-qtquick-controls 5.7.1~20161021-2 ii qml-module-qtquick2 5.7.1~20161021-4 ii qtchooser 58-gfab25f1-1 ii qtcreator-data4.1.0-3 Versions of packages qtcreator recommends: ii clang1:3.8-34 ii gdb 7.11.1-2 ii make 4.1-9 ii qmlscene 5.7.1~20161021-4 ii qt5-doc 5.6.1-1 ii qt5-qmltooling-plugins 5.7.1~20161021-4 ii qtbase5-dev-tools5.7.1~20161021+dfsg-5 ii qtcreator-doc4.1.0-3 ii qtdeclarative5-dev-tools 5.7.1~20161021-4 ii qttools5-dev-tools 5.7.1~20161021-2 ii qttranslations5-l10n 5.7.1~20161021-1 ii qtxmlpatterns5-dev-tools 5.7.1~20161021-3 ii xterm [x-terminal-emulator] 327-1 Versions of packages qtcreator suggests: pn cmake ii g++4:6.1.1-1 pn git ii kdelibs5-data 4:4.14.25-1 ii subversion 1.9.4-3+b1 -- no debconf information
Bug#782054: Please support Dovecot Maildir++
i just pushed a fix to master.
Bug#841420: fix
-no-pie is not a useful option here, because it's passed to the _linker_ only. i got it to build with this minimal patch: --- a/Makefile +++ b/Makefile @@ -400,5 +400,5 @@ KBUILD_CFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \ -Werror-implicit-function-declaration \ -Wno-format-security \ - -std=gnu89 + -std=gnu89 -fno-PIE KBUILD_AFLAGS_KERNEL :=
Bug#782054: Please support Dovecot Maildir++
ok, i did misread the spec in a subtle way. the thing is that while all
other folders are physically nested under INBOX, the imap view puts them
at the same (root) level. to get them shown as subfolders of INBOX, they
need to have _two_ leading dots, as we've seen in the example with
evolution (though i don't see that actually specified anywhere -
somebody cares to verify with dovecot and courier?). this is rather
counterintuitive.
the consequence is that i need to a) adjust the name mapping algorithms
and b) forbid setting Path when SubFolders is set to Maildir++, as in
this mode the location of all boxes is determined by Inbox as i've said
before.
i'm not entirely sure what to do with the Verbatim mode. in principle,
it's possible to use it to work with dovecot's maildir++ with the "fs"
layout by setting Inbox and Path to the exact same location. the caveat
being that physical subfolders of Inbox must be ignored for INBOX'
purposes - they may show up only relative to Path (i.e., as top-level
folders). this is exactly opposite to the case where somebody chooses to
put Inbox under Path, in which case subfolders of Inbox most definitely
*should* show up under INBOX, as they couldn't be sensibly represented
relative to Path ("/subbox" makes semantically no
sense).
Bug#782054: Please support Dovecot Maildir++
please also save a message to INBOX and find out where it ends up. i'm interested how the physical location of INBOX relates to ~/Mail.
Bug#782054: Please support Courier Maildir++
On Tue, Oct 04, 2016 at 05:57:35PM -0400, Nik Melchior wrote: > I don't know whose interpretation of Maildir++ is correct, but Courier > does in fact prepend a '.' for top-level mailboxes. > please post your on-disk layout and the imap view (output from mbsync -l -Dn -a is sufficient, provided you didn't misconfigure it too much).
Bug#828357: isync: FTBFS with openssl 1.1.0
fixed in git on isync_1_2_branch.
Bug#782054: mbsync: New version cannot open Maildir boxes
On Tue, Jul 28, 2015 at 09:21:57AM +0100, Ian Campbell wrote: > It would be super useful if mbsync -l could produce the actual literal path > of the Maildir to which a given folder was being sync'd. With sufficient > debug/verbosity I can infer from the "reading sync state" message, but > having a concise way to see how things will end up would greatly simplify > tweaking the config. > -l isn't a debugging option, so that's out of scope. i could make the output of -Dm more direct in that regard. anyway, this belongs to the isync list or feature tracker. > So, please could you recommend a set of options which produce a > Maildir tree which is compatible with Evolution's Maildir++? > git master already has support for real maildir++ (as i understand it, anyway) and entirely dotless subfolders, but evolution's interpretation of the format definitely seems a bit funny, so that remains incompatible.
Bug#782054: mbsync: New version cannot open Maildir boxes
On Sun, May 10, 2015 at 04:04:59AM +0200, Guillem Jover wrote: And while I'm not trying to be obtuse here, the way I read the specs I don't see anything wrong with my reasoning. well, maybe you should re-read the mbsync manual then, to get a factual basis for your reasoning. you are *still* not getting what Path is. you're looking for Inbox. you don't even need a Path. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782054: mbsync: New version cannot open Maildir boxes
On Mon, May 04, 2015 at 10:40:19PM +0200, Guillem Jover wrote: Either that or I'm very confused… i'd bet on the latter. ;) Path is not the top-level folder - it is a namespace that contains top-level folders. this is also what you'd find on an actual imap server. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758172: isync: dots in maildir names
git master now has a SubFolders option to select the folder naming style. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782054: mbsync: New version cannot open Maildir boxes
i made a bunch of fixes (for 1.2.x) and added the SubFolders option to select the folder naming style (for 1.3), the latter of which should make the dot hack unnecessary (by consistently not using leading dots). let me know if any issues remain. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782054: mbsync: New version cannot open Maildir boxes
you need to use SubFolders Verbatim, Path without the trailing dot, and rename the folders to actually be a real hierarchy with no leading dots. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782054: mbsync: New version cannot open Maildir boxes
On Mon, May 04, 2015 at 08:12:08PM +0200, Guillem Jover wrote: It seems to me that either «SubFolders Maildir++» does not work as documented or the documentation is not clear enough, (or I don't understand it). your config attempts to have dots prefixed to the top-level folders' names. there is no standard that would cover that, and i'm not going to restore the fuzziness that allowed your configuration to work pretty much by accident. it might be possible to trick mbsync by setting the Path one level up and using Slave :store:Maildir/, so it would think your top-level folders are subfolders. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758172: isync: dots in maildir names
as it happens, i sent a related message to the isync mailing list literally two hours earlier. i don't think i'll make use of the patch. if nothing else, because reliance on dirent.d_type is a no-go. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782054: mbsync: New version cannot open Maildir boxes
On Tue, Apr 07, 2015 at 06:42:02PM +0200, Guillem Jover wrote: pattern '*' (effective '*'): Path, no INBOX got mailbox list from slave: [nothing] well, that explains a bit. i suspect this is due to the trailing dot in the Path specification, i.e., your attempt to create a namespace which uniformly uses leading dots, not only for subfolders. what changed is the level of trust mbsync puts into the box listings. i'm not quite sure why it doesn't try to create the slave mailboxes, though. will have to investigate. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782054: mbsync: New version cannot open Maildir boxes
strange, i'd have suspected d8225390fcd3d31577d3d74ab3d18b8762c5008b first (dovecot users are expected to be affected in particular, as many appear to have a NAMESPACE of INBOX. configured). the output of -DMn would be a good start in either case. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765052: mbsync: Please add a more compact output mode
this is now implemented in git master (to be 1.2). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778388: ccache: scanner confused by comment signs in strings
this is pretty incredible ... i can't reproduce it with your testcase, either. but when i run the actual build with CCACHE_LOGFILE=/dev/stdout, it totally confirms that the issue is real: [2015-02-16T20:25:26.035076 20314] === CCACHE STARTED = [2015-02-16T20:25:26.035222 20314] Command line: /usr/bin/ccache /usr/bin/g++ -c -pipe -g -Wall -W -D_REENTRANT -fPIE -DQT_NO_MTDEV -DQT_NO_TSLIB -DQT_NO_LIBINPUT -DQT_NO_XKB -DPROPARSER_DEBUG -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_TESTLIB_LIB -DQT_CORE_LIB -DQT_NAMESPACE=TestSpace -DQT_TESTCASE_BUILDDIR=/home/obuddenh/depot/qt5_build/qtbase/tests/auto/tools/qmakelib -I/home/obuddenh/depot/qt5/qtbase/tests/auto/tools/qmakelib -I. -I/home/obuddenh/depot/qt5/qtbase/qmake/library -I../../../../include -I../../../../include/QtTest -I../../../../include/QtCore -I.moc -I/home/obuddenh/depot/qt5/qtbase/mkspecs/linux-g++ -o .obj/qmakeparser.o /home/obuddenh/depot/qt5/qtbase/qmake/library/qmakeparser.cpp [2015-02-16T20:25:26.035255 20314] Hostname: troll08 [2015-02-16T20:25:26.035295 20314] Working directory: /home/obuddenh/depot/qt5_build/qtbase/tests/auto/tools/qmakelib [2015-02-16T20:25:26.035379 20314] Source file: /home/obuddenh/depot/qt5/qtbase/qmake/library/qmakeparser.cpp [2015-02-16T20:25:26.035393 20314] Object file: .obj/qmakeparser.o [2015-02-16T20:25:26.035412 20314] Trying direct lookup [2015-02-16T20:25:26.035865 20314] Looking for object file hash in /home/obuddenh/.ccache/1/8/3571b3286295ea842e4d0e4b5d8614-51629.manifest [2015-02-16T20:25:26.055382 20314] Got object file hash from manifest [2015-02-16T20:25:26.055444 20314] Unlink .obj/qmakeparser.o via .obj/qmakeparser.o.tmp.rm.troll08.20314 [2015-02-16T20:25:26.055697 20314] Copying /home/obuddenh/.ccache/6/1/77b6a1a9b40804c3fde51f0bc6c051-1584683.o to .obj/qmakeparser.o via .obj/qmakeparser.o.troll08.20314.XX (uncompressed) [2015-02-16T20:25:26.056724 20314] Created .obj/qmakeparser.o from /home/obuddenh/.ccache/6/1/77b6a1a9b40804c3fde51f0bc6c051-1584683.o [2015-02-16T20:25:26.056755 20314] Succeeded getting cached result [2015-02-16T20:25:26.056793 20314] Acquired lock /home/obuddenh/.ccache/6/stats.lock [2015-02-16T20:25:26.056988 20314] Releasing lock /home/obuddenh/.ccache/6/stats.lock [2015-02-16T20:25:26.057008 20314] Unlink /home/obuddenh/.ccache/6/stats.lock (as-tmp) [2015-02-16T20:25:26.057033 20314] Result: cache hit (direct) to reproduce it, you only need: qtbase/dev (@1d2efe1f27bedcbaa157ef4e82b8eda33dda46ad). this pending change: https://codereview.qt-project.org/105039 (PS3) including dependencies. this hunk on top: --- a/qmake/library/qmakeparser.cpp +++ b/qmake/library/qmakeparser.cpp @@ -1340,6 +1374,7 @@ static bool getBlock(const ushort *tokens, int limit, int offset, QString *outS return false; } *outStr += fL1S( H() + fL1S(tokNames[maskedTok]); +*outStr += fL1S( /* \\u) + QString::number(maskedTok, 16) + fL1S( */); if (tok TokNewStr) *outStr += fL1S( | TokNewStr); if (tok TokQuoted) ... and a lot of time, heh. i thought i might have some env variables set (CCACHE_UNIFY), but this doesn't appear to be the case, either. i can try to extract a smaller testcase if you don't beat me to it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778388: ccache: scanner confused by comment signs in strings
On Mon, Feb 16, 2015 at 09:26:02PM +0100, Joel Rosdahl wrote: Yes, a reduced testcase would be much appreciated. I don't have access to https://codereview.qt-project.org/105039 and I wouldn't know what to do anyway. :-) oh, right, it was a draft, invite only. fixed now. i think you'll figure it out easily. anyway, cloning the whole thing seems like overkill, indeed. you can just get the patched version of the file from the diff view. from there it is extracting the code into a minimal qt/qmake project. i expect this to be a somewhat time-consuming iterative process, so i'm not exactly in a hurry ... (BTW: You did clear the cache before you compiled the changed source code, right? Otherwise a cache hit is expected from the previous experiments, of course. Just checking.) i retried with multiple string and number variants i didn't use before, so this is of no concern. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778388: ccache: scanner confused by comment signs in strings
Package: ccache Version: 3.1.10-1 Severity: normal i have this fine piece of code: *outStr += fL1S( /* \\u) + QString::number(maskedTok, 16) + fL1S( */); if i change anything between the /* parts, ccache will think that nothing changed ... even though the comment chars are obviously quoted, so they do not denote a section that is irrelevant for comparison. as expected, the problem goes away when the line is changed to: *outStr += fL1S( /* \\u) + QString::number(maskedTok, 16) + fL1S( */); -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-1-amd64 (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages ccache depends on: ii libc6 2.19-7 ii zlib1g 1:1.2.8.dfsg-1 ccache recommends no packages. Versions of packages ccache suggests: pn distcc none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765052: mbsync: Please add a more compact output mode
well, you want it reduced to which box and how far did it already get? that can be condensed further: C: 0/2: B: 3/15 M: +0/0 *0/0 #0/0 S: +3/3 *0/0 #0/0 these being channel and box, respectively. that presentation actually becomes interesting when channels are parallelized. of course, the counters then need to be cumulative. the thing is that the totals are not known in advance (this is the case even for the existing counters), so the value as a real progress bar is somewhat limited. your presentation just hides it by giving boxes a special status. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758172: isync: Adds . to Maildir directory names
guys, i suggest you have a good look into the manual again before you say anything more. the dots in the maildir subfolders are part of the deal and have *nothing* to do with the server configuration. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758172: isync: Adds . to Maildir directory names
https://sourceforge.net/p/isync/mailman/message/30694372/ https://sourceforge.net/p/isync/feature-requests/5/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743725: rkhunter: systemd support
Package: rkhunter Version: 1.4.0-3 Followup-For: Bug #743725 with debian's push for systemd, this upgrade becomes more pressing - without it, it constantly reports Warning: No running system logging daemon has been found. because 1.4.0 does not recognize journald. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749224: libgl1-mesa-dev: excessive dependencies when using proprietary nvidia driver
Package: libgl1-mesa-dev Version: 9.2.2-1 Severity: normal some years ago, nvidia said that people should compile applications against the official GL headers, and debian followed suit, eliminating the nvidia-glx-dev package, leaving mesa as the only libgl-dev provider. however, the libgl1-mesa-dev package of course depends on libgl1-mesa-glx, which pulls in the whole mesa stack including llvm. that's tens of megabytes of dead packages on a system that does not use mesa. i suggest to rectify the situation by splitting out a libgl1-mesa-minimal-dev package that provides the portable gl headers and making that a libgl-dev provider. the package should only depend on the virtual libgl1 package. in the next step, packages which explicitly depend on libgl1-mesa-dev (e.g. libcairo2-dev, which made me notice the problem to start with) should be adjusted accordingly. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687607: isync: Still no recursive sync?
i don't think there is any other explanation for your observation than that you are doing it wrong. because it works pretty well, within some limits. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744389: [commit] isync_1_1_branch: don't lie about the default of User
commit 4ab12ae76e8a266ba3660b5cc2042946c7bfa653 Author: Oswald Buddenhagen o...@users.sf.net Date: Sun Apr 13 17:07:53 2014 +0200 don't lie about the default of User unlike the isync wrapper, mbsync does not have a default for the IMAP user. the remote user seldomly matches the local one, so forwarding it is more confusing than helpful. CCMAIL: 744...@bugs.debian.org src/mbsync.1 |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/mbsync.1 b/src/mbsync.1 index e2fe2b3..a2335d9 100644 --- a/src/mbsync.1 +++ b/src/mbsync.1 @@ -245,7 +245,7 @@ Specify the TCP port number of the IMAP server. (Default: 143 for IMAP, .. .TP \fBUser\fR \fIusername\fR -Specify the login name on the IMAP server. (Default: current local user) +Specify the login name on the IMAP server. .. .TP \fBPass\fR \fIpassword\fR -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/debian-bugs-dist
Bug#744259: [commit] isync_1_1_branch: don't forget to reset message counts when skipping scan
commit 4d8575100d208129bc5d45e3968262415602ac04
Author: Oswald Buddenhagen o...@users.sf.net
Date: Sat Apr 12 19:02:06 2014 +0200
don't forget to reset message counts when skipping scan
amends b6949c64d2.
CCMAIL: 744...@bugs.debian.org
src/drv_maildir.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/src/drv_maildir.c b/src/drv_maildir.c
index 34c38b6..0f58318 100644
--- a/src/drv_maildir.c
+++ b/src/drv_maildir.c
@@ -1030,8 +1030,10 @@ maildir_load( store_t *gctx, int minuid, int maxuid, int
newuid, int *excs, int
ctx-excs = nfrealloc( excs, nexcs * sizeof(int) );
ctx-nexcs = nexcs;
- if (ctx-fresh)
+ if (ctx-fresh) {
+ ctx-gen.count = ctx-gen.recent = 0;
goto dontscan;
+ }
if (maildir_scan( ctx, msglist ) != DRV_OK) {
cb( DRV_BOX_BAD, aux );
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/debian-bugs-dist
Bug#737708: [commit] isync_1_1_branch: rework maildir store mapping
commit 19d86d2aa9415047d8e0a391bd2502023bff80fc
Author: Oswald Buddenhagen o...@users.sf.net
Date: Mon Mar 10 11:57:37 2014 +0100
rework maildir store mapping
the trivial approach of having home and root stores produced ugly
results, and totally failed with the introduction of nested folder
handling.
instead, create a store per local directory, just as one would manually.
CCMAIL: 737...@bugs.debian.org
src/compat/config.c | 86 +++
src/compat/isync.h |7 +++
src/compat/util.c | 13 ++
3 files changed, 82 insertions(+), 24 deletions(-)
diff --git a/src/compat/config.c b/src/compat/config.c
index 2e160b6..39bbbe9 100644
--- a/src/compat/config.c
+++ b/src/compat/config.c
@@ -29,8 +29,6 @@
#include stdio.h
#include ctype.h
-static int local_home, local_root;
-
static char *
my_strndup( const char *s, size_t nchars )
{
@@ -121,16 +119,6 @@ load_config( const char *path, config_t ***stor )
cfg = **stor = nfmalloc( sizeof(config_t) );
*stor = cfg-next;
memcpy( cfg, global, sizeof(config_t) );
- if (val[0] == '~' val[1] == '/') {
- val += 2;
- local_home = 1;
- } else if (!memcmp( val, Home, HomeLen )
val[HomeLen] == '/') {
- val += HomeLen + 1;
- local_home = 1;
- } else if (val[0] == '/')
- local_root = 1;
- else
- local_home = 1;
/* not expanded at this point */
cfg-path = nfstrdup( val );
} else if (!strcasecmp( OneToOne, cmd )) {
@@ -382,7 +370,9 @@ write_config( int fd )
{
FILE *fp;
const char *cn, *scn;
+ char *path, *local_box, *local_store;
config_t *box, *sbox, *pbox;
+ int pl;
if (!(fp = fdopen( fd, w ))) {
perror( fdopen );
@@ -395,15 +385,17 @@ write_config( int fd )
if (global.expunge || expunge)
fputs( Expunge Both\n, fp );
fputc( '\n', fp );
- if (local_home || o2o)
- fprintf( fp, MaildirStore local\nPath \%s/\\nInbox
\%s/INBOX\\nAltMap %s\n\n,
-maildir, maildir, tb( altmap 0 ) );
- if (local_root)
- fprintf( fp, MaildirStore local_root\nPath /\nAltMap %s\n\n,
tb( altmap 0 ) );
if (o2o) {
write_imap_server( fp, global );
write_imap_store( fp, global );
- fprintf( fp, Channel o2o\nMaster :%s:\nSlave :local:\nPattern
%%\n, global.store_name );
+ fprintf( fp, MaildirStore local\nPath %s/\n, quotify( maildir
) );
+ if (!inbox) { /* just in case listing actually produces an
INBOX ... */
+ nfasprintf( (char **)inbox, %s/INBOX, maildir );
+ fprintf( fp, Inbox %s\n, quotify( inbox ) );
+ }
+ if (altmap 0)
+ fputs( AltMap yes\n, fp );
+ fprintf( fp, \nChannel o2o\nMaster :%s:\nSlave
:local:\nPattern %%\n, global.store_name );
write_channel_parm( fp, global );
} else {
for (box = boxes; box; box = box-next) {
@@ -446,6 +438,55 @@ write_config( int fd )
gotsrv:
write_imap_store( fp, box );
gotall:
+
+ path = expand_strdup( box-path );
+ if (!memcmp( path, Home, HomeLen ) path[HomeLen] ==
'/')
+ nfasprintf( path, ~%s, path + HomeLen );
+ local_store = local_box = strrchr( path, '/' ) + 1;
+ pl = local_store - path;
+ /* try to re-use existing store */
+ for (pbox = boxes; pbox != box; pbox = pbox-next)
+ if (pbox-local_store_path !memcmp(
pbox-local_store_path, path, pl ) !pbox-local_store_path[pl])
+ goto gotstor;
+ box-local_store_path = my_strndup( path, pl );
+ /* derive a suitable name */
+ if (!strcmp( box-local_store_path, /var/mail/ ) ||
!strcmp( box-local_store_path, /var/spool/mail/ )) {
+ local_store = nfstrdup( spool );
+ } else if (!strcmp( box-local_store_path, ~/ )) {
+ local_store = nfstrdup( home );
+ } else {
+ local_store = memrchr( box-local_store_path,
'/', pl - 1 );
+ if (local_store) {
+ local_store = my_strndup( local_store +
1, pl - 2
Bug#737708: isync: Mailbox path corruption
On Fri, Feb 07, 2014 at 12:30:02PM +0400, Eugene Berdnikov wrote: If this is a wrapper bug, it should be also fixed, I think. obviously SyncState * MaildirStore local Path ~/ Path ~/Mail/ Inbox ~/INBOX Inbox /var/mail/berd AltMap no MaildirStore local_root [...] nuke the entire section. Channel main Master :rdtex:INBOX Slave :local_root:var/mail/berd Master :rdtex: Slave :local: Expunge Both Channel is_spam Master :rdtex:is_spam Slave :local:Mail/is_spam Master :rdtex:is_spam Slave :local:is_spam Expunge Both -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737708: isync: Mailbox path corruption
On Fri, Feb 07, 2014 at 10:54:12AM +0400, Eugene Berdnikov wrote: On Wed, Feb 05, 2014 at 12:44:01PM +0100, Oswald Buddenhagen wrote: this appears to be an upstream bug in the compatibility wrapper. you can migrate to the proper mbsync by running isync -w and fixing the broken .mbsyncrc by hand. Tried: run isync -w from 1.1.0-1 package. Resultimg .mbsyncrc does not contain dots in file paths. However, running mbsync -a on it gives the same result (errors messages about broken file paths). Change paths in .mbsyncrc to absolute does not help. the problem must be that you have a path in the mailbox name, while it should be only in the Path element. i.e., the local_root hack just doesn't work any more. i can't give you a complete config, because you didn't, either... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737708: isync: Mailbox path corruption
this appears to be an upstream bug in the compatibility wrapper. you can migrate to the proper mbsync by running isync -w and fixing the broken .mbsyncrc by hand. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734164: console-data: should conflict with console-setup
anton, On Sat, Jan 11, 2014 at 01:27:39PM +0200, Anton Zinoviev wrote: This is what I would do if I was in your position: [...] your proposal is completely useless to users in my position. console-setup *does* break console-data, because its mere presence makes the debconf setup of console-data ineffective (note that this also closely relates with the kdb package). i don't care whether that results in a dpkg Breaks statement, but the situation must be made *damn obvious* to make system upgrades not just plain broken from a user perspective. and get over the idea that free software is all about choice (for its own sake). there is enough research which discredits this position. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734164: console-data: should conflict with console-setup
On Sat, Jan 11, 2014 at 06:48:24PM +0200, Anton Zinoviev wrote: Console-setup doesn't break console-data for the following reasons: 2. console-setup can be configured not to overwrite the configuration of console-data. nobody talked about overwriting. the phrase was made ineffective. anyway, i don't know whether i'm talking about console-data at all at this point, because things are such a mess. it's where i configured my keymap, in any case. previously. open /etc/init.d/kbd and look for HAVE_SETUPCON. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734164: console-data: should conflict with console-setup
Package: console-data Version: 1.12-3 Severity: normal console-data appears to be mostly deprecated in favor of console-setup, and is overridden by the latter if it is installed. this isn't exactly obvious without reading through the scripts, and leads to problems like bug #626680, ubuntu bug 521878, and a lot more confused users. the two packages should conflict to provide an indication of the situation. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12.1 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages console-data depends on: ii debconf [debconf-2.0] 1.5.52 Versions of packages console-data recommends: pn console-common none ii kbd 1.15.5-1 Versions of packages console-data suggests: pn unicode-data none -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727239: isync: segfault when not configured and invoked with arguments
this was fixed one commit after 1.0.4, five and a half years ago. the 1.0.5 release was a bit over a year ago, finally. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725503: libruby1.9.1: misguided alternative selection
Package: libruby1.9.1 Version: 1.9.3.448-1 Severity: normal the file /etc/bash_completion.d/gem is an alternative. however, the file offered as an alternative is /etc/bash_completion.d/gem1.9.1 ... which means that in reality, *both* files will be loaded. note that this would be different if the file was installed to /usr/share/bash-completion/completions, as these files are loaded on-demand. i don't quite understand what that alternative selection is supposed to be good for anyway - the completion is based on the command name in the completion script itself, so in either case you're only completing for gem1.9.1. if you meant to make completion for gem, you'd need some trickery with $0. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11.0 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libruby1.9.1 depends on: ii libc6 2.17-92+b1 ii libffi6 3.0.13-4 ii libgdbm3 1.8.3-12 ii libncurses5 5.9+20130608-1 ii libncursesw5 5.9+20130608-1 ii libreadline6 6.2+dfsg-0.1 ii libssl1.0.0 1.0.1e-3 ii libtinfo5 5.9+20130608-1 ii libyaml-0-2 0.1.4-2 ii zlib1g1:1.2.8.dfsg-1 libruby1.9.1 recommends no packages. libruby1.9.1 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
