17 Dec 2023 at 18:15, Andreas Tille wrote:
> > > Is there
> > > any better way than editing debian/obitools.substvars in d/rules by
> > > adding some override_dh_gencontrol?
> >
> > Remove the line:
> >
> > Cython>=0.24
> >
> > fro
On Sat, May 16, 2020 at 11:09:33AM +0800, Paul Wise wrote:
> On Fri, 2020-05-15 at 19:56 -0700, Steve Langasek wrote:
> > FTR, UbuntuStudio is an official Ubuntu flavor, not a derivative ;)
> Woops. Did that change at some point or did I mix them up with another
> distro or jus
FTR, UbuntuStudio is an official Ubuntu flavor, not a derivative ;)
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.or
r/bin/gcc, etc. are always symlinks to the real interpreter on Debian,
not wrapper scripts - other distributions have tried to do this as a wrapper
script and the result wasn't pretty.
Avoiding the performance hit would require that any changes to the banner
be made in the python source itself.
On Wed, Aug 02, 2017 at 12:10:05PM -0400, ba...@debian.org wrote:
> On Jul 30, 2017, at 02:41, Steve Langasek wrote:
> >> https://wiki.debian.org/Python/LibraryStyleGuide where it states:
> >>You'll want to have at least the following build dependencies:
>
l because without it, build-time tests failed for
python3. If I also added python-lxml, that was purely a cut'n'paste error.
> BTW, does it make sense to upload another -1 version to ftp-master
> to replace the one in the NEW queue?
AFAIK you would need to get the ftpmasters to rej
llowing commit
> https://anonscm.debian.org/cgit/collab-maint/html5-parser.git/commit/?id=4a8e02b20698e35e577482f96efdeb17826d797f
> which I reverted afterwards.
> Thanks a lot and all the best
Thanks,
--
Steve Langasek Give me a lever long enough and a F
On Fri, Jun 16, 2017 at 10:23:06PM -0700, Steve Langasek wrote:
> [1] pytables is a failure specific to Ubuntu armhf buildds which raise
> SIGBUS, this should not affect Debian. python-astropy rebuilds with no
> problem, but doesn't pick up python3.6 support.
To clarify: python-ast
3.6 added as supported should already have patches
filed in the Debian BTS.
The rebuild with python3.6 as default is also now in progress for Ubuntu;
test build results can be seen here:
https://launchpad.net/~canonical-foundations/+archive/ubuntu/python3.6-as-default
Hope that helps,
--
Steve L
version that is just symlinked on the filesystem to the
default version?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://ww
ny”.
> What is broken here? How can I find out?
I believe this is a regression in python3.5 3.5.1-15. Similar build
failures were seen with this version in Ubuntu.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set
On Wed, Mar 23, 2016 at 09:21:19AM +1100, Brian May wrote:
> Steve Langasek writes:
> > No. I first noticed this bug because the package failed to build in
> > Ubuntu[1], which uses sbuild, not pbuilder. I reproduced the failure in a
> > clean sid schroot. I thi
No. I first noticed this bug because the package failed to build in
Ubuntu[1], which uses sbuild, not pbuilder. I reproduced the failure in a
clean sid schroot. I think either your sbuild environment is not clean, or
it is not up-to-date.
--
Steve Langasek Give me a
y kind.
It's not my place to judge whether this was a correct disciplinary action
for the DPMT, of which I am not a member; but for the record, this does not
in any way prevent Thomas from continuing to maintain *his* packages. The
DPMT doesn't block a maintainer from moving their packages
On Mon, Aug 17, 2015 at 11:10:26AM -0400, Barry Warsaw wrote:
> On Aug 15, 2015, at 08:24 PM, Vincent Bernat wrote:
> >So, what's the situation? Should we do something during this Debconf?
> JFDI. :)
Yes, let's!
--
Steve Langasek Give me a lever lon
Relatively few at this point, but there is a session here at DebConf14 this
evening that will be streamed and might be worth following:
https://summit.debconf.org/debconf14/meeting/75/dgit-treat-the-archive-as-a-git-remote/
--
Steve Langasek Give me a lever long enough a
On Wed, May 07, 2014 at 11:43:24PM +0200, Matthias Klose wrote:
> Am 07.05.2014 23:01, schrieb Steve Langasek:
> > On Wed, May 07, 2014 at 10:15:37PM +0200, Matthias Klose wrote:
> >> Am 07.05.2014 17:27, schrieb Barry Warsaw:
> >>>> + ++ +
d, I think it's more important that we make sure the base system
is leading by example. As described on debian-devel[1], there seem to be
some porting blockers before we can migrate from python to python3 in the
standard install.
[1] https://lists.debian.org/debian-devel/2014/04/msg00784.html
ooth wheezy->jessie upgrades is not even remotely funny.
This has no impact on upgrades. Why would you expect cross-installing
anything as part of an upgrade?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can
]
> export-dir = ../build-area/
> to make sure no contributors dirties the git with build files (yes, you
> can do that in your ~/.gbp.conf, and the system configuration file in
> /etc, but the point here is to make sure *everyone* uses the build-area).
Right... these are things the e
s with only
python3 installed. Would you accept patches to reportbug and
apt-listchanges to move them to python3?
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
lly
needed changed in order to swap python for python3 in the default install -
lsb-release is one of them, and I don't remember offhand what the others
were.
In short, I see no reason why Debian would want to stick with python2 by
default in Jessie. The barrier is much lower than i
meant to use the check_auto_buildable method to declare whether
they should or should not be used. Why can pybuild not autodetect?
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the
depend on udebs, they
are not installable on a full system; so they must be downloaded from the
mirror.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
> Don't detect anything. Add an option (say, --multiarch-me-harder),
> so that maintainers can opt-in for :any dependencies.
That doesn't sound to me like it's optimizing for the common case.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Dev
's python, we
could generate dependencies such as:
python:any (>= 2.7.5-5) | python (>= 2.6.6-3)
which I think would DTRT in all cases except where you try to cross-install
on top of the wheezy python, which is a negligible use case.
--
Steve Lan
r/bin/python2 compatibility benefits our users, yes. Promoting
its use, or making /usr/bin/python incompatible with the many existing
scripts running on older Debian releases, does not.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
ying that /usr/bin/python should change to python3 *any
> time soon*.
I say that it shouldn't change *ever*. API versioning is important. It's
not less important for interpreter shebangs than it is for sonames. Just
because Arch screwed up doesn&
o be discussed on debian-devel because
they can have system-wide repercussions. Can you please kick off a thread
to discuss this there?
> I don't share the opinion on the severity of #709198, and how it should be
> fixed, if we are going this route of keeping the python interpreter workin
sure new library deps are
listed in pre-depends instead of depends. Yet I think this should be
entertained as an alternative to increasing the amount of code duplicated
across hundreds of maintainer scripts.
--
Steve Langasek Give me a lever long enough and a Free OS
D
fered with other transitions
given that it comes at the beginning of the release cycle - I would suggest
moving on to more constructive topics.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set i
n; and as Dmitrijs
mentions, being able to cross-build packages that use python too.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.d
's
reasonable to work around that one known case, but why spend any effort on
this problem unless and until we see a pattern of such abuse (where "a
pattern" is N>1)?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
On Wed, Aug 08, 2012 at 01:10:00PM +0400, Dmitry Shachnev wrote:
> This can be caused by extra space in your override_dh_auto_install
> line: it should be "dh_auto_install --prefix=/usr" without space after
> "--".
No, it shouldn't. --prefix is not an argum
debian.org/Python/PyCentral2DhPython2
> http://wiki.debian.org/Python/PythonSupportToDHPython2
> Any objections if I do that?
I think the current pages strike the right balance between maintainability
and having an easy, linear document that maintainers can follow. IMHO it
would be nice to keep
On Fri, Jun 10, 2011 at 03:27:00PM -0400, Barry Warsaw wrote:
> On Jun 10, 2011, at 10:09 AM, Steve Langasek wrote:
> >Did you try with:
> > DEB_PYTHON2_MODULE_PACKAGES = ubuntu-system-service
> Bingo!
> >This is a list of Debian package names, not python package
uggestions are welcome. Or, if you have an example diff showing the
> conversion of a python-central+cdbs package to dh_python2+cdbs, I would love
> to see it.
I don't have an example, because my test case also got converted from cdbs
to dh(1) in the middle of the night ;-)
--
Steve Lang
her than _build?
Anyway, I'd be surprised if this couldn't be reduced to:
override_dh_auto_build:
dh_auto_build -- --install-layout=deb
Furthermore, I'd be surprised to learn that dh_auto_* weren't already
passing --install-layout=deb.
However, AIUI the main concern
is a mercurial-buildpackage but I don't know how feature complete/
> comparable to git-buildpackage or svn-buildpackage it is.
> How well does debcommit work with mercurial or bazaar?
debcommit works perfectly well in bazaar.
--
Steve Langasek Give me a lever lo
tory the way git's are?
I don't know why you would say that merging is more difficult in bzr,
frankly. Perhaps you're comparing bzr merging with the seemingly common git
practice of discarding revision history as a substitute for doing an actual
DVCS merge? Having done merges i
the decision is for git, please take care with
the branch layout so that git-buildpackage *does* work out of the box, and
please *do* use the pristine-tar options.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set
keywords like "dh_python2". Maybe a name like
"Python/PythonSupportToDHPython2" would be better (with a
backwards-compatible redirect added)? I think that would help make this a
little easier to find... and certainly make it easier for me to figure out
what I'm going to find at
, I would encourage you to report bugs against
lintian (preferably with patches) for these issues. (Ideally, cc:ing
debian-python on the bug reports, so that we don't accidentally wind up with
lintian checks that don't match the consensus understanding of how python
packages are supposed to work
27;t think the arguments for consolidating on python-foo apply here.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debia
On Wed, Jun 09, 2010 at 09:05:49PM +0200, Sandro Tosi wrote:
> On Mon, Jun 7, 2010 at 01:39, Steve Langasek wrote:
> >> Please reply to debian-python with fix reports or reports of false
> >> positives.
> > Not quite either of these, but in a similar vein, I'
probably be exempted
from the MBF.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...
stable [1].
> Why currently compiling a package which contains binary extensions only
> build them for python 2.5?
There could be a number of reasons (including a bug in python-defaults that
no one noticed yet). What source package are you looking at?
--
Steve Langasek Giv
s
the new maintainer of python, then based on a sample size of one TC member,
I would disagree.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
On Tue, Jan 12, 2010 at 09:17:44AM +0100, Pietro Battiston wrote:
> Il giorno mar, 12/01/2010 alle 00.06 -0800, Steve Langasek ha scritto:
> > On Tue, Jan 12, 2010 at 08:56:08AM +0100, Sandro Tosi wrote:
> > > On Tue, Jan 12, 2010 at 08:39, Andreas Tille wrote:
> > >
ound like some sort of noble enterprise for the good of Debian.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
current pythonX.Y executable.
The python package must also depend on the
appropriate pythonX.Y to
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
t;pedantic" (people - e.g., me - don't
agree that this check is correct). But I don't see the point in adding
pedantic tags to lintian. :)
The rest seem ok to me.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
-central needs to be NMUed to handle
> such packages.
There is no bug filed against python-central for this. An NMU would be out
of order.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and
; > * patch /usr/bin/pyversions to use them instead
> > * or introduce a new script that does this, and get cdbs and dh7
> > to use it instead
> If there is really a consensus about that, it would not be too hard to
> implement
> it in d
are not documentation.
They're documentation that you're wrong. Stop wasting my time.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
he responses in this thread show that the list is far more beset
with python-support apologists now, who are even less willing to approach
the problem from a policy perspective and are only interested in defending
their favorite tool.
--
Steve Langasek Give me a lever long enough
nilaterally
implement helpers that don't do what was asked for.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp
never been
> more than an implementation detail for python-central.
They were part of the design that came out of the python packaging BoF in
DebConf 6 that you then proceeded to ignore entirely.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
versions without XS-Python-Version when you
> use python-support, just ignore this notice.
FSVO "fine" that includes "completely destroying the value of the python
policy for the Debian release team".
The right answer here is to file a bug against cdbs telling it to
On Sat, Sep 05, 2009 at 08:40:30PM -0700, Ludovico Cavedon wrote:
> Steve Langasek debian.org> writes:
> > The XS-Python-Version field was specified as a tool for detecting, without
> > having to download and inspect individual source packages, that a given
> > package can
tool for detecting, without
having to download and inspect individual source packages, that a given
package can be successfully rebuilt for a python transition, to aid the
release team in this work.
The python-support maintainer's decision to undermine this doesn't represent
bes
make pretty obvious to anyone not convinced yet
> that -central can't really be considered a “chosen one”, no?
So how does python-support address this bug without instead making
python-based programs excessively brittle during upgrades?
There are tradeoffs here.
--
Steve Langa
On Mon, Mar 02, 2009 at 05:30:57PM -0500, Ondrej Certik wrote:
> On Mon, Mar 2, 2009 at 3:44 PM, Steve Langasek wrote:
> > My rebuttal is that if git is technical superior to bazaar because bazaar
> > has a mechanism to create repositories with only partial history, then
> >
ically superior to git because git has rebasing as a
first-class feature.
:-)
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
a case of a package with
a lot of reverse-dependencies; so I don't disagree with the conclusion to
avoid an upload to unstable for now.)
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubunt
ceiling is much lower for svn than for DVCS.
The real danger is that most people who know DVCSes aren't content to teach
people how to use them like svn. ;)
I agree with Scott that workflow documentation is really the single biggest
factor in how approachable this will be
. That's not what the word "intuitive" means.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
s
On Sun, Dec 21, 2008 at 12:08:18AM +0100, Ondrej Certik wrote:
> On Sat, Dec 20, 2008 at 7:49 PM, Steve Langasek wrote:
> >> as it is really ugly to use
> > Ugly how?
> Well, it's just slow once you get used to git and how fast it is,
> it really sucks to w
just my subjective opinion, please don't start a flame war now)
It's a rather strongly worded opinion; if you want to avoid flame wars, you
might find it helpful to bring specific criticisms to the table instead of
just declaring a solution "ugly". :)
Slinkin
On Tue, Feb 26, 2008 at 10:04:26PM -0600, Steve M. Robbins wrote:
> On Sat, Feb 23, 2008 at 09:17:24PM -0800, Steve Langasek wrote:
> > Decorate only the shared library names with the python versions, and retain
> > the current names for the .a files and .so symlinks - with tw
t I think it solves
all the other drawbacks of the other solutions you suggested.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
s
> I don't see why newer python-numpy makes it uninstallable.
Because it depends on python-scipy, which is the depending package that has
already been made uninstallable?
> Any ideas how to fix b), so that python-numpy can go to testing?
By dealing with python-scipy.
--
Steve Lang
ses a problem for
your package then your package is missing either a build-dependency or a
build-conflict (or is buggy in some other way).
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubunt
ilable that can be used to reproduce this list from
Packages/Sources? I would very much prefer to be able to generate an
authoritative list of per-arch binaries that need to be binNMUed, so that
the progress can be tracked and so we're not needlessly binNMUing packages
that have sourceful uploads
ated to declarations of symbols exported by the library itself.
python2.4-dev was such a false positive. If a bug was ever opened for it,
it's been closed and archived long ago.
You should proceed with the ldbl transition for your own package.
--
Steve Langasek Give m
> was pretty stupid to have DPMT as uploader, as it would make every
> package NMU.
No, what was said was that it was meaningless to list a mailing list in the
Uploaders field because a mailing list can never do an upload and therefore
it misses the /point/ of the Uploaders field.
--
Stev
uot;current"
> should be replaced?
No objections.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
--
To UNSUBS
, then the package's
> > current dependencies are wrong...
> python2.4 is default now so there's no need to add extra dependencies
Um, no. Your package is supposed to have a versioned dependency on python
(>= 2.4), and it doesn't.
--
Steve Langasek
t's built for python2.X explicitly, the
package name needs to reflect that, which means manual changes are needed to
update it for a new python version. That's out of scope for 'current'.
> BTW: "current, >=2.4" helped me a lot with packaging gaupol when
> pyt
be
> > built for one version of python, the version that is currently the
> > default version in Debian.
> not necessary default (see "current, >=2.X" where 2.X is greater than default)
> but for single version only, yes. I understand it this way, but
>
On Thu, Mar 22, 2007 at 12:47:17AM +0100, Josselin Mouette wrote:
> Le mercredi 21 mars 2007 à 15:51 -0700, Steve Langasek a écrit :
> > > If we don't, I don't see the purpose of the policy alltogether.
> > Allowing transitions between default versions of python
ackage anyway".
Right.
> So that first quick look just says that what we need is a way to find
> out about packages that:
> * build private extensions (needed for question (2));
> * only build things for the default python version (opposed to those
> who build for as many
pilation is needed in that case, even if pyversions -s
> changes.
As you allude later, ideally you would have binNMUs in response to the
pyversions -s change, so that the package is updated for additions/deletions
to the supported list. The binNMU is not *required*, true, but doing such
binNM
On Thu, Mar 22, 2007 at 12:05:30AM +0100, Pierre Habouzit wrote:
> On Wed, Mar 21, 2007 at 03:51:20PM -0700, Steve Langasek wrote:
> > On Wed, Mar 21, 2007 at 11:16:14PM +0100, Pierre Habouzit wrote:
> > > If we don't, I don't see the purpose of the policy alltogethe
On Wed, Mar 21, 2007 at 11:16:14PM +0100, Pierre Habouzit wrote:
> On Wed, Mar 21, 2007 at 02:44:29PM -0700, Steve Langasek wrote:
> > On Wed, Mar 21, 2007 at 08:22:32PM +0100, Josselin Mouette wrote:
> > > I think it's time to update the python policy with the progress t
On Wed, Mar 21, 2007 at 10:59:40PM +0100, Piotr Ożarowski wrote:
> [Steve Langasek, 21.03.2007]
> > So with current deprecated, what is the solution for a package which wants
> > to build a single binary extension for the current python version in a
> > package named python
On Wed, Mar 21, 2007 at 11:03:37PM +0100, Josselin Mouette wrote:
> Le mercredi 21 mars 2007 à 14:51 -0700, Steve Langasek a écrit :
> > On Wed, Mar 21, 2007 at 10:47:37PM +0100, Josselin Mouette wrote:
> > > If this is a public extension, this goes completely against the s
On Wed, Mar 21, 2007 at 10:47:37PM +0100, Josselin Mouette wrote:
> Le mercredi 21 mars 2007 à 14:44 -0700, Steve Langasek a écrit :
> > On Wed, Mar 21, 2007 at 08:22:32PM +0100, Josselin Mouette wrote:
> > > I think it's time to update the python policy with the progress t
des: meaningful in the case of inter-module
> dependencies, as discussed at Debconf;
Do the helpers implement this, or is this going to be a policy that packages
can't actually comply with?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
On Sat, Feb 24, 2007 at 06:17:35PM -0800, Suhas kurse wrote:
> I am new to Python programming.
> I want to set the PYTHONPATH in "Windows XP". How should I go about it
> Appreciate your reply
1) Install Debian
2) ask an on-topic question about Python on Debian
HTH,
ge->etch though; OTOH, I also don't see why it's important to avoid
removal of zope2.7 on upgrade, it /is/ an obsolete package from the etch
perspective.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it o
7;t this only the case if the user was upgrading from an old version
of the package that's no longer in the archive? If so, there's nothing RC
about this because mercurial wasn't included in sarge.
--
Steve Langasek Give me a lever long enough and a Free OS
De
d to figure out how to make an sgid games pyracerz binary. The
first solution that suggests itself to me is a small sgid wrapper written in
C that does nothing except change gid and execute the python program.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Develo
I hope people won't make again the mistake to define
> policies in a meeting.
I think the only lesson is to not invite you to such meetings, because
you'll piss on any attempt at building consensus anyway.
--
Steve Langasek Give me a lever long enough and a Free O
On Mon, Sep 04, 2006 at 08:41:55AM +0200, Raphael Hertzog wrote:
> On Sun, 03 Sep 2006, Steve Langasek wrote:
> > On Sun, Sep 03, 2006 at 11:38:19PM +0200, Julien Danjou wrote:
> > > Suggested packages:
> > > python-doc python-profiler
> > > The foll
ing doing bytecompiling, right?) need
a dependency on python (>= 2.3.5-6)...
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http:/
icated
> python dependence.
> And if I just ${python:Depends} I receive msg that I need to put
> python as Dependence.
Out of interest (I know someone has already offered you a patch), could you
post your package somewhere so that we can understand what went wrong?
--
Steve Langasek
On Sat, Aug 26, 2006 at 11:18:15AM +0200, Josselin Mouette wrote:
> Le vendredi 25 août 2006 à 17:09 -0700, Steve Langasek a écrit :
> > > As long as these fields don't even have clear semantics, implementing
> > > them is, at best, useless.
> > So, why has th
On Fri, Aug 25, 2006 at 10:26:54PM +0200, Josselin Mouette wrote:
> Le vendredi 25 août 2006 à 13:09 -0700, Steve Langasek a écrit :
> > I object to basing future work exclusively on dh_pysupport as long as it
> > implements your unilateral decision to abandon the XB-Python-Versio
pite the proof that 80% of
> this "policy" thing is nothing but useless complication for package
> maintainers).
I object to basing future work exclusively on dh_pysupport as long as it
implements your unilateral decision to abandon the XB-Python-Version field
and deprecate the XS-Python-
1 - 100 of 137 matches
Mail list logo
