Just done some reviewing/tweaking. I've pushed the following changes to the git
repo, please
tell me if you have any objections.
I added a gpb.conf to make git-buildpackage actually use pristine tar and hence
result in an orig
tarball that was consistent with what is already in Ubuntu.
I
python-numpy* is no longer buildable in testing due to the removal of the
"cython" binary package.
The maintainer has requested removal of python-numpy from unstable but the
ftpmasters have not yet
actioned it, presumably because there are still reverse-dependencies in
unstable. A rc bug is
I would like to join the DPMT, there are a couple of reasons for this.
Firstly I have been making an effort to try and get broken build-dependencies
in testing fixed, and this often ends up involving python module packages. It
would be easier to fix such packages as a member of the team than
On 21/04/2020 22:20, Thomas Goirand wrote:
So, if I'm following correctly, what you seem to propose, is to remove
Python 2 from unittest2. If that's the case, then I agree with such a
plan. I just didn't dare to do it yet.
Yes, whichever approach is taken to dealing with funcsigs, unittest2
If my understanding is correct I see two possible ways forward.
1. Rebuild python3.8 against the new glibc.
2. Remove the stropts include from samba, it doesn't seem to actually be used
for anything (at least I can't find any other references to HAVE_STROPTS_H in
the code).
I am currently
The samba FTBFS is blocking the python 3.8 transition in raspbian bullseye, so
I decided to take a look.
error: Unable to determine origin of type `struct cli_credentials'
I don't think this is the error that is causing the build failure. The same error can be seen
in succesful build logs.
Relevant packages and bugs:
943107 git-buildpackage: Python2 removal in sid/bullseye
This bug is not marked as rc.
Nevertheless I believe that this bug report is in-fact a false positive. From
what I can tell git-buildpackage, even in buster, does not (build-)depend on
python 2 or any
There's another kind of issue
Yeah, sadly the transition tracker only looks at unstable, so packages that are
fixed in unstable but haven't migrated to testing for some reason won't show up.
; here is an example :
- sagemath builds only for Python 3.7, so some of this subpackages
don't load
I just took a look at the "add python3.8 transition tracker", and split the remaining
"bad" packages into categories.
Key package, rc bug with patch.
* gpgme1.0 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944774
Not key package, but not marked for autoremoval from testing
* macs version
On 07/12/2019 15:09, Håvard Flaget Aasen wrote:
If you still wish to disable tests for python 2, you might be looking for this
export PYBUILD_DISABLE_python2=test
That line in debian/rules should work.
You have some more options here: https://wiki.debian.org/Python/Pybuild
and perhaps the
On 07/12/2019 07:47, peter green wrote:
It would be preferable to only disable the testsuite for python2, but I have no
idea how to do that, so my current debdiff disables the testsuite completely, I
also ran into an issue with the package's clean target not cleaning up properly.
Just
zope.interface is currently rc buggy because of an unsatisfiable
build-depenency on python-zope.event, the package is also orphaned.
The package is a key package, so the issue won't be dealt with by autoremovals,
furthermore the python-zope.interface package has quite a stack of reverse
Package: python-sponge
Severity: serious
x-debbugs-cc: debian-python@lists.debian.org
While looking at some python2 removal issues, I came across python sponge. I
noticed the following about the package.
* Python 2 only.
* Only one maintainer upload (and one NMU) ever.
* Not in stable or
matplotlib2 seems to be an important node in the python2 removal/reduction
problem (and the qt4 removal problem). I have noticed there are a substantial
number of python module packages that it build-depends on but does not depend
on.
python-backports.functools-lru-cache
python-cairocffi
pylint3 is now a cruft package, however it still has a fair few reverse
dependencies, from
https://ftp-master.debian.org/users/dktrkranz/NBS
* source package pylint version 2.2.2-4 no longer builds
binary package(s): pylint3
on all
- suggested command:
dak rm -m "[auto-cruft] NBS
> tmp = rt.encrypt('Cycle{}'.format(pickle.dumps(objSave)))
Thanks to this hint
This hint was *wrong*, it will introduce garbage into the string and the
"rotor" code is clearly designed to work with byte strings, not unicode strings.
Change it to
"tmp=rt.encrypt(
but this leads later to
Traceback (most recent call last):
File "cycle.py", line 83, in OnCloseWindow
Save_Cycle(cycle.name, cycle.passwd, cycle.file)
File "/home/andreas/debian-maintain/salsa/med-team/cycle/save_load.py", line
46, in Save_Cycle
tmp=rt.encrypt(
(note for people reading on bug 934333, the start of this thread can be found
at https://lists.debian.org/debian-python/2019/08/msg00070.html )
On 13/08/2019 11:54, Andrey Rahmatullin wrote:
This is worrying, a package with revdeps shouldn't have been dropped.
AIUI a "go cleanly" approach
Hi
I've been looking at various python 2 cruft packages (packages no longer built
by the corresponding source packages) and why they can't be cleaned up, I have
been looking in a derivative but many of my results are also relevant to debian
proper. Where relevant I have been filing bugs
> No one in Debian (or Ubuntu) reported it.
That is hardly surprising, most Debian/Ubuntu users will be using the default
python3 version.
IMO (I am just a random dd) if Debian is going to switch the default python
version for buster it should be done ASAP to maximize the amount of testing
pygame in Debian testing is currently python2 only, I am sure I am not alone in
thinking this is not a good state of affairs given that pygame is frequently
used for introducing people to programming.
pygame in sid has python3 support but is held back from migrating to testing by
three rc
(sorry if this is long winded, but I feel the need to explain the situation
so-far, the important bit of this mail is the last few paragraphs)
python-gevent cannot currently be built in testing because it has a build-dependency on
python-greenlet (>= 0.4.13) but testing only has 0.4.12-2. This
I am looking into cleaning up some software so it can be uploaded to Debian.
Inside the documentation folder is a copy of the python logo. I found the
python.org page for the logo more confusing than helpful.
1. Is the python logo under a license acceptable for including in a Debian
package?
> However, in Debian case, I do not know how this can be handled as 2 packages
cannot hold the same file (even if __init__ is only an empty file), and at least
one must be present (if you install only one).
I'm not a python expert but I expect the least-horrible way to do this would be
to
Package: libapache2-mod-wsgi-py3
Version: 4.3.0-1
Severity: serious
Tags: stretch sid
x-debbugs-cc: debian-python@lists.debian.org
I run a derivative called raspbian and I noticed our auto-binnmuer was
repeatedly binnmuing mod-wsgi. Further investigation reveealed that
every time it was
One python package used heavilly in the raspberry pi community is
pygame. Unfortunately the package hasn't had an upstream stable release
since 2009 and the upstream stable release doesn't support python3.
Currently sid has the latest upstream stable release and no
python3-pygame package.
While investigating the build failure of scim-python on armhf I
discovered that importing enchant with python 2.6 fails on armhf
root@debian:/# python2.6 -c import enchant
Traceback (most recent call last):
File string, line 1, in module
File
package: adonthell
version: 0.3.5-4
severity: serious
x-debbugs-cc: debian-python@lists.debian.org
During the run up to the lenny release python 2.5 was made the default
and this made adonthell FTBFS on arm(el) with Fatal Python error:
exceptions bootstrapping error.
tags 486654 +patch
thanks
Rebuilding with gcc-4.2 fails in the same way, so I guess it is due to
Python changes.
The package builds succesfully on arm (I don't have armel availible to
test but I presume the issue is the same on both) with python2.4. I have
attatched a patch to make it use
Anyway, given that 0.3.4.cvs.20050813-3 compiled but
0.3.4.cvs.20050813-4 didn't, I guess this is somehow related to
gcc-4.3.
It looks like the default python version also changed between the two
builds from 2.4 to 2.5 so that would be a suspect too.
--
To UNSUBSCRIBE, email to [EMAIL
make[4]: Entering directory
`/build/buildd/adonthell-0.3.4.cvs.20080529/src/modules'
../../src/adonthell-0.3 -c
*** warning: prefs::read_adonthellrc: creating config file failed
Fatal Python error: exceptions bootstrapping error.
Something is going wrong with the intitalisation of the embedded
31 matches
Mail list logo
