Bug#1083279: biber: can't build debian-package-book-* with pbuilder anymore because aof missing dependency
Control: severity -1 important On 03.10.2024 22:14, gregor herrmann wrote: Hi all, Which confirms my hunch that the problem is not with biber and not with libencode-perl. Thanks for the information. For now I lower the severity. H. -- Testmail OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1074976: fweb: ftbfs with GCC-14
On 03.07.2024 14:27, Matthias Klose wrote: Hi Yann, The package fails to build in a test rebuild on at least amd64 with gcc-14/g++-14, but succeeds to build with gcc-13/g++-13. The severity of this report will be raised before the trixie release. Here are the first two patches in case you are interested. They solve a few issues, but of course not all. In 2023 version 1.70 was released, not sure if it makes sense to have a look at that version. Hilmar -- sigfault --- fweb-1.62.orig/Web/configure +++ fweb-1.62/Web/configure @@ -614,7 +614,7 @@ cat > conftest.$ac_ext <&5; (eval $ac_link) 2>&5; } && test -s conftest; then ac_cv_prog_cc_works=yes --- fweb-1.62.orig/Web/ftangle.c +++ fweb-1.62/Web/ftangle.c @@ -1402,7 +1402,7 @@ static boolean is_label= NO; static boolean should_continue= NO; -static continuation_line= NOT_CONTINUATION; +static int continuation_line= NOT_CONTINUATION; static STMT_LBL stmt_num[50]; --- fweb-1.62.orig/Web/ftangle.web +++ fweb-1.62/Web/ftangle.web @@ -460,7 +460,7 @@ /* Various flags help \Fortran\ out. */ static boolean is_label = NO; static boolean should_continue = NO; -static continuation_line = NOT_CONTINUATION; +static int continuation_line = NOT_CONTINUATION; static STMT_LBL stmt_num[50]; /* Archaic; for numbering |do|s in \Fortran. Should use \Ratfor\ instead. */ OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1077439: Fwd: Bug#1077439: latex-cjk-japanese-wadalab: FTBFS: wftodm.c:57:1: error: return type defaults to ‘int’ [-Wimplicit-int]
On 01.08.2024 14:30, Danai SAE-HAN (韓達耐) wrote: Hi Danai, sounds rather like a wacky solution, as we hide the code issues, instead of solving them However as explained: the code is never used by the end user, hence the quality does not matter. I checked with diffoscope, everything fine. Go ahead and many thanks! Will you run dput after salsa commit? Hilmar The easiest fix is to replace the following line in debian/rules: cc -Wall -g -O2 -o build/wftodm wftodm.c with: cc -ansi -g -O2 -o build/wftodm wftodm.c It works under GCC 14 as well. The "wftodm" binary is only used during build time to build AFM and PFA fonts; it is not shipped to the end user of the package. So IMHO this easy fix is enough. What do you think? If you agree, I will upload the change to Salsa. -- sigfault
Bug#1077439: Fwd: Bug#1077439: latex-cjk-japanese-wadalab: FTBFS: wftodm.c:57:1: error: return type defaults to ‘int’ [-Wimplicit-int]
Control: tags -1 + help On 31.07.2024 10:48, Danai SAE-HAN (韓達耐) wrote: Hi Danai, When compiling wftodm.c from the latex-cjk-japanese-wadalab package, I get a bunch of warnings with GCC 13 (see also below Lucas' output). To me, these seems just fairly benign warnings based on deprecated C89 conventions. With GCC 14 these warnings turn into errors and the build fails (as described), so these messages are not benign. They are long standing, though. On the other hand, they are just syntax errors; so people which speak C, should be able to fix them. I tried do a patch, but my C knowledge got lost over years. I tag that bug "help" for now. With this bug report, I've been thinking: should we continue to put time and effort in a venerable but older package like CJK? Or do we keep this package as legacy, and forcefully ignore some of the warnings of the C compiler? Let me know what you think. Unfortunately I don't speak CJK, I've never used any of these packages. Hence I can't really say, how useful latex-cjk-japanese-wadalab is. The popcon of both package are comparable (probably b/c latex-cjk-all declares a dep on it). So, we can't simply drop it. I tend to say: let's wait for help. Hilmar OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1077073: texlive-bin FTBFS on 32-bit with gcc 14
Control: forwarded -1 https://tug.org/pipermail/tex-live/2024-July/050773.html On 25.07.2024 21:18, Adrian Bunk wrote: Hi, https://buildd.debian.org/status/logs.php?pkg=texlive-bin&ver=2024.20240313.70630%2Bds-3 I've forwarded the issue for now. H. -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1074343: src:texlive-bin: fails to migrate to testing for too long: unresolved RC issue
On 26.06.2024 22:25, Paul Gevers wrote: Hi, The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:texlive-bin has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version has an RC bug filed that's not resolved yet: 1072056. As you noticed this bug is just an Migration blocker bug, the only reason is to present the migration to testing for now. I can close it at any point in time, when I think the time is up. Same for #1072054 and I would have done this in one of the next days. Hilmar -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1005961: nq,fq: trying to overwrite '/usr/bin/fq', which is also in package nq 0.3.1-4
On 04.06.2024 17:29, Stephen Gelman wrote: On May 29, 2024 at 4:04:13 PM, Bastian Germann mailto:b...@debian.org>> wrote: Hi, I suggest fq renames the binary because it was introduced over 4 years later and has only been in one release so far. Both packages have very low usage acc to popcon, but for fq the fq binary is the entire point of the package, whereas for nq, the fq binary seems to only be a small part of the functionality of the package. Therefore, I think that nq should rename the fq binary. With that argument I could also upload another new package called tq, which contains only the binary /usr/bin/tq (+ man page) and argue that it has the right keep that name b/c it is the only binary in it. ;-) I rather follow the argumentation of Bastian: new packages should better care if they introduce file conflicts w/ existing packages, especially if the names of the programs are rather short. I had a look if there are packages, which needs nq or fq for building, i.e. if renaming could cause FTBFS bugs: currently there are none for both. So, we only will generate frustrated end users. Hilmar -- sigfault
Bug#1072828: Work-around is ineffective on !amd64
Control: reassign -1 texlive-base Control: found -1 2024.20240401-2 Control: tags -1 + pending patch On 19.06.2024 13:19, Adrien Nader wrote: Hello, I found https://tug.org/svn/texlive?revision=71214&view=revision this morning. It only touches the win32 implementations however. I did something similar for the non-win32 implementation and it fixed the issue for me: https://git.launchpad.net/~adrien/ubuntu/+source/texlive-bin/commit/?id=ccb9edaa83fe517936416ab24476351e3ad7 While the issue is fixed, my confidence in the change is average at best as there could be many side effects. I would prefer to have something from upstream. I just asked upstream and here is the patch: https://tug.org/svn/texlive?revision=71233&view=revision I'll upload fixed tl-base soon; the test build run fine. Hilmar -- sigfault
Bug#1072828: Work-around is ineffective on !amd64
On 18.06.2024 23:01, Adrien Nader wrote: Hi Adrien, I've straced the build and the file seems generated and I see some interesting things. I've heavily edited the output because the original is already 11M. The file is created and written to but it's in "/build/therion-oW9QKw/therion-6.2.1/build/thbook" rather than "/tmp/mt646779.tmp" where mktexpk expects it to be. I rather compared the logs from a working [1] and a not working build [2] The working build says: kpathsea: Running mktexpk --mfmode / --bdpi 600 --mag 1+0/600 --dpi 600 logo10 mkdir: cannot create directory ‘././sbuild-nonexistent’: Permission denied mktexpk: Running mf-nowin -progname=mf \mode:=ljfour; mag:=1+0/600; nonstopmode; input logo10 This is METAFONT, Version 2.71828182 (TeX Live 2023/Debian) (preloaded base=mf) (/usr/share/texlive/texmf-dist/fonts/source/public/knuth-lib/logo10.mf (/usr/share/texlive/texmf-dist/fonts/source/public/knuth-lib/logo.mf [77] [69] [84] [65] [70] [80] [83] [79] [78]) ) Font metrics written on logo10.tfm. Output written on logo10.600gf (9 characters, 1748 bytes). Transcript written on logo10.log. mktexpk: /tmp/texfonts/pk/ljfour/public/knuth-lib/logo10.600pk: successfully generated. ) (see the transcript file for additional information) ...so all generated files go to /tmp. kpathsea: Running mktexpk --mfmode / --bdpi 600 --mag 1+0/600 --dpi 600 logo10 mktexpk: Running mf-nowin -progname=mf \mode:=ljfour; mag:=1+0/600;nonstopmode; input logo10 This is METAFONT, Version 2.71828182 (TeX Live 2025/dev/Debian)(preloaded base=mf) (/usr/share/texlive/texmf-dist/fonts/source/public/knuth-lib/logo10.mf (/usr/share/texlive/texmf-dist/fonts/source/public/knuth-lib/logo.mf [77] [69] [84] [65] [70] [80] [83] [79] [78]) ) Font metrics written on /<>/build/thbook/logo10.tfm. Output written on /<>/build/thbook/logo10.600gf (9 characters, 1748 bytes). Transcript written on /<>/build/thbook/logo1 0.log. The statement --output-dir= (which is handed over to the pdftex command by the CMakeLists.txt) is regarded and the generated files are put anywhere. Note that while running the commands directly myself, it seems I managed to generate the file in an expected location and I was getting an error about logo10.720gf rather than .600gf. Well, this is probably due to no submitting the correct parameters to mktexpk. In my test package the command is Running mktexpk --mfmode / --bdpi 600 --mag 1+120/600 --dpi 720 logo10 in the end logo10.720pk is generated hille@rasppi2:~/tmp-1.0 $ pdffonts thbook.pdf name type encoding emb sub uni object ID - --- --- --- - [none] Type 3Custom yes no no 4 0 SDXKYB+CMR10 Type 1Builtin yes yes no 5 0 ...and probably used. This is only a simple test file having the Logo10 as only Type3 font. Several environment variables refer to the first directory: KPSE_DOT, TEXINPUTS, OLDPWD, TEXMF_OUTPUT_DIRECTORY. For TEXMF_OUTPUT_DIRECTORY, I've found the following: https://tug.org/pipermail/tex-live-commits/2024-February/028329.html The commit mostly contains version updates, it is probably not relevant, but the NEWS message is interesting. I'm wondering at all, why the therion package cares about the output path of the pdftex engine. I'll stop there as now I'm definitely out of time for today. I'll stop here too, maybe simply removing the --output-dir statement from the CMakeLists.txt solves the issue. I'll test ASAP. If yes, we don't look at a general issue, which needs to be solved on TL side. Hilmar [1] https://buildd.debian.org/status/fetch.php?pkg=therion&arch=all&ver=6.2.1-1&stamp=1710963335&raw=1 [2] https://buildd.debian.org/status/fetch.php?pkg=therion&arch=amd64&ver=6.2.1-1%2Bb1&stamp=1717847632&raw=1 -- sigfault
Bug#1072828: Work-around is ineffective on !amd64
On 18.06.2024 15:26, Adrien Nader wrote: Hi Adrien, I hit that issue while working on the vtk9 9.3 transition in Ubuntu and I also tried to add 'texlive-fonts-recommended' as a dependency (at least temporarily so that the transition can finish). Unfortunately it only works on amd64. On arm64, armhf, ppc64el and s390x, the error is still present (see https://launchpad.net/~adrien/+archive/ubuntu/oracular-gdcm-ftbfs-vtk-9.3/+sourcepub/16226649/+listing-archive-extra ) I didn't investigate further. > If you look at the build logs you'll notice that only on amd64 the package texlive-fonts-recommended was installed. Not sure, why this happened, but you added it to Build-Depends-Indep instead of Build-Depends (as it was done for texlive-base). H. -- sigfault
Bug#1072682: luametatex: context 2024.04 and luametatex 2.11 no longer build PDF via Pandoc. (+ workaround)
Control: reassign -1 luametatex Control: tags -1 + pending On 06.06.2024 15:17, Gijs Hillenius wrote: Hello, Context 2024.04.01.20240428+dfsg-2 and Luametatex 2.11.02+ds-4 no longer let me build PDFs from Emacs Org-Mode files via Pandoc. After downgrading to luametatex 2.11.01 (from 2.11.02) I can at least build the minimal example, as the format generation works again. I'll downgrade to lmtx 2.11.01 soon. H. -- sigfault
Bug#1072828: texlive-binaries upgrade breaks therion build
On 08.06.2024 16:09, Adrian Bunk wrote: Hi, https://buildd.debian.org/status/fetch.php?pkg=therion&arch=amd64&ver=6.2.1-1%2Bb1&stamp=1717847632&raw=0 ... FAILED: thbook/thbook.pdf /<>/build/thbook/thbook.pdf I can confirm that the failing command works fine on a normal computer..this is a chroot on arm64. hille@rasppi2:~$ mktexpk --mfmode / --bdpi 600 --mag 1+0/600 --dpi 600 logo10 mktexpk: Running mf-nowin -progname=mf \mode:=ljfour; mag:=1+0/600; nonstopmode; input logo10 This is METAFONT, Version 2.71828182 (TeX Live 2025/dev/Debian) (preloaded base=mf) (/usr/share/texlive/texmf-dist/fonts/source/public/knuth-lib/logo10.mf (/usr/share/texlive/texmf-dist/fonts/source/public/knuth-lib/logo.mf [77] [69] [84] [65] [70] [80] [83] [79] [78]) ) Font metrics written on logo10.tfm. Output written on logo10.600gf (9 characters, 1748 bytes). Transcript written on logo10.log. mktexpk: /home/hille/.texlive2024/texmf-var/fonts/pk/ljfour/public/knuth-lib/logo10.600pk: successfully generated. /home/hille/.texlive2024/texmf-var/fonts/pk/ljfour/public/knuth-lib/logo10.600pk hille@rasppi2:~$ Hence I tend to say this is something specific for sbuild environments, which could have lower priority than "serious". Downgrading texlive-binaries to 2023.20230311.66589-9 OR installing texlive-fonts-recommended works around this issue. Why not simply adding texlive-fonts-recommended to BD (which carries the Type1 fonts of logo10) and then solve the issue? We may open a new bug "why does mktexpk does not work in an sbuild?", but this could have a lower priority, IMHO. H. -- sigfault
Bug#1071893: sagetex: FTBFS: unsatisfiable build-dependencies
Control: reassign -1 python3-ipywidgets Control: found -1 8.1.1-5 Control: affects -1 src:sagetex On 25.05.2024 19:22, Santiago Vila wrote: Hello, If this is really a bug in one of the build-depends, please use reassign and affects, so that this is still visible in the BTS web page for this package. Doing so. H. -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1005961: nq,fq: trying to overwrite '/usr/bin/fq', which is also in package nq 0.3.1-4
Control: found -1 fq/0.9.0-2 Control: found -1 nq/0.3.1-4 On 18.02.2022 08:39, Axel Beckert wrote: Hello, Trying to install fq fails for me as follows: Preparing to unpack .../archives/fq_0.0.4-2_amd64.deb ... Unpacking fq (0.0.4-2) ... dpkg: error processing archive /var/cache/apt/archives/fq_0.0.4-2_amd64.deb (--unpack): trying to overwrite '/usr/bin/fq', which is also in package nq 0.3.1-4 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/fq_0.0.4-2_amd64.deb As these two "fq" seem to have completely different purposes, please either rename one of the commands (or both) or add a Conflicts header to conflict with the other package. While preparing a NMU for nq Christoph Biedl pointed out, that the issue was solved the wrong way. According to the policy [1] "Two different packages must not install programs with different functionality but with the same filenames. (...) If this case happens, one of the programs must be renamed. The maintainers should report this to the debian-devel mailing list and try to find a consensus about which program will have to be renamed. If a consensus cannot be reached, both programs must be renamed." For now I reopen the bug, not 100% sure how to proceed. I'm not the maintainer of nq and I won't be able to make a strong decision like renaming a binary in the nq package. Hilmar [1] https://www.debian.org/doc/debian-policy/ch-files.html -- -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1061546: srcpd: installs file into aliased location
Control: tags -1 + pending On 26.01.2024 23:01, Preuße...@buxtehude.debian.org, Hilmar wrote: On 26.01.2024 09:35, Chris Hofstaedtler wrote: Hi, Please move /lib/udev/rules.d/10-liusb.rules into /usr/lib before srcpd reaches testing. hille42@hz:~/devel/srcpd$ dpkg-deb -c srcpd_2.1.6-2_amd64.deb|grep usb -rw-r--r-- root/root 151 2024-01-26 21:45 ./usr/lib/udev/rules.d/10-liusb.rules I guess this looks OK, not sure when I'll upload. Tag bug pending, time for upload still not determined. H. -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1068419: perdition: dependencies unsatisfiable after binnmu for time64 transition.
Control: tags -1 + patch
On 04.04.2024 21:57, Peter Green wrote:
Hi,
After being rebuilt for the time64 transition, perdition
depends on both libvanessa-socket2 and libvanessa-socket2.
As a result it is uninstallable.
Interesting in this case, the uninstallability seems to apply to all
architectures and not just those undergoing the time64 transition.
For any unknown reason the dep on libvanessa-socket2 is hard coded in
the control file:
Package: perdition
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, libvanessa-socket2 (>=
0.0.12), lsb-base (>= 3.2-14)
Conflicts: perdition-bdb
So I guess removing that libvanessa-socket2 (>= 0.0.12) and rebuilding
the package should solve the issue.
H.
--
sigfault
OpenPGP_signature.asc
Description: OpenPGP digital signature
Bug#1066117: FTBFS: missing build-dep on libnsl-dev
On 12.03.2024 21:59, Aurelien Jarno wrote: Hi Aurelien, Starting with glibc 2.31, support for NIS (libnsl library) has been moved to a separate libnsl2 package. In order to allow a smooth transition, a libnsl-dev has been added to the libc6-dev package. This dependency has been temporarily dropped in the 2.37-15.1 NMU, as part of the 64-bit time_t transition. This causes proftpd-dfsg to FTBFS in sid with: I've seen the issue, but I wasn't sure if I have to do something or if I have just have to wait until the dep change has been reverted. Let me know if I should upload a fixed package w/ the BD added. Thanks, Hilmar -- sigfault
Bug#1064918: tex-common postinst script fails due to a bug in lua script /usr/bin/mtxrun.lua
Control: affects -1 context,texlive-binaries Control: merge -1 1064402 On 06.03.2024 23:23, Preuße...@buxtehude.debian.org, Hilmar wrote: Control: severity -1 grave Control: reassign -1 luametatex Control: merge -1 1064402 Next try. H. -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064918: tex-common postinst script fails due to a bug in lua script /usr/bin/mtxrun.lua
Control: affects -1 texlive-binaries,context Control: merge -1 1064402 On 06.03.2024 23:23, Preuße...@buxtehude.debian.org, Hilmar wrote: Control: severity -1 grave Control: reassign -1 luametatex Control: merge -1 1064402 Next try. H. -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1065212: asymptote: recent libc6-dev change causes XDR and V3D support to be dropped
On 01.03.2024 23:33, Aurelien Jarno wrote: Hi Aurelien, This can be fixed by adding an explicit Build-Depends on libtirpc-dev. The glibc change will likely be reverted in the short term, but given its a change we want to do for Trixie, this will only lower the severity of the bug. I do not fully understand, what needs to be done from my side: add a BD on libtirpc-dev and (maybe) remove it later on? If you say the change will be reverted later, I'd guess one can rather wait for that point in time and then request an binNMU (or wait until anybody triggers a mass binNMU). What do I miss? Hilmar -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064854: Breaks tex-common's configuration
Control: affects -1 texlive-binaries Control: merge -1 1064402 Control: affects -1 context OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064854: Breaks tex-common's configuration
Control: reassign -1 luametatex Control: severity -1 grave Control: merge -1 1064402 Control: affects -1 context On 26.02.2024 18:50, julien.pu...@gmail.com wrote: Hi, since a few days, I saw a configuration issue with the tex-common package. (What I don't get is why it actually needs configuration since I don't see uploads since months.) No, it is in the upgraded luametatex, which is for the upcoming TL 2024 and should have been uploaded to experimental. Downgrade it and put it on hold. apt-listbugs is helpful here. Sorry, for the inconvenience! Hilmar -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064402: texlive-binaries: tex-common configure: lua error : startup file: /bin/mtxrun.lua:2438: attempt to assign to const variable 'i'
On 21.02.2024 16:15, Vincent Lefevre wrote: Hi Vincent, Indeed, I can reproduce the problem on another machine, only with luametatex 2.11.01+ds-2: qaa:~> mtxrun --generate lua error : startup file: /bin/mtxrun.lua:2438: attempt to assign to const variable 'i' You'll see the failure in an upgrade if you upgrade luametatex at the same time as the TeX Live packages (at least, *not after* TeX Live). Thanks for the report, I'll have a look at that soon. Hilmar -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1061546: srcpd: installs file into aliased location
On 26.01.2024 09:35, Chris Hofstaedtler wrote: Hi, Please move /lib/udev/rules.d/10-liusb.rules into /usr/lib before srcpd reaches testing. hille42@hz:~/devel/srcpd$ dpkg-deb -c srcpd_2.1.6-2_amd64.deb|grep usb -rw-r--r-- root/root 151 2024-01-26 21:45 ./usr/lib/udev/rules.d/10-liusb.rules I guess this looks OK, not sure when I'll upload. Hilmar -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1058462: texlive-bibtex-extra: file conflict with liblatex-tounicode-perl on ltx2unitxt(1) manpage
On 12.12.2023 14:07, Andreas Beckmann wrote: Hi Andreas, thanks for the report, I'll remove the manual page and the perl script from texlive-bibtex-extra . Hilmar during a test with piuparts I noticed your package failed to install because it tries to overwrite other packages files without declaring a Breaks+Replaces relation. From the attached log (scroll to the bottom...): Preparing to unpack .../texlive-bibtex-extra_2023.20231207-1_all.deb ... Unpacking texlive-bibtex-extra (2023.20231207-1) ... dpkg: error processing archive /var/cache/apt/archives/texlive-bibtex-extra_2023.20231207-1_all.deb (--unpack): trying to overwrite '/usr/share/man/man1/ltx2unitxt.1.gz', which is also in package liblatex-tounicode-perl 0.54-1 Errors were encountered while processing: /var/cache/apt/archives/texlive-bibtex-extra_2023.20231207-1_all.deb -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1058038: texlive-extra: Blocker bug
On 11.12.2023 21:30, Chris Hofstaedtler wrote: On Mon, Dec 11, 2023 at 02:57:35PM +, Hilmar Preusse wrote: Hi, Severity: normal This bug blocks the migration for now, I'll close it, once the other two packages tend to migrate. Pretty sure severity: normal does not block => raising. Thanks for pointing that out. reportbug must have have downgraded my bug b/c I did not specify justification for "serious". H. -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1051243: This affects the build of the pspp package
On 20.11.2023 13:11, Luca Boccassi wrote: Hi, This looks like an undeclared versioning dependency issue. If there are such constraints, please consider declaring them appropriately in the package control file by defining a dependency on the exact upstream version of zlib (e.g.: >= 1.3~ and << 1.3.1 or something like that). Then every new upstream revision of zlib need to be handled as a sort- of soname transition for tex-common. Currently it is rather an overdone version check in the source code. In rev -8 we have untighten that check. Further a simple rebuild would have solved the issue too. H. -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1051243: This affects the build of the pspp package
On 20.11.2023 10:43, Friedrich Beckmann wrote: Hi, i noticed a failure in our CI pipeline for pspp probably due to this bug. The problem occurs when I try to install "apt install texlive-plain-generic“. The install fails with A new package is on the way. Another adaption to zlib is needed, I'll trigger that later on. H. -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1056186: texlive-binaries: zlib library mismatch
On 18.11.2023 15:42, Jerome BENOIT wrote: Hi, To clarify things, the message is not only irritating but also aborting: the package tex-common cannot currently configure. I'm aware of this: the other user reported a core dump and in our output an aborted message is visible. Therefore I'm afraid, that a simple rebuild won't solve the issue. H. -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1056183: Bug#1056186: texlive-binaries: zlib library mismatch
On 18.11.2023 14:57, Jerome Benoit wrote: Hi, Hi, the issue appeared to me within a Sid schroot environment at postinstallation time of tex-common. I traced it back to texlive-binaries by looking the logfile at the fmutils stage. The issue seems to originate from the recent migration from zlib 1.2.13 to zlib 1.3. For short, the following command-line $ luatex -ini -jobname=luatex -progname=luatex luatex.ini gives PANIC: unprotected error in call to Lua API (zlib library version does not match - header: 1.2.13, library: 1.3) aborted Already reported, but on the wrong package. I'll try, whether a simple rebuild of the package solves the issue, but I'm afraid it won't. The message "zlib library version does not match - header: 1.2.13, library: 1.3" is irritating, but I know that behavior from other packages too (e.g. proftp). I understand this warning: "expect trouble ahead". Hilmar -- sigfault 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#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#1055111: ffmpeg FTBFS: makeinfo: Undefined subroutine &Texinfo::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&ver=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 &Texinfo::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#1052048: texlive-bibtex-extra: Can't generate bibliography since last upgrade at trixie
On 16.09.2023 17:16, Mechtilde Stehmann wrote: Hello Mechtilde, After last update at trixie I can't proper build https://salsa.debian.org/ddp- team/dpb/ locally. It builds correct on trixie at the Salsa CI at 03.09.2023. The last upload to trixie was at 05.09.2023. Do you have some kind of log file, showing an error message? Please don't send files having a size of > 100KB. I lost the bibliography in the pdf of this big document. That's why I set it to grave. For now I leave it at this severity, although I don't share you opinion. Hilmar -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Bug#1041508: tex-common: fmutil fails to rebuild formats
On 04.09.2023 00:21, Preuße...@buxtehude.debian.org, Hilmar wrote: On 03.09.2023 07:20, Paul Gevers wrote: Hello Paul, I've just added an ignore hint for texlive-extra, as the r-bioc-biocstyle issue is clearly less of a problem than this one (and bug reports are filed). Thanks for your response! When will the ignore hint be effective? Andreas T. uploaded my (untested) fix to unstable. So in case the fix is correct, r-bioc-biocstyle should stop blocking texlive-extra soon. Hilmar -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Bug#1041508: tex-common: fmutil fails to rebuild formats
On 03.09.2023 07:20, Paul Gevers wrote: Hello Paul, I've just added an ignore hint for texlive-extra, as the r-bioc-biocstyle issue is clearly less of a problem than this one (and bug reports are filed). Thanks for your response! When will the ignore hint be effective? Hilmar -- sigfault
Bug#1041508: tex-common: fmutil fails to rebuild formats
Control: reassign -1 texlive-binaries On 20.07.2023 00:06, ಚಿರಾಗ್ ನಟರಾಜ್ wrote: Hi, Upgrading tex-common seems to fail when attempting to rebuild formats (log attached). That issue is in texlive-binaries and has been solved there. H. -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Bug#1037510: texlive-lang-japanese: dangling symlinks due to missing dependencies
On 13.06.2023 18:00, Vincent Lefevre wrote: Hi Vincent, There is a dangling symlink on my machine: /usr/share/texlive/texmf-dist/fonts/truetype/public/ipaex/ipaexm.ttf -> ../../../../../../fonts/opentype/ipaexfont-mincho/ipaexm.ttf This seems to be due to a missing dependency on fonts-ipaexfont-mincho. Thanks for the report! Currently we just suggest these 4 packages. I propose to promote the suggest to recommend. Do you think that would be sufficient? Mhhh: these 4 packages have a (installed) size of 40MB. Maybe the is neglect-able given the size of texlive-lang-japanese (300MB). Let me know what you think. H. -- sigfault OpenPGP_0x0C871C4C653C1F59.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#1035857: texlive-fonts-extra: broken font symlinks for junicode
On 10.05.2023 11:18, Andreas Beckmann wrote: Hi again, during a test with piuparts I noticed your package ships (or creates) broken symlinks: OK, had a closer look: the "Debian Fonts Task Force" replaced the "Junicode 1" by "Junicode 2" although they may behave differently "Users of the various versions of Junicode 1 need to be aware that documents originally set in Junicode 1 may reflow when set in Junicode 2. Further, documents that use the OpenType features of Junicode 1 (aside from basics like kerning and standard ligatures) may not be displayed properly when changed over to Junicode 2." I guess it would have been better to create fonts-junicode2 and then slowly phase out fonts-junicode, when v2 left beta stage. I could simply fix the links and point them to the v2 OTF fonts. This could be even done now. This would give Debian users the v2 fonts but I don't know if they are compatible to the Junicode related files in texlive-fonts-extra. Junicode v2 wasn't even uploaded to CTAN yet. I guess it is a better idea to stay with Junicode 1 for now and re-integrate them into tfe after bookworm.. fonts-alegreya-sans will not be in bookworm (and hasn't been in bullseye), thus /usr/share/texlive/texmf-dist/fonts/opentype/huerta/alegreya also contains broken symlinks. Well, I tend to say "this is not my fault". I may revert my decision after bookworm. H. -- sigfault
Bug#1035857: texlive-fonts-extra: broken font symlinks for junicode
Control: tags -1 + bookworm-ignore On 10.05.2023 22:47, Andreas Beckmann wrote: On 10/05/2023 22.24, Preuße, Hilmar wrote: Hi, 42a992dff6dd2b54ce0ffc10367a29913e062c0b, else there would be no upgrade path from bullseye to bookworm. I have to delay the fix to post-bookworm. 42f75ab3ead843b6b04edc6f4aed7498cb53101f . This could be reverted before bookworm, I'd need to build a new orig.tar.gz as the font files are black listed. Is it really that urgent? You have some nice non-trivial packages here ;-) Well, yes. If you say the broken symlinks are not really a problem for bookworm (and hard to fix), feel free to downgrade the severity and People trying to use that font, would need to install a package from unstable. Until now there was no complaint (except you). Best thing we could do is to fix the issue in fonts-alegreya-sans. I tried so by reporting to upstream, but currently there is not much move. postpone a fix for it to trixie. "trixie"? First release for years, not starting with "b". I started already confusing the code names. ;-) H. -- -- sigfault
Bug#1035857: texlive-fonts-extra: broken font symlinks for junicode
On 10.05.2023 11:18, Andreas Beckmann wrote: Hello, during a test with piuparts I noticed your package ships (or creates) broken symlinks: 3m10.3s ERROR: FAIL: Broken symlinks: /usr/share/texlive/texmf-dist/fonts/truetype/public/junicode/Junicod -> ../../../../../../fonts/truetype/junicode/Junicode-BoldItalic.ttf (texlive-fonts-extra-links) /usr/share/texlive/texmf-dist/fonts/truetype/public/junicode/Junicode-Bold -> ../../../../../../fonts/truetype/junicode/Junicode-Bold.ttf (texlive-fonts-extra-links) /usr/share/texlive/texmf-dist/fonts/truetype/public/junicode/Junicode-It -> ../../../../../../fonts/truetype/junicode/Junicode-Italic.ttf (texlive-fonts-extra-links) /usr/share/texlive/texmf-dist/fonts/truetype/public/junicode/Junicode.ttf -> ../../../../../../fonts/truetype/junicode/Junicode.ttf (texlive-fonts-extra-links) fonts-junicode nowadays only ships *.otf, no more *.ttf. I planned to fix that in the past (move files from t-f-e-links to t-f-e), see commit 7fc1a4238a23a5bc0a7c76fd6465906d48601a0a . Unfortunately at the same time I moved that some files into the other direction, so I had to revert that step in 42a992dff6dd2b54ce0ffc10367a29913e062c0b, else there would be no upgrade path from bullseye to bookworm. I have to delay the fix to post-bookworm. The Junicode link names also look broken to me, like they got truncated somehow, and missing the file extension. Especially the first one: "Junicod". Yes, this is definitely a Typo, but correcting them does not solve an issue. fonts-alegreya-sans will not be in bookworm (and hasn't been in bullseye), thus /usr/share/texlive/texmf-dist/fonts/opentype/huerta/alegreya also contains broken symlinks. Was introduced in 5a1a62fe981bf67e743592ba689c2f18853a8886. Unfortunately I noticed to late that fonts-alegreya-sans is RC buggy and I downgraded the Dep to recommend: 42f75ab3ead843b6b04edc6f4aed7498cb53101f . This could be reverted before bookworm, I'd need to build a new orig.tar.gz as the font files are black listed. Is it really that urgent? Hilmar -- sigfault
Bug#1035051: pssh: Fail to start
On 28.04.2023 12:55, Christian Marillat wrote: Hi, Dear Maintainer, This version fail to send files with this error (Was working with 2.3.4-2): This happens (probably) b/c your hosts file contains a port specification. I've put a patched package on [1]. In my tests it solved the issue; could you check? Hilmar [1] https://freeshell.de/~hille42/pssh/ -- sigfault
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#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#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#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#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#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#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#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#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#1021658: Processed: autopkgtest regressions are RC (and this one also blocks the perl transition)
Am 24.10.2022 um 19:48 teilte Paul Gevers mit: Hi all, I think Hilmar was afraid of what happens after latexml is removed from testing. Than TL migrates and breaks latexml for users of testing that don't immediately remove packages that are no longer in testing. Yes, correct. The idea to add a breaks into texlive-latex-base sounds reasonable to me and I'll introduce it. Meanwhile latexml upstream has provided a patch for the issue. I did not test it, but they have their own test beds and it looks good so far. Not sure when I'll find time to upload new packages. Hilmar -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Bug#1021658: Processed: autopkgtest regressions are RC (and this one also blocks the perl transition)
Am 22.10.2022 um 10:21 teilte Debian Bug Tracking System mit: Hi Adrian, the breakage is not caused by the perl upload, but due to the latest TeX Live upload at the beginning of this month. Hence TL either does not migrate to testing (which is good in the moment IMHO). I reported the issue upstream, not sure when we get a solution. I could remove the few failing tests from the test suite, but we would get a degraded TL / latexml combination in testing this way. Can we add an override / hint to make sure perl migrates to testing? Further the autorm for latexml would need to be removed, else the new TL will migrate to testing and will break an (already) installed latexml package. Any further ideas how to handle the situation? Hilmar severity 1021658 serious Bug #1021658 [latexml] latexml: AutoPKG test suite fails since latest upload of TLive Severity set to 'serious' from 'important' block 1019353 by 1021658 Bug #1019353 [release.debian.org] transition: perl 5.36 1019353 was blocked by: 1022133 1022150 1021324 1016761 1021735 1022132 1020446 1022124 1022152 1019353 was blocking: 1022003 Added blocking bug(s) of 1019353: 1021658 thanks Stopping processing here. -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Bug#1016272: transient bug in latex
Am 12.10.2022 um 11:22 teilte Cédric Boutillier mit: Hi, For the record, please find attached one of the latex files produced with kramdown which was causing the problematic character, together with the output of the failing compilation log with latex from texlive-latex-base/2022.20220722-1, and the succeeding compilation with texlive-latex-base/2022.20220923-1. Best wishes, (/usr/share/texlive/texmf-dist/tex/latex/ucs/utf8x.def File: utf8x.def 2022/08/07 UCS: Input encoding UTF-8 Package ucs Info: utf8x disabled, assuming standard utf8 processing (ucs) load ucs package to force utf8x processing. Seems "utf8x" is finally dead! Yehh! As of beginning of August utf8x falls back to standard utf8 inputenc and hence we don't run into utf8x bugs. Hilmar -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Bug#1016272: transient bug in latex
Control: notfound -1 2022.20220923-1 Am 12.10.2022 um 11:22 teilte Cédric Boutillier mit: This bug seems caused by a transient bug due to a non-UTF8 character in one of the included files by latex(?). This problem was present with texlive-latex-base 2022.20220722-1, but after the recent upgrade to 2022.20220923-1, the problem has disappeared, and all tests pass. Next try for control. H. -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Bug#1016055: fmtutil failed. Output has been stored in
Am 01.08.2022 um 09:22 teilte Klaus Ethgen mit: Am So den 31. Jul 2022 um 22:02 schrieb Hilmar Preuße: Hi Klaus, This sounds like a full file system during installation, which can lead to various issues like this. I suggest to close the issue as "caused by full file system". Could be but I suspect apt/dpkg to take care of that and fail graceful. The install script of a package fails, hence apt declares the whole package installation to be not successful. apt can't do much in this situation except trying the script of the later version in the hope a script bug was fixed in the new version. This was not the case, the script failed (probably) due to a full file system. This is not uncommon when doing TL upgrades. So, what do you expect? Should apt delete some random files and start over? apt could try to do some random system checks like "df -h", show users the results, so they get an idea why the installation failed. However this is an wishlist bug for apt, not a serious bug for "tex-common". Can we close the issue here? Hilmar -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Bug#1016323: gnuplot: FTBFS: dvips: DVI file can't be opened: gnuplot.dvi: No such file or directory
Control: reassign -1 src:gnuplot OpenPGP_signature Description: OpenPGP digital signature
Bug#1016323: gnuplot: FTBFS: dvips: DVI file can't be opened: gnuplot.dvi: No such file or directory
Am 31.07.2022 um 15:38 teilte Adrian Bunk mit:
Control: reassign -1 src:gnuplot
Hi,
It works after downgrading texlive-latex-base to 2022.20220605-1.
Testcase:
$ cat test.tex
\documentclass{article}
\usepackage[utf8x]{inputenc}
\usepackage{hyperref}
\begin{document}
.
\end{document}
Many thanks for your minimal example. According to upstream (David
Carlisle) one should avoid using utf8x and instead switch to utf8
instead (see [1]). Consider to replace utf8x to utf8. Feel free to call
back if this does not solve the issue.
Hilmar
[1] https://tex.stackexchange.com/q/652187/50836
--
sigfault
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1016055: fmtutil failed. Output has been stored in
Am 31.07.2022 um 15:50 teilte Klaus Ethgen mit: Hi, Some additional informations: Yesterday I found files from texlive-pictures with 0 bytes size. I reinstalled that package and the files have correct size now. This sounds like a full file system during installation, which can lead to various issues like this. I suggest to close the issue as "caused by full file system". Hilmar -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Bug#1016055: fmtutil failed. Output has been stored in
Am 31.07.2022 um 12:15 teilte Klaus Ethgen mit: Hi, buf_size=10 xetex -ini -jobname=xelatex-dev -progname=xelatex-dev -etex xelatex.ini Successful run. I append the log file to the mail. Try to play with different values for buf_size. On [1] they speak about increasing the buf_size, meanwhile they decrease the values. Even without the buf_size setting, xetex runs fine. You could try to run "fmtutil-sys --all" as user root. If that works try to start over using "apt -f install". Hilmst -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Bug#1016055: fmtutil failed. Output has been stored in
Am 31.07.2022 um 10:57 teilte Klaus Ethgen mit: Hi, Could you send me /etc/texmf/web2c/texmf.cnf and the output of "ls -la /etc/texmf/texmf.d/"? ~> ls -la /etc/texmf/texmf.d/ insgesamt 4 drwxr-xr-x 1 root root 24 5. Sep 2021 . drwxr-xr-x 1 root root 124 28. Jun 2017 .. -rw-r--r-- 1 root root 26 12. Mai 2013 00debian.cnf Looks pretty much like standard. Does /etc/texmf/web2c/texmf.cnf contain information regarding buf_size? Could you try to temporarily override buf_size and then call the commands ins question, i.e. buf_size=10 xetex -ini -jobname=xelatex-dev -progname=xelatex-dev -etex xelatex.ini Try to play with different values for buf_size. On [1] they speak about increasing the buf_size, meanwhile they decrease the values. Hilmar [1] https://tex.stackexchange.com/questions/43430/how-to-increase-bufsize-for-lualatex-or-pdflatex -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Bug#1016055: fmtutil failed. Output has been stored in
Am 26.07.2022 um 09:16 teilte Klaus Ethgen mit: Hi, Sorry, late response: the mail did not make it into our mailing list, hence I noticed this bug by chance. fmtutil: running `xetex -ini -jobname=xelatex-dev -progname=xelatex-dev -etex xelatex.ini' ... This is XeTeX, Version 3.141592653-2.6-0.94 (TeX Live 2022/Debian) (INITEX) restricted \write18 enabled. entering extended mode (/usr/share/texlive/texmf-dist/tex/generic/tex-ini-files/xelatex.ini (/usr/share/texlive/texmf-dist/tex/latex-dev/base/latex.ltx! Unable to read an entire line---bufsize=20. Please increase buf_size in texmf.cnf. Could you send me /etc/texmf/web2c/texmf.cnf and the output of "ls -la /etc/texmf/texmf.d/"? Hilmar -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Bug#1015085: texworks-manual: FTBFS: make[4]: *** [Makefile:66: index.ind] Error 1
Control: reassign -1 texlive-plain-generic Control: tags -1 + pending Am 16.07.2022 um 15:56 teilte Lucas Nussbaum mit: Hi, During a rebuild of all packages in sid, your package failed to build on amd64. It was a bug in TeX4HT. I have a patch for this and will upload fixed packages soon. H. -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Bug#1015085: texworks-manual: FTBFS: make[4]: *** [Makefile:66: index.ind] Error 1
Am 22.07.2022 um 14:55 teilte Hilmar Preuße mit: Am 21.07.2022 um 00:20 teilte Hilmar Preuße mit: Am 16.07.2022 um 15:56 teilte Lucas Nussbaum mit: Hi During a rebuild of all packages in sid, your package failed to build on amd64. For now there is an MWE, which compiles fine using LaTeX but can't be processed using htlatex (that's what we try to do). I'll try to contact TeX people soon: I got a heads up from "Michal Hoftich", so I'll start packaging next round of texlive-base, -lang, -extra in the hope to solve the issue. https://tex.stackexchange.com/questions/651631/htlatex-fails-to-convert-file New snapshot solves one issue, build fails later on. We have to investigate. I'll upload new TL snapshots anyway. H. -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Bug#1015085: texworks-manual: FTBFS: make[4]: *** [Makefile:66: index.ind] Error 1
Am 21.07.2022 um 00:20 teilte Hilmar Preuße mit: Am 16.07.2022 um 15:56 teilte Lucas Nussbaum mit: Hi, During a rebuild of all packages in sid, your package failed to build on amd64. For now there is an MWE, which compiles fine using LaTeX but can't be processed using htlatex (that's what we try to do). I'll try to contact TeX people soon: I got a heads up from "Michal Hoftich", so I'll start packaging next round of texlive-base, -lang, -extra in the hope to solve the issue. https://tex.stackexchange.com/questions/651631/htlatex-fails-to-convert-file @Lucas: are there more packages affected using htlatex? Hilmar -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Bug#1015085: texworks-manual: FTBFS: make[4]: *** [Makefile:66: index.ind] Error 1
Am 16.07.2022 um 15:56 teilte Lucas Nussbaum mit:
Hi,
During a rebuild of all packages in sid, your package failed to build
on amd64.
For now there is an MWE, which compiles fine using LaTeX but can't be
processed using htlatex (that's what we try to do). I'll try to contact
TeX people soon:
\listfiles
\documentclass[a4paper,12pt,oneside,openany]{book}
%\usepackage{manual}
%\title{A short manual for \Tw}
%\author{Alain Delmotte, Stefan Löffler, and others}
%\date{}
\begin{document}
\appendix
\chapter{Regular expressions}
\label{sec:regexp}
\end{document}
H.
--
sigfault
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1012018: texlive-bin: FTBFS during separate binary-indep build
Am 28.05.2022 um 21:53 teilte Andreas Beckmann mit: Hi Andreas, Looks like you need to move some bits that are irrelevant for the binary-indep build to a override_dh_install-arch (or probably better execute_after_dh_install-arch) target. Many thanks for the pointer! I could separate the install indep and the install arch target a little better and therefore (hopefully) solve the issue. We are far from being perfect, i.e. we still do a full build for arch "all" just to get 2 transitional packages, but this may be sorted out later. Hilmar -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Bug#1012018: texlive-bin: FTBFS during separate binary-indep build
Am 28.05.2022 um 21:53 teilte Andreas Beckmann mit: Hi, Looks like you need to move some bits that are irrelevant for the binary-indep build to a override_dh_install-arch (or probably better execute_after_dh_install-arch) target. Our build system did not change between TL 2021 & 2022. The only difference is, that we introduced some transitional packages, which are of arch "all" and hence the sbuild is started for arch "all". Now the d/rules files makes some assumption about, which files are there after build, which differs between arch "any" and "all". What would work is to convert the transitional packages into arch "any", but I'm pretty sure some people would not like the idea. Hilmar -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Bug#1012018: texlive-bin: FTBFS during separate binary-indep build
Am 28.05.2022 um 21:53 teilte Andreas Beckmann mit: Hi Andreas, texlive-bin fails to build the arch-indep packages during a separate run as would be done by the buildds. Many thanks for the report! Unfortunately it came to me very late as the mailing list does not like large E-Mails containing build logs. Please avoid attaching large log files. Hilmar -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Bug#1008956: tex-common: Something in package "tex-common" causes dpkg to exit with exit code -1
On 4/6/22 23:34, Ashleigh Moore wrote: Hi, Well, if the /tmp was full, would it have been able to generate the error logs in there? I did run the dpkg configure command like 4 or 5 times, and every time, it made a report.. Maybe there was enough space for the logs, but not for the format files, which should have been generated in that step... Hilmar -- #206401 http://counter.li.org
Bug#1008956: tex-common: Something in package "tex-common" causes dpkg to exit with exit code -1
On 4/6/22 23:34, Ashleigh Moore wrote: Hi, Well, if the /tmp was full, would it have been able to generate the error logs in there? I did run the dpkg configure command like 4 or 5 times, and every time, it made a report.. Maybe there was enough space for the logs, but not for the format files, which should have been generated in that step... Hilmar -- #206401 http://counter.li.org
Bug#1008956: tex-common: Something in package "tex-common" causes dpkg to exit with exit code -1
On 4/6/22 18:49, Ashleigh Moore wrote: Hi, Well uh, this is embarrassing, but apparently it fixed itself overnight. And since the machine rebooted since then, I no longer have the tmp files it made. I suppose if I have this occur again, I'll let you guys know? I am so sorry if this was a waste of your time.. Maybe the /tmp file system was full. I'd close the ticket for now. Would this be OK? Hilmar -- Testmail
Bug#1008956: tex-common: Something in package "tex-common" causes dpkg to exit with exit code -1
Am 05.04.2022 um 00:13 teilte Ashleigh Moore mit: Hi Ashleigh, I noticed the error that dpkg reported: exit code -1, and the package "tex-common". I saw that it made a error report with the name "fmtutil.", but I thought that perhaps it was a fluke brought on by the mammoth number of packages I had it installing. If you have still one of these files, please provide it. Thanks! Hilmar -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Bug#1005033: biber breaks rubber autopkgtest: There were errors running biber.
Control: tags -1 + pending Am 05.02.2022 um 21:29 teilte Paul Gevers mit: Hi, With a recent upload of biber the autopkgtest of rubber fails in testing when that autopkgtest is run with the binary packages of biber from unstable. It passes when run with only packages from testing. In tabular form: Today I uploaded the biblatex release, which corresponds to the biber package. Hence the issue should be already solved. We just have to wait for another round of test results. Hilmar -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Bug#1004671: incompatible with current biblatex version
Control: reassign -1 biber Control: found -1 2.17-1 Am 04.02.2022 um 22:42 teilte Hilmar Preuße mit: Control: reassign -1 texlive-bibtex-extra Control: found -1 2021.20211217-1 Control: tags -1 + pending Maybe leave it better on the biber package to make sure, people don't install the biber upload, which broke the whole thing. H. -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Bug#1004671: incompatible with current biblatex version
Control: reassign -1 texlive-bibtex-extra Control: found -1 2021.20211217-1 Control: tags -1 + pending Am 31.01.2022 um 15:53 teilte Ryan Kavanagh mit: Hi, I'm not sure if this should instead be filed against texlive-bibtex-extra, but the current version of biber is incompatible with the biblatex package currently in Debian unstable. This effectively renders biber useless and makes it impossible to compile documents that use biblatex. The new biblatex has been uploaded to CTAN and has been integrated into the TL packages. I'm currently building new source packages. Hilmar -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Bug#1004671: incompatible with current biblatex version
Control: forwarded -1 https://github.com/plk/biblatex/issues/1202 Am 31.01.2022 um 15:53 teilte Ryan Kavanagh mit: Hi, I'm not sure if this should instead be filed against texlive-bibtex-extra, but the current version of biber is incompatible with the biblatex package currently in Debian unstable. This effectively renders biber useless and makes it impossible to compile documents that use biblatex. Yes, that was a mistake to upload a new biber. Sorry! The issue will be solved by a new biblatex. I asked upstream (biber/biblatex) when there will be an upload to CTAN [1], the answer was "just waiting for a missing biber build for FreeBSD.". Once this is done I'll package the new biblatex to solve the issue. I mark this bug as forwarded although it is not really an upstream issue. Hope this is acceptable for now. Hilmar [1] https://github.com/plk/biblatex/issues/1202 -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Bug#1001785: texlive-extra affected by log4j CVEs
Am 16.12.2021 um 09:38 teilte Sven Mueller mit: Hi Sven, hi Norbert, texlive-extra-utils contains arara (https://github.com/islandoftex/arara) which was updated two days ago via TeX Live (https://www.tug.org/texlive/) which was updated slightly after that. Please update to the newest TeX Live ASAP, as arara in unstable and testing (also stable?) currently bundles a vulnerable apache-log4j2 version. According to my knowledge the arara.jar from stable does not contain the java class in question: hille@sid:~/TL_1 $ unzip -l arara.jar |grep -i lookup|grep -i jndi hille@sid:~/TL_1 $ hille@sid:~/TL_1 $ unzip -l arara_sid.jar |grep -i lookup|grep -i jndi 2937 2021-12-12 23:41 org/apache/logging/log4j/core/lookup/JndiLookup.class So stable is not affected. Could anybody confirm? Hilmar -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Bug#1001785: texlive-extra affected by log4j CVEs
Am 16.12.2021 um 09:38 teilte Sven Mueller mit: Hi, texlive-extra-utils contains arara (https://github.com/islandoftex/arara) which was updated two days ago via TeX Live (https://www.tug.org/texlive/) which was updated slightly after that. Please update to the newest TeX Live ASAP, as arara in unstable and testing (also stable?) currently bundles a vulnerable apache-log4j2 version. For unstable / testing I'll simply push a new CTAN snapshot to the archive. Should not be that hard. I did not check stable yet, but I'm pretty sure it is affected too. I'd put the jar file in question on the blacklist and hence remove it from the package. Would this be OK? Did you check oldstable yet? Hilmar -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Bug#1000710: ghostscript: Fails to convert EPS file using -sDEVICE=pngalpha
Am 27.11.2021 um 16:25 teilte Hilmar Preusse mit: Hi all, Since gs 9.54 the conversion of some eps files does not work for at least one output devices. This came to my attention b/c the test suite of asymptote fails to run for at least one file. I got the information that the issue has been solved in master: https://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=d9d8db23e862707795e76ea8f8cdcf7434b2df65 I can confirm that the file in question now converts correctly. Hilmar -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Bug#1000781: ghostscript breaks asymptote autopkgtest: build fails: GPL Ghostscript 9.55.0: Unrecoverable error, exit code 1
Control: reassign -1 ghostscript Control: severity 1000710 serious Control: merge 1000710 -1 Am 28.11.2021 um 21:29 teilte Paul Gevers mit: Hi Paul, Dear maintainer(s), With a recent upload of ghostscript the autopkgtest of asymptote fails in testing when that autopkgtest is run with the binary packages of ghostscript from unstable. It passes when run with only packages from testing. In tabular form: We are already on it and I forwarded the issue to upstream: https://bugs.ghostscript.com/show_bug.cgi?id=704737 Last statement we got from there was: "This appear to be fixed already, I will narrow down the relevant commit tomorrow." So chances are good to have a fix soon. Hilmar -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Bug#998240: texlive: causes lgrind to FTBFS
Am 01.11.2021 um 14:32 teilte Andreas Beckmann mit:
Hi,
The offending line + some context:
537 % The meta-symbols and their meanings are:
538 % \begin{description}
539 % \item[\$] The end of a line
540 % \item[\^] The beginning of a line
541 % \item[$\backslash$d] A delimiter (space, tab, newline, start of line)
542 % \item[$\backslash$a] Matches any string of symbols (like `.*' in lex)
543 % \item[$\backslash$p] Matches any identifier. In a procedure definition
Replacing the "\item[\^]" by "\item[\^{}]" solved the issue for me. I
guess I don't need to create a patch / pull request for this. ;-)
Hilmar
--
sigfault
OpenPGP_signature
Description: OpenPGP digital signature
Bug#996620: FTBFS: error: cannot bind non-const lvalue reference of type ‘temp_string&’ to an rvalue of type ‘temp_string’
Control: tags -1 + pending Am 16.10.2021 um 12:49 teilte Hilmar Preusse mit: Source: wp2latex Version: 3.100-1 Severity: serious Tags: upstream Justification: 4. Dear Maintainer, the package fails to build from source since gcc-11 is the default compiler: Patch is on salsa, tag pending. H. -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Bug#993164: proftpd-core: When upgrading from Buster to Bullseyes, the installation of ProFTPd fails
Am 31.08.2021 um 12:53 teilte Andreas Günther mit: Hi Andreas, but I realized that now. The whole time the installer was bothered by a line in "/etc/proftpd/proftpd.conf", namely "IdentLookups off". I commented on this line and thus everything could be reinstalled and started successfully. Hmmm. In proftpd-dfsg (1.3.7a-2) I did: * Enclose "IdentLookups off" in in sample configuration. According to https://github.com/proftpd/proftpd/issues/677 . Best regards and thank you very much Can we close the case now? Hilmar -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Bug#993164: proftpd-core: When upgrading from Buster to Bullseyes, the installation of ProFTPd fails
Am 30.08.2021 um 10:16 teilte Andreas Günther mit: Hi, I have now deleted everything again dpkg -r proftpd-core proftpd-basic proftpd-mod-crypto proftpd-mod-wrap and downloaded all the necessary packages and try to install them in order. First the package proftpd-core_1.3.7a + dfsg-12_amd64.deb. But that fails again: dpkg -i proftpd-core_1.3.7a+dfsg-12_amd64.deb I would not expect that this works. Your specific proftp configuration needs to crypto and the wrap modules so I'd expect that the setup fails, b/c they could not be found. However I still don't understand why the setup fails if they are at least in unpacked state. Vormals nicht ausgewähltes Paket proftpd-core wird gewählt. (Lese Datenbank ... 44962 Dateien und Verzeichnisse sind derzeit installiert.) Vorbereitung zum Entpacken von proftpd-core_1.3.7a+dfsg-12_amd64.deb ... Entpacken von proftpd-core (1.3.7a+dfsg-12) ... proftpd-core (1.3.7a+dfsg-12) wird eingerichtet ... usermod: Keine Änderungen Synchronizing state of proftpd.service with SysV service script with /lib/ systemd/systemd-sysv-install. Executing: /lib/systemd/systemd-sysv-install enable proftpd Failed to enable unit: Unit file /etc/systemd/system/proftpd.service is masked. dpkg: Fehler beim Bearbeiten des Paketes proftpd-core (--install): »installiertes proftpd-core-Skript des Paketes post-installation«- Unterprozess gab den Fehlerwert 1 zurück Trigger für man-db (2.9.4-2) werden verarbeitet ... Fehler traten auf beim Bearbeiten von: proftpd-core I am still convinced that there is something wrong with this package. -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Bug#993164: proftpd-core: When upgrading from Buster to Bullseyes, the installation of ProFTPd fails
On 8/29/21 10:12 AM, Andreas Günther wrote: Am Samstag, 28. August 2021, 17:09:37 CEST schrieb Hilmar Preuße: Hi, Hmm, weird: the modules in question should be provided by proftpd-mod-wrap & proftpd-mod-crypto, should should have installed. Could you check if the files /usr/lib/proftpd/mod_tls.so & /usr/lib/proftpd/mod_wrap.so do exist? Hilmar Hi Hilmar, both, /usr/lib/proftpd/mod_wrap.so and /usr/lib/proftpd/mod_tls.so doesn't exist. But that also seems logical to me, because in order to be able to install proftpd-mod-wrap and proftpd-mod-crypto, proftpd-core has to be completely installed because of the dependencies. But the installation of proftpd-core fails right from the start. dpkg: Error while editing the package proftpd-core (--configure): The "installed proftpd-core script of the post-installation package" subprocess returned the error value 1 dpkg: Dependency problems prevent configuration of proftpd-mod-crypto: proftpd-mod-crypto depends on proftpd-core (= 1.3.7a + dfsg-12); but: Package proftpd-core is not yet configured. At the moment I think something is going wrong with the installation of proftpd-core. When splitting off the wrap and the crypto modules into own packages I put them into recommends to make sure they are installed. proftpd-dfsg (1.3.7a-2) unstable; urgency=medium [ Hilmar Preusse ] * Move modules depending on libsodium & libwrap0 into own packages. New packages are recommended. Francesco later decided to put them into Suggests: proftpd-dfsg (1.3.7a+dfsg-3) unstable; urgency=medium * Moved -mod-wrap and -mod-crypto among Suggests, thanks to changes to default template for modules.conf. So, you probably have a custom modules.conf and refused to use the one from the package maintainers. So solution could be: either install these packages or use the modules.conf from the package. Please send the output of apt install proftpd-core proftpd-basic proftpd-mod-crypto proftpd-mod-wrap I'm wondering why this does not work: all packages should be unpacked before the proftpd-core is configured, so all files needed to configure proftpd-core should be available. Hilmar -- #206401 http://counter.li.org
Bug#993164: proftpd-core: When upgrading from Buster to Bullseyes, the installation of ProFTPd fails
Am 28.08.2021 um 16:46 teilte Andreas Günther mit: Hi, please keep the bug in Cc. here I have the output from systemctl status proftpd.service: proftpd.service - ProFTPD FTP Server Loaded: loaded (/lib/systemd/system/proftpd.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Sat 2021-08-28 10:16:33 CEST; 6h ago Process: 37982 ExecStartPre=/usr/sbin/proftpd --configtest -c $CONFIG_FILE (code=exited, status=1/FAILURE) CPU: 6ms Aug 28 10:16:33 web systemd[1]: Starting ProFTPD FTP Server... Aug 28 10:16:33 web proftpd[37982]: Checking syntax of configuration file Aug 28 10:16:33 web proftpd[37982]: 2021-08-28 10:16:33,852 web proftpd[37982]: mod_dso/0.5: unable to load 'mod_tls.c'; check to see if '/usr/lib/proftpd/mod_tls.la' exists Aug 28 10:16:33 web proftpd[37982]: 2021-08-28 10:16:33,852 web proftpd[37982]: fatal: LoadModule: error loading module 'mod_tls.c': Datei oder Verzeichnis nicht gefunden on line 16 o> Aug 28 10:16:33 web proftpd[37982]: 2021-08-28 10:16:33,852 web proftpd[37982]: warning: unable to include '/etc/proftpd/modules.conf': Die Operation ist nicht erlaubt Aug 28 10:16:33 web proftpd[37982]: 2021-08-28 10:16:33,853 web proftpd[37982]: mod_dso/0.5: unable to load 'mod_wrap.c'; check to see if '/usr/lib/proftpd/mod_wrap.la' exists Aug 28 10:16:33 web proftpd[37982]: 2021-08-28 10:16:33,853 web proftpd[37982]: fatal: LoadModule: error loading module 'mod_wrap.c': Datei oder Verzeichnis nicht gefunden on line 8 o> Aug 28 10:16:33 web systemd[1]: proftpd.service: Control process exited, code=exited, status=1/FAILURE Aug 28 10:16:33 web systemd[1]: proftpd.service: Failed with result 'exit-code'. Aug 28 10:16:33 web systemd[1]: Failed to start ProFTPD FTP Server. Hmm, weird: the modules in question should be provided by proftpd-mod-wrap & proftpd-mod-crypto, should should have installed. Could you check if the files /usr/lib/proftpd/mod_tls.so & /usr/lib/proftpd/mod_wrap.so do exist? Hilmar -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Bug#993164: proftpd-core: When upgrading from Buster to Bullseyes, the installation of ProFTPd fails
Am 28.08.2021 um 10:20 teilte Andreas Guenther mit: Hi, Although I do speak German I prefer English error messages. ;-) Could you provide the output of "systemctl status proftpd.service" and "journalctl -xe" and the /var/log/proftpd/proftpd.log? Thanks! This error occurred for the first time when upgrading the system from Buster to Bullseye: dpkg: Fehler beim Bearbeiten des Paketes proftpd-mod-crypto (--configure): Abhängigkeitsprobleme - verbleibt unkonfiguriert dpkg: Abhängigkeitsprobleme verhindern Konfiguration von proftpd-mod-wrap: proftpd-mod-wrap hängt ab von proftpd-core (= 1.3.7a+dfsg-12); aber: Paket proftpd-core ist noch nicht konfiguriert. . . Fehler traten auf beim Bearbeiten von: proftpd-core proftpd-mod-crypto proftpd-mod-wrap proftpd-basic Then I deleted all the packages involved and tried to reinstall them with the same result: dpkg --remove proftpd-basic proftpd-core proftpd-mod-crypto proftpd-mod-wrap apt install proftpd-core proftpd-basic proftpd-mod-crypto proftpd-mod-wrap After deleting all packages again, I only installed proftpd-core: apt install proftpd-core See "systemctl status proftpd.service" and "journalctl -xe" for details. dpkg: Fehler beim Bearbeiten des Paketes proftpd-core (--configure): »installiertes proftpd-core-Skript des Paketes post-installation«-Unterprozess gab den Fehlerwert 1 zurück Fehler traten auf beim Bearbeiten von: proftpd-core The package obviously cannot be installed due to the proftpd-core script. My expectation of you would be to make ProFTPd installable. -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Bug#986686: missing b-d netpbm?
Am 14.07.2021 um 00:50 teilte Norbert Preining mit: Hi Norbert, @Norbert: do you have an opinion. Should be rather branch from 20200329-1, which is currently in testing? Seems to be ok. Documentation fixes are explicitly included in the freeze exception list. I understand this as: we branch from 20200329-1 and go with "20200329-1bullseye1". In this case we have a rather small debdiff. I could use "20200329-2", but this version will never appear in the changelog of the master. Note sure if this would be OK. Please: - prepare a debdiff (even if it is long) - file a freeze exception bug report - include the *code* (debian/control) changes in the main email and state that the rest of the debdiff is documentation only changes - state that *no* functional changes are there, only ensuring that there is no FTBFS - after the ok, upload I guess that should do it Thanks a lot Norbert -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Bug#986686: missing b-d netpbm?
Am 13.07.2021 um 23:27 teilte Adrian Bunk mit: On Tue, Jul 13, 2021 at 10:13:20PM +0200, Hilmar Preuße wrote: Hi, I am not a member of the release team. "It is just documentation" has a point, suggesting d85a1829 plus UNRELEASED -> unstable would sound reasonable to me. You could ask the release team by submitting an unblock request with reportbug release.debian.org containing a diff of debian/ between the version currently in testing and what you'd like to upload. Yes, yes. The debdiff has a size of 270KB and I don't even intend to read it. @Norbert: do you have an opinion. Should be rather branch from 20200329-1, which is currently in testing? Hilmar -- sigfault OpenPGP_signature Description: OpenPGP digital signature
