Mailman 3 October 2011 - Distutils-SIG

config file handling in bdist_rpm
by Matthew Richardson 20 Oct '11

20 Oct '11

I'm currently using the bdist_rpm method to build rpms. I've had a look through the distutils source, and it seems to generate a %files section in the specfile and just put everything in there. Would it be possible to extend bdist_rpm to also use the %config section for config files, so that these are properly identified in the rpm and thus not removed or overwritten on rpm changes? Thanks, Matthew -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

[Bug] Zip: Compressed size is set to a non-zero value when uncompressed size is set to zero
by Alan Haggai Alavi 19 Oct '11

19 Oct '11

Hello, .ZIP archive generation using setuptools seems to generate an invalid archive. The attached archive was created with setuptools: python setup.py sdist --format=zip Analysing the hexdump and Zip-Parser's (https://github.com/alanhaggai/ Zip-Parser) output (attached file: zip_parser.out) it seems that the archive is corrupt. In its local file header and central directory file header for Foo-0.2.0/bar/__init__.py, compressed size is set to 2 (the compressed data being 0x03 and 0x00). Uncompressed size is set to 0! This has been confirmed using Ark (KDE archiving tool) and a snapshot has been attached. More details can be read at the bug reported against Archive::Zip Perl module - https://rt.cpan.org/Public/Bug/Display.html?id=68446 When zipfile was used to create the archive (that is, without using setuptools) this faulty behavior was not noticed. Please let me know if there is anyway that I can help. Attachment files: - http://alanhaggai.org/files/Foo-0.2.0.zip - http://alanhaggai.org/files/ark.png - http://alanhaggai.org/files/zip_parser.out Regards, Alan Haggai Alavi. -- The difference makes the difference.

2 2

[issue135] Problem with bdist_rpm with rpm 3.0.5
by Chris Dukes 14 Oct '11

14 Oct '11

New submission from Chris Dukes <chris.dukes.aix(a)gmail.com>: I need to support bdist_rpm with the older version of RPM (3.0.5) that ships with AIX. %install python setup.py install --single-version-externally-managed -O1 --root=$RPM_BUILD_ROOT --record=INSTALLED_FILES leads to a file list ending with the egg-info directory after listing the files in the egg-info directory. %files -f INSTALLED_FILES %defattr(-,root,root) RPM 3.0.5 ends up recursing the egg-info directory a second time and reporting all the files in the egg-info directory as duplicates and fails when building the RPM. Thanks, Chris Dukes ---------- messages: 644 nosy: chris.dukes.aix priority: bug status: unread title: Problem with bdist_rpm with rpm 3.0.5 _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue135> _______________________________________________

1 0

buildout & develop
by Andrea Crotti 07 Oct '11

07 Oct '11

I am in the current situation, I have an application that uses a lot of libraries (ETS / pyqt...). In plus there for every application there are a lot of eggs, which are actually directory eggs. At the moment we run everything in a brutal way messing up with the system, but I thought that we can change this using - a pypi server on localhost - zc.buildout and smarter setup.py files To run in production mode it looks relatively easy, build the eggs in a place where the pypiserver looks and run everything. But is it possible to use the equivalent of "setup.py develop"? Ideally whenever I save a new file it should run the python setup.py develop only for that where it belongs, any idea on how to do something like this?

4 4

Persistent system-level files across installations
by Mac Ryan 06 Oct '11

06 Oct '11

I am using stdeb to produce my debian packages and I am a novice when it comes to packaging in general, so bear with me if I am mixing together apples and oranges and just help me understanding better... What I am trying to achieve is to have certain files of my application that are persistent across software updates in other words: updating from mypackage-1.0 to mypackage-1.0.1 should imply overwriting only certain files of the v.1.0 if present, but not all of them. These "persistent files" are application-specific and not user-specific (i.e. they don't live in the /home/* hierarchy). [If this information is of any use: said files are sqlite files with usage statistic] My questions: At what level should I manage this? It is something I have to manage within my application (1), within my setup.py configuration script (2), or is something I am obliged to handle by dropping stdeb and packaging for debian "from scratch" (3)? Any link to examples very much appreciated! Thank you in advance for your time! :) /mac

3 4