[issue5243] Missing dependency in distutils build
New submission from Patrick Gerken : When running the command install_lib, the command build_clib is not run. If a package contains clibs they can be dependencies for extension libs, at least that is stated in the module docstring of build_clib. In real life you can see it when trying to run the command install_lib on the current reportlab2.3. The patch provided needs do be applied in the distutils dir directly with patch install_lib.py dependency.patch As requested, I asked on the mailing list first, whether this really is a bug. http://mail.python.org/pipermail/distutils-sig/2009-February/010974.html I am half finished writing a test case, that I'll append to this ticket later. -- assignee: tarek components: Distutils files: dependency.patch keywords: patch messages: 81892 nosy: do3cc, tarek severity: normal status: open title: Missing dependency in distutils build type: behavior versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7 Added file: http://bugs.python.org/file13064/dependency.patch ___ Python tracker <http://bugs.python.org/issue5243> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5243] Missing dependency in distutils build
Patrick Gerken added the comment: The attached test works breaks without the patch and passes with the patch. I am not sure whether the test itself is written following best practice. I would be more than happy for a review, with hints what should be done better. Added file: http://bugs.python.org/file13103/test_install_lib.py ___ Python tracker <http://bugs.python.org/issue5243> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7011] tarinfo has problems with longlinks
New submission from Patrick Gerken : Sadly, I am unable to debug it enough to be able to provide a thorough test case. I can provide information of how to reproduce the problem on request. I have a tar file and a diff to tarfile.py with some pdbs that only get activated in the middle of the file just before the problematic data. Installing an egg fails, and setuptools eats the original error. The original error is this: ValueError: 'invalid literal for int(): \xcf\xcf\xdf\xfc\xe9\xcd\xa9\xa9' That happens in the call to next in the class TarFile. Here we read in a chunk of filedata, and let TarInfo parse it. But the chunk of data is actually the beginning of an image in the tar file. Here is a more thorough report of my pdb findings: Environment: I created an egg on linux, which resulted in a tar.gz file. Installing that egg fails, because the tarfile library has problems reading the tar file. tar itself can extract the full file without problems. I have a self compiled python 2.4.6. The last file that is apparently read correctly form TarFile.next, is a LONGLINK, tarinfo.type == 'L' This type has a method callback in TarInfo.TYPE_METH, which it uses for returning the real TarInfo object. That goes into proc_gnulong of tarfile.py. This proc_gnulong method calls next again, to get the real file info, I think. The next buffer that is read out, contains a file name that is exactly 100chars long, and seems to be a directory, because it has a trailing slash. but its filetype is '0'. I suspected the error here, and to cross check, I checked the output of "tar -tf" on the tar file. I expect tar to return the filenames in the same order as python reads them in. Before the directory that next seems to find, there is his parent directory in there. The previous tarinfo object is exactly about this parent directory. So it looks like, we actually have a directory entry here. Enough wild guesses and more observations: The next call of TarInfo.next() creates a TarInfo object again, here at about line 693, he checks if the file is a regular file but ends with a slash. If so, he changes the file type from '0', regular file, to '5', DIRTYPE. He actually does that with our TarInfo object. The TarInfo object is created successfully and the next method continues to run. Then, around line 1650, there is a check, if tarinfo.isreg() or tarinfo.type not in SUPPORTED_TYPES:... Here the offset for reading the next TarInfo Buffer is increased by the size of the actual file size in the tar file. But not for our TarInfo object, because it is not regular file any longer. If I pad the offset manually, everything continues to work. But I won't do it this time. The call to next finishes, and after a while TarInfo.next() is called again. This time, next tries to read a chunk of data again, but this time, the chunk of data is an actual file content, it starts with 'GIF89a...', which makes sense, the directory contains images. Here parsing of the tar file fails. -- components: Library (Lib) messages: 93198 nosy: do3cc severity: normal status: open title: tarinfo has problems with longlinks versions: Python 2.4 ___ Python tracker <http://bugs.python.org/issue7011> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7011] tarinfo has problems with longlinks
Patrick Gerken added the comment: doh, I only searched for open bugs. Not for closed. This ticket is a dublicate of http://bugs.python.org/issue1471427 and fixed in python 2.5. If somebody has similar problems, here is a quickfix: I finally was able to reproduce the issue. It only happens when the path without the filename but the trailing slash is exactly 100 chars long. Then, because of the trailing slash, tarfile makes this thing a directory, and if the file itself was not empty, the next read cannot be parsed as a tar file. Since I am bound to 2.4 I will rename the directories. -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue7011> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5243] Missing dependency in distutils build
Patrick Gerken added the comment: Hi Tarek, I think clib stuff is installed in the right python directory and the ext install step then just finds them. To reproduce the issue, run the "old" easy_install in a virtualenv. easy_install ReportLab It will then fail because of the missing library. I can also show it during Plone Conference, just look for me in irc. Thanks, Patrick -- ___ Python tracker <http://bugs.python.org/issue5243> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5243] Missing dependency in distutils build
Patrick Gerken added the comment: Thank you, tarek The sys.path should have been obvious. Added file: http://bugs.python.org/file13159/test_install_lib.py ___ Python tracker <http://bugs.python.org/issue5243> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
