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 found
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
pre
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 wo
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 will
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 t
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. e.
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 python
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 un
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 i
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 manp
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.
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
depend
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 testin
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
pytho
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( b'Cycle'+pickle.dumps(objSave
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( 'Cycle'+pickle.dum
(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 was
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 agains
> 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
wi
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 bugs
(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? o
> 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 ship
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 rebuilt
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. Expe
On 16/04/15 14:50, Paul Tagliamonte wrote:
Aloha, Developers!
Many of our projects in Debian are written in Python -- yay, Python!
However, a large chunk are implemented in Python 2 -- Booo, Python 2!
Background
==
Python 2 is scheduled to be EOL'd upstream officially and for good i
Loïc Minier wrote:
We faced this in the Ubuntu armhf port as well; the bug is described in
details there:
https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/898172
Essentially ctypes' "find_library" is very wrong and should not be used
(it tries to emulate ld.so's search behavior b
Hector Oron wrote:
Hello again,
2011/12/25 peter green :
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 &quo
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 "", line 1, in
File "/usr/lib/python2.6/dist-packages/enchant/__init__.py", lin
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."
(http://bugs.debian.org/
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 py
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 PRO
>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 embedd
34 matches
Mail list logo
