Hi,
The situation around dpkg-buildpackage and multiarch/cross-compile
support is confusing.
I now realize I had a wrong idea on what dh_auto_configure does
internally.
> However, this is an uncommon case if you're using dh; you rarely need
> to set them in debian/rules because debhelper will se
Hi Osamu,
Thanks for the quick resolution to this bug. I'm happy with the change
you've uploaded, so just a few reactions here to your comments - feel free
to ignore:
On Fri, Oct 10, 2014 at 10:55:59PM +0900, Osamu Aoki wrote:
> I agree that it is bad to have cruft in the packages uploaded to th
Hi,
I decided not to enable "include /usr/share/dpkg/architecture.mk" in
debian/rules, despite of the fact "Reliance on exported environment
flags" in the dpkg-buildpackage manpage recommendation not to rely on
its exported variables.
Now debmake's manual document has;
| Adding "include /usr/sha
Hi,
The more I look into this, I agree not to include
> DPKG_EXPORT_BUILDFLAGS = 1
> include /usr/share/dpkg/default.mk
nor
> DPKG_EXPORT_BUILDFLAGS = 1
> include /usr/share/dpkg/buildflags.mk
But
> include /usr/share/dpkg/architecture.mk
is tempting.
This is because the buildflag variables
Hi,
(It looks like this was not sent or lost in somewhere. Updating its
content and sending this now.)
Thanks for your useful feedback on how debmake should behave.
On Tue, Sep 30, 2014 at 11:11:01AM -0700, Steve Langasek wrote:
> Package: debmake
> Version: 4.1.4-1
> Severity: important
>
> I
Package: debmake
Version: 4.1.4-1
Severity: important
I have just seen a package come through the Ubuntu NEW queue that used
debmake to prepare it, and had the attached resulting debian/rules file.
First, I think it's bad form for a tool like debmake to output commented-out
examples in its produc
6 matches
Mail list logo
