From mojca.miklavec.lists at gmail.com  Wed Dec  2 05:17:33 2020
From: mojca.miklavec.lists at gmail.com (Mojca Miklavec)
Date: Wed, 2 Dec 2020 05:17:33 +0100
Subject: Naming the ARM(64) binaries for Windows
Message-ID: <CALBOmsbEnnM+PcgQHpoH-JM313VCddrj4jST6ePGk1o19mDiRA@mail.gmail.com>

Hi,

After figuring out how to build the binaries for arm on Windows, we
added some preliminary support to ConTeXt.

I just wanted to ask what TeX Live's official name would be for that
architecture in case it gets supported one day (in order to at least
try to be somewhat compatible in naming).

Please note that I'm not asking anyone to add any support whatsoever,
just some brainstorming about the naming in some distant future, since
the naming scheme for Windows doesn't follow the one from other
unixes.

Mojca

From henri at henrimenke.de  Wed Dec  2 09:42:28 2020
From: henri at henrimenke.de (Henri Menke)
Date: Wed, 02 Dec 2020 09:42:28 +0100
Subject: Naming the ARM(64) binaries for Windows
In-Reply-To: <CALBOmsbEnnM+PcgQHpoH-JM313VCddrj4jST6ePGk1o19mDiRA@mail.gmail.com>
References: <CALBOmsbEnnM+PcgQHpoH-JM313VCddrj4jST6ePGk1o19mDiRA@mail.gmail.com>
Message-ID: <64410f5eb0cc5ba1dbe2fc6d74ad7b9b5d6f0062.camel@henrimenke.de>

On Wed, 2020-12-02 at 05:17 +0100, Mojca Miklavec wrote:
> Hi,
> 
> After figuring out how to build the binaries for arm on Windows, we
> added some preliminary support to ConTeXt.
> 
> I just wanted to ask what TeX Live's official name would be for that
> architecture in case it gets supported one day (in order to at least
> try to be somewhat compatible in naming).

It should be named `aarch64`, because the GNU triplet for this architecture is
`aarch64-linux-gnu` which is what GNU config.guess reports, which is used by TeX
Live.  Most Linux distributions call it that way (with Debian being one notable
exception where it's called arm64).  Note that the new Apple Silicon M1
architecture is also called `aarch64-apple-darwin`.  What is the output of
`uname -m` on a Windows ARM machine?

Cheers, Henri

> Please note that I'm not asking anyone to add any support whatsoever,
> just some brainstorming about the naming in some distant future, since
> the naming scheme for Windows doesn't follow the one from other
> unixes.
> 
> Mojca


From jhielscher at posteo.de  Wed Dec  2 14:42:05 2020
From: jhielscher at posteo.de (Johannes Hielscher)
Date: Wed, 2 Dec 2020 14:42:05 +0100
Subject: Naming the ARM(64) binaries for Windows
In-Reply-To: <64410f5eb0cc5ba1dbe2fc6d74ad7b9b5d6f0062.camel@henrimenke.de>
References: <CALBOmsbEnnM+PcgQHpoH-JM313VCddrj4jST6ePGk1o19mDiRA@mail.gmail.com>
 <64410f5eb0cc5ba1dbe2fc6d74ad7b9b5d6f0062.camel@henrimenke.de>
Message-ID: <20201202144205.15efc5a2@capsicvm>

Am Wed, 02 Dec 2020 09:42:28 +0100
schrieb Henri Menke via tex-live <tex-live at tug.org>:

> > I just wanted to ask what TeX Live's official name would be for that
> > architecture in case it gets supported one day (in order to at least
> > try to be somewhat compatible in naming).  
> 
> It should be named `aarch64`, because the GNU triplet for this
> architecture is `aarch64-linux-gnu`

I second this. Back then (October 2017) when I suggested inclusion of
the aarch64-linux port into TL, I did some (superficial) research on
where the different names for that ISA come from, and concluded that
?aarch64? is the least troublesome one (wrt arm64, armv8h, armv8-a and
others).
This is reflected in the installer/tlmgr info text 
> GNU/Linux on ARM64 (aarch64-linux)
http://tug.org/svn/texlive/trunk/Master/tlpkg/TeXLive/TLUtils.pm?r1=46207&r2=46208

Unfortunately, the naming isn't always consistent across OS/distro
boundaries (cf. ppc64el|ppc64le, x86_64|x86-64|x64|amd64), and at least
some of this Babylonian confusion carried over into TL in the form of
x86_64-{linux,solaris,?} vs. amd64-{free,net}bsd.

Naming is balancing uniformity among our own naming vs. respect for
varying conceptions and history of OS platforms out there. If I were to
decide, I'd try to avoid multiple names for the same thing, and go with
what we have (here: aarch64) as far as no grave objections are raised
from the ?new? side.

To add some perspective: Supposed we chose the ?wrong? name here (i. e.
Microsoft decides to refuse allegiance with TL). Then it'll be at least
as much of an issue as explaining users of recent Windows ?x64?
machines why to go with ?win32? or ?x86_64-cygwin?.

> > Naming the ARM(64) binaries for Windows
Just to be sure: we are talking about pure native 64-bit ARM64 aka ARMv8
here? Or has MS decided to also include some 32-bit legacy, not only
with their x86 emulation, but also native ARM (NB: ARMv8 also supports
32-bit mode, coined AArch32)?

Best,
Johannes


From mojca.miklavec.lists at gmail.com  Wed Dec  2 23:23:19 2020
From: mojca.miklavec.lists at gmail.com (Mojca Miklavec)
Date: Wed, 2 Dec 2020 23:23:19 +0100
Subject: Naming the ARM(64) binaries for Windows
In-Reply-To: <64410f5eb0cc5ba1dbe2fc6d74ad7b9b5d6f0062.camel@henrimenke.de>
References: <CALBOmsbEnnM+PcgQHpoH-JM313VCddrj4jST6ePGk1o19mDiRA@mail.gmail.com>
 <64410f5eb0cc5ba1dbe2fc6d74ad7b9b5d6f0062.camel@henrimenke.de>
Message-ID: <CALBOmsb-7xL-u6HqWjvEP2wWoWihWWd7bYLBb9abTmJpRFrORw@mail.gmail.com>

On Wed, 2 Dec 2020 at 14:42, Johannes Hielscher wrote:
> > > Naming the ARM(64) binaries for Windows
> Just to be sure: we are talking about pure native 64-bit ARM64 aka ARMv8
> here? Or has MS decided to also include some 32-bit legacy, not only
> with their x86 emulation, but also native ARM (NB: ARMv8 also supports
> 32-bit mode, coined AArch32)?

Just to clarify: I don't own any arm-based hardware running Windows,
so at the moment I probably have no simple way of testing anything
myself.

But (on a 64-bit Intel processor which I do have) Microsoft offers
four different options to compile binaries: Win32, x64, ARM, ARM64.

I have absolutely no idea under what circumstances one would want to
compile 32-bit arm Windows binaries. Maybe for Windows RT? (Which I
wouldn't bother supporting even if we do one day start supporting Arm
in TL.)


On Wed, 2 Dec 2020 at 09:43, Henri Menke via tex-live wrote:
>
> It should be named `aarch64`,

I was primarily asking about the full name for the binaries, not just
for the architecture name. Even if we decide to stick with "aarch64",
that still leaves the question about whether that means aarch64-win /
aarch64-windows / aarch64-mswin / win-aarch64 / windows-aarch64 / ...
etc. (in addition to possible replacing aarch64 with arm64)

Microsoft almost exclusively promotes "ARM64".

> because the GNU triplet for this architecture is
> `aarch64-linux-gnu` which is what GNU config.guess reports,
> which is used by TeX Live.

... except when it isn't [used by TL].
How do you run config.guess on a clean Windows box (without having
installed one of the toolsets like cygwin, msys, WSL, ...)?

>From http://tug.org/svn/texlive/trunk/Master/tlpkg/TeXLive/TLUtils.pm?revision=56565&view=markup#l242
> If C<$^O =~ /MSWin/i> is true we know that we're on
> Windows and we set the global variable C<$::_platform_> to C<win32>.
> Otherwise we call C<platform_name> with the output of C<config.guess>
> as argument.

> Note that the new Apple Silicon M1
> architecture is also called `aarch64-apple-darwin`.

Where did you get this piece of information. I don't have the hardware
to be able to try. In MacPorts it's certainly called "arm64". (And
"uname -p" hasn't always been the most reliable piece of information
when Apple was switching architectures; 64-bit capable macs would
often return "i386", for example.)

Also, it will be called universal-darwin in TeX Live, again overruling
the config.guess.

> What is the output of `uname -m` on a Windows ARM machine?

Apart from the fact that I don't have the hardware: how do you even
(somewhat officially) run uname on Windows?
Assuming we are not counting third-party tools which happily report
"x86_64-linux" (WSL) or "x86_64-cygwin" and alike, ...

Also note that we are already using inconsistent names by shipping
x86_64-linux, but amd64-freebsd.

Mojca

From karl at freefriends.org  Thu Dec  3 00:19:14 2020
From: karl at freefriends.org (Karl Berry)
Date: Wed, 2 Dec 2020 16:19:14 -0700
Subject: Naming the ARM(64) binaries for Windows
In-Reply-To: <CALBOmsbEnnM+PcgQHpoH-JM313VCddrj4jST6ePGk1o19mDiRA@mail.gmail.com>
Message-ID: <202012022319.0B2NJEdc031481@freefriends.org>

    Subject: Naming the ARM(64) binaries for Windows

Does Hans have a preference?

In the abstract, I'd prefer aarch64-windows, but if Microsoft only ever
calls it "arm64", arm64-windows seems better to me. For the same reason
that we use amd64-freebsd but x86_64-linux -- that's what the users of
those particular systems are used to, so it seems nicer to follow suit
in TL than enforce a one-size-fits-all regime.

As implied already, Windows (that is, TL's "win32") is not detected by
running uname or config.guess or any such tool, since they don't
generally exist. Instead, we check Perl's builtin $^O variable (as you
can see in various places in TLUtils.pm and throughout the code). This
is one of the significant reasons why supporting two different sets of
Windows binaries in TL would be such a hassle, since presumably that
test would have to be refined. And everywhere that uses the results of
the test would also have to be inspected and possibly adapted. It is
pervasive throughout the entire infrastructure.

Best,
Karl

From richardmoncriefkoch at icloud.com  Thu Dec  3 05:07:34 2020
From: richardmoncriefkoch at icloud.com (Richard Koch)
Date: Wed, 2 Dec 2020 20:07:34 -0800
Subject: Naming the ARM(64) binaries for Windows
Message-ID: <AC10965C-AA2E-48B1-AFD1-AAAC605D5874@icloud.com>

To add one tiny piece of information, on new Apple Silicon hardware,

	uname

returns

	darwin

and

	uname -p 

returns

	arm

and

	uname -m

returns

	arm64

and 

	uname -a

returns

	20.1.0 Darwin Kernel Version 20.1.0: Sat Oct 31 00:07:10 PDT 2020; root:xnu-7195.50.7~2/RELEASE_ARM64_T8101 arm64
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/tex-live/attachments/20201202/052cf2ff/attachment.html>

From norbert at preining.info  Fri Dec  4 00:11:40 2020
From: norbert at preining.info (Norbert Preining)
Date: Fri, 4 Dec 2020 08:11:40 +0900
Subject: Naming the ARM(64) binaries for Windows
In-Reply-To: <AC10965C-AA2E-48B1-AFD1-AAAC605D5874@icloud.com>
References: <AC10965C-AA2E-48B1-AFD1-AAAC605D5874@icloud.com>
Message-ID: <20201203231140.t7lxy5uewaqxcypb@burischnitzel.preining.info>

Hi

so I think with this:

> 	20.1.0 Darwin Kernel Version 20.1.0: Sat Oct 31 00:07:10 PDT 2020; root:xnu-7195.50.7~2/RELEASE_ARM64_T8101 arm64

the suggestion by Karl
	arm64-windows
is a good one.

But that leaves the problems he mentioned still open. I have given it
several times a shot, but it is not trivial, and lots of places.
And not all Windows might be treated the same way, maybe.

I will see at some point whether I can give it another shot ;-)

Best

Norbert

--
PREINING Norbert                              https://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

From henri at henrimenke.de  Thu Dec 10 09:35:43 2020
From: henri at henrimenke.de (Henri Menke)
Date: Thu, 10 Dec 2020 09:35:43 +0100
Subject: Possibly broken mirror
Message-ID: <9779b061b2f94bbc901ce5fce1d89c1616383760.camel@henrimenke.de>

Dear list,

recently I've been experiencing intermittent failures of TeX Live updates.  It's
always the same mirror causing it:

tlmgr: TLPDB::from_file could not initialize from: https://ftp.rrzn.uni-hannover.de/pub/mirror/tex-archive/systems/texlive/tlnet/tlpkg/texlive.tlpdb
tlmgr: Maybe the repository setting should be changed.
tlmgr: More info: https://tug.org/texlive/acquire.html

What's the procedure? Should I contact CTAN?

Kind regards,
Henri


From Herbert.Voss at fu-berlin.de  Thu Dec 10 09:43:23 2020
From: Herbert.Voss at fu-berlin.de (Herbert Voss)
Date: Thu, 10 Dec 2020 09:43:23 +0100
Subject: Possibly broken mirror
In-Reply-To: <9779b061b2f94bbc901ce5fce1d89c1616383760.camel@henrimenke.de>
References: <9779b061b2f94bbc901ce5fce1d89c1616383760.camel@henrimenke.de>
Message-ID: <70fbf3c9-a228-8569-4945-42a1b1b2493e@fu-berlin.de>



Am 10.12.20 um 09:35 schrieb Henri Menke via tex-live:
> recently I've been experiencing intermittent failures of TeX Live updates.  It's
> always the same mirror causing it:
>
> tlmgr: TLPDB::from_file could not initialize from: https://ftp.rrzn.uni-hannover.de/pub/mirror/tex-archive/systems/texlive/tlnet/tlpkg/texlive.tlpdb
> tlmgr: Maybe the repository setting should be changed.
> tlmgr: More info: https://tug.org/texlive/acquire.html

no problem here with for example:

iMac:~ voss$ tlmgr install --reinstall 
--repository=https://ftp.rrzn.uni-hannover.de/pub/mirror/tex-archive/systems/texlive/tlnet 
xetex
tlmgr: package repository 
https://ftp.rrzn.uni-hannover.de/pub/mirror/tex-archive/systems/texlive/tlnet 
(not verified: gpg unavailable)
[1/26, ??:??/??:??] reinstall: atbegshi [409k]
[2/26, 00:01/02:59] reinstall: atveryend [380k]
[...]


Herbert


From henri at henrimenke.de  Thu Dec 10 10:25:37 2020
From: henri at henrimenke.de (Henri Menke)
Date: Thu, 10 Dec 2020 10:25:37 +0100
Subject: Possibly broken mirror
In-Reply-To: <70fbf3c9-a228-8569-4945-42a1b1b2493e@fu-berlin.de>
References: <9779b061b2f94bbc901ce5fce1d89c1616383760.camel@henrimenke.de>
 <70fbf3c9-a228-8569-4945-42a1b1b2493e@fu-berlin.de>
Message-ID: <2f9586efde6f443f7bda561cc9094ab5a8cf2d8e.camel@henrimenke.de>

On Thu, 2020-12-10 at 09:43 +0100, Herbert Voss wrote:
> 
> Am 10.12.20 um 09:35 schrieb Henri Menke via tex-live:
> > recently I've been experiencing intermittent failures of TeX Live
> > updates.  It's
> > always the same mirror causing it:
> > 
> > tlmgr: TLPDB::from_file could not initialize from: 
> > https://ftp.rrzn.uni-hannover.de/pub/mirror/tex-archive/systems/texlive/tlnet/tlpkg/texlive.tlpdb
> > tlmgr: Maybe the repository setting should be changed.
> > tlmgr: More info: https://tug.org/texlive/acquire.html
> 
> no problem here with for example:

Interesting. For me this fails reproducibly. Also I get

   $ tlmgr update --self --all --repository=https://ftp.rrzn.uni-hannover.de/pub/mirror/tex-archive/systems/texlive/tlnet
   /opt/texlive/current/bin/x86_64-linux/tlmgr: TLPDB::from_file could not initialize from: https://ftp.rrzn.uni-hannover.de/pub/mirror/tex-archive/systems/texlive/tlnet/tlpkg/texlive.tlpdb
/opt/texlive/current/bin/x86_64-linux/tlmgr: Maybe the repository setting should be changed.
/opt/texlive/current/bin/x86_64-linux/tlmgr: More info: https://tug.org/texlive/acquire.html
$ curl https://ftp.rrzn.uni-hannover.de/pub/mirror/tex-archive/systems/texlive/tlnet
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
$ openssl s_client -showcerts -connect ftp.rrzn.uni-hannover.de:443
CONNECTED(00000003)
depth=0 C = DE, ST = Niedersachsen, L = Hannover, O = Leibniz Universitaet Hannover, OU = LUIS, CN = ftp.uni-hannover.de
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = DE, ST = Niedersachsen, L = Hannover, O = Leibniz Universitaet Hannover, OU = LUIS, CN = ftp.uni-hannover.de
verify error:num=21:unable to verify the first certificate
verify return:1
   [...]

   So it looks like their SSL configuration is completely broken, which is also
   confirmed by SSL Labs:

   https://www.ssllabs.com/ssltest/analyze.html?d=ftp.rrzn.uni-hannover.de

   Since it works for you I guess Apple puts the intermediate certificates

   DFN-Verein Global Issuing CA
   DFN-Verein Certification Authority 2

   into the system trust store.

   Cheers, Henri

   > 
> iMac:~ voss$ tlmgr install --reinstall 
> --repository=
> https://ftp.rrzn.uni-hannover.de/pub/mirror/tex-archive/systems/texlive/tlnet 
> xetex
> tlmgr: package repository 
> https://ftp.rrzn.uni-hannover.de/pub/mirror/tex-archive/systems/texlive/tlnet 
> (not verified: gpg unavailable)
> [1/26, ??:??/??:??] reinstall: atbegshi [409k]
> [2/26, 00:01/02:59] reinstall: atveryend [380k]
> [...]
> 
> 
> Herbert
> 


From khaliliasbo at yahoo.com  Mon Dec 14 12:06:59 2020
From: khaliliasbo at yahoo.com (Alireza Khalili)
Date: Mon, 14 Dec 2020 11:06:59 +0000 (UTC)
Subject: `beamer.cls'
References: <1417992960.288066.1607944019623.ref@mail.yahoo.com>
Message-ID: <1417992960.288066.1607944019623@mail.yahoo.com>

! LaTeX Error: File `beamer.cls' not found.

Please help me. Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/tex-live/attachments/20201214/358cb945/attachment.html>

From beebe at math.utah.edu  Tue Dec 15 05:50:46 2020
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Mon, 14 Dec 2020 21:50:46 -0700
Subject: [UCE] `beamer.cls'
In-Reply-To: <1417992960.288066.1607944019623@mail.yahoo.com>
Message-ID: <CMM.0.95.0.1608007846.beebe@gamma.math.utah.edu>

Alireza Khalili <khaliliasbo at yahoo.com> reports this error at his
site:

	! LaTeX Error: File `beamer.cls' not found.

Beamer has been around for many years, and should be in every TeX Live
distribution

On my home Ubuntu 20.04 system, I get this report:

	% kpsewhich beamer.cls
	/usr/share/texlive/texmf-dist/tex/latex/beamer/beamer.cls

Did you install a minimal TeX Live, and then perhaps still need to
install the beamer package?  If so, then this should fix your problem:

	% tlmgr update --self
	% tlmgr install beamer

If, on the other hand, you have used some Unix distribution's
installation of TeX, then many of them split up the system into
hundreds of separate packages, and you may have to use the system
package manager (apt-get, dnf, pacman, pkg, pkgutil, slapt-get, yum,
....)  that is appropriate for your system.

On my Ubuntu system, beamer is installed by apt in this location:
	
	/usr/share/texlive/texmf-dist/tex/latex/beamer/beamer.cls

and comes from this package:

	% dpkg -S /usr/share/texlive/texmf-dist/tex/latex/beamer/beamer.cls
	texlive-latex-recommended: /usr/share/texlive/texmf-dist/tex/latex/beamer/beamer.cls

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe at math.utah.edu  -
- 155 S 1400 E RM 233                       beebe at acm.org  beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------

From Alois.Steindl at tuwien.ac.at  Tue Dec 15 10:24:37 2020
From: Alois.Steindl at tuwien.ac.at (Alois Steindl)
Date: Tue, 15 Dec 2020 10:24:37 +0100
Subject: `beamer.cls'
In-Reply-To: <1417992960.288066.1607944019623@mail.yahoo.com>
References: <1417992960.288066.1607944019623.ref@mail.yahoo.com>
 <1417992960.288066.1607944019623@mail.yahoo.com>
Message-ID: <1265b9f4-3fae-0019-0df6-e72fce283bf3@tuwien.ac.at>

Am 14.12.2020 um 12:06 schrieb Alireza Khalili via tex-live:
> ! LaTeX Error: File `beamer.cls' not found.
>
> Please help me. Thanks

Hello,

you either need to install it or help TeXLive to find it.

 From your posting it is hard to guess, how one might be able to help 
you, but search machines like google help a lot. What have you done so 
far to solve your problem?

Good luck

Alois

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/tex-live/attachments/20201215/f570d3fd/attachment.html>

From amaxwell at mac.com  Sat Dec 19 20:21:20 2020
From: amaxwell at mac.com (Adam R. Maxwell)
Date: Sat, 19 Dec 2020 11:21:20 -0800
Subject: tlmgr dump-tlpdb question
Message-ID: <1A15DB53-0313-4651-B76D-81540F9FA1B7@mac.com>

Hi Norbert and Karl,

In the past, I think tlmgr's dump-tlpdb action sent the name of the
mirror to stdout as the first line, and I was using this in TeX Live
Utility. The command looks something like this, although in actual use I
pipe it to my python tlpdb parser:

tlmgr --repository http://ctan.math.utah.edu/ctan/tex-archive/systems/texlive/tlnet --machine-readable dump-tlpdb --remote > /tmp/utah.tlpdb

Looking at my parser code, it seems the first line of output for a
remote mirror used to be

location-url <tab character> http://....

I'll have to keep digging in my code to see if I really needed this, or
if it was just a belt-and-suspenders thing, but it strikes me as
something generally useful if you're using the multiplexor. I see the URL
is now written to stderr, but I prefer not to parse tlmgr's stderr for
pretty obvious reasons :-).

thanks,
Adam



From norbert at preining.info  Sun Dec 20 21:41:05 2020
From: norbert at preining.info (Norbert Preining)
Date: Mon, 21 Dec 2020 05:41:05 +0900
Subject: tlmgr dump-tlpdb question
In-Reply-To: <1A15DB53-0313-4651-B76D-81540F9FA1B7@mac.com>
References: <1A15DB53-0313-4651-B76D-81540F9FA1B7@mac.com>
Message-ID: <X9+24TFNX5mvP+ZO@burischnitzel.preining.info>

Hi Adam,

> In the past, I think tlmgr's dump-tlpdb action sent the name of the
> mirror to stdout as the first line, and I was using this in TeX Live

Hmm, that hasn't changed afair.

> tlmgr --repository http://ctan.math.utah.edu/ctan/tex-archive/systems/texlive/tlnet --machine-readable dump-tlpdb --remote > /tmp/utah.tlpdb


I git blamed tlmgr.pl, and at least for 3 years there haven't been any
changes.

> location-url <tab character> http://....

This still come out, but only when doing --local, not for --remote

> is now written to stderr, but I prefer not to parse tlmgr's stderr for
> pretty obvious reasons :-).

The url is also now written in the above way to stderr when called with
--remote.


Hope that helps and clarifies the case a bit. Again, as far as I
remember there haven't been any changes in this area for quite some
time.

Best

Norbert

--
PREINING Norbert                              https://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

From amaxwell at mac.com  Sun Dec 20 22:00:09 2020
From: amaxwell at mac.com (Adam R. Maxwell)
Date: Sun, 20 Dec 2020 13:00:09 -0800
Subject: tlmgr dump-tlpdb question
In-Reply-To: <X9+24TFNX5mvP+ZO@burischnitzel.preining.info>
References: <1A15DB53-0313-4651-B76D-81540F9FA1B7@mac.com>
 <X9+24TFNX5mvP+ZO@burischnitzel.preining.info>
Message-ID: <B40C47F0-4420-4FD8-B314-3CF70BD08237@mac.com>



> On Dec 20, 2020, at 12:41 , Norbert Preining <norbert at preining.info> wrote:
> 
>> location-url <tab character> http://....
> 
> This still come out, but only when doing --local, not for --remote

Interesting. According to the comments in my code, it's only
for remote, not for local. I certainly could have been wrong
about that, but I'm seeing a log message that I don't recall
seeing in the past. 

Thanks for checking into it.

Adam



From atsol at aegean.gr  Mon Dec 21 10:07:36 2020
From: atsol at aegean.gr (Antonis Tsolomitis)
Date: Mon, 21 Dec 2020 11:07:36 +0200
Subject: about files removal from fontsetup
Message-ID: <df0961a138b29e89cabd639aeff32b36f5b9a24e.camel@aegean.gr>



Dear TL maintainers,

I just realized that although the package I upload to CTAN
contains all the files needed, some of them are removed by
TEXLIVE. These files according to README.TEXLIVE found in

texlive/2020/texmf-dist/doc/latex/fontsetup

are 

	fspcambria.sty
	fsplucidaot.sty
	fspminion.sty
	fspmsgaramondot.sty
and
	fspsample-cambria.pdf
	fspsample-lucida.pdf
	fspsample-minion.pdf
	fspsample-msgaramond.pdf

Can you please explain me the reason? The source of the pdf files
are included in fontsetup as fspsample.tex; one file for all of
them as they are identical except the fonts. The file
fspsample.tex does contain all fontselection lines commented out.

These pdf files do contain commercial fonts embedded. Even if you
do not allow this, I do not understand what is the problem with
the .sty files. These are text files showing how to use commercial
fonts. There is nothing nonfree in the style files. Why are they
removed?

thank you,

Antonis.




From karl at freefriends.org  Mon Dec 21 23:45:31 2020
From: karl at freefriends.org (Karl Berry)
Date: Mon, 21 Dec 2020 15:45:31 -0700
Subject: about files removal from fontsetup
In-Reply-To: <df0961a138b29e89cabd639aeff32b36f5b9a24e.camel@aegean.gr>
Message-ID: <202012212245.0BLMjVdN030096@freefriends.org>

Hi Antonis,

    Why are they removed?

https://tug.org/texlive/pkgcontrib.html#requirements
(item 2).

I added this url to the script that generates the README.TEXLIVE file
for the sake of future queries. Should have done that long ago. --best, karl.

From ud.usenetcorrespondence at web.de  Wed Dec 23 00:42:23 2020
From: ud.usenetcorrespondence at web.de (ud.usenetcorrespondence at web.de)
Date: Wed, 23 Dec 2020 00:42:23 +0100
Subject: Vanilla TeX Live 2020 - install-tl -gui - automatic platform
 detection fails when Live System with i386-linux-binaries is running on an
 x86_64-machine.
Message-ID: <trinity-5230e28e-590a-4271-a32b-95f35221ff76-1608680543656@3c-app-webde-bap16>

Scenario which lead to (now resolved) problems:
-----------------------------------------------

I installed vanilla TeX Live 2020 on a Debian-based System,
Knoppix 8.6.1.

Knoppix 8.6.1 is based on Debian/stable (buster), with some
packages from Debian/testing and unstable (sid) for newer
graphics drivers or desktop software packages.
It uses Linux kernel 5.3.5 and Xorg 7.7 (core 1.20.4).

Knoppix 8.6.1 is intended as a Live-System which can be installed
on DVD/USB-stick/(micro) SD-memory-card.

Therefore i386-binaries are used by this system no matter if the
machine in use is i386 or x86_64.

If you install Knoppix 8.6.1 on a recordable medium, e.g., a
USB-stick or a (micro) SD-memory-card, then you can have a so-
called "overlay-partition" where changes to the system can be
stored.

If you do this, you have the possibility to "remaster" the system,
i.e., to create a variant of the system where all changes are
incorporated.

More information about Knoppix 8.6.1 can be found at
<https://www.knopper.net/knoppix/knoppix861-en.html>

I ran this Live-System on an x86_64-machine.

Thus the command arch yielded: x86_64
while the command dpkg --print-architecture yielded: i386.



The problem which occurred when installing vanilla TeX Live 2020:
-----------------------------------------------------------------

I did my first installing-attempt according to the manual
"TeX Live - Quick install" at
<http://www.tug.org/texlive/quickinstall.html> :

When you run

    sudo install-tl -gui

, then on x86_64-machines installation for x86_64-linux platform
is pre-entered in the "Advanced" settings of the GUI no matter if
Debian-i386-binaries are in use (as was the case with my
scenario).

You can't change this pre-entered setting in the GUI-"Advanced"-
screen but only have i386-linux-binaries installed additionally
to the x86_64-linux-binaries.

With my first installing-attempt I didn't realize this, thus
x86_64-linux binaries were installed on a platform where
i386-linux-binaries were in use otherwise.

As the machine in use was an x86_64-machine pdflatex and
lualatex worked nicely.

But xetex/xelatex did not because it depends on things like
fontconfig / libfontconfig1.

The x86_64-linux xetex-binary could not find the x86_64-variants
of fontconfig / libfontconfig1 as only the i386-variants were
installed on the system in question.

This led to error-messages:

    xetex can't find shared library libfontconfig.so.1
    xelatex can't find shared library libfontconfig.so.1

I was puzzled at first because

    $ sudo apt-get install libfontconfig1

yielded the following message:

    libfontconfig1 is already the latest version (2.13.1-2).


Removing the erroneous x86_64-TeX Live installation and running
the installer with the -force-platform-option, i.e., via the
command

    sudo ./install-tl -gui -force-platform i386-linux

gave me a TeX Live-installation with i386-binaries where
everything works smoothly.



Why I am posting to the TeX Live mailing list:
----------------------------------------------

While I was in the process of getting to the heart of the
problem, I made it a question at TeX-LaTeX-StackExchange.

Subject:
texlive-2020 / xetex can't find shared library libfontconfig.so.1

URL:
<https://tex.stackexchange.com/q/575859>

At TeX-LaTeX-StackExchange I was asked to do the following:

> you could raise this on texlive list see if the
> platform detection can catch this case


Sincerely

Ulrich


From norbert at preining.info  Wed Dec 23 04:47:52 2020
From: norbert at preining.info (Norbert Preining)
Date: Wed, 23 Dec 2020 12:47:52 +0900
Subject: Vanilla TeX Live 2020 - install-tl -gui - automatic platform
 detection fails when Live System with i386-linux-binaries is running on an
 x86_64-machine.
In-Reply-To: <trinity-5230e28e-590a-4271-a32b-95f35221ff76-1608680543656@3c-app-webde-bap16>
References: <trinity-5230e28e-590a-4271-a32b-95f35221ff76-1608680543656@3c-app-webde-bap16>
Message-ID: <X+K96K/Nfa8eBsmF@bulldog.preining.info>

Hi Ulrich,

that is indeed a tricky combination. TeX Live doesn't use dpkg to
determine the architecture but the config.guess tool from the autoconf
family.

The "problem" (not really a problem though) is that Debian has
multi-arch support, so you can run i386 and amd64 binaries side by side.
This is in fact a good thing (at least for those of use running Steam and
Wine ;-) but in this case it creates complication, because the *natural*
architecture is not used but one that is also supported.

I don't see any easy way to catch these things, but one thing comes to
my mind: we *could* check what kind of binary the Perl interpreter that
runs the installer actually is with
	use Config;
	if ($Config{longsize} == 4) {
	  # this is a 32bit perl that might run on 64bit arch
	} elsif ($Config{longsize} == 8) {
	  # this is a 64bit perl (and thus on 64bit arch)
	} else {
	  # give me a break
	}
By this we **could** override the detection of the hardware architecture
with the actual OS type running.

This is NOT perfect, becasue one **could** in principle on Debian amd64
system install a 32bit perl .... but well, those who do this are on
their own ;-)

>     xetex can't find shared library libfontconfig.so.1
>     xelatex can't find shared library libfontconfig.so.1
> 
> I was puzzled at first because
> 
>     $ sudo apt-get install libfontconfig1
> 
> yielded the following message:
> 
>     libfontconfig1 is already the latest version (2.13.1-2).

Despite all the above, you could simply add amd64 as architecture to
Debian, and then install libfontconfig1:amd64
	dpkg --add-architecture amd64
	apt-get update
	apt-get install libfontconfig1:amd64

All the best

Norbert

--
PREINING Norbert                              https://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

From ud.usenetcorrespondence at web.de  Wed Dec 23 12:04:08 2020
From: ud.usenetcorrespondence at web.de (ud.usenetcorrespondence at web.de)
Date: Wed, 23 Dec 2020 12:04:08 +0100
Subject: Aw: Re: Vanilla TeX Live 2020 - install-tl -gui - automatic
 platform detection fails when Live System with i386-linux-binaries is
 running on an x86_64-machine.
In-Reply-To: <X+K96K/Nfa8eBsmF@bulldog.preining.info>
References: <trinity-5230e28e-590a-4271-a32b-95f35221ff76-1608680543656@3c-app-webde-bap16>
 <X+K96K/Nfa8eBsmF@bulldog.preining.info>
Message-ID: <trinity-cdb86838-f7bb-49e3-8b6b-1f2f326841c6-1608721448320@3c-app-webde-bap02>

Hello Norbert,

thank you for your quick reply.
?
> The "problem" (not really a problem though) 

Indeed. ;-)

> This is NOT perfect, becasue one **could** in principle on Debian amd64
> system install a 32bit perl .... but well, those who do this are on
> their own ;-)

Probably it is sufficient to mention in the short installation-tutorials/
manuals that there are edge cases/scenarios where you are on your own
with making sure that binaries for the correct platform are installed
by applying the -force-platform-option.  ;-)

> Despite all the above, you could simply add amd64 as architecture to
> Debian, and then install libfontconfig1:amd64

You are right - as long as you focus only on the x86_64-machine which 
was in use by me the day when my installing-attempts took place.

The scenario described by me focuses on a Live System runable from
USB-Stick/(micro) SD-card/DVD (after remastering) which is intended
to work both on i386-platforms and on x86_64-platforms.

Installing TeX Live x86_64-linux binaries and making xetex work by
additionally installing libfontconfig1:amd64 would lead to TeX Live
components working only when the Live System in question is run on a
x86_64-machine. I suppose things would be broken when running the
Live System in question on i386-machines.


Sincerely

Ulrich


From by at tongji.edu.cn  Fri Dec 25 12:28:55 2020
From: by at tongji.edu.cn (by at tongji.edu.cn)
Date: Fri, 25 Dec 2020 19:28:55 +0800 (GMT+08:00)
Subject: A bug report about the LaTeX package - exercise
Message-ID: <7c4fd57c.6391.17699a8a86f.Coremail.by@tongji.edu.cn>

Good evening, Sir/Madam:

I download the most recent Texlive 2020 distribution and find a problem when I am using the package - exercise to typeset one book I am working on.  The following is description of the problem that was met.

For the following LaTeX codes,

------------------------
\documentclass{book}
\usepackage{exercise}
\begin{document}
\tableofcontents
\listofexercises
\begin{Exercise}
This is an exercise.
\end{Exercise}
\shipoutExercise
\end{document}
------------------------

It is noticed that an invalid letter `t' will appear in each entry of the list of exercises typesetted through the macro - `\listofexercises'.  After examining the file - `exercise.sty' provided by the LaTeX exercise package, I think it is due to the codes in the line of 371.  The original code is `\theExercise\ \expandafter{\itshape \ExerciseTitle}\hspace{.66em}}'.  However this will cause things like `...\fontshape it...' to enter the corresponding loe file finally.  The correct way to specify an italic font shape is something like `\fontshape{it}', `\fontshape\itdefault', but not `\fontshape it'.  Typesetting `\fontshape it' will cause two problems.  First LaTex will report that it can not find the font shape specified by the letter `i'.  Second the letter `t' will sneak into the final file typesetted.  There are many ways to solve it.  The one I adopt is to change the original code - `... \expandafter{\itshape...' to `...\expandafter{\noexpand\itshape...' to prohibit the expansion of the macro - `\itshape' when the corresponding contents are written to the loe file.  Lastly, as a reminder, a similar situation is also found in the line 392 of `exercise.sty'.

That is all.  Thanks.

Sincerely,
Bin Yu


From enrico.gregorio at gmail.com  Fri Dec 25 16:12:44 2020
From: enrico.gregorio at gmail.com (Enrico Gregorio)
Date: Fri, 25 Dec 2020 16:12:44 +0100
Subject: A bug report about the LaTeX package - exercise
In-Reply-To: <7c4fd57c.6391.17699a8a86f.Coremail.by@tongji.edu.cn>
References: <7c4fd57c.6391.17699a8a86f.Coremail.by@tongji.edu.cn>
Message-ID: <78B8EDC2-7291-4622-842F-EC7607163463@gmail.com>



> On 25 Dec 2020, at 12:28 , by--- via tex-live <tex-live at tug.org> wrote:
> 
> Good evening, Sir/Madam:
> 
> I download the most recent Texlive 2020 distribution and find a problem when I am using the package - exercise to typeset one book I am working on.  The following is description of the problem that was met.
> 
> For the following LaTeX codes,
> 
> ------------------------
> \documentclass{book}
> \usepackage{exercise}
> \begin{document}
> \tableofcontents
> \listofexercises
> \begin{Exercise}
> This is an exercise.
> \end{Exercise}
> \shipoutExercise
> \end{document}
> ????????????

This is not the right place to report bugs in packages.

Anyway, a solution can be found at

https://tex.stackexchange.com/q/544940/4427

Ciao
Enrico



From veropgr at yahoo.gr  Sun Dec 27 22:52:04 2020
From: veropgr at yahoo.gr (=?UTF-8?B?zrPOtc+Oz4HOs865zr/PgiDOss61z4HPjM+Azr/Phc67zr/Pgg==?=)
Date: Sun, 27 Dec 2020 21:52:04 +0000 (UTC)
Subject: feynman tex package
References: <225630193.7421601.1609105924002.ref@mail.yahoo.com>
Message-ID: <225630193.7421601.1609105924002@mail.yahoo.com>

Hi? i m looking for a package?? for? feynman graph 


thank? you 

George? P. Veropoulos
MSc, PhD 
???????? ??. ?????????????????? ??????? ?????
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/tex-live/attachments/20201227/fb74564a/attachment.html>

From khzimmer at posteo.de  Sun Dec 27 23:58:06 2020
From: khzimmer at posteo.de (khzimmer at posteo.de)
Date: Sun, 27 Dec 2020 23:58:06 +0100
Subject: feynman tex package
In-Reply-To: <225630193.7421601.1609105924002@mail.yahoo.com>
References: <225630193.7421601.1609105924002.ref@mail.yahoo.com>
 <225630193.7421601.1609105924002@mail.yahoo.com>
Message-ID: <1bea4d1a52c4123ed7e8721263907ca6@posteo.de>

Hi, please have a look at this page:

https://de.overleaf.com/learn/latex/feynman_diagrams

Cheers
Karl-Heinz

Am 27.12.2020 22:52 schrieb ???????? ?????????? via tex-live:
> Hi i m looking for a package for feynman graph
> 
> thank you
> 
> GEORGE  P. VEROPOULOS
> 
> MSC, PHD
> 
> ???????? ?. ??????????
> ???????? ??????? ????


From manfred at dante.de  Mon Dec 28 05:06:55 2020
From: manfred at dante.de (Manfred Lotz)
Date: Mon, 28 Dec 2020 05:06:55 +0100
Subject: feynman tex package
In-Reply-To: <225630193.7421601.1609105924002@mail.yahoo.com>
References: <225630193.7421601.1609105924002.ref@mail.yahoo.com>
 <225630193.7421601.1609105924002@mail.yahoo.com>
Message-ID: <20201228050655.53c07fc7@hogwart>

On Sun, 27 Dec 2020 21:52:04 +0000 (UTC)
???????? ?????????? via tex-live <tex-live at tug.org> wrote:

> Hi? i m looking for a package?? for? feynman graph 
> 
> 
> thank? you 
> 
> George? P. Veropoulos
> MSc, PhD 
> ???????? ??. ?????????????????? ??????? ?????

https://ctan.org/search?phrase=feynman

-- 
Manfred


From veropgr at yahoo.gr  Mon Dec 28 09:14:02 2020
From: veropgr at yahoo.gr (=?UTF-8?B?zrPOtc+Oz4HOs865zr/PgiDOss61z4HPjM+Azr/Phc67zr/Pgg==?=)
Date: Mon, 28 Dec 2020 08:14:02 +0000 (UTC)
Subject: live tex 2020 porblem
References: <269678598.7494642.1609143242295.ref@mail.yahoo.com>
Message-ID: <269678598.7494642.1609143242295@mail.yahoo.com>

Hii have installed in my? the Texlive 2020? but after months? stop? to working
i re installed??? and when? i trying to open a tex file? the program not open
what happen?thank you

George? P. Veropoulos
MSc, PhD 
???????? ??. ?????????????????? ??????? ?????
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/tex-live/attachments/20201228/bce3d095/attachment.html>

From P.Taylor at Hellenic-Institute.Uk  Mon Dec 28 11:09:15 2020
From: P.Taylor at Hellenic-Institute.Uk (Philip Taylor)
Date: Mon, 28 Dec 2020 10:09:15 +0000
Subject: live tex 2020 porblem
In-Reply-To: <269678598.7494642.1609143242295@mail.yahoo.com>
References: <269678598.7494642.1609143242295.ref@mail.yahoo.com>
 <269678598.7494642.1609143242295@mail.yahoo.com>
Message-ID: <897b0d73-a79b-0cf0-7088-81b219c03ffe@Hellenic-Institute.Uk>

???????? ?????????? via tex-live wrote:

> Hi
> i have installed in my? the Texlive 2020? but after months? stop? to 
> working
>
> i re installed??? and when i trying to open a tex file? the program 
> not open
>
> what happen?

I think we need rather more information, ??????? ? what operating 
system, for a start, and what program do you /expect /to open when you 
try to open a TeX file ?? The latter will almost certainly not be TeX 
itself, but more likely a dedicated TeX editor such as TeXworks.
/Philip Taylor/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/tex-live/attachments/20201228/0517d1e3/attachment.html>

From Alois.Steindl at tuwien.ac.at  Mon Dec 28 14:10:56 2020
From: Alois.Steindl at tuwien.ac.at (Alois Steindl)
Date: Mon, 28 Dec 2020 14:10:56 +0100
Subject: AW: live tex 2020 porblem
Message-ID: <ifhh8puq5epai3ohqm6m4u9f.1609160400577@email.lge.com>

Hello,with this error description nobody will be able to help you.I guess, you have already taken notice of?https://www.tug.org/begin.html#helpIn order to increase your chance for help you should tellYour systemHow do you try to open the file?What exactly happens?Good luck!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/tex-live/attachments/20201228/b7f104b3/attachment.html>

From veropgr at yahoo.gr  Tue Dec 29 15:48:39 2020
From: veropgr at yahoo.gr (=?UTF-8?B?zrPOtc+Oz4HOs865zr/PgiDOss61z4HPjM+Azr/Phc67zr/Pgg==?=)
Date: Tue, 29 Dec 2020 14:48:39 +0000 (UTC)
Subject: table of coentens , feynmam gra[h
References: <45577698.8204698.1609253319083.ref@mail.yahoo.com>
Message-ID: <45577698.8204698.1609253319083@mail.yahoo.com>

Hi i hava a tex? document(in greek language) in? live tex? and i use the \tableofcontentsbut in? pdf? file? dont? create? the? table of on contens 
also? i have?? some? feynamm diagram?? but the live tex dont support this

thank yoy in advance? 



George? P. Veropoulos
MSc, PhD 
???????? ??. ?????????????????? ??????? ?????
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/tex-live/attachments/20201229/68c639bb/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MASTER_NEW.tex
Type: application/octet-stream
Size: 80296 bytes
Desc: not available
URL: <https://tug.org/pipermail/tex-live/attachments/20201229/68c639bb/attachment-0001.obj>

From P.Taylor at Hellenic-Institute.Uk  Tue Dec 29 16:56:13 2020
From: P.Taylor at Hellenic-Institute.Uk (Philip Taylor)
Date: Tue, 29 Dec 2020 15:56:13 +0000
Subject: table of coentens , feynmam gra[h
In-Reply-To: <45577698.8204698.1609253319083@mail.yahoo.com>
References: <45577698.8204698.1609253319083.ref@mail.yahoo.com>
 <45577698.8204698.1609253319083@mail.yahoo.com>
Message-ID: <2129c60e-55aa-9c68-e40f-166dea20a807@Hellenic-Institute.Uk>

Hallo ??????? ?

> Hi i hava a tex document(in greek language) in? live tex? and i use 
> the \tableofcontents
> but in? pdf? file dont? create? the? table of on contens
> also? i have?? some feynamm diagram?? but the live tex dont support this

In the absence of the file "Feynman.tex", I cannot test thoroughly, but 
lacking that file and telling XeLaTeX to proceed without it (<enter>, 
followed by "S" for 'scroll'), I appear to get a ToC ("???????????")? on 
page~3 (see attached).? Of course, this requires two runs of XeLaTeX, 
not just one.

Philip Taylor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/tex-live/attachments/20201229/bf4034cf/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Fullscreen capture 29122020 155413.jpg
Type: image/jpeg
Size: 247062 bytes
Desc: not available
URL: <https://tug.org/pipermail/tex-live/attachments/20201229/bf4034cf/attachment-0001.jpg>

From veropgr at yahoo.gr  Wed Dec 30 14:27:12 2020
From: veropgr at yahoo.gr (=?UTF-8?B?zrPOtc+Oz4HOs865zr/PgiDOss61z4HPjM+Azr/Phc67zr/Pgg==?=)
Date: Wed, 30 Dec 2020 13:27:12 +0000 (UTC)
Subject: change the appenics name
References: <861242064.8632500.1609334832944.ref@mail.yahoo.com>
Message-ID: <861242064.8632500.1609334832944@mail.yahoo.com>

Hi? i use? the??? statement? \begin{appendix}? \end{appendix}?? with? xgreek support package? and the? output is? 

?????????? ?'?? the? A? is? woth? '?? i can? delete this? 







thank you? in advance

George? P. Veropoulos
MSc, PhD 
???????? ??. ?????????????????? ??????? ?????
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/tex-live/attachments/20201230/f2cb2ff1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1609334819341blob.jpg
Type: image/png
Size: 73475 bytes
Desc: not available
URL: <https://tug.org/pipermail/tex-live/attachments/20201230/f2cb2ff1/attachment-0001.png>