Re: RFS: DPMT: flufl.lock 2.1.1-1
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
Reply to: