Re: [RFS] libsecrecy 0.0.2+dfsg-1 (Was: libmaus2 update attempt 2.0.762^W 764^W 762 & libsecrecy intro)
Hi Étienne,
On Sat, Nov 14, 2020 at 03:58:39PM +0100, Étienne Mollier wrote:
> > I've seen your pushes. Seems you did not found itp_from_debian_dir[1]
> > which makes the ITP bug more convenient. But its fine to do that
> > manually.
>
> > [1] https://salsa.debian.org/r-pkg-team/dh-r/-/blob/master/scripts/itp_from_debian_dir
>
> So that's where it keeps hiding from me! :D
Sorry, I admit its nearly perfectly hidden (and I had to seek myself the
repository - its in the PATH on my machines :-( ). Any idea where to
make it better visible is welcome.
> I'm a bit wary of putting more package into the archive without
> a good reason. Going through the normal reportbug process gives
> me some time to find justifications. But yeah, for standardized
> R packages, having a fully automated process makes complete
> sense, as I understood.
It helped a lot to add a set of new dependencies for R packages.
Meanwhile I'm using this script for other packages as well. :-P
> > Just let me know if its ready for sponsering (or may be I need to
> > read on my mails ... ;-) )
>
> No worries, I wanted to reread a thing or two today. I think
> that the package is suitable for review; I would be especially
> happy of a triple check on the copyrights side:
>
> https://salsa.debian.org/med-team/libsecrecy
Copyright looks good to me. I tried to make the header only package
"Architecture: all" but lintian shouted at me due to the pkg-config
file in /usr/lib/TRIPLET - so I reverted that change.
> Salsa CI wise, the package is scanned as in quite good shape.
> A note on the autopkgtest: the run-unit-test tends to crash at
> random, I always saw these in qemu-user context until then, but
> I'm not entirely sure of the source. Some of the GPGME calls
> tend to end in SIGABRT. I thought it would be eligible to being
> marked "flaky", so to make sure other unrelated errors are not
> caught by the flaky aspect, I added a second run-stable-test
> suite marked "superficial", which redoes only the stable
> commands of the initial test.
Using flaky test makes sense here.
> If it sounds good to you, I think libsecrecy would be eligible
> to go to the NEW queue.
>
> > Thanks as always
>
> And as always, you're welcome!
:-)
Package is uploaded to new.
> Have a nice day, :)
Same to you, Andreas.
--
http://fam-tille.de
Reply to: