Re: Nitrokey for DDs

[Gard Spreemann]

Zlatan Todorić  writes:

> I saw there was mention of GNUK and Yubikeys but I didn't see anyone
> mentioned Nitrokey.
>
> https://www.nitrokey.com/
>
> They are a small German-based vendor, producing some nice products
> (among other "keys") and they (AFAIK) are doing it all in FLOSS spirit
> (aka they released everything in open).
>
> https://github.com/nitrokey

I'll throw in my personal anecdote about Nitrokey. I've used their
NitroKey Pro (first gen.) for many years now, and I continue to be very
happy with the product. Most importantly, I found the people very
helpful: I once lost the cap that protects the plug (it didn't fall off,
I left it behind on a train), emailed them and was promptly supplied
with several replacements for free without even being charged for
international shipping.

 -- Gard



signature.asc
Description: PGP signature

Re: Backports needed for Firefox/Thunderbird ESR 78 in Buster/Stretch

[Christoph Martin]

Hi. Any progress here?
Or any way to help?

Am 01.09.20 um 19:17 schrieb Moritz Muehlenhoff:

>> It may be more future-proof, in case we need it for a future
>> rustc for the next ESR bump.
> 
> My gut feeling is the next ESR thing will need LLVM 11 or so, but happy to
> be proven wrong :-) So maybe let's directly move to 10 directly.
> 
> Once uploaded and acked threw NEW, I'll upload wasi-lib rebuilt against
> LLVM, then.
> 

How much data load is acceptable in debian/ dir and upstream (Was: edtsurf_0.2009-7_amd64.changes REJECTED)

[Andreas Tille]

Hi,

in the Debian Med team there are two GSoC students very busy to write
autopkgtests for (in the long run) all our packages (if possible).  For
several packages it is necessary to provide data sets which in many
cases are not provided together with the upstream source.  The students
rather were seeking the internet for data available in scientific
publications or some public databases.  I personally think they did
quite a good job in doing so to test our software in some real world
examples.

In the Debian Med team we have the rule that we do not only rely on the
existing packaging source directory for the autopkgtest but in addition
provide the test script (and thus the needed data) inside
/usr/share/doc/pkgname to serve as a useful example for the program in
question on one hand and also enable users to run the test right on
their machine as well.

In the case of larger data sets it seems to be natural to provide the
data in a separate binary architecture all package to not bloat the
machines of users who do not want this and also save bandwidt of our
mirroring network.  New binary packages require new processing and my
question is here about a set of rejection mails we received ( .

On Sun, Sep 13, 2020 at 12:00:08PM +, Thorsten Alteholz wrote:[1]
> your debian tar file is much too large.

I admit the debian/ dir (2.7MB) exceeds the real code (300kB) by far.
However can we please fix somewhere in our packaging documentation
what size of the debian/ dir is acceptable or not.

> Please put all data in a separate source package and don't forget to add the 
> copyright information.

I think we should try to document somehow, when there is a need for
some separate source package.  I would agree if the code is some kind
of moving target and data would not change or if there is some kind
of versioned downloadable tarball or the data can be shared between
different software package.  But here none of these conditions is
fulfilled.

> But as you don't really need 4we2.ply, you might just omit as well.

I think in the example of edtsurf this is the major point.  You have
given the perfectly helpful hint to Pranav in some other case and
instead of shipping data for the only reason of comparing the result we
started to ship check sums instead.  So I think for this case we can
settle with some solution.

On Sun Sep 13 13:00:09 BST 2020, Thorsten Alteholz wrote:[2]
> please explain why you need such a huge amount of test data in this package.

Shayan has explained it in 2a.  I also think if upstream delivers the
source package that way we should not really change the tarball to
shrink the size of the data originally shipped if the license is OK.

The same question as I had above for the term "much too large" applies
here for "huge amount".  Some kind of rule of thumb what is acceptable
or not would be helpful.

I'm also wondering what you mean by "Please explain" in a "reject" mail.
For my understanding someone asks for an explanation before a decision
is drawn.  But the reject is actually a decision.  In what form would
you expect the explanation.  Probably not via mail (as Shayan did) since
this would not bring back the package into the new queue.  So could you
please be more verbosely like:

   Please explain in debian/README.??? why you decided to keep
   all test data that is provided by upstream.

or something like this.  Shayan is a very dedicated and extremely
productive newcomer.  It would be great if he would get some more
helpful advise how to enhance.  Since I personally also have no
real clue I'm writing here for some kind of general clarification.

On  Sun Sep 13 18:00:08 BST 2020, Thorsten Alteholz wrote:[3]
> please don't hide data under debian/*.

Sorry, Thorsten but I think "hiding" is not the right term.  We have no
other dir to add extra files than the debian/ dir.  That's why I think
Nilesh was correct to store the data here - where these IMHO naturally
belong since these are test data and thus are next to the autopkgtest
script.

> If you really need those data please create a separate source package

That's the question that I'm repeatedly wondering about and thats why I
assemble all these three rejects here in one mail:  What is the general
opinion for creating a separate source package in cases like this.  I
do not see any profit from an extra source package.  From my point of
view autopkgtest data are belonging to the packaging code and thus are
fine here.  But for sure I might be wrong and would like to clarify
this hereby.

> and never ever do Recommend: such package.

That's absolutely correct and definitely an oversight of mine as the
sponsor of this package.  Sorry about this.  On the other hand I'm not
sure whether it is a reason for a reject.  If there would be no other
issue for the package I would consider it more productive for all
of us if you would accept and file an RC bug that could be fixed in
the source-only upload that is needed anyway.

> Don't forget to mention the 

Re: How much data load is acceptable in debian/ dir and upstream

[Russ Allbery]

Andreas Tille  writes:

> I think we should try to document somehow, when there is a need for some
> separate source package.  I would agree if the code is some kind of
> moving target and data would not change or if there is some kind of
> versioned downloadable tarball or the data can be shared between
> different software package.  But here none of these conditions is
> fulfilled.

Is there any overlap of the test data required by different packages?  I'm
wondering if it would make sense to create a new native Debian package
called debian-med-test-data or something like that, and put all of the
data used for package test suites in that package.  The tests can then
depend on it.

That may be a little inefficient for autopkgtest because it will need to
download more data than is necessary to test a specific package, but a bit
cleaner for the archive since it collects a class of data in one place and
provides a natural place for supporting documentation, copyright
information, and so forth.  It also provides a logical place to put
supporting scripts to, say, refresh the download or restructure the data
if required for different packages.  It feels a bit more self-documenting
and obvious what's going on.

That also avoids the hassle of having to maintain a bunch of separate test
data packages (although one could of course also do that) by collecting
the packaging in one place.

-- 
Russ Allbery (r...@debian.org)  

Re: How much data load is acceptable in debian/ dir and upstream (Was: edtsurf_0.2009-7_amd64.changes REJECTED)

[Richard Laager]

On 9/14/20 2:04 PM, Andreas Tille wrote:
> in the Debian Med team there are two GSoC students very busy to write
> autopkgtests for (in the long run) all our packages (if possible).

That is an excellent thing to do.

> On  Sun Sep 13 18:00:08 BST 2020, Thorsten Alteholz wrote:[3]
>> please don't hide data under debian/*.
> 
> Sorry, Thorsten but I think "hiding" is not the right term.

FWIW, I agree that "hiding" seems wrong here.

> We have no
> other dir to add extra files than the debian/ dir.

Assuming a "3.0 (quilt)" package, you have the option of adding another
source tarball. [1] I'm not sure if that is better or worse here. It
just moves data from one source tarball (the debian one) to another. But
it is an _option_ at least.

>> Don't forget to mention the copyright information.
> 
> In principle yes, but these data are not copyrightable as far as I know.
> Nilesh has mentioned the origin of data in debian/tests/README to
> provide a reference.  If you consider this information not sufficient
> please let us know a better way.

I would put the explanation in debian/copyright (instead of or in
addition to any other location). If you're using machine-readable
copyright, use "License: public-domain", and and note that 7.1.1
_requires_ an explanation of why it is public-domain, as public domain
is commonly misunderstood. [2]

[1]
https://wiki.debian.org/Projects/DebSrc3.0#How_to_use_multiple_upstream_tarballs_in_3.0_.28quilt.29_format.3F

[2]
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-short-name

-- 
Richard



signature.asc
Description: OpenPGP digital signature

Re: How much data load is acceptable in debian/ dir and upstream (Was: edtsurf_0.2009-7_amd64.changes REJECTED)

[Tobias Frost]

On Mon, Sep 14, 2020 at 03:32:54PM -0500, Richard Laager wrote:

> >> Don't forget to mention the copyright information.
> > 
> > In principle yes, but these data are not copyrightable as far as I know.
> > Nilesh has mentioned the origin of data in debian/tests/README to
> > provide a reference.  If you consider this information not sufficient
> > please let us know a better way.

Note, IANAL;
I don't know if DATA itself is copyrightable, however, the act of collecting
data can to my understanding constitute copyright.

--
tobi