Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #12422 > unrolled thread

[RFC] python-cobra, python3-sbml5

Back to article view | Back to linux.debian.maint.python

Contents

  [RFC] python-cobra, python3-sbml5 Nilesh Patra <npatra974@gmail.com> - 2020-04-04 15:50 +0200
    Re: [RFC] python-cobra, python3-sbml5 Andrey Rahmatullin <wrar@debian.org> - 2020-04-04 17:30 +0200
    Re: [RFC] python-cobra, python3-sbml5 Andreas Tille <andreas@fam-tille.de> - 2020-04-05 08:40 +0200
      Re: [RFC] python-cobra, python3-sbml5 Nilesh Patra <npatra974@gmail.com> - 2020-04-05 12:30 +0200
        Re: [RFC] python-cobra, python3-sbml5 Andreas Tille <andreas@an3as.eu> - 2020-04-05 12:30 +0200
          Re: [RFC] python-cobra, python3-sbml5 Nilesh Patra <npatra974@gmail.com> - 2020-04-05 13:00 +0200

#12422 — [RFC] python-cobra, python3-sbml5

[Multipart message — attachments visible in raw view] — view raw

Hi,
Currently python-cobra FTBFS reported here [1].

>From the logs, in the last message[2] it looks like an import-error for
'_libsbml' file which corresponds to libsbml (with python3-sbml5 as a
provide) package. When I dug into looking at libsbml, I noticed that the
relevant file (libsbml.py) which throws error
is generated with swig-3.0 by the upstream [3]

While the same file in the apt archive (observed after $apt source
python3-sbml5) seems to be generated with swig-4.0, and that's the current
swig version in Debian now.

When I compared, the one generated with swig 4.0 looks pretty different
from the one generated by swig 3.0.
I "suspect" that the error is due to the swig version change to 4.0, and
corresponding API changes.

I would really appreciate if I could have more folks "confirm" that this is
the case, and I'm not missing out on anything else.
I'll then file a report upstream then, asking for corresponding code
changes needed for swig 4.0.

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955656

[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955656#10

[3]:
https://salsa.debian.org/med-team/libsbml/-/blob/master/src/bindings/python/libsbml.py?expanded=true&viewer=simple

Thanks and regards
Nilesh

[toc] | [next] | [standalone]

#12423

[Multipart message — attachments visible in raw view] — view raw

On Sat, Apr 04, 2020 at 06:53:55PM +0530, Nilesh Patra wrote:
> >From the logs, in the last message[2] it looks like an import-error for
> '_libsbml' file which corresponds to libsbml (with python3-sbml5 as a
> provide) package. When I dug into looking at libsbml, I noticed that the
> relevant file (libsbml.py) which throws error
> is generated with swig-3.0 by the upstream [3]
> 
> While the same file in the apt archive (observed after $apt source
> python3-sbml5) seems to be generated with swig-4.0, and that's the current
> swig version in Debian now.
Sorry, I couldn't understand which two files are you comparing. One is
from the python3-sbml5 binary package and is generated with swig 4, where
is the second one, generated by swig 3?

-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]

#12425

Hi Nilesh,

On Sat, Apr 04, 2020 at 06:53:55PM +0530, Nilesh Patra wrote:
> 
> >From the logs, in the last message[2] it looks like an import-error for
> '_libsbml' file which corresponds to libsbml (with python3-sbml5 as a
> provide) package. When I dug into looking at libsbml, I noticed that the
> relevant file (libsbml.py) which throws error
> is generated with swig-3.0 by the upstream [3]

I admit I'm absolutely naive about swig - but if libsbml.py is really
autogenerated what about re-generating it with swig-4?

Kind regards

      Andreas.
 
> [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955656
> 
> [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955656#10
> 
> [3]:
> https://salsa.debian.org/med-team/libsbml/-/blob/master/src/bindings/python/libsbml.py?expanded=true&viewer=simple
> 
> Thanks and regards
> Nilesh

-- 
http://fam-tille.de

[toc] | [prev] | [next] | [standalone]

#12427

[Multipart message — attachments visible in raw view] — view raw

Hi

On Sun, 5 Apr 2020, 11:43 Andreas Tille, <andreas@fam-tille.de> wrote:

> Hi Nilesh,
>
> On Sat, Apr 04, 2020 at 06:53:55PM +0530, Nilesh Patra wrote:
> >
> > >From the logs, in the last message[2] it looks like an import-error for
> > '_libsbml' file which corresponds to libsbml (with python3-sbml5 as a
> > provide) package. When I dug into looking at libsbml, I noticed that the
> > relevant file (libsbml.py) which throws error
> > is generated with swig-3.0 by the upstream [3]
>
> I admit I'm absolutely naive about swig - but if libsbml.py is really
> autogenerated what about re-generating it with swig-4?
>

I think there's a miscommunication here. The file in the archive(on doing
$apt source python3-sbml5) is generated with swig-4 already, while it's
generated with swig-3 upstream.
Hence the issue.


>
> > [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955656
> >
> > [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955656#10
> >
> > [3]:
> >
> https://salsa.debian.org/med-team/libsbml/-/blob/master/src/bindings/python/libsbml.py?expanded=true&viewer=simple
> >
> > Thanks and regards
> > Nilesh
>
> --
> http://fam-tille.de
>

[toc] | [prev] | [next] | [standalone]

#12428

On Sun, Apr 05, 2020 at 03:40:56PM +0530, Nilesh Patra wrote:
> > > '_libsbml' file which corresponds to libsbml (with python3-sbml5 as a
> > > provide) package. When I dug into looking at libsbml, I noticed that the
> > > relevant file (libsbml.py) which throws error
> > > is generated with swig-3.0 by the upstream [3]
> >
> > I admit I'm absolutely naive about swig - but if libsbml.py is really
> > autogenerated what about re-generating it with swig-4?
> 
> I think there's a miscommunication here. The file in the archive(on doing
> $apt source python3-sbml5) is generated with swig-4 already, while it's
> generated with swig-3 upstream.
> Hence the issue.

Ahhh, so it is regenerated in the Debian package build process but it
conflicts with other parts of the upstream code?  Did I now understood
correctly?

I wonder if we should exclude this kind of autogenerated code inside
the source tarball since we are repackaging the source anyway to exclude
some files for policy reasons.  I'm doing so in other source tarballs
for instance with cython files to be absolutely sure that this code
is regenerated.  This would probably not solve the build issue but might
be a good idea in general.  What do you think?

Kind regards

      Andreas.
 
> > > [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955656
> > >
> > > [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955656#10
> > >
> > > [3]: https://salsa.debian.org/med-team/libsbml/-/blob/master/src/bindings/python/libsbml.py?expanded=true&viewer=simple

-- 
http://fam-tille.de

[toc] | [prev] | [next] | [standalone]

#12429

[Multipart message — attachments visible in raw view] — view raw

On Sun, 5 Apr 2020, 15:50 Andreas Tille, <andreas@an3as.eu> wrote:

> On Sun, Apr 05, 2020 at 03:40:56PM +0530, Nilesh Patra wrote:
> > > > '_libsbml' file which corresponds to libsbml (with python3-sbml5 as a
> > > > provide) package. When I dug into looking at libsbml, I noticed that
> the
> > > > relevant file (libsbml.py) which throws error
> > > > is generated with swig-3.0 by the upstream [3]
> > >
> > > I admit I'm absolutely naive about swig - but if libsbml.py is really
> > > autogenerated what about re-generating it with swig-4?
> >
> > I think there's a miscommunication here. The file in the archive(on doing
> > $apt source python3-sbml5) is generated with swig-4 already, while it's
> > generated with swig-3 upstream.
> > Hence the issue.
>
> Ahhh, so it is regenerated in the Debian package build process but it
> conflicts with other parts of the upstream code?  Did I now understood
> correctly?
>

Yep.
That's my _suspicion_ though, that the rest of the upstream code isn't
compatible with the new version, and there are API changes needed.
Hence I sent the mail to confirm if I'm thinking in the right direction.


> I wonder if we should exclude this kind of autogenerated code inside
> the source tarball since we are repackaging the source anyway to exclude
> some files for policy reasons.  I'm doing so in other source tarballs
> for instance with cython files to be absolutely sure that this code
> is regenerated.  This would probably not solve the build issue but might
> be a good idea in general.  What do you think?
>

It seems like libsbml.py would be needed by the rest of the code. So we can
maybe keep the upstream's generated code and not generate it on our own -
this however does not seem DFSG compliant.
Not really sure what to do here.


> Kind regards
>
>       Andreas.
>
> > > > [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955656
> > > >
> > > > [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955656#10
> > > >
> > > > [3]:
> https://salsa.debian.org/med-team/libsbml/-/blob/master/src/bindings/python/libsbml.py?expanded=true&viewer=simple
>
> --
> http://fam-tille.de
>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web