texlive-2023

[ken@…]

From Karl Berry on tldistro list:

Hi everyone - I've moved the tl23 and mactex23 images and other files to the public areas on tug.org. They are making their way around CTAN. Please give it a couple days to reach the mirrors. ​https://tug.org/texlive/acquire.html ​https://tug.org/mactex

I've so far found one european mirror with 2023 source, dates are 20230313 for source and texmf, but 20230311 for tlpdb.

[ken@…]

Points of interest so far:

1. There is only one test failure in texlive-source, but it is new. In Web2C eptexdir/wcfname fails - seems to be a test for different japanese encodings, but created temp files do not exist. Same when tested on LFS-11.2 and LFS-11.1.

2. No context program, nor contextjit. In 2022 these were symlinks to the scripts the texmf-dist/scripts/context/stubs/unix but in 2023 that stubs directory does not exist.

Reported.

[ken@…]

For context: both context and mtxrun are now (in binaries) symlinks to luametatex which is not shipped in TL2023. Supposedly there is source in TL at source/luametatex-230310.tar.xz but that is NOT part of the texlive-source tarball.

Upstream source is at ​https://github.com/contextgarden/luametatex/ and it uses cmake. BUT - no releases, no tags.

More details at ​https://wiki.contextgarden.net/Installation - seems to just be binaries.

[ken@…]

Found it at ​https://tug.org/svn/texlive/trunk/Master/source/, I can download that via firefox (click on it, click on download - it is currently at svn revision 66577 but probably could be hosted on anduin.

I thought this part was a local problem, there may be more discussion on the tldistro list in the next days.

[ken@…]

I got a further reply on the (main) tex-live list ​https://tug.org/pipermail/tex-live/2023-March/048950.html -

Anything in the "main" branch:

   https://github.com/contextgarden/luametatex/tree/main

you can consider to be a "tagged" release. Look at the commit titles to
get the version.

The "work" branch:

   https://github.com/contextgarden/luametatex/tree/work

would be, as you say, just a random snapshot. The only time that I've
ever needed to use this is if I'm testing a patch that Hans made to
solve I bug that I reported.

You can also use the source for the "ConTeXt LMTX Distribution" (aka the
"official" ConTeXt distribution):

   https://github.com/contextgarden/context/tree/main/source/luametatex/source

This should generally be fairly similar to the "tagged" releases above,
although it sometimes has a few new patches. Anything in here was deemed
stable enough to send out to all of the ConTeXt LMTX users.

[ken@…]

Managed, eventually, to manually install luametatex where I wanted (ninja install adds an unnecessary bin directory after the prefix which was already pointing to .../bin/x86_64-linux) and symlink context and mtxrun to luametatex. But mtxrun --generate fails with

startup error : no format file given, quitting

There is an AUR file ​https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=luametatex which appears on a quick glance to be using various source files from February (at least the TL tarball has all those parts), but then downloading zip files from ctan of contributed context filters, installing the progs and making them executable, then installing the context modules somewhere, creating a setuptex file in the source, various things related to preserving source and allowing future updates (I think), and then linking from the source to texlive fonts IFF those have been installed.

Seems to have some useful parts, but that build is quite separate from texlive.

Looking at what was in TL2022 and what is in TL2023, probably the lua files in texmf-dist/context/data/ might be useful. Beyond that it's anybody's guess, a lot of stuff is PDFs, some of the tex files might be usable but it's a mess.

[ken@…]

Got it working, at least for mkiv. Will create a ticket for luametatex.

[Xi Ruoyao]

Replying to ken@…:

Points of interest so far:

1. There is only one test failure in texlive-source, but it is new. In Web2C eptexdir/wcfname fails - seems to be a test for different japanese encodings, but created temp files do not exist. Same when tested on LFS-11.2 and LFS-11.1.

psutils.test still fails for me, in addition to wcfname. I guess you didn't see the psutils.test failure because you've not passed "-k" to "make check", so the test suite is not finished when a test fails early.

[Xi Ruoyao]

biber needs an update too, or I get:

ERROR - Error: Found biblatex control file version 3.10, expected version 3.9.
This means that your biber (2.18) and biblatex (3.19) versions are incompatible.
See compat matrix in biblatex or biber PDF documentation.

[Xi Ruoyao]

Alright, there is already #17757.

[Xi Ruoyao]

I've updated texlive-2023 and biber-2.19 and it seems no issues. I don't use context.

[ken@…]

Replying to Xi Ruoyao:

Replying to ken@…:

Points of interest so far:

1. There is only one test failure in texlive-source, but it is new. In Web2C eptexdir/wcfname fails - seems to be a test for different japanese encodings, but created temp files do not exist. Same when tested on LFS-11.2 and LFS-11.1.

psutils.test still fails for me, in addition to wcfname. I guess you didn't see the psutils.test failure because you've not passed "-k" to "make check", so the test suite is not finished when a test fails early.

Thanks, added to my list.

[ken@…]

On the binary, all looks good except for asy which does not run, it needs libGLX.so. That comes from libglvnd (from freedesktop), fedora patch a load of python scripts to invoke python3 and split the package, using configure variations - looks as if their GL variant will provide that but also other gl, GL libs. Arch use meson, ninja and list a load of libs, three appear to conflict with mesa: libEGL.so.1.0.0, libGL.so.1, libGLESv2.so.1.

Will investigate. Maybe needs a hint.

[Douglas R. Reno]

Replying to ken@…:

On the binary, all looks good except for asy which does not run, it needs libGLX.so. That comes from libglvnd (from freedesktop), fedora patch a load of python scripts to invoke python3 and split the package, using configure variations - looks as if their GL variant will provide that but also other gl, GL libs. Arch use meson, ninja and list a load of libs, three appear to conflict with mesa: libEGL.so.1.0.0, libGL.so.1, libGLESv2.so.1.

Will investigate. Maybe needs a hint.

Would it be possible to build libglvnd and then just copy the relevant headers and libraries into /usr/lib and /usr/include for just libGLX? I know Mesa can produce a GLX support library as well with -Dglx=xorg (or -Dglx=dri) being passed to it, though it's not what we're looking for here.

If we were to add libglvnd to the book normally with all of its libraries, we need to pass -Dglvnd=true to Mesa so the libraries do not conflict.

This is interesting too (spotted in 23.0.0, was doing some research for libGLX):

option( 
  'gallium-rusticl', 
  type : 'boolean',
  value : false,
  description : 'build gallium "rusticl" OpenCL frontend.',
) 

For our use case, it isn't needed right now, but I guess the initial rust support for Mesa has been merged...

In summary, if we add libglvnd, we can add -Dglvnd=true and then maybe -Dglx=dri (just to be on the safe side) so that things do not conflict.

[ken@…]

Replying to Douglas R. Reno:

Replying to ken@…:

On the binary, all looks good except for asy which does not run, it needs libGLX.so. That comes from libglvnd (from freedesktop), fedora patch a load of python scripts to invoke python3 and split the package, using configure variations - looks as if their GL variant will provide that but also other gl, GL libs. Arch use meson, ninja and list a load of libs, three appear to conflict with mesa: libEGL.so.1.0.0, libGL.so.1, libGLESv2.so.1.

Will investigate. Maybe needs a hint.

Would it be possible to build libglvnd and then just copy the relevant headers and libraries into /usr/lib and /usr/include for just libGLX? I know Mesa can produce a GLX support library as well with -Dglx=xorg (or -Dglx=dri) being passed to it, though it's not what we're looking for here.

If we were to add libglvnd to the book normally with all of its libraries, we need to pass -Dglvnd=true to Mesa so the libraries do not conflict.

I've added it on the one completed 11.3 system where I installed the binary, it overwrites just about everything from mesa, including installing newer versions of libEGL.so (1.1.0), libGLESv1_CM.so (1.2.0),libGLESv2.so (2.1.0), libGL.so (1.7.0) then adds the following on a default build:

libs: libGLdispatch.so, libGLX.so, libOpenGL.so directory /usr/include/glvnd and pkgconfig files for glx, libglvnd, opengl.

On that machine with a low-end AMD APU it allows asy to create 2D PDFs in latex, but not 3D (asy is usually broken for that on low-end AMD APUs). I see no obvious reason to add it to the book. I was thinking of a hint for those BLFS users who wish to use asy from binary TL2023, but my estimate is that their number is zero - so I'll just add some sort of optional dep, with a note it is only needed for using asy, and will overwrite files from mesa.

This is interesting too (spotted in 23.0.0, was doing some research for libGLX):

option( 
  'gallium-rusticl', 
  type : 'boolean',
  value : false,
  description : 'build gallium "rusticl" OpenCL frontend.',
) 

For our use case, it isn't needed right now, but I guess the initial rust support for Mesa has been merged...

In summary, if we add libglvnd, we can add -Dglvnd=true and then maybe -Dglx=dri (just to be on the safe side) so that things do not conflict.

[ken@…]

Replying to ken@…:

Replying to Xi Ruoyao:

Replying to ken@…:

Points of interest so far:

1. There is only one test failure in texlive-source, but it is new. In Web2C eptexdir/wcfname fails - seems to be a test for different japanese encodings, but created temp files do not exist. Same when tested on LFS-11.2 and LFS-11.1.

psutils.test still fails for me, in addition to wcfname. I guess you didn't see the psutils.test failure because you've not passed "-k" to "make check", so the test suite is not finished when a test fails early.

Thanks, added to my list.

Sorry, not agreed. In case it matters, this system is LFS 20230308 11.3-17, gde679165f9a63ce94202d356abbae2b9a3bff5c3 and BLFS 20230308 11.3-84 g2554b062cdec93b7700943a7b655783aecd122c. Since I'm still of the view that people should be encouraged to script (but to keep the pieces when their scripts break) I added some bash to look at all the test-suite.log files in texlive (I normally discard the build tree) and to count the FAIL lines.

Results with make -k check using -j12 (not sure if j12 is used for tests) reformatted so that trac puts each on a separate line.

./utils/axodraw2/test-suite.log:

./utils/xml2pmx/test-suite.log:

./utils/autosp/test-suite.log:

./utils/ps2eps/test-suite.log:

./utils/lacheck/test-suite.log:

./utils/tpic2pdftex/test-suite.log:

./utils/m-tx/test-suite.log:

./utils/devnag/test-suite.log:

./utils/pmx/test-suite.log:

./utils/t1utils/test-suite.log:

./texk/bibtex-x/test-suite.log:

./texk/psutils/test-suite.log:

./texk/lcdf-typetools/test-suite.log:

./texk/dvi2tty/test-suite.log:

./texk/kpathsea/test-suite.log:

./texk/gregorio/test-suite.log:

./texk/dvipng/test-suite.log:

./texk/web2c/test-suite.log:

FAIL: eptexdir/wcfname

./texk/web2c/omegafonts/test-suite.log:

./texk/web2c/otps/test-suite.log:

./texk/texlive/test-suite.log:

./texk/seetexk/test-suite.log:

./texk/detex/test-suite.log:

./texk/musixtnt/test-suite.log:

./texk/dvipos/test-suite.log:

./texk/makejvf/test-suite.log:

./texk/cjkutils/test-suite.log:

./texk/makeindexk/test-suite.log:

./texk/ps2pk/test-suite.log:

./texk/xdvik/tests/test-suite.log:

./texk/dviout-util/test-suite.log:

./texk/afm2pl/test-suite.log:

./texk/ttfdump/test-suite.log:

./texk/dvipsk/test-suite.log:

./texk/ttf2pk2/test-suite.log:

./texk/mendexk/test-suite.log:

./texk/dvipdfm-x/test-suite.log:

./texk/dtl/test-suite.log:

./texk/chktex/test-suite.log:

./texk/upmendex/test-suite.log:

./texk/dvidvi/test-suite.log:

./libs/luajit/test-suite.log:

./libs/zziplib/test-suite.log:

./libs/potrace/test-suite.log:

./libs/teckit/test-suite.log:

./libs/pplib/test-suite.log:

./libs/lua53/test-suite.log:

./libs/gd/test-suite.log:

1 failed test(s)

[ken@…]

Replying to ken@…:

Sorry, not agreed. In case it matters, this system is LFS 20230308 11.3-17, gde679165f9a63ce94202d356abbae2b9a3bff5c3 and BLFS 20230308 11.3-84 g2554b062cdec93b7700943a7b655783aecd122c. Since I'm still of the view that people should be encouraged to script (but to keep the pieces when their scripts break) I added some bash to look at all the test-suite.log files in texlive (I normally discard the build tree) and to count the FAIL lines.

Nevertheless, I did get a lot more results with make -k check.

[ken@…]

Replying to ken@…:

Replying to ken@…:

Sorry, not agreed. In case it matters, this system is LFS 20230308 11.3-17, gde679165f9a63ce94202d356abbae2b9a3bff5c3 and BLFS 20230308 11.3-84 g2554b062cdec93b7700943a7b655783aecd122c.

Further thoughts - no PAPER* variables in the environment, but I do have /etc/papersize containing 'a4'. LC_ALL is en_GB.UTF-8.

Unless anything else comes up, I guess I'll note that psutils.testmay fail. At the moment I'm some days away from doing/measuring this on a vanilla system.

[Xi Ruoyao]

Replying to ken@…:

Replying to ken@…:

Replying to ken@…:

Sorry, not agreed. In case it matters, this system is LFS 20230308 11.3-17, gde679165f9a63ce94202d356abbae2b9a3bff5c3 and BLFS 20230308 11.3-84 g2554b062cdec93b7700943a7b655783aecd122c.

Further thoughts - no PAPER* variables in the environment, but I do have /etc/papersize containing 'a4'. LC_ALL is en_GB.UTF-8.

Unless anything else comes up, I guess I'll note that psutils.testmay fail. At the moment I'm some days away from doing/measuring this on a vanilla system.

Negative, it fail *deterministically* with latest libpaper, not *may*.

libpaper was updated in 11.3-88, later than 11.3-84 so you didn't see the issue.

[ken@…]

Replying to Xi Ruoyao:

Unless anything else comes up, I guess I'll note that psutils.testmay fail. At the moment I'm some days away from doing/measuring this on a vanilla system.

Negative, it fail *deterministically* with latest libpaper, not *may*.

libpaper was updated in 11.3-88, later than 11.3-84 so you didn't see the issue.

My apologies, I thought I had picked up libpaper2 but that was while doing other changes after the main parts of this system had already been completed.

[ken@…]

Replying to ken@…:

Replying to Douglas R. Reno:

Replying to ken@…:

On the binary, all looks good except for asy which does not run, it needs libGLX.so. That comes from libglvnd (from freedesktop), fedora patch a load of python scripts to invoke python3 and split the package, using configure variations - looks as if their GL variant will provide that but also other gl, GL libs. Arch use meson, ninja and list a load of libs, three appear to conflict with mesa: libEGL.so.1.0.0, libGL.so.1, libGLESv2.so.1.

Would it be possible to build libglvnd and then just copy the relevant headers and libraries into /usr/lib and /usr/include for just libGLX? I know Mesa can produce a GLX support library as well with -Dglx=xorg (or -Dglx=dri) being passed to it, though it's not what we're looking for here.

If we were to add libglvnd to the book normally with all of its libraries, we need to pass -Dglvnd=true to Mesa so the libraries do not conflict.

LOL, I dropped libglvnd on top of the system, binary asy works. Then I built latest firefox beta using LLVM16 and rust-1.68.0. Firefox beta did not start, first error is

Crash Annotation GraphicsCriticalError: |[0][GFX1-]: glxtest: libEGL no display (t=0.067514) [GFX1-]: glxtest: libEGL no display
Crash Annotation GraphicsCriticalError: |[0][GFX1-]: glxtest: libEGL no display (t=0.067514) |[1][GFX1-]: glxtest: No visuals found (t=0.0675473) [GFX1-]: glxtest: No visuals found

so I've broken that system. As you say, need to change Mesa IFF libglvnd is going to be installed.

[ken@…]

Replying to ken@…:

If we were to add libglvnd to the book normally with all of its libraries, we need to pass -Dglvnd=true to Mesa so the libraries do not conflict.

LOL, I dropped libglvnd on top of the system, binary asy works. Then I built latest firefox beta using LLVM16 and rust-1.68.0. Firefox beta did not start, first error is

Crash Annotation GraphicsCriticalError: |[0][GFX1-]: glxtest: libEGL no display (t=0.067514) [GFX1-]: glxtest: libEGL no display
Crash Annotation GraphicsCriticalError: |[0][GFX1-]: glxtest: libEGL no display (t=0.067514) |[1][GFX1-]: glxtest: No visuals found (t=0.0675473) [GFX1-]: glxtest: No visuals found

so I've broken that system. As you say, need to change Mesa IFF libglvnd is going to be installed.

Not quite correct. Arch have libglvnd depending on mesa, so first I tried rebuilding mesa with that extra swithc, but glxinfo and glxgears failed to link. Then I ripped out all of mesa and libglvnd and tried building mesa with that switch: meson failed, dependency libglvnd not found.

Errk, libglvnd does not build: fatal error: GL/glxproto.h: No such file or directory So not all of /usr/include/GL came from mesa.

[ken@…]

re libGLX (libglvnd) - trying to reinstall glxgears and glxinfo (building mesa with the switch after libglvnd) still fails with a lot of undefined references.

[Xi Ruoyao]

AFAIK libglx from libglvnd is only a shim layer. It selects a libglx from Mesa or a GPU vendor (for example the NVIDIA one) and load it.

The correct solution is installing libglx from Mesa.

[Xi Ruoyao]

Please don't add libglvnd unless you plan to support the binary driver from NVIDIA (or another vendor). libglvnd is only a shim layer, it does not provide any function expect selecting a suitable GL/EGL/GLX driver provided by another package (from source or binary).

[ken@…]

Replying to Xi Ruoyao:

AFAIK libglx from libglvnd is only a shim layer. It selects a libglx from Mesa or a GPU vendor (for example the NVIDIA one) and load it.

The correct solution is installing libglx from Mesa.

The asy binary needs libGLX, not libglx, because it was compiled on a debian system. Apparently it has been like that for the past two years as well. And no, I have zero intention of adding libglvnd, but I hoped to find a way of showing how it could be added to a completed BLFS xorg without breaking future package builds if someone wanted to use asy from the binary.

However, something went wrong when I restored a backup, that box no longer finds grub.

[Xi Ruoyao]

Replying to ken@…:

Replying to Xi Ruoyao:

AFAIK libglx from libglvnd is only a shim layer. It selects a libglx from Mesa or a GPU vendor (for example the NVIDIA one) and load it.

The correct solution is installing libglx from Mesa.

The asy binary needs libGLX, not libglx, because it was compiled on a debian system. Apparently it has been like that for the past two years as well. And no, I have zero intention of adding libglvnd, but I hoped to find a way of showing how it could be added to a completed BLFS xorg without breaking future package builds if someone wanted to use asy from the binary.

I searched libGLX in ​https://github.com/vectorgraphics/asymptote but there is nothing. How did it end up linking to libGLX? Can we just provide a "dummy" library to work around?

Is there a download link for the asy executable and a test case so I can try it?

Or should we simply suggest to build asymptote following BLFS?

[Xi Ruoyao]

I downloaded an asy binary from ​https://sourceforge.net/projects/asymptote/files/2.85/asymptote-2.85.x86_64.tgz. It is fundamentally incompatible with (B)LFS: it needs various libraries not provided by LFS and BLFS, besides libGLX.so.0:

• libgsl.so.25 (BLFS provides libgsl.so.27)
• libtinfo.so.6 (LFS builds it as a part of libncursesw.so.6)
• libncurses.so.6 (LFS builds the wide-character version, libncursesw.so.6, the non-wide-character version not built)
• libboost_filesystem.so.1.78.0 (BLFS provides libboost_filesystem.so.1.81.0)
• libboost_thread.so.1.78.0 (BLFS provides libboost_thread.so.1.81.0)
• libboost_system.so.1.78.0 (BLFS provides libboost_system.so.1.81.0)

There is no rational way to support this thing in BLFS. Or is the asy binary from tlmgr "better"?

[ken@…]

I've restored the system, fixed up grub, and then built libglvnd followed by rebuilding mesa without rebuilding glxinfo, glxgears, i.e. not using the patch on the rebuild. That is not ideal but after adding firefox-beta that now works (as does asy for 'asy --version'.

The libs used by my existing glxgears have become:

 · linux-vdso.so.1
 · libGL.so.1
 · libX11.so.6
 · libm.so.6
 · libc.so.6
 · libGLdispatch.so.0
 · libGLX.so.0
 · libxcb.so.1
 · /lib64/ld-linux-x86-64.so.2
 · libXau.so.6
 · libXdmcp.so.6

and for glxinfo:

 · linux-vdso.so.1
 · libGL.so.1
 · libX11.so.6
 · libc.so.6
 · libGLdispatch.so.0
 · libGLX.so.0
 · libxcb.so.1
 · /lib64/ld-linux-x86-64.so.2
 · libXau.so.6
 · libXdmcp.so.6

The binary asy from TL2023 is linked to

· linux-vdso.so.1
· libGLX.so.0
· libglut.so.3
· librt.so.1
· libz.so.1
· libGL.so.1
· libstdc++.so.6
· libm.so.6
· libgcc_s.so.1
· libpthread.so.0
· libc.so.6
· libGLdispatch.so.0
· libX11.so.6
· libXrandr.so.2
· libXxf86vm.so.1
· libXi.so.6
· /lib64/ld-linux-x86-64.so.2
· libxcb.so.1 
· libXext.so.6 
· libXrender.so.1
· libXau.so.6
· libXdmcp.so.6

and I see that libGLX pulls in libGLdispatch and libGL.so now pulls in both GLX and GLdispatch.

I have more alternatives to look at, but "shipped binary asy is not usable in BLFS" is becoming a possibility.

[ken@…]

For my sins, I've been added to ​https://tug.org/texlive/distro.html :-(

[ken@…]

For psutils, there is a difference in the rounding (in 6tth place of decimals) between old libpaper and current libpaper2, nothing to worry about.

[ken@…]

Replying to ken@…:

and I see that libGLX pulls in libGLdispatch and libGL.so now pulls in both GLX and GLdispatch.

I have more alternatives to look at, but "shipped binary asy is not usable in BLFS" is becoming a possibility.

On a freshly restored system, everything is fine if I do the following for libglvnd:

mkdir build
cd build
meson setup .. \
 --prefix=/usr \
 --buildtype=release
ninja
(ninja test if desired)
export DESTDIR=/tmp/LIBGLX
ninja install
(and the nas root)
p -v $DESTDIR/usr/lib/libGLX.so* /usr/lib
cp -v $DESTDIR/usr/lib/libGLdispatch.so* /usr/lib

That installs enough for asy from install-tl-unx to run and does not break anything when updating BLFS.

[Xi Ruoyao]

Replying to ken@…:

Replying to ken@…:

and I see that libGLX pulls in libGLdispatch and libGL.so now pulls in both GLX and GLdispatch.

I have more alternatives to look at, but "shipped binary asy is not usable in BLFS" is becoming a possibility.

On a freshly restored system, everything is fine if I do the following for libglvnd:

mkdir build
cd build
meson setup .. \
 --prefix=/usr \
 --buildtype=release
ninja
(ninja test if desired)
export DESTDIR=/tmp/LIBGLX
ninja install
(and the nas root)
p -v $DESTDIR/usr/lib/libGLX.so* /usr/lib
cp -v $DESTDIR/usr/lib/libGLdispatch.so* /usr/lib

That installs enough for asy from install-tl-unx to run and does not break anything when updating BLFS.

Can you try ln -sv libGL.so.1 /usr/lib/libGLX.so.0 instead? I guess it may work but not sure.

[Xi Ruoyao]

And I'm not sure if you should install libGLX.so and libGLdispatch.so even if libGLX.so.1 and libGLdispatch.so.? is needed. You can install libGLX.so.1 and libGLdispatch.so.? alone to make asy work.

Installing a non-versioned .so symlink can influence building process of other packages. For example, a package may find libGLdispatch.so then attempts to use headers from libglvnd, and fails to build. "Major" distros often separate the non-versioned .so symlinks along with the headers into the -dev package for this reason.

[ken@…]

psutils.test - fedora have a patch at ​https://src.fedoraproject.org/rpms/texlive-base/raw/rawhide/f/texlive-base-libpaperv2.patch which changes the rounding to match what libpaper2 produces.

[ken@…]

Replying to ken@…:

psutils.test - fedora have a patch at ​https://src.fedoraproject.org/rpms/texlive-base/raw/rawhide/f/texlive-base-libpaperv2.patch which changes the rounding to match what libpaper2 produces.

No real point in patching for that. For wcfname, the dev says "It seems that encoding conversion procedure Encode::from_to() failed in fn-generate.perl and it caused error. I committed a patch to skip tests for Shift_JIS/EUC-JP if it failed. ​https://tug.org/svn/texlive?view=revision&revision=6670" so I'll just note that both tests fail.

[ken@…]

Fixed in (sha:g830acb578ee0 r11.3-221)

[Bruce Dubbs]

Milestone renamed