[DRE-maint] liboauth-ruby: initial upload for review

[Will Daniels]

Hi Lucas,

Thanks for a quick response. I have updated the package with those
improvements and other replies inline below.

Lucas Nussbaum wrote:
> Well, for a first attempt, you did very well!
>
>   
Yay! :)
> It is very important to use svn-inject to import the package into SVN.
> The way you imported it, the mergeWithUpstream SVN property wasn't set,
> so svn-buildpackage & friends refused to work.  (fixed)
>
>   
Oops, I do remember reading that on the homepage now that you mention it
:$ However, I have just tried using svn-inject after making these
changes and it tells me:

svn-buildpackage doesn't support Debian source package formats other
than 1.0. Aborting.

I tried installing the latest version from sid but it has the same
problem. Do you know an alternative way that would allow me to continue
using quilt? Do I just have to set that SVN property you mention? I have
only used git-buildpackage in the past, which is fine with quilt, so I
did not think to check that beforehand.

I know it's more intended for dealing with bigger patch sets, but I'm
quite fond of quilt and I'd prefer to use it if possible. I guess I
could try to fix svn-buildpackage myself, but I'm assuming there must be
something fundamentally difficult about it if nobody has done this yet...?

I will investigate further, but if anybody already knows what the score
is with svn-bp/quilt please advise.
> debian/rules:
> install/liboauth-ruby1.8::
> 	dh_installchangelogs -pliboauth-ruby1.8 History.txt
> Can probably be replaced by:
> DEB_INSTALL_CHANGELOGS_liboauth-ruby1.8 := History.txt
>
> (but I haven't checked)
>
>   
Yes, I didn't have any particular reason for calling it directly; fixed.
> Lintian warning:
> W: liboauth-ruby source: out-of-date-standards-version 3.8.3 (current is
> 3.8.4)
>
>   
I was being lazy and relying on the lintian in Ubuntu Karmic (then
Launchpad to check the clean build). I'll set up a pbuilder chroot for
Debian unstable, or at least install a newer lintian; fixed.
> You might want to add a comment following DEP4 for
> debian/patches/repack-deprecate-rubygems. Even if the patch is very
> simple, it's still a good practice.
>
>   
I have added now a header note on the quilt patch and a comment in the
patched files, but I don't think I understand what you mean by "DEP4".
Is this a reference to the Debian Enhancement Proposal for tdebs or have
I misunderstood? :D
> Unfortunately, it seems that we often lack packages for some of the
> libraries required to run ruby tests.
>
>   
We have the necessary libraries to run them, but I don't know if there
is a special target in the build rules for running tests (I've never
encountered such myself) or if you tend to distribute them in the
package (and if so, which package)?
>> 3. The upstream sources include scripts to generate the lib's homepage
>> on rubyforge. I did not think it of value to attempt to package this for
>> docs or anything else. For starters, it begins with instructions to
>> "sudo gem install oauth" etc.
>>     
>
> That's probably fine. Is there any reason to believe that the copyright
> would be different here?
>
>   
I don't see any specific or alternative attribution of authorship,
copyright or license for the website files, so presumably they just fall
under the main copyright and license? The MIT license is actually stated
in the HTML content of the index file itself, applying to "this code",
so I would expect that implies the inclusion of itself sufficiently?

There is a javascript with an additional copyright there (and a
different license - LGPL) but I cannot see anything that is incompatible
with DFSG to hold in the orig source archive, and if these website files
are not distributed in the binary packages then do we still need to list
it in copyright?

Thanks,
Will