For example, CPython is distributed under the PSF License and is
included in Debian main:
https://metadata.ftp-master.debian.org/changelogs//main/p/python3.13/python3.13_3.13.1-3_copyright
Hope that helps!
--
Jeremy Stanley
signature.asc
Description: PGP signature
while, which is (slowly) growing in
popularity too: https://packages.debian.org/signify
--
Jeremy Stanley
signature.asc
Description: PGP signature
me soon. Sure it was removed from the CPython
stdlib, but that's simply because CPython itself no longer relies on
it for building. The idea was that it would be better maintained
outside of the stdlib as part of an independent packaging library.
--
Jeremy Stanley
signature.asc
Description: PGP signature
]
See
https://salsa.debian.org/python-team/tools/dh-python/-/commit/31eff8f
which merged last week.
--
Jeremy Stanley
signature.asc
Description: PGP signature
r system site directories with pip.
--
Jeremy Stanley
signature.asc
Description: PGP signature
t Debian will help you fix things once you've done it. This
feature is simply a guard rail for users who otherwise wouldn't know
where the edge of that cliff is located.
There are already solutions for your power users, but as is often
said in such situations: If it breaks you get to keep
f you use the
--system-site-packages option when creating it.
--
Jeremy Stanley
signature.asc
Description: PGP signature
ges enabled then it will
still use any Debian-packaged Python libraries you've installed.
--
Jeremy Stanley
signature.asc
Description: PGP signature
f you need different versions of dependencies for
different things.
To your original question, if you really want to use some
Debian-packaged libraries mixed with things installed from source or
from PyPI, make your venv with the --system-site-packages option.
--
Jeremy Stanley
signature.asc
Descri
nd many
projects have settled on some common ones (particularly "test") to
separate hard dependencies from optional or testing-related
dependencies, but these concepts vary widely enough between
different distros that I wouldn't expect a package maintainer to
take the filtered bind
run a project and its tests, but we also rely on it heavily
in automated CI jobs to determine what non-Python packages should be
installed for tests to execute correctly.
--
Jeremy Stanley
ff like that from the repository.
> refstack-client # confirm, in refstack_client
Fixed in 0.1.0 from February (unstable carries an unreleased
snapshot from last year).
--
Jeremy Stanley
signature.asc
Description: PGP signature
tested upstream if folks think that would be a helpful
data point, but it's not entirely trivial since I'll have to do some
extra work to override the requirement constraints (otherwise I
would have just done it before replying).
--
Jeremy Stanley
signature.asc
Description: PGP signature
d to do a MBF," so I assumed that's
been the plan all along? Or are you asking why it hasn't been
started now that it's been a few weeks?
--
Jeremy Stanley
signature.asc
Description: PGP signature
ude
https://packages.debian.org/python3-testrepository or
https://packages.debian.org/python3-stestr (both are
subunit-emitting test runners), which pretty much all of the
OpenStack projects moved to years ago as replacements for nose.
--
Jeremy Stanley
signature.asc
Description: PGP signature
e original intent for a "source distribution" package), since most
users installing directly from PyPI are going to pull a wheel
instead of an sdist when available, and wheels are expected to be
much more pared down anyway.
Like many things in the packaging realm, there is no
one-si
on and some metadata. This has
reduced the pressure on upstreams with massive suites of tests or
volumes of documentation to strip them out of sdists, making it more
likely they'll ship full source distributions that way.
--
Jeremy Stanley
signature.asc
Description: PGP signature
reasons. Running some battery of upstream tests makes
sense, but testsuites which require root access outside a chroot,
integration tests orchestrated across multiple machines, access to
unusual sorts of accelerator or network hardware, and so on can
easily comprise part of "the upstream
On 2021-06-26 02:04:40 + (+), Paul Wise wrote:
> On Fri, Jun 25, 2021 at 11:42 PM Jeremy Stanley wrote:
[..]
> > 2. Cryptographically signed tarballs of the file tree corresponding
> >to a tag in the Git repository, with versioning, revision
> >history, release
tail or broaden to related
examples elsewhere in the ecosystem.
--
Jeremy Stanley
signature.asc
Description: PGP signature
ut files into Debian source packages which can be generated at
package build time from other files in Debian, but when those files
can't be generated without the presence of the Git repository itself
which *isn't* files in Debian, using the generated copies supplied
(and signed!) by upstream seems no different than many other sorts
of data which get shipped in Debian source packages.
--
Jeremy Stanley
signature.asc
Description: PGP signature
eing
only a copy of the file contents from source control while missing
other relevant context Git would normally provide.
--
Jeremy Stanley
signature.asc
Description: PGP signature
thon for custom development because it is patched and
tuned specifically for running system applications packaged for
their distro and not intended as a general-purpose Python
distribution.
--
Jeremy Stanley
signature.asc
Description: PGP signature
akes/+archive/ubuntu/ppa
--
Jeremy Stanley
signature.asc
Description: PGP signature
;re going to use the python3 packaged in oldstable, then can't
you use the libraries (e.g. python3-yaml) packaged in oldstable as
well and take advantage of whatever security fixes are backported by
the package maintainers/security team?
--
Jeremy Stanley
signature.asc
Description: PGP signature
er
pip is needed to be able to deal with that too (at least if you
don't want to have to preinstall an entire build toolchain so you
can install sdists instead).
--
Jeremy Stanley
signature.asc
Description: PGP signature
python3-full and install
it instead, and accidentally get "software developer tools" when
they do so. But who else is specifically choosing to install a
Python interpreter if not people writing and running non-packaged
Python source?
--
Jeremy Stanley
signature.asc
Description: PGP signature
from github with git.
>
> Is there a solution here, so that uscan uses a repack script directly
> without attempting to download first?
Maybe I'm missing something obvious, but can't you just use mode=git
(see uscan manpage for details on this feature). I assumed this is
what was being suggested.
--
Jeremy Stanley
signature.asc
Description: PGP signature
me comments, skipping notes earlier than a certain
version, collapsing pre-release notes, and so on. A quick test of
Nova's release notes indicates that even if you don't truncate them
though and include everything back to when the project started using
reno 5 years ago, that NEWS file woul
hether it
actually represents a problem for downstream packaging likely varies
a bit from project to project.
--
Jeremy Stanley
signature.asc
Description: PGP signature
On 2020-10-31 12:03:50 +0100 (+0100), Thomas Goirand wrote:
[...]
> On 10/31/20 3:07 AM, Jeremy Stanley wrote:
> > I have to agree, though in the upstream projects with which I'm
> > involved, those generated files are basically a lossy re-encoding of
> > metadata
es, and so on. Some of
this information may be referenced from copyright licenses, so it's
important in those cases for package maintainers to generate it when
making their source packages if not using the sdist tarballs
published by the project.
--
Jeremy Stanley
signature.asc
Description: PGP signature
programming language, similar to Python and developed by the same
community, but not directly compatible with Python. Debian provides
an interpreter for Python3, but has (or will have by then) ceased
distributing a Python interpreter.
--
Jeremy Stanley
signature.asc
Description: PGP signature
erge requests are also normally to a build result detail
page provided by the dashboard, thought you should be able to
configure it to link directly to the job logs instead.
--
Jeremy Stanley
signature.asc
Description: PGP signature
started work on that at various times in
https://bugs.debian.org/705844 but more recently there are some
JavaScript deps for its Web dashboard which could get gnarly to
unwind in a Debian context).
--
Jeremy Stanley
signature.asc
Description: PGP signature
oposal makes
some sense. The Testing Cabal folk were heavily involved in
OpenStack and influential in shaping its quality assurance efforts;
so OpenStack relies much more heavily on these libraries than other
ecosystems of similar size, and OpenStack community members, present
and past, continue to colla
On 2020-05-04 19:07:00 + (+), Jeremy Stanley wrote:
> On 2020-05-04 19:13:38 +0200 (+0200), Florian Weimer wrote:
> > I'm trying to package pwclient, which depends on python3-pbr and has a
> > rudimentary manual page generated from Sphinx documentation. Is there
&
://salsa.debian.org/openstack-team/clients/python-openstackclient/-/blob/88bdecc66a30b4e3d5aec9cdae4cc529c33690e6/debian/rules#L27
>
Then there's a similar dh_installman override a few lines later.
--
Jeremy Stanley
signature.asc
Description: PGP signature
fix more than 80 common lintian issues in Debian packages.
It comes with a wrapper script that invokes the scripts, updates
the changelog (if desired) and commits each change to version
control.
(from https://packages.debian.org/lintian-brush )
--
Jeremy Stanley
signature.
management
solution like conda or virtualenv.
--
Jeremy Stanley
signature.asc
Description: PGP signature
using and relying on, rather than wading through a large list of
packages which are mostly orphaned because nobody's using them
anyway.
--
Jeremy Stanley
signature.asc
Description: PGP signature
erver sufficiently to
cause protocol negotiation to fall back to an old enough version
that the attacker can then exploit known flaws to decrypt and/or
proxy ("man in the middle") that communication. Having both the
client and the server be unwilling to use susceptible older prot
https://manpages.debian.org/debdiff
http://snapshot.debian.org/package/python3.6/
[also, please don't Cc me, I do already read the mailing list]
--
Jeremy Stanley
signature.asc
Description: PGP signature
you're not
willing.
https://backports.debian.org/Contribute/
--
Jeremy Stanley
signature.asc
Description: PGP signature
missing something, there's no substantial difference
between building a package of Python3.6 and copying it to the
system, or performing a `make altinstall` and copying the resulting
files (via rsync, tar and scp, whatever) to the target system. If
you're okay with the idea of build
r that matter) gives distros flexible options, and
that you base your decisions as to what to use on research and fact
rather than hearsay.
--
Jeremy Stanley
signature.asc
Description: Digital signature
ream tarball from the source package to upstream release
announcements/checksums/signatures is a pretty large benefit you're
robbing from downstream recipients who might wish to take advantage
it.
--
Jeremy Stanley
signature.asc
Description: Digital signature
e maintainers to alter tarballs prior to
including them in the archive as fairly serious bug in its software.
--
Jeremy Stanley
signature.asc
Description: Digital signature
of upstream Git repositories (and
generating intermediate sdists on the fly or supplying version data
directly from the environment via debian/rules)?
I'm eager to see what upstream release management features you're
taking advantage of so we can better know which of those efforts are
valu
fore the
community feels its Py3K support efforts are truly complete.
--
Jeremy Stanley
signature.asc
Description: Digital signature
uthors would rather not check
into their revision control systems. So sdists, while a tarball
under the hood (and by filename extension), are still really an
installable packaging format more than they are a source
distribution format.
--
Jeremy Stanley
agement after what's employed for Debian's archive keys.
--
Jeremy Stanley
signature.asc
Description: Digital signature
onflict over
namespace-level init when some modules were editable installs.
Historical details of the decision are outlined at:
https://specs.openstack.org/openstack/oslo-specs/specs/kilo/drop-namespace-packages.html#problem-description
>
--
Jeremy Stanley
;m mostly running pip on unstable when developing, and I
run it from a bootstrapped virtualenv anyway so don't actually use
the Debian package of it other than to bootstrap my initial venv.
--
Jeremy Stanley
g as "closely" is interpreted in ways consistent with,
say, tarballs for C-based projects. Consider `setup.py sdist`
similar to `make dist` where the dist target of some projects may
still run additional commands to generate metadata or other files
not tracked in revision control prior to invoking tar/gzip.
--
Jeremy Stanley
On 2016-03-03 08:38:40 +0800 (+0800), Paul Wise wrote:
[...]
> FYI pep257 is definitely packaged:
>
> https://packages.debian.org/search?keywords=pep257
[...]
Whoops! Thanks--I almost certainly fat-fingered my package search on
that one.
--
Jeremy Stanley
hon.org/pypi/clonedigger
I can probably think up more that I've used, but the above rise to
the top of my list.
--
Jeremy Stanley
there
(which, mind you, aren't even actually required to be usable python
packages, they could be just about anything) would be nice, I don't
have any expectation that PyPI would ever eventually make it
mandatory.
--
Jeremy Stanley
those branches with
dependencies which were contemporary to the corresponding releases
rather than chasing ever changing behavior in them. Sometimes it is
done for expediency due to lack of interested volunteer effort, and
sometimes out of necessity because dependencies may simply conflict
in unresolvable ways.
--
Jeremy Stanley
mporary measure and can be removed if
all the broken tests are either removed or corrected (the assumption
being that distro package maintainers who have an interest in that
branch may volunteer to backport those patches from master if this
is important to them).
--
Jeremy Stanley
60 matches
Mail list logo
