Bug#1069864: busybox: Please enable "install" applet
Package: busybox Version: 1:1.35.0-4+b3 Severity: wishlist Tags: patch Hi, BusyBox can provide a simple version of "install" command (https://busybox.net/downloads/BusyBox.html#install). Unfortunately, in the package configuration, the options responsible for enabling this applet are not set: # CONFIG_INSTALL is not set # CONFIG_FEATURE_INSTALL_LONG_OPTIONS is not set (for all 3 packages - regular, static and udeb) This is a quite frequently used command that is part of coreutils, so it is worth making it available in the minimal environment provided by BusyBox. Simple patch (for regular package) attached. Regards, Robert Paciorek -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-9-amd64 (SMP w/6 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages busybox depends on: ii libc6 2.36-9+deb12u4 busybox recommends no packages. busybox suggests no packages. -- no debconf information --- busybox-1.36.1.org/debian/config/pkg/deb2023-11-13 13:46:07.0 + +++ busybox-1.36.1/debian/config/pkg/deb2024-04-24 02:07:05.532609382 + @@ -265,8 +265,8 @@ CONFIG_HOSTID=y CONFIG_ID=y CONFIG_GROUPS=y -# CONFIG_INSTALL is not set -# CONFIG_FEATURE_INSTALL_LONG_OPTIONS is not set +CONFIG_INSTALL=y +CONFIG_FEATURE_INSTALL_LONG_OPTIONS=y CONFIG_LINK=y CONFIG_LN=y CONFIG_LOGNAME=y
Bug#1069773: linux-image-6.1.0-20-amd64: Bluetooth fails to resume after suspend with linux-image-6.1.0-20
Package: src:linux
Version: 6.1.85-1
Severity: important
Dear Maintainer,
After upgrading to linux-image-6.1.0-20-amd64 and rebooting my laptop, my
Bluetooth mouse failed to work after resuming from suspend (via closing and
reopening my laptop). Manually stopping and starting Bluetooth via the Gnome
controls allowed the mouse to reconnect.
I experimented and determined that any time I suspended by closing the lid,
when it resumed, my mouse would not automatically reconnect and Bluetooth had
to be manually restarted, either by GUI or by systemctl. Additionally, after
each suspend, two additional lines got appended to the linux console log:
Bluetooth: hci0: Opcode 0xc24 failed: -112
Bluetooth: hci0: unexpected event for opcode 0x0406
When I rebooted into linux-image-6.1.0-18-amd64, the previous kernel, I was
able to suspend and resume without any issues from Bluetooth, and the above two
lines were not appended to the console log after each suspend.
This seems to be some sort of regression in Bluetooth device handling. While I
only have a mouse to test, I'd guess that other types of devices may also be
affected.
-- Package-specific info:
** Version:
Linux version 6.1.0-20-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian
12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP
PREEMPT_DYNAMIC Debian 6.1.85-1 (2024-04-11)
** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.1.0-20-amd64
root=UUID=4b219315-d9dc-4199-8fc6-e3d5042f5df4 ro quiet
** Tainted: POE (12289)
* proprietary module was loaded
* externally-built ("out-of-tree") module was loaded
* unsigned module was loaded
** Kernel log:
[5.312310] sof-audio-pci-intel-tgl :00:1f.3: bound :00:02.0 (ops
i915_audio_component_bind_ops [i915])
[5.319244] sof-audio-pci-intel-tgl :00:1f.3: use msi interrupt mode
[5.335718] kauditd_printk_skb: 14 callbacks suppressed
[5.335720] audit: type=1400 audit(1713958189.171:25): apparmor="STATUS"
operation="profile_load" profile="unconfined" name="/usr/bin/evince" pid=794
comm="apparmor_parser"
[5.335723] audit: type=1400 audit(1713958189.171:26): apparmor="STATUS"
operation="profile_load" profile="unconfined"
name="/usr/bin/evince//sanitized_helper" pid=794 comm="apparmor_parser"
[5.335725] audit: type=1400 audit(1713958189.171:27): apparmor="STATUS"
operation="profile_load" profile="unconfined" name="/usr/bin/evince-previewer"
pid=794 comm="apparmor_parser"
[5.335727] audit: type=1400 audit(1713958189.171:28): apparmor="STATUS"
operation="profile_load" profile="unconfined"
name="/usr/bin/evince-previewer//sanitized_helper" pid=794
comm="apparmor_parser"
[5.335728] audit: type=1400 audit(1713958189.171:29): apparmor="STATUS"
operation="profile_load" profile="unconfined"
name="/usr/bin/evince-thumbnailer" pid=794 comm="apparmor_parser"
[5.344889] sof-audio-pci-intel-tgl :00:1f.3: hda codecs found, mask 5
[5.344891] sof-audio-pci-intel-tgl :00:1f.3: using HDA machine driver
skl_hda_dsp_generic now
[5.344893] sof-audio-pci-intel-tgl :00:1f.3: DMICs detected in NHLT
tables: 2
[5.346134] sof-audio-pci-intel-tgl :00:1f.3: firmware: direct-loading
firmware intel/sof/sof-rpl.ri
[5.346138] sof-audio-pci-intel-tgl :00:1f.3: Firmware info: version
2:2:0-57864
[5.346139] sof-audio-pci-intel-tgl :00:1f.3: Firmware: ABI 3:22:1
Kernel ABI 3:23:0
[5.346141] sof-audio-pci-intel-tgl :00:1f.3: unknown sof_ext_man header
type 3 size 0x30
[5.369054] audit: type=1400 audit(1713958189.203:30): apparmor="STATUS"
operation="profile_load" profile="unconfined" name="libreoffice-soffice"
pid=799 comm="apparmor_parser"
[5.369074] intel_rapl_common: Found RAPL domain package
[5.369081] audit: type=1400 audit(1713958189.203:31): apparmor="STATUS"
operation="profile_load" profile="unconfined" name="libreoffice-soffice//gpg"
pid=799 comm="apparmor_parser"
[5.391433] input: ThinkPad Extra Buttons as
/devices/platform/thinkpad_acpi/input/input16
[5.443377] sof-audio-pci-intel-tgl :00:1f.3: Firmware info: version
2:2:0-57864
[5.443381] sof-audio-pci-intel-tgl :00:1f.3: Firmware: ABI 3:22:1
Kernel ABI 3:23:0
[5.448092] sof-audio-pci-intel-tgl :00:1f.3: firmware: direct-loading
firmware intel/sof-tplg/sof-hda-generic-2ch.tplg
[5.448097] sof-audio-pci-intel-tgl :00:1f.3: Topology: ABI 3:22:1
Kernel ABI 3:23:0
[5.448233] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: Parent card not
yet available, widget card binding deferred
[5.464806] typec port0: bound usb1-port5 (ops connector_ops [usbcore])
[5.464822] typec port0: bound usb4-port1 (ops connector_ops [usbcore])
[5.476776] snd_hda_codec_realtek ehdaudio0D0: autoconfig for ALC257:
line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker
[5.476779] snd_hda_codec_realtek ehdaudio0D0:speaker_outs=0
(0x0/0x0/0x0/0x0/0x0)
[5.476780] snd_hda_codec_realtek ehdaudio0D0:hp_outs=1
Bug#1069499: mtbl: FTBFS on armhf: dh_auto_test: error: make -j4 check "TESTSUITEFLAGS=-j4 --verbose" VERBOSE=1 returned exit code 2
Lucas Nussbaum wrote: > Source: mtbl > Version: 1.3.0-1 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20240420 ftbfs-trixie ftbfs-t64-armhf > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on armhf. > > > Relevant part (hopefully): > > test-sorted-merge: t/test-sorted-merge.c:96: quiet_tmpnam: Assertion > > `not_found == 1' failed. Hi, Lucas: I see the function that failed here has been entirely rewritten since this release, so I've uploaded the latest upstream version 1.6.1 and that built successfully on all architectures. So I'll mark this bug fixed in 1.6.1-1. Thanks! -- Robert Edmonds edmo...@debian.org
Bug#1068517: kate: request to backport patch for upstream bug 476307
Package: kate Version: 4:22.12.3-1 Severity: normal Dear Maintainer, Upstream bug https://bugs.kde.org/show_bug.cgi?id=476307 has been reported resolved by MR https://invent.kde.org/utilities/kate/-/merge_requests/1441 It would be extremely helpful if you were able to pull the patch back to bookworm, or at least ensure the fix is included in the next stable, as the bug causes me pain every day. -- System Information: Debian Release: 12.5 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kate depends on: ii kate5-data 4:22.12.3-1 ii kio 5.103.0-1 ii ktexteditor-katepart 5.103.0-1.1 ii libc62.36-9+deb12u4 ii libkf5activities55.103.0-1 ii libkf5bookmarks5 5.103.0-1 ii libkf5completion55.103.0-1 ii libkf5configcore55.103.0-2 ii libkf5configgui5 5.103.0-2 ii libkf5configwidgets5 5.103.0-1 ii libkf5coreaddons55.103.0-1 ii libkf5crash5 5.103.0-1 ii libkf5dbusaddons55.103.0-1 ii libkf5guiaddons5 5.103.0-1 ii libkf5i18n5 5.103.0-1 ii libkf5iconthemes55.103.0-1 ii libkf5jobwidgets55.103.0-1 ii libkf5kiocore5 5.103.0-1 ii libkf5kiofilewidgets55.103.0-1 ii libkf5kiogui55.103.0-1 ii libkf5kiowidgets55.103.0-1 ii libkf5newstuff5 5.103.0-1 ii libkf5newstuffcore5 5.103.0-1 ii libkf5newstuffwidgets5 5.103.0-1 ii libkf5parts5 5.103.0-1 ii libkf5service-bin5.103.0-1 ii libkf5service5 5.103.0-1 ii libkf5syntaxhighlighting55.103.0-3 ii libkf5texteditor55.103.0-1.1 ii libkf5textwidgets5 5.103.0-1 ii libkf5wallet-bin 5.103.0-1 ii libkf5wallet55.103.0-1 ii libkf5widgetsaddons5 5.103.0-1 ii libkf5windowsystem5 5.103.0-1 ii libkf5xmlgui55.103.0-1 ii libkuserfeedbackcore11.2.0-2 ii libkuserfeedbackwidgets1 1.2.0-2 ii libqt5concurrent55.15.8+dfsg-11 ii libqt5core5a 5.15.8+dfsg-11 ii libqt5dbus5 5.15.8+dfsg-11 ii libqt5gui5 5.15.8+dfsg-11 ii libqt5network5 5.15.8+dfsg-11 ii libqt5sql5 5.15.8+dfsg-11 ii libqt5widgets5 5.15.8+dfsg-11 ii libqt5xml5 5.15.8+dfsg-11 ii libstdc++6 12.2.0-14 ii plasma-framework 5.103.0-1+deb12u1 ii qml-module-org-kde-kquickcontrolsaddons 5.103.0-1 ii qml-module-qtquick-layouts 5.15.8+dfsg-3 ii qml-module-qtquick2 5.15.8+dfsg-3 Versions of packages kate recommends: ii sonnet-plugins 5.103.0-1 Versions of packages kate suggests: pn darcs pn exuberant-ctags ii git 1:2.39.2-1.1 ii khelpcenter 4:22.12.3-1 ii konsole-kpart4:22.12.3-1 ii mercurial6.3.2-1 pn subversion -- no debconf information
Bug#1068489: O: clamassassin -- email virus filter wrapper for ClamAV
Package: wnpp Severity: normal X-Debbugs-Cc: clamassas...@packages.debian.org Control: affects -1 + src:clamassassin I intend to orphan the clamassassin package. I no longer use this package, and I'm not sure if upstream is still maintaining it (I could not find a current location distributing this software). Nowadays I think there are plugins for rspamd and spamassassin that can do this kind of scanning. The package description is: clamassassin is a simple virus filter wrapper for ClamAV for use in procmail filters and similar applications. clamassassin's interface is similar to that of spamassassin, making it easy to implement for those familiar with that tool. clamassassin is designed with an emphasis on security, robustness and simplicity.
Bug#1039889: recommends old ffmpeg libs
Any news on this? pqiv used to be able to playback videos (mp4 / mpg) on debian 11 (and still after updating to 12). With a fresh install of debian 12 (pqiv 2.12) pqiv cannot do this anymore. Robert
Bug#1021738: man2html: CVE-2021-40647 CVE-2021-40648
clone 1021738 -1 retitle 1021738 man2html: CVE-2021-40647 tags 1021738 +pending retitle -1 man2html: CVE-2021-40648 tags -1 +moreinfo thanks Moritz Mühlenhoff pisze: Hi First of all I'm sorry for not taking care about it earlier, I didn't have time for Debian work in the previous year. The following vulnerabilities were published for man2html. CVE-2021-40647[0]: Ok, this is quite easy to fix, I will upload fixed version soon. CVE-2021-40648[1]: | In man2html 1.6g, a filename can be created to overwrite the previous | size parameter of the next chunk and the fd, bk, fd_nextsize, According to instructions given at https://gist.github.com/untaman/cb58123fe89fc65e3984165db5d40933 I tried to reproduce this with the following commands: file=$(perl -e 'print "A" x 132') touch $file man2html $file I used man2html built with AddressSanitizer and it found only a few small memory leaks coming from global variables. So I have no idea what really is wrong in this CVE. The source code references given at the above link actually refer to calls to fopen()/fclose() functions rather then to directly malloc() and free() directly. Regards, robert
Bug#1061928: avro-c: NMU diff for 64-bit time_t transition
Steve Langasek wrote: > Hi Robert, > > On Tue, Jan 30, 2024 at 02:05:11PM -0500, Robert Edmonds wrote: > > Steve Langasek wrote: > > > As part of the 64-bit time_t transition required to support 32-bit > > > architectures in 2038 and beyond > > > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified > > > avro-c as a source package shipping runtime libraries whose ABI > > > either is affected by the change in size of time_t, or could not be > > > analyzed via abi-compliance-checker (and therefore to be on the safe > > > side we assume is affected). > > > Hi, Steve: > > > I'm not aware of anything in avro-c that embeds time_t, or really any > > platform-provided structs, into the API/ABI. Can you point me to the > > actual changes in the avro-c ABI due to this change? > > > Thanks! > > avro-c falls into the second of these categories, "or could not be analyzed > and therefore we assume is affected". > > Output of the attempt to analyze the package with abi-compliance-checker: > https://adrien.dcln.fr/misc/armhf-time_t/2024-01-17/logs/libavro-dev/base/log.txt Ah, I see, so basically every header in the -dev package is getting included: // add includes #include "/usr/include/avro/allocation.h" #include "/usr/include/avro/basics.h" #include "/usr/include/avro/consumer.h" #include "/usr/include/avro/data.h" #include "/usr/include/avro/errors.h" #include "/usr/include/avro/generic.h" #include "/usr/include/avro/io.h" #include "/usr/include/avro/legacy.h" #include "/usr/include/avro/msinttypes.h" #include "/usr/include/avro/msstdint.h" #include "/usr/include/avro/platform.h" #include "/usr/include/avro/refcount.h" #include "/usr/include/avro/resolver.h" #include "/usr/include/avro/schema.h" #include "/usr/include/avro/value.h" #include "/usr/include/avro.h" I guess you have to do it that way since there isn't really anything universal and machine readable that says: this is the public API header file to include to use this library. For avro-c in particular the documentation of the library is here: https://avro.apache.org/docs/1.11.1/api/c/ And they only mention including to users of the library. So those headers that work around problems on Microsoft platforms don't end up getting included on other systems since the #include's of those headers are conditionalized. > This shows there are headers that can't be compiled because they're > Windows-specific. So it seems counterproductive to ship these at all in > Debian? > > If this header were removed from the package, or if a quirk were added to > https://salsa.debian.org/vorlon/armhf-time_t/-/blob/main/check-armhf-time_t?ref_type=heads > to exclude the incorrect headers from the analysis, we could confirm that > avro-c is unaffected and avoid unnecessary NMUs / transitions to unstable. If there is a way to quirk the avro-c package for this analysis so you only include /usr/include/avro.h rather than every header file shipped in the -dev package I think it would let your analysis succeed, without missing anything, and, I would guess that that analysis would show no ABI changes and thus no ABI transition is necessary. I'm also open to just dropping those ms*.h files from the -dev package which should just work without any other changes without breaking anything else, but I haven't tested it. Thanks! -- Robert Edmonds edmo...@debian.org
Bug#1061928: avro-c: NMU diff for 64-bit time_t transition
Steve Langasek wrote: > As part of the 64-bit time_t transition required to support 32-bit > architectures in 2038 and beyond > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified > avro-c as a source package shipping runtime libraries whose ABI > either is affected by the change in size of time_t, or could not be > analyzed via abi-compliance-checker (and therefore to be on the safe > side we assume is affected). Hi, Steve: I'm not aware of anything in avro-c that embeds time_t, or really any platform-provided structs, into the API/ABI. Can you point me to the actual changes in the avro-c ABI due to this change? Thanks! -- Robert Edmonds edmo...@debian.org
Bug#1061409: rasdaemon does not actually support PAGE_CE_ACTION etc.
Package: rasdaemon Version: 0.6.8-1.1 rasdaemon upstream offers the ability to offline memory when failures are detected (see <https://github.com/mchehab/rasdaemon/commit/9ae6b70eff>). Debian's rasdaemon includes the configuration files to do that at /etc/default/rasdaemon, with lines like: PAGE_CE_REFRESH_CYCLE="24h" PAGE_CE_THRESHOLD="50" PAGE_CE_ACTION="soft" This makes it look like the feature is enabled. However, those settings in /etc/default/rasdaemon are never actually used, and rasdaemon will never try to offline failing memory, because the Debian package is not compiled with the necessary "--enable-memory-ce-pfa" flag. Compiling rasdaemon with "--enable-memory-ce-pfa" would fix this. I tested compiling with that extra flag, and if you do so, these new lines are emitted in the logs when it is started, indicating the code is working: rasdaemon: Page offline choice on Corrected Errors is soft rasdaemon: Threshold of memory Corrected Errors is 50 / 24h I'd like to suggest that this option be enabled. If people don't want to use this feature, they can edit /etc/default/rasdaemon as documented to change it to PAGE_CE_ACTION="off". If it is decided not to enable this feature, then /etc/default/rasdaemon should be modified to remove these options so it doesn't look like it is enabled. -- Robert L Mathews
Bug#1061270: lintian: Reports bogus bin-sbin-mismatch issues
Package: lintian Version: 2.116.3 Severity: normal For dwww package lintian reports: X: dwww: bin-sbin-mismatch usr/sbin/dwww -> usr/bin/dwww [etc/cron.daily/dwww] X: dwww: bin-sbin-mismatch usr/sbin/dwww -> usr/bin/dwww [etc/cron.weekly/dwww] X: dwww: bin-sbin-mismatch usr/sbin/dwww -> usr/bin/dwww [postinst] X: dwww: bin-sbin-mismatch usr/sbin/dwww -> usr/bin/dwww [usr/lib/cgi-bin/dwww] X: dwww: bin-sbin-mismatch usr/sbin/dwww -> usr/bin/dwww [usr/sbin/dwww-refresh-cache] And lintian is simply wrong here. The dwww package contains a single /usr/bin/dwww command and a few other /usr/sbin/dwww-something commands. All the scripts listed above check the commands correcly. For example /etc/cron-weekly/dwww basically contains this (unimportant stuff removed): # check if swish++ is installed test -x /usr/bin/index++ || exit 0 # check if dwww is still installed test -x /usr/sbin/dwww-index++ || exit 0 # See ionice(1) [ -x /usr/bin/ionice ] && IONICE="/usr/bin/ionice -c3 -t" || IONICE= $IONICE dwww-index++ > /dev/null Regards, robert -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (990, 'unstable-debug'), (990, 'stable-updates'), (990, 'stable-security'), (990, 'unstable'), (990, 'stable'), (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.11-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages lintian depends on: ii binutils2.41.90.20240115-1 ii bzip2 1.0.8-5+b2 ii diffstat1.65-1 ii dpkg1.22.2 ii dpkg-dev1.22.2 ii file1:5.45-2+b1 ii gettext 0.21-14 ii gpg 2.2.40-1.1+b1 ii intltool-debian 0.35.0+20060710.6 ii iso-codes 4.16.0-1 ii libapt-pkg-perl 0.1.40+b3 ii libarchive-zip-perl 1.68-1 ii libberkeleydb-perl 0.64-2+b2 ii libcapture-tiny-perl0.48-2 ii libclass-xsaccessor-perl1.19-4+b2 ii libclone-perl 0.46-1+b1 ii libconfig-tiny-perl 2.30-1 ii libconst-fast-perl 0.014-2 ii libcpanel-json-xs-perl 4.37-1+b1 ii libdata-dpath-perl 0.59-1 ii libdata-validate-domain-perl0.10-1.1 ii libdata-validate-uri-perl 0.07-2 ii libdevel-size-perl 0.83-2+b2 pn libdigest-sha-perl ii libdpkg-perl1.22.2 ii libemail-address-xs-perl1.05-1+b2 ii libfile-basedir-perl0.09-2 ii libfile-find-rule-perl 0.34-3 ii libfont-ttf-perl1.06-2 ii libhtml-html5-entities-perl 0.004-3 ii libhtml-tokeparser-simple-perl 3.16-4 ii libio-interactive-perl 1.025-1 ii libipc-run3-perl0.048-3 ii libjson-maybexs-perl1.004005-1 ii liblist-compare-perl0.55-2 ii liblist-someutils-perl 0.59-1 ii liblist-utilsby-perl0.12-2 ii libmldbm-perl 2.05-4 ii libmoo-perl 2.005005-1 ii libmoox-aliases-perl0.001006-2 ii libnamespace-clean-perl 0.27-2 ii libpath-tiny-perl 0.144-1 ii libperlio-gzip-perl 0.20-1+b2 ii libperlio-utf8-strict-perl 0.010-1+b1 ii libproc-processtable-perl 0.636-1+b1 ii libregexp-wildcards-perl1.05-3 ii libsereal-decoder-perl 5.004+ds-1+b1 ii libsereal-encoder-perl 5.004+ds-1+b1 ii libsort-versions-perl 1.62-3 ii libsyntax-keyword-try-perl 0.29-1+b1 ii libterm-readkey-perl2.38-2+b2 ii libtext-levenshteinxs-perl 0.03-5+b2 ii libtext-markdown-discount-perl 0.16-1+b1 ii libtext-xslate-perl 3.5.9-1+b3 ii libtime-duration-perl 1.21-2 ii libtime-moment-perl 0.44-2+b2 ii libtimedate-perl2.3300-2 ii libunicode-utf8-perl0.62-2+b1 ii liburi-perl 5.21-1 ii libwww-mechanize-perl 2.17-1 ii libwww-perl 6.73-1 ii libxml-libxml-perl 2.0207+dfsg+really+2.0134-1+b2 ii libyaml-libyaml-perl0.86+ds-1+b1 ii lzip [lzip-decompressor]1.23-6 ii lzop1.04-2 ii man-db 2.12.0-3 ii patchutils 0.4.2-1 ii perl [libencode-perl] 5.38.2-3 ii t1utils 1.41-4 ii unzip 6.0-28 ii xz-utils5.4.5-0.3 lintian recommends no packages. Versions of packages lintian sugg
Bug#1061271: reportbug: Please make "Selected mail user agent cannot be found" more user friendly
Package: reportbug Version: 12.0.0 Severity: wishlist Today I've tried to run reportbug after a pretty long time of not using it, and it turned out that it did nothing, but printing something like: "Selected mail user agent cannot be found, exiting". It took me a few minutes to discover that I have ~/.reportbugrc from 2012 containing a "mutt" line, but mutt package was no longer installed on my system (most likely it got removed some time ago by mistake). After reinstalling mutt, reportbug started working fine. But I wish the message printed by reportbug in such cases would be more helpful. It would be nice if it could at least include the name of the selected mua, for example: "Selected mail user agent 'mutt' cannot be found". (It would be even greater if it could print the name of the config file as well, e.g. "Mail user agent 'mutt' selected in ~/.reportbugrc cannot be found"). Regards, robert -- Package-specific info: ** Environment settings: EDITOR="vim" DEBEMAIL="rob...@debian.org" DEBFULLNAME="Robert Luberda" INTERFACE="text" ** /home/robert/.reportbugrc: reportbug_version "1.99.29" mode advanced ui text realname "Robert Luberda" email "rob...@debian.org" no-cc offline mutt -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (990, 'unstable-debug'), (990, 'stable-updates'), (990, 'stable-security'), (990, 'unstable'), (990, 'stable'), (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.11-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages reportbug depends on: ii apt2.7.10 ii python33.11.6-1 ii python3-reportbug 12.0.0 ii sensible-utils 0.0.20 reportbug recommends no packages. Versions of packages reportbug suggests: pn claws-mail ii debconf 1.5.83 ii debsums 3.0.2.1 ii dlocate 1.12 pn emacs-bin-common ii file1:5.45-2+b1 ii gnupg 2.2.40-1.1 ii postfix [mail-transport-agent] 3.8.4-1 pn python3-urwid pn reportbug-gtk ii xdg-utils 1.1.3-4.1 Versions of packages python3-reportbug depends on: ii apt2.7.10 ii file 1:5.45-2+b1 ii python33.11.6-1 ii python3-apt2.7.5 ii python3-debian 0.1.49 ii python3-debianbts 4.0.2 ii python3-requests 2.31.0+dfsg-1 ii sensible-utils 0.0.20 python3-reportbug suggests no packages. -- no debconf information
Bug#237925: ITP: cdemu -- CD drive emulator for Linux
Hi, apologies, but I've transitioned to another task, and the estimated time for CDEmu is approximately 6 months. So whoever completes their task first can take care of the CDEmu maintenance. On Tue, Jan 16, 2024 at 12:49 AM Matteo Bini wrote: > > Control: owner 237925 Matteo Bini > > Hi Christoph, hi Robert. > > I'm still going to package CDEmu, but I don't know exactly when. There > are a few things I need to better understand before I can do it, for > instance if it's fine to make as many DEB packages as the source > tarballs CDEmu is divided in. Moreover right now I'm a bit busy. > > CDEmu is on my to do list. However if Robert has time to spare and would > like to take care of it, he's most welcome. > > My current ETA is about four months from now. > > Thank you for your interest. > > -- > Matteo Bini
Bug#1060228: qt6-multimedia: Cmake config for MultimediaQuickPrivate is not packaged
Source: qt6-multimedia Version: 6.4.2-11 Severity: normal X-Debbugs-Cc: rob...@griebl.org Hi, The Debian Qt6 MM packages are not shipping with a cmake config for the private module "MultimediaQuickPrivate". While you normally do not have to deal with this private module, you definitely DO need it when using qmltc to compile QML code using QtMultiMedia QML types, as qmltc generates code that includes private headers from there: Failed to find required Qt component "MultimediaQuickPrivate". [cmake] [cmake] Expected Config file at [cmake] "/usr/lib/x86_64-linux-gnu/cmake/Qt6MultimediaQuickPrivate/Qt6MultimediaQuickPrivateConfig.cmake" [cmake] does NOT exist [cmake] Thanks for looking into this, Robert -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-4-amd64 (SMP w/32 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1059836: RM: radare2-cutter -- NPOASR; Unfit for stable release due to unrealiable upstream
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: debian-security-to...@lists.debian.org, r...@debian.org
Bug#1059505: ffmpeg: Library dependency with __attribute__((constructor)) function
d_init () at
/lib/x86_64-linux-gnu/libopenblas.so.0
#5 0x7fffe7e6807f in gotoblas_init () at
/lib/x86_64-linux-gnu/libopenblas.so.0
#6 0x77fcfe3e in call_init (env=0x7fffe7f8,
argv=0x7fffe7e8, argc=1, l=) at ./elf/dl-init.c:74
#7 call_init (l=, argc=1, argv=0x7fffe7e8,
env=0x7fffe7f8) at ./elf/dl-init.c:26
#8 0x77fcff24 in _dl_init (main_map=0x77ffe2c0, argc=1,
argv=0x7fffe7e8, env=0x7fffe7f8) at ./elf/dl-init.c:121
#9 0x77fe5500 in _dl_start_user () at /lib64/ld-linux-x86-64.so.2
#10 0x0001 in ()
#11 0x7fffeaf7 in ()
#12 0x in ()
(gdb)
Stack frames 5 and 6 show the dynamic loader calling gotoblas_init() in
libopenblas.so.0, before main() starts. And here's that function in
openblas:
https://sources.debian.org/src/openblas/0.3.25%2Bds-1/driver/others/memory.c/#L1507
Anyway, it would be nice if all programs linked against libavfilter or
libavdevice weren't forced to start up a thread pool for some other
library that happens to get pulled in but is otherwise unused. I'm not
aware of a technique to prevent a constructor function in a shared
library from running.
It looks like this is caused by ffmpeg being compiled with
--enable-pocketsphinx (at least on amd64), and indirectly by
libopenblas's API relying on an implicit __attribute__((constructor))
library initialization function rather than having an explicit library
initialization function.
Feel free to reassign this bug to src:openblas, or to clone it and
reassign to src:openblas.
Thanks!
--
Robert Edmonds
edmo...@debian.org
/*
* Compile with:
*
* gcc -O2 -Wall -o avfilter_test avfilter_test.c $(pkg-config --cflags --libs libavfilter)
*/
#define _GNU_SOURCE
#include
#include
#include
#include
int main(void) {
puts(avfilter_configuration());
putchar('\n');
char *cmd = NULL;
asprintf(, "cat /proc/%d/status | grep ^Threads", (int)getpid());
return system(cmd);
}
Bug#237925: ITP: cdemu -- CD drive emulator for Linux
I've created a tutorial for installing cdemu in Debian (using a Dockerfile), it can be easily adapted to the official Debian package(s): https://github.com/rayrapetyan/cdemu_debian_install/tree/main Produces 7 independent deb packages: vhba-dkms*.deb libmirage_*.deb (required by cdemu-daemon and image-analyzer) cdemu-daemon_*.deb cdemu-client_*.deb gcdemu*.deb gir*.deb image-analyzer*.deb If no one replies, I can take ownership of these. On Thu, 7 Jan 2021 14:54:59 +0200 Anya Annetova wrote: > Any progress on this?
Bug#1055423: O: fbpanel -- lightweight X11 desktop panel
Package: wnpp Severity: normal FBPanel is a spinoff of the fspanel (f***ing small panel) with more eye candy. It provides a taskbar (list of all opened windows), desktop switcher, launchbar, clock, is EWMH/NETWM compliant, and has modest resource usage.
Bug#1053790: Unreliable data in debsecan security tracker
Package: debsecan Version: 0.4 Given CVE-2023-4911: https://security-tracker.debian.org/tracker/CVE-2023-4911 There is no link between glibc and this CVE in data from debsecan security tracker( https://security-tracker.debian.org/tracker/debsecan/release/1/GENERIC), therefore debsecan doesn't report this CVE on any debian and we can't rely on it.
Bug#962800: Nearly identical issue as #965800
Setting up nut-client on a RPi 3B+ and a RPi 4B. admin@nut-clientns1080:~ $ upsc nut-clientns1080@localhost Error: Connection failure: Connection refused admin@nut-clientns1080:~ $ upsc nut-server...@192.168.xxx.xxx Init SSL without certificate database battery.charge: 100 battery.charge.low: 10 ## ### snipped for brevity ### ## ups.model: Back-UPS ES 550 ups.productid: 0002 ups.serial: 3B0743X46110 ups.status: OL ups.timer.reboot: 0 ups.timer.shutdown: -1 ups.vendorid: 051d admin@nut-clientns1080:~ $ sudo systemctl status nut-client ● nut-monitor.service - Network UPS Tools - power device monitor and shutdown controller Loaded: loaded (/lib/systemd/system/nut-monitor.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2023-09-25 08:25:22 EDT; 23h ago Process: 899 ExecStart=/sbin/upsmon (code=exited, status=0/SUCCESS) Main PID: 901 (upsmon) Tasks: 2 (limit: 1599) CPU: 9.925s CGroup: /system.slice/nut-monitor.service ├─900 /lib/nut/upsmon └─901 /lib/nut/upsmon Sep 25 08:25:22 nut-clientns1080 systemd[1]: Starting Network UPS Tools - power device monitor and shutdown controller... Sep 25 08:25:22 nut-clientns1080 upsmon[899]: fopen /run/nut/upsmon.pid: No such file or directory Sep 25 08:25:22 nut-clientns1080 upsmon[899]: UPS: nut-server...@192.168.xxx.xxx (slave) (power value 1) Sep 25 08:25:22 nut-clientns1080 upsmon[899]: Using power down flag file /etc/killpower Sep 25 08:25:22 nut-clientns1080 upsmon[900]: Startup successful Sep 25 08:25:22 nut-clientns1080 systemd[1]: nut-monitor.service: Can't open PID file /run/nut/upsmon.pid (yet?) after start: Operation not permitted Sep 25 08:25:22 nut-clientns1080 systemd[1]: nut-monitor.service: Supervising process 901 which is not our child. We'll most likely not notice when it exits. Sep 25 08:25:22 nut-clientns1080 upsmon[901]: Init SSL without certificate database Sep 25 08:25:22 nut-clientns1080 systemd[1]: Started Network UPS Tools - power device monitor and shutdown controller. Sep 25 08:25:22 nut-clientns1080 upsmon[901]: Login on UPS [nut-server...@192.168.xxx.xxx] failed - got [ERR ACCESS-DENIED] Output of /var/log/syslog Sep 26 07:51:41 nut-clientns1080 upsmon[901]: Signal 15: exiting Sep 26 07:51:41 nut-clientns1080 systemd[1]: Stopping Network UPS Tools - power device monitor and shutdown controller... Sep 26 07:51:41 nut-clientns1080 systemd[1]: nut-monitor.service: Succeeded. Sep 26 07:51:41 nut-clientns1080 systemd[1]: Stopped Network UPS Tools - power device monitor and shutdown controller. Sep 26 07:51:41 nut-clientns1080 systemd[1]: nut-monitor.service: Consumed 10.030s CPU time. Sep 26 07:51:41 nut-clientns1080 systemd[1]: Starting Network UPS Tools - power device monitor and shutdown controller... Sep 26 07:51:41 nut-clientns1080 upsmon[12471]: fopen /run/nut/upsmon.pid: No such file or directory Sep 26 07:51:41 nut-clientns1080 upsmon[12471]: UPS: nut-server...@192.168.xxx.xxx (slave) (power value 1) Sep 26 07:51:41 nut-clientns1080 upsmon[12471]: Using power down flag file /etc/killpower Sep 26 07:51:41 nut-clientns1080 upsmon[12473]: Startup successful Sep 26 07:51:41 nut-clientns1080 systemd[1]: nut-monitor.service: Can't open PID file /run/nut/upsmon.pid (yet?) after start: Operation not permitted Sep 26 07:51:41 nut-clientns1080 systemd[1]: nut-monitor.service: Supervising process 12474 which is not our child. We'll most likely not notice when it exits. Sep 26 07:51:41 nut-clientns1080 systemd[1]: Started Network UPS Tools - power device monitor and shutdown controller. Sep 26 07:51:41 nut-clientns1080 upsmon[12474]: Init SSL without certificate database Sep 26 07:51:41 nut-clientns1080 upsmon[12474]: Login on UPS [nut-server...@192.168.xxx.xxx] failed - got [ERR ACCESS-DENIED] Hardware in use: RPi 4B configuration: admin@nut-clientns1080:~ $ pinout Revision : b03112 SoC: BCM2711 RAM: 2GB Storage: MicroSD RPi 3B+ configuration: admin@nut-clientes550:~ $ pinout Revision : a020d3 SoC: BCM2837 RAM: 1GB Storage: MicroSD Both RPi's are running Raspbian 11 Lite 64-bit OS with current version of NUT. admin@nut-client550:~ $ sudo apt list nut Listing... Done nut/oldstable,oldstable,now 2.7.4-13 all [installed] While searching web for a solution I found Debian bug #962800. Is there a workaround available? -- --- *Bob Wooden*
Bug#1041872: command-not-found: Problem with user permission SOLVED
Package: command-not-found Version: 23.04.0-1 Followup-For: Bug #1041872 Dear Maintainer, I am writing to say that I fixed (at least) one of the problems I described in the initial bug report. Every time I typed a wrong command, a warning about "not being able to parse the sources file" was shown, which was bizarre because "apt" and "aptitude" work as expected. At the moment of filling the bug report I thought it was a problem with the file permissions because I had problems to generate the database even working as root. After a few weeks, reviewing the status of this bug, I noticed another one (#1042872) reporting the same warning but with a different file name. It was pointed out (message #10) that the source file in DEB822-format should not have a blank line before the 1st APT source. I removed the line in my file and the warning is gone. What I don't know is whether this problem was also the origin of not being able to generate the database initially. Feel free to close the bug, although I think there should be a note somewhere about this issue when installing this package. The sources.list(5) man page is clear when it describes the format of the sources files in DEB822 style. " Individual entries are separated by an empty line; additional empty lines are ignored, and a # character at the start of the line marks the entire line as a comment." Thank you for maintaining the package. Regards. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.4.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.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 command-not-found depends on: ii apt-file 3.3 ii lsb-release 12.0-2 ii python3 3.11.4-5+b1 ii python3-apt 2.6.0 command-not-found recommends no packages. Versions of packages command-not-found suggests: pn snapd -- no debconf information
Bug#945203: fwupd: Cannot update firmware
Package: fwupd Version: 1.9.3-1 Followup-For: Bug #945203 Dear Maintainer, I am writing to add that the firmware has been updated. I do not know how, when, or why. The message informing about a new possible upgrade did not show up recently. When I realized that (it took more than a few boot cycles), I reviewed the history which confirmed the upgrade. This is not helpful. I mean things happening without any supervision. Thanks anyway. Regards. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.4.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.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 fwupd depends on: ii adduser3.137 ii libarchive13 3.6.2-1 ii libc6 2.37-7 ii libcbor0.8 0.8.0-2+b1 ii libcurl3-gnutls8.2.1-1 ii libflashrom1 1.3.0-2.1 ii libfwupd2 1.9.3-1 ii libgcab-1.0-0 1.6-1 ii libglib2.0-0 2.77.1-2 ii libgnutls303.7.9-2 ii libgudev-1.0-0 237-2 ii libgusb2 0.4.5-1.1 ii libjcat1 0.1.9-1 ii libjson-glib-1.0-0 1.6.6-1 ii liblzma5 5.4.1-0.2 ii libmbim-glib4 1.28.4-2 ii libmbim-proxy 1.28.4-2 ii libmm-glib01.20.6-2 ii libpolkit-gobject-1-0 123-1 ii libprotobuf-c1 1.4.1-1+b1 ii libqmi-glib5 1.32.4-2 ii libqmi-proxy 1.32.4-2 ii libsmbios-c2 2.4.3-1 ii libsqlite3-0 3.42.0-1 ii libsystemd0254-1 ii libtss2-esys-3.0.2-0 3.2.1-3 ii libxmlb2 0.3.10-2 ii shared-mime-info 2.2-1 Versions of packages fwupd recommends: ii bolt 0.9.5-1 ii dbus 1.14.8-2 ii fwupd-amd64-signed [fwupd-signed] 1:1.4+1 ii jq 1.6-2.1 ii python33.11.4-5 pn secureboot-db ii udisks22.10.0-5 Versions of packages fwupd suggests: ii gir1.2-fwupd-2.0 1.9.3-1 -- Configuration Files: /etc/fwupd/daemon.conf [Errno 2] El fitxer o directori no existeix: '/etc/fwupd/daemon.conf' /etc/fwupd/fwupd.conf [Errno 13] S’ha denegat el permís: '/etc/fwupd/fwupd.conf' /etc/fwupd/msr.conf [Errno 2] El fitxer o directori no existeix: '/etc/fwupd/msr.conf' /etc/fwupd/redfish.conf [Errno 2] El fitxer o directori no existeix: '/etc/fwupd/redfish.conf' /etc/fwupd/thunderbolt.conf [Errno 2] El fitxer o directori no existeix: '/etc/fwupd/thunderbolt.conf' /etc/fwupd/uefi_capsule.conf [Errno 2] El fitxer o directori no existeix: '/etc/fwupd/uefi_capsule.conf' -- no debconf information
Bug#1043096: xserver-xorg-input-libinput: After upgrading from Bullseye to Bookworm, mouse scrollwheel behaves odd with Logitech MX;Master 3 mouse
Package: xserver-xorg-input-libinput Version: 1.2.1-1+b1 Severity: important Dear Maintainer, after upgrading from Bullseye to Bookworm, mouse scrollwheel behaviour became odd with (at least) Logitech MX Master 3 mouse. The distribution upgrade also upgraded xserver-xorg-input-libinput from 0.30.0-1 to 1.2.1-1+b1. The observed issues are: 1. All applications: Each tick scrolled up or down produces a random scrolling distance. When scrolling up and down the same number of ticks, end position is different from the start position. 2. Firefox only: After stopping scrolling with the mouse wheel, first tick is ignored when starting scrolling in the opposite direction. When scrolling up and down one tick only, no scrolling happens at all. In Bullseye, scrolling is perfect. Each tick is recognised and scrolls exactly the same distance (in lines or pixels) in all applications. This affects at least the Logitech MX Master 3 mouse. This behaviour was not observed with no-name usb mouse or Microsoft Bluetooth Notebook Mouse 5000. But it may affect other mice as well, Logitech or not. Downgrading xserver-xorg-input-libinput to 0.30.0-1 resolves this issue in Bookworm. Upgrading to 1.3.0-1 from Sid does resolve the random scroll distance, but not the missing ticks when reverting scroll direction or scrolling one tick up and down. So, some change in xserver-xorg-input-libinput after 0.30.0-1 breaks mouse wheel scrolling at least with Logitech MX Master 3 mouse. This issue is very annoying and seriously affects user experience. -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 Feb 26 2012 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 274 May 3 03:41 /usr/bin/Xorg Diversions concerning libGL are in place diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx- diversions diversion of /usr/lib/powerpc64le-linux-gnu/libGLESv2.so.2 to /usr/lib/mesa-diverted/powerpc64le-linux-gnu/libGLESv2.so.2 by glx- diversions diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.0.0 by glx- diversions diversion of /usr/lib/libGLESv2.so.2 to /usr/lib/mesa- diverted/libGLESv2.so.2 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to /usr/lib/mesa- diverted/arm-linux-gnueabihf/libGL.so by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLX_indirect.so.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLX_indirect.so.0 by glx- diversions diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 by glx- diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so by glx- diversions diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2 to /usr/lib/mesa- diverted/i386-linux-gnu/libGLESv2.so.2 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.1.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.1.0 by glx- diversions diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2.1.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2.1.0 by glx- diversions diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2 to /usr/lib/mesa- diverted/x86_64-linux-gnu/libGLESv2.so.2 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGLX_indirect.so.0 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLX_indirect.so.0 by glx- diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx- diversions diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2.1.0 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2.1.0 by glx- diversions diversion of /usr/lib/powerpc64le-linux-gnu/libGLESv1_CM.so to /usr/lib/mesa-diverted/powerpc64le-linux-gnu/libGLESv1_CM.so by glx- diversions diversion of /usr/lib/aarch64-linux-gnu/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/aarch64-linux-gnu/libGLESv1_CM.so.1.1.0 by glx- diversions diversion of /usr/lib/powerpc64le-linux-gnu/libGL.so.1.2.0 to /usr/lib/mesa-diverted/powerpc64le-linux-gnu/libGL.so.1.2.0 by glx- diversions diversion of /usr/lib/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa- diverted/libGLESv1_CM.so.1.1.0 by glx-diversions diversion of /usr/lib/powerpc64le-linux-gnu/libGLESv2.so to /usr/lib/mesa-diverted/powerpc64le-linux-gnu/libGLESv2.so by glx- diversions diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1 by glx- diversions diversion of /usr/lib/aarch64-linux-gnu/libGL.so.1.2.0 to /usr/lib/mesa-diverted/aarch64-linux-gnu/libGL.so.1.2.0 by glx- diversions diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so
Bug#1042729: linux-image-6.4.0-1-amd64: kernel debian 6.4.0-1-amd64, problem with r8169 ethernet connection
Package: src:linux Version: 6.4.4-1 Severity: important Dear Maintainer, * What led up to the situation? Installing and using the new default kernel for Trixie. * What exactly did you do (or not do) that was effective (or ineffective)? Using previous kernel 6.3.0-2 solved the issue. WiFi connection is working well with both kernels. de jul. 31 09:09:31 lipl340 kernel: [ cut here ] de jul. 31 09:09:31 lipl340 kernel: NETDEV WATCHDOG: enp7s0 (r8169): transmit queue 0 timed out 7000 ms de jul. 31 09:09:31 lipl340 kernel: WARNING: CPU: 5 PID: 0 at net/sched/sch_generic.c:525 dev_watchdog+0x232/0x240 de jul. 31 09:09:31 lipl340 kernel: Modules linked in: ctr ccm rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device snd_sof_pci_intel_cnl snd_sof_intel_hda_common soundwire_intel soundwi> de jul. 31 09:09:31 lipl340 kernel: videobuf2_common iTCO_vendor_support intel_uncore snd_hwdep wmi_bmof pcspkr watchdog mc processor_thermal_device_pci_legacy cfg80211 mei_me processor_th> de jul. 31 09:09:31 lipl340 kernel: crc64_rocksoft_generic r8169 rc_core drm_ttm_helper sha512_generic crc64_rocksoft xhci_hcd scsi_mod ttm crc_t10dif realtek i2c_hid_acpi crct10dif_generi> de jul. 31 09:09:31 lipl340 kernel: CPU: 5 PID: 0 Comm: swapper/5 Not tainted 6.4.0-1-amd64 #1 Debian 6.4.4-1 de jul. 31 09:09:31 lipl340 kernel: Hardware name: LENOVO 81LK/LNVNB161216, BIOS BGCN31WW 06/23/2020 de jul. 31 09:09:31 lipl340 kernel: RIP: 0010:dev_watchdog+0x232/0x240 de jul. 31 09:09:31 lipl340 kernel: Code: ff ff ff 48 89 df c6 05 35 13 05 01 01 e8 d6 3d fa ff 45 89 f8 44 89 f1 48 89 de 48 89 c2 48 c7 c7 40 84 6f 82 e8 3e 17 70 ff <0f> 0b e9 2d ff ff f> de jul. 31 09:09:31 lipl340 kernel: RSP: 0018:a75d40254e70 EFLAGS: 00010286 de jul. 31 09:09:31 lipl340 kernel: RAX: RBX: 89ec68cb4000 RCX: de jul. 31 09:09:31 lipl340 kernel: RDX: 0104 RSI: 0027 RDI: de jul. 31 09:09:31 lipl340 kernel: RBP: 89ec68cb44c8 R08: R09: a75d40254d00 de jul. 31 09:09:31 lipl340 kernel: R10: 0003 R11: 82cd26a8 R12: 89ec43148600 de jul. 31 09:09:31 lipl340 kernel: R13: 89ec68cb441c R14: R15: 1b58 de jul. 31 09:09:31 lipl340 kernel: FS: () GS:89edaa74() knlGS: de jul. 31 09:09:31 lipl340 kernel: CS: 0010 DS: ES: CR0: 80050033 de jul. 31 09:09:31 lipl340 kernel: CR2: 559629d45a90 CR3: 0001726cc005 CR4: 003706e0 de jul. 31 09:09:31 lipl340 kernel: Call Trace: de jul. 31 09:09:31 lipl340 kernel: de jul. 31 09:09:31 lipl340 kernel: ? dev_watchdog+0x232/0x240 de jul. 31 09:09:31 lipl340 kernel: ? __warn+0x81/0x130 de jul. 31 09:09:31 lipl340 kernel: ? dev_watchdog+0x232/0x240 de jul. 31 09:09:31 lipl340 kernel: ? report_bug+0x191/0x1c0 de jul. 31 09:09:31 lipl340 kernel: ? prb_read_valid+0x1b/0x30 de jul. 31 09:09:31 lipl340 kernel: ? handle_bug+0x3c/0x80 de jul. 31 09:09:31 lipl340 kernel: ? exc_invalid_op+0x17/0x70 de jul. 31 09:09:31 lipl340 kernel: ? asm_exc_invalid_op+0x1a/0x20 de jul. 31 09:09:31 lipl340 kernel: ? dev_watchdog+0x232/0x240 de jul. 31 09:09:31 lipl340 kernel: ? __pfx_dev_watchdog+0x10/0x10 de jul. 31 09:09:31 lipl340 kernel: call_timer_fn+0x24/0x130 de jul. 31 09:09:31 lipl340 kernel: ? __pfx_dev_watchdog+0x10/0x10 de jul. 31 09:09:31 lipl340 kernel: __run_timers+0x222/0x2c0 de jul. 31 09:09:31 lipl340 kernel: run_timer_softirq+0x2f/0x50 de jul. 31 09:09:31 lipl340 kernel: __do_softirq+0xf1/0x301 de jul. 31 09:09:31 lipl340 kernel: __irq_exit_rcu+0xb5/0x130 de jul. 31 09:09:31 lipl340 kernel: sysvec_apic_timer_interrupt+0xa2/0xd0 de jul. 31 09:09:31 lipl340 kernel: de jul. 31 09:09:31 lipl340 kernel: de jul. 31 09:09:31 lipl340 kernel: asm_sysvec_apic_timer_interrupt+0x1a/0x20 de jul. 31 09:09:31 lipl340 kernel: RIP: 0010:cpuidle_enter_state+0xcc/0x440 de jul. 31 09:09:31 lipl340 kernel: Code: da fa 58 ff e8 b5 f0 ff ff 8b 53 04 49 89 c5 0f 1f 44 00 00 31 ff e8 73 06 58 ff 45 84 ff 0f 85 56 02 00 00 fb 0f 1f 44 00 00 <45> 85 f6 0f 88 85 0> de jul. 31 09:09:31 lipl340 kernel: RSP: 0018:a75d40137e90 EFLAGS: 0246 de jul. 31 09:09:31 lipl340 kernel: RAX: 89edaa74 RBX: c75d3fd68c00 RCX: de jul. 31 09:09:31 lipl340 kernel: RDX: 0005 RSI: 8263fc6a RDI: 8262c555 de jul. 31 09:09:31 lipl340 kernel: RBP: 0002 R08: 0002 R09: 36ca de jul. 31 09:09:31 lipl340 kernel: R10: 89edaa771d64 R11: 0016 R12: 82d98300 de jul. 31 09:09:31 lipl340 kernel: R13: 0007b34c6ebd R14: 0002 R15: de jul. 31 09:09:31 lipl340 kernel: cpuidle_enter+0x2d/0x40 de jul. 31 09:09:31 lipl340 kernel: do_idle+0x217/0x270 de jul. 31 09:09:31 lipl340 kernel: cpu_startup_entry+0x1d/0x20 de jul. 31 09:09:31 lipl340 kernel:
Bug#1042250: bup: FTBFS: dh_auto_test: error: make -j8 test "TESTSUITEFLAGS=-j8 --verbose" VERBOSE=1 returned exit code 2
It looks like this is a brittle unit test. Lucas Nussbaum wrote: > > Failures: > > ! /<>/test/ext/test-help:35 '1' = '0' FAILED This line is: WVPASSEQ 1 $(bup help save | head -1 | grep -cF 'bup-save(1)') The hyphen in the grep expression "bup-save(1)" in the unit test is the ordinary ASCII character 45: ASCII 2/13 is decimal 045, hex 2d, octal 055, bits 00101101: prints as `-' Official name: Hyphen Other names: Dash, Minus, Worm That matches the output of "bup help save | head -1" in the C locale: root@8f8c3e4ea090:/# LC_ALL=C LANG=C bup help save | head -1 | hd troff::5: warning: cannot select font 'CB' troff::152: warning: cannot select font 'C' vv 62 75 70 2d 73 61 76 65 28 31 29 20 20 20 20 20 |bup-save(1) | ^^ 0010 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 | | * 0070 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 62 | b| 0080 75 70 2d 73 61 76 65 28 31 29 0a |up-save(1).| 008b root@8f8c3e4ea090:/# > The full build log is available from: > http://qa-logs.debian.net/2023/07/26/bup_0.33.2-1_unstable.log User Environment […] LANG=C.UTF-8 LC_ALL=C.UTF-8 […] However, with a UTF-8 locale I see the hyphen being encoded as the byte sequence 0xE2 0x80 0x90: root@8f8c3e4ea090:/# LC_ALL=C.UTF-8 LANG=C.UTF-8 bup help save | head -1 | hd troff::5: warning: cannot select font 'CB' troff::152: warning: cannot select font 'C' 62 75 70 e2 80 90 73 61 76 65 28 31 29 20 20 20 |bup...save(1) | 0010 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 | | * 0080 20 62 75 70 e2 80 90 73 61 76 65 28 31 29 0a | bup...save(1).| 008f root@8f8c3e4ea090:/# Which is the UTF-8 encoding of the Unicode character U+2010 'HYPHEN'. So I guess the bup unit tests should probably set LANG/LC_ALL explicitly. Thanks! -- Robert Edmonds edmo...@debian.org
Bug#945203: fwupd: Cannot update firmware
Package: fwupd Version: 1.9.3-1 Followup-For: Bug #945203 Dear Maintainer, A warning displayed each time I login the system (Lenovo IdeaPad 340) says there is an update available. After ignoring it for a few weeks, I tried updating the firmware, specifically the UEFI dbx device (217 --> 371), using "fwupdmgr update". I received the same message: "failed to write data to efivars: Error writing to file descriptor: No space left on device" After looking it up (Internet search, DBTS), I found this bug stating that nothing can be done. I understand that there is nothing else to do if there is not more room. Regarding the other suggested possibility (about the BIOS locking it down), is there any option to convince the BIOS to be more "open"? Anyway, another question is about a way to remove or to avoid the warning when login (when the update is not possible as is our case). The last question is to calm down my curiosity because of my poor understanding of the life of a (software) bug. This is one of my first bug reports, and I still don't get the criteria to change the bug status. Why the bug is open yet? I mean, it has been dealt with. What else can be done? It is my understanding that the information will still be available even if the bug is closed. Thank you in advance for your time. Regards, robert -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.3.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.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 fwupd depends on: ii adduser3.137 ii libarchive13 3.6.2-1 ii libc6 2.37-6 ii libcbor0.8 0.8.0-2+b1 ii libcurl3-gnutls7.88.1-10 ii libflashrom1 1.3.0-2.1 ii libfwupd2 1.9.3-1 ii libgcab-1.0-0 1.6-1 ii libglib2.0-0 2.76.4-4 ii libgnutls303.7.9-2 ii libgudev-1.0-0 237-2 ii libgusb2 0.4.5-1.1 ii libjcat1 0.1.9-1 ii libjson-glib-1.0-0 1.6.6-1 ii liblzma5 5.4.1-0.2 ii libmbim-glib4 1.28.4-2 ii libmbim-proxy 1.28.4-2 ii libmm-glib01.20.6-2 ii libpolkit-gobject-1-0 122-4 ii libprotobuf-c1 1.4.1-1+b1 ii libqmi-glib5 1.32.4-2 ii libqmi-proxy 1.32.4-2 ii libsmbios-c2 2.4.3-1 ii libsqlite3-0 3.42.0-1 ii libsystemd0253.5-1 ii libtss2-esys-3.0.2-0 3.2.1-3 ii libxmlb2 0.3.10-2 ii shared-mime-info 2.2-1 Versions of packages fwupd recommends: ii bolt 0.9.5-1 ii dbus 1.14.8-2 ii fwupd-amd64-signed [fwupd-signed] 1:1.4+1 ii jq 1.6-2.1 ii python33.11.4-5 pn secureboot-db ii udisks22.10.0-4 Versions of packages fwupd suggests: ii gir1.2-fwupd-2.0 1.9.3-1 -- Configuration Files: /etc/fwupd/daemon.conf [Errno 2] El fitxer o directori no existeix: '/etc/fwupd/daemon.conf' /etc/fwupd/fwupd.conf [Errno 13] S’ha denegat el permís: '/etc/fwupd/fwupd.conf' /etc/fwupd/msr.conf [Errno 2] El fitxer o directori no existeix: '/etc/fwupd/msr.conf' /etc/fwupd/redfish.conf [Errno 2] El fitxer o directori no existeix: '/etc/fwupd/redfish.conf' /etc/fwupd/thunderbolt.conf [Errno 2] El fitxer o directori no existeix: '/etc/fwupd/thunderbolt.conf' /etc/fwupd/uefi_capsule.conf [Errno 2] El fitxer o directori no existeix: '/etc/fwupd/uefi_capsule.conf' -- no debconf information
Bug#1041872: command-not-found: Problem with user permission
Package: command-not-found Version: 23.04.0-1 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Installing "command-not-found" using aptitude, enabling it in /etc/bashrc, and misspelling a command. A warning was displayed: "WARNING:root:could not open file '/etc/apt/sources.list.d/DebianRepositories.sources': Unable to parse section data". Nothing else. * What exactly did you do (or not do) that was effective (or ineffective)? Searching the DBTS provided information about similar behaviors (#965020, #1021953), but specially #966307 because to be able to make it work the same non-sense steps described there must be taken. A similar solution can be found at StackExchange [1]. 1) According to the documentation of "command-not-found"[2], issuing "update- command-not-found(8)" must create a list of programs from whatever is at /var/cache/apt/apt-file/. It did nothing, not even an error, because there was nothing there. 2) Therefore, apt-file(1) must be executed manually as "root" user! Even when it is a normal user command (again, according to its documentation man page): ~$ LANG=C apt-file update Reading package lists... Done E: Could not open lock file /var/lib/apt/lists/lock - open (13: Permission denied) E: Unable to lock directory /var/lib/apt/lists/ W: Problem unlinking the file /var/cache/apt/pkgcache.bin - RemoveCaches (13: Permission denied) W: Problem unlinking the file /var/cache/apt/srcpkgcache.bin - RemoveCaches (13: Permission denied) 3) After the previous step, and issuing another "update-command-not-found" (also as root), the database of programs appears at /var/lib/command-not-found/ as described in [1] and [2]. However, the directory /var/cache/apt/apt-file still does not exist. So, what will happen the next time "update-command-not- found" is issued? 4) Currently, when misspelling a command in a CLI, the warning about not being able to open the sources.list file is still displayed. ~$ LANG=C datE WARNING:root:could not open file '/etc/apt/sources.list.d/DebianRepositories.sources': Unable to parse section data Command 'datE' not found, did you mean: command 'dat' from deb liballegro4-dev command 'date' from deb coreutils Try: apt install I do not really know whether the permission of the user play any role in the crazy behavior of the "command-not-found" tool. However, the fact of getting a warning about not being able to access a file usually available (mode 644) every time I misspelled a command was the cause of investigating it. As a user, I think this is too much trouble. Anyway, I take advantage of the message to thank you in advance for your work and help. Regards, robert [1] https://unix.stackexchange.com/questions/585107/debian-command-not-found- error-local-variable-cnf-referenced-before-assignme [2] /usr/share/doc/command-not-found/README.Debian *** End of the template - remove these template lines *** -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.3.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.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 command-not-found depends on: ii apt-file 3.3 ii lsb-release 12.0-2 ii python3 3.11.4-5 ii python3-apt 2.6.0 command-not-found recommends no packages. Versions of packages command-not-found suggests: pn snapd -- no debconf information
Bug#1041006:
This problem can be worked around (if configuration allows this) by changing: mail_attribute_dict = file:%h/dovecot-attributes to e.g. mail_attribute_dict = file:/path/to/mails/%d/%n/dovecot-attributes This avoids missing %h value. Bug can be closed. NOTE: Examples in dovecot documentation all use: mail_attribute_dict = file:%h/Maildir/dovecot-attributes This triggered the error I've observed. -- Robert Senger PGP/GPG Public Key ID: 8714E1A3
Bug#1041006: dovecot: Setting ACLs through IMAP fails with mail-crypt-plugin enabled
Source: dovecot Severity: normal This bug was observed in dovecot 2.3.4 on Debian 10 and in dovecot 2.3.20 on FreeBSD 13. The following plugins are enabled: mail-crypt, mail-crypt-acl, imap-acl and acl. We are using encrypted folder keys for mail encryption. Encryption is enabled or disabled for each user individually by storing the mail_crypt_save_version option in userdb. Sharing a user's mailbox to another user works fine if sharing is enabled on the command line using doveadm. If the sharing user's mails are encrypted, the password can be supplied on the command line. But sharing by using e.g. Roundcube as MUA throws an error in the dovecot logs, regardless if the sharing user has encryption enabled or not. This is the error message: Jul 13 18:15:34 prokyon dovecot: imap(administra...@mydomain.de)<23701><8f41pGAAkIL9EChC8NEBAQAC>: Error: mail-crypt-acl-plugin: Cannot initialize destination user some...@mydomain.de: userdb didn't return a home directory, but mail_attribute_dict used it (%h): file:%h/dovecot-attributes Jul 13 18:15:34 prokyon dovecot: imap(administra...@mydomain.de)<23701><8f41pGAAkIL9EChC8NEBAQAC>: Error: Mailbox INBOX: Failed to set ACL After that, sharing is configured only halfway. It looks like mail-crypt-acl plugin fails to determine the receiving user's home directory. I cannot see any attemps to query userdb in advance of this error. The configured userdb query definitely returns the home directory (otherwise nothing would work at all...). This is independent whether the sharing user has encryption enabled or not. I cannot run any tests with unencrypted folder keys, or global keys, or encryption disabled globally with mail-crypt plugin enabled but unused. I would expect that this error will occur in all these configurations. Expected result is that folder sharing at least can be enabled by using a capable MUA (like Roundcube), if the sharing user is using unencrypted folder keys, if global keys are used or encryption is disabled for the sharing user (this is the configuration where I see this error). I don't know what happens if the sharing user uses encrypted folder keys and the password is needed for sharing. -- Robert Senger PGP/GPG Public Key ID: 8714E1A3
Bug#1040623: bookworm-pu: package bup/0.33.2-1+deb12u1
Adam D. Barratt wrote:
> On Sat, 2023-07-08 at 02:24 -0400, Robert Edmonds wrote:
> > I'd like to update the version of bup in bookworm from 0.33-2 to
> > 0.33.2-1+deb12u1, which incorporates two upstream bugfix releases for
> > a bug deemed important enough by upstream to issue point releases.
> >
>
> The version number for p-u needs to be lower than unstable. This looks
> like a backport of 0.33.2-1 from unstable, so the convention would be
> 0.33.2-1~deb12u1.
>
> Feel free to re-upload with the corrected version number; there's no
> need to wait for the original upload to be rejected.
Uploaded with the corrected version number. Interdebdiff from the
rejected version below.
Thanks!
diff -u bup-0.33.2/debian/changelog bup-0.33.2/debian/changelog
--- bup-0.33.2/debian/changelog 2023-07-08 01:17:38.0 -0400
+++ bup-0.33.2/debian/changelog 2023-07-08 16:11:59.0 -0400
@@ -1,9 +1,9 @@
-bup (0.33.2-1+deb12u1) bookworm; urgency=medium
+bup (0.33.2-1~deb12u1) bookworm; urgency=medium
* Upstream version 0.33.2, with a fix for a problem that can cause POSIX.1e
ACLs to be restored incorrectly.
- -- Robert Edmonds Sat, 08 Jul 2023 01:17:38 -0400
+ -- Robert Edmonds Sat, 08 Jul 2023 16:11:59 -0400
bup (0.33.2-1) unstable; urgency=medium
diff -u bup-0.33.2/debian/patches/debian-changes
bup-0.33.2/debian/patches/debian-changes
--- bup-0.33.2/debian/patches/debian-changes2023-07-08 01:17:38.0
-0400
+++ bup-0.33.2/debian/patches/debian-changes2023-07-08 16:11:59.0
-0400
@@ -30,4 +30,4 @@
-date='2023-07-01 15:08:43 -0500'
-+commit='61307904e4133b55acf7c2794da47fafecedf5af'
-+date='2023-07-08 01:27:47 -0400'
++commit='db4734ba24249fee8060a186e03e6173ce2e5d55'
++date='2023-07-08 16:12:37 -0400'
modified=False
--
Robert Edmonds
edmo...@debian.org
Bug#1040623: bookworm-pu: package bup/0.33.2-1+deb12u1
3 - Changes in 0.33 as compared to 0.32 - Changes in 0.32 as compared to 0.31 - Changes in 0.31 as compared to 0.30.1 @@ -103,9 +105,9 @@ Test status === -| master | +| main | || -| [](https://cirrus-ci.com/github/bup/bup) | +| [](https://cirrus-ci.com/github/bup/bup) | Getting started === @@ -119,12 +121,12 @@ git clone https://github.com/bup/bup ``` - - This will leave you on the master branch, which is perfect if you + - This will leave you on the main branch, which is perfect if you would like to help with development, but if you'd just like to use bup, please check out the latest stable release like this: ```sh -git checkout 0.33 +git checkout 0.33.2 ``` You can see the latest stable release here: diff -Nru bup-0.33/config/configure bup-0.33.2/config/configure --- bup-0.33/config/configure 2022-10-16 17:18:38.0 -0400 +++ bup-0.33.2/config/configure 2023-07-01 16:08:43.0 -0400 @@ -86,6 +86,12 @@ bup-add-cflag-if-supported -Wno-unused-command-line-argument +# Since ./configure changes pwd, fix MAKE if it's relative +case "$MAKE" in +/*) ;; +*/*) MAKE="../../$MAKE";; +esac + for make_candidate in make gmake; do found_make="$(bup_find_prog "$make_candidate" "$MAKE")" if test "$found_make" \ @@ -119,7 +125,7 @@ "$BUP_PYTHON_CONFIG") fi else -for py_min_ver in 10 9 8 7 6; do +for py_min_ver in 11 10 9 8 7; do bup_python_config="$(bup_find_prog "python3.$py_min_ver-config" '')" test -z "$bup_python_config" || break done diff -Nru bup-0.33/debian/changelog bup-0.33.2/debian/changelog --- bup-0.33/debian/changelog 2022-12-26 22:27:53.0 -0500 +++ bup-0.33.2/debian/changelog 2023-07-08 01:17:38.0 -0400 @@ -1,3 +1,50 @@ +bup (0.33.2-1+deb12u1) bookworm; urgency=medium + + * Upstream version 0.33.2, with a fix for a problem that can cause POSIX.1e +ACLs to be restored incorrectly. + + -- Robert Edmonds Sat, 08 Jul 2023 01:17:38 -0400 + +bup (0.33.2-1) unstable; urgency=medium + + [ Rob Browning ] + * 0.33.2 +- Update base_version for 0.33.2 development +- correct_posix1e_v1_delimiters: provide path for error messages + (Closes: #1039089) +- Update docs for 0.33.2 release +- Update base_version for 0.33.2 release + + [ Robert Edmonds ] + * New upstream version 0.33.2 + * debian/docs: Include upstream release note '0.33.2-from-0.33.1.md' + + -- Robert Edmonds Sat, 01 Jul 2023 18:51:02 -0400 + +bup (0.33.1-1) unstable; urgency=medium + + [ Rob Browning ] + * 0.33.1 +- conftest.py: switch to Path to support pytest 7+ +- conftest.py: restore support for pytest < 7 +- configure: handle relative MAKE paths +- test_get: remove vestigial debug messages +- configure: allow and prefer python3.11-config; ignore 3.6 +- buptest init: get quote from shlex not pipes +- test-comparative-split-join: accommodate varying HEAD names +- cirrus: move to freebsd 12.4 to fix rsync-related test failures +- compare-trees: add --features and disallow args with it and -h +- Restore posix1e default acls as default, not access; improve tests +- Fix ACL metadata format; delimit short form entries with commas +- Update docs for 0.33.1 release +- Update base_version for 0.33.1 release + + [ Robert Edmonds ] + * New upstream version 0.33.1 (Closes: #1038609) + * debian/docs: Include upstream release note '0.33.1-from-0.33.md' + + -- Robert Edmonds Sun, 18 Jun 2023 19:57:44 -0400 + bup (0.33-2) unstable; urgency=medium * Upload to unstable. diff -Nru bup-0.33/debian/docs bup-0.33.2/debian/docs --- bup-0.33/debian/docs2022-12-26 22:27:53.0 -0500 +++ bup-0.33.2/debian/docs 2023-07-08 01:17:38.0 -0400 @@ -1,2 +1,4 @@ README README.md +note/0.33.1-from-0.33.md +note/0.33.2-from-0.33.1.md diff -Nru bup-0.33/debian/patches/debian-changes bup-0.33.2/debian/patches/debian-changes --- bup-0.33/debian/patches/debian-changes 2022-12-26 22:27:53.0 -0500 +++ bup-0.33.2/debian/patches/debian-changes2023-07-08 01:17:38.0 -0400 @@ -3,8 +3,8 @@ in some VCS, and exported as a single patch instead of more manageable atomic patches. bup-0.33.orig/GNUmakefile -+++ bup-0.33/GNUmakefile +--- bup-0.33.2.orig/GNUmakefile bup-0.33.2/GNUmakefile @@ -61,7 +61,7 @@ else test_tmp := $(CURDIR)/test/tmp endif @@ -23,11 +23,11 @@ $(current_sampledata) $(current_sampledata): bup-0.33.orig/lib/bup/source_info.py -+++ bup-0.33/lib/bup/source_info.py +--- bup-0.33.2.orig/lib/bup/source_inf
Bug#1039556: ITP: volare -- tiling, tabbed Wayland compositor based on Sway
Package: wnpp Severity: wishlist Owner: Robert Edmonds * Package name: volare Version : No releases yet Upstream Author : Arnout Engelen * URL : https://codeberg.org/raboof/volare * License : MIT Programming Lang: C Description : tiling, tabbed Wayland compositor based on Sway Volare is a tabbed, tiling Wayland compositor based on Sway, with modifications to make its window management behavior similar to that of the Notion window manager. Many tiling window managers are "dynamic", meaning they automatically change the tiling layout as windows appear and disappear. Volare's behavior is more static, keeping the user's existing tiling layout in place without automatically rearranging the tiling layout as application windows are created, moved, or destroyed. -- Robert Edmonds edmo...@debian.org
Bug#1039485: astcenc links against libastcenc-veneer.so, which is not available
Package: astcenc Version: 4.5.0+ds-1 Severity: grave Justification: renders package unusable X-Debbugs-Cc: rob...@griebl.org Dear Maintainer, The new 4.5.0 upload in sid is not usable on amd64, as it links against an unobtainable lib. I tried to install the libastcenc-dev package and the libastcenc4d, but that did not help. ldd /usr/bin/astcenc linux-vdso.so.1 (0x7ffd26528000) libtinyexr.so.1d => /lib/x86_64-linux-gnu/libtinyexr.so.1d (0x7fa6faa4a000) libstb.so.0 => /lib/x86_64-linux-gnu/libstb.so.0 (0x7fa6fa9c9000) libastcenc-veneer.so => not found libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x7fa6fa60) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fa6fa8ea000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7fa6fa8c4000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fa6fa41f000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fa6fa8a5000) /lib64/ld-linux-x86-64.so.2 (0x7fa6fab0a000) -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.3.0-1-amd64 (SMP w/32 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages astcenc depends on: ii libc6 2.36-9 ii libgcc-s1 13.1.0-5 ii libstb0 0.0~git20220908.8b5f1f3+ds-1 ii libstdc++613.1.0-5 ii libtinyexr1d 1.0.5+dfsg-1 astcenc recommends no packages. astcenc suggests no packages. -- no debconf information
Bug#1037287: AttributeError: 'NoneType' object has no attribute 'hardlink_target'
Nicholas Guriev wrote: > Since some time bup is unable to backup my data. This is apparently related to > hard links somehow. > bup "-d" > "/media/mymedia/a3907ce1-af8b-40b1-b26b-f37322e39382/barberry-kde-backups" > "save" "-n" "kup" "-vv" "/home/mymedia" "/home/mymedia/.steam/steam/config" > "/home/mymedia/.steam/steam/userdata" > Traceback (most recent call last): > File "/usr/lib/bup/cmd/bup-save", line 413, in > meta.hardlink_target = find_hardlink_target(hlink_db, ent) > AttributeError: 'NoneType' object has no attribute 'hardlink_target' > Exception ignored in: > Traceback (most recent call last): > File "/usr/lib/bup/cmd/../bup/git.py", line 722, in __del__ > File "/usr/lib/bup/cmd/../bup/git.py", line 919, in close > File "/usr/lib/bup/cmd/../bup/git.py", line 897, in _end > File "/usr/lib/bup/cmd/../bup/git.py", line 942, in write > NameError: name 'open' is not defined Hi, I'd suggest normal bug debugging steps like "bup fsck" or "bup index --clear" and if that doesn't fix the problem, try posting on the upstream bup mailing list (https://groups.google.com/g/bup-list). -- Robert Edmonds edmo...@debian.org
Bug#1038609: POSIX1e ACL correctness fixes (0.32.1, 0.33.1)
Package: bup Version: 0.32-3 Severity: important Tags: upstream X-Debbugs-Cc: r...@defaultvalue.org bup upstream has released two related point releases of bup (0.32.1, 0.33.1) which more correctly save and restore POSIX1e ACLs. bup 0.32 (oldstable) and bup 0.33 (stable, unstable) are currently affected and should be updated to the point releases. The upstream notes for 0.32.1 [0] and 0.33.1 [1] are reproduced below. [0]: https://github.com/bup/bup/blob/main/note/0.32.1-from-0.32.md [1]: https://github.com/bup/bup/blob/main/note/0.33.1-from-0.33.md Notable changes in 0.32.1 since 0.32 Bugs * POSIX1e ACLs should be restored more correctly now. Previously bup incorrectly restored default (`ACL_TYPE_DEFAULT`) ACLs as access acls (`ACL_TYPE_ACCESS`). When both existed, it restored the access ACL first and then the default ACL as an access ACL. Now, bup should restore each with the proper type. This issue only affects saves created on platforms where bup currently supports ACLs, so presumably mostly just saves created on Linux since the current ACL support depends on non-standard functions like `acl_extended(3)`. There is one remaining issue, which isn't fixed in this release, but is fixed in 0.33.1 (because fixing it here could create saves that are backward incompatible with 0.33). The problem is that in this version and older versions, bup stores ACLs in the `acl_to_any_text(3)` format with a newline delimiter, when the standard (and `acl_from_text(3)` which restore depends on) requires commas. This may cause restores that include ACLs (likely only those from Linux right now) to fail on some platforms (e.g. Cygwin). Notable changes in 0.33.1 since 0.33 Bugs * POSIX1e ACLs should be restored correctly now. Previously there were two problems. First, bup incorrectly restored default (`ACL_TYPE_DEFAULT`) ACLs as access acls (`ACL_TYPE_ACCESS`). When both existed, it restored the access ACL first and then the default ACL as an access ACL. Now, bup should restore each with the proper type. This issue only affects saves created on platforms where bup currently supports ACLs, so presumably mostly just saves created on Linux since the current ACL support depends on non-standard functions like `acl_extended(3)`. Second, bup stored ACLs in the `acl_to_any_text(3)` format with a newlne delimiter, when the standard (and `acl_from_text(3)` which restore depends on) requires commas. Now bup uses commas, and translates previously created saves during restore when possible. If a previously created ACL entry contains a comma, then bup will give up, report an error, and skip it. If nothing else, this could cause restores of relevant saves to fail on some platforms.
Bug#1036998:
Note that this patch fixes a Debian policy violation ( https://www.debian.org/doc/debian-policy/ch-source.html) which should qualify this as a "serious" severity bug where: "For packages in the main archive, required targets must not attempt network access, except, via the loopback interface, to services on the build host that have been started by the build."
Bug#1036998: emacs contains tests that will fail on builders with restricted networks
Package: emacs Version: 28.2+1 Tags: patch Hi, we've noticed that some of the emacs tests currently open remote sockets during a Debian build. Builders and build servers don't always provide full network access and this can cause false failures during build. I've attached a patch to disable these tests. From: Robert Qian
Bug#1036538: ITP: emptty -- Dead simple CLI Display Manager on TTY
Package: wnpp Severity: wishlist Owner: Robert Edmonds * Package name: emptty Version : 0.10.0-1 Upstream Author : Michal Tvrznik * URL : https://github.com/tvrzna/emptty * License : Expat Programming Lang: Go Description : text-based display manager for starting graphical sessions emptty is a simple, text-based display manager for starting Wayland or Xorg sessions from a virtual console. It allows the user to interactively select a specific desktop environment or window manager to start and remembers the user's selection. The types of sessions that can be started can be configured system-wide or by the user. -- Robert Edmonds edmo...@debian.org
Bug#1036525: network-manager-applet: Add support for WPA3 Enterprise networks
Source: network-manager-applet Version: 1.30.0-2 Severity: wishlist Tags: patch upstream Dear Maintainer, please add support for WPA3 Enterprise networks. NetworkManager does support these networks, only network-manager-applet and libnma packages do not. I've patched both packages and successfully added full support for WPA3 Enterprise. I am not a professional developer, and I do not have a build environment, so I had to patch the deb-src packages. Because of that, I have not included these patches as they may be of doubtfull quality, but if anyone is interested in those patches, just contact me. Robert -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.27-sandybridge (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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
Bug#1035967: ypserv: yphelper, yppush fail to run with segmentation fault
On 12/05/2023 13:32, Francesco P. Lovergine wrote: On Fri, May 12, 2023 at 01:01:24PM +0100, Robert Pumphrey wrote: Thank you for the fast response. On the NIS master, I have moved the domain directory /var/yp/domain to a backup. I then ran /usr/lib/yp/ypinit -m and added the IP addresses of the NIS slaves. This ran successfully. /usr/lib/yp/yphelper --hostname runs successfully on the master. /usr/lib/yp/yphelper --maps nameofnismaster runs successfully on the master and gives a list of maps. This is quite strange, because in moving from bullseye to bookworm no chages in the binary gdbm files have been required in my test. Test done after generating maps in bullseye. Are your current maps older than that? Even, I'm assuming you are on a amd64 arch. I am on amd64. I have ensured that the slaves have the hostname of the NIS master in /etc/hosts and it now works. On buster, this must not have been an issue, but obviously is a hard requirement for bullseye. I guess the only remaining problem really is that yphelper seg faults if the names are not in /etc/hosts, which is not ideal, but also now not a show stopper for me. Thank you for helping me. I have noticed that if the /etc/hosts file does not have an entry for local machine, then /usr/lib/yp/yphelper --hostname seg faults. This is expressly mandatory in NIS configuration, as by documentation. Every hostname used must be resolved at /etc/hosts level. Anyway that should not cause a segfault but an error, indeed. That seems an upstream issue (or several for each tool). All the other trials could be a direct consequence of that. The NIS master now looks to be operating correctly. On one of the NIS slaves, I moved the domain directory /var/yp/domain to a backup. I then ran /usr/lib/yp/ypinit -s nameofnismaster and I get a segmentation fault, followed by Can't enumerate maps from name>. Please check that it is running. /usr/lib/yp/yphelVper --hostname runs successfully on the slave /usr/lib/yp/yphelper --maps nameofnismaster seg faults So I have made some progress. Please let me know if there is anything else I can tell you. Regards Rob On 12/05/2023 10:09, Francesco P. Lovergine wrote: tags 1035967 + moreinfo unreproducible thanks Hi Rob, I just verified with a fresh installation of bookworm and it perfectly works. My first hypothesis could be about a gdbm-related breakage. It is somethig already seen in the past and even annotatedi at sect.9 of the Debian HOWTO. NEVER CROSS THE STREAMS (cit.). GDBM is quite weak in managing changes in file formats due to external conditions (e.g. changes in compiler/optimizations/ecc.) Could you plese run yptest on your serveri and send anomalies in result? Is this a single NIS master or do you have slaves ? Could you please regenerate gdbm stuff by ypinit -m after cleaning up maps? Anywyay, my next step will be preparing an upgrading box to test bullseye->bookworm, stay tuned. On Thu, May 11, 2023 at 07:55:26PM +, Rob Pumphrey wrote: Package: ypserv Version: 4.1-2 Severity: important Dear Maintainer, Recently upgraded our NIS master from buster to bullseye. when I run cd /var/yp; make several apps fail to run and seg fault, for example /usr/lib/yp/yphelper --hostname Segmentation fault yppush -d example.com ypservers Segmentation fault makedbm does appear to make valid files when run from the cmd line -- System Information: Debian Release: 11.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-22-amd64 (SMP w/4 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 ypserv depends on: ii hostname 3.23 ii libc6 2.31-13+deb11u6 ii libcrypt1 1:4.4.18-4 ii libgdbm6 1.19-2 ii libnsl2 1.3.0-2 ii libsystemd0 247.3-7+deb11u2 ii libtirpc3 1.3.1-1+deb11u1 ii lsb-base 11.1.0 ii make 4.3-4.1 ii rpcbind [portmap] 1.2.5-9 ii ucf 3.0043 Versions of packages ypserv recommends: ii yp-tools 4.2.3-3 Versions of packages ypserv suggests: pn krb5-kdc ii ypbind-mt 2.7.2-2 -- no debconf information -- Certus Technology Associates Limited. http://www.certus-tech.com Tel: +44 (0)114 272 5081 -- Certus Technology Associates Limited. http://www.certus-tech.com Tel: +44 (0)114 272 5081
Bug#1035967: ypserv: yphelper, yppush fail to run with segmentation fault
Thank you for the fast response. On the NIS master, I have moved the domain directory /var/yp/domain to a backup. I then ran /usr/lib/yp/ypinit -m and added the IP addresses of the NIS slaves. This ran successfully. /usr/lib/yp/yphelper --hostname runs successfully on the master. /usr/lib/yp/yphelper --maps nameofnismaster runs successfully on the master and gives a list of maps. I have noticed that if the /etc/hosts file does not have an entry for local machine, then /usr/lib/yp/yphelper --hostname seg faults. The NIS master now looks to be operating correctly. On one of the NIS slaves, I moved the domain directory /var/yp/domain to a backup. I then ran /usr/lib/yp/ypinit -s nameofnismaster and I get a segmentation fault, followed by Can't enumerate maps from name>. Please check that it is running. /usr/lib/yp/yphelper --hostname runs successfully on the slave /usr/lib/yp/yphelper --maps nameofnismaster seg faults So I have made some progress. Please let me know if there is anything else I can tell you. Regards Rob On 12/05/2023 10:09, Francesco P. Lovergine wrote: tags 1035967 + moreinfo unreproducible thanks Hi Rob, I just verified with a fresh installation of bookworm and it perfectly works. My first hypothesis could be about a gdbm-related breakage. It is somethig already seen in the past and even annotatedi at sect.9 of the Debian HOWTO. NEVER CROSS THE STREAMS (cit.). GDBM is quite weak in managing changes in file formats due to external conditions (e.g. changes in compiler/optimizations/ecc.) Could you plese run yptest on your serveri and send anomalies in result? Is this a single NIS master or do you have slaves ? Could you please regenerate gdbm stuff by ypinit -m after cleaning up maps? Anywyay, my next step will be preparing an upgrading box to test bullseye->bookworm, stay tuned. On Thu, May 11, 2023 at 07:55:26PM +, Rob Pumphrey wrote: Package: ypserv Version: 4.1-2 Severity: important Dear Maintainer, Recently upgraded our NIS master from buster to bullseye. when I run cd /var/yp; make several apps fail to run and seg fault, for example /usr/lib/yp/yphelper --hostname Segmentation fault yppush -d example.com ypservers Segmentation fault makedbm does appear to make valid files when run from the cmd line -- System Information: Debian Release: 11.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-22-amd64 (SMP w/4 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 ypserv depends on: ii hostname 3.23 ii libc6 2.31-13+deb11u6 ii libcrypt1 1:4.4.18-4 ii libgdbm6 1.19-2 ii libnsl2 1.3.0-2 ii libsystemd0 247.3-7+deb11u2 ii libtirpc3 1.3.1-1+deb11u1 ii lsb-base 11.1.0 ii make 4.3-4.1 ii rpcbind [portmap] 1.2.5-9 ii ucf 3.0043 Versions of packages ypserv recommends: ii yp-tools 4.2.3-3 Versions of packages ypserv suggests: pn krb5-kdc ii ypbind-mt 2.7.2-2 -- no debconf information -- Certus Technology Associates Limited. http://www.certus-tech.com Tel: +44 (0)114 272 5081
Bug#1035577: New upstream Dovecot stable version 2.3.20
Package: dovecot-core Version: 1:2.3.19.1+dfsg1-2.1 Severity: wishlist The current upstream version of dovecot is 2.3.20, which fixes several problems in 2.3.19 while adding almost no features. It's been remarkably problem-free on the Dovecot mailing list, compared to 2.3.19 that had numerous problem reports. If possible, it would be great to see 2.3.20 in Debian rather than 2.3.19. -- Robert L Mathews
Bug#1035528: ssh-audit: Please update the debian package
Hello Martin, thank you for creating Bug report #1035528 The missing update might be due to a broken watchfile. I already sent a MR a week ago. But the maintainer ChangZhuo Chen (陳昌倬) replied with cryptic messages via E-Mail, never accepted the Merge Request and then stopped replying to mails. I also would be interested to have progress here. My merge request: https://salsa.debian.org/debian/ssh-audit/-/merge_requests/4 Greets Ernst OpenPGP_0x2868F0A15BA19C08.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#1034440: RFP: freac -- fre:ac is a free audio converter and CD ripper with support for various popular formats and encoders.
Package: wnpp Followup-For: Bug #1034440 X-Debbugs-Cc: roberternst+deb...@posteo.de -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello, I would be willing to package it. I used freac by myself already and it would be worth having it in Debian. As I already saw here https://github.com/enzo1982/freac/issues/8 that there is already something to work with. I'm rather new to all of this, so please bear with me :) Greets Ernst -BEGIN PGP SIGNATURE- iQHRBAEBCgA7FiEE8NuD/nPdSgd1x8SzITV2f1s6CnEFAmRGYJ4dHHJvYmVydGVy bnN0K2RlYmlhbkBwb3N0ZW8uZGUACgkQITV2f1s6CnETVwv/Vj7y8btC4JQZHLKR a136RAG446vB5LaiJOan07H8ihUK9EoTcZJxf9GcWGVe3SZhsuLNOBVGJXWvEjeb AWxzEXNVosYWhRWw6nFoTCSUtdMT+glVjpL11H0xVb7gDeLOshwfZUcf4e8xbzLR KdgOVw7Xx21KzzAPu9x4qOmDJ32Yx+KDbvUUxdWN3z6y/JPCP941rZr6n+jRtD1E 7yNsb6yt1VSnvmhwwK84YpTH+g788eiUzlqM9Rn26RKmgjqDff22IWw1ZqdKkPJ5 /ZY1JMTfJhT6IONB6mctI8FdlViBefyP7giNYYmHWBYUavgb1zkeIAiJ6mVdiwO7 +oFlKWxyZgnCSpp1aD+aHCaF+RLZ+yEdaX2STxnjk/EzdW8uZZIpWyYnjji80DPw /tdjH1MIF0GZr8CKlvdwAspONYllW+nqW8EYUgcTfO0aF7Ou2U+DiGJImmedGwaq PAwa8V3UzqkW6QVYFi+zq7c+KOEMv61ei8lWUHYoRE4BS76y =f2lZ -END PGP SIGNATURE-
Bug#1034629: pdf-presenter-console: pdfpc terminates with symbol lookup error
Dear Jochen, Am 22.04.23 um 14:12 schrieb Jochen Sprickerhof: I don't have this in my ldd output and I don't find the file in Debian. Can you try moving it away and see if it helps? Thank you, that helped! Some packages from deb-multimedia.org were lurking around and they caused the trouble. After removing them I can use pdfpc again. Best regards, Robert OpenPGP_signature Description: OpenPGP digital signature
Bug#1034629: pdf-presenter-console: pdfpc terminates with symbol lookup error
de195000) libdav1d.so.6 => /lib/x86_64-linux-gnu/libdav1d.so.6 (0x7fa6ddfce000) libgav1.so.1 => /lib/x86_64-linux-gnu/libgav1.so.1 (0x7fa6ddee5000) librav1e.so.0 => /lib/x86_64-linux-gnu/librav1e.so.0 (0x7fa6ddc0) libSvtAv1Enc.so.1 => /lib/x86_64-linux-gnu/libSvtAv1Enc.so.1 (0x7fa6dd20) libaom.so.3 => /lib/x86_64-linux-gnu/libaom.so.3 (0x7fa6dca0) libyuv.so.0 => /lib/x86_64-linux-gnu/libyuv.so.0 (0x7fa6dd15b000) libpsl.so.5 => /lib/x86_64-linux-gnu/libpsl.so.5 (0x7fa6ddecf000) libgssapi_krb5.so.2 => /lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x7fa6dc9ae000) libmount.so.1 => /lib/x86_64-linux-gnu/libmount.so.1 (0x7fa6dc94b000) libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x7fa6dde9f000) libffi.so.8 => /lib/x86_64-linux-gnu/libffi.so.8 (0x7fa6ddbf4000) libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x7fa6dc8b1000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fa6dde9a000) libevdev.so.2 => /lib/x86_64-linux-gnu/libevdev.so.2 (0x7fa6ddbd6000) libatspi.so.0 => /lib/x86_64-linux-gnu/libatspi.so.0 (0x7fa6dc876000) libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x7fa6dc82) libdatrie.so.1 => /lib/x86_64-linux-gnu/libdatrie.so.1 (0x7fa6ddbcc000) libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x7fa6ddbc7000) libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x7fa6dc60) libbrotlicommon.so.1 => /lib/x86_64-linux-gnu/libbrotlicommon.so.1 (0x7fa6dc5dd000) libelf.so.1 => /lib/x86_64-linux-gnu/libelf.so.1 (0x7fa6dc5c2000) libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x7fa6dc80d000) libGLdispatch.so.0 => /lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x7fa6dc509000) libGLX.so.0 => /lib/x86_64-linux-gnu/libGLX.so.0 (0x7fa6dc4d5000) libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7fa6dc4a8000) libabsl_synchronization.so.20220623 => /lib/x86_64-linux-gnu/libabsl_synchronization.so.20220623 (0x7fa6dc496000) libvmaf.so.1 => /lib/x86_64-linux-gnu/libvmaf.so.1 (0x7fa6dc39a000) libunistring.so.2 => /lib/x86_64-linux-gnu/libunistring.so.2 (0x7fa6dc1e4000) libidn2.so.0 => /lib/x86_64-linux-gnu/libidn2.so.0 (0x7fa6dc1b3000) libkrb5.so.3 => /lib/x86_64-linux-gnu/libkrb5.so.3 (0x7fa6dc0d9000) libk5crypto.so.3 => /lib/x86_64-linux-gnu/libk5crypto.so.3 (0x7fa6dc0ac000) libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x7fa6dc807000) libkrb5support.so.0 => /lib/x86_64-linux-gnu/libkrb5support.so.0 (0x7fa6dc09e000) libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x7fa6dc047000) libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x7fa6dc02f000) libabsl_graphcycles_internal.so.20220623 => /lib/x86_64-linux-gnu/libabsl_graphcycles_internal.so.20220623 (0x7fa6dc027000) libabsl_stacktrace.so.20220623 => /lib/x86_64-linux-gnu/libabsl_stacktrace.so.20220623 (0x7fa6dc022000) libabsl_symbolize.so.20220623 => /lib/x86_64-linux-gnu/libabsl_symbolize.so.20220623 (0x7fa6dc01a000) libabsl_time.so.20220623 => /lib/x86_64-linux-gnu/libabsl_time.so.20220623 (0x7fa6dc008000) libabsl_malloc_internal.so.20220623 => /lib/x86_64-linux-gnu/libabsl_malloc_internal.so.20220623 (0x7fa6dc00) libabsl_base.so.20220623 => /lib/x86_64-linux-gnu/libabsl_base.so.20220623 (0x7fa6dbffa000) libabsl_spinlock_wait.so.20220623 => /lib/x86_64-linux-gnu/libabsl_spinlock_wait.so.20220623 (0x7fa6dbff5000) libabsl_raw_logging_internal.so.20220623 => /lib/x86_64-linux-gnu/libabsl_raw_logging_internal.so.20220623 (0x7fa6dbff) libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x7fa6dbfe9000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x7fa6dbfd6000) libmd.so.0 => /lib/x86_64-linux-gnu/libmd.so.0 (0x7fa6dbfc9000) libabsl_debugging_internal.so.20220623 => /lib/x86_64-linux-gnu/libabsl_debugging_internal.so.20220623 (0x7fa6dbfc2000) libabsl_demangle_internal.so.20220623 => /lib/x86_64-linux-gnu/libabsl_demangle_internal.so.20220623 (0x7fa6dbfb8000) libabsl_strings.so.20220623 => /lib/x86_64-linux-gnu/libabsl_strings.so.20220623 (0x7fa6dbf9a000) libabsl_time_zone.so.20220623 => /lib/x86_64-linux-gnu/libabsl_time_zone.so.20220623 (0x7fa6dbf7e000) libabsl_int128.so.20220623 => /lib/x86_64-linux-gnu/libabsl_int128.so.20220623 (0x7fa6dbf77000) libabsl_strings_internal.so.20220623 => /lib/x86_64-linux-gnu/libabsl_strings_internal.so.20220623 (0x7fa6dbf71000) libabsl_throw_delegate.so.20220623 => /lib/x86_64-linux-gnu/libabsl_throw_delegate.so.20220623 (0x7fa6dbf6a000) Please let me know if I can try anything else to trace this bug. I'd be glad to help. (Could an output of strace help?) Best regards, Robert OpenPGP_signature Description: OpenPGP digital signature
Bug#1034669: libsafe-dev: Update the package to 1.1.0
Package: libsafe-dev Version: 1.0.1-2 Followup-For: Bug #1034669 X-Debbugs-Cc: roberternst+deb...@posteo.de -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 GPG test via reporttool -BEGIN PGP SIGNATURE- iQHRBAEBCgA7FiEE8NuD/nPdSgd1x8SzITV2f1s6CnEFAmRCWgkdHHJvYmVydGVy bnN0K2RlYmlhbkBwb3N0ZW8uZGUACgkQITV2f1s6CnG0Awv/U69w4BYGFlVuZZd2 Dhi8mfZuvi/EovyRkLguR6xtg3ZAL6ShXQ7llWtLGtVtq7bBBLIZYVUe+KqFXOjw CvGbIaQHeCYvpW9SFLTKs+UkQALH90og8PKP9Ygk+CsYFdRoEEvVj3knt3fF0Jy8 aPnytj9zV4J3Fc1MT/negxTEOW0+VA/jMwRAiC+E68pMZChjSBLzIE2ku9Y7bt0I 2zsC4r2H9r+svii/ZhHMOoUUzyX4Qs8vmL6qiN82ZfuKmTa+5j0bavP/eXsfPqKZ ngCMU3QlZw+t54BCd9WPUvrvA/INmj1J4/kY4g39wvyXE77XsjD17ASf9PocxORq Fd6zGQuvfrHB8m7vls/1m7KbdWFxzbKW+8roizJ6WAnIA9yGWaRKjJZHwQV3ga+8 q1j9TzxYurXqQPYX7adJLZtmWQ5SqhvPeXoIrxynqd5YOr1FiOphrivoLsFGGD2V l95W+moty01WD5/ztbm0kB29ygh0nGPpb3bVVl2aaFLsVNN3 =SLg/ -END PGP SIGNATURE-
Bug#1034669: libsafe-dev: Update the package to 1.1.0
Package: libsafe-dev Severity: wishlist X-Debbugs-Cc: roberternst+deb...@posteo.de Dear Maintainer, * What led up to the situation? I'm working on libsafe-dev due to suggestion of the dear Maintainer, irc user jello said I should create a wishlist bug for the process * What exactly did you do (or not do) that was effective (or ineffective)? I already built the package locally and want to use this bug to track my endeavor * What was the outcome of this action? A lot of confusion and learnings. But also some files generated * What outcome did you expect instead? I think this question relates to bugs rather than package updates -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.15.90.1-microsoft-standard-WSL2 (SMP w/8 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect
Bug#1034629: pdf-presenter-console: pdfpc terminates with symbol lookup error
Package: pdf-presenter-console Version: 4.6.0-1 Severity: grave Justification: renders package unusable X-Debbugs-Cc: jaesc...@l3s.de Dear Maintainer, When starting pdfpc it immediately dies with the following error message: > pdfpc slides.pdf pdfpc: symbol lookup error: /lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37: undefined symbol: gst_transcoder_get_sync_signal_adapter -- System Information: Debian Release: 12.0 APT prefers testing APT policy: (500, 'testing'), (50, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-7-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 pdf-presenter-console depends on: ii libc6 2.36-9 ii libcairo2 1.16.0-7 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libgee-0.8-20.20.6-1 ii libglib2.0-02.74.6-2 ii libgstreamer-plugins-base1.0-0 1.22.0-3 ii libgstreamer1.0-0 1.22.0-2 ii libgtk-3-0 3.24.37-2 ii libjson-glib-1.0-0 1.6.6-1 ii libmarkdown22.2.7-2 ii libpango-1.0-0 1.50.12+ds-1 ii libpangocairo-1.0-0 1.50.12+ds-1 ii libpoppler-glib822.12.0-2+b1 ii libqrencode44.1.1-1 ii libsoup2.4-12.74.3-1 ii libwebkit2gtk-4.0-372.40.0-3 ii libx11-62:1.8.4-2 Versions of packages pdf-presenter-console recommends: ii gstreamer1.0-gtk3 1.22.0-5 pdf-presenter-console suggests no packages. -- no debconf information
Bug#1033284: apache2 2.4.56-1 redirects not normal working appeared %3f
This Bug with $3f added is fixed in apache trunk r1908813. https://bz.apache.org/bugzilla/show_bug.cgi?id=66547
Bug#1033585: "smbios-token-ctl -d" yields "RuntimeError: generator raised StopIteration"
Package: smbios-utils Any dependency in the smbios-tools python scripts on /usr/lib/python3/dist-packages/libsmbios_c/smbios_token.py imporperly raises a StopIteration exception with newer versions of Python 3 and terminates. # smbios-token-ctl -d Token: 0x0005 - Serial Port 1 (COM2) value: bool = false Desc: Configure the system's first/only built-in serial port to respond as CO M2. ... ... ... Token: 0xf654 - unknown (unknown) value: bool = false Desc: unknown Traceback (most recent call last): File "/usr/lib/python3/dist-packages/libsmbios_c/smbios_token.py", line 134, in __iter__ raise StopIteration StopIteration The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/usr/sbin/smbios-token-ctl", line 475, in sys.exit( main() ) ^^ File "/usr/sbin/smbios-token-ctl", line 380, in main dumpTokens(tokenTable, tokenXlator, options) File "/usr/sbin/smbios-token-ctl", line 214, in dumpTokens for token in tokenTable: RuntimeError: generator raised StopIteration This patch corrects the problem, allowing iterations to continue as expected: --- smbios_token.py 2023-03-27 13:47:02.135215225 -0400 +++ smbios_token.py.new 2023-03-27 13:47:32.275214757 -0400 @@ -129,9 +129,12 @@ while 1: cur =DLL.token_table_get_next( self._tableobj, cur ) if bool(cur): -yield cur.contents +try: +yield cur.contents +except StopIteration: +return else: -raise StopIteration +return @traceLog() def __getitem__(self, id): I am running Debian Bookworm # uname -a Linux lt3107-1 6.1.0-6-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.15-1 (2023-03-05) x86_64 GNU/Linux -- Robert Mavrinac Systems Analyst School of Computer Science Room 3103B Lambton Tower University of Windsor 401 Sunset Avenue, Windsor, ON N9B 3P4 519-253-3000 (4410) Email: mavri...@uwindsor.ca<mailto:mavri...@uwindsor.ca>
Bug#1033355: openrefine: Command line option -m is ignored
Package: openrefine Version: 3.6.2-1 Severity: normal X-Debbugs-Cc: jaesc...@l3s.de Dear Maintainer, The script to start Openrefine ignores the option -m to set the max memory heap size to use. After starting "openrefine -m 8000M" I get the following command line: /usr/bin/java -cp server/classes:server/* -Xms1400M -Xmx1400M -Drefine.memory=1400M -Drefine.max_form_content_size=1048576 -Drefine.verbosity=info -Dpython.path=main/webapp/WEB-INF/lib/jython -Dpython.cachedir=/home//.local/share/google/refine/cachedir -Drefine.webapp=main/webapp -Drefine.port= -Drefine.interface=127.0.0.1 -Drefine.host=127.0.0.1 com.google.refine.Refine Thus, the command line option is ignored and instead all three relevant options (-Xms, -Xmx, -Drefine.memory) are set to 1400M as defined in /etc/openrefine/refine.ini: # Maximum JVM heap (memory) and max form size allocations #REFINE_MAX_FORM_CONTENT_SIZE=1048576 REFINE_MEMORY=1400M # Initial (and minimum) size of Java heap REFINE_MIN_MEMORY=1400M I think the problem is that /usr/share/openrefine/refine first parses the command line args and then loads refine.ini which overwrites the just set variables. Changing the order should solve the problem. Best regards, Robert -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing'), (50, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-6-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 openrefine depends on: ii curl7.88.1-1 ii default-jre [java9-runtime] 2:1.17-74 ii jython 2.7.3+repack1-1 ii libapache-jena-java 4.5.0-2 ii libapache-poi-java 4.0.1-4 ii libclojure-java 1.11.1-2 ii libcommons-codec-java 1.15-1 ii libcommons-collections3-java3.2.2-2 ii libcommons-collections4-java4.2-1 ii libcommons-compress-java1.22-1 ii libcommons-fileupload-java 1.4-2 ii libcommons-io-java 2.11.0-2 ii libcommons-lang-java2.6-10 ii libcommons-lang3-java 3.12.0-2 ii libcommons-text-java1.10.0-1 ii libcommons-validator-java 1:1.7-1 ii libgoogle-api-services-drive-java 1.32.1-2 ii libgoogle-api-services-sheets-java 1.32.1-3 ii libgoogle-http-client-java 1.42.0-2 ii libguava-java 31.1-1 ii libhttpclient5-java 5.2.1-1 ii libhttpcore-java4.4.16-1 ii libjackson2-annotations-java2.14.0-1 ii libjackson2-core-java 2.14.1-1 ii libjackson2-databind-java 2.14.0-1 ii libjasypt-java 1.9.3-1 ii libjaxb-api-java2.3.1-1 ii libjetty9-java 9.4.50-3 ii libjsoup-java 1.15.3-1 ii libjsr305-java 0.1~+svn49-11 ii libjuniversalchardet-java 2.4.0-3 ii liblanguage-detector-java 0.6-2 ii liblog4j2-java 2.19.0-2 ii libmarc4j-java 2.9.2-1 ii libmariadb-java 2.7.6-1 ii libodfdom-java 0.9.0~RC2-2 ii libokhttp-java 3.13.1-3 ii libopenrefine-butterfly-java1.2.4-1 ii libopenrefine-opencsv-java 2.4-2 ii libopenrefine-vicino-java 1.2-3 ii libowasp-encoder-java 1.2.3-2 ii libpostgresql-jdbc-java 42.5.4-1 ii libservlet-api-java 4.0.1-2 ii libslf4j-java 1.7.32-1 ii libsweble-common-java 3.0.8-3 ii libsweble-wikitext-java 3.1.9-2 ii libwikidata-toolkit-java0.13.3-1 ii libxerial-sqlite-jdbc-java 3.40.1.0+dfsg-1 ii openjdk-11-jre [java9-runtime] 11.0.18+10-1~deb11u1 ii openjdk-17-jre [java9-runtime] 17.0.6+10-1 ii procps 2:4.0.2-3 ii velocity1.7-6 openrefine recommends no packages. openrefine suggests no packages. -- no debconf information
Bug#1022760: openrefine: localhost:3333 returns HTTP ERROR 404 Not Found
Dear Markus,
I found the problem: the package misses a dependency to libjoda-time-java.
I created a simple log4j.properties file and then run openrefine
manually with a modified classpath that included the directory that
contained the log4j.properties file (/tmp/or in my case):
java \
-cp server/classes:server/*:/tmp/or \
-Xms1400M \
-Xmx1400M \
-Drefine.memory=1400M \
-Drefine.max_form_content_size=1048576 \
-Drefine.verbosity=info \
-Dpython.path=main/webapp/WEB-INF/lib/jython \
-Dpython.cachedir=/home//.local/share/google/refine/cachedir \
-Drefine.webapp=main/webapp \
-Drefine.port= \
-Drefine.interface=127.0.0.1 \
-Drefine.host=127.0.0.1 com.google.refine.Refine
Then I got the following output:
INFO log - Logging initialized @123ms to
org.eclipse.jetty.util.log.Slf4jLog
INFO refine_server - Starting Server bound to '127.0.0.1:'
INFO refine_server - refine.memory size: 8000M JVM Max heap: 8388608000
INFO refine_server - Initializing context: '/' from
'/usr/share/openrefine/webapp'
INFO Server - jetty-9.4.50.v20221107; built: unknown; git: unknown; jvm
17.0.6+10-Debian-1
WARN WebAppContext - Failed startup of context
o.e.j.w.WebAppContext@147ed70f{/,file:///usr/share/openrefine/webapp/,STOPPED}{/usr/share/openrefine/webapp}
java.nio.file.NoSuchFileException:
/usr/share/openrefine/webapp/WEB-INF/lib/joda-time.jar
at
java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
at
java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)
at
java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
at
java.base/sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:55)
at
java.base/sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:148)
at
java.base/sun.nio.fs.LinuxFileSystemProvider.readAttributes(LinuxFileSystemProvider.java:99)
at java.base/java.nio.file.Files.readAttributes(Files.java:1851)
at java.base/java.util.zip.ZipFile$Source.get(ZipFile.java:1264)
at
java.base/java.util.zip.ZipFile$CleanableResource.(ZipFile.java:709)
at java.base/java.util.zip.ZipFile.(ZipFile.java:243)
at java.base/java.util.zip.ZipFile.(ZipFile.java:172)
at java.base/java.util.jar.JarFile.(JarFile.java:347)
at
java.base/sun.net.www.protocol.jar.URLJarFile.(URLJarFile.java:103)
at
java.base/sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:72)
at
java.base/sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:153)
at
java.base/sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:131)
at
java.base/sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:92)
at
org.eclipse.jetty.webapp.MetaInfConfiguration.getTlds(MetaInfConfiguration.java:445)
at
org.eclipse.jetty.webapp.MetaInfConfiguration.scanForTlds(MetaInfConfiguration.java:361)
at
org.eclipse.jetty.webapp.MetaInfConfiguration.scanJars(MetaInfConfiguration.java:172)
at
org.eclipse.jetty.webapp.MetaInfConfiguration.preConfigure(MetaInfConfiguration.java:106)
at
org.eclipse.jetty.webapp.WebAppContext.preConfigure(WebAppContext.java:488)
at
org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:523)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73)
at
org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
at
org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:110)
at
org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:97)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73)
at
org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
at org.eclipse.jetty.server.Server.start(Server.java:423)
at
org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:110)
at
org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:97)
at org.eclipse.jetty.server.Server.doStart(Server.java:387)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73)
at com.google.refine.RefineServer.init(Refine.java:236)
at com.google.refine.Refine.init(Refine.java:118)
at com.google.refine.Refine.main(Refine.java:112)
INFO AbstractConnector - Started ServerConnector@6b2fad11{HTTP/1.1,
(http/1.1)}{127.0.0.1:}
INFO Server - Started @361ms
Openrefine now works after I've manually installed joda-time.
Best regards,
Robert
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1022760: openrefine: localhost:3333 returns HTTP ERROR 404 Not Found
Dear Markus, Am 17.03.23 um 15:38 schrieb Markus Koschany: I presume you don't have librhino-java >= 1.7.14 installed on your system because your apt policy prefers testing over unstable. Sorry, I forgot to add this: > dpkg -l | grep rhino ii librhino-java 1.7.14-2 ii rhino 1.7.14-2 I've upgraded (lib)rhino after reading the bug report but this did not help. Is there a way to debug Openrefine? I tried both -v debug and -v trace but did not get more output (Maybe I have to configure log4j properly as the warning suggests?) Best regards, Robert
Bug#1022760: openrefine: localhost:3333 returns HTTP ERROR 404 Not Found
Package: openrefine Version: 3.6.2-1 Followup-For: Bug #1022760 X-Debbugs-Cc: jaesc...@l3s.de Dear Maintainer, I experience the exact same problem with the latest version, that is, starting openrefine and opening http://localhost: results in a 404. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing'), (50, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-5-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 openrefine depends on: ii curl7.88.1-1 ii default-jre [java9-runtime] 2:1.17-74 ii jython 2.7.3+repack1-1 ii libapache-jena-java 4.5.0-2 ii libapache-poi-java 4.0.1-4 ii libclojure-java 1.11.1-2 ii libcommons-codec-java 1.15-1 ii libcommons-collections3-java3.2.2-2 ii libcommons-collections4-java4.2-1 ii libcommons-compress-java1.22-1 ii libcommons-fileupload-java 1.4-2 ii libcommons-io-java 2.11.0-2 ii libcommons-lang-java2.6-10 ii libcommons-lang3-java 3.12.0-2 ii libcommons-text-java1.10.0-1 ii libcommons-validator-java 1:1.7-1 ii libgoogle-api-services-drive-java 1.32.1-2 ii libgoogle-api-services-sheets-java 1.32.1-3 ii libgoogle-http-client-java 1.42.0-2 ii libguava-java 31.1-1 ii libhttpclient5-java 5.2.1-1 ii libhttpcore-java4.4.16-1 ii libjackson2-annotations-java2.14.0-1 ii libjackson2-core-java 2.14.1-1 ii libjackson2-databind-java 2.14.0-1 ii libjasypt-java 1.9.3-1 ii libjaxb-api-java2.3.1-1 ii libjetty9-java 9.4.50-3 ii libjsoup-java 1.15.3-1 ii libjsr305-java 0.1~+svn49-11 ii libjuniversalchardet-java 2.4.0-3 ii liblanguage-detector-java 0.6-2 ii liblog4j2-java 2.19.0-2 ii libmarc4j-java 2.9.2-1 ii libmariadb-java 2.7.6-1 ii libodfdom-java 0.9.0~RC2-2 ii libokhttp-java 3.13.1-3 ii libopenrefine-butterfly-java1.2.4-1 ii libopenrefine-opencsv-java 2.4-2 ii libopenrefine-vicino-java 1.2-3 ii libowasp-encoder-java 1.2.3-2 ii libpostgresql-jdbc-java 42.5.4-1 ii libservlet-api-java 4.0.1-2 ii libslf4j-java 1.7.32-1 ii libsweble-common-java 3.0.8-3 ii libsweble-wikitext-java 3.1.9-2 ii libwikidata-toolkit-java0.13.3-1 ii libxerial-sqlite-jdbc-java 3.40.1.0+dfsg-1 ii openjdk-11-jre [java9-runtime] 11.0.18+10-1~deb11u1 ii openjdk-17-jre [java9-runtime] 17.0.6+10-1 ii procps 2:4.0.2-3 ii velocity1.7-6 openrefine recommends no packages. openrefine suggests no packages. -- no debconf information
Bug#1031509: clamav: 2 RCE bugs in ClamAV 0.103 (+ 1.0.0), CVE-2023-20032/CVE-2023-20052
Package: clamav Version: 0.103.7+dfsg-0+deb11u1 Severity: important Dear Maintainer, ClamAV/Cisco have released a security advisory concerning 2 potential-RCE bugs in ClamAV: https://blog.clamav.net/2023/02/clamav-01038-01052-and-101-patch.html According to the the security tracker, all versions currently in Debian are vulnerable: https://security-tracker.debian.org/tracker/CVE-2023-20032 https://security-tracker.debian.org/tracker/CVE-2023-20052 Please consider an update. Currently, ClamAV is not suitable for use in a (quite common) email-scanning setup like with Amavis, but can still be used (with appropriate care) directly. Thus I think Severity: important fits. Kind regards, Robert -- Package-specific info: --- configuration --- # Automatically created by the clamav-freshclam postinst # Comments will get lost when you reconfigure the clamav-freshclam package DatabaseOwner clamav UpdateLogFile /var/log/clamav/freshclam.log LogVerbose false LogSyslog false LogFacility LOG_LOCAL6 LogFileMaxSize 0 LogRotate true LogTime true Foreground false Debug false MaxAttempts 5 DatabaseDirectory /var/lib/clamav DNSDatabaseInfo current.cvd.clamav.net ConnectTimeout 30 ReceiveTimeout 0 TestDatabases yes ScriptedUpdates yes CompressLocalDatabase no Bytecode true NotifyClamd /etc/clamav/clamd.conf # Check for new database 24 times a day Checks 24 DatabaseMirror db.local.clamav.net DatabaseMirror database.clamav.net --- data dir --- total 226104 -rw-r--r-- 1 clamav clamav293670 Feb 17 14:46 bytecode.cvd -rw-r--r-- 1 clamav clamav 60744631 Feb 17 14:44 daily.cvd -rw-r--r-- 1 clamav clamav69 Feb 17 14:43 freshclam.dat -rw-r--r-- 1 clamav clamav 170479789 Feb 17 14:46 main.cvd -- System Information: Debian Release: 11.6 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-0.deb11.4-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages clamav depends on: ii clamav-freshclam [clamav-data] 0.103.7+dfsg-0+deb11u1 ii libc6 2.31-13+deb11u5 ii libclamav9 0.103.7+dfsg-0+deb11u1 ii libcurl47.74.0-1.3+deb11u3 ii libjson-c5 0.15-2 ii libssl1.1 1.1.1n-0+deb11u3 ii zlib1g 1:1.2.11.dfsg-2+deb11u2 Versions of packages clamav recommends: ii clamav-base 0.103.7+dfsg-0+deb11u1 Versions of packages clamav suggests: pn clamav-docs pn libclamunrar -- no debconf information
Bug#1031413: Slow backward search in long lines
Package: w3m Version: 0.5.3+git20230121-2 Severity: minor When I search backward in w3m by using the '?' command, the program freezes with high CPU usage for a bit of time if the found text is near the end of a very long line. How to reproduce the issue: printf 'first line\nsecond line is %*s a long line\nthird line\n' 1 '' > test.txt w3m test.txt Run those commands and then go to the third line and search backward for the word "line". Now the program will freeze for a second. If you increase the number 1, the freezing time will increase with the square of that number. The reason that this happens when searching backward but not forward is that in the function `backwardSearch` in search.c there is this loop: while (regexMatch(...) == 1) but in `forwardSearch` it's just an if statement: if (regexMatch(...) == 1) That means that when searching backward, we do one regexMatch for each character on the line and since the regexMatch itself already searches through the characters, that's pretty wasteful and that's what gives us the squared times. It should be possible to change this so that an if statement is used in `backwardSearch` just like in `forwardSearch`. Maybe there could be two versions of `regexMatch` where one of them searches backwards or just returns the last match instead of the first one so that we don't have to call it in a loop.
Bug#1029716: make-sqldeveloper-package fails on linking in temporary directory
./make-sqldeveloper-package: 654: [: Illegal number: libglassgtk2 ./make-sqldeveloper-package: 656: [: Illegal number: libglassgtk2 ./make-sqldeveloper-package: 654: [: Illegal number: ffmpeg-57 ./make-sqldeveloper-package: 656: [: Illegal number: ffmpeg-57 ./make-sqldeveloper-package: 654: [: Illegal number: lite ./make-sqldeveloper-package: 656: [: Illegal number: lite ./make-sqldeveloper-package: 654: [: Illegal number: libfxplugins ./make-sqldeveloper-package: 656: [: Illegal number: libfxplugins ./make-sqldeveloper-package: 654: [: Illegal number: ffmpeg-56 ./make-sqldeveloper-package: 656: [: Illegal number: ffmpeg-56 ./make-sqldeveloper-package: 654: [: Illegal number: libdecora_sse ./make-sqldeveloper-package: 656: [: Illegal number: libdecora_sse ./make-sqldeveloper-package: 654: [: Illegal number: libprism_common ./make-sqldeveloper-package: 656: [: Illegal number: libprism_common done! Cleaning up work directory "/tmp/user/0/tmp.OkM7V0yfPp/sqldeveloper-22.2.1.234.1810" for compliant package(s) generation: deleting foreign binaries, image thumbnails and caches, foreign configuration files, source code, empty directories, done! fixing shebang lines, executable bit, done! documenting demo files, theme templates, application notes, done! Populating the "/tmp/user/0/tmp.OkM7V0yfPp/sqldeveloper-22.2.1.234.1810/debian" package control directory: finding libraries to build ... done! debian/changelog ... done! debian/compat ... done! debian/control ... done! debian/rules ... done! debian/sqldeveloper-22.2.1.234.1810.copyright ... done! debian/sqldeveloper-22.2.1.234.1810.doc-base ... done! debian/libjnidispatch-22.2.1.234.1810.shlibs.amd64 ... done! debian/libjnidispatch-22.2.1.234.1810.shlibs.i386 ... done! debian/sqldeveloper-22.2.1.234.1810.changelog ... done! debian/control ... updated! debian/sqldeveloper-22.2.1.234.1810.copyright ... done! debian/sqldeveloper-22.2.1.234.1810.install.in ... done! debian/sqldeveloper-22.2.1.234.1810.lintian-overrides.amd64 ... done! debian/sqldeveloper-22.2.1.234.1810.lintian-overrides.i386 ... done! debian/libjnidispatch-22.2.1.234.1810.copyright ... updated! debian/sqldeveloper-22.2.1.234.1810.copyright ... updated! debian/sqldeveloper-22.2.1.234.1810.install ... done! debian/sqldeveloper-22.2.1.234.1810.links ... done! debian/sqldeveloper-22.2.1.234.1810.lintian-overrides ... done! debian/sqldeveloper-22.2.1.234.1810.manpages ... done! debian/sqldeveloper-22.2.1.234.1810.NEWS ... done! debian/sqldeveloper-22.2.1.234.1810.postinst ... done! debian/sqldeveloper-22.2.1.234.1810.prerm ... done! debian/sqldeveloper-22.2.1.234.1810.README.Debian ... done! debian/sqldeveloper.22.2.1.234.1810.1 ... done! debian/sdcli.22.2.1.234.1810.1 ... done! debian/sql.22.2.1.234.1810.bundled.1 ... done! debian/sqldeveloper.22.2.1.234.1810.bash ... done! debian/sqldeveloper.22.2.1.234.1810.desktop ... done! debian/sqldeveloper.22.2.1.234.1810.xpm ... done! Building debian package(s) from sqldeveloper v22.2.1.234.1810 in "/root": sqldeveloper-22.2.1.234.1810_22.2.1.234.1810+0.5.4-1_all.deb ... done! libjnidispatch-22.2.1.234.1810_4.2.2+0.5.4-1_amd64.deb ... done! I am using Linux hostname 6.1.0-1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.4-1 (2023-01-07) x86_64 GNU/Linux qnd libc 2.36-8 -- Robert Mavrinac Systems Analyst School of Computer Science Room 3103B Lambton Tower University of Windsor 401 Sunset Avenue, Windsor, ON N9B 3P4 519-253-3000 (4410) Email: mavri...@uwindsor.ca<mailto:mavri...@uwindsor.ca>
Bug#1029207: Fwd: gamin problem on debian testing
Package: courier-imap
Version: 5.0.13+1.0.16-3+b5 amd64
Hello,
I wanted to upgrade my email server, so I decided to install Bookworm
(current debian testing) on a new machine. I wish to use virtual users.
postfix, postgresql auth, virtual users, courier imapd.
ii courier-authdaemon 0.71.4-1+b1 amd64Courier
authentication daemon
ii courier-authlib0.71.4-1+b1 amd64Courier
authentication library
ii courier-authlib-postgresql 0.71.4-1+b1 amd64PostgreSQL
support for the Courier authentication library
ii courier-authlib-userdb 0.71.4-1+b1 amd64userdb
support for the Courier authentication library
ii courier-base 1.0.16-3+b5 amd64Courier mail
server - base system
ii courier-imap 5.0.13+1.0.16-3+b5 amd64
Courier mail server - IMAP server
ii libcourier-unicode4:amd64 2.1.2-2+b1 amd64Courier
Unicode library (shared runtime library)
ii gamin 0.1.10-6 amd64File and
directory monitoring system
ii libgamin0 0.1.10-6 amd64Client library
for the gamin file and directory monitoring system
It doesn't work.
I got a message from thunderbird:
(set debug, cut from imaplog.dat
WRITE: * OK [ALERT] Filesystem notification initialization error --
contact your mail administrator (check for configuration errors with the
FAM/Gamin library)
This bug has a long history in debian bugtrack, suggest to install fam,
but there is no fam in debian testing.
/var/log/mail.log:
imapd: Failed to connect to socket /tmp/fam--
I started to investigate about this socket name, mainly the two dash on
it's end.
I downloaded and extracted gamin source, and found this in
server/gam_channel.c:
#ifdef HAVE_ABSTRACT_SOCKETS
ret = g_strconcat("/tmp/fam-", user, "-", gam_client_id, NULL);
#else
So it needs the username. I've gave it a try and added a regular user
along the virtual one (same username, same uid and gid) and it staarted
to work.
Then I removed the regular user and readded with some random character
appended, same uid, same gid, and it works also. I've checked with lsof
that the gam_server libexeced process uses the username from the
/etc/passwd.
lsof:
gam_serve 10851 username8u unix 0x9286ce 0t0
90092
@/tmp/fam-username-@
type=STREAM (CONNECTED)
gam_serve 10851 username9u unix 0x7a8182 0t0
90095
@/tmp/fam-username-@
type=STREAM (CONNECTED)
If I delete the regular user again, then:
gam_serve 10966200425u unix 0x9422bc0f 0t0
95756
@/tmp/fam-somebody-@
type=STREAM (LISTEN)
the gam_serve opens the socket as somebody, the imapd checks as a null
string.
I don't know, if this is a problem, or my fault.
Thank you for any help.
Robert
Bug#1020215: w3m interprets when not in but in
After using my version of w3m every day since I posted this, the only problem I have noticed on a few pages is that it doesn't handle titles directly under html tags, so this doesn't work: Hello I don't know if we want to care about that case and I don't think it's valid HTML but I wanted to let you know.
Bug#1027867: libgl1-mesa-dri: xorg segfaults at startup on fresh debian install
Package: libgl1-mesa-dri Version: 22.3.2-1 Severity: important X-Debbugs-Cc: robert.alm.nils...@paradoxinteractive.com Dear Maintainer, I upgraded libgl1-mesa-dri to the version currently in testing (22.3.1-1 but problem exists in latest unstable version too, 22.3.2-1) and with that came a new problem, xorg didn't start anymore. The problem exists both after a bookworm upgrade (where the last upgrade before this one was two weeks ago) and in a fresh install of the debian bookworm alpha iso. This bug report is sent from the fresh install. I have tested upgrading the package to the version in unstable (22.3.2-1) and I get the same problem. I have tested downgrading to the version in stable (20.3.5-1) and that fixes the problem (starting X then works). -- Package-specific info: glxinfo: DISPLAY is not set. /etc/X11/X does not exist. /etc/X11/X is not a symlink. /etc/X11/X is not executable. VGA-compatible devices on PCI bus: -- 00:02.0 VGA compatible controller [0300]: Intel Corporation CoffeeLake-H GT2 [UHD Graphics 630] [8086:3e9b] /etc/X11/xorg.conf does not exist. Contents of /etc/X11/xorg.conf.d: - total 0 /etc/modprobe.d contains no KMS configuration files. Kernel version (/proc/version): --- Linux version 6.0.0-6-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-9.1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.39) #1 SMP PREEMPT_DYNAMIC Debian 6.0.12-1 (2022-12-09) Xorg X server log files on system: -- -rw-r--r-- 1 root root 27608 Jan 4 10:05 /var/log/Xorg.0.log -rw-r--r-- 1 aa27938 Jan 4 10:23 /home/a/.local/share/xorg/Xorg.0.log Contents of most recent Xorg X server log file (/home/a/.local/share/xorg/Xorg.0.log): -- [ 1071.460] X.Org X Server 1.21.1.5 X Protocol Version 11, Revision 0 [ 1071.460] Current Operating System: Linux x 6.0.0-6-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.0.12-1 (2022-12-09) x86_64 [ 1071.460] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-6.0.0-6-amd64 root=UUID=c6629e54-6c6d-407b-adf2-bc3b9f00a9a3 ro quiet [ 1071.460] xorg-server 2:21.1.5-1 (https://www.debian.org/support) [ 1071.460] Current version of pixman: 0.42.2 [ 1071.460]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 1071.460] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 1071.460] (==) Log file: "/home/a/.local/share/xorg/Xorg.0.log", Time: Wed Jan 4 10:23:11 2023 [ 1071.461] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 1071.461] (==) No Layout section. Using the first Screen section. [ 1071.461] (==) No screen section available. Using defaults. [ 1071.461] (**) |-->Screen "Default Screen Section" (0) [ 1071.461] (**) | |-->Monitor "" [ 1071.461] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 1071.461] (==) Automatically adding devices [ 1071.461] (==) Automatically enabling devices [ 1071.461] (==) Automatically adding GPU devices [ 1071.461] (==) Automatically binding GPU devices [ 1071.461] (==) Max clients allowed: 256, resource mask: 0x1f [ 1071.461] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [ 1071.461]Entry deleted from font path. [ 1071.461] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, built-ins [ 1071.461] (==) ModulePath set to "/usr/lib/xorg/modules" [ 1071.461] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 1071.461] (II) Loader magic: 0x55c27854cf00 [ 1071.461] (II) Module ABI versions: [ 1071.461]X.Org ANSI C Emulation: 0.4 [ 1071.461]X.Org Video Driver: 25.2 [ 1071.461]X.Org XInput driver : 24.4 [ 1071.461]X.Org Server Extension : 10.0 [ 1071.462] (++) using VT number 1 [ 1071.464] (II) systemd-logind: took control of session /org/freedesktop/login1/session/_33 [ 1071.465] (II) xfree86: Adding drm device (/dev/dri/card0) [ 1071.465] (II) Platform probe for /sys/devices/pci:00/:00:01.0/:01:00.0/drm/card0 [ 1071.466] (II) systemd-logind: got fd for /dev/dri/card0 226:0 fd 13 paused 0 [ 1071.466] (II) xfree86: Adding drm device (/dev/dri/card1) [ 1071.466] (II) Platform probe for /sys/devices/pci:00/:00:02.0/drm/card1 [ 1071.467] (II) systemd-logind: got fd for /dev/dri/card1 226:1 fd 14 paused 0 [ 1071.472]
Bug#1026991: intel-media-va-driver: the library causes application crash in mpv or any other media player
Package: intel-media-va-driver Version: 21.1.1+dfsg1-1 Severity: normal X-Debbugs-Cc: days...@gmail.com Dear Maintainer, * What led up to the situation? video playback using smplayer then mpv using vaapi use the following syntax: "mpv --vo=vaapi * What exactly did you do (or not do) that was effective (or ineffective)? switching to software renderer * What was the outcome of this action? eats up 90% CPU at all time on blu-ray-quality videos (inacceptable) * What outcome did you expect instead? vaapi not crashing the application and servicing hardware acceleration * Note Upstream fix has been already dispatched, just include the following patch into the package: https://github.com/intel/media-driver/issues/1095 -- System Information: Debian Release: 11.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-20-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en_GB Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages intel-media-va-driver depends on: ii libc6 2.31-13+deb11u5 ii libgcc-s1 10.2.1-6 ii libigdgmm11 20.4.1+ds1-1 ii libstdc++6 10.2.1-6 ii libva2 [libva-driver-abi-1.10] 2.10.0-1 intel-media-va-driver recommends no packages. intel-media-va-driver suggests no packages. -- no debconf information
Bug#1025452: lintian: useless checks of debian/tests datafiles
Package: lintian Version: 2.115.3 Severity: important I'm working on new upstream version of upx-ucl. The package contains some *intentionally broken* ELF files inside debian/tests to check that for example upx does not crash on them. However for some reason lintan wants the data files to be perfectly correct binaries, with an accompanying source files. IMHO this is just ridiculous. Those files are in debian/tests anyway, what's the point of having such strict requirements on them? Anyway, some time ago I added overrides for those warnings, but now I can see that: - the overrides do no longer work, because lintian now requires names to be put inside square brackets; - some new checks were implemented to see if ELF file is correct, and the new checks display a bunch of additional warnings making it completely unreadable (and I do not think they can be overridden). Please just look at this lintian output of upx-ucl 3.96-3 package: Now running lintian --display-info --display-experimental --pedantic --color=always upx-ucl_3.96-3_amd64.changes ... upx-ucl_3.96-3.dsc (patched): Warning while running readelf ondebian/tests/data/907426-poc_free: Parse error in readelf section headers [row 1]: [ 0] 00010102: 0001003e0002 405418 40 43 0 0 15762873573703680 at /usr/share/lintian/bin/../lib/Lintian/Index/Elf.pm line 569. upx-ucl_3.96-3.dsc (patched): Warning while running readelf ondebian/tests/data/907426-poc_free: Parse error in readelf section headers [row 9]: [ 4] 00ce: 00010102464c457f 4025b00d003e0002 35166de4b60f d84f21364027050f A 51577028 955743702 432376351040014592 at /usr/share/lintian/bin/../lib/Lintian/Index/Elf.pm line 569. upx-ucl_3.96-3.dsc (patched): Warning while running readelf ondebian/tests/data/907426-poc_free: Parse error in readelf section headers [row 11]: [ 5] 27080001: 213c84c840070f02 ec0ec27011c 2fb3cc074005 7b0b90641704e460 WAxMILTCo 9475801 2872516608 510523112357773942 at /usr/share/lintian/bin/../lib/Lintian/Index/Elf.pm line 569. upx-ucl_3.96-3.dsc (patched): Warning while running readelf ondebian/tests/data/907426-poc_free: Parse error in readelf section headers [row 15]: [ 8] 0400322e: 0302dd34cfba fff60303141f2006 5631d867221fc1ff 490437432c17f6f7 ox 2146830080 2207070372 1972876281791746561 at /usr/share/lintian/bin/../lib/Lintian/Index/Elf.pm line 569. upx-ucl_3.96-3.dsc (patched): Warning while running readelf ondebian/tests/data/907426-poc_free: Parse error in readelf section headers [row 19]: [10] 2f311b08: 086c21b017098f12 864219082f6247e5 17866c21b0865e62 a7021b086c212f29 AMLOGTop 1691277137 398596360 12089950241734945530 at /usr/share/lintian/bin/../lib/Lintian/Index/Elf.pm line 569. upx-ucl_3.96-3.dsc (patched): Warning while running readelf ondebian/tests/data/907426-poc_free: Parse error in readelf section headers [row 22]: [11] 5f55b086: f14d86421908bb17 17488fe56c21b086 745f20421b086198 2b02d0759b23b0 WAXMSLOGTCxxlExx 1814138935 2486117640 3417519580065700616 at /usr/share/lintian/bin/../lib/Lintian/Index/Elf.pm line 569. upx-ucl_3.96-3.dsc (patched): Warning while running readelf ondebian/tests/data/907426-poc_free: Parse error in readelf section headers [row 24]: [12] 17dd86c2: 01804219086c0b2f 8a1d42190864217 86373677841b0861 432f5b21b0864277 WAMSLGTxop 527180208 3944157743 6210289578152757356 at /usr/share/lintian/bin/../lib/Lintian/Index/Elf.pm line 569. upx-ucl_3.96-3.dsc (patched): Warning while running readelf ondebian/tests/data/907426-poc_free: Parse error in readelf section headers [row 26]: [13] 1bc3178d: 701738086c21902f 2f8c5f7b86c21b08 1748bf3d6c21b086 21039f0002a87272 AILGTxop 3076108358 1132526 4860816968149843738 at /usr/share/lintian/bin/../lib/Lintian/Index/Elf.pm line 569. upx-ucl_3.96-3.dsc (patched): Warning while running readelf ondebian/tests/data/907426-poc_free: Parse error in readelf section headers [row 29]: [14] 2fb31817: 17206c87272077ac 4d862689f100039 5fff0036de63efa8 746573006b68635f WAXMop 1718026210 1752397164 7382801058585599744 at /usr/share/lintian/bin/../lib/Lintian/Index/Elf.pm line 569. upx-ucl_3.96-3.dsc (patched): Warning while running readelf ondebian/tests/data/907426-poc_free: Parse error in readelf section headers [row 34]: [18] 5f6f6eb5: adbe103fc928f28c 64742666807a4b04 1b74845f6ec7756f 6e3eddf0a16d956d XxSIOTCop 1699376211 2037396843 8452239821877519578 at /usr/share/lintian/bin/../lib/Lintian/Index/Elf.pm line 569. upx-ucl_3.96-3.dsc (patched): Warning while running readelf ondebian/tests/data/907426-poc_free: Parse error in readelf section headers [row 36]: [19] 372f004f: bdb7bdb77e62bd6f 6567208368764a6d 7784009dba17c2b5 322738739d0cdd91 WxMILOTCxop 2826200169 3671557790 3259666543423467181 at
Bug#1025131: apt-cacher-cleanup does not work
Mark Hindley pisze:
Hi,
Control: tags -1 patch
Robert,
Many thanks for pointing this out.
Does the attached patch help?
No, due to perl's syntax error related to unmatched parenthesis. I'm
attaching a patch that actually works.
Regards,
Robert
From cc36b2f690d694ad0cfe1b1c0ca5df7ead3e57ca Mon Sep 17 00:00:00 2001
From: Mark Hindley
Date: Wed, 30 Nov 2022 11:30:21 +
Subject: [PATCH] Add encoded underscores to *_files_regexp. Test fix for
#1025131.
---
lib/apt-cacher.pl | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/apt-cacher.pl b/lib/apt-cacher.pl
index 712d0bc..dad985a 100755
--- a/lib/apt-cacher.pl
+++ b/lib/apt-cacher.pl
@@ -132,7 +132,7 @@ sub read_config {
qw(vmlinuz
linux
initrd\.gz
- (?:%VALID_PACKAGE_NAME%_%VALID_VERSION%[_\.])?changelog
+ (?:%VALID_PACKAGE_NAME%(?:_|%5f)%VALID_VERSION%[_\.])?changelog
NEWS\.Debian
%VALID_UBUNTU_RELEASE_NAMES%\.tar\.gz(?:\.gpg)?
(?:by-hash/(?i:MD5SUM/[0-9a-f]{32}|SHA1/[0-9a-f]{40}|SHA256/[0-9a-f]{64}))
@@ -141,7 +141,7 @@ sub read_config {
)
) . ')$',
package_files_regexp => '(?:' . join('|',
- qw((?:^|/)%VALID_PACKAGE_NAME%_%VALID_VERSION%(?:_%VALID_ARCHS%\.(?:u|d)?deb|\.dsc|\.tar\.(?:gz|bz2|xz|lzma)(?:\.asc)?|\.diff\.gz)
+ qw((?:^|/)%VALID_PACKAGE_NAME%(?:_|%5f)%VALID_VERSION%(?:(?:_|%5f)%VALID_ARCHS%\.(?:u|d)?deb|\.dsc|\.tar\.(?:gz|bz2|xz|lzma)(?:\.asc)?|\.diff\.gz)
\.rpm
index\.db-.+\.gz
\.jigdo
--
2.35.1
Bug#1025131: apt-cacher-cleanup does not work
Package: apt-cacher Version: 1.7.27 Severity: important The "Encode embedded underscores in URLs when building filenames" change introduced in 1.7.27 broke apt-cacher-cleanup.pl: it does not clean *.deb files at all, as stored file names such as adduser%5f3.127%5fall.deb adduser%5f3.128%5fall.deb adduser%5f3.129%5fall.deb do no longer match to the $package_files_regexp. Regards robert -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (990, 'unstable-debug'), (990, 'unstable'), (990, 'testing'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages apt-cacher depends on: ii debconf [debconf-2.0] 1.5.79 ii distro-info-data 0.56 ii ed 1.18-1 ii init-system-helpers1.64 ii libdpkg-perl 1.21.9 ii libfilesys-df-perl 0.92-7+b1 ii libio-interactive-perl 1.023-2 ii libio-interface-perl 1.09-2+b2 ii libipc-sharelite-perl 0.17-4+b7 ii libnetaddr-ip-perl 4.079+dfsg-2+b1 ii libsys-syscall-perl0.25-7 ii libwww-curl-perl 4.17-8+b1 ii libwww-perl6.67-1 ii lsb-base 11.5 ii perl 5.36.0-4 ii sysvinit-utils [lsb-base] 3.05-6 ii update-inetd 4.51 Versions of packages apt-cacher recommends: ii libberkeleydb-perl0.64-2+b1 ii libio-compress-lzma-perl 2.201-1 Versions of packages apt-cacher suggests: pn libfreezethaw-perl ii libio-socket-inet6-perl 2.73-1 -- Configuration Files: /etc/apt-cacher/apache.conf changed [not included] /etc/apt-cacher/apt-cacher.conf changed [not included] /etc/cron.d/apt-cacher changed [not included] -- debconf information excluded -- debsums errors found: debsums: changed file /usr/share/apt-cacher/apt-cacher-cleanup.pl (from apt-cacher package) debsums: changed file /usr/share/apt-cacher/lib/apt-cacher.pl (from apt-cacher package)
Bug#1015003: transmission-daemon Out of Memory
The issue has been already fixed, but we have to wait for the next release, or we can install the nightly builds as recommended by ckerr. More details at https://bugs.launchpad.net/ubuntu/+source/transmission/+bug/1973084/comments/9 On Sun, 27 Nov 2022 12:13:32 +0100 Robert Micsutka wrote: > I am experiencing the same issue. > > Nov 26 23:43:21 nas kernel: Out of memory: Killed process 809 > (transmission-da) total-vm:8404340kB, anon-rss:7405076kB, file-rss:228kB, > shmem-rss:0kB, UID:117 pgtables:14688kB oom_score_adj:0 > > On Thu, 29 Sep 2022 20:01:49 +1000 Jiri Kanicky wrote: > > I am experiencing the same issue. > > > > Sep 26 04:33:33 server kernel: Out of memory: Killed process 16702 > > (transmission-da) total-vm:4933944kB, anon-rss:3566896kB, file-rss:0kB, > > shmem-rss:0kB, UID:133 pgtables:7928kB oom_score_adj:0d
Bug#1015003: transmission-daemon Out of Memory
I am experiencing the same issue. Nov 26 23:43:21 nas kernel: Out of memory: Killed process 809 (transmission-da) total-vm:8404340kB, anon-rss:7405076kB, file-rss:228kB, shmem-rss:0kB, UID:117 pgtables:14688kB oom_score_adj:0 On Thu, 29 Sep 2022 20:01:49 +1000 Jiri Kanicky wrote: > I am experiencing the same issue. > > Sep 26 04:33:33 server kernel: Out of memory: Killed process 16702 > (transmission-da) total-vm:4933944kB, anon-rss:3566896kB, file-rss:0kB, > shmem-rss:0kB, UID:133 pgtables:7928kB oom_score_adj:0d
Bug#1023501: busybox-static: version 1:1.35.0-3 breaks boot on hppa
severity 1023501 grave retitle 1023501 busybox-static: version 1:1.35.0-3 breaks boot on hppa and amd64 found 1023501 1:1.35.0-3 notfound 1023501 1:1.35.0-2 On Sat, 05 Nov 2022 13:31:51 + John David Anglin wrote: Package: busybox-static Version: 1:1.35.0-2 Severity: normal Dear Maintainer, With 1:1.35.0-3, boot ends in initramfs: Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... done. Begin: Waiting for root file system ... Begin: Running /scripts/local-block ... mdadm: No arrays found in config file or automatically done. Begin: Running /scripts/local-block ... mdadm: No arrays found in config file or automatically I had the same issue on amd64. Removing mdadm package did not help. Downgrading busybox-static to 1.35.0-2 fixed the issue. I'm including the system information generated by reportbug below: -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (990, 'unstable-debug'), (990, 'unstable'), (990, 'testing'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages busybox depends on: ii libc6 2.36-4 busybox recommends no packages. busybox suggests no packages. -- no debconf information Regards, Robert
Bug#1021248: rrdcached: Remove $remote_fs from /etc/init.d/rrdcached
Package: rrdcached
Version: 1.7.2-3+b7
Severity: normal
Dear Maintainer,
I want to suggest removing the dependency on $remote_fs for rrdcached.
I assume that in 99% of cases rrdached writes to a local filesystem.
The remaining cases can be handled by adding $remote_fs again or even by
using a systemd override (After=remote-fs.target).
I am getting a circular dependency with another service that has to be
started after rrdcached but before a remote filesystem can be mounted.
-- System Information:
Debian Release: 11.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.15.39-4-pve (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE
not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages rrdcached depends on:
ii init-system-helpers 1.60
ii libc62.31-13+deb11u3
ii libglib2.0-0 2.66.8-1
ii librrd8 1.7.2-3+b7
ii lsb-base 11.1.0
rrdcached recommends no packages.
rrdcached suggests no packages.
-- Configuration Files:
/etc/init.d/rrdcached changed:
#!/bin/sh
### BEGIN INIT INFO
# Provides: rrdcached
# Required-Start: $local_fs $named $time $network
# Required-Stop: $local_fs $network
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: start or stop rrdcached
# Description: Daemon that accumulates updates to RRD files and flushes
# them periodically or on command.
### END INIT INFO
#
PATH=/sbin:/usr/sbin:/bin:/usr/bin
NAME=rrdcached
DESC="RRD cache daemon"
DAEMON=/usr/bin/rrdcached
DEFAULT=/etc/default/rrdcached
test -f ${DEFAULT} && . ${DEFAULT}
PIDFILE=${PIDFILE:-/var/run/${NAME}.pid}
RRDCACHED_OPTIONS="\
${BASE_OPTIONS} \
${NETWORK_OPTIONS} \
${WRITE_TIMEOUT:+-w ${WRITE_TIMEOUT}} \
${WRITE_JITTER:+-z ${WRITE_JITTER}} \
${WRITE_THREADS:+-t ${WRITE_THREADS}} \
${BASE_PATH:+-b ${BASE_PATH}} \
${JOURNAL_PATH:+-j ${JOURNAL_PATH}} \
${DAEMON_GROUP:+-G ${DAEMON_GROUP}} \
${DAEMON_USER:+-U ${DAEMON_USER}} \
-p ${PIDFILE} \
${SOCKFILE:+${SOCKGROUP:+-s ${SOCKGROUP}} ${SOCKMODE:+-m ${SOCKMODE}}
-l unix:${SOCKFILE}} \
"
. /lib/lsb/init-functions
RETVAL=1
# Do any pre-start checks. If this returns nonzero, the failure
# diagnostic has already been generated.
validate_prestart () {
if [ -n "${JOURNAL_PATH}" -a ! -d "${JOURNAL_PATH}" ] ; then
mkdir -p "${JOURNAL_PATH}"
if [ 0 != $? ] ; then
log_failure_msg "${NAME}: Unable to find/create journal
directory ${JOURNAL_PATH}"
return 1
fi
fi
if [ -n "${BASE_PATH}" -a ! -d "${BASE_PATH}" ] ; then
mkdir -p "${BASE_PATH}"
if [ 0 != $? ] ; then
log_failure_msg "${NAME}: Unable to find/create base
directory ${BASE_PATH}"
return 1
fi
fi
return 0
}
# Whatever's necessary to start a daemon. Any currently-running
# daemon is left unmolested and no new daemon is started. Return as
# with start_daemon.
do_start () {
start_daemon -p ${PIDFILE} ${DAEMON} ${RRDCACHED_OPTIONS}
return $?
}
# Perform a restart from a state with no daemon running. This
# function emits the success/failure diagnostics. Return as with
# restart.
do_restart_diag () {
validate_prestart
if [ 0 != $? ] ; then
rv=$?
else
do_start
rv=$?
if [ 0 = $? ] ; then
log_success_msg "${NAME} restarted"
else
log_failure_msg "${NAME} restart failed"
fi
fi
return ${rv}
}
# Whatever's necessary to check daemon status. Sets PID if the daemon
# is running. Return as pidofproc.
do_status () {
PID=$( pidofproc -p ${PIDFILE} ${DAEMON} )
return $?
}
# Whatever's necessary to stop the daemon. Returns as stop action.
do_stop () {
killproc -p ${PIDFILE} ${DAEMON}
rv=$?
# rrdcached traps the TERM signal and does some flushing.
# Give it a chance to shut down before returning, lest
# we restart it too soon.
max_iters=${STOP_WAIT_DELAY:-5}
while [ 0 -lt ${max_iters} ] ; do
if pidofproc -p ${PIDFILE} ${DAEMON} >/dev/null ; then
log_warning_msg "${NAME} is still running"
sleep 1
max_iters=$(( ${max_iters} - 1 ))
rv=1
else
rv=0
break
fi
done
return $?
}
case "$1" in
start)
# Succeed if service already started or start attempt succeeds
if do_status > /dev/null ; then
log_success_msg "${NAME} is already started as ${PID}"
RETVAL=0
else
validate_prestart
RETVAL=$?
if [ 0 = ${RETVAL} ] ; then
do_start
RETVAL=$?
if [ 0 = ${RETVAL} ] ; then
Bug#1020639: (no subject)
merge 1020639 1021076 severity 1020639 grave Raising severity has PDF Arranger is now unusable
Bug#1020639: (no subject)
severity 1020639 important Lowering serverity because pdfarranger as NOT YET been removed from testing
Bug#1020639: pdfarranger: libqpdf 11 require pdfarranger 1.9.1
Package: pdfarranger Version: 1.8.2-1 Severity: grave Tags: upstream Justification: renders package unusable X-Debbugs-Cc: jeromerob...@gmx.com Dear Maintainer, pdfarranger depends on pikepdf. pikepdf 5.1.1 FTBS with libqpdf 11: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019694 According to Salsa pikepdf 6 is about to be uploaded. Once done pdfarranger will stop working because of: https://github.com/pdfarranger/pdfarranger/issues/716 So pdfarranger should be updated to 1.9.1. Tagging as grave because pdfarranger has already been removed from testing because pikepdf was removed from testing because of 1019694. Once pikepdf will be back in version 6 pdfarranger will be unusable. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.19.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 pdfarranger depends on: ii gir1.2-glib-2.01.73.0+ds-1 ii gir1.2-gtk-3.0 3.24.34-3 ii gir1.2-poppler-0.1822.08.0-2.1 ii python33.10.6-1 ii python3-cairo 1.20.1-3+b1 ii python3-dateutil 2.8.1-6 ii python3-gi 3.42.2-2 ii python3-gi-cairo 3.42.2-2 ii python3-pikepdf5.1.1+dfsg-1+b1 ii python3-pkg-resources 65.3.0-1.1 Versions of packages pdfarranger recommends: ii python3-img2pdf 0.4.4-2 pdfarranger suggests no packages. -- no debconf information
Bug#1020215: (no subject)
Typo in my patch, it should be "if (obuf->flag & RB_HEAD)", not "if (obuf->flag | RB_HEAD)"
Bug#1020215: w3m interprets when not in but in
Package: w3m
Version: 0.5.3+git20220429-1+b1
When opening a page in w3m that contains an element that contains
a tag, w3m will use that svg title as the page title.
An example of a page to demonstrate this problem is github.com. The
real title of github.com is "GitHub: Where the world builds software ·
GitHub" but w3m displays the title "Go" (or the name of any other
language) because the front page contains svg images for different
programming languages with title tags.
Here is a patch I made. I don't know if this is the most optimal way to
solve this but it seems to work in practice and I will use it locally
until there in an upstream fix.
commit f41db326e73fde685c1d0b79e46beec56336995e
Author: Robert Alm Nilsson
Date: Sun Sep 18 09:51:29 2022 +0200
Only read title when in head
Before this change, it was possible that w3m would interpret a title tag
under e.g. an svg tag as the page title.
diff --git a/file.c b/file.c
index 9704cea..8e8b280 100644
--- a/file.c
+++ b/file.c
@@ -4816,19 +4816,23 @@ HTMLtagproc1(struct parsed_tag *tag, struct
html_feed_environ *h_env)
/* obuf->flag |= RB_IGNORE_P; */
return 1;
case HTML_TITLE:
- close_anchor(h_env, obuf);
- process_title(tag);
- obuf->flag |= RB_TITLE;
- obuf->end_tag = HTML_N_TITLE;
+ if (obuf->flag & RB_HEAD) {
+ close_anchor(h_env, obuf);
+ process_title(tag);
+ obuf->flag |= RB_TITLE;
+ obuf->end_tag = HTML_N_TITLE;
+ }
return 1;
case HTML_N_TITLE:
- if (!(obuf->flag & RB_TITLE))
- return 1;
- obuf->flag &= ~RB_TITLE;
- obuf->end_tag = 0;
- tmp = process_n_title(tag);
- if (tmp)
- HTMLlineproc1(tmp->ptr, h_env);
+ if (obuf->flag | RB_HEAD) {
+ if (!(obuf->flag & RB_TITLE))
+ return 1;
+ obuf->flag &= ~RB_TITLE;
+ obuf->end_tag = 0;
+ tmp = process_n_title(tag);
+ if (tmp)
+ HTMLlineproc1(tmp->ptr, h_env);
+ }
return 1;
case HTML_TITLE_ALT:
if (parsedtag_get_value(tag, ATTR_TITLE, ))
@@ -5523,9 +5527,13 @@ HTMLtagproc1(struct parsed_tag *tag, struct
html_feed_environ *h_env)
}
}
case HTML_N_HEAD:
+ obuf->flag &= ~RB_HEAD;
if (obuf->flag & RB_TITLE)
HTMLlineproc1("", h_env);
+ return 1;
case HTML_HEAD:
+ obuf->flag |= RB_HEAD;
+ return 1;
case HTML_N_BODY:
return 1;
default:
diff --git a/fm.h b/fm.h
index 25857f8..9e12b42 100644
--- a/fm.h
+++ b/fm.h
@@ -675,6 +675,7 @@ struct readbuffer {
#define RB_DEL 0x10
#define RB_S 0x20
#define RB_HTML5 0x40
+#define RB_HEAD0x80
#define RB_GET_ALIGN(obuf) ((obuf)->flag_ALIGN)
#define RB_SET_ALIGN(obuf,align) do{(obuf)->flag &= ~RB_ALIGN; (obuf)->flag |=
(align); }while(0)
Bug#1014730: liburi-perl: Breaks apt-cacher with "Can't locate Regexp/IPv6.pm" error
gregor herrmann pisze:
I'm a bit surprised, because the new code in 5.11 should behave
better if Regexp::IPv6 is not available:
Yes, but it looks like apt-cacher seems to set its own SIG{__DIE__} handler.
+our $IPv6_re;
+
+sub _looks_like_raw_ip6_address {
+ my $addr = shift;
+
+ if ( !$IPv6_re ) { #-- lazy / runs once / use Regexp::IPv6 if installed
+eval {
I've just checked that adding
local $SIG{__DIE__};
here (i.e. before the require line) fixes the issue with apt-cacher for me.
+ require Regexp::IPv6;
+ Regexp::IPv6->import( qw($IPv6_re) );
+ 1;
+} || do { $IPv6_re = qr/[:0-9a-f]{3,}/; }; #-- fallback: unambitious
guess
But may as well move libregexp-ipv6-perl to Depends, I guess.
Probably yes, but IMHO it would be better to restore default __DIE__
handler.
Regards,
robert
Bug#1014730: liburi-perl: Breaks apt-cacher with "Can't locate Regexp/IPv6.pm" error
Package: liburi-perl Version: 5.11-1 Severity: serious Justification: Policy 7.2 Control: affects -1 apt-cacher After recent upgrade I've noticed that apt-cached does no longer work: Err:2 http://apt-testing.vox:3142/apt-cacher/debian bookworm InRelease 502 apt-cacher internal error (died) [IP: 127.0.0.1 3142] The following information is printed into apt-cacher.log: Mon Jul 11 00:02:52 2022|error [18513]: Can't locate Regexp/IPv6.pm in @INC (you may need to install the Regexp:: IPv6 module) (@INC contains: /usr/share/apt-cacher/lib /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.34.0 /usr /local/share/perl/5.34.0 /usr/lib/x86_64-linux-gnu/perl5/5.34 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-bas e /usr/lib/x86_64-linux-gnu/perl/5.34 /usr/share/perl/5.34 /usr/local/lib/site_perl) at /usr/share/perl5/URI/_gen eric.pm line 25. Downgrading liburi-perl to 5.10 fixes the issue. Regards, robert -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.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 liburi-perl depends on: ii perl 5.34.0-5 liburi-perl recommends no packages. Versions of packages liburi-perl suggests: pn libbusiness-isbn-perl pn libregexp-ipv6-perl ii libwww-perl6.67-1 -- no debconf information
Bug#1011146: Fwd: 1011146: nvidia-graphics-drivers-tesla-470 is a dependency of libb2
Is libb2 a dependency of coreutils (for b2sum)? -- Forwarded message - From: Robert Ransom Date: Thu, May 26, 2022, 07:47 Subject: 1011146: nvidia-graphics-drivers-tesla-470 is a dependency of libb2 To:
Bug#1011160: Incorrect patch for CVE-2022-1355
Package: libtiff Version: 4.3.0-7 In 4.3.0-7 it looks like you've included a patch based on https://gitlab.com/ libtiff/libtiff/-/commit/9752dae8febab08879fc0159e7d387cff14eb3c3 as a fix for CVE-2022-1355, but I don't think this is the right patch. You can confirm this by building the package with `-fsanitize=address` and running the issue's poc command listed at https://gitlab.com/libtiff/libtiff/-/issues/400: > tiffcp -8 -8 -8 -8 -8 -8 -8 -8 -8 -8 ./i ./i When putting together the fix for the NixOS package, I noticed that it still triggers AddressSanitizer in an identical way with the patch. I think this happened because the commit in question is (mistakenly?) commented with > Closes #400 et #8 Perhaps this was just a typo on their part. The good news is that the commit https://gitlab.com/libtiff/libtiff/-/commit/ c1ae29f9ebacd29b7c3e0c7db671af7db3584bc2, merged in https://gitlab.com/ libtiff/libtiff/-/merge_requests/323, applies cleanly (no prerequisite patches or patch mangling required) and *does* solve the poc. robert.
Bug#1010147: mutt 2.x broke workflow in mailbox handling with history changes
Hi, On Mon, 25 Apr 2022 11:22:51 +0200 =?utf-8?q?Uwe_Kleine-K=C3=B6nig?= wrote: > I'd like to have that fixed in Debian---ideally in stable--- and wonder > what is the best way forward. The obvious options are > > a) apply the patch to 2.0.5-4.1 and upload to proposed updates > b) add a backport or 2.2.3-1 to bpo > > Given that upstream considered this change worth to be applied to > their stable branch, I would consider option a) justified. > > What is your opionion here? I can prepare an nmudiff for option a) if > you're ok with that option and also offer to actually to nmu. (But > having you upload would be my preferred way.) Is there anything we can do to help? rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Bug#1009632: The QPA plugin package contains the TLS backends
Hi Patrick,
On 15.04.2022 18:03, Patrick Franz wrote:
And while we're at it: the image format plugins also do not really
belong into the qpa plugin package for the same reasons: you can use
QtGui and the QImage classes perfectly fine in a headless daemon:
/usr/lib/x86_64-linux-gnu/qt6/plugins/imageformats/libqgif.so
/usr/lib/x86_64-linux-gnu/qt6/plugins/imageformats/libqico.so
/usr/lib/x86_64-linux-gnu/qt6/plugins/imageformats/libqjpeg.so
Which package name do you suggest ? We already have " qt6-image-formats-
plugins", but that is from the qtimageformats module.
The question is how modular we really want to be here: as gif and jpg
are really standard image formats, I'd rather package those up in the
libqt6gui6 package (as it was done for libqt5gui5).
If you do want to split them off, then it might be something like
"qt6-[base|gui]-image-formats-plugins".
You'd probably have to rename the existing package
("qt6-image-formats-plugins") to "qt6-extra-image-formats-plugins" as
well to avoid confusion.
cu
Robert
Bug#1009632: The QPA plugin package contains the TLS backends
Package: qt6-qpa-plugins Version: 6.2.2 The new Qt6 plugins for the TLS backend (QSslSocket) got packaged with the QPA plugins, which is a bit awkward if you have a headless daemon that needs to download from https:// URLs, because you are now pulling in a lot of X11 and OpenGL dependencies. I think these should be in their own qt6-tls-plugins package: /usr/lib/x86_64-linux-gnu/qt6/plugins/tls/libqcertonlybackend.so /usr/lib/x86_64-linux-gnu/qt6/plugins/tls/libqopensslbackend.so And while we're at it: the image format plugins also do not really belong into the qpa plugin package for the same reasons: you can use QtGui and the QImage classes perfectly fine in a headless daemon: /usr/lib/x86_64-linux-gnu/qt6/plugins/imageformats/libqgif.so /usr/lib/x86_64-linux-gnu/qt6/plugins/imageformats/libqico.so /usr/lib/x86_64-linux-gnu/qt6/plugins/imageformats/libqjpeg.so Thanks for looking into this, Robert
Bug#1007872: libc6-dev: getaddrinfo() finds an AF_INET address when hinting AF_UNSPEC, but not when hinting AF_INET
Package: libc6-dev
Version: 2.33-7
Severity: normal
Dear Maintainer,
Under certain circumstances, when calling getaddrinfo with hints.ai_family =
AF_UNSPEC, the first result is an AF_INET address. When calling it with
hints.ai_family = AF_INET, however, it returns 251 (No address associated with
hostname).
Here is a short program that reproduces the issue:
```c
#include
#include
#include
#include
#include
int main(int argc, char *argv[]) {
const char hostname[] = "SomeHostname";
const char service[] = "1433";
struct addrinfo hints, *res;
memset(, 0, sizeof(hints));
int ret = getaddrinfo(hostname, service, , );
assert(ret == 0);
assert(res->ai_family == AF_INET);
freeaddrinfo(res);
hints.ai_family = AF_INET;
ret = getaddrinfo(hostname, service, , );
if (ret != 0) {
printf(gai_strerror(ret));
printf("\n");
} else {
freeaddrinfo(res);
}
return ret;
}
```
I have only been able to reproduce the bug when all of the following criteria
are met:
- Running in a Docker container on a Windows host
- The hostname is unqualified
- The container's /etc/resolv.conf does not include the correct search option
to resolve the hostname
- The Windows host is set up to resolve unqualified names by applying the
correct DNS suffix
getaddrinfo() also returns 251 if the AI_ADDRCONFIG flag is set, even though
the container has an IPV4 address.
The bug is also present in 2.34-0experimental3.
Symptoms are superficially similar to #854301, but the container is online and
passing AI_ADDRCONFIG returns no result.
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.60.1-microsoft-standard-WSL2 (SMP w/12 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
Versions of packages libc6-dev depends on:
ii libc-dev-bin2.33-7
ii libc6 2.33-7
ii libcrypt-dev1:4.4.27-1.1
ii libnsl-dev 1.3.0-2
ii linux-libc-dev 5.16.12-1
ii rpcsvc-proto1.4.2-4
libc6-dev recommends no packages.
Versions of packages libc6-dev suggests:
pn glibc-doc
ii manpages-dev 5.10-1
-- no debconf information
Bug#1004896: efibootmgr: please provide some automation
Package: efibootmgr Version: 17-1 Severity: wishlist Dear Maintainer, Please consider providing some level of automation of running debian with efistub as part of the package. There is a very nice write-up with example config files and scripts in the debian wiki https://wiki.debian.org/EFIStub I imagine there could be a file in /etc/default/efiboot with entries such as EFI_ADD_ENTRY=1 EFI_CMDLINE_LINUX=quiet add_efi_memmap EFI_COPY_INITRD=1 EFI_COPY_VMLINUZ=1 Thank you, Robert -- System Information: Debian Release: 11.2 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-11-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=C, LC_CTYPE=C.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 efibootmgr depends on: ii libc62.31-13+deb11u2 ii libefiboot1 37-6 ii libefivar1 37-6 ii libpopt0 1.18-2 efibootmgr recommends no packages. efibootmgr suggests no packages. -- no debconf information
Bug#1004414: systemd-cron: generator turns crontabs public readable
Package: systemd-cron Version: 1.15.18-1 Severity: normal Tags: security X-Debbugs-Cc: robert.siemer-report...@backsla.sh, Debian Security Team Crontabs, especially in /var/spool/cron are not readable to all users. Translated command lines in unit files in /run/systemd/generator on the other hand are. Shell variable assignments, written before a command would turn readable to everyone, which they are otherwise never. Further: the changed situation improves the opportunities for snooping around. On purpose? Regards, Robert -- Package-specific info: -- output of systemd-delta -- System Information: Debian Release: bookworm/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 5.10.0-8-686-pae (SMP w/2 CPU threads) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages systemd-cron depends on: ii libc6 2.33-3 ii python3 3.9.8-1 ii systemd [systemd-sysusers] 250.3-1 ii systemd-sysv250.3-1 Versions of packages systemd-cron recommends: ii postfix [mail-transport-agent] 3.6.4-1 systemd-cron suggests no packages. -- no debconf information
Bug#1004326: libnss-systemd: postinst modification of /etc/nsswitch.conf forgets (g)shadow
Package: libnss-systemd Version: 250.3-1 Severity: normal X-Debbugs-Cc: robert.siemer-report...@backsla.sh /var/lib/dpkg/info/libnss-systemd\:i386.postinst does not add `systemd` on the shadow and gshadow lines of /etc/nsswitch.conf, only passwd and group. All four dbs should have `systemd` added according to man page nss-systemd(8). I guess the manual page got corrected without it going into the postinst script, isn’t it? Regards, Robert -- System Information: Debian Release: bookworm/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 5.10.0-8-686-pae (SMP w/2 CPU threads) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libnss-systemd depends on: ii libc62.33-3 ii systemd 250.3-1 libnss-systemd recommends no packages. libnss-systemd suggests no packages. -- no debconf information
Bug#1004118: closed by James McCoy (Re: Bug#1004118: E1187: Failed to source defaults.vim)
I’m pretty sure that it was a vim alternative at the time I installed it. – Might have been 10+ years ago, though. Anyway... good to know which way to go now. Regards, Robert On Fri, Jan 21, 2022 at 2:39 PM Debian Bug Tracking System < ow...@bugs.debian.org> wrote: > This is an automatic notification regarding your Bug report > which was filed against the vim-tiny package: > > #1004118: E1187: Failed to source defaults.vim > > It has been closed by James McCoy . > > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact James McCoy < > james...@debian.org> by > replying to this email. > > > -- > 1004118: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004118 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems > > > > -- Forwarded message -- > From: James McCoy > To: Robert Siemer , > 1004118-d...@bugs.debian.org > Cc: > Bcc: > Date: Fri, 21 Jan 2022 08:37:52 -0500 > Subject: Re: Bug#1004118: E1187: Failed to source defaults.vim > On Fri, Jan 21, 2022 at 03:58:58AM +0100, Robert Siemer wrote: > > vim-tiny should come with defaults.vim, I believe. > > No, vim-tiny exists purely to provide a vi binary in the base system and > therefore is geared towards a vi-like experience more so than a vim-like > experience. > > This is why vim-tiny does not register itself as an option for the vim > alternative. > > If you want it to be more vim-like, then installing vim-runtime is a > reasonable step to take. > > Cheers, > -- > James > GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB > > > -- Forwarded message -- > From: Robert Siemer > To: Debian Bug Tracking System > Cc: > Bcc: > Date: Fri, 21 Jan 2022 03:58:58 +0100 > Subject: E1187: Failed to source defaults.vim > Package: vim-tiny > Version: 2:8.2.3995-1 > Severity: normal > X-Debbugs-Cc: robert.siemer-report...@backsla.sh > > vim-tiny should come with defaults.vim, I believe. Which way I’m not sure, > but it seems vim-common does not deliver it and vim-tiny does not depend > on vim-runtime, which has it. > > > -- Package-specific info: > > --- real paths of main Vim binaries --- > /usr/bin/vi is /usr/bin/vim.tiny > /usr/bin/vim is /usr/bin/vim.tiny > > -- System Information: > Debian Release: bookworm/sid > APT prefers stable-security > APT policy: (500, 'stable-security'), (500, 'unstable') > Architecture: i386 (i686) > > Kernel: Linux 5.10.0-8-686-pae (SMP w/2 CPU threads) > Kernel taint flags: TAINT_UNSIGNED_MODULE > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE > not set > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages vim-tiny depends on: > ii libacl1 2.3.1-1 > ii libc62.33-3 > ii libselinux1 3.3-1+b1 > ii libtinfo66.3-2 > ii vim-common 2:8.2.3995-1 > > vim-tiny recommends no packages. > > Versions of packages vim-tiny suggests: > pn indent > > -- no debconf information >
Bug#1004118: E1187: Failed to source defaults.vim
Package: vim-tiny Version: 2:8.2.3995-1 Severity: normal X-Debbugs-Cc: robert.siemer-report...@backsla.sh vim-tiny should come with defaults.vim, I believe. Which way I’m not sure, but it seems vim-common does not deliver it and vim-tiny does not depend on vim-runtime, which has it. -- Package-specific info: --- real paths of main Vim binaries --- /usr/bin/vi is /usr/bin/vim.tiny /usr/bin/vim is /usr/bin/vim.tiny -- System Information: Debian Release: bookworm/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 5.10.0-8-686-pae (SMP w/2 CPU threads) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages vim-tiny depends on: ii libacl1 2.3.1-1 ii libc62.33-3 ii libselinux1 3.3-1+b1 ii libtinfo66.3-2 ii vim-common 2:8.2.3995-1 vim-tiny recommends no packages. Versions of packages vim-tiny suggests: pn indent -- no debconf information
Bug#1003983: opendkim cannot initialize resolver in dkim_dns_init() (libunbound, libnettle, ...?)
Without libunbound it works. – Problem solved? :-o On Wed, Jan 19, 2022 at 12:41 PM David Bürgin wrote: > Robert Siemer: > > Opendkim does not run. > > > > # opendkim -f > > [1642532480] libunbound[837:0] error: nettle random(yarrow) cannot > initialize, getentropy failed: Function not implemented > > opendkim: can't configure DKIM library: failed to initialize resolver > > > > I even recompiled from source deb, both opendkim and libunbound. > > An ltrace showed that dkim_dns_init() fails with -1, and that > > one calls ub_ctx_create() which returns 0 but provokes the > > first line to be printed. The second line is the reason printed > > when dkim_dns_init() fails. > > opendkim uses libunbound by default. The error is from libunbound, > perhaps try building opendkim without libunbound and see what happens? > > > https://salsa.debian.org/debian/opendkim/-/blob/debian/2.11.0_beta2-6/debian/rules#L10-14 >
Bug#1003983: opendkim cannot initialize resolver in dkim_dns_init() (libunbound, libnettle, ...?)
Package: opendkim Version: 2.11.0~beta2-6 Severity: important X-Debbugs-Cc: robert.siemer-report...@backsla.sh Opendkim does not run. # opendkim -f [1642532480] libunbound[837:0] error: nettle random(yarrow) cannot initialize, getentropy failed: Function not implemented opendkim: can't configure DKIM library: failed to initialize resolver I even recompiled from source deb, both opendkim and libunbound. An ltrace showed that dkim_dns_init() fails with -1, and that one calls ub_ctx_create() which returns 0 but provokes the first line to be printed. The second line is the reason printed when dkim_dns_init() fails. # opendkim -n # Fyi: this works, but -n only checks the config file. -- System Information: Debian Release: bookworm/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'unstable') Architecture: i386 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages opendkim depends on: ii adduser 3.118 ii dns-root-data2021011101 ii init-system-helpers 1.61 ii libbsd0 0.11.3-1 ii libc62.33-2 ii libdb5.3 5.3.28+dfsg1-0.8 ii libldap-2.4-22.4.59+dfsg-1 ii liblua5.3-0 5.3.6-1 ii libmemcached11 1.0.18-4.2 ii libmilter1.0.1 8.16.1-2 ii libopendbx1 1.4.6-16 ii libopendkim112.11.0~beta2-6 ii librbl1 2.11.0~beta2-6 ii libssl1.11.1.1m-1 ii libunbound8 1.13.1-1 ii libvbr2 2.11.0~beta2-6 ii lsb-base 11.1.0 Versions of packages opendkim recommends: ii opendkim-tools 2.11.0~beta2-6 opendkim suggests no packages. -- Configuration Files: /etc/dkimkeys/README.PrivateKeys [Errno 13] Permission denied: '/etc/dkimkeys/README.PrivateKeys' /etc/opendkim.conf changed: Syslog yes SyslogSuccess yes Canonicalizationrelaxed/simple OversignHeaders From SigningTablecsl:*=submission KeyTable csl:submission=backsla.sh:submission:/etc/dkimkeys/submission.private UserID opendkim UMask 007 Socket local:/var/spool/postfix/opendkim/opendkim.sock PidFile /run/opendkim/opendkim.pid TrustAnchorFile /usr/share/dns/root.key -- no debconf information
Bug#1003383: systemd-cryptenroll: TPM2 not supported on this build.
Package: systemd Version: 249.7-1 Severity: important X-Debbugs-Cc: m...@gmx.at -- Package-specific info: -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-2-amd64 (SMP w/16 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages systemd depends on: ii adduser 3.118 ii libacl1 2.3.1-1 ii libapparmor1 3.0.3-6 ii libaudit11:3.0.6-1+b1 ii libblkid12.37.2-5 ii libc62.33-1 ii libcap2 1:2.44-1 ii libcrypt11:4.4.27-1 ii libcryptsetup12 2:2.4.2-1 ii libgcrypt20 1.9.4-5 ii libgnutls30 3.7.2-5 ii libgpg-error01.43-1 ii libip4tc21.8.7-1 ii libkmod2 29-1 ii liblz4-1 1.9.3-2 ii liblzma5 5.2.5-2 ii libmount12.37.2-5 ii libpam0g 1.4.0-11 ii libseccomp2 2.5.3-2 ii libselinux1 3.3-1+b1 ii libsystemd0 249.7-1 ii libzstd1 1.4.8+dfsg-3 ii mount2.37.2-5 ii util-linux 2.37.2-5 Versions of packages systemd recommends: ii dbus [default-dbus-system-bus] 1.12.20-3 ii systemd-timesyncd [time-daemon] 249.7-1 Versions of packages systemd suggests: ii policykit-10.105-31 pn systemd-container Versions of packages systemd is related to: pn dracut ii initramfs-tools 0.140 ii libnss-systemd 249.7-1 ii libpam-systemd 249.7-1 ii udev 249.7-1 -- no debconf information
Bug#1003195: enlightenment: E crashes after coming back from a different VTY
On Thu, 06 Jan 2022 22:26:53 -0800, Ross Vandegrift writes:
>On Thu, Jan 06, 2022 at 12:32:44AM +0100, Robert Waldner wrote:
>> F'rex, switching to VTY1 (text console) works as expected, but after
>> switching back to Enlightenment on VTY7 E crashes.
>> Same after switching back to VTY7 from VTY8 (where a different user runs
>> XFCE4).
>Switching to a different vty and back works fine for me, but I don't have
>another desktop session running anywhere. Does the issue still happen if you
>only have one session running?
Good point: yes, it does.
>> Backtrace log / ~/.e-crashdump.txt from when I get the back screen/red
>> writing situation:
>It looks like you're missing the debug symbols. Please follow the instructions
>at https://wiki.debian.org/HowToGetABacktrace and try again.
I've installed enlightenment-dbgsym, but can't get Enlightenment
started via gdb:
--
$ gdb -batch -n -ex 'set pagination off' -ex run -ex bt -ex 'bt full' -ex 'threa
d apply all bt full' --args /usr/bin/startx /usr/bin/enlightenment_start
"0x7ffc0cb4c140s": not in executable format: file format not recognized
No executable file specified.
Use the "file" or "exec-file" command.
No stack.
No stack.
--
~/.e-crashdump.txt (attached) looks filled with a bit more info, though.
I've then started E normally via lightdm, and attached to the (or
rather "a", there's a couple) running
/usr/bin/enlightenment process with gdb as per
https://wiki.debian.org/XStrikeForce/XserverDebugging and did a
backtrace there, gdb.txt is also attached.
Hope that helps.
Thanks for taking an interest!
Kind regards,
Robert
Continuing.
Thread 1 "enlightenment" received signal SIGINT, Interrupt.
0x7ffaf92af872 in __libc_pause () at ../sysdeps/unix/sysv/linux/pause.c:29
29 in ../sysdeps/unix/sysv/linux/pause.c
#0 0x7ffaf92af872 in __libc_pause () at
../sysdeps/unix/sysv/linux/pause.c:29
resultvar = 18446744073709551102
sc_cancel_oldtype = 0
#1 0x7ffaf92b0140 in () at
/lib/x86_64-linux-gnu/libpthread.so.0
#2 0x55a77f727280 in ()
#3 0x7ffaeddff3b6 in () at
/lib/x86_64-linux-gnu/libnvidia-eglcore.so.495.44
#4 0x7ffaeddf1d1d in () at
/lib/x86_64-linux-gnu/libnvidia-eglcore.so.495.44
#5 0x7ffaeddf2399 in () at
/lib/x86_64-linux-gnu/libnvidia-eglcore.so.495.44
#6 0x7ffaeddc9098 in () at
/lib/x86_64-linux-gnu/libnvidia-eglcore.so.495.44
#7 0x7ffaeddcb4a0 in () at
/lib/x86_64-linux-gnu/libnvidia-eglcore.so.495.44
#8 0x7ffaedd30bc5 in () at
/lib/x86_64-linux-gnu/libnvidia-eglcore.so.495.44
#9 0x7ffaef55b688 in () at /lib/x86_64-linux-gnu/libEGL_nvidia.so.0
#10 0x7ffaef4ff59f in () at /lib/x86_64-linux-gnu/libEGL_nvidia.so.0
#11 0x7ffaf4324bbb in eglReleaseThread () at
/lib/x86_64-linux-gnu/libEGL.so.1
#12 0x7ffaf4375cb3 in () at
/usr/lib/x86_64-linux-gnu/evas/modules/engines/gl_x11/v-1.25/module.so
#13 0x7ffaf437320f in () at
/usr/lib/x86_64-linux-gnu/evas/modules/engines/gl_x11/v-1.25/module.so
#14 0x7ffaf9c928c8 in efl_canvas_output_del () at
/lib/x86_64-linux-gnu/libevas.so.1
#15 0x7ffaf9bfb305 in () at /lib/x86_64-linux-gnu/libevas.so.1
#16 0x7ffaf9f75d6a in efl_destructor () at /lib/x86_64-linux-gnu/libeo.so.1
#17 0x7ffaf9f7f054 in efl_del () at /lib/x86_64-linux-gnu/libeo.so.1
#18 0x7ffaf95231f2 in _ecore_evas_free () at
/lib/x86_64-linux-gnu/libecore_evas.so.1
#19 0x55a77d250146 in _e_comp_free (c=0x55a77f254d70) at
../src/bin/e_comp.c:847
#20 0x55a77d2f3e58 in e_object_unref (obj=0x55a77f254d70) at
../src/bin/e_object.c:153
ref = 0
__func__ = "e_object_unref"
#21 0x55a77d2f3f4d in e_object_del (obj=) at
../src/bin/e_object.c:60
__func__ = "e_object_del"
#22 0x55a77d2538f4 in e_comp_shutdown () at ../src/bin/e_comp.c:1434
l =
ll =
ec =
#23 0x55a77d2e66c8 in _e_main_screens_shutdown () at
../src/bin/e_main.c:1585
#24 0x55a77d2e6ccb in _e_main_shutdown (errcode=errcode@entry=0) at
../src/bin/e_main.c:1157
i =
#25 0x55a77d226921 in main (argc=, argv=) at
../src/bin/e_main.c:1119
waslocked = 0 '\000'
strshare =
s =
action =
{__sigaction_handler = {sa_handler = 0x55a77d30cda0 ,
sa_sigaction = 0x55a77d30cda0 }, sa_mask = {__val = {0 }}, sa_flags = -1073741820, sa_restorer = 0x0}
__func__ = "main"
Thread 4 (Thread 0x7f2f49165700 (LWP 2598539) "Eanimator-timer"):
#0 0x7f2f4df9e116 in epoll_wait (epfd=48, events=0x7f2f49164760,
maxevents=2, timeout=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
#1 0x7f2f4eca071b in () at /lib/x86_64-linux-gnu/libecore.so.1
#2 0x7f2f4ece4cc1 in () at /lib/x86_64-linux-gnu/libecore.so.1
#3 0x7f2f4ede1e0a in () at /lib/x86_
Bug#1003195: enlightenment: E crashes after coming back from a different VTY
Package: enlightenment Version: 0.24.2-8 Severity: normal Dear Maintainer, after upgrading from Debian 10 to 11.2, I can no longer seamlessly switch to different VTYs/Window Managers and then back to Enlightenment. F'rex, switching to VTY1 (text console) works as expected, but after switching back to Enlightenment on VTY7 E crashes. Same after switching back to VTY7 from VTY8 (where a different user runs XFCE4). _Most_ of the time I get a black screen with red writing, citing "Guru meditation #02248813.0011", and can recover my Enlightenment session (and open programs) via pressing F1. At other times I get a non-responsive screen where I can see the title bars of all windows but clicking anywhere with the mouse is non-responsive - this I can usually recover via restarting Enlightenment (which I've bound to ctrl-alt-x for this purpose), but sometines all I can do is kill all Enlightenment processes from, say, VTY1 and logging in again from lightdm. Backtrace log / ~/.e-crashdump.txt from when I get the back screen/red writing situation: --- Thread 1 (Thread 0x7f287f74e740 (LWP 5319)): #0 0x7f287d1c6b8d in pause () at ../sysdeps/unix/syscall-template.S:81 No locals. #1 No locals. #2 0x7f286afbed2b in ?? () from /usr/lib/enlightenment/modules/comp/linux-gnu-x86_64-0.17.3/module.so No symbol table info available. #3 0x7f286afbef4b in ?? () from /usr/lib/enlightenment/modules/comp/linux-gnu-x86_64-0.17.3/module.so No symbol table info available. #4 0x7f287f031657 in ?? () from /usr/lib/x86_64-linux-gnu/libecore.so.1 No symbol table info available. #5 0x7f287f0359d9 in ?? () from /usr/lib/x86_64-linux-gnu/libecore.so.1 No symbol table info available. #6 0x7f287f035f17 in ecore_main_loop_begin () from /usr/lib/x86_64-linux-gnu/libecore.so.1 No symbol table info available. #7 0x00434ac0 in main () No symbol table info available. Detaching from program: /usr/bin/enlightenment, process 5319 --- VTY-switching in this manner has worked well for me for over a decade now, and I'm a bit stumped on as to how to debug this. Thanks for any pointers. Kind regards, Robert -- System Information: Debian Release: 11.2 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'testing'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.14.0-0.bpo.2-amd64 (SMP w/16 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages enlightenment depends on: ii dbus-user-session [default-dbus-session-bus] 1.12.20-2 ii dbus-x11 [dbus-session-bus] 1.12.20-2 ii enlightenment-data0.24.2-8 ii libasound21.2.4-1.1 ii libbluetooth3 5.55-3.1 ii libc6 2.31-13+deb11u2 ii libecore-con1 1.25.1-1 ii libecore-drm2-1 1.25.1-1 ii libecore-evas11.25.1-1 ii libecore-file11.25.1-1 ii libecore-input1 1.25.1-1 ii libecore-ipc1 1.25.1-1 ii libecore-wl2-11.25.1-1 ii libecore-x1 1.25.1-1 ii libecore1 1.25.1-1 ii libedje-bin 1.25.1-1 ii libedje1 1.25.1-1 ii libeet1 1.25.1-1 ii libeeze1 1.25.1-1 ii libefreet-bin 1.25.1-1 ii libefreet1a 1.25.1-1 ii libeina1a 1.25.1-1 ii libeio1 1.25.1-1 ii libelementary11.25.1-1 ii libelput1 1.25.1-1 ii libemile1 1.25.1-1 ii libemotion1 1.25.1-1 ii libevas1 1.25.1-1 ii libevas1-engines-drm 1.25.1-1 ii libevas1-engines-wayland 1.25.1-1 ii libevas1-engines-x1.25.1-1 ii libpam0g 1.4.0-9+deb11u1 ii libpulse0 14.2-2 ii libuuid1 2.36.1-8 ii libwayland-client01.18.0-2~exp1.1 ii libwayland-server01.18.0-2~exp1.1 ii lib
Bug#1002838: pdfarranger: Error "Can't convert ObjectHelper" when saving
This is fixed in pdfarranger 1.8.2 by https://github.com/pdfarranger/pdfarranger/commit/de8acb310e23cacd8409bd895f9cfbd64af9bf23
Bug#1002640: bind9 won't start after upgrading from 9.11 - "the working directory is not writable"
On Sun, 26 Dec 2021 10:47:42 -0500, Simon Deziel writes: >What's in /etc/default/named? Chroot'ing could cause some issues. This is stock, AFAICT: --- # # run resolvconf? RESOLVCONF=no # startup options for the server OPTIONS="-u bind" --- >Since you are hitting permission issues, I'd also check dmesg for >AppArmor denial messages (`dmesg | grep apparmor`). At least there's nothing (to me) obvious: root@fsckv2:~# dmesg | grep apparmor [6.889374] audit: type=1400 audit(1640488235.484:2): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libreoffice-senddoc" pid=900 comm="apparmor_parser" [6.889470] audit: type=1400 audit(1640488235.484:3): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libreoffice-xpdfimport" pid=901 comm="apparmor_parser" [6.889533] audit: type=1400 audit(1640488235.484:4): apparmor="STATUS" operation="profile_load" profile="unconfined" name="lsb_release" pid=889 comm="apparmor_parser" [6.889746] audit: type=1400 audit(1640488235.484:5): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libreoffice-oopslash" pid=896 comm="apparmor_parser" [6.889794] audit: type=1400 audit(1640488235.484:6): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=894 comm="apparmor_parser" [6.889797] audit: type=1400 audit(1640488235.484:7): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" pid=894 comm="apparmor_parser" [6.890474] audit: type=1400 audit(1640488235.484:8): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=891 comm="apparmor_parser" [6.890477] audit: type=1400 audit(1640488235.484:9): apparmor="STATUS" operation="profile_load" profile="unconfined" name="man_filter" pid=891 comm="apparmor_parser" [6.890479] audit: type=1400 audit(1640488235.484:10): apparmor="STATUS" operation="profile_load" profile="unconfined" name="man_groff" pid=891 comm="apparmor_parser" [6.891157] audit: type=1400 audit(1640488235.484:11): apparmor="STATUS" operation="profile_load" profile="unconfined" name="named" pid=899 comm="apparmor_parser" Kind regards, Robert -- -- Acronyms explained: TCPA -- (T)otal (C)ontrol of (P)rivate (A)ssets -- - captainiglo
Bug#1002640: bind9 won't start after upgrading from 9.11 - "the working directory is not writable"
On Sun, 26 Dec 2021 14:20:21 +0100, =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= writes: >Well, what is your working directory and is it writeable by user:group > under which named runs at your system? root@fsckv2:~# grep direct /etc/bind/named.conf.options directory "/etc/bind"; root@fsckv2:~# ls -la /etc/bind/ total 104 drwxrwsr-x 3 root bind 4096 Dec 26 11:35 . root@fsckv2:~# grep OPTIONS /etc/default/named OPTIONS="-u bind" Running named from buster, 1:9.11.5.P4+dfsg-5.1, started normally from systemd: root@fsckv2:~# ps auxwww| grep [n]amed bind 133379 0.0 0.9 1728372 323376 ? Ssl 12:09 0:04 /usr/sbin/named -f -u bind Kind regards, Robert
Bug#1002640: bind9 won't start after upgrading from 9.11 - "the working directory is not writable"
Package: bind9 Version: 1:9.16.22-1~deb11u1 Severity: important Dear Maintainers, I upgraded my nameserver from buster to bullseye, afterwards named wouldn't start anymore. Looking at syslog, the relevant part seems to be: ... Dec 26 11:36:01 fsck named[128029]: configuring command channel from '/etc/bind/rndc.key' Dec 26 11:36:01 fsck named[128029]: command channel listening on 127.0.0.1#953 Dec 26 11:36:01 fsck named[128029]: configuring command channel from '/etc/bind/rndc.key' Dec 26 11:36:01 fsck named[128029]: command channel listening on ::1#953 Dec 26 11:36:01 fsck named[128029]: the working directory is not writable ^ Dec 26 11:36:01 fsck named[128029]: loading configuration: permission denied Dec 26 11:36:01 fsck named[128029]: exiting (due to fatal error) Dec 26 11:36:01 fsck systemd[1]: named.service: Main process exited, code=exited, status=1/FAILURE Dec 26 11:36:01 fsck systemd[1]: named.service: Failed with result 'exit-code'. Note that this is straight from systemd trying to start it. Running named as `named -g -u bind` got the same result (CWD: /home/myuser). But! starting it manually with a CWD that's writable by group bind (eg. `cd /etc/bind; named -g -u bind`) works: ... 26-Dec-2021 11:44:10.434 configuring command channel from '/etc/bind/rndc.key' 26-Dec-2021 11:44:10.434 command channel listening on 127.0.0.1#953 26-Dec-2021 11:44:10.434 configuring command channel from '/etc/bind/rndc.key' 26-Dec-2021 11:44:10.434 command channel listening on ::1#953 26-Dec-2021 11:44:10.434 not using config file logging statement for logging due to -g option 26-Dec-2021 11:44:10.434 zone 10.in-addr.arpa/IN: loaded serial 2002041301 ... Now this wouldn't be a problem is systemd could start named, but it can't: root@fsckv2:/etc/bind# systemctl start named root@fsckv2:/etc/bind# systemctl status named ● named.service - BIND Domain Name Server Loaded: loaded (/lib/systemd/system/named.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Sun 2021-12-26 11:46:23 CET; 1s ago Docs: man:named(8) Process: 130605 ExecStart=/usr/sbin/named -f $OPTIONS (code=exited, status=1/FAILURE) Main PID: 130605 (code=exited, status=1/FAILURE) CPU: 51ms Dec 26 11:46:23 fsckv2 systemd[1]: named.service: Scheduled restart job, restart counter is at 5. Dec 26 11:46:23 fsckv2 systemd[1]: Stopped BIND Domain Name Server. Dec 26 11:46:23 fsckv2 systemd[1]: named.service: Start request repeated too quickly. Dec 26 11:46:23 fsckv2 systemd[1]: named.service: Failed with result 'exit-code'. Dec 26 11:46:23 fsckv2 systemd[1]: Failed to start BIND Domain Name Server. For testing, I also `apt-get -b source`d bind9 from testing/unstable (9.17.21-1) but it exhibits the same non-working bevaviour. (If needed I can provide all config in private mail, but am loathe to disclose them publicly as it's quite extensive (this is a nameserver for quite some domains, plus the resolver for all my internal networks).) Kind regards and grateful for any hints, Robert -- System Information: Debian Release: 11.2 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'testing'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-10-amd64 (SMP w/16 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages bind9 depends on: ii adduser3.118 ii bind9-libs 1:9.16.22-1~deb11u1 ii bind9-utils1:9.16.22-1~deb11u1 ii debconf [debconf-2.0] 1.5.77 ii dns-root-data 2021011101 ii init-system-helpers1.60 ii iproute2 5.10.0-4 ii libc6 2.31-13+deb11u2 ii libcap21:2.44-1 ii libfstrm0 0.6.0-1+b1 ii libjson-c5 0.15-2 ii liblmdb0 0.9.24-1 ii libmaxminddb0 1.5.2-1 ii libprotobuf-c1 1.3.3-1+b2 ii libssl1.1 1.1.1k-1+deb11u1 ii libuv1 1.40.0-2 ii libxml22.9.10+dfsg-6.7 ii lsb-base 11.1.0 ii netbase6.3 ii zlib1g 1:1.2.11.dfsg-2 bind9 recommends no packages. Versions of packages bind9 suggests: pn bind-doc pn dnsutils pn resolvconf pn ufw -- Configuration Files: /etc/bind/named.conf changed [not included] /etc/bind/named.conf.local changed [not included] /etc/bind/named.conf.options changed [not included] -- debconf information: bind9/run-resolvconf: false bind9/start-as-user: bind bind9/different-configuration-file:
Bug#1000339: r-cran-raster breaks r-cran-satellite autopkgtest: unable to find an inherited method for function 'extend'
Andreas, The background of this problem is the change in dependency between "raster" and "terra". "terra" was dependent on "raster"; now it is the other way around. This change was made in terra 1.4-07, 1.4-09 and 1.4-11 that were released between 2021-10-05 and 2021-10-11, and in raster 3.5-2 (2021-10-11). In the attachment I show the behavior of `library(satellite)` with the raster package prior to 2021-10-11, with the current versions, and for possible intermediate steps. It shows that you can get the warnings you see if you have current versions of terra/raster but an old version of satellite. >From what I can tell from this log: https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-satellite/16823806/log.gz you are using satellite_1.0.4 and raster_3.5-2 (current versions), and terra_1.4-11 (the current version is 1.4-22; but 1.4-11 should be OK). Is it possible that your session is actually loading satellite_1.0.2? Hope this helps, Robert On Tue, Nov 30, 2021 at 12:48 AM Andreas Tille wrote: > Control: forwarded -1 Robert J. Hijmans , Florian > Detsch > Control: tags -1 upstream > Control: tags -1 help > > Hi Robert and Florian, > > I'm contacting you as the maintainers or raster and satellite. As you > can see below in the Debian packaged versions of these packages some > conflict was raised in the test of satellite after the latest version of > raster was uploaded. > > I'm perfectly aware that the packages are tested on CRAN and thus I > assume that possibly some special circumstances in the Debian packaged > version might lead to the issue that is reported in the bug below. I > wonder whether you can give some hints how to solve the conflict in the > test (at the very end of this mail). > > Thanks a lot for your help > > Andreas. > > Am Sun, Nov 21, 2021 at 09:24:52PM +0100 schrieb Paul Gevers: > > Source: r-cran-raster, r-cran-satellite > > Control: found -1 r-cran-raster/3.5-2-1 > > Control: found -1 r-cran-satellite/1.0.4-1 > > Severity: serious > > Tags: sid bookworm > > X-Debbugs-CC: debian...@lists.debian.org > > User: debian...@lists.debian.org > > Usertags: breaks needs-update > > > > Dear maintainer(s), > > > > With a recent upload of r-cran-raster the autopkgtest of r-cran-satellite > > fails in testing when that autopkgtest is run with the binary packages of > > r-cran-raster from unstable. It passes when run with only packages from > > testing. In tabular form: > > > >passfail > > r-cran-raster from testing3.5-2-1 > > r-cran-satellite from testing1.0.4-1 > > all others from testingfrom testing > > > > I copied some of the output at the bottom of this report. > > > > Currently this regression is blocking the migration of r-cran-raster to > > testing [1]. Due to the nature of this issue, I filed this bug report > > against both packages. Can you please investigate the situation and > reassign > > the bug to the right package? > > > > More information about this bug and the reason for filing it can be > found on > > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation > > > > Paul > > > > [1] https://qa.debian.org/excuses.php?package=r-cran-raster > > > > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-satellite/16823806/log.gz > > > > BEGIN TEST testthat.R > > > > R version 4.1.2 (2021-11-01) -- "Bird Hippie" > > Copyright (C) 2021 The R Foundation for Statistical Computing > > Platform: x86_64-pc-linux-gnu (64-bit) > > > > R is free software and comes with ABSOLUTELY NO WARRANTY. > > You are welcome to redistribute it under certain conditions. > > Type 'license()' or 'licence()' for distribution details. > > > > R is a collaborative project with many contributors. > > Type 'contributors()' for more information and > > 'citation()' on how to cite R or R packages in publications. > > > > Type 'demo()' for some demos, 'help()' for on-line help, or > > 'help.start()' for an HTML browser interface to help. > > Type 'q()' to quit R. > > > > > library(testthat) > > > library(satellite) > > Loading required package: raster > > Loading required package: sp > > code for methods in class "Rcpp_SpatCategories" was not checked for > > suspicious field assignments (recommended package 'codetools' not > > available?) > > code for methods in class "Rcpp_SpatCategories" was not checked for > > suspicious field assignments (recomm
Bug#1000339: r-cran-raster breaks r-cran-satellite autopkgtest: unable to find an inherited method for function 'extend'
On Tue, Nov 30, 2021 at 10:46 PM Andreas Tille wrote: > Dear Robert, > > Am Tue, Nov 30, 2021 at 09:18:18PM -0800 schrieb Robert J. Hijmans: > > Dear Andreas, > > > > raster 3-5.2 depends on terra; but it does not specify which version of > > terra. I believe it needs to be terra 1.4-11 to not get this error. > > Is it *exactly* this version or >= 1.4-11? We had once packaged terra > just for raster startung with 1.4-11 and than moved on upgrading it to > the current version 1.4-22. > Sorry about being not very precise, I should have said >= 1.4-11 1.4-22 is even better I now wonder whether it is the order of installation. Can you install raster *after* installing terra? That might help in getting the namespaces work as they should. If not, I will try to make some dockers to see if I can reproduce this. > > From what you sent I cannot see which version of terra is installed, but > I > > am guessing it is an earlier version. Is that something you can check? > > There was never any earlier version than 1.4-11 in Debian. The Debian > bug report links to a full log of the test[1] which installs > > ... > Get:117 http://deb.debian.org/debian testing/main amd64 r-cran-terra > amd64 1.4-11-2 [2,358 kB] > Get:118 http://deb.debian.org/debian unstable/main amd64 r-cran-raster > amd64 3.5-2-1 [3,063 kB] > ... > > > I can dig a bit more if needed, please let me know. > > Your help would be really appreciated > > Andreas. > > > [1] > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-satellite/16823806/log.gz > > -- > http://fam-tille.de >
Bug#1000339: r-cran-raster breaks r-cran-satellite autopkgtest: unable to find an inherited method for function 'extend'
Dear Andreas, raster 3-5.2 depends on terra; but it does not specify which version of terra. I believe it needs to be terra 1.4-11 to not get this error. >From what you sent I cannot see which version of terra is installed, but I am guessing it is an earlier version. Is that something you can check? I can dig a bit more if needed, please let me know. Robert On Tue, Nov 30, 2021 at 12:48 AM Andreas Tille wrote: > Control: forwarded -1 Robert J. Hijmans , Florian > Detsch > Control: tags -1 upstream > Control: tags -1 help > > Hi Robert and Florian, > > I'm contacting you as the maintainers or raster and satellite. As you > can see below in the Debian packaged versions of these packages some > conflict was raised in the test of satellite after the latest version of > raster was uploaded. > > I'm perfectly aware that the packages are tested on CRAN and thus I > assume that possibly some special circumstances in the Debian packaged > version might lead to the issue that is reported in the bug below. I > wonder whether you can give some hints how to solve the conflict in the > test (at the very end of this mail). > > Thanks a lot for your help > > Andreas. > > Am Sun, Nov 21, 2021 at 09:24:52PM +0100 schrieb Paul Gevers: > > Source: r-cran-raster, r-cran-satellite > > Control: found -1 r-cran-raster/3.5-2-1 > > Control: found -1 r-cran-satellite/1.0.4-1 > > Severity: serious > > Tags: sid bookworm > > X-Debbugs-CC: debian...@lists.debian.org > > User: debian...@lists.debian.org > > Usertags: breaks needs-update > > > > Dear maintainer(s), > > > > With a recent upload of r-cran-raster the autopkgtest of r-cran-satellite > > fails in testing when that autopkgtest is run with the binary packages of > > r-cran-raster from unstable. It passes when run with only packages from > > testing. In tabular form: > > > >passfail > > r-cran-raster from testing3.5-2-1 > > r-cran-satellite from testing1.0.4-1 > > all others from testingfrom testing > > > > I copied some of the output at the bottom of this report. > > > > Currently this regression is blocking the migration of r-cran-raster to > > testing [1]. Due to the nature of this issue, I filed this bug report > > against both packages. Can you please investigate the situation and > reassign > > the bug to the right package? > > > > More information about this bug and the reason for filing it can be > found on > > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation > > > > Paul > > > > [1] https://qa.debian.org/excuses.php?package=r-cran-raster > > > > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-satellite/16823806/log.gz > > > > BEGIN TEST testthat.R > > > > R version 4.1.2 (2021-11-01) -- "Bird Hippie" > > Copyright (C) 2021 The R Foundation for Statistical Computing > > Platform: x86_64-pc-linux-gnu (64-bit) > > > > R is free software and comes with ABSOLUTELY NO WARRANTY. > > You are welcome to redistribute it under certain conditions. > > Type 'license()' or 'licence()' for distribution details. > > > > R is a collaborative project with many contributors. > > Type 'contributors()' for more information and > > 'citation()' on how to cite R or R packages in publications. > > > > Type 'demo()' for some demos, 'help()' for on-line help, or > > 'help.start()' for an HTML browser interface to help. > > Type 'q()' to quit R. > > > > > library(testthat) > > > library(satellite) > > Loading required package: raster > > Loading required package: sp > > code for methods in class "Rcpp_SpatCategories" was not checked for > > suspicious field assignments (recommended package 'codetools' not > > available?) > > code for methods in class "Rcpp_SpatCategories" was not checked for > > suspicious field assignments (recommended package 'codetools' not > > available?) > > code for methods in class "Rcpp_SpatDataFrame" was not checked for > > suspicious field assignments (recommended package 'codetools' not > > available?) > > code for methods in class "Rcpp_SpatDataFrame" was not checked for > > suspicious field assignments (recommended package 'codetools' not > > available?) > > code for methods in class "Rcpp_SpatExtent" was not checked for > suspicious > > field assignments (recommended package 'codetools' not available?) > > code for methods in class "Rcpp_SpatExt
Bug#997194: mtr: FTBFS: ../ui/curses.c:435:17: error: format not a string literal and no format arguments [-Werror=format-security]
On 10/24/21 4:36 AM, Rogier Wolff wrote: > > I think this is perfectly legal C code and your compiler doesn't like > it. It doesn't just warn, but gives an error. > > Roger. Rogier, that is a 100% true statement, but Debian (and most other distributions) have started using the -Werror=format-security build flag for everything everywhere because leaving all of these calls as-is means, in certain cases, leaving vulnerabilities in. Sure, you can prove that mtr's code introduces no such vulnerabilities because none of the format specs are user-supplied, but it's probably not reasonable to expect that that would be a one-time effort, whereas changing the code would be.
