Is runpy missing from python2.6 ?
Dear Debian Python people, While testing the upgrade of a system to Squeeze, I am experiencing errors like the following: Paramétrage de python-markupsafe (0.9.2-1) ... Could not import runpy module Traceback (most recent call last): File "/usr/bin/pycompile", line 280, in main() File "/usr/bin/pycompile", line 264, in main compile(files, versions, e_patterns) File "/usr/bin/pycompile", line 194, in compile pipe.send(fn) File "/usr/bin/pycompile", line 176, in py_compile stdin.write(filename + '\n') IOError: [Errno 32] Broken pipe Apt-file suggests that runpy is only available in python2.7, that is not installed in my system. But actually, python-markupsafe is not the only module needing runpy: at least python-imaging-tk and python-pkg-resources give me the same error. So I wonder: is it an bug in the above packages, or is runpy missing from python2.6? 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/20100822120212.ga6...@merveille.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
Packaging python-mocker and cloud-init in Debian ?
Dear all, is there somebody interested to maintain or co-maintain cloud-init (and therefore python-mocker, on which it depends) in Debian ? https://launchpad.net/cloud-init http://labix.org/mocker cloud-init provides utilities to make systems "just work" on computer clouds such as the Amazon Elastic Computer Cloud, in particular: - update-grub-legacy-ec2 and its kernel hooks, to create a GRUB 1 menu file for pvgrub (no need for GRUB on the MBR itself). - facilities to download the public SSH key speficied in an instance's metadata. As a user, I am interested having these packages in Debian, but I am weak in python packaging (by the way, if somebody wants to co-maintain m2crypto...). The packages have a long history in Ubuntu (maintainers CCed), so it should be realtively straightforward to have them in Debian. Please CC me as I am not subscribed. 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/20120318081938.gb7...@falafel.plessy.net
Re: Packaging python-mocker and cloud-init in Debian ?
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. Hi Scott, 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. 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/20120321234710.gb13...@falafel.plessy.net
About #625481 and uploading python-mocker to Sid.
Dear Andrew, we are currently discussing on the debian-python list about the packaging of cloud-init in Debian, which would depend on your package, python-mocker. 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. 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/20120322000803.gc13...@falafel.plessy.net
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: About #625481 and uploading python-mocker to Sid.
Le Mon, Apr 02, 2012 at 05:55:23PM +0200, Jakub Wilk a écrit : > * Charles Plessy , 2012-04-02, 22:15: > >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. > > Sorry about that, it's fallout after the Alioth upgrade. > > >Shall I join the Alioth group ? > > Yes, joining the team might be faster than waiting until we fix the > permissions issue. Thanks ! I have injected mocker, and made a couple of package updates. http://anonscm.debian.org/viewvc/python-modules/packages/mocker/trunk/ Unfortunately, for #625481, the package still refuses to build twice in a row, although with a different error. -- dpkg-source -I -b mocker-1.0 dpkg-source: info: using source format `3.0 (quilt)' dpkg-source: info: building mocker using existing ./mocker_1.0.orig.tar.gz dpkg-source: info: local changes detected, the modified files are: mocker-1.0/mocker.egg-info/PKG-INFO dpkg-source: info: you can integrate the local changes with dpkg-source --commit dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/mocker_1.0-2.diff.u4kUvm dpkg-buildpackage: error: dpkg-source -I -b mocker-1.0 gave error exit status 2 -- The difference is: --- a/mocker.egg-info/PKG-INFO +++ b/mocker.egg-info/PKG-INFO @@ -1,4 +1,4 @@ -Metadata-Version: 1.0 +Metadata-Version: 1.1 Name: mocker Version: 1.0 Summary: Graceful platform for test doubles in Python (mocks, stubs, fakes, and dummies) I do not have time remaining today to investigate, but everybody is welcome... Also, I see that there is a new upstream release available. If anobody knows particular pros or cons for the upgrade, please let me know. 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/20120405145537.ga1...@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: 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: Packaging python-mocker and cloud-init in Debian ?
Le Mon, Apr 30, 2012 at 09:24:59PM +0900, Charles Plessy a écrit : > 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. > > python-mocker is now in Sid, maintained in the python-modules repository. I have injected cloud-init to the python-apps repository (thanks to the admins). I am currently studying how it works, and have done a couple of cleanings and updates on low-hanging fruits. Any help will be much appreciated ! http://anonscm.debian.org/viewvc/python-apps/packages/cloud-init/trunk/debian/?view=log 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/20120503140147.ga22...@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 ?
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 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 ?
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 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 Fri, May 11, 2012 at 07:54:51AM +0900, Charles Plessy a écrit : > Le Thu, May 10, 2012 at 09:24:22AM +0900, Charles Plessy a écrit : > > 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 ? I uploaded the package to Experimental (build logs attached). The main issues currently are: - The absence of init scripts (but the package might work out of the box with Upstart ?). - The debconf templates are not translated, as I did not yet understand the semantics of the Choices-C field. Once the package is accepted, we can use the BTS to better organise our work on it. Have a nice week-end, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan cloud-init_0.6.3-1_amd64.build.xz Description: Binary data
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
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
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
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
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
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: Recommending get-orig-source for packages ?
Le Wed, Dec 04, 2013 at 11:30:01AM +0100, Jakub Wilk a écrit : > * Andreas Tille , 2013-12-04, 10:41: > > >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) 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. If out of our thousands of developers, only one person did a work (and is not in situation of monopoly), then we should not veto the outcome on the basis that somebody else could have done it better. 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/20131204105810.gc21...@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 , 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
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: Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access
Le Wed, Jan 22, 2014 at 11:51:33AM +0800, Thomas Goirand a écrit : > > And here's one for pristine-tar: > [DEFAULT] > upstream-branch = upstream-unstable > debian-branch = debian-unstable > pristine-tar = True Bonus points if the Git repository on Alioth has its HEAD pointing to the debian branch (that is, the one that contains debian/gbp.conr) instead of master. In that case, the command "gbp clone" will do the right thing by tracking the relevant branches by default (which debcheckout will not). This is especially useful when using pristine-tar, because often the beginners are surprised by the error message when this branch is not directly available. 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/20140122041811.gd4...@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
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
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
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: 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: 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: 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: 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
Le Tue, Oct 21, 2014 at 12:42:56AM +0800, Thomas Goirand a écrit : > > So, just generating the orig.tar.xz from upstream Git tag, in practice, > does the same thing as pristine-tar, except that you *know* you have to > take past orig.tar.xz from the Debian archive, always, instead of > discovering that pristine-tar lead to issues. Hi Thomas, this is two separate questions: - The source of the tarball: upstream or generated by the maintainer. - Making the tarball reproducible off-line with pristine-tar. I you generate a orig.tar.xz by yourself, then you can (or have to if it is the packaging team's requirement) register it with the command “pristine-tar ”. Since it is not much work, I thing that it is fair to ask people to do it even if personally they do not use it. Also, if one happens to forget (which I of course do not encourage), another person working on the package can just download the source package from the Debian archive, and register the tarball in the pristine-tar branch with the command above. Pristine-tar is much about preparing a package update while not having access to the Debian archive at the same time. Two' invokations of git-archive will not necessary generate byte-identical tarballs. However, when updating only the Debian part of a packags, one needs an identical copy of the tarball already present in the Debian archive, or at the very least its MD5 sum. As you see pristine-tar can be more usful to some than to others, but altogether it is easy and not much involving. 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/20141020221838.GA8549@aqwa.igloo
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: 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: 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
