Bug#1082679: freedoom: FTBFS with .dsc from archive: mis-detects that deutex does not support PNG
Am Dienstag, dem 01.10.2024 um 03:26 +0200 schrieb Santiago Vila: > b) The SHELL="bash -Eeuo pipefail" definition in debian/rules. I think I can just remove these lines, upstream did the same some years ago: https://github.com/freedoom/freedoom/commit/77c53e11adfb1e5124e363d68518527c4fcfdf1a Thanks again! - Fabian signature.asc Description: This is a digitally signed message part
Bug#1082679: freedoom: FTBFS with .dsc from archive: mis-detects that deutex does not support PNG
Thank you very much for this update! Am 2024-10-01 03:26, schrieb Santiago Vila: Maybe we could just take for granted that deutex has PNG support, because it has, and drop the check in the toplevel Makefile, Since `deutex-check` isn't declared as a .PHONY rule, I think I can just run `touch deutex-check` before the build and be done with it. - Fabian
Bug#1082679: freedoom: FTBFS with .dsc from archive: mis-detects that deutex does not support PNG
Maybe the `deutex -h` output to stdout get spoiled by other build steps running in parralel, so that it doesn't include "PNG" as an isolated word anymore? - Fabian
Bug#1080073: gstreamer1.0-fdkaac: Please upgrade to gst-plugins-bad1.0_1.24.7
Package: gstreamer1.0-fdkaac Version: 1.20.0-1 Severity: wishlist Hi, this package has fallen a bit behind the gst-plugins-bad1.0 package with which it shares sources. Please upgrade to keep both in sync. Thanks! - Fabian -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.10.6-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gstreamer1.0-fdkaac depends on: ii libc6 2.39-7 ii libfdk-aac2 2.0.2-1 ii libglib2.0-0t64 [libglib2.0-0] 2.81.2-1 ii libgstreamer-plugins-base1.0-0 1.24.7-1 ii libgstreamer1.0-0 1.24.7-1 gstreamer1.0-fdkaac recommends no packages. gstreamer1.0-fdkaac suggests no packages. -- no debconf information
Bug#1065860: fonts-cantarell: Please drop dependencies on python3-distutils
Hi Emmanuel, Am Freitag, dem 12.07.2024 um 17:23 -0300 schrieb Emmanuel Arias: > Please if you have any objection or you want to do any change please > let > me know. no objections, please feel free to upload asap. Thanks, - Fabian signature.asc Description: This is a digitally signed message part
Bug#498048: Not resolved bug #498048 from Sat, 6 Sep 2008 / Chained ogg-flac files don't work
Hello, Am Sonntag, dem 07.07.2024 um 12:38 +0200 schrieb phil995511 -: > I'm a LMS (Logitech Music Server) user on Debian. With this software > solution 30~40 % of web radio dont work because chained ogg-flac > files don't work :-( > > 16 years after its creation, this bug has not been resolved and > continues to cause problems for people who use Debian as a music > server ;-( lack of response for 16 years is most often a sign that the issue has been reported to the wrong address. And indeed, it is nearly impossible for a software distribution such as Debian to coordinate the implementation of a feature that requires patches in multiple upstream sources. It is always best to discuss such issues with the enthusiasts that actually care about these very specific features, such as the community in the slimdevices forums. > The user philippe_44 who is one of the developers of the LMS found > the solution and said he provided it to you a few months ago. I don't know who that collective "you" is, but as you stated yourself, this bug report has seen no activity for the past 16 years and I cannot remember any other mail addressing this specific issue as well. > https://forums.slimdevices.com/forum/user-forums/general-discussion/1686476-problems-playing-web-radios-in-flac?p=1686490#post1686490 > > Would you be so kind as to make this patch available in Debian as > soon as possible, please ? Now that the issue has been reported to FLAC upstream and a fix is provided, it is up to the FLAC upstream maintainers to review the patch and either accept it or request changes. Then, it will eventually end up in the next upstream release and we will package that for Debian. I am not going to add a patch to the Debian package that has not yet been approved by FLAC upstream. > With the agreement of their managers, you could use the Debian > Security Channel to distribute this important update quickly to > Debian users... Absolutely no, no chance! Most impotantly, because this is not a security fix. Quite the contrary, this patch adds a lot of code that hasn't been approved by upstream yet and applying it from the PR would be much more of a new security risk than anything else. > The fact that this problem has remained unresolved for all this time > is certainly pushing people to look for solutions other than Debian > ;-( Well, since the fix hasn't even made it into FLAC upstream yet, I don't see how this is a Debian specific issue in any way. Any other distribution will face the same issue. Sorry I couldn't help, but you will need a bit more patience. :/ Cheers, - Fabian signature.asc Description: This is a digitally signed message part
Bug#1068443: systemd: "systemctl --user ..." results in Connection refused
Am Samstag, dem 06.04.2024 um 11:15 +0200 schrieb Michael Biebl: > Is the problem reproducible after a reboot? > Is the problem reproducible for a freshly created user? Interestingly, today it worked when I wanted to reproduce the issue. I'll report back when it occurs again. Thanks! - Fabian signature.asc Description: This is a digitally signed message part
Bug#1061486: 7zip: Has both Breaks+Replaces and Conflicts against p7zip-full and p7zip
Source: 7zip Version: 23.01+dfsg-7 Severity: normal Hi again, currently, the 7zip package has both a versioned Breaks+Replaces as wellas a versioned Conflicts relationship against the p7zip-full and p7zip packages. In general, if a package conflict can be resolved by installing a specific version of "the other" package, a Breaks+Replaces relationship is sufficient. A Conflicts relationship is meant for two packages which can never get installed at the same time, e.g. because they provide the same service. https://www.debian.org/doc/debian-policy/ch-relationships.html Cheers, - Fabian -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-5-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1061485: 7zip: The 7zip-standalone package isn't standalone
Source: 7zip Version: 23.01+dfsg-7 Severity: normal Hi, currently, the 7zip-standalone package has a hard dependency on the full-featured 7zip package, rendering it quite useless as a "light" standalone package. Please consider either turning it into an actual standalone package without any further dependencies or remove it altogether, if it doesn't provide any more functionality than the 7zip package and depends on it anyway. Thanks, - Fabian -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-5-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1055088: game-data-packager: jazz_jackrabbit_collection information outdated
Package: game-data-packager Version: 77 Severity: normal X-Debbugs-Cc: openj...@packages.debian.org Hi, the packaging information for the jazz_jackrabbit_collection package from GOG.com is outdated. Thre is a new package available for download called 'setup_jazz_jackrabbit_collection_2.0_csv2_(51327).exe' now, and some of the file contents have changed. What is the best way to update g-d-p in this regard? Manually, file by file? Or is there a better way? Cheers, - Fabian -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-3-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages game-data-packager depends on: ii python3 3.11.4-5+b1 ii python3-debian 0.1.49 ii python3-yaml6.0.1-1 Versions of packages game-data-packager recommends: ii game-data-packager-runtime 77 Versions of packages game-data-packager suggests: pn arj ii binutils 2.41-6 pn cabextract pn cdparanoia pn dynamite ii gcc 4:13.2.0-1 pn gdebi | gdebi-kde ii gir1.2-gdkpixbuf-2.0 2.42.10+dfsg-1+b1 ii innoextract 1.9-0.1 pn lgc-pg ii lgogdownloader3.11-2 ii lhasa [lzh-archiver] 0.4.0-1 ii make 4.3-4.1 ii p7zip-full16.02+dfsg-8 ii pkexec123-3 ii python3-gi3.46.0-1 ii python3-omg 0.5.1-1 ii python3-pil 10.0.0-1 pn steam pn steamcmd pn unace-nonfree ii unar 1.10.7+ds1+really1.10.1-2+b3 pn unrar pn unshield ii unzip 6.0-28 pn vorbis-tools ii xdelta1.1.3-10.4 ii xdelta3 3.0.11-dfsg-1.2 pn xorriso -- no debconf information
Bug#983291: Re: Default font: Transition from DejaVu to Noto
> If I recall it correctly, the primary suggestion in that bug report > is to split fonts-noto-core into an LCG and an "other" package. I have created a MR to implement this: https://salsa.debian.org/fonts-team/fonts-noto/-/merge_requests/1 - Fabian signature.asc Description: This is a digitally signed message part
Bug#1051487: python3-reportlab: depends on T1 and TTF fallback fonts at the same time
Package: python3-reportlab Version: 4.0.4-11 Severity: minor Hi, according to the comment added in debian/patches/dejavu-font-default.diff: # the T1 file was not yet found! # fall back to Vera TTF font This reads to me that python-reportlabs tries to find the T1 fonts *first* and then falls back trying to find the TTF fonts only if the former doesn't succeed. However, the package has hard dependencies on both the T1 fonts in fonts-urw-base35, and the TTF fallback fonts in fonts-dejavu-core and fonts-dejavu-extra. I guess it would suffice to let the package depend on "fonts-urw-base35 | fonts-dejavu-core, fonts-urw-base35 | fonts-dejavu-extra" to make sure that either the T1 fonts or *both* TTF fallback fonts packages are installed. Thanks! Cheers, - Fabian -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.4.0-3-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-reportlab depends on: ii fonts-dejavu-core 2.37-8 ii fonts-dejavu-extra 2.37-8 ii fonts-urw-base3520200910-7 ii python3 3.11.4-5+b1 ii python3-freetype2.4.0-1 ii python3-pil 10.0.0-1 ii python3-rlpycairo 0.3.0-2 python3-reportlab recommends no packages. Versions of packages python3-reportlab suggests: ii evince [pdf-viewer] 45~alpha-2 pn python-reportlab-doc pn python3-egenix-mxtexttools -- no debconf information
Bug#1050218: python3-reportlab: please do not depend on ttf-bitstream-vera
Package: python3-reportlab Version: 4.0.4-9 Severity: normal Hi, currently python3-reportlab is the only package on my system which pulls in the deprecated ttf-bitstream-vera font, which has long been obsoleted by fonts-dejavu. Please change to *any* other font or at least offer a choice of alternative fonts, but I really don't want ttf-bitstream-vera on my system. Thanks! Cheers, - Fabian -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.4.0-1-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-reportlab depends on: ii fonts-urw-base3520200910-7 ii python3 3.11.4-5+b1 ii python3-freetype2.4.0-1 ii python3-pil 10.0.0-1 ii python3-rlpycairo 0.3.0-2 ii ttf-bitstream-vera 1.10-8.2 python3-reportlab recommends no packages. Versions of packages python3-reportlab suggests: ii evince [pdf-viewer] 45~alpha-2 pn python-reportlab-doc pn python3-egenix-mxtexttools -- no debconf information
Bug#1050000: installation-reports: please install libpam-fprintd on a laptop with fingerprint reader
Package: installation-reports Severity: wishlist Boot method: USB Image version: https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/debian-testing-amd64-netinst.iso Date: 20230808 Machine: Lenovo IdeaPad 5 14IAL7 Partitions: Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect media: [O] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments/Problems: Hi, I don't have a bug to report, installation went smooth this time! Just a suggestion to make: My laptop has a built-in fingerprint reader (relevant output of lsusb below). However, after installation it is still impossible to register a fingerprint on the user setup page of the gnome-settings app. This possibility is only added after the libpam-fprintd package is installed. Thus, my suggestion is that if a fingerprint reader is detected during the hardware detection phase during the Debian installation to install the libpam-fprintd package. Thanks! - Fabian Bus 003 Device 003: ID 04f3:0c4d Elan Microelectronics Corp. ELAN:Fingerprint -- Package-specific info: == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="13 (trixie) - installer build 20230808-00:02:33" X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux brainbug 6.4.0-1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.4.4-2 (2023-07-30) x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Device [8086:4601] (rev 04) lspci -knn: Subsystem: Lenovo Device [17aa:382b] lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation Alder Lake-UP3 GT2 [Iris Xe Graphics] [8086:46a8] (rev 0c) lspci -knn: Subsystem: Lenovo Device [17aa:382f] lspci -knn: 00:04.0 Signal processing controller [1180]: Intel Corporation Alder Lake Innovation Platform Framework Processor Participant [8086:461d] (rev 04) lspci -knn: Subsystem: Lenovo Device [17aa:3832] lspci -knn: 00:06.0 PCI bridge [0604]: Intel Corporation 12th Gen Core Processor PCI Express x4 Controller #0 [8086:464d] (rev 04) lspci -knn: Subsystem: COMPAL Electronics Inc Device [14c0:013d] lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:08.0 System peripheral [0880]: Intel Corporation 12th Gen Core Processor Gaussian & Neural Accelerator [8086:464f] (rev 04) lspci -knn: Subsystem: Lenovo Device [17aa:3838] lspci -knn: 00:0d.0 USB controller [0c03]: Intel Corporation Alder Lake-P Thunderbolt 4 USB Controller [8086:461e] (rev 04) lspci -knn: Subsystem: Intel Corporation Device [8086:7270] lspci -knn: Kernel driver in use: xhci_hcd lspci -knn: Kernel modules: xhci_pci lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation Alder Lake PCH USB 3.2 xHCI Host Controller [8086:51ed] (rev 01) lspci -knn: Subsystem: Lenovo Device [17aa:3825] lspci -knn: Kernel driver in use: xhci_hcd lspci -knn: Kernel modules: xhci_pci lspci -knn: 00:14.2 RAM memory [0500]: Intel Corporation Alder Lake PCH Shared SRAM [8086:51ef] (rev 01) lspci -knn: Subsystem: Lenovo Device [17aa:3823] lspci -knn: 00:15.0 Serial bus controller [0c80]: Intel Corporation Alder Lake PCH Serial IO I2C Controller #0 [8086:51e8] (rev 01) lspci -knn: Subsystem: Lenovo Device [17aa:3814] lspci -knn: Kernel driver in use: intel-lpss lspci -knn: Kernel modules: intel_lpss_pci lspci -knn: 00:15.3 Serial bus controller [0c80]: Intel Corporation Alder Lake PCH Serial IO I2C Controller #3 [8086:51eb] (rev 01) lspci -knn: Subsystem: Lenovo Device [17aa:3821] lspci -knn: Kernel driver in use: intel-lpss lspci -knn: Kernel modules: intel_lpss_pci lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation Alder Lake PCH HECI Controller [8086:51e0] (rev 01) lspci -knn: Subsystem: Lenovo Device [17aa:382d] lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:51ba] (rev 01) lspci -knn: Subsystem: Lenovo Device [17aa:3809] lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:1d.0 PCI bridge [0604]: Intel Corporation Alder Lake PCI Express x1 Root Port #10 [8086:51b1] (rev 01) lspci -knn: Subsystem: Lenovo Device [17aa:380d] lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:1e.0 Communication controller [0780]: Intel Corporation Alder Lake PCH UART #0 [8086:51a8] (rev 01) lspci -knn: Subsystem: Lenovo Device [17aa:3818] lspci -knn: Kernel driver in use: intel-lpss lspci -knn:
Bug#1041264: fonts-recommended: depends on removed fonts-liberation2
Why the severity? The fonts-liberation2 package is now a transitional package which pulls in the actual fonts-liberation package. Von meinem/meiner Galaxy gesendet
Bug#1041264: fonts-recommended: depends on removed fonts-liberation2
Why the severity? The fonts-liberation2 package is now a transitional package which pulls in the actual fonts-liberation package. Von meinem/meiner Galaxy gesendet
Bug#1041242: libheif1: 1.16.2-1+b1 breaks displaying any pictures
Do you have the heif-gdk-pixbuf package installed? Von meinem/meiner Galaxy gesendet
Bug#1039955: fonts-liberation should provide /usr/share/fonts/truetype/liberation2 for backwards compatibility
Hi Nilesh, Am Freitag, dem 30.06.2023 um 08:53 +0530 schrieb Nilesh Patra: > Could you consider to vendor truetype/liberation2 as a symlink to > truetype/liberation? sure, I could do that. But then we'd end up again with two entries in the file system for the same (in this case even identical) font. Getting rid of this was the main incentive for this transition in the first place. I don't expect many packages to depend on the precise location of the font files in the file system at all, we have fontconfig for this. The actual transition from fonts-liberation2 to fonts-liberation (>= 1:2) will be short and painless: You literally only have to change one char in the path names. In other words, I am reluctant to add additional complexity to the transitional dummy package to ease a transition that's as complex as changing a single char in a path name for depending packages. I hope you understand. Cheers, - Fabian signature.asc Description: This is a digitally signed message part
Bug#1039568: RM: zsnes -- ROM; i386-only, abandoned upstream, alternatives exist
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove Hi, as outlined by smcv in #1039564: zsnes is i386-only due to its use of i386 assembly language, and this seems unlikely to change any time soon. Alternatives available for multiple CPUs include: - ares - higan - mednafen - any libretro frontend (for example retroarch) with one of: - libretro-bsnes-mercury family - libretro-snes9x (non-free) Upstram development has ceased in 2007, the last Debian maintainer upload was in 2014 and there are more viable alternatives available. Thanks! - Fabian
Bug#1038940: RM: fonts-liberation2 -- ROM; obsoleted by fonts-liberation (>= 1:2.1.5-2~)
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: fonts-liberati...@packages.debian.org Control: affects -1 + src:fonts-liberation2 Hi, as announced on debian-devel [1], Liberation fonts v1 have been abandoned upstream and Liberation fonts v2 are the only maintained version - along with the Liberation Sans Narrow font which has been extracted out of the v1 releases. It does thus not make sense anymore to have the v1 fonts packaged separately n Debian and let them block the "fonts-liberation" package name, with the prefered version of the fonts moved out into the "fonts-liberation2" package. With the latest upload, I have thus let the v2 font take over the src:fonts-liberation package name, providing both fonts-liberation and fonts-liberation2 binary packages, the latter being a transitional dummy package depending on the further. So, so src:fonts-liberation2 package is now obsolete and should get removed from Debian unstable (and testing). Thank you! Cheers, - Fabian [1] https://lists.debian.org/debian-devel/2023/06/msg00220.html
Bug#1003010: fonts-liberation2: please Provides fonts-liberation
Hi there, sorry for the late reply! Am Sonntag, dem 02.01.2022 um 20:44 +0200 schrieb Martin-Éric Racine: > It would be desirable for fonts-liberation2 to Provides fonts- > liberation so as to avoid installing two versions of essentially the > same font. First, strictly speaking fonts-liberation and fonts-liberation2 aren't only two versions of the same font, but in fact tw different fonts. Apart from the fact that both get installed into two different locations in the file system (obviously), the v1 package contains one more font family than the v2 package, i.e. Sans Narrow. Second, what causes the situation that both fonts are installed at the same time? Is it package dependencies and if yes, which packages cause this? Because, well apart from Sans Narrow, there is no technical reason to have both versions installed at the same time. Cheers, - Fabian signature.asc Description: This is a digitally signed message part
Bug#448105: mplayer: Illegal Instruction in init_audio_codec
Hi Reimar,I remember that back then, when powerpc was still a release architecture in Debian, we built two flavors of the ffmpeg libraries -- one with altivec and one without:https://salsa.debian.org/multimedia-team/ffmpeg/-/blob/debian/master/debian/rules#L184That code is still there, so I wonder why your linker doesn't pick up the flavor that matches your processor's instruction set.Cheers, - Fabian Von meinem/meiner Galaxy gesendet Ursprüngliche Nachricht Von: Reimar Döffinger Datum: 06.06.23 20:24 (GMT+01:00) An: Lorenzo , 448...@bugs.debian.org Betreff: Bug#448105: mplayer: Illegal Instruction in init_audio_codec > On 6 Jun 2023, at 15:17, Reimar Döffinger wrote:> >> Disable altivec for everyone doesn't seem a good compromise to me, I'm>> going to build twice on powerpc and let the user decide which one to use> > To be clear: as MPlayer has no hand-written altivec, I I expect only a maybe 5-10% or so degradation (pure guess), the most performance critical stuff in FFmpeg should not be affected.So, funny thing. I installed debian-ppc on qemu g3 emulated system.What did I find out:- xfce4 crashes with illegal instruction- ffmpeg does not crash, but only because it is built with --disable-altivec which makes it basically unusably slow on e.g. G4 systems.So there is no winning.So for practical purposes, you can just as well compile MPlayer with --disable-altivec, since FFmpeg is compiled this way the speed of MPlayer won't make a relevant difference.On the details what goes on here (skip if you do not like rants):What is the source of all these issues? gccIn the past, -maltivec was used to just enable support for altivec intrinsics.However gcc then changed and generated Altivec instructions even from plain C code.While that makes sense in a way, it meant code everywhere broke on non-altivec systems.This includes FFmpeg.For packages important enough/depending on maintainer, the "solution" was to disable altivec completely, making these programs vastly slower on Altivec enabled computers.Others like xfce4 and MPlayer only work on PPC systems with Altivec.Without extensive code and build system changes, this seems now an unsolvable situation.Unless someone adds an option like -faltivec that Apple had, which allows the intrinsics but not compiler generation of altivec instructions (I think gcc maintainers at one point said they could not do that).clang has both -faltivec and -maltivec, but neither are properly documented, so who knows if they would help here or not.Either way, without someone EXTREMELY motivated, this seems not solvable (switching to clang with -faltivec if it were to work just MIGHT have a chance).I guess it's a lesson in not buying into architectures where the creators don't have their shit together enough to get even the basics right - and upstreamed... (I guess it's mostly solved by PPC being as good as dead now).(don't get me wrong, I still sometimes boot my old MacMini with G4 and update to latest Debian, but I think the ISA is just dead at this point, unfortunately).Sorry for the long rant,Reimar
Bug#1035824: installation-reports: unable to detect Realtek RTL8188EUS 802.11n USB WiFi adapter
Package: installation-reports Severity: normal Boot method: USB Image version: debian-bookworm-DI-rc2-amd64-netinst.iso (downloaded 2023-05-05) Machine: Lenovo IdeaPad 5 Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[E] Configure network: [ ] Detect media: [ ] Load installer modules: [ ] Clock/timezone setup: [ ] User/password setup:[ ] Detect hard drives: [ ] Partition hard drives: [ ] Install base system:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[E] Comments/Problems: Sadly, another failed attempt to install Debian on my brand-new Lenovo IdeaPad 5, this time using a USB dongle equiped with the Realtek RTL8188EUS chip set. The installer failed to detect the network adapter and presented me with a list of kernel modules, none of which got my device to work. This is what dmesg reports after I plug the adapter into a USB port on my current device, which is obviously not the same one as the report applies to (which is why I removed all of the appended logs): [42871.476218] usb 1-4: new high-speed USB device number 19 using xhci_hcd [42871.624725] usb 1-4: New USB device found, idVendor=0bda, idProduct=8179, bcdDevice= 0.00 [42871.624729] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [42871.624731] usb 1-4: Product: 802.11n NIC [42871.624732] usb 1-4: Manufacturer: Realtek [42871.624733] usb 1-4: SerialNumber: 00E04C0001 [42871.936975] r8188eu: module is from the staging directory, the quality is unknown, you have been warned. [42871.970033] usbcore: registered new interface driver r8188eu [42872.005633] r8188eu 1-4:1.0 wlx482254c71aaf: renamed from wlan0 [42872.597812] r8188eu 1-4:1.0: firmware: direct-loading firmware rtlwifi/rtl8188eufw.bin [42872.597825] r8188eu 1-4:1.0: Firmware Version 11, SubVersion 1, Signature 0x88e1 [42881.731472] r8188eu 1-4:1.0: firmware: direct-loading firmware rtlwifi/rtl8188eufw.bin Interstingly, calling dmesg on the system where the installation attempt failed, the line starting with 42871.936975,i.e. where the actual kernel module is loaded, and all following ones are omitted. Hope this helps! Cheers, - Fabian
Bug#1035569: installation-reports: failed to detect Realtek RTL8852BE WiFi 6 802.11ax PCIe adapter
Package: installation-reports Severity: normal Boot method: USB Image version: debian-bookworm-DI-rc2-amd64-netinst.iso from 2023-05-05 Date: 2023-05-05 12:00 Machine: Lenovo IdeaPad 5 14IAL7 Partitions: Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[E] Configure network: [ ] Detect media: [ ] Load installer modules: [ ] Clock/timezone setup: [ ] User/password setup:[ ] Detect hard drives: [ ] Partition hard drives: [ ] Install base system:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[E] Comments/Problems: Thi shappened on a different machine than the one I write this report from (obviously, thus removed the logs below). Today I attempted to install Debian bookworm on a brand new Lenovo IdeaPad 5 14IAL7 with an i5-1235U CPU, 16GB RAM and 512GB SDD. The installation failed to proceed at the network card detection stage. Apparently, the machine has a Realtek RTL8852BE adapter, which *should* be supported by recent kernels. However, the installer presented me with a list of kernel modules to choose from. I went through the list and selected anything that even remotely matched the adapter name, but without success. Since I only had downloaded the netinst image, I had to quit the installation proess at this point. Cheers, - Fabian
Bug#1034555: unblock: fluidsynth/2.3.1-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: fluidsy...@packages.debian.org, fluidsy...@packages.debian.org
Control: affects -1 + src:fluidsynth
Please unblock package fluidsynth
[ Reason ]
This revision fixes a regression that was introduced upstream between
the 2.3.0 and 2.3.1 releases and has been fixed in the 2.3.2 release.
[ Impact ]
The regression introduced a multi-second gap between looping MIDI
tracks. Since fluidsynth is the default renderer for MIDI music in
SDL2, this will affect *a lot* of games in Debian.
[ Tests ]
n/a
[ Risks ]
None, I'd say. The fix has been backported from the upstream GIT
repository and is in the 2.3.2 version, which has already been
released. The output of `git show -w c0e2ef` on the commit in question
has three lines of code changes, the rest is indentation:
--- a/src/midi/fluid_midi.c
+++ b/src/midi/fluid_midi.c
@@ -2179,6 +2179,8 @@ fluid_player_callback(void *data, unsigned int msec)
fluid_atomic_int_set(&player->seek_ticks, -1); /* clear seek_ticks
*/
}
+if(fluid_list_next(player->currentfile) == NULL && player->loop == 0)
+{
/* Once we've run out of MIDI events, keep playing until no voices
are active */
if(status == FLUID_PLAYER_DONE &&
fluid_synth_get_active_voice_count(player->synth) > 0)
{
@@ -2207,6 +2209,7 @@ fluid_player_callback(void *data, unsigned int msec)
{
status = FLUID_PLAYER_PLAYING;
}
+}
/* Once there's no reason to keep playing, we're actually done */
if(status == FLUID_PLAYER_DONE)
[ Checklist ]
[X] all changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in testing
[ Other info ]
n/a
unblock fluidsynth/2.3.1-2
diff -Nru fluidsynth-2.3.1/debian/changelog fluidsynth-2.3.1/debian/changelog
--- fluidsynth-2.3.1/debian/changelog 2022-12-30 16:10:11.0 +0100
+++ fluidsynth-2.3.1/debian/changelog 2023-04-18 07:48:30.0 +0200
@@ -1,3 +1,11 @@
+fluidsynth (2.3.1-2) unstable; urgency=medium
+
+ * Team upload.
+ * Apply patch from upstream to fix seamless looping between MIDI
+files.
+
+ -- Fabian Greffrath Tue, 18 Apr 2023 07:48:30 +0200
+
fluidsynth (2.3.1-1) unstable; urgency=medium
* New upstream version 2.3.1
diff -Nru
fluidsynth-2.3.1/debian/patches/0046-Fix-seamless-looping-between-MIDI-files.patch
fluidsynth-2.3.1/debian/patches/0046-Fix-seamless-looping-between-MIDI-files.patch
---
fluidsynth-2.3.1/debian/patches/0046-Fix-seamless-looping-between-MIDI-files.patch
1970-01-01 01:00:00.0 +0100
+++
fluidsynth-2.3.1/debian/patches/0046-Fix-seamless-looping-between-MIDI-files.patch
2023-04-18 07:47:25.0 +0200
@@ -0,0 +1,76 @@
+From c0e2ef4243b83f29620b2078fc0f1198bafd7d90 Mon Sep 17 00:00:00 2001
+From: derselbst
+Date: Sun, 2 Apr 2023 17:31:24 +0200
+Subject: [PATCH 46/49] Fix seamless looping between MIDI files
+
+Fixes #1227
+---
+ src/midi/fluid_midi.c | 45 +++
+ 1 file changed, 24 insertions(+), 21 deletions(-)
+
+diff --git a/src/midi/fluid_midi.c b/src/midi/fluid_midi.c
+index 0676c452..b72c3914 100644
+--- a/src/midi/fluid_midi.c
b/src/midi/fluid_midi.c
+@@ -2178,34 +2178,37 @@ fluid_player_callback(void *data, unsigned int msec)
+ player->start_msec = msec; /* should be the (synth)-time of
the last tempo change */
+ fluid_atomic_int_set(&player->seek_ticks, -1); /* clear
seek_ticks */
+ }
+-
+-/* Once we've run out of MIDI events, keep playing until no voices
are active */
+-if(status == FLUID_PLAYER_DONE &&
fluid_synth_get_active_voice_count(player->synth) > 0)
++
++if(fluid_list_next(player->currentfile) == NULL && player->loop == 0)
+ {
+-/* The first time we notice we've run out of MIDI events but
there are still active voices, disable all hold pedals */
+-if(!player->end_pedals_disabled)
++/* Once we've run out of MIDI events, keep playing until no
voices are active */
++if(status == FLUID_PLAYER_DONE &&
fluid_synth_get_active_voice_count(player->synth) > 0)
+ {
+-for(i = 0; i < synth->midi_channels; i++)
++/* The first time we notice we've run out of MIDI events but
there are still active voices, disable all hold pedals */
++if(!player->end_pedals_disabled)
+ {
+-fluid_synth_cc(player->synth, i, SUSTAIN_SWITCH, 0);
+-fluid_synth_cc(player->synth, i, SOSTENUTO_SWITCH, 0);
++
Bug#1034050: fonts-creep2: generated font is TrueType, not OpenType
Am Freitag, dem 07.04.2023 um 15:14 +0100 schrieb nwil...@glyphography.com: > based on the outline format contained within (quadratic vs cubic > Beziers), then filename extension alone is not adequate. > > Similarly, if the intent is to make some sort of distinction based on > the contents of the tables (e.g., GSUB and GPOS), then the filename > extension still isn't adequate, because .ttf files can and do include > those tables (see Noto and many many others). I'd say we make the distinction by container format. Though, I agree that this distinction is still pretty arbitrary. - Fabian signature.asc Description: This is a digitally signed message part
Bug#1034020: openal-soft: please upgrade to 1.23
Source: openal-soft Version: 1:1.19.1-2 Severity: wishlist Hi there, please upgrade the openal-soft package to upstream version 1.23! The 1.19.1 release which is currently in Debian exhibits some serious clicking when sounds are played repeatedly in Doom source ports and reportedly these clinks are fixed in newer versions (at least 1.21.1): https://github.com/fabiangreffrath/woof/pull/973#issuecomment-1499154366 Also, you may want to upgrade the Homepage field in debian/control and the debian/watch file to point to the new upstream location at https://github.com/kcat/openal-soft Thanks! Cheers, - Fabian -- System Information: Debian Release: 12.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-security'), (500, 'experimental'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-7-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#1032935: unblock: fonts-dejavu/2.37-6
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: fonts-dej...@packages.debian.org
Control: affects -1 + src:fonts-dejavu
Please unblock package fonts-dejavu.
The upstream Makefle touches all generated TTF font files with the time
stamp of the corresponding SFD source file, so time stamps are never
updated between package revisions from the same sources.
The -6 package revision touches all generated TTF font files with
$SOURCE_DATE_EPOCH, so the time stamps are updated whenever the package
revision is updated.
This fixes bug #1032599.
Please find the debdiff attached.
Thanks!
- Fabian
diff -Nru fonts-dejavu-2.37/debian/changelog fonts-dejavu-2.37/debian/changelog
--- fonts-dejavu-2.37/debian/changelog 2023-02-26 07:54:14.0 +0100
+++ fonts-dejavu-2.37/debian/changelog 2023-03-10 09:35:35.0 +0100
@@ -1,3 +1,10 @@
+fonts-dejavu (2.37-6) unstable; urgency=medium
+
+ * Touch all generated TTF files with SOURCE_DATE_EPOCH time,
+Closes: #1032599.
+
+ -- Fabian Greffrath Fri, 10 Mar 2023 09:35:35 +0100
+
fonts-dejavu (2.37-5) unstable; urgency=medium
[ Paul Menzel ]
diff -Nru fonts-dejavu-2.37/debian/rules fonts-dejavu-2.37/debian/rules
--- fonts-dejavu-2.37/debian/rules 2023-02-07 08:26:34.0 +0100
+++ fonts-dejavu-2.37/debian/rules 2023-03-10 09:33:34.0 +0100
@@ -1,11 +1,14 @@
#!/usr/bin/make -f
+include /usr/share/dpkg/pkg-info.mk
+
%:
dh $@
-
+
override_dh_auto_build:
make full-ttf
sh debian/scripts/generate-udeb.sh
+ touch --no-create --date="$(shell date --utc --date=@${SOURCE_DATE_EPOCH} --iso-8601=seconds)" build/*.ttf
override_dh_auto_clean:
$(RM) -rf tmp/ build/ udeb-generated/ udeb-build/
signature.asc
Description: This is a digitally signed message part
Bug#1031005: gst-play-1.0: video hangs after seeking, app is responsive
Package: gstreamer1.0-plugins-base-apps Version: 1.22.0-3 Severity: normal Hi there, I have a couple of videos here, mostly in MP4 v2 format [1], that gstreamer-based players have some problems with. In this specific case, playing a video with gst-play-1.0 and seeking through the video ultimately leads to the video stream hanging, i.e. still frame without sound. The app is still responsive, though, so that I can still seek from one audioless still frame to the next (or previous), but not much more. In order to reproduce, open a video file and press right/left arrow keys in quick succession. Sometimes it takes some more approaches, some other times the video freezes after a simple e.g. right/right/right/left sequence. The same happens in Totem, btw, which is where I found the bug. However, I wanted to check if it's a bug in the Totem app or in gstramer itself and thus reproduced it with the most basic gstreamer-based player I could imagine. I am still not sure if this is the right package to assign this bug to. Cheers, - Fabian [1] $ file ~/Videos/* | cut -d ':' -f 2 | sed 's/^\s*//g' | sort -u ISO Media, Apple iTunes Video (.M4V) Video ISO Media, MP4 Base Media v1 [ISO 14496-12 ISO Media, MP4 v2 [ISO 14496-14] Matroska data -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'experimental'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages gstreamer1.0-plugins-base-apps depends on: ii gstreamer1.0-tools 1.22.0-2 ii libc6 2.36-8 ii libglib2.0-02.74.5-1 ii libgstreamer-plugins-base1.0-0 1.22.0-3 ii libgstreamer1.0-0 1.22.0-2 gstreamer1.0-plugins-base-apps recommends no packages. gstreamer1.0-plugins-base-apps suggests no packages. -- no debconf information
Bug#1030155: adding webfonts (woff/woff2)
Hi Daniel, Am Dienstag, dem 31.01.2023 um 18:23 +0100 schrieb Daniel Baumann: > patch attached. sorry, but your patch doesn't apply in debian/control. Could you probably file a MR in the GIT repo instead? Thanks! - Fabian signature.asc Description: This is a digitally signed message part
Bug#902981: Font Awesome v5 in Debian
Hi Julian,this is highly appreciated, thanks for all the effort you put into this!I'd recommend to avoid the "awesome" part of the name altogether. Font Awesome upstream apparently changed his mind and had become rather hostile towards open development, so we shouldn't give them more reason to feel under attack. How about "font-dfsgsome" or "font-handsome" or whatever wordplay you like? - Fabian Von meinem/meiner Galaxy gesendet Ursprüngliche Nachricht Von: Julian Gilbey Datum: 29.01.23 13:21 (GMT+01:00) An: Jonas Smedegaard Cc: 902...@bugs.debian.org, Bastian Germann Betreff: Bug#902981: Font Awesome v5 in Debian On Sun, Jan 29, 2023 at 12:21:29PM +0100, Jonas Smedegaard wrote:> Quoting Julian Gilbey (2023-01-29 12:03:30)> > If you would like me to go ahead and work on this, please say.> > Sure I would like you to go ahead - why would I not want that?> > Sounds like a fun project, and Free, and beneficial to Debian.Great!> One thing you might consider is to name the resulting package something> (similar but) different than fontawesome, to not upset upstream> developers by hijacking their name for something arguably different.A good point. I was thinking of creating a GitHub project calledFontAwesome-DFSG, with a README explaining what is it, how it wascreated and how it is not endorsed by the FontAwesome "owners". ButI'm not sure what to call the Debian package - it is essentially justa repackaging of the FontAwesome fonts. Perhaps we could call thesource package fonts-font-awesome-dfsg, and the binary packagesfonts-font-awesome-4.7, fonts-font-awesome-dfsg-5,fonts-font-awesome-dfsg-6 and fonts-font-awesome-dfsg (for the currentversion of the upstream font)?I'm open to ideas!Best wishes, Julian
Bug#1028459: [Pkg-fonts-devel] Bug#1028459: not metric-compatible anymore
Am Samstag, dem 21.01.2023 um 18:55 +0100 schrieb Rene Engelhard: > This upgrade, which now unfortunately already is in testing makes the > font NOT metric-compatible with Cambria... Ouch, that's unfortunate! Do we know which glyphs are affected so that they can probably get patch back to metric compatiblilty? - Fabian signature.asc Description: This is a digitally signed message part
Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing"
Hi Roland, thank you very much for the effort you put into this issue! Am Freitag, dem 20.01.2023 um 23:03 +0100 schrieb Roland Rosenfeld: > So we should think about "repairing" these files and make them real > .pfb files with segment headers. Only problem is, that t1binary We must not forget the primary purpose of these fonts, and that is to serve as the 35 base fonts for ghostscript! Thus, I consider it out of question to modify the original T1 fonts in this package. What we may discuss about is to replace the "compatibility symlinks" in /usr/share/fonts/X11/Type1 with actual converted PFB files. > doesn't handle C059-Italic.t1 correctly but generates a completely > broken font file. Does it work if you first convert to PFA format and from there to PFB format? - Fabian signature.asc Description: This is a digitally signed message part
Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing"
Hi, Am Donnerstag, dem 19.01.2023 um 13:57 -0500 schrieb Jorge Moraleda: > Fabian mentioned that "upstream has decided to rename the binary font > files and in that course change the file extensions from .pfb to > .t1." but from the above experiment it seems that upstream changed > the actual file format, and then they changed the file extensions to > match the new format. to be honest, I wasn't even aware of the format change until yesterday. > IMHO opinion, the solution would be to either not create the symbolic > links or to preserve the original names including the extension. I > don't know enough to know what is best. The symlinks were introduced to facilitate the transition from the gsfonts package, which had its fonts installed in these directories with these exact file names. Maybe it makes sense to remove them again immediately after the next Debian stable release to prevent subtle bugs like this. @roland what do you think? - Fabian signature.asc Description: This is a digitally signed message part
Bug#983291: [Pkg-fonts-devel] Bug#983291: fonts-noto-core: Excessive fonts bundles in fonts-noto-core make desired font selection painful
Am Donnerstag, dem 19.01.2023 um 13:12 +0100 schrieb Jonas Smedegaard: > The very purpose of Noto is to cover many scripts. > If you need latin-cyrillic-greek coverage, pick another o the many > fonts covering that smaller scope. Sure, I was expecting a stubborn reply... However, you contradict yourself here: On Mon, 22 Feb 2021 01:19:02 +0100 Jonas Smedegaard wrote: > I agree that it makes sense to split the Noto fonts into more packages. On Thu, 25 Feb 2021 05:56:11 +0100 Jonas Smedegaard wrote: > What I will do instead is generally split more fine-grained - for all > all users globally to be able to mix and match. - Fabian signature.asc Description: This is a digitally signed message part
Bug#1025267: Nimbus Roman: wrong glyph for ₤ (U+20A4 LIRA SIGN)
control: forwarded -1 https://github.com/ArtifexSoftware/urw-base35-fonts/issues/38 signature.asc Description: This is a digitally signed message part
Bug#1013213: gftools: version outdated, blocking build of cascadia code
On Sun, 17 Jul 2022 15:38:56 +0200 Agathe Porte wrote: > python-gflanguages has been uploaded to NEW. > > Now ITP glyphsets [1] is blocking this upgrade Now both python-gflanguages and python-glyphsets have fond their way into Debian. - Fabian signature.asc Description: This is a digitally signed message part
Bug#1006932: AW: RFC: fontconfig 2.14.1-1 experimental branch on salsa.debian.org
Hi Andreas, thank you for working on this! I think an upload of your current branch to experimental would be reasonable at this point. - Fabian This e-mail is sent on behalf of Doncasters Group. Its contents are confidential to the recipient and may be legally privileged, subject to export controls regulations and may also contain personal information, which is subject to applicable data protection laws. If you are not the intended recipient: (1) you must not disclose, copy or distribute its contents to any other person nor use its contents in any way; (2) please contact Doncasters Group on +44 (0) 1332 694143 (IT administration) quoting the name and sender and the addressee then permanently delete it from your system. Any personal information communicated by email is subject to the provisions of the Doncasters Group Data Protection Policy and relevant Privacy Notice (as amended from time to time) – a copy of which is available upon request. For general enquiries please contact +44 (0) 1332 864900. Doncasters Group has scanned this e-mail for viruses but does not accept any responsibility for viruses once this e-mail has been transmitted. You should scan attachments (if any) for viruses. Doncasters Precision Castings - Bochum GmbH Bessemerstrasse 82, D-44793, Bochum, Germany Telefon (02 34) 6 22-1, Telefax (02 34) 6 22-335 Geschaeftsfuehrung: Michael Joseph Quinn Sitz der Gesellschaft: Bochum Registergericht: Bochum HR B 5748, UST-IdNr.: DE811150153
Bug#1026791: ITP: dsda-doom -- Doom source port with a focus on demo recording and speedrunning
Package: wnpp Severity: wishlist Owner: Fabian Greffrath X-Debbugs-Cc: debian-de...@lists.debian.org, pkg-games-de...@lists.alioth.debian.org * Package name: dsda-doom Version : 0.25 Upstream Contact: Ryan Krafnick <https://github.com/kraflab> * URL : https://github.com/kraflab/dsda-doom * License : GPL-2 Programming Lang: C Description : Doom source port with a focus on demo recording and speedrunning This is a fork of prboom+ with extra tooling for demo recording and playback, with a focus on speedrunning. As announced earlier [1], I'd like to replace the prboom-plus Doom engine in Debian with its more actively developed fork dsda-doom. While developement of the former has mostly stagnated, the latter pioneered with new features like the introduction of the MBF21 modding standard and DSDehacked (aka unlimited everything). Apart from that, it also keeps demo compatibility as its highest goal, has added support for Heretic and Hexen and has the vibrant DSDA speedrunning community behind it. [1] https://lists.debian.org/debian-devel/2021/08/msg00412.html
Bug#1014545: AW: Bug#1014545: Info received (Update fontconfig to 2.14.1)
> The reason why the Debian/watch file for the Debian package doesn't catch > this is that it searches for release tarballs with ".bz2" extension, whereas > upstream has switched to ".xz" compression since the 2.13.91 release. https://salsa.debian.org/freedesktop-team/fontconfig/-/merge_requests/9 This e-mail is sent on behalf of Doncasters Group. Its contents are confidential to the recipient and may be legally privileged, subject to export controls regulations and may also contain personal information, which is subject to applicable data protection laws. If you are not the intended recipient: (1) you must not disclose, copy or distribute its contents to any other person nor use its contents in any way; (2) please contact Doncasters Group on +44 (0) 1332 694143 (IT administration) quoting the name and sender and the addressee then permanently delete it from your system. Any personal information communicated by email is subject to the provisions of the Doncasters Group Data Protection Policy and relevant Privacy Notice (as amended from time to time) – a copy of which is available upon request. For general enquiries please contact +44 (0) 1332 864900. Doncasters Group has scanned this e-mail for viruses but does not accept any responsibility for viruses once this e-mail has been transmitted. You should scan attachments (if any) for viruses. Doncasters Precision Castings - Bochum GmbH Bessemerstrasse 82, D-44793, Bochum, Germany Telefon (02 34) 6 22-1, Telefax (02 34) 6 22-335 Geschaeftsfuehrung: Michael Joseph Quinn Sitz der Gesellschaft: Bochum Registergericht: Bochum HR B 5748, UST-IdNr.: DE811150153
Bug#1014545: Update fontconfig to 2.14.1
Control: retitle -1 please update fontconfig to 2.14.1 Indeed, upstream has already released fontconfig 2.14.1 in October 2022. The reason why the Debian/watch file for the Debian package doesn't catch this is that it searches for release tarballs with ".bz2" extension, whereas upstream has switched to ".xz" compression since the 2.13.91 release. - Fabian This e-mail is sent on behalf of Doncasters Group. Its contents are confidential to the recipient and may be legally privileged, subject to export controls regulations and may also contain personal information, which is subject to applicable data protection laws. If you are not the intended recipient: (1) you must not disclose, copy or distribute its contents to any other person nor use its contents in any way; (2) please contact Doncasters Group on +44 (0) 1332 694143 (IT administration) quoting the name and sender and the addressee then permanently delete it from your system. Any personal information communicated by email is subject to the provisions of the Doncasters Group Data Protection Policy and relevant Privacy Notice (as amended from time to time) – a copy of which is available upon request. For general enquiries please contact +44 (0) 1332 864900. Doncasters Group has scanned this e-mail for viruses but does not accept any responsibility for viruses once this e-mail has been transmitted. You should scan attachments (if any) for viruses. Doncasters Precision Castings - Bochum GmbH Bessemerstrasse 82, D-44793, Bochum, Germany Telefon (02 34) 6 22-1, Telefax (02 34) 6 22-335 Geschaeftsfuehrung: Michael Joseph Quinn Sitz der Gesellschaft: Bochum Registergericht: Bochum HR B 5748, UST-IdNr.: DE811150153
Bug#1025267: Nimbus Roman: wrong glyph for ₤ (U+20A4 LIRA SIGN)
Hi Jakub, Am Donnerstag, dem 01.12.2022 um 19:21 +0100 schrieb Jakub Wilk: > In the Nimbus Roman font, the character ₤ (U+20A4 LIRA SIGN) looks > like > "zł". It should look similar to £ (U+00A3 POUND SIGN) instead. well, I doubt that we'll be able to fix this in the scope of the Debian package. Would you please do me a favor and forward this issue to the upstream git tracker? Thank you! - Fabian signature.asc Description: This is a digitally signed message part
Bug#1021845: s050000l.afm lost in transition from gsfonts to fonts-urw-base35
Hi Christoph, Am Samstag, dem 15.10.2022 um 22:18 +0200 schrieb Christoph Biedl: > and identified the problem as follows: This file s05l.afm was > previously provided by gsfonts package, that package is now > transitional > and depends on fonts-urw-base35, but the file is not provided there. as Roland already stated, the file has merely been moved to a different location. The actual transition should be trivial. I have filed heads-up bug reports against all packages with an install- time relationship with the previous gsfonts and gsfonts-x11 packages, but I may have somehow missed packages with Build-Depends on gsfonts. I will provide a README.Debian file with the next revision, explicitly listing the font files with their previous and new file names and paths to make migrations easier. Thanks! Cheers, - Fabian signature.asc Description: This is a digitally signed message part
Bug#1021347: fonts-texgyre: please demote fonts-texgyre-math to Recommends
Package: fonts-texgyre Version: 20180621-3.1 Severity: normal Hi, while I was glad to see that the math fonts have finally been split off of the fonts-texgyre package, I was a bit disappointed to realize that I would have to install them anyway, because fonts-texgyre has a hard dependency on fonts-texgyre-math. Please consider demoting this relation to a Recommends. BTW, the package needs a new source-only upload anyway to make its transition to testing. ;) Cheers, - Fabian -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'experimental'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.19.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) -- no debconf information
Bug#1021210: ITP: woof -- continuation of the Doom source port MBF targeted at modern systems
Package: wnpp Severity: wishlist Owner: Fabian Greffrath X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Games Team * Package name: woof Version : 10.3.0 Upstream Author : Fabian Greffrath * URL : Debian Games Team * License : GPL-2.0+ and others Programming Lang: C (with CMake build system) Description : continuation of the Doom source port MBF targeted at modern systems Woof! is a continuation of Lee Killough's Doom source port MBF targeted at modern systems. . MBF stands for "Marine's Best Friend" and is widely regarded as the successor of the Boom source port by TeamTNT. It serves as the code base for popular Doom source ports such as PrBoom+/DSDA-Doom or The Eternity Engine. As the original engine was limited to run only under MS-DOS, it has been ported to Windows by Team Eternity under the name WinMBF in 2004. Woof! is developed based on the WinMBF code with the aim to make MBF more widely available and convenient to use on modern systems. . To achieve this goal, this source port is less strict regarding its faithfulness to the original MBF. It is focused on quality-of-life enhancements, bug fixes and compatibility improvements. However, all changes have been introduced in good faith that they are in line with the original author's intentions and even for the trained eye, this source port should still look very familiar to the original MBF. . In summary, this project's goal is to forward-port MBF.EXE from DOS to 21st century and remove all the stumbling blocks on the way. Furthermore, just as MBF was ahead of its time, this project dedicates itself to early adoption of new modding features such as DEHEXTRA+DSDHacked, UMAPINFO and MBF21. I am the project's upstream developer and would like to maintain this package under the umbrella of the Debian Games Team. It is a Doom source port somewhere between Crispy Doom and PrBoom+ in terms of complexity and may be considered as PrBoom+'s successor for casual play whereas DSDA-Doom (the other source port I am going to package next) is focussed more on demo recording and speed running.
Bug#1020244: fonts-urw-base35: A monospaced font shouldn't have ligatures
HI Markus, Am Freitag, dem 30.09.2022 um 17:08 +0200 schrieb Markus Hitter: > Would you mind making a packaging patch? This would solve the problem > at least for Debian (and Ubuntu) users, giving upstream as much time > as they want or need. sorry, no chance! This has to be solved upstream, there will be no isolated Debian/Ubuntu solution to this. This issue affects Ghostscript, all PDF renderes, LaTeX, etc. across all distros. Thus, you have already done the right thing by forwarding your solution to upstream (or at least their distributor). It's up to them now. You know, the reason why we ditched the gsfonts package in favor of fonts-urw-base35 was that the former contained an unmaintained Debian- specific fork of the fonts. Patching the fonts-urw-base35 package in Debian would create the exact same situation again. ;) Thanks anyway! Cheers, - Fabian signature.asc Description: This is a digitally signed message part
Bug#1020244: fonts-urw-base35: A monospaced font shouldn't have ligatures
Am Donnerstag, dem 29.09.2022 um 18:06 +0200 schrieb Markus Hitter: > Bugfix provided in the upstream bug. I've seen that, thank you! > Now comes the hardest part: encouraging upstream maintainers to > accept the bugfix. They usually feel alienated if some unknown idiot > (me) comes along and solves a long standing issue quickly. Last time I think the underlying issue is that even Artifex isn't the actual author of the fonts, but (URW)++. So, Artifex is bound to wait for (URW)++ to provide for upstream fixes, and this takes longer and longer. The problem with your patch is that it would have to go the other way round, i.e. first to (URW)++ so that they can use it as a base for theit further development. This case is very unlikely to happen, though. :( > (bugfix for Gitk) I solved this by writing poems :-) Let's hope it helps this time as well. :D Cheers, - Fabian signature.asc Description: This is a digitally signed message part
Bug#694320: [gsfonts] Fonts include copyrighted adobe fragment all rights reserved
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 unblock 694320 by 694308 The fonts files in fonts-urw-core35 are not built by fontforge anymore. - Fabian -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEIsF2SKlSa4TfGRyWy+qOlwzNWd8FAmMUfacACgkQy+qOlwzN Wd9hghAA0ZNlg3JqcZYSOI6XRWCSz22Q8hYKpFdqzXNSkY0O/aA9fFIPN2OC/p2b FIBWEgjZZ0o7aa060fu0hfYTajjQly9vRxZdmynYdxcISjmJ85qyVrkmYY0sMrWT yMpakN52mXK/E5lbwFdI0LNk6OZ9VKcPY09lxfXKZMPKZtBDEtVdnCD+hHOJ6MQs iF7wLB+R9Nf/E7sARv97FqprqIIkCU1pCuqmgD5/YxdcNlqYz3lDCv2IKqk53UFk wAQjedXM+OHAvE0zeo7UmAZraufVxyOC++U6yU0zcSiJlbTEkbVZSn/WsyxXjnk1 bSLl8PBuVfpRFY+ZMNhF6M27PEMa94AiVFaT06ZIFJByoP5BHqho1tJAMIlQAkFk ksaW7dPJz2FYDlDsC6HVVkMYg8t+cqii0vuZK9IabdQ49tF2RxYBYVhTybW+GRw8 Wc6/uW80Z+lqnrQ8l8pViMghQg1CGjShCdDL6J2DMJY4BboGM0Qd+hHONRhRStmX SrCKgBWRZLxYds/Iw3T+2TW1pWf8EZ1ElTAXQRiIMgaeOqMvkzGidD8eKYES5/Qz uwPyXyIQnLPrp2gMc05BC7VF47PR7SpE1E6rldqSESNxjY/PcNeVFDq8YC3ZEdPV RYgQPBwWONma16YHy65UXycrCRIWmru3hs3v+OwnbwMHSrqhzmo= =uJpJ -END PGP SIGNATURE-
Bug#977765: [Pkg-fonts-devel] Bug#977765: src:gsfonts: package superseded by fonts-urw-base35
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Am Samstag, dem 27.08.2022 um 19:40 +0200 schrieb Jonas Smedegaard: > Yes, Ghostscript contains a script update-gsfonts which makes use of > it. I see, thank you . So, I'll keep the file. Do you guys think I will have to post a heads-up to debian-devel for the transition? - Fabian -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEIsF2SKlSa4TfGRyWy+qOlwzNWd8FAmMKexQACgkQy+qOlwzN Wd+l3xAA2hXXT0zFjuNnsyqJT9dY6eDrH0CFG8JhI21dkBBl/DBEAov8Mxdv/a7x kZ683Vcx+5z4oa7ig4Ik7LGmTcRLdz0F023IG84a31UuWWEnt9IeWm5sFB1AugSC OMvqOp+4VFLMTxCb1RBGKJ9nLELCeRXKDULoc/4PWHLxicTQTaT958wmq5IbxgJf bsXHWy+u2w8X72R+h1CVPlh1KwNtL8V73PITBODSLnxWPdHZS3kHMMF0X4slBI/P ej96A2upjnyYJF5NUwkzHAkXMBUGL/3l/AMowIm28bBhBFiVuWme5KzuXJ5gvptt KKZ0qDNXRCDmoEjSRqMFJWC8L8OSs4Gw3ajq6Fn/tojpvGl4mz3N7qdMO8LETD6J q0EGa+UW32HCz/WUe1lRvSgrHyZe7igGmhdbnNZgT8XHpQG8DKaPoMWMt7MjxIIb p+8yU58tIfg27SQfEsEmiZ3gXMp/WYkVnCAbJAqxLejohA5XB2Hfn5XDNhZHibAM iP/KcPUyUlBr59/x8I1++Z4BJrVwHsuwpCAbWMdIXzVqE8Ufe00piG1z68/8xw3k tnztmEIFgHfkiP/K+D1EdeyA9QJlTFVc6AohJC4JzTiTsk53Ej6C27g4k6eusOXw +IFcgHLCcn+AsMUk38jzQP5K/BT44nTOFZwCzX7nMng7A7bOEx0= =/rte -END PGP SIGNATURE-
Bug#977765: [Pkg-fonts-devel] Bug#977765: src:gsfonts: package superseded by fonts-urw-base35
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 @Jonas: Is the file /etc/ghostscript/fontmap.d/10fonts-urw-base35.conf [1] even necessary now that the font files are directly symlinked in the libgs9-common package? Cheers, - Fabian [1] https://salsa.debian.org/fonts-team/fonts-urw-base35/-/blob/master/debian/10fonts-urw-base35.conf Am Samstag, dem 27.08.2022 um 14:12 +0200 schrieb Fabian Greffrath: > Am Freitag, dem 26.08.2022 um 09:52 +0200 schrieb Roland Rosenfeld: > > Just go for it. > > I have just uploaded fonts-urw-base35_20200910-2 to experimental > which > takes over the gsfonts and gsfonts-x11 packages. So, if you guys > could > check if the transition works out for you as expected, that'd be > appreciated. > > Thanks! > > - Fabian > -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEIsF2SKlSa4TfGRyWy+qOlwzNWd8FAmMKS3gACgkQy+qOlwzN Wd/OEw/+LaO8ZtZFtXNTRCbr0pybxPhIMpqOL16b1vhnT31XwQvGAzuRhuNF2/9g pL2mNe01HKE5FldwuH9+XawdfYnH0P9dMRzm1CXZAwdrVjefwQkhISfFgta+zwG9 A744jNnC7zk/ChQRapmrRKilUjK7MqA3GhC+0jr7I6NF7qNEsi+EUpMDSn5KeqXc d8l2dbmvSFYaajVxTvnNkq3y7feLCyDKIsJKFbVD+FpBs/Om4MRJDBGuc9FKOjTS 4+tsQaWi6FFbdVu4NbEGhcYi3u6b3MWUAfo4MgAQuiE3fpv1rRSE4Hw6aRP7YSwZ 6YKVVURiXbNDdmYjP3lS4yaQ+KWvvIjezUcTuD8RAPgcqUic70+UFU7ytNLR/yXm lP4L0aQuALQD3QFtWh+wFS3Kk/o98afGoqd8gxkDsoUAkwAejHzLAPa2H3j2dpRf 4fgRCVCi4cFroILW/gB7S2ytqvhxGaVoBTYm0XcaTe1KsOt/P1n4CUzf2hVEwFOI UCOet2tzGe34HEvYxFyJoa9nLZu2IE/Qy2BYLNJMBWBZLgi5LHiYfVdh1XRaEx1p lpn2pf+l4ETHwH3/G7aekf1Ew2A6xvIKuja8lSNKsGoQ/jXViIqmPWiCVZGzDA7L oU476E1e3TNhyPIu2G7YH59m7pv8h4LHr5QIGeKRjOUdeCIFkMY= =U7BW -END PGP SIGNATURE-
Bug#977765: [Pkg-fonts-devel] Bug#977765: src:gsfonts: package superseded by fonts-urw-base35
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Am Freitag, dem 26.08.2022 um 09:52 +0200 schrieb Roland Rosenfeld: > Just go for it. I have just uploaded fonts-urw-base35_20200910-2 to experimental which takes over the gsfonts and gsfonts-x11 packages. So, if you guys could check if the transition works out for you as expected, that'd be appreciated. Thanks! - Fabian -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEIsF2SKlSa4TfGRyWy+qOlwzNWd8FAmMKCiYACgkQy+qOlwzN Wd/wnhAAwwgzhqlgOuioHah1qrqaNeJZIasP1oQ7uPFq6wKDkKSGSMP4pvR2rNSp GHtdh+PzCij/5ADfEl8wEB0b3kkVmKhPPH8uMmUH4TZW+YxBypem6fsLAP7P0cSH kUeFMqjmQFQtuB1rcjT2UXQS5daG/UYE2f5RMxOsh5zxx5Wja4NAYUdOm2qdrLQG 73zczLWK3rX7+jJh7nEn48IjC8LmRAOr77tOnazVhWMjGIuEQqJ+klKaRFz8jY0R rb1LvWves+kpwMmNW8G+GoTrUqhArHqngAWszq6eW/A+VeBM9ZZdDTrmwVOhCoeO csh+y11e2QIlzJsZ8fp3KI/8UDfOBD5RmzlfvTVfYc+V/Zs0eh6DXhcrfYFJIeGZ TAiRm4eEKlqzZF2kdwn5mQsrmgVoSC8Ox/qLgVS9FCwVDCqjYQIb9mTDnS+td5gS +gvbZOruEdQd1pcRhcA+z3Dvi4c9DCsR3ixre8f2iWmhw07HFT7IGBGqy7+kz8nL JA/uSzrMTDg7Kyzsx0GAVOmhxABFur6Cy23iRW4btsJGij7GdMggRIBjIfs1CsMD 91nV96GsPbLXM/HUrr7XBmTrDFaMTdtgmyp0zbDVRFfDas8mFBt3BDBc3JofLVv3 RALcjqc3AdfpJZtlELV/SYR1Y9RXI+WzafRDN87Jrg8VxRiqy50= =aC/0 -END PGP SIGNATURE-
Bug#977765: [Pkg-fonts-devel] Bug#977765: src:gsfonts: package superseded by fonts-urw-base35
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, 28 Jul 2022 10:21:17 +0200 Fabian Greffrath wrote: > > Maybe now is the time? > Indeed my plan is to tackle this issue in about four weeks. I currently despair of the format of the fonts.scale and fonts.alias files that are provided by the gsfonts-x11 package and that I somehow need to adjust to the new font file and family names in the course of replacing the gsfonts-x11 package (which will get disfunct as soon as fonts-urw-base35 replaces and provides gsfonts). - Fabian -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEIsF2SKlSa4TfGRyWy+qOlwzNWd8FAmMHHsYACgkQy+qOlwzN Wd/NnRAAk1flQ4W7nXO/IDxCIL/kLxY7QbVdiwU3J5dwPnlCLclpIb10PoNCmwEo Zb3OW/fvT7tFuDQpiCZJU4XiT92vqQjMqcCRtInpZaKlzuu1rc5+13qeqYlht41E KuAHKhjvRbXUtBLodYKutVYw9iZKbFeHblx5tbpyBbvQcJUn89kF5vmAKUqAZ9Gr gKQTH8iniREayC4PV6TuLFQwIZdvKS5XYnSkhqfNyYpLwHZ3IoREsaQcBPvI/cAO 26BjI9AmRyPL11DNi2G0KAJm5ieyhvlE3BFo6UN5f3Mqc4SO/8fhdMTxpAkm0O+s l6C/sPEnRL3/XT4DaYWxPo05Dn0Vqb1MMnrReL/qDZPlywPk4AT6fiTbxvxEJC+Y bvKdjfsEZqoAYYybxiyDZG3kOc9qupmTHbrW/+7oxzhLxJ4Z8W566ABFucKDgdSA 89VmpgdABPW981oViF74yTjkGC71XuRr1c1YhcIGFePUk5VAd2AlaNkAoxllRn3e d705WrRQiJ7dCueHKizrXuiqAl7iJ2xaJDDv/Tqtlf1JIqx0jj2+vmsiDVasjSY8 BE40uRcKhqtbgDlzgUQQ8ctCPHV+udBWtqisJ16G7fqEIL3lra73VQrUSh8JO3k6 GSGNoaSnJJ4nhrF5CxuPGKo3vjNtgcPWzubuDDFicP5tRziHf6M= =YtHR -END PGP SIGNATURE-
Bug#977765: [Pkg-fonts-devel] Bug#977765: src:gsfonts: package superseded by fonts-urw-base35
> Maybe now is the time?Indeed my plan is to tackle this issue in about four > weeks. - Fabian Von meinem/meiner Galaxy gesendet Ursprüngliche Nachricht Von: Chris Hofstaedtler Datum: 28.07.22 01:02 (GMT+01:00) An: Fabian Greffrath , 977...@bugs.debian.org Cc: Jonas Smedegaard , Paul Gevers Betreff: Re: Bug#977765: [Pkg-fonts-devel] Bug#977765: src:gsfonts: package superseded by fonts-urw-base35 * Fabian Greffrath [220727 23:01]:[..]> My stance on this: In theory it should be technically possible to replace> the gsfonts (and gsfonts-x11) package with fonts-urw-base35 and I believe> this would be the right step, given that the latter font set is actively> maintained and extended - and actually used by ghostscript both upstream and> in Debian. And as a matter of fact, I have prepared this transition since I> uploaded the fonts-urw-base35 package for the first time. So, why haven't I> triggered this transition yet?[..]> So, to summarize: Yes, I think we should replace gsfonts+gsfonts-x11 with> fonts-urw-base35 at a given time and this transition is already prepared for> the most part. But I don't see this as a pressing issue right now, given the> lack of real-world issues this apparently causes, given the lack of bug> reports we received during the past 5 years - and given how late in the> release cycle we are to introduce a potentially disruptive change like this.Maybe now is the time?Chris
Bug#981285: Please move fdk-aac to main
Am 26.01.2022 10:51, schrieb Laurent Bigonville: Could anybody of the multimedia team have a look at this? What do you expect from "having a look at this"? I agree that the package should be in main, but in the end it's up to the ftp-masters to decide. - Fabian
Bug#1001791: fonts-cantarell: Renders system hardly usable
Hi, Am 16.12.2021 11:22, schrieb G. Heine: this version displays only letters a-z correctly thus making the system hardly usable, unless you change to a different font. The problem is best shown with the attached screen-shot. this seems to be a duplicate of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788791 Have you restarted your desktop session after the fonts have been upgraded? - Fabian
Bug#953740: Please package new upstream release of fonts-cantarell
PS: Related upstream request here https://gitlab.gnome.org/GNOME/cantarell-fonts/-/issues/55 - Fabian
Bug#953740: Please package new upstream release of fonts-cantarell
Gentlemen, Am 03.12.2021 14:09, schrieb Fabian Greffrath: That'd be it, then. ;) I have uploaded a package to experimental [*] in which I applied the two "tricks" I outlined before. I have not experienced any issues with Gnome Shell, Gnome Control Center or any other Gnome app, yet. Please install the package and give it a try yourself. [*] Because we are tracking GNOME releases in debian/watch, but I have packaged a font release which is not part of a GNOME release, yet. The optional building of either the static fonts or the variable font has just been introduced in Cantarell 0.302, whereas GNOME still has 0.301 on its servers. Also, because I have disabled an overlay removal algorithm which upstream has explicitly chosen and fall back to the default one instead. Thanks! - Fabian
Bug#953740: Please package new upstream release of fonts-cantarell
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, 4 Oct 2020 21:32:14 -0400 Jeremy Bicha wrote: > https://github.com/daltonmaag/statmake It seems that this is only required to build the variable font [1], which we do not necessarily want. We have only built and shipped the static fonts so far. > https://github.com/fonttools/skia-pathops It seems that this is more-or-less optional. That is, it is explicitely chosen as the algorithm to remove overlaps [2]. But according to the ufo2ft docs, the "booleanOperations" is used by default [3]. So, perhaps it is worth a try to simply patch out explicit usage of "pathops" for our Debian package. That'd be it, then. ;) - Fabian [1] https://gitlab.gnome.org/GNOME/cantarell-fonts/-/blob/master/scripts/make-variable-font.py#L60 [2] https://gitlab.gnome.org/GNOME/cantarell-fonts/-/blob/master/scripts/make-static-fonts.py#L34 [3] https://github.com/googlefonts/ufo2ft/blob/4c5d9a621bea090a37a14f7dfc70a39ee99cfea4/Lib/ufo2ft/preProcessor.py#L127 -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEIsF2SKlSa4TfGRyWy+qOlwzNWd8FAmGqFvAACgkQy+qOlwzN Wd9fdRAA0gefEjny64cfYlbYA0UB/dnQTNrZACXwi3XiQ85lHgsQ45+tlGBZuHu8 UulHrGvIgvEdtjY1gHCYpI/Bw5pCR2lbuyx2HZ2FkgMlqCODTIfr5BL5SIFVNcF+ MYYpnv/HsgJz7mQ6QSSaTBBCg/LWb6zJxgYX4Zh5g47T4j524UazMdH9KsdxxWYq NocE7WSbQpECePgj9ELS+3+zCEbiLG+8mp9hj2uRC4Q/cBvfUTU9JBth0XsopNUv cN0aOfcmJM06U7v/hThBbCa7TJp1hN3/BYL+fyNknFTuKWvhaReYg7Ot+cQzI285 QKVEW/HyMAtN2jEfPZkaG278MZIz1YQAtNWI6gxE9lOkmG7MOydsXd66zWjQlhtv doT4bl2+SdLC+QSgWRHxzJyU2XlRnU8tkO2uox7FSKeFOKwGuMmNn9ArEvyAhQGN bSMppsprvXFFF1xf22CX2N2d988aZewJ3o4pWD0G7Hub4d3kIPUJkbNvq22L/nhO nD3/i9g7mp23actobh3uoV0m89+/ze+n15xA/wHmhDUxKKd/px7nnx5608b1rxyG wvX0Z8C8Iq1jHtDN6E/yBAk7XOnLH3EPc2DDzIKW/jsnMJZzxlltOD54yZ47GJyn cG5hIhSEroSarlXXuOMxCEscl+//vcMyrl5pEsz35IEYG1OxHqk= =oi6X -END PGP SIGNATURE-
Bug#998748: ffmpeg: headless package version
Hi corsac, Am 11.11.2021 15:36, schrieb Yves-Alexis Perez: So I went ahead and gave it a try. For the sake of interested people, here's some details. could you prepare a patch that makes this available as a package build-time option, e.g. if DEB_BUILD_OPTIONS contains "headless"? Thanks! - Fabian
Bug#999116: ~ Re: Bug#999116: doom-wad-shareware: missing required debian/rules targets build-arch and/or build-indep
Am 11.11.2021 14:30, schrieb Jonathan Dowland: You could consider moving to dh. Although it might seem a bit crazy for a package of literally one file. But if I had done that instead of golfing the packaging down to the bare minimum, this upload would not be necessary (and likely :1.9.fixed-2 could have been avoided as well) Yep, the main advantage of using dh is that you can get the packaging 90% right at first try. I guess I'll take the opportunity and give the package a complete overhaul. Thanks for your reply! Cheers, - Fabian
Bug#999116: doom-wad-shareware: missing required debian/rules targets build-arch and/or build-indep
Hello Jonathan, I am going to fix this bug by re-uploading a new package revision. Should I take the opportunity and remove you from the Uploaders list, i.e. replace yourself with myself? Cheers, Fabian Am 09.11.2021 22:28, schrieb Lucas Nussbaum: Source: doom-wad-shareware Version: 1.9.fixed-2 Severity: important Justification: Debian Policy section 4.9 Tags: bookworm sid User: debian...@lists.debian.org Usertags: missing-build-arch-indep Dear maintainer, Your package does not include build-arch and/or build-indep targets in debian/rules. This is required by Debian Policy section 4.9, since 2012. https://www.debian.org/doc/debian-policy/ch-source.html#main-building-script-debian-rules Please note that this is also a sign that the packaging of this software could benefit from a refresh. For example, packages using 'dh' cannot be affected by this issue. This mass bug filing was discussed on debian-devel@ in https://lists.debian.org/debian-devel/2021/11/msg00052.html . The severity of this bug will be changed to 'serious' after a month. Best, Lucas ___ Pkg-games-devel mailing list pkg-games-de...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-games-devel
Bug#998513: rott: Fails at startup when doing XFree86-VidModeExtension/XF86VidModeGetAllModeLines X request
Am 08.11.2021 09:59, schrieb Konstantin Khomoutov: Oh, indeed: I have rebooted the laptop to apply the latest Bullseye updates, and the issue has gone away; sorry for the noise. I'm going to close this bug. Alright, thank you. Anyway, we should keep in mind to upgrade this game to use SDL2 sooner or later... Do you mean this error? Yes, right. Fluidsynth changed their API to enforce a certain order in which objects are freed, and SDL-Mixer needs to be patched to adhere to this. - Fabian
Bug#998513: rott: Fails at startup when doing XFree86-VidModeExtension/XF86VidModeGetAllModeLines X request
Hi Konstantin, Am 04.11.2021 18:43, schrieb Konstantin Khomoutov: At startup, rott-commercial fails when performing what looks like a query to the X server regarding its capabilities: I cannot reproduce this issue, so it might have to do with your specfic video hardware or drivers. I guess that's the price we pay for still using SDL1.2 for a game in 2021. /o\ What I can confirm, though, is the game crashing when using libsdl-mixer1.2 (<< 1.2.12-17), but that's a different story and happens only after the intro. Does it help if you pass the "-window" command line parameter to avoid any fullscreen mode switching? Thanks! Cheers, - Fabian
Bug#996955: task-desktop silently pulls in task-desktop-gnome via Recommends
Am 21.10.2021 21:05, schrieb Brian Potkin: Fortunately, not selecting it isn't of any consequence. A user gets what else is chosen. I don't consider it "fortunate", it is inconsistent that having that choice selected or not does not make a difference as long as any other choice is selected. And that having that choice selected but none of the others will indeed install one of the others. No, that is not the case. Selecting "Desktop Environment" only will have the effect of selecting the default desktop. This could be Xfce, which is not the first one in the list. Yes, right, that's on non-amd64/non-i386. That's even more confusing, that selecting the generic choice but not explicitly selecting any of the choices in the list will implicitly install the third choice in that list. - Fabian
Bug#996955: task-desktop silently pulls in task-desktop-gnome via Recommends
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Am Donnerstag, dem 21.10.2021 um 18:33 +0100 schrieb Brian Potkin: > I think this is exactly the way it was designed. Whether the design > is the best is what has been brought up in this report. The results are pretty surprising and unpredictable, though. > There is the concept of "default desktop". At the present time it is > Gnome. The first selection is for the default. The description for > task-desktop says: You don't have a chance to read the description of the task-desktop package during d-i. As Holger already stated, it must be made clear that merely selecting "Desktop Environment" will have the same effect as selecting the first one in the list, even if this has been explicitly unselected. - Fabian -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEIsF2SKlSa4TfGRyWy+qOlwzNWd8FAmFxs8UACgkQy+qOlwzN Wd/z1RAA5qtuYcv/O7hbs51+GgxM+Rw7GfokPKH84b5UuYlNs7qrvIHl7tL7dGY2 n76iyX0SI3QEPHnm99w+KjUv5XzOuFSIJIzFsbuywZTN96VH9fkDKIS6qhWmyvYj djTdyPMhFqhDcnuC4ZMRsk/SKm1LCR2rj/GgNe3BlZKV81P04sKshVo+Z1IhiG8n HZjn/APxLc/fZm/OcUIeZ3i9ANpD3/A4Snwc7/BNRWg6uO845xXIuJRyPRPpOfQv 6SVlhxeQG5aPqMxMjbc1LFD9KSvQKX5CEQWR1NM9od7GPfs/aa1YO3BaPfvT90h+ Hi9jbVNX4/oBJJ4eFiEjaCOzC5/6GIern1HYvnRvwZC5Ex2N9DgD/oz71lRTUAxA JlSIRwL9ndoz2NSYISsV4d736jJ6EWtBHIk9+6y30D8KFzC3AsK3mmTroV7FuIA5 TsjeJvzgRrZWInudDPWqZsqXI4NOKbH2X7TPyQDLkoeKGky9LtS9Z6j8BMZraivO QCIzOelZ/tlCsnXs1ftcgpNktDIaSTqOpLgF5YOVfkvRZYHvtf7AiS4f1iMM24jN ooPWblioZGROAjxIR4/znjqWr4dVF8sv0aoSOeF6TgpxHrNBx2aWDHJYTd1u3s/F POpn4AzdzvZOiOpSf/Cusm/ubCVRNoVSXxZPwsb8gzHivzJ3y+I= =IFgM -END PGP SIGNATURE-
Bug#996955: task-desktop silently pulls in task-desktop-gnome via Recommends
Hi Holger, thanks for your reply! Am 21.10.2021 16:31, schrieb Holger Wansing: Selecting "Desktop Environment", but not choose one of the displayed possiblities (like "GNOME", "KDE" and so on) is not the way, how this dialog was designed, I guess. Yes, apparently. :/ I could imagine a solution, where the checkbox in the first line "Desktop Environment" is not directly changeable at all, but gets automatically checked or unchecked, if the user selects one of the desktop environment options below (or does not check any of them). Or the first line having no checkbox at all would be even better. Yes, one of these options would clearly help improve this experience. Thanks! Cheers, - Fabian
Bug#996955: task-desktop silently pulls in task-desktop-gnome via Recommends
Package: task-desktop Version: 3.68 Severity: normal Tags: d-i X-Debbugs-Cc: debian-b...@lists.debian.org Hi, I just installed Debian stable in a virtual machine. When I was asked during the installation process which "meta-packages" to install I left "Desktop Environment" selected but explicitly deselected GNOME. I expected to end up with a minimal graphical environment, e.g. X with twm and xterm or similar. However, I was surprised to find out after installation that indeed the entire GNOME desktop was installed albeit me explicitly deselecting it during installation. The reason seems to be that task-desktop Recommends a whole list of alternative desktop environments with task-desktop-gnome being the first on the list -- and since Recommends are installed by default and since the first of a list of alternatives is installed by default, this is how I ended up getting GNOME installed, although I didn't even want it. The outcome is the same as if I had left the GNOME checkbox selected, which is quite surpsising and unexpected to me. Please consider introducing an absolute bare minimum package to let task-desktop depend on (by means of Recommends) instead of falling back to GNOME. Thanks! Cheers, - Fabian -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'experimental'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.14.0-2-amd64 (SMP w/8 CPU threads) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages task-desktop depends on: ii desktop-base11.0.3 ii tasksel 3.68 ii xorg1:7.7+23 ii xserver-xorg-input-all 1:7.7+23 ii xserver-xorg-video-all 1:7.7+23 Versions of packages task-desktop recommends: ii alsa-utils 1.2.5.1-1 ii anacron 2.3-31+b1 ii avahi-daemon0.8-5 ii eject 2.37.2-1 ii firefox 93.0-1 ii fonts-symbola 2.60-1.1 ii iw 5.9-3 ii libnss-mdns 0.14.1-2 ii sudo1.9.5p2-3 ii task-gnome-desktop 3.68 ii xdg-utils 1.1.3-4.1 task-desktop suggests no packages. -- no debconf information
Bug#984807: Add stdmusic to freeciv-sound-standard package
HI Markus, Am 08.09.2021 11:50, schrieb Markus Koschany: would rather drop freeciv-sound-standard completely agreed! The sounds and music are an integral part of the game, they add a mere 2 MB to the installation and are easily missed as they are currently packaged. Thanks! - Fabian
Bug#990246: vlc: reproducible builds: Embeds build username and hostname in binaries
Sorry for my super-clever MUA adding line breaks on its own.
Bug#990246: vlc: reproducible builds: Embeds build username and hostname in binaries
Control: forwarded 990246 https://code.videolan.org/videolan/vlc/-/issues/26035 Am 26.08.2021 04:59, schrieb Vagrant Cascadian: Control: forwarded 990246 https://savannah.gnu.org/support/index.php?110532
Bug#990246: vlc: reproducible builds: Embeds build username and hostname in binaries
Control: forwarded -1 https://code.videolan.org/videolan/vlc/-/issues/26035 Am 26.08.2021 04:59, schrieb Vagrant Cascadian: Control: forwarded 990246 https://savannah.gnu.org/support/index.php?110532
Bug#990861: prboom-plus: No secret found sound in Freedoom
control: tags -1 unreproducible Hi Andrew, Am Freitag, dem 09.07.2021 um 17:24 +0200 schrieb Andrew via Pkg-games- devel: > Secret found! sound only works for non-free Doom data, not Freedoom. sorry, but I cannot reproduce this. If prboom-plus cannot find the sfx_secret sound lump - which it won't, because we don't ship it anymore in prboom-plus.wad - it falls back to using the sfx_itmbk sound. This sound lump is always present in the IWAD since Doom 1.2 and also in Freedoom. https://github.com/coelckers/prboom-plus/blob/f5ba5a39ad596af681ed3102fed5f28cc685089c/prboom2/src/p_spec.c#L2377 In Freedoom, however, this sfx may be a bit muted and sound unfamiliar, so is it possible you merely overheard it? https://github.com/freedoom/freedoom/blob/master/sounds/dsitmbk.wav Cheers, - Fabian signature.asc Description: This is a digitally signed message part
Bug#988016: prboom-plus: Segmentation fault on Wayland
Control: tags -1 confirmed upstream Control: forwarded -1 https://www.doomworld.com/forum/topic/31039-prboom-plus-ver-2514/?page=123&tab=comments#comment-2301968 Am Montag, dem 03.05.2021 um 20:51 +0200 schrieb Chris via Pkg-games- devel: > On sway WM with "xwayland" disabled, prboom-plus seems to work fine, I > can configure options and play a game. However, once I quit, I get > the error: Yes, we are currently trying to nail this down on the Doomworld forum: https://www.doomworld.com/forum/topic/31039-prboom-plus-ver-2514/?page=123&tab=comments#comment-2301968 - Fabian signature.asc Description: This is a digitally signed message part
Bug#987333: jumpnbump crashes on systems with unsigned char.
Hi Peter, Am 22.04.2021 00:52, schrieb peter green: If I get no response to this bug and I get time to test out the patch I will likely upload a NMU in a week or so. the patch looks trivially correct to me. A NMU/Team Upload would be appreciated. Thank you! Cheers, - Fabian
Bug#985129: musescore3: /usr/bin/mscore3 terminated with SIGSEGV
Hi Thorsten, Am Sonntag, dem 14.03.2021 um 20:05 + schrieb Thorsten Glaser: > @Fabian since you were the driving force behind SF3 integration > into FluidSynth itself, you might wish to have a look at the > patch as well. forwarded to Fluidsynth upstream, thanks! (I am not active in this project anymore). - Fabian signature.asc Description: This is a digitally signed message part
Bug#977765: [Pkg-fonts-devel] Bug#977765: src:gsfonts: package superseded by fonts-urw-base35
Hi all, Am 07.02.2021 22:51, schrieb Jonas Smedegaard: Added now explicitly. well, thanks. I can't wait to participate in this discussion. My stance on this: In theory it should be technically possible to replace the gsfonts (and gsfonts-x11) package with fonts-urw-base35 and I believe this would be the right step, given that the latter font set is actively maintained and extended - and actually used by ghostscript both upstream and in Debian. And as a matter of fact, I have prepared this transition since I uploaded the fonts-urw-base35 package for the first time. So, why haven't I triggered this transition yet? First, we have packaged the urwcyr fork in the gsfonts package which has added cyrillic glyphs to most (all?) fonts and I have been told that we set parts of official Debian documentation with these fonts, and this includes translations into languages which depend on the presence of cyrillic glyphs. Granted, nowadays there are dozens of alternative fonts available in Debian that provide these glyphs. Anyway, back then when I proposed the transition I have been told to please wait. I guess it was late in a release cycle... Second, I have never experienced any "name space clash" in real life. In my experience, fonts are either selected directly by file path or by means of fontconfig. And the latter has sophisticated heuristics to return "the right font" for a given search pattern. If it finds two fonts with the same name, it chooses the one with a higher version number or glyph count or whatever. I don't know if there is some special case that ghostscript can't properly handle, though. So, to summarize: Yes, I think we should replace gsfonts+gsfonts-x11 with fonts-urw-base35 at a given time and this transition is already prepared for the most part. But I don't see this as a pressing issue right now, given the lack of real-world issues this apparently causes, given the lack of bug reports we received during the past 5 years - and given how late in the release cycle we are to introduce a potentially disruptive change like this. Cheers, - Fabian PS: Also, please note that there is a third (outdated) copy of the same fonts available in the texlive-fonts-recommended package which the TeX people want to keep, though, for TeX reasons I guess.
Bug#980289: fonts-liberation2: 2.1.2-1 install fonts 2 times
Indeed! Apparently, upstream didn't even have an install rule in their own Makefile prior to the 2.1.2 release. Thanks for noticing. Cheers, - Fabian Von meinem/meiner Galaxy gesendet Ursprüngliche Nachricht Von: stephrom Datum: 17.01.21 12:39 (GMT+01:00) An: Debian Bug Tracking System Betreff: Bug#980289: fonts-liberation2: 2.1.2-1 install fonts 2 times Package: fonts-liberation2Version: 2.1.2-1Severity: normalDear maintainer, Latest update on sid (fonts-liberation2_2.1.2-1_all.deb) install fonts intwo different places: - /usr/share/fonts/truetype/liberation2 - /usr/share/fonts/liberation-fonts-ttf-2.1.2I can't find this in the changelog so I assume it's a bug with the debian/installfile.Thanks.-- System InformationDebian Release: bullseye/sidKernel Version: Linux sid 5.10.0-1-amd64 #1 SMP Debian 5.10.5-1 (2021-01-09) x86_64 GNU/Linux
Bug#980289: fonts-liberation2: 2.1.2-1 install fonts 2 times
Indeed! Apparently, upstream didn't even have an install rule in their own Makefile prior to the 2.1.2 release. Thanks for noticing. Cheers, - Fabian Von meinem/meiner Galaxy gesendet Ursprüngliche Nachricht Von: stephrom Datum: 17.01.21 12:39 (GMT+01:00) An: Debian Bug Tracking System Betreff: Bug#980289: fonts-liberation2: 2.1.2-1 install fonts 2 times Package: fonts-liberation2Version: 2.1.2-1Severity: normalDear maintainer, Latest update on sid (fonts-liberation2_2.1.2-1_all.deb) install fonts intwo different places: - /usr/share/fonts/truetype/liberation2 - /usr/share/fonts/liberation-fonts-ttf-2.1.2I can't find this in the changelog so I assume it's a bug with the debian/installfile.Thanks.-- System InformationDebian Release: bullseye/sidKernel Version: Linux sid 5.10.0-1-amd64 #1 SMP Debian 5.10.5-1 (2021-01-09) x86_64 GNU/Linux
Bug#968574: ffmpeg: Please backport upstream patch to fix build on powerpc and ppc64
Hi there,> I think this patch is trivial enough that it can be included without any furthertesting besides the testing on Debian powerpc and ppc64, where I have verifiedthe patch to fix the problem.it would probably help if you could become a member if the pkg-multimedia team, applied these patches and did a team upload. I can add you right now once you apply. Cheers, - Fabian Von meinem/meiner Galaxy gesendet Ursprüngliche Nachricht Von: John Paul Adrian Glaubitz Datum: 16.01.21 23:27 (GMT+01:00) An: 968...@bugs.debian.org Cc: debian-powe...@lists.debian.org Betreff: Bug#968574: ffmpeg: Please backport upstream patch to fix build on powerpc and ppc64 Hi!On 8/17/20 10:56 PM, John Paul Adrian Glaubitz wrote:> ffmpeg currently FTBFS on powerpc and ppc64 [1]:> (...)> Upstream has a patch for that, see [2]. Could you backport that patch?The bug is unfortunately still present and the package still fails to build fromsource on Debian powerpc [1] and ppc64 [2].I think this patch is trivial enough that it can be included without any furthertesting besides the testing on Debian powerpc and ppc64, where I have verifiedthe patch to fix the problem.Could the patch be included with the next package revision?Thanks,Adrian> [1] https://buildd.debian.org/status/fetch.php?pkg=ffmpeg&arch=powerpc&ver=7%3A4.3.1-6&stamp=1610485996&raw=0> [2] https://buildd.debian.org/status/fetch.php?pkg=ffmpeg&arch=ppc64&ver=7%3A4.3.1-6&stamp=1610485440&raw=0-- .''`. John Paul Adrian Glaubitz: :' : Debian Developer - glaub...@debian.org`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#977538: fonts-agave: does not follow upstream's recommended build procedure
Am Mittwoch, den 30.12.2020, 19:09 +0100 schrieb Gürkan Myczko: > I wish I could. I'm struggling with that pipeline. Maybe you can hint > me? Hm, not sure, quite some usual GIT workflow: I clone the repository with "git clone ", apply my local changes, add or remove files with "git add/rm", review my changes with "git diff", check what would be commited with "git status", commit my changes with "git commit -- debian" and finally push them to salsa with "git push --all". This does not involve package building and uploading, yet. For this I use "gbp buildpackage" for test builds and finally "gbp buildpackage -- git-tag --git-pbuilder" for the version that I am going to upload. After that, I push the tag with "git push --all && git push --tags". Anyway, I have just imported your revision 3 DSC file, fixed a nitpick and uploaded it. Thanks! Oh, and I just uploaded the fresh new v36 release as well... Happy new year. ;) - Fabian signature.asc Description: This is a digitally signed message part
Bug#977538: fonts-agave: does not follow upstream's recommended build procedure
Hi Gürkan, Am Dienstag, den 29.12.2020, 20:37 +0100 schrieb Gürkan Myczko: > I think that's what you wanted: could you please push your changes to GIT so I can review them there? > Happy New Year! It's not over yet, but I can't wait for it, too. ;) - Fabian signature.asc Description: This is a digitally signed message part
Bug#977765: [Pkg-fonts-devel] Bug#977765: src:gsfonts: package superseded by fonts-urw-base35
Hi Jonas, Am Sonntag, den 20.12.2020, 14:10 +0100 schrieb Jonas Smedegaard: > This package has been superseded by fonts-urw-base35, which contains > the > same fonts but a newer release and using policy-compliant package > name. indeed, I have prepared fonts-urw-base35 to take over both gsfonts and gsfonts-x11 since the very beginning: https://salsa.debian.org/fonts-team/fonts-urw-base35/-/blob/master/debian/control#L15 However, I have hesitated to do so. The reason is that we have the urwcyr fork in the gsfonts package, and last time I checked not all cyrillic glyphs that this fork added were also available in the urw releases. > Setting severity to serious, as this package is not fit for release. Why do you think the package is not fit for release? Because it did not have a maintainer upload for the last 10 years? It is static font data, after all? Or because it does not follow a naming convention that isn't even Debian policy? Cheers, - Fabian signature.asc Description: This is a digitally signed message part
Bug#977538: fonts-agave: does not follow upstream's recommended build procedure
Package: fonts-agave Version: 35-2 Severity: normal Hi Gürkan, I see that the Agave fonts are build from their SFD sources with a pretty simple "open and save as OTF" rule. However, upstream provides some pretty detailed build instructions on the project page. Especially, the fonts are build in TTF format and there is an additional step that involves running ttfautohint over the generated font files: https://github.com/blobject/agave#build Please consider adapting the Debian packaging to these build instructions. If you need any help with this, please don't hesitate to ask. Thanks! - Fabian -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'experimental'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-4-amd64 (SMP w/8 CPU threads) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) -- no debconf information
Bug#976719: fonts-recommended: consider applying proposed changes
Package: fonts-recommended Version: 1 Severity: wishlist Hi Adam, please consider applying the proposed changes that I filed as Merge Requests on Salsa: move recommended font packages from Depends to Recommends https://salsa.debian.org/fonts-team/fonts-recommended/-/merge_requests/1 replace fonts-freefont-otf with fonts-unifont https://salsa.debian.org/fonts-team/fonts-recommended/-/merge_requests/2 add fonts-texgyre as an alternative to fonts-urw-base35 https://salsa.debian.org/fonts-team/fonts-recommended/-/merge_requests/3 Thanks! - Fabian
Bug#976296: blender: Segmentation fault when importing background image
Hi all,this might be the Blender vs. Python3.9 case then. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976378The dmo packages were a red herring, sorry. - Fabian Von meinem/meiner Galaxy gesendet
Bug#976296: blender: Segmentation fault when importing background image
Hi, Am 2020-12-03 00:47, schrieb will: ii libavcodec58 10:4.3.1-dmo3 ii libavdevice58 10:4.3.1-dmo3 ii libavformat58 10:4.3.1-dmo3 ii libavutil56 10:4.3.1-dmo3 ii libswscale5 10:4.3.1-dmo3 it's incredible that people still install these package. Please replace them with their Debian pendants and try again. Thanks! - Fabian
Bug#975712: Processed: Re: Unifont should be installed by default on Bullseye
control: reassign -1 task-desktop Am Montag, den 30.11.2020, 13:51 + schrieb Debian Bug Tracking System: > Bug #975712 [unifont] Unifont should be installed by default on > Bullseye That would be the task-desktop package, I guess. signature.asc Description: This is a digitally signed message part
Bug#975441: x264 silently disables gpac support with gpac 1.0.1
control: tags -1 upstream patch Am 2020-11-22 11:52, schrieb Adrian Bunk: Warning: gpac is too old, update to 2007-06-21 UTC or later This seems to be the fix: https://code.videolan.org/videolan/x264/-/commit/7c2004b58c26da661618262c9c06b73ad3a9ff6c - Fabian
Bug#974090: [Pkg-fonts-devel] Bug#974090: fonts-gfs-artemisia breaks lcdf-typetools autopkgtest: lots of failures
Am 2020-11-09 20:58, schrieb Paul Gevers: # Failed test 'Testing stderr' # at debian/tests/cfftot1.t line 24. # got: 'cfftot1: /usr/share/fonts/truetype/artemisia/GFSArtemisia.otf: No such file or directory This is looking for an opentype font in the truetype directory, which is quite probably wrong. - Fabian
Bug#972897: libavformat58: provide libavformat-extra package now?
control: tags -1 +patch control: forwarded -1 https://salsa.debian.org/multimedia-team/ffmpeg/-/merge_requests/6 Please review my merge request for a patch. - Fabian signature.asc Description: This is a digitally signed message part
Bug#972896: libgs9-common: please relax the dependency on fonts-urw-base35
Am 2020-10-26 11:01, schrieb Jonas Smedegaard: Your signalling that you think I am an idiot does not help here. I absolutely do not think you are an idiot! Quite the contrary, I assume you to be a very intelligent person, thus I wonder why you ask me to repeat my arguments over and over again. Please keep such provocations to yourself! Indeed, sorry for the provocation. I will have ghostscript tell dh_linktree to relax its checks to only be concerned about paths (not content), which should lead to somewhat relaxed versioning of dependency for future migrations. I believe this is the right thing to do. Thanks for that! - Fabian
Bug#972896: libgs9-common: please relax the dependency on fonts-urw-base35
Am 2020-10-26 09:56, schrieb Jonas Smedegaard: You cannot mean to sugges that ghostscript should violate Debian Policy by ignoring the integrity of symlinks, so it must be something else. Please elaborate what you have in mind. *Sigh!* Please reconsider letting unrelated packages migrate to testing by not applying an upper bound to their version number in your package's dependencies. Please expect other package maintainers to behave well and not change file paths which would break your package but require not much more than a trivial rebuild. Thanks! - Fabian
Bug#972896: libgs9-common: please relax the dependency on fonts-urw-base35
Am 2020-10-25 22:48, schrieb Jonas Smedegaard: It seems to me that the concrete delay is caused by ghostscript in _testing_ having tight dependency on the font, and that it therefore cannot be solved by an upload to unstable - only by ghostscript migrating to testing (or ghostscript getting kicked out of testing). That said, relaxing the dependency would avoid similar delays in the future. Indeed, it is the ghostscript package in testing that blocks the migration of the font package due to its strict dependencies which limit the font package's version number to an upper bound. Both packages are currently forced to migrate in lockstep. The reason for the tight dependency is to ensure the integrity of the symlinking between the font package and Ghostscript. It is resolved by dh_linktree which explains it like this in its man page: I see. But by applying this measure you prevent the usual case, i.e. packages migrating independently, in order to avoid the very uncommon and unexpected case, i.e. file locations getting out of sync. Please reconsider. - Fabian
Bug#972897: libavformat58: provide libavformat-extra package now?
Package: libavformat58 Version: 7:4.3.1-4 Severity: wishlist Hi there, is there any reason why we don't yet provide an additional libavformat-extra package which could contain support for the SMB protocol? We already do so for libavcodec-extra and libavfilter-extra, so I don't see any reason why we shouldn't add another -extra flavor to provide for a popular feature. The next possible opportunity could be the next SONAME bump in one of the libraries when we have to go through the NEW queue anyway. Thoughts? Cheers, - Fabian -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'experimental'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.8.0-3-amd64 (SMP w/8 CPU threads) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages libavformat58 depends on: ii libavcodec58 7:4.3.1-4 ii libavutil56 7:4.3.1-4 ii libbluray2 1:1.2.0-3 ii libbz2-1.0 1.0.8-4 ii libc62.31-4 ii libchromaprint1 1.5.0-1 ii libgme0 0.6.3-2 ii libgnutls30 3.6.15-4 ii libopenmpt0 0.4.11-1 ii librabbitmq4 0.10.0-1 ii libsrt1-gnutls 1.4.1-5+b1 ii libssh-gcrypt-4 0.9.4-1 ii libxml2 2.9.10+dfsg-6.1 ii libzmq5 4.3.3-2+b1 ii zlib1g 1:1.2.11.dfsg-2 libavformat58 recommends no packages. libavformat58 suggests no packages. -- no debconf information
Bug#972896: libgs9-common: please relax the dependency on fonts-urw-base35
Package: libgs9-common Version: 9.52.1~dfsg-1 Severity: important Hi there, the fonts-urw-base35 is currently stuck in unstable and not allowed to migrate to testing because the ghostscript package currently suffers from a completely unrelated RC bug. This is because the libgs9-common package has an overly strict dependecy on fonts-urw-base35: Depends: fonts-urw-base35 (<< 20170801.1.0~), fonts-urw-base35 (>= 20170801.1) Thus, the font package is punished for a bug in ghostscript that's not even related to the font at all. Please relax the dependency to just the "fonts-urw-base35 (>= 20170801.1)" part so that newer versions of the font than the one the ghostscript package was built with are allowed to migrate to testing. Thanks! - Fabian -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'experimental'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.8.0-3-amd64 (SMP w/8 CPU threads) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages libgs9-common depends on: ii fonts-urw-base35 20170801.1-3 Versions of packages libgs9-common recommends: ii fonts-droid-fallback 1:6.0.1r16-1.1 libgs9-common suggests no packages. -- no debconf information
Bug#972783: prboom-plus: Hangs after screen setup without strace
What happens if you simply run prboom-plus in a terminal, without any parameters? Von meinem Samsung Galaxy Smartphone gesendet. Ursprüngliche Nachricht Von: Nicolas Patrois Datum: 23.10.20 14:54 (GMT+01:00) An: Debian Bug Tracking System Betreff: Bug#972783: prboom-plus: Hangs after screen setup without strace Package: prboom-plusVersion: 2:2.5.1.7um+git89-1Severity: normalTags: upstreamDear Maintainer,Because my computer gets old, I run prboom-plus with taskset.It hangs and I can’t see the fullscreen, I can just in xterm see that thefullscreen is ready.I tried to discover what was the bug with strace and it happens that I can playprboom-plus when it runs under strace.Here is the full command line:strace taskset -ac 0 doom2.sh -file/usr/local/share/games/doom/wadoom2/icarus/ICARUS.WADdoom2.sh is a shell script that executes a Perl script that runs prboom-plus.It used to run correctly yesterday.-- System Information:Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable')Architecture: i386 (i686)Kernel: Linux 5.7.0-1-686-pae (SMP w/3 CPU threads)Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULELocale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR:fr:en_GB:enShell: /bin/sh linked to /bin/dashInit: systemd (via /run/systemd/system)LSM: AppArmor: enabledVersions of packages prboom-plus depends on:ii libc6 2.31-4ii libdumb1 1:0.9.3-6+b3ii libfluidsynth2 2.1.5-1ii libgcc-s1 10.2.0-15ii libgl1 1.3.2-1ii libglu1-mesa [libglu1] 9.0.1-1ii libmad0 0.15.1b-10ii libpcre3 2:8.39-13ii libportmidi0 1:217-6ii libsdl2-2.0-0 2.0.12+dfsg1-4ii libsdl2-image-2.0-0 2.0.5+dfsg1-2ii libsdl2-mixer-2.0-0 2.0.4+dfsg1-2+b1ii libsdl2-net-2.0-0 2.0.1+dfsg1-4+b1ii libstdc++6 10.2.0-15ii libvorbisfile3 1.3.7-1ii zlib1g 1:1.2.11.dfsg-2Versions of packages prboom-plus recommends:ii freedoom 0.12.1-2ii game-data-packager 65Versions of packages prboom-plus suggests:ii ffmpeg 10:4.3.1-dmo3-- no debconf information___Pkg-games-devel mailing listPkg-games-devel@alioth-lists.debian.nethttps://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-games-devel
Bug#972783: prboom-plus: Hangs after screen setup without strace
What happens if you simply run prboom-plus in a terminal, without any parameters? Von meinem Samsung Galaxy Smartphone gesendet. Ursprüngliche Nachricht Von: Nicolas Patrois Datum: 23.10.20 14:54 (GMT+01:00) An: Debian Bug Tracking System Betreff: Bug#972783: prboom-plus: Hangs after screen setup without strace Package: prboom-plusVersion: 2:2.5.1.7um+git89-1Severity: normalTags: upstreamDear Maintainer,Because my computer gets old, I run prboom-plus with taskset.It hangs and I can’t see the fullscreen, I can just in xterm see that thefullscreen is ready.I tried to discover what was the bug with strace and it happens that I can playprboom-plus when it runs under strace.Here is the full command line:strace taskset -ac 0 doom2.sh -file/usr/local/share/games/doom/wadoom2/icarus/ICARUS.WADdoom2.sh is a shell script that executes a Perl script that runs prboom-plus.It used to run correctly yesterday.-- System Information:Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable')Architecture: i386 (i686)Kernel: Linux 5.7.0-1-686-pae (SMP w/3 CPU threads)Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULELocale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR:fr:en_GB:enShell: /bin/sh linked to /bin/dashInit: systemd (via /run/systemd/system)LSM: AppArmor: enabledVersions of packages prboom-plus depends on:ii libc6 2.31-4ii libdumb1 1:0.9.3-6+b3ii libfluidsynth2 2.1.5-1ii libgcc-s1 10.2.0-15ii libgl1 1.3.2-1ii libglu1-mesa [libglu1] 9.0.1-1ii libmad0 0.15.1b-10ii libpcre3 2:8.39-13ii libportmidi0 1:217-6ii libsdl2-2.0-0 2.0.12+dfsg1-4ii libsdl2-image-2.0-0 2.0.5+dfsg1-2ii libsdl2-mixer-2.0-0 2.0.4+dfsg1-2+b1ii libsdl2-net-2.0-0 2.0.1+dfsg1-4+b1ii libstdc++6 10.2.0-15ii libvorbisfile3 1.3.7-1ii zlib1g 1:1.2.11.dfsg-2Versions of packages prboom-plus recommends:ii freedoom 0.12.1-2ii game-data-packager 65Versions of packages prboom-plus suggests:ii ffmpeg 10:4.3.1-dmo3-- no debconf information___Pkg-games-devel mailing listPkg-games-devel@alioth-lists.debian.nethttps://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-games-devel
Bug#972104: RFS: comic-neue/2.51-1 [Team] -- less horrible remake of Comic Sans
Hi Gürkan, I am looking for a sponsor for my package "comic-neue": I have just found this by pure coincidence. * Vcs : https://salsa.debian.org/fonts-team/fonts-comic-neue Could you please push your working branch to the GIT repo and file a merge request there? There are other changes that I'd like to get into the package before the next upload. Thanks! - Fabian
Bug#968555: ffmpeg: please disable build dep on libpocketsphinx-dev for alpha
Am 2020-08-17 11:30, schrieb Michael Cree: Ffmpeg does not build on alpha as it currently depends on libpocketsphinx-dev but pocketsphinx does not build on alpha due to long standing test suite failures. I see the build dependency has been removed on many other arches including some release arches, and it would be nice if the same could be done for alpha. Too bad we don't have architecture wildcards for use in Build-Depends that provide more detail of the used architecture, like e.g. [any-littleendian] or [any-32bit]. Or do we? - Fabian
Bug#962074: blender: crash in an assertion and doubt about CMAKE_BUILD_TYPE
Hi there, Am 2020-06-30 13:49, schrieb Matteo F. Vescovi: I'm spending few days of [VAC] so I'm afk. Feel free to provide me a patch to fix the issue and I'll more than happy to apply it to the package once I'm back, as already done in the past. ;-) will adding the line export DEB_CPPFLAGS_MAINT_APPEND = -DNDEBUG to debian/rules already do the fix? - Fabian
