Bug#1040330: Build without libffado on Ubuntu
Hi Sebastien, Le mar. 4 juil. 2023 à 16:45, Sebastien Bacher a écrit : > > The recent update added a depends on libffado, that component is > currently in Ubuntu universe so it means we need to build without it > there. Could you consider using the attached patch so we can keep the > package in sync between the distributions? > > The .install change is a bit hackish but works, I can work on another > variant with logic in the .rules instead of if you would prefer > Thanks for this patch. I applied the d/rules part, it would be wonderful to have the logic in d/rules. I like to have the list of installed files to make sure I don't miss anything. Best regards, Dylan
Bug#1036731: python3-debian: fails to parse some debian/control.in files
Package: python3-debian Version: 0.1.49 Hello, python3-debian is not able anymore to parse correctly some debian/control.in. The first version with this issue is 0.1.44, so I suppose it is related to the new RTS parser. The consequence of this bug is wrap-and-sort crashes when it run on these files. Below is the error message: Traceback (most recent call last): File "/usr/bin/wrap-and-sort", line 496, in main() File "/usr/bin/wrap-and-sort", line 481, in main modified_files = wrap_and_sort(args) ^^^ File "/usr/bin/wrap-and-sort", line 312, in wrap_and_sort control = WrapAndSortControl(control_file, args) ^^ File "/usr/bin/wrap-and-sort", line 99, in __init__ super().__init__(filename, use_rts_parser=args.rts_parser) File "/usr/lib/python3/dist-packages/devscripts/control.py", line 210, in __init__ self._deb822_file = parse_deb822_file(sequence) ^^^ File "/usr/lib/python3/dist-packages/debian/_deb822_repro/parsing.py", line 3095, in parse_deb822_file deb822_file = Deb822FileElement(LinkedList(tokens)) ^^ File "/usr/lib/python3/dist-packages/debian/_util.py", line 159, in __init__ self.extend(values) File "/usr/lib/python3/dist-packages/debian/_util.py", line 272, in extend for v in values: File "/usr/lib/python3/dist-packages/debian/_deb822_repro/_util.py", line 104, in _impl for token in token_stream: File "/usr/lib/python3/dist-packages/debian/_deb822_repro/_util.py", line 104, in _impl for token in token_stream: File "/usr/lib/python3/dist-packages/debian/_deb822_repro/parsing.py", line 2991, in _build_field_with_value value_element = next(buffered_stream, None) ^^^ File "/usr/lib/python3/dist-packages/debian/_deb822_repro/_util.py", line 143, in __next__ return next(self._stream) ^^ File "/usr/lib/python3/dist-packages/debian/_deb822_repro/_util.py", line 104, in _impl for token in token_stream: File "/usr/lib/python3/dist-packages/debian/_deb822_repro/parsing.py", line 2939, in _build_value_line tokens_in_value = list(buffered_stream.takewhile(_non_end_of_line_token)) ^^^ File "/usr/lib/python3/dist-packages/debian/_deb822_repro/_util.py", line 149, in takewhile while buffer or self._fill_buffer(5): File "/usr/lib/python3/dist-packages/debian/_deb822_repro/_util.py", line 198, in _fill_buffer self._buffer.append(next(self._stream)) ^^ File "/usr/lib/python3/dist-packages/debian/_deb822_repro/_util.py", line 104, in _impl for token in token_stream: File "/usr/lib/python3/dist-packages/debian/_deb822_repro/parsing.py", line 3031, in _abort_on_error_tokens raise SyntaxOrParseError( debian._deb822_repro.types.SyntaxOrParseError: Syntax or Parse error on the line: "%if USE_SYSTEM_ZLIB\n" An easy way to reproduce the crash is to run wrap-and-sort on the debian/ folder of firefox-esr: > wget > http://deb.debian.org/debian/pool/main/f/firefox-esr/firefox-esr_102.11.0esr-1.debian.tar.xz > tar -xvf firefox-esr > wrap-and-sort It crashes in a similar way on these packages: babel-minify and xapian-bindings. Best regards, Dylan
Bug#981285: Please move fdk-aac to main
Hello ftpmasters, First of all, thanks for your hard work! May I ask about the status of the request to move the fdk-aac package into main? A new version moving fdk-aac in main was uploaded in the NEW queue on the 31 Jan 2022, but if I am not wrong, there has been no feedback yet (at least not in #981285). I am asking because regularity, pipewire users ask me why AAC support is disabled in the pipewire package whereas it is enabled in others distributions. I'm sure the decision is not obvious otherwise it would not be the oldest package in the NEW queue :-) but it would be nice to have an update of your point of view on that. A "yes", "no" or "maybe" one of them would be enough :-) Thank you for your time! Best regards, Dylan
Bug#1037286: transition: libcamera 0.0.5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Dear Release Team, Please schedule a transition slot for libcamera 0.0.5. The auto-generated ben tracker looks good: https://release.debian.org/transitions/html/auto-libcamera.html The unique reverse dep (pipewire 0.3.71-1) builds fine with the new libcamera in experimental. Thanks, Dylan
Bug#1035081: RFC: onnxruntime packaging
Hello, I have finalized [1] the package of onnxruntime and have sent it to the NEW queue [2]. I only enabled features I need. A review and/or improvements are welcome :-). Best, Dylan [1] https://salsa.debian.org/deeplearning-team/onnxruntime [2] https://ftp-master.debian.org/new/onnxruntime_1.12.1+dfsg-1.html
Bug#1037138: linux-image-6.0.0-4-amd64: Linux kernel appears to not be respecting sysctl config value "net.ipv6.conf.all.disable_ipv6=1"
Package: src:linux
Version: 6.0.8-1
Severity: normal
Tags: ipv6
X-Debbugs-Cc: dizzy@domad.science
Dear Maintainer,
I am attempting to disable ipv6 entirely on this machine as it being enabled is
causing multiple issues with long connection timeouts etc, and I do not have
ipv6 support from my ISP nor do I use it locally. However, the generally given
advice to set net.ipv6.conf.all.disable_ipv6 to 1 is having no effect, neither
setting it in /etc/sysctl.conf nor using command line sysctl. Setting
net.conf.ipv6..disable_ipv6 works, and is what I am currently doing
for my primary network interface, but I would like ipv6 disabled globally.
This appears to be a kernel issue afaict, I'm not 100% up on how the sysctl
mechanism works, but yeah.
-- Package-specific info:
** Version:
Linux version 6.0.0-4-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian
12.2.0-9) 12.2.0, GNU ld (GNU Binutils for Debian) 2.39) #1 SMP PREEMPT_DYNAMIC
Debian 6.0.8-1 (2022-11-11)
** Command line:
root=UUID=9195fe01-470b-4e23-8bec-110cf1aa12cc ro quiet splash
initrd=boot\initrd.img-6.0.0-4-amd64
** Tainted: OE (12288)
* externally-built ("out-of-tree") module was loaded
* unsigned module was loaded
** Kernel log:
[652201.887641] I/O error, dev sr0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1
prio class 2
[652201.887644] Buffer I/O error on dev sr0, logical block 0, async page read
[652201.887653] sr 2:0:0:0: [sr0] tag#7 unaligned transfer
[652201.887654] I/O error, dev sr0, sector 1 op 0x0:(READ) flags 0x0 phys_seg 1
prio class 2
[652201.887656] Buffer I/O error on dev sr0, logical block 1, async page read
[652201.887661] sr 2:0:0:0: [sr0] tag#8 unaligned transfer
[652201.887661] I/O error, dev sr0, sector 2 op 0x0:(READ) flags 0x0 phys_seg 1
prio class 2
[652201.887662] Buffer I/O error on dev sr0, logical block 2, async page read
[652201.887666] sr 2:0:0:0: [sr0] tag#9 unaligned transfer
[652201.887667] I/O error, dev sr0, sector 3 op 0x0:(READ) flags 0x0 phys_seg 1
prio class 2
[652201.887668] Buffer I/O error on dev sr0, logical block 3, async page read
[652201.887672] sr 2:0:0:0: [sr0] tag#10 unaligned transfer
[652201.887673] I/O error, dev sr0, sector 4 op 0x0:(READ) flags 0x0 phys_seg 1
prio class 2
[652201.887674] Buffer I/O error on dev sr0, logical block 4, async page read
[652201.887678] sr 2:0:0:0: [sr0] tag#11 unaligned transfer
[652201.887678] I/O error, dev sr0, sector 5 op 0x0:(READ) flags 0x0 phys_seg 1
prio class 2
[652201.887679] Buffer I/O error on dev sr0, logical block 5, async page read
[652201.887683] sr 2:0:0:0: [sr0] tag#12 unaligned transfer
[652201.887684] I/O error, dev sr0, sector 6 op 0x0:(READ) flags 0x0 phys_seg 1
prio class 2
[652201.887685] Buffer I/O error on dev sr0, logical block 6, async page read
[652201.887689] sr 2:0:0:0: [sr0] tag#13 unaligned transfer
[652201.887690] I/O error, dev sr0, sector 7 op 0x0:(READ) flags 0x0 phys_seg 1
prio class 2
[652201.887691] Buffer I/O error on dev sr0, logical block 7, async page read
[660275.943849] input: Microsoft X-Box 360 pad 0 as
/devices/virtual/input/input68
[661843.954123] usb 1-3: USB disconnect, device number 24
[661844.358016] usb 1-3: new full-speed USB device number 25 using xhci_hcd
[661844.757670] usb 1-3: New USB device found, idVendor=045e, idProduct=02ea,
bcdDevice= 5.0f
[661844.757676] usb 1-3: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[661844.757677] usb 1-3: Product: Controller
[661844.757679] usb 1-3: Manufacturer: Microsoft
[661844.757680] usb 1-3: SerialNumber: 303336303030383234323338
[661844.769591] input: Microsoft X-Box One S pad as
/devices/pci:00/:00:02.1/:16:00.0/usb1/1-3/1-3:1.0/input/input69
[663457.496690] usb 1-3: USB disconnect, device number 25
[663457.905293] usb 1-3: new full-speed USB device number 26 using xhci_hcd
[663458.237568] usb 1-3: New USB device found, idVendor=045e, idProduct=02ea,
bcdDevice= 5.0f
[663458.237574] usb 1-3: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[663458.237576] usb 1-3: Product: Controller
[663458.237577] usb 1-3: Manufacturer: Microsoft
[663458.237578] usb 1-3: SerialNumber: 303336303030383234323338
[663458.247343] input: Microsoft X-Box One S pad as
/devices/pci:00/:00:02.1/:16:00.0/usb1/1-3/1-3:1.0/input/input70
[672383.489343] usb 1-3: USB disconnect, device number 26
[672384.599744] usb 1-3: new full-speed USB device number 27 using xhci_hcd
[672384.930355] usb 1-3: New USB device found, idVendor=045e, idProduct=02ea,
bcdDevice= 5.0f
[672384.930361] usb 1-3: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[672384.930363] usb 1-3: Product: Controller
[672384.930364] usb 1-3: Manufacturer: Microsoft
[672384.930366] usb 1-3: SerialNumber: 303336303030383234323338
[672384.940759] input: Microsoft X-Box One S pad as
/devices/pci:00/:00:02.1/:16:00.0/usb1/1-3/1-3:1.0/input/input71
[672631.293810] usb 1-3: USB disconnect, device number 27
[672631.933067] usb 1-3:
Bug#1042713: wireplumber: High cpu usage
Le lun. 31 juil. 2023 à 00:21, Nick a écrit : > > On rebooting, a process called wireplumber consumes most of the cpu. > Sound does work. If I kill the process, cpu usage falls, my fan stops > spinning and I no longer have sound. I have to kill wireplumber on > each reboot (or let it try to fry my cpu). Do you have pipewire-libcamera installed? If yes, can you remove it? Can you provide log from pipewire and wireplumber as explained here [1]? Best regards, Dylan [1] https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Troubleshooting#general
Bug#1041302: svt-av1: breaks ABI without SONAME bump
Hi Sebastian, On Mon, 17 Jul 2023 08:51:00 +0200 Sebastian Ramacher wrote: > Version 1.6.0 removed compressed_ten_bit_format from the middle of > EbSvtAv1EncConfiguration, hence changing the memory layout of that > struct. This means that the ABI changed requiring a SONAME bump. I reported this issue upstream. But , now the question is: what is the best way to deal with that on our side? Should I artificially bump the soname? If so, what soname can I use? How do we handle these cases in Debian usually? Best regards, Dylan
Bug#1042011: openrazer-driver-dkms: Driver module fails to build with 6.3 kernel
Hi, Le mar. 25 juil. 2023 à 19:54, Dimitar Samarov a écrit : > > CC [M] /var/lib/dkms/openrazer-driver/3.6.1/build/driver/razerkbd.mod.o > /var/lib/dkms/openrazer-driver/3.6.1/build/driver/razerkbd.mod.c:10:10: fatal > error: asm/orc_header.h: No such file or directory >10 | #include > | ^~ > compilation terminated. > > > I have no clue what could've caused this. I made an attempt at reinstalling > the > linux image, including the headers, but to no avail. > This seems to be a duplicate of #1040178 [1] which is a bug is the kernel package. It should be fixed with the kernel pkgs in unstable, could you confirm? Best regards, Dylan [1] https://bugs.debian.org/1040178
Bug#1043034: pipewire-pulse: Missing dependencie(s) or incomplete
Hi, Le ven. 4 août 2023 à 23:21, Jiff a écrit : > > Ze error : > == > Uninstall *pulse* except those required by other packages. > > Ze cure : > = > apt install pavucontrol paprefs > I don't understand what is your issue, can you elaborate? pavucontrol and paprefs are not dependencies of pipewire. Best regards, Dylan
Bug#1043034: pipewire-pulse: Missing dependencie(s) or incomplete
Hi, Le sam. 5 août 2023 à 11:42, B a écrit : > > After removing almost all pulseaudio packages, except those linked to > other programs, I rebooted and pipewire-pulse was gone (pipewire and > wireplumber were launched as usual). Not sure what happened, maybe a package that should have stayed has been deleted. > I rebooted just in case, but still no pipewire-pulse, so I scooped the > web searching for a solution and find a guy saying that installing > pavucontrol & paprefs made him troubleshoot his loss of audio also with > pipewire-pulse too, so I tried, which installed some other packages, and > rebooted - this time, pipewire-pulse was up and running after login. > > I'm not a specialist, but I think it was missing an > org.freedesktop.xxx.xml file that came with one of these two packages or > came from one of their dependencies. I don't see any reference about a missing org.freedesktop.xxx.xml file in the log you provided. I suppose you've confused it with the missing "org.freedesktop.portal.Desktop" which is a D-Bus interface used by pipewire for screen-sharing, so not related to your sound issue. This file is provided by the package xdg-desktop-portal (neither pavucontrol nor paprefs). However, I can see in your log you are facing these bugs #995357 [1] and #1037447 [2]. Both of them are not blocking to get sound and are already fixed in newer versions that should land in *-backports repo soon I hope (waiting for a review in the backports queue) > As I made a research for org.freedesktop.*.xml and checked before > and after installing these 2 packages, I saw that the one in the log > wasn't on my disk before, but was there after. > > So, I emitted the hypothesis that it could be an omission in the > pipewire-pulse package, whether it is missing in it or a missing > dependency toward another package. To get rid of pulseaudio and to install pipewire, you can install the metapackage pipewire-audio which depends on all required pipewire packages and conflicts with pulseaudio and its bluetooth plugins package. But really, pipewire does not depend or requires pavucontrol or paprefs. Best regards, Dylan [1] https://bugs.debian.org/995357 [2] https://bugs.debian.org/1037447
Bug#1038990: transition: liblc3 1.0.3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Dear Release Team, Please schedule a transition slot for liblc3 1.0.3. The auto-generated ben tracker looks good: https://release.debian.org/transitions/html/auto-liblc3.html The unique reverse dep (pipewire) builds fine with the new liblc3 in experimental. Thanks, Dylan
Bug#1038990: transition: liblc3 1.0.3
Le dim. 25 juin 2023 à 21:36, Sebastian Ramacher a écrit : > > > The unique reverse dep (pipewire) builds fine with the > > new liblc3 in experimental. > > Please go ahead. Thanks, uploaded! Best regards, Dylan
Bug#1035901: spa.v4l2: '/dev/video4' VIDIOC_ENUM_FRAMESIZES: Unpassender IOCTL (I/O-Control) für das Gerät
Le mer. 14 juin 2023 à 17:30, AlMa a écrit : > Jun 13 21:00:22 AnonymizedMachineName pipewire[1146]: spa.v4l2: > '/dev/video4' VIDIOC_ENUM_FRAMESIZES: Unpassender IOCTL (I/O-Control) > für das Gerät > Jun 13 21:00:22 AnonymizedMachineName pipewire[1146]: spa.v4l2: > '/dev/video4' VIDIOC_ENUM_FRAMESIZES: Unpassender IOCTL (I/O-Control) > für das Gerät > > The last two error messages > > spa.v4l2: '/dev/video4' VIDIOC_ENUM_FRAMESIZES: Unpassender IOCTL > (I/O-Control) für das Gerät I suspect a bug in the driver handling your /dev/video4 device. Do you have more information about what device is your /dev/video4? Dylan
Bug#1033899: pipewire: Pipewire fails to sart, "Main process exited, code=killed, satus=31/SYS".
Le lun. 3 avr. 2023 à 18:54, Itai Shaked a écrit : > > I am at a loss since there seems to be zero usable information in the logs, > just that the service is killed for some (unspecified?) reason. > Can you manually start pipewire with an increased verbose level? The following command should give us more details [1]: PIPEWIRE_LOG_SYSTEMD=false PIPEWIRE_DEBUG=5 pipewire 2>log Dylan [1] https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Troubleshooting#pipewire-debugging-options
Bug#1038001: librem-ec-acpi-dkms: Patch available upstream
Package: librem-ec-acpi-dkms Version: 0.9.1-4 Followup-For: Bug #1038001 X-Debbugs-Cc: d...@bostoncoop.net There's a patch for this upstream: https://source.puri.sm/nicole.faerber/librem-ec-acpi-dkms/-/commit/cec8c0e8bf1532c9c605f60bb02a2ef0f98e5d77 --Dylan Thurston -- System Information: Debian Release: trixie/sid APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages librem-ec-acpi-dkms depends on: ii dkms 3.0.11-2 librem-ec-acpi-dkms recommends no packages. librem-ec-acpi-dkms suggests no packages. -- no debconf information
Bug#1063530: node-undici: FTBFS with nodejs 18.19.0+dfsg-6~deb12u1
~~
../../../../usr/share/nodejs/@types/node/ts4.8/globals.d.ts:344:37 -
error TS2307: Cannot find module 'undici-types' or its corresponding
type declarations.
344 type RequestDuplex = import("undici-types").RequestDuplex;
~~
../../../../usr/share/nodejs/@types/node/ts4.8/globals.d.ts:360:21 -
error TS2307: Cannot find module 'undici-types' or its corresponding
type declarations.
360 : typeof import("undici-types").Request;
~~
../../../../usr/share/nodejs/@types/node/ts4.8/globals.d.ts:367:21 -
error TS2307: Cannot find module 'undici-types' or its corresponding
type declarations.
367 : typeof import("undici-types").Response;
~~
../../../../usr/share/nodejs/@types/node/ts4.8/globals.d.ts:374:21 -
error TS2307: Cannot find module 'undici-types' or its corresponding
type declarations.
374 : typeof import("undici-types").FormData;
~~
../../../../usr/share/nodejs/@types/node/ts4.8/globals.d.ts:381:21 -
error TS2307: Cannot find module 'undici-types' or its corresponding
type declarations.
381 : typeof import("undici-types").Headers;
~~
Found 18 errors in the same file, starting at:
../../../../usr/share/nodejs/@types/node/ts4.8/globals.d.ts:325
dh_auto_build: error: cd ./llparse-builder && sh -ex
../debian/nodejs/llparse-builder/build returned exit code 2
Best regards,
Dylan
Bug#1063898: pipewire-bin: customization file in ALSA profile-sets wrongly packaged
Hi, Le mer. 14 févr. 2024 à 13:45, Sander van Grieken a écrit : > > The file /usr/share/alsa-card-profile/mixer/profile-sets/-custom.conf, > which is packaged as part of pipewire-bin and intended to be customized by the > user, is packaged in a way that it is overwritten by upgrades. > > The file -custom.conf should not be included, or included with a different > name, e.g. -custom.conf.example > This file/feature was implemented with the idea of using dpkg-divert on it, see https://gitlab.freedesktop.org/pipewire/pipewire/-/merge_requests/1686 Any reason of not using dpkg-divert? Best regards, Dylan
Bug#1063530: node-undici: FTBFS with nodejs 18.19.0+dfsg-6~deb12u1
Control: tag -1 patch > While doing a rebuild of some node packages in Bookworm, it appears several > packages (at least ~ 50 pkgs) no longer build with nodejs > 18.19.0+dfsg-6~deb12u1 > (from bookworm-security repo) while they still successfully build with nodejs > 18.13.0+dfsg1-1 (from the main bookworm repo). They all fail with the > same error: > error TS2307: Cannot find module 'undici-types' or its corresponding > type declarations. A fix for this issue has been proposed: https://salsa.debian.org/js-team/node-undici/-/merge_requests/2/ Thanks Ryan! Best regards, Dylan
Bug#1021530: wireplumber: No sound after upgrade to 0.4.12-1
Hi, Are there still problems here? I'm tempted to close this bug since wireplumber doesn't conflict with pulseaudio. If there is a conflict it is between pulseaudio and pipewire-pulse and/or pipewire-alsa. But installing pipewire-audio should get ride of pulseaudio to avoid any conflicts (**after** a reboot). Best regards, Dylan
Bug#1006365: wireplumber: Please split audio files out of the main package
Control: tag -1 wontfix Le jeu. 24 févr. 2022 à 11:33, Laurent Bigonville a écrit : > > Would it be possible to split the configuration and plugins files that > enable the "audio" part of pipewire to an other package? That way > pipewire-pulse could depend on that package instead? I tag this bug as wontfix for now. Once wireplumber 0.5 is released, we can re-evaluate it. Best, Dylan
Bug#998073: wireplumber: fails to automatically switch to headphones when connected
Control: fixed -1 0.4.13-1 Hi Vincent, Le lun. 18 déc. 2023 à 23:57, Vincent Lefevre a écrit : > > FYI, I have a new laptop, where I use wireplumber 0.4.13-1 > (Debian stable) with the same Bluetooth devices (speakers and > headphones), and there are no such problems with it. That is a good news! > So either the bug has been fixed in wireplumber 0.4.13-1 or there > has been something else on the old laptop that broke wireplumber. > I don't see any change in the changelog of 0.4.13 that could be related to this bug. As we have no other clues, I tag this bug as fixed with 0.4.13-1 without closing it. Best regards, Dylan
Bug#1012454: wireplumber: multiple permission denied errors in logs after installing
Hi, Do you still have this problem? Best regards, Dylan
Bug#1057767: pipewire: Last upgrade completely broke bluetooth connection: : org.bluez.Error.Failed br-connection-unknown
Hi, Le ven. 8 déc. 2023 à 10:48, arne anka a écrit : > >* What led up to the situation? > > On Dec 6 I upgraded and since the my BT thingy does not connect to my PC > anymore. > I am hearing impaired and need to use a BT thingy called RemoteMic+ (by > Starkey) to be able to listen to music or make calls/attend meetings via PC. > So, this is a major issue for me. > Among others these packages were upgraded: > > firmware-iwlwifi > > libpipewire-0.3-0 > libpipewire-0.3-common > libspa-0.2-bluetooth > libspa-0.2-modules > > >* What exactly did you do (or not do) that was effective (or > ineffective)? > > First I downgraded firmware-iwlwifi to version 20230210-5 -- to no avail. Did you try downgrading only firmware-iwlwifi to the last working version without downgrading pipewire? Was the kernel updated at the same time? If you can confirm that the problem comes from pipewire, it's worth filling a bug report upstream at: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues Best regards, Dylan
Bug#1061071: transition: libcamera 0.2.0
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: affects -1 + src:libcamera Dear Release Team, Please schedule a transition slot for libcamera 0.2.0. The auto-generated ben tracker looks good: https://release.debian.org/transitions/html/auto-libcamera.html The unique reverse dep (pipewire 1.0.1-1) builds fine with 2 upstream patches [1], since they break the backward compatibility, I plan to do an upload of pipewire once libcamera0.2 is in unstable. Thanks, Dylan [1] https://salsa.debian.org/utopia-team/pipewire/-/commit/a48d3473
Bug#1056701: ITP: roc-toolkit -- real-time audio streaming over the network
Package: wnpp Severity: wishlist Owner: Dylan Aïssi X-Debbugs-Cc: debian-de...@lists.debian.org, debian-multime...@lists.debian.org * Package name: roc-toolkit * URL: https://roc-streaming.org/ * License: MPL-2.0 Roc is a network transport, highly specialized for the real-time streaming use case. The user writes the stream to the one end and reads it from another end, and Roc deals with all the complexity of the task of delivering data in time and with no loss. Encoding, decoding, adjusting rates, restoring losses - all these are performed transparently under the hood. This package is maintained by Debian Multimedia Team at: https://salsa.debian.org/multimedia-team/roc-toolkit
Bug#1061071: transition: libcamera 0.2.0
Hi Sebastian, Le dim. 21 janv. 2024 à 16:56, Sebastian Ramacher a écrit : > > > Please schedule a transition slot for libcamera 0.2.0. > > Please go ahead. > Thanks! Both libcamera 0.2 and pipewire were uploaded to unstable yesterday. Best regards, Dylan
Bug#988337: weston: Fails to start with `environment variable XDG_RUNTIME_DIR is not set.`
Control: tag -1 wontfix As explained in the linked upstream bug, this is expected and marked as "won't fix". Best, Dylan
Bug#1055825: pipewire v0.3.84 breaks HDMI audio
Le dim. 12 nov. 2023 à 07:15, Ian Bruce a écrit : > > pipewire v0.3.84 broke that. It forced the removal of pulseaudio (except some > libraries), There was no change in the packaging of pw 0.3.84 forcing the removal of pulseaudio. > and disabled HDMI audio completely. HDMI output can still be selected in > "pavucontrol", > and the amplitude indicator wiggles appropriately, but absolutely nothing > comes > out of the > TV speakers. Switching the stream back to the analog speakers works properly; > switching > to HDMI produces silence. No issue here with pw 0.3.85 to switch between laptop speakers and hdmi speakers. > I have now downgraded pipewire to v0.3.65/stable, and everything works > properly > again. > A playing stream can be switched back and forth repeatedly between speakers > and > TV, > with no problems. pipewire v0.3.83 is no longer available in the archive for > testing, > but something between v0.3.65 and v0.3.84 broke HDMI audio completely, at > least > with this > hardware configuration, which doesn't seem particularly unusual. If you want to test other versions, you can find all previous packages at https://snapshot.debian.org/package/pipewire/ Best, Dylan
Bug#1060785: libspa-audioconvert: Crash sometimes due to misaligned load to YMM register.
Hi Ohta, Le dim. 14 janv. 2024 à 10:24, Kyuma Ohta a écrit : > > Sometimes ...mostly be load growth a lot..., pipe-wire daemon or > pipewire-pulse daemon crashes with below message [1]. > > This happens misalign of loading to YMM register [2][3]. > > This crash seems to happen at "vlddqu -0x20(%rcx),%ymm2" [2], > this need align at 256bit (but, Older Ryzen may be need only align of > 128bit). > But, RCX register didn't align of 256bits [3]. > Value is 0x5650f98e99c4 . > > So, software related libspa-audioconvert crashes sometime and randomly. > I think. Thank you for this bug report. May I ask you to forward it upstream? at https://gitlab.freedesktop.org/pipewire/pipewire/-/issues Thank you! Best regards, Dylan
Bug#1060785: libspa-audioconvert: Crash sometimes due to misaligned load to YMM register.
Hello, Le lun. 15 janv. 2024 à 22:00, K.Ohta a écrit : > > I forwarded to upstream. > See, https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3790 . > Thank you for your suggestion. This bug is marked as fixed upstream, so can we close it here as well or is it still an issue? Best regards, Dylan
Bug#1070041: waybar: wireplumber support disabled in 0.10.2-1
Source: waybar Version: 0.10.2-1 Severity: important Hello, Since 0.10.2-1 the support of wireplumber in waybar got disabled. Indeed, since 0.10.1 waybar requires wirpelumber >= 0.5 whereas previous versions are only compatible with wireplumber <= 0.4.X. So, the current dependency on libwireplumber-0.4-dev has no effect as confirmed by its build log: Run-time dependency wireplumber-0.5 found: NO (tried pkgconfig and cmake) Currently, wireplumber 0.5 is only available in experimental waiting for his transition slot. Could you either drop the dependency on libwireplumber-0.4-dev in unstable/testing or do an upload to experimental with a build-dep on libwireplumber-0.5-dev? I will fill a bug for the wireplumber-0.5 transition and will mark this bug as blocker to make thing easier for release team. Thank you. Best, Dylan
Bug#1070043: transition: wireplumber 0.5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: affects -1 + src:wireplumber Dear Release Team, Please schedule a transition slot for wireplumber 0.5. The auto-generated ben tracker was deleted (not sure why), but here is a new ben file: Ben file: - title = "wireplumber-0.5"; is_affected = .build-depends ~ /libwireplumber-0.4-dev|libwireplumber-0.5-dev/; is_good = .depends ~ "libwireplumber-0.5-0"; is_bad = .depends ~ "libwireplumber-0.4-0"; - I identified two packages affected by this transition: - waybar, but last upload has mistakenly dropped the support of wireplumber (#1070041), but anyway the version in unstable is compatible with wireplumber 0.5. - asahi-audio which only provides config for wireplumber, but the new version compatible with wireplumber is already in experimental (#1067660). Thanks. Best regards, Dylan
Bug#1067660: wireplumber: Wireplumber 0.5.0 breaks asahi-audio 1.x
Hello, Le dim. 31 mars 2024 à 15:41, Andreas Henriksson a écrit : > > PLEASE NOTIFY US WHEN YOU UPLOAD wireplumber 0.5.x to UNSTABLE, so we > can do a coordinated transition (uploading asahi-audio 2.x to unstable). > (You might also want to contact release-team to set up a transition > tracker, even if this might not be a normal transition where binNMUs are > useful etc.) > The autogenerated tracker for transition was removed (don't know why). I asked for a new one (#1070043). The only other package (waybar) affected by this transition has now a compatible version in unstable. So, I think except the t64 transition nothing else is blocking, I am waiting the green light from the release team for next step, and I will ping here before uploading wireplumber 0.5 in unstable. Best regards, Dylan
Bug#1067660: wireplumber: Wireplumber 0.5.0 breaks asahi-audio 1.x
Hello Andreas, Le mar. 30 avr. 2024 à 17:26, Andreas Henriksson a écrit : > > We now have asahi-audio 2.x in experimental. Please poke us again when > we should upload to unstable (or feel free to NMU asahi-audio to > unstable when you upload wireplumber 0.5.x to unstable). > The release team agreed to go ahead with this transition, so I am going to upload wireplumber in unstable and I will do a nmu for asahi-audio at the same time. Best regards, Dylan
Bug#1070043: transition: wireplumber 0.5
Le dim. 5 mai 2024 à 18:41, Sebastian Ramacher a écrit : > > > Please schedule a transition slot for wireplumber 0.5. > > Please go ahead. > Thanks, uploaded to unstable. Best regards, Dylan
Bug#1070348: pipewire: pipewire-pulse: warningin syslog every second for snap_get_audio_permissions
Hello Sergio and Jeremy, Le sam. 4 mai 2024 à 05:48, Michael Welsh Duggan a écrit : After updating my linux kernel to 6.7.12-1, I keep getting the following message in my syslog, once a second: pipewire-pulse[]: default: snap_get_audio_permissions: kernel lacks 'fine grained unix mediation'; snap audio permissions won't be honored. It seems that snap support in pipewire requires a kernel feature (fine grained unix mediation) that is not yet enabled in Debian. I'm thinking of disabling for now the snap support in Debian since there is no point in keeping it enabled if it's unusable. But, I will keep it enabled for Ubuntu. What do you think? Best regards, Dylan
Bug#1070041: waybar: wireplumber support disabled in 0.10.2-1
Hello, On Mon, 29 Apr 2024 11:01:52 +0200 =?UTF-8?B?RHlsYW4gQcOvc3Np?= wrote: > > Currently, wireplumber 0.5 is only available in experimental waiting for his > transition slot. wireplumber 0.5 was uploaded to unstable today. Best regards, Dylan
Bug#1065345: pipewire-jack: Improve package description
Hello, Le dim. 3 mars 2024 à 10:24, Chris Joelly a écrit : > In my point of view it is not clearly understandable fromthe package > desciptions or package docs how pipewire-jack and libspa-0.2-jack relate. I > understood that pipewire-jack, aside from being a plugin, is a implementation > of a JACK server based on JACK API and pipewire. And, I understood > libspa-0.2-jack is a lib which is needed for pipewire to connect to a JACK > server. These are two different things imho. Looks like a duplicate of https://bugs.debian.org/1062262 Now, we have (only in git for now): pipewire-jack: This package contains a plugin for JACK applications to output via PipeWire. libspa-0.2-jack: This package contains a plugin to make PipeWire able to connect to a JACK server, which will be used for audio playback and recording. I guess it makes things clearer? Feel free to create a merge request to improve the description. > But I learned that JACK client applications can not connect to pipewire-jack > when libspa-0.2-jack is not installed. Thus, libspa-0.2-jack is too needed > when > JACK clients want to connect to pipewire-jack, basically making it a > dependency? Heu no, I just tried to remove libspa-0.2-jack, then run (after a reboot) $ pw-jack sndfile-jackplay my_random_wave_file and it works. Best, Dylan
Bug#1066112: weston: Enable support to libseat launcher in weston 10
Hello, Le mar. 12 mars 2024 à 20:45, Carlos Henrique Lima Melara a écrit : > > Taking this into consideration and the outcome of Init systems and > systemd GR [3], I'd like to check with you the possibility of enabling the > support for libseat launcher in stable via a proposed-updates upload to > bookworm. I'm not against that, but we will have to convince the release team that it won't introduce new bugs. That means we have to fill a bug report against the pseudo-package "release.debian.org". If we are going to touch the package in Bookworm, I would like to try pushing the last bugfix release of the serie 10.0. It was a private request from upstream but I didn't realized that there were very few changes in the bugfix releases, it's worth a try. What do you think? I can try this week to prepare an updated package in a dedicated branch in salsa, so you can test it. Then, if everything is okay, we could fill the request to the release team. > I did rebuild bookworm's version with the option enabled and tested it a > bit in my notebook. I've also used abi-compliance-checker to check if > this could have caused any ABI change in libweston and it didn't. I'll > provide the debdiff output for you to check. > > Also, should you answer positively, I can do a more exhaustive testing > and check if we don't introduce any errors when running with elogind and > systemd-logind. This will be very useful to convince the release team. Best regards, Dylan
Bug#1066836: libcamera: ftbfs with 64-bit time_t
Hi Kieran, I guess this task is for me ;-) Yes, I will submit it. Best, Dylan On 3/14/24 13:04, Kieran Bingham wrote: Hi Steve, do you also plan to submit this to the libcamera-devel mailing list? -- Kieran Quoting Steve Langasek (2024-03-14 05:35:04) Package: libcamera Version: 0.2.0-1 Severity: serious Tags: patch Justification: ftbfs User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu noble ubuntu-patch Dear maintainers, libcamera fails to build from source on 32-bit architectures under 64-bit time_t, because it has a module that legitimately un-sets _FILE_OFFSET_BITS for building but this is not allowed without also unsetting _TIME_BITS: [...] [267/430] c++ -Isrc/v4l2/v4l2-compat.so.p -Isrc/v4l2 -I../src/v4l2 -Iinclude -I../include -Iinclude/libcamera/ipa -Iinclude/libcamera -fdiagnostics-color=always -Wall -Winvalid-pch -Wextra -Werror -std=c++17 -Wno-redundant-move -Wno-psabi -Wshadow -include /<>/obj-arm-linux-gnueabihf/config.h -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -fno-stack-clash-protection -fdebug-prefix-map=/<>=/usr/src/libcamera-0.2.0-1ubuntu3 -Wno-error -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=3 -fPIC -DLIBCAMERA_BASE_PRIVATE -U_FILE_OFFSET_BITS -D_FILE_OFFSET_BITS=32 -D_LARGEFILE64_SOURCE -fvisibility=hidden -MD -MQ src/v4l2/v4l2-compat.so.p/v4l2_camera.cpp.o -MF src/v4l2/v4l2-compat.so.p/v4l2_camera.cpp.o.d -o src/v4l2/v4l2-compat.so.p/v4l2_camera.cpp.o -c ../src/v4l2/v4l2_camera.cpp FAILED: src/v4l2/v4l2-compat.so.p/v4l2_camera.cpp.o c++ -Isrc/v4l2/v4l2-compat.so.p -Isrc/v4l2 -I../src/v4l2 -Iinclude -I../include -Iinclude/libcamera/ipa -Iinclude/libcamera -fdiagnostics-color=always -Wall -Winvalid-pch -Wextra -Werror -std=c++17 -Wno-redundant-move -Wno-psabi -Wshadow -include /<>/obj-arm-linux-gnueabihf/config.h -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -fno-stack-clash-protection -fdebug-prefix-map=/<>=/usr/src/libcamera-0.2.0-1ubuntu3 -Wno-error -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=3 -fPIC -DLIBCAMERA_BASE_PRIVATE -U_FILE_OFFSET_BITS -D_FILE_OFFSET_BITS=32 -D_LARGEFILE64_SOURCE -fvisibility=hidden -MD -MQ src/v4l2/v4l2-compat.so.p/v4l2_camera.cpp.o -MF src/v4l2/v4l2-compat.so.p/v4l2_camera.cpp.o.d -o src/v4l2/v4l2-compat.so.p/v4l2_camera.cpp.o -c ../src/v4l2/v4l2_camera.cpp In file included from /usr/include/features.h:394, from /usr/include/arm-linux-gnueabihf/c++/13/bits/os_defines.h:39, from /usr/include/arm-linux-gnueabihf/c++/13/bits/c++config.h:679, from /usr/include/c++/13/bits/requires_hosted.h:31, from /usr/include/c++/13/deque:60, from ../src/v4l2/v4l2_camera.h:10, from ../src/v4l2/v4l2_camera.cpp:8: /usr/include/features-time64.h:26:5: error: #error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64" 26 | # error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64" | ^ [...] (https://launchpad.net/ubuntu/+source/libcamera/0.2.0-1ubuntu3/+build/27902670) Since this is a legitimate un-setting of _FILE_OFFSET_BITS in order to get access to the necessary libc6 prototypes and macros, and since the functions being intercepted are not sensitive to time_t, the simplest solution is to also unset _TIME_BITS. Please see the attached patch, which has been uploaded to Ubuntu to fix this build failure. Thanks for considering, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- Dylan Aïssi Software Engineer Collabora Ltd. Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK Registered in England & Wales, no. 5513718
Bug#1066112: weston: Enable support to libseat launcher in weston 10
Hi, Le mer. 13 mars 2024 à 16:05, Carlos Henrique Lima Melara a écrit : > > > I can try this week to prepare an updated package in a dedicated branch > > in salsa, so you can test it. Then, if everything is okay, we could fill > > the request to the release team. > > Sure, just let me know if you need help with anything and/or when the > packaging is ready for testing. Ready for testing at: https://salsa.debian.org/xorg-team/wayland/weston/-/tree/debian-10.0 I just realized the branch name is confusing... Best, Dylan
Bug#1063088: weston: NMU diff for 64-bit time_t transition
Hello, Le lun. 5 févr. 2024 à 02:54, Steve Langasek a écrit : > > If you have any concerns about this patch, please reach out ASAP. Although > this package will be uploaded to experimental immediately, there will be a > period of several days before we begin uploads to unstable; so if information > becomes available that your package should not be included in the transition, > there is time for us to amend the planned uploads. > I am wondering what is the plan with this package/bug? I noticed that changes related to the 64-bit time_t transition were not uploaded to unstable and because I uploaded several versions in unstable after your NMU in exp, I wonder if I haven't interfered with this transition. Best regards, Dylan
Bug#1067660: wireplumber: Wireplumber 0.5.0 breaks asahi-audio 1.x
Control: reassign -1 asahi-audio Control: notfound -1 0.4.17-1 Control: found -1 1.7-1 Control: affects -1 wireplumber Hello, Thanks for this bug report, I reassign it to asahi-audio since the versioned dependency is on it and not on wireplumber. Le lun. 25 mars 2024 à 09:45, Thomas Renard a écrit : > > According to the new api in wireplumber asahi-audio 1.x breaks. The asahi > developer tries to fix this upstream in asahi-audio during this week but > because of the > api change asahi-audio 2.x will break with wireplumber <0.5.0. > > So there is/will be a direct dependency: > > wireplumber 0.4.x compatible to asahi-audio 1.x > wireplumber >= 0.5.0 comaptible to asahi-audio 2.x > > Source; fedora-asahi-dev channel on matrix 24.03.2024, @chadmed around 01.24. > https://matrix.to/#/#asahi-devel:fedoraproject.org > > Please consider this I don't plan to upload wireplumber 0.5.0 to unstable soon because it's kind of blocked by waybar which is not yet compatible with it, it's fixed in git upstream but no release and also because of the t64 transition. So, since asahi-audio seems to want to fix this bug this week, we should have a new compatible version of asahi-audio in due course. Best, Dylan
Bug#1066112: weston: Enable support to libseat launcher in weston 10
Hi Charles,
Sorry for not answering before.
Le jeu. 4 avr. 2024 à 16:04, Carlos Henrique Lima Melara
a écrit :
>
> > So, I have good and bad news, but I guess they are mostly good.
> >
> > THe bad news first, when I was checking the upstream commits, I saw some
> > changes in libweston.h which raised some flags about ABI incompatibilty
> > because they introduced some members in a publicly exposed struct. So I
> > set my feet on testing abi changes with abi-dumper +
> > abi-compliance-checker (it was my first time, that's why it took so
> > long).
> >
> > The actually bad new is 08979a1 (from 10.0.4) [1] makes some problematic
> > changes in libweston.h:
> >
> > --- a/include/libweston/libweston.h
> > +++ b/include/libweston/libweston.h
> > @@ -1289,6 +1289,7 @@ struct weston_view {
> > struct weston_surface *surface;
> > struct wl_list surface_link;
> > struct wl_signal destroy_signal;
> > + struct wl_signal unmap_signal;
> >
> > /* struct weston_paint_node::view_link */
> > struct wl_list paint_node_list;
> > @@ -1441,6 +1442,7 @@ struct weston_pointer_constraint {
> > bool hint_is_pending;
> >
> > struct wl_listener pointer_destroy_listener;
> > + struct wl_listener view_unmap_listener;
> > struct wl_listener surface_commit_listener;
> > struct wl_listener surface_activate_listener;
> > };
> >
> > This introduces an ABI incompatibility in libweston as caught by
> > abi-compliance-checker (report attached):
> >
> > Comparing ABIs ...¬
> > Comparing APIs ...¬
> > Creating compatibility report ...¬
> > Binary compatibility: 77.8%¬
> > Source compatibility: 100%¬
> > Total binary compatibility problems: 1, warnings: 1¬
> > Total source compatibility problems: 0, warnings: 1¬
> > Report: compat_reports/libweston-10.so.dump/0_to_1/compat_report.html¬
> >
> > I think this would get a solid NO from the release team (although I'm
> > not sure). Since the whole 10.0.4 release (the 4 commits) are related to
> > each other, I think we won't be able to pick it.
> >
> > That said, I started testing with the 10.0.3 release (because if we
> > can't get the latest, let's try to get something at least). And the
> > results are good, we have 100% abi and api compatibility for all DSOs,
> > even internal ones.
> >
> > Also, building the 10.0.3 (always with libseat launcher support
> > enabled), the build time tests give the same results (with 10.0.5 I was
> > getting slightly different results).
> >
> > I also tested the libseat launcher and normal launcher and they both
> > work.
> >
> > Finally, since the 10.0.5 patch release is only 1 commit, we can grab it
> > as a patch in the packaging side, so we would just miss the 10.0.4 patch
> > release.
> >
> > Well, it was a long email, but the main takeway is 10.0.4 introduces an
> > ABI incompatibility and would be unsuitable for a proposed-update to
> > bookworm. But we can use the 10.0.3 release plus the only commit in
> > 10.0.5 with libseat launcher support with 100% abi and api
> > compatibility.
Thanks a lot for your analysis and testing.
This ABI incompatibility it's unfortunate :-( In this case, I would
instead focus our request to your initial request, i.e. only enabling
the support of libseat without trying to push a new version. It would
make our request simpler and I hope easier to accept.
Initially, the next release point for Bookworm was planned tomorrow,
but due to the xz issue, it's postponed to a later date. I guess we are
too late for it anyway.
I pushed a new branch "debian-bookworm-updates" with only
10.0.1-1+deb12u1, could you please test this one, especially
with logind to make sure we are not introducing any regressions?
Meanwhile, I pinged upstream to ask for their opinion about
that to make sure we are not going to break stuff. I also
drafted a bug report for release team.
> Would you be okay of using 10.0.3 instead of 10.0.5?
>
> Also, if you need any help, please let me know.
>
> Maybe a disclaimer I should have sent in the first email, I do work at
> Toradex which is an embedded systems company and we are rebuilding
> weston with libseat-launcher support for a while. I'm also a Debian
> contributor and maintainer (DM) and I suggested to our management to try
> to send this change to Debian as a contribution. They were very
> supportive about contributing back to Debian, so here we are :-)
That is nice! Thank you for pushing your changes upstream :-)
Let's try to make it a success for more contributions.
Best,
Dylan
Bug#1066112: weston: Enable support to libseat launcher in weston 10
Hi, Le ven. 5 avr. 2024 à 16:00, Dylan Aïssi a écrit : > Meanwhile, I pinged upstream to ask for their opinion about > that to make sure we are not going to break stuff. launcher-libseat has an higher priority than launcher-logind, that means enabling launcher-libseat will change the default behavior for all users. Although this should be harmless because libseat should contact logind, it doesn't work for whatever reason. I just tested with a VM without a graphical login. I can launch weston 10.0.1-1, but it fails with 10.0.1-1+deb12u1. So, I guess it would require more changes unsuitable for bookworm :-( Best, Dylan
Bug#1067886: chromium: Repeated crashes
Package: chromium Version: 123.0.6312.58-1 Severity: important X-Debbugs-Cc: d...@bostoncoop.net, d...@bostoncoop.net After upgrading from 122.0.6261.128-1 to 123.0.6312.58-1, I'm experiencing repeated crashes/thread hangs on many web pages. It seems to happen more often on pages with more complicated scripting. For instance browsing Discord will trigger the crash pretty quickly. Another place I experience frequent crashes is on my university's Canvas page. I downgraded to verify that it wasn't just my memory. I've attach a gdb log from a Discord session. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.7.9-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages chromium depends on: ii chromium-common 123.0.6312.58-1 ii libasound2t641.2.11-1+b1 ii libatk-bridge2.0-0t642.51.90-4 ii libatk1.0-0t64 2.51.90-4 ii libatomic1 14-20240315-1 ii libatspi2.0-0t64 2.51.90-4 ii libc62.37-15.1 ii libcairo21.18.0-3 ii libcups2t64 2.4.7-1.2+b1 ii libdbus-1-3 1.14.10-4+b1 ii libdouble-conversion33.3.0-1+b1 ii libdrm2 2.4.120-2 ii libevent-2.1-7t642.1.12-stable-8.1+b1 ii libexpat12.6.2-1 ii libflac12t64 1.4.3+ds-2.1 ii libfontconfig1 2.15.0-1.1 ii libfreetype6 2.13.0+dfsg-1 ii libgbm1 24.0.3-1+b1 ii libgcc-s114-20240315-1 ii libglib2.0-0t64 2.78.4-6 ii libgtk-3-0t64 [libgtk-3-0] 3.24.41-4 ii libjpeg62-turbo 1:2.1.5-2+b2 ii libjsoncpp25 1.9.5-6+b2 ii liblcms2-2 2.14-2+b1 ii libminizip1t64 1:1.3.dfsg-3.1 ii libnspr4 2:4.35-1.1+b1 ii libnss3 2:3.99-1 ii libopenh264-72.4.1+dfsg-1 ii libopenjp2-7 2.5.0-2+b3 ii libopus0 1.4-1+b1 ii libpango-1.0-0 1.52.1+ds-1 ii libpng16-16t64 1.6.43-3 ii libpulse016.1+dfsg1-3+b1 ii libsnappy1v5 1.1.10-1+b1 ii libstdc++6 14-20240315-1 ii libwebp7 1.3.2-0.4+b1 ii libwebpdemux21.3.2-0.4+b1 ii libwebpmux3 1.3.2-0.4+b1 ii libwoff1 1.0.2-2+b1 ii libx11-6 2:1.8.7-1 ii libxcb1 1.15-1 ii libxcomposite1 1:0.4.5-1 ii libxdamage1 1:1.1.6-1 ii libxext6 2:1.3.4-1+b1 ii libxfixes3 1:6.0.0-2 ii libxkbcommon01.6.0-1 ii libxml2 2.9.14+dfsg-1.3+b2 ii libxnvctrl0 535.171.04-1 ii libxrandr2 2:1.5.4-1 ii libxslt1.1 1.1.35-1 ii xdg-desktop-portal-gtk [xdg-desktop-portal-backend] 1.15.1-1+b1 ii zlib1g 1:1.3.dfsg-3.1 Versions of packages chromium recommends: ii chromium-sandbox 123.0.6312.58-1 Versions of packages chromium suggests: pn chromium-driver pn chromium-l10n pn chromium-shell Versions of packages chromium-common depends on: ii libc6 2.37-15.1 ii libjsoncpp25 1.9.5-6+b2 ii
Bug#1067958: ruy: FTBFS on armel, armhf
Control: severity -1 important Hello, Severity serious because it ftbfs on architectures where it has never successfully built seems a bit excessive. Best, Dylan Le ven. 29 mars 2024 à 14:24, Kentaro HAYASHI a écrit : > > Source: ruy > Severity: serious > Tags: ftbfs > Control: found -1 0.0.0~git20230215.21a85fe-1 > X-Debbugs-Cc: ken...@xdump.org > > Dear Maintainer, > > ruy fails to build on armel, armhf. > > FYI: > > https://buildd.debian.org/status/fetch.php?pkg=ruy=armel=0.0.0%7Egit20230215.21a85fe-1=1688810281=0 > https://buildd.debian.org/status/fetch.php?pkg=ruy=armhf=0.0.0%7Egit20230215.21a85fe-1=1688810272=0 > > Regards, >
Bug#1063898: pipewire-bin: customization file in ALSA profile-sets wrongly packaged
Le jeu. 15 févr. 2024 à 16:03, Sander van Grieken a écrit : > > Using dpkg-divert is fine. Maybe adding a single comment line mentioning > dpkg-divert in /usr/share/alsa-card-profile/mixer/profile-sets/default.conf, > just above the include of -custom.conf would be helpful. > Patching files always has a maintenance cost that I would like to avoid and since dpkg-divert is something specific to Debian, I am not sure upstream is interested by adding such comment. But, we can install a -custom.conf.README explaining how to use dpkg-divert on it. What do you think? Best, Dylan
Bug#1071577: transition: libcamera 0.3.0
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: affects -1 + src:libcamera Dear Release Team, Please schedule a transition slot for libcamera 0.3.0. The auto-generated ben tracker looks good: https://release.debian.org/transitions/html/auto-libcamera.html The unique reverse dep (pipewire 1.0.6-1) builds fine with libcamera 0.3.0 in experimental. Thanks. Best regards, Dylan
Bug#1071577: transition: libcamera 0.3.0
Hi, Le mer. 22 mai 2024 à 08:51, Emilio Pozuelo Monfort a écrit : > > > Please schedule a transition slot for libcamera 0.3.0. > > > Go ahead. > Thanks, done! Best regards, Dylan
Bug#1072675: snapshot.debian.org: no snapshot for June
Package: snapshot.debian.org Severity: important Dear Maintainer, It seems that all snapshots for June are missing, the last one was on 31 May as shown at: https://snapshot.debian.org/archive/debian/ This makes it impossible to retrieve packages uploaded to the Debian archive since 1st June. Best regards, Dylan
Bug#1072282: libre2-dev: please provide cmake config files
Package: libre2-dev Version: 20240501-3 Severity: wishlist Dear maintainer, Could you please provide cmake config files (re2Targets.cmake, re2Targets-none.cmake, re2Config.cmake and re2ConfigVersion.cmake) in libre2-dev? This will help software using cmake as build system (like onnxruntime) to locate re2. These files are generated when re2 is built with cmake. Best regard, Dylan
Bug#1072335: libheif: ftbfs with svt-av1 2.1
Source: libheif
Version: 1.17.6-1
Severity: important
Tags: ftbfs patch
Forwarded: https://github.com/strukturag/libheif/pull/1146
Dear maintainer,
libheif fails to build with svt-av1 2.1.0+dfsg-1 in experimental.
This is already fixed upstream [1] with the attached patch.
Could you please apply this patch?
Thank you.
Best regards,
Dylan
[1] https://github.com/strukturag/libheif/commit/a911b26
From a911b26a902c5f89fee2dc20ac4dfaafcb8144ec Mon Sep 17 00:00:00 2001
From: Andrey Semashev
Date: Fri, 15 Mar 2024 17:46:48 +0300
Subject: [PATCH] Fix compilation with libsvtav1 2.0.0.
---
libheif/plugins/encoder_svt.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libheif/plugins/encoder_svt.cc b/libheif/plugins/encoder_svt.cc
index 4597d7b8fc..1ff3bce2d5 100644
--- a/libheif/plugins/encoder_svt.cc
+++ b/libheif/plugins/encoder_svt.cc
@@ -646,7 +646,7 @@ struct heif_error svt_encode_image(void* encoder_raw, const struct heif_image* i
if (nclx) {
svt_config.color_description_present_flag = true;
-#if SVT_AV1_VERSION_MAJOR == 1
+#if SVT_AV1_VERSION_MAJOR >= 1
svt_config.color_primaries = static_cast(nclx->color_primaries);
svt_config.transfer_characteristics = static_cast(nclx->transfer_characteristics);
svt_config.matrix_coefficients = static_cast(nclx->matrix_coefficients);
Bug#1069255: libheif: please consider using aom as the preferred plugin and demoting x265 to suggests
Hello, On Fri, 19 Apr 2024 08:02:03 +1200 Vladimir Petko > According to[1], the MIR work was prioritized on aom packages, and due to x265 > nack and plans to replace it with kvazaar, it was demoted to Suggests. > > In Ubuntu, the attached patch was applied to achieve the following: > > * d/control: update dependencies for the Main Inclusion Request (LP: > #2061089): > - Swap libheif-plugin-aomdec and libheif-plugin-dav1d. > - Demote libheif-plugin-x265 to Suggests. Those are distribution choices (and Debian is not Ubuntu), they applied these changes to avoid having dav1d and x265 in their main repo. Not sure why we should follow their choices especially when they seem wrong: dav1d is known to better perform for decoding av1 than aom. Best regards, Dylan
Bug#1070729: wireplumber: 0.5 breaks unmodified configurations because of incompatible state format
Hi, Le mer. 8 mai 2024 à 05:21, Grzesiek11 a écrit : > > As mentioned by the NEWS entry, 0.5 replaces the old configuration > system with a new one utilizing JSON. It also states this should be > transparent for systems using only Debian configuration, however the > state format (for files stored in $XDG_STATE_HOME/wireplumber) is also > incompatible, causing unmodified configurations to break. > > The workaround I used is removing the state directory and restarting the > service, causing it to regenerate. I just uploaded wireplumber 0.5.3 in sid. This version seems to fix a potential duplicated bug. Could you check if this version fix your issue once the package lands in apt repository? Thanks, Dylan
Bug#1072675: snapshot.debian.org: no snapshot for June
Hi, On 6/12/24 16:41, Appu Goundan wrote: Hi, We're noticing that there are still no snapshots for June. Is there an update on this issue? Is there something we can do to help? The infrastructure is being updated so they should reappear afterwards. As a workaround until the work in progress is completed, it is possible to use instead: https://snapshot-mlm-01.debian.org Best regards, Dylan
Bug#1072645: pipewire: Apps using pipewire broken
Hi, Le mer. 5 juin 2024 à 19:45, Helge Kreutzmann a écrit : > > I upgraded from stable to testing a few days ago. In stable all video > and audio applications worked as expected, e.g. vlc, mpv, cmus, > mpg123, ogg123 … > > Now many apps don't. Some (like cmus) produce output, but e.g. vlc and > mpv do not. The only difference I could determine is using pipewire. How did you install pipewire? Did you install pipewire-audio or wireplumber? > pavucontrol only shows a dummy output. It seems that the pipewire's session manager (wireplumber) has a problem or is missing. Best regards, Dylan
Bug#1075896: wireplumber: Please backport v0.5 to stable. v0.4 broken with pipewire 1.2
Hi, Le dim. 7 juil. 2024 à 14:57, NoisyCoil a écrit : > > After upgrading pipewire to 1.2, which was backported to stable back in > April, neither the GNOME settings panel nor `wpctl status` are able to detect > the correct sink, and I can no longer regulate volume (although sound still > plays). Rolling back to 1.0 fixes this. On the same machine, a > testing/unstable installation with wireplumber 0.5 + pipewire 1.2 + the same > kernel has no issues. Apparently then, it is the pairing of wireplumber 0.4 + > pipewire 1.2 that is not working properly. Since bookworm-backports is > already providing pipewire 1.2, I would like to ask you to backport > wireplumber 0.5 to stable in the hope that this will fix the issue. > I don't have any issue here with pipewire 1.2 and wireplumber 0.4 on Bookworm. I guess your issue comes from something else? I am still hesitant to backport wireplumber 0.5 because of the format change of its conf files, this will break users' configuration. Best regards, Dylan
Bug#1074440: kodi dies with "PyImport_AppendInittab() may not be called after Py_Initialize()"
This appears to be https://github.com/xbmc/xbmc/issues/24069
Python seems to be enforcing this behavior since early in the 3.12
cycle: https://docs.python.org/3/whatsnew/changelog.html#id141
Locally, I applied the commit linked from that bug report:
https://github.com/xbmc/xbmc/commit/4bf9de87e700f0de56ef698a8d8d6eb7d4ff9050
It applied and built clean and I haven't had the issue since.
(Admittedly only a few hours, but as Harri noted, it happened almost
immediately before.)
Anyway, thanks for maintaining this. Cheers!
Dylan
On Fri, 28 Jun 2024 18:31:42 +0200 Harald Dunkel wrote:
Package: kodi
Version: 2:20.5+dfsg-2+b2
kodi dies immediately with
{harri@cecil:~ (master) 1032} kodi
/usr/bin/kodi: 1: ulimit: error setting limit (Operation not permitted)
kodi: ulimit is unsupported by this shell
libva info: VA-API version 1.21.0
libva error: vaGetDriverNames() failed with unknown libva error
Fatal Python error: PyImport_AppendInittab: PyImport_AppendInittab() may not be
called after Py_Initialize()
Python runtime state: core initialized
Thread 0x7fa184c006c0 (most recent call first):
File "", line 1648 in _fill_cache
File "", line 1605 in find_spec
File "", line 1502 in _get_spec
File "", line 1528 in find_spec
File "", line 1262 in _find_spec
File "", line 1322 in _find_and_load_unlocked
File "", line 1360 in _find_and_load
Aborted
According to
https://www.reddit.com/r/kodi/comments/1coowz1/crash_in_pyimport_appendinittab_pyimport/?rdt=36220
this is a regression with python 3.12. If I move back to 3.11 the problem
disappears.
According to the reddit link the problem has been fixed with kodi 21. Looking
at the code in git this could be commit
1bfa3ef9e3b6d25d581bb1f48f6a740fca1c06cf.
Regards
Harri
Bug#1074340: transition: svt-av1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: affects -1 + src:svt-av1 Dear Release Team, Please schedule a transition slot for svt-av1. The auto-generated ben tracker looks good: https://release.debian.org/transitions/html/auto-svt-av1.html All reverse deps (ffmpeg, gst-plugins-bad1.0, libavif, handbrake and libheif) build fine with the new version in experimental. Thanks, Dylan
Bug#1074336: transition: roc-toolkit 0.4.0
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: affects -1 + src:roc-toolkit Dear Release Team, Please schedule a transition slot for roc-toolkit 0.4.0. The auto-generated ben tracker looks good: https://release.debian.org/transitions/html/auto-roc-toolkit.html The unique reverse dep (pipewire 1.0.7-1) builds fine with roc-toolkit 0.4.0 in experimental. Thanks. Best regards, Dylan
Bug#1063660: firmware-nonfree: Please backport newer firmware to Bookworm
Hello, As we now have a new version of firmware-nonfree in deb/testing, is there a backport planned? I'm willing to prepare the package if no one is against it. Best regards, Dylan
Bug#1074340: transition: svt-av1
Le dim. 7 juil. 2024 à 19:15, Sebastian Ramacher a écrit : > > > Please schedule a transition slot for svt-av1. > > > Please go ahead > Thanks, uploaded! Best, Dylan
Bug#461102: ITP: meritous -- action-adventure dungeon crawl game
Package: wpnn Severity: wishlist * Package name: mertious Version : 1.2 Upstream Author : Lancer-X/ASCEAI * URL : http://www.asceai.net/meritous/ * License : GPL (version 3) Programming Lang: C Description : action-adventure dungeon crawl game Far below the surface of the planet is a secret. A place of limitless power. Those that seek to control such a utopia will soon bring an end to themselves. Seeking an end to the troubles that plague him, PSI user MERIT journeys into the hallowed Orcus Dome in search of answers. Mertious is a action-adventure game with simple controls but a challenge to find a balance of power verses recovery time during real-time battles. Set in a fractually-generated world, the player can explore up to 10,000 rooms in search of powerful artifacts, tools to help them, and to eventually free the Orcus Dome from evil. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.21-2-686 (SMP w/1 CPU core) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#457622: context: Importing mps files from latex is broken
On Mon, Dec 24, 2007 at 10:15:27AM +0100, Norbert Preining wrote: Hi Dylan, On So, 23 Dez 2007, Dylan Thurston wrote: With the latest version of context, including Metapost figures in latex (using graphicx) is broken. I've attached minimal test files, and with thoose I get the error log below. I want to upload a fixed version but I cannot test it because I don't know how to activate the mps to pdf converter. ... Sorry, I should have said: I created the test-0.mps file by moving the test.0 file (since latex recognizes the type of file solely by extension). So to recreate the problem from the files I sent, run % mpost test % mv test.0 test-0.mps % latex t Peace, Dylan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489775: libparams-validate-perl: prototype.patch bug: Undefined subroutine Params::Validate::_validate called at /usr/lib/perl5/Params/ValidateXS.pm line 131.
Package: libparams-validate-perl Version: 0.91-1 Severity: grave Justification: renders package unusable Lines 131 and 132 of /usr/lib/perl5/Params/ValidateXS.pm are invalid. They were added in 0.89-3 (UNRELEASED), with a note: NOTE to potential uploaders: please check if debian/patches/prototype.patch is sane and remove it otherwise debian/patches/prototype.patch is most certainly not sane, and it should be removed. Removal of this patch fixes the problem. A more elaborate explaination: pod-coverage complained about the original source lines, which looked like this: *validate = \_validate; *validate_pos = \_validate_pos; So, prototype.patch was created, which makes them read this way: *validate = \_validate([EMAIL PROTECTED]); *validate_pos = \_validate_pos(\@@); Perl interpretes \_validate([EMAIL PROTECTED]) as \ (_validate([EMAIL PROTECTED])), which is: passing @$ as a reference to _validate(), and take a reference to the return value. This causes the program to die, because at the time it is called, there is no _validate() function (it is undefined). -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.25-2-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libparams-validate-perl depends on: ii libc6 2.7-11 GNU C Library: Shared libraries ii perl 5.10.0-10 Larry Wall's Practical Extraction ii perl-base [perlapi-5.10.0]5.10.0-10 The Pathologically Eclectic Rubbis libparams-validate-perl recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#567859: docbook-xsl-ns: Path for import in epub/docbook.xsl points to wrong directory
Package: docbook-xsl-ns Version: 1.75.2+dfsg-4 Severity: normal Tags: patch In usr/share/xml/docbook/stylesheet/docbook-xsl-ns/epub/docbook.xsl, there are three XSL imports. All three point to the docbook-xsl directory not docbook-xsl-ns. When using a DocBook 5 file to make an epub file, it generates a lot of errors and doesn't properly format the file (using fbreader as a test). Changing these to point to docbook-xsl-ns removes the errors and fbreader renders the file properly. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.29-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages docbook-xsl-ns depends on: ii xml-core 0.13 XML infrastructure and XML catalog Versions of packages docbook-xsl-ns recommends: ii docbook-xsl-doc-html [docbook 1.75.2-1 stylesheets for processing DocBook ii docbook5-xml 5.0-2 standard XML documentation system Versions of packages docbook-xsl-ns suggests: ii dbtoepub 0+svn8532-1 DocBook XML to .epub converter pn docbook-xsl-saxon none(no description available) ii fop1:0.95.dfsg-7 XML to PDF Translator ii libsaxon-java 1:6.5.5-6 The Saxon XSLT Processor ii libxalan2-java 2.7.1-5 XSL Transformations (XSLT) process pn xalan none(no description available) -- no debconf information --- docbook.xsl-orig 2010-01-31 14:23:18.0 -0600 +++ docbook.xsl 2010-01-31 14:18:16.0 -0600 @@ -17,9 +17,9 @@ version="1.0"> - - - + + +
Bug#510543: gimp: Newly opened files sometimes appear under old window
On Fri, Jan 02, 2009 at 05:31:40PM -0500, Ari Pollak wrote: severity 510543 minor thanks I'm not sure that anything can be done about this in GIMP, since it's usually up to the window manager to decide where how to place new windows. Should this be reassigned to metacity, then? I haven't observed this behaviour with other applications. --Dylan Thurston -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518800: lamsarrow.sty non-free?
On Tue, Mar 10, 2009 at 12:19:19PM +0100, Norbert Preining wrote: I guess we should remove that lamsarrow.sty. Or the whole package pb-diagram? The latest version of pb-diagram can use xypic instead, so there's no need to remove it. It's also worth checking with the author of lamsarrow. --Dylan Thurston -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656707: xournal: Fonts do not display on Apple Preview
I already have, actually, see here: http://sourceforge.net/tracker/?func=detailaid=3477005group_id=163434atid=827733 On Sat, Jan 21, 2012 at 05:57:18PM -0600, Carlo Segre wrote: Hi Dylan: Thanks, I will pass this upstream. Carlo On Sat, 21 Jan 2012, Dylan Thurston wrote: Package: xournal Version: 0.4.6~pre20110721-1 Severity: normal The PDF files that Xournal produces using 'Export to PDF' do not display properly under Apple Preview on MacOS: the fonts are not visible. PDF files produced by printing to a PDF file work fine. Other PDF viewers seem to work fine, including, eg, Adobe Acrobat on the Mac. I've attached a small test xournal file and PDF files produced in the two different ways. I note that the cairo rendering library had a very similar bug 4 years ago. See, eg, http://lists.freedesktop.org/archives/cairo-bugs/2007-June/001256.html Since xournal has its own font subsetting code, perhaps this bug was inherited from somewhere else. (The bug is doubtless ultimately in Apple Preview, but it seems worth working around.) Workarounds: Use print to pdf rather than the built-in export, or use a different viewer. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (50, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.1.0-1-686-pae (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xournal depends on: ii ghostscript-x 9.04~dfsg-3 ii libatk1.0-0 2.2.0-2 ii libc6 2.13-24 ii libcairo2 1.10.2-6.2 ii libfontconfig1 2.8.0-3 ii libfreetype62.4.8-1 ii libgdk-pixbuf2.0-0 2.24.0-2 ii libglib2.0-02.30.2-5 ii libgnomecanvas2-0 2.30.3-1 ii libgtk2.0-0 2.24.8-3 ii libpango1.0-0 1.29.4-2 ii libpoppler-glib60.16.7-2+b1 ii libx11-62:1.4.4-4 ii zlib1g 1:1.2.3.4.dfsg-3 xournal recommends no packages. xournal suggests no packages. -- no debconf information -- Carlo U. Segre -- Duchossois Leadership Professor of Physics Associate Dean for Graduate Admissions, Graduate College Illinois Institute of Technology Voice: 312.567.3498Fax: 312.567.3494 se...@iit.edu http://phys.iit.edu/~segre se...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741874: cmatrix bug
I get the same error after exiting cmatrix; Cannot find default font and the terminal font is bold after exiting cmatrix. I get the error both with and without cmatrix-xfonts if it matters
Bug#788793: netselect-apt depends on curl but does not list curl as dependency
Package: netselect-apt Version: 0.3.ds1-26 Severity: important Dear Maintainer, I was trying to use netselect-apt on a clean system in order to select the best mirror for my system. However, it would not work. I received an error along the lines of (sorry for the paraphrasing but I do not have the system in question in front of me) No valid servers for protocol . I ran it with debug on (-d) and the issue became apparent: It was trying to test that the servers were usable by using curl! It continued to try to do this no matter what switch I tried. I didn't have curl installed, and the package merely recommends curl, but does not depend on it. As far as I could tell however, there's no way to get it working *without* curl installed. I feel like curl should be listed as a dep, not a rec, unless I'm completely off base and there's a way to get it to go through without curl. Thanks for your attention to this, Dylan J. Morrison -- System Information: Debian Release: 7.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.18.5-x86_64-linode52 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#878276: xfce4-timer-plugin: Hard to click when used on a vertical panel
Package: xfce4-timer-plugin Version: 1.6.0-1+b1 Severity: normal I have my panel in vertical mode, with 2 rows and 20 pixels/row, on the right side of the screen (screenshot attached). The xfce4-timer-plugin is fairly annoying to use in this mode: to successfully start a timer, I need to click very far over to the right of the timer bar, in a very small range of pixels. -- System Information: Debian Release: 9.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-4-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) Versions of packages xfce4-timer-plugin depends on: ii libc6 2.24-11+deb9u1 ii libcairo2 1.14.8-1 ii libgdk-pixbuf2.0-0 2.36.5-2+deb9u1 ii libglib2.0-02.50.3-2 ii libgtk2.0-0 2.24.31-2 ii libxfce4ui-1-0 4.12.1-2 ii libxfce4util7 4.12.1-3 ii xfce4-panel 4.12.1-2 xfce4-timer-plugin recommends no packages. xfce4-timer-plugin suggests no packages. -- no debconf information
