On 2023-02-02 14:16:11 + (+), c.bu...@posteo.jp wrote:
[...]
> The upstream maintainers have to create a binddep.txt file.
Yes, it would look something like this:
https://opendev.org/openstack/nova/src/branch/master/bindep.txt
And then projects relying on it document using the bindep too
into a pyproject.toml
> file.
> But some Python applications (e.g. BIT) do have non-Python dependencies to
> specific Debian packages e.g. "rsync".
>
> As upstream I do document that into README or somewhere else in a human
> readable file.
>
> But is there a
Thanks for your reply.
Am 02.02.2023 14:46 schrieb Jeremy Stanley:
with https://pypi.org/project/bindep which is effectively a manifest
of distribution package names and a grammar for indicating
Awesome.
The upstream maintainers have to create a binddep.txt file.
And the distro maintainers do
In the OpenStack ecosystem we mostly solved this around 8 years ago
with https://pypi.org/project/bindep which is effectively a manifest
of distribution package names and a grammar for indicating
differences in package naming or requirements between different
distributions and versions thereof. It'
Hello,
I'm part of upstream maintainer team of "backintime" (BIT).
A modern Python project (which BIT is currently not) would specify
dependencies and other build related information's into a pyproject.toml
file.
But some Python applications (e.g. BIT) do have non-Pyt
Piotr Ożarowski writes:
> gandi-cli name suggests it's not providing public module and thus no
> "public" requires.txt. If you want dh_python3 to read dependencies from
> a random file - make sure dh_python3 knows which one it should use:
>
> override_dh_python3:
> dh_python3 --requires pa
[Ben Finney, 2018-07-15]
> The Debian package ‘gandi-cli’ is building with none of the Python
> library dependencies detected, so the “Depends” field contains none of
> the required Python library packages. Why isn't ‘dh_python3’ reading the
> dependencies from ‘requires.txt’?
gandi-cli name sugge
Howdy all,
The Debian package ‘gandi-cli’ is building with none of the Python
library dependencies detected, so the “Depends” field contains none of
the required Python library packages. Why isn't ‘dh_python3’ reading the
dependencies from ‘requires.txt’?
When I install the upstream source, it cr
Hi,
On Wed, Jul 26, 2006, Matthias Klose wrote:
> Please could you check dh_python with the patch from #378604?
(Sorry for the delay.)
I applied the patch and tried again with:
XS-Python-Version: 2.3
got:
Depends: libc6 (>= 2.3.6-6), libglib2.0-0 (>= 2.10.0),
libgnome-menu
Please could you check dh_python with the patch from #378604?
Loïc Minier writes:
> On Tue, Jul 25, 2006, Joe Wreschnig wrote:
> > The scripts in /usr/lib/python2.3/site-packages/GMenuSimpleEditor call
> > plain "python". That's probably causing the dependency.
>
> After I've "sed 1d" the files,
On Tue, Jul 25, 2006, Joe Wreschnig wrote:
> The scripts in /usr/lib/python2.3/site-packages/GMenuSimpleEditor call
> plain "python". That's probably causing the dependency.
After I've "sed 1d" the files, the Depends of python-gmenu still has:
Depends: libc6 (>= 2.3.6-6), libglib2.0-0 (>= 2.1
On Tue, Jul 25, 2006, Joe Wreschnig wrote:
> The scripts in /usr/lib/python2.3/site-packages/GMenuSimpleEditor call
> plain "python". That's probably causing the dependency.
Ok, I suspected this, but since there was no other python2.3 depends, I
thought there was something wrong in the first pla
s 2.3 when it was built, it ships files below
> /usr/lib/python2.3, so why doesn't it end with a python2.3 dependency
> instead of pure python dependencies? And why does it "conflict" with a
> "python" 2.4?
The scripts in /usr/lib/python2.3/site-packages/GMenu
6-6), libglib2.0-0 (>= 2.10.0),
libgnome-menu2 (>= 2.14.0), python-central (>= 0.5), python (>=
2.3), python (<< 2.4)
Python-Version: 2.3
Since "current" was 2.3 when it was built, it ships files below
/usr/lib/python2.3, so why doesn't it end with a python2.
A useful way to figure out the dependencies for packages that I just
sorta-discovered:
python -v (filename) < /dev/null 2>&1 | grep import
This dumps out the filenames of the packages that are imported. A
proper dependency checker (like the dh_perl that just went into
debhelper) probably wouldn'
15 matches
Mail list logo
