El 19/06/12 16:10, Andrey Rahmatullin escribió:
> Why do you need hardening-wrapper? You should use flags set by
> dpkg-buildflags.
Because that
(http://wiki.debian.org/Hardening#Notes_for_packages_using_CMake),
referred by lintian-info too. Using it I only need to define "export
DEB_BUILD_HARDENING=1" on my debian/rules and it adds the CPPFLAGS to
CFLAGS and CXXFLAGS (Cmake ignores CPPFLAGS).
> You should read http://bugs.debian.org/673112 mentioned in the lintian tag
> description and use hardening-check --verbose on binaries reported. If
> only memcpy and memmove are printed by hardening-check, you should ignore
> the warning.
Done. I have emmove, memcpy and read... I will read this link to learn
more about removing this warning.
> That's right, 0.1.0~2012......git-1 is less than 0.1.0. If you need
> versions that are greater than 0.1.0, use + instead of ~.
Ok, thanks
> git-describe(1)
>
> file:///usr/share/doc/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.UPSTREAM-GIT
> (if you use git-buildpackage)
I don't use git-buildpackage and git describe on their repository
returns a bit estrange string...

$ git describe --tags
v0.1.1-27-g55c0f4e

Thanks for your quick help :-)

--
José Luis Segura Lucas

On Tue, Jun 19, 2012 at 04:42:33PM +0200, José Luis Segura Lucas wrote:
> > Why do you need hardening-wrapper? You should use flags set by
> > dpkg-buildflags.
> Because that
> (http://wiki.debian.org/Hardening#Notes_for_packages_using_CMake),
> referred by lintian-info too. Using it I only need to define "export
> DEB_BUILD_HARDENING=1" on my debian/rules and it adds the CPPFLAGS to
> CFLAGS and CXXFLAGS (Cmake ignores CPPFLAGS).
I see several solutions there, and the hardening-wrapper one is in my
opinion the worst one: it adds a build dependency and it uses own set of
configuration variables, not compatible with dpkg-buildflags ones.

> > file:///usr/share/doc/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.UPSTREAM-GIT
> > (if you use git-buildpackage)
> I don't use git-buildpackage
Then I don't understand what do you mean by "packaging directly from VCS".

> and git describe on their repository
> returns a bit estrange string...
>
> $ git describe --tags
> v0.1.1-27-g55c0f4e
I thought you've meant exactly the -27-g55c0f4e part.

--
WBR, wRAR

El 19/06/12 16:56, Andrey Rahmatullin escribió:
> I see several solutions there, and the hardening-wrapper one is in my
> opinion the worst one: it adds a build dependency and it uses own set of
> configuration variables, not compatible with dpkg-buildflags ones.
Yes, it adds a build-dependency... but it still use dpkg-buildflags,
doesn't it?
> Then I don't understand what do you mean by "packaging directly from VCS".
I mean to package the software directly from a VCS version, instead for
a tarball. Now, I'm getting the sources with git, generate a tarball
myself with the appropriate name, put it in the parent directory and
build the package. I think that it can be a way to avoid the manual
tarball generation. I'm reading about git-buildpackage, because it can help.
>
> I thought you've meant exactly the -27-g55c0f4e part.
>
The problem are the "-", but I hope that when uploading to Debian they
have a freeze stable version :-D

--
José Luis Segura Lucas

On Tue, Jun 19, 2012 at 05:04:46PM +0200, José Luis Segura Lucas wrote:
> > I see several solutions there, and the hardening-wrapper one is in my
> > opinion the worst one: it adds a build dependency and it uses own set of
> > configuration variables, not compatible with dpkg-buildflags ones.
> Yes, it adds a build-dependency... but it still use dpkg-buildflags,
> doesn't it?
It uses dpkg-buildflags in addition to doing more or less the same in a
different way.

--
WBR, wRAR

On Tue, Jun 19, 2012 at 04:04:31PM +0200, José Luis Segura Lucas wrote:
> repository but not still in a numbered version, so, I tried to use the
> latest known version and add a ~TIMESTAMPgit... to the minor version
> number, but debuild warns me about the version 0.1.0~2012......git-1 is
> less than 0.1.0.

Use A~B only if this version should come before A - that is, for example, if
you expect the next upstream release to be A. In your case, use A+B so the
version comes after A in version order.

> The latest thing is that I have seen several packages with ~TIMESTAMP
> (screen, by example): they add a alpha-numeric string after the "git"
> word... what does it mean?

It's the beginning of the hash git uses to uniquely identify the version.
You can see the full hash in, for example, git log, at the beginning of each
patch:

commit 2ff04fd5a95f36497bc8e8c6e44d70c474384ec2
Author: Antti-Juhani Kaijanaho <antti-juhani@kaijanaho.fi>
Date: Mon Jun 18 23:26:59 2012 +0300

Add install-sh

Signed-off-by: Antti-Juhani Kaijanaho <antti-juhani@kaijanaho.fi>

In this case, the hash is the long string after the word "commit"
on the first line, and I would use for example 2ff04 in the version number if I
packaged this version as a git snapshot.

> Where can I found some information about
> packaging directly from VCS?

git-buildpackage has excellent docs. You don't have to use the tools but they
help.

--
Antti-Juhani Kaijanaho, Jyväskylä, Finland
http://antti-juhani.kaijanaho.fi/newblog/
http://www.flickr.com/photos/antti-juhani/

2012/6/19 José Luis Segura Lucas wrote:

> (http://wiki.debian.org/Hardening#Notes_for_packages_using_CMake),
> referred by lintian-info too. Using it I only need to define "export
> DEB_BUILD_HARDENING=1" on my debian/rules and it adds the CPPFLAGS to
> CFLAGS and CXXFLAGS (Cmake ignores CPPFLAGS).

Correct me if I'm wrong, but IIRC the CPPFLAGS have nothing to do with C++.
They're for `cpp` tool which is "The C PreProcessor" (check `man cpp`).
So as far as I understand cmake (and every other build system) MUST ignore
the CPPFLAGS, right?

The CFLAGS should be used by `gcc` and CXXFLAGS should to go to `g++`.

Is there a bug somewhere causing CPPFLAGS to be used by g++? Is that a typo
on wiki? Or am I missing something?

--
Serge


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAOVenEoDggX0LQLy5p9kcjP5YwmQf+x6UbuYY1Yf_EQyjdqvf g@mail.gmail.com">http://lists.debian.org/CAOVenEoDggX0LQLy5p9kcjP5YwmQf+x6UbuYY1Yf_EQyjdqvf g@mail.gmail.com

On Sat, Jun 23, 2012 at 11:08:50PM +0300, Serge wrote:
> > (http://wiki.debian.org/Hardening#Notes_for_packages_using_CMake),
> > referred by lintian-info too. Using it I only need to define "export
> > DEB_BUILD_HARDENING=1" on my debian/rules and it adds the CPPFLAGS to
> > CFLAGS and CXXFLAGS (Cmake ignores CPPFLAGS).
>
> Correct me if I'm wrong, but IIRC the CPPFLAGS have nothing to do with C++.
Nobody said they do.

> They're for `cpp` tool which is "The C PreProcessor" (check `man cpp`).
> So as far as I understand cmake (and every other build system) MUST ignore
> the CPPFLAGS, right?
Do you say that cpp(1) is not used in the build process of C and C++
software?

--
WBR, wRAR

On Sat, Jun 23, 2012 at 11:08:50PM +0300, Serge wrote:
> 2012/6/19 José Luis Segura Lucas wrote:
> > (http://wiki.debian.org/Hardening#Notes_for_packages_using_CMake),
> > referred by lintian-info too. Using it I only need to define "export
> > DEB_BUILD_HARDENING=1" on my debian/rules and it adds the CPPFLAGS to
> > CFLAGS and CXXFLAGS (Cmake ignores CPPFLAGS).
>
> Correct me if I'm wrong, but IIRC the CPPFLAGS have nothing to do with C++.
> They're for `cpp` tool which is "The C PreProcessor" (check `man cpp`).
> So as far as I understand cmake (and every other build system) MUST ignore
> the CPPFLAGS, right?

They SHOULD include CPPFLAGS.

> The CFLAGS should be used by `gcc` and CXXFLAGS should to go to `g++`.
>
> Is there a bug somewhere causing CPPFLAGS to be used by g++? Is that a typo
> on wiki? Or am I missing something?

Both gcc and g++ preprocess the source first.

--
I was born an ugly, dumb and work-loving child, then an evil midwife
replaced me in the crib.

2012/6/23 Andrey Rahmatullin wrote:

>> They're for `cpp` tool which is "The C PreProcessor" (check `man cpp`).
>> So as far as I understand cmake (and every other build system) MUST
>> ignore the CPPFLAGS, right?
>
> Do you say that cpp(1) is not used in the build process of C and C++
> software?

Yes, unless you actually call `cpp` directly by your build scripts somewhy.
Gcc uses internal preprocessor by default.
(I just checked `strace -f g++ test.cpp` to make sure)

--
Serge


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAOVenErrwiBPitsQES1hi2QA0Akc+MdAqYEtr8eDrhnOhMuCh g@mail.gmail.com">http://lists.debian.org/CAOVenErrwiBPitsQES1hi2QA0Akc+MdAqYEtr8eDrhnOhMuCh g@mail.gmail.com

Serge <sergemdev@gmail.com> writes:
> 2012/6/23 Andrey Rahmatullin wrote:

>> Do you say that cpp(1) is not used in the build process of C and C++
>> software?

> Yes, unless you actually call `cpp` directly by your build scripts somewhy.
> Gcc uses internal preprocessor by default.

Same thing in different packaging.

Reading the "Present Output Variables" section in the Autoconf manual
about CFLAGS and CPPFLAGS would probably be informative. If you follow
the Autoconf variable conventions, CPPFLAGS must be passed to every
compiler invocation unless you're specifically telling the compiler *not*
to preprocess the input source (highly unusual).

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87lijdvgr0.fsf@windlord.stanford.edu">http://lists.debian.org/87lijdvgr0.fsf@windlord.stanford.edu