Re: python-phonenumbers
Hi Renaud On 2024-08-14 09:05:14 +0200, Renaud Thiry wrote: > Hello, python team! > > We've been having issues with this package not formatting some numbers > properly in debian bullseye-slim > > As it's due to an environmental change (namely international phone formats > changing in brazil, mexico and others since the current version of the > package was released), I understand it would be valid to submit a stable > update. > > Is there anyone who could handle that, and if not could you point me > towards a guide of some sort for me to submit an updated version of the > package? The process to prepare fixes for (old)stable is documented at https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#upload-stable. Note however that bullseye will become LTS tomorrow (see https://wiki.debian.org/LTS) and the final point release will happen on August 31st (see https://lists.debian.org/debian-release/2024/07/msg00231.html). After that, the bug would need be fixed via LTS. Cheers -- Sebastian Ramacher
Re: Autoremoval mails for python-passlib
-passlib, flagged for > removal in 29.2 days >tryton-modules-sale-subscription: buggy deps python-passlib, flagged for > removal in 29.2 days >tryton-modules-sale-supply-drop-shipment: buggy deps python-passlib, > flagged for removal in 29.2 days >tryton-modules-sale-supply: buggy deps python-passlib, flagged for removal > in 29.2 days >tryton-modules-sale: buggy deps python-passlib, flagged for removal in > 29.2 days >tryton-modules-stock-forecast: buggy deps python-passlib, flagged for > removal in 29.2 days >tryton-modules-stock-inventory-location: buggy deps python-passlib, > flagged for removal in 29.2 days >tryton-modules-stock-location-sequence: buggy deps python-passlib, flagged > for removal in 29.2 days >tryton-modules-stock-lot-sled: buggy deps python-passlib, flagged for > removal in 29.2 days >tryton-modules-stock-lot: buggy deps python-passlib, flagged for removal > in 29.2 days >tryton-modules-stock-package-shipping-dpd: buggy deps python-passlib, > flagged for removal in 29.2 days >tryton-modules-stock-package-shipping-ups: buggy deps python-passlib, > flagged for removal in 29.2 days >tryton-modules-stock-package-shipping: buggy deps python-passlib, flagged > for removal in 29.2 days >tryton-modules-stock-package: buggy deps python-passlib, flagged for > removal in 29.2 days >tryton-modules-stock-product-location: buggy deps python-passlib, flagged > for removal in 29.2 days >tryton-modules-stock-shipment-measurements: buggy deps python-passlib, > flagged for removal in 29.2 days >tryton-modules-stock-split: buggy deps python-passlib, flagged for removal > in 29.2 days >tryton-modules-stock-supply-day: buggy deps python-passlib, flagged for > removal in 29.2 days >tryton-modules-stock-supply-forecast: buggy deps python-passlib, flagged > for removal in 29.2 days >tryton-modules-stock-supply-production: buggy deps python-passlib, flagged > for removal in 29.2 days >tryton-modules-stock-supply: buggy deps python-passlib, flagged for > removal in 29.2 days >tryton-modules-stock: buggy deps python-passlib, flagged for removal in > 29.2 days >tryton-modules-timesheet-cost: buggy deps python-passlib, flagged for > removal in 29.2 days >tryton-modules-timesheet: buggy deps python-passlib, flagged for removal > in 29.2 days >tryton-server: buggy deps python-passlib, flagged for removal in 29.2 days > > -- > > Mathias Behrle > PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 > AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6 > -- Sebastian Ramacher signature.asc Description: PGP signature
Re: pyacoustid: upstream update and various packaging improvements
Hi Lars
On 2018-07-16 01:25:37, Lars Kruse wrote:
> Hello,
>
> I am a member of the DPMT, but no DD or DM.
> This is supposed to be my first package upload within the DPMT, thus please be
> patient, in case I misunderstand the procedure.
>
> My proposed changes of the package include the following:
> * migrate from git-dpm to gbp
> * update upstream (closing all open bugs)
> * add initial autopkgtests
> * updates of policy version and compat level
>
> I prepared a merge request with my changes:
> https://salsa.debian.org/python-team/modules/pyacoustid/merge_requests/1
>
> The git-dpm migration requires a branch renaming ("master" ->
> "debian/master").
> The upstream update requires an update of the upstream branch.
> Thus the merge request is not fully self-contained. See my forked repository
> for
> the complete updated environment:
> https://salsa.debian.org/sumpfralle-guest/pyacoustid/
>
> I am not sure, how to proceed now, but I could imagine the following steps:
> 1) someone takes the time to review my changes (maybe followed by fixes from
> me)
> 2) I push my changes (including a debian/??? version tag) to the
>packaging repository within DPMT (and delete my forked repository)
> 3) the reviewer sponsors the upload of the package
>
> I am looking forward to your comments or reviews.
Thanks for taking care of pyacoustid. I'm no longer active in the Python teams,
but as long as you follow their best practices, it should be easy enough to find
a sponsor on the Python mailing list (or via sponsorhip-requests).
Cheers
--
Sebastian Ramacher
signature.asc
Description: PGP signature
Re: Review/sponsorship of osmalchemy package
On 2016-10-03 11:19:10, Piotr Ożarowski wrote: > [Sebastian Ramacher, 2016-10-03] > > > > > why? I know ftp-masters change all packages from optional to extra > > > > > but I > > > > > probably missed an announcement about the reason... > [...] > > Where is the myth that they change priority to extra even coming from? > > all my NEW packages have extra by default even though I set optional. > > See f.e. python-async-timeout > At least on https://packages.qa.debian.org/p/python-async-timeout.html > (which also states section=misc instead of python). In the past I also > received an email after *each* upload about section mismatch. This is the section and priority of the *source* package (which to my understanding does not have any meaning at all). The binary packages correctly have % apt-cache show python3-async-timeout | egrep "Section|Priority" Section: python Priority: optional Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Re: Review/sponsorship of osmalchemy package
On 2016-10-03 10:12:04, Piotr Ożarowski wrote: > > >> * Please set "Priority: extra" and not optional. > > > > > > why? I know ftp-masters change all packages from optional to extra but I > > > probably missed an announcement about the reason... > > > > > > Because of > > https://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities > > maybe? :) > > I don't see anything new here. I always used optional unless one of > dependencies was already non-optional. If libraries get Priority=extra > by default, where do f.e. -doc packages go now? Where is the myth that they change priority to extra even coming from? Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Re: pep8 build depends on jessie
On 2016-05-01 20:21:26, Brian May wrote: > Hello, > > If I try to build a package on Jessie using sbuild that has > "python-pep8 | pep8" in the build depends, it gives me the > following error: > > --- cut --- > Installing build dependencies > Reading package lists... > Building dependency tree... > Reading state information... > Some packages could not be installed. This may mean that you have > requested an impossible situation or if you are using the unstable > distribution that some required packages have not yet been created > or been moved out of Incoming. > The following information may help to resolve the situation: > > The following packages have unmet dependencies: > sbuild-build-depends-shortuuid-dummy : Depends: python-pep8 but it is not > installable > E: Unable to correct problems, you have held broken packages. > apt-get failed. > E: Package installation failed > Not removing build depends: cloned chroot in use > --- cut --- > > Why isn't it falling back to installing pep8 when python-pep8 is not > available? Isn't this the expected behaviour? Or have I got something > wrong? That's expected behavior. sbuild only considers the first alternative. Regards -- Sebastian Ramacher signature.asc Description: PGP signature
Re: git repo lint tool
On 2015-10-13 16:30:53, Stefano Rivera wrote: > codespeak-lib: Non-Canonical Vcs fields codespeak-lib is no longer in the archive. > Sebastian Ramacher >breathe >flask-openid >python-libdiscid (U) They are no longer maintained under the DPMT umbrella. Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Re: dh_python3 and dh_strip
Hi On 2015-04-28 12:20:32, Dmitry Shachnev wrote: > I have noticed that my python3-sip4-dbg package does not have debug symbols > for the python3 extension (i.e. sip.cpython-34m-x86_64-linux-gnu.so). > > That package does not use distutils/setuptools, but uses its own build > system instead. In debian/rules, we make sure that: > > - python3 extension is installed into > debian/python3-sip/usr/lib/python3.4/dist-packages/sip.so > > - python3 extension for debug interpreter is installed into > debian/python3-sip/usr/lib/python3.4/dist-packages/sip_d.so > > Yes, this is a bit Python 2 style, but we want to let dh_python3 do the > proper renaming instead of doing that ourselves. > > The we call "dh_strip -ppython3-sip --dbg-package=python3-sip-dbg", which > creates a debug symbols file at > debian/python3-sip-dbg/usr/lib/debug/usr/lib/python3.4/dist-packages/sip.so. > > But then dh_python3 is called and it does the following renaming: > > I: dh_python3 fs:90: renaming > debian/python3-sip-dbg/usr/lib/debug/usr/lib/python3.4/dist-packages/sip.so > to > debian/python3-sip-dbg/usr/lib/debug/usr/lib/python3.4/dist-packages/sip.cpython-34dm-x86_64-linux-gnu.so > > That file contains the debugging symbols for the extension built for > non-debug interpreter, so it should be renamed to > sip.cpython-34m-x86_64-linux-gnu.so, not sip.cpython-34dm-x86_64-linux-gnu.so. > > Is there any way to make dh_python3 use the correct file name here? > > I have tried changing debian/rules to run dh_strip *after* dh_python3, > but then (for some reason) it leaves > /usr/lib/python3.4/dist-packages/sip.cpython-34dm-x86_64-linux-gnu.so > unstripped, which is wrong AFAIK. You could bump compat to 9 and use debug symbol files based on the build id. This should circumvent any filename based problems. Cheers -- Sebastian Ramacher signature.asc Description: Digital signature
Re: pybuild and -dbg packages
On 2015-04-01 20:15:04, Nikolaus Rath wrote: > Hi, > > I recently switched the python-llfuse package to use pybuild. However, > this seems to have a side effect that the debugging symbols for the C > extension are no longer included in the -dbg package, so it now contains > only the extension build for the debug interpreter. Is that deliberate? > > I think that either the debugging symbols shouldn't be stripped from the > extension for the regular interpreter, or the stripped symbols should be > included in the -dbg package. But currently neither is the case. In the process of converting it to pybuild, you've droppped the dh_strip override. Bring it back and the debug symbols should be back in -dbg. Cheers -- Sebastian Ramacher signature.asc Description: Digital signature
Re: Python-babel 1.3 available from Sid
On 2013-10-08 12:52:35, Thomas Goirand wrote:
> On 10/08/2013 03:34 AM, Sebastian Ramacher wrote:
> > Hi
> >
> > On 2013-10-08 00:50:27, Thomas Goirand wrote:
> >> Hi,
> >>
> >> FYI, I have uploaded python-babel 1.3 in Sid. I couldn't wait for more,
> >> so I did the work...
> >>
> >> I haven't pushed to the SVN, because git-svn is producing some weird
> >> errors. Andrey, could you push the changes?
> >>
> >> Cheers,
> >>
> >> Thomas
> >
> > How about you clean up the mess you've created?
> >
> > Andrey clearly stated in the bug that he's working on it
>
> He wrote that on Wed, 28th of Aug 2013. That's a long time ago, and as I
> couldn't wait for more, as some or my packages for OpenStack
> (build-)depends on Babel 1.3.
For a package that had to go through NEW anyway that's really no excuse.
Pinging him and waiting a day or two for a reply doesn't hurt.
> > and changed the topic of #debian-python to look for a sponsor.
>
> I'm sorry that I missed it, and that I got fooled by the wrong VCS
> fields in the old package. Though probably writing in this bug would
> have been more efficient than writing in the topic of the IRC channel?
That's what we tell non-DDs to do. [1] says:
Sponsorship requests can be sent on the main discussion list or on
#debian-python IRC channel (OFTC network).
[1] http://python-modules.alioth.debian.org/python-modules-policy.html
> > So you could have at
> > least asked Andrey what's the status of the packaging and helped him
> > upload the changes he has prepared in the repository.
> >
> > I find this behavior very inappropriate.
>
> You want to talk about behaviors and include the -python list to add
> some fun? Let's do that if you think that helps (I think it's a huge
> waste of time). wRAR/Andrey's behavior is bordeline with me on IRC all
> the time, and it starts to be quite annoying. I'd like this type of
> harassment to to stop right away: it's not fun to read at all.
If I wanted to have fun I'd laugh about it somewhere private and go on.
But this is an team issue as our DDs appearently don't know where
non-DDs are supposed to look for a sponsor. But what's even worse is
that instead of sorting out personal issues with a team member, his work
is thrown away.
> > Apart from that your changes in debian/copyright are wrong.
>
> Would you care explain what is wrong there?
Copyright 2007-2013 Edgewall Software is wrong. AUTHORS and LICENSE
should give you a hint what's actually true.
> > debian/changelog is inaccurate (python-pybabel is still there).
>
> Yes right, because I saw that there was still some reverse dependencies
> and reverted my change, then forgot to also revert the changelog. I have
> filled bugs against packages that still depends on pybabel and I think
> it's best to wait until they are fixed.
>
> > There is no ${python:Recommends}.
>
> What do you mean there's no ${python:Recommends}?
dpkg-gencontrol: warning: Recommends field of package python-babel: unknown
substitution variable ${python:Recommends}
...
dpkg-gencontrol: warning: Recommends field of package python3-babel: unknown
substitution variable ${python3:Recommends}
> > Why does python-babel-doc depend on
> > python3-pkg-resources and why is ${sphinxdoc:Depends} missing?
>
> This is a bad copy/past which should be fixed. Not a huge deal to fix
> though (the bulk of the work in the other parts of the package was the
> most important bit of what was urgently needed).
That's no excuse to upload an unfinished package.
Regards
--
Sebastian Ramacher
signature.asc
Description: Digital signature
Re: Python-babel 1.3 available from Sid
On 2013-10-08 09:13:54, Vincent Bernat wrote: > ❦ 8 octobre 2013 07:18 CEST, Andrey Rahmatullin : > > >> Though probably writing in this bug would > >> have been more efficient than writing in the topic of the IRC channel? > > > Yes, that's my only mistake. > > Though of course it's a fundamental problem with non-DD packages: I've > > made a package I find ready for uploading, I've built and deployed it > > locally, I've published the changes, I've used some method to notify > > potential sponsors and I don't have any motivation to spend any more > > effort to get it uploaded. > > Please, ask here. That's not what we tell our non-DD members. [1] says Sponsorship requests can be sent on the main discussion list or on #debian-python IRC channel (OFTC network). Regards [1] http://python-modules.alioth.debian.org/python-modules-policy.html -- Sebastian Ramacher signature.asc Description: Digital signature
Re: Python-babel 1.3 available from Sid
Hi
On 2013-10-08 00:50:27, Thomas Goirand wrote:
> Hi,
>
> FYI, I have uploaded python-babel 1.3 in Sid. I couldn't wait for more,
> so I did the work...
>
> I haven't pushed to the SVN, because git-svn is producing some weird
> errors. Andrey, could you push the changes?
>
> Cheers,
>
> Thomas
How about you clean up the mess you've created?
Andrey clearly stated in the bug that he's working on it and changed the
topic of #debian-python to look for a sponsor. So you could have at
least asked Andrey what's the status of the packaging and helped him
upload the changes he has prepared in the repository.
I find this behavior very inappropriate.
Apart from that your changes in debian/copyright are wrong.
debian/changelog is inaccurate (python-pybabel is still there). There is
no ${python:Recommends}. Why does python-babel-doc depend on
python3-pkg-resources and why is ${sphinxdoc:Depends} missing?
Regards
--
Sebastian Ramacher
signature.asc
Description: Digital signature
Re: RFS: python-keyring 1.4-1
On 2013-06-18 18:21:27, Dmitry Shachnev wrote: > >> > What's the status of all the other tests? Many tests are skipped because > >> > of missing dependencies. > >> > >> Gnome-keyring-daemon refuses to run in xvfb. As I do not know other > >> Secret Service implementations, it's currently impossible to test > >> GNOME and Secret Service backends (libsecret's upstream testsuite has > >> some code for mocking Secret Service, but I didn't yet have time to > >> test it). > > > > If we can't run them reliably I'd rather see them disabled. > > These tests either succeed or are skipped — i.e. do not affect the > build. Why should we disable them? Because they cause the package to FTBFS if python-secretstorage is installed and there's no gnome-keyring or dbus session available. > >> Python-fs is too old in Debian (python-keyring needs at least 0.4), so > >> this test can't be run also. > > > > What about the gdata tests? > > Gdata is a Google backend, so these tests do nothing when you don't > have an internet connection. Also (with my python-gdata maintainer hat > on), I would avoid adding any new (build-)dependencies on it because > it's mostly dead and unmaintained code. Fine with me then. Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Re: RFS: python-keyring 1.4-1
On 2013-06-14 14:55:58, Dmitry Shachnev wrote: > Thanks for your review. > > On Wed, Jun 12, 2013 at 2:34 AM, Sebastian Ramacher > wrote: > > I'd put the script in /usr/share/doc/python-keyring or > > /usr/share/python-keyring. There's no need to put it in /usr/bin. > > It's now in /usr/share/python-keyring. I think lines 48 and 49 can be removed too. > > Also, I wouldn't copy the the master password from the old keyring to the > > new one. If the user already created a new Crypto keyring with a different > > password, this would destroy it. I'd also make it more explicit when asking > > for the password that it's the password for the old keyring. > > Fixed. > > >> Note that it fails to build when python3-secretstorage is installed > >> (see upstream #102), but there is no problem when you are building in > >> chroot. > > > > So either > > - get ImportKiller fixed, > > - disable ImportKiller based tests for Python 3.3 for now or > > - add python3-secretstorage and python3-gi to Build-Conflicts. > > ImportKiller is fixed now. > > > What's the status of all the other tests? Many tests are skipped because > > of missing dependencies. > > Gnome-keyring-daemon refuses to run in xvfb. As I do not know other > Secret Service implementations, it's currently impossible to test > GNOME and Secret Service backends (libsecret's upstream testsuite has > some code for mocking Secret Service, but I didn't yet have time to > test it). If we can't run them reliably I'd rather see them disabled. > Python-fs is too old in Debian (python-keyring needs at least 0.4), so > this test can't be run also. What about the gdata tests? It currently FTBFS twice in a row: | dpkg-source: info: local changes detected, the modified files are: | python-keyring-1.4/keyring.egg-info/PKG-INFO | python-keyring-1.4/keyring.egg-info/SOURCES.txt | python-keyring-1.4/keyring.egg-info/dependency_links.txt | python-keyring-1.4/keyring.egg-info/entry_points.txt | python-keyring-1.4/keyring.egg-info/requires.txt | python-keyring-1.4/keyring.egg-info/top_level.txt Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Re: RFS: python-keyring 1.4-1
On 2013-06-11 18:47:12, Dmitry Shachnev wrote:
> On Sun, Jun 9, 2013 at 10:05 PM, Sebastian Ramacher
> wrote:
> > If nobody beats me to it, I'll take a look at it later next weak. Did
> > you have a look at the open bugs? Also, 1.0 dropped support for the
> > auto-conversion of pre-0.9 Crypto based backends. Although wheezy has
> > the code to convert the the storage, I think it'd be a good idea to
> > at least mention the fact in NEWS.Debian and maybe also provide a script
> > to convert old keyrings.
>
> Done (though needs someone else to test it, as discussed in IRC).
I'd put the script in /usr/share/doc/python-keyring or
/usr/share/python-keyring. There's no need to put it in /usr/bin. Also,
I wouldn't copy the the master password from the old keyring to the new one. If
the user already created a new Crypto keyring with a different password,
this would destroy it. I'd also make it more explicit when asking for
the password that it's the password for the old keyring.
> Note that it fails to build when python3-secretstorage is installed
> (see upstream #102), but there is no problem when you are building in
> chroot.
So either
- get ImportKiller fixed,
- disable ImportKiller based tests for Python 3.3 for now or
- add python3-secretstorage and python3-gi to Build-Conflicts.
What's the status of all the other tests? Many tests are skipped because
of missing dependencies.
The version from PyPI is versioned as 1.4. The version from bitbucket as
1.4dev. 1.4dev is not PEP 386 compatible version and breaks anything
having a requirment on keyring >= 1.4 in setup.py or using
pkg_resources.require:
| >>> import pkg_resources as p; p.require("keyring >= 1.4")
| Traceback (most recent call last):
| File "", line 1, in
| File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 696, in
require
| needed = self.resolve(parse_requirements(requirements))
| File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 598, in
resolve
| raise VersionConflict(dist,req) # XXX put more info here
| VersionConflict: (keyring 1.4dev (/usr/lib/python2.7/dist-packages),
Requirement.parse('keyring>=1.4'))
Regards
--
Sebastian Ramacher
signature.asc
Description: Digital signature
Re: RFS: python-keyring 1.4-1
On 2013-06-08 15:06:11, Dmitry Shachnev wrote: > Hi, I would like to request sponsorship of python-keyring package. This > is a major update, done with maintainer's permission. > > Changelog: > > * New upstream release. > * Switch debian/watch to use .tar.bz2 archives from BitBucket, rather than > .zip archives from PyPI; drop unzip build-dependency. > * Recommend python[3]-secretstorage, as the default backend now uses it. > * Suggest python[3]-gi and gir1.2-gnomekeyring-1.0, as the GNOME Keyring > backend now uses it. > * Suggest python-gdata and python-keyczar, as other backends use them. > * Drop all previous patches, applied upstream. > * debian/patches/no-pytest-runner.patch: do not require pytest-runner, > it is not in Debian. > * Bump Standards-Version to 3.9.4 and debhelper compat level to 9. > * Disable HTTP traffic in debian/rules. > * Run upstream testsuite during build; simplify other debian/rules parts. > * Build-depend on python[3]-mock and python[3]-crypto, for the testsuite. > * Remove build directory in clean target. > * Update some file names to match upstream renamings. If nobody beats me to it, I'll take a look at it later next weak. Did you have a look at the open bugs? Also, 1.0 dropped support for the auto-conversion of pre-0.9 Crypto based backends. Although wheezy has the code to convert the the storage, I think it'd be a good idea to at least mention the fact in NEWS.Debian and maybe also provide a script to convert old keyrings. Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Re: pytaglib: looking for a sponsor
Hi Michael,
here is my incomplete review of pytaglib.
On 2013-03-04 15:05:09, Michael Helmling wrote:
> I am looking for a sponsor for my "pytaglib" package, which is a library for
> accessing metadata ("tags") of audio files.
>
> Pytaglib essentially binds two functions of the popular TagLib C++ library
> which were introduced in version 1.8, providing a unified, format-independent
> way of reading and writing arbitrary tags. In my opininon this makes pytaglib
> very small (and thus easy to maintain) yet powerfull because you can do
> virtually anything you want without having to care about the particular file
> format.
>
> The library is available for both python2 and python3. Packages have been
> uploaded to mentors (https://mentors.debian.net/package/pytaglib) as well as
> the python-modules SVN repository. As far as I can tell, there are no formal
> problems left in the package, at least lintian does not complain.
>
> I'd be happy if anyone would be willing to sponsor the package. The bindings
> are written in Cython, so it might be beneficial if a potential sponsor has
> come across that software, although the code should be well-readable by
> anyone
> who understands python and perhaps a little C++.
>
> Comments, criticism and questions are generally welcome. :-)
* How does pytaglib compare to python-tagpy?
* Why Priority: extra? I'd use optional.
* AFAICT there is need to list libtag1c2a (>= 1.8) in python(3)-taglib's
Depends. That's what dh_shlibdeps will create anyway since pytaglib is
using symbols from >= 1.8.
* Is this really Python >= 2.7 only? The only things that look
incompatible to 2.6 are in setup.py and can be fixed easily.
* Please build the extensions also for the debug interpreter and
ship them in python(3)-taglib-dbg.
* Is there a reason why the files listed in extend-diff-ignore aren't
just removed in the clean target?
* lintian4py emits:
p: python3-taglib: SOURCES.txt-in-binary-package
p: python-taglib: SOURCES.txt-in-binary-package
* The GPL-3 paragraph is missing the part starting with "This program
is distributed ..." and it should also refer to
/usr/share/common-licenses/GPL-3.
* doc/pyprinttags.1 is Copyright 2013. That's missing in
debian/copyright. Other files also have Copyright something-2013.
Regards
--
Sebastian Ramacher
signature.asc
Description: Digital signature
RFS: python-crypto (adopting package)
Hi, I am looking for a sponsor for the new version 2.3-1 of my package "python-crypto". It builds these binary packages: python-crypto - cryptographic algorithms and protocols for Python python-crypto-dbg - cryptographic algorithms and protocols for Python (debug extensio python-crypto-doc - cryptographic algorithms and protocols for Python (documentation) The package appears to be lintian clean. The upload would fix these bugs: 532121, 617001, 625238 The package can be found in the svn repository at svn+ssh://svn.debian.org/svn/python-modules/packages/python-crypto I would be glad if someone uploaded this package for me. Kind regards, -- Sebastian Ramacher signature.asc Description: OpenPGP digital signature
Request to join the DPMT
Hi, I would like to join the DPMT to maintain the "python-crypto" package with the team. "python-crypto" has been orphaned and I intend to adopt it [1]. In the course of my RFS [2] on the debian-mentors list, Jakub Wilk has asked me to join the team [3]. My alioth login is sramacher-guest. Kind regards, [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=532121 [2] http://lists.debian.org/debian-mentors/2011/03/msg00269.html [3] http://lists.debian.org/debian-mentors/2011/04/msg00163.html -- Sebastian Ramacher signature.asc Description: OpenPGP digital signature
