Fwd: String/Bytes Problem in layout2layout.py
Jose,
are the proposed changes sensible?
I remember there were flowing similar patches to python codebase before.
Pavel
- Forwarded message from "Leo L. Schwab" -
From: "Leo L. Schwab"
To: Debian Bug Tracking System
Subject: Bug#1002821: lyx-common: String/Bytes Problem in layout2layout.py
Package: lyx-common
Version: 2.3.6-1
Severity: normal
Tags: patch upstream
X-Debbugs-Cc: ew...@ewhac.org
Dear Maintainer,
Discovered this while trying to use Editorium's LyXBook modules.
layout2layout.py was konking out with "TypeError: cannot use a bytes
pattern on a string-like object." After a bunch of debugging, I found
some strings in the script that hadn't been bytes-ified, which seemed to
fix the problem. Patch attached.
Schwab
-- System Information:
Debian Release: bookworm/sid
APT prefers testing-security
APT policy: (500, 'testing-security'), (500, 'unstable'), (500, 'testing'),
(500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.15.0-2-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages lyx-common depends on:
ii python3 3.9.8-1
ii tex-common 6.17
Versions of packages lyx-common recommends:
ii lyx 2.3.6-1
lyx-common suggests no packages.
-- no debconf information
--- /usr/share/lyx/scripts/layout2layout.py 2020-12-01 02:33:35.0
-0800
+++ ./layout2layout.py 2021-12-29 01:04:59.614016427 -0800
@@ -484,8 +484,8 @@
i += 1
continue
col = match.group(2)
-if col == "collapsable":
-lines[i] = match.group(1) + "collapsible"
+if col == b"collapsable":
+lines[i] = match.group(1) + b"collapsible"
i += 1
continue
@@ -703,7 +703,7 @@
# Insert the required number of arguments at the end of the style
definition
match = re_End.match(lines[i])
if match:
-newarg = ['']
+newarg = [b'']
# First the optionals (this is the required order pre 2.1)
if opts > 0:
if opts == 1:
@@ -1153,7 +1153,7 @@
if latextype == b"item_environment" and label.lower() ==
b"counter_enumi":
lines[labeltype_line] =
re_LabelType.sub(b'\\1\\2\\3Enumerate', lines[labeltype_line])
# Don't add the LabelCounter line later
-counter = ""
+counter = b""
# Replace
#
@@ -1227,12 +1227,12 @@
if options.input_file:
source = open(options.input_file, 'rb')
else:
-source = sys.stdin
+source = sys.stdin.buffer
if options.output_file:
output = open(options.output_file, 'wb')
else:
-output = sys.stdout
+output = sys.stdout.buffer
if options.format > currentFormat:
error("Format %i does not exist" % options.format);
- End forwarded message -
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: configure.py assumes "python" command exists
Am 27.12.2021 um 20:30 schrieb José Abílio Matos :
>
> On Saturday, 25 December 2021 18.32.21 WET Scott Kostyshak wrote:
> > On Sun, Oct 31, 2021 at 12:58:19PM -0400, Scott Kostyshak wrote:
>
> Hi Scott,
> I find you choice of dates very convenient. :-)
>
> https://journeys.dartmouth.edu/folklorearchive/2016/11/12/halloween-and-christmas/
>
> “Why do programmers always mix up Halloween and Christmas?”
> “Because Oct 31 = Dec 25.”
>
> > Bump.
> >
> > Scott
>
> Regarding the problem at hand, as an example, my suggestion is to change:
>
> \converter pdf4 pdf8 "python $$s/scripts/convert_pdf.py $$i $$o ebook"
>
> to
>
> \converter pdf4 pdf8 "$${python} $$s/scripts/convert_pdf.py $$i $$o ebook"
>
> The idea is to use the converter code, e.g. the $$i $$o ..., and add there
> the substitution from $${python} to the python path that we have already
> determined in os::find_python.
I like your proposal.
Regarding the use of python calls in configure.py I’ve stolen your idea to use
sys.executable and made a patch.
This avoids the warning '„LyX“ needs to be updated‘ (see my RFC mail thread)
and lyx starts as usual if I install python3 at first
(https://www.python.org/downloads/release/python-3101)
Stephan
python-in-configure.patch
Description: Binary data
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: fsanitize: member access within null pointer
Am Mon, 27 Dec 2021 09:48:38 -0500 schrieb Scott Kostyshak : > > Maybe some native English speaker would fit here better. > > A comment in LyX's code? Something just like the following? > > // Using Clang and fsanitize suggests there is an issue here but we do > // not understand the code enough to change it and we are not aware of > // how to trigger a crash or other issue while using LyX, so we leave > // it as is. For ML discussion, see here: > // > https://www.mail-archive.com/search?l=mid=20211227113249.53bf5a63%40admin1-desktop > > Scott +1 from my side. Commit please if Pavel has no objections. Kornel pgpuUNFsYlANn.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC] Python related system prompt "Lyx must be updated" on macOS
Am 28.12.2021 um 13:55 schrieb José Abílio Matos : > > On Tuesday, 28 December 2021 12.33.57 WET Stephan Witt wrote: > > The LyX tasks here are IMO: > > 1. Assure the detected python3 is used consequently. This is not the case > > ATM. > > 2. Document the meaning of the prompts the LyX user is seeing on > > Monterey. > > 3. Provide a working python3 or give appropriate feedback on > > first start about users option to install python3. > > > > AFAIK, José Abílio is working on a solution for 1. I’m able to help with the > > Mac part of the problem. > > I am not working on 1, the issue that I am working is a bit different, > although related. I referred to your proposal to consequently use the detected python version in our scripts. ATM on Mac with python3 installed there are hardcoded calls of python e.g. in configure.py or - as you’ve pointed out - in the generated converter calls triggering the warning „LyX“ needs to be updated we want to avoid. > In the case of mac we can > What I suggest is to use by default the latest python version available in > the system. That’s part of the problem. „Virgin“ systems have python 2 only. > As it is now we search for a python version and stick with it. > What I propose is to test the different versions available and pick the > latest. > > Python 3 has been tested extensively and so it is ready to be the default > option. Yes, I agree. > > Regarding the point 3 - Apples recommendation to bundle python with LyX > > (49764202) - I’m not sure if this is a real option. The Windows package > > contains python, IMO. So it is possible. But is it clever? I don’t like the > > solution to point the user to homebrew or macports to install python. Too > > much terminal work, IMO. > > > > What do others think about the situation? > > How do you deal with the latex installation in mac? LyX starts fine w/o it and the user has to install some TeX distribution to use it. There is a recommended one: MacTeX - having a installable disc image for download on it’s web site. This is easy to use. For Python the situation is a little bit different. The macOS „blames“ LyX at the first configure run if the user didn’t install a recent python 3 already. Either we live with it and document this near the download link at lyx.org or we try to inform the user at LyX startup and give the opportunity to download and install python 3 and refuse to run configure with the system python. This solves the problem we run into if Apple removes python altogether. The homebrew or macports packages are the other option for experienced users. Some of them have an installation on the system already. So we should detect it and be fine with it too. In any case we should ensure the detected usable python is used consequently. Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
