On 04/21/2016 05:20 PM, Matthias Klose wrote:
> On 21.04.2016 16:52, Thomas Goirand wrote:
>> On 04/21/2016 04:10 PM, Edward Betts wrote:
>>> Recently I've come across some Python libraries that have a test
>>> suite in
>>> their github repo but don&#
On 05/11/2016 11:31 AM, Christopher Baines wrote:
> On 23/12/15 15:30, Christopher Baines wrote:
>> On 23/12/15 11:31, Thomas Goirand wrote:
>>> I was the maintainer of this package, though I lost interest for it
>>> because there's no reverse dependency for i
On 05/11/2016 02:31 PM, Christopher Baines wrote:
> On 11/05/16 13:19, Thomas Goirand wrote:
>> On 05/11/2016 11:31 AM, Christopher Baines wrote:
>>> On 23/12/15 15:30, Christopher Baines wrote:
>>>> On 23/12/15 11:31, Thomas Goirand wrote:
>>>>> I was
On 05/12/2016 10:13 AM, Christopher Baines wrote:
> On 12/05/16 07:57, Thomas Goirand wrote:
>> On 05/11/2016 02:31 PM, Christopher Baines wrote:
>>> On 11/05/16 13:19, Thomas Goirand wrote:
>>>> On 05/11/2016 11:31 AM, Christopher Baines wrote:
>>>>>
rse also fetch my key from the Debian keyring...)
Cheers,
Thomas Goirand (zigo)
List of maintainers / source packages:
==
Changed-By: Barry Warsaw
Source: python-webob
Changed-By: Brian May
Source: python-amqp
Changed-By: Daniele Tricoli
Source: beta
is proposing hacks to support both
names (thanks, that's very much welcome!). So it will be smooth, and we
can slowly open, then close bugs, slowly.
Cheers,
Thomas Goirand (zigo)
in
]
then simply do:
override_dh_auto_install:
pkgos-dh_auto_install
and that's it, it will handle the /usr/bin/python{3,}-slugify
alternative implementations for you.
I hope that helps,
Cheers,
Thomas Goirand (zigo)
On 06/22/2016 09:51 PM, Hugo Lefeuvre wrote:
> Hi Ben,
>
>>> The package is originally requested as a Python module[2] and it seems
>>> clear to me that the whole thing is only useful as a library
>>
>> I don't understand this statement. If it is *only* useful as a library,
>> why install the com
t; However, I have to say I'm a bit reluctant to make the package depend on a
> supplementary Build-Dependency only in order to prettify debian/rules.
You don't have to do that. You can open pkgos-dh_auto_install, see what
it does, and pickup ideas there. It's only 10 lines of shell scripts,
and you probably don't even need everything that's inside.
Cheers,
Thomas Goirand (zigo)
inxdoc
endif
IMO, that's better because you don't need to clean Doc/.build/html.
Also, the dh_auto_build isn't the correct target. Some derivative may
well choose not to implement dh_sphinxdoc (for example, for small
systems where they don't want docs), and here, you're making their lives
miserable.
Cheers,
Thomas Goirand (zigo)
gt; You won't mind if I upload 0.9.2?
The file here:
https://github.com/openstack/requirements/blob/master/upper-constraints.txt
shows that OpenStack Newton (currently in Experimental) is right now
gating on 0.9.1 upstream, so 0.9.2 is probably fine as well. Please go
ahead, you're saving me some work! :) Hopefully, this wont break Mitaka
(currently in Sid).
Cheers,
Thomas Goirand (zigo)
ST API client and tooling - Python 3.x
2.d Long desc for Package: aptly-publisher
The long desc start by an empty line. This isn't nice. Also, please
consider longer long descriptions. 2 lines isn't enough, at least 5
would be nicer. Upstream has a lot more info which you can pickup
it's not needed now.
Well, it may sometimes be needed. For example, let's say Stretch is
released, and at some point, Buster gets Python 3.6. Some packages may
support only that, and then you may need X-Python3-Version: >= 3.6. But
if we have already 3.4, and you're declaring "I'm supporting only >=
3.2", then there is no point.
Cheers,
Thomas Goirand (zigo)
P.S: Please don't CC me, I'm subscribed, and if you didn't know, it's
the rule in Debian to not CC.
ps://bugs.debian.org/768382
https://bugs.debian.org/801649
It is also annoying that git-dpm doesn't produce a clean git history. It
ends up this way:
commit 241398abe0c476f39f0b4d62fb5227e4d0a52778
Merge: c72e5ea 880b748
Author: Thomas Goirand
Date: Tue Aug 2 08:40:37 2016 +
merge
On 08/10/2016 10:41 PM, Barry Warsaw wrote:
> * IOW, if
> you choose to use gbp-pq, am I forced to do so when I modify the same repo?
> Or if you choose to use PoQ (plain 'ol quilt), will that affect how others
> can co-maintain the package in git?
That's the point. If we decide to use gbp-p
Hi Ondrej, and many others,
Here's the explanations from Andreas Beckmann. It just appear to pop in
my mail today. It's IMO convincing.
Cheers,
Thomas Goirand (zigo)
Forwarded Message
Subject: Re: postrm in python-qrcode
Date: Wed, 7 Sep 2016 20:37:56 +0200
Fro
il, because each SMTP
server on the way to your inbox can add a "Received:" field, so you can
trace the email.
So yes, footers in emails can break stuff, but not mangling subject,
which is part of the metadata.
Cheers,
Thomas Goirand (zigo)
===
* Why do you think you need such a file? The issue is there, it's not a
false positive, so just leave lintian complain. It gives a warning, not
a hard error, so that's fine.
Everything else looked ok to me, though it was only a quick look...
Cheers,
Thomas Goirand (zigo)
ry Sphinx-using
> package?
I don't see why upstream requiring PYTHONPATH=. would be bad...
Cheers,
Thomas Goirand (zigo)
s_proxy to do that, really,
is the wrong way. Lots of my packages contain intersphinx disabling patches.
Cheers,
Thomas Goirand (zigo)
ake it more automated. Does anyone have an idea about how to write such
automation?
Cheers,
Thomas Goirand (zigo)
n't care if the python version is 2 or 3, that's what IMO they should
rightly do).
So, I don't agree with you, and believe that gradually using
#!/usr/bin/python2 is a good approach to the transition. IMO, that's
what we should start doing as much as possible.
If the dependencies for Python itself aren't calculated well with that
shebang, then we should address that to make it right regardless of this
choice.
Cheers,
Thomas Goirand (zigo)
On 11/07/2016 04:21 PM, Scott Kitterman wrote:
> On Monday, November 07, 2016 10:08:25 AM Barry Warsaw wrote:
>> On Nov 07, 2016, at 11:44 AM, Thomas Goirand wrote:
>>> So, I don't agree with you, and believe that gradually using
>>> #!/usr/bin/python2 is a good
o discourage upstream to use namespaced
modules. This indeed could prevent from running unit tests. That's what
has been discovered in the OpenStack world, and now all the oslo libs
aren't using namespace (though we've kept the dot for the egg-names).
Cheers,
Thomas Goirand (zigo)
package names, we wouldn't have any substitution to
calculate.
Anyway, I don't see why Django modules should be an exception to any
rule we choose. If upstream is missing the "django-" prefix, then we
should suggest it.
Thomas Goirand (zigo)
member what I did for this
package, for which I don't care much (I just tried to be helpful
globally in Debian in this case). Did I forget to include what I push to
Git? :/
Cheers,
Thomas Goirand (zigo)
On 01/29/2017 08:17 AM, Arto Jantunen wrote:
> Scott Kitterman writes:
>> Does that then result in one big undifferentiated mass of diff in the source
>> package?
>
> No, it results in separate patches with their headers intact in the
> source package. I assume git-dpm (which I've never used) pr
is at 0.9.0 upstream, but it'll stay at 0.8.8 for Stretch.
> Still, we'd like to have everything in place once the release happens and
> freeze is lifted.
>
> -Barry
Could you please put this on hold? It's possible that I resume my work
on OpenStack packages (though I can't disclose anything on this yet).
Cheers,
Thomas Goirand (zigo)
ile is considered deprecated upstream,
and only maintained for bugs and security. There's alternative
available, like python-oslo.concurrency.
Cheers,
Thomas Goirand (zigo)
On 03/03/2017 04:09 PM, Allison Randal wrote:
> On 03/03/2017 08:01 AM, Thomas Goirand wrote:
>> Could you please put this on hold? It's possible that I resume my work
>> on OpenStack packages (though I can't disclose anything on this yet).
>
> Hi Thomas,
>
ng already, and one of
the reasons I'm not comfortable moving packages to the team.
Thomas Goirand (zigo)
m for so long to also be very careful as well.
That's *not* hilarious, and I'm not amused,
Thomas Goirand (zigo)
On 03/04/2017 05:13 AM, Brian May wrote:
> Thomas Goirand writes:
>
>> And I'm not even addressing yet the horrible git-dpm troubles, how
>> many more years the team is forcibly burying every contributor into.
>
> There is discussion on changing this. The consensus
t interacting with. It'd be awesome if we could
see more of your contribution.
> So, let's keep working together. You have people who are ready to
> listen and want to help. Take advantage.
I hope it will really happen, and that some people really will help.
Cheers,
Thomas Goirand (zigo)
On 03/05/2017 06:09 PM, Allison Randal wrote:
> Well, that thread got exciting... I realize there's history here, folks,
> but for the good of Debian, please set that aside.
>
> On 03/04/2017 09:51 PM, Thomas Goirand wrote:
>> On 03/04/2017 06:42 AM, Clint Byrum wrote:
On 03/05/2017 01:44 AM, Scott Kitterman wrote:
> On Sunday, March 05, 2017 01:26:19 AM Thomas Goirand wrote:
>> On 03/04/2017 04:04 PM, Scott Kitterman wrote:
>>> This was not about isolated mistakes.
>>> [...]
>>> I do not, however, think it's useful t
On 03/05/2017 01:13 AM, Scott Kitterman wrote:
> On March 4, 2017 6:41:13 PM EST, Thomas Goirand wrote:
>> On 03/04/2017 06:03 AM, Scott Kitterman wrote:
>>> If you don't understand why, after repeated warnings,
>>> you were temporarily banned from team repository
any problems, knows where the well-written documentation
> is, etc. We need dedicated people to help people on IRC and email when they
> get stuck or have a problem. And we have to consider the needs of those for
> whom contribution to DPMT is not a full-time job.
I already talked and wrote about it, I would very much like a packaging
CI/CD to be deployed for Debian. However, I'm scared to attempt doing it
by myself only. I don't want to become a single point of failure.
Cheers,
Thomas Goirand (zigo)
his
using:
# cat debian/gbp.conf
[DEFAULT]
debian-branch = debian/unstable
Last, I would consider it a nice improvement. Not a critical one. So if
others feel like we should keep the git-dpm old layout to avoid
confusing people, I wouldn't mind so much.
Your thoughts?
Cheers,
Thomas Goirand (zigo)
On 03/06/2017 11:18 PM, Brian May wrote:
> On 2017-03-07 08:43, Thomas Goirand wrote:
>
>> I prefer if we use debian/unstable rather than debian/master though, so
>> it is more explicit where we upload that branch.
>
> My reading of DEP-14 is that is says we should use
d be minimal. They
are, from my view point, a binary release, not a source release.
It makes a lot of sense to therefore use the git repository, which is
what I've been doing as much as possible.
Cheers,
Thomas Goirand (zigo)
emote plugin). First of all, upstream not using git are the very
few minority these days, so it's very rare cases to handle, and most of
the time, it's upstream who aren't very active, so it's not really a big
problem: I just use pristine-tar.
Cheers,
Thomas Goirand (zigo)
m that, no problem with other upstream files.
Cheers,
Thomas Goirand (zigo)
ponents are still not fully
Py3 compatible.
So yeah, in this case, it is a little bit too soon to drop Python 2.
Hopefully, we will be able to do that before Buster.
Cheers,
Thomas Goirand (zigo)
(>= 1.4.0-2)
>> Reverse Depends: python-sahara (>= 1:5.0.0-2)
>> Reverse Depends: python-senlin (>= 2.0.0-2)
>> Reverse Depends: python-trove (>= 1:6.0.0-2)
>> Reverse Depends: python-watcher (>= 0.30.0-4)
>
> Alternative: maybe I should go to the other plan of uploading the old
> version of kombu with an increased epoch?
Upgrading all of the above is absolutely not possible. I see that it was
uploaded with 4.0.2+really3.0.35+dfsg-2 which was the correct thing to
do. Thanks!
Cheers,
Thomas Goirand (zigo)
serves severity "grave"? Are others sharing
the view that it could be downgraded to "important"?
Cheers,
Thomas Goirand (zigo)
diff -Nru python-cassandra-driver-3.7.1/debian/changelog
python-cassandra-driver-3.7.1/debian/changelog
--- python-cassandra-driver-3.7.1/debian/changel
d be just adding an
> Architecture: field to the -dbg packages (and for Buster, porting the
> code to support big endian architectures).
This looks like the most reasonable solution to me. Thoughts anyone?
Cheers,
Thomas Goirand (zigo)
On 04/06/2017 09:36 PM, Thomas Goirand wrote:
> On 04/06/2017 08:39 PM, Ondrej Novy wrote:
>> And auto -dbgsym doesn't support python-dbg. So it's wrong for Python C
>> modules.
>
> I guess I need to read more about this then.
>
> On 04/06/2017 06:31 PM, Dmit
pkgos-alternative-bin (from
openstack-pkg-tools) if you want some automations, so you don't need to
write the maintainer's scripts by hand (which is the main pain point).
Cheers,
Thomas Goirand (zigo)
around in some ugly ways (ie:
with a "maintained by hand" list of pydists-overrides). I wish we could
have a constructive discussion about this here.
Cheers,
Thomas Goirand (zigo)
to find (ie: cat
/var/lib/dpkg/info/python-foo.list once the package is installed), the
egg name vs package name is a *way* more confusing. Besides this, our
priority should be our users, and I am convinced that most aren't python
developers.
Cheers,
Thomas Goirand (zigo)
Hi,
Thanks for raising these questions, and giving me the opportunity to
debunk some of the things you mentioned.
On 05/17/2017 11:31 AM, Piotr Ożarowski wrote:
> [Thomas Goirand, 2017-05-17]
>> On 05/16/2017 02:38 PM, Piotr Ożarowski wrote:
>>> hint: Debian Python Policy §3.3
s talking about moving *general
purpose* Python libraries only. The rest of will continue to use the
workflow of generating orig files using "git archive".
At least, that's what I understand from our sprint meetings, and that is
if anyone (but me) in the team dares to start doing a little bit of
packaging, which I haven't seen happening so far...
Cheers,
Thomas Goirand (zigo)
k
it feels "clean".
And by the way, when it comes to the OpenStack stuff, FTP masters have
already expressed their dislike of the upstream ChangeLog: it is a *WAY*
to big, at the level of megabytes sometimes, and it may appear in .deb
files that would otherwise be a few kilobytes. All this isn't new...
Cheers,
Thomas Goirand (zigo)
On 08/07/2017 12:20 AM, Jeremy Stanley wrote:
> Thomas references the AUTHORS and ChangeLog files (which embed
> important metadata from the revision control system into the release
> tarball, far from useless in my opinion); but taking the
> nova-15.0.0.tar.gz release for example, those two files
e years, I found using this method a way better than using
"python{3,} setup.py build_sphinx". I'd suggest you try my way too.
Cheers,
Thomas Goirand (zigo)
at least would care. And would very much welcome anyone doing the work
of packaging and maintaining this kind of software.
Cheers,
Thomas Goirand (zigo)
On 10/01/2017 11:50 PM, Matthias Klose wrote:
> On 01.10.2017 21:33, Thomas Goirand wrote:
>> On 10/01/2017 09:47 AM, Ghislain Vaillant wrote:
>>> Besides, rrom an end-user perspective, I can't picture anyone preferring
>>> the (potentially lagging) packaged versi
and have Build-Profiles: for the python-foo-doc package. This
could even become a standard in the DPMT if everyone agrees.
Thoughts anyone?
Cheers,
Thomas Goirand (zigo)
On 10/04/2017 04:41 AM, Ghislain Vaillant wrote:
>
>
> On 03/10/17 22:46, Thomas Goirand wrote:
>> On 09/29/2017 01:08 PM, PICCA Frederic-Emmanuel wrote:
>>> Hello guyes.
>>>
>>>> override_dh_sphinxdoc:
>>
to add Python 3 support on as
many packages as I can, and finally get rid of Python 2, so it'd be
great if you could review it.
Note that I've added python3 support to antlr, though now I'm not sure
if xlwt even use it anymore. Maybe we should also remove it's depends?
Cheers,
Thomas Goirand (zigo)
On 10/26/2017 12:27 PM, Jan Dittberner wrote:
> On Wed, Oct 25, 2017 at 08:02:57PM +0200, Thomas Goirand wrote:
>> Hi Jan,
>>
>> I've pushed to the git a new branch called new-upstream-1.3.0, which
>> adds Python 3 support, and some improvements to the package
On 10/26/2017 03:02 PM, Thomas Goirand wrote:
> To avoid breakage, I'll wait for antlr support for Python 3 passes the
> NEW queue, and then upload. I've already merged to master.
I've found out that antlr.py is embedded, and still in use in this
upstream release. So I added
n your package. Sixer will patch the code in a way so that it
works with both Python 2 and 3.
Note that it wont do *all* for you, like you'll have to convert print
statements into function calls manually, but it does a big chunk, which
is quite helpful.
I hope that helps,
Cheers,
Thomas Goirand (zigo)
want, I can take care of importing the DPMT packages. Didn't we
have already scripts to migrate from SVN, written by tumbleweed? If we
do, then I can also do the work for apps, once they are migrated to Git.
Cheers,
Thomas Goirand (zigo)
. Asking to join on the
Alioth group is definitively *not* the procedure.
I hope that helps,
Cheers,
Thomas Goirand (zigo)
[1] https://python-modules.alioth.debian.org/policy.html
ol.
- force python 3, and directly remove the Python 2 package.
I'm open to both directions.
But before that, I'd like to make sure dput-ng is in good enough shape,
and have my peers try it. I also would like to have approval from past
maintainers of dput before the upload.
Cheers,
Thomas Goirand (zigo)
ulting this very mailing list, of course. Opinions?
>
> TIA & Cheers
I also asked myself this question for python3 only packages.
I used to have:
- python-foo
- python3-foo
- python-foo-doc
But what now that python-foo is gone? Should I rename the doc package?
Please share your thoughts,
Cheers,
Thomas Goirand (zigo)
nother package, and we have to
fallback to python-foo. Think about generic libs for compression,
images, network standards...
Which is why I think we should have standardize on python-foo for the
source package (which is what I do).
Cheers,
Thomas Goirand (zigo)
On 03/13/2018 10:11 AM, Ole Streicher wrote:
> and makes it harder for external people to find the package.
I don't see how. A query to https://packages.debian.org/foo will also
show python-foo, and same with apt-cache search. So how is it harder?
Cheers,
Thomas Goirand (zigo)
one of the 49 needed uploads).
Thanks for the list, and good that you're planning on doing this,
Cheers,
Thomas Goirand (zigo)
On 04/01/2018 11:55 PM, Thomas Goirand wrote:
> On 03/26/2018 01:32 PM, Piotr Ożarowski wrote:
>> Hi,
>>
>> Here's a list of packages that will FTBFS soon if dh-python will not be
>> added to Build-Depends (it's time to drop dh-python from python3's
>
Django environment and restart
the tests. I'm not sure how hard that would be though.
Cheers,
Thomas Goirand (zigo)
ne could use it for tests.
Cheers,
Thomas Goirand (zigo)
As far as I am aware, nothing in Debian depends on django-celery.
>
> Any thoughts?
I agree as well. Please file a bug for its removal.
Cheers,
Thomas Goirand (zigo)
hanks,
> Joseph
Hi Joseph,
I've archived the repo, which is the procedure in the team when
something goes away (at least, that's what I've been doing so far, and
unless Ondrej or others prefers something else?).
Cheers,
Thomas Goirand (zigo)
gins.
>
> Which package is the one that's failing to build now?
I agree with the above. Never the less, I don't see why we wouldn't ship
easy_install anymore, it's still useful (outside of packaging).
Cheers,
Thomas Goirand (zigo)
ok to upload to Debian later.
I hope this helps,
Cheers,
Thomas Goirand (zigo)
sor likes it, and then see if your sponsor prefers
Git only. Later on, if you get into the habits of having only 1 or 2
sponsors, then maybe you'll arrange with them to use only Git.
Cheers,
Thomas Goirand (zigo)
w about we
just do a few NMUs as a team to fix that completely in the archive?
Ondrej, what's the list of packages?
Cheers,
Thomas Goirand (zigo)
ython command, but
> maybe with a python2 command.
I very much support this proposal, and don't understand why Scott and
Piotr aren't (plus seemingly inventing things you haven't proposed).
Cheers,
Thomas Goirand (zigo)
t want. And I'm sure that
I'm not the only one confused.
Cheers,
Thomas Goirand (zigo)
sioned provides, and to Debian 8
> introducing
> the same set of python2 packages.
>
> Matthias
Hi Matthias,
We need to clear-out something.
Is your proposal includes changing:
"Build-Depends: python{,-all,-dev}"
with:
"Build-Depends: python2{,-all,-dev}"
I don't think that's part of your proposal, but it looks like someone
understood this, I'm not sure why.
Cheers,
Thomas Goirand (zigo)
On 05/20/2018 11:49 PM, Thomas Goirand wrote:
> On 05/17/2018 08:53 PM, Matthias Klose wrote:
>> PEP 394 [1] saw an update in April 2018 [2], the diffs at [3].
>>
>> The most important change from my point of view is
>>
>> -* It is suggested that even distribu
remove the minified javascript in a
patch *IF* (and only if) there is normal code next to it, which isn't
your case. So you must produce a +dfsg orig tarball.
Cheers,
Thomas Goirand (zigo)
n
> better with dgit (of course..)
The problem with git-debrebase will be the same as with git-dpm. As soon
as you try to upgrade / merge a new upstream release, you dive into a
rebase/conflict nightmare.
Cheers,
Thomas Goirand (zigo)
On 08/08/2018 01:38 PM, Nikolaus Rath wrote:
> That doesn't make sense to me. git-dpm maintains (and rebases) Debian
> patches separately, so upgrading to a new upgrade release can
> principally not be any harder than with gbp.
It is a nightmare when patches are conflicting.
> The problems with g
patch, and try to manually modify the code to do what the patch suggests
... or not! That's the important bit. Be able to see what's going on and
take a wise decision.
Cheers,
Thomas Goirand (zigo)
On 08/08/2018 09:19 PM, Nikolaus Rath wrote:
> On Aug 08 2018, Thomas Goirand wrote:
>> On 08/08/2018 01:38 PM, Nikolaus Rath wrote:
>>> That doesn't make sense to me. git-dpm maintains (and rebases) Debian
>>> patches separately, so upgrading to a new upgrade re
ks
>
> Olivier
Well, the upload of yesterday from Jan Dittberner fixed it. Just wait it
migrates to testing.
Cheers,
Thomas Goirand (zigo)
imes with OpenStack already. So, no
mater what the faith of the sphinx-build command, it's always best to
use python3 -m sphinx, IMO.
Cheers,
Thomas Goirand (zigo)
aded PBR 4.2.0-2 with lots of in debian/control,
which includes removing mock if such build profile is activated.
I hope this helps,
Cheers,
Thomas Goirand (zigo)
On 08/21/2018 10:26 AM, Ondrej Novy wrote:
> Hi,
>
> po 20. 8. 2018 v 12:37 odesílatel Thomas Goirand <mailto:z...@debian.org>> napsal:
>
> If you do the later, then anyway, you'll have to do the former if you
> need backports. This bite me a few time
s to add:
extend-diff-ignore = "^[^/]*[.]egg-info/"
in your debian/source/options file. The rest of the files are normally
cleaned automatically by dh_clean.
> I can create a .gitignore file for them?
Don't.
> or I have to push this files/folder to salsa?
Don't. Please write a correct clean target in your rules file instead.
Cheers,
Thomas Goirand (zigo)
o ok to ask for help, but that
doesn't seem to be your way. I'm kind of disappointed to see no answer
to #902631 from you in this regard, leaving the bug open for nearly 3
months now. Could you at least let Nicolas do the upload?
Cheers,
Thomas Goirand (zigo)
ams/PythonModulesTeam
https://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin
https://wiki.debian.org/Python/LibraryStyleGuide
I hope this helps,
Cheers,
Thomas Goirand (zigo)
n't like.
No. Github was using proprietary software before Microsoft's acquisition
and most Debian people advised against using Github for years before it.
Now that it has happened, it looks like a lot of people understand
better why we were saying it.
Cheers,
Thomas Goirand (zigo)
before the freeze). In any ways, it'd be nice to communicate
what you're planning on doing.
Cheers,
Thomas Goirand (zigo)
On 11/5/18 9:08 AM, Thomas Goirand wrote:
> Hi there!
>
> During Debconf, we decided we would not decide yet, and see in November
> if we think it's reasonable to allow Python 3.7 to reach Buster. Time
> has passed, RC bugs have been fixed, and now is probably the time t
t of the patch
is done as usual (except that it's done *before* the folder rename).
I hope this helps,
Cheers,
Thomas Goirand (zigo)
201 - 300 of 518 matches
Mail list logo
