I've finally managed to look into these problems. I believe I've solved them all and will commit the updates, along with cargo-culting the same changes into the other three flufl.* packages, asap.
On Aug 23, 2011, at 11:06 PM, Piotr Ożarowski wrote: >[Barry Warsaw, 2011-08-22] >> I've managed to file ITPs and package up two more flufl packages, flufl.lock > >* build directory is not removed in clean target (and thus package > cannot be build twice in a row) This is because dh_auto_clean does not remove the build/sphinx directories. Adding an override_dh_auto_clean target which `rm -rf build/sphinx` does the trick. However, I wonder if this is something that `--with sphinxdoc` should help with? If so, I'm willing to at least file a bug. FWIW, `pbuilder --build --twice ...` along with an A* hook to invoke a shell were the essential debugging tools for this problem. >* lintian complains with: > >W: flufl.lock source: build-depends-on-1-revision build-depends: >python-sphinx (>= 1.0.7+dfsg-1) Bumped this down to 1.0.7. >E: python-flufl.lock: helper-templates-in-copyright Okay, I removed the "(s)" but this one seems bogus for several reasons. First, the lintian warning really doesn't tell you what's wrong with your debian/copyright file, so you're left to guessin' 'n googlin'. Second, debbug #631674. >E: python-flufl.lock: extended-description-is-empty This one also feels a bit bogus to me. Do I really *have* to have an extended description? Maybe the summary is all there is. But okay, easily fixed. >W: python-flufl.lock: duplicate-changelog-files >usr/share/doc/python-flufl.lock/changelog.gz >usr/share/doc/python-flufl.lock/html/_sources/NEWS.txt.gz I'm not getting this one now. Maybe it's due to the other changes I'm about to commit. Please let me know if you still get this. >* it FTBFS in my pbuilder (works fine on my desktop): The trick is to add `--bindmounts "/dev/shm /dev/shm" to your pbuilder command. Should I document this somewhere in my source package? Is this an acceptable requirement for a package? If not, I think the only other option is to disable the failing tests. >PS feel free to reply in private Thanks. I hope you don't mind me replying publicly, since I think the information may be useful to other Python packagers, or spur constructive discussions about the toolset. Plus, I'm too old to worry anymore about looking like an idiot. :) Anyway, thanks for the great feedback, and apologies for taking so long to respond. Cheers, -Barry -- 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/20110907180750.3f425...@resist.wooz.org