[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#903270: marked as done (RFS: sharness/1.0.0-1 [ITP] shell library for running tests)

Your message dated Fri, 13 Jul 2018 00:15:57 -0400
with message-id <87pnzrvkhu.fsf@sergiodj.net>
and subject line Re: Bug#903270: RFS: sharness/1.0.0-1 [ITP] shell library for running tests
has caused the Debian Bug report #903270,
regarding RFS: sharness/1.0.0-1 [ITP] shell library for running tests
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
903270: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903270
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "sharness"

 Package name    : sharness
 Version         : 1.0.0-1
 Upstream Author : Christian Couder <chriscool@tuxfamily.org>
 URL             : https://github.com/chriscool/sharness
 License         : GPL-2 or later
 Section         : devel

It builds those binary packages:

  sharness   - shell library for automated tests with TAP output

Sharness is used by a few Debian packages as part of their DEP8 tests
(via autopkgtest):
  * gearmand
  * git-reintegrate
  * git-remote-bzr
  * git-remote-hg
  * hiera-eyaml
  * jemalloc
  * mod-gearman
  * munin
  * pass-otp
  * puppet-lint
  * puppet-module-puppetlabs-concat
  * puppet-module-puppetlabs-ntp
  * puppet-module-puppetlabs-stdlib
(the list was assembled via https://codesearch.debian.net)

Currently these packages embed a copy of the sharness.sh file below
debian/tests.
I will file bug reports against these packages (including patches) after
the sharness package is available, in order to help them getting rid of
their embedded code copies.

I am part of the munin packaging team, thus the munin package would
benefit immediately from this new package.

I plan to maintain the sharness package for the foreseeable future.

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/sharness


Alternatively, one can download the package with dget using this
command:

  dget -x https://mentors.debian.net/debian/pool/main/s/sharness/sharness_1.0.0-1.dsc


Cheers,
Lars

--- End Message ---
--- Begin Message --- 
On Thursday, July 12 2018, Lars Kruse wrote:

> Hello Sergio,

Hi Lars,

>> 2) A word about git tags.  I noticed you only have the "debian/1.0.0-1"
>> tag, but no "upstream/1.0.0" tag in your git repo.  git-buildpackage
>> should have created that for you; it's worth checking to see if you
>> didn't forget to push.
>
> gbp ist still quite new to me ...
> I tagged the upstream release now.

After I sent you the reply I saw that you're actually packaging on top
of upstream's git repo.  I personally don't like this option, but that's
a matter of taste.  If you haven't yet, I recommend you read:

  https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.upstream-git.html

which covers your case.

>> Hm, alright.  The "aggregate-results.sh" may be useful to some users; it
>> provides a way to display the results in a nicer way, right?
>
> Indeed, the code looks like that. But I also expected it to adjust its exit code
> in case of errors. Thus it feels like a tool just for humans and not for
> testing. We will see, how upstream responds ...

Right, this is a tool for humans to "embellish" the output generate by
the main script, which is fine and is actually an approach taken by
other testing backends.

>> Maybe you could install it under /usr/share/doc/sharness/contrib/, since it's
>> not an example script, but doesn't seem *that* important to justify polluting
>> the PATH.  What do you think?
>
> That sounds good.
> I suggested this location in the discussion with upstream:
>  https://github.com/chriscool/sharness/issues/78#issuecomment-404706089

Cool.  Thanks for spearheading this.

> Now I install this file via dh_install in the above location.
> But dh_install seems to remove the executable flag from the file (as the target
> path indicates a documentation file, I guess).
> Do you think, this is acceptable? Or would an "override_dh_auto_install" target
> be justified for a chown operation?

That's acceptable.  It's part of our policy to not install executable
files under /usr/share/doc/.

> I uploaded another source package for another round ...

Thanks.  I noticed you've rewritten the history of your git repo.
That's fine for now because the package hasn't been uploaded yet, but
it's something pretty much frowned upon by everybody, so avoid doing
that.

The package looks great now, thank you very much for your patience!
I've uploaded it.

When you're ready, please contact me and I can create the sharness
repository under the 'debian' namespace on salsa, so you can migrate it.

Cheers,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Attachment: signature.asc
Description: PGP signature


--- End Message ---
Reply to: