Bug#1072682: luametatex: context 2024.04 and luametatex 2.11 no longer build PDF via Pandoc. (+ workaround)

[Preuße]

Control: reassign -1 context
Control: severity -1 grave

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.



I set that bug to grave and assume it is in the context package. For now
I got the suggestion to upgrade the context code, however the version in
Debian is the one, which is currently available on CTAN.

Hilmar
--
sigfault

Bug#1072828: texlive-binaries upgrade breaks therion build

[Preuße]

On 08.06.2024 16:09, Adrian Bunk wrote:

Hi,


https://buildd.debian.org/status/fetch.php?pkg=therion=amd64=6.2.1-1%2Bb1=1717847632=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#1072743: texlive-extra-utils: pdfxup: --pages option fails if page range omits start or end of range

[Hilmar Preuße]

08.06.2024 10:25:00 Sanjoy Mahajan :

> Yes, I'll be happy to discuss it with upstream.
> Should I CC you?  Or just update the Debian bug as needed?
> 
> -Sanjoy
> 
> On 2024-06-07 15:48, Preuße, Hilmar  wrote:
> 
>> On 07.06.2024 13:09, Sanjoy Mahajan wrote:
>> 
>> Hi,
>> 
>>> The man entry for pdfxup says that --pages can handle an omitted start
>>> or end of range, e.g. "--pages 2-" or "--pages -5".  However, using the
>>> following pdf file as a test (it's one page long) gives an error
>>> if either the start or end of the range is omitted.
>>> 
>> Are you willing to discuss this with the upstream author?
>> 
>> https://www.ctan.org/tex-archive/support/pdfxup
>> 
>> Thanks,
>>    Hilmar
>> -- 
>> sigfault
I'm one of the TL maintainers, so keeping the bug in Cc is sufficient. Thanks.

Hilmar

Bug#1072743: texlive-extra-utils: pdfxup: --pages option fails if page range omits start or end of range

[Preuße]

On 07.06.2024 13:09, Sanjoy Mahajan wrote:

Hi,


The man entry for pdfxup says that --pages can handle an omitted start
or end of range, e.g. "--pages 2-" or "--pages -5".  However, using the
following pdf file as a test (it's one page long) gives an error
if either the start or end of the range is omitted.


Are you willing to discuss this with the upstream author?

https://www.ctan.org/tex-archive/support/pdfxup

Thanks,
  Hilmar
--
sigfault

Bug#1072682: luametatex: context 2024.04 and luametatex 2.11 no longer build PDF via Pandoc. (+ workaround)

[Preuße]

On 06.06.2024 16:03, Gijs Hillenius wrote:

Hi Gijs,


The log tells me what I reported:

" Running pandoc with args: (-f org -t context -o /path/somedocument.pdf 
--standalone /path/somedocument.tmp44bTvt.org)

I can run the same command in a non Emacs terminal:



Are you able to compile a minimal context file e.g.?

\starttext
Hello, World!
\stoptext

(call context as "context input.tex") Currently I'm not in my chroot,
b/c building the format file fails:

tex error   > tex error on line 924 in file spac-ali.mkxl: Undefined
control sequence


\frozen\linebreakcriterion
  \defaultlinebreakcriterion

I'm pretty sure this worked once, else I wouldn't have uploaded that
stuff to Debian.

Hilmar
--
sigfault

Bug#1072682: luametatex: context 2024.04 and luametatex 2.11 no longer build PDF via Pandoc. (+ workaround)

[Preuße]

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.

the error I get :

Running pandoc with args: (-f org -t context -o (path to org file) --standalone 
(path to inputfile)
Error occured.
Error producing PDF.



Are you able to provide the exact command line, which is called and a
sample document...or another step by step instruction for reproduction?
Thanks!

Hilmar
--
sigfault

Bug#1072211: marked as done (texlive-base: pdflatex very slow after upgrading to texlive 2024.20240401-2)

[Preuße]

Control: reopen -1

On 31.05.2024 23:57, Debian Bug Tracking System wrote:

> Your message dated Fri, 31 May 2024 21:54:34 +> with message-id 


and subject line Bug#1072211: fixed in texlive-lang 2024.20240401-3
has caused the Debian Bug report #1072211,
regarding texlive-base: pdflatex very slow after upgrading to texlive 
2024.20240401-2
to be marked as done.



Of course this is wrong, I just entered the wrong bug number in the 
changelog of texlive-lang. Reopening.


H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1072211: texlive-base: pdflatex very slow after upgrading to texlive 2024.20240401-2

[Preuße]

On 30.05.2024 13:23, J.L.G. Pallero wrote:

Hi,


After the last upgrade of texlive packages in Sid, from
2023.20240207-1 to 2024.20240401-2, I found pdflatex very slow in the
compilation. The same documents compiled with the 2023.20240207-1
version were built quicker. Is it a problem on my side or is a
general behavior?




See the discussion in Bug#1070150. Does that sound familiar.

H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1071649: mflua.1: some remarks and editorial changes for this man page

[Preuße]

On 26.05.2024 23:46, Karl Berry wrote:

Hello Karl,


FYI, I sent in a report to bug-help2man. If the output can be made
usable, I'll add it to TL, else maybe give up on help2man and just fix
it by hand as Bjarni wrote originally. We'll see what happens. -k


Thanks for the report. Do they have a tracking system?

The Debian bug I've closed few hours ago, as the issue has been solved 
in Debian...just the way how to solve it does not seem optimal.


Hilmar
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1071893: sagetex: FTBFS: unsatisfiable build-dependencies

[Preuße]

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#1071649: mflua.1: some remarks and editorial changes for this man page

[Preuße]

On 24.05.2024 22:35, Bjarni Ingi Gislason wrote:

Hello Bjarni,


mflua --help | groff -man -ww -b -z



Not sure, what you're trying to do here. To use help2man you have to 
call something like "help2man -N mflua > mflua.1"


This gives you a file:

hille@rasppi2:~ $ file mflua.1
mflua.1: troff or preprocessor input, ASCII text

You could check if the quality of this file is better, than that you 
evaluated initially. If not, the bug report goes to help2man. ;-)


@Karl: seems we generated mflua.1 using help2man years ago and did not 
touch it since then: the file is not generated during build.


Hilmar
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1071647: mendex.1: some remarks and editorial changes for this man page

[Preuße]

Control: tags -1 - patch

On 23.05.2024 22:18, Bjarni Ingi Gislason wrote:

On Thu, May 23, 2024 at 09:32:32AM +0200, Preuße, Hilmar wrote:

On 23.05.2024 00:24, Bjarni Ingi Gislason wrote:


Hello Bjarni,


here are some notes and editorial fixes for the manual.

The patch is in the attachment.



Unfortunately the patch not match to the manual page from TL204
[1]. Could you adapt to that version? Thanks!



 The file I get with 'wget2 ...' is a Doc file.


No, it is not a doc file, but the HTML file representing the web page:

hille@rasppi2:~ $ wget2 
https://github.com/debian-tex/texlive-bin/blob/master_tl_2024/texk/mendexk/mendex.1
[0] Downloading 
'https://github.com/debian-tex/texlive-bin/blob/master_tl_2024/texk/mendexk/mendex.1' 
...

Saving 'mendex.1.1'
HTTP response 200 
[https://github.com/debian-tex/texlive-bin/blob/master_tl_2024/texk/mendexk/mendex.1]

hille@rasppi2:~ $ file mendex.1.1
mendex.1.1: HTML document, Unicode text, UTF-8 text, with very long 
lines (1616)




  If I copy it from the page with 'firefox' I get the man page when I use the
'raw' choice. 



When downloading the raw manual page for TL2024 and trying to apply your 
patch it does not apply.


hille@rasppi2:~ $ wget2 
"https://raw.githubusercontent.com/debian-tex/texlive-bin/master_tl_2024/texk/mendexk/mendex.1;
[0] Downloading 
'https://raw.githubusercontent.com/debian-tex/texlive-bin/master_tl_2024/texk/mendexk/mendex.1' 
...

Saving 'mendex.1'
HTTP response 200 
[https://raw.githubusercontent.com/debian-tex/texlive-bin/master_tl_2024/texk/mendexk/mendex.1]
hille@rasppi2:~ $ wget2 -O mendex.1.diff 
"https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1071647;filename=mendex.1.diff;msg=5;
[0] Downloading 
'https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1071647;filename=mendex.1.diff;msg=5' 
...

Saving 'mendex.1.diff'
HTTP response 200 
[https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1071647;filename=mendex.1.diff;msg=5]

hille@rasppi2:~ $ patch < mendex.1.diff
(Stripping trailing CRs from patch; use --binary to disable.)
patching file mendex.1
Hunk #13 FAILED at 459.
Hunk #15 FAILED at 510.
Hunk #16 succeeded at 556 with fuzz 2.
2 out of 17 hunks FAILED -- saving rejects to file mendex.1.rej


What do you get if you use the option '--dry-run' for 'patch' or the
diagnostics from it?


See above.

Many thanks for your help! I remove the patch tag for now.

Hilmar
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1071647: mendex.1: some remarks and editorial changes for this man page

[Preuße]

On 23.05.2024 00:24, Bjarni Ingi Gislason wrote:

Hello,


Dear Maintainer,

   here are some notes and editorial fixes for the manual.

The patch is in the attachment.



Unfortunately the patch not match to the manual page from TL204 [1]. 
Could you adapt to that version? Thanks!


Hilmar

[1] 
https://github.com/debian-tex/texlive-bin/blob/master_tl_2024/texk/mendexk/mendex.1

--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1071649: mflua.1: some remarks and editorial changes for this man page

[Preuße]

Control: tags -1 + pending

On 23.05.2024 01:07, Bjarni Ingi Gislason wrote:

Hello,


Dear Maintainer,

   here are some notes and editorial fixes for the manual.

The patch is in the attachment.


Applied.

Hilmar
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1038937: nq package out of date with upstream, 0.5 was released more than a year ago

[Preuße]

Control: block -1 by 1005961

On 03.05.2024 21:47, Christoph Biedl wrote:

Hi,


nq 0.5 was released March 26, 2022 and contains several bug fixes and 
improvements.
nq 0.3.1 was released March 7, 2018, and is what is in all of stable, testing, 
and unstable.
Please update this package.


Upon request by upstream and following the statements given in
,
also there's the LowNMU flag ... I'll upload 0.5-0.1 in the next days.
To improve quality and as it was a no-brainer, I'll also add an autopkgtest.

I took over the task to do an NMU. The RFS bug is open, unfortunately 
#1005961 needs to solved first.


Hilmar
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1057407: texworks: Intent to drop poppler-qt6 on i386

[Preuße]

On 04.12.2023 14:43, Jeremy Bícha wrote:

Hi Jeremy,


As the maintainer of Debian's poppler source package, I would like to
drop poppler's Qt6 packages on i386.


I just uploaded texworks 0.6.9 and for i386 the status on the buildd is

Dependency installability problem for texworks on i386:

texworks build-depends on:
- libpoppler-qt6-dev:i386
libpoppler-qt6-dev depends on missing:
- libpoppler-dev:i386 (= 24.02.0-4)

So, texworks won't be built for i386 and won't be available for unstable 
and testing. Is that OK, can we close that bug now?


Hilmar
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070331: RFS: nq/0.5-0.1 [NMU] -- Lightweight queue system

[Preuße]

On 11.05.2024 09:08, Tobias Frost wrote:

Hi,


Please also announce the NMU / RFS to the package maintainer,
preferable as bug reported against it. Thanks!  


The package is flagged as LowNMU [1], which says:

"You don't need to contact the maintainers beforehand, and you don't 
need to use a delayed upload queue. If the package maintainer or 
maintainer group is active, it is polite to let them have a stab at 
fixing the problem first."


Given the fact that the last upload was 3.5 years ago I'd assume that 
the maintainers group is non-active. Hence I did not inform them.


Hilmar

[1] https://tracker.debian.org/pkg/nq
--
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070802: texlive-latex-extra: (regression) acro no longer compiles

[Preuße]

On 10.05.2024 08:07, Manny wrote:

X-Debbugs-Cc: cont...@mychemistry.eu


Hello Manny,


normally I don't have time to care about issues like this. Are you willing
to report this issue to the upstream author?


The upstream project is in MS Github which is a non-starter for
me. I’ll go as far as /reading/ from the site. I’m surprised such a
crippling bug has not been reported there, but I found this comment:

   https://github.com/cgnieder/acro/issues/233#issuecomment-1013665911

I do not fully understand the comment, but to me it rather looks as if 
the author gave some comments on the new behavior of the package instead 
of accepting a bug.



Apparently Bookworm is using the absolute latest version of acro
(3.8). So from the Debian side, the acro version needs to be rolled
back.



I won't do a roll back. If you need the old version back, please install 
it into your LOCALTEMXMF tree and use it.


Hilmar
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070802: texlive-latex-extra: (regression) acro no longer compiles

[Preuße]

09.05.2024 14:12:32 Manny :


Hi Manny,

normally I don't have time to care about issues like this. Are you 
willing to report this issue to the upstream author?


Hilmar



Package: texlive-latex-extra
Version: 2022.20230122-4
Severity: normal
Tags: upstream
X-Debbugs-Cc: debbug.texlive-latex-ex...@sideload.33mail.com

After an upgrade from Bullseye to Bookworm, the acro package breaks
compilation even if no acronyms are even defined. Documents making use
of acro compiled and functioned fine in the past (version
2020.20210202-3) but no longer compile after the upgrade to
2022.20230122-4.

This is a short sample document:


--
#206401 http://counter.li.org



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070802: texlive-latex-extra: (regression) acro no longer compiles

[Hilmar Preuße]

09.05.2024 14:12:32 Manny :

> Package: texlive-latex-extra
> Version: 2022.20230122-4
> Severity: normal
> Tags: upstream
> X-Debbugs-Cc: debbug.texlive-latex-ex...@sideload.33mail.com
> 
> After an upgrade from Bullseye to Bookworm, the acro package breaks
> compilation even if no acronyms are even defined. Documents making use
> of acro compiled and functioned fine in the past (version
> 2020.20210202-3) but no longer compile after the upgrade to
> 2022.20230122-4.
> 
> This is a short sample document:
> 
> ===8<
> \documentclass{scrlttr2}
> \usepackage{acro}
> 
> %\DeclareAcronym{foo}{short=FOO, long=breaks even if no acronym is defined}
> 
> \begin{document}
> \begin{letter}{recipient}
>   lipsum
> \end{letter}
> \end{document}
> ===8<
> 
> The error is this:
> 
> ===8<
> ERROR: Package acro Error: Patching `maketitle' failed. Please contact the 
> acro
> (acro)    author.
> 
> Type  to continue.
> ... 
>  
> l.6 \begin{document}
>    
> --- HELP ---
> No help available
> ===8<
> 
> The upstream tag was applied because that’s where the defect is, but
> action can still be taken on the Debian release. Debian should either
> roll back the acro.sty version, or advance it. The current version is
> apparently completely unusable. Both latex and pdflatex fail to
> compile it. This is the fls file:
> 
> ===8<
> PWD /tmp
> INPUT /etc/texmf/web2c/texmf.cnf
> INPUT /usr/share/texmf/web2c/texmf.cnf
> INPUT /usr/share/texlive/texmf-dist/web2c/texmf.cnf
> INPUT /var/lib/texmf/web2c/pdftex/latex.fmt
> INPUT sample.tex
> OUTPUT sample.log
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlttr2.cls
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlttr2.cls
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlttr2.cls
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlttr2.cls
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlttr2.cls
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlttr2.cls
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlttr2.cls
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlttr2.cls
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlttr2.cls
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlttr2.cls
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlttr2.cls
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrkbase.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrkbase.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrkbase.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrkbase.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrkbase.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrkbase.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrkbase.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrkbase.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrkbase.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrkbase.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrkbase.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrbase.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrbase.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrbase.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrbase.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrbase.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrbase.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrbase.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrbase.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrbase.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrbase.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrbase.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile.sty
> INPUT /usr/share/texlive/texmf-dist/tex/latex/koma-script/scrlfile.sty
> INPUT 

Bug#1070331: RFS: nq/0.5-0.1 [NMU] -- Lightweight queue system

[Preuße]

Control: block -1 by 1005961

On 03.05.2024 23:45, Christoph Biedl wrote:

Hi,


That would be necessary - although I don't know how to solve this in a
sensible way.

Sorry for disturbing your best intentions to bring nq back in shape -
but this problem will not disappear by ignoring it.


Completely agree. Let's see if there are reactions for the re-opened bug.

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

[Preuße]

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#1070331: RFS: nq/0.5-0.1 [NMU] -- Lightweight queue system

[Preuße]

On 03.05.2024 22:29, Christoph Biedl wrote:

Hilmar Preusse wrote...


Hi Christoph,


Changes since the last upload:

  nq (0.5-0.1) unstable; urgency=medium
  .
* Non-maintainer upload.
  .
* New upstream version (Closes: #1038937).



* Bump Standards and dh compat version, no changes needed.


I'm a little surprised why you would change that in a NMU.

Well, this was reported by lintian. As they were no further changes 
needed, I though it would be a good idea.



* Add upstream metadata file.
* Add "Conflicts: fq".


We have a problem. Conflicts: is not enough, with both nq and fq
providing /usr/bin/fq, they are in violation of policy 10.1:

| Two different packages must not install programs with different
| functionality but with the same filenames.



Thanks for pointing this out. The solution in the pull request (which 
introduced the Conflict) looked weird, but in the end #1005961 was 
solved the same (wrong) way, hence I thought it would be OK.


As I'm not the maintainer of either of these package I don't really feel 
responsible to solve the conflict. At first I'd reopen the bug above and 
state it as wrongly solved quoting the policy entry.


H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070150: texlive-latex-extra: performance regression under emulation with 2023.20240207-1

[Preuße]

Control: reassign -1 texlive-binaries
Control: severity -1 important

On 01.05.2024 00:19, Steev Klimaszewski wrote:

Hi all,


Since the 2023.20240207-1 release, there is a major performance
regression when running the tex-common postinst hook in an arm64
chroot on amd64 host.



I assume this is important, further the package needs to be corrected.

H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070226: rubber -Wrefs seems broken due to a bad regexp in converters/latex.py

[Preuße]

Control: forwarded -1 https://gitlab.com/latex-rubber/rubber/-/issues/15

On 02.05.2024 10:22, Pierre Letouzey wrote:

Hello,


Issue already reported upstream: https://gitlab.com/latex-
rubber/rubber/-/issues/15

The provided 2-line patch appears to solve this issue.



Thanks for the report. Marking that bug a forwarded.

Hilmar
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070150: texlive-latex-extra: performance regression under emulation with 2023.20240207-1

[Preuße]

On 01.05.2024 22:46, Steev Klimaszewski wrote:

Hi,


May 01 14:28:46 catcodes, registers, parameters,
May 01 14:28:46 LaTeX2e <2024-06-01> pre-release-0 (develop 2024-5-1 
branch)

May 01 14:28:46 (/usr/share/texlive/texmf-dist/tex/latex/l3kernel/expl3.ltx
May 01 14:51:15 
(/usr/share/texlive/texmf-dist/tex/latex/l3kernel/expl3-code.tex)) hacks, > May 01 14:51:19 document commands, control, par, spacing, files, font





Noticed that too, that loading this file takes quite long. In Debian 
stable (on a Rasbpi4) it are just a few seconds. In a chroot (Debian 
unstable / experimental) it takes longer, but still not the 30 minutes I 
see in your log. There is no difference between pdflatex and lualatex.


H,
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1052298: metafun broken?

[Preuße]

Control: reassign -1 context-modules
Control: tags -1 + pending

On 30.04.2024 18:28, Preuße...@buxtehude.debian.org, Hilmar wrote:

Hi *,

I'll upload a context-modules package to Debian experimental, which will 
contain the legacy mkii packages. This will bring back metafun.mpii, but 
won't make you happy anyway, as even the minimal example does not 
compile. I'll close that bug anyway, please open a new one, once you 
tested the package.




Reassign, tag

H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1052298: metafun broken?

[Preuße]

On 23.02.2024 23:31, Hilmar Preuße wrote:

On 27.10.23 22:31, Siep Kroonenberg wrote:


Hi Stéphane,


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.




I'll upload a context-modules package to Debian experimental, which will 
contain the legacy mkii packages. This will bring back metafun.mpii, but 
won't make you happy anyway, as even the minimal example does not 
compile. I'll close that bug anyway, please open a new one, once you 
tested the package.


root@rasppi2:~# cat a.mp
input metafun.mp ;
root@rasppi2:~# mpost -interaction=nonstopmode a.mp
This is MetaPost, version 2.02 (TeX Live 2023/Debian) (kpathsea version 
6.3.5)

(/usr/share/texlive/texmf-dist/metapost/base/mpost.mp
(/usr/share/texlive/texmf-dist/metapost/base/plain.mp
Preloading the plain mem file, version 1.005) ) (./a.mp
(/usr/share/texmf/metapost/context/base/common/metafun.mp
(/usr/share/texlive/texmf-dist/metapost/context/base/mpii/metafun.mpii
(/usr/share/texlive/texmf-dist/metapost/context/base/mpii/mp-base.mpii
Preloading the plain mem file, version 1.004 for metafun ii
! Redundant equation.

   ;
l.338 mm=2.83464;
   pt=0.99626;dd=1.06601;  bp:=1;
! Redundant equation.

   ;
l.338 mm=2.83464;  pt=0.99626;
  dd=1.06601;  bp:=1;
! Redundant equation.

   ;
l.338 ...3464;  pt=0.99626;dd=1.06601;
bp:=1;
! Redundant equation.

   ;
l.339 cm=28.34645;
   pc=11.95517;   cc=12.79213; in:=72;
! Redundant equation.

   ;
l.339 cm=28.34645; pc=11.95517;
  cc=12.79213; in:=72;
! Redundant equation.

   ;
l.339 ...4645; pc=11.95517;   cc=12.79213;
   in:=72;
! Redundant equation.

   ;
l.530 laboff=(0,0);labxf=.5;
  labyf=.5;
! Redundant equation.

   ;
l.530 ...  =(0,0);labxf=.5;  labyf=.5;

! Redundant equation.

   ;
l.531 laboff.lft=(-1,0);   labxf.lft=1;
  labyf.lft=.5;
! Redundant equation.

   ;
l.531 ...ft=(-1,0);   labxf.lft=1;   labyf.lft=.5;

! Redundant equation.

   ;
l.532 laboff.rt =(1,0);labxf.rt =0;
  labyf.rt =.5;
! Redundant equation.

   ;
l.532 ...t =(1,0);labxf.rt =0;   labyf.rt =.5;

! Redundant equation.

   ;
l.533 laboff.bot=(0,-1);   labxf.bot=.5;
  labyf.bot=1;
! Redundant equation.

   ;
l.533 ...bot=(0,-1);   labxf.bot=.5;  labyf.bot=1;

! Redundant equation.

   ;
l.534 laboff.top=(0,1);labxf.top=.5;
  labyf.top=0;
! Redundant equation.

   ;
l.534 ...top=(0,1);labxf.top=.5;  labyf.top=0;

! Redundant equation.

   ;
l.535 laboff.ulft=(-.7,.7);labxf.ulft=1;
  labyf.ulft=0;
! Redundant equation.

   ;
l.535 ...lft=(-.7,.7);labxf.ulft=1;  labyf.ulft=0;

! Redundant equation.

   ;
l.536 laboff.urt=(.7,.7);  labxf.urt=0;
  labyf.urt=0;
! Redundant equation.

   ;
l.536 ...urt=(.7,.7);  labxf.urt=0;   labyf.urt=0;

! Redundant equation.

   ;
l.537 laboff.llft=-(.7,.7);labxf.llft=1;
  labyf.llft=1;
! Redundant equation.

   ;
l.537 ...lft=-(.7,.7);labxf.llft=1;  labyf.llft=1;

! Redundant equation.

   ;
l.538 laboff.lrt=(.7,-.7); labxf.lrt=0;
  labyf.lrt=1;
! Redundant equation.

   ;
l.538 ...lrt=(.7,-.7); labxf.lrt=0;   labyf.lrt=1;

) (/usr/share/texlive/texmf-dist/metapost/context/base/mpii/mp-tool.mpii)
(/usr/share/texlive/texmf-dist/metapost/context/base/mpii/mp-spec.mpii)
(/usr/share/texlive/texmf-dist/metapost/context/base/mpii/mp-core.mpii)
(/usr/share/texlive/texmf-dist/metapost/context/base/mpii/mp-page.mpii)
(/usr/share/texlive/texmf-dist/metapost/context/base/mpii/mp-text.mpii)
(/usr/share/texlive/texmf-dist/metapost/context

Bug#1057407: texworks: Intent to drop poppler-qt6 on i386

[Preuße]

On 04.12.2023 14:43, Jeremy Bícha wrote:

Hi Jeremy,


As the maintainer of Debian's poppler source package, I would like to
drop poppler's Qt6 packages on i386.

I filed Bug#1068672 and you probably should be able to drop poppler-qt6 
on i386. My package will turn either into "not-installable" or 
"BD-Uninstallable" for i386. I suggest to go ahead on your side, so we 
can close that bug. I intend to upload texworks 0.6.9, once you dropped 
poppler-qt6 for i386 .


Hilmar
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061546: srcpd: installs file into aliased location

[Preuße]

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#1057407: texworks: Intent to drop poppler-qt6 on i386

[Preuße]

On 08.04.2024 00:08, Preuße...@buxtehude.debian.org, Hilmar wrote:

On 20.12.2023 15:25, Jeremy Bícha wrote:

On Sat, Dec 16, 2023 at 6:02 PM Hilmar Preuße  wrote:


Hi Jeremy,


As no package depend on texworks, I'll drop i386 as requested. If you
have a patch for me I'll be glad.


My plan is to first get a newer poppler from Experimental into
Unstable. After that poppler transition completes, then I can stop
building poppler qt6 on i386 and ask the ftpmasters to remove poppler
qt6 on i386 and texworks on i386. I don't think there is anything we
need to do to the texworks packaging; texworks will just be in depwait
status on i386.



OK, fine. So I guess there is nothing to do from my side regarding 
packaging, we have just to remove the texworks packages for i386 from 
the archive, else you won't be able to remove your packages, right?


I've filed #1068672 to remove i386 for texworks from the archive and it 
was processed today. I guess you can proceed soon.


Hilmar


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1067614: texlive-latex-extra: pdfcomment docs reference the cloud instead of local files; also font option broken

[Preuße]

Control: tags -1 + wontfix

On 24.03.2024 18:29, Manny wrote:

Hi Manny,

thanks to Norbert for explaining, why we can't solve this issue. I tag 
that bug wontfix.



If only the Debian-specific bug is worked and the rest of this report
is closed, perhaps that’s fair enough. I’ve gone as far as I’m willing
to go. I just want these problems to be recorded /somewhere/ amid the
author being unreachable.



I'm aware of a bug in our TL packages, were both (submitter and upstream 
author) are dead. Still the bug is open, I just removed the "forwarded" 
flag.



BTW, there’s perhaps a defect in the Package-specific info that the
reportbug tool prints for texlive-latex-extra. It prints this:

===8<
Please read and follow the instructions in the first lines below
the text: "-- Package-specific info:".
Thank you.

Please don't add attachments > 100KB. They won't make it through
our mailing list and we won't see the report!
===8<

Around 800k of attachments were apparently accepted okay for bug
1067612, so the above-mentioned 100k limit may not be in force.

This is explained in the text: the DBTS is able to handle these kind of 
attachments, but the mailing list server won't forward the E-Mail to my 
private E-Mail account. As I don't scan the web pages of the bug tracker 
on a regular basis, changes in bugs or new bugs may remain undiscovered 
(by me) for a while.


Hilmar
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1057407: texworks: Intent to drop poppler-qt6 on i386

[Preuße]

On 20.12.2023 15:25, Jeremy Bícha wrote:

On Sat, Dec 16, 2023 at 6:02 PM Hilmar Preuße  wrote:


Hi,


As no package depend on texworks, I'll drop i386 as requested. If you
have a patch for me I'll be glad.


My plan is to first get a newer poppler from Experimental into
Unstable. After that poppler transition completes, then I can stop
building poppler qt6 on i386 and ask the ftpmasters to remove poppler
qt6 on i386 and texworks on i386. I don't think there is anything we
need to do to the texworks packaging; texworks will just be in depwait
status on i386.



OK, fine. So I guess there is nothing to do from my side regarding 
packaging, we have just to remove the texworks packages for i386 from 
the archive, else you won't be able to remove your packages, right?


H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1068419: perdition: dependencies unsatisfiable after binnmu for time64 transition.

[Preuße]

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#1065876: texlive-extra-utils: The shebang of script de-macro invokes 'python' rather than 'python3'

[Preuße]

Control: tags -1 + pending

On 10.03.2024 17:28, Diego Caraffini wrote:

Hi,


I have a paper written in LaTeX that the publisher required to not
contain any user macro, so I used de-macro to produce a distributable
version with a Makefile target.


Fixed in git, will be part of next upload.

H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061152: asymptote: autopkgtest should test installed package

[Preuße]

On 03.04.2024 12:54, Julian Gilbey wrote:

On Wed, Jan 24, 2024 at 06:07:56PM +0100, Sven Joachim wrote:

Hi Julian,


nice. However, it first builds the program and then tests that,
rather than the package from the archive.  This is not very useful,
as changes in reverse dependencies could cause breakage at runtime
which might vanish after a rebuild.

[...]
(followed by suggestion of how to fix this)

If Sven's patch works, you would also be able to drop most of the
test-time dependencies and depend only on asymptote itself (and maybe
one or two other packages), as you would not need to build asymptote.



Currently it does not, but I did not find the time yet to refine it and 
get it running. Once this is done I can test if all Deps of the test 
suite are really needed, I guess a few of them are not surplus, but 
we'll see.


H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1066117: FTBFS: missing build-dep on libnsl-dev

[Preuße]

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

[Preuße]

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

[Preuße]

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#1064918: tex-common postinst script fails due to a bug in lua script /usr/bin/mtxrun.lua

[Preuße]

Control: severity -1 grave
Control: reassign -1 luametatex
Control: merge -1 1064402

On 27.02.2024 19:06, Giacomo Mulas wrote:

Hi,

after the latest standard "apt upgrade" I was left with an unconfigured 
tex-common, due to the following reported error:


lua error : startup file: /usr/bin/mtxrun.lua:2438: attempt to assign to 
const variable 'i'




I merge that bug to the luametatex's bug now.

Hilmar
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1065094: pdftex.1: some remarks and editorial changes for this man page

[Hilmar Preuße]

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#1065212: asymptote: recent libc6-dev change causes XDR and V3D support to be dropped

[Preuße]

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#1065094: pdftex.1: some remarks and editorial changes for this man page

[Preuße]

Control: forwarded -1 https://tug.org/pipermail/tldistro/2024q1/000474.html

On 29.02.2024 19:33, Bjarni Ingi Gislason wrote:

Hello,


   here are some notes and editorial fixes for the manual.

The patch is in the attachment.



I've forwarded to tldistro for now.

Hilmar
--
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

[Preuße]

On 27.02.2024 19:06, Giacomo Mulas wrote:

Hello Giacomo,

Indeed, mtxrun.lua uses texlua, as an interpreter, and that is provided 
by texlive-binaries, which was also upgraded a couple of days ago.
Gotcha! I downgraded texlive-binaries to the previous version, and now 
tex-common configures correctly.
So, apparently, the upgrade of texlive-binaries from version 
2023.20230311.66589-8+b1 to 2023.20230311.66589-9 broke the postinst 
script of tex-common, where it attempts to run mtxrun.lua.




According to the actual knowledge (#1064402) the issue is caused by the 
(not very helpful) luametatex upgrade, which should have been targeted 
to experimental, as it belongs to the upcoming TL 2024 release. Please 
downgrade your luametatex to the version from testing (and put it on 
hold), then upgrading tl-bin should not be an issue.


Hilmar
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064917: apology for the duplicated bug report

[Preuße]

Control: merge -1 1064918

On 27.02.2024 21:56, Giacomo Mulas wrote:

Sorry for sending the same bug report twice, I thought the first one did 
not

get sent. Please feel free to remove one of them, or to merge them,
whichever is easier.


Done.

Hilmar
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064854: Breaks tex-common's configuration

[Preuße]

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

[Preuße]

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#1052298: metafun broken?

[Hilmar Preuße]

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

[Hilmar Preuße]

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#1064402: texlive-binaries: tex-common configure: lua error : startup file: /bin/mtxrun.lua:2438: attempt to assign to const variable 'i'

[Preuße]

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

[Preuße]

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#1061546: srcpd: installs file into aliased location

[Preuße]

Control: severity -1 serious

On 26.01.2024 09:35, Chris Hofstaedtler wrote:


Source: srcpd
Version: 2.1.6-1
User: helm...@debian.org
Usertag: dep17m2
Severity: important

Not sure, when I'll have time to fix the issue. Set to serious for now 
to prevent migration.


H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061151: asymptote: should run tests at build time

[Preuße]

On 19.01.2024 17:11, Sven Joachim wrote:

Hello,


Your package has a test suite that probably should be run at build time,
but it is not.  I looked at the git repository and found that it has
been disabled since at least 2015:



Fix is implemented in git and will be in next upload.

H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061152: asymptote: autopkgtest should test installed package

[Preuße]

On 19.01.2024 17:23, Sven Joachim wrote:

Hello,


Your package's autopkgtest runs the upstream test suite which is
nice. However, it first builds the program and then tests that,
rather than the package from the archive.  This is not very useful,
as changes in reverse dependencies could cause breakage at runtime
which might vanish after a rebuild.



Not sure how to change that. I removed the "build-needed" restriction 
from the test suite control file and run the autopkgtest as follows:


autopkgtest asymptote_2.86+ds1-2_amd64.deb asymptote_2.86+ds1-2.dsc -- 
schroot unstable-amd64-sbuild


The test fails:

(Reading database ... 52447 files and directories currently installed.)
Removing autopkgtest-satdep (0) ...
autopkgtest [12:35:24]: test test-suite: [---
make: *** No rule to make target 'test'.  Stop.
autopkgtest [12:35:25]: test test-suite: ---]
autopkgtest [12:35:25]: test test-suite:  - - - - - - - - - - results - 
- - - - - - - - -

test-suite   FAIL non-zero exit status 2
autopkgtest [12:35:25]:  summary
test-suite   FAIL non-zero exit status 2

...probably b/c the build did not run yet and there is no Makefile.

Were you able to run the test suite w/o running a build first? If yes 
let me know how. Thanks!


H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061151: asymptote: should run tests at build time

[Preuße]

On 19.01.2024 18:04, Sven Joachim wrote:

On 2024-01-19 17:11 +0100, Sven Joachim wrote:


Hi Sven,


Your package has a test suite that probably should be run at build time,
but it is not.  I looked at the git repository and found that it has
been disabled since at least 2015:

,
| $ git show f69991bf3
| commit f69991bf3cf85c0560ac93a2b24d96ce67c061d9
| Author: Norbert Preining 
| Date:   Tue Jun 23 08:41:59 2015 +0900
|
| do not do testing
|
| diff --git a/debian/rules b/debian/rules
| index 6d9d7387..2d52d8f6 100755
| --- a/debian/rules
| +++ b/debian/rules
| @@ -22,6 +22,9 @@ override_dh_auto_install:
| make install-asy DESTDIR=$(CURDIR)/debian/tmp
| dh_installtex -pasymptote
|
| +override_dh_auto_test:
| +   : do nothing here, otherwise make tries to compile prc/test.cc
| +
|  override_dh_clean:
| dh_clean
| rm --force doc/latexusage.pdf doc/latexusage.dvi 
doc/TeXShopAndAsymptote.dvi doc/CAD.dvi
`

This leaves me rather puzzled: why exactly would it bad if make tries to
compile prc/test.cc?


Out of curiosity, I removed the dh_auto_test override and built the
package with "sbuild --no-arch-all".  This ran the test suite where
various files were compiled, but not prc/test.cc.  The build was
successful.



As you noticed I did not enter that entry and the person who did that 
does not actively work for Debian any more. Maybe at the time of the 
commit the file prc/test.cc was still compiled and linked and that was 
bad somehow.
Anyway I'd like to leave it as it is: there are some slow architectures, 
hence I'd not run the test suite on all arches. I may remove the comment 
if that solves an issue.


Hilmar
--
sigfault



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

[Hilmar Preuße]

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#1059943: Acknowledgement (libpoppler126: Wrong image rendering on big endian machines)

[Preuße]

Control: affects -1 + src:texworks

On 03.01.2024 23:45, Debian Bug Tracking System wrote:

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 1059943: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059943.



Affects texworks. Due to this issue the test suite of TeXworks fails on BE.

H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1046800: texinfo: Fails to build source after successful build

[Preuße]

On 13.08.2023 21:21, Lucas Nussbaum wrote:

Hi,


dpkg-source: info: local changes detected, the modified files are:
  texinfo-7.0.3/doc/info-stnd_html/variable_002dassignment.html
  texinfo-7.0.3/doc/texinfo_html/xref.html



That stuff below doc/info-stnd_html & doc/texinfo_html is now deleted, 
patch was done in one of latest uploads. We now have:


dpkg-source: info: local changes detected, the modified files are:
 texinfo_orig/doc/stamp-1
 texinfo_orig/doc/stamp-2
 texinfo_orig/doc/stamp-vti
 texinfo_orig/doc/version-stnd.texi
 texinfo_orig/doc/version-texi2any_api.texi
 texinfo_orig/doc/version.texi
 texinfo_orig/man/makeinfo.1
 texinfo_orig/man/texindex.1
 texinfo_orig/po_document/ca.po
 texinfo_orig/tp/Texinfo/XS/TestXS.c
dpkg-source: info: Hint: make sure the version in debian/changelog 
matches the unpacked source tree


I'm discussing this with upstream.

H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059617: texlive-latex-base: matrix errors in amsmath package

[Preuße]

On 29.12.2023 11:20, andrei wrote:

Hi andrei,


I successfully  compile (by pdflatex) the file:

But I get an error when compile this file with uncommented rows:

! Extra alignment tab has been changed to \cr.
 \endtemplate
  
l.28  &1&2 &1&2 &1&2 &1&2 &1&

  2  \\
?



We are not a LaTeX help desk, this is a very strong exception! The 
explanation + "fix" can be found here [1]. So putting the line 
\setcounter{MaxMatrixCols}{12} right after the \usepackage{amsmath} line 
solves your issue.


Hilmar

[1] 
https://www.overleaf.com/learn/latex/Errors/Extra_alignment_tab_has_been_changed_to_%5Ccr

--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059179: Acknowledgement (transition: proftpd-dfsg)

[Preuße]

Control: severity -1 important

On 21.12.2023 00:18, Debian Bug Tracking System wrote:

Hi,


If you wish to submit further information on this problem, please
send it to 1059...@bugs.debian.org.

Bumping to important to fix the security issue CVE-2023-48795 in trixie 
too. Currently the proftp modules are awaiting a rebuild, which prevents 
migration.


H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1057407: texworks: Intent to drop poppler-qt6 on i386

[Hilmar Preuße]

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#1058452: tex-common: "fmtutil failed" in post-installation script

[Preuße]

Control: reassign -1 texlive-formats-extra

On 13.12.2023 15:10, Norbert Preining wrote:

On Wed, 13 Dec 2023, =?UTF-8?Q?Preu=C3=9...@buxtehude.debian.org wrote:


Hi,


Is it fine to close the case?


Actually no, the packages should have proper dependencies that this
cannot happen.

Hilmar, please bump the minimal dep on tl-base to the required level.



Reassign to tl-formats-extra for now.

H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1058452: tex-common: "fmtutil failed" in post-installation script

[Preuße]

On 13.12.2023 15:10, Norbert Preining wrote:

On Wed, 13 Dec 2023, =?UTF-8?Q?Preu=C3=9...@buxtehude.debian.org wrote:


Hi Norbert,


Is it fine to close the case?


Actually no, the packages should have proper dependencies that this
cannot happen.

Hilmar, please bump the minimal dep on tl-base to the required level.



You mean the dep version tex-common or the one for texlive-formats-extra?

H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1058452: tex-common: "fmtutil failed" in post-installation script

[Preuße]

On 13.12.2023 13:38, Sanjoy Mahajan wrote:

Hi,


Upgrading the texlive-base (2023.20231007-1 => 2023.20231207-1)
(suggested by Hilmar Preuße) has resurrected them.

-Sanjoy


Is it fine to close the case?

H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1058462: texlive-bibtex-extra: file conflict with liblatex-tounicode-perl on ltx2unitxt(1) manpage

[Preuße]

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#1058452: tex-common: "fmtutil failed" in post-installation script

[Preuße]

On 12.12.2023 12:06, Sanjoy Mahajan wrote:

Hi,


I've attached /tmp/fmtutil.amiyTgkU

The relevant lines may be its last lines:

   fmtutil [WARNING]: inifile pdfxmltex.ini for pdfxmltex/pdftex not found.
   fmtutil [WARNING]: inifile xmltex.ini for xmltex/pdftex not found.
   fmtutil [INFO]: disabled formats: 1
   fmtutil [INFO]: successfully rebuilt formats: 43
   fmtutil [INFO]: not available formats: 2
   fmtutil [INFO]: failed to build: 2 (pdftex/pdfxmltex pdftex/xmltex)
   fmtutil [INFO]: total formats: 48
   fmtutil [INFO]: exiting with status 2

The exit status of 2 makes me think that it results from there being two
unavailable formats.



These files are in texlive-base

hille@debian:~$ apt-file search xmltex.ini
texlive-base: 
/usr/share/texlive/texmf-dist/tex/generic/tex-ini-files/pdfxmltex.ini
texlive-base: 
/usr/share/texlive/texmf-dist/tex/generic/tex-ini-files/xmltex.ini


They were in texlive-formats-extra before the latest uploaded; different 
path, hence no file conflict.



Versions of packages texlive-binaries recommends:
ii  dvisvgm   3.1.2+ds-1
ii  texlive-base  2023.20231007-1


Upgrading texlive-base to 2023.20231207-1 should solve your issue.

H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1058038: texlive-extra: Blocker bug

[Preuße]

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#1057407: texworks: Intent to drop poppler-qt6 on i386

[Preuße]

On 04.12.2023 14:43, Jeremy Bícha wrote:

Hi Jeremy,


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.



I personally stopped using i386 about 9 years ago, so in my personal 
opinion it is OK. According to [1] i386 is still on 2nd rank, still 7 
times higher than the 3rd rank arm64, but only 1/22 of amd64.


Can we switch back to QT5 (on i386) or would this not be helpful? Are 
there popcon statistics per package?


Hilmar

[1] https://popcon.debian.org/
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1057234: sbuild: Generates weird messages in /var/log/syslog

[Preuße]

Control: clone 1057234 -1
Control: reassign -1 schroot
Control: retitle -1 schroot: Generates weird messages in /var/log/syslog

On 02.12.2023 08:30, Johannes Schauer Marin Rodrigues wrote:

Quoting Hilmar Preusse (2023-12-01 23:10:36)


Hi,


I run sbuild as following:

sbuild --no-run-lintian --arch-all --dist=sid *.dsc -d unstable-amd64-sbuild

, where unstable-amd64-sbuild references a chroot. Updating the chroot is done:

sudo sbuild-update -udcar unstable-amd64-sbuild

Both commands generate weird messages in /var/log/syslog like this:

2023-12-01T09:36:52.230653+01:00 haka2 schroot[3182]: [unstable-
amd64-sbuild-327cf8c2-30d1-4469-aa7b-9bc3653dbc45 chroot] (root->root) Running
command: "perl -e #012use strict;#012
use warnings;#012use POSIX;#012

Sample file is attached. These #012 are page feed chars IIRC. Unfortunately
logcheck is not able to handle the situation and generates E-Mails, which
report the full command line by line. There is definitely a white list rule for
schroot in /etc/logcheck/ignore.d.server/schroot, but it is not able to handle
the lot of special characters. Consider to not print the full perl script into
the log file (if possible).

It may be an issue in logcheck, but rather prefer to avoid message instead of
trying to white list afterwards.


it may also be an issue with schroot, no? I do not think sbuild at any point
tells schroot to write anything to syslog.

What should sbuild do to fix this?



I wasn't sure b/c I use mostly sbuild. Cloning to schroot.

H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#985397: /usr/share/texlive/texmf-dist/tex/latex/tikzposter/tikzposter.cls: tikzposter.cls: licensed under non-existing version 2.0 of LPPL

[Preuße]

Control: forwarded -1 https://bitbucket.org/surmann/tikzposter/issues/44

On 17.03.2021 11:15, Braun Gábor wrote:


Package: texlive-pictures
Version: 2018.20190227-2
Severity: normal
File: /usr/share/texlive/texmf-dist/tex/latex/tikzposter/tikzposter.cls

Dear Maintainer,



Forwarded.

H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056587: texlive-latex-base: some math characters get replaced as of Debian's TeX Live 2023

[Preuße]

Control: severity -1 wishlist
Control: retitle -1 fmtutil should ignore TEXINPUTS set in root env

On 28.11.2023 00:27, Debian Bug Tracking System wrote:

Processing control commands:


severiy -1 wishlist

Unknown command or malformed arguments to command.


title -1 fmtutil should ignore TEXINPUTS set in root env

Unknown command or malformed arguments to command.




--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056587: texlive-latex-base: some math characters get replaced as of Debian's TeX Live 2023

[Preuße]

Control: severiy -1 wishlist
Control: title -1 fmtutil should ignore TEXINPUTS set in root env

On 27.11.2023 01:06, Norbert Preining wrote:

Hello Norbert,


Since I am not using Debian, nor developing for Debian, I think I
stop arguing here. No need to discuss my opinion on that matter
further. Feel free to bring it up to the TC, or d-d, or where ever
you feel is the correct place.



Many, many thanks for stepping in, I did not find the time to help here. 
For now I'd rather contact debian-mentors and ask for their opinion. I 
did not find any statement in the policy.


Hilmar
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056587: texlive-latex-base: some math characters get replaced as of Debian's TeX Live 2023

[Preuße]

On 25.11.2023 01:20, Vincent Lefevre wrote:

Hi,


I didn't break anything. Any user, including root, may have his own
environment variables for his own use. This should never interfer
with package installation.

Why not unsetting TEXINPUTS in the postinst script?



The specific file (glyphtounicode.tex) is only read during format 
generation AFAICT. So, if we unset the TEXINPUTS variable the fmtutil 
will again read the default and you will loose your custom file. So 
either leaving TEXINPUTS or clearing it will not get /your/ expected 
results. I guess you need a correctly fixed glyphtounicode.tex, which 
contains a correct fix, w/o breaking other things.


Currently I don't understand, why a file glyphtounicode.tex sitting in 
/usr/local/share/texmf/tex/generic/pdftex/ is ignored during format 
generation, but this is not the topic of this bug.


Hilmar
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1041441: Bug#1018206: luatex loses or changes text when discretionaries with priorities are used

[Preuße]

On 24.09.2023 23:29, Preuße...@buxtehude.debian.org, Hilmar wrote:

On 28.08.2023 21:59, Preuße...@buxtehude.debian.org, Hilmar wrote:

On 23.07.2023 23:21, Preuße...@buxtehude.debian.org, Hilmar wrote:


Hi Peter,

I've uploaded the revision -8 to unstable, which is a prereq for 
having a fix in bookworm. I've uploaded packages for bookworm to here 
[1]. Would be nice if you could patch your system and test them. At 
least your example is solved.


Hilmar

[1] https://freeshell.de/~hille42/1041441/



Ping...

I intend to push the fix to next point release, but I need to make 
sure it solves the issue in question.




Ping.

Hilmar


Ping.

Hilmar


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056587: texlive-latex-base: some math characters get replaced as of Debian's TeX Live 2023

[Preuße]

On 24.11.2023 03:50, Vincent Lefevre wrote:

Hi,


If I understand correctly, /var/lib/texmf/web2c/pdftex/pdflatex.fmt is
generated by fmtutil, but its man page does not say that $TEXINPUTS is
used.



Well, fmtutil in turn calls the TeX interpreters / compilers, which then 
read $TEXINPUTS and find your file. I'd say: you broke your system 
somehow, I tend to close the bug.


H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056587: texlive-latex-base: some math characters get replaced as of Debian's TeX Live 2023

[Hilmar Preuße]

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#1051542: texlive-extra-utils: a5toa4 fails to generate pdf: No such file or directory

[Preuße]

Control: tags -1 + pending
Control: tags -1 + patch

On 22.11.2023 07:59, Pavel Sanda wrote:

Hi,


This patch passed all my testing. Pavel


Great! Patch is in repo and will be in next upload.

H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1041631: texlive-xetex: CreationDate in the generated PDF file is incorrect by 1 hour in some timezones

[Preuße]

On 21.11.2023 01:11, Vincent Lefevre wrote:

On 2023-11-20 22:53:06 +0100, Preuße, Hilmar wrote:


Hi,


Currently I'm now able to reproduce the issue, I guess b/c we're in winter
time. I guess I have to break the time on my test box...


No need to break the time. Try with "TZ=Australia/Canberra", which
currently has summer time.

zira:~> export TZ=Australia/Canberra
zira:~> date && xelatex test.tex && pdfinfo test.pdf | grep Date:
Tue Nov 21 11:10:08 AEDT 2023
[...]
CreationDate:Tue Nov 21 10:10:08 2023 AEDT



I'm able top reproduce it here on TL 2023.

Hilmar
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1051542: texlive-extra-utils: a5toa4 fails to generate pdf: No such file or directory

[Preuße]

Control: tags -1 - pending

On 21.11.2023 10:42, Pavel Sanda wrote:

On Mon, Nov 20, 2023 at 11:21:19PM +0100, Preuße, Hilmar wrote:


Hi,


I plan to push it into CTAN, so it will hopefully get fixed in trixie
(or bookworm if some cares to backport the fix).


Thanks for the patch! I did not test it, but I've seen you did. I pushed it
to our repo so it will be in next upload. Good luck with pushing the patch
to CTAN.


Hilmar, please hold on with upload. I need to improve the patch as it breaks
with absolute paths. Don't know where I made the mistake because I was testing
for it before going public. Anyway I need to come with a better fix.
Will keep you posted...



Thanks for information. I'll comment the patch for now.

Hilmar


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056204: nmu: texlive-bin_2023.20230311.66589-7

[Preuße]

On 20.11.2023 11:34, Adrian Bunk wrote:

Hi all,


Right now the autopkgtests block zlib migration to testing since they
test zlib/unstable with texlive-binaries/testing - this is permitted
by the dependencies.

And this is not just a test issue:

Anybody has opened #1056312, I add my statement how to address this 
issue. So, I guess time to close this bug here.


Thanks to all, who contributed!

Hilmar
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1051542: texlive-extra-utils: a5toa4 fails to generate pdf: No such file or directory

[Preuße]

Control: tags -1 - wontfix
Control: tags -1 + pending

On 20.11.2023 16:46, Pavel Sanda wrote:

Hello Pavel,


You can try proposed fix on your current setup.
https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg220760.html

I plan to push it into CTAN, so it will hopefully get fixed in trixie
(or bookworm if some cares to backport the fix).

Thanks for the patch! I did not test it, but I've seen you did. I pushed 
it to our repo so it will be in next upload. Good luck with pushing the 
patch to CTAN.


Hilmar
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1041631: texlive-xetex: CreationDate in the generated PDF file is incorrect by 1 hour in some timezones

[Preuße]

On 21.07.2023 16:46, Vincent Lefevre wrote:

On 2023-07-21 16:36:21 +0200, Preuße, Hilmar wrote:

On 21.07.2023 16:28, Vincent Lefevre wrote:


Hi,


The "CreationDate:" field in the generated PDF file is incorrect by
1 hour in the Europe/Paris CEST timezone (= UTC + 2).


I've uploaded TL2023 to experimental. Are you willing to test if the issue
is solved there?

Beware: the package is not complete yet, there is not context package being
compatible to texlive-binaries.


Sorry, I've just noticed that I forgot to include the test.tex file.
Here is it (this is the simplest one as possible):

\documentclass{article}
\begin{document}
.
\end{document}

If you installed TL2023 on one of your machines, could you try to
reproduce the bug after "export TZ=Europe/Paris", for instance?

Otherwise, I can try (but it will be a bit complex to upgrade the
packages to experimental and downgrade again after the test).



Currently I'm now able to reproduce the issue, I guess b/c we're in 
winter time. I guess I have to break the time on my test box...


H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056315: texlive-latex-base: lualatex - zlib library version does not match

[Preuße]

Control: reassign -1 texlive-binaries
Control: block -1 by 1056204
Control: severity -1 grave
Control: forcemerge -1 1056183

On 20.11.2023 14:18, Grégory Mounié wrote:

Hi,


When trying to compile a Latex file with lualatex, lualatex fails immediately
with the following messages:


Just bug handling. Bug is known and addressed already in latest upload.

H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1051243: This affects the build of the pspp package

[Preuße]

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

[Preuße]

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#1056204: nmu: texlive-bin_2023.20230311.66589-7

[Preuße]

On 20.11.2023 01:13, Adrian Bunk wrote:

Hi,


I just noticed that we had this issue already 13 years ago. [2]


And from then zlib1g still has the
   Breaks: texlive-binaries (<< 2009-12)
that will also require updating again.



No, that's younger:

zlib (1:1.2.6.dfsg-2) unstable; urgency=low

  * Break texlive-binaries before 2009-12 due to gzeof() behaviour
change (closes: #659681).

 -- Mark Brown   Thu, 23 Feb 2012 23:28:27 +

Not sure, if we need an updated breaks statement. Anyway, I'll ping 
Tiago again, if the test can be removed at all-


Hilmar
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056304: lualatex needs to be rebuilt against zlib 1.3

[Preuße]

Control: reassign -1 texlive-binaries
Control: block -1 by 1056204
Control: severity -1 grave
Control: forcemerge -1 1056183

On 20.11.2023 10:29, Eric Marsden wrote:

Hi,


% lualatex
PANIC: unprotected error in call to Lua API (zlib library version does not 
match - header: 1.2.13, library: 1.3)
zsh: IOT instruction  lualatex
% lualatex --credits
This is LuaHBTeX, Version 1.17.0 (TeX Live 2023/Debian)

The LuaTeX team is Hans Hagen, Hartmut Henkel, Taco Hoekwater, Luigi Scarso.



Reported a few times already, merging.

H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056204: nmu: texlive-bin_2023.20230311.66589-7

[Hilmar Preuße]

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#1056160: ITS: auctex

[Preuße]

On 19.11.2023 18:09, Davide G. M. Salvetti wrote:

Hi Davide,


I have not yet digged into it, but it looks similar to #1051243.

What do you think?



Actually it is #1056210 and friends. The root cause of #1051243 has been 
fixed long ago, just the phenomenon looks similar to #1056210, hence 
people reopen the bug.


H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056204: nmu: texlive-bin_2023.20230311.66589-7

[Hilmar Preuße]

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

[Hilmar Preuße]

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#1056189: luahbtex: PANIC: unprotected error in call to Lua API (zlib library version does not match - header: 1.2.13, library: 1.3)

[Preuße]

Control: severity -1 grave
Control: merge -1 1056186

On 18.11.2023 16:19, Andreas Metzler wrote:

Hi,


trying to install texlive-latex-base+texlive-plain-generic to fullfill a
build dependency resulted in:
8X--
Setting up tex-common (6.18) ...
Running mktexlsr. 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.VGYt4Mud
Please include this file if you report a bug.



Rebuilding tl-binaries with the new zlib in place seems to solve the 
issue. I'll try to do an bin-NMU.


H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056186: texlive-binaries: zlib library mismatch

[Preuße]

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

[Preuße]

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#1056160: ITS: auctex

[Preuße]

On 18.11.2023 11:51, Davide G. M. Salvetti wrote:

Hello Davide,


please, let me have some more time.  I plan to release a new version
within a fortnight.

Many thanks for fast response! I'll leave the ITS bug open, but I won't 
drive the salve process forward. In case I can help somehow, let me know.


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/

[Hilmar Preuße]

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

[Hilmar Preuße]

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/)

[Hilmar Preuße]

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"

[Hilmar Preuße]

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)

[Hilmar Preuße]

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