search

epicsdeb / epics-base

EPICS Base packaging
http://www.aps.anl.gov/epics/
Other
5 stars 10 forks source link

build dependent modules w/ hardening flags by default #7

Closed mdavidsaver closed 8 years ago

mdavidsaver commented 8 years ago

Since #1 the epics-base package has been built with the debian hardening flags (eg. stack protect/relro). Now add /etc/epics/configure/conf.d/05hardening.make so that dependent code will also do this. I think this is fairly low risk. On the chance that something does break, this can be disabled with the make variable 'SKIP_HARDENING=YES'.

05hardening.make is generated at package build time since calling dpkg-buildflags can be a little slow.

mark0n commented 8 years ago

Can you please make the distribution in the changelog file "unstable"? AFAIK "UNRELEASED" is not a valid distribution. Apart from that your modifications look fine to me.

ralphlange commented 8 years ago

As far as I know, unreleased is Debian default for creating packages locally.

See e.g. https://www.debian.org/doc/manuals/maint-guide/update.en.html

mark0n commented 8 years ago

Ralph, thanks for pointing me to the right piece of documentation (I was just looking at the policy manual). So I guess I'm supposed to change that to "unstable" as soon as things build fine for me and I consider it ready for release? I'm still trying to learn the Debian processes...

ralphlange commented 8 years ago

Exactly. (Btw. That page is second if you google for "debian unreleased". I just remembered that I was stumbling over the same thing at some time :-)

Some of the tools (gbp?) create that tag as default when you start a new version. I think the intention is that it helps keeping you from uploading unfinished things to any official builder until you deliberately change the tag.

mdavidsaver commented 8 years ago

Ok, gents. I didn't mean to leave the UNRELEASED (it was late). Typically I edit the changelog in two steps: "dch -i" to start the new version, and "dch -r" to replace UNRELEASED with unstable. I forgot the second step.

@mark0n I have sometimes done this intentionally for minor changes I didn't intend to build/release immediately (eg. fixing typos in manpages). So it's reasonable to ask for clarification.