Bug#1065094: pdftex.1: some remarks and editorial changes for this man page
Control: tags -1 + fixed-upstream On 29.02.24 19:33, Bjarni Ingi Gislason wrote: Hi, Dear Maintainer, here are some notes and editorial fixes for the manual. Karl Berry told me "I installed the pdftex.man patch, with a few minor adjustments for the current source." I tag as fixed in upstream. H. -- -- Testmail OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1052298: metafun broken?
On 27.10.23 22:31, Siep Kroonenberg wrote: Hello, The standalone context is mostly free from mkii, but cont-tmf.zip still has most of the legacy stuff, which will mostly be added back in, in the form of a context-legacy package for TL. I find sorting things out and creating / modifying the .tlpsrc definitions for the context packages a tricky business; it is going a lot slower than I hoped and expected. I noticed that there is now a package context-legacy.r69173.tar.xz in the TL/archive subdir . I contains a lot of stuff "tex/context/patterns/mkii". I guess I have to package that and upload it into Debian. Please confirm. Hilmar -- Testmail OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064517: texlive-bin: CVE-2024-25262
On 23.02.24 16:31, Moritz Mühlenhoff wrote: Hello Moritz, The following vulnerability was published for texlive-bin. CVE-2024-25262[0]: | texlive-bin commit c515e was discovered to contain heap buffer | overflow via the function ttfLoadHDMX:ttfdump. This vulnerability | allows attackers to cause a Denial of Service (DoS) via supplying a | crafted TTF file. I'll upload tl-bin -9 soon. Do we need a fix in Debian stable too? Hilmar -- Testmail OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1060859: [Pkg-nagios-devel] Bug#1060859: monitoring-plugins-check-logfiles: Add abiltiy to search systemd journals by syslog identifiers
On 15.01.24 20:32, John Lines wrote: Hi, The attached patch allows an argument of --type=journald:identifier='postfix/smtp' to be specified. The patch can't be applied as it is: the check_logfiles file is generated during build. I moved the code to the appropriate source files, new package is here. Please test: https://www.preining.info/~hille42/ Hilmar -- Testmail OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1057407: texworks: Intent to drop poppler-qt6 on i386
Control: tags -1 + pending On 04.12.23 14:43, Jeremy Bícha wrote: Hi, texworks is the only package that uses poppler's Qt6 in Debian. Please let me know if it's ok with you if texworks is no longer built for i386 in Debian. The debian-devel-announce of today[1] reads: "Maintainers who wish to drop i386 support can do so *after* coordination with the reverse (build) dependencies of their package, as with dropping support for any other architecture." As no package depend on texworks, I'll drop i386 as requested. If you have a patch for me I'll be glad. Hilmar [1] https://lists.debian.org/debian-devel-announce/2023/12/msg3.html -- Testmail OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1056587: texlive-latex-base: some math characters get replaced as of Debian's TeX Live 2023
On 11/23/23 15:53, Vincent Lefevre wrote: On 2023-11-23 15:44:17 +0100, Vincent Lefevre wrote: Hi Vincent, \documentclass{article} \pagestyle{empty} \begin{document} $x'$ ; $\oplus$ ; $\ominus$ ; $\otimes$ ; $\ell$ ; OK. \end{document} I get the following: x0 ; ⊕ ; ; ⊗ ; ` ; OK. instead of x′ ; ⊕ ; ⊖ ; ⊗ ; ℓ ; OK. I forgot to say that these are the characters obtained with pdftotext (the issue is not with the glyphs, but with the textual part). Sorry, I'm failing to reproduce: hille@sid:~$ pdflatex a This is pdfTeX, Version 3.141592653-2.6-1.40.25 (TeX Live 2023/Debian) (preloaded format=pdflatex) restricted \write18 enabled. entering extended mode (./a.tex LaTeX2e <2023-06-01> patch level 1 L3 programming layer <2023-08-29> (/usr/share/texlive/texmf-dist/tex/latex/base/article.cls Document Class: article 2023/05/17 v1.4n Standard LaTeX document class (/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo)) (/usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def) (./a.aux) [1{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}] (./a.aux) ) xmf-dist/fonts/type1/public/amsfonts/cm/cmsy7.pfb> Output written on a.pdf (1 page, 36600 bytes). Transcript written on a.log. hille@sid:~$ pdftotext a.pdf hille@sid:~$ cat a.txt x′ ; ⊕ ; ⊖ ; ⊗ ; ℓ ; OK. , which looks good, IMHO. Could you add \listfiles to the top of your document and post the logfile here? Hilmar -- Testmail OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1056204: nmu: texlive-bin_2023.20230311.66589-7
On 11/19/23 00:40, Adrian Bunk wrote: Hi Adrian, A proper fix would be either to: 1. patch the version check out of texlive-bin (preferred), or Did so, see [1]. I did not remove the check completely, I just un-tightened the version. I can confirm that a texlive package linked on testing (zlib 1.2.x) is installable on unstable (zlib 1.3.x). I hope this solves the issue for the next 20 years. I intend to upload new packages tomorrow, this NMU bug can be closed, once this has been done. I just noticed that we had this issue already 13 years ago. [2] Hilmar [1] https://github.com/debian-tex/texlive-bin/blob/master/debian/patches/untighten_version_check_zlib.diff [2] https://lists.debian.org/debian-tex-maint/2010/06/msg00071.html -- Testmail OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1056204: nmu: texlive-bin_2023.20230311.66589-7
On 11/19/23 00:40, Adrian Bunk wrote: On Sat, Nov 18, 2023 at 11:51:15PM +0100, Hilmar Preuße wrote: On 11/18/23 20:18, Samuel Thibault wrote: Hi all, nmu texlive-bin_2023.20230311.66589-7 . ANY . unstable . -m "Rebuild against new zlib" Thanks for filing the NMU bug. So a binnmu of the texlive-bin source package seems needed on all archs to fix installing texlive-binaries. I tested if recompiling solves the issue and it does. Hence I bump severity of the NMU bug the get a solution ASAP. I don't see how a binNMU would solve the problem. A proper fix would be either to: 1. patch the version check out of texlive-bin (preferred), or I can patch out that version check as found by Samuel, but I don't see how that would solve the core dump or the SIGABRT, which was reported. I hope lua_error(L) is not the equivalent of "exit with SIGABRT". ;-) I still suspect that something broke in the API of zlib, the zlib people are not aware of. 2. ensure texlive-bin has package dependencies that match this runtime check The zlib people, did not change the API version or created a version statement in the depends line like "Depends: ... zlib1g (>= 1:1.3)", hence I'd add an artificial "Breaks: ... zlib1g (<= 1:1.2.3)" to my texlive-binaries package to make sure 1.3 is in place, when the new texlive-binaries comes in. Correct? And it also might affects users directly, without proper dependencies e.g. a bookworm -> trixie upgrade might end up with the following order (among many other things happening during the upgrade): 1. zlib gets upgraded 2. the tex-common trigger runs 3. texlive-bin gets upgraded If this is permitted by the dependencies, then step 2 must not fail. I'd rather expect that the triggers run at the end of the setup process, i.e. after all packages replaced their files. At least this was the original ideal behind them IIRC. Hilmar -- Testmail OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1056204: nmu: texlive-bin_2023.20230311.66589-7
Control: severity -1 important Control: block 1056183 by -1 On 11/18/23 20:18, Samuel Thibault wrote: Hi Samuel, nmu texlive-bin_2023.20230311.66589-7 . ANY . unstable . -m "Rebuild against new zlib" Thanks for filing the NMU bug. So a binnmu of the texlive-bin source package seems needed on all archs to fix installing texlive-binaries. I tested if recompiling solves the issue and it does. Hence I bump severity of the NMU bug the get a solution ASAP. Hilmar -- Testmail OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1055901: [Pkg-raspi-maintainers] Bug#1055901: raspi-firmware: postinst fails, makes bad assumption about existence of /boot/firmware/
On 11/13/23 23:20, Cyril Brulebois wrote: Hilmar Preusse (2023-11-13): Hi, the package fails to install on my system. I simply assumes that /boot/firmware is a mount point and fails if this is not the case. If /boot/firmware is expected to be a mount point the installer should have created it. The system was once installed as bullseye and later upgraded to bookworm. What exactly is your system? What is that rpt suffix? It is an raspi3, not sure if that is the needed information, here comes the apt-cache policy hille@rasppi1:~ $ apt-cache policy raspi-firmware raspi-firmware: Installed: 1:1.20231024+ds-1+rpt1 Candidate: 1:1.20231024+ds-1+rpt1 Version table: *** 1:1.20231024+ds-1+rpt1 500 500 http://archive.raspberrypi.org/debian bookworm/main arm64 Packages 500 http://archive.raspberrypi.org/debian bookworm/main armhf Packages 100 /var/lib/dpkg/status 1.20220830+ds-1 500 500 http://deb.debian.org/debian bookworm/non-free-firmware arm64 Packages 500 http://deb.debian.org/debian bookworm/non-free-firmware armhf Packages Does that help you anyhow? Hilmar -- Testmail OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1055846: texlive-extra-utils: spix is listed in the package description but not installed in package files
Control: severity -1 normal On 11/12/23 15:55, Vincent-Xavier JUMEL wrote: Hi, While I wanted to give spix a try (https://spix.readthedocs.io/en/latest/install/) I've trusted Debian to package it in this specific package, which is reported by `apt show texlive-extra-utils | grep spix` Instead, my shell reported no `/usr/bin/spix` and `dpkg -L texlive-extra-utils | grep spix` shows that spix is installed but misses a link in `/usr/bin/` Could you please fix it ? You may use the script even from the actual location, so the link in /usr/bin ist just for convenience. I'll update the link list soon. Lowering severity to normal. Hilmar -- Testmail OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1055901: Acknowledgement (raspi-firmware: postinst fails, makes bad assumption about existence of /boot/firmware/)
On 11/13/23 23:03, Debian Bug Tracking System wrote: Hi, Thank you for filing a new Bug report with Debian. You can follow progress on this Bug here: 1055901: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055901. Here is the error message I get: hille@rasppi1:~ $ sudo apt -f install Reading package lists... Done Building dependency tree... Done Reading state information... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. 2 not fully installed or removed. After this operation, 0 B of additional disk space will be used. Setting up raspi-firmware (1:1.20231024+ds-1+rpt1) ... Error: missing /boot/firmware, did you forget to mount it? dpkg: error processing package raspi-firmware (--configure): installed raspi-firmware package post-installation script subprocess returned error exit status 1 dpkg: dependency problems prevent configuration of rpi-eeprom: rpi-eeprom depends on raspi-firmware; however: Package raspi-firmware is not configured yet. dpkg: error processing package rpi-eeprom (--configure): dependency problems - leaving unconfigured Processing triggers for initramfs-tools (0.142) ... Errors were encountered while processing: raspi-firmware rpi-eeprom E: Sub-process /usr/bin/dpkg returned an error code (1) Hilmar -- Testmail OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1051236: proftpd-core: SSH key exchanges fail unexpectedly with "unable to write X bytes of raw data"
On 9/4/23 22:10, Jeremy Lecour wrote: Hi Jeremy, After upgrading to Debian 12, my SFTP client stopped working with errors when connecting. I've opened a GitHub issue and the problem has been solved. https://github.com/proftpd/proftpd/issues/1694 It will even be backported to the 1.3.8 branch, so I hope that it might be available in an upcoming update in Debian 12. I've put test packages here [1]. Could you try them and report back if they solve the issue? Hilmar [1] https://freeshell.de/~hille42/debian_1051236/ -- Testmail OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1054218: texlive-latex-base: pdflatex failures on big-endian architectures (s390x)
On 10/30/23 11:52, Hilmar Preuße wrote: Hi Stuart, I was told not to use that URL, so here is a new one https://freeshell.de/~hille42/debian_1054218/ Did you find the time to test the fix? Hilmar -- Testmail OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1055233: Several math features break in new version
On 11/2/23 16:17, Kumar Appaiah wrote: Hello Kumar, I've inserted a begin-math/end-math symbol since I think you left one out. Proceed, with fingers crossed. mtx-context | fatal error: return code: 1 Please let me know what I can do to help. I am downgrading temporarily though. I don't use ConTeXt at all, hence I can't tell, if this is function as designed or a bug. Would you be so kind to contact the people of the NTG Mailing list (ntg-cont...@ntg.nl)? Maybe they have a solution for you or at least clarify if this is a bug or not. Thanks, Hilmar -- Testmail OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1055078: autoproject: autopkgtest fails since texinfo 1.7
Control: severity -1 important Control: tags -1 + patch Control: retitle -1 autopkgtest fails since texinfo 7.1 On 10/30/23 23:53, Hilmar Preusse wrote: Hi all, No, I don't have a patch for this yet. I'll try to look into this, but can' promise anything. Patch is attached, tagging. H. -- Testmail diff -Nru autoproject-0.20/debian/changelog autoproject-0.20/debian/changelog --- autoproject-0.20/debian/changelog 2021-10-01 02:19:30.0 +0200 +++ autoproject-0.20/debian/changelog 2023-11-01 23:35:44.0 +0100 @@ -1,3 +1,9 @@ +autoproject (0.20-15) unstable; urgency=medium + + * Don't use @setfilename in TeXInfo file, if file is included. + + -- Hilmar Preusse Wed, 01 Nov 2023 23:35:44 +0100 + autoproject (0.20-14) unstable; urgency=medium * QA upload. diff -Nru autoproject-0.20/debian/patches/40_not_use_setfilename_when_include.patch autoproject-0.20/debian/patches/40_not_use_setfilename_when_include.patch --- autoproject-0.20/debian/patches/40_not_use_setfilename_when_include.patch 1970-01-01 01:00:00.0 +0100 +++ autoproject-0.20/debian/patches/40_not_use_setfilename_when_include.patch 2023-11-01 22:41:59.0 +0100 @@ -0,0 +1,8 @@ +--- autoproject-0.20.orig/lib/all/all/all/gpl.texinfo autoproject-0.20/lib/all/all/all/gpl.texinfo +@@ -1,4 +1,4 @@ +-@setfilename gpl.info ++@comment @setfilename gpl.info + + @unnumbered GNU GENERAL PUBLIC LICENSE + @center Version 2, June 1991 diff -Nru autoproject-0.20/debian/patches/series autoproject-0.20/debian/patches/series --- autoproject-0.20/debian/patches/series 2021-10-01 02:19:30.0 +0200 +++ autoproject-0.20/debian/patches/series 2023-11-01 22:42:27.0 +0100 @@ -1,3 +1,4 @@ 10_fix-manpage.patch 20_modernize-AC_INIT.patch 30_remove_@refill_command.patch +40_not_use_setfilename_when_include.patch OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1055111: ffmpeg FTBFS: makeinfo: Undefined subroutine ::Config::set_from_init_file called at doc/t2h.pm
On 10/31/23 17:21, Adrian Bunk wrote: Hi, https://buildd.debian.org/status/logs.php?pkg=ffmpeg=7%3A6.0-8 ... makeinfo --html -I doc --no-split -D config-not-all --init-file=/<>/doc/t2h.pm --output doc/ffmpeg.html /<>/doc/ffmpeg.texi makeinfo: error parsing /<>/doc/t2h.pm: Undefined subroutine ::Config::set_from_init_file called at /<>/doc/t2h.pm line 24. make[2]: *** [/<>/doc/Makefile:70: doc/ffmpeg.html] Error 1 Could it be caused the upload of TeXinfo 7.1, did it work with TeXinfo from testing? I don't see any change for this in the /usr/share/doc/texinfo/NEWS.gz . Hilmar -- Testmail OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#115503: texi2dvi: source file directory included in search path
On 10/13/01 23:21, Florian Weimer wrote: Hi Florian, texi2dvi includes the source file directory in the TeX search path. This is quite unusual for programs processing -I options (such as C compilers), and even makeinfo doesn't do that. Furthermore, it's not possible to remove that directory from the search path. Could you check if the issue has been solved in the meantime? Thanks, Hilmar -- Testmail OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#115503: texi2dvi: source file directory included in search path
On 10/13/01 23:21, Florian Weimer wrote: Hi Florian, texi2dvi includes the source file directory in the TeX search path. This is quite unusual for programs processing -I options (such as C compilers), and even makeinfo doesn't do that. Furthermore, it's not possible to remove that directory from the search path. Could you check if the issue has been solved in the meantime? Thanks, Hilmar -- Testmail OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1054218: texlive-latex-base: pdflatex failures on big-endian architectures (s390x)
Hi, I was told not to use that URL, so here is a new one https://freeshell.de/~hille42/debian_1054218/ Hilmar 29.10.2023 18:12:25 Hilmar Preuße : > On 10/19/23 14:20, Stuart Prescott wrote: > > Hi Stuart, > >> The unittests of the 'plastex' package run pdflatex to generate some >> figures, and then extract the text from the figures to verify that >> various implementation details of the package are working. These tests >> pass on all release architectures except s390x. They also fail on ppc64. >> The common feature of the failures is that the architecture is >> big-endian. >> > > I've got a patch from upstream, which /seems/ to solve the issue. Packages > for PPC64 are here [1]. If you need packages for s390x, the debian.tar.xz and > the dsc file are there too. Please be so kind to test on s390 too. Please be > aware that simply copying the pdftex binary out of the package is not > sufficient, the format file needs to re-generated too, better install the > packages. > > Hilmar > > [1] https://www.beckmann.pro/~hille42/debian_1054218/ > -- > Testmail
Bug#1054218: texlive-latex-base: pdflatex failures on big-endian architectures (s390x)
On 10/19/23 14:20, Stuart Prescott wrote: Hi Stuart, The unittests of the 'plastex' package run pdflatex to generate some figures, and then extract the text from the figures to verify that various implementation details of the package are working. These tests pass on all release architectures except s390x. They also fail on ppc64. The common feature of the failures is that the architecture is big-endian. I've got a patch from upstream, which /seems/ to solve the issue. Packages for PPC64 are here [1]. If you need packages for s390x, the debian.tar.xz and the dsc file are there too. Please be so kind to test on s390 too. Please be aware that simply copying the pdftex binary out of the package is not sufficient, the format file needs to re-generated too, better install the packages. Hilmar [1] https://www.beckmann.pro/~hille42/debian_1054218/ -- Testmail OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1054218: texlive-latex-base: pdflatex failures on big-endian architectures (s390x)
On 10/19/23 14:20, Stuart Prescott wrote: Hi Stuart, Attached: test.tex (one of the little .tex files plastex generates in its tests) amd64.pdf (output of "pdflatex test.tex" on amd64) s390x.pdf (output of "pdflatex test.tex" on s390x) I could reduce the input file to the minimal LaTeX file and the phenomenon is still visible. Interestingly it does not appear, when using plain pdfTeX. H. -- Testmail OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1051497: closed by Debian FTP Masters (reply to Hilmar Preusse ) (Bug#1051497: fixed in texlive-extra 2023.20231007-1)
On 10/21/23 02:12, Al Ma wrote: Hi Al Ma, to be honest: I don't really care, which version of a specific (LaTeX) package I do package. Once a specific package version has made its way to CTAN, I assume that the TeX Live people will pick it up and I'll package it later on. Looking at the tar ball hille42@hz:~/devel/TeXLive/zzz_upstream_raw/ctan.mirror.norbert-ruehl.de/archive$ ls -l *newtx.* -rw-rw-r-- 1 hille42 hille42 1053468 Aug 26 23:46 newtx.doc.r68071.tar.xz lrwxrwxrwx 1 hille42 hille42 23 Aug 26 23:46 newtx.doc.tar.xz -> newtx.doc.r68071.tar.xz -rw-rw-r-- 1 hille42 hille42 6792716 Aug 26 23:46 newtx.r68071.tar.xz lrwxrwxrwx 1 hille42 hille42 19 Aug 26 23:46 newtx.tar.xz -> newtx.r68071.tar.xz ...I used for creating the deb package I know that it is dated August 2023 and I'd assume that it is the latest version from CTAN [1] however I didn't check that. I now checked the file versions of the CTAN package and compared to the file versions in Debian and they are identical. So, we look at v1.726 in Debian. Yes, the statements \fileversion{1.723} and \fileversion{1.724} in the sty files are not very helpful, but this is now my fault. Hilmar [1] https://ctan.org/pkg/newtx Thank you for a quick answer. Note that the version of the package NewTX (most likely, 1.726 (cf. https://ctan.org/pkg/newtx), since all the mentioned bugs are repaired, whereas it was not the case for a few immediately preceeding versions) deviates from the version of the file newtx.sty (namely, still 1.724). My question concerns the version of the whole NewTX package and not the versions of the constituent files. (Since you wrote that the present bug report 1051497 is repaired, I highly believe you that you put 1.726 into texlive-fonts-extra, and what I'd like to know is how to check this in the future.) -- Testmail OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1042024: RFS: hintview/1.3.1-1 [ITP] -- Program to view HINT files
Control: block 1041668 by -1 On 7/25/23 23:12, Hilmar Preuße wrote: Package: sponsorship-requests Severity: wishlist Dear mentors, Add blocking statement.
Bug#1042024: RFS: hintview/1.3.1-1 [ITP] -- Program to view HINT files
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "hintview": * Package name : hintview Version : 1.3.1-1 Upstream contact : Martin Ruckert * URL : https://hint.userweb.mwn.de/hint/hintview.html * License : GPL-2+ * Vcs : https://github.com/debian-tex/hintview Section : text The source builds the following binary packages: hintview - Program to view HINT files To access further information about this package, please visit the following URL: https://mentors.debian.net/package/hintview/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/h/hintview/hintview_1.3.1-1.dsc Changes for the initial release: hintview (1.3.1-1) unstable; urgency=medium . * Initial release. (Closes: #1041668) The HINT file format is an alternative to the DVI or PDF format that was designed specifically for on screen reading of documents. Especially on mobile devices, reading DVI or PDF documents can be cumbersome. Mobile devices are available in a large variety of sizes but are typically not large enough to display documents formatted for letter-size paper. To compensate for the limitations of a small screen, users are used to alternate between landscape (few long lines) and portrait (more short lines) mode. The HINT format supports variable and varying screen sizes leveraging the ability of TEX to format a document for (almost) arbitrary values of \hsize and \vsize. Regards, -- Testmail
Bug#1038000: bookworm-pu: package texlive-bin/2022.20220321.62855-5.1+deb12u1
On 6/28/23 09:01, Jonathan Wiltshire wrote: Hi Jonathan, When do you expect the bugs to be closed in unstable? I've pushed the new texlive-bin and the context package to unstable. Hilmar -- Testmail
Bug#1037347: unblock: pssh/2.3.5-2, dvisvgm/3.0.4-1, latexmk/1:4.80-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Unfortunately I've uploaded pssh, dvisvgm & latexmk to unstable, a while ago, although the packages were not intended for bookworm. I expected that they will migrate to testing, once bookworm is released. All packages still report that they are blocked. Please unblock so they can migrate to testing now. Many thanks! Hilmar unblock pssh/2.3.5-2 unblock dvisvgm/3.0.4-1 unblock latexmk/1:4.80-1
Bug#1035946: RFS: justbuild/1.1.0-1 [ITP] -- Justbuild generic build system
On 5/11/23 15:11, Oliver Reiche wrote: Hi, The source builds the following binary packages: justbuild - Justbuild generic build system To access further information about this package, please visit the following URL: https://mentors.debian.net/package/justbuild/ If you look at that page you see a few points, which needs to be addressed. Please fix at least the lintian errors and warnings. The initial upload should not go to testing, either use unstable or experimental. H. -- Testmail
Bug#1035313: pstricks causes gray output of xdvi
On 4/30/23 20:28, Al Ma wrote: Hi, Feed mwe.tex containing \documentclass{article} \usepackage{pstricks} \begin{document} Test \end{document} Thanks for the report. The issue seems to have been resolved recently. Could you look for the line \pstVerb{0.8 setlinewidth 0 setgray}%default setting (needed for lualatex) (1 line) in pstricks.tex (should be around line 4250) and replace it by: +%%% changed 20230430 by hv, confuses otherwise the dvi color handling +\ifluatex\pstVerb{0.8 setlinewidth 0 setgray}\fi%default setting (needed for lualatex) +%%% (3 lines). Does that solve your issue? Hilmar -- Testmail
Bug#1034383: biber: Documentation file biber.pdf not TeXed correctly
Control: tags -1 + pending On 4/13/23 22:18, Dylan Thurston wrote: Hi, The file /usr/share/doc/biber.pdf has evidently not been run through LaTeX enough times: all cross-references show up as '??'. For any reason we always ignored the LaTeX Warning: Label(s) may have changed. Rerun to get cross-references right. messages in the build log. Bug is solved in git, will be fixed post-bookworm. Hilmar -- Testmail
Bug#1034100: Acknowledgement (unblock: texlive-base/2022.20230122-3)
Control: tags -1 - moreinfo Many thanks for help. Hilmar 09.04.2023 10:12:36 Sebastian Ramacher : > Control: tags -1 moreinfo confirmed > > On 2023-04-09 00:29:55 +0200, Hilmar Preuße wrote: >> On 4/9/23 00:24, Debian Bug Tracking System wrote: >> >> Hi, >> >>> You can follow progress on this Bug here: 1034100: >>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034100. >>> >> Attached is the promised debdiff. > > Please go ahead and remove the moreinfo tag once the package is > available in unstable. > > Cheers > >> >> Hilmar >> -- >> Testmail > >> diff -Nru texlive-base-2022.20230122/debian/changelog >> texlive-base-2022.20230122/debian/changelog >> --- texlive-base-2022.20230122/debian/changelog 2023-02-15 >> 14:35:08.0 +0100 >> +++ texlive-base-2022.20230122/debian/changelog 2023-04-01 >> 12:57:29.0 +0200 >> @@ -1,3 +1,12 @@ >> +texlive-base (2022.20230122-3) UNRELEASED; urgency=medium >> + >> + * Add Romanian debconf translation by Remus-Gabriel Chelu >> + (Closes: #1033738). >> + * Add patch to fix hyphenation penalties in german language >> + (Closes: #1034038). >> + >> + -- Hilmar Preusse Sat, 01 Apr 2023 12:57:29 +0200 >> + >> texlive-base (2022.20230122-2) unstable; urgency=medium >> >> [ Jelmer Vernooij ] >> diff -Nru texlive-base-2022.20230122/debian/patches/1034038 >> texlive-base-2022.20230122/debian/patches/1034038 >> --- texlive-base-2022.20230122/debian/patches/1034038 1970-01-01 >> 01:00:00.0 +0100 >> +++ texlive-base-2022.20230122/debian/patches/1034038 2023-04-01 >> 12:57:29.0 +0200 >> @@ -0,0 +1,11 @@ >> +--- >> texlive-base-2022.20230122.orig/texmf-dist/tex/generic/babel/babel-transforms.lua >> >> texlive-base-2022.20230122/texmf-dist/tex/generic/babel/babel-transforms.lua >> +@@ -364,7 +364,7 @@ >> + goto next >> + >> + elseif mode == 1 and crep and (crep.pre or crep.no or crep.post) >> then >> +- d = node.new(7, 0) -- (disc, discretionary) >> ++ d = node.new(7, 3) -- (disc, regular) >> + d.pre = Babel.str_to_nodes(crep.pre, matches, item_base) >> + d.post = Babel.str_to_nodes(crep.post, matches, item_base) >> + d.replace = Babel.str_to_nodes(crep.no, matches, item_base) >> diff -Nru texlive-base-2022.20230122/debian/patches/series >> texlive-base-2022.20230122/debian/patches/series >> --- texlive-base-2022.20230122/debian/patches/series 2023-02-15 >> 14:16:01.0 +0100 >> +++ texlive-base-2022.20230122/debian/patches/series 2023-04-01 >> 12:57:29.0 +0200 >> @@ -25,3 +25,4 @@ >> python3-shebang >> debian-fix-quote-in-quote >> update_epspdf_luascript >> +1034038 >> diff -Nru texlive-base-2022.20230122/debian/po/ro.po >> texlive-base-2022.20230122/debian/po/ro.po >> --- texlive-base-2022.20230122/debian/po/ro.po 1970-01-01 >> 01:00:00.0 +0100 >> +++ texlive-base-2022.20230122/debian/po/ro.po 2023-04-01 >> 12:55:00.0 +0200 >> @@ -0,0 +1,77 @@ >> +# Mesajele în limba română pentru pachetul texlive-base. >> +# Romanian translation of texlive-base. >> +# Copyright © 2023 THE PACKAGE'S COPYRIGHT HOLDER >> +# This file is distributed under the same license as the texlive-base >> package. >> +# >> +# Remus-Gabriel Chelu , 2023. >> +# >> +# Cronologia traducerii fișierului „texlive-base”: >> +# Traducerea inițială, făcută de R-GC, pentru versiunea texlive-base >> 2022.20230122-2(2012-04-24). >> +# Actualizare a traducerii pentru versiunea Y, făcută de X, Y(anul). >> +# >> +msgid "" >> +msgstr "" >> +"Project-Id-Version: texlive-base 2022.20230122-2\n" >> +"Report-Msgid-Bugs-To: texlive-b...@packages.debian.org\n" >> +"POT-Creation-Date: 2012-04-24 14:30+0900\n" >> +"PO-Revision-Date: 2023-03-26 17:57+0200\n" >> +"Last-Translator: Remus-Gabriel Chelu \n" >> +"Language-Team: Romanian \n" >> +"Language: ro\n" >> +"MIME-Version: 1.0\n" >> +"Content-Type: text/plain; charset=UTF-8\n" >> +"Content-Transfer-Encoding: 8bit\n" >> +"Plural-Forms: nplurals=3; plural=(n==1 ? 0 : n==0 || (n!=1 && n%100>=1 && " >> +"n%100<=19) ? 1 : 2);\n" >> +"X-Bugs: Report translation errors to the Language-Team a
Bug#1034100: Acknowledgement (unblock: texlive-base/2022.20230122-3)
On 4/9/23 00:24, Debian Bug Tracking System wrote: Hi, You can follow progress on this Bug here: 1034100: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034100. Attached is the promised debdiff. Hilmar -- Testmail diff -Nru texlive-base-2022.20230122/debian/changelog texlive-base-2022.20230122/debian/changelog --- texlive-base-2022.20230122/debian/changelog 2023-02-15 14:35:08.0 +0100 +++ texlive-base-2022.20230122/debian/changelog 2023-04-01 12:57:29.0 +0200 @@ -1,3 +1,12 @@ +texlive-base (2022.20230122-3) UNRELEASED; urgency=medium + + * Add Romanian debconf translation by Remus-Gabriel Chelu + (Closes: #1033738). + * Add patch to fix hyphenation penalties in german language +(Closes: #1034038). + + -- Hilmar Preusse Sat, 01 Apr 2023 12:57:29 +0200 + texlive-base (2022.20230122-2) unstable; urgency=medium [ Jelmer Vernooij ] diff -Nru texlive-base-2022.20230122/debian/patches/1034038 texlive-base-2022.20230122/debian/patches/1034038 --- texlive-base-2022.20230122/debian/patches/1034038 1970-01-01 01:00:00.0 +0100 +++ texlive-base-2022.20230122/debian/patches/1034038 2023-04-01 12:57:29.0 +0200 @@ -0,0 +1,11 @@ +--- texlive-base-2022.20230122.orig/texmf-dist/tex/generic/babel/babel-transforms.lua texlive-base-2022.20230122/texmf-dist/tex/generic/babel/babel-transforms.lua +@@ -364,7 +364,7 @@ + goto next + + elseif mode == 1 and crep and (crep.pre or crep.no or crep.post) then +-d = node.new(7, 0) -- (disc, discretionary) ++d = node.new(7, 3) -- (disc, regular) + d.pre = Babel.str_to_nodes(crep.pre, matches, item_base) + d.post= Babel.str_to_nodes(crep.post, matches, item_base) + d.replace = Babel.str_to_nodes(crep.no, matches, item_base) diff -Nru texlive-base-2022.20230122/debian/patches/series texlive-base-2022.20230122/debian/patches/series --- texlive-base-2022.20230122/debian/patches/series 2023-02-15 14:16:01.0 +0100 +++ texlive-base-2022.20230122/debian/patches/series 2023-04-01 12:57:29.0 +0200 @@ -25,3 +25,4 @@ python3-shebang debian-fix-quote-in-quote update_epspdf_luascript +1034038 diff -Nru texlive-base-2022.20230122/debian/po/ro.po texlive-base-2022.20230122/debian/po/ro.po --- texlive-base-2022.20230122/debian/po/ro.po 1970-01-01 01:00:00.0 +0100 +++ texlive-base-2022.20230122/debian/po/ro.po 2023-04-01 12:55:00.0 +0200 @@ -0,0 +1,77 @@ +# Mesajele în limba română pentru pachetul texlive-base. +# Romanian translation of texlive-base. +# Copyright © 2023 THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the texlive-base package. +# +# Remus-Gabriel Chelu , 2023. +# +# Cronologia traducerii fișierului „texlive-base”: +# Traducerea inițială, făcută de R-GC, pentru versiunea texlive-base 2022.20230122-2(2012-04-24). +# Actualizare a traducerii pentru versiunea Y, făcută de X, Y(anul). +# +msgid "" +msgstr "" +"Project-Id-Version: texlive-base 2022.20230122-2\n" +"Report-Msgid-Bugs-To: texlive-b...@packages.debian.org\n" +"POT-Creation-Date: 2012-04-24 14:30+0900\n" +"PO-Revision-Date: 2023-03-26 17:57+0200\n" +"Last-Translator: Remus-Gabriel Chelu \n" +"Language-Team: Romanian \n" +"Language: ro\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Plural-Forms: nplurals=3; plural=(n==1 ? 0 : n==0 || (n!=1 && n%100>=1 && " +"n%100<=19) ? 1 : 2);\n" +"X-Bugs: Report translation errors to the Language-Team address.\n" +"X-Generator: Poedit 3.2.2\n" + +#. Type: error +#. Description +#: ../texlive-base.templates:2001 +msgid "Unmanageable system paper size (${libpaperPaper})" +msgstr "Dimensiune de hârtie de sistem imposibil de gestionat (${libpaperPaper})" + +#. Type: error +#. Description +#: ../texlive-base.templates:2001 +msgid "" +"The currently defined system-wide paper size is ${libpaperPaper}. However, the " +"TeX configuration system cannot handle this paper size for ${binary}." +msgstr "" +"Dimensiunea de hârtie definită în prezent pentru întregul sistem este " +"${libpaperPaper}. Cu toate acestea, sistemul de configurare TeX nu poate " +"gestiona această dimensiune de hârtie pentru ${binary}." + +#. Type: error +#. Description +#: ../texlive-base.templates:2001 +msgid "The setting will remain unchanged." +msgstr "Configurarea va rămâne neschimbată." + +#. Type: error +#. Description +#: ../texlive-base.templates:2001 +msgid "" +"The following command can show the list of known paper sizes for ${binary}:" +msgstr "" +"Următoarea comandă poate afișa lista cu dimensiunile de hârtie cunoscute pentru " +"${binary}:" + +#. Type: multiselect +#. Description +#: ../texlive-base.templates:3001 +msgid "TeX binaries that should use the system paper size:" +msgstr "Binarele TeX care ar trebui să utilizeze dimensiunea hârtiei de sistem:" + +#. Type: multiselect +#. Description +#: ../texlive-base.templates:3001 +msgid
Bug#899413: texlive-latex-extra: beamerthemeAachen.sty is missing package tangocolors
Control: tags -1 + pending On 5/23/18 23:49, Tobias Gruetzmacher wrote: Hello, The latex-beamer style "Aachen" isn't usable, since it does \RequirePackage{tangocolors} but tangocolors.sty is nowhere to be found... I've uploaded the package to CTAN, so it will be in TL soon. Tag as pending. H. -- Testmail
Bug#1020405: lintian: Tag license-problem-json-evil reports wrongly
Control: tags -1 - moreinfo On 9/21/22 12:21, Bastien Roucariès wrote: Hi, A copy of the MIT License is included in this file." How did you remove the file? By patching ? Or by repack ? For this license you need a repack see man uscan Question was answered a while ago, remove tag moreinfo. H. -- Testmail
Bug#899413: texlive-latex-extra: beamerthemeAachen.sty is missing package tangocolors
On 7/12/19 09:57, Hilmar Preuße wrote: Hi You might try to ask the author to upload it to CTAN, here is a link to one of the files with an email of the author. When it is on CTAN, it will enter into TeX Live, and via that finds it way into Debian ;-) https://github.com/dgsiegel/latex-tangocolors/issues/1 H. -- Testmail
Bug#1032424: proftpd-core: Can't load mod_rewrite
Am 06.03.2023 um 15:19 teilte Bernhard Ehlers mit: Hi Bernhard, When starting proftpd with default configuration, it complains about loading the module mod_rewrite. Fortunately this issue was already known in upstream and I got a patch. Does the updated package on [1] solve the issue for you? Hilmar [1] https://freeshell.de/~hille42/t1/ -- sigfault
Bug#1032424: proftpd-core: Can't load mod_rewrite
Am 06.03.2023 um 15:19 teilte Bernhard Ehlers mit: Hi, When starting proftpd with default configuration, it complains about loading the module mod_rewrite. Hmm, weird. I'm able to reproduce the issue, but currently I have no explanation, as all other modules are loaded fine. H. The following diagnostics were shown: root@7c6d004cf953:~# proftpd 2023-03-06 14:11:33,419 7c6d004cf953 proftpd[239]: mod_dso/0.5: unable to load 'mod_rewrite.c'; check to see if '/usr/lib/proftpd/mod_rewrite.la' exists 2023-03-06 14:11:33,419 7c6d004cf953 proftpd[239]: fatal: LoadModule: error loading module 'mod_rewrite.c': No such file or directory on line 74 of '/etc/proftpd/modules.conf' 2023-03-06 14:11:33,419 7c6d004cf953 proftpd[239]: warning: unable to include '/etc/proftpd/modules.conf': Operation not permitted root@7c6d004cf953:~# root@7c6d004cf953:~# ls /usr/lib/proftpd/mod_rewrite* /usr/lib/proftpd/mod_rewrite.so Proftpd wants to load /usr/lib/proftpd/mod_rewrite.la, but that file doesn't exist, instead /usr/lib/proftpd/mod_rewrite.so is available. When commenting "LoadModule mod_rewrite.c" in /etc/proftpd/modules.conf proftpd starts without these messages. -- sigfault
Bug#1032425: proftpd-core: Module mod_memcache issues warning
Control: severity -1 minor Control: tags -1 + wontfix Am 06.03.2023 um 15:28 teilte Bernhard Ehlers mit: Hi Bernhard, When module mod_memcache is loaded by "LoadModule mod_memcache.c", the following warning is shown: 2023-03-06 14:22:42,504 7c6d004cf953 proftpd[255]: mod_memcache/0.1: compiled using libmemcached-1.0.18 headers, but linked to libmemcached-1.1.3 library To prevent that message I'd need to do an bin-NMU every time the libmemcached has been pushed to a new version. I can't do that, tag as wontfix, severity minor. H. -- sigfault
Bug#1029720: [Pkg-nagios-devel] Bug#1029720: monitoring-plugins-contrib: false positive w bookworm kernel: "running kernel does not match on-disk kernel image'
Am 26.01.2023 um 17:41 teilte Holger Levsen mit: Hi, on a system running bookworm and the latest amd64 kernel /usr/lib/nagios/plugins/check_running_kernel warns me that the running kernel doesnt match the on-disk kernel, while it *is* running the latest kernel. (line breaks added for better readability.) In the moment I'm trying to understand how the script works. My current state is: it checks, which compression mode is used, for the kernel images in /boot/ (which seems to be xz for bookworm), then it decompresses the xz compressed part of the kernel images and searches for "Linux version". The part after "Linux version" is compared to the content of /proc/version. Unfortunately there is a difference: /boot/vmlinuz: Linux version 6.1.0-5-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) # SMP PREEMPT_DYNAMIC Debian 6.1.12-1 (2023-02-15) /proc/version Linux version 6.1.0-5-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.12-1 (2023-02-15) So it could be a bug in the kernel configuration too. All this worked fine on Debian stable. I did not check if there was another compression method in use. I could not dig further, I failed to extract the xz compressed part of the kernel correctly. Not sure if this is useful. Hilmar -- sigfault
Bug#1031949: tex-common: fmtutil fails to copy logs, installation fails
The issue is reported against texlive-binaries: #922500 . Hilmar 26.02.2023 10:24:20 Gard Spreemann : > > Norbert Preining writes: > >>> that my user had set. But it still seems like a bug that postinst fails >>> if the system doesn't have a certain locale. Or maybe I'm viewing this >>> incorrectly? >> >> Yes, you do ;-) >> >> Certain programs, in this case luatex, require correct locale setup to >> work. It would be nice if we could detect these problems beforehand and >> warn the user with a clear message, but also this is non-trivial. >> >> If the locale are incorrectly setup, there is not much to do but fail. >> >> Think about: You could configure to set your shell to >> /bin/IamNotThereBash >> and it would of course create a lot of problems. Maintainer scripts >> cannot work around all possible misconfiguration of a system. > > Fair enough - you've convinved me :-) > > But should this bug remain open, with lowered severity and a better > title and description, to document this fact for users? Unless there's > already a bug covering this matter. > > Thanks for the help. > > Best, > Gard
Bug#1029913: Fwd: Bug#1029913: texlive-pictures: /usr/share/texlive/texmf-dist/scripts/epspdf/epspdf.tlu: /tmp write vulnerability
On 2/15/23 18:51, Frank Heckenbach wrote: Hi Frank, Of course, chdir into /tmp is a bit risky as any file creation before the next chdir would be susceptible to the same problem, but I assume you made sure this won't happen. BTW, when looked at the changes made, I noticed this: io.stdout:write('cannot cd into '..d..'\n') I don't know much about Lua conventions, but normally I'd expect such messages to be written to stderr, not stdout. If you think there are still things, which needs to be improved, please be so kind to open a new bug with lower severity. This one is closed and will get archived soon. Hilmar -- Testmail
Bug#1029439: feynmf: FTBFS in bookworm (I can't open file `fmfsamp4')
On 2/23/23 14:28, James Addison wrote: On Thu, 23 Feb 2023 at 12:53, James Addison wrote: Hi, pass: texlive-base (2022.20220605-1) unstable; urgency=low fail: texlive-base (2022.20220923-2) unstable; urgency=medium It should be possible to look at the differences between those (and maybe the related packages such as texlive-latex-base) to find further clues. I'm going to start on that fairly soon. Ok, it turns out that the problem was a compatibility-break between v2 and v3 of the base doc.sty file. Fortunately the texlive-latex-base package ships the previous (v2, feynmf-compatible) version of that file along with v3. This seems to be just a temporary solution, as the TL upstream people, will stop providing the old doc.sty at any time in the future. You may lower the severity, but not close the issue. Hilmar -- Testmail
Bug#1029439: feynmf: FTBFS in bookworm (I can't open file `fmfsamp4')
On 2/21/23 22:00, James Addison wrote: Hi all, I'm adding the 'help' tag to this bug, and am cc'ing the debian-tex-maint list, because it feels like extra brainpower could aid in figuring this one out more quickly. A brief recap of this bug so far, for folks reading the list: * the feynmf Debian package is failing to build in testing (bookworm) * the bug may somehow be related to the mflogo TeX package * successful build logs are available on buildd.debian.org for comparison Sorry, I'm not of any help here. At the first glance we look at a syntax error in the feynmf.dtx file however I'm wondering why this did not pop within the last > 25 years. As feynmf upstream seems to be dead I suggest to contact the people from https://tex.stackexchange.com/ . I already had a short look, but I could not find a posting describing this issue. Therefore I suggest to ask there; they should be able at least to clarify if the issue is located in the LaTeX3 code or in feynmf. Sorry, Hilmar -- Testmail
Bug#1029913: texlive-pictures: /usr/share/texlive/texmf-dist/scripts/epspdf/epspdf.tlu: /tmp write vulnerability
Am 29.01.2023 um 00:00 teilte Frank Heckenbach mit: Hello Frank, Package: texlive-pictures Version: 2020.20210202-3 Severity: grave File: /usr/share/texlive/texmf-dist/scripts/epspdf/epspdf.tlu Classic /tmp write vulnerability: function dir_writable writes to "/tmp/1" (and if this fails, "/tmp/2" etc.) without sufficient checks. Harmless demonstration: Siep Kroonenberg released a new version of that epspdf.tlu. I've put a new package of texlive-pictures here [1]. Let me know if that solves the issue for you. I'd like to upload the new package ASAP. Hilmar [1] https://freeshell.de/~hille42/TL_2023-2/ -- sigfault
Bug#1023391: texlive-full: The EB Garamond font is not installed properly within debian texlive-full
reassign 1023391 texlive-fonts-extra-links reassign 1020492 texlive-fonts-extra-links merge 1023391 1020492 retitle 1023391 texlive-fonts-extra-links pulls in old Garamond fonts stop Am 15.02.2023 um 10:23 teilte Harald Jele mit: After doing so, the latex compilation shows the same result as a portable TeXlive does. The former broken EB Garamond fonts are fixed. I put a minimal example to https://wwwu.aau.at/hjele/texlive_vs_debian_testing/eb_garamond.zip Retitle, merge, reassign. Hilmar -- sigfault
Bug#1020492: texlive-full: EB Garamond in textlive-full
Am 04.02.2023 um 16:01 teilte Hilmar Preuße mit: Hi, Please remove these files any try again. Is that issue also solved by the patch for Bug#1023391 ? Hilmar -- sigfault
Bug#1023391: texlive-full: The EB Garamond font is not installed properly within debian texlive-full
Am 15.02.2023 um 00:22 teilte Hilmar Preuße mit: Hi Harald, I'm building new packages, which do not depend on fonts-ebgaramond: the fonts in there are not part of TL any more, so the dep is obsolete. I'll hand them over for testing ASAP. Here is the link: https://freeshell.de/~hille42/TL_2023-2/ It should be sufficient to replace package texlive-fonts-extra-links by a new package. 1. You should be able to remove package fonts-ebgaramond after the update. Please do so. 2. After removal you'll have two broken symlinks: /usr/share/texlive/texmf-dist/fonts/opentype/public/ebgaramond/EBGaramond12-Italic.otf /usr/share/texlive/texmf-dist/fonts/opentype/public/ebgaramond/EBGaramond12-Regular.otf Please remove them manually, I'll remove them in final release of -2. 3. Run "mktexlsr" as user root. 4. Then try again to convert the document and report if that solves the issue. Provide log files in any case. Thanks! Hilmar -- sigfault
Bug#1023391: texlive-full: The EB Garamond font is not installed properly within debian texlive-full
Am 14.02.2023 um 13:41 teilte Hilmar Preuße mit: Am 14.02.2023 um 13:29 teilte Jele, Harald mit: Hi Harald, removing the fonts-ebgaramond seems not to be a good idea: apt remove fonts-ebgaramond would remove almost the whole texlive installation because of it's dependencies. Could you nevertheless try that step, just to prove that is is the faulty package? Thanks! I'm building new packages, which do not depend on fonts-ebgaramond: the fonts in there are not part of TL any more, so the dep is obsolete. I'll hand them over for testing ASAP. Hilmar -- sigfault
Bug#1023391: texlive-full: The EB Garamond font is not installed properly within debian texlive-full
Am 14.02.2023 um 13:29 teilte Jele, Harald mit: Hi, removing the fonts-ebgaramond seems not to be a good idea: apt remove fonts-ebgaramond would remove almost the whole texlive installation because of it's dependencies. Could you nevertheless try that step, just to prove that is is the faulty package? Thanks! Hilmar -- sigfault
Bug#1023391: texlive-full: The EB Garamond font is not installed properly within debian texlive-full
Am 14.02.2023 um 10:55 teilte Jele, Harald mit: Hi Harald, no local fonts are installed anymore and I reproduced this issue again. I made a reply via reportbug to the bug report #1023391 with a new tgz, containing all output files of lualatex. One made with a portable texlive installation (which is fine), one with texlive on a current debian testing. You have the package fonts-ebgaramond installed. Could you remove it and try again? Hilmar -- sigfault
Bug#1031123: RFS: libcommons-collections4-java/4.4-1 [Team] -- Apache Commons Collections - Extended Collections API for Java
Am 12.02.2023 um 07:54 teilte min sun mit: Hi, To access further information about this package, please visit the following URL: https://mentors.debian.net/package/libcommons-collections4-java/ If you look at that link you'll see a few things, which should the resolved. At least the distribution name has to be changed from UNRELEASED to the desired value. H. -- sigfault
Bug#1030387: [Debian GNUstep maintainers] Bug#1030387: gnustep-make: FTBFS with TeXInfo 7.0.x
Am 06.02.2023 um 22:45 teilte Richard Frith-Macdonald mit: Hi, Thanks. FYI I implemented the suggested change in gnustep-make trunk in the git repository, after having tried it out with TeXinfo 5 and 6 I guess you meant TeXinfo 6 & 7; TeXinfo 5 is not even in oldstable. I can't find your changes on salsa. ;-( Hilmar -- sigfault
Bug#1030622: tex-common package post-installation script subprocess returned error exit status 1
Control: reassign -1 texlive-latex-base Control: tags -1 pending Am 06.02.2023 um 06:20 teilte Stéphane Glondu mit: Le 05/02/2023 à 20:52, Hilmar Preuße a écrit : Hi, Today the new texlive-base & texlive-extra did migrate to testing and hence were upgraded on your system. The texlive-lang did not migrate yet, this will happen soon. Once texlive-lang-japanese is upgraded, please repeat the test. Is suspect an incompatibility in these packages, as I'm not able to reproduce the issue using unstable. Then, a dependency (Breaks and/or Conflicts) is missing somewhere... I just upgraded texlive-lang-* and indeed the problem seems to have disappeared. I'd expect at texlive-latex-base, however I'm not sure. Reassign to the most likely package for now. To solve the issue, I'd need another upload of texlive-base. As we're still waiting for a fix of #1029913, I'll delay that upload. Fix is in github, tag pending. Hilmar -- sigfault
Bug#1030622: tex-common package post-installation script subprocess returned error exit status 1
Am 05.02.2023 um 19:56 teilte Stéphane Glondu mit: Package: tex-common Version: 6.18 Severity: serious Hello, I got this when upgrading texlive today in testing: Paramétrage de tex-common (6.18) ... Running mktexlsr. This may take some time... done. Running mtxrun --generate. This may take some time... done. Running updmap-sys. This may take some time... done. Running mktexlsr /var/lib/texmf ... done. Building format(s) --all. This may take some time... fmtutil failed. Output has been stored in /tmp/fmtutil.RDPxpv93 Please include this file if you report a bug. Today the new texlive-base & texlive-extra did migrate to testing and hence were upgraded on your system. The texlive-lang did not migrate yet, this will happen soon. Once texlive-lang-japanese is upgraded, please repeat the test. Is suspect an incompatibility in these packages, as I'm not able to reproduce the issue using unstable. For the records: the error message is: ** * * making upLaTeX format * ** (/usr/share/texlive/texmf-dist/tex/platex/base/plcore.ltx ! Argument of \platexNILa has an extra }. \par l.52 ...ter\expandafter\expandafter{\platexBANNER} % ? ! Emergency stop. \par l.52 ...ter\expandafter\expandafter{\platexBANNER} % Hilmar -- sigfault
Bug#1023391: texlive-full: The EB Garamond font is not installed properly within debian texlive-full
Am 03.11.2022 um 11:48 teilte Harald Jele mit: Hi, when installing texlive-full into debian testing the EB Garamond fonts seem to be not installed correctly. Not all ligatures are available, the bold face does not even have a dash ... I put a minimal example to http://wwwu.aau.at/hjele/texlive_vs_debian_testing/eb_garamond.zip Compile the wut.tex via lualatex 2 pdfs are included. One is the output of a current texlive portable installation. One comes from a up to date debian testing. I'm unable to reproduce the issue. As you did not provide a log file I can only guess that we have the same root cause as for #1020492: make sure that the local incarnations of the fonts are deleted. Hilmar -- sigfault
Bug#1020492: texlive-full: EB Garamond in textlive-full
Am 22.09.2022 um 09:50 teilte Harald Jele mit: Hi, after installing TeX Live 2022/dev/Debian via the texlive-full pkg I had to recognize, that the font EB Garamond is not well installed. At least the Bold Font installation is corrupted. Could you fix this? For testing this I made an example here: https://wwwu.aau.at/hjele/eb_garamond_example/20220916_eb_garamond.zip Your log file gives the idea, that a few font files used are not provided by Debian: Output written on wut.pdf (9 pages, 61637 bytes). Please remove these files any try again. Hilmar -- sigfault
Bug#1023586: texlive-extra-utils: pythontex won't find python (when on python3)
Am 07.11.2022 um 12:38 teilte Olivier Berger mit: Norbert Preining writes: Hi Olivier, This can be addressed by explicitely invoking with: pythontex --interpreter python:python3 Maybe also installing python-is-python3 or how the package name was. That's it. However, the description states "No packages may declare dependencies on this package." ... does this include recommends or suggests ? In the Debian package the python interpreter is hard coded to python3 in the pythontex scripts. Hence I do not really understand, what is going on here. Could you provide a minimal input file for problem reproduction? Hilmar -- sigfault
Bug#1030346: elpa-transient: FTBFS with TeXInfo 7.0.x
Am 03.02.2023 um 12:17 teilte Hilmar Preusse mit: Hi, The easiest solution is probably to collect the docs from the new location, specified in d/elpa-transient-doc.docs, but that needs to be verified. Probably not the best idea; this way the package becomes incompatible to TeXinfo 6.8. Rather consider to use option "--output=" of makeinfo to change the directory where the files are written. H. -- sigfault
Bug#1030352: m4: FTBFS with TeXInfo 7.0.x
Am 03.02.2023 um 14:23 teilte Santiago Vila mit: Hi Santiago, The easiest solution is probably to add option "--output=$(package)" to the makeinfo --html in d/rules, but this needs to be verified. I confirm that adding --output=$(package) works (and also produces identical results in unstable according to diffoscope). BTW: The new Texinfo package now depends on install-info. Is that normal/expected? hille@sid-amd64:~$ apt-cache show texinfo|grep Dep Depends: perl:any, libtext-unidecode-perl, libxml-libxml-perl, texinfo-lib (>= 7.0.2-1), tex-common Can't see this. Maybe one of the package it pulls in declares a Dep, but this is not my fault. H. -- sigfault
Bug#1029461: Processed (with 1 error): xemacs21-packages: FTBFS in bookworm (LaTeX Error: File `pdftexcmds.sty' not found)
Control: reassign -1 texlive-latex-base Control: forcemerge -1 1029438 Am 31.01.2023 um 23:50 teilte Santiago Vila mit: Well, I feared the merge could fail, and yes, it did. I have not gotten the hang of it. If you could merge them properly, that would be great. Thanks a lot. -- sigfault
Bug#1030059: pycirkuit: Fails to run autopkgtest test suite
Am 30.01.2023 um 21:11 teilte Hilmar Preusse mit: Hi, A few days ago I uploaded a new TeX Live snapshot. Since then the test suite of your package fails to run, see [1]. Interestingly I can run the line from the test script without any issue: /usr/bin/pycirkuit -t -p -f /usr/share/doc/pycirkuit/examples/*.ckt --destination /tmp First I suspected, that my main system has another set of TeX Live package, but this was wrong: even after stripping down the main system to all packages, which are listed in the dep of pycirkuit I could convert the files, using the command above. Hilmar -- sigfault
Bug#1029720: [Pkg-nagios-devel] Bug#1029720: Bug#1029720: Bug#1029720: monitoring-plugins-contrib: false positive w bookworm kernel: "running kernel does not match on-disk kernel image'
Am 30.01.2023 um 13:57 teilte Hilmar Preuße mit: Am 30.01.2023 um 13:10 teilte Jan Wagner mit: Hi, thanks for confirming. As I don't have a bookworm system (with running kernel) at hand, I can't go deeper into debugging this issue until I get hands on it. I'm able to reproduce, if that helps. hille@sid-amd64:~$ /usr/lib/nagios/plugins/check_running_kernel WARNING: Running kernel does not match on-disk kernel image: [Linux version 6.1.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-13) 12.2.0, GNU ld (GNU Binutils for Debian) 2.39.90.20221231) #1 SMP PREEMPT_DYNAMIC Debian 6.1.4-1 (2023-01-07) != Linux version 6.1.0-2-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) # SMP PREEMPT_DYNAMIC Debian 6.1.7-1 (2023-01-18)] The message above is correct. When comparing the two lines, one notices that they are not equal: Linux version 6.1.0-2-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.7-1 (2023-01-18) vs. Linux version 6.1.0-2-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) # SMP PREEMPT_DYNAMIC Debian 6.1.7-1 (2023-01-18) Meanwhile I rebooted into the 2nd kernel, which did not solve the issue. H. -- sigfault
Bug#1029913: texlive-pictures: /usr/share/texlive/texmf-dist/scripts/epspdf/epspdf.tlu: /tmp write vulnerability
Control: tags -1 + help Am 29.01.2023 um 00:00 teilte Frank Heckenbach mit: Hi, Classic /tmp write vulnerability: function dir_writable writes to "/tmp/1" (and if this fails, "/tmp/2" etc.) without sufficient checks. Harmless demonstration: % mkfifo /tmp/1 % epspdf /etc/hostname /dev/null # any non-empty input file will do hangs indefinitely trying to write to the pipe (as can be seen using strace). I sent an E-Mail to upstream, however I don't expect a fast response. Tagging "help" for know. Hilmar -- sigfault
Bug#1029720: [Pkg-nagios-devel] Bug#1029720: Bug#1029720: monitoring-plugins-contrib: false positive w bookworm kernel: "running kernel does not match on-disk kernel image'
Am 30.01.2023 um 13:10 teilte Jan Wagner mit: Hi, thanks for confirming. As I don't have a bookworm system (with running kernel) at hand, I can't go deeper into debugging this issue until I get hands on it. I'm able to reproduce, if that helps. hille@sid-amd64:~$ /usr/lib/nagios/plugins/check_running_kernel WARNING: Running kernel does not match on-disk kernel image: [Linux version 6.1.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-13) 12.2.0, GNU ld (GNU Binutils for Debian) 2.39.90.20221231) #1 SMP PREEMPT_DYNAMIC Debian 6.1.4-1 (2023-01-07) != Linux version 6.1.0-2-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) # SMP PREEMPT_DYNAMIC Debian 6.1.7-1 (2023-01-18)] When running with bash -x I see two times (two kernel images installed) the message: ++ echo 'ERROR: Unable to extract kernel image.' ..but this could be benign. I did not fully read the output yet. Hilmar -- sigfault
Bug#1024997: install-info: dir entry for emacs is bolloxed
Am 30.01.2023 um 06:51 teilte Brendan O'Dea mit: Hi Brendan, On Mon, Nov 28, 2022 at 11:46:49PM +0100, Hilmar Preuße wrote: Version: 7.0-1 Am 28.11.2022 um 23:28 teilte Barak A. Pearlmutter mit: Yes! That fixes it. Closing then. This is still present in the unstable version of the package. You should probably keep this open until 7.0 gets to unstable. IIRC the Debian BTS is based on versions, unless it is an RC bug. So I'll probably forget about this bug. Please be so kind to close it, when TInfo 7.0.x entered unstable. I'm not sure, if this will happen before bookworm. Hilmar -- sigfault
Bug#1025985: glosstext: FTBFS: LaTeX Error: File `pdftexcmds.sty' not found.
Control: affects -1 src:glosstex
Bug#1015123: latex-cjk-chinese-arphic: FTBFS: E: Build killed with signal TERM after 150 minutes of inactivity
Am 21.01.2023 um 16:05 teilte Danai SAE-HAN (韓達耐) mit: Hi Danai, Indeed, I have tested it yesterday too and the scripts now breeze through without bailing out. I would like to keep the bug, and will solve it by adding a versioned build-dependency on Fontforge to ensure it will always build properly. Please keep in mind, that I've accepted a pull request from Janitor for the package. So, please issue "git pull" before working on the package. Hilmar -- sigfault
Bug#1029325: texlive-latex-extra: adequate reports broken-symlink
Am 21.01.2023 um 12:24 teilte Vincent Smeets mit: Hi, The command "adequate texlive-latex-extra" reports a broken link. $ adequate texlive-latex-extra texlive-latex-extra: broken-symlink /usr/share/texlive/texmf-dist/tex/latex/pdfx/sRGB_IEC61966-2-1_black_scaled.icc -> ../../../../../color/icc/sRGB_IEC61966-2-1_black_scaled.icc $ Versions of packages texlive-latex-extra suggests: pn icc-profiles You need to install the package icc-profiles to solve the link. We can't depend or recommend the package as it is non-free. texlive-latex-extra: py-file-not-bytecompiled /usr/share/texlive/texmf-dist/scripts/webquiz/webquiz_layout.py texlive-latex-extra: py-file-not-bytecompiled /usr/share/texlive/texmf-dist/scripts/webquiz/webquiz_templates.py texlive-latex-extra: py-file-not-bytecompiled /usr/share/texlive/texmf-dist/scripts/webquiz/webquiz_xml.py > Do we need to address this issue? Hilmar -- sigfault
Bug#1025049: asymptote: Error in shipout3
Am 20.01.2023 um 13:06 teilte Picca Frédéric-Emmanuel mit: Dear Frédéric, as I'm not able to reproduce the issue (due to different software constellation on the Desktop): would you be so kind to forward that issue to upstream by your own? The upstream tracker is on https://github.com/vectorgraphics/asymptote/issues I case of questions regarding the Debian package feel free to contact us. Many thanks, Hilmar Here the backtrace generated after the crash, it seems that there is an Arithmetic Exception. the gl parameter at line 23 seems strange #23 0x5591db410072 in gl::glrender (prefix="", pic=0x2, format=, width=5.3049894774131808e-315, height=0, angle=2.3978552443441112e-312, zoom=5.3982412455708344e-315, m=..., M=..., shift=..., margin=..., t=0x7ffc641f9990, background=0x5591db748b90, nlightsin=3, lights=0x7f31c6fb10e8, diffuse=0x7f31c6fb1070, specular=0x7f31c6fb1000, view=false, oldpid=0) at ./glrender.cc:2207 -- sigfault
Bug#1028630: RFP: proftpd-mod-sftp-ldap -- module for ProFTPD supports retrieving/using user SSH public keys from LDAP
Am 13.01.2023 um 22:54 teilte Paweł Tomulik mit: Hi Paweł, ProFTPD mod_sftp_ldap may be very useful for ProFTPD installations with virtual users stored in LDAP database together with SSH keys. It enables the authentication based on these keys stored in LDAP. The package has been uploaded to Debian and is now sitting in the NEW queue. I'd expect a processing time of about 1-2 weeks. https://ftp-master.debian.org/new/proftpd-mod-sftp-ldap_0.2-1.html H. -- sigfault
Bug#1015123: latex-cjk-chinese-arphic: FTBFS: E: Build killed with signal TERM after 150 minutes of inactivity
Am 20.12.2022 um 04:08 teilte Danai SAE-HAN (韓達耐) mit: Hi, Sorry, I forgot all about this! I figured out it was a regression so in Unstable you need to go two versions back for Fontforge, which will ignore the warnings instead of halting the process. I'll be back home on 30 December. Meanwhile I'll send a message upstream. With the latest upload of fontforge the issue is solved: #1015092 . We could simply close the bug or tighten the build dep. Hilmar -- sigfault
Bug#1029127: context: manual has non-free files
Am 18.01.2023 um 20:29 teilte Bastian Germann mit: Am 18.01.23 um 20:20 schrieb Hilmar Preuße: Am 18.01.2023 um 11:52 teilte Bastian Germann mit: Am 18.01.23 um 11:21 schrieb Hilmar Preuße: Hi, Do you have a list of these files or do you know how to generate one? grep -r licence=cc-by-nc-sa This gives a lot of TeX input files should I remove them? Yes. But please make the repack reproducible. The easiest way is to convert the debian/copyright file to the machine-readable format and use Files-Excluded. As we don't get tar balls from upstream, the most easy way would be to edit the make-orig-tar and exclude the files there. I'll try to look into that further ASAP. Hilmar -- sigfault
Bug#1029127: context: manual has non-free files
Am 18.01.2023 um 11:52 teilte Bastian Germann mit: Am 18.01.23 um 11:21 schrieb Hilmar Preuße: Hi, Do you have a list of these files or do you know how to generate one? grep -r licence=cc-by-nc-sa This gives a lot of TeX input files should I remove them? Hilmar -- sigfault
Bug#1029127: context: manual has non-free files
Am 18.01.2023 um 10:49 teilte Bastian Germann mit: Hi Bastian, Many of context's manual files contain licence=cc-by-nc-sa which is a non-free license (non-commercial). Please repack to get rid of them. Do you have a list of these files or do you know how to generate one? Thanks, Hilmar -- sigfault
Bug#1028989: RFS: proftpd-mod-sftp-ldap/0.2-1 [ITP] -- ProFTPD module mod_sftp-ldap
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "proftpd-mod-sftp-ldap": * Package name : proftpd-mod-sftp-ldap Version : 0.2-1 Upstream contact : TJ Saunders * URL : http://www.castaglia.org/proftpd/modules/mod_sftp-ldap.html * License : GPL-2+ * Vcs : https://salsa.debian.org/debian-proftpd-team/proftpd-mod-sftp-ldap Section : net The source builds the following binary packages: proftpd-mod-sftp-ldap - ProFTPD module mod_sftp-ldap To access further information about this package, please visit the following URL: https://mentors.debian.net/package/proftpd-mod-sftp-ldap/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/p/proftpd-mod-sftp-ldap/proftpd-mod-sftp-ldap_0.2-1.dsc Changes for the initial release: proftpd-mod-sftp-ldap (0.2-1) unstable; urgency=medium . * Initial upload (Closes: #1028630). . [ Paweł Tomulik ] * Providing an initial package I could use as starter. Regards, -- Hilmar Preusse
Bug#1028630: RFP: proftpd-mod-sftp-ldap -- module for ProFTPD supports retrieving/using user SSH public keys from LDAP
Control: retitle -1 ITP: proftpd-mod-sftp-ldap Control: reassign -1 wnpp Am 13.01.2023 um 22:54 teilte Paweł Tomulik mit: Hi, ProFTPD mod_sftp_ldap may be very useful for ProFTPD installations with virtual users stored in LDAP database together with SSH keys. It enables the authentication based on these keys stored in LDAP. The upstream project is here: https://github.com/Castaglia/proftpd-mod_sftp_ldap I've initially packaged it for Debian, and put here: https://gitlab.com/ptomulik/proftpd-mod_sftp_ldap Meanwhile I created an repo on salsa, which will be official repository. Hilmar -- sigfault
Bug#1028630: RFP: proftpd-mod-sftp-ldap -- module for ProFTPD supports retrieving/using user SSH public keys from LDAP
Am 13.01.2023 um 22:54 teilte Paweł Tomulik mit: Hi Paweł, ProFTPD mod_sftp_ldap may be very useful for ProFTPD installations with virtual users stored in LDAP database together with SSH keys. It enables the authentication based on these keys stored in LDAP. The upstream project is here: https://github.com/Castaglia/proftpd-mod_sftp_ldap I've initially packaged it for Debian, and put here: https://gitlab.com/ptomulik/proftpd-mod_sftp_ldap Many thanks for your package so far, I can use the code nearly as it is! For now I requested TJ to create a (pre-)release to make sure we don't get in conflict when a potential 0.1 is released later on. Yes, I could release version "0.0~git20220320.450f9b4-1"... let's see how fast TJ answers. Hilmar [1] https://github.com/Castaglia/proftpd-mod_sftp_ldap/issues/9 -- sigfault
Bug#1025985: glosstext: FTBFS: LaTeX Error: File `pdftexcmds.sty' not found.
Control: tags -1 + pending Am 11.01.2023 um 02:48 teilte Adrian Bunk mit: Hi, Your package fails to build with: |Writing index file glosstex.idx |(/usr/share/texlive/texmf-dist/tex/latex/hypdoc/hypdoc.sty |(/usr/share/texlive/texmf-dist/tex/latex/base/atveryend-ltx.sty) |(/usr/share/texlive/texmf-dist/tex/latex/hyperref/hyperref.sty |(/usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty) |(/usr/share/texlive/texmf-dist/tex/generic/iftex/iftex.sty) | |! LaTeX Error: File `pdftexcmds.sty' not found. ... This is basically a continuation of #1016218. :-( Fixed on my computer, not pushed to github yet. H. -- sigfault
Bug#1012612: texinfo: Info documentation links to missing "pod2texi" manual
Am 10.06.2022 um 11:29 teilte Timothy Allen mit: Dear Timothy, As I'm sure you know, when the "texinfo" package is installed, it creates `/usr/share/info/texinfo.info.gz`, and a metadata chunk from the preamble of that file is merged into `/usr/share/info/dir`. I've uploaded texinfo 7.0.1-3 to Debian experimental. Could you install it and check if it solves the issue? Thanks! Hilmar -- sigfault
Bug#1028056: texlive-lang-chinese: xtuthesis.pdf still contains Lenna image
Am 06.01.2023 um 12:46 teilte Bastian Germann mit: Hi, The non-free Lenna image is stripped from the xtuthesis package via debian/tpm2deb.cfg. However, xtuthesis.pdf still contains the image and is actually a non-source file. So please exclude it as well. I've excluded the file (no "git push" yet), will be removed with next TL snapshot. Hilmar -- sigfault
Bug#1028101: RFS: texinfo/7.0.1-3 -- Documentation system for on-line information and printed output
Am 07.01.2023 um 16:16 teilte Bastian Germann mit: Hi Bastian, The NIV has to be represented in d/copyright regardless of having the "right" wording or not. You currently do not mention it at all. GFDL-1.3+ (no NIV) is considered non-free, so please fix this. I do not mind the lintian override then. New package is on mentors. Please be so kind to have a look. The diff is here [1] . Hilmar [1] https://github.com/debian-tex/texinfo/commit/6ba1816bca53dd14559e8fbba7e4b75f5a90a20f -- sigfault
Bug#1028101: RFS: texinfo/7.0.1-3 -- Documentation system for on-line information and printed output
Am 07.01.2023 um 02:30 teilte Bastian Germann mit: Am 07.01.23 um 02:27 schrieb Bastian Germann: Hi, boilerplate code boilerplate license text (in @quotation): Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled ``GNU Free Documentation License''. Currently the problematic passage is not contained the d/copyright at all, see [1]. Do we need it in that file? If yes, could you give an example how to reference that license correctly in d/copyright ? Thanks, Hilmar [1] https://github.com/debian-tex/texinfo/blob/master/debian/copyright -- sigfault
Bug#1028101: RFS: texinfo/7.0.1-3 -- Documentation system for on-line information and printed output
Am 07.01.2023 um 02:27 teilte Bastian Germann mit: Hi Bastian, On Fri, 6 Jan 2023 23:49:43 +0100 Hilmar Preusse wrote: - "license-problem-gfdl-non-official-text": override and fix. The GFDL variant has to be GFDL-NIV-1.3+ and the short license text that you have in d/copyright has to contain the section that is available in the matching files' boilerplate code. Please correct that and remove the overrides. The lintian override was made for the upstream source code, containing the wrong wording. The issue was forwarded upstream and addressed there [1]. The next minor upstream release will have the fix. Is that sufficient? Hilmar [1] https://git.savannah.gnu.org/cgit/texinfo.git/commit/?id=6600c8007856c7103542f648e4c3d75e1c735de1 -- sigfault
Bug#1026934: Package colortbl does not work with dinbrief anymore
Control: tags -1 + wontfix Am 24.12.2022 um 10:27 teilte Joey Schulze mit: Hi, I have found an incompatibility between the package colortbl and the dinbrief documentclass. The problem sneaked into bullseye and did not exist in buster. It seems to be still present in bookwork unfortunately (for verification i copied both colortbl.sty and dinbrief.cls into the directory containing the sample LaTeX file). Please see this minimal LaTeX files to reproduce the problem As you probably are able to speak German I refer this thread from dctt [1]. The issue is probably in dinbrief, but I have little hope that we'll get a fix for this. Tagging. Hilmar [1] https://de.comp.text.tex.narkive.com/pPx7YIaB/problem-mit-xcolor-bzw-pdftex-def-und-dinbrief -- -- sigfault
Bug#1026789: Broken vf files in package?
Package: texlive-fonts-extra Version: 2022.20221123-2 Severity: normal This is a question, which came up, when working on #1026460. Things are worse: file(1) /does/ have magic for "TeX virtual font data" but is *that* weak (only 16 bit, 0xf7 0xca at the start of file) it gets beaten by the pattern for the dreaded MS-DOS executables (which is plain nightmare). After some searching I found the parser for virtual font files in texk/dvipsk/virtualfont.c starting at line 189. So I could harden the magic at least a little bit by exploiting the command byte (243, 0xf3) at offset 0xb the earliest. Since I had to download the huge texlive-fonts-extra .deb to extract the reproducer, this at least also brought more than 20k samples to verify the result. Some .vf files fail the test, and I'd like to ask you whether they are technically correct: # From the texlive-bin sources (bullseye) * texk/web2c/tests/badvpl.vpl (I assume that's not a bug) # From texlive-fonts-extra_2022.20221123-2_all.deb: * /usr/share/texlive/texmf-dist/fonts/vf/public/mathdesign/mdbch/mdbchbofc8t.vf * /usr/share/texlive/texmf-dist/fonts/vf/public/mathdesign/mdbch/mdbchrofc8t.vf They look fairly broken (error messages inside), perhaps they shouldn't be there anyway? * /usr/share/texlive/texmf-dist/fonts/vf/public/ebgaramond/EBGaramondInitials-tlf-ts1.vf * /usr/share/texlive/texmf-dist/fonts/vf/public/gfsbodoni/gbodonio9a.vf * /usr/share/texlive/texmf-dist/fonts/vf/public/hfoldsty/hfoit0600.vf * /usr/share/texlive/texmf-dist/fonts/vf/public/hfoldsty/hfoit0700.vf * /usr/share/texlive/texmf-dist/fonts/vf/public/hfoldsty/hfost0600.vf * /usr/share/texlive/texmf-dist/fonts/vf/public/hfoldsty/hfost0700.vf * /usr/share/texlive/texmf-dist/fonts/vf/public/hfoldsty/hfotc0600.vf * /usr/share/texlive/texmf-dist/fonts/vf/public/hfoldsty/hfotc0700.vf * /usr/share/texlive/texmf-dist/fonts/vf/public/hfoldsty/hfott0600.vf * /usr/share/texlive/texmf-dist/fonts/vf/public/hfoldsty/hfott0700.vf * /usr/share/texlive/texmf-dist/fonts/vf/public/hfoldsty/hfovi0600.vf * /usr/share/texlive/texmf-dist/fonts/vf/public/hfoldsty/hfovi0700.vf * /usr/share/texlive/texmf-dist/fonts/vf/public/hfoldsty/hfovt0600.vf * /usr/share/texlive/texmf-dist/fonts/vf/public/hfoldsty/hfovt0700.vf * /usr/share/texlive/texmf-dist/fonts/vf/public/libertinus-type1/LibertinusSerifInitials-Regular-tlf-ts1.vf These are pretty small (88 octets at most, usually just 12) so still not having them detected properly might not be the biggest loss. Are these files technically OK? Hilmar -- sigfault
Bug#1015123: latex-cjk-chinese-arphic: FTBFS: E: Build killed with signal TERM after 150 minutes of inactivity
Am 27.07.2022 um 12:10 teilte Danai SAE-HAN (韓達耐) mit: Hi Danai, is there progress? Did you get response from upstream? Hilmar Some observations: Going back to fontforge version 20201107~dfsg-4 and its dependencies, I notice the following warning message: 21900/1114292: Add extrema... Simplifying outlines... NaN value in spline creationNaN value in spline creationNaN value in spline creationNaN value in spline creationNaN value in spline creationNaN value in spline creationNaN value in spline creationNaN value in spline creationNaN value in spline creationNaN value in spline creationNaN value in spline creationNaN value in spline creationNaN value in spline creationNaN value in spline creationNaN value in spline creationNaN value in spline creationNaN value in spline creationNaN value in spline creationNaN value in spline creationNaN value in spline creationNaN value in spline creationNaN value in spline creationNaN value in spline creationNaN value in spline creationNaN value in spline creationNaN value in spline creationNaN value in spline creationNaN value in spline creationNaN value in spline creationNaN value in spline creationNaN value in spline creationNaN value in spline creationNaN value in spline creationNaN value in spline creationNaN value in spline creationNaN value in spline creationNaN value in spline creationNaN value in spline creationNaN value in spline creationNaN value in spline creationNaN value in spline creation22000/1114292: Add extrema... Simplifying outlines... A more recent version of Fontforge will just let the application hang. I will have to contact upstream to figure out what is causing this. -- sigfault
Bug#1025980: texlive-extra breaks latexml autopkgtest: Couldn't convert t/structure/glossary.tex
Control: reassign -1 latexml Am 12.12.2022 um 21:56 teilte Paul Gevers mit: Hi Paul, With a recent upload of texlive-extra the autopkgtest of latexml fails in testing when that autopkgtest is run with the binary packages of texlive-extra from unstable. It passes when run with only packages from testing. In tabular form: The issue is in latexml. It is known in upstream and the (soon to be relased) new version has the fix. H. -- sigfault
Bug#1025980: texlive-extra breaks latexml autopkgtest: Couldn't convert t/structure/glossary.tex
Control: reasssign -1 latexml Control: forwarded -1 https://github.com/brucemiller/LaTeXML/issues/1985 Control: tags -1 + fixed-upstream pending Am 12.12.2022 um 21:56 teilte Paul Gevers mit: Hi Paul, With a recent upload of texlive-extra the autopkgtest of latexml fails in testing when that autopkgtest is run with the binary packages of texlive-extra from unstable. It passes when run with only packages from testing. In tabular form: The issue is in latexml. It is known in upstream and the (soon to be relased) new version has the fix. H. -- sigfault
Bug#1025940: info: buffer overflow in copy_converting()
Control: tags -1 + patch pending Am 12.12.2022 um 10:48 teilte Jakub Wilk mit: Hi, Some parts of groff.info make info(1) crash: $ info groff > /dev/null corrupted size vs. prev_size Aborted Got a prompt patch from upstream, solved in git. Hilmar -- sigfault
Bug#1023007: tex-common: configuration fails due to "Illegal instruction" on i386
Am 10.12.2022 um 18:16 teilte Bernhard Übelacker mit: Hi, I have seen other packages that added a dependency to package sse2-support in such cases. That would not solve the issue, but would make it visible at installation time for the user, if I understand it right. Thanks for the hint. My "git diff" below. As far as I understood I need to declare a Pre-Depwait: the sse2-support fails already in preinst if SSE2 support is missing, so a Dep should be OK. Do you agree? Hilmar hille@sid-amd64:~/devel/TeXLive/github/texlive-bin$ git diff diff --git a/debian/control b/debian/control index 6286e991..21349a62 100644 --- a/debian/control +++ b/debian/control @@ -50,6 +50,7 @@ Depends: libptexenc1 (>= ${source:Version}), libtexlua53-5 (<< ${source:Version}.1~), libtexluajit2 (>= ${source:Version}) [amd64 armel armhf hurd-i386 i386 kfreebsd-amd64 kfreebsd-i386 powerpc], libtexluajit2 (<< ${source:Version}.1~) [amd64 armel armhf hurd-i386 i386 kfreebsd-amd64 kfreebsd-i386 powerpc], + sse2-support [ i386 ], t1utils, tex-common, perl:any, ${shlibs:Depends}, ${misc:Depends} Hlimar -- sigfault
Bug#1025049: asymptote: Error in shipout3
Am 30.11.2022 um 07:48 teilte picca mit: Hello, I imagine that the zzz1.asy file is my B_b3_y.asy, right ? Yes, correct. if so, something must be different between your environment and mine. I use the latest unstable with ghostscript 10 and you ? Some here. Pure Debian unstable, w/ gs 10 installed. hille@sid-amd64:~$ dpkg -l ghost* Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ NameVersion Architecture Description +++-===-=--> ii ghostscript 10.0.0~dfsg-7 amd64interpreter for the PostScri> ii ghostscript-x:amd64 10.0.0~dfsg-7 amd64interpreter for the PostScri> Is it possible to have a more informative debug message than this one ? Does [1] help you somehow? H. [1] https://tex.stackexchange.com/questions/592394/using-asymptote-for-3d-plots -- sigfault
Bug#1025049: asymptote: Error in shipout3
Am 29.11.2022 um 10:02 teilte Picca Frédéric-Emmanuel mit: Hi, sorry I'm failing to reproduce the issue. For me that command line works: hille@sid-amd64:~/devel/TeXLive$ asy -config "" -d -render=4 -f png -o zzz1.png zzz1.asy hille@sid-amd64:~/devel/TeXLive$ ls -l zzz1.* -rw-r--r-- 1 hille hille 812 Nov 29 21:55 zzz1.asy -rw-r--r-- 1 hille hille 16444 Nov 29 23:42 zzz1.eps -rw-r--r-- 1 hille hille 16663 Nov 29 23:45 zzz1.png H. while working on the hkl package I found that asy doe snot compile anymore my files. /usr/bin/asy -config "" -d -render=4 -f png -o 3S+1D.png 3S+1D.asy shipout3(prefix,f,preview ? nativeformat() : format, ^ /usr/share/asymptote/three.asy: 2896.13: runtime: /usr/bin/asy -config "" -d -render=4 -f png -o B_b3_y.png B_b3_y.asy shipout3(prefix,f,preview ? nativeformat() : format, ^ /usr/share/asymptote/three.asy: 2896.13: runtime: /usr/bin/asy -config "" -d -render=4 -f png -o B_a.png B_a.asy shipout3(prefix,f,preview ? nativeformat() : format, ^ /usr/share/asymptote/three.asy: 2896.13: runtime: /usr/bin/asy -config "" -d -render=4 -f png -o B_b.png B_b.asy shipout3(prefix,f,preview ? nativeformat() : format, ^ -- sigfault
Bug#1024997: install-info: dir entry for emacs is bolloxed
Am 28.11.2022 um 15:41 teilte Barak A. Pearlmutter mit: Hi Barak, Note the strange characters here that mess up the entry: $ cat -v /usr/share/info/dir | egrep -2 '[(]emacs[)]' * Magit: (magit). Using Git from Emacs with Magit. * With-Editor: (with-editor). Using the Emacsclient as $EDITOR. ^ZM-^L}[^EM-^KM-6M-bd^E* Emacs: (emacs). The extensible self-documenting text editor. * Emacs FAQ: (efaq).Frequently Asked Questions about Emacs. * Haskell Mode: (haskell-mode). Haskell Development Environment for Emacs(en) I've uploaded texinfo 7.0 to experimental. Could you test if that eventually solves the issue? Hilmar -- sigfault
Bug#1014755: texlive-lang-czechslovak causes error with wordlflags with emblems
Am 11.07.2022 um 16:16 teilte Petr Nivnický mit: Hello Petr, All flags with emblems (with worldflags package https://ctan.org/pkg/ worldflags) are not generated when Czech or Slovak babel are used. Other languages work. All flags without emblems work even with Czech or Slovak babel. So, I think this could be related to texlive-lang-czechslovak package. Testing document, error repeateble in Gummi, TeXworks and TeXstudio. \documentclass{article} \usepackage[english]{babel} % English works %\usepackage[spanish]{babel} % Spanish works %\usepackage[czech]{babel} % Czech does NOT work %\usepackage[slovak]{babel} % Slovak does NOT work \usepackage{worldflags} \begin{document} \worldflag{SK} \end{document} Error: /usr/share/texmf/tex/latex/worldflags/worldflag_SK.tex:10: Missing number, treated as zero. The issue is still present in Debian unstable. The ldf files for Czech and Slovak both read: %% Czech Language Definition File %% Please report errors to: Petr Tesa\v r\'ik %% babel at tesarici.cz Are you willing to contact Petr to get an opinion about the issue? At least we should learn if the issue is in the ldf files or not. Thanks! Hilmar -- sigfault
Bug#989029: info: scroll-backward is buggy
Control: reassign -1 gnuplot-doc Am 24.05.2021 um 01:36 teilte Vincent Lefevre mit: Hello, as discussed in that bug the issue seems only to occur w/ gnuplot-doc so the issue is specific to the gnuplot documentation. Please be so kind to have a look at the issue. Hilmar The info manual says: ('scroll-backward') Shift the text in this window down. The inverse of 'scroll-forward'. If you are at the start of a node, takes you to the "previous" node, so that you can read an entire manual from finish to start by repeating . The default scroll size can be changed by invoking the ('scroll-backward-page-only-set-window') command with a numeric argument. [...] But this doesn't behave like that in the gnuplot manual from the gnuplot-doc 5.4.1+dfsg1-1 Debian package: Go to "Bugs". This gives 5 Bugs ** Please e-mail bug reports to the gnuplot-bugs mailing list or upload the report to the gnuplot web site on SourceForge. Please give complete information on the version of gnuplot you are using and, if possible, a test script that demonstrates the bug. See 'seeking-assistance'. * Menu: * known_limitations:: * External_libraries:: Then do a scroll-backward (with the Backspace or PageUp key). This gives: 5.2 External libraries == [...] which is not the "previous" node, but some later node. -- System Information: Debian Release: 11.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-security'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-7-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages info depends on: ii install-info 6.7.0.dfsg.2-6 ii libc6 2.31-12 ii libtinfo6 6.2+20201114-2 info recommends no packages. info suggests no packages. -- no debconf information -- sigfault
Bug#989029: info: scroll-backward is buggy
Control: tags -1 + wontfix Am 24.05.2021 um 01:36 teilte Vincent Lefevre mit: Hi, As found out the issue is limited to this specific info page and probably not a bug in info, but in the info page. I tag the bug as wontfix for now. Hilmar The info manual says: ('scroll-backward') Shift the text in this window down. The inverse of 'scroll-forward'. If you are at the start of a node, takes you to the "previous" node, so that you can read an entire manual from finish to start by repeating . The default scroll size can be changed by invoking the ('scroll-backward-page-only-set-window') command with a numeric argument. [...] -- sigfault
Bug#1024065: info: infinite(?) loop with LC_ALL=C
Control: tags -1 + pending patch Am 14.11.2022 um 11:44 teilte Jakub Wilk mit: Hi, This seems to hang forever: $ LC_ALL=C info python3.10 -n 'Other Language Changes<3>' Upstream has provided a patch (which solved the issue for me), new packages for amd64 are here [1]. If you need build for other arch for testing please build the package for it. Hilmar [1] https://freeshell.de/~hille42/texinfo/ -- sigfault
Bug#1023590: RFS: monitoring-plugins-check-logfiles/4.1.0.1-1 [ITP] -- Nagios plugin check_logfiles
Am 16.11.2022 um 20:16 teilte Alexander Reichle-Schmehl mit: Hi, Thanks for the upload! Just two small remarks: * I think it would be relatively easy to add autopkgtest to the package, allowing automatic verification of the functionality. * Feel free to ping me for additinal pointers / examples. > As you did an non-source only upload I probably have to do another upload anyway. Maybe I'm wrong here. * I know that there is a maintainers team for several icinga / monitoring related packages, but I don't know how they are organized. Please consider joining them; team maintainership is usually a very good idea for various reasons. I'll consider to contact them. Hilmar -- sigfault
Bug#1023007: tex-common: configuration fails due to "Illegal instruction" on i386
Control: retitle -1 luatex has no support for CPU's w/o SSE2 Control: tags -1 + wontfix Am 29.10.2022 um 04:51 teilte G.raud mit: Hi, When trying to reconfigure the package tex-common (whose configuration had already failed previously): I just found the upstream bug: http://tracker.luatex.org/view.php?id=1008 Tag it wontfix. Sorry! H. -- sigfault
Bug#1023920: asymptote-x11: xasy crashed when clicking on the grid button
Control: tags -1 + patch fixed-upstream Am 13.11.2022 um 00:53 teilte Jean-Philippe Georget mit: Hi, Yes the bug is not present anymore. When I toggle on the grid icon, it works as expected. Tagging. The asy release will be probably released soon, hence I'd rather wait, then doing a patch release. H. -- sigfault