k: Do not rename libraries from e.g.
vtkClientServerPython.so to
vtkClientServerPython.cpython-38-x86_64-linux-gnu.so!
+ dh_python3 -V $(PY3RANGE) --no-ext-rename # Hack: Do not rename
libraries from e.g. vtkClientServerPython.so to
vtkClientServerPython.cpython-38-x86_64-linux-gnu.so!
ove
ioned in the original bug report now have
either built cleanly recently or have been removed for other reasons.
There doesn't seem much point in keeping this bug open now.
Thanks,
--
Colin Watson (he/him) [cjwat...@debian.org]
recently). Does upstream test with
the latest version?
--
Colin Watson (he/him) [cjwat...@debian.org]
On Mon, Dec 16, 2024 at 01:58:14AM +, Colin Watson wrote:
> While there are a few bits of that transition tracker still red, the
> current target is to work on the list of autopkgtest failures shown on
> https://tracker.debian.org/pkg/python3-defaults in order to get the
> additio
On Tue, Dec 17, 2024 at 12:53:42PM +, Julian Gilbey wrote:
> On Mon, Dec 16, 2024 at 01:58:14AM +0000, Colin Watson wrote:
> > [...]
> > * spyder: #1088068/#1089054.
>
> I'm struggling with this one; I've asked at
> https://github.com/spyder-ide/spyder/issue
On Tue, Dec 17, 2024 at 12:06:08PM +, Colin Watson wrote:
> On Tue, Dec 17, 2024 at 08:44:39AM +0100, Simon Josefsson wrote:
> > I noticed that 1.2.0-1 migrated to testing, so I did an upload to
> > finalize the packaging move and it now live here:
> >
> > https://s
and
drop "--with python3" from debian/rules.
--
Colin Watson (he/him) [cjwat...@debian.org]
chitecture-specific failures showing up
there. Some might go away with a few more retries I guess, but we'll
likely need to work out what to do about the rest. I haven't looked at
these in any depth.
Can anyone help with any of the remaining problems here? This would be
especially usefu
f
> existing python-zombie-imp.
I think that should only be done where the PyPI name starts with
"zombie-" (or I suppose where it doesn't exist - but if we need it and
it doesn't exist then IMO somebody should upload it to PyPI first, as
namespace clas
OK, done, and I asked #debian-ftp to reject the un-namespaced package
from NEW.
Thanks,
--
Colin Watson (he/him) [cjwat...@debian.org]
ace "import pipes" with
"import shlex" and "pipes.quote" with "shlex.quote"; that seems to be
all that this script needs.
--
Colin Watson (he/him) [cjwat...@debian.org]
ed, or
would it be possible to do this mass bug-filing at sub-RC level so that
there's a convenient list in the BTS?
Thanks,
--
Colin Watson (he/him) [cjwat...@debian.org]
ell, all that technology is
old and cruft, and we have shiny new goodness in aiosmtpd.
Rather than bringing it up to date, presumably as a wrapper around
aiosmtpd, I think it's better to declare this package abandoned and
remove it from Debian.
Thanks,
--
Colin Watson (he/him) [cjwat...@debian.org]
. This is a very complicated way to write
`sys.version_info >= (3, 2)` though!
--
Colin Watson (he/him) [cjwat...@debian.org]
help
with maintaining the packages as well.
My Alioth login is 'cjwatson'.
I have read https://python-modules.alioth.debian.org/policy.html and I
accept it.
Thanks,
--
Colin Watson [cjwat...@debian.org]
signature.asc
Description: Digital signature
x27;, '',
'phpldapadmin (<= 1.0~)', '', [], []],
+packages = {'phpldapadmin': ['1.0', 'web', 'phpldapadmin', '1.0', 'all', None,
'', 'apache2 (>= 2.0)', '', '', [], []
lude socket support.
Socket support does seem to be there:
$ dpkg -c
/mirror/ubuntu/pool/main/p/python2.4/python2.4-minimal_2.4.2-1ubuntu2_i386.deb
| grep socket
-rw-r--r-- root/root 49608 2006-01-17 12:59:02
./usr/lib/python2.4/lib-dynload/_socket.so
kages that had been broken became newly installable
due to this change that a single new uninstallable package could be
tolerated. Once the release-critical bugs affecting it are fixed,
python-ldap can move in in its own time.
(Phew!)
Cheers,
--
Colin Watson [
On Tue, Oct 07, 2003 at 07:28:23PM +0200, Matthias Klose wrote:
> Colin Watson writes:
> > For what it's worth, I think a python-defaults source package or some
> > such would help: at the moment there are several packages needlessly
> > stalled on python2.3, even tho
u know there was a particular version of pythonX.Y that your package
> doesn't work with.
The versioned dependency is probably generated automatically by
dpkg-shlibdeps:
$ cat /var/lib/dpkg/info/python2.3.shlibs
libpython2.3 1.0 python2.3 (>= 2.3)
I assume that this means binaries
version of python2.3 in testing, so if people can
please have patience until Wednesday, we can get testing updated and
then go on with our lives.
Cheers,
--
Colin Watson [EMAIL PROTECTED]
me is too
difficult at the moment. Anthony?
The remaining buggy packages are cyrus-sasl2, heimdal, and pyddr. I'll
file an actual bug on pyddr tomorrow if nobody beats me to it.
Cheers,
--
Colin Watson [EMAIL PROTECTED]
s needlessly
stalled on python2.3, even though their dependencies are simply
'python2.3 (>= 2.3)' or similar. If the python binary package were built
from a separate source package then we could decouple transitions from
the task of keeping the versioned packages up to date.
--
Colin Watson [EMAIL PROTECTED]
On Tue, Sep 30, 2003 at 12:25:29PM +1000, Donovan Baarda wrote:
> On Tue, 2003-09-30 at 06:50, Matthias Klose wrote:
> > Colin Watson writes:
> > > While this would probably help users, it won't make the transition
> > > easier as far as testing is concerne
On Mon, Sep 29, 2003 at 10:48:11PM +0200, Matthias Klose wrote:
> Colin Watson writes:
> > Buggy packages
> > ==
>
> gnue-* is missing here.
No; gnue-common in testing depended on python2.1, not python. The
version in unstable should certainly be fixed, bu
On Mon, Sep 29, 2003 at 03:21:42PM -, Alastair wrote:
> From: Colin Watson <[EMAIL PROTECTED]>
> > Missing builds
> > ==
> >
> > * newt: hppa
>
> Is this an error /out of date? From the archive,
> it appears that hppa is up-to-date on ne
complete
so that we have something more or less releaseable first?
--
Colin Watson [EMAIL PROTECTED]
On Mon, Sep 29, 2003 at 12:16:37PM +0100, Mikhail Sobolev wrote:
> is libmetakit-python missing from this list for a reason?
It depends on python2.2, which isn't a problem as far as testing's
concerned. Packages depending on 'python (>= 2.2), python (<< 2.3)' ar
g and so on. It would be helpful if we
could regard Python packages as being in a mini-freeze for the moment,
with RC bug fixes only; having to wait for lots of 10-day testing delays
is going to be a pain otherwise.
Cheers,
--
Colin Watson [EMAIL PROTECTED]
: extra
Section: web
Installed-Size: 316
Maintainer: Colin Watson <[EMAIL PROTECTED]>
Architecture: all
Version: 1.0.0-8
Depends: python (>= 2.2), python (<< 2.3)
Suggests: www-browser, httpd
Filename: pool/main/l/linbot/linbot_1.0.0-8_all.deb
Size: 66042
MD5sum: 4407d81a7c9757feb401d156
ordination from
upstream, or being able to use a single libsip. I agree that it's ugly,
though.
Do libsip upstream set any sonames? Is it important that binaries linked
against it on Debian can be run on other distributions?
--
Colin Watson [EMAIL PROTECTED]
31 matches
Mail list logo
