Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.java > #9979 > unrolled thread

Re: scala-tools-sbinary_0.4.2+2.11.M5-1_amd64.changes REJECTED

Back to article view | Back to linux.debian.maint.java

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: scala-tools-sbinary_0.4.2+2.11.M5-1_amd64.changes REJECTED Frederic Bonnard <frediz@linux.vnet.ibm.com> - 2017-09-05 09:40 +0200
    Re: scala-tools-sbinary_0.4.2+2.11.M5-1_amd64.changes REJECTED Andreas Tille <andreas@an3as.eu> - 2017-10-04 21:30 +0200
      Re: scala-tools-sbinary_0.4.2+2.11.M5-1_amd64.changes REJECTED Thorsten Alteholz <debian@alteholz.de> - 2017-10-04 22:50 +0200
        Re: scala-tools-sbinary_0.4.2+2.11.M5-1_amd64.changes REJECTED Andreas Tille <andreas@an3as.eu> - 2017-10-20 07:20 +0200
    Re: scala-tools-sbinary_0.4.2+2.11.M5-1_amd64.changes REJECTED Andreas Tille <tille@debian.org> - 2017-11-15 17:00 +0100
      Re:  =?us-ascii?Q?scala-tools-sbinary=5F0=2E4=2E2+2=2E11=2EM5-1=5Famd?= =?us-ascii?Q?64=2Echanges?= REJECTED Frédéric Bonnard <frediz@linux.vnet.ibm.com> - 2017-11-17 12:20 +0100
        Re: =scala-tools-sbinary REJECTED Andreas Tille <tille@debian.org> - 2017-12-05 14:40 +0100

#9979 — Re: scala-tools-sbinary_0.4.2+2.11.M5-1_amd64.changes REJECTED

[Multipart message — attachments visible in raw view] — view raw

Forwarding to the correct debian-java mailing list..

---

Hi Thorsten,

thanks for working on that and everybody that answered to help this
topic to progress. I've been off my computer last week.

> your package seems to consist mostly of jar files without the corresponding 
> sources. So I am afraid I have to reject it.

That's right, there are several jars that are part of the embedded sbt
binary distribution that is used to only build the current sbt.
All started here :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639910#118

There Mehdi Dogguy explained we can bootstrap sbt this way as long as we
do not ship those binary jars in the Debian binary package. It seems
this process has been followed for other softwares.

That looked ok for me since the spirit of Debian is there : the
different components to upload are DFSG compliant : the sources of sbt
are there (2) and licenses of all files are DFSG compliant (10) (other
DFSG points are ok too; no mention of specific distribution point or
restriction, classical licenses).

The only thing is that in main the set of components that I've pushed
may Depends on each other for runtime, but a simultaneous push in main
of those should in theory be ok (2.2.1 : None of the packages in the
main archive area require software outside of that area to function.)

If binary jars for compilation are a problem, what should be done when
for example you have a font file (with DFSG compatible license) that is
used for generating image files at build time and those generated images
will be included in the binary package. Should that source package be
refused because the project didn't include the source of the font file
(which can come from another project) ? (that could be a font file or
any image without the source but with a DFSG license still)

Sorry to play the devil's advocate and being irritating, I'm not that
kind :), just willing to understand.
So, am I missing some clear and strict policy point or is that a
question of interpretation.

F.

> 
>   Thorsten
> 
> 
> 
> ===
> 
> Please feel free to respond to this email if you don't understand why
> your files were rejected, or if you upload new files which address our
> concerns.
> 

[toc] | [next] | [standalone]

#10063

Hi Thorsten,

I was asking on IRC #debian-ftp how we can deal with the current
deadlock and lamby suggested to ping you again.  We are just waiting
for advise what to do next.  If re-uploading as it was is a sensible
thing to do please let us know.  If not, what exactly do you expect
us to do?

Kind regards

     Andreas.

On Tue, Sep 05, 2017 at 09:19:44AM +0200, Frederic Bonnard wrote:
> Forwarding to the correct debian-java mailing list..
> 
> ---
> 
> Hi Thorsten,
> 
> thanks for working on that and everybody that answered to help this
> topic to progress. I've been off my computer last week.
> 
> > your package seems to consist mostly of jar files without the corresponding 
> > sources. So I am afraid I have to reject it.
> 
> That's right, there are several jars that are part of the embedded sbt
> binary distribution that is used to only build the current sbt.
> All started here :
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639910#118
> 
> There Mehdi Dogguy explained we can bootstrap sbt this way as long as we
> do not ship those binary jars in the Debian binary package. It seems
> this process has been followed for other softwares.
> 
> That looked ok for me since the spirit of Debian is there : the
> different components to upload are DFSG compliant : the sources of sbt
> are there (2) and licenses of all files are DFSG compliant (10) (other
> DFSG points are ok too; no mention of specific distribution point or
> restriction, classical licenses).
> 
> The only thing is that in main the set of components that I've pushed
> may Depends on each other for runtime, but a simultaneous push in main
> of those should in theory be ok (2.2.1 : None of the packages in the
> main archive area require software outside of that area to function.)
> 
> If binary jars for compilation are a problem, what should be done when
> for example you have a font file (with DFSG compatible license) that is
> used for generating image files at build time and those generated images
> will be included in the binary package. Should that source package be
> refused because the project didn't include the source of the font file
> (which can come from another project) ? (that could be a font file or
> any image without the source but with a DFSG license still)
> 
> Sorry to play the devil's advocate and being irritating, I'm not that
> kind :), just willing to understand.
> So, am I missing some clear and strict policy point or is that a
> question of interpretation.
> 
> F.
> 
> > 
> >   Thorsten
> > 
> > 
> > 
> > ===
> > 
> > Please feel free to respond to this email if you don't understand why
> > your files were rejected, or if you upload new files which address our
> > concerns.
> > 





-- 
http://fam-tille.de

[toc] | [prev] | [next] | [standalone]

#10065

Hi Andreas,

On Wed, 4 Oct 2017, Andreas Tille wrote:

> I was asking on IRC #debian-ftp how we can deal with the current
> deadlock and lamby suggested to ping you again.  We are just waiting
> for advise what to do next.  If re-uploading as it was is a sensible
> thing to do please let us know.  If not, what exactly do you expect
> us to do?

as long as all sources are available in the upload, I think the "buildable 
from source"-requirement can be loosened for bootstrapping the package.
If I remember correctly, the missing sources and the incomplete 
debian/copyright have been the only reasons for the rejection (except 
somebody else objects now).


On Tue, Sep 05, 2017 at 09:19:44AM +0200, Frederic Bonnard wrote:
>> If binary jars for compilation are a problem, what should be done when
>> for example you have a font file (with DFSG compatible license) that is
>> used for generating image files at build time and those generated images
>> will be included in the binary package. Should that source package be
>> refused because the project didn't include the source of the font file
>> (which can come from another project) ? (that could be a font file or
>> any image without the source but with a DFSG license still)

Generally speaking, if you can not build each part of a binary package 
from source, this package can not be in main. Somehow you have to create 
that font file, afterwards you create the images and put them into the 
binary package. This doesn't sound much different from compiled sources!?

   Thorsten

[toc] | [prev] | [next] | [standalone]

#10095

Hi folks,

is there anything I can contribute?  It would be great if we could come
closer to the problem I was asking for in the beginning of the year[1]
to get sbt working.

Kind regards

       Andreas.

[1] https://lists.debian.org/debian-mentors/2017/02/msg00239.html

On Wed, Oct 04, 2017 at 10:42:53PM +0200, Thorsten Alteholz wrote:
> Hi Andreas,
> 
> On Wed, 4 Oct 2017, Andreas Tille wrote:
> 
> > I was asking on IRC #debian-ftp how we can deal with the current
> > deadlock and lamby suggested to ping you again.  We are just waiting
> > for advise what to do next.  If re-uploading as it was is a sensible
> > thing to do please let us know.  If not, what exactly do you expect
> > us to do?
> 
> as long as all sources are available in the upload, I think the "buildable
> from source"-requirement can be loosened for bootstrapping the package.
> If I remember correctly, the missing sources and the incomplete
> debian/copyright have been the only reasons for the rejection (except
> somebody else objects now).
> 
> 
> On Tue, Sep 05, 2017 at 09:19:44AM +0200, Frederic Bonnard wrote:
> > > If binary jars for compilation are a problem, what should be done when
> > > for example you have a font file (with DFSG compatible license) that is
> > > used for generating image files at build time and those generated images
> > > will be included in the binary package. Should that source package be
> > > refused because the project didn't include the source of the font file
> > > (which can come from another project) ? (that could be a font file or
> > > any image without the source but with a DFSG license still)
> 
> Generally speaking, if you can not build each part of a binary package from
> source, this package can not be in main. Somehow you have to create that
> font file, afterwards you create the images and put them into the binary
> package. This doesn't sound much different from compiled sources!?
> 
>   Thorsten
> 
> 

-- 
http://fam-tille.de

[toc] | [prev] | [next] | [standalone]

#10151

Hi,

I wonder whether somebody keeps on working for this and what help I
could possibly provide.

Kind regards

      Andreas.

On Tue, Sep 05, 2017 at 09:19:44AM +0200, Frederic Bonnard wrote:
> Forwarding to the correct debian-java mailing list..
> 
> ---
> 
> Hi Thorsten,
> 
> thanks for working on that and everybody that answered to help this
> topic to progress. I've been off my computer last week.
> 
> > your package seems to consist mostly of jar files without the corresponding 
> > sources. So I am afraid I have to reject it.
> 
> That's right, there are several jars that are part of the embedded sbt
> binary distribution that is used to only build the current sbt.
> All started here :
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639910#118
> 
> There Mehdi Dogguy explained we can bootstrap sbt this way as long as we
> do not ship those binary jars in the Debian binary package. It seems
> this process has been followed for other softwares.
> 
> That looked ok for me since the spirit of Debian is there : the
> different components to upload are DFSG compliant : the sources of sbt
> are there (2) and licenses of all files are DFSG compliant (10) (other
> DFSG points are ok too; no mention of specific distribution point or
> restriction, classical licenses).
> 
> The only thing is that in main the set of components that I've pushed
> may Depends on each other for runtime, but a simultaneous push in main
> of those should in theory be ok (2.2.1 : None of the packages in the
> main archive area require software outside of that area to function.)
> 
> If binary jars for compilation are a problem, what should be done when
> for example you have a font file (with DFSG compatible license) that is
> used for generating image files at build time and those generated images
> will be included in the binary package. Should that source package be
> refused because the project didn't include the source of the font file
> (which can come from another project) ? (that could be a font file or
> any image without the source but with a DFSG license still)
> 
> Sorry to play the devil's advocate and being irritating, I'm not that
> kind :), just willing to understand.
> So, am I missing some clear and strict policy point or is that a
> question of interpretation.
> 
> F.
> 
> > 
> >   Thorsten
> > 
> > 
> > 
> > ===
> > 
> > Please feel free to respond to this email if you don't understand why
> > your files were rejected, or if you upload new files which address our
> > concerns.
> > 





-- 
http://fam-tille.de

[toc] | [prev] | [next] | [standalone]

#10152 — Re: =?us-ascii?Q?scala-tools-sbinary=5F0=2E4=2E2+2=2E11=2EM5-1=5Famd?= =?us-ascii?Q?64=2Echanges?= REJECTED

[Multipart message — attachments visible in raw view] — view raw

Hi Andreas,
sorry for not answering recently. The reason for this is that I'm
actively investigating another way of doing the bootstrap since 2weeks
and would have liked to have something to say.
So, yes, I'm still on that front.
I don't give up the first way I tried, but I try to see if I can't
do another way that is less complex : having things in non-free may
be easy and faster, but pulling all that to main afterwards may be
difficult.. I'm not sure.
Also, I feel like having less control over the process as I did, because
I fear that some deps may generate "bigjars" and include .class files
that weren't compiled but extracted from library jars provided to
bootstrap...
At the moment, my idea is to try to compile sbt by just providing all
the scalac commands needed and try to do all the process "manually".
And do that for all the jars upon which the previous scalac commands
depends on.
So for the deps that are not compiled with sbt, I could package them
directly in main and for the one using sbt, try to do things by hand.
I just hope that there won't be any dependency where I
won't be able to use that process..

Sorry for not providing you any deadline or certainty on the outcome
of this.

F.

On Wed, 15 Nov 2017 16:56:21 +0100, Andreas Tille <tille@debian.org> wrote:
> Hi,
> 
> I wonder whether somebody keeps on working for this and what help I
> could possibly provide.
> 
> Kind regards
> 
>       Andreas.
> 
> On Tue, Sep 05, 2017 at 09:19:44AM +0200, Frederic Bonnard wrote:
> > Forwarding to the correct debian-java mailing list..
> > 
> > ---
> > 
> > Hi Thorsten,
> > 
> > thanks for working on that and everybody that answered to help this
> > topic to progress. I've been off my computer last week.
> > 
> > > your package seems to consist mostly of jar files without the corresponding 
> > > sources. So I am afraid I have to reject it.
> > 
> > That's right, there are several jars that are part of the embedded sbt
> > binary distribution that is used to only build the current sbt.
> > All started here :
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639910#118
> > 
> > There Mehdi Dogguy explained we can bootstrap sbt this way as long as we
> > do not ship those binary jars in the Debian binary package. It seems
> > this process has been followed for other softwares.
> > 
> > That looked ok for me since the spirit of Debian is there : the
> > different components to upload are DFSG compliant : the sources of sbt
> > are there (2) and licenses of all files are DFSG compliant (10) (other
> > DFSG points are ok too; no mention of specific distribution point or
> > restriction, classical licenses).
> > 
> > The only thing is that in main the set of components that I've pushed
> > may Depends on each other for runtime, but a simultaneous push in main
> > of those should in theory be ok (2.2.1 : None of the packages in the
> > main archive area require software outside of that area to function.)
> > 
> > If binary jars for compilation are a problem, what should be done when
> > for example you have a font file (with DFSG compatible license) that is
> > used for generating image files at build time and those generated images
> > will be included in the binary package. Should that source package be
> > refused because the project didn't include the source of the font file
> > (which can come from another project) ? (that could be a font file or
> > any image without the source but with a DFSG license still)
> > 
> > Sorry to play the devil's advocate and being irritating, I'm not that
> > kind :), just willing to understand.
> > So, am I missing some clear and strict policy point or is that a
> > question of interpretation.
> > 
> > F.
> > 
> > > 
> > >   Thorsten
> > > 
> > > 
> > > 
> > > ===
> > > 
> > > Please feel free to respond to this email if you don't understand why
> > > your files were rejected, or if you upload new files which address our
> > > concerns.
> > > 
> 
> 
> 
> 
> 
> -- 
> http://fam-tille.de
> 

[toc] | [prev] | [next] | [standalone]

#10213 — Re: =scala-tools-sbinary REJECTED

Hi Frédéric,

On Thu, Nov 16, 2017 at 10:55:52AM +0100, Frédéric Bonnard wrote:
> ...
> 
> Sorry for not providing you any deadline or certainty on the outcome
> of this.

Thanks for the explanation - feel free to ping me if you need any
sponsoring.

Good luck with your progress

      Andreas.

-- 
http://fam-tille.de

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.java

csiph-web