On Thursday, September 17, 2020 3:07:23 P.M. CDT Thomas Goirand wrote:
> On 9/16/20 2:55 PM, Steven Robbins wrote:
> > Since you're soliciting opinions, here's mine. In the absence of a
> > documented consensus, ftpmaster should respect the packager's judgement
> > rather than reject on their own
On 9/16/20 2:55 PM, Steven Robbins wrote:
> Since you're soliciting opinions, here's mine. In the absence of a
> documented
> consensus, ftpmaster should respect the packager's judgement rather than
> reject on their own personal opinion.
Reviewing the packaging is also part of the FTP master
On 9/14/20 9:04 PM, Andreas Tille wrote:
>> 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 sou
Tobias Frost writes:
> my 2 cents: debian/ should not be used for much data: It will be duplicated
> by the upload
> of every package revision. So (being extreme now), having several hundreds of
> MiB would
> be quite expensive in terms of storage overheade.
>
> I have not idea how much "much dat
On Wed, Sep 16, 2020 at 04:55:41PM +0200, Andreas Tille wrote:
>
> Provided that license and copyright of the data in question is OK
> is there any size limit for data to be stored under debian/?
my 2 cents: debian/ should not be used for much data: It will be duplicated by
the upload
of eve
Hi Russ
On Mon, Sep 14, 2020 at 12:21:10PM -0700, Russ Allbery wrote:
> > 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
> > ver
On Tuesday, September 15, 2020 11:18:28 P.M. CDT Andreas Tille wrote:
> Hi Paul,
>
> On Tue, Sep 15, 2020 at 10:00:45PM +0200, Paul Gevers wrote:
> > On 14-09-2020 21:04, Andreas Tille wrote:
> > > In the case of larger data sets it seems to be natural to provide the
> > > data in a separate binar
Hi Paul,
On Tue, Sep 15, 2020 at 10:00:45PM +0200, Paul Gevers wrote:
> On 14-09-2020 21:04, Andreas Tille wrote:
> > 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
Hi Andreas,
On 14-09-2020 21:04, Andreas Tille wrote:
> 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 binar
On Tue, 15 Sep 2020 08:55:40 +0200
Tobias Frost wrote:
> 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
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.
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 h
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 b
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
14 matches
Mail list logo
