[Debian-ha-maintainers] libqb_0.17.1-1_amd64.changes is NEW

[Richard B Winters]

On Sun, 2015-04-26 at 23:14 +0200, Ferenc Wagner wrote:
> Christoph Berg <myon at debian.org> writes:
> 
> > Re: Richard B Winters 2015-04-24 <1429834338.8752.77.camel at mmogp.com>
> >
> >>> Do you want to redo 0.17.1-1, or release 0.17.1-2?  I've pushed some
> >>> changes based on the (now rejected) 0.17.1-1 upload to
> >>> https://github.com/wferi/libqb/commits/debian/sid, please take a look.
> >>> (This is the DEP-14 repo structure I originally put up as a demo while
> >>> debating the best structure.)
> >
> > I've cherry-picked some of your changes from there, thanks!
> >
> > Most notably, I've omitted the soname bump, as we should only deviate
> > from upstream if there's an actual reason. So far I haven't seen any
> > problems with the new libqb version (though I haven't tried too hard
> > yet).
> 
> Maybe I should ping https://github.com/ClusterLabs/libqb/issues/134, in
> case the libqb maintainers have something to add.
> 
> > Feri, if you have more to add, can you push that to the alioth repo?
> 
> More to remove.  I'd like to declare the library package Multi-Arch:
> same, but the triplets are dropped from the paths.  The commit message
> of 526b3844 does not explain this move (and enabling dependency tracking
> does not buy us anything anyway).  So I prefer my 2d880746.

The Multi-Arch: same part I didn't realize, that's excellent I'd think
that's a given; looking forward to the commit. 

Don't know what you mean by triplets are dropped from the paths;  or
that 'the commit message does not explain this move'.

I didn't - at least knowingly - 'drop triplets from the path'; and I
answer to this since that was my commit:

https://wiki.debian.org/Multiarch/Tuples#Why_not_use_GNU_triplets.3F

There is also nothing wrong with enabling dependency tracking:

http://www.gnu.org/software/automake/manual/html_node/Dependency-Tracking.html

> I also added a couple of more relations:
> Package: libqb-doc
> Recommends: w3m | www-browser
> Suggests: libqb-dev

Yea I saw Christoph cherry-pick that, after I had done something similar
in corosync and pacemaker I was thinking of doing the same in libqb;
awesome that you added it.

> The left-behind docs/doxygen_sqlite3.db is a good catch, but that should
> be cleaned by the upstream docs/Makefile.am, so an upstreamable patch
> would be more useful than bringing in the debian/clean big hammer.

Should be yes, but I don't think we should wait on them either.

> Especially that .version (according to build-aux/git-version-gen) should
> be present in the distribution tarball (pity we've only got a git tag).
> Thus I created a patch for bringing .version in.  This will complain
> loudly when upstream fixes this problem.  The same goes for another
> missing file, .tarball-version, too.

I could be mistaken (as I have been with libqb a couple times already),
but I didn't need a .version file; just a .tarball-version file
generates the latter just fine and ensures *.pc files contain the proper
version string.

> > it's correct that the upload needed to be removed to get a proper
> > orig tarball in place
> 
> Have you found a proper upstream distribution tarball for 0.17.1?  If
> you mean the GitHub tag links, I wonder how stable they results are...

The current repository has the proper upstream tarball; but it still
requires the patch for .tarball-version. These issues were forwarded
upstream.

> >>> I've just noticed your activity in the debian-ha repo.  AFAIK, replacing
> >>> the Doxygen-installed jquery.js by a pure jquery.js from jQuery is
> >>> specifically recommended against by the Doxygen developers, because
> >>> their jquery.js contains other code besides jQuery.
> >
> > Upstreams tend to recommend using embedded code copies a lot. Is there
> > any documentation what they actually changed in jquery?
> 
> So, but see doxygen itself for a more detailed description of the problems:
> https://sources.debian.net/src/doxygen/1.8.8-5/debian/README.jquery/

Good read, I'll be sure to override the lintian informational errors on
packages that need it with a reference to that link.

-- 
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/20150426/caf2c2b9/attachment.sig>