Bug#963526: DDPO: Watch column is empty
Package: qa.debian.org Severity: important Hello, it's been a few days that the Watch column on any DDPO page is empty; since i consider an important aspect of the DDPO info set, i marked the prio as important. Could you please look into what's broken and restore the version information in DDPO? Thanks, Sandro -- System Information: Debian Release: 10.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#963525: steam-launcher: Steam crashes after dist-upgrade, possibly due to graphics drivers
package: steam-launcher version: 1:1.0.0.62 Dear Maintainer, It seems to have broken after updating the mesa drivers. Steam will launch and try to install, "libgl1-mesa-dri:i386" and "libgl1:1386". I have enabled support for 32 bit packages multiple times. It then says the package "libgl1-mesa-dri:i386" is replaced by "libgl1-mesa-dri". Lastly it says neither of them have an installation candidate. I press "Enter" and it says the following 32-bit libraries are missing "libGL.so.1" and "libdrm.so.2". Steam is currently completely broken and fails to start. It also says my arch is foreign. Transcript: $ steam /home/ohare-air/.local/share/Steam/steam.sh: line 114: VERSION_ID: unbound variable Package libgl1-mesa-dri:i386 needs to be installed Package libgl1:i386 needs to be installed /home/ohare-air/.local/share/Steam/steam.sh: line 114: VERSION_ID: unbound variable Running Steam on debian 64-bit /home/ohare-air/.local/share/Steam/steam.sh: line 114: VERSION_ID: unbound variable STEAM_RUNTIME is enabled automatically Pins up-to-date! Error: You are missing the following 32-bit libraries, and Steam may not run: libGL.so.1 libdrm.so.2 Steam client's requirements are satisfied /home/ohare-air/.local/share/Steam/ubuntu12_32/steam [2020-06-22 20:17:47] Startup - updater built Jun 4 2020 05:50:42 Installing breakpad exception handler for appid(steam)/version(1591251555) Looks like steam didn't shutdown cleanly, scheduling immediate update check Installing breakpad exception handler for appid(steam)/version(1591251555) [2020-06-22 20:17:47] Checking for update on startup [2020-06-22 20:17:47] Checking for available updates... [2020-06-22 20:17:47] Downloading manifest: client-download.steampowered.com/client/steam_client_ubuntu12 Installing breakpad exception handler for appid(steam)/version(1591251555) [2020-06-22 20:17:48] Download skipped: /client/steam_client_ubuntu12 version 1591251555, installed version 1591251555 [2020-06-22 20:17:48] Nothing to do [2020-06-22 20:17:48] Verifying installation... [2020-06-22 20:17:48] Performing checksum verification of executable files [2020-06-22 20:17:49] Verification complete Failed to load steamui.so - dlerror(): libGL.so.1: wrong ELF class: ELFCLASS64 [2020-06-22 20:17:49] Shutdown Installing breakpad exception handler for appid(steam)/version(1591251555) Installing breakpad exception handler for appid(steam)/version(1591251555) Kernel version: 5.6.0-2-amd64 AMD Ryzen 7 1700x AMD Radeon RX 580 firmware-amd-gaphics installed non-free, contrib enabled
Bug#963524: debian-policy: Binary and Description fields not mandatory in .changes on source-only uploads
Control: reassign -1 debian-policy Control: retitle -1 debian-policy: Binary and Description fields not mandatory in .changes on source-only uploads On Mon, 2020-06-22 at 18:51:21 -0700, Felix Lechner wrote: > Package: dpkg > Severity: normal > X-Debbugs-CC: debian-lint-ma...@lists.debian.org > Starting with an upcoming release, Lintian will check for the presence > of required and recommended fields in various packaging control files. > Our methods are probably not perfect, but it was brought to my > attention that 'dpkg-buildpackage -S' produces *.changes files without > 'Binary' and 'Description' fields. This is due to a fix in dpkg 1.19.3 prompted by #818618, which brought up an inconsistency in the handling of these fields (commit 4a4619831de8b8972f86b489660dc98f187cfa34 in dpkg.git). DAK got also fixed to accept these .changes files. > Policy 5.5 states that both fields are mandatory. [1] > > [1] > https://www.debian.org/doc/debian-policy/ch-controlfields.html#debian-changes-files-changes > > You may be able to find details about an example (by building Lintian) > at the link below. > > https://salsa.debian.org/lintian/lintian/-/commit/54a3c2437eadb0684f6762a81a82163f36562d3e#note_176583 > > Please note that I filed this bug with normal severity, even though as > a policy violation, it should be serious. I did so because I believe > the policy is at least partially in error (with respect to the > 'Binary' field). The deb-changes(5) and policy state that these fields contain information for binary packages being uploaded. On a source-only upload, there are no such binaries, so the definition was internally inconsistent. I think the only thing missing is policy clarifying that this field is only mandatory on non-source-only uploads. Regards, Guillem
Bug#963524: dpkg: source-only *.changes files lack two mandatory fields
Package: dpkg Severity: normal X-Debbugs-CC: debian-lint-ma...@lists.debian.org Hi Guillem, Starting with an upcoming release, Lintian will check for the presence of required and recommended fields in various packaging control files. Our methods are probably not perfect, but it was brought to my attention that 'dpkg-buildpackage -S' produces *.changes files without 'Binary' and 'Description' fields. Policy 5.5 states that both fields are mandatory. [1] [1] https://www.debian.org/doc/debian-policy/ch-controlfields.html#debian-changes-files-changes You may be able to find details about an example (by building Lintian) at the link below. https://salsa.debian.org/lintian/lintian/-/commit/54a3c2437eadb0684f6762a81a82163f36562d3e#note_176583 Please note that I filed this bug with normal severity, even though as a policy violation, it should be serious. I did so because I believe the policy is at least partially in error (with respect to the 'Binary' field). This issue may be loosely related to your pending Bug#956321 but is clearly a different issue. Thank you for your hard work on dpkg and friends. Kind regards Felix Lechner
Bug#859926: Hello dear
*Dear,I hope my email finds you in good health.Finally, i made it to success with another partner after you couldn't complete the transaction with me. But i did not forget your effort then, it was part of my success still. So i left a bank cheque with the Catholic Reverend sister whom i told you about sometime ago as my trusted Secretary.Contact her at this below email immediately, introduce yourself as the cashier cheque recipient and demand for your cheque release process.Send email to: Reverend sister Angela HelpeEmail:helperange...@gmail.com Tel: +228 98766629*
Bug#963523: apt: show held packages status with 'apt list --upgradable' command
Package: apt Version: 1.8.2.1 Severity: wishlist Tags: upstream Dear Maintainers, Sometimes I hold some packages from being automatically upgraded using 'apt-mark hold ' command; but when I run 'apt list --upgradable' command, there is no way to know which package has been held. Indeed, I can know list of held package by running 'apt-mark showhold' command. But isn't it would be nice if these information will also be available with 'apt list --upgradable' command as meta information along with package? May be just adding meta tag along with package would be enough. $ sudo apt-mark hold riot-desktop riot-desktop set on hold. ## Actual output of apt list command. $ apt list --upgradable Listing... Done libvlc-bin/stable,stable 3.0.11-0+deb10u1 amd64 [upgradable from: 3.0.10-0+deb10u1] libvlc5/stable,stable 3.0.11-0+deb10u1 amd64 [upgradable from: 3.0.10-0+deb10u1] libvlccore9/stable,stable 3.0.11-0+deb10u1 amd64 [upgradable from: 3.0.10-0+deb10u1] riot-desktop/unknown 1.6.5 amd64 [upgradable from: 1.6.4] vlc-bin/stable,stable 3.0.11-0+deb10u1 amd64 [upgradable from: 3.0.10-0+deb10u1] vlc-data/stable,stable 3.0.11-0+deb10u1 all [upgradable from: 3.0.10-0+deb10u1] vlc-l10n/stable,stable 3.0.11-0+deb10u1 all [upgradable from: 3.0.10-0+deb10u1] vlc-plugin-base/stable,stable 3.0.11-0+deb10u1 amd64 [upgradable from: 3.0.10-0+deb10u1] vlc-plugin-notify/stable,stable 3.0.11-0+deb10u1 amd64 [upgradable from: 3.0.10-0+deb10u1] vlc-plugin-qt/stable,stable 3.0.11-0+deb10u1 amd64 [upgradable from: 3.0.10-0+deb10u1] vlc-plugin-samba/stable,stable 3.0.11-0+deb10u1 amd64 [upgradable from: 3.0.10-0+deb10u1] vlc-plugin-skins2/stable,stable 3.0.11-0+deb10u1 amd64 [upgradable from: 3.0.10-0+deb10u1] vlc-plugin-video-output/stable,stable 3.0.11-0+deb10u1 amd64 [upgradable from: 3.0.10-0+deb10u1] vlc-plugin-video-splitter/stable,stable 3.0.11-0+deb10u1 amd64 [upgradable from: 3.0.10-0+deb10u1] vlc-plugin-visualization/stable,stable 3.0.11-0+deb10u1 amd64 [upgradable from: 3.0.10-0+deb10u1] vlc/stable,stable 3.0.11-0+deb10u1 amd64 [upgradable from: 3.0.10-0+deb10u1] ## Instead, we can add a little meta tag along with riot-desktop package, or something similar. $ apt list --upgradable Listing... Done libvlc-bin/stable,stable 3.0.11-0+deb10u1 amd64 [upgradable from: 3.0.10-0+deb10u1] libvlc5/stable,stable 3.0.11-0+deb10u1 amd64 [upgradable from: 3.0.10-0+deb10u1] libvlccore9/stable,stable 3.0.11-0+deb10u1 amd64 [upgradable from: 3.0.10-0+deb10u1] riot-desktop/unknown 1.6.5 amd64 [upgradable from: 1.6.4] [hold] vlc-bin/stable,stable 3.0.11-0+deb10u1 amd64 [upgradable from: 3.0.10-0+deb10u1] vlc-data/stable,stable 3.0.11-0+deb10u1 all [upgradable from: 3.0.10-0+deb10u1] vlc-l10n/stable,stable 3.0.11-0+deb10u1 all [upgradable from: 3.0.10-0+deb10u1] vlc-plugin-base/stable,stable 3.0.11-0+deb10u1 amd64 [upgradable from: 3.0.10-0+deb10u1] vlc-plugin-notify/stable,stable 3.0.11-0+deb10u1 amd64 [upgradable from: 3.0.10-0+deb10u1] vlc-plugin-qt/stable,stable 3.0.11-0+deb10u1 amd64 [upgradable from: 3.0.10-0+deb10u1] vlc-plugin-samba/stable,stable 3.0.11-0+deb10u1 amd64 [upgradable from: 3.0.10-0+deb10u1] vlc-plugin-skins2/stable,stable 3.0.11-0+deb10u1 amd64 [upgradable from: 3.0.10-0+deb10u1] vlc-plugin-video-output/stable,stable 3.0.11-0+deb10u1 amd64 [upgradable from: 3.0.10-0+deb10u1] vlc-plugin-video-splitter/stable,stable 3.0.11-0+deb10u1 amd64 [upgradable from: 3.0.10-0+deb10u1] vlc-plugin-visualization/stable,stable 3.0.11-0+deb10u1 amd64 [upgradable from: 3.0.10-0+deb10u1] vlc/stable,stable 3.0.11-0+deb10u1 amd64 [upgradable from: 3.0.10-0+deb10u1] Cheers, Vipul
Bug#859926: Hello dear
*Dear,I hope my email finds you in good health.Finally, i made it to success with another partner after you couldn't complete the transaction with me. But i did not forget your effort then, it was part of my success still. So i left a bank cheque with the Catholic Reverend sister whom i told you about sometime ago as my trusted Secretary.Contact her at this below email immediately, introduce yourself as the cashier cheque recipient and demand for your cheque release process.Send email to: Reverend sister Angela HelpeEmail:helperange...@gmail.com Tel: +228 98766629*
Bug#859926: Hello dear
*Dear,I hope my email finds you in good health.Finally, i made it to success with another partner after you couldn't complete the transaction with me. But i did not forget your effort then, it was part of my success still. So i left a bank cheque with the Catholic Reverend sister whom i told you about sometime ago as my trusted Secretary.Contact her at this below email immediately, introduce yourself as the cashier cheque recipient and demand for your cheque release process.Send email to: Reverend sister Angela HelpeEmail:helperange...@gmail.com Tel: +228 98766629*
Bug#859926: Hello dear
*Dear,I hope my email finds you in good health.Finally, i made it to success with another partner after you couldn't complete the transaction with me. But i did not forget your effort then, it was part of my success still. So i left a bank cheque with the Catholic Reverend sister whom i told you about sometime ago as my trusted Secretary.Contact her at this below email immediately, introduce yourself as the cashier cheque recipient and demand for your cheque release process.Send email to: Reverend sister Angela HelpeEmail:helperange...@gmail.com Tel: +228 98766629*
Bug#963522: WebKitWebProcess: random crash (SIGSEGV)
Package: libwebkit2gtk-4.0-37 Version: 2.28.2-2+b1 Severity: normal File: /usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/WebKitWebProcess Usertags: crash I got a random crash (SIGSEGV) in WebKitWebProcess. I've included the gdb backtrace and some possibly related syslog messages below. I don't know how to reproduce the crash. I'm not entirely sure but I think it was from liferea. It could also have been from evolution or gnome-ring. If more data from the below core file is needed, it will be available until it is automatically deleted in one week's time. If this bug report isn't useful, please close it. Jun 22 21:40:26 kernel: Code: 00 0f 84 cf 0d 00 00 49 8d 7e 08 e8 b6 4c 1c 01 48 8d 35 ef d1 a1 01 48 89 c7 e8 a7 31 94 ff 48 8b 6b 38 0f b6 c0 89 44 24 14 <48> 8b 45 00 48 8b 40 10 48 89 44 24 08 49 8b 46 08 48 89 44 24 30 Jun 22 21:40:26 kernel: WebKitWebProces[4176684]: segfault at 0 ip 7f2c105a6654 sp 7ffddbb32310 error 4 in libwebkit2gtk-4.0.so.37.44.4[7f2c0f8ea000+3008000] Jun 22 21:38:39 WebKitWebProces[4176684]: WebKit wasn't able to find the GL video sink dependencies. Hardware-accelerated zero-copy video rendering can't be enabled without this plugin. Jun 22 21:38:39 WebKitWebProces[4176684]: WebKit wasn't able to find the GL video sink dependencies. Hardware-accelerated zero-copy video rendering can't be enabled without this plugin. $ gdb -batch -n -ex 'set pagination off' -ex bt -ex 'bt full' -ex 'thread apply all bt full' --core /var/crash/1000/4176684-1000-1000-11-1592833226-chianamo--usr-lib-x86_64-linux-gnu-webkit2gtk-4.0-WebKitWebProcess.core /usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/WebKitWebProcess [New LWP 4176684] [New LWP 4176686] [New LWP 4176703] [New LWP 4176688] [New LWP 4176691] [New LWP 4177107] [New LWP 4176707] [New LWP 4176705] [New LWP 4177109] [New LWP 4176704] [New LWP 4177101] [New LWP 4176706] [New LWP 4177110] [New LWP 4177108] [New LWP 414318] [New LWP 409773] [New LWP 414319] [New LWP 409881] [New LWP 409923] [New LWP 409890] [New LWP 409928] [New LWP 409926] [New LWP 414317] [New LWP 409772] [New LWP 409875] [New LWP 409774] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `/usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/WebKitWebProcess 7 28'. Program terminated with signal SIGSEGV, Segmentation fault. #0 operator() () at ../Source/WebCore/platform/graphics/gstreamer/WebKitWebSourceGStreamer.cpp:699 699 ../Source/WebCore/platform/graphics/gstreamer/WebKitWebSourceGStreamer.cpp: No such file or directory. [Current thread is 1 (Thread 0x7f2c0869cf80 (LWP 4176684))] #0 operator()() () at ../Source/WebCore/platform/graphics/gstreamer/WebKitWebSourceGStreamer.cpp:699 #1 0x7f2c0dfbe9fc in WTF::Function::operator()() const () at ../Source/WTF/wtf/Function.h:84 #2 WTF::RunLoop::performWork() () at ../Source/WTF/wtf/RunLoop.cpp:124 #3 0x7f2c0e00c839 in operator() () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:68 #4 _FUN() () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:70 #5 0x7f2c0e79b4de in g_main_dispatch (context=0x56541f0bebb0) at ../../../glib/gmain.c:3309 #6 g_main_context_dispatch (context=context@entry=0x56541f0bebb0) at ../../../glib/gmain.c:3974 #7 0x7f2c0e79b890 in g_main_context_iterate (context=0x56541f0bebb0, block=block@entry=1, dispatch=dispatch@entry=1, self=) at ../../../glib/gmain.c:4047 #8 0x7f2c0e79bb63 in g_main_loop_run (loop=0x56541f0a5860) at ../../../glib/gmain.c:4241 #9 0x7f2c0e00d298 in WTF::RunLoop::run() () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:96 #10 0x7f2c1059e5bf in WebKit::AuxiliaryProcessMain(int, char**) () at ../Source/WebKit/Shared/AuxiliaryProcessMain.h:68 #11 0x7f2c0f630e0b in __libc_start_main (main=0x56541e4e9760 , argc=3, argv=0x7ffddbb32738, init=, fini=, rtld_fini=, stack_end=0x7ffddbb32728) at ../csu/libc-start.c:308 #12 0x56541e4e97ea in _start () #0 operator()() () at ../Source/WebCore/platform/graphics/gstreamer/WebKitWebSourceGStreamer.cpp:699 #1 0x7f2c0dfbe9fc in WTF::Function::operator()() const () at ../Source/WTF/wtf/Function.h:84 #2 WTF::RunLoop::performWork() () at ../Source/WTF/wtf/RunLoop.cpp:124 #3 0x7f2c0e00c839 in operator() () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:68 #4 _FUN() () at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:70 #5 0x7f2c0e79b4de in g_main_dispatch (context=0x56541f0bebb0) at ../../../glib/gmain.c:3309 dispatch = 0x7f2c0e00c850 <_FUN()> prev_source = 0x0 was_in_call = 0 user_data = 0x7f2c058fa000 callback = 0x7f2c0e00c830 <_FUN()> cb_funcs = 0x7f2c0e870280 cb_data = 0x56541f167300 need_destroy = source = 0x56541f27b660 current = 0x56541f0bec70 i = 0 __func__ = "g_main_dispatch" #6 g_main_context_dispatch (context=context@entry=0x56541f0bebb0) at ../../../glib/gmain.c:3974 #7 0x7f2c0e79b890 in
Bug#963519: lintian: false positive: latex2rtf: source-is-missing latex2rtf
Hi Chris, On Mon, Jun 22, 2020 at 2:33 PM Chris Lawrence wrote: > > The latex2rtf binary is built by a Makefile, without a source file > specifically called latex2rtf.c > > it's a false positive That's not possible (or there is a misunderstanding). The tag source-is-missing operates on source packages. It does not seek sources for executables shipped in installation packages. Did you perhaps include the executable in your source package? As an aside, I can not duplicate your report with the version in unstable: % ./frontend/lintian /mirror/debian/pool/main/l/latex2rtf/*.dsc /mirror/debian/pool/main/l/latex2rtf/latex2rtf_2.3.16-1+b1_amd64.deb W: latex2rtf: national-encoding usr/share/latex2rtf/cfg/direct.cfg W: latex2rtf: national-encoding usr/share/latex2rtf/cfg/icelandic.cfg W: latex2rtf source: package-uses-deprecated-debhelper-compat-version 9 I: latex2rtf: hardening-no-bindnow usr/bin/latex2rtf I: latex2rtf: spelling-error-in-copyright Coypright Copyright I: latex2rtf source: testsuite-autopkgtest-missing I: latex2rtf source: unused-license-paragraph-in-dep5-copyright bsd-3 (paragraph at line 46) P: latex2rtf source: insecure-copyright-format-uri http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ P: latex2rtf source: rules-requires-root-missing P: latex2rtf source: trailing-whitespace debian/changelog (line 246) Kind regards Felix Lechner
Bug#963520: guitarix: stop using rename.ul in d/rules
Control: retitle 963520 guitarix: depend on prename Sorry, this should have said: Various scripts in src:guitarix, f.e. make_lv2_X11bundle.sh, appear to look for a rename(1) binary. It is likely they find rename.ul from util-linux today. Please make sure they find rename or another tool instead, possibly by depending on prename. Chris
Bug#963521: pdfminer: please stop using rename.ul
Source: pdfminer Version: 20191020+dfsg-2 Dear Maintainer, pdfminer's debian/rules uses the rename.ul binary from util-linux, which will soon stop installing this binary. Please use another tool, for example prename, instead. Thanks, Chris
Bug#963492: logrotate: Copytruncate breaks rotate 0
Control: tags -1 - upstream + buster confirmed fixed-upstream Hi, Thanks for reporting. That is a known issue of 3.14 and is fixed[1] in 3.15 [2] . I think it's a minor issue, so I am not planning on backporting it to stable. Best regards, Christian Göttsche [1]: https://github.com/logrotate/logrotate/commit/4de537490a8128477f51eaeef70db17fa138afa3 [2]: https://github.com/logrotate/logrotate/blob/master/ChangeLog.md#3150---2018-12-04
Bug#963520: guitarix: stop using rename.ul in d/rules
Source: guitarix Version: 0.39.0+dfsg1-3.1 Dear Maintainer, your package appears to use `rename.ul` from util-linux, which will stop installing this binary soon. Please use `rename` from prename or other tools instead. Thanks, Chris
Bug#963112: [Pkg-javascript-devel] node-katex_0.10.2+dfsg-2_amd64.changes REJECTED
Quoting Sean Whitton (2020-06-22 23:26:37) > Would someone want to use libjs-katex without nodejs installed? Yes: Pandoc can produce output which uses katex rendered with the Javascript interpreter of web browsers, not on OS-bound Javascript rendering like Node.js. Currently Pandoc suggests node-katex, but pulling in Node.js is unneeded baggage. For some users it may even be bad: Node.js may not be covered by security support for as long as Firefox (due to the extraordinary treatment of Firefox in stable Debian). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#908467: btrfsmaintenance: Setting idle IO priority via BTRFS_SCRUB_PRIORITY is broken
Control: forwarded -1 https://github.com/kdave/btrfsmaintenance/pull/66 Dear Philip, Philip writes: > Package: btrfsmaintenance > Version: 0.4.2-1 > Followup-For: Bug #908467 > > Dear Maintainer, > > This bug is actually preventing Debian to work as a multimedia server like > Plex, because during scrubbing, everything else becomes very slow and > unresponsive and with even a few TB to scrub, it takes already almost two days > (in my case 38h). > So this bug is actually for me more urgent than for the the other poster. > I've also noticed that btrfs has gotten slower sometime post ~linux-4.9 (with defaults), and I wish the fix proposed in this bug actually resolved it. Given that with btrfs a syncthing update of several thousand files will also slow a desktop down to an unusable state, I agree with upstream that it's a kernel issue. For a server, I've had best results with the old non-multiqueue scheduler and CFQ, and for desktop I schedule scrubs or defrags for times I won't be using the system and use the non-multiqueue deadline scheduler--this is documented on our wiki. In the worst-case scenario, I wonder if ancient (but still existing) kernel issue that makes a desktop unusable when a USB drive is maxed out with IO (any filesystem) is what causes this effect. eg: that btrfs is guaranteed to trigger the same condition on any type of drive that is otherwise triggered by drive that has slow IO and high iowait (with any filesystem). > Thanks though for your work > You're welcome. Sorry this long-standing issue still exists (broader issue than btrfsmaintenance)...back in 2015 I fully expected it to be resolved by now. The wiki documents a bunch of things that make this problem worse (eg: using compression, keeping snapshots around, filling the disk more than ~80% full, etc). Not a real solution, I know... P.S. I'm also testing a zfs system, and its performance also falls off a cliff when an aged fs is above ~80% capacity--and once that happens, removing of files will never restore the old performance. That's why I prefer btrfs, despite the known cases that cause terrible performance. Regards, Nicholas signature.asc Description: PGP signature
Bug#931651: false positive: Match data clobbered by buffer modification hooks
David Bremner writes: > David Bremner writes: > > 0) set up a sid chroot on zelenka > 1) install emacs-nox in that chroot > 2) run the sample elisp code per the first message in the bug. > I can now duplicate this with emacs-nox 1:26.3+1-2 in an i386 or amd64 chroot.
Bug#963387: [request-tracker-maintainers] Bug#963387: Bug#963387: request-tracker4: FTBFS: CORE missing dependencies: Plack::Handler::Starlet ...MISSING
On Mon, Jun 22, 2020 at 11:44:13PM +0100, Dominic Hargreaves wrote:
> Control: retitle -1 request-tracker4: FTBFS with newer libmojolicious-perl:
> t/web/ticket_owner.t
> Control: tags -1 + confirmed
>
> On Sun, Jun 21, 2020 at 10:34:37PM +0200, Lucas Nussbaum wrote:
> > During a rebuild of all packages in sid, your package failed to build
> > on amd64.
> >
> > Relevant part (hopefully):
>
> ...
> > > SOME DEPENDENCIES WERE MISSING.
> > > MAILGATE missing dependencies:
> > > Mozilla::CA ...MISSING
> > > CORE missing dependencies:
> > > Plack::Handler::Starlet ...MISSING
> > >
> > > Perl library path for /usr/bin/perl:
> > > /etc/perl
> > > /usr/local/lib/x86_64-linux-gnu/perl/5.30.3
> > > /usr/local/share/perl/5.30.3
> > > /usr/lib/x86_64-linux-gnu/perl5/5.30
> > > /usr/share/perl5
> > > /usr/lib/x86_64-linux-gnu/perl-base
> > > /usr/lib/x86_64-linux-gnu/perl/5.30
> > > /usr/share/perl/5.30
> > > /usr/local/lib/site_perl
> > > make[1]: *** [Makefile:272: testdeps] Error 1
>
> This was not the problem (the immediately following lines are):
>
> make[1]: Leaving directory '/<>'
> make: [debian/rules:38: build-stamp] Error 2 (ignored)
>
> > The full build log is available from:
> >
> > http://qa-logs.debian.net/2020/06/20/request-tracker4_4.4.4-1_unstable.log
>
> The actual error is:
>
> Not an ARRAY reference at /usr/share/perl5/Mojo/DOM/CSS.pm line 237.
> Not an ARRAY reference at /usr/share/perl5/Mojo/DOM/CSS.pm line 237.
>
> # Failed test 'no warnings'
> # at /usr/share/perl/5.30/Test/Builder.pm line 152.
> # There were 1 warning(s)
> # Previous test 95 'Ticket -> Reply'
> # Not an ARRAY reference at /usr/share/perl5/Mojo/DOM/CSS.pm line 237.
> # at /usr/share/perl5/Log/Dispatch/Perl.pm line 86.
> # Log::Dispatch::Perl::__ANON__("Not an ARRAY reference at
> /usr/share/perl5/Mojo/DOM/CSS.pm li"...) called at
> /usr/share/perl5/Log/Dispatch/Output.pm line 64
> #
> Log::Dispatch::Output::_log_with_num(Log::Dispatch::Perl=HASH(0x55e04f914d00),
> 5, "message", "Not an ARRAY reference at /usr/share/perl5/Mojo/DOM/CSS.pm
> li"..., "level", "critical") called at /usr/share/perl5/Log/Dispatch.pm line
> 170
> # Log::Dispatch::_log_with_num(Log::Dispatch=HASH(0x55e04f8d43b8), 5,
> "level", "critical", "message", "Not an ARRAY reference at
> /usr/share/perl5/Mojo/DOM/CSS.pm li"...) called at
> /usr/share/perl5/Log/Dispatch.pm line 25
> # Log::Dispatch::__ANON__(Log::Dispatch=HASH(0x55e04f8d43b8), "Not an ARRAY
> reference at /usr/share/perl5/Mojo/DOM/CSS.pm li"...) called at
> /<>/lib/RT.pm line 408
> # RT::__ANON__("Not an ARRAY reference at /usr/share/perl5/Mojo/DOM/CSS.pm
> li"...) called at /usr/share/perl5/Mojo/DOM/CSS.pm line 237
> # Mojo::DOM::CSS::_pc(qr((?:^|:)class$)u,
> qr((?:^|\s+)transaction(?:\s+|$))u, ARRAY(0x55e050a066e0),
> ARRAY(0x55e050a066e0), ARRAY(0x55e050a066e0)) called at
> /usr/share/perl5/Mojo/DOM/CSS.pm line 291
> # Mojo::DOM::CSS::_selector(ARRAY(0x55e0510b0c78), ARRAY(0x55e050a066e0),
> ARRAY(0x55e050a066e0), ARRAY(0x55e050a066e0)) called at
> /usr/share/perl5/Mojo/DOM/CSS.pm line 61
> # Mojo::DOM::CSS::_combinator(ARRAY(0x55e0510b2a70), ARRAY(0x55e050a066e0),
> ARRAY(0x55e050a066e0), ARRAY(0x55e050a066e0), 2) called at
> /usr/share/perl5/Mojo/DOM/CSS.pm line 34
> # Mojo::DOM::CSS::_ancestor(ARRAY(0x55e0510b2a70), ARRAY(0x55e0510a9cc0),
> ARRAY(0x55e050a066e0), ARRAY(0x55e050a066e0), 0, 2) called at
> /usr/share/perl5/Mojo/DOM/CSS.pm line 75
> # Mojo::DOM::CSS::_combinator(ARRAY(0x55e0510b2a70), ARRAY(0x55e0510a9cc0),
> ARRAY(0x55e050a066e0), ARRAY(0x55e050a066e0), 0) called at
> /usr/share/perl5/Mojo/DOM/CSS.pm line 172
> # Mojo::DOM::CSS::_match(ARRAY(0x55e0510b2038), ARRAY(0x55e0510a9cc0),
> ARRAY(0x55e050a066e0), ARRAY(0x55e050a066e0)) called at
> /usr/share/perl5/Mojo/DOM/CSS.pm line 266
> # Mojo::DOM::CSS::_select(1, ARRAY(0x55e050a066e0), ARRAY(0x55e0510b2038))
> called at /usr/share/perl5/Mojo/DOM/CSS.pm line 26
> # Mojo::DOM::CSS::select_one(Mojo::DOM::CSS=HASH(0x55e0510b0c00),
> ".transaction.people .description") called at /usr/share/perl5/Mojo/DOM.pm
> line 27
> # Mojo::DOM::at(Mojo::DOM=REF(0x55e050aab360), ".transaction.people
> .description") called at t/web/ticket_owner.t line 393
> #
> # Some tests failed or we bailed out, tmp directory
> '/<>/t/tmp/web-ticket_owner.t-pLaG9Zs3' is not cleaned
> # Tests were run but no plan was declared and done_testing() was not seen.
> # Looks like your test exited with 255 just after 98.
> t/web/ticket_owner.t ...
> Dubious, test returned 255 (wstat 65280, 0xff00)
> Failed 1/98 subtests
>
> Almost certainly triggered by the recent uploads of libmojolicious-perl.
> It happens with both 8.55+dfsg-1 (sid) and 8.54+dfsg-1 (bullseye).
Confirmed it doesn't happen with 8.53. Forwarded upstream.
Bug#888315: blender: segfault on start
Hi, same problem here: segfault on blender start. I sent that report to the blender package: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963203 Same problem with openscad, btw: Jun 21 19:21:47 bob kernel: openscad[31289]: segfault at a0 ip 14bd1303b9b8 sp 7ffd5c895a30 error 4 in iris_dri.so[14bd12553000+e11000] Jun 21 19:21:47 bob kernel: Code: 44 24 18 48 c7 44 24 10 00 00 00 00 48 c7 44 24 18 00 00 00 00 50 4c 8d 4c 24 18 e8 52 85 ad ff 48 8b 44 24 18 31 d2 48 89 ef <4c> 8b b0 a0 00 00 00 4c 89 f6 e8 59 94 fd ff 48 8b bd 28 01 00 00 cu -- Markus Grunwald https://www.the-grue.de/~markus/markus_grunwald.gpg
Bug#963387: [request-tracker-maintainers] Bug#963387: request-tracker4: FTBFS: CORE missing dependencies: Plack::Handler::Starlet ...MISSING
Control: retitle -1 request-tracker4: FTBFS with newer libmojolicious-perl:
t/web/ticket_owner.t
Control: tags -1 + confirmed
On Sun, Jun 21, 2020 at 10:34:37PM +0200, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
> Relevant part (hopefully):
...
> > SOME DEPENDENCIES WERE MISSING.
> > MAILGATE missing dependencies:
> > Mozilla::CA ...MISSING
> > CORE missing dependencies:
> > Plack::Handler::Starlet ...MISSING
> >
> > Perl library path for /usr/bin/perl:
> > /etc/perl
> > /usr/local/lib/x86_64-linux-gnu/perl/5.30.3
> > /usr/local/share/perl/5.30.3
> > /usr/lib/x86_64-linux-gnu/perl5/5.30
> > /usr/share/perl5
> > /usr/lib/x86_64-linux-gnu/perl-base
> > /usr/lib/x86_64-linux-gnu/perl/5.30
> > /usr/share/perl/5.30
> > /usr/local/lib/site_perl
> > make[1]: *** [Makefile:272: testdeps] Error 1
This was not the problem (the immediately following lines are):
make[1]: Leaving directory '/<>'
make: [debian/rules:38: build-stamp] Error 2 (ignored)
> The full build log is available from:
>http://qa-logs.debian.net/2020/06/20/request-tracker4_4.4.4-1_unstable.log
The actual error is:
Not an ARRAY reference at /usr/share/perl5/Mojo/DOM/CSS.pm line 237.
Not an ARRAY reference at /usr/share/perl5/Mojo/DOM/CSS.pm line 237.
# Failed test 'no warnings'
# at /usr/share/perl/5.30/Test/Builder.pm line 152.
# There were 1 warning(s)
# Previous test 95 'Ticket -> Reply'
# Not an ARRAY reference at /usr/share/perl5/Mojo/DOM/CSS.pm line 237.
# at /usr/share/perl5/Log/Dispatch/Perl.pm line 86.
# Log::Dispatch::Perl::__ANON__("Not an ARRAY reference at
/usr/share/perl5/Mojo/DOM/CSS.pm li"...) called at
/usr/share/perl5/Log/Dispatch/Output.pm line 64
#
Log::Dispatch::Output::_log_with_num(Log::Dispatch::Perl=HASH(0x55e04f914d00),
5, "message", "Not an ARRAY reference at /usr/share/perl5/Mojo/DOM/CSS.pm
li"..., "level", "critical") called at /usr/share/perl5/Log/Dispatch.pm line 170
# Log::Dispatch::_log_with_num(Log::Dispatch=HASH(0x55e04f8d43b8), 5,
"level", "critical", "message", "Not an ARRAY reference at
/usr/share/perl5/Mojo/DOM/CSS.pm li"...) called at
/usr/share/perl5/Log/Dispatch.pm line 25
# Log::Dispatch::__ANON__(Log::Dispatch=HASH(0x55e04f8d43b8), "Not an ARRAY
reference at /usr/share/perl5/Mojo/DOM/CSS.pm li"...) called at
/<>/lib/RT.pm line 408
# RT::__ANON__("Not an ARRAY reference at /usr/share/perl5/Mojo/DOM/CSS.pm
li"...) called at /usr/share/perl5/Mojo/DOM/CSS.pm line 237
# Mojo::DOM::CSS::_pc(qr((?:^|:)class$)u, qr((?:^|\s+)transaction(?:\s+|$))u,
ARRAY(0x55e050a066e0), ARRAY(0x55e050a066e0), ARRAY(0x55e050a066e0)) called at
/usr/share/perl5/Mojo/DOM/CSS.pm line 291
# Mojo::DOM::CSS::_selector(ARRAY(0x55e0510b0c78), ARRAY(0x55e050a066e0),
ARRAY(0x55e050a066e0), ARRAY(0x55e050a066e0)) called at
/usr/share/perl5/Mojo/DOM/CSS.pm line 61
# Mojo::DOM::CSS::_combinator(ARRAY(0x55e0510b2a70), ARRAY(0x55e050a066e0),
ARRAY(0x55e050a066e0), ARRAY(0x55e050a066e0), 2) called at
/usr/share/perl5/Mojo/DOM/CSS.pm line 34
# Mojo::DOM::CSS::_ancestor(ARRAY(0x55e0510b2a70), ARRAY(0x55e0510a9cc0),
ARRAY(0x55e050a066e0), ARRAY(0x55e050a066e0), 0, 2) called at
/usr/share/perl5/Mojo/DOM/CSS.pm line 75
# Mojo::DOM::CSS::_combinator(ARRAY(0x55e0510b2a70), ARRAY(0x55e0510a9cc0),
ARRAY(0x55e050a066e0), ARRAY(0x55e050a066e0), 0) called at
/usr/share/perl5/Mojo/DOM/CSS.pm line 172
# Mojo::DOM::CSS::_match(ARRAY(0x55e0510b2038), ARRAY(0x55e0510a9cc0),
ARRAY(0x55e050a066e0), ARRAY(0x55e050a066e0)) called at
/usr/share/perl5/Mojo/DOM/CSS.pm line 266
# Mojo::DOM::CSS::_select(1, ARRAY(0x55e050a066e0), ARRAY(0x55e0510b2038))
called at /usr/share/perl5/Mojo/DOM/CSS.pm line 26
# Mojo::DOM::CSS::select_one(Mojo::DOM::CSS=HASH(0x55e0510b0c00),
".transaction.people .description") called at /usr/share/perl5/Mojo/DOM.pm line
27
# Mojo::DOM::at(Mojo::DOM=REF(0x55e050aab360), ".transaction.people
.description") called at t/web/ticket_owner.t line 393
#
# Some tests failed or we bailed out, tmp directory
'/<>/t/tmp/web-ticket_owner.t-pLaG9Zs3' is not cleaned
# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 255 just after 98.
t/web/ticket_owner.t ...
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 1/98 subtests
Almost certainly triggered by the recent uploads of libmojolicious-perl.
It happens with both 8.55+dfsg-1 (sid) and 8.54+dfsg-1 (bullseye).
Bug#963517: fai support for CentOS package groups needs enhancement
Mmmm, space in package names are really bad. Are you sure the package group name contains a space or is it only the description of the group which contains spaces? Can you give an example please. -- regards Thomas
Bug#949196: libzypp: diff for NMU version 17.7.0-1.1
Hi, Am Montag, 22. Juni 2020 schrieb Giovanni Mascellani: > Hi, > > Il 20/06/20 19:01, Mike Gabriel ha scritto: > > Thanks for patching libzypp. Your NMU is ok, I will include your > > .debdiff on its VCS. In fact, I am considering orphaning libzypp and > > zypper in Debian. Do you have interest in taking over? > > Ugh, I just realized I stupidly embedded the amd64 architecture in my > patch, leading to obvious FTBFS on the other archs. It is ok for you if > I directly NMU libzypp replacing x86_64-linux-gnu with > $(DEB_HOST_MULTIARCH)? yes, please. Mike -- Gesendet von meinem Fairphone (powered by SailfishOS)
Bug#963519: lintian: false positive: latex2rtf: source-is-missing latex2rtf
Package: lintian Version: 2.80.0 Severity: normal The latex2rtf binary is built by a Makefile, without a source file specifically called latex2rtf.c (etc.), by linking a bunch of other files. I'm not sure if this is a result of the weird Makefile that is designed to allow the binary to be built with a .exe extension for Windows or what... regardless, it's a false positive in this case. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (102, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.2 (SMP w/24 CPU cores) 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.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils 2.34-8 ii bzip21.0.8-3 ii diffstat 1.63-1 ii dpkg 1.19.7 ii dpkg-dev 1.19.7 ii file 1:5.38-5 ii gettext 0.19.8.1-10 ii gpg 2.2.20-1 ii intltool-debian 0.35.0+20060710.5 ii libapt-pkg-perl 0.1.36+b3 ii libarchive-zip-perl 1.68-1 ii libcapture-tiny-perl 0.48-1 ii libclass-xsaccessor-perl 1.19-3+b5 ii libclone-perl0.45-1 ii libconfig-tiny-perl 2.24-1 ii libcpanel-json-xs-perl 4.19-1 ii libdevel-size-perl 0.83-1+b1 ii libdpkg-perl 1.19.7 ii libemail-address-xs-perl 1.04-1+b2 ii libemail-valid-perl 1.202-1 ii libfile-basedir-perl 0.08-1 ii libfile-find-rule-perl 0.34-1 ii libfont-ttf-perl 1.06-1 ii libhtml-parser-perl 3.72-5 ii libio-async-loop-epoll-perl 0.21-1 ii libio-async-perl 0.77-2 ii libjson-maybexs-perl 1.004002-1 ii liblist-compare-perl 0.53-1 ii liblist-moreutils-perl 0.416-1+b5 ii liblist-utilsby-perl 0.11-1 ii libmoo-perl 2.004000-1 ii libmoox-aliases-perl 0.001006-1 ii libnamespace-clean-perl 0.27-1 ii libpath-tiny-perl0.114-1 ii libsereal-decoder-perl 4.014+ds-1 ii libsereal-encoder-perl 4.014+ds-1 ii libtext-levenshtein-perl 0.13-1 ii libtimedate-perl 2.3300-1 ii libtry-tiny-perl 0.30-1 ii libtype-tiny-perl1.010002-1 ii libunicode-utf8-perl 0.62-1+b1 ii liburi-perl 1.76-2 ii libxml-libxml-perl 2.0134+dfsg-2 ii libxml-writer-perl 0.625-1 ii libyaml-libyaml-perl 0.82+repack-1 ii man-db 2.9.2-1 ii patchutils 0.3.4-3 ii perl [libdigest-sha-perl]5.30.3-4 ii t1utils 1.41-4 ii xz-utils 5.2.4-1+b1 Versions of packages lintian recommends: ii libperlio-gzip-perl 0.19-1+b6 Versions of packages lintian suggests: pn binutils-multiarch ii libtext-template-perl 1.58-1 -- no debconf information
Bug#963112: [Pkg-javascript-devel] node-katex_0.10.2+dfsg-2_amd64.changes REJECTED
Hello Pirate,
On Mon 22 Jun 2020 at 12:58AM +0530, Pirate Praveen wrote:
> We usually use Provides instead of splitting when we can remove the Depends
> on the interpreter. For example node-clipboard provides libjs-clipboard.js.
> This works when the node package does not ship a user facing significant
> executable. User facing executable as separate binary was recognized as a
> valid reason by CTTE in the ruling I quoted in my first reply.
>
> In case of this particular package, katex binary also provide a command line
> interface via katex command. So we cannot drop the depends on nodejs (rc bug,
> nodejs is not an optional component but the interpreter needed to run the
> katex program). Avoiding unnecessary dependency on interpreters was achieved
> in all previous instances by removing the dependency on pure libraries. We
> expect whichever user facing program depending on the library to set Depends
> on the interpreter. For example gitlab depending on nodejs is enough for
> node-clipboard to satisfy dependency on nodejs. In this case katex itself is
> a user facing program not tied to nodejs development (it is used for maths
> typesetting). So we cannot reasonably expect a user wanting to use katex will
> have nodejs installed already.
Would someone want to use libjs-katex without nodejs installed?
> I thought the CTTE guideline on this specific case of user facing executable
> was enough. They could have just asked for an explanation before rejecting.
You should ensure it's visible in the source package, in
README.{source,Debian} and/or d/changelog.
--
Sean Whitton
Bug#963508: /lib/ld-linux.so.2: LD_PRELOAD breaks with plain filename
On 2020-06-22 19:00, Ian Jackson wrote: > Package: libc6 > Version: 2.28-10 > Severity: normal > File: /lib/ld-linux.so.2 > > Hi. I found this behaviour: > > $ eatmydata man ls >/dev/null > ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded > (cannot open shared object file): ignored. > ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded > (cannot open shared object file): ignored. > ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded > (cannot open shared object file): ignored. > ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded > (cannot open shared object file): ignored. > $ You probably have apparmor installed and enabled on your system. Binaries that are run with an apparmor profile get AT_SECURE enabled, which disables many features that have an impact on security, including preloading libraries. > Experimenting shows that the problem is triggered by having LD_PRELOAD > containing only the library name: > > $ faketime yesterday printenv | grep PREL > LD_PRELOAD=libgtk3-nocsd.so.0:/usr/$LIB/faketime/libfaketime.so.1 > $ faketime yesterday env LD_PRELOAD=libfaketime.so.1 man ls >/dev/null > ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded > (cannot open shared object file): ignored. > ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded > (cannot open shared object file): ignored. > ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded > (cannot open shared object file): ignored. > ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded > (cannot open shared object file): ignored. > ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded > (cannot open shared object file): ignored. > ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded > (cannot open shared object file): ignored. > ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded > (cannot open shared object file): ignored. > ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded > (cannot open shared object file): ignored. > $ faketime.so.1 is not in the standard path, ie on an amd64 system not directly in /usr/lib/x86_64-linux-gnu: $ dpkg -L libfaketime | grep libfaketime.so.1 /usr/lib/x86_64-linux-gnu/faketime/libfaketime.so.1 So you definitely need to use the full path, or add that path to LD_LIBRARY_PATH or to /etc/ld.so.conf. > The problem is not limited to man: > > $ faketime yesterday env LD_PRELOAD=libfaketime.so.1 dash -c true > ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded > (cannot open shared object file): ignored. > $ Same issue here, you can't just assume that /lib/ld-linux.so.2 will search on the full filesystem. Here are the paths that are searched according to the man page: If a shared object dependency does not contain a slash, then it is searched for in the following order: - Using the directories specified in the DT_RPATH dynamic section attribute of the binary if present and DT_RUNPATH attribute does not exist. Use of DT_RPATH is deprecated. - Using the environment variable LD_LIBRARY_PATH, unless the executable is being run in secure-execution mode (see below), in which case this variable is ignored. - Using the directories specified in the DT_RUNPATH dynamic section attribute of the binary if present. Such directories are searched only to find those objects required by DT_NEEDED (direct dependencies) entries and do not apply to those objects' children, which must themselves have their own DT_RUNPATH entries. This is unlike DT_RPATH, which is applied to searches for all children in the dependency tree. - From the cache file /etc/ld.so.cache, which contains a compiled list of candidate shared objects previously found in the augmented library path. If, however, the binary was linked with the -z nodeflib linker option, shared objects in the default paths are skipped. Shared objects installed in hardware capability directories (see below) are preferred to other shared objects. - In the default path /lib, and then /usr/lib. (On some 64-bit architectures, the default paths for 64-bit shared objects are /lib64, and then /usr/lib64.) If the binary was linked with the -z nodeflib linker option, this step is skipped. > This message on debian-user seems related: > https://lists.debian.org/debian-user/2017/03/msg00335.html Yes, there seems to be an issue there, but I am personally not able to reproduce it. Note however that I only tried it in a jessie chroot, not in a complete jessie system. > Colin Watson (CC'd) reports that sid works. I have tested on sid and on experimental, I do not find a different behaviour. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#963287: notmuch: FTBFS: grotty: ():1662: fatal error: output error
On Mon, Jun 22, 2020 at 09:18:59PM +0100, Colin Watson wrote: > I'm going to upload man-db with a dependency on bsdextrautils | > bsdmainutils (<< 12.1.1~) shortly. (There's been a bit of a delay > because of some unrelated po4a-induced breakage that I had to stop and > fix upstream first.) Done (man-db 2.9.3-1). -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#963506: RFS: symfit/0.5.2-1 [ITP] -- Symbolic Fitting in Python, fitting as it should be
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "symfit" * Package name: symfit Version : 0.5.2-1 Upstream Author : Martin Roelfs * URL : https://github.com/tBuLi/symfit * License : GPL-2.0-or-later * Vcs : https://salsa.debian.org/stephanlachnit/symfit Section : python It builds those binary packages: python3-symfit - Symbolic Fitting in Python, fitting as it should be To access further information about this package, please visit the following URL: https://mentors.debian.net/package/symfit Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/symfit/symfit_0.5.2-1.dsc Changes since the last upload: * Initial release. (Closes: #963503) Regards, -- Stephan Lachnit
Bug#963518: source-highlight: Embeds user shell in scripts
Source: source-highlight Version: 3.1.9-1.2 Severity: normal Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: shell X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org When CONFIG_SHELL is not set during configure, configure attempts various methods to detect a valid shell, including using the build user's shell, which may vary from user to user. This then gets embedded into scripts shipped in the libsource-highlight-common package, breaking reproducibility: ./usr/share/source-highlight/source-highlight-esc.sh Offset 1, 8 lines modifiedOffset 1, 8 lines modified 1 #!/bin/bash 1 #!/bin/sh ./usr/share/source-highlight/src-hilite-lesspipe.sh Offset 1, 8 lines modifiedOffset 1, 8 lines modified 1 #!·/bin/bash 1 #!·/bin/sh The attached patch works around this by setting CONFIG_SHELL=/bin/sh in debian/rules during configure. Thanks for maintaining source-highlight! live well, vagrant From 3f369205d838c908a453a944735ab1f0bc12e915 Mon Sep 17 00:00:00 2001 From: Vagrant Cascadian Date: Mon, 22 Jun 2020 20:25:50 + Subject: [PATCH] debian/rules: Set CONFIG_SHELL to /bin/sh during configure. This enables reproducible builds regardless of the configured shell of the build user. --- debian/rules | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/rules b/debian/rules index 011a918..c92d9a6 100755 --- a/debian/rules +++ b/debian/rules @@ -3,7 +3,7 @@ dh $@ override_dh_auto_configure: - dh_auto_configure -- \ + CONFIG_SHELL=/bin/sh dh_auto_configure -- \ --with-bash-completion=/usr/share/bash-completion/completions \ --with-boost-regex=boost_regex -- 2.20.1 signature.asc Description: PGP signature
Bug#963513: Please restore LC_TIME symlinks
On Mon, Jun 22, 2020 at 09:41:20PM +0200, Jordi Mallach wrote: In #584837, it was requested that the symlinks from ...//LC_MESSAGES/coreutils.mo to ../LC_TIME/coreutils.mo were removed due to being pointless and unused. I'm unsure if that was the case at that point (it's been 10 years), but current implementations of some of the commands in coreutils do need and expect LC_TIME to operate correctly: openat(AT_FDCWD, "/usr/share/locale/ca/LC_TIME/coreutils.mo", O_RDONLY) = 3 In particular, at least ls and date will try to use it to represent date formats correctly on verbose outputs. This affects at least Catalan, which shows time incorrectly unless you force a date format string by hand. Can you give examples of expected and current output?
Bug#963517: fai support for CentOS package groups needs enhancement
Package: fai-server
Version: 5.9.4
FAI supports rpm based systems like CentOS, including rpm groups. The
readconfig subroutine in the install_packages perl script should have some
enhancement for this case, though.
There is a warning message if a package name contains an upper case letter.
Package groups do commonly use upper case, though.
Most severe, though, is that rpm groups may contain spaces! I don't know
who had the bright idea to do this, but if is unfortunately in general
practice. I was looking into splitting out the graphical-server-environment
rpm group to separate out gnome packages, and many of the sub-groups contain
spaces. So, it looks like the line in install_packages:
push @{$list{$type}}, split if $doit;
is insufficient. Perhaps a reasonable extension is to allow quoted strings
in the package_config files? I'm not enough of a perl addict to suggest a
good modification for this, although I'm rather sure that it isn't more than
a few lines of code.
Bug#963287: notmuch: FTBFS: grotty: ():1662: fatal error: output error
On Mon, Jun 22, 2020 at 09:56:13PM +0200, Lucas Nussbaum wrote: > On 22/06/20 at 21:35 +0200, Michael Meskes wrote: > > The reason for this move is moving from the old and heavily patched BSD > > source to the more up-to-date GNU version. > > I did a partial archive rebuild reverting to the version of bsdmainutils > with 'col' and others. It seems that the list of affected packages from > #963327 is complete with the exception of 'notmuch'. > > A good plan would probably be to fix man-db, and look at what are the > remaining failures after that. I'm going to upload man-db with a dependency on bsdextrautils | bsdmainutils (<< 12.1.1~) shortly. (There's been a bit of a delay because of some unrelated po4a-induced breakage that I had to stop and fix upstream first.) However, in order to make buster → bullseye upgrades work properly, I think it's necessary to have bsdmainutils depend on bsdextrautils for at least one release cycle. Otherwise there may be a point during the upgrade where col isn't installed and so man will be broken; it's worth putting some effort into avoiding that because if the upgrade happens to break then users may need to consult man pages to work out what to do. The only reliable way I can think of to avoid this kind of problem is to have a hard dependency for a while as a transitional measure. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#963516: ffmpeg: Please activate HWAccel
Source: ffmpeg Severity: wishlist Dear Maintainer, In a Debian multimedia server something like hardware acceleration is absolutely necessary. Fotunately ffmpeg has all ready, but it has to be enabled at configuration time: --enable-cuda-nvcc \ --enable-hwaccels \ --enable-nvenc Thanks -- System Information: Debian Release: 10.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-9-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#963515: cups-bsd: Unable to print opendocument text with lpr command
Package: cups-bsd Version: 2.3.3-1 Severity: minor Hi! If I launch: lpr -P myprinter myfile.odt I've got this error message and printing is canceled: lpr : Unsupported document-format "application/vnd.oasis.opendocument.text". I've already tested with other printers, and the result is the same. Here is a post from another person in another website that describes a similar issue: https://unix.stackexchange.com/questions/561632/cups-error-format-not-supported-from-command-line Like sebelk, I haven't got any problem to prind odt documents directly from libreoffice. Thanks. -- Ludo -- System Information: Debian Release: bullseye/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (200, 'unstable'), (150, 'stable'), (100, 'experimental') Architecture: i386 (i686) Kernel: Linux 5.6.0-2-686-pae (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cups-bsd depends on: ii cups-client2.3.3-1 ii cups-common2.3.3-1 ii debconf [debconf-2.0] 1.5.74 ii libc6 2.30-8 ii libcups2 2.3.3-1 cups-bsd recommends no packages. Versions of packages cups-bsd suggests: ii cups 2.3.3-1 ii openbsd-inetd [inet-superserver] 0.20160825-4+b1 ii update-inetd 4.50 -- debconf information: cups-bsd/setuplpd: false
Bug#908467: btrfsmaintenance: Setting idle IO priority via BTRFS_SCRUB_PRIORITY is broken
Package: btrfsmaintenance Version: 0.4.2-1 Followup-For: Bug #908467 Dear Maintainer, This bug is actually preventing Debian to work as a multimedia server like Plex, because during scrubbing, everything else becomes very slow and unresponsive and with even a few TB to scrub, it takes already almost two days (in my case 38h). So this bug is actually for me more urgent than for the the other poster. Thanks though for your work -- System Information: Debian Release: 10.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-9-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages btrfsmaintenance depends on: ii btrfs-progs 4.20.1-2 ii cron 3.0pl1-134+deb10u1 ii systemd 241-7~deb10u4 btrfsmaintenance recommends no packages. btrfsmaintenance suggests no packages. -- Configuration Files: /etc/default/btrfsmaintenance changed [not included] -- no debconf information
Bug#753299: marked as done (libghc-highlighting-kate-dev: Highlighting Ocaml fails)
Note that highlighting-kate is deprecated and has been replaced by the skylighting library, used in more recent versions of pandoc.
Bug#962134: [External] Re: Bug#962134: add Sound Open Firmware
On 6/4/2020 9:21 AM, Mark Pearson wrote: OK - I have asked the SOF folk to talk to you about this. I'll unicast you the email address so you have the correct contact details too. I know some discussions started with the SOF folk. Has there been any progress for this issue? Anything that is stuck that I can help with? Thanks Mark
Bug#931566:
Bug#962348: kig: boost1.67 is being removed from testing
Hi Pino On 2020-06-08 14:47:13 +0200, Pino Toscano wrote: > Also, boost transitions works slightly different than other library > transitions: the old and the new libraries are provided by different > sources and they are co-installable (not their -dev, though). > It's enough that the new boost is available in testing, so the switch > of boost-default is not a blocker transition but a a gradual > rebuild/fix that can generally happen side by side with other changes. > This is similar to what happens when the default Python version is > switched: both the old and the new are co-installable, and already in > testing. kig is now the only reverse dependency of boost1.67 in testing. Could you please take a look at this soon so that I can add a removal hint for boost1.67? Thanks in advance Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#963514: RFS: tupi/0.2+git08-3 [QA][RC] -- 2D Animation design and authoring tool
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "tupi" * Package name: tupi Version : 0.2+git08-3 Upstream Author : Gustav Gonzalez * URL : http://www.maefloresta.com/portal * License : GPL-2+ * Vcs : None Section : graphics It builds those binary packages: tupi - 2D Animation design and authoring tool tupi-data - Data files for tupi (2D Animation design and authoring tool) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/tupi Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/t/tupi/tupi_0.2+git08-3.dsc Changes since the last upload: * QA upload. * Update compat level to 13. * Remove parallel from d/rules, which is default now. * Use https with copyright-format-uri. * Remove unnecessary get-orig-source from d/rules. * Fix FTBFS. (Closes: #963386) -- Regards Sudip
Bug#963503: ITP: symfit -- Symbolic Fitting in Python, fitting as it should be
Package: wnpp Severity: wishlist Owner: Stephan Lachnit Package name: symfit Version : 0.5.2 Upstream Author : Martin Roelfs URL : https://github.com/tBuLi/symfit License : GPLv2 Programming Lang: python3 Description : Symbolic Fitting in Python, fitting as it should be The goal of this project is simple: to make fitting in Python pythonic. The project aims to marry the power of scipy.optimize with the readability of sympy to create a highly readable and easy to use fitting package which works for projects of any scale. Documentation: https://symfit.readthedocs.io/en/stable/ I would maintain this in Debian Python Modules Team or Debian Science team, depdending on interest. Cheers, Stephan Lachnit
Bug#963287: notmuch: FTBFS: grotty: ():1662: fatal error: output error
On 22/06/20 at 21:35 +0200, Michael Meskes wrote: > On Mon, 2020-06-22 at 20:57 +0200, Julien Cristau wrote: > > On Mon, Jun 22, 2020 at 19:46:21 +0200, Michael Meskes wrote: > > > > > > Depending on bsdmainutils to get col et al seems entirely right, > > > > it's > > > > been right forever, there doesn't seem to be a reason to break > > > > that > > > > both > > > > for dependent packages and for end users. Especially not without > > > > notice. > > > > > > There is no point arguing against your "do not change anything" > > > attitude. > > > > > I'm not saying don't change anything, I'm saying don't break stuff > > for > > users for no reason. > > You are saying the reason is "it's been right forever". > > The reason for this move is moving from the old and heavily patched BSD > source to the more up-to-date GNU version. I did a partial archive rebuild reverting to the version of bsdmainutils with 'col' and others. It seems that the list of affected packages from #963327 is complete with the exception of 'notmuch'. A good plan would probably be to fix man-db, and look at what are the remaining failures after that. Lucas
Bug#963513: Please restore LC_TIME symlinks
Package: coreutils Version: 8.30-3+b1 Severity: normal Tags: l10n Hi, In #584837, it was requested that the symlinks from ...//LC_MESSAGES/coreutils.mo to ../LC_TIME/coreutils.mo were removed due to being pointless and unused. I'm unsure if that was the case at that point (it's been 10 years), but current implementations of some of the commands in coreutils do need and expect LC_TIME to operate correctly: openat(AT_FDCWD, "/usr/share/locale/ca/LC_TIME/coreutils.mo", O_RDONLY) = 3 In particular, at least ls and date will try to use it to represent date formats correctly on verbose outputs. This affects at least Catalan, which shows time incorrectly unless you force a date format string by hand. See also https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33211 for some related issue. Thanks, Jordi -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.6.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8), LANGUAGE=ca_ES:ca (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages coreutils depends on: ii libacl1 2.2.53-8 ii libattr1 1:2.4.48-5 ii libc62.30-8 ii libselinux1 3.0-1+b3 coreutils recommends no packages. coreutils suggests no packages. -- no debconf information
Bug#963287: notmuch: FTBFS: grotty: ():1662: fatal error: output error
On Mon, 2020-06-22 at 20:57 +0200, Julien Cristau wrote: > On Mon, Jun 22, 2020 at 19:46:21 +0200, Michael Meskes wrote: > > > > Depending on bsdmainutils to get col et al seems entirely right, > > > it's > > > been right forever, there doesn't seem to be a reason to break > > > that > > > both > > > for dependent packages and for end users. Especially not without > > > notice. > > > > There is no point arguing against your "do not change anything" > > attitude. > > > I'm not saying don't change anything, I'm saying don't break stuff > for > users for no reason. You are saying the reason is "it's been right forever". The reason for this move is moving from the old and heavily patched BSD source to the more up-to-date GNU version. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#963512: RFP: obs-v4l2sink -- obs-studio plugin to send output to a Video4Linux2 loopback device
Package: wnpp Severity: wishlist * Package name: obs-v4l2sink Version : 0.1.0 Upstream Author : Han-Tai Chen * URL : https://github.com/CatxFish/obs-v4l2sink * License : GPL v2 Programming Lang: C++ Description : obs-studio plugin to send output to a Video4Linux2 loopback device obs-v4l2sink is an OBS Studio plugin that provides output capabilities to a Video4Linux2 device. It is basically a Linux version of obs-virtual-cam, but only contains the video sink part. You can use it with v4l2loopback to achieve cross-program video transfer between OBS Studio and third party software supporting Video4Linux2, e.g. to present an OBS session in proprietary browser- based conferencing systems by selecting the OBS session as a webcam.
Bug#963154: nmapsi4: Must not be arch:any
Em sáb., 20 de jun. de 2020 às 10:00, Adrian Bunk escreveu: > > There are plenty of packages in the archive whose build dependencies > cannot be fulfilled on all release architectures. > > This is not a problem. Ok, thanks Adrian. I fixed forensics-all, affected by this change. Regards, Eriberto
Bug#962827: [pkg-php-pear] Bug#962827: Fix uploaded to DELAYED/5: libphp-phpmailer: CVE-2020-13625
Hi Paul, Thank you for your fix. Le 22/06/2020 à 09:02, Paul Gevers a écrit : > As announced I've prepared an upload for libphp-phpmailer (versioned as > 6.1.6-1) and uploaded it to DELAYED/5. If anybody objects against me > adding myself as uploader, please tell me and I'll cancel the upload. On the contrary, welcome to the team, feel free to reschedule the upload to DELAYED/0! > By the way, if anybody has a copy of the old git archive (I couldn't > find it on alioth-archive.debian.org) I would like to get one too. It’s there: https://alioth-archive.debian.org/git/pkg-php/libphp-phpmailer.git.tar.xz Regards David
Bug#963408: pmtools: FTBFS: dh_auto_test: error: make -j4 test TEST_VERBOSE=1 returned exit code 2
On Sun, Jun 21, 2020 at 11:35:22PM +0200, gregor herrmann wrote: > On Sun, 21 Jun 2020 22:11:05 +0200, Lucas Nussbaum wrote: > > > # 'pod2text: unable to format > > > /usr/lib/x86_64-linux-gnu/perl-base/Carp.pm > Interesting bug, and not found in cpantesters. > > I note that /usr/lib/x86_64-linux-gnu/perl-base/Carp.pm (from > perl-base) indeed has no POD, but /usr/share/perl/5.30.3/Carp.pm > (from perl-modules-5.30) does. And bin/pman finds the first one. > > I wonder why this pops up now? Can this be related to the recent > changes of @INC in src:perl? Yes. The .pm files in perl-base have their POD documentation stripped away (see debian/stripdoc in src:perl). Those are now first on @INC even when libperl5.30 are perl-modules-5.30 are installed (see #962138). Looks like /usr/bin/perldoc finds the second Carp.pm when the first doesn't contain any POD documentation, but the pmtools build can't. Not sure what to do about this bug. As an isolated corner case we can patch around it, but the fact is we're slightly more visibly deviated from upstream than we used to be. We'll see if more things like these crop up. We could also stop stripping the docs in perl-base. Statistics about how much space it's saving now would be useful if we want to consider that. Copying perl@pdo as a heads up. -- Niko
Bug#962827: Fix uploaded to DELAYED/5: libphp-phpmailer: CVE-2020-13625
Package: libphp-phpmailer Version: 6.1.5-0.1 Tags: patch pending Dear maintainer, As announced I've prepared an upload for libphp-phpmailer (versioned as 6.1.6-1) and uploaded it to DELAYED/5. If anybody objects against me adding myself as uploader, please tell me and I'll cancel the upload. By the way, if anybody has a copy of the old git archive (I couldn't find it on alioth-archive.debian.org) I would like to get one too. Regards. Paul diff -Nru libphp-phpmailer-6.1.5/debian/changelog libphp-phpmailer-6.1.6/debian/changelog --- libphp-phpmailer-6.1.5/debian/changelog 2020-04-22 22:11:37.0 +0200 +++ libphp-phpmailer-6.1.6/debian/changelog 2020-06-22 20:31:41.0 +0200 @@ -1,3 +1,16 @@ +libphp-phpmailer (6.1.6-1) unstable; urgency=medium + + * New upstream version 6.1.6 +- CVE-2020-13625 an output escaping bug when the name of a file + attachment contains a double quote character. This can result in + the file type being misinterpreted by the receiver or any mail + relay processing the message (Closes: #962827) + * Add myself as uploader + * Drop Kevin Coyner as uploader (Closes: #929548) + * Point Vcs-* fields to the dgit server for now as Alioth is gone + + -- Paul Gevers Mon, 22 Jun 2020 20:31:41 +0200 + libphp-phpmailer (6.1.5-0.1) unstable; urgency=medium * Non-maintainer upload diff -Nru libphp-phpmailer-6.1.5/debian/control libphp-phpmailer-6.1.6/debian/control --- libphp-phpmailer-6.1.5/debian/control 2020-04-22 22:11:37.0 +0200 +++ libphp-phpmailer-6.1.6/debian/control 2020-06-22 20:31:41.0 +0200 @@ -2,12 +2,12 @@ Section: php Priority: optional Maintainer: Debian PHP PEAR Maintainers -Uploaders: Kevin Coyner +Uploaders: Paul Gevers Build-Depends: debhelper (>= 7.4~), phpab, pkg-php-tools (>= 1.7~) Standards-Version: 3.9.7 Homepage: https://github.com/PHPMailer/PHPMailer -Vcs-Git: git://anonscm.debian.org/pkg-php/libphp-phpmailer.git -Vcs-Browser: http://anonscm.debian.org/gitweb/?p=pkg-php/libphp-phpmailer.git +Vcs-Git: https://git.dgit.debian.org/libphp-phpmailer.git +Vcs-Browser: https://browse.dgit.debian.org/libphp-phpmailer.git Package: libphp-phpmailer Architecture: all signature.asc Description: OpenPGP digital signature
Bug#963287: notmuch: FTBFS: grotty: ():1662: fatal error: output error
On Mon, Jun 22, 2020 at 19:46:21 +0200, Michael Meskes wrote: > > Depending on bsdmainutils to get col et al seems entirely right, it's > > been right forever, there doesn't seem to be a reason to break that > > both > > for dependent packages and for end users. Especially not without > > notice. > > There is no point arguing against your "do not change anything" > attitude. > I'm not saying don't change anything, I'm saying don't break stuff for users for no reason. Cheers, Julien
Bug#963511: ITP: prometheus-tplink-plug-exporter -- Prometheus exporter for TP-Link Smart plug metrics
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij * Package name: prometheus-tplink-plug-exporter Version : 0.2.0 Upstream Author : fffonion * URL : https://github.com/fffonion/tplink-plug-exporter * License : BSD-2 Programming Lang: Go Description : Prometheus exporter for TP-Link Smart plug metrics Prometheus exporter for TP-Link Smart Plugs that provide power measurements.
Bug#963510: gsmartcontrol: fails to load on fresh Debian 10 install
Package: gsmartcontrol Version: 1.1.3-2 Severity: important Dear Maintainer, * What led up to the situation? Fresh install of Debian 10 (debian-live-10.4.0-amd64-gnome.iso). Installed gsmartcontrol using the gui "Software" interface. * What exactly did you do (or not do) that was effective (or ineffective)? Used the dash to find and start gsmartcontrol. Entered password when prompted for elevated permissions by the gui interface. * What was the outcome of this action? Gsmartcontrol does not load. * What outcome did you expect instead? Gsmartcontrol loads correctly. * What extra things did you try? 1) Check user account elevated privelages work: Installed and verified that gparted runs fine with elevated privileges - so user account works fine. 2) Ran from cli and received some errors: :~$ gsmartcontrol-root No protocol specified Unable to init server: Could not connect: Connection refused (gsmartcontrol:4088): Gtk-WARNING **: 19:23:32.852: cannot open display: :0 3) Looked about for some similar problems and found references to privilege elevation issues with GUI programs requiring root access under Wayland. Wrote a script which loads gsmartcontrol through an xhost hack: #!/bin/bash xhost si:localuser:root gsmartcontrol-root xhost -si:localuser:root Which allows the program to load. I suspect something is wrong with the polkit config. -- System Information: Debian Release: 10.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-9-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gsmartcontrol depends on: ii libatk1.0-0 2.30.0-2 ii libatkmm-1.6-1v5 2.28.0-2 ii libc62.28-10 ii libcairo-gobject21.16.0-4 ii libcairo21.16.0-4 ii libcairomm-1.0-1v5 1.12.2-4 ii libfribidi0 1.0.5-3.1+deb10u1 ii libgcc1 1:8.3.0-6 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libglib2.0-0 2.58.3-2+deb10u2 ii libglibmm-2.4-1v52.58.0-2 ii libgtk-3-0 3.24.5-1 ii libgtkmm-3.0-1v5 3.24.0-2 ii libpango-1.0-0 1.42.4-8~deb10u1 ii libpangocairo-1.0-0 1.42.4-8~deb10u1 ii libpangomm-1.4-1v5 2.42.0-2 ii libpcre3 2:8.39-12 ii libpcrecpp0v52:8.39-12 ii libsigc++-2.0-0v52.10.1-2 ii libstdc++6 8.3.0-6 ii smartmontools6.6-1 gsmartcontrol recommends no packages. gsmartcontrol suggests no packages. -- no debconf information
Bug#532150: Bug#865792: reportbug: Allow an arbitrary MUA to be configured (patch)
On Mon, Jun 22, 2020 at 9:27 AM Paul Wise wrote: > > On Mon, 2020-06-22 at 12:31 +0200, Nis Martensen wrote: > > > The current MUA support in reportbug has two main limitations: > > Just importing the MUA handling from reportbug-ng would solve most of > these, including the gmail case. Preferably the MUA handling > from reportbug-ng and reportbug should be factored out into a Python > MUA module that reportbug would then switch to. Unfortunately, the patch under discussion is three years old. I made it after determining that reportbug-ng wouldn't do it for me, but I don't remember what the problem was, and don't know what might have happened since to resolve my issue. Not much help there. > > We could provide an example wrapper script in > > /usr/share/doc/reportbug/examples/custom-mua that turns this into a > > mailto URL and calls xdg-open with that. Users could copy that > > somewhere and make it executable. It would be great if this scheme > > would even allow using webmail services as mailto handlers. Hello, > > gnome-gmail. > > A script for opening a mail in the email composer of the user's > preferred MUA already exists and is called xdg-email. xdg-open and xdg-email are pretty much equivalent as far as this discussion goes. Again - three years. I don't remember if it was lack of foresight that led me to not incorporate xdg-* up front, or if there was a real problem. I seem to remember an issue with body formatting. That may have been gnome-gmail specific. On Mon, Jun 22, 2020 at 6:37 AM Nis Martensen wrote: > > ...Here my thoughts so far. I'm hoping to find time to get a solution into reportbug soon. > > The current MUA support in reportbug has two main limitations: > 1. It only allows a small fixed set of MUAs. > 2. It does not support passing attachments to the MUA. > ... > Comments, suggestions? If I can interpret, it sounds like there are two options on the table - something looking like https://salsa.debian.org/reportbug-team/reportbug/-/merge_requests/24, or a reportbug-ng port. The MR needs, at a minimum, elimination of the version option, and clarity in the documentation re supported and unsupported MUAs. More complete attachment support would be gravy. Eliminating the concept of the MUA from reportbug would be attractive. Require xdg support? My needs follow the patch path. If consensus favors that, I can work it.
Bug#963497: affects 963497
control: affects 963497 certbot thanks
Bug#963509: prospector: please upgrade to version 1.2
Package: prospector
Version: 1.1.7-2
Severity: wishlist
Hi,
There is an updated version of prospector right now on PyPI:
https://pypi.org/project/prospector/
In particular, according to its changelog, it fixes problems like what I
reported in bug 947551.
Considering that prospector isn't usable at all at the moment (I should
probably raise the severity of that bug, as a matter of documentation), it
would be really, really appreciated to have this upload of prospector.
Thanks,
Rogério Brito.
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing'), (200, 'unstable'), (150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.6.0-2-rt-amd64 (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.utf-8, LC_CTYPE=pt_BR.utf-8 (charmap=UTF-8),
LANGUAGE=en_US.utf-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages prospector depends on:
ii dodgy 0.1.9-3
ii libjs-sphinxdoc2.4.3-4
ii pylint 2.4.4-2
ii python33.8.2-3
ii python3-astroid2.3.3-1
ii python3-mccabe 0.6.1-3
ii python3-mypy 0.770-2
ii python3-pep8-naming0.9.1-1
ii python3-pycodestyle2.5.0-3
ii python3-pydocstyle 2.1.1-1
ii python3-pyflakes 2.2.0-1
ii python3-pylint-celery 0.3-5
ii python3-pylint-django 2.0.13-1
ii python3-pylint-flask 0.5-4
ii python3-pylint-plugin-utils0.6-1
ii python3-pyroma 2.6b2-1
ii python3-requirements-detector 0.6-2
ii python3-setoptconf 0.2.0-5
ii python3-typed-ast 1.4.1-1+b1
ii python3-yaml 5.3.1-2
Versions of packages prospector recommends:
ii vulture 1.4-1
prospector suggests no packages.
-- no debconf information
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Bug#963495: affects 963495
control: affects 963495 reportbug thanks
Bug#960379: FTBFS again
Quoting Giovanni Mascellani (2020-06-22 18:40:50) > Bitcoin is FTBFSing again because of a missing dependency on > bsdextrautils (from which hexdump is used). Therefore I am uploading > another NMU fixing this. I am not delaying it, since I had no objections > on the first NMU and I believe this one to be uncontroversial. Thanks for your help! If you are interested, you are welcome to join the team and help maintain Bitcoin and related packages in general. Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#962827: libphp-phpmailer: CVE-2020-13625
Control: owner -1 ! Dear Debian PHP PEAR Maintainers, On Sun, 14 Jun 2020 21:23:30 +0200 Salvatore Bonaccorso wrote: > Source: libphp-phpmailer > Version: 6.1.5-0.1 > Severity: grave As it seems the team doesn't really care about libphp-phpmailer a lot, I intend to work on fixing this issue *and* adding myself as uploader. Unless somebody objects of course. Paul signature.asc Description: OpenPGP digital signature
Bug#963508: /lib/ld-linux.so.2: LD_PRELOAD breaks with plain filename
Package: libc6 Version: 2.28-10 Severity: normal File: /lib/ld-linux.so.2 Hi. I found this behaviour: $ eatmydata man ls >/dev/null ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. $ Experimenting shows that the problem is triggered by having LD_PRELOAD containing only the library name: $ faketime yesterday printenv | grep PREL LD_PRELOAD=libgtk3-nocsd.so.0:/usr/$LIB/faketime/libfaketime.so.1 $ faketime yesterday env LD_PRELOAD=libfaketime.so.1 man ls >/dev/null ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. $ The problem is not limited to man: $ faketime yesterday env LD_PRELOAD=libfaketime.so.1 dash -c true ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. $ This message on debian-user seems related: https://lists.debian.org/debian-user/2017/03/msg00335.html Colin Watson (CC'd) reports that sid works. Thanks for your attention. Ian. -- System Information: Debian Release: 10.4 APT prefers stable-debug APT policy: (500, 'stable-debug'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages libc6:i386 depends on: ii libgcc1 1:8.3.0-6 Versions of packages libc6:i386 recommends: ii libidn2-0 2.0.5-1+deb10u1 Versions of packages libc6:i386 suggests: ii debconf [debconf-2.0] 1.5.71 ii glibc-doc 2.28-10 ii libc-l10n 2.28-10 ii locales2.28-10 -- debconf information excluded
Bug#963287: notmuch: FTBFS: grotty: ():1662: fatal error: output error
> Depending on bsdmainutils to get col et al seems entirely right, it's > been right forever, there doesn't seem to be a reason to break that > both > for dependent packages and for end users. Especially not without > notice. There is no point arguing against your "do not change anything" attitude. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#963287: notmuch: FTBFS: grotty: ():1662: fatal error: output error
On Mon, Jun 22, 2020 at 19:04:49 +0200, Michael Meskes wrote: > > I think it's probably best at this point to have bsdmainutils depend > > on > > bsdextrautils. That gets rid of the breakage in the place where it > > originated, and doesn't leave things without a transition path. > > I beg to disagree, there is a transition plan, namely depending on the > right package. Things change, that's what unstable is for. Depending on > bsdmainutils to get bsdextrautils does not sound right to me. > Depending on bsdmainutils to get col et al seems entirely right, it's been right forever, there doesn't seem to be a reason to break that both for dependent packages and for end users. Especially not without notice. Cheers, Julien
Bug#963377: xterm: FTBFS: /bin/sh: 1: col: not found
On 2020-06-21 17:11 -0400, Thomas Dickey wrote: > On Sun, Jun 21, 2020 at 10:13:41PM +0200, Lucas Nussbaum wrote: >> Source: xterm >> Version: 356-1 >> Severity: serious >> Justification: FTBFS on amd64 >> Tags: bullseye sid ftbfs >> Usertags: ftbfs-20200620 ftbfs-bullseye >> >> Hi, >> >> During a rebuild of all packages in sid, your package failed to build >> on amd64. > > col's in bsdmainutils It used to be there, but has recently been moved to bsdextrautils. This has caused a lot of breakage, so bsdmainutils ought to depend on bsdextrautils for the time being to fix that. However… >> > GROFF_NO_SGR=stupid /bin/sh -c "tbl ../ctlseqs.ms | groff -Tascii -ms | >> > col -bx" >../ctlseqs.txt >> > /bin/sh: 1: col: not found >> > make[2]: *** [Makefile:180: ../ctlseqs.txt] Error 127 > > refer to > > xterm (332-1) unstable; urgency=medium > > * Regenerate ctlseqs.txt from ctlseqs.ms (Closes: #848818). > > - Add groff to Buils-Depends. …I should also have added a build dependency on bsdmainutils there. That package is already pulled in via debhelper → man-db → bsdmainutils, so I overlooked it. I have just uploaded xterm 356-2 with bsdextrautils | bsdmainutils (<< 12.1.1~) added to Build-Depends. Cheers, Sven
Bug#963507: ifupdown: networking.service starts before rdma-load-modules@infiniband.service
Package: ifupdown Version: 0.8.19 Severity: normal Tags: patch Hi, we use ifupdown to configure IPoIB devices. The normal workflow is that udev loads the kernel modules for InfiniBand and activates `rdma-load-modules@infiniband.service`, which loads `ib_ipoib`. Then `networking.service` runs afterwards and configures the IPoIB devices. We had one system where `networking.service` was started before `rdma-load-modules@infiniband.service` and therefore failed to configure the IPoIB devices: ``` $ zgrep --color '\(RDMA\|Reached target\|Raise network\)' /var/log/syslog.1.gz | head -n 23 Jun 18 21:50:19 systemd[1]: Started Load RDMA modules from /etc/rdma/modules/srp_daemon.conf. Jun 18 21:50:19 systemd[1]: Reached target Local File Systems (Pre). Jun 18 21:50:19 systemd[1]: Reached target Local File Systems. Jun 18 21:50:19 systemd[1]: Reached target System Time Synchronized. Jun 18 21:50:19 systemd[1]: Reached target System Initialization. Jun 18 21:50:19 systemd[1]: Reached target Sockets. Jun 18 21:50:19 systemd[1]: Reached target Basic System. Jun 18 21:50:19 systemd[1]: Reached target Timers. Jun 18 21:50:19 systemd[1]: Reached target Network (Pre). Jun 18 21:50:20 systemd[1]: Starting Raise network interfaces... Jun 18 21:50:20 systemd[1]: Starting Load RDMA modules from /etc/rdma/modules/infiniband.conf... Jun 18 21:50:20 systemd[1]: Starting Load RDMA modules from /etc/rdma/modules/rdma.conf... Jun 18 21:50:20 systemd[1]: Starting RDMA Node Description Daemon... Jun 18 21:50:20 systemd[1]: Starting Load RDMA modules from /etc/rdma/modules/roce.conf... Jun 18 21:50:20 systemd[1]: Started RDMA Node Description Daemon. Jun 18 21:50:20 systemd[1]: Started Load RDMA modules from /etc/rdma/modules/roce.conf. Jun 18 21:50:20 systemd[1]: Started Load RDMA modules from /etc/rdma/modules/rdma.conf. Jun 18 21:50:21 systemd[1]: Started Load RDMA modules from /etc/rdma/modules/infiniband.conf. Jun 18 21:50:21 systemd[1]: Reached target RDMA Hardware. Jun 18 21:50:21 systemd[1]: Failed to start Raise network interfaces. Jun 18 21:50:21 systemd[1]: Reached target Network. Jun 18 21:50:22 systemd[1]: Reached target Network is Online. Jun 18 21:50:28 systemd[1]: Reached target Login Prompts. ``` `rdma-load-modules@.service` declares to run before `network-pre.target`, but when udev triggers `rdma-load-modules@infiniband.service`, the `network-pre.target` is already passed and therefore `networking.service` does not wait for `rdma-load-modules@infiniband.service` to finish. So I suggest to let `ifupdown-pre.service` declare to run before `network-pre.target`. That way it is ensured that `rdma-load-modules@infiniband.service` is activated before `network-pre.target` is reached. As alternative, `rdma-load-modules@.service` could declare to run before `networking.service` in addition to `networking-pre.target`. -- Benjamin Drung DevOps Engineer and Debian & Ubuntu Developer Platform Integration (IONOS Cloud) 1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498 Vorstand: Dr. Christian Böing, Hüseyin Dogan, Dr. Martin Endreß, Hans-Henning Kettler, Arthur Mai, Matthias Steinberg, Achim Weiß Aufsichtsratsvorsitzender: Markus Kadelke Member of United Internet
Bug#963287: notmuch: FTBFS: grotty: ():1662: fatal error: output error
> I think it's probably best at this point to have bsdmainutils depend > on > bsdextrautils. That gets rid of the breakage in the place where it > originated, and doesn't leave things without a transition path. I beg to disagree, there is a transition plan, namely depending on the right package. Things change, that's what unstable is for. Depending on bsdmainutils to get bsdextrautils does not sound right to me. We have to make the change eventually. And keep in mind that there may be other breakages as we changed sources for col et al. I am not aware of any, and I assume Chris isn't either, but there still may be some incompatibilities. I don't see the point of postponing the switch. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#963287: notmuch: FTBFS: grotty: ():1662: fatal error: output error
> I don't know what Julien had in mind, presumably worried about other > breakage to surface. Note that obvious fix to man-db will all > debhelper > using packages transitively build-depending on bsdextrautils. Instead of bsdmainutils, yes. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#962917: libatomic-ops: FTBFS in the testsuite on riscv64 due to missing -pthread
On Sat, Jun 20, 2020 at 12:20:14AM +0300, Ivan Maidanski wrote: > Please disregard my previous patch, and use the following one: > https://github.com/ivmai/libatomic_ops/commit/f067c258d5df3dc364857c11718be4516ca73ea0.patch > > Karsten, could you please test it? Hello, will do, but it will probably take some days. Yesterday my computer's system drive started showing massive malfunctions and I'm currently waiting for a replacement to be delivered so that I can get the system up again. Regards, Karsten -- Hiermit widerspreche ich ausdrücklich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung.
Bug#950052: please warn for files installed into /
Hi Mattia, On Mon, Jun 22, 2020 at 9:40 AM Mattia Rizzolo wrote: > > However, please do try to judge the proposals Actually, I implement them so you and the community can judge. Kind regards Felix Lechner
Bug#963505: ITP: golang-github-otiai10-copy -- Golang copy directory recursively
Package: wnpp
Severity: wishlist
Owner: Pirate Praveen
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org
* Package name : golang-github-otiai10-copy
Version : 1.2.0-1
Upstream Author : Hiromu OCHIAI
* URL : https://github.com/otiai10/copy
* License : Expat
Programming Lang: Go
Description : Golang copy directory recursively
copies directories recursively.
.
Example:
.
go err := Copy("your/directory", "your/directory.copy")
Build dependency of gitlab-shell.
Bug#960379: FTBFS again
Bitcoin is FTBFSing again because of a missing dependency on bsdextrautils (from which hexdump is used). Therefore I am uploading another NMU fixing this. I am not delaying it, since I had no objections on the first NMU and I believe this one to be uncontroversial. Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#950052: please warn for files installed into /
Noted. Let's see what it'll yield. However, please do try to judge the proposals, instead of very blindly implement them. Arguing might be unproductive but, as I mentioned in the past, generally annoying and likely inactionable tags are likewise very unproductive for us! :) On Mon, 22 Jun 2020, 6:24 pm Felix Lechner, wrote: > Hi Mattia, > > On Mon, Jun 22, 2020 at 8:58 AM Mattia Rizzolo wrote: > > > > I don't think I have much voice here, but tbh I feel like this is > totally artificially adding > > restraints that have no real reason to exist. > > That sweeping statement does not cover either (1) the accidental > installation errors that can occur when people use cp(1) instead of > install(1) to copy files, or (2) the degradation of style and > placement logic that happens with repetitive paths. > > > It's alright to think that at times this might be hiding a packaging > error, but honestly most of > > those case are usually self-evident and IME very rarely are a real > problem. > > Please remember I am closing bugs for requested features. I do not > argue much because I find it unproductive. Instead, I implement > everything that is remotely reasonable. > > I, too, have found repetitive paths annoying in the past, and have > seen installation errors in which a destination folder was > accidentally duplicated. > > Let's reserve judgment until we see how the check performs in the > wild. In the end, you may well be right. But we don't know that yet. > > Kind regards > Felix Lechner >
Bug#963287: notmuch: FTBFS: grotty: ():1662: fatal error: output error
On Mon, Jun 22, 2020 at 13:37:56 -0300, David Bremner wrote: > Michael Meskes writes: > > > On Mon, 2020-06-22 at 11:37 -0300, David Bremner wrote: > >> Michael Meskes writes: > >> > >> > > IMO the move of col needs to be rolled back ASAP. And, if it is > >> > > to > >> > > >> > Why? Care to give a reason? > >> > > >> > >> The change broke man-db, as I explained in a previous message. > > > > Oh, that I understand and I'm sorry I didn't notice that issue before, > > but why is rolling back preferable over fixing man-db? > > I don't know what Julien had in mind, presumably worried about other > breakage to surface. Note that obvious fix to man-db will all debhelper > using packages transitively build-depending on bsdextrautils. > I think it's probably best at this point to have bsdmainutils depend on bsdextrautils. That gets rid of the breakage in the place where it originated, and doesn't leave things without a transition path. Cheers, Julien
Bug#963287: notmuch: FTBFS: grotty: ():1662: fatal error: output error
Michael Meskes writes: > On Mon, 2020-06-22 at 11:37 -0300, David Bremner wrote: >> Michael Meskes writes: >> >> > > IMO the move of col needs to be rolled back ASAP. And, if it is >> > > to >> > >> > Why? Care to give a reason? >> > >> >> The change broke man-db, as I explained in a previous message. > > Oh, that I understand and I'm sorry I didn't notice that issue before, > but why is rolling back preferable over fixing man-db? I don't know what Julien had in mind, presumably worried about other breakage to surface. Note that obvious fix to man-db will all debhelper using packages transitively build-depending on bsdextrautils. d
Bug#963504: ITP: novaworx- Novaworx IDE
Package: wnpp Severity: wishlist * Package name : libnovaworx-syntax Version : 0.0.7 Upstream Author : Mark Soderquist * URL : https://sourceforge.net/projects/novaworx/ * License : GPL-2+ Programming Lang: Java Description : Novaworx IDE Provides the library novaworx-syntax which is a dependency of J-Lawyer-Client (ITP:#962415) * Why is this package useful/relevant? * Is it a dependency for another package? Yes * Do you use it yourself? * If there are other packages providing similar functionality, how does it compare? * How do you plan to maintain it? Do you plan to maintain it inside a packaging team? (check list at https://wiki.debian.org/Teams) I want to maintain it inside the Java-Team * Are you looking for co-maintainers? Do you need a sponsor? No ...-- Mechtilde Stehmann ## Debian Developer ## PGP encryption welcome ## F0E3 7F3D C87A 4998 2899 39E7 F287 7BBA 141A AD7F signature.asc Description: OpenPGP digital signature
Bug#950052: please warn for files installed into /
Hi Mattia, On Mon, Jun 22, 2020 at 8:58 AM Mattia Rizzolo wrote: > > I don't think I have much voice here, but tbh I feel like this is totally > artificially adding > restraints that have no real reason to exist. That sweeping statement does not cover either (1) the accidental installation errors that can occur when people use cp(1) instead of install(1) to copy files, or (2) the degradation of style and placement logic that happens with repetitive paths. > It's alright to think that at times this might be hiding a packaging error, > but honestly most of > those case are usually self-evident and IME very rarely are a real problem. Please remember I am closing bugs for requested features. I do not argue much because I find it unproductive. Instead, I implement everything that is remotely reasonable. I, too, have found repetitive paths annoying in the past, and have seen installation errors in which a destination folder was accidentally duplicated. Let's reserve judgment until we see how the check performs in the wild. In the end, you may well be right. But we don't know that yet. Kind regards Felix Lechner
Bug#949196: libzypp: diff for NMU version 17.7.0-1.1
Hi, Il 20/06/20 19:01, Mike Gabriel ha scritto: > Thanks for patching libzypp. Your NMU is ok, I will include your > .debdiff on its VCS. In fact, I am considering orphaning libzypp and > zypper in Debian. Do you have interest in taking over? Ugh, I just realized I stupidly embedded the amd64 architecture in my patch, leading to obvious FTBFS on the other archs. It is ok for you if I directly NMU libzypp replacing x86_64-linux-gnu with $(DEB_HOST_MULTIARCH)? Thanks, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#950052: please warn for files installed into /
I don't think I have much voice here, but tbh I feel like this is totally artificially adding restraints that have no real reason to exist. It's alright to think that at times this might be hiding a packaging error, but honestly most of those case are usually self-evident and IME very rarely are a real problem. On Mon, 22 Jun 2020, 5:39 pm Felix Lechner, wrote: > Hi Chris, > > On Mon, Jun 22, 2020 at 7:57 AM Chris Lamb wrote: > > > > P: lintian: repeated-path-segment usr usr/share/lintian/checks/usr/ > lib.pm > > Also solved by renaming, in commit 68b72cd0. > > Kind regards > Felix Lechner > >
Bug#963502: RFS: lwatch/0.6.2-2 -- Simple log colorizer
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "lwatch" * Package name: lwatch Version : 0.6.2-2 Upstream Author : Artur R. Czechowski * URL : https://sourceforge.net/projects/lwatch * License : GPL-2 * Vcs : None Section : admin It builds those binary packages: lwatch - Simple log colorizer To access further information about this package, please visit the following URL: https://mentors.debian.net/package/lwatch Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/l/lwatch/lwatch_0.6.2-2.dsc Changes since the last upload: * QA upload. * Run wrap-and-sort. * Set Debian QA Group as maintainer. (see #809234) * Using new DH level format. Consequently: - debian/compat: removed. - debian/control: changed from 'debhelper' to 'debhelper-compat' in Build-Depends field and bumped level to 13. * debian/control: - Added homepage field. - Added 'Rules-Requires-Root: no' to source stanza. - Bumped Standards-Version to 4.5.0. - Removed lwatch-dbg package because now is normally autogenerated. * debian/copyright: - Migrated to new format 1.0. - Updated all data. * debian/dirs: removed usr/sbin field. * debian/patches/010_fix-spelling-error.patch: created to fix spelling errors. * debian/rules: - Added DEB_BUILD_MAINT_OPTIONS variable to improve GCC hardening. - Migrated to new (reduced) format. * debian/tests/control: created to perform CI test. * debian/upstream/metadata: created. * debian/watch: updated. Regards, Gleisson
Bug#959995: coreutils: Please package new upstream release (8.32)
Hi Michael, I would like to second Boyuan's wish for updating this package. Is there anything blocking the switch to version 8.32? Regards, Thorsten
Bug#963211: libmu-dbm6: Tries to overwrite `libmu_dbm.so.6.0.0` from `libmailutils6`
Control: severity -1 serious On Sat, 20 Jun 2020 18:08:58 +0200 Paul Menzel wrote: > Package: libmu-dbm6 > Version: 1:3.9-2 > > > Dear Debian folks, > > > Trying to update my Debian Sid/unstable system, `apt full-upgrade` > failed with the messages below. > > > dpkg: Fehler beim Bearbeiten des Archivs /tmp/apt-dpkg-install-9C7NlK/00-libmu-dbm6_1%3a3.9-2_i386.deb (--unpack): > > Versuch, »/usr/lib/i386-linux-gnu/libmu_dbm.so.6.0.0« zu überschreiben, welches auch in Paket libmailutils6:i386 1:3.7-2.1 ist > > dpkg-deb: Fehler: »einfügen«-Unterprozess wurde durch Signal (Datenübergabe unterbrochen (broken pipe)) getötet > > It looks like some conflict needs to be added? Raising severity to serious since this makes the package uninstallable
Bug#963430: Any volunteer to spent some time on the new version of artemis (Was: Bug#963430: artemis: FTBFS: /bin/sh: 1: /usr/share/java/j2ssh-core.jar: Permission denied)
Hi Emmanuel, Le 22/06/2020 à 16:30, Andreas Tille a écrit : > Hi Emmanuel, > > On Mon, Jun 22, 2020 at 10:57:15AM -0300, Emmanuel Arias wrote: >> I would be happy to help on artemis. Obviously I will need >> a more experienced developer helping me. :) > > I'll try hard to answer any question you might rise here on > this list (no matter how basic it might be) if you volunteer > to work on Artemis (or any other package). > > Thanks a lot for your commitment > > Andreas. > If you need it, I will be very happy to try to help you, based on my recent Java packaging tasks. All the best, Pierre
Bug#963501: haskell-wl-pprint-terminfo: Removal notice: broken and unmaintained
Source: haskell-wl-pprint-terminfo Version: 3.7.1.4-7 Severity: grave Justification: renders package unusable This package seems to be unmaintained (last upstream upload in 2016). It depends on the (broken) haskell-wl-pprint-extras, is not part of Stackage and has no rev dependencies. I intend to remove this package. -- Ilias
Bug#963499: haskell-wl-pprint-extras: Removal notice: broken and unmaintained
Source: haskell-wl-pprint-extras Version: 3.5.0.5-9 Severity: grave Justification: renders package unusable This package seems to be unmaintained (last upstream upload in 2015). Does not build with GHC 8.8 and is not part of Stackage. Its only rev-dep (haskell-wl-pprint-terminfo) is also unmaintained and should be removed. I intend to remove this package. -- Ilias
Bug#963500: ITP: smartleia -- A Python toolkit for LEIA board control
Package: wnpp Severity: wishlist Owner: phi...@debian.org * Package name: smartleia Version : 0.2.1 Upstream Author : D. El-Baze, R. Benadjila, M. Renard, P. Trebuchet, P. Thierry * URL : https://github.com/cw-leia/smartleia * License : LGPL2+ Programming Lang: Python Section : libs Description : A complete toolkit to interact with Leia board virtual smartcard driver Allows to use PCSC and OpenSC tools to communicate with Leia-connected Smartcards thanks, -- Philippe THIERRY signature.asc Description: PGP signature
Bug#960886: dnetc does not need restarting after log rotate
Ping
Bug#950052: please warn for files installed into /
Hi Chris, On Mon, Jun 22, 2020 at 7:57 AM Chris Lamb wrote: > > P: lintian: repeated-path-segment usr usr/share/lintian/checks/usr/lib.pm Also solved by renaming, in commit 68b72cd0. Kind regards Felix Lechner
Bug#963357: marked as pending in libtest-redisserver-perl
On Mon, 22 Jun 2020 00:37:00 +0200, gregor herrmann wrote: > Well, yes, except that the build fails on the buildd: > https://buildd.debian.org/status/fetch.php?pkg=libtest-redisserver-perl=all=0.21-2=1592776913=0 The give-back hit a not-ipv6-only host and succeeded. Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Rolling Stones: Driftaway signature.asc Description: Digital Signature
Bug#963472: qemu-system-data: Embeds user and host in slof.bin
On 2020-06-22, Michael Tokarev wrote: > 22.06.2020 07:26, Vagrant Cascadian wrote: > ... >> -RELEASE="$(USER)@$(HOSTNAME) release $(shell cat ../VERSION)" >> +RELEASE="release $(shell cat ../VERSION)" > > Here and in other similar places, how about using RELEASE=... > explicitly in the parent makefile (which is d/rules) instead > of patching? For the most part, whatever works! > I dunno, I'm just a bit dislike patching and prefer to override > a variable like this if it's possible. > > Patch is good in a way that it works as long as the problem place > stays the same, - so that if anything there changes (including the > case when the patch isn't needed anymore), we'll have to revisit > it at least. If the patches are upstreamable (many would need reworking), then getting them upstream would help other distros working on reproducibile builds, rather than just working around it in debian/rules for Debian. > Somewhat similar is the situation with LC_* variables, - sometimes > I just export LC_ALL=C in the top of d/rules and be done with it, > after that I don't care how well the upstream build system deals > with various intl. stuff. Note that sometimes non-C locale might > expose difficult to debug bugs, - for example, in the C locale > the order of upper- and lower-case letters (first all uppercase > next all lowercase) is different than in some other locales, > like in RU, where upper and lower-case is intermixed (first Aa, > next Bb etc), - so when doing thigs like $(ls -1 | head ..) > we might have entirely different results. > > What do you think? Other than the potential for upstreaming, that sounds good too. If just going the debian/rules route, I'd recommend using LC_ALL=C.UTF-8, although it's not in upstream glibc, it's always available in Debian and gets you UTF-8 out of the box. Though I haven't tested on all locales, the sort order seems to be more consistant across UTF-8 locales, though haven't tested all locales. > And thank you for debugging all this! Thanks for the quick response! It's been a bit different building on a 32-core machine with ~150GB of ram than my old dual-core with 4GB of ram back when I used to maintain qemu... :) live well, vagrant signature.asc Description: PGP signature
Bug#963498: org.kde.kdeconnect_open.desktop": "*/*" is an invalid MIME type
Package: kdeconnect
Version: 20.04.2-1
Severity: minor
Tags: upstream
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I believe this was just introduced with 20.04.2-1. Updating
the MIME info installing other packages prints
Error in file "/usr/share/applications/org.kde.kdeconnect_open.desktop":
"*/*" is an invalid MIME type ("*" is an unregistered media type)
and it says
MimeType=*/*;
I do not know a solution since it seems it's meant to handle arbitrary
file types.
- -- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing'), (2, 'unstable'), (1, 'testing-debug'), (1,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.6.0-2-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages kdeconnect depends on:
ii kde-cli-tools 4:5.17.5-2
ii kio 5.70.1-1
ii libc6 2.30-8
ii libfakekey0 0.1-10+b1
ii libkf5configcore5 5.70.0-1
ii libkf5configwidgets5 5.70.0-1
ii libkf5coreaddons5 5.70.0-1
ii libkf5dbusaddons5 5.70.0-1
ii libkf5i18n5 5.70.0-1
ii libkf5iconthemes5 5.70.0-1
ii libkf5kcmutils5 5.70.0-1
ii libkf5kiocore55.70.1-1
ii libkf5kiofilewidgets5 5.70.1-1
ii libkf5kiowidgets5 5.70.1-1
ii libkf5notifications5 5.70.0-1
ii libkf5people5 5.70.0-1
ii libkf5pulseaudioqt2 1.2-2
ii libkf5service-bin 5.70.0-1
ii libkf5service55.70.0-1
ii libkf5waylandclient5 4:5.70.0-1
ii libkf5widgetsaddons5 5.70.0-1
ii libqca-qt5-2 2.2.1-2
ii libqca-qt5-2-plugins 2.2.1-2
ii libqt5core5a 5.12.5+dfsg-10+b1
ii libqt5dbus5 5.12.5+dfsg-10+b1
ii libqt5gui55.12.5+dfsg-10+b1
ii libqt5multimedia5 5.12.5-1+b1
ii libqt5network55.12.5+dfsg-10+b1
ii libqt5qml55.12.5-5
ii libqt5quick5 5.12.5-5
ii libqt5widgets55.12.5+dfsg-10+b1
ii libqt5x11extras5 5.12.5-1
ii libstdc++610.1.0-3
ii libx11-6 2:1.6.9-2+b1
ii libxtst6 2:1.2.3-1
ii plasma-framework 5.70.1-1
ii qml-module-org-kde-kirigami2 5.70.0-1
ii qml-module-org-kde-people 5.70.0-1
ii qml-module-qtquick-controls 5.12.5-1+b1
ii qml-module-qtquick-controls2 5.12.5+dfsg-2+b1
ii qml-module-qtquick-layouts5.12.5-5
ii qml-module-qtquick2 5.12.5-5
ii sshfs 3.7.0+repack-1
kdeconnect recommends no packages.
Versions of packages kdeconnect suggests:
pn python-nautilus
- -- no debconf information
-BEGIN PGP SIGNATURE-
iHUEARYIAB0WIQT287WtmxUhmhucNnhyvHFIwKstpwUCXvDIWQAKCRByvHFIwKst
pySiAQCI5m4kHODQkR6FGUEy5nTXGH1uDSIFljEqskLBWL4uPgEAr6h1hiyqCzio
xeL9MSpnXJsRkx3z/guUMpkDilIkXwo=
=6Kgt
-END PGP SIGNATURE-
Bug#963287: notmuch: FTBFS: grotty: ():1662: fatal error: output error
On Mon, 2020-06-22 at 11:37 -0300, David Bremner wrote: > Michael Meskes writes: > > > > IMO the move of col needs to be rolled back ASAP. And, if it is > > > to > > > > Why? Care to give a reason? > > > > The change broke man-db, as I explained in a previous message. Oh, that I understand and I'm sorry I didn't notice that issue before, but why is rolling back preferable over fixing man-db? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#963332: ariba: FTBFS: dh_auto_test: error: pybuild --test --test-nose -i python{version} -p 3.8 returned exit code 13
On Mon, Jun 22, 2020 at 04:41:10PM +0200, Sascha Steinbiss wrote: > > That's because it is not an error: ariba supports multiple assemblers, Sure its not an error - but I've thought that testing what *can* be tested might not harm. > and by default it looks like the much more lightweight fermi-lite > (libfml) is used. Hence I wouldn't depend on it; it might be a good > Suggestion though? You are the expert. A grep uncovered some instances of the string spades. I have no idea whether Recommends or Suggests is correct and totally leave it to your insight. Kind regards Andreas. -- http://fam-tille.de
Bug#950052: please warn for files installed into /
Felix Lechner wrote: > > Up to you. > > In commit 1b9e1048, I went with option #2. Thanks. As of f938c5480, we are still seeing it for: P: lintian: repeated-path-segment usr usr/share/lintian/checks/usr/lib.pm Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#963332: ariba: FTBFS: dh_auto_test: error: pybuild --test --test-nose -i python{version} -p 3.8 returned exit code 13
Hi Andreas,
thanks for your email!
[Test failures]
[...]
>>> --
>>> Ran 356 tests in 57.387s
>>>
>>> FAILED (SKIP=2, errors=6)
>>> E: pybuild pybuild:352: test: plugin distutils failed with: exit code=1: cd
>>> /<>/.pybuild/cpython3_3.8_ariba/build; python3.8 -m nose -v
>>> dh_auto_test: error: pybuild --test --test-nose -i python{version} -p 3.8
>>> returned exit code 13
>
> It seems the test failures are all connected to pymummer which was
> upgraded recently.
Okay, I can take a look.
> BTW, I've added a (Build-)Depends on spades which also shows up in the
> test log as missing without causing an actual error.
That's because it is not an error: ariba supports multiple assemblers,
and by default it looks like the much more lightweight fermi-lite
(libfml) is used. Hence I wouldn't depend on it; it might be a good
Suggestion though?
Best regards
Sascha
signature.asc
Description: OpenPGP digital signature
Bug#963287: notmuch: FTBFS: grotty: ():1662: fatal error: output error
Michael Meskes writes: >> IMO the move of col needs to be rolled back ASAP. And, if it is to > > Why? Care to give a reason? > The change broke man-db, as I explained in a previous message. d
Bug#963430: Any volunteer to spent some time on the new version of artemis (Was: Bug#963430: artemis: FTBFS: /bin/sh: 1: /usr/share/java/j2ssh-core.jar: Permission denied)
Hi Emmanuel, On Mon, Jun 22, 2020 at 10:57:15AM -0300, Emmanuel Arias wrote: > I would be happy to help on artemis. Obviously I will need > a more experienced developer helping me. :) I'll try hard to answer any question you might rise here on this list (no matter how basic it might be) if you volunteer to work on Artemis (or any other package). Thanks a lot for your commitment Andreas. -- http://fam-tille.de
Bug#963287: notmuch: FTBFS: grotty: ():1662: fatal error: output error
> IMO the move of col needs to be rolled back ASAP. And, if it is to Why? Care to give a reason? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#963497: selinux-policy-default: Let's Encrypt certbot tools crashed into Segmentation fault with SELinux Enforcing mode
Package: selinux-policy-default
Version: 2:2.20161023.1-9
Severity: grave
Justification: renders package unusable
Control: -1 = certbot
Dear Maintainer,
I have tried to run Apache server with Let's Encrypt security
certificates. I enabled SELinux in Enforcing mode.
I've installed certbot with dependent pacheges.
And when I try to run it, certbot command failed with error Segmentation
fault:
***
root@vps:~# getenforce
Enforcing
root@vps:~# certbot --apache -d virt.domain -d www.virt.domain
Segmentation fault
root@vps:~# man certbot
root@vps:~# certbot --apache -d virt.domain -d www.virt.domain --debug
Segmentation fault
root@vps:~#
***
There is auth.log messages when certbot fired:
***
root@vps:/etc/bind# grep certbot /var/log/audit/audit.log
type=AVC msg=audit(1592778047.217:76615): avc: denied { execmem } for
pid=22641 comm="certbot"
scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process
permissive=0
type=SYSCALL msg=audit(1592778047.217:76615): arch=c03e syscall=9
success=no exit=-13 a0=0 a1=1000 a2=7 a3=22 items=0 ppid=17778 pid=22641 auid=0
uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts4 ses=1405
comm="certbot" exe="/usr/bin/python3.5"
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
type=ANOM_ABEND msg=audit(1592778047.221:76616): auid=0 uid=0 gid=0 ses=1405
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=22641
comm="certbot" exe="/usr/bin/python3.5" sig=11
type=AVC msg=audit(1592778051.169:76617): avc: denied { execmem } for
pid=22643 comm="certbot"
scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process
permissive=0
type=SYSCALL msg=audit(1592778051.169:76617): arch=c03e syscall=9
success=no exit=-13 a0=0 a1=1000 a2=7 a3=22 items=0 ppid=17778 pid=22643 auid=0
uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts4 ses=1405
comm="certbot" exe="/usr/bin/python3.5"
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
type=ANOM_ABEND msg=audit(1592778051.173:76618): auid=0 uid=0 gid=0 ses=1405
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=22643
comm="certbot" exe="/usr/bin/python3.5" sig=11
type=AVC msg=audit(1592778288.940:76901): avc: denied { execmem } for
pid=23208 comm="certbot"
scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process
permissive=0
type=SYSCALL msg=audit(1592778288.940:76901): arch=c03e syscall=9
success=no exit=-13 a0=0 a1=1000 a2=7 a3=22 items=0 ppid=17778 pid=23208 auid=0
uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts4 ses=1405
comm="certbot" exe="/usr/bin/python3.5"
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
type=ANOM_ABEND msg=audit(1592778288.944:76902): auid=0 uid=0 gid=0 ses=1405
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=23208
comm="certbot" exe="/usr/bin/python3.5" sig=11
type=AVC msg=audit(1592778319.924:76911): avc: denied { execmem } for
pid=23219 comm="certbot"
scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process
permissive=0
type=SYSCALL msg=audit(1592778319.924:76911): arch=c03e syscall=9
success=no exit=-13 a0=0 a1=1000 a2=7 a3=22 items=0 ppid=17778 pid=23219 auid=0
uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts4 ses=1405
comm="certbot" exe="/usr/bin/python3.5"
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
type=ANOM_ABEND msg=audit(1592778319.928:76912): auid=0 uid=0 gid=0 ses=1405
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=23219
comm="certbot" exe="/usr/bin/python3.5" sig=11
type=AVC msg=audit(1592824753.138:84440): avc: denied { execmem } for
pid=26179 comm="certbot" scontext=system_u:system_r:initrc_t:s0
tcontext=system_u:system_r:initrc_t:s0 tclass=process permissive=0
type=SYSCALL msg=audit(1592824753.138:84440): arch=c03e syscall=9
success=no exit=-13 a0=0 a1=1000 a2=7 a3=22 items=0 ppid=1 pid=26179
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=(none) ses=4294967295 comm="certbot" exe="/usr/bin/python3.5"
subj=system_u:system_r:initrc_t:s0 key=(null)
type=ANOM_ABEND msg=audit(1592824753.142:84441): auid=4294967295 uid=0 gid=0
ses=4294967295 subj=system_u:system_r:initrc_t:s0 pid=26179 comm="certbot"
exe="/usr/bin/python3.5" sig=11
type=SERVICE_START msg=audit(1592824753.150:84442): pid=1 uid=0 auid=4294967295
ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=certbot
comm="systemd" exe="/lib/systemd/systemd" hostname=? addr=? terminal=?
res=failed'
type=AVC msg=audit(1592832902.769:84609): avc: denied { execmem } for
pid=26849 comm="certbot"
Bug#963161: lynis: CVE-2019-13033
Control: severity -1 minor Hi Marc, On Mon, Jun 22, 2020 at 04:33:42PM +0900, Marc Dequènes (duck) wrote: > Quack, > > On 2020-06-20 03:34, Salvatore Bonaccorso wrote: > > > CVE-2019-13033[0]: > > | In CISOfy Lynis 2.x through 2.7.5, the license key can be obtained by > > | looking at the process list when a data upload is being performed. > > | This license can be used to upload data to a central Lynis server. > > | Although no data can be extracted by knowing the license key, it may > > | be possible to upload the data of additional scans. > > It should be possible to enable the license system on the packaged version > but it makes no sense to do so since you would end-up quitting on all the > extra tests that are not opensourced (only in the enterprise version). The > central server also is not packaged for this reason. That is to say I > believe this bug can completely be ignored. Thanks for this usefull comment indeed! So yes I agree we probably can just ignore the issue, and mark it as resolved once as well fixed sourcwise with a 3.0.0 or later upload, but do not need to handle it explicitly otherwise. I have already marked the CVE now in the security-tracker as unimportant. Thank you! Regards, Salvatore
Bug#907374: 907374: ITP -> RFP (wontfix)
retitle 907374 RFP: pspio -- multiformat I/O library for pseudopotentials noowner 907374 tags 907374 + wontfix thanks According to the homepage [1], the project is archived, thus no longer developed. Hence I disown and mark the ITP as wontfix. [1] https://gitlab.e-cam2020.eu/esl/pspio Andrius
Bug#963287: notmuch: FTBFS: grotty: ():1662: fatal error: output error
On Mon, Jun 22, 2020 at 03:42:33PM +0200, Michael Meskes wrote: > > 'm adding the maintainers of util-linux (bsdextrautils) and > > bsdmainutils > > to Cc. Which path forward do you see for this issue? A similar issue > > seems to affect many packages, such as: > > ... > > It seems to me there are two options here, either we ask all those > packages to change the dependency or we force bsdextrautils > installation by making bsdmainutils depend on it. > > When changing the package I decided against a hard dependency because > it forces people to install something even if they don't need/want it > without a technical reason. > > And quite frankly I think the build dependency should be to the package > that is needed directly and not through another one. > IMO the move of col needs to be rolled back ASAP. And, if it is to happen again, it needs to be managed properly and not break reverse deps without notice. Cheers, Julien
Bug#950052: please warn for files installed into /
Hi Chris, On Mon, Jun 22, 2020 at 12:45 AM Chris Lamb wrote: > > Up to you. In commit 1b9e1048, I went with option #2. Kind regards Felix Lechner
