[Debian-ha-maintainers] libqb is ready

[Richard B Winters]

Hi Feri,

> I just didn't know the reference point.  If it was 0.17.0-2 from Debian
> unstable, then all right, your dropped two patches, which were both
> applied upstream.

I see, the patches were fixes that are in upstream, and were patched
into the source prior to a new release...no longer necessary.

> Is "export DEB_BUILD_MAINT_OPTIONS = hardening=+all" really needed?

From what I understand, hardening=+all adds all the hardening flags,
which is not the default.  

See
https://wiki.debian.org/HardeningWalkthrough#Enabling_dpkg-buildflags_in_your_debian.2Frules_files

Please correct me if I'm wrong. BTW this is the guide I followed
previously, that I didn't notice it was fully automatic in:

https://wiki.debian.org/Hardening

The only reference to it being full automatic since debhelper9 is in the
cmake section, and I didn't need to read that section...the top link
however, explains it right away.


> Also, I don't get the "ibqb is linked against pthread..." comment block,
> could you explain it, please?

This package now supports the glib-based examples, and as a result it
also makes use of libpthread librt and libdl. Do not trust the warnings
that are displayed in a source build suggesting that it causes a useless
dependency - as reported by dpkg.  
  
See configure.ac in the source for more information.

> Could you please share these lectures with me?

Yes sure :)

https://www.debian.org/doc/manuals/maint-guide/advanced.en.html
https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-symbols

to start, and I'll have to ask Pabs for the links again because I was
directed off of those links to the ones above, and didn't save the
latter because other links I was directed to had the info I ultimately
needed. Though if you want his lecture, you could always hop on mentors
and ask him :)


> >>>   * debian/libqb-dev.docs: Added for coding_style.txt
> >> 
> >> Generally, I'd prefer dh_installdocs --link-doc=libqb0 and dh_install
> >> --fail-missing, if reasonable.  You can even use those via
> >> 
> >> dh $@ --with autoreconf --fail-missing --link-doc=libqb0
> >> 
> >> (but see eg. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685683)
> >
> > I will use your second suggested implementation - after reading the
> > supplied informational link :)
> 
> You mustn't use concrete architecture names (like x86_64-linux-gnu) in
> the *.install files, because they must work on other architectures as
> well.  Wildcard them.

Hmm, where did I do that?

> Also, I don't know if you dropped coding_style.txt by mistake, but it
> doesn't belong to the documentation of the binary package, so I'd leave
> it out anyway.

Was dropped intentionally, and for that very reason.

> The bug referenced above points out that switching to --link-doc
> requires manual migration in libqb-dev.postinst.  For example:
> 
> #!/bin/sh
> set -e
> 
> if [ "$1" = configure ] && dpkg --compare-versions "$2" lt 0.17.1-1; then
>     DOCDIR=/usr/share/doc/libqb-dev
>     DOCLINK=/usr/share/doc/libqb0
> 
>     if [ -d $DOCDIR ] && [ ! -L $DOCDIR ] ; then
>         rmdir $DOCDIR
>         ln -s $DOCLINK $DOCDIR
>     fi
> fi
> 
> #DEBHELPER#
> 
> exit 0

That was with regard to the symbolic links not actually being
there...though they were for me in debian/tmp after build - as well as
post-install in /usr/share/doc/lib*, so is that script really even
necessary in this case?

> >>>   * debian/<pkg>.lintian-overrides: Added to prevent lintian flags as a 
> >>>     side effect of several of the manual pages not being properly 
> >>>     formatted for conversion by doxygen; hyphens, mispellings, and  
> >>>     invalid whois entries
> >> 
> >> I think these are genuine problems and should not be overridden, but
> >> rather fixed and upstreamed (especially that you're packaging a git
> >> snapshot).  The misspellings are the easiest; I'd have to look into the
> >> rest.
> >
> > Many on Debian mentors found it completely acceptable to ignore those
> > errors.
> 
> Yes, they are OK to ignore.  Still, they are real problems and should be
> fixed eventually.  That's why I don't recommend hiding (overriding)
> them.

I do know what you mean, but it is easy to see what is overridden, it
just stops spam is all. Unless I'm not understanding what the override
is doing in this case - when I check lintian output afterwards with
override enabled - I get a nice small message that there were xx # of
overrides, and inspection easily shows what they are.

> > This seems like the last thing anyone should be worried about,
> > especially considering the state of the stack.
> 
> Sure, I don't suggest to fix them now.  Only maybe notify upstream about
> the really obvious stuff (like the "incomming" typos).

Ok, I will do so here shortly.


Best,



-- 
Rik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/debian-ha-maintainers/attachments/20150329/151bfe84/attachment.sig>