Bug#949022: ITP: dmagnetic/0.20-1 -- Interpreter to play textadventures from Magnetic Scrolls in glorious ANSI Art
Package: sponsorship-requests Severity: normal Dear mentors, I have upgraded my package "dmagnetic" * Package name: dmagnetic Version : 0.20-1 Upstream Author : Thomas Dettbarn * URL : https://www.dettus.net/dMagnetic/ * License : BSD-2-Clause * Vcs : None Section : games It builds those binary packages: dmagnetic - Interpreter to play textadventures from Magnetic Scrolls in glorious ANSI Art To access further information about this package, please visit the following URL: https://mentors.debian.net/package/dmagnetic Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/d/dmagnetic/dmagnetic_0.20-1.dsc Changes since the last upload: * Update to release 0.20. * It is possible to play with the original MS DOS binaries * A glitch in the text output has been removed. * The glitch prevented solving jinxter's sliding puzzle. * Changed the standards version to 4.4.1 Regards, -- Thomas Dettbarn
Bug#949021: xserver-xorg-video-intel: i915 Intel Iris Plus G7 (rev 07) hang & reset under load
Package: xserver-xorg-video-intel Version: 2:2.99.917+git20190815-1 Severity: important Tags: upstream Under GPU load, X hangs, then resets; after this reset, the system is responsive but hardly workable (massive input lag). A reboot is needed. Dmesg shows that i915 hangs, then resets (causing steam to segfault, in this case): [ 706.762555] perf: interrupt took too long (2524 > 2500), lowering kernel.perf_event_max_sample_rate to 79000 [ 878.147587] perf: interrupt took too long (3241 > 3155), lowering kernel.perf_event_max_sample_rate to 61500 [ 1091.099151] perf: interrupt took too long (4106 > 4051), lowering kernel.perf_event_max_sample_rate to 48500 [ 1325.609741] perf: interrupt took too long (5182 > 5132), lowering kernel.perf_event_max_sample_rate to 38500 [ 1602.725312] perf: interrupt took too long (6736 > 6477), lowering kernel.perf_event_max_sample_rate to 29500 [ 1612.531293] perf: interrupt took too long (8769 > 8420), lowering kernel.perf_event_max_sample_rate to 22750 [ 1612.916769] Asynchronous wait on fence i915:cinnamon[1250]:1643a timed out (hint:intel_atomic_commit_ready+0x0/0x50 [i915]) [ 1613.840431] i915 :00:02.0: Resetting rcs0 for preemption time out [ 1616.132812] i915 :00:02.0: GPU HANG: ecode 11:1:0x86d7fffd, in cinnamon [1250], stopped heartbeat on rcs0 [ 1616.132872] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace. [ 1616.132873] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel [ 1616.132873] drm/i915 developers can then reassign to the right component if it's not a kernel issue. [ 1616.132873] The GPU crash dump is required to analyze GPU hangs, so please always attach it. [ 1616.132899] GPU crash dump saved to /sys/class/drm/card0/error [ 1616.237695] i915 :00:02.0: Resetting rcs0 for stopped heartbeat on rcs0 [ 1616.240203] i915 :00:02.0: Resetting rcs0 for preemption time out [ 1616.246717] i915 :00:02.0: Resetting chip for stopped heartbeat on rcs0 [ 1616.449034] i915 :00:02.0: Failed to reset chip [ 1619.235971] perf: interrupt took too long (12434 > 10961), lowering kernel.perf_event_max_sample_rate to 16000 [ 1624.484008] broken atomic modeset userspace detected, disabling atomic [ 1626.701976] show_signal_msg: 15 callbacks suppressed [ 1626.702056] steam[1992]: segfault at 17 ip ea71a81f sp ff96d270 error 6 in steamclient.so[ea281000+190a000] [ 1626.702196] Code: 47 14 89 44 24 2c 89 41 08 8d 04 1d b4 30 00 00 e8 b6 01 c9 ff 89 c6 8b 00 85 c0 0f 84 6a 01 00 00 25 ff ff ff 1f 89 c5 31 c0 0f b1 2f 85 c0 89 c1 89 c2 0f 84 88 00 00 00 25 ff ff ff 1f 39 [ 1626.984687] steam[1992]: segfault at 17 ip ea71a81f sp ff96d270 error 6 in steamclient.so[ea281000+190a000] [ 1626.985066] Code: 47 14 89 44 24 2c 89 41 08 8d 04 1d b4 30 00 00 e8 b6 01 c9 ff 89 c6 8b 00 85 c0 0f 84 6a 01 00 00 25 ff ff ff 1f 89 c5 31 c0 0f b1 2f 85 c0 89 c1 89 c2 0f 84 88 00 00 00 25 ff ff ff 1f 39 [ 1635.525918] perf: interrupt took too long (15684 > 15542), lowering kernel.perf_event_max_sample_rate to 12750 [ 1784.579838] perf: interrupt took too long (22575 > 19605), lowering kernel.perf_event_max_sample_rate to 8750 This bug is reported upstream at https://gitlab.freedesktop.org/mesa/mesa/issues/2352. -- Package-specific info: /etc/X11/X does not exist. /etc/X11/X is not a symlink. /etc/X11/X is not executable. VGA-compatible devices on PCI bus: -- 00:02.0 VGA compatible controller [0300]: Intel Corporation Iris Plus Graphics G7 [8086:8a52] (rev 07) /etc/X11/xorg.conf does not exist. Contents of /etc/X11/xorg.conf.d: - total 0 /etc/modprobe.d contains no KMS configuration files. Kernel version (/proc/version): --- Linux version 5.5.0-rc5-amd64 (debian-ker...@lists.debian.org) (gcc version 9.2.1 20200104 (Debian 9.2.1-22)) #1 SMP Debian 5.5~rc5-1~exp1 (2020-01-06) Xorg X server log files on system: -- -rw-r--r-- 1 root root 35954 Jan 16 08:17 /var/log/Xorg.0.log Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): - [13.220] X.Org X Server 1.20.7 X Protocol Version 11, Revision 0 [13.220] Build Operating System: Linux 4.19.0-6-amd64 x86_64 Debian [13.220] Current Operating System: Linux Nesbitt 5.5.0-rc5-amd64 #1 SMP Debian 5.5~rc5-1~exp1 (2020-01-06) x86_64 [13.220] Kernel command line: BOOT_IMAGE=/vmlinuz-5.5.0-rc5-amd64 root=/dev/mapper/NESBITT-ROOT ro quiet [13.220] Build Date: 14 January 2020 10:13:49AM [13.220] xorg-server 2:1.20.7-2 (https://www.debian.org/support) [13.220] Current version of pixman: 0.36.0 [13.220]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [13.220] Markers: (--) probed, (**) from config file,
Bug#949006: debian-policy: Stop recommending stamp files in debian/rules
Niels Thykier wrote: > debhelper cannot see "inside" the upstream build system. If you modify > a .c file, debhelper won't notice and will currently just skip the > entire build. Alternatively, debhelper will have to invoke the build > system and rely on it to not be flawed. Yes, I think that would be a good behavior (invoking the build system and if it's flawed, let the packager work with upstream on it). Especially because the effect is directly on the packagers --- buildds wouldn't be hurt by this, as you note. Is that the proposed debhelper change? Where can I sign up? :) > AFAICT, the current practise recommended by policy have the same issue > (assuming you implement the stamp file or touch the "build" file). Right, using "touch build" or build-stamp is a last resort, for dealing with irreperable upstream build systems. Having a proper upstream build system is much better (and isn't all that rare). Thanks, Jonathan
Bug#946580: No coqidetop in coq package breaks editor plugins
Hi, On Wed, Jan 15, 2020 at 12:06:20PM -0500, Julien Lepiller wrote: > Thanks for the fix! The changelog seems to imply your change of coqidetop was > after coq upstream advice. To be clear, I am only the upstream of a plugin > that uses coq, not an upstream of coq itself :) yes I know. I asked Hugo Herbelin, who works in the same lab as me. -Ralf.
Bug#949020: linux-image-5.5.0-rc5-amd64: Poweroff/suspend doesn't work in 5.5.0-rc5
Package: src:linux Version: 5.5~rc5-1~exp1 Severity: normal Neither shutdown nor suspend works in this kernel version. Systemd seems to indicate it is trying at least, but the system hangs either right before shutdown (clean situation, requiring a poweroff with the power button) or before sleep (hung system, can't do anything except also hard powering off and rebooting later). Syslog from a suspend action: Jan 16 06:43:53 Nesbitt NetworkManager[749]: [1579153433.6342] manager: sleep: sleep requested (sleeping: no enabled: yes) Jan 16 06:43:53 Nesbitt NetworkManager[749]: [1579153433.6343] device (p2p-dev-wlan0): state change: disconnected -> unmanaged (reason 'sleeping', sys-iface-state: 'managed') Jan 16 06:43:53 Nesbitt NetworkManager[749]: [1579153433.6345] manager: NetworkManager state is now ASLEEP Jan 16 06:43:53 Nesbitt systemd[1]: Reached target Sleep. Jan 16 06:43:53 Nesbitt systemd[1]: Starting Suspend... Jan 16 06:43:53 Nesbitt kernel: [55203.294410] PM: suspend entry (s2idle) Jan 16 06:43:53 Nesbitt systemd-sleep[19110]: Suspending system... -- Package-specific info: ** Version: Linux version 5.5.0-rc5-amd64 (debian-ker...@lists.debian.org) (gcc version 9.2.1 20200104 (Debian 9.2.1-22)) #1 SMP Debian 5.5~rc5-1~exp1 (2020-01-06) ** Command line: BOOT_IMAGE=/vmlinuz-5.5.0-rc5-amd64 root=/dev/mapper/NESBITT-ROOT ro quiet ** Not tainted ** Kernel log: [ 11.240204] usb 3-10: config 1 interface 1 altsetting 0 endpoint 0x3 has wMaxPacketSize 0, skipping [ 11.240207] usb 3-10: config 1 interface 1 altsetting 0 endpoint 0x83 has wMaxPacketSize 0, skipping [ 11.240213] usb 3-10: New USB device found, idVendor=8087, idProduct=0026, bcdDevice= 0.02 [ 11.240215] usb 3-10: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 11.268290] mc: Linux media interface: v0.10 [ 11.269619] alg: No test for fips(ansi_cprng) (fips_ansi_cprng) [ 11.272214] SCSI subsystem initialized [ 11.275443] usb-storage 4-1:1.0: USB Mass Storage device detected [ 11.275734] scsi host0: usb-storage 4-1:1.0 [ 11.275814] videodev: Linux video capture interface: v2.00 [ 11.275824] usbcore: registered new interface driver usb-storage [ 11.277009] usbcore: registered new interface driver uas [ 11.285112] uvcvideo: Found UVC 1.00 device Integrated Camera (13d3:56b2) [ 11.303110] uvcvideo 3-1:1.0: Entity type for entity Extension 4 was not initialized! [ 11.303111] uvcvideo 3-1:1.0: Entity type for entity Extension 3 was not initialized! [ 11.303112] uvcvideo 3-1:1.0: Entity type for entity Processing 2 was not initialized! [ 11.303112] uvcvideo 3-1:1.0: Entity type for entity Camera 1 was not initialized! [ 11.303150] input: Integrated Camera: Integrated C as /devices/pci:00/:00:14.0/usb3/3-1/3-1:1.0/input/input21 [ 11.303195] usbcore: registered new interface driver uvcvideo [ 11.303195] USB Video Class driver (1.1.1) [ 11.309377] Bluetooth: Core ver 2.22 [ 11.309386] NET: Registered protocol family 31 [ 11.309386] Bluetooth: HCI device and connection manager initialized [ 11.309388] Bluetooth: HCI socket layer initialized [ 11.309390] Bluetooth: L2CAP socket layer initialized [ 11.309391] Bluetooth: SCO socket layer initialized [ 11.313933] usbcore: registered new interface driver btusb [ 11.315171] Bluetooth: hci0: Bootloader revision 0.4 build 0 week 11 2017 [ 11.316154] Bluetooth: hci0: Device revision is 2 [ 11.316169] Bluetooth: hci0: Secure boot is enabled [ 11.316169] Bluetooth: hci0: OTP lock is enabled [ 11.316169] Bluetooth: hci0: API lock is enabled [ 11.316170] Bluetooth: hci0: Debug lock is disabled [ 11.316170] Bluetooth: hci0: Minimum firmware build 1 week 10 2014 [ 11.317265] bluetooth hci0: firmware: direct-loading firmware intel/ibt-19-32-4.sfi [ 11.317267] Bluetooth: hci0: Found device firmware: intel/ibt-19-32-4.sfi [ 12.307973] scsi 0:0:0:0: Direct-Access USB Disk 3.0 0009 PQ: 0 ANSI: 6 [ 12.318811] scsi 0:0:0:0: Attached scsi generic sg0 type 0 [ 12.321712] sd 0:0:0:0: [sda] 60825600 512-byte logical blocks: (31.1 GB/29.0 GiB) [ 12.322349] sd 0:0:0:0: [sda] Write Protect is off [ 12.322367] sd 0:0:0:0: [sda] Mode Sense: 23 00 00 00 [ 12.323064] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 12.346647] sda: sda1 [ 12.347847] sd 0:0:0:0: [sda] Attached SCSI removable disk [ 12.400600] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) [ 12.419559] audit: type=1400 audit(1579159022.895:2): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libreoffice-xpdfimport" pid=734 comm="apparmor_parser" [ 12.420287] audit: type=1400 audit(1579159022.895:3): apparmor="STATUS" operation="profile_load" profile="unconfined" name="torbrowser_tor" pid=730 comm="apparmor_parser" [ 12.420374] audit: type=1400 audit(1579159022.895:4): apparmor="STATUS" operation="profile_load"
Bug#945076: firmware-linux: Missing firmware for i915 on Intel 1065G7 (Ice Lake)
On kernel 5.5, firmware i915/icl_dmc_ver1_09.bin is also requested (and currently missing). Firmware is also available on kernel.org. signature.asc Description: Digital signature
Bug#949019: firmware-linux-nonfree: Missing firmware for Ice Lake sound card renders it disabled
Package: firmware-linux-nonfree Version: 20190717-2 Severity: normal Missing firmware intel/sof/sof-icl.ri makes that the sound card is not working in kernel 5.5 (only sound output is "dummy", until I plug in an USB sound card). Please update the firmware packages with more recent blobs than those of six months ago :-) recent hardware depends on it. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.5.0-rc5-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages firmware-linux-nonfree depends on: ii firmware-amd-graphics 20190717-2 ii firmware-misc-nonfree 20190717-2 Versions of packages firmware-linux-nonfree recommends: ii amd64-microcode 3.20191218.1 ii intel-microcode 3.20191115.2 firmware-linux-nonfree suggests no packages. -- no debconf information
Bug#949006: debian-policy: Stop recommending stamp files in debian/rules
Jonathan Nieder: > Hi! > > Niels Thykier wrote: > >> [...] >> >> Notely, this trickery prevents you from hacking on the upstream parts >> and use "dpkg-buildpackage -b -nc -uc -us" to reduce the build times >> for subsequent builds. You would have to add some rm -f calls to >> delete "internal debhelper state files" as well between each >> dpkg-buildpackage call. > > The ideal is to have dependencies correctly set so that if something > changes, the build system knows exactly what needs to be rebuilt. Is > that achieveable in the debhelper context? > > Summary: I don't have a strong opinion about what policy should say to > do with poorly-designed makefiles, but let's make sure debhelper > doesn't enter that category. > > Thanks, > Jonathan > As I see it, there is no way for debhelper to sanely determine whether something should be rebuild or not without just rerunning that part. debhelper cannot see "inside" the upstream build system. If you modify a .c file, debhelper won't notice and will currently just skip the entire build. Alternatively, debhelper will have to invoke the build system and rely on it to not be flawed. AFAICT, the current practise recommended by policy have the same issue (assuming you implement the stamp file or touch the "build" file). Thanks, ~Niels
Bug#940570: gtk-layer-shell status
Hi Birger, (Cc:ing upstream because of the man page donation, see below...) On Do 09 Jan 2020 13:38:20 CET, Birger Schacht wrote: Hi, I have now renamed the -dev and the -doc package and merged the contents of the -examples package into the -doc package. cheers, Birger I have once more looked into gtk-layer-shell. I, in fact, felt the urge to re-introduce the doc / example bin:pkg split (doc being arch:all, whereas examples having to be arch:any). I am sorry for my previous urge to merge doc + examples. I did not take into account the gtk-layer-demo application and it being the reason for turning a doc bin:pkg into an arch:any pkg. So... Furthermore, I renamed the doc and example pkgs to -doc and -examples. And I added some other commits: * dh_missing --fail-missing * copyright format * typo fix in gtk-layer-demo * provide man page for gtk-layer-demo @wmww: please feel free to pick the new man page from the Debian package and to add it upstream. https://salsa.debian.org/debian/gtk-layer-shell/blob/debian/sid/debian/gtk-layer-demo.1 I just have uploaded the package to Debian's NEW queue... Greets, Mike -- DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgpR7ih9u8Kt6.pgp Description: Digitale PGP-Signatur
Bug#949018: python3-jinja2: Incompatible with Python 3.8
Package: python3-jinja2 Version: 2.10.1-1 Severity: normal I'd expect Upstream to have fixed this by now. /usr/lib/python3/dist-packages/jinja2/utils.py:485 /usr/lib/python3/dist-packages/jinja2/utils.py:485: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working from collections import MutableMapping /usr/lib/python3/dist-packages/jinja2/runtime.py:318 /usr/lib/python3/dist-packages/jinja2/runtime.py:318: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working from collections import Mapping -- System Information: Debian Release: 10.2 APT prefers stable APT policy: (700, 'stable'), (600, 'unstable'), (550, 'experimental'), (550, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.0-1-amd64 (SMP w/8 CPU cores) 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 python3-jinja2 depends on: ii python3 3.7.3-1 ii python3-markupsafe 1.1.0-1 Versions of packages python3-jinja2 recommends: ii python3-pkg-resources 40.8.0-1 Versions of packages python3-jinja2 suggests: pn python-jinja2-doc -- no debconf information
Bug#949017: discus: invalid syntax while size > (0.9999999999 * pow(10L, 3))
Package: discus Version: 0.2.9-11 Severity: grave Justification: renders package unusable Hi, I get the following: ~/ discus File "/usr/bin/discus", line 121 while size > (0.99 * pow(10L, 3)): ^ SyntaxError: invalid syntax Regards Jean-Luc -- System Information: Debian Release: bullseye/sid APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.5.0-rc6-i7-0.1 (SMP w/8 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 /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages discus depends on: ii python 2.7.17-2 discus recommends no packages. discus suggests no packages. -- no debconf information
Bug#948983: Acknowledgement (evdi-dkms: Loading new evdi-5.2.14 DKMS files...)
Please, apply the patch, you know that upstream is always slow when it comes to those things Renato Gallo System Engineer sede legale e operativa: Via Privata Cefalonia, 14 - 20156 - Milano (MI) Tel. +39 02 - 87049490 Fax +39 02 - 48677349 Mobile. +39 342 - 6350524 Wi | FreeNumbers: https://freenumbers.way-interactive.com Wi | SMS: https://sms.way-interactive.com Wi | Voip: https://voip.way-interactive.com Asterweb: http://www.asterweb.org Le informazioni contenute in questo messaggio e negli eventuali allegati sono riservate e per uso esclusivo del destinatario. Persone diverse dallo stesso non possono copiare o distribuire il messaggio a terzi. Chiunque riceva questo messaggio per errore è pregato di distruggerlo e di informare immediatamente [ mailto:i...@sigmaware.it | info@ ] asterweb.org - Original Message - From: "Debian Bug Tracking System" To: "renato" Sent: Wednesday, January 15, 2020 4:21:04 PM Subject: Bug#948983: Acknowledgement (evdi-dkms: Loading new evdi-5.2.14 DKMS files...) Thank you for filing a new Bug report with Debian. You can follow progress on this Bug here: 948983: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948983. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): Hanno Stock If you wish to submit further information on this problem, please send it to 948...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. -- 948983: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948983 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#624768: libnss-cache
I just learned of this bug via the action needed list on tracker.debian.org/pkg/nsscache; nsscache and libnss-cache are designed specifically to handle the requirements described in message #22 and onwards, fyi.
Bug#949016: Useless in Debian
Package: php-doctrine-cache-bundle Version: 1.3.5+git-1 Severity: serious [ Filled as an RC-bug by the maintainer to see the package auto-removed from testing. ] I packaged php-doctrine-cache-bundle as used by symfony, but symfony does not use is anymore (it uses php-doctrine-bundle instead, as a build-dependency). There is a priori little point to ship php-doctrine-cache-bundle in the next stable Debian release. I intend to follow up with an RM request in a few months if nobody objects (but feel free to beat me to it). Regards David signature.asc Description: PGP signature
Bug#949007: debian-policy: Typo in example
Control: tags -1 pending
Niels Thykier writes:
> In
> https://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules-gainrootapi
> we find the following example:
> """
> Examples of valid use of the gain root command:
> # sh-syntax (assumes set -e semantics for error handling)
> $DEB_GAIN_ROOT_CMD some-cmd --which-requires-root
> # perl
> my @cmd = ('some-cmd', '--which-requires-root');
> unshift(@cmd, split(' ', $ENV{DEB_GAIN_ROOT_CMD})) if $ENV{DEB_GAIN_ROOT_CMD};
> system(@cmd) == or die("@cmd failed");
> """
> The Perl code is invalid. There is missing a 0 after "==" and before
> "or die(...)".
Thanks! Fixed for the next release.
--
Russ Allbery (r...@debian.org)
Bug#945172: same issue on ThinkPad E490
I'm facing the same error on Debian testing running on a Lenovo ThinkPad E490. root@maelcum:~# uname -a Linux maelcum 5.4.0-2-amd64 #1 SMP Debian 5.4.8-1 (2020-01-05) x86_64 GNU/Linux root@maelcum:~# lshw --cut *-generic UNCLAIMED description: Unassigned class product: RTL8822BE 802.11a/b/g/n/ac WiFi adapter vendor: Realtek Semiconductor Co., Ltd. physical id: 0 bus info: pci@:05:00.0 version: 00 width: 64 bits clock: 33MHz capabilities: pm msi pciexpress cap_list configuration: latency=0 resources: ioport:2000(size=256) memory:b120-b120 --cut root@maelcum:~# dpkg -l firmware-realtek ii firmware-realtek 20190717-2 all Binary firmware for Realtek wired/wifi/BT adapters
Bug#949015: libvips42: Add libimagequant dependency?
Package: libvips42 Version: 8.7.4-1 Severity: wishlist Dear Maintainer, This library can create paletted PNGs as of version 8.7.0, but it needs to be linked to libimagequant in order to do this. Would you please consider adding libimagequant as a dependency to the official Debian package? This library is already available in the official Debian repository (libimagequant0). Thank you! -- System Information: Debian Release: 10.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (300, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) 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 libvips42 depends on: ii libc6 2.28-10 ii libcairo2 1.16.0-4 ii libcfitsio73.450-3 ii libexif12 0.6.21-5.1 ii libexpat1 2.2.6-2+deb10u1 ii libfftw3-double3 3.3.8-2 ii libfontconfig1 2.13.1-2 ii libfreetype6 2.9.1-3+deb10u1 ii libgcc11:8.3.0-6 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libgif75.1.4-3 ii libglib2.0-0 2.58.3-2+deb10u2 ii libgomp1 8.3.0-6 ii libgsf-1-114 1.14.45-1 ii libhdf5-1031.10.4+repack-10 ii libilmbase23 2.2.1-2 ii libjpeg62-turbo1:1.5.2-2+b1 ii liblcms2-2 2.9-3 ii libmagickcore-6.q16-6 8:6.9.10.23+dfsg-2.1 ii libmatio4 1.5.13-3 ii libopenexr23 2.2.1-4.1 ii libopenslide0 3.4.1+dfsg-4 ii liborc-0.4-0 1:0.4.28-3.1 ii libpango-1.0-0 1.42.4-7~deb10u1 ii libpangoft2-1.0-0 1.42.4-7~deb10u1 ii libpng16-161.6.36-6 ii libpoppler-glib8 0.71.0-5 ii librsvg2-2 2.44.10-2.1 ii libstdc++6 8.3.0-6 ii libtiff5 4.0.10-4 ii libwebp6 0.6.1-2 ii libwebpmux30.6.1-2 ii libxml22.9.4+dfsg1-7+b3 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages libvips42 recommends: pn nip2 libvips42 suggests no packages. -- no debconf information
Bug#949014: ITP: php-slim -- PHP micro framework for writing simple applications and APIs
Package: wnpp Severity: wishlist Owner: James Valleroy * Package name: php-slim Version : 3.12.3 Upstream Author : Josh Lockhart * URL : https://www.slimframework.com/ * License : Expat Programming Lang: PHP Description : PHP micro framework for writing simple applications and APIs php-slim is a dispatcher that receives an HTTP request, invokes an appropriate callback routine, and returns an HTTP response. It is an ideal for creating APIs and for rapid prototyping. php-slim 3.x is a dependency for shaarli (ITP #864559). I will maintain it within Debian PHP PEAR Maintainers team.
Bug#949010: maven: Add support for maven wrapper completion
Package: maven Version: 3.6.2-1 Followup-For: Bug #949010 Dear Maintainer, sorry, the correct line for maven wrapper completion should be: complete -o default -o nospace -F _mvn mvn mvnDebug mvnw Jiri Pejchal -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-1-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages maven depends on: pn libjansi-java pn libmaven3-core-java pn libwagon-file-java pn libwagon-http-shaded-java ii openjdk-11-jre-headless [java7-runtime-headless] 11.0.6+7-1 ii openjdk-14-jre-headless [java7-runtime-headless] 14~27-1 maven recommends no packages. maven suggests no packages. -- no debconf information
Bug#929157: sympa: wwsympa stops working after upgrade: Can't locate object method "host_port" via package "URI::_generic"
Hi there, same error on the sympa instance of lists.fs.lmu.de/sympa, for us the error occurred every time someone tried to open Support->Documentation in the header menu of the main page, also they would see an error there instead of the main documentation page. Sub-pages (e.g. $DOMAIN/sympa/help/introduction) did work, though, and after a bit of looking around I found out that the page that would be shown at /help is also reachable at /help/index, so the issue (broken help page and log error) can be avoided by adding the following line to our nginx config before the URL is forwarded to fastcgi: rewrite sympa/help$ /sympa/help/index redirect; To answer a question previously asked in this bug thread: in our case, the global config does not contain any wwsympa_url entry, but the robot configs in question have an entry of the form "wwsympa_url https://DOMAIN.TLD/sympa;. Kind regards, Aldo signature.asc Description: OpenPGP digital signature
Bug#949013: Upgrade of Perl stymied by a dependency issue
Package: libgtk2-perl Version: 2:1.24993-1 Whilst running a dist-upgrade, the Perl packages cannot be upgraded due to an erroneous dependency. libgtk2-perl : Depends: perlapi-5.28.1 which is a virtual package, provided by: - perl-base (5.28.1-6), but 5.30.0-9 is to be installed
Bug#949012: Error generating boot image
Package: initramfs-tools Version: 0.135 uname -a output:- Linux roblaptop 5.4.0-2-amd64 #1 SMP Debian 5.4.8-1 (2020-01-05) x86_64 GNU/Linux Processing triggers for libglib2.0-0:amd64 (2.62.4-1) ... Processing triggers for libc-bin (2.29-7) ... Processing triggers for systemd (244-3) ... Processing triggers for man-db (2.9.0-2) ... Processing triggers for dbus (1.12.16-2) ... Processing triggers for initramfs-tools (0.135) ... update-initramfs: Generating /boot/initrd.img-5.4.0-2-amd64 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8125a-3.fw for module r8169 depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/var/tmp/mkinitramfs_kzFpRd/lib/modules/5.4.0-2- amd64/modules.builtin.bin' depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/var/tmp/mkinitramfs_kzFpRd/lib/modules/5.4.0-2- amd64/modules.builtin.bin' The depmod: error lines repeat dozens of times until the boot image generation finishes. I have no idea which package is at fault. However, the laptop boots normally afterwards.
Bug#929024: [RPKI] Bug#929024: ITP: routinator -- An RPKI Validator
On Jan 02, Marco d'Itri via RPKI wrote: > I have packaged all missing dependencies: at this point the only blocker > is ring and possibly other not up to date dependencies (I have not > checked all of them). bcder is a problem too, since now it is uninstallable: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948632 -- ciao, Marco signature.asc Description: PGP signature
Bug#949007: debian-policy: Typo in example
Niels Thykier wrote:
> In
> https://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules-gainrootapi
> we find the following example:
>
> """
> Examples of valid use of the gain root command:
>
> # sh-syntax (assumes set -e semantics for error handling)
> $DEB_GAIN_ROOT_CMD some-cmd --which-requires-root
>
> # perl
> my @cmd = ('some-cmd', '--which-requires-root');
> unshift(@cmd, split(' ', $ENV{DEB_GAIN_ROOT_CMD})) if $ENV{DEB_GAIN_ROOT_CMD};
> system(@cmd) == or die("@cmd failed");
> """
>
> The Perl code is invalid. There is missing a 0 after "==" and before "or
> die(...)".
(I don't think this is normative, so probably not needed, but just in
case:)
Seconded. Thanks for catching it.
Sincerely,
Jonathan
Bug#949006: debian-policy: Stop recommending stamp files in debian/rules
Hi! Niels Thykier wrote: > I would like to propose that we drop or replace the following > recommendation in Policy: > > """ > When a package has a configuration and build routine which takes a > long time, or when the makefiles are poorly designed, or when build > needs to run clean first, it is a good idea to touch build when the > build process is complete. This will ensure that if debian/rules build > is run again it will not rebuild the whole program. [11] > """ > > (And related footnote about using "build-stamp" instead of "build"). [...] > As I understand it, the primary purpose behind this recommendation > comes from the need for running "debian/rules build && fakeroot > debian/rules binary" and thereby repeating the build step in some > cases (as listed in the text). I don't have a strong opinion about what we should recommend to do with poorly-designed makefiles (e.g. wouldn't it make sense for us to work with upstream to make them less poorly designed?), but I think this bug report is not characterizing the motivation correctly. The motivation is the same as the motivation for rules to be idempotent in any Makefile: it allows one to safely run steps in any order, rerun them without unnecessary work, and so on. In other words, this is a quality of implementation issue that affects all developers working with the source package, not just buildds. If we switch to a policy that focuses only on buildds working, that would take away a large part of what I find appealing about working within Debian. > However, with the advent of Rules-Requires-Root many packages can now > be built with a direct "debian/rules binary" call and here the stamp > file is no longer useful for the above purpose. > > Furthermore, debhelper need some complexity in implementing/emulating > this behaviour. This may sound "easy" until you try to implement this > "correctly" for the following sequence of debian/rules calls: > > debian/rules build-arch > debian/rules binary-indep > > This has resulted in debhelper using arcane trickery such as log files > (up to compat 9) and its own "stamp-log" (compat 10+). Both > techniques have their limitations and causes frustrations for people > that has a "well-behaving" upstream build system as they have to work > around debhelper's trickery. > > Notely, this trickery prevents you from hacking on the upstream parts > and use "dpkg-buildpackage -b -nc -uc -us" to reduce the build times > for subsequent builds. You would have to add some rm -f calls to > delete "internal debhelper state files" as well between each > dpkg-buildpackage call. The ideal is to have dependencies correctly set so that if something changes, the build system knows exactly what needs to be rebuilt. Is that achieveable in the debhelper context? Summary: I don't have a strong opinion about what policy should say to do with poorly-designed makefiles, but let's make sure debhelper doesn't enter that category. Thanks, Jonathan
Bug#948722: qemu-block-extra, (build-)dependencies unsatisfiable on mipsel.
On 14/01/2020 10:24, Michael Tokarev wrote: Control: severity -1 normal Control: tag -1 + moreinfo 12.01.2020 18:37, peter green wrote: Package: qemu-block-extra Version: 1:4.2-1 Severity: serious The binary packages built from the ceph source package were recently removed from mipsel, because the new version of ceph runs out of address space during the build. Your package build-depends on libradios-dev and librbd-dev and depends on librados2 and librbd1 which are built from the ceph source package. So qemu-block-extra is now uninstallable and the qemu source package is unbuildable on mipsel. Hm. For the start, I see that new ceph packages are being built on mips/mips64 right now as I write this. So things aren't that simple, at least. Ceph 14.2.4 was uploaded to unstable in late december, but failed to build on many architectures. The maintainer found workarounds for most of them, but could not find any soloution to the address space exhaustion issue on mipsel (when a build says "out of memory" it nearly always really means out of address space). With version 14.2.4-8 the maintainer decided it was time to give up on mipsel, he removed mipsel from the architecture lists and filed a removal request with the ftp masters. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947887 It seems that with version 1.4.2.5-1 mipsel was quietly re-added to the achitecture list, I do not know if this was a mistake or if the maintainer was deliberately testing if the problem had gone away. Either way ceph has continued to fail to build on mipsel. Next, even if we're now uninstallable on some architecture, it is definitely not our fault, It's not about "fault". so I don't see why this bugreport is of serious severity. rc policy "Packages must be buildable within the same release." I'm not going to play severity ping-pong with you, but I am ccing the ceph maintainers and the release team in-case they want to give a position on this. Also, it has nothing to do with this particular version of qemu, either. True enough, afaict normal practice is to file bugs against the current version in testing/unstable unless there is reason not to. And more, it has nothing to do with qemu-block-extra package, too, even if that's the only pkg which actually uses the library in question, -- we _build_-depend on librados-dev too, so it is qemu source which FTBFS on mips. If you would preffer to reassign to the source package that is fine by me, doesn't make much practical difference. So far I don't quite understand what's going on with ceph on mips, hence adding a "moreinfo" tag. We shouldn't drop optional features on different architectures easily, If I thought this was just some transient issue I wouldn't have bothered filing this bug, but I doubt it is. or else it would quickly become a mess, not understanding which features of which packages are enabled on which architecture (I speak here about general debian, not about this particular (pair of) package). At some point I think Debian needs to have a hard think about how 32-bit architectures are supported, possiblly introducing official support for cross-building heavier packages, but so-far there doesn't seem to have been a strong will to do so.
Bug#902413: why not remove tmpfiles altogether?
Hi, I'm not sure why there is a tmpfiles entry at all. Admittedly I'm not a systemd expert but wouldn't putting RuntimeDirectory=fail2ban in the unit file do what is needed? This creates /run/fail2ban on dameon start and removes it on daemon stop. See the sandboxing section of systemd.exec(5) - Craig
Bug#949011: open-vm-tools 11.0.5 released
Package: open-vm-tools Version: 2:11.0.1-4 We have released open-vm-tools 11.0.5. See https://github.com/vmware/open-vm-tools/releases/tag/stable-11.0.5 Oliver
Bug#949010: maven: Add support for maven wrapper completion
Package: maven Version: 3.6.2-1 Severity: wishlist Dear Maintainer, it would be nice if the packaged bash completion had support for maven wrapper[1] - i.e., "./mvnw" had the same completion as "mvn". The following works for me: complete -o default -o nospace -F _mvn mvn mvnDebug mvnw ./mvnw Jiri Pejchal [1] https://github.com/takari/maven-wrapper -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-1-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages maven depends on: ii libjansi-java 1.18-1 ii libmaven3-core-java 3.6.2-1 ii libwagon-file-java3.3.3-1 ii libwagon-http-shaded-java 3.3.3-1 ii openjdk-11-jre-headless [java7-runtime-headless] 11.0.6+7-1 ii openjdk-14-jre-headless [java7-runtime-headless] 14~27-1 maven recommends no packages. maven suggests no packages. -- no debconf information
Bug#948388: navit: fails to connect to gpsd
Hello Bernd, I could further isolate the cmake failing issue. It starts failing when the package qtbase5-dev is installed. This gets installed as build dependency for libgps26. A workaround would be to temporarily uninstall qtbase5-dev. Maybe better would be to add following to navit to allow building while qtbase5-dev is installed. Building that way produces equal .deb packages. Kind regards, Bernhard --- navit-0.5.3+dfsg.1.orig/debian/rules2018-09-01 12:16:52.0 +0200 +++ navit-0.5.3+dfsg.1/debian/rules2020-01-15 23:57:58.840074000 +0100 @@ -75,6 +75,9 @@ CMAKEFLAGS += -Dsupport/shapefile=TRUE # Enable libspeechd CMAKEFLAGS += -Dspeech/speech_dispatcher=TRUE +# Disable Qt explicitly to allow building while qtbase5-dev is installed +CMAKEFLAGS += -DDISABLE_QT=TRUE + # Avoid floating point calculation for armel ifeq ($(DEB_HOST_ARCH), armel) CMAKEFLAGS += -DAVOID_FLOAT=TRUE
Bug#949009: duck table is not very useful
Package: qa.debian.org Severity: normal Usertag: udd The duck table in UDD just has a list of source packages; it would be great if it could include the actual fields that are invalid. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-2-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 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 /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#949008: alfred ftbfs unknown type name ‘timestamp_t’
package: alfred
version: 2018.2.1
severity: serious
alfred failed to build when binnmu'd for the libgps transition.
alfred-gpsd.c:85:3: error: unknown type name ‘timestamp_t’
85 | timestamp_t now = timestamp();
| ^~~
alfred-gpsd.c:85:21: warning: implicit declaration of function ‘timestamp’; did
you mean ‘timercmp’? [-Wimplicit-function-declaration]
85 | timestamp_t now = timestamp();
| ^
| timercmp
alfred-gpsd.c:92:4: warning: implicit declaration of function
‘unix_to_iso8601’; did you mean ‘now_to_iso8601’?
[-Wimplicit-function-declaration]
92 |unix_to_iso8601(now, tbuf, sizeof(tbuf)),
|^~~
|now_to_iso8601
alfred-gpsd.c:88:4: warning: format ‘%s’ expects argument of type ‘char *’, but
argument 3 has type ‘int’ [-Wformat=]
88 |"{\"class\":\"TPV\",\"device\":\"command line\","
|^
..
92 |unix_to_iso8601(now, tbuf, sizeof(tbuf)),
|
||
|int
alfred-gpsd.c:89:17: note: format string is defined here
89 |"\"time\":\"%s\","
|~^
| |
| char *
|%d
make[3]: *** [Makefile:87: alfred-gpsd.o] Error 1
Bug#949006: debian-policy: Stop recommending stamp files in debian/rules
Source: debian-policy Severity: wishlist Hi, I would like to propose that we drop or replace the following recommendation in Policy: """ When a package has a configuration and build routine which takes a long time, or when the makefiles are poorly designed, or when build needs to run clean first, it is a good idea to touch build when the build process is complete. This will ensure that if debian/rules build is run again it will not rebuild the whole program. [11] """ (And related footnote about using "build-stamp" instead of "build"). I think a better solution would be to either drop the recommendation entirely or keep it only for packages with this issue and Rules-Requires-Root set to binary-targets. Either way would enable me to move some debhelper hacks out of the "default" in future compat level (at least for people with Rules-Requires-Root). # Rationale: As I understand it, the primary purpose behind this recommendation comes from the need for running "debian/rules build && fakeroot debian/rules binary" and thereby repeating the build step in some cases (as listed in the text). However, with the advent of Rules-Requires-Root many packages can now be built with a direct "debian/rules binary" call and here the stamp file is no longer useful for the above purpose. Furthermore, debhelper need some complexity in implementing/emulating this behaviour. This may sound "easy" until you try to implement this "correctly" for the following sequence of debian/rules calls: debian/rules build-arch debian/rules binary-indep This has resulted in debhelper using arcane trickery such as log files (up to compat 9) and its own "stamp-log" (compat 10+). Both techniques have their limitations and causes frustrations for people that has a "well-behaving" upstream build system as they have to work around debhelper's trickery. Notely, this trickery prevents you from hacking on the upstream parts and use "dpkg-buildpackage -b -nc -uc -us" to reduce the build times for subsequent builds. You would have to add some rm -f calls to delete "internal debhelper state files" as well between each dpkg-buildpackage call. Thanks, ~Niels
Bug#949007: debian-policy: Typo in example
Source: debian-policy
Severity: minor
In
https://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules-gainrootapi
we find the following example:
"""
Examples of valid use of the gain root command:
# sh-syntax (assumes set -e semantics for error handling)
$DEB_GAIN_ROOT_CMD some-cmd --which-requires-root
# perl
my @cmd = ('some-cmd', '--which-requires-root');
unshift(@cmd, split(' ', $ENV{DEB_GAIN_ROOT_CMD})) if $ENV{DEB_GAIN_ROOT_CMD};
system(@cmd) == or die("@cmd failed");
"""
The Perl code is invalid. There is missing a 0 after "==" and before "or
die(...)".
Thanks,
~Niels
Bug#833317: en
On Thu, 21 Feb 2019 10:08:03 +0100 =?UTF-8?Q?G=C3=BCrkan_Myczko?= wrote: > Hello Roland > > Can you try with version 2.0? It also doesn't have en locale in the > locale directory, however > it is default english. It has been a while and I have changed systems twice in the meantime… ^^ With flowblade 2.4-1, I'm still getting a German interface with: $ locale LANG=en_US.UTF-8 LANGUAGE=en_US:en LC_CTYPE=de_DE.UTF-8 LC_NUMERIC=en_US.UTF-8 LC_TIME=de_DE.UTF-8 LC_COLLATE=de_DE.UTF-8 LC_MONETARY=de_DE.UTF-8 LC_MESSAGES=en_US.UTF-8 LC_PAPER=de_DE.UTF-8 LC_NAME=de_DE.UTF-8 LC_ADDRESS=de_DE.UTF-8 LC_TELEPHONE=de_DE.UTF-8 LC_MEASUREMENT=de_DE.UTF-8 LC_IDENTIFICATION=de_DE.UTF-8 LC_ALL= > You have a mixture of everything in your locale > settings, not sure what > you expect upstream or maintainer to do? Given that I live in Germany, it makes sense for me to set certain locale variables to de_DE.UTF-8, e.g. time formatting, currency, collation order, paper format etc. The usual way is to respect LANG, LANGUAGE or LC_MESSAGES for user interface output: $ LANGUAGE=en_US git status fatal: not a git repository (or any of the parent directories): .git $ LANGUAGE=de_DE git status fatal: Kein Git-Repository (oder irgendeines der Elternverzeichnisse): .git $ LANGUAGE=en_US cat nonexistent cat: nonexistent: No such file or directory $ LANGUAGE=de_DE cat nonexistent cat: nonexistent: Datei oder Verzeichnis nicht gefunden Apparently [1] the precedence is LANGUAGE, LC_ALL, LC_MESSAGES, LANG: $ LANG= LANGUAGE= LC_ALL= LC_MESSAGES=de_DE.UTF-8 git status fatal: Kein Git-Repository (oder irgendeines der Elternverzeichnisse): .git $ LANG= LANGUAGE= LC_ALL= LC_MESSAGES=en_US.UTF-8 git status fatal: not a git repository (or any of the parent directories): .git Maybe that has something to do with it? But note that all of these four variables are set to en_US in my case. [1]: https://www.gnu.org/software/gettext/manual/html_node/Locale-Environment-Variables.html - Roland
Bug#948842: nm.debian.org: please let people upload their OpenPGP certificate directly
On Wed, Jan 15, 2020 at 07:12:36PM +0100, Enrico Zini wrote: > On Mon, Jan 13, 2020 at 05:03:50PM -0500, Daniel Kahn Gillmor wrote: > > > With the SKS network slowly dying, gpg not receiving third-party > > > certifications anymore by default and other changes to the ecosystem, > > > retrieving OpenPGP certificates and third-party certifications may be > > > harder in the future. > > > > > > It is simpler to let applicants provide a certificate themselves > > > directly. > > > > I endorse this suggestion :) > > > > I note that we shouldn't *require* users to upload their certificate > > necessarily. The change asked for here is just to make it possible for > > them to do the upload if they choose to. > > I like the sentiment, and I am slightly afraid of turning nm.debian.org > into the debian keyserver replacement. > > I mean, we could, but I'd like to figure out where we want to have the > authoritative source of key material for Debian. > > Here are various options that I can think of: > > - nm.debian.org, needs the data > - contributors.debian.org has a much more comprehensive user database > - keyring.debian.org primarily manages key material > - sso.debian.org is the authoritative user database > - the oncoming replacement of sso.debian.org will be the actual >authoritative user database > > I'd feel better having this information together with the authoritative > user database, which at this point in time would mean waiting for the > new SSO to be up, and then hooking into that somehow. > > Alternatively, having this information managed by the authoritative > team, which could mean keyring-maint providing a key upload service tied > to the new SSO. In this case, I don't mind helping to write the key > upload service for keyring-maint, if you want. [wearing no hat other than operator of the keyserver in question] Y'all are welcome to (and tell prospective contributors to) send keys to the.earth.li, which is not SKS and still accepts third party certifications. It does some limited signature verification which I'm generally working to improve when time allows, but I think it's a half-way house between what we current have (trust a failing keyserver network to have the data) and what's being proposed (implement a very specific service to suit our needs for retrieving 3rd party certs). J. -- "I'm not anti-establishment, I | .''`. Debian GNU/Linux Developer just don't see the point." -- | : :' : Happy to accept PGP signed Matthew Kirkwood, OxLUG mailing | `. `' or encrypted mail - RSA list. | `-key on the keyservers. signature.asc Description: PGP signature
Bug#949003: Doesn't work on 64 bit architectures
On Wed, 2020-01-15 at 22:49 +0100, Roberto Lumbreras wrote: > Hi, > > Could you please send me how to reproduce the bug? > It just works for me... but for sure my setup is different. I'm trying to use UML with slirp and it crashes before i even manage to setup a network connection :/ I can have a look at giving you a more specific reproduction method if you can't trigger it but that will probably take a few days at least; from the code it seems it somewhat wack-a-mole still though.. > On Wed, Jan 15, 2020 at 10:03 PM Sjoerd Simons > wrote: > > > Package: slirp > > Version: 1:1.0.17-9 > > Severity: important > > > > The last upload fixes slirp crashes directly on startup on amd64; > > It now > > just crashes > > when starting to use it > > > > backtrace: > > Program terminated with signal SIGSEGV, Segmentation fault. > > #0 0x5567818fa30b in tcp_reass (tp=tp@entry=0x556782590610, > > ti=0x82590610, ti@entry=0x0, m=, m@entry=0x0) > > at ./tcp_input.c:210 > > 210 ./tcp_input.c: No such file or directory. > > (gdb) bt > > #0 0x5567818fa30b in tcp_reass (tp=tp@entry=0x556782590610, > > ti=0x82590610, ti@entry=0x0, m=, m@entry=0x0) > > at ./tcp_input.c:210 > > #1 0x5567818fb8c1 in tcp_input (m=0x55678258ed00, > > iphlen= > out>, inso=inso@entry=0x0) at ./tcp_input.c:1074 > > #2 0x5567818f073c in ip_input (m=) at > > ip_input.c:214 > > #3 0x5567818f86ef in sl_dispatch (ttyp=ttyp@entry=0x55678258b2 > > d0) at > > ./sl.c:127 > > #4 0x5567818f889e in sl_input (ttyp=0x55678258b2d0, > > if_bptr=0x7ffdd869e9e9 "\300\004\005\264\004\002\b\n\366KBX", > > if_n=) at ./sl.c:35 > > #5 0x5567818ef6b2 in if_input (ttyp=0x55678258b2d0) at > > ./if.c:191 > > #6 0x5567818f24a4 in main_loop () at ./main.c:1158 > > #7 0x5567818e37d7 in main (argc=1, argv=0x7ffdd869f848) at > > ./main.c:95 > > > > > > Problem now is usage of dereferences of seg_next which again is a > > pointer > > cast to a 32 bit value to cause disaster. > > > > Most likely all the usages of `#if SIZEOF_CHAR_P == 4` should be > > reviewed > > and > > fixed up to properly make slirp work on 64 bit systrms... > > > > -- System Information: > > Debian Release: bullseye/sid > > APT prefers unstable-debug > > APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, > > 'testing'), (500, 'stable'), (1, 'experimental') > > Architecture: amd64 (x86_64) > > > > Kernel: Linux 5.4.0-2-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 slirp depends on: > > ii libc6 2.29-9 > > ii libcrypt1 1:4.4.10-10 > > > > slirp recommends no packages. > > > > slirp suggests no packages. > > > > -- no debconf information > > > >
Bug#866965: re: dosemu: DPMI unhandled exception instability back again
tag 866965 moreinfo unreproducible thanks Hi everyone! Can you still reproduce this bug? I'm running stretch's dosemu under buster and I have found no issues so far :-/ Thanks for checking!
Bug#949003: Doesn't work on 64 bit architectures
Hi, Could you please send me how to reproduce the bug? It just works for me... but for sure my setup is different. On Wed, Jan 15, 2020 at 10:03 PM Sjoerd Simons wrote: > Package: slirp > Version: 1:1.0.17-9 > Severity: important > > The last upload fixes slirp crashes directly on startup on amd64; It now > just crashes > when starting to use it > > backtrace: > Program terminated with signal SIGSEGV, Segmentation fault. > #0 0x5567818fa30b in tcp_reass (tp=tp@entry=0x556782590610, > ti=0x82590610, ti@entry=0x0, m=, m@entry=0x0) > at ./tcp_input.c:210 > 210 ./tcp_input.c: No such file or directory. > (gdb) bt > #0 0x5567818fa30b in tcp_reass (tp=tp@entry=0x556782590610, > ti=0x82590610, ti@entry=0x0, m=, m@entry=0x0) > at ./tcp_input.c:210 > #1 0x5567818fb8c1 in tcp_input (m=0x55678258ed00, iphlen= out>, inso=inso@entry=0x0) at ./tcp_input.c:1074 > #2 0x5567818f073c in ip_input (m=) at ip_input.c:214 > #3 0x5567818f86ef in sl_dispatch (ttyp=ttyp@entry=0x55678258b2d0) at > ./sl.c:127 > #4 0x5567818f889e in sl_input (ttyp=0x55678258b2d0, > if_bptr=0x7ffdd869e9e9 "\300\004\005\264\004\002\b\n\366KBX", > if_n=) at ./sl.c:35 > #5 0x5567818ef6b2 in if_input (ttyp=0x55678258b2d0) at ./if.c:191 > #6 0x5567818f24a4 in main_loop () at ./main.c:1158 > #7 0x5567818e37d7 in main (argc=1, argv=0x7ffdd869f848) at ./main.c:95 > > > Problem now is usage of dereferences of seg_next which again is a pointer > cast to a 32 bit value to cause disaster. > > Most likely all the usages of `#if SIZEOF_CHAR_P == 4` should be reviewed > and > fixed up to properly make slirp work on 64 bit systrms... > > -- System Information: > Debian Release: bullseye/sid > APT prefers unstable-debug > APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, > 'testing'), (500, 'stable'), (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.4.0-2-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 slirp depends on: > ii libc6 2.29-9 > ii libcrypt1 1:4.4.10-10 > > slirp recommends no packages. > > slirp suggests no packages. > > -- no debconf information > -- Regards, Roberto Lumbreras Debian developer
Bug#810239: ITA: ratfor -- Rational Fortran preprocessor for Fortran 77
Control: retitle -1 ITA: ratfor -- Rational Fortran preprocessor for Fortran 77 In intend to adopt the orphaned "ratfor" package since it may help in future maintenance of the "iraf" package (some astronomers *love* old programs!). The package will be maintained under the debian-science umbrella, and therefore live there on salsa: https://salsa.debian.org/science-team/ratfor Best regards Ole
Bug#949005: ITP: twig-i18n-extension - The Twig i18n extension is a library that provides the i18n extension for Twig
Package: wnpp Owner: phpMyAdmin Team Severity: wishlist * Package name : twig-i18n-extension Version : 2.0.0 Upstream Author : Fabien Potencier & phpMyAdmin contributors * URL : https://github.com/phpmyadmin/twig-i18n-extension * License : MIT Programming Lang: PHP Description : twig-i18n-extension is a php library that provides the i18n Twig extension This package is a dependency of phpMyAdmin since version 5.0.2 (not yet released, 5.0.1 for now) (https://github.com/phpmyadmin/phpmyadmin/pull/15674) The library is a fork of twig-extensions that only contains the i18n extension. Ref: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901502 Ref: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946301#17 VCS-Git: https://salsa.debian.org/phpmyadmin-team/twig-i18n-extension
Bug#949004: syndication FTCBFS: missing Build-Depends: qttools5-dev
Source: syndication Version: 1:5.62.0-3 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs syndication fails to cross build from source, because it misses a dependency on qttools5-dev. Please refer to #915122 for details. Please consider applying the attached patch. Helmut diff --minimal -Nru syndication-5.62.0/debian/changelog syndication-5.62.0/debian/changelog --- syndication-5.62.0/debian/changelog 2019-11-30 22:20:50.0 +0100 +++ syndication-5.62.0/debian/changelog 2020-01-15 18:43:25.0 +0100 @@ -1,3 +1,10 @@ +syndication (1:5.62.0-3.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Build-Depends: qttools5-dev. See #915122. (Closes: #-1) + + -- Helmut Grohne Wed, 15 Jan 2020 18:43:25 +0100 + syndication (1:5.62.0-3) unstable; urgency=medium * Team upload. diff --minimal -Nru syndication-5.62.0/debian/control syndication-5.62.0/debian/control --- syndication-5.62.0/debian/control 2019-11-30 22:14:52.0 +0100 +++ syndication-5.62.0/debian/control 2020-01-15 18:43:24.0 +0100 @@ -11,7 +11,7 @@ libkf5codecs-dev (>= 5.62.0~), pkg-kde-tools (>> 0.15.15), qtbase5-dev (>= 5.11.0~), - qttools5-dev-tools (>= 5.11.0~), + qttools5-dev (>= 5.11.0~), Standards-Version: 4.4.0 Homepage: https://projects.kde.org/projects/kde/pim/syndication Vcs-Browser: https://salsa.debian.org/qt-kde-team/kde/syndication
Bug#948728: (No Subject)
In case anyone is interested, I filed a bug report for APT: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948735 >postgresql-client-11 sounds like a bug but the dev seems to be ignoring it. >postgresql-common I found this: https://www.postgresql.org/message-id/cabuevewgx16f-%2bwpk-rkh%2brufgcpveg0xjcwazoobyzka_j...@mail.gmail.com
Bug#949002: Package ready in principle
Hi all, I forgot to add that I already have a package prepared for this. Can someone help me in bringing it into sid? I have no idea how this process works - I prepared the package using dh-make-golang, and now have a git repository which builds the package using git-buildpackage. Thanks in advance! Cheers, Ben
Bug#949003: Doesn't work on 64 bit architectures
Package: slirp Version: 1:1.0.17-9 Severity: important The last upload fixes slirp crashes directly on startup on amd64; It now just crashes when starting to use it backtrace: Program terminated with signal SIGSEGV, Segmentation fault. #0 0x5567818fa30b in tcp_reass (tp=tp@entry=0x556782590610, ti=0x82590610, ti@entry=0x0, m=, m@entry=0x0) at ./tcp_input.c:210 210 ./tcp_input.c: No such file or directory. (gdb) bt #0 0x5567818fa30b in tcp_reass (tp=tp@entry=0x556782590610, ti=0x82590610, ti@entry=0x0, m=, m@entry=0x0) at ./tcp_input.c:210 #1 0x5567818fb8c1 in tcp_input (m=0x55678258ed00, iphlen=, inso=inso@entry=0x0) at ./tcp_input.c:1074 #2 0x5567818f073c in ip_input (m=) at ip_input.c:214 #3 0x5567818f86ef in sl_dispatch (ttyp=ttyp@entry=0x55678258b2d0) at ./sl.c:127 #4 0x5567818f889e in sl_input (ttyp=0x55678258b2d0, if_bptr=0x7ffdd869e9e9 "\300\004\005\264\004\002\b\n\366KBX", if_n=) at ./sl.c:35 #5 0x5567818ef6b2 in if_input (ttyp=0x55678258b2d0) at ./if.c:191 #6 0x5567818f24a4 in main_loop () at ./main.c:1158 #7 0x5567818e37d7 in main (argc=1, argv=0x7ffdd869f848) at ./main.c:95 Problem now is usage of dereferences of seg_next which again is a pointer cast to a 32 bit value to cause disaster. Most likely all the usages of `#if SIZEOF_CHAR_P == 4` should be reviewed and fixed up to properly make slirp work on 64 bit systrms... -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-2-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 slirp depends on: ii libc6 2.29-9 ii libcrypt1 1:4.4.10-10 slirp recommends no packages. slirp suggests no packages. -- no debconf information
Bug#948932: bug #948932 also has a python problem, with hplip-data
It is worth looking at bug #948932, which has a patch for a python problem with hplip-data. It is possible that this patch will resolve #948932 as well
Bug#949002: ITP: golang-github-ddevault-go-libvterm -- fork of go-libvterm used by the aerc mail client
Package: wnpp Severity: wishlist Owner: Ben Fiedler * Package name: golang-github-ddevault-go-libvterm Version : 0.0~git20190526.b7d861d-1 Upstream Author : Drew DeVault * URL : https://github.com/ddevault/go-libvterm * License : Expat Programming Lang: Go Description : fork of go-libvterm used by the aerc mail client go-libvterm Go binding to libvterm . This is my personal fork for use with aerc (https://git.sr.ht/~sircmpwn/aerc). Breaking changes will come unannounced. . This is hosted on GitHub because of a bug in Golang (https://github.com/golang/go/issues/32260). Issues and pull requests here will be ignored, please send patches to the aerc mailing list instead. License MIT This package must be provided in order to later package the aerc mail client [1], which is tracked here [2]. [1]: https://aerc-mail.org [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947962
Bug#948987: libssl: libssl1.1 segfaults when kopete is using it (libjingle-call)
On 2020-01-15 17:12:29 [+0100], Jens Schmidt wrote: > Package: libssl1.1 > Version: 1.1.1d-0+deb10u2 > Severity: critical > File: libssl > Justification: breaks unrelated software > > Dear Maintainer, > > when using kopete, dmesg shows a shitload of: > [timestamp] libjingle-call[11878]: segfault at 48 ip 7f693f599ed3 sp > 7fff4db27280 error 4 in libcrypto.so.1.1[7f693f561000+19e000] > [timestamp] Code: 40 24 01 00 00 00 4c 89 e2 c7 40 50 01 00 00 00 0f ae f0 e8 > af 83 fc ff 85 c0 74 6c e8 76 9a fc ff 48 89 43 70 48 85 c0 74 2d <48> 8b 45 > 48 48 85 c0 74 74 48 89 df ff d0 85 c0 0f 84 a7 00 00 00 > > I assume this is not intended behaviour. > > This is reproduceable on all (7) of our workstations. Same hardware, same > software. Isn't this the same report as #913679 ? > Regards > Jens Sebastian
Bug#932582: anbox: ignores mouse input
On 15/01/2020 14.15, Shengjing Zhu wrote: The snap version includes a software render feature. Maybe you're using this? This could be slow. I'm not sure how to verify this, but it makes sense that hardware acceleration is not being used. The Debian package must use hardware render. Intel ARK doesn't show much information about your CPU's graphic[1]. Maybe this CPU is too old? (run `anbox system-info` will give your some info) version: 4 snap-revision: 186 cpu: arch: x86 brand: Intel(R) Core(TM) i5 CPU M 540 @ 2.53GHz features: - aes os: name: Debian GNU/Linux version: snap-based: true kernel: version: Linux version 5.4.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 9.2.1 20200104 (Debian 9.2.1-22)) #1 SMP Debian 5.4.8-1 (2020-01-05) binder: true ashmem: true graphics: egl: vendor: Mesa Project version: 1.4 (DRI2) extensions: - EGL_ANDROID_native_fence_sync - EGL_CHROMIUM_sync_control - EGL_EXT_buffer_age - EGL_EXT_image_dma_buf_import - EGL_EXT_image_dma_buf_import_modifiers - EGL_KHR_config_attribs - EGL_KHR_create_context - EGL_KHR_create_context_no_error - EGL_KHR_fence_sync - EGL_KHR_get_all_proc_addresses - EGL_KHR_gl_colorspace - EGL_KHR_gl_renderbuffer_image - EGL_KHR_gl_texture_2D_image - EGL_KHR_gl_texture_3D_image - EGL_KHR_gl_texture_cubemap_image - EGL_KHR_image - EGL_KHR_image_base - EGL_KHR_image_pixmap - EGL_KHR_no_config_context - EGL_KHR_reusable_sync - EGL_KHR_surfaceless_context - EGL_EXT_pixel_format_float - EGL_KHR_wait_sync - EGL_MESA_configless_context - EGL_MESA_drm_image - EGL_MESA_image_dma_buf_export - EGL_NOK_texture_from_pixmap - EGL_WL_bind_wayland_display gles2: vendor: Intel Open Source Technology Center vendor: OpenGL ES 2.0 Mesa 18.0.5 extensions: - GL_ANGLE_texture_compression_dxt3 - GL_ANGLE_texture_compression_dxt5 - GL_APPLE_texture_max_level - GL_EXT_blend_minmax - GL_EXT_compressed_ETC1_RGB8_sub_texture - GL_EXT_discard_framebuffer - GL_EXT_draw_buffers - GL_EXT_draw_elements_base_vertex - GL_EXT_frag_depth - GL_EXT_map_buffer_range - GL_EXT_multi_draw_arrays - GL_EXT_occlusion_query_boolean - GL_EXT_polygon_offset_clamp - GL_EXT_read_format_bgra - GL_EXT_robustness - GL_EXT_separate_shader_objects - GL_EXT_texture_border_clamp - GL_EXT_texture_compression_dxt1 - GL_EXT_texture_filter_anisotropic - GL_EXT_texture_format_BGRA - GL_EXT_texture_rg - GL_EXT_texture_type_2_10_10_10_REV - GL_EXT_unpack_subimage - GL_KHR_blend_equation_advanced - GL_KHR_context_flush_control - GL_KHR_debug - GL_KHR_no_error - GL_KHR_robustness - GL_NV_draw_buffers - GL_NV_fbo_color_attachments - GL_NV_read_buffer - GL_NV_read_depth - GL_NV_read_depth_stencil - GL_NV_read_stencil - GL_OES_EGL_image - GL_OES_EGL_image_external - GL_OES_EGL_sync - GL_OES_compressed_ETC1_RGB8_texture - GL_OES_depth24 - GL_OES_depth_texture - GL_OES_draw_elements_base_vertex - GL_OES_element_index_uint - GL_OES_fbo_render_mipmap - GL_OES_get_program_binary - GL_OES_mapbuffer - GL_OES_packed_depth_stencil - GL_OES_required_internalformat - GL_OES_rgb8_rgba8 - GL_OES_standard_derivatives - GL_OES_stencil8 - GL_OES_surfaceless_context - GL_OES_texture_3D - GL_OES_texture_border_clamp - GL_OES_texture_float - GL_OES_texture_float_linear - GL_OES_texture_half_float - GL_OES_texture_half_float_linear - GL_OES_texture_npot - GL_OES_vertex_array_object - GL_OES_vertex_half_float Not sure if that provides any insight to help solve why the mouse/keyboard won't work with packaged version. I'm comfortable that its plausible the CPU is too old, albeit, the PC is circa 2010, so old, but not that old. And I'm not sure if anyone tests anbox with XFCE, the integration with XFCE may also be a problem. [1] https://ark.intel.com/content/www/us/en/ark/products/43544/intel-core-i5-540m-processor-3m-cache-2-53-ghz.html
Bug#949001: sssd.service will not launch with installed config file permissions/ownership
Package: sssd Version: 1.15.0-3 user@host-debian9:~$ sudo apt install sssd Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: adcli ldap-utils libbasicobjects0 libc-ares2 libcollection4 libdhash1 libini-config5 libipa-hbac0 libldap-2.4-2 libldap-common libnfsidmap2 libnl-route-3-200 libnss-sss libpam-pwquality libpam-sss libpath-utils1 libref-array1 libsasl2-modules libsasl2-modules-gssapi-mit libsss-idmap0 libsss-nss-idmap0 libsss-sudo python-sss sssd-ad sssd-ad-common sssd-common sssd-ipa sssd-krb5 sssd-krb5-common sssd-ldap sssd-proxy Suggested packages: libsasl2-modules-ldap libsasl2-modules-otp libsasl2-modules-sql apparmor sssd-tools The following NEW packages will be installed: adcli ldap-utils libbasicobjects0 libc-ares2 libcollection4 libdhash1 libini-config5 libipa-hbac0 libnfsidmap2 libnl-route-3-200 libnss-sss libpam-pwquality libpam-sss libpath-utils1 libref-array1 libsasl2-modules-gssapi-mit libsss-idmap0 libsss-nss-idmap0 libsss-sudo python-sss sssd sssd-ad sssd-ad-common sssd-common sssd-ipa sssd-krb5 sssd-krb5-common sssd-ldap sssd-proxy The following packages will be upgraded: libldap-2.4-2 libldap-common libsasl2-modules 3 upgraded, 29 newly installed, 0 to remove and 181 not upgraded. Need to get 2,875 kB of archives. After this operation, 8,519 kB of additional disk space will be used. Do you want to continue? [Y/n] y Get:1 http://ftp.us.debian.org/debian stretch/main amd64 libldap-common all 2.4.44+dfsg-5+deb9u3 [85.7 kB] Get:2 http://ftp.us.debian.org/debian stretch/main amd64 libldap-2.4-2 amd64 2.4.44+dfsg-5+deb9u3 [220 kB] Get:3 http://ftp.us.debian.org/debian stretch/main amd64 libnfsidmap2 amd64 0.25-5.1 [32.0 kB] Get:4 http://ftp.us.debian.org/debian stretch/main amd64 adcli amd64 0.8.2-1+b1 [86.5 kB] Get:6 http://ftp.us.debian.org/debian stretch/main amd64 ldap-utils amd64 2.4.44+dfsg-5+deb9u3 [192 kB] Get:8 http://ftp.us.debian.org/debian stretch/main amd64 libnl-route-3-200 amd64 3.2.27-2 [136 kB] Get:9 http://ftp.us.debian.org/debian stretch/main amd64 libpam-pwquality amd64 1.3.0-1+b1 [13.0 kB] Get:10 http://ftp.us.debian.org/debian stretch/main amd64 libbasicobjects0 amd64 0.6.0-1 [5,886 B] Get:11 http://ftp.us.debian.org/debian stretch/main amd64 libc-ares2 amd64 1.12.0-1+deb9u1 [81.6 kB] Get:12 http://ftp.us.debian.org/debian stretch/main amd64 libcollection4 amd64 0.6.0-1 [22.1 kB] Get:13 http://ftp.us.debian.org/debian stretch/main amd64 libdhash1 amd64 0.6.0-1 [8,686 B] Get:14 http://ftp.us.debian.org/debian stretch/main amd64 libpath-utils1 amd64 0.6.0-1 [8,720 B] Get:15 http://ftp.us.debian.org/debian stretch/main amd64 libref-array1 amd64 0.6.0-1 [7,220 B] Get:16 http://ftp.us.debian.org/debian stretch/main amd64 libini-config5 amd64 0.6.0-1 [42.8 kB] Get:17 http://ftp.us.debian.org/debian stretch/main amd64 libipa-hbac0 amd64 1.15.0-3 [20.0 kB] Get:18 http://ftp.us.debian.org/debian stretch/main amd64 libnss-sss amd64 1.15.0-3 [28.6 kB] Get:19 http://ftp.us.debian.org/debian stretch/main amd64 libpam-sss amd64 1.15.0-3 [32.9 kB] Get:20 http://ftp.us.debian.org/debian stretch/main amd64 libsss-idmap0 amd64 1.15.0-3 [24.3 kB] Get:21 http://ftp.us.debian.org/debian stretch/main amd64 libsss-nss-idmap0 amd64 1.15.0-3 [21.5 kB] Get:22 http://ftp.us.debian.org/debian stretch/main amd64 libsss-sudo amd64 1.15.0-3 [22.5 kB] Get:23 http://ftp.us.debian.org/debian stretch/main amd64 python-sss amd64 1.15.0-3 [65.8 kB] Get:5 http://security-cdn.debian.org/debian-security stretch/updates/main amd64 libsasl2-modules amd64 2.1.27~101-g0780600+dfsg-3+deb9u1 [102 kB] Get:7 http://security-cdn.debian.org/debian-security stretch/updates/main amd64 libsasl2-modules-gssapi-mit amd64 2.1.27~101-g0780600+dfsg-3+deb9u1 [90.6 kB] Get:24 http://ftp.us.debian.org/debian stretch/main amd64 sssd-common amd64 1.15.0-3 [958 kB] Get:25 http://ftp.us.debian.org/debian stretch/main amd64 sssd-ad-common amd64 1.15.0-3 [62.7 kB] Get:26 http://ftp.us.debian.org/debian stretch/main amd64 sssd-krb5-common amd64 1.15.0-3 [77.2 kB] Get:27 http://ftp.us.debian.org/debian stretch/main amd64 sssd-ad amd64 1.15.0-3 [115 kB] Get:28 http://ftp.us.debian.org/debian stretch/main amd64 sssd-ipa amd64 1.15.0-3 [188 kB] Get:29 http://ftp.us.debian.org/debian stretch/main amd64 sssd-krb5 amd64 1.15.0-3 [23.9 kB] Get:30 http://ftp.us.debian.org/debian stretch/main amd64 sssd-ldap amd64 1.15.0-3 [38.7 kB] Get:31 http://ftp.us.debian.org/debian stretch/main amd64 sssd-proxy amd64 1.15.0-3 [45.3 kB] Get:32 http://ftp.us.debian.org/debian stretch/main amd64 sssd amd64 1.15.0-3 [15.2 kB] Fetched 2,875 kB in 1s (1,757 kB/s) Reading changelogs... Done Extracting templates from packages: 100% (Reading database ... 131575 files and directories currently installed.) Preparing to unpack .../00-libldap-common_2.4.44+dfsg-5+deb9u3_all.deb ... Unpacking libldap-common
Bug#949000: packaging-tutorial: the last line gets dropped off from slide 47
Package: packaging-tutorial
Version: 0.24
Severity: normal
Tags: patch
Dear Maintainer,
While preparing a translation into Dutch,
I noticed that the last line of slide 47
gets lost, because there is one line too many
to fit on that slide.
Please find attached a patch to fix the problem in the .pot file.
Cheers,
Frans Spiesschaert
-- System Information:
Debian Release: 10.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=nl_BE.utf8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8),
LANGUAGE=nl_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
>From 8bf1d5e7ce8a5fb1904499176d9e488a7aec297c Mon Sep 17 00:00:00 2001
From: Frans Spiesschaert
Date: Wed, 15 Jan 2020 21:04:44 +0100
Subject: [PATCH] Prevent the last line to get dropped off from slide 47
---
po4a/po/packaging-tutorial.pot | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/po4a/po/packaging-tutorial.pot b/po4a/po/packaging-tutorial.pot
index 200d188..8a66819 100644
--- a/po4a/po/packaging-tutorial.pot
+++ b/po4a/po/packaging-tutorial.pot
@@ -2391,7 +2391,7 @@ msgstr ""
#: packaging-tutorial.tex:1199
msgid ""
"\\textbf{ITA}: \\textbf{I}ntent \\textbf{T}o \\textbf{A}dopt Someone "
-"intends to adopt the package You could propose your help!"
+"intends to adopt the package. You could propose your help!"
msgstr ""
#. type: itemize
--
2.20.1
Bug#948921: linux-image-5.4.0-2-amd64: decrypting root partition does not work on 5.4.0 (works on 5.3.0) with decrypt_keyctl
Hi Luc, On Wed, Jan 15, 2020 at 09:22:05AM +0100, Luc Maisonobe wrote: > Here are some additional informations about the problem. > > I rechecked it was not a keyboard layout problem by setting up > an additional luks key, a very short one that used only keys that > were at the same position in both qwerty and azerty. It does > not work, so it's definitely not a keyboard problem. > > The error I get on boot is as follows: > > Caching passphrase for sdb1_crypt:*** > [ 15.212421] device-mapper: table: 253:0: crypt: Error allocating > crypto tfm > device-mapper: reload ioctl on failed: No such file or directory > cryptsetup: ERROR: sdb1_crypt: cryptsetup failed, bad password or options? > > Caching passphrase for sdb1_crypt: > > I tried to use a key file instead of a key typed by user just > like I did on the other laptop. I do not want to use this method > for this specific machine for security reasons (it should not be > abel to boot unattended), but tried it temporarily. I regenerated > the initramfs after changing the /etc/crypttab file, but it didn't > work either. When generating initramfs, I got the following warning, > so it may explain why it didn't work. > > cryptsetup: WARNING: Skipping root target sdb1_crypt: uses a key file > > In this case (booting with a key file), the error was different: > > Volume group "vg-ssd" not found > Cannot process volume group vg-ssd > Volume group "vg-hdd" not found > Cannot process volume group vg-hdd > Volume group "vg-hdd" not found > Cannot process volume group vg-hdd > Volume group "vg-hdd" not found > ... > Cannot process volume group vg-hdd > Volume group "vg-hdd" not found > Cannot process volume group vg-hdd > mdadm: error opening /dev/md?*: No such file or directory > Cannot process volume group vg-hdd > Volume group "vg-hdd" not found > > then the boot process drops to initramfs shell. Exploring the filesystem > at this stage, I didn't find the key file. Your issue sounds like #948593. In case yes, we should reassign and merge it with that bug. Regards, Salvatore
Bug#938421: (no subject)
Control: reassign -1 ftp.debian.org Control: retitle -1 RM: rurple-ng -- RoQA; dead upstream; unmaintained; low popcon; blocking py2 removal The existing maintainer does not plan to port it to Python 3, so let's just remove it.
Bug#943398: linux-perf-5.2: perf report segmentation fault
Hi, On Tue, Jan 14, 2020 at 01:08:02AM +0100, Bernhard Übelacker wrote: > Dear Maintainer, > I could reproduce using linux-perf-5.2 and it is > also visible in linux-perf-5.4 5.4.8-1, > by just pressing enter. > > The crash happens because in line 3172 > function hist_browser__selected_entry returns > browser->he_selection, which is at this time a > null pointer. > This null pointer gets dereferenced to > access the res_samples member. > > Upstream seems to have fixed other occourences [1] > of browser->he_selection being null, but this is > already contained in 5.4 while a crash still happens. Can you report the issue directly upstream? Regards, Salvatore
Bug#948999: pixelize: Proposal to update pixelize package
Package: pixelize Version: 1.0.0-1build1 Severity: wishlist Tags: newcomer Dear Maintainer, For some of my own needs I decided to port the program "pixelize" to a the latest version of GTK3 (the source code has not been touched since early 2009). In the process, I fixed a few bugs and added some features (I was needing). I sent some emails to Paul Wilkins (the original author) to let him know of the work I was doing but so far I did not receive any feedback from him. As the pixelize package seems to be considered quite out of date by the debian tracker I thought you might be interested in the modifications/additions/fixes I brought to pixelize. My friendly fork is available on github: https://github.com/jcdubois/pixelize Let me know if this is of any interest to you or if you have any question. Regards -- System Information: Debian Release: buster/sid APT prefers eoan-updates APT policy: (500, 'eoan-updates'), (500, 'eoan-security'), (500, 'eoan'), (100, 'eoan-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.3.0-24-generic (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pixelize depends on: ii libc6 2.30-0ubuntu2 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-1build1 ii libglib2.0-02.62.1-1 ii libgtk2.0-0 2.24.32-4ubuntu1 pixelize recommends no packages. pixelize suggests no packages. -- no debconf information
Bug#948851: (no subject)
>Are you sure you did't check "Show all fields templated" in Configuration -> >Template? I apparently did, without knowing what that meant... By un-checking the box, I was able to edit the text to remove the ':'s and alter the length of the long lines to bypass the other bug... Is there documentation on using QtPass? I could not find any... Based upon my own experience, the rule for the "text box" (does it have a name - there is no description by it...?) appears to be: "For each line that has a ':' in it, make a template field out of what is to the right of the ':' and bring up any text to the left of it and place it opposite the template as a description." (Are there other rules...?)
Bug#948257: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/var/tmp/mkinitramfs_N1a1Mk/lib/modules/5.4.0-1-amd64/modules.builtin.bin'
Same problem on my computer kmod -V kmod version 26 +XZ -ZLIB +LIBCRYPTO -EXPERIMENTAL uname -ar 5.4.0-2-amd64 #1 SMP Debian 5.4.8-1 (2020-01-05) x86_64 GNU/Linux On Mon, 06 Jan 2020 10:02:05 +0530 crvi wrote: > Package: kmod > Version: 26+20191223-1 > Severity: important > > Dear Maintainer, > > * What led up to the situation? > > apt-get dist-upgrade > > * What exactly did you do (or not do) that was effective (or > ineffective)? > > apt-get dist-upgrade > > * What was the outcome of this action? > > Processing triggers for initramfs-tools (0.135) ... > update-initramfs: Generating /boot/initrd.img-5.4.0-1-amd64 > depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open > builtin file > '/var/tmp/mkinitramfs_DRc0S1/lib/modules/5.4.0-1-amd64/modules.builtin.bin > depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open > builtin file > '/var/tmp/mkinitramfs_DRc0S1/lib/modules/5.4.0-1-amd64/modules.builtin.bin > depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open > builtin file > '/var/tmp/mkinitramfs_DRc0S1/lib/modules/5.4.0-1-amd64/modules.builtin.bin > > * What outcome did you expect instead? > > Successful ramfs generation > > > > -- System Information: > Debian Release: bullseye/sid > APT prefers unstable-debug > APT policy: (500, 'unstable-debug'), (500, 'unstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.4.0-1-amd64 (SMP w/1 CPU core) > Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE > Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en (charmap=UTF-8) > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages kmod depends on: > ii libc6 2.29-8 > ii libkmod2 26+20191223-1 > ii liblzma5 5.2.4-1+b1 > ii libssl1.1 1.1.1d-2 > ii lsb-base 11.1.0 > > kmod recommends no packages. > > kmod suggests no packages. > > -- no debconf information
Bug#948708: Further information
Hey, Finally found firefox-esr-debugsym. Attached is the output of bt from gdb with debug symbols loaded, and disassemble too. Looks like it's just going into NULL memory? Should this go upstream instead? Let me know if I can provide any further information. Thanks, /Nick Thread 1 "firefox-esr" received signal SIGILL, Illegal instruction. 0xf2aaf1f0 in e843419@07fb_00070e4f_34c () from /usr/lib/firefox-esr/libxul.so (gdb) bt #0 0xf2aaf1f0 in e843419@07fb_00070e4f_34c () at ./build-browser/dist/include/nsCOMPtr.h:367 #1 0xf2aaeff8 in nsCOMPtr_base::~nsCOMPtr_base() (this=0xd8f8, __in_chrg=) at ./build-browser/dist/include/nsCOMPtr.h:331 #2 0xf2aaeff8 in nsCOMPtr::~nsCOMPtr() (this=0xd8f8, __in_chrg=) at ./build-browser/dist/include/nsCOMPtr.h:381 #3 0xf2aaeff8 in nsCommandLine::EnumerateHandlers(nsresult (*)(nsICommandLineHandler*, nsICommandLine*, void*), void*) (this=this@entry=0xe6aa8040, aCallback=aCallback@entry=0xf2aad7d0 , aClosure=aClosure@entry=0x0) at ./toolkit/components/commandlines/nsCommandLine.cpp:424 #4 0xf2ab0228 in nsCommandLine::Run() (this=0xe6aa8040) at ./toolkit/components/commandlines/nsCommandLine.cpp:503 #5 0xf2c4498c in XREMain::XRE_mainRun() (this=this@entry=0xdc18) at ./build-browser/dist/include/nsCOMPtr.h:841 #6 0xf2c44f70 in XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) (this=this@entry=0xdc18, argc=argc@entry=1, argv=argv@entry=0xef18, aConfig=...) at ./toolkit/xre/nsAppRunner.cpp:4750 #7 0xf2c45478 in XRE_main(int, char**, mozilla::BootstrapConfig const&) (argc=1, argv=0xef18, aConfig=...) at ./toolkit/xre/nsAppRunner.cpp:4831 #8 0xaaab0958 in do_main(int, char**, char**) (argc=, argv=, envp=0xef28) at ./build-browser/dist/include/mozilla/UniquePtr.h:308 #9 0xaaab009c in main(int, char**, char**) (argc=1, argv=0xef18, envp=0xef28) at ./browser/app/nsBrowserApp.cpp:296 (gdb) disassemble /s Dump of assembler code for function e843419@07fb_00070e4f_34c: ./build-browser/dist/include/nsCOMPtr.h: 367 ./build-browser/dist/include/nsCOMPtr.h: No such file or directory. => 0xf2aaf1f0 <+0>: .inst 0x ; undefined 0xf2aaf1f4 <+4>: b 0xf2aaf008 End of assembler dump. (gdb) disassemble /m Dump of assembler code for function e843419@07fb_00070e4f_34c: 367 in ./build-browser/dist/include/nsCOMPtr.h 0xf2aaf1cc <+1300>: ldr x1, [x0] 0xf2aaf1d0 <+1304>: ldr x1, [x1, #16] 0xf2aaf1d4 <+1308>: blr x1 0xf2aaf1d8 <+1312>: b 0xf2aaee14 0xf2aaf1dc <+1316>: stp x25, x26, [sp, #48] 0xf2aaf1e0 <+1320>: stp x27, x28, [sp, #64] 0xf2aaf1e4 <+1324>: bl 0xefa82c80 <__stack_chk_fail@plt> 0xf2aaf1e8: b 0xf2ab01e8 0xf2aaf1ec: nop => 0xf2aaf1f0 <+0>: .inst 0x ; undefined 0xf2aaf1f4 <+4>: b 0xf2aaf008 0xf2aaf1f8: .inst 0x ; undefined 0xf2aaf1fc: .inst 0x ; undefined 0xf2aaf200: .inst 0x ; undefined 0xf2aaf204: .inst 0x ; undefined 0xf2aaf208: .inst 0x ; undefined 0xf2aaf20c: .inst 0x ; undefined 0xf2aaf210: .inst 0x ; undefined
Bug#932582: anbox: ignores mouse input
On Thu, Jan 16, 2020 at 3:03 AM Alan MacLeod wrote: > > Hi, > > I've tried both the Snap and packaged versions: the Snap version works > fully, but is very slow, and the packaged version appears quicker, but I The snap version includes a software render feature. Maybe you're using this? This could be slow. > cannot interact with the applications - OP's description is exactly what > I am experiencing: everything opens, I can resize the windows and close > them, but I cannot interact with the application with mouse or keyboard. > > I'm using: > Debian Testing > kernel 5.4.0.2-amd64 > XFCE 4.14 > HP 8440p laptop - Intel core i5 540, 8 GB RAM The Debian package must use hardware render. Intel ARK doesn't show much information about your CPU's graphic[1]. Maybe this CPU is too old? (run `anbox system-info` will give your some info) And I'm not sure if anyone tests anbox with XFCE, the integration with XFCE may also be a problem. [1] https://ark.intel.com/content/www/us/en/ark/products/43544/intel-core-i5-540m-processor-3m-cache-2-53-ghz.html -- Shengjing Zhu
Bug#948998: freeradius: Consider compiling with collectd support
Package: freeradius Version: 3.0.19+dfsg-3 Severity: normal Dear Maintainer, radsniff was added to freeradius in 3.x.x and provides the ability to collect statistics when coupled with the collectd libraries. Adding this dependency is small compared to freeradius' existing dependency and thus shouldn't effect install size. -- System Information: Debian Release: 10.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores) 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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages freeradius depends on: ii freeradius-common 3.0.17+dfsg-1.1 ii freeradius-config 3.0.17+dfsg-1.1 ii libatomic1 8.3.0-6 ii libc6 2.28-10 ii libcap21:2.25-2 ii libct4 1.1.6-1+b1 ii libfreeradius3 3.0.19+dfsg-3 ii libgdbm6 1.18.1-5 ii libpam0g 1.3.1-5 ii libpcre3 2:8.39-12+b1 ii libperl5.285.28.1-6 ii libreadline8 8.0-3 ii libsqlite3-0 3.29.0-2 ii libssl1.1 1.1.1d-0+deb10u2 ii libtalloc2 2.1.16-3 ii libwbclient0 2:4.9.11+dfsg-1 ii lsb-base 10.2019051400 Versions of packages freeradius recommends: ii freeradius-utils 3.0.19+dfsg-3 Versions of packages freeradius suggests: pn freeradius-krb5 ii freeradius-ldap3.0.19+dfsg-3 pn freeradius-mysql pn freeradius-postgresql pn freeradius-python2 ii snmp 5.7.3+dfsg-5+b1 -- no debconf information
Bug#948997: ITP: rust-pgp -- OpenPGP implemented in pure Rust, permissively licensed
Package: wnpp Severity: wishlist Owner: Daniel Kahn Gillmor * Package name: rust-pgp Version : 0.4.0 Upstream Author : Friedel Ziegelmayer * URL : https://github.com/rpgp/rpgp * License : MIT or Apache 2.0 Programming Lang: Rust Description : OpenPGP implemented in pure Rust, permissively licensed rPGP is the only full Rust implementation of OpenPGP, following RFC4880 and RFC2440. It offers a minimal low-level API and does not prescribe trust schemes or key management policies. It fully supports all functionality required by the Autocrypt 1.1 e-mail encryption specification. This is used by the DeltaChat application, among other tools. --dkg signature.asc Description: PGP signature
Bug#948996: freeradius: Consider including support for collectd when compiling freeradius.
Package: freeradius Version: 3.0.19+dfsg-3 Severity: normal Dear Maintainer, Radsniff was introduced in the 3.x.x branch of code and when coupled with collectd can provide statistics collection. Including this option does add a libcollectd dependency, but seeing that freeradius already has a dozen or so libraries it depends on, this shouldn't add too much bloat to the package. -- System Information: Debian Release: 10.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores) 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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages freeradius depends on: ii freeradius-common 3.0.17+dfsg-1.1 ii freeradius-config 3.0.17+dfsg-1.1 ii libatomic1 8.3.0-6 ii libc6 2.28-10 ii libcap21:2.25-2 ii libct4 1.1.6-1+b1 ii libfreeradius3 3.0.19+dfsg-3 ii libgdbm6 1.18.1-5 ii libpam0g 1.3.1-5 ii libpcre3 2:8.39-12+b1 ii libperl5.285.28.1-6 ii libreadline8 8.0-3 ii libsqlite3-0 3.29.0-2 ii libssl1.1 1.1.1d-0+deb10u2 ii libtalloc2 2.1.16-3 ii libwbclient0 2:4.9.11+dfsg-1 ii lsb-base 10.2019051400 Versions of packages freeradius recommends: ii freeradius-utils 3.0.19+dfsg-3 Versions of packages freeradius suggests: pn freeradius-krb5 ii freeradius-ldap3.0.19+dfsg-3 pn freeradius-mysql pn freeradius-postgresql pn freeradius-python2 ii snmp 5.7.3+dfsg-5+b1 -- no debconf information
Bug#932582: anbox: ignores mouse input
Hi, I've tried both the Snap and packaged versions: the Snap version works fully, but is very slow, and the packaged version appears quicker, but I cannot interact with the applications - OP's description is exactly what I am experiencing: everything opens, I can resize the windows and close them, but I cannot interact with the application with mouse or keyboard. I'm using: Debian Testing kernel 5.4.0.2-amd64 XFCE 4.14 HP 8440p laptop - Intel core i5 540, 8 GB RAM apt policy anbox anbox: Installed: (none) Candidate: 0.0~git20191115-1 Version table: 0.0~git20191115-1 990 990 https://deb.debian.org/debian testing/contrib amd64 Packages 500 https://deb.debian.org/debian unstable/contrib amd64 Packages 100 /var/lib/dpkg/status 0.0~git20190124-1 500 500 https://deb.debian.org/debian stable/contrib amd64 Packages snap list anbox Name Version Rev Tracking Publisher Notes anbox 4-56c25f1 186 beta morphis devmode What other info can I provide? I'm currently running the Snap version. Thanks Alan
Bug#948992: tap.py removed the python-tap package, but dbus-python b-d's on that
On Wed, Jan 15, 2020 at 1:54 PM Simon McVittie wrote: > > Control: tags -1 + moreinfo > Control: found -1 1.2.14-1 > > On Wed, 15 Jan 2020 at 19:09:17 +0100, Matthias Klose wrote: > > tap.py removed the python-tap package, but dbus-python still b-d's on that > > package. > > Where do you see such a dependency and is it a problem? > > dbus-python 1.2.14-1 in testing B-D on python-tap and python3-tap. > > dbus-python 1.2.16-1 in sid B-D on python3-tap, only. > > Can I mark this bug as closed in 1.2.16-1 or is there something I'm > not seeing? yes, close this as there's nothing to do here > For now I'm marking this bug as found in 1.2.14-1 so that it doesn't > prevent dbus-python from migrating, which would have the opposite of the > effect you presumably intended. > > I had intended to wait for dbus-python 1.2.14-1 to migrate to testing > before uploading src:tap.py 3.0 with python-tap removed (upstream removed > support for Python 2 in that version), but Sandro Tosi did a team upload > of src:tap.py removing the python-tap binary package as soon as the > dependency had gone away in unstable, so I didn't have the opportunity > to wait for migration. oops, i squash them when i see them :) -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Bug#948995: ITP: r-cran-setrng -- GNU R set (normal) random number generator and seed
Package: wnpp Severity: wishlist Subject: ITP: r-cran-setrng -- GNU R set (normal) random number generator and seed Package: wnpp Owner: Andreas Tille Severity: wishlist * Package name: r-cran-setrng Version : 2013.9 Upstream Author : Paul Gilbert * URL : https://cran.r-project.org/package=setRNG * License : GPL-2 Programming Lang: GNU R Description : GNU R set (normal) random number generator and seed SetRNG provides utilities to help set and record the setting of the seed and the uniform and normal generators used when a random experiment is run. The utilities can be used in other functions that do random experiments to simplify recording and/or setting all the necessary information for reproducibility. See the vignette and reference manual for examples. Remark: This package is maintained by Debian R Packages Maintainers at https://salsa.debian.org/r-pkg-team/r-cran-setrng
Bug#948992: tap.py removed the python-tap package, but dbus-python b-d's on that
Control: tags -1 + moreinfo Control: found -1 1.2.14-1 On Wed, 15 Jan 2020 at 19:09:17 +0100, Matthias Klose wrote: > tap.py removed the python-tap package, but dbus-python still b-d's on that > package. Where do you see such a dependency and is it a problem? dbus-python 1.2.14-1 in testing B-D on python-tap and python3-tap. dbus-python 1.2.16-1 in sid B-D on python3-tap, only. Can I mark this bug as closed in 1.2.16-1 or is there something I'm not seeing? For now I'm marking this bug as found in 1.2.14-1 so that it doesn't prevent dbus-python from migrating, which would have the opposite of the effect you presumably intended. I had intended to wait for dbus-python 1.2.14-1 to migrate to testing before uploading src:tap.py 3.0 with python-tap removed (upstream removed support for Python 2 in that version), but Sandro Tosi did a team upload of src:tap.py removing the python-tap binary package as soon as the dependency had gone away in unstable, so I didn't have the opportunity to wait for migration. smcv
Bug#948752: RFS: rumur/2020.01.11-1 -- model checker for the Murphi language
On Tue, Jan 14, 2020 at 08:00:23AM -0800, Matthew Fernandez wrote: > > autopkgtest [04:41:21]: test librumur-api: [--- > Is there a way to run autopkgtest myself? I was expecting pdebuild would > do it but I can’t find options for this. Are you running it locally or > looking at build server results somewhere? There's some not entirely clear info in "man autopkgtest". I'm using an old-style not best way to run it, thus it's probably not the best idea to copy my schroot setup. You can use schroot (using a sane way...), lxc or qemu. There's more information in "man autopkgtest-virt-*"; especially autopkgtest-build-qemu seem trivial to use. > As far as I could tell, the build servers don't run the autopkgtests until > a sponsor uploads the package to NEW but maybe I am mistaken. Yeah, the official infrastructure uses only packages from the archive. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, ⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month. ⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake, ⠈⠳⣄ etc), let the drink age at least 3-6 months.
Bug#948522: If I rebuild src:file with libseccomp-dev installed, then "fakeroot file ..." crashes with "Bad system call"
Control: tag 948522 pending Daniel Schepler wrote... > As the subject says: in my environment with libseccomp-dev installed, > the resulting file package gets a dependency on libseccomp2. And if I > install that, then I subsequently get strange errors while trying to > build src:binutils, (...) It might be an interesting topic whether "Not needed packages installed in the build system trigger a build error" should be considered a bug - since the idea is to always use a system with only those packages installed that are needed. That's something for another day. Given the fact however the fix is really simple (and my experiences with seccomp are not that good and I don't want to be remebered about them), I'll just go ahead as suggested. Cheers, Christoph signature.asc Description: PGP signature
Bug#948994: gulp should Depend on node-get-value
Package: gulp Version: 4.0.2-4 Severity: normal Dear Maintainer, while building yarnpkg on experimental, it fails while executing the gulp command: ... gulp build [18:34:23] Local gulp not found in /builds/js-team/node-yarnpkg/debian/output/node-yarnpkg-1.21.1 [18:34:23] Try running: npm install gulp [18:34:23] Using globally installed gulp internal/modules/cjs/loader.js:638 throw err; ^ Error: Cannot find module 'get-value' at Function.Module._resolveFilename (internal/modules/cjs/loader.js:636:15) at Function.Module._load (internal/modules/cjs/loader.js:562:25) at Module.require (internal/modules/cjs/loader.js:692:17) at require (internal/modules/cjs/helpers.js:25:18) at Object. (/usr/share/nodejs/gulp/node_modules/array-sort/index.js:12:11) at Module._compile (internal/modules/cjs/loader.js:778:30) at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10) at Module.load (internal/modules/cjs/loader.js:653:32) at tryModuleLoad (internal/modules/cjs/loader.js:593:12) at Function.Module._load (internal/modules/cjs/loader.js:585:3) as can be seen in this salsa CI run: https://salsa.debian.org/js-team/node-yarnpkg/-/jobs/511658 get-value is required by array-sort which is a dependency of gulp-cli 2: https://github.com/gulpjs/gulp-cli/blob/master/package.json#L36 BTW a few weeks ago it had worked gulp 4.0.2-4 from experimental: https://salsa.debian.org/js-team/node-yarnpkg/-/jobs/470197 It could be that the culprit is one of the gulp dependencies ... Paolo -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gulp depends on: ii node-archy 1.0.0-3 ii node-chalk 2.4.2-1 ii node-chokidar2.1.6-3 ii node-concat-stream 1.6.2-1 ii node-defaults1.0.3-1 ii node-deprecated 0.0.1-1 ii node-es6-weak-map2.0.2-1 ii node-find-up 4.1.0-2 ii node-for-own 1.0.0-1 ii node-globule 1.3.0-1 ii node-gulp-util 3.0.7-1 ii node-interpret 1.0.1-1 ii node-is-unc-path 1.0.0-1 ii node-liftoff 3.1.0-4 ii node-minimist1.2.0-1 ii node-normalize-package-data 2.4.0-1 ii node-orchestrator0.3.8-1 ii node-parse-json 5.0.0-2 ii node-pinkie-promise 2.0.1-1 ii node-pretty-hrtime 1.0.3-1 ii node-semver 7.1.1-2 ii node-set-blocking2.0.0-1 ii node-string-width2.1.1-1 ii node-tildify 2.0.0-1 ii node-v8flags 3.1.2-3 ii node-vinyl-fs3.0.3-3 ii node-y18n4.0.0-2 ii node-yargs-parser16.1.0-1 ii nodejs 10.17.0~dfsg-2 gulp recommends no packages. gulp suggests no packages. -- no debconf information
Bug#948752: RFS: rumur/2020.01.11-1 -- model checker for the Murphi language
On Tue, Jan 14, 2020 at 08:07:05PM -0800, Matthew Fernandez wrote: > OK, uploaded a new version with this fix. Please let me know if you have a > chance to take another look. Alas, still fails: /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/librumur.a(parser.yy.cc.o): in function `rumur::VarDecl::~VarDecl()': (.text._ZN5rumur7VarDeclD0Ev[_ZN5rumur7VarDeclD5Ev]+0x14): undefined reference to `__gmpz_clear' /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/librumur.a(parser.yy.cc.o): in function `void rumur::parser::semantic_type::move, std::allocator > > >(rumur::parser::semantic_type&&)': (.text._ZN5rumur6parser13semantic_type4moveISt6vectorINS_3PtrINS_7VarDeclEEESaIS6_vOS1_[_ZN5rumur6parser13semantic_type4moveISt6vectorINS_3PtrINS_7VarDeclEEESaIS6_vOS1_]+0x89): undefined reference to `__gmpz_clear' [...] /usr/bin/ld: (.text+0xf2e): undefined reference to `__gmpz_add' /usr/bin/ld: (.text+0xf36): undefined reference to `__gmpz_clear' /usr/bin/ld: (.text+0xf3e): undefined reference to `__gmpz_clear' Full log at http://ix.io/27tY Meow! -- ⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, ⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month. ⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake, ⠈⠳⣄ etc), let the drink age at least 3-6 months.
Bug#948993: firejail-profiles: profile for transmission-daemon does not whitelist ~/.config/transmission-daemon
Package: firejail-profiles Version: 0.9.62-2 Severity: normal Dear Maintainer, On Debian GNU/Linux, the configuration of transmission-daemon lies in ~/.config/transmission-daemon instead of ~/.config/transmission, which means ~/.config/transmission-daemon should be whitelisted in the profile for transmission-daemon, while in current profile, only ~/.config/transmission is whitelisted, causing the configuration of transmission-daemon is not accessible inside the jail. Currently I walkaround this via transmission-daemon.local. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=zh_CN.utf8, LC_CTYPE=zh_CN.utf8 (charmap=UTF-8), LANGUAGE=zh_CN.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages firejail-profiles depends on: ii firejail 0.9.62-2 firejail-profiles recommends no packages. firejail-profiles suggests no packages. -- no debconf information
Bug#948842: nm.debian.org: please let people upload their OpenPGP certificate directly
On Mon, Jan 13, 2020 at 05:03:50PM -0500, Daniel Kahn Gillmor wrote: > > With the SKS network slowly dying, gpg not receiving third-party > > certifications anymore by default and other changes to the ecosystem, > > retrieving OpenPGP certificates and third-party certifications may be > > harder in the future. > > > > It is simpler to let applicants provide a certificate themselves > > directly. > > I endorse this suggestion :) > > I note that we shouldn't *require* users to upload their certificate > necessarily. The change asked for here is just to make it possible for > them to do the upload if they choose to. I like the sentiment, and I am slightly afraid of turning nm.debian.org into the debian keyserver replacement. I mean, we could, but I'd like to figure out where we want to have the authoritative source of key material for Debian. Here are various options that I can think of: - nm.debian.org, needs the data - contributors.debian.org has a much more comprehensive user database - keyring.debian.org primarily manages key material - sso.debian.org is the authoritative user database - the oncoming replacement of sso.debian.org will be the actual authoritative user database I'd feel better having this information together with the authoritative user database, which at this point in time would mean waiting for the new SSO to be up, and then hooking into that somehow. Alternatively, having this information managed by the authoritative team, which could mean keyring-maint providing a key upload service tied to the new SSO. In this case, I don't mind helping to write the key upload service for keyring-maint, if you want. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Bug#948992: tap.py removed the python-tap package, but dbus-python b-d's on that
Package: src:dbus-python Version: 1.2.16-1 Severity: serious Tags: sid bullseye tap.py removed the python-tap package, but dbus-python still b-d's on that package.
Bug#947962: Packaging efforts for aerc
On Wed, Jan 15, 2020 at 05:45:03PM +0100, Ben Fiedler wrote: > Hi all, > > I'd like to help packaging aerc. > > Some of the dependencies needed are already packaged, but at least Drew's > fork of go-libvterm [1] is missing. It really looks like something that should be a package on its own, yeah. > I've already got a building version of that package, should I register an > ITP and upload that? Please do. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, ⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month. ⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake, ⠈⠳⣄ etc), let the drink age at least 3-6 months.
Bug#948991: buster-pu: package schleuder/3.4.0-2+deb10u2
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Dear SRMs,
Schleuder in buster (proposed-updates) is affected by various problems, which I
would like to fix:
- Add missing List-Id header to notification mails sent to admins:
This should help with filtering such messages, which is currently
not easy to do in a reliable way. (Closes: #948980)
- Handle various exceptions due to decryption problems gracefully:
Handle incoming mails encrypted to an absent key, using symmetric
encryption or containing PGP-garbage in a more graceful manner:
Don't throw an exception, don't notify (and annoy) the admins,
instead inform the sender of the mail how to do better.
(Closes: #948981)
- Default to ASCII-8BIT encoding for external data:
This should ensure Schleuder is able to handle incoming mails in different
character sets. Currently Schleuder may run into a fatal error due to
"invalid byte sequence in US-ASCII". (Closes: #948982)
The proposed code changes are minimal, targeted, guarded by tests and validated
in production. All of them are fixed in unstable via 3.4.1-2.
Please find the debdiff between schleuder/3.4.0-2+deb10u1 and
schleuder/3.4.0-2+deb10u2 attached.
Thanks for your work!
Cheers,
Georg
diffstat for schleuder-3.4.0 schleuder-3.4.0
changelog | 16
patches/0020-admin-notifications-list-id-header.patch | 41 ++
patches/0021-handle-decryption-errors-gracefully.patch | 199 +++
patches/0022-ASCII-8BIT-encoding.patch | 284 +
patches/series |3
5 files changed, 543 insertions(+)
diff -Nru schleuder-3.4.0/debian/changelog schleuder-3.4.0/debian/changelog
--- schleuder-3.4.0/debian/changelog 2019-11-08 10:45:22.0 +
+++ schleuder-3.4.0/debian/changelog 2020-01-15 17:11:59.0 +
@@ -1,3 +1,19 @@
+schleuder (3.4.0-2+deb10u2) buster; urgency=medium
+
+ * debian/patches:
+- Pull in upstream patch to add missing List-Id header to notification
+ mails sent to admins. (Closes: #948980)
+- Pull in upstream patch to handle decryption problems gracefully: Handle
+ incoming mails encrypted to an absent key, using symmetric encryption or
+ containing PGP-garbage in a more graceful manner: Don't throw an
+ exception, don't notify (and annoy) the admins, instead inform the
+ sender of the mail how to do better. (Closes: #948981)
+- Pull in upstream patch to default to ASCII-8BIT encoding. This should
+ ensure Schleuder is able to handle mails with different charsets.
+ (Closes: #948982)
+
+ -- Georg Faerber Wed, 15 Jan 2020 17:11:59 +
+
schleuder (3.4.0-2+deb10u1) buster; urgency=medium
* debian/patches:
diff -Nru schleuder-3.4.0/debian/patches/0020-admin-notifications-list-id-header.patch schleuder-3.4.0/debian/patches/0020-admin-notifications-list-id-header.patch
--- schleuder-3.4.0/debian/patches/0020-admin-notifications-list-id-header.patch 1970-01-01 00:00:00.0 +
+++ schleuder-3.4.0/debian/patches/0020-admin-notifications-list-id-header.patch 2020-01-15 17:11:59.0 +
@@ -0,0 +1,41 @@
+Description: admin notifications: add missing List-Id header
+Author: Georg Faerber
+Origin: upstream
+Forwarded: https://0xacab.org/schleuder/schleuder/merge_requests/312/diffs?commit_id=ee41fd4215bba6bea5aba12806089e9d415c1bd1
+Last-Update: 2020-01-15
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: schleuder/lib/schleuder/logger_notifications.rb
+===
+--- schleuder.orig/lib/schleuder/logger_notifications.rb 2020-01-15 14:43:57.209563572 +
schleuder/lib/schleuder/logger_notifications.rb 2020-01-15 15:32:09.448514094 +
+@@ -42,6 +42,8 @@
+ gpg_opts.merge!(encrypt: true, keys: { address => key.fingerprint })
+ end
+ mail.gpg gpg_opts
++
++ mail.header['List-Id'] = "<#{@list.email.gsub('@', '.')}>"
+ end
+ mail.deliver
+ end
+Index: schleuder/spec/schleuder/unit/logger_notifications_spec.rb
+===
+--- schleuder.orig/spec/schleuder/unit/logger_notifications_spec.rb 2019-11-03 18:31:21.013704003 +
schleuder/spec/schleuder/unit/logger_notifications_spec.rb 2020-01-15 15:32:09.448514094 +
+@@ -97,4 +97,16 @@
+ expect(message.parts.size).to be(2)
+ expect(message.parts.first.parts.first.body.to_s).to eql('Something')
+ end
++
++ it 'includes a List-Id header in notification mails sent to admins' do
++list = create(:list, send_encrypted_only: false)
++list.subscribe("schleu...@example.org", nil, true)
++
++mail = Mail.new
++list.logger.notify_admin("Something", mail.to_s, I18n.t('notice'))
++
++message =
Bug#948990: package still has a python2 autopkg test
Package: src:python-testtools Version: 2.3.0-6 Severity: serious Tags: sid bullseye patch package still has a python2 autopkg test patch at https://patches.ubuntu.com/p/python-testtools/python-testtools_2.3.0-6ubuntu1.patch
Bug#947866: (no subject)
Hi, I think this behavior is actually not a bug, but a feature ;-) Are you sure you did't check "Show all fields templated" in Configuration -> Template? (see attached image). If you still think it's a bug, please attach the whole file that corresponds to the entry [but please mask sensitive data!]. In that case I'll forward it upstream (https://github.com/IJHack/QtPass/issues) - or you directly file the bug upstream, as you like. Best regards, Philip
Bug#948926: Help for linking library needed (Was: Bug#948926: blasr ftbfs with libpbbam1.0.6)
On Wed, Jan 15, 2020 at 05:50:03PM +0100, Andreas Tille wrote: > Control: tags -1 help > > On Tue, Jan 14, 2020 at 09:48:10PM +0100, Paul Gevers wrote: > > Did not find CMake 'cmake' > > Found CMake: NO > > Run-time dependency pbbam found: NO > > > > meson.build:54:0: ERROR: Could not generate cargs for pbbam: > > Package pbcopper was not found in the pkg-config search path. > > Perhaps you should add the directory containing `pbcopper.pc' > > to the PKG_CONFIG_PATH environment variable > > Package 'pbcopper', required by 'pbbam', not found > > I've fixed this specific issue (and others) in Git[1] but I'm running > into trouble I have no idea to fix. > > > ... > [22/25] c++ -o toAfg 'toAfg@exe/utils_ToAfg.cpp.o' -I/usr/include/pbseq > -L/usr/lib/x86_64-linux-gnu -L/usr/lib/x86_64-linux-gnu/hdf5/serial > -Wl,--as-needed -Wl,--no-undefined -Wl,-O1 -Wdate-time - > D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/build/blasr-5.3.3+dfsg=. > -fstack-protector-strong -Wformat -Werror=format-security -DHAVE_HDF5_1_10_1 > -std=c++14 -Wl,--start-group -lhdf5_cpp -lhdf5 libblasr_impl. a -pthread > -lblasr /usr/lib/x86_64-linux-gnu/libz.so -lpbdata -lpbihdf -lblasr -lpbdata > -lpbihdf -Wl,--end-group '-Wl,-rpath,$ORIGIN/' > -Wl,-rpath-link,/build/blasr-5.3.3+dfsg/build/ > FAILED: toAfg > c++ -o toAfg 'toAfg@exe/utils_ToAfg.cpp.o' -I/usr/include/pbseq > -L/usr/lib/x86_64-linux-gnu -L/usr/lib/x86_64-linux-gnu/hdf5/serial > -Wl,--as-needed -Wl,--no-undefined -Wl,-O1 -Wdate-time -D_FORTIFY_SOURCE=2 - > g -O2 -fdebug-prefix-map=/build/blasr-5.3.3+dfsg=. -fstack-protector-strong > -Wformat -Werror=format-security -DHAVE_HDF5_1_10_1 -std=c++14 > -Wl,--start-group -lhdf5_cpp -lhdf5 libblasr_impl.a -pthread -lblasr / > usr/lib/x86_64-linux-gnu/libz.so -lpbdata -lpbihdf -lblasr -lpbdata -lpbihdf > -Wl,--end-group '-Wl,-rpath,$ORIGIN/' > -Wl,-rpath-link,/build/blasr-5.3.3+dfsg/build/ > /usr/bin/ld: toAfg@exe/utils_ToAfg.cpp.o: undefined reference to symbol > '_ZN6PacBio3BAM9BamRecordD1Ev' > /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libpbbam.so.0.23.0: error adding > symbols: DSO missing from command line > collect2: error: ld returned 1 exit status It tells you to add libpbbam to the link command. > In the pbuilder chroot I tried to simplify the linker call and > reduced it to > > root@sputnik:/build/blasr-5.3.3+dfsg/build# c++ -o toAfg > 'toAfg@exe/utils_ToAfg.cpp.o' -I/usr/include/pbseq > -L/usr/lib/x86_64-linux-gnu -L/usr/lib/x86_64-linux-gnu/hdf5/serial > -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -DHAVE_HDF5_1_10_1 -std=c++14 > -lhdf5_cpp -lhdf5 ./libblasr_impl.a -pthread -lz -lpbdata -lpbihdf -lpbihdf > -lblasr > /usr/bin/ld: toAfg@exe/utils_ToAfg.cpp.o: undefined reference to symbol > '_ZN6PacBio3BAM9BamRecordD1Ev' > /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libpbbam.so.0.23.0: error adding > symbols: DSO missing from command line > collect2: error: ld returned 1 exit status Indeed libpbbam is still missing here. > I've checked that the symbol which is not found exists in the linked > libraries: It's not linked. Also, using grep for this is very wrong, you need to use nm -D and check it's defined there (it is though). -- WBR, wRAR signature.asc Description: PGP signature
Bug#923795: /etc/cron.daily/tomcat7: compresses “live” logfiles
Hello, Am 15.01.20 um 18:10 schrieb Sylvain Beucler: > Hello Thorsten, > > I'm working on a tomcat7 security-only update, and checking the pending > bugs. > > /etc/cron.daily/tomcat7 uses the "copytruncate" method, which normally > should handle this situation, where it's not possible/wanted to restart > the server, and there's "a very small time slice between copying the > file and truncating it, so some logging data might be lost" > (logrotate.conf(5)), so I assume the potentially missing write is a > known compromise. > > Note: it also uses the "weekly" keyword which does not match this bug's > mention of "not have been written to for a day". > > At first glance the situation looks OK to me. What would you recommend? The Tomcat 7 security update for Jessie and Wheezy is handled by Mike Gabriel and myself already. I have uploaded the package to https://people.debian.org/~apo/tomcat7/ and I am waiting for Mike's review. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#923795: /etc/cron.daily/tomcat7: compresses “live” logfiles
Hello Thorsten, I'm working on a tomcat7 security-only update, and checking the pending bugs. /etc/cron.daily/tomcat7 uses the "copytruncate" method, which normally should handle this situation, where it's not possible/wanted to restart the server, and there's "a very small time slice between copying the file and truncating it, so some logging data might be lost" (logrotate.conf(5)), so I assume the potentially missing write is a known compromise. Note: it also uses the "weekly" keyword which does not match this bug's mention of "not have been written to for a day". At first glance the situation looks OK to me. What would you recommend? Cheers! Sylvain
Bug#946580: No coqidetop in coq package breaks editor plugins
Thanks for the fix! The changelog seems to imply your change of coqidetop was after coq upstream advice. To be clear, I am only the upstream of a plugin that uses coq, not an upstream of coq itself :)
Bug#947962: Packaging efforts for aerc
Hi all, I'd like to help packaging aerc. Some of the dependencies needed are already packaged, but at least Drew's fork of go-libvterm [1] is missing. I've already got a building version of that package, should I register an ITP and upload that? Cheers, Ben Fiedler [1]: https://github.com/ddevault/go-libvterm
Bug#948989: ksh: CVE-2019-14868
Source: ksh Version: 2020.0.0-2 Severity: grave Tags: security upstream Justification: user security hole Hi, The following vulnerability was published for ksh. CVE-2019-14868[0]: |environment variables on startup are interpreted as arithmetic |expression leading to code injection If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2019-14868 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14868 [1] https://github.com/att/ast/commit/c7de8b641266bac7c77942239ac659edfee9ecd2 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#948926: Help for linking library needed (Was: Bug#948926: blasr ftbfs with libpbbam1.0.6)
Control: tags -1 help On Tue, Jan 14, 2020 at 09:48:10PM +0100, Paul Gevers wrote: > Did not find CMake 'cmake' > Found CMake: NO > Run-time dependency pbbam found: NO > > meson.build:54:0: ERROR: Could not generate cargs for pbbam: > Package pbcopper was not found in the pkg-config search path. > Perhaps you should add the directory containing `pbcopper.pc' > to the PKG_CONFIG_PATH environment variable > Package 'pbcopper', required by 'pbbam', not found I've fixed this specific issue (and others) in Git[1] but I'm running into trouble I have no idea to fix. ... [22/25] c++ -o toAfg 'toAfg@exe/utils_ToAfg.cpp.o' -I/usr/include/pbseq -L/usr/lib/x86_64-linux-gnu -L/usr/lib/x86_64-linux-gnu/hdf5/serial -Wl,--as-needed -Wl,--no-undefined -Wl,-O1 -Wdate-time - D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/build/blasr-5.3.3+dfsg=. -fstack-protector-strong -Wformat -Werror=format-security -DHAVE_HDF5_1_10_1 -std=c++14 -Wl,--start-group -lhdf5_cpp -lhdf5 libblasr_impl. a -pthread -lblasr /usr/lib/x86_64-linux-gnu/libz.so -lpbdata -lpbihdf -lblasr -lpbdata -lpbihdf -Wl,--end-group '-Wl,-rpath,$ORIGIN/' -Wl,-rpath-link,/build/blasr-5.3.3+dfsg/build/ FAILED: toAfg c++ -o toAfg 'toAfg@exe/utils_ToAfg.cpp.o' -I/usr/include/pbseq -L/usr/lib/x86_64-linux-gnu -L/usr/lib/x86_64-linux-gnu/hdf5/serial -Wl,--as-needed -Wl,--no-undefined -Wl,-O1 -Wdate-time -D_FORTIFY_SOURCE=2 - g -O2 -fdebug-prefix-map=/build/blasr-5.3.3+dfsg=. -fstack-protector-strong -Wformat -Werror=format-security -DHAVE_HDF5_1_10_1 -std=c++14 -Wl,--start-group -lhdf5_cpp -lhdf5 libblasr_impl.a -pthread -lblasr / usr/lib/x86_64-linux-gnu/libz.so -lpbdata -lpbihdf -lblasr -lpbdata -lpbihdf -Wl,--end-group '-Wl,-rpath,$ORIGIN/' -Wl,-rpath-link,/build/blasr-5.3.3+dfsg/build/ /usr/bin/ld: toAfg@exe/utils_ToAfg.cpp.o: undefined reference to symbol '_ZN6PacBio3BAM9BamRecordD1Ev' /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libpbbam.so.0.23.0: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status In the pbuilder chroot I tried to simplify the linker call and reduced it to root@sputnik:/build/blasr-5.3.3+dfsg/build# c++ -o toAfg 'toAfg@exe/utils_ToAfg.cpp.o' -I/usr/include/pbseq -L/usr/lib/x86_64-linux-gnu -L/usr/lib/x86_64-linux-gnu/hdf5/serial -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -DHAVE_HDF5_1_10_1 -std=c++14 -lhdf5_cpp -lhdf5 ./libblasr_impl.a -pthread -lz -lpbdata -lpbihdf -lpbihdf -lblasr /usr/bin/ld: toAfg@exe/utils_ToAfg.cpp.o: undefined reference to symbol '_ZN6PacBio3BAM9BamRecordD1Ev' /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libpbbam.so.0.23.0: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status I've checked that the symbol which is not found exists in the linked libraries: root@sputnik:/build/blasr-5.3.3+dfsg/build# grep _ZN6PacBio3BAM9BamRecordD1Ev /usr/lib/x86_64-linux-gnu/*libpb* Binary file /usr/lib/x86_64-linux-gnu/libpbbam.so matches Binary file /usr/lib/x86_64-linux-gnu/libpbbam.so.0.23.0 matches Binary file /usr/lib/x86_64-linux-gnu/libpbbam.so.1.0.6 matches Binary file /usr/lib/x86_64-linux-gnu/libpbdata.a matches Binary file /usr/lib/x86_64-linux-gnu/libpbdata.so matches I wonder whether the issue might be connected to the fact that there is only a shared lib but no libpbbam.a (the build system of libpbbam-dev would need to be tweaked - but I'd assume a shared lib should be sufficient for linking, right?) Any hint to fix the build would be welcome. Kind regards Andreas. [1] https://salsa.debian.org/med-team/blasr -- http://fam-tille.de
Bug#948988: buster-pu: package postfix/3.4.7-0+deb10u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
This is the next in the usual postfix update series. I waited to see if
upstream feedback revealed any problems (it didn't). This version is in
Testing. I'm running it in production with no issues. Slightly
differently than usual for postfix updates, I am including one packaging
related change to make it so the sysv init works inside a docker
instance. While not essential, it is based on Debian user feedback, so
I think it's worth including since it's a very low risk change.
Details:
[Scott Kitterman]
* Refactor running status detection in sysv init based on upstream
postfix-script so it works in docker. Closes: #941293
[Wietse Venema]
* 3.4.8
- Bugfix (introduced: Postfix 2.8): don't gratuitously enable
all after-220 tests when only one such test is enabled.
This made selective tests impossible with 'good' clients.
File: postscreen/postscreen_smtpd.c.
- Bugfix: the 20180903 postscreen fix for a misleading
"PIPELINING after BDAT" warning looked at the wrong variable.
The warning now says "BDAT without valid RCPT", and the
error is no longer treated as a command PIPELINING error
(but sending BDAT is still a client error, because postscreen
rejects all RCPT commands and does not announce PIPELINING
support). File: postscreen/postscreen_smtpd.c.
- Usability: the parser for key/certificate chain files
rejected inputs that contain an EC PARAMETERS object. While
this is technically correct (the documentation says what
types are allowed) this is surprising behavior because the
legacy cert/key parameters will accept such inputs. For
now, the parser skips object types that it does not know
about for usability, and logs a warning because ignoring
inputs is not kosher. Viktor and Wietse. File: tls/tls_certkey.c.
Scott K
diff -Nru postfix-3.4.7/debian/changelog postfix-3.4.8/debian/changelog
--- postfix-3.4.7/debian/changelog 2019-10-01 19:21:59.0 -0400
+++ postfix-3.4.8/debian/changelog 2020-01-15 09:05:50.0 -0500
@@ -1,3 +1,37 @@
+postfix (3.4.8-0+10debu1) buster; urgency=medium
+
+ [Scott Kitterman]
+
+ * Refactor running status detection in sysv init based on upstream
+postfix-script so it works in docker. Closes: #941293
+
+ [Wietse Venema]
+
+ * 3.4.8
+- Bugfix (introduced: Postfix 2.8): don't gratuitously enable
+ all after-220 tests when only one such test is enabled.
+ This made selective tests impossible with 'good' clients.
+ File: postscreen/postscreen_smtpd.c.
+
+- Bugfix: the 20180903 postscreen fix for a misleading
+ "PIPELINING after BDAT" warning looked at the wrong variable.
+ The warning now says "BDAT without valid RCPT", and the
+ error is no longer treated as a command PIPELINING error
+ (but sending BDAT is still a client error, because postscreen
+ rejects all RCPT commands and does not announce PIPELINING
+ support). File: postscreen/postscreen_smtpd.c.
+
+- Usability: the parser for key/certificate chain files
+ rejected inputs that contain an EC PARAMETERS object. While
+ this is technically correct (the documentation says what
+ types are allowed) this is surprising behavior because the
+ legacy cert/key parameters will accept such inputs. For
+ now, the parser skips object types that it does not know
+ about for usability, and logs a warning because ignoring
+ inputs is not kosher. Viktor and Wietse. File: tls/tls_certkey.c.
+
+ -- Scott Kitterman Wed, 15 Jan 2020 09:05:50 -0500
+
postfix (3.4.7-0+deb10u1) buster; urgency=medium
[Wietse Venema]
diff -Nru postfix-3.4.7/debian/init.d postfix-3.4.8/debian/init.d
--- postfix-3.4.7/debian/init.d 2019-10-01 19:21:45.0 -0400
+++ postfix-3.4.8/debian/init.d 2020-01-15 09:02:40.0 -0500
@@ -39,16 +39,9 @@
else
POSTCONF="postmulti -i $INSTANCE -x postconf"
fi
-
-queue=$($POSTCONF -hx queue_directory 2>/dev/null || echo
/var/spool/postfix)
-daemondir=$($POSTCONF -hx daemon_directory 2>/dev/null || echo
/usr/lib/postfix/sbin)
-if [ -f ${queue}/pid/master.pid ]; then
- pid=$(sed 's/ //g' ${queue}/pid/master.pid)
- # what directory does the executable live in. stupid prelink systems.
- dir=$(ls -l /proc/$pid/exe 2>/dev/null | sed 's/.* -> //;
s/\/[^\/]*$//')
- if [ "X$dir" = "X${daemondir}" ]; then
- echo y
- fi
+daemon_directory=$($POSTCONF -hx daemon_directory 2>/dev/null || echo
/usr/lib/postfix/sbin)
+if ! $daemon_directory/master -t 2>/dev/null ; then
+echo y
fi
}
diff -Nru postfix-3.4.7/HISTORY postfix-3.4.8/HISTORY
--- postfix-3.4.7/HISTORY 2019-09-21 11:57:46.0 -0400
+++ postfix-3.4.8/HISTORY 2019-11-11 18:01:20.0
Bug#948987: libssl: libssl1.1 segfaults when kopete is using it (libjingle-call)
Package: libssl1.1 Version: 1.1.1d-0+deb10u2 Severity: critical File: libssl Justification: breaks unrelated software Dear Maintainer, when using kopete, dmesg shows a shitload of: [timestamp] libjingle-call[11878]: segfault at 48 ip 7f693f599ed3 sp 7fff4db27280 error 4 in libcrypto.so.1.1[7f693f561000+19e000] [timestamp] Code: 40 24 01 00 00 00 4c 89 e2 c7 40 50 01 00 00 00 0f ae f0 e8 af 83 fc ff 85 c0 74 6c e8 76 9a fc ff 48 89 43 70 48 85 c0 74 2d <48> 8b 45 48 48 85 c0 74 74 48 89 df ff d0 85 c0 0f 84 a7 00 00 00 I assume this is not intended behaviour. This is reproduceable on all (7) of our workstations. Same hardware, same software. Regards Jens -- System Information: Debian Release: 10.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.3.0-0.bpo.2-amd64 (SMP w/16 CPU cores) Kernel taint flags: 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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libssl1.1:amd64 depends on: ii debconf [debconf-2.0] 1.5.71 ii libc6 2.28-10 libssl1.1:amd64 recommends no packages. libssl1.1:amd64 suggests no packages. -- debconf information: libssl1.1/restart-services: libssl1.1/restart-failed:
Bug#948983: evdi-dkms: Loading new evdi-5.2.14 DKMS files...
the patch https://crazy.dev.frugalware.org/ evdi - all -in- one - fixes . patch works and makes the module compile fine if applied to the source, please include it in the dkms build
Bug#948710: openssh-server: Fail to upgrade "ssh.service: Unit -.mount is masked"
Hi Phillip Am 15.01.20 um 17:08 schrieb Phillip Susi: > > I brought this up on systemd-devel the other day and Lennart agreed that > it is a bug in systemd that it refuses to start services that depend on > masked mount units when the mount is active. He advised me to file a > bug report on github, but github insisted on emailing me before allowing > me to log in even though I know my login and password, and they seem to > still have my no longer existing ubuntu email address, and so I am > locked out. I filed such a bug report in the mean time https://github.com/systemd/systemd/issues/14550 signature.asc Description: OpenPGP digital signature
Bug#948710: openssh-server: Fail to upgrade "ssh.service: Unit -.mount is masked"
I brought this up on systemd-devel the other day and Lennart agreed that it is a bug in systemd that it refuses to start services that depend on masked mount units when the mount is active. He advised me to file a bug report on github, but github insisted on emailing me before allowing me to log in even though I know my login and password, and they seem to still have my no longer existing ubuntu email address, and so I am locked out. Their contact us page also does not seem to work nor have they replied to my attempts to email support@, so I am unable to file the upstream bug. He also advised that gparted should be using a bsd file lock instead of masking mount units. Curtis Gedack wasn't sure about making the change at least for the upcoming release of gparted. Perhaps after that.
Bug#948986: aptitude search: please allow searching by component (main/contrib/non-free)
Package: aptitude Version: 0.8.12-1 Severity: wishlist Tags: upstream Dear Maintainer, Please add a search pattern ?component(…) that can be used as ?component(main), ?component(non-free), ?component(contrib). Thanks, Daniel
Bug#944890: ListenStream= references a path below legacy directory /var/run/, updating /var/run/libvirt/foo → /run/libvirt/foo; please update the unit file accordingly.
Am 15.01.20 um 16:35 schrieb Michael Biebl: > I've updated the code to use runstatedir. > What remains is to use --runstatedir=/run in debian/rules. Small correction: Since debhelper compat 11 this is already the default and since libvirt uses compat 12, you don't need to explicitly set it anymore. Michael signature.asc Description: OpenPGP digital signature
Bug#948985: RM: libgdal-grass/experimental -- NVIU; Superseded by version in unstable
Package: ftp.debian.org Severity: normal Please remove libgdal-grass from experimental, the version in unstable is newer. Kind Regards, Bas
Bug#948658: qemu: Qemu 4.2 hangs/freezes completely due to audio backend changes [regression][bisected]
Hello!
After some more digging, I've tracked the problem to the audio input /
capture-side of the code. If I leave out the QEMU_ALSA_ADC_DEV="null"
environment variable, the freeze does not happen, but Qemu spews
hundreds of errors, following lines repeat many times:
--
alsa: Could not initialize ADC
alsa: Failed to open `default':
alsa: Reason: No such file or directory
alsa: Could not initialize ADC
alsa: Failed to open `default':
alsa: Reason: No such file or directory
audio: Failed to create voice `adc'
--
I also tried disabling the capture in the code, with this patch against
v4.2.0 git. (You also have to pass --disable-werror to configure.)
diff --git a/audio/audio.c b/audio/audio.c
index 56fae55047..82476a41de 100644
--- a/audio/audio.c
+++ b/audio/audio.c
@@ -1352,8 +1352,10 @@ static void audio_run_capture (AudioState *s)
void audio_run(AudioState *s, const char *msg)
{
audio_run_out(s);
+#if 0
audio_run_in(s);
audio_run_capture(s);
+#endif
#ifdef DEBUG_POLL
{
.. and with the patch it worked perfectly. No hangs/freeze. But obviously
it is not a solution for other people as it disables audio capture/recording.
Personally I don't need it, of course, which is why I have that
QEMU_ALSA_ADC_DEV="null" set.
Hope this helps.
--
] ccr/TNSP ^ pWp :: c...@tnsp.org :: https://tnsp.org/~ccr/
] https://tnsp.org/hg/ -- https://www.openhub.net/accounts/ccr
] PGP key: 7BED 62DE 898D D1A4 FC4A F392 B705 E735 307B AAE3
Bug#948984: RM: gdal/experimental -- NVIU; Superseded by version in unstable
Package: ftp.debian.org Severity: normal Please remove gdal from experimental, the version in unstable is newer. Kind Regards, Bas
Bug#944890: ListenStream= references a path below legacy directory /var/run/, updating /var/run/libvirt/foo → /run/libvirt/foo; please update the unit file accordingly.
On Sun, 17 Nov 2019 12:28:38 +0100 Laurent Bigonville wrote: > Package: libvirt-daemon-system > Version: 5.6.0-2 > Severity: minor > > Hello, > > During boot, systemd complains that the .service and .socket files are > pointing to /var/run instead of /run: > > systemd[1]: /lib/systemd/system/virtlockd.socket:6: ListenStream= references > a path below legacy directory /var/run/, updating > /var/run/libvirt/virtlockd-sock → /run/libvirt/virtlockd-sock; please update > the unit file accordingly. > systemd[1]: /lib/systemd/system/virtlockd-admin.socket:8: ListenStream= > references a path below legacy directory /var/run/, updating > /var/run/libvirt/virtlockd-admin-sock → /run/libvirt/virtlockd-admin-sock; > please update the unit file accordingly. > systemd[1]: /lib/systemd/system/libvirtd-admin.socket:8: ListenStream= > references a path below legacy directory /var/run/, updating > /var/run/libvirt/libvirt-admin-sock → /run/libvirt/libvirt-admin-sock; please > update the unit file accordingly. > systemd[1]: /lib/systemd/system/libvirtd-ro.socket:8: ListenStream= > references a path below legacy directory /var/run/, updating > /var/run/libvirt/libvirt-sock-ro → /run/libvirt/libvirt-sock-ro; please > update the unit file accordingly. > systemd[1]: /lib/systemd/system/libvirtd.socket:6: ListenStream= references a > path below legacy directory /var/run/, updating /var/run/libvirt/libvirt-sock > → /run/libvirt/libvirt-sock; please update the unit file accordingly. > systemd[1]: /lib/systemd/system/virtlogd.socket:6: ListenStream= references a > path below legacy directory /var/run/, updating > /var/run/libvirt/virtlogd-sock → /run/libvirt/virtlogd-sock; please update > the unit file accordingly. > systemd[1]: /lib/systemd/system/virtlogd-admin.socket:8: ListenStream= > references a path below legacy directory /var/run/, updating > /var/run/libvirt/virtlogd-admin-sock → /run/libvirt/virtlogd-admin-sock; > please update the unit file accordingly. > > > /run is supported in debian for quite some times, that can be used I > guess. I've updated the code to use runstatedir. What remains is to use --runstatedir=/run in debian/rules. I then noticed that upstream made similar changes as well. So once we get a newer release of libvirt, this should be supported ootb. But since I already did the work, I'm attaching the patches, just in case you decide to keep 5.6 in unstable for a while longer. Michael From 80a821f040807e5cf4b1bd0d9c9905d960203de4 Mon Sep 17 00:00:00 2001 From: Michael Biebl Date: Wed, 15 Jan 2020 14:25:38 +0100 Subject: [PATCH 1/4] Search and replace to use runstatedir instead localstatedir find . -type f | xargs sed -i 's#@localstatedir@/run#@runstatedir@#' find . -type f | xargs sed -i 's#LOCALSTATEDIR "/run#RUNSTATEDIR "#' find . -type f | xargs sed -i 's#LOCALSTATEDIR/run#RUNSTATEDIR#' --- src/bhyve/bhyve_utils.h | 2 +- src/libvirt-admin.c | 2 +- src/libvirtd.8.in | 16 src/libxl/libxl_conf.h| 2 +- src/locking/lock_daemon.c | 8 src/locking/lock_driver_lockd.c | 2 +- src/locking/virtlockd-admin.socket.in | 2 +- src/locking/virtlockd.pod | 8 src/locking/virtlockd.socket.in | 2 +- src/logging/log_daemon.c | 8 src/logging/log_manager.c | 2 +- src/logging/virtlogd-admin.socket.in | 2 +- src/logging/virtlogd.pod | 8 src/logging/virtlogd.socket.in| 2 +- src/lxc/lxc_conf.h| 2 +- src/network/bridge_driver.c | 4 ++-- src/network/leaseshelper.c| 2 +- src/nwfilter/nwfilter_dhcpsnoop.c | 2 +- src/nwfilter/nwfilter_driver.c| 4 ++-- src/remote/libvirtd-admin.socket.in | 2 +- src/remote/libvirtd-ro.socket.in | 2 +- src/remote/libvirtd.pod | 10 +- src/remote/libvirtd.socket.in | 2 +- src/remote/remote_daemon.c| 8 src/remote/remote_driver.h| 4 ++-- src/storage/storage_driver.c | 2 +- src/util/virhostdev.c | 2 +- src/virtlockd.8.in| 12 ++-- src/virtlogd.8.in | 12 ++-- src/vz/vz_driver.c| 2 +- 30 files changed, 69 insertions(+), 69 deletions(-) diff --git a/src/bhyve/bhyve_utils.h b/src/bhyve/bhyve_utils.h index 3d212e3..8dda606 100644 --- a/src/bhyve/bhyve_utils.h +++ b/src/bhyve/bhyve_utils.h @@ -31,7 +31,7 @@ #define BHYVE_AUTOSTART_DIRSYSCONFDIR "/libvirt/bhyve/autostart" #define BHYVE_CONFIG_DIR SYSCONFDIR "/libvirt/bhyve" -#define BHYVE_STATE_DIRLOCALSTATEDIR "/run/libvirt/bhyve" +#define BHYVE_STATE_DIRRUNSTATEDIR "/libvirt/bhyve" #define BHYVE_LOG_DIR LOCALSTATEDIR "/log/libvirt/bhyve" typedef struct _virBhyveDriverConfig virBhyveDriverConfig; diff --git
Bug#948983: (no subject)
Thanks for reporting. This has been reported upstream, already: https://github.com/DisplayLink/evdi/issues/172 Basically I am waiting for a fix from upstream. The patch mentioned in the bug report changes quite a few things (related to installation, etc.) and I would prefer if someone splits it up and reviews it, so we can include the necessary parts.
Bug#948983: evdi-dkms: Loading new evdi-5.2.14 DKMS files...
Package: evdi-dkms Version: 5.2.14 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? apt-get install evdi-dkms * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? Reading package lists... Done Building dependency tree Reading state information... Done evdi-dkms is already the newest version (5.2.14). 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. 1 not fully installed or removed. After this operation, 0 B of additional disk space will be used. Do you want to continue? [Y/n] Setting up evdi-dkms (5.2.14) ... Removing old evdi-5.2.14 DKMS files... -- Deleting module version: 5.2.14 completely from the DKMS tree. -- Done. Loading new evdi-5.2.14 DKMS files... Building for 5.4.0-2-amd64 Building for architecture x86_64 Building initial module for 5.4.0-2-amd64 Error! Bad return status for module build on kernel: 5.4.0-2-amd64 (x86_64) Consult /var/lib/dkms/evdi/5.2.14/build/make.log for more information. dpkg: error processing package evdi-dkms (--configure): installed evdi-dkms package post-installation script subprocess returned error exit status 10 Errors were encountered while processing: evdi-dkms E: Sub-process /usr/bin/dpkg returned an error code (1) cat /var/lib/dkms/evdi/5.2.14/build/make.log DKMS make.log for evdi-5.2.14 for kernel 5.4.0-2-amd64 (x86_64) Wed Jan 15 16:01:29 CET 2020 make KBUILD_VERBOSE=1 SUBDIRS=/var/lib/dkms/evdi/5.2.14/build SRCROOT=/var/lib/dkms/evdi/5.2.14/build CONFIG_MODULE_SIG= -C /lib/modules/5.4.0-2-amd64/build modules make[1]: Entering directory '/usr/src/linux-headers-5.4.0-2-amd64' make -C /usr/src/linux-headers-5.4.0-2-amd64 -f /usr/src/linux-headers-5.4.0-2-common/Makefile modules make -f /usr/src/linux-headers-5.4.0-2-common/Makefile syncconfig if [ -f /usr/src/linux-headers-5.4.0-2-common/.config -o \ -d /usr/src/linux-headers-5.4.0-2-common/include/config -o \ -d /usr/src/linux-headers-5.4.0-2-common/arch/x86/include/generated ]; then \ echo >&2 "***"; \ echo >&2 "*** The source tree is not clean, please run 'make mrproper'"; \ echo >&2 "*** in /usr/src/linux-headers-5.4.0-2-common";\ echo >&2 "***"; \ false; \ fi make -f /usr/src/linux-headers-5.4.0-2-common/scripts/Makefile.build obj=scripts/basic ln -fsn /usr/src/linux-headers-5.4.0-2-common source sh /usr/src/linux-headers-5.4.0-2-common/scripts/mkmakefile /usr/src/linux-headers-5.4.0-2-common sh: 0: Can't open /usr/src/linux-headers-5.4.0-2-common/scripts/mkmakefile make[3]: *** [/usr/src/linux-headers-5.4.0-2-common/Makefile:513: outputmakefile] Error 127 make[3]: *** Waiting for unfinished jobs /usr/src/linux-headers-5.4.0-2-common/scripts/Makefile.build:42: /usr/src/linux-headers-5.4.0-2-common/scripts/basic/Makefile: No such file or directory make[4]: *** No rule to make target '/usr/src/linux-headers-5.4.0-2-common/scripts/basic/Makefile'. Stop. make[3]: *** [/usr/src/linux-headers-5.4.0-2-common/Makefile:499: scripts_basic] Error 2 make[2]: *** [/usr/src/linux-headers-5.4.0-2-common/Makefile:677: include/config/auto.conf.cmd] Error 2 make[1]: *** [/usr/src/linux-headers-5.4.0-2-common/Makefile:179: sub-make] Error 2 make[1]: Leaving directory '/usr/src/linux-headers-5.4.0-2-amd64' make: *** [Makefile:22: all] Error 2 * What outcome did you expect instead? the package should install flawlessly *** End of the template - remove these template lines *** -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages evdi-dkms depends on: ii dkms 2.8.1-4 evdi-dkms recommends no packages. evdi-dkms suggests no packages. -- no debconf information
Bug#948982: schleuder: fails to handle mails in different charsets depending on the environment
Package: schleuder Version: 3.4.1-1 Forwarded: https://0xacab.org/schleuder/schleuder/issues/409 Tags: fixed-upstream Currently, depending on the environment, which differs for example between Postfix and Exim, Schleuder may run into a fatal error due to "invalid byte sequence in US-ASCII" if handling mails with different charsets. A fix addressing this issue was released upstream: default to ASCII-8BIT encoding for external data in any case. This change ensures, that Schleuder is able to handle mails with different charsets, regardless via which MTA, for example Postfix or Exim, it was invoked.
Bug#948955: wmaker: invisible windows and applications
Control: forwarded -1 wmaker-...@googlegroups.com On Wed, Jan 15, 2020 at 4:45 AM Peter Keel wrote: > > > Package: wmaker > Version: 0.95.8-3 > Severity: important > > Dear Maintainer, > > Some applications don't render a window at all, and others only as a > sliver on WindowMaker. They work on fluxbox, indeed, you can change > the window manager while they are running, and suddenly the window > becomes visible. Meanwhile application is running, as witnessed by > the sound they're playing. > > Some games on proton, such as "Rome: Total War" do have the problem, > but most importantly, virtualbox has it too. > > The following are screenshots of a virtualbox-window (not the > control panel-thingie of virtualbox, that always works, but the > window of a virtual machine) > > https://temp.discordia.ch/virtualbox-window-wmaker-2020-01-15_08-43.png > That's all of it. And this is the SAME window on fluxbox (upper part only): > https://temp.discordia.ch/virtualbox-window-fluxbox-2020-01-15_08-47.png Thanks for the report! I'm forwarding this upstream.
Bug#948981: schleuder: fails to gracefully handle incoming mails which are not encrypted to the list key
Package: schleuder Version: 3.4.1-1 Forwarded: https://0xacab.org/schleuder/schleuder/issues/337 Tags: fixed-upstream Schleuder fails to handle incoming mails, which are not encrypted to the list key, but are encrypted to a different key, using symmetric encryption or are just containing PGP-garbage. It throws an exception and errors out. A fix addressing this issue was released upstream: Don't throw an exception, don't notify (and annoy) the admins, instead inform the sender of the mail how to do better.
