gzip eps

[Patrick Dupre]

Hello,

I am attaching an eps file
(NoDressedrecoil.eps)
You could do
cp -a NoDressedrecoil.eps No_Dressedrecoil.eps
cp -a NoDressedrecoil.eps No_Dressed_recoil.eps

and then
gzip -f No_Dressedrecoil.eps
gzip -f No_Dressed_recoil.eps

And you should obtain a different behavior
like

Traceback (most recent call last):
  File "/usr/share/lyx/scripts/convertDefault.py", line 68, in <module>
    if sys.argv[3] == 'ppm' and (im and version >= 0x060305 or gm):
                                        ^^^^^^^^^^^^^^^^^^^
TypeError: '>=' not supported between instances of 'str' and
'int'

This seems only due to the name No_Dressed_recoil.eps

Thank for your concerns


===========================================================================
 Patrick DUPRÉ                                 | | email: pdupre(a)gmx.com
===========================================================================

[Roger Heflin]

On Mon, Jan 15, 2024 at 9:24 AM Patrick Dupre via users
<users(a)lists.fedoraproject.org&gt; wrote:
>  Hello,
>
>  I am attaching an eps file
>  (NoDressedrecoil.eps)
>  You could do
>  cp -a NoDressedrecoil.eps No_Dressedrecoil.eps
>  cp -a NoDressedrecoil.eps No_Dressed_recoil.eps
>
>  and then
>  gzip -f No_Dressedrecoil.eps
>  gzip -f No_Dressed_recoil.eps
>
>  And you should obtain a different behavior
>  like
>
>  Traceback (most recent call last):
>    File "/usr/share/lyx/scripts/convertDefault.py", line 68, in <module>
>      if sys.argv[3] == 'ppm' and (im and version >= 0x060305 or gm):
>                                          ^^^^^^^^^^^^^^^^^^^
>  TypeError: '>=' not supported between instances of 'str' and
> 'int'
>
>  This seems only due to the name No_Dressed_recoil.eps
>
>  Thank for your concerns
>  
gzip is a  compiled executable, and if the real gzip was run you
should not be able to get a traceback like that.

To get a trackback like that either you aren't running the right gzip
("which gzip" should point to /usr/bin/gzip) or you have bad shell
code running (from some other package?) that is intercepting and
producing the error.

Your gzip is probably not /usr/bin/gzip.

see what the below shows.

which gzip ; file /usr/bin/gzip ; ldd /usr/bin/gzip
/usr/bin/gzip
/usr/bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1
(SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2,
BuildID[sha1]=122aaface4722838f70907f0cea3dee4b958dde2, for GNU/Linux
3.2.0, stripped
linux-vdso.so.1 (0x00007ffc2a318000)
libc.so.6 => /lib64/libc.so.6 (0x00007fbfdf254000)
/lib64/ld-linux-x86-64.so.2 (0x00007fbfdf539000)

[Patrick Dupre]

I am sorry, but today, I cannot reproduce the bug !

I made a dnf update yesterday night (as I do every days).

Is there a link?

> On Mon, Jan 15, 2024 at 9:24 AM Patrick Dupre via users
> <users(a)lists.fedoraproject.org&gt; wrote:
> >
> > Hello,
> >
> > I am attaching an eps file
> > (NoDressedrecoil.eps)
> > You could do
> > cp -a NoDressedrecoil.eps No_Dressedrecoil.eps
> > cp -a NoDressedrecoil.eps No_Dressed_recoil.eps
> >
> > and then
> > gzip -f No_Dressedrecoil.eps
> > gzip -f No_Dressed_recoil.eps
> >
> > And you should obtain a different behavior
> > like
> >
> > Traceback (most recent call last):
> >   File "/usr/share/lyx/scripts/convertDefault.py", line 68, in
<module>
> >     if sys.argv[3] == 'ppm' and (im and version >= 0x060305 or gm):
> >                                         ^^^^^^^^^^^^^^^^^^^
> > TypeError: '>=' not supported between instances of 'str' and
'int'
> >
> > This seems only due to the name No_Dressed_recoil.eps
> >
> > Thank for your concerns
> >
> gzip is a  compiled executable, and if the real gzip was run you
> should not be able to get a traceback like that.
> 
> To get a trackback like that either you aren't running the right gzip
> ("which gzip" should point to /usr/bin/gzip) or you have bad shell
> code running (from some other package?) that is intercepting and
> producing the error.
> 
> Your gzip is probably not /usr/bin/gzip.
> 
> see what the below shows.
> 
> which gzip ; file /usr/bin/gzip ; ldd /usr/bin/gzip
> /usr/bin/gzip
> /usr/bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1
> (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2,
> BuildID[sha1]=122aaface4722838f70907f0cea3dee4b958dde2, for GNU/Linux
> 3.2.0, stripped
> linux-vdso.so.1 (0x00007ffc2a318000)
> libc.so.6 => /lib64/libc.so.6 (0x00007fbfdf254000)
> /lib64/ld-linux-x86-64.so.2 (0x00007fbfdf539000)
>

[Patrick O'Callaghan]

On Mon, 2024-01-15 at 16:24 +0100, Patrick Dupre via users wrote:
>  Hello,
>  
>  I am attaching an eps file 
No, you didn't.

poc

[Barry]

>  On 15 Jan 2024, at 15:24, Patrick Dupre via users
> <users(a)lists.fedoraproject.org&gt; wrote:
>  
>  Traceback (most recent call last):
>   File "/usr/share/lyx/scripts/convertDefault.py", line 68, in <module>
>     if sys.argv[3] == 'ppm' and (im and version >= 0x060305 or gm):
>                                         ^^^^^^^^^^^^^^^^^^^
>  TypeError: '>=' not supported between instances of 'str' and
> 'int' 
That is bad python code. Version is a string and cannot be compare against 0x060305.
Suggest you report against the RPM package that /usr/share/lyx/scripts/convertDefault.py
comes from.

Barry

[Todd Zullinger]

Barry wrote:
> > On 15 Jan 2024, at 15:24, Patrick Dupre via users
> <users(a)lists.fedoraproject.org&gt; wrote:
> > 
> > Traceback (most recent call last):
> >  File "/usr/share/lyx/scripts/convertDefault.py", line 68, in
> <module>
> >    if sys.argv[3] == 'ppm' and (im and version >= 0x060305 or gm):
> >                                        ^^^^^^^^^^^^^^^^^^^
> > TypeError: '>=' not supported between instances of 'str' and
> 'int'
>  
>  That is bad python code. Version is a string and cannot be compare against 0x060305.
>  Suggest you report against the RPM package that /usr/share/lyx/scripts/convertDefault.py
> comes from. 
Upstream says it's fixed in 2.4.0:

    https://www.lyx.org/trac/ticket/12763

Though I think this is tangential to the real issue, which
Roger's reply detailed.

-- 
Todd

[Todd Zullinger]

I wrote:
>  Barry wrote:
> >> On 15 Jan 2024, at 15:24, Patrick Dupre via users
> <users(a)lists.fedoraproject.org&gt; wrote:
> >> 
> >> Traceback (most recent call last):
> >>  File "/usr/share/lyx/scripts/convertDefault.py", line 68, in
> <module>
> >>    if sys.argv[3] == 'ppm' and (im and version >= 0x060305 or gm):
> >>                                        ^^^^^^^^^^^^^^^^^^^
> >> TypeError: '>=' not supported between instances of 'str' and
> 'int'
> > 
> > That is bad python code. Version is a string and cannot be compare against 0x060305.
> > Suggest you report against the RPM package that
> /usr/share/lyx/scripts/convertDefault.py comes from.
>  
>  Upstream says it's fixed in 2.4.0:
>  
>      https://www.lyx.org/trac/ticket/12763 
The fix looks to be 639b5da1af (Fix the remaing issues with
comparisons with objects of different types., 2019-06-03)¹.
This could be trivially cherry-picked to the 2.3.x branch.

¹ https://www.lyx.org/trac/changeset/639b5da1af/lyxgit

-- 
Todd

[Barry]

>  On 15 Jan 2024, at 23:56, Todd Zullinger <tmz(a)pobox.com&gt;
> wrote:
>  
>  The fix looks to be 639b5da1af (Fix the remaing issues with
>  comparisons with objects of different types., 2019-06-03)¹.
>  This could be trivially cherry-picked to the 2.3.x branch.
>  
>  ¹ https://www.lyx.org/trac/changeset/639b5da1af/lyxgit
>   
Worth putting in a bug report to get it fixed.

Barry

[José Matos]

On Mon, 2024-01-15 at 23:15 +0000, Barry wrote:
>  That is bad python code. Version is a string and cannot be compare
>  against 0x060305.
>  Suggest you report against the RPM package that
>  /usr/share/lyx/scripts/convertDefault.py comes from.
>  
>  Barry 
That is a leftover from Python 2. In Python 2 it was possible to
compare different types although the result only depended on the types
and not of the values:

https://portingguide.readthedocs.io/en/latest/comparisons.html

Incidentally that is also the reason when comparing a value with None
should be done using the "is" operator and not "==" since None is a
singleton and of a different type.

-- 
José Abílio

[José Matos]

On Mon, 2024-01-15 at 16:24 +0100, Patrick Dupre via users wrote:
>  Hello,
>  
>  Traceback (most recent call last):
>    File "/usr/share/lyx/scripts/convertDefault.py", line 68, in
>  <module>
>      if sys.argv[3] == 'ppm' and (im and version >= 0x060305 or gm):
>                                          ^^^^^^^^^^^^^^^^^^^
>  TypeError: '>=' not supported between instances of 'str' and
> 'int'
>  
>  This seems only due to the name No_Dressed_recoil.eps
>  
>  Thank for your concerns
>  
>  =====================================================================
>  ======
>   Patrick DUPRÉ                                 | | email:
>  pdupre(a)gmx.com
>  =====================================================================
>  ====== 
This particular bug is already fixed in LyX 2.4, as detailed in this
thread.

For what is worth LyX 2.4 is entering the release candidate stage.
RC1 has been released yesterday.

You can tests it from copr:
https://copr.fedorainfracloud.org/coprs/jamatos/lyx-devel

The version there is called lyx-devel and so it can be parallel
installable with 2.3 LyX.

One other major difference in that version is that it is built with
qt6.

Notice that I am using this as a testing stage so that when LyX 2.4 is
released all these changes will become the Fedora lyx package.

Regards,
-- 
José Abílio

[Patrick Dupre]

Hello,

I am really confused.
Why, when a called gzip, lyx was involved
while I use /usr/bin/gzip ?
Is it because a lyx window was loaded?
Or because the eps.gz file was called by the lyx application?

It does not make sense to me.

>
> On Mon, 2024-01-15 at 16:24 +0100, Patrick Dupre via users wrote:
> > Hello,
> > 
> > Traceback (most recent call last):
> >   File "/usr/share/lyx/scripts/convertDefault.py", line 68, in
> > <module>
> >     if sys.argv[3] == 'ppm' and (im and version >= 0x060305 or gm):
> >                                         ^^^^^^^^^^^^^^^^^^^
> > TypeError: '>=' not supported between instances of 'str' and
'int'
> > 
> > This seems only due to the name No_Dressed_recoil.eps
> > 
> > Thank for your concerns
> > 
> > =====================================================================
> > ======
> >  Patrick DUPRÉ                                 | | email:
> > pdupre(a)gmx.com
> > =====================================================================
> > ======
> 
> This particular bug is already fixed in LyX 2.4, as detailed in this
> thread.
> 
> For what is worth LyX 2.4 is entering the release candidate stage.
> RC1 has been released yesterday.
> 
> You can tests it from copr:
> https://copr.fedorainfracloud.org/coprs/jamatos/lyx-devel
> 
> The version there is called lyx-devel and so it can be parallel
> installable with 2.3 LyX.
> 
> One other major difference in that version is that it is built with
> qt6.
> 
> Notice that I am using this as a testing stage so that when LyX 2.4 is
> released all these changes will become the Fedora lyx package.
> 
> Regards,
> -- 
> José Abílio
> --
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
>

[José Matos]

On Tue, 2024-01-16 at 12:16 +0100, Patrick Dupre via users wrote:
>  Hello,
>  
>  I am really confused.
>  Why, when a called gzip, lyx was involved
>  while I use /usr/bin/gzip ?
>  Is it because a lyx window was loaded?
>  Or because the eps.gz file was called by the lyx application?
>  
>  It does not make sense to me. 
This is an explanation as far as I remember. Th code where the error
message occurs is used to preview the file.

That code tries several different paths in order to display the file.
So even if one path fails it will try other routes to get the file
displayed.

What could be happening in this case is that, due to the way as the
converter code works, the compressed and uncompressed files use
different paths to be displayed. So in one case the you get the error
while in the other than is never run.

Well, after 2.4 is released I intend to have a look into that part of
the code. :-)

-- 
José Abílio