Hi, On Tue, 11 Apr 2017 16:21:05 +0200, Andreas Tille <andreas@an3as.eu> wrote: > Hi Frederic, > > 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 > discussion. yes, no problem. > 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 <andreas@an3as.eu> wrote: > > > Hi Frederic, > > > > > > thanks for this packaging effort. I'd like to come back to my initial > > > problem[1] 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) : > > https://mentors.debian.net/packages/uploader/frediz%40linux.vnet.ibm.com > > 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. do you think of a different way of pushing those packages in Git ? Because when we discussed previously, you mentionned that those packages are made of multiple source tarballs and that git-buildpackage does not deal with that properly : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855941#34 Also there is a load of binary jars which are used, for the time being, to bootstrap packages using sbt as build tool, and I was not sure if git was adapted to that (well it will handle this I guess, but within the Debian process, I don't know). What do you think ? (Still, VCS would really be nice for team comaintaining of course given the number of package that will be needed) Given that all jars currently embedded will disappear one day, we will end up using a VCS for sure. Doing without for now as for scala-pickling can help to speed up package submission to NEW queue. But is that time gap, between now and the end of the bootstrap acceptable without VCS? I don't know since I have no idea of it. But I guess it will take months. I don't think the packaging will evolve too much though as the needed libraries for the different sbt modules are numerous but don't evolve much (for those I could check the upstream history). What do you think ? is there some intermediate solution ? > > 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? well, I'm not sure, I just considered the following facts : - this is work in progress and sbt will need many more modules to just build any random project out there ( but on the other hand this can never end ) - the bootstrap process is not finished (and all this source packages looks ugly to me as there are with embedded jars :) ) ; but this take a bit of time - I'd like to play more with all this (I'm not a scala expert) and have some reviews from scala guys - debian freeze is ongoing My unstable-experimental slider bar is not well calibrated so far, I'm not used to estimate that kind of things actually :) On the other hand having sbt reach unstable and people hitting problems of some particular sbt modules not yet packaged or worse, may help dragging some workforce :) and help test all this (such as your pilon package). Also, those packages I did so far enable sbt to minimally run, so at least it's not broken, just missing modules. > > 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 : > > https://mentors.debian.net/packages/uploader/frediz%40linux.vnet.ibm.com > > 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 > emphasis. ok > Thanks for your contribution welcome F. > > Andreas. > > > > > > > [1] 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 <ftpmaster@ftp-master.debian.org> 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 > > > > > > > -- > http://fam-tille.de >
Attachment:
pgpmNGG4D4Yh7.pgp
Description: PGP signature