Bug#691745: dpkg-buildflags should not define _FORTIFY_SOURCE with DEB_BUILD_OPTIONS=noopt

2012-10-29 Thread Guillem Jover
On Mon, 2012-10-29 at 12:31:13 +0100, Matthias Klose wrote: > Package: dpkg > > glibc-2.16 adds an extra warning when _FORTIFY_SOURCE is defined > without -O >1. This macro should not be defined if noopt is in > effect in DEB_BUILD_OPTIONS. > > I didn't check for combinations of hardening flags a

Bug#691745: dpkg-buildflags should not define _FORTIFY_SOURCE with DEB_BUILD_OPTIONS=noopt

2012-10-29 Thread Matthias Klose
Package: dpkg glibc-2.16 adds an extra warning when _FORTIFY_SOURCE is defined without -O >1. This macro should not be defined if noopt is in effect in DEB_BUILD_OPTIONS. I didn't check for combinations of hardening flags and noopt needing this change as well. http://sourceware.org/git/?p=g

Bug#681474: Dpkg::Vendor: should support /etc/os-release and /etc/os-release.d/*

2012-10-29 Thread Jonathan Nieder
Raphael Hertzog wrote: > Surely you don't have to invent X ways to identify the OS just because > you want to identify it in different contexts? Yes, I think this is where we disagree. > Using a single source is just a better design that avoids mistakes > where /etc/dpkg/origins/default says Deb

Bug#681474: Dpkg::Vendor: should support /etc/os-release and /etc/os-release.d/*

2012-10-29 Thread Raphael Hertzog
On Mon, 29 Oct 2012, Jonathan Nieder wrote: > Raphael Hertzog wrote: > > > In both cases the purpose of the file is to provide identification > > information about the OS. > > Identification for what purpose? So I know which programmer to > complain to when running into compatibility bugs, like

Bug#691449: dpkg-buildflags should have an export mode for shell scripts

2012-10-29 Thread Jonathan Nieder
Guillem Jover wrote: > On Sun, 2012-10-28 at 02:53:57 -0700, Jonathan Nieder wrote: >> Here's another try at putting it in the description of --export. What >> do you think? > > Certainly an improvement, although I'm not yet sold on the embedded > examples, it would probably also make more sense

Bug#681474: Dpkg::Vendor: should support /etc/os-release and /etc/os-release.d/*

2012-10-29 Thread Jonathan Nieder
Raphael Hertzog wrote: > In both cases the purpose of the file is to provide identification > information about the OS. Identification for what purpose? So I know which programmer to complain to when running into compatibility bugs, like the HTTP User-Agent field? For display and theming? To d

Bug#681474: Dpkg::Vendor: should support /etc/os-release and /etc/os-release.d/*

2012-10-29 Thread Raphael Hertzog
On Sun, 28 Oct 2012, Jonathan Nieder wrote: > Raphael Hertzog wrote: > > > Why would it be better to deploy a > > dpkg-specific file over a generic file even if dpkg is the only software > > making use of that generic file? > > Because it makes the purpose of the