Re: Adopting OpenStack packages
Excerpts from Brian May's message of 2017-03-06 12:30:56 +1100: > The concept to convert from git-dpm to gbp pq is very very easy: > > 1. Delete debian/.git-dpm > 2. Unapply all patches. > 3. Commit and push. > > (repeat for all branches on all repositories) > > Step 2 is easier said then done. I can do it easy enough on my own > packages. I think we need a documented process anyone can follow. Plus > dealing with errors as required (e.g. if unapplying patches causes > conflicts due to non-compliant git-dpm package) - if anything like this > happens - hopefully on not many packages, these packages might require > manual processing. > > The obvious way "quilt pop -a" doesn't work, because the quilt .pc > directory does not exist, and quilt thinks the patches are already > unapplied. I sent an email previously with some (untested) suggestions I > had. > Can we do this now, and push to a branch, so that when we unfreeze we can just 'git merge --ff-only' from master and then re-do any that fail?
Re: Adopting OpenStack packages
Excerpts from Thomas Goirand's message of 2017-03-04 04:37:16 +0100: > 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, > > > > I appreciate your preferences, I really do. But the past few months have > > been a pretty harsh reminder that a bus factor of one is a dangerous > > place to be. OpenStack isn't the only project that depends on these > > Python modules, and it's bad for Debian if maintenance drops every time > > you're between jobs. You need to let go, and let us help you. > > Maintaining general Python dependencies is what DPMT is here for. I > > promise we will be mindful of OpenStack's needs. > > > > Allison > > Allison, > > I do appreciate and welcome help. But this would IMO not help. Here's why. > > 1/ The OpenStack team is as much open as the DPMT. Anyone can join. Even > better, you don't need to join, you can just send patches to Gerrit. And > any DD/DM can upload. The Gerrit CI/CD is far more advanced than the Git > on Alioth. Moving back to Alioth is a regression in may ways (safety of > data, access rights vs gerrit, workflow effectiveness, automated > testing, etc.). And I'm not even addressing yet the horrible git-dpm > troubles, how many more years the team is forcibly burying every > contributor into. Plus Alioth is a security nightmare, and it's loaded > so much that even a simple git push can take hours (real life experience). > I don't join it because it has not reached critical mass. I do love that you have built up a really nice set of automation, but I don't like that it's mostly just you. Maybe now that we have more eyes on it, we can change that, but meanwhile we can move more generic packages into DPMT and get an instant critical mass of people who will be responsive to general packaging needs that keep the release rolling forward. So even if we keep the OpenStack specific stuff in that workflow, I'd prefer that generic things be maintained by a larger team. > 2/ Stretch is frozen, and during the freeze, I continued maintaining and > closing RC bugs. I will continue to do so. I never wrote I would stop > caring for Debian packages or Debian in general. > > I wrote I cannot continue maintaining OpenStack on my free time the way > I did when I was full time, and I did so after seeing that nobody worked > on the Ocata release. But there's no meaningful RC bugs open right now, > and there's never been any for more than a few days on all the OpenStack > packages (ie: Newton release). I don't think it is giving me justice to > say I stopped caring, and that it caused trouble to Debian, the DPMT, or > any Python module/app maintainer. It did not (at least so far). > It's very troubling to me because despite all the work you've done, it's still mostly just you. I know, DPMT doesn't seem as awesome as the things you and a few others have made. But we _are_ a team, and we _will_ maintain the things that need maintaining. > 3/ The history of critical OpenStack dependencies not maintained in the > team shows the exact opposite thing that you are promising. > > SQLAlchemy and it's half finished transition during the e freeze (1.1.5 > is in Sid and haven't migrated, forcing some not-needed potentially > hand-crafted dangerous SQLA-related patches in OpenStack Newton for > Stretch) is a very good example of the maintainer being completely > careless of both the freeze of Stretch and OpenStack. I raised the topic > in the release list, the maintainer didn't even care to give meaningful > answers to valid points of argumentation (unless I raised the issue to a > tech-ctte bug), nobody seemed to care enough, and I didn't find enough > energy to fight yet another battle with the maintainer. The only option > given by the maintainer (ie: fight it through the tech-comittee) would > have been a waste of time for a lot of people, and probably would have > drained a lot of my energy at a moment were I didn't had much to spare. > So I gave up. > > Django maintainers haven't been very careful either, giving weeks > instead of the needed months for the transition, making Horizon for > Newton in Stretch very difficult to achieve. The last patch was made > after the final release, even if both upstream and myself produced > patches during more than 3 months to achieve the result. > > Nothing makes me believe this will change and maintainers in Debian will > start caring for OpenStack. > That's for _OpenStack_. We're talking about libraries here. Nobody is suggesting that DPMT take on Keystone or Horizon. > Alembic is one piece of the puzzle that may be a source of trouble in > OpenStack. Having a package inside the umbrella of the OpenStack team > has the huge advantage to tell the world that package maintainers must > care. I'm not sure it will continue to be the
Re: Best practice for adding python3 version to existing module with helper programs?
Excerpts from Neil Muller's message of 2016-06-24 00:26:25 +0200: > I'm working on packaging the latest version of sqlobject, which adds > supprt for python 3, and I'm unsure of how best to handle the helper > applications that ship as part of the package. The helper applications > will work with both python2 and python3, so it's not clear to me how > to apply the advice given in [1], and I'd ideally want the helper > programs available regardless of which version of the module is > installed. > > Looking at some other packages in the archive, there seem to be > several approaches used to solve similar problems > > a) Bundle the application in both python2 and python3 version and use > alternatives to manage the version (docutils and sphinx, for example, > although in those cases the programs are used fairly extensively as > applications) This seems like the most reasonable method, and the one I'd expect as a user.
Re: Indeed, python-concurrent.futures is the same
Excerpts from Piotr Ożarowski's message of 2014-01-31 02:05:43 -0800: [Vincent Bernat, 2014-01-31] Sandro has orphaned python-concurrent.futures: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736714 sorry to see that, unfortunately people who do something also have to have thick skin to ignore people who talk much Since it is team maintained, I don't think it really makes sense. Should we just close the bug report and remove Sandro from the Uploaders field? orphaning does make sense, packages without human in Maintainer or Uploaders fields are not allowed I would hope that a team member would feel that the team would be the first place to turn to, rather than orphaning it on the bug tracker. :-/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1391200052-sup-8...@fewbar.com
Re: Fw: [Debian Wiki] Update of Python/LibraryStyleGuide by FedericoCeratto
Excerpts from Dimitri John Ledkov's message of 2013-12-27 07:18:05 -0800: On 27 December 2013 15:00, Thomas Goirand z...@debian.org wrote: On 12/17/2013 01:02 AM, Barry Warsaw wrote: [...] You'll want to have at least the following build dependencies: * debhelper (= 8) - * dh-python * python-all (= 2.6.6-3~) * python-setuptools * python3-all * python3-setuptools Hi, Just reacting on the above change. It's my understanding that we do need to add dh-python explicitly if we want clean backports (eg: unchanged from Sid). Am I right? If that's the case, shouldn't we advise to write dh-python explicitly for until Jessie is released? Why should back-ports dictate how Jessie is developed? This is not the same requirements as e.g. dpkg where last one must be able to process all packages from the immediately next release. I don't think this is dictation, just pragmatic cooperation with a fairly popular service. And dh-python is available from backports - stable-bpo 1.20131021-1~bpo70+1 I don't understand why are you insisting on blocking migrations to dh-python. Is there some non-Debian requirement that you are omitting / not-telling here? I can't tell if you're being suspicious or leading. Either way, can we just trust each-other and use clear language? I don't see any ulterior motive there, just a desire to keep things simple. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1388160356-sup-8608@clint-HP
Re: GUI tool for packaging
Excerpts from Thomas Kluyver's message of 2012-11-09 05:19:03 -0800: This is an idea I've had knocking around for a while. Packaging is complex - there are lots of different tools and syntaxes you have to understand to do a good job of it - quilt, debhelper, watch files, etc. - along with specialist terminology. I know various CLI tools aim to simplify things, but not everything can be automated, and the tools end up with lots of options to learn about. The upshot is that most open source developers rely on a relatively small number of specialist packagers to do the rather esoteric work of preparing Debian packages. To get this to scale, I think we need to encourage more upstreams to provide packaging - whether it's for inclusion in Debian, or to provide .deb packages themselves, like Google Chrome, MongoDB and Dropbox do. As part of the effort to encourage development of Applications for Ubuntu, pkgme was created. The idea was to generate *full packages* based only on the usual metadata provided to most build systems or language-specific packaging systems. https://launchpad.net/pkgme At one point I was interested in writing a ruby backend for this, but got distracted and moved to other focus, but I think it solves what you are talking about, without need to develop a large project like a GUI. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1352951434-sup-8...@fewbar.com
Fwd: Re: Copyright and License status of transtab
Hello. I am working on preparing the 'python-translitcodec' python module for inclusion in Debian, and I've run into a snag with an ambiguous license/copyright. I contacted the author of the python module, and the attributed author of the directory in question. His reply is below. Would including the text and headers of said reply in the debian/copyright file be sufficient to meet the DFSG? I tend to think they would be, but would appreciate a +1 from those who know better than I. Thank you! --- Begin forwarded message from Markus Kuhn --- From: Markus Kuhn markus.k...@cl.cam.ac.uk To: Clint Byrum cl...@ubuntu.com Cc: Jason Kirtland j...@discorporate.us Date: Mon, 30 Jan 2012 03:23:38 -0800 Subject: Re: Copyright and License status of transtab Clint Byrum wrote on 2012-01-30 07:34 UTC: My name is Clint, and I'm working on Packaging the python library 'translitcodec' for Debian. In the course of packaging and review, its become clear that the license status of one directory of the library is ambiguous. Because Debian follows strict guidelines to both avoid liability for its developers, and also safeguard user freedom, the software won't be accepted without first clarifying this. The software in question is available here: http://pypi.python.org/pypi/translitcodec/ Jason, you are the attributed author. It claims to make use of the transtab data provided by you, Dr. Markus Kuhn. Can either of you provide documentation of the copyright status and/or license granted to this data? http://www.cl.cam.ac.uk/~mgk25/download/transtab.tar.gz Should I ever get around to making another transtab release (an old, unfinished project), I'll try to remember to add the following license text somewhere: Markus Kuhn http://www.cl.cam.ac.uk/~mgk25/ -- -mm-dd http://www.cl.cam.ac.uk/~mgk25/short-license.html Executive summary: I promise not to sue you. Hope this helped ... Markus --- End forwarded message --- -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1328040264-sup-8...@fewbar.com
Policy page is out of date with actual policy
It had been a while since I added a package to SVN, so I went hunting for the procedure and somehow ended up here: http://python-modules.alioth.debian.org/python-modules-policy.html This led me to follow the perl modules procedure, which uses -l 2, and no -o. This meant I put my modules in the wrong place in SVN. I backed them out, but this needs to be fixed. olasd in #debian-python informed me that the proper thing to do is follow this: http://wiki.debian.org/Teams/PythonAppsPackagingTeam/HowTo And just sub in modules for apps. How do we get that policy page updated? -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1327739355-sup-4...@fewbar.com
Re: RFS: python-translitcodec , python-mongokit
Excerpts from Jakub Wilk's message of Sat Jan 28 04:00:06 -0800 2012:
* Clint Byrum cl...@ubuntu.com, 2012-01-28, 00:52:
I've pushed python-translitcodec and python-mongokit into the SVN
repository.
translitcodec looks interesting. (Though I don't intend to sponsor it,
sorry. I'm boycotting dh_python2.) I will be finally able to phase out
my python-elinks[0].
Thanks for such a detailed review! Replies inline.
scripts/update_table.py tries to call sys.exit(), though it never
imports sys.
It should be:
if not (os.path.exists('translitcodec') and
os.path.exists('transtab'))
rather than:
if not os.path.exists('translitcodec') and os.path.exists('transtab')
These seem like upstream bugs that should be opened up. The script likely
does not see much use as the table doesn't change much.
Please remove the top comment from debian/rules, it doesn't make sense.
Done.
Please add Vcs-* fields.
Done.
Using debhelper (= 8) instead of debhelper (= 8.0.0) would be
more friendly to backporters.
Done.
You can remove ${shlibs:Depends} from Depends, it won't be ever
substituted.
Done.
Why Priority: extra?
I interpreted this library to match the clause in the description in
the policy manual are only likely to be useful if you already know what
they are.
Quoting DEP-5 specification: There are many versions of the MIT
license. Please use Expat instead, when it matches.
Done.
Please honour DEB_BUILD_OPTIONS=nocheck.
Done.
It would be nice to run tests with all supported Python versions, not
only the default one.
Can you recommend a good package to look at to implement this?
I wonder what is the copyright/license status of transtab directory.
Ugh. This seems very ambiguous. I'll contact the author of translitcodec
and also Markus Kuhn to get an explicit license/copyright declaration.
Lintian emits:
E: python-translitcodec source: no-human-maintainers
W: python-translitcodec source: changelog-should-mention-nmu
W: python-translitcodec source: source-nmu-has-incorrect-version-number 0.2-1
I: python-translitcodec source: debian-watch-contains-dh_make-template
Added myself into Uploaders, re-ran lintian and warnings went away.
[0] http://jwilk.net/software/python-elinks
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1327791476-sup-5...@fewbar.com
RFS: txzookeeper
Hello, I am writing to request sponsorship of a NEW package, txzookeeper 0.2.1+bzr39-1 into Debian. I've added it to the DPMT tree, and uploaded it to mentors.debian.net (which is apparently having trouble right now). Anyway, the package can be viewed in SVN here: http://anonscm.debian.org/viewvc/python-modules/packages/txzookeeper/ Thanks! -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1307577812-sup-...@fewbar.com
Re: Deadline for 10.10 updates?
On Sep 22, 2010, at 12:21 PM, Tim Michelsen wrote: When is the last date to submit an updated package? Ubuntu 10.10 is in FinalFreeze: https://wiki.ubuntu.com/FinalFreeze The Version of the Spyder Science IDE to be included in 10.10 is very outdated: http://packages.ubuntu.com/maverick/spyder spyder is in universe, so you just need to convince an archive admin that it is safe for upload. 2.0 seems to be a beta release, so that is unlikely to happen, given that 10.10 is just 2 weeks away from final release. Its also not in Debian yet. I do see that 1.1.1 is in Debian testing, you can request a sync for that version: https://wiki.ubuntu.com/SyncRequestProcess But again, given how close we are to the Maverick release, your best bet may be to submit it to backports after the release: https://help.ubuntu.com/community/UbuntuBackports Good luck! -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/80ad791f-5103-484f-84e7-ae2e02f90...@ubuntu.com
Re: Python packaging, dependencies, upstream facilities
On Sep 21, 2010, at 3:26 AM, Piotr Ożarowski wrote: [Simon McVittie, 2010-09-21] On Tue, 21 Sep 2010 at 10:30:33 +0200, Piotr Ożarowski wrote: I see only one sane way to fix the problem - changing Python interpreter to recognize API from filenames, like foo.1.py foo.2.py foo.2.3.py (with `import foo = 2` as valid syntax) and let upstream authors decide when to bump it, just like C guys do, but that's a topic for python-devel mailing list... If upstreams are going to do this, surely they could do so just as effectively without interpreter changes, by versioning the imported module? but this way you cannot `import foo` anymore, you'll have to change all import lines (s/foo/foo2/) even if your code is not affected by API change Because languages like python do runtime call resolution, they cannot, and should not, be treated like compiled languages in this respect. In python's case, if I do import foo x = foo.bar() And foo has renamed bar to baz, I won't find out until I actually run the code that calls the missing class definition. With C++, there's a class missing, and at the bare minimum, I'll fail at link time, probably during compile. Because of this, I think this is at least somewhat out of band for the interpreter, and up to the integrators and consumers of the libraries to define the requirements of a particular set of programs. In the java world, they use maven because it handles this for them. They create a maven spec file that says I need libX, libY, and libZ (v1.1). maven, during the build, goes out and finds libX and libY's latest versions, then finds the closest match to libZ v1.1. These are placed in jars in the classpath for the project, and viola it just works. Of course, java also has compile time checks, so they can actually do this with a bit more likelihood of things working (if it compiles it works, right? ;) Robert is, I think, suggesting that packaging could do this as well. Right now each python library can exist on the system once. If it conflicts, game over. But, if you can get the order of the library loading path right, then this structure solves Robert's original desire: /usr/share/pyshared/foo1 /usr/share/pyshared/foo2 /usr/share/pyshared/foo = foo2 /usr/share/pyshared/consumer-of-foo1/lib-packages/foo = /usr/share/pyshared/foo1 This would be quite easily doable in debhelper scripts, and it means that users can do 'import foo' in their code, but integrators can package things appropriately to override the whatever version with specific versions. Off the top of my head, these are a few non-trivial issues to solve: * What about instances where a dependent-library of consumer-of-foo1 also wants to 'import foo' but needs foo2? Now I have to make sure the entire chain works with foo1. How can I do that? * How do I efficiently and reliably prepend that lib-packages directory only when using consumer-of-foo1 While I think Robert described it as TERRIBLE when I suggested it the other day, the way that pylons does this, I think its at least simple and understandable. For working on the CLI, pylons simply spawns a shell that sets PYTHONPATH/PYTHONHOME. Likewise, one is required to do so when running their particular pylons based app as a web application. This allows you to run easy_install or anything else, inside that CLI, and the libraries are installed local to the application. Its not necessarily ideal, but it shows the great lengths one must go to to have multiple versions of libraries. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8ef14727-1029-47f8-bfa4-fd11fbd30...@ubuntu.com
Re: Will DPMT be ok maintaining a package that could potentially build other language bindings?
[bump] Anybody? On Jul 27, 2010, at 1:37 AM, Clint Byrum wrote: So I recently uploaded python-libgearman into the svn repository, but bzed pointed out that it didn't build from the swig bindings, and so really wasn't acceptable to upload to Debian. I agree, and now I have a source package that builds from the upstream swig sources, but this begs the question as to whether or not DPMT wants to maintain something that, long term, should also build lua and ruby bindings. Here is the branch with the packaging in it: https://code.launchpad.net/~clint-fewbar/+junk/gearman-interface-packaging If it seems ok and DPMT doesn't mind having it in the repository when we add ruby/lua bindings, then I'll check it in, otherwise I will seek more broad sponsorship for the package. Thanks! -Clint -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/35a4ee6e-e98f-426c-88ee-f6c50213a...@ubuntu.com -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c5d1920-a4e3-48ec-b7fd-744321179...@ubuntu.com
Will DPMT be ok maintaining a package that could potentially build other language bindings?
So I recently uploaded python-libgearman into the svn repository, but bzed pointed out that it didn't build from the swig bindings, and so really wasn't acceptable to upload to Debian. I agree, and now I have a source package that builds from the upstream swig sources, but this begs the question as to whether or not DPMT wants to maintain something that, long term, should also build lua and ruby bindings. Here is the branch with the packaging in it: https://code.launchpad.net/~clint-fewbar/+junk/gearman-interface-packaging If it seems ok and DPMT doesn't mind having it in the repository when we add ruby/lua bindings, then I'll check it in, otherwise I will seek more broad sponsorship for the package. Thanks! -Clint -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/35a4ee6e-e98f-426c-88ee-f6c50213a...@ubuntu.com
Re: Hello DPMT!
On Thu, 2010-07-01 at 12:21 +0200, Bernd Zeimetz wrote: Welcome to the team, I've added you some seconds ago. Please make sure you read our policy http://python-modules.alioth.debian.org/python-modules-policy.html before committing to the svn. For sponsoring requests and general discussion the best place to join is #debian-python on the OFTC network. Hint: usually we don't sponsor packages which are not in the team's svn Thanks very much Bernd. I went ahead and uploaded python-libgearman to the svn repository. I think it may be tagged a bit incorrectly, as I forgot to include my change to have the Maintainer: field set to DPMT. I committed that, but svn-buildpackage --retag didn't seem to send the tag to the repository. I would appreciate it very much if somebody could review the package, provide any feedback, and/or possibly sponsor it into Debian. Thank you! -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1278523129.13786.2.ca...@ubuntu
RFS: python-libgearman
Dear Debian Python Maintainers Team, I am looking for a sponsor for my package python-libgearman. * Package name: python-libgearman Version : 0.13.2-1 Upstream Author : Monty Taylor mord...@inaugust.com * URL : http://pypi.python.org/pypi/python-libgearman/ * License : BSD Section : python It builds these binary packages: python-libgearman - Python wrapper of libgearman The package appears to be lintian clean. My motivation for maintaining this package is: Improving support for building python applications that utilize gearman-job-server as their backend job manager. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/python-libgearman - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/python-libgearman/python-libgearman_0.13.2-1.dsc I would be glad if someone uploaded this package for me. Kind regards Clint Byrum -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1277928690.8455.15.ca...@ubuntu
