Re: Boto 3 and Debian
Le Mon, Jun 29, 2015 at 11:56:44PM +0200, Tomasz Rybak a écrit : There's new version of Boto, library to access AWS cloud services: https://aws.amazon.com/blogs/aws/now-available-aws-sdk-for-python-3 -boto3/ It's API-incompatible with current Boto (2.38). But both boto and boto3 can be installed at the same time. It looks like new Boto uses botocore (already in Debian, although in older version - 0.81). Are there any plans for boto3? And - how can I help? Hello Tomasz, I am not sure if the maintainers of python-botocore and python-boto read these lists; feel free to contact them directly and in any case, feel free to package boto3 ! Have a nice week-end, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150704020016.gc4...@falafel.plessy.net
Re: pybuild (Re: image-file-in-usr-lib)
Le Mon, May 11, 2015 at 09:03:53AM +0200, Ole Streicher a écrit : The Debian Policy [4] states (9.1.1): | 1. The FHS requirement that architecture-independent application- | specific static files be located in /usr/share is relaxed to a | suggestion. In particular, a subdirectory of /usr/lib may be used by a | package (or a collection of packages) to hold a mixture of | architecture-independent and architecture-dependent files. However, | when a directory is entirely composed of architecture-independent | files, it should be located in /usr/share. which is a bit contradicting to the current practice: If it is just a suggestion, then maybe the lintian warning has not right severity warning and should be lowered? And are pure python packages (Architecure: all) not covered by the last sentence and should *not* be in /usr/lib/ by policy? Hi Ole, indeed, this is a recent change in the Policy (see bugs.debian.org/741304). Probably Lintian is lagging behind. Maybe somebody can ping bug #415558 ? Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2015051108.ge1...@falafel.plessy.net
Re: [python-pysam] - 4 packages built and all lintian clean
Le Sat, Dec 06, 2014 at 08:19:39AM +, Jorge Sebastião Soares a écrit : It's been a while since I posted this first. Is someone able to have a look at this package? Hi Jorge, I am a bit short of time, but I will have a look next Wednesday if nobody does before. Cheers -- Charles -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141206083830.gf15...@falafel.plessy.net
Re: Keeping upstream commits separate from Debian packaging commits
Le Thu, Oct 16, 2014 at 02:12:40PM -0400, Hans-Christoph Steiner a écrit : I think there is a lot of value to always including the Debian upstream/v1.0 tag. It provides a standard way to access the upstream version across all repos. There is no such standard out there in the wild. There are tags like v1.0, 1.0, release-1.0, the-real-1.0, etc. etc. Note that if the name scheme is consistent within a repository, git-buildpackage can easily be configured in debian/gbp.conf. The default is “upstream-tag = upstream/%(version)s”, but that can be changed to “upstream-tag = v%(version)s”, etc. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141016223049.ga8...@falafel.plessy.net
Re: Using pristine-tar (was: Keeping upstream commits separate from Debian packaging commits)
Le Mon, Oct 13, 2014 at 10:40:00AM -0400, Barry Warsaw a écrit : I search d-d on gmane and wasn't able to find Joey's specific message about pristine-tar bitrot. pristine-tar does have a few bugs that could be relevant. I'm not sure where that leaves us though. Ah sorry, it was a message from Henrique de Moraes Holschuh. https://lists.debian.org/debian-devel/2014/08/msg00694.html Cheers, -- Charles -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141013225728.ga27...@falafel.plessy.net
Re: Using pristine-tar (was: Keeping upstream commits separate from Debian packaging commits)
Le Sun, Oct 12, 2014 at 06:14:19PM -0400, Barry Warsaw a écrit : On Oct 12, 2014, at 01:27 PM, Tristan Seligmann wrote: That's interesting, I didn't know about that. I'm not really sure I understand how dgit replaces pristine-tar, unless you assume that every tarball you want to store is in the archive. (Perhaps that's a reasonable assumption?) And since we are not planning to use dgit in DPMT (as I understand it), I'm not sure what the obvious way for us to replace pristine-tar is. In practice, I haven't seen any problems with pristine-tar. And given that archive uploads still currently require a tarball, and PyPI releases are overwhelmingly tarball-based, I think it still makes sense for DPMT to continue to use pristine-tar workflows by default. Hi Barry, in the Debian Med team, we had concrete evidence last May that the pristine-tar data bitrots with time in the way explained by Joey on debian-devel. Sorry to not have a high-quality summary to propose, but you can have a look at the following thread and do not hesitate to ask for more information on our list if you would like. http://lists.alioth.debian.org/pipermail/debian-med-packaging/2014-May/026728.html http://lists.alioth.debian.org/pipermail/debian-med-packaging/2014-June/027063.html Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141012234118.ga3...@falafel.plessy.net
Re: Keeping upstream commits separate from Debian packaging commits (was: Fighting commit storm madness)
Le Fri, Oct 10, 2014 at 11:11:46AM +0200, W. Martin Borgert a écrit : Where is the repository of the scripts involved? Maybe I have some spare time this weekend... I hope, it's all sh or Python. I forgot all my Perl. Hi Martin, good news, it is in Python :) https://github.com/mhagger/git-multimail/ Cheers, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141010095153.gd29...@falafel.plessy.net
Re: Fighting commit storm madness (was: [Python-modules-commits] [python-mplexporter] 135/135: Merge pull request #30 from rainwoodman/patch-1)
Le Thu, Oct 09, 2014 at 11:41:47PM -0400, Scott Kitterman a écrit : On Friday, October 10, 2014 11:08:53 Chow Loong Jin wrote: On Thu, Oct 09, 2014 at 07:57:48PM -0400, Scott Kitterman wrote: [..] Presumably one is the one who set up the git repos. I, for another one, would really appreciate it if someone would take care of this. Don't they all share the hook script? I've no idea. I just want the madness to stop. Hi Scott, Why do not you check by yourself ? ssh alioth.debian.org grep -L 'maxCommitEmails = 20' /git/python-modules/packages/*.git/config All Git repositories contain “maxCommitEmails = 20” in their config file, which will strongly mitigate the problem. Somebody modified all these files on Oct 9 around 8 am UTC, and I guess that this was to add this parameter. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141010035641.gb29...@falafel.plessy.net
Re: Fighting commit storm madness (was: [Python-modules-commits] [python-mplexporter] 135/135: Merge pull request #30 from rainwoodman/patch-1)
Le Fri, Oct 10, 2014 at 12:03:38AM -0400, Scott Kitterman a écrit : Changing the number of commits is solving the wrong problem. The problem that needs to be solved is including upstream commits. That's thoroughly uninteresting for a packaging team. Also, it's not just the mails, it's the IRC bot too (I believe the IRC bot acts off the repository, not mails). In my experience, when updating the upstream branch, the number of upstream commits is usually higher than 20, and therfore the push of the upstream branch will generate a single message. Cheers, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141010054912.gc29...@falafel.plessy.net
Re: Fwd: [Python-modules-commits] [python-mplexporter] 135/135: Merge pull request #30 from rainwoodman/patch-1
Le Tue, Sep 23, 2014 at 10:29:10PM +0100, Sandro Tosi a écrit : Hi all, there's some people who's subscribed to the commit ml, so getting all the changes done to our repos. Now, with the transition to git we are getting this: 135 emails for updating a package (and these are only upstream changes). Did you consider this side effect? Do you have a plan to reduce the amount of noise it causes reducing dramatically the SN ratio on the ml? Hello everybody, the commit messages are sent with git-multimail (https://github.com/mhagger/git-multimail/), and I recommend to set multimailhook.maxCommitEmails to something around 20 in each repository's configuration file. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140923224658.gc9...@falafel.plessy.net
What is the most idiomatic way in Debian to modify defaults in setup.py ?
Hello everybody, to enable dynamic linking to a C library in a python module (instead of static linking), an upstream author proposes me to either implement an option in setup.py or to make it query an environment variable. With the goal of using the most standard packaging tools, can you recommend me one or the other solution ? Also, to discover the include path, can I recommend upstream to use the pkg-config file of the library, or is there a better solution ? The module is python-pysam, to name it. Thanks for your help, and have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140821221433.gb...@falafel.plessy.net
Which maintainer for cloud-init, now in collab-maint (Git) ?
Dear all, I have moved the source package of cloud-init on Alioth from python-apps (Subversion) to collab-maint (Git). Shall I replace “Python Applications Packaging Team” in the Maintainer field by something else, or would the current situation be OK ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140412085944.gd14...@falafel.plessy.net
Re: Which maintainer for cloud-init, now in collab-maint (Git) ?
Le Sat, Apr 12, 2014 at 11:59:38AM +0200, Piotr Ożarowski a écrit : [Charles Plessy, 2014-04-12] Shall I replace “Python Applications Packaging Team” in the Maintainer field by something else, or would the current situation be OK ? yes, please remove PAPT/DPMT from Maintainer/Uploaders fields Done, thanks for the fast answer. -- Charles -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140412235629.gb10...@falafel.plessy.net
Re: Recommending get-orig-source for packages ?
Le Tue, Dec 10, 2013 at 05:35:08PM +1100, Ben Finney a écrit : By my reading of ‘copyright-format/1.0’ (the “Machine-readable debian/copyright file” specification), the normative place for that information is the “Source” field: Source Formatted text, no synopsis: an explanation of where the upstream source came from. Typically this would be a URL, but it might be a free-form explanation. The Debian Policy section 12.5 requires this information unless there are no upstream sources, which is mainly the case for native Debian packages. If the upstream source has been modified to remove non-free parts, that should be explained in this field. Because of that explicit specification, and that such repacking needs to be in an automated program or configuration anyway and explained in the “Source” field, I think adding another special place for this information is unnecessary duplication. Hi Ben, http://bugs.debian.org/685506 tracks the proposal of adding a Files-Excluded in the next version of the specification. Your comment implies that the definition of the Source field should be changed together with the addition of Files-Excluded, and I think that it is totally doable. People who like the information to be in debian/copyright worked on an implementation that is used and now supported in devscripts. In contrary, people who like the information to be somewhere else, however good are their reasons, did not produce a viable alternative. Unless there is a concrete commitment for creating a robust and well-accepted alternative, I think that there is no point discussing the issue further. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20131210085912.gd23...@falafel.plessy.net
Re: Recommending get-orig-source for packages ?
Le Wed, Dec 04, 2013 at 12:13:48PM +0100, Jakub Wilk a écrit : * Charles Plessy ple...@debian.org, 2013-12-04, 19:58: Well, there was a lenthy discussion, uscan bug, Wiki page trying to summarise everything. The people who contributed did not brought up your (and Paul's concern) and I guess Charles Plessy would have been in favour of using d/upstream. I do not think it is my fault if you did not raised you voice when it was time ... https://lists.debian.org/debian-policy/20130116133513.ga4...@jwilk.net (actually https://lists.debian.org/20130116133513.ga4...@jwilk.net) D'oh. Hi Jakub, Debian has what its developers implement. I am sure that if somebody steps up and does the actual work of implementing a better solution and migrating the existing information, Andreas will complain. s/complain/comply/ perhaps? D'oh as well. Indeed, I meant will not complain, sorry for the noise... -- Charles -- 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/20131204114901.gd15...@falafel.plessy.net
Bug#726262: O: python-m2crypto -- a crypto and SSL toolkit for Python
Package: wnpp Severity: normal Subject: O: python-m2crypto -- a crypto and SSL toolkit for Python Le Mon, Sep 23, 2013 at 12:44:56PM +0900, Charles Plessy a écrit : m2crypto currently has 5 bugs of severity Important, which I am not able to solve. I was wondering if Dima was planning to solve them or is the Python modules team would be interested in taking care of m2crypto together with Dima. The source package is currenlty maintained in Git with patches commited direclty to the master branch. Since this is definitely not (yet ?) a standard way, please let me know if you would like me to convert it to a more classical packaging style. Le Sat, Oct 05, 2013 at 08:46:18AM +0900, Charles Plessy a écrit : Dima, I think that I will orphan the package if you do not answer. Anyway, it is easy to be reverted. In case I orphan the package, would the Python modules team interested in adopting it ? Since nobody answered to my emails, I orphan this package. -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20131013232514.ga25...@falafel.plessy.net
Re: Future of the m2crypto package in Debian.
Le Mon, Sep 23, 2013 at 12:44:56PM +0900, Charles Plessy a écrit : m2crypto currently has 5 bugs of severity Important, which I am not able to solve. I was wondering if Dima was planning to solve them or is the Python modules team would be interested in taking care of m2crypto together with Dima. The source package is currenlty maintained in Git with patches commited direclty to the master branch. Since this is definitely not (yet ?) a standard way, please let me know if you would like me to convert it to a more classical packaging style. Hello again, Dima, I think that I will orphan the package if you do not answer. Anyway, it is easy to be reverted. In case I orphan the package, would the Python modules team interested in adopting it ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20131004234618.ga8...@falafel.plessy.net
Future of the m2crypto package in Debian.
Dear Dima and Python team, I have participated to maintain the m2crypto in the past two year because it was a required package for euca2ools. But since the version 3 of euca2ools, this is not the case anymore, and I would like to remove myself from the Uploaders field. m2crypto currently has 5 bugs of severity Important, which I am not able to solve. I was wondering if Dima was planning to solve them or is the Python modules team would be interested in taking care of m2crypto together with Dima. The source package is currenlty maintained in Git with patches commited direclty to the master branch. Since this is definitely not (yet ?) a standard way, please let me know if you would like me to convert it to a more classical packaging style. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20130923034456.gd25...@falafel.plessy.net
Anybody intersted in packaging boto's requestbuilder ?
Hello everybody, Sorry for the cross-post... Please follow up on debian-cl...@lists.debian.org if you feel that reply-all is not appropriate. I would need a python-requestbuilder package for updating euca2ools to version 3.0.0, but I am severly over-commited for the next months at least, so I would prefer not to maintain one more package. Would somebody be interested in packaging requestbuilder ? (preferably in collab-maint with Git or python-modules with Subversion) https://github.com/boto/requestbuilder Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20130616012456.ga7...@falafel.plessy.net
About m2crypto.
Hello everybody, there are five long-standing bugs on the m2crypto package that are above my level. If somebody would be interested to look at them, that would be great ! http://bugs.debian.org/src:m2crypto Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20130506064700.gd20...@falafel.plessy.net
Re: How does team maintenace of python module works?
Le Wed, Feb 20, 2013 at 11:02:15PM -0500, Scott Kitterman a écrit : On Thursday, February 21, 2013 11:08:13 AM Chow Loong Jin wrote: ... That argument applies to any VCS that you don't use on a daily basis. You use bzr on a daily basis and forget how to use git. I use git on a daily basis and forget how to use svn/bzr and have to relearn it any time someone forces me to use one of those. I don't think this is a valid reason for avoiding git. ... It is to a degree, but the learning curve for git is subtantially steeper than for other VCS. I've learned CVS, SVN, BZR, and Git at one time or another and there is no question in my mind which one, by a lot, is the most complex to learn. Dear Scott, I undertand that learning Git after BZR is hard, because learning BZR after Git is equally painful. I think that the key difficulty is whether a system is learned first or second, not the system itself. This is where git-buildpackage is nice, as it re-implements the same user experience as with svn-buildpackage, and therefore provides some kind of upgrade path. Cheers, -- Charles Plessy -- 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/20130221060056.ga1...@falafel.plessy.net
Re: Packaging python-mocker and cloud-init in Debian ?
Le Thu, May 10, 2012 at 09:24:22AM +0900, Charles Plessy a écrit : If Upstart works out of the box on lean Debian systems (I never checked), how about uploading first to experimental, so that others can help testing the package. Then, once init scripts and perhaps systemd are ready, and once we agree that the package is in shape for unifying with Ubuntu, I will upload to Unstable, probably after the Wheezy freeze. I have now: - Deleted all the parts related to pv-grub. - Reverted the removal of the dpkg diversion of ureadahead. (Tracking the issue in https://bugs.launchpad.net/ubuntu/+source/ureadahead/+bug/997838) The package still does not have init scripts. Do you or the Python Apps team think it would be a blocker for an upload to Experimental ? Once the package is in Debian, I can subscribe to the VCS commits, and we can use the bug tracking system... Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- 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/20120510225451.ga11...@falafel.plessy.net
Re: Packaging python-mocker and cloud-init in Debian ?
Le Wed, May 09, 2012 at 03:20:50AM -0400, Scott Moser a écrit : I proposed the idea to the grub2 maintainers in http://bugs.debian.org/672104. I spoke to Colin Watson about this today, and he suggested that grub2 was not the right place for this. But, he would help/sponsor a grub-legacy-ec2 package into debian. So I think we'll chase that. Great. I followed up in http://bugs.debian.org/672104. I propose to move the discussion there, as it becomes off-topic for python-apps. In the meantime, I consider uploading a version of cloud-init where grub-legacy-ec2 and all the diversions have been removed. Would this make your work hader in Ubuntu ? As long as you're willing to work towards a unified package in the future, I'm not opposed to that. The biggest missing piece is the sysvinit scripts. I don't think you added any, did you? Not yet. To be honest, I never used cloud-init either, but it looks it will do many of the things I need. Co-maintainers are much welcome ! If Upstart works out of the box on lean Debian systems (I never checked), how about uploading first to experimental, so that others can help testing the package. Then, once init scripts and perhaps systemd are ready, and once we agree that the package is in shape for unifying with Ubuntu, I will upload to Unstable, probably after the Wheezy freeze. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- 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/20120509235403.ga18...@falafel.plessy.net
Re: Packaging python-mocker and cloud-init in Debian ?
Le Sat, May 05, 2012 at 01:29:24PM -0400, Scott Moser a écrit : On Sat, 5 May 2012, Charles Plessy wrote: I think that your proposition to separate grub-legacy-ec2 is good, especially that in Debian, the plan is to maintain cloud-init in the python applications packaging team, and grub-legacy-ec2 has nothing to do with Python. It looks like ideally, the functions of grub-legacy-ec2 could be attached to the grub2 package so that they can share their configuration. How about if I contact the grub2 maintainers and tell about the need to create menu.lst in pv-grub-booted systems, proposing grub-legacy-ec2's code as a starting point ? I think that sounds like a good idea. Hi again, I proposed the idea to the grub2 maintainers in http://bugs.debian.org/672104. In the meantime, I consider uploading a version of cloud-init where grub-legacy-ec2 and all the diversions have been removed. Would this make your work hader in Ubuntu ? Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- 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/20120509044935.ge...@falafel.plessy.net
Re: Packaging python-mocker and cloud-init in Debian ?
Hi again, I think that the best start would be to upload a lean version of cloud-init, see below for details. Would it inflict you a significant work overhead ? Le Fri, May 04, 2012 at 03:18:45PM -0400, Scott Moser a écrit : On Fri, 4 May 2012, Charles Plessy wrote: - In the cloud-init packiage they are used to disable ureadahead. Isn't there a more propre way for package A to disable a service provided by package B ? If ureadahead must never run when cloud-init is installed, its upstart job could test if cloud-init is installed and exit in that case. Or, if ureadahead and cloud-init should not be installed together, wouldn't a simple Conflicts: statement solve the problem ? Disabling of readahead via diversion is the correct path in my opinion. ureadahead is a dependency of 'ubuntu-minimal'. So that is why we've not conflicted with it. ureadahead does not make sense in any virtual machine. cloud-init was designed to run in virtual machines... so we disable it. I sampled opinions on the matter on debian-mentors, and the one answer I had for the moment is also supporting that it is ureadahead that should contain what is necessary for not running in presence of cloud-init. I can keep the current Ubuntu code in the Debian package, but if somebody would upload ureadahead to Debian, I think that would made cloud-init seriously buggy according to Debian's policy. So if possible, I would prefer to keep the code out. - In the grub-legacy-ec2, diversions are used to take over grub-set-default from grub-legacy or grub2-common. These two packages manage this situation by conflicting with each other. Wouldn't it be simpler to also conflict with grub-legacy and grub2-common, or are there situations where they should be installed together ? grub-legacy-ec2 does conflict with grub. grub-legacy-ec2's purpose in life is to manage /boot/grub/menu.lst without worrying about installing a bootloader. This is because EC2 instances typically boot via pv-grub, which is a grub-alike that lives outside the image, but reads /boot/grub/menu.lst from inside the image. It explicitly does not conflict with grub-pc so you can create one image (like one from cloud-images.ubuntu.com) that can run with grub-pc as the bootloader or pv-grub as the bootloader. On Debian Sid, grub depends on grub-pc, which is grub 2. So cloud-init in Debian should at least be corrected to conflict against grub-legacy. For the use of grub-pc and grub-legacy-ec2 at the same time, do you forsee cases where there would need different defaults for grub-legacy-ec2 and grub-pc ? I think that your proposition to separate grub-legacy-ec2 is good, especially that in Debian, the plan is to maintain cloud-init in the python applications packaging team, and grub-legacy-ec2 has nothing to do with Python. It looks like ideally, the functions of grub-legacy-ec2 could be attached to the grub2 package so that they can share their configuration. How about if I contact the grub2 maintainers and tell about the need to create menu.lst in pv-grub-booted systems, proposing grub-legacy-ec2's code as a starting point ? Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- 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/20120505132122.ga24...@falafel.plessy.net
Re: Packaging python-mocker and cloud-init in Debian ?
Le Sat, May 05, 2012 at 01:29:24PM -0400, Scott Moser a écrit : On Sat, 5 May 2012, Charles Plessy wrote: I can keep the current Ubuntu code in the Debian package, but if somebody would upload ureadahead to Debian, I think that would made cloud-init seriously buggy according to Debian's policy. So if possible, I would prefer to keep the code out. which policy would that be? IIRC, I was advised to do the dpkg-divert by an experienced debian developer. /etc/init/ureadahead.conf is a conffile of ureadahead, as defined in Debian Policy's section 10.7.1, and the section 10.7.4 mandates that the maintainer scripts must not alter a conffile of any package, including the one the scripts belong to. use of grub-pc and grub-legacy-ec2 at the same time, do you forsee cases where there would need different defaults for grub-legacy-ec2 and grub-pc ? I'm sorry, I'm not sure what you mean by 'defaults'. If you mean which kernel to boot, there is some unfortunate code in grub-legacy-ec2 that explicitly ignores certain kernels by kernel name because they're known not to boot (due to buggyness of kernel, not config... thats largely historical). I mean the 'default' (sorry for the plural in my previous message) set by the grub-set-default program that is diverted. It looks like both grub-set-default-legacy-ec2 and grub-pc's grub-set-default modify /boot/grub/default, so if the same value makes sense for both grub-legacy-ec2 and grub-pc, there would not need to divert grub-pc's file, but rather to depend on grub2-common, which distributes grub-set-default and does not depend on grub-pc. Have a nice Sunday, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- 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/20120506000707.gb10...@falafel.plessy.net
Re: Packaging python-mocker and cloud-init in Debian ?
Le Thu, May 03, 2012 at 11:24:34AM -0400, Scott Moser a écrit : My goal would be to keep minimal changes from debian to ubuntu, and the code there does not cause any issues that i'm aware of if there is no readahead installed. Is there some policy that explicitly calls that out? For ureadahead in particular, I was worried that it could cause problems as the package does not exist in Debian. After reading how diversions work (I never used them before), it looks like it would be harmless to keep that Ubuntu-specific code in the package for Debian. But more in general, I wonder if diversions are the good tool here. - In the cloud-init packiage they are used to disable ureadahead. Isn't there a more propre way for package A to disable a service provided by package B ? If ureadahead must never run when cloud-init is installed, its upstart job could test if cloud-init is installed and exit in that case. Or, if ureadahead and cloud-init should not be installed together, wouldn't a simple Conflicts: statement solve the problem ? - In the grub-legacy-ec2, diversions are used to take over grub-set-default from grub-legacy or grub2-common. These two packages manage this situation by conflicting with each other. Wouldn't it be simpler to also conflict with grub-legacy and grub2-common, or are there situations where they should be installed together ? I am now looking at update-grub-legacy-ec2. It uses debconf and ucf directly, wich make the package more complex (and will trigger extra work for the translations). It looks like this was carried over from Ubuntu's grub-legacy package. Is it still necssary in grub-legacy-ec2's context ? Otherwise, I would be tempted to remove that part, in order to simplify the package. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- 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/20120504021021.gb5...@falafel.plessy.net
Re: Packaging python-mocker and cloud-init in Debian ?
Le Thu, Mar 22, 2012 at 08:47:10AM +0900, Charles Plessy a écrit : Le Tue, Mar 20, 2012 at 10:57:34AM -0400, Scott Moser a écrit : The grub stuff is only in the ubuntu package, and arguably should be separate source from cloud-init entirely. Basically, it maintains /boot/grub/menu.lst without conflicting with grub-pc. it is actually grub-legacy-ec2 that drove my attention to cloud-init. It looks like it would be very useful to Debian as well. I am looking for a solution to create a machine image in a fully autmodated way with debian-installer. In my understanding, preseeding 'd-i pkgsel/include string cloud-init grub-legacy-ec2' (with perhaps extra preseeding for the packages themselves) would make the image bootable by pvgrub and reachable via SSH. This said, I do not mind if the two binary packages come from the same source package or not. Before this, I guess the first step is to fix #625481 and get python-mocker in Sid. Hello everybody, python-mocker is now in Sid, maintained in the python-modules repository. In my understanding, python-apps would be suitable for the 'cloud-init' package. Can one admin add me ? Cheers, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- 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/20120430122459.gb1...@falafel.plessy.net
Re: About #625481 and uploading python-mocker to Sid.
Dear Andrew and everybody, I just uploaded mocker 1.0-2 to unstable. The source package is available at the followign URLs: Vcs-Svn: svn://svn.debian.org/python-modules/packages/mocker/trunk/ Vcs-Browser: http://anonscm.debian.org/viewvc/python-modules/packages/mocker/trunk/ The upload closed #625481, but I am not sure which change solved the problem. The next task is cloud-init. Would there be a volunteer ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20120411140434.gb16...@falafel.plessy.net
Re: Bug#625481: About #625481 and uploading python-mocker to Sid.
Version 1.0-2 Le Thu, Apr 05, 2012 at 08:33:45PM +0200, Jakub Wilk a écrit : This is a very common problem with (packages using) setuptools. The idiomatic solution is to nuke the whole *.egg-info directory in the clean target, or add it extend-diff-ignore. Thanks a lot, that solved the problem. Among all the changes between 1.0-1 and 1.0-2, one fixed the original problem (cannot represent change to mocker-1.0/.coverage: binary file contents changed). I could not trace which change in particular did. Or maybe the toolchain evolved ? Anyway, I am closing this bug. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- 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/20120411141947.ga11...@plessy.org
Re: About #625481 and uploading python-mocker to Sid.
On Thu, Mar 22, 2012 at 09:08:03AM +0900, Charles Plessy wrote: I see that you have not adressed yet #625481 for a couple of monthes. If it is by lack of time or interest in the package, would you be like to co-maintain it within the Debian Python Modules Team's Subversion repository ? Alternatively, if you prefer Git, we could place the package in collab-maint or in pkg-eucalyptus, for instance. Le Fri, Mar 23, 2012 at 08:53:24AM +1300, Andrew Mitchell a écrit : Fixing #625481 uploading to unstable had slipped off my todo list, sorry. I'll take a look at uploading python-mocker this weekend. I'm also fine with it being maintained within the DPMT repository. Dear Debian Python Modules Team, I tried to inject mocker in svn+ssh://svn.debian.org/svn/python-modules/packages, but it is not anymore writable for all DDs. Shall I join the Alioth group ? Have a nice day, (please CC me) -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- 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/20120402131539.ga10...@falafel.plessy.net
Re: [Debian-med-packaging] Bug#596318: mgltools-bhtree: python2.5-dev used as build-dependency, not python-dev or python2.6-dev
Le Fri, Sep 10, 2010 at 09:58:14AM +, Matthias Klose a écrit : Package: mgltools-bhtree Version: 1.5.4.cvs.20090603-1 Severity: serious User: debian-python@lists.debian.org Usertag: python2.6 The package build-depends on python2.5-dev, which is not the default python version for squeeze. The package should be rebuilt with python2.6, either build-depending on python-dev (recommended) or python2.6-dev. Hello Matthias, Is there any reason why you filed a bug against 1.5.4.cvs.20090603-1 instead of asking for an unblock of 1.5.4.cvs.20090603-1.1. Didn't that NMU solve the problem (see #586852). I am confused and puzzled what to do now. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- 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/20100911124147.gb6...@merveille.plessy.net
