Bug#1076675: Broken french locale/babel setting (Undefined control sequence / Missing \begin{document})

[Preuße]

On 24.07.2024 15:35, Alexis Bienvenüe wrote:

Hello Alexis,


It seems that \FBCompactItemize@setup is called from line 1189 of
/usr/share/texlive/texmf-dist/tex/generic/babel-french/french.ldf
but this function is defined as \FB@CompactItemize@setup (with an extra @) at 
line 1281.

Removing the first @ at line 1281 seems to fix this bug.
Note that the same should also be done with \FB@ListOldLayout@setup at line 
1274.

I don't know where this file come from upstream.



Thanks for the analysis. I've contacted the upstream author and hope for 
reply soon.


Hilmar
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1076675: Wrong macro definition in french.ldf?

[Preuße]

Dear Daniel,

down here in the Debian bug tracking system we got a bug report [1], 
which points to a possible bug in french.ldf. I don't really have a 
minimal example for problem reproduction, except the code at the 
beginning of the report, which is far form being minimal.


More interesting is the statement below [2]:


It seems that \FBCompactItemize@setup is called from line 1189 of
/usr/share/texlive/texmf-dist/tex/generic/babel-french/french.ldf
but this function is defined as \FB@CompactItemize@setup (with an extra 
@) at line 1281.


Removing the first @ at line 1281 seems to fix this bug.
Note that the same should also be done with \FB@ListOldLayout@setup at 
line 1274.



Could you check and suggest a proper solution?

Thanks,
  Hilmar

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076675
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076675#23
--
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:

Hi Julian


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.



I did for most of them [1]. The most heavy stuff (texlive-*) is pulled 
in by asymptote itself. I'll evaluate if these Deps can be downgraded to 
Recommends.


Hilmar

[1] 
https://github.com/debian-tex/asymptote/commit/7afaf5386b32778e9334c6912c66a7f8628de356

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

Hi Julian,


On Wed, Jan 24, 2024 at 06:07:56PM +0100, 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.

[...]
(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.



Today I tested again and the test suites run, not sure, what was the 
fault before. Into debian/tests/control I inserted:


Depends: asymptote (= ${binary:Version}),

That failed b/c the syntax was not understood. When leaving out the 
version specification the test runs fine, but I'm not sure if it is OK 
to leave out the version specification.


Hilmar
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1076010: texlive-latex-base: regressions using babel+hebrew in luatex

[Preuße]

On 09.07.2024 13:02, Nick Black (Public gmail account) wrote:

Hi,


Beginning sometime this year, using Hebrew with babel in LuaTeX results in
positioning errors.

2023.20240207-1 worked properly, but one of the three 2024 updates introduced
these regressions. I'm not sure which. I can look into it if you'd like me to.



I've uploaded a new snapshot of texlive-base/-lang/-extra, which should 
enter testing soon. Please be so kind to test.


Hilmar
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1076010: texlive-latex-base: regressions using babel+hebrew in luatex

[Preuße]

On 09.07.2024 13:02, Nick Black (Public gmail account) wrote:

Hi,


This seems independent of surrounding text and placement on the page.
Like I said, I'm preparing a true minimum viable example. Let me know
what else I can provide.



I don't really have the time to care about upstream issues. I plan to 
upload a new CTAN Snapshot, so there is a chance that the issue gets 
solved soon. Alternatively you may install the latest babel into your 
local texmf tree and tell me if the issue got solved.


Thanks,
  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]

On 19.05.2024 14:14, Preuße, Hilmar wrote:

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
<https://github.com/leahneukirchen/nq/issues/48#issuecomment-2091077937>,
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.


The upstream of nq released version 1.0, where some binaries are renamed 
to solve the file conflict. Hence I'll do an NMU for nq and upload to 
the delayed queue.


Hilmar


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1074343: src:texlive-bin: fails to migrate to testing for too long: unresolved RC issue

[Preuße]

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

[Preuße]

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#1071576: bugs.debian.org: bug subscription no longer possible: no "Please confirm subscription" e-mail

[Preuße]

On 21.06.2024 10:40, Vincent Lefevre wrote:

Hi,


I've tried again with

Date: Fri, 21 Jun 2024 09:56:17 +0200


For me bug subscription works again fine. No clue what is the difference
to your setup.

Hilmar
--
sigfault

Bug#1072828: Work-around is ineffective on !amd64

[Preuße]

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=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=revision

I'll upload fixed tl-base soon; the test build run fine.

Hilmar
--
sigfault

Bug#1072828: Work-around is ineffective on !amd64

[Preuße]

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=all=6.2.1-1=1710963335=1
[2]
https://buildd.debian.org/status/fetch.php?pkg=therion=amd64=6.2.1-1%2Bb1=1717847632=1
--
sigfault

Bug#1072828: Work-around is ineffective on !amd64

[Preuße]

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)

[Preuße]

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