Re: Comments regarding scala-pickling_0.10.1-1_amd64.changes
- To: Frederic Bonnard <email@example.com>, Debian Java List <firstname.lastname@example.org>
- Subject: Re: Comments regarding scala-pickling_0.10.1-1_amd64.changes
- From: Andreas Tille <email@example.com>
- Date: Tue, 11 Apr 2017 16:21:05 +0200
- Message-id: <[🔎] 20170411142105.GO6026@an3as.eu>
- In-reply-to: <20170411155842.GF23789@kin.test.toulouse-stg.fr.ibm.com>
- References: <E1cvpDo-0006Fy-S3@fasolo.debian.org> <20170410152000.GF5383@kin.test.toulouse-stg.fr.ibm.com> <20170411114827.GJ6026@an3as.eu> <20170411155842.GF23789@kin.test.toulouse-stg.fr.ibm.com>
I took the freedom to copy your mail to Debian Java list where this
discussion seems to belong to. If you agree please stick to list
On Tue, Apr 11, 2017 at 03:58:42PM +0200, Frederic Bonnard wrote:
> Hi Andreas,
> On Tue, 11 Apr 2017 13:48:27 +0200, Andreas Tille <firstname.lastname@example.org> wrote:
> > Hi Frederic,
> > thanks for this packaging effort. I'd like to come back to my initial
> > problem how I could build a project using
> > sbt $* one-jar
> > How far are we from this and how can I (who has *no* idea at all about
> > scala) help to reach this. Sponsoring additional packages is fine in
> > any case.
> You got it :)
> Here is the list of packages that are done the same way scala-pickling
> was done (and which was accepted by ftpmasters) :
So we are only 10 packages away. ;-)
New queue is quite empty currently - lets fill it! ;-)
Would you mind moving all these to pkg-java Git and ping me step by
step. I'm fine by uploading also those packages where a predependency
remains in new. I'd use a local apt repository and thus we could speed
up the process a bit.
> Those packages enable to have a sbt command working with a dummy
> project, i.e. this set of package is a minimal set of binary/lib to run
> "sbt help" :) .
> Now sbt is a modular tool, which means that there are hundreds of
> library/plugins that provide different capabilities in your scala build
> "recipe". So, depending on the package that uses sbt as build tool, some
> additional plugins for sbt may be needed and thus needs to be packaged.
> So, this set of packages may be enough so that you can build pilon but
> from my experience, I'd expect that it would need unpackaged libs.
> So the work would then be to identify those and continue that process of
> packaging till you can get pilon to build with sbt.
> My goal was to identify and bring this minimal sbt related packages so that other
> people interested can continue the plugin packaging task and also a "method" to
> package those during the bootstrap (since not all those plugins are in Debian and
> are brought at the moment with the *bootstrap* source tarballs).
Thanks for the helpful explanation.
> Of course, I can help for pilon and its sbt-related build deps.
Cool. So lets get sbt into Debian and than have a look at pilon. BTW,
I think we can upload right to unstable instead of experimental or do
you have good reason to play inside experimental sandbox?
> I hope my explanations are understandable else, feel free to ask :)
I think your explanation was verbose enough to let me understand the
course of needed actions.
> For now, all the packages I have on mentors.d.o are related to this
> minimal sbt and its libs and need sponsoring :
> I guess I still need to open RFS bugs for every of them, right ?
As it concerns me I'm fine if I find the package in any team VCS and you
ping me. My personal sponsoring policy is that I sponsor directly from
VCS and I do not care about RFS bugs.
I'd also like to mention that in the long term you might consider
becoming a Debian Maintainer. Seems you are doing pretty complex stuff
and thus have understood even advanced packaging. Once we might be able
to run `sbt help` I'll probably ask you for this with a stronger
Thanks for your contribution
> >  https://lists.debian.org/debian-mentors/2017/02/msg00239.html
> > On Mon, Apr 10, 2017 at 03:20:00PM +0200, Frederic Bonnard wrote:
> > > Hi Thorsten,
> > > do you mean, is there a reason for all these files that I included
> > > rather than the entries thus created in the debian/copyright for these
> > > jars ?
> > > Concerning the former, scala-pickling uses sbt make-like tool to build
> > > itself. Similarly, lots of scala libraries are build with sbt.
> > > But sbt is not in Debian. And scala-pickling is one of its
> > > Build-Depends . So to bootstrap sbt, I'm bringing all sbt and all its
> > > libraries needed as binary and thus there are a lot of jars to drag
> > > which are those jars files.
> > > Then I have to give the licenses and copyright of all files in the
> > > packaging, including the additional jars, right ?
> > > In the long term, those jars will be packaged in Debian, and the
> > > bootstrap process will not be needed any longer, and we could get rid
> > > of all those bootstrapdeps-entries.
> > > Does this answer you question ?
> > >
> > > F.
> > >
> > >
> > > On Wed, 05 Apr 2017 17:59:56 +0000, Thorsten Alteholz <email@example.com> wrote:
> > > > Hi Frederic,
> > > >
> > > > I marked your package for accept, but is there a reason for all those
> > > > bootstrapdeps-entries in your debian/copyright?
> > > >
> > > > Thanks!
> > > > Thorsten
> > > >
> > > >
> > --
> > http://fam-tille.de